Several times on my current project there has been push back and push forward on architecture decisions. For instance the NxBRE solution, which I was stoked about working on, has gone away. I am now creating a row based database result set processor instead. It wouldn’t be my first choice in management of unknown rules but sometimes you take the tasks and just run.
With that I will continue my future writings on topics pertaining to my personal project of a Transit Engine. What I mean by a Transit Engine I will ellaborate. I am breaking down the technology, politics, economics, and function of transit services, including single occupancy vehicle modes such as automobiles, and building an object model, prospectively an API/SDK, application, and other pieces that will be able to work together to model logistics and transportation around various areas of the world.
So stay tuned and I WILL have some model objects, diagrams, and other cool info related to my ongoing project.
So after a far longer process than I originally had planned on (fortunately I had saved a ton of time by using a prebuilt solution such as NxBRE) I acheived a building integration of the NxBRE Project into the primary Visual Studio Solution. No particular fault of NxBREs it is just that some of the references and other items got fubared when moved across. That leads me to…
…Visual Studio Team Server’s Source Control would NOT let me just add the project. I’m not sure what the deal was with that, but it was determined. What I had to do in the end was literally do a manual creation of a project and name it the same, then add all the files as one would existing code files. After working out the bugs everything seems hunky dory. Gracious though it was a bit of excessive work that I didn’t really need to focus on at this time.
Now that this is done I intend to in the next few days create some examples and stick them up on the site in relation to utilizing NxBRE.
Besides the refactor tool, check out the website. Very nicely built, very responsive user interface.
The NxBRE Application is available at the owner Agile Partner’s Website. It is located in a sub path at http://www.agilepartner.net/oss/nxbre/. To the left of the page one can download the software package via the download link. The download is provided along with source control by SourceForge.Net.
There are three primary packages to download. Click the NxBRE download button and you will find the IE-Console, Miscellaneous (Extra Documentation), and NxBRE Packages available for download. Personally I’d put each download into one directly. Unzip each respective file into a respective directly within the single directory the files are placed into.
Once everything was downloaded, unzipped, and placed in their proper order I began opening each project/solution to organize them the way I wanted. The first Visual Studio Solution I opened is ‘RuleEngine’ Solution. This solution has an “Examples” solutions folder with a “SpeedTest” project in it and a “RuleEngine” and “UnitTests” project in the primary root of the solution. Once these projects are opened do the ole’ standard “build without errors” routine. If you don’t have NUnit installed the build will break so make sure to get it downloaded and installed.
One thing that is a pet peeve of mine is to have Visual Studio based unit tests for use against projects. So with the inclusion of unit tests under the NUnit testing framework included, I started working on converting those to Visual Studio based tests. These I’ll post up in my file share section after I complete it.
For now, with the unit tests needing converted, I’m going to get the project building first. What I did was remove any links to the NUnit testing framework so the solution could build. I setup a second project that would store untouched, unedited, NxBRE Solution files. I renamed the solution file specifcally to RuleEngineU.sln just to make sure that I didn’t get confused.
After downloading and installing NUnit I set about making sure the project would build. I wanted to get it to build to assure that I had a good working model to re-write the unit tests in VS against and also as reference for when I create the actual rules engine that I will be putting into production for the project.
At this point I got everything running, created a second solution copy of NxBRE and started converting the unit tests to Microsoft’s Framework. My progress in altering those will be in a follow up entry, for now, lunch calls out to me! Grub time.
So I’ve got my scope better defined after this week on the current rules engine I need to create for the current job I’m working on. The prospect of developing this rules engine is interesting to me. In the very near future (next 2-3 business days) I will find out even more specifics about the scope requirements as I begin building, or enhancing the rules engine I decide on. So far I’m working on the following as a basis, which I might or might not use in the final engine design and implementation.
The base prototype that I am using at this time for the rules engine is the NxBRE. This engine will act as basis of whatever I end up making, whether it is a completely different engine or the NxBRE engine itself is still undecided. I’m hoping in the next few days to iron our the usage, the following is what I have to consider.
- Will the NxBRE engine do what is needed of it.
- Will the NxBRE engine cost less than a custom solution built by me? (i.e. will it take longer to build a custom solution myself, or implement this and learn how to use it and extend it?)
- Will a custom solution be robust enough for future use?
- Will enough support be available via RuleML and other features of NxBRE to meet the demands that an in house solution would provide? (i.e. will enough developers be using it to make it a “standard” for usage that is easy to train and understand?)
So with that I’ve got to test out the NxBRE engine, so the following entry will be a how to doc on how to get this sucker downloaded, installed, and running. Maybe I’ll even have time to setup some samples!