Skip to main content

A Hitchhiker's Guide to SOA

Posted by edort on June 28, 2005 at 12:20 PM PDT

I thought that a session title that had the phrase "Hitchhicker's Guide" in it would draw a good audience, but I had no inkling of the crush of humanity waiting to get into the session "A Hitchhiker's Guide to SOA: Orchestrating Loosely Coupled J2EE Services with BPMN and BPEL." It felt like Times Square at New Year's Eve.

This was worth the mob scene. I know a few things about SOA, having written a few articles on it. However most of what I know delves into SOAP standards and JAX technologies for web services. I knew little about orchestration technologies like BPEL and nothing about BPMN, so I thought this would be a good session to sit in on.

It was definitely worth attending (even though I had to inch my way into the room with the rest of the mob). It was worth attending for two reasons. First it was witty. In a takeoff on Douglas Adams's Hitchhiker's Guide to the Universe, Beckham, Fast, and Frisino (all three are Sun Java enterprise tools architects, with Beckham Sun's lead architect) attempted to answer their version of the "Ultimate Question": What's the answer to everything? If you recall, in Adams's book, "A Hitchhiker's Guide to the Galaxy," Deep Thought, the second greatest computer of all time and space, gives the answer to the Ultimate Question. The answer is 42. Well, in Beckham's, Fast's, and Firsino's version, the Ultimate Question is: Are BPEL and BPMN the answer to everything for service orchestration in SOA? What's the answer? If you're chomping at the bit to know, skip the next few paragraphs.

The second reason the session was worth attending is that I learned some more about Business Process Execution language (BPEL) and I learned about Business Processing Modeling Notation (BPMN). Some of you might ask what are BPEL and BPMN? In fact, what's orchestration? Let's take the last one first, orchestration (in the SOA context) is the means of getting services to work together in the correct way and in the correct sequence. Imagine an online travel service. The service needs to do things like manage hotel reservations and handle flight scheduling. An effective way of architecting the service is to design it as a composite service, where each activity, such as managing hotel reservations, is handled by a separate service. The overall service, then, is a composite of these individual services. However to make this work you need a way to orchestrate the service, and the orchestration needs to conform to the business processes for the travel service. In other words, the sequence of services needs to mirror the sequence of "real-life" operations that take place as part of the travel service. And that leads up to BPEL and BPMN.

BPEL is an XML-based language that is used to describe business processes. It's very expressive and comprehensive. BPEL is more programming language-like than run-of-the-mill XML-based implementations. For example, it has constructs to manipulate data, and elements that describe the order of activities in a process (it doesn't only describe data). However it's not a complete programming language -- you can't for example, use it to access non-XML resources like database management systems. In addition, BPEL can't do real work. That's left up to worker services. These services are typically asynchronous, conversational, and document-centric (that is, AC/DC). So between BPEL and these worker services, you can describe a composite service that comprises a set of worker services, and enable the composite service for orchestration.

But coding using BPEL can be tedious. The BPEL schema is enormous, so although the language is highly expressive, programmers tend not to code in it.

One level of abstraction up from BPEL is BPMN, which is a standard for drawing business process diagrams. BPMN is a modelling notation that's used to graphically represent processes using common flowcharting symbols. The diagrams map to BPEL.

So let's get back to the Ultimate Question: Are BPEL and BPMN the answer to everything for service orchestation in SOA? The answer: no.
Why? Because even with BPMN, describing and modifying processes are still too tedious. So what's the real answer? Tools!

O.K. you're not surprised -- after all, Beckham, Fast, and Frisino are tools guys. But they did back up their answer with a neat demo of Sun Java Studio Enterprise 9 (a future version of the JSE tool), that showed how easy it will be to describe and modify processes, and to orchestrate a composite service. You don't need to know BPEL. It's all graphical and it all maps to BPEL and Java. There seem to be pallets and menus for just about everything you need, including selections for Java-based "functoids". (I'm not exactly sure what these are, but I like the name.) There are also easy-to-use features for orchestrating a composite service. You wire the component services together by dragging a line between the services at the appropriate points in the process. And you can see what's going on (for example, what messages are being exchanged) one step of the process at a time.

I'll be on the lookout for more about JSE 9 over time. I'd like to get my hands on it and try it out.

You can get the slides for this session at

Related Topics >>