Now that the BRE pipeline framework v1.3.0 has been released and is also compatible with BizTalk Server 2013 I am starting to think of what the next version is going to deliver.
My colleague Craig Haiden who has recently joined the project team (and who’s brain is a bit like an ESB toolkit :)) had the brilliant idea to add an optional ResolverPolicy parameter to the pipeline component that allows you to call a resolution BRE policy before calling an InstructionLoaderPolicy or an ExecutionPolicy. This ResolverPolicy would allow you to evaluate your message content/context using the out of the box vocabulary definitions and then based on the evaluation results you could decide which InstructionLoaderPolicy and ExecutionPolicy you want to call on during the execution of your pipeline component. This could open the door towards a much simplified implementation of the ESB pattern without using the ESB toolkit and would allow you to create generic onramps/offramps using this framework.
Another feature I have been thinking of is allowing for the XML message itself to be asserted in a typed fashion as a fact so that one could use XML vocabulary definitions to evaluate or update the XML message. This would require an extension of the InstructionLoaderPolicy framework to allow for the assertion of the XML document in a typed fashion to the ExecutionPolicy. Now this would be a relatively expensive operation for a pipeline but might be handy in messaging only scenarios to avoid unnecessary orchestrations from being created as a container for BRE execution.
A nice to have would be to extend the BREPipelineFramework.SampleInstructions.HelperInstructions such that it supports regex based find replaces on the message body just because I have seen this requirement on so many projects (even though it makes my spine tingle to think that a message has to be manipulated in this fashion on a pipeline, sometimes it is just necessary).
Does anyone else have anything that they would like to add to the wish list? Do let me know so we can consider them, and do remember that the framework follows a plugin model and that you can create and use your own MetaInstructions/Instructions and corresponding vocabulary definitions.