The last few years, XML has become the preferred format to exchange information between heterogeneous systems. Conversions between the XML format and the programming data structures like java objects can be a bit slow and those conversions are hard to develop. This creates a virtual barrier between the java world and the XML world.

 

Of course, developers wouldn't be developers if they didn't find a way around this little problem. In a first wave, technologies like XPath and XSLT were created. So with those technologies at hand, developers didn't need to convert the XML to an Object Oriented Programming (OOP) environment to do the transformation, that way avoiding the barrier.

 

The second wave was WSDL, SOAP and web services. First the focus was on RPC-style web services, now a shift is finalizing towards document style web services. Once this dust was settled the net result was a standard interface language for XML based integration.

 

Recently, a third wave has started to unfold that builds on top of the WSDL interface language. On the XML specifications front, there's the WS-* specifications, of which WS-BPEL is the one that most clearly shows the trend. In Java land there is Java Business Integration (JBI). Let's take a closer look at those two.

 

The basis of WS-BPEL can best be described as an XML scripting language that has WSDL service invocations as its primitive operations. Simply spoken, you write a function in XML that is comprised of control constructs and WSDL operation invocations. That function can now be exposed as a new WSDL service. This is of course oversimplified. In reality, WS-BPEL adds a lot of syntactic sugar on top of this. But you can sense that this technology allows you to do some processing/programming in the XML world without crossing the barrier of XML conversion to Object Oriented Programming (OOP) objects.

 

Java Business Integration (JBI) specifies a component platform for WSDL based services. It has a similar structure as other component technologies like e.g. JMX, OSGi, Session EJBs. But the difference is that JBI targets this bus and component structure in the XML world. This is achieved by using WSDL as the interface language for the components (Service Engines).

 

This third wave clearly marks a trend towards a complete programming paradigm in the XML landscape. So we started off by avoiding the XML parsing problem. But now, the XML programming has introduced a new problem. Development of XML software is not as easy as we'ld hoped for. In traditional OO programming languages we have powerfull debuggers, unit testing, refactoring and more. Will that be the next step in this XML evolution ? Duplicating that effort in the XML landscape ?

 

Currently the $64 question that this trend puts forward is "What is the natural balance between OOP and XML programming ?". What kind of programming should we be doing in plain OOP and what processing is appropriate in the XML world ?

 

Stay tuned here on this blog for my answer on these questions in my next blog: "My appreciation of the Enterprise Integration Patterns".