Why should we use XML-based languages (such as BPEL4WS) for orchestration flow definition instead of C# or Java?
That question relates to the more general question of why multiple languages exist to solve a particular problem. More specifically, a choice of a language relies upon its ability to provide an abstraction level that matches closely the problem that needs to solved.
Orchestration flow definition (aka orchestration logic) entails the following requirements:
- Flexible and straightforward handling of XML data for integration
- Integration of Web services as well as native components (e.g. messaging)
- Developer friendly learning curve and leveraging known design patterns
- Hide plumbing details through infrastructure
An XML language can provide a dialect to match the abstraction level of the logic that needs to be written and provides for native handling of XML and integration of Web services. This can be a good solution for simple flows but get increasingly unwieldy for expressing more complex flows. An XML dialect is naturally suited to manipulation by visual tools for design of orchestration flow.
Adam Bosworth states in his essay that "Simple things should be declarative and complex things should be procedural". In the end, the choice of an XML language versus one such as C# or Java boils down to how complex the orchestration flow is and whether the target developers are more adept in using visual tools or writing code. It is likely that emerging orchestration solutions will provide both declarative and procedural approaches to encoding orchestration flow logic.
Dig Deeper on Topics Archive
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.