BPEL-J, SOA, EoD and maintenance - (as maintainable, as JSPs) 📎
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">
<bpelj:code>
response.setTaxRate(taxRate);
response.setDiscount(discount.getRate());
float subtotal = response.getSubtotal();
subtotal = subtotal * (1 – discount.getRate());
response.setSubtotal(subtotal);
float taxes = subtotal * taxRate;
float total = subtotal + taxes;
response.setTax(taxes);
response.setTotal(total);
// Prepare the text message to be sent in the next activity.
jmsMessage = p_inquiryTopic.getSession().createTextMessage(response);
</bpelj:code>
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 :-).