The driving force of the SOA hype is the increase of maintainability and ease of development. The dream: the combination of independent services to "composite" applications in a easy and fast way is in the practice not always possible. In real world the services are only in rare case compatible - even the parameters aren't. In the practice the parameters have perhaps the same name, but totally different semantics. To make such services compatible (during the "orchestration"), you need a kind of mapping. This becomes more hard in the XML-world to establish. The idea to solve the problem comes with the WS-BPELJ specification.This specification allows the coordination of different services (the definition of the flow) and matching of parameters. It can be compared with a configurable state machine or controller (or facade). The funny story here: for more complex semantic translations - Java-Code can be used.
An example from the (WS-BPELJ) spec:
<bpelj:snippet name="Calculate Total">
float subtotal = response.getSubtotal();
subtotal = subtotal * (1 – discount.getRate());
float taxes = subtotal * taxRate;
float total = subtotal + taxes;
// Prepare the text message to be sent in the next activity.
jmsMessage = p_inquiryTopic.getSession().createTextMessage(response);
The mixture of Java-Code and XML reminds me at the old JSP days. The JSPs became often unmaintainable, so taglibs, or structured frameworks like Struts were introduced. The main idea was simple: the seperation of presentation and business logic.
I'm only curious, whether the mixture of XML and Java is more maintainable, than HTML and Java :-).
NEW: Online Workhop Effective WebApps without Frameworks is also coming to: MUC Airport.