ILOG Rules for .NET 3.0 – quick overview

Andrew Siemer's Blog Enterprise Web Applications, ASP.NET MVC, C#, SQL Server, Architecture, & Writing

<< Entity Framework : An entity object cannot be referenced by multiple instances of IEntityChangeTracker. | Home | Word Press Tag Cloud to be reused across other tag-able systems – WP Cumulous >>

Comments (9) | Share

I have been working on a project for the past year or so. This project was originally decided to be implemented in a BizTalk environment. Although most of us were new to this form of SOA development we went ahead with the understanding that we would eventually learn enough to stand up, manage, and develop for BizTalk. With this in mind we developed our entire application in such a way that we thought the app would simply plug in to the BizTalk environment (from an orchestration point of view any ways).

Some of the reasons that we decided to go with BizTalk was that it was very scalable, configurable, flexible, and that it had many components that we could easily use in our application. Some of these components were the Business Rules Engine (BRE), various reporting tools (BAM), built in queue integration, etc. We liked the idea of using already built and tested components. Why recreate the wheel after all? After we played with BizTalk for quite some time, took several classes, and spent many months with our BizTalk consultants, we eventually heard one statement that summed up BizTalk in every way:

“BizTalk can do anything you want it too, it just can’t do anything out of the box!”

Whaaaaa?

Any ways…again…a year later I am still working on an application that needs some of these BizTalk style components. One of which we have found is needed more and more. We needed an external program to manage the flow of our application. One might immediately jump to Windows Workflow Foundation and the Rules Engine that comes with WWF. However, one of the marching orders of this application is that the business users can make changes to the logic of the application in such a way that it doesn’t require a code push and is not restricted by the length of a development cycle. We had looked into several rules engines along the way to see if any were capable of addressing this need. All of the rules engines that we came across were Java based and forced you to integrate with them via web services. Yuck.

We eventually came across ILOG Rules for .NET. This is a program (now owned by IBM and a Microsoft Gold partner) that integrates into a .NET developers world in a very seamless manner. It plugs right into Visual Studio allowing the developer to define flows, express facts to rule editors, verbalize those facts in a more business friendly manner, and call into the execution server to run the rules all without any headache at all.

In addition to that the rules, decision tables, and flows can be edited externally in Microsoft Word or Excel.

And for those in a real Microsoft shop you probably have a SharePoint installation to manage all of your documents. SharePoint is also fully integrated into this suite for rule doc management, workflow management, etc. (sorry, no screen shot of this yet)

The best part of this application in my mind is that ILOG gives you a 6 month free trial of the fully functional suite! This means that you can easily knock together a proof of concept before you purchase their (very reasonably priced) program. http://www.ilog.com/dev/brms/rfdntrial/ And another benefit to their free trial is that they provide you will full access to their support forum. I had a few issues during my POC development that I got pretty quick help with through this online help format!

In future posts I will show my proof of concept and address some of the gotchas that I ran into.

I am going to assume that you can get through their registration and free trial download process. I am also going to assume that you can get all of their programs installed and running (they cover that pretty well).

One word to the wise – do be sure to install the execution server first so that you don’t have to mess with any configuration files down the road! This should be pretty easy as it is the first installer you come across.

Also, be sure to read through their various documents and white papers (with the QuickStart being the most helpful!):

Quick Start	C:\Program Files\ILOG\ILOG Rules for .NET Quick Start 3.0\Documentation\QuickStart.pdf
White papers	http://www.ilog.com/products/rulesnet/whitepapers/
Online help	http://docs.ilog.com/brms/documentation/rulesnet30/

Posted on Monday, March 30, 2009 3:14 PM | Back to top

Comments on this post: ILOG Rules for .NET 3.0 – quick overview

# re: ILOG Rules for .NET 3.0 – quick overview

Your quick review for the .NET is very helpful for somebody wondering why people still need BRMS engines when there is already BizTalk Server.

Have you evaluated InRule ? They are also Microsoft Certified Partner and claim to plug-in very well with .NET platform and BizTalk.

How would wou compare InRule to ILOG for .NET ?

