Gregor's Ramblings
Home Patterns Ramblings Articles Talks Download Links Books Contact

Dagstuhl Seminar

Aug 20, 2006

Gregor Hohpe
Hi, I am Gregor Hohpe, co-author of the book Enterprise Integration Patterns. I like to work on and write about asynchronous messaging systems, service-oriented architectures, and all sorts of enterprise computing and architecture topics. I am also the Chief Architect at Allianz SE, one of the largest insurance companies in the world.
Here I share my thoughts and ideas on a semi-regular basis. I call these notes "ramblings" because they are typically based on my personal opinions and observations as opposed to official "articles".

I just returned from a trip to Germany to attend a workshop on The Role of Business Processes in Service Oriented Architectures. Besides a guaranteed top score in buzzword bingo the workshop provided a unique opportunity to connect thought leaders from academia and industry over the course of a week. The attendee roster sported the usual industry heavyweights, i.e., Microsoft, IBM, SAP, making me proud to add Google to the list. The workshop format gave participants a chance to present their current work, followed by numerous ad-hoc workshops and discussions in larger and smaller groups.

Arriving at the event Sunday evening, I quickly realized that this would become an interesting week. How could it not if I already had a few beers with Satish Thatte (the "father" of XLANG and a co-creator of WS-BPEL), Sanjiva Weerawarana (co-author of WSDL and WS-BPEL), Frank Leymann ("father" of WSFL and co-creator of BPEL), and many other SOA and BPM authorities before the workshop even formally started. Want to know why "port type" is called just that? Well, I can simply put Sanjiva on the spot. Is BPEL too low level? I am sure Satish has an opinion. Choreography vs. Orchestration? Just ring the bell and let Frank and Kohei battled this one out.

It is also nice to be back in Germany. The conference venue is a veritable castle, of course equipped with wireless Internet access and a well stocked library that operates on the honor system 24 hours a day. They also "rent" bikes (they are actually available for free) without one having to sign a 3 page release form containing only sentences starting with "whereas". Beer is freely (OK, readily) available on location -- you simply grab a bottle and mark it down on your weekly consumption sheet. At the end of the week you get to compare scores with your intellectual drinking buddies. Oh, and the best part: beer is 1 Euro per bottle.

The workshop is not a conference in your traditional sense where hundreds of people pay a thousand Dollars or so to listen to a stream of more or less interesting monologues by more or less well known people. The workshop had a series of short presentations, followed by many ad-hoc discussions, a panel or two, and a lot of dinner table conversations. The density of information being passed around was truly mind boggling. I am trying here to summarize some of my take-aways.


Dieter Koenig gave an update on the role of BPEL in SCA (Service Component Architecture). SCA focuses on the assembly of individual services into larger applications. It defines (amongst other things) a common format that allows the configuration of a module for deployment, by specifying properties and resolving references. Components that are composed into modules can be custom programs, BPEL processes or anything else that conforms to the interface specification. One interesting question came up, question the necessity of yet another level of indirection when BPEL already has the notion of partner links and roles, which allow processes to be hooked into other services at deployment time. The conclusion was that in case of a BPEL component being deployed in the context of SCA the tools should generate the SCA spec from the BPEL process template so that the double level of indirection is transparent to the component developer and the (human) assembler.

BPEL Engines

Sanjiva alerted me to the fact that FiveSight's PXE BPEL Engine , which was open sourced by Intalio is now part of the Apache ODE project. The goal is to merge the multiple BPEL implementations that live under the Apache umbrella into a single one. The good news is that we are converging towards a single "standard" open source BPEL implementation. The question how long the transition will take. According to Intalio major progress has been made.


Gerhard Pfau and Matthias Kloppmann presented on BPEL for People. The highlight to me was the list of Interaction Patterns (see Slide 4). It catalogs different roles humans play in an automated process and describes the interactions the humans have as part of each role. For example, humans participate in a task, they usually query for a list of available tasks, claim a task and later complete the task (or return it into the pool). My suggestion was to make the acronym cooler by calling it BPEL4PPL or BPEL4PPEL. This would also have the nice side-effect to convert the last hard core Microsofties who insist on pronouncing BPEL as "beppel" instead of "bee-pel" (unless they want to go the route of "beppel for peppel"…)

Open Workflow Nets

Karsten Wolf and Peter Massuthe (working with Wolfgang Reisig) applied the notion of Open Workflow Nets to analyzing the observable behavior of a service. The context to this work is to identify formal models of workflow services. A simple example of a vending machine illustrated the depth of this problem. The process modeling the vending machine supports four external "operations": Insert Coin, Select Tea, Select Coffee and Deliver Beverage. The first three are inbound and the last one is outbound messages. The question is, which client processes are valid in a sense that they actually complete the process without getting stuck somewhere (such a client is called a Strategy)? For example, a customer inserting a coin, selecting coffee and accepting the beverage is a strategy while a customer who inserts a coin and waits for a beverage without making a selection is not (the vending machine ends up in a deadlock state). The set of all strategies for a service is called an Operating Guideline. it provides an interesting artifact for a published workflow-driven service because it allows the service composition layer to assess whether service consumer and provider are "compatible". Wolfgang Reisig posted a nice overview presentation on this topic. Tools4BPEL contains associated tools that can convert BPEL processes into open workflow nets.

Conversation Patterns

I gave both a presentation and held a workshop on Conversation Patterns. It was great (and a little daunting) to have such an experienced audience for my presentation. Immediately, good discussions and suggestions erupted. Sanjiva is cataloging more MEPs (Message Exchange Patterns) as part of WSDL 2.0. Uwe Zdun, who is working with Shahram Duster on describing process models using patterns, suggested arranging a pattern language where larger patterns can be composed from smaller "pattern primitives". Egon Börger authored a paper with Alistair Barros on and suggested a decomposition of the patterns into send and receive primitives. The level of interest and discussion left me inspired and motivated to continue my work on Conversation Patterns.

Heading Home

After so much intellectual stimulation I stopped by the Nürburgring's infamous Nordschleife on the way home. This treacherous race track of 20km has more corners than I could count and is full of blind turns, hill tops, and changing road conditions. At multiple points in its history the track was deemed too dangerous for racing but interestingly it was deemed safe enough to let the general public go wild on it. That is if you consider Evo, STi, RS4, M5, and 911 GT3 drivers the general public. Sadly, the combination of lack of horsepower, lack of familiarity with the track and lack of racing experience turned me and my BMW 116 into a 170 km/h obstacle.


Gregor is the Chief IT Architect of Allianz SE. He is a frequent speaker on asynchronous messaging and service-oriented architectures and co-authored Enterprise Integration Patterns (Addison-Wesley). His mission is to make integration and distributed system development easier by harvesting common patterns and best practices from many different technologies.