Programming inside orchestrations: Where should I put the code?

  • Article

Abstract: A common question from my customers: ‘how much code should be in the orchestration, and how much code should be leveraged into .NET components?’

In the BPEL standard, a business workflow is used only to coordinate the execution of components (web services). With XLANG, you can add .NET code, so the workflow have not only the orchestration, but also the implementation.
But the matter is that, the fact that you can code inside the orchestration does not mean that you should, of course .  Why? Well, apart from all the stuff in my previous posts, from the technical point of view it’s difficult to maintain and difficult to debug. From my experience, the guideline is to put few code inside the orchestration, with the following rules:

The orchestration should contain:

  • Control flow. That is, shapes and messages.
  • Code needed to make the control flow run. Loop variables, initializations, helper calls, etc. --> if it’s simple.

The code leveraged to components should be:

  • Code dealing with technical aspects. Resources, Xml/XPath handling, conversion algorithms, anything that requires error handling, etc,
  • Control flow code, if complex, and/or requires technical stuff.

My justification is that leveraging code to components has the following advantages:

  • Easy to debug.
  • Easy to maintain.
  • Can have error handling.
  • Can use any CLR feature that you want.
  • Use the .NET language of your choice :-)
  • Some other more, sure…

So, go on and use helper components, and refactor everyday!

feedback?