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