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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.