Interestingly, if you polled some of the people who have been involved in the creation of one of the key standards for BPM (business process management), I have a feeling that a lot of them would describe the time spent on that standard as "such a process."
The process that Im referring to is the creation of the Web Services Business Process Execution Language 2.0, a standard that has been years in the making and as of the writing of this column still hasnt received official status from the OASIS standards body (although that could happen any day now).
If youve had anything to do with BPM in recent years then youre probably familiar with BPEL, which is the main standard used by many BPM systems for defining business processes and interactions. Now, like many other modern standards, BPEL is XML-based, meaning it has the ability to play well with Web services. And the growth in recent years of SOAs (service-oriented architectures) has had many interested in using BPEL as the glue with which to build complex process-oriented SOA implementations.
But getting BPEL to play nice in Web services environments hasnt been as easy as it looked at first glance. This led to an update of the standard called BPEL4WS (BPEL for Web Services) that tried to make Web services and processes work well together, but this attempt was widely seen as a failure that led vendors to create proprietary methods for integrating BPEL and Web services.
That was in 2003, and work began almost immediately on the follow-up, which became WS-BPEL 2.0, which has now been literally years in the making.
So why should you care? Its just another dumb standards fight, right? An example of vendors fighting to make a standard work best with their stuff and not their competitors products, and infighting leading to delay after delay.
Well, of course, thats exactly what it is. But the standard itself could prove to be very important and could change the way that companies create and manage business processes and build SOAs.
In the eyes of many developers and businesses, BPEL and SOA are two different concepts that were made to be together (sort of like in the peanut butter cup ads, "Hey, you got your processes in my Web services!") Thats because by providing a standardized way to build processes into an SOA, BPEL makes it very easy for business partners, customers and other third parties to tie into your infrastructure.
One of the main advantages that BPEL brings to Web services is its orchestration capabilities. The ability to map out processes and workflows within a Web service using BPEL opens up lots of additional opportunities when it comes to building rich, interactive and flexible Web services. Basically, it adds more intelligence in the way that your Web services and applications deal with and respond to processes.
Now, I dont expect WS-BPEL 2.0 to be perfect. No new standard ever is, and given the path that this standard has followed, there are bound to be some gotchas. I, for one, will be interested to see how WS-BPEL 2.0 and its use in SOA implementations plays out across platforms. Will it be used the same way in J2EE-based (Java 2 Platform, Enterprise Edition) SOA infrastructures as it will be in Microsoft .Net SOA systems? If not, will this limit the portability of processes within SOA systems built on different products and different technology stacks?
Hopefully, WS-BPEL 2.0 will work the same way and be seamlessly portable across all systems. After all, we are talking about an integration system here. If a technology isnt able to integrate well with different platforms, then many companies just wont use that technology or standard.
So heres to the (hopefully) imminent standardization of Web Services Business Process Execution Language 2.0. May it lead to new innovations and improvements in how businesses use Web services and integrate processes.
Im hoping it will succeed. If only so that the word "process" can be seen in a more positive light.
eWEEK Chief Technology Analyst Jim Rapoza can be reached at email@example.com.