Being left handed and, therefore, left footed, I once tried to take dancing lessons so I'd look a little less ungainly at family functions like weddings. My father, who's ambidextrous, makes it look easy. Of course, I always forget that when he was growing up, dancing was the main social activity. Naturally I found it much more difficult than it looks.

Web services choreography, orchestration, and general business process management are the programming equivalents of ballroom dancing. Web services itself is about making multiple computers work together. Sort of like a school dance, where the teachers come around and make the boys and girls dance together. The basics, the plumbing of Web services, UDDI, SOAP, WSDL, and XML, make the dance possible. They provide the underlying infrastructure that is necessary for multiple processes on multiple systems to communicate.

By themselves these basics can do a great deal of useful work. And fortunately, most software vendors have found it a relatively simple matter to add Web services support to their products, which provides the ubiquity needed for Web services to realize the "network effect."

But look at them closely and you realize that there are a host of additional things that you either want or need that just aren't provided by SOAP, WSDL, UDDI, and XML. Some of the most important functionality that is not present is the ability to construct a process out of a Web service, or from multiple Web services. It's easy to forget that Web services can have more than one method, and that you can construct a whole process (such as order processing) as a single set of methods if you so choose. What's not present is the ability to manage those processes, and combine them with branching, coordination, transactional integrity, and error handling.

Choreography and BPM are added-value aspects of Web services - much like the steps of a waltz, they organize what can otherwise be a chaotic occasion (ever seen a high school dance to modern music?). They are also likely to be the major vendor battleground over the next several years. The battle over plumbing is nearly over, with the standards evolving but not really changing all that much, and interoperability is there. Much like the J2EE world, where application server vendors first competed on standards but now work on value adds, the basics of Web services are becoming endemic in platforms. Two years ago, it was hard to find a platform with full support. Now it's surprising if the support isn't there. Two years from now, the plumbing will be forgotten and we will be working on a higher level of abstraction once again.

In the meantime, the BPM vendors have an education process to complete. Like most revolutionary tools, until you've been presented the value proposition it's difficult to imagine how to use such a tool, and what value it can bring to an organization. While I don't have space to try to put such a proposition into words here, think "agility." BPM is all about reacting quickly to business changes, and being able to redefine the business process as needed, instead of over a yearly update cycle.

Naturally, we've focused this month on those tools and standards that assist with BPM. We wanted to give you a glimpse of what the future holds for you. So read on, while I put these funny looking footprints on the floor and try to learn the Macarena...

Author Bio
Sean Rhody is the editor-in-chief of Web Services Journal and managing editor of WebLogic Developer's Journal. He is a respected industry expert and a consultant with a leading consulting services company. Sean@sys-con.com