Replace BRE by C# library

Jan 16, 2013 at 4:09 PM

Hi Johann,

I like the idea of this pipeline. The only stopper to use it for me is BRE. I don't use is very much. For most of my requirements it is overkill. The only good thing is the rules could be changed at run-time. But this is not the Pro of BRE but Con of BizTalk.

BRE is overkill because: it requires study very specific model of development (it hard to create, test, understand, support, trace, debugg); a different deployment mode.

I'm not a single person. The BRE adoption shows that developers don't use it. The single place where I can see BRE it is the POCs.

That's my suggestion. If the pipeline framework functionality would work on the base of plain .NET dll, I would definitely use it.

C# is much simpler in development comparing with BRE. It is less known but it is also simpler in deployment (redeployment) in BizTalk.

Thank you for this interesting framework!

Jan 17, 2013 at 3:58 AM

Hi Leonid,

Thanks for your comments.  I totally get what you're saying and I do agree with the unfortunate fact that BRE uptake amongst developers has been very poor.  In a large part I think this has to do with BizTalk's steep learning curve and the fact that BRE is a whole different mindset.

The power I see in the BRE is the fact that it is decoupled from your pipelines / orchestrations and allows for some pretty interesting potentially generic context driven patterns. 

Would I use this framework beyond just for POCs?  That very much depends on the organization in question and their commitment to the BRE.  If they are an organization that already uses the BRE to some effect, or they want their developers to build up their skills in the BRE then I'd say that this framework is a good candidate.  If the commitment is lacking, then that would probably make this framework difficult to support.

One thing of note is that all the brains of this framework is in C# classes, the idea is simply that the execution of that logic is exercised through the BRE in a human readable friendly manner.



Jan 17, 2013 at 5:57 AM

Hi Johann,

Thank you for interesting discussion.

In my experience the BRE would help if we have a lot of facts. That's where the Rete engine shines. In all other cases C# code is more friendly in every aspect.

If the whole customization logic could be placed in the "plug-in" C# class, it would be great. Say, I would take the C# interface, implement what I need, build dll, then place it in the well-known spot. Pipeline would use it.

Jan 17, 2013 at 8:51 AM

Hi Leonid,

I absolutely agree with you, and I'm not sure if I misunderstand you but that is exactly what this pipeline framework is, with a small caveat that the BRE is used as a container to actually exercise the plugins.

The customization logic (ie. a collection of methods which allow you to do stuff such as promote context properties or real values from SSO etc...) is all provided for in C# classes that derive from the MetaInstructionBase (typically used for conditional logic or to setup actions) base class or from classes that implement the IInstruction (the actions to execute) interface.

However we also need a container to actually pick and choose which logic to actually execute the logic, and selectively choose which methods in your plugin classes you want to call on and with what parameters.  I chose to use the BRE for this since it provides a level of flexibility and decoupling, rather than requiring you to provide complex parameters on your pipeline instances. I also like that BRE vocabularies allow for very self documenting logic and if well designed then BizTalk documentor output of the rules usually can be directly included in your technical documentation.

If you can think of another clean means to actually execute the plugin classes for each pipeline instance then I would be really interested to hear your idea, and would consider how the framework could be extended to provide for a non-BRE option to provide more options.



Jan 17, 2013 at 4:43 PM

As I understand, your Pipeline Framework intention is to manipulate the message context and content. Now it can be done in the pipeline components. But working with them is cumbersome and one more abstraction layer would be very helpful. 

You have implemented this layer in BRE terms. Maybe the C# implementation would be also helpful especially for those developers which don't want to use BRE but C#. Looks like these developers outnumber the BRE developers :)