Skip navigation
2005

Tom Baeyens's Blog

July 2005 Previous month Next month

 

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".

 

Here's a retrospective to the JBoss jBPM activities and feedback we received at this year's JavaOne conference.

 

Workflow and BPM systems have been around for a while now and orchestration engines are mushrooming all over the place. Despite the fact that all of these systems have similar goals, it is impossible to find 2 concrete solutions that are based on a common foundation. Each solution is a unique mix of functionalities. Unique mixes might be great at a coctail party but regrettably the analogy doesn't stand. You can safely trust us on this one, we seached hard but couldn't to find that analogy...

 

This fragmentation of the workflow, BPM and orchestration landscape leaves the industry in an orphaned position. Without common foundations model, there is no mindshare and almost no progress. The value of such a foundations model can be best understood if we look at the database world. There, you have 3 well known paradigms: the relational model, hierarchical databases and object orietented databases. No such model existed yet for workflow, BPM and orchestration.

 

Many people didn't realize such a model was missing and only felt confused by the diversity of the BPM offerings. In my session, we launched the idea of a unified model: Graph Oriented Programming. We had massive positive feedback after the talk and at the booth. People were very enthousiast and hopefull that this new model will bring unification and thereby opening up a whole new array of possibilities.

 

It took us 4 years of extensive research to develop the Graph Oriented Programming model. During that time, we developed a simple but powerfull kernel module. The open source community continiously challenged us and helped in defining solutions. Now, we have delivered proof that this model is capable of supporting all 3 domains: workflow, BPM and orchestration. The JBoss jBPM product is build on this model and is the only BPM engine that is able to support multiple process languages on the same kernel (plain POJO) software. JBoss jBPM has support for JPDL, which is a language focussed on managing tasklists for people and it also has a very clean integration with standard Java. But jBPM also has support for BPEL, an orchestration process language.

 

This unification in process modelling foundations also removes the necessity for multiple process engines in one software project. Instead of having to use a workflow engine and a separate orchestration engine, you now can just use the workflow extension and the orchestration extension of the same product.

 

So don't wait any longer. JBoss jBPM version 3.0 has been released just before JavaOne and you can download it today and take a look at what this means in practice.

Filter Blog

By date: