Inside Architecture

Notes on Enterprise Architecture, Business Alignment, Interesting Trends, and anything else that interests me this week...

On XML Models of Process

On XML Models of Process

  • Comments 4

XML is an interesting language, but is it a useful one for describing a process?

We have multiple competing standards for workflow and collaboration.  We have BPEL, XPDL, SWFL, XRL, XScufl, and custom XML workflow models developed for the XFlow, AntFlow, Agile, YAWL, and OpenWFE tools.  (If anyone is looking for a good idea for a masters thesis in Workflow, they should create a comparison of these different languages, catalog features, and create a roadmap for the rest of us).

Just to add to the fun, rather than learn an existing modelling language, I wrote my own for an internal tool I'm working on.  Wise?  Probably not.  In keeping with the philosophy of the project?  Yes.  Most of the languages I mention above are the creation of committees and have many features designed for multiple vendors to extend the core set.  I needed less (features demanded by existing Java projects) and more (features specific to my Microsoft-based solution).

I also needed a language feature that I didn't see anywhere else, including on the workflow patterns homepage: native support for ad-hoc workflow.  This means allowing a user the right to change the routing rules in the middle of a workflow process, while the engine maintains managability.  No mean feat. 

So, inspired by YAWL, and angry at the limitations of the competing partner products that we evaluated, our team wrote another XML based workflow model structure. 

I learned a few things that I want to share:

  1. XML is an interesting language, but not a forgiving one.  It is easy to create bugs by making small errors in the specification of a schema, where the downstream ripples can be quite large.  If I had to do this all again, I'd better appreciate the time it takes to create and debug the schema itself.
  2. I am far from the first person to tackle the idea of Workflow.  Perhaps it would have been better to start with XPDL (or a subset thereof).  My customers would have a better ability to switch away from my project later, which is one of the stated goals of the project.  I, on the other hand, could have leveraged the built-in workflow experience that comes from leveraging a schema that comes from workflow experts.
  3. XML is an old-fashioned declarative language.  It is about as advanced as C (not C# or Java).  Therefore, while there are many things you can do in XML, you have the freedom to do some pretty stupid stuff.  In addition, you don't have the constructs to do some elegant stuff.  By comparison, XML is an infant.  The effect: the resulting code is difficult for a human being to create, read, follow, analyze, debug, test, or support.
  4. XML parsers are touchy.  They remind me of Fortran-77 compilers.  First error and they are done.  You can't count on an error message from a parser to be all that helpful. 
  5. Tools for generating XML are new, but getting better.  Two commercial tools worth mentioning: Microsoft Infopath (the most underrated, creative, well-built, xml forms system I've seen), and Altova Stylevision (an interesting product that suffers primarily from the lack of imagination of its original designers, not the details of the implementation).  Add Visual Studio for Schema generation and you have almost everything you need.
  6. Automatic mapping between XML and databases: a new and immature field.  The current bits in SQL Server 2000 are OK, but I'm looking forward to better capabilities in Yukon and other tools.  Right now, I wouldn't count on using automatically generated or automatically parsed XML as a way of reducing struggle and pain on a development project.  You will only replace one kind of agony with another.
  7. Like any code-based method, process declaration in XML inherently describes only one aspect of a process: the static connectivity between pre-declared states.  The dynamic aspect is not well described or modeled when you focus on the static.  Some folks have tried to focus on a dynamic model exclusively, but the resulting description was even harder to understand (refer: Biztalk HWS).  In other words, the model, in XML, isn't clean enough to provide to business users.  A LOT of translation is required.  XSLT comes in very handy.
  8. Even with these drawbacks, I can't imagine a better way.

So, XML it is.   And for now, I'm still using my proprietary schema for workflow models.  Perhaps, someday, I will switch over to BPEL or XPDL.  But not this day.

  • Nick,

    I too have wrestled with what you are experiencing as well. However, I think it just boils down to an issue of portability. As you've stated so eloquently, while XML is good at some things as it relates to process definition, it is bad at others and gives you freedom to make some really stupid mistakes. But because it's a "portable" vocabulary for describing business process, its benefits far outweigh its shortcomings. I've built workflow-based applications around a more relational model, but kept coming back to the XML-based model just because of the simplicity of deployment, configuration, and maintenance.

    But you know, one of the more interesting challenges is being able to distribute a given process definition to multiple instances of a process execution engine and have them all participate as if it were one instance doing performing all the processing/execution (without human intervention). I talk a little more about this on my blog post regarding state management. This is one area, even BizTalk Server hasn't been able to master. XML is making this much easier to describe and implement and provides for a more "packaged" solution.

    I have my reservations with more "standard" process definition languages such as BPEL, primarily because I don't think we'll ever get to a point where we can capture every conceivable business scenario into a single vocabulary. However, I do believe that all languages could exhibit a "common" subset and then implement their own extensions. Having some level of commonality promotes better interoperability yet doesn't lock you completely into a path where you "do or die" :-)

    Really good post.
  • Nick,

    I just read your response to my blog post on state management. Thanks for the response. I also handle "calling" into another model (as you mentioned in your response) via what I call transition handlers. I provide infrastructure where custom components that implement my ITransitionHandler interface, could hook into a given process flow and call out to another process and supply information via a TransitionParameterCollection of TransitionParameter objects. These objects *could* contain information for executing a given activity within a process thereby serving as another sort of "message transport", however, this type of functionality would be restricted to only working on a single machine just because of its current implementation and the fact that it wouldn't be transporting all of the state and the receiver would need to be knowledgeable of ITransitionHandler as well. My rules engine does something similar through the use of the BusinessRuleManager and delegates. But the underlying transport medium in all of this still goes back to tried and true XML :-)

    Portability, flexibility, and configurability make XML the de facto choice (I guess)
  • Hi Nick - interesting article very much reflecting the current screaming little circles I was running around in.

    I was curious though - isn't BizTalk all about modelling processes? Does it use XML to store it's process model - if so, is it a propietary format, or one of the 'standards' you listed above?
  • Hi Neil,

    Yes, Biztalk is all about modelling processes. It's strengths lie in creating a model for helping applications collaborate, not in helping people collaborate. I'm sure that the human workflow parts will mature and become a strength for BTS, but I know that I was challenged to use BTS Human Workflow Services, and I found it daunting at best.

    BTS uses BPEL to store its process model.
Page 1 of 1 (4 items)