Left by Mihai on Apr 29, 2009 5:46 AM

# re: ILOG Rules for .NET 3.0 – quick overview

There will almost certainly be a need for BRMS outside of BizTalk for a few reasons. A BizTalk implementation blows a BRMS out of the water in terms of price. So if all you need is a rules engine...and nothing else...then why would you spend all those extra dollars on a super powered SOA bus that also happens to do rules? We actually looked at BizTalk and if I were to just need rules it would have a way to high learning curve to be even remotely approachable for the average Joe. BRMS by way of ILOG Rules for .NET is super easy. The average Joe (or less) can get it up and running in literally one day!

Regarding InRule, yes - I looked at them too. While they may have almost as mature a product from the rules engine perspective they do not have all the tools that lay around the peripherals. For me this is a problem simply because our reason for getting a rules engine such as ILOG Rules for .NET was to remove as much business logic from our applications in a manner that someone that was more familiar with business rules than my development team was...could make direct (or very close to direct) changes to that logic separate from what ever was in the immediate development cycle. ILOG Rules for .NET delivers very well on this promise in the form of Rule Studio (100% integration with Visual Studio), Word and Excel plugins (for writing rules and decision tables), Team Server which plugs in to Sharepoint for rule artifact management, and the Execution Server management tool (forgetting it's name at this moment) which any windows administrator will be immediate familiar with. RFDN also integrates seamlessly with both BizTalk and Windows Workflow Foundation!

Not to mention that the team that made ILOG Rules for .NET also create JRule which is one of the industry leaders in the Java rule engines. This engine is also the underlying rule processor for Ebay...which to me says a lot! Add to that they were recently purchased by IBM and you have just the right mix to make me drool for this product!

Left by Andrew Siemer on Apr 29, 2009 7:30 AM

# re: ILOG Rules for .NET 3.0 – quick overview

I posted some observations over on at http://geekswithblogs.net/cyoung/archive/2009/04/29/131593.aspx.

One small point of information on the last comment. You get the BizTalk Rules Engine with the $2K Branch edition, so it can potentially work out a good deal cheaper to buy a BTS licence, rather than a licence for a third-party BRMS, just to get the rules engine. I have to say, though, that I have yet to come across anyone who has purchased the Branch edition for that reason alone. And, as I said in my observations, you get what you pay for. ILOG Rules for .NET is a totally different proposition to Microsoft's free/bundled engines.

Left by Charles Young on Apr 29, 2009 3:20 PM

# re: ILOG Rules for .NET 3.0 – quick overview

The BizTalk rules engine is no where near as feature rich as something like ILOG's offering though. It is purely a rules engine...nothing else. The ILOG Rules for .NET is a rule engine with many different forms of rule processing to best fit your projects needs, there are many ways to gain access to the rules and their processing (local rule execution via .net, remote execution via an execution server that is communicated with via WCF), it comes with widgets to snap into windows workflow, plugs into Visual Studio IDE, plugs into Word and Excel and Sharepoint, and is manageable in the same standard way that any Microsoft product is through an MMC. This is a much broader offering and vastly more user friendly than just the engine alone.

And if all I wanted was a rule engine to use I would use the Rule Engine that is included with Windows Workflow which comes free with .NET, already has some example UIs that sit on top of it (though you have to roll your own) and performs in exactly the same way as the BTS offering. I believe that the next version of BTS will actually be using Windows Workflow for its orchestration and rules processing needs. So you are better off learning that over the BTS rules (though they are very much alike).

Left by Andrew Siemer on Apr 30, 2009 9:04 AM

# re: ILOG Rules for .NET 3.0 – quick overview

The idea that Microsoft will rip existing orchestration functionality and replace it with WF technology was always a dangerous myth which has been robustly disclaimed by the relevant people in MS in the face of significant concern from existing enterprise customers (I know, I was there at some of the sessions). However, although the detailed design of the next version of BizTalk hasn't, I believe, been completed yet, it is inevitable that WF and WCF will have a profound effect on the future of the product.

As far as rules are concerned, everything is rather uncertain currently. Microsoft's plans have changed significantly with regard to rules in .NET 4.0 in the last few months, and it is clear that this whole issue has been looked at very carefully. One basic argument, which was made to the WF Rules people directly, is that rules engines without some level of tooling are only ever going to have limited application. MS BRE at least has some level of tooling, and a repository, which WF Rules does not have.

I don't know the details of what MS are now planning, but I believe they are looking to provide a more unified story across the platform with regard to rules. One obvious challenge, though, is that there is a world of difference between their two existing technologies. WF Rules is sequential. MS BRE is a Rete engine that processes tuple sets, rather like a database system. MS BRE has significant additional capabilities with regard to pattern matching across different tuple types (i.e., performing joins), and adopts a fundamentally more declarative approach than WF Rules, though WF Rule's forward chaining mechanism is of some help here. It is also much more scalable than WF Rules, and outperforms today's WF Rules in most scenarios. By contrast, WF Rules is significantly easier for developers to use, and frankly better suited to the bread & butter stuff of simple decision making within process flows.

The whole issue of how sequential and set-based pattern matching can be bought together in a single engine is an ongoing topic of debate in the rules community, and no one has entirely cracked the problem, although there are some interesting technologies and ideas. There is not really a uniform agreement on exactly what is meant by 'sequential' rules processing. I suspect that MS has some ideas of its own in this regard, but it is simply too early to know what the shape of rules processing will be on the Microsoft platform in the future. Of course, if Karl or Kavita or Jurgen (all from MS) would like to comment further...(just kidding, guys).

In the meantime, I warmly commend products like ILOG Rules for .NET which, as you say, offer much richer tooling and models than anything MS currently has (at a price, of course).

Left by Charles Young on May 02, 2009 4:05 AM

# re: ILOG Rules for .NET 3.0 – quick overview

Thanks Andrew and Charles for the warm review. At ILOG, we have thought a lot about various algorithms for execution and provide three in a single engine. At the end of the day, every project has its requirements and folks are free to choose the best fit. Of the three two are sequential and are optimal for different patterns within a ruleset. No single algorithm it seems can solve all problems with acceptable performance since rulesets vary in so many dimensions and integration scenarios.

BRMS is somewhat orthogonal to BPM and or orchestrated SOA. BRMS enforces a tighter life-cycle around rule management which is in reality independent of the BPM life-cycle. It makes BPM more agile just as it does architectures that don’t require BPM. We feel that BRMS is a good compliment to BizTalk and WF and see little over-lap in terms of the problems they solve. Rules tied to the process model belong in the BPM tool while rules that require a separate lifecycle belong to the BRMS. Rules managed by the BRMS life-cycle fundamentally require tooling specific to business users and provide appropriate levels of governance.

Combining BPM and BRMS is a really interesting topic—especially when one considers enterprise problems such as service proliferation. For example, the creation of slightly different services from a shared model can be avoided when BRMS is used to manage the complexity within. I intend to present a paper on this very top shortly.

Cheers!

Chris Berg
Product Manager, ILOG BRMS

Left by Chris Berg on May 12, 2009 6:05 AM

# re: ILOG Rules for .NET 3.0 – quick overview

My comment is more to be with developer perspective. We are going to have rules developed in ILOG and it is done by a separate team. What I would like to ask is how are we going to call these rules from my .NET(ASP.NET) client? is it just a service call or I will have to have some library around that?

Thanks and Regards,
Abraham

Left by Abraham Daniel on Jun 03, 2010 8:44 AM

# re: ILOG Rules for .NET 3.0 – quick overview

No one has ever stated how much this thing cost. InRule cost 100k. We need something more affordable..

Left by TLC on Sep 08, 2010 11:17 AM

# re: ILOG Rules for .NET 3.0 – quick overview

We want to try out ILOG for .NET and would like to seek your views. I have not seen a followup article. I

Left by Suryanarayana on Jul 11, 2011 5:31 AM

Your comment:

Title:

Name:

Email: (never displayed) (will show your gravatar)

Comment: Allowed tags: blockquote, a, strong, em, p, u, strike, super, sub, code

Verification: