Web Service Orchestration BOF Follow Up.

I would like to thank you all for coming to the BOF session on Web services Orchestration. I was glad that many people engaged into the discussion and time flew by so fast, I didn’t manage to bring up some of the items I had in mind.

Over the course of the discussion, it became apparent, that there is some interest, but also a lot of confusion on what it is and how to use it. I am trying to sum up some of the questions we discussed here and try to come up with some more answers as well. Please feel free to post comments with the items I didn’t cover adequately.

It was nice to see that people are using Web services although the feedback indicates that they are mostly using Web services internally and for integration projects. It’s also very nice to see that people are starting to think about leveraging orchestration to build new functionality.

First let’s talk about the terminology for a minute, since we had some differing opinions there as well. To many, the term “service orchestration” implies, or is closely related, to business process modeling, support for long-running processes and other B2B-class features. In this area we can build orchestrations with proprietary tools such as webMethods, BizTalk 2002, etc. The next wave of products in this area will center around the OASIS standard, BPEL, which is an XML-based language to model and execute business processes.

Most people in our talk have looked to BizTalk for orchestration, but unfortunately, nobody in the room really stepped up and talked about experience with alternative orchestration products (and my co-host, who could have done that, shamelessly ditched our talk!).

There also the lesser overloaded term “service composition”, which I think is a closely related concept. This concept will become very prominent once Longhorn and Indigo ship and building message based services will become the paramount paradigm for building applications. Indigo will really push up to think in terms of applications being composed from services. (Web) service driven applications using InfoPath as the application designer / execution engine are just the herald for the future wave of application built on top of services. Light weight composition/execution tools, like InfoPath, not just heavy weight server apps like BizTalk will bring the composition concept into an entirely new application space. Most of you did agree that even with Indigo, you would much rather keep orchestration logic outside the compiled code, in BPEL processes for example, than writing code with Whidbey / Indigo to execute services. One point of view though was that the immaturity of the protocols (and subsequently the tools) will make alternate solutions, like applications build on JMS and message queues viable options.

Many of you are still waiting for the WS-* standards to harden and mature. In today’s world, WSE is only a sub-optimal choice for building apps that run inside the data center. It’s already limited lifespan doesn’t make it a great platform for applications that are intended to live beyond the next two years. However, this is just a reflection of the current flux in which the WS-* standards still are.

I hope this summary touches on what we talked about. I’d be happy to get more feedback from you.