Yossi Dahan [BizTalk]

Google
 

Monday, December 12, 2005

My thoughts on - "A Messaging-based State Machine Design Pattern, using BizTalk Server" by Brian Loesgen

This morning I've read Brian Loesgen's post - A Messaging-based State Machine Design Pattern, using BizTalk Server (You can see how far behind I am on my "blog reading")

While I normally don't comment on other people's posts (fear of revenge?)
I did feel it might be worth adding my thoughts on this one...

In his post (and I do recommend reading it) Brian suggests to break large processes into smaller blocks that can be reused - makes absolute sense of course.
He goes further and suggests a way to "chain" these blocks in a way that can be re-configured without re-building (and deploying) the solution, which is a nice goal no doubt.

While I cannot, of course, disagree with his goals I think the suggested implementation is quite simplistic and will not fit most real-world scenarios.
However, I do think the idea is good and worth looking into, so I’ve decided to contribute my two cents (or pennies in my case) to the discussion, here goes it -

In my view there are two basic problems with the approach suggested -

1. In my view - it's quite simplistic.

If I understand correctly Brian suggests that each block sets a "status" context property to something like "BlockA_Finished" before returning the message to the messagebox.
The next block in the process can then subscribe to messages with "BlockA_Finished" value and when done set it to "BlockB_Finished" and so on.

The main problem with this approach is that the overall process has to be very simple and liniar.
It does not allow any rules that are more complex then “A finished, execute B”.
If, for instance, you need something that goes – if A finished and total is 100 then do B otherwise do C (and even that is a very simplistic example) – there’s no way to do it.

2. It does not answer the requirements

I keep thinking I must be missing something here, but as far as I can think – if you currently have the sequence mentioned - A finished, start B, and a new requirement comes along meaning that you need to have process called C in between, you will have to change and re-compile process B as the filter on the initalising received shape has to change.




So, with these two problems in mind I started to think how I would implement a similiar generic concept and came with the following as one way to implementing it (I’m sure there are others) -

Create a sort of central unit (in the form of a BizTalk orchestration of course) to will accept all "completed" messages – that is messages that has came out of any single process.

For each such message that central process accepts it will decide, using the rules engine, probably with the support of a database (or any other similar generic mechanism) what is the next operation on this message.
Once decided a NextStep property on that message is set with the name of the next process required to be executed on the message and the message is returned to the messagebox.

Each process, instead of being subscribed to messages that came out of the previous process, subscribes to messages that are marked as having this particular process as their next step (by having it's name in the NextStep context property).
If needed (probably yes), another pre-defined property can be used to pass information between processes in a generic way using a pre-defined structure (something called Xml, rings a bell?)

What we've got now is a chain in which each singular step does not need to be aware about anything outside it’s scope, definitely not the previous step or next step in the chain.
In fact – we’re definitely not limited to a simple step by step chain at all.

What it also means is that we’ve ended up creating is a what is the basis of every workflow product out there (as opposed to a development server like BizTalk Server), and as you may know there are quite a few in the market which makes me think if there's a point to doing this in the context of a project...


1 Comments:

  • Quickie comment: I'll have to go back an re-read my post, as it sounds like I may not have been clear. If "A" calls "B" calls "C", then "A" does *not* need to know about "B", that's the whole point. "A" just does something with the message, such as updating a status field, and B is listening for that. If you wanted "D" to run in parallel, then "D" could also listen for that same status, so you'd now have one serial path bu also a parallel branch. Putting the "what status do I set this to when I am done?" piece in the rules engine is a great way to do it (we've used that on past projects), as it decouples the flow and lets you change it externally.

    By Anonymous Brian Loesgen, at 28/01/2006, 23:05  

Post a Comment

<< Home