Like many IT professionals, I'm an amateur musician. As such, I know how much effort it can be to get a group of people to work together, start together, end together and make a pleasant sort of noise together. And I play in a small group, so I can imagine the coordination effort of something like a symphony orchestra.

This month we're focusing our attention on Business Process Management or, as some call it, Business Process Orchestration (you were wondering where I was going with the opening paragraph, weren't you?). This particular idea has been around for some time in a variety of forms. The premise is that a business has a set of business rules that define how it acts. These rules, or processes, are best captured in systems that allow them to be edited and changed quickly, by business people, not technologists, in response to business conditions. Or so the theory goes.

Workflow was one of the first responses to this theory, and systems that provide workflow automation exist and are in use today. Business Rules engines were another attempt to implement this idea, with a slightly different emphasis - more on rules and grammar, less on process. Regardless of emphasis, this idea has been in play for some time, and many vendors have taken a stab at it.

What makes BPM interesting for Web services is that it provides a portion of the overall picture that is vital to the acceptance of Web services as an operating pardigm. To understand this, picture the use of Web services within an enterprise, as an addition to, or in some cases in place of, an EAI solution. Without a BPM solution, when we create the Web services that encapsulate the internal systems, we are for all intents and purposes creating yet another stovepipe, because we're creating a coded system that deals with the intricacies of our multiple internal systems.

With a BPM capability, we remove the stovepipe by abstracting the logic out of code and into a capability that is integrated into the whole stack of Web services, and intimately aware of them.

Of course, without an easy way to describe business processes, all of this becomes moot. It's one of the uniquely strange truisms of our industry - the more complex a task is, the simpler we have to make a system to describe it in order to be successful.

Our needs regarding BPM are tri-fold. First, we need a language that describes business process well, and meshes with the tools and standards of Web services. Next, we need a studio to design Business Processes in, one that is simple, yet powerful - one that business people can use. Finally, we need an engine that can enact the processes in a distributed, load-balanced fashion, and provide metrics and monitoring.

We actually already have several languages. The Business Process Management Institute (BPMI.ORG) is working on BPML - Business Process Markup Language - a standard that has a number of vendors committed to it. IBM has also put forth a standard - WSFL, or Web Services Flow Language. Interestingly enough, another vendor, Sonic, has already shipped a working implementation of WSFL.

We also have plenty of engines. BEA has an engine in their WebLogic Integration package. IONA, IBM, Sonic, and others also provide engines for the implementation of BPM. Most of these engines are still in the first or second iterations, so while they provide good implementation, they lack some polish, mature metrics and management.

And there are still others building studios. The good thing about a standard language for describing BPM is that a tool maker can use their creative genius to make the tool better, rather than the language. Vendors like Intalio, Proactivity, and RioLabs are concentrating on developing standalone tools that provide for BPM. The big players in the application server arena also provide some slick tools, but with more emphasis on integration to the application server.

Still, BPM in Web services, like the rest of the stack, is an unfinished symphony. We need to settle on a standard language, mature the interfaces, and determine metrics. We also need EAI to be included in the mix, so that Web services represents a truly powerful paradigm for application integration as well as enterprise integration. Which is even more complex. Stay tuned and enjoy the music.

Author Bio
Sean Rhody is the editor-in-chief of Web Services Journal. He is a respected industry expert and a consultant with a leading Internet service company. Sean@sys-con.com