News

Does Service Enablement Equal Vendor Entitlement?

• By Stephen Swoyer
• September 28, 2005

SOA enthusiasts have been trumpeting a coming generation of composite applications—applications that are composed of multiple, independent, plug-and-play services.

Before companies can start building composite apps and start down the path to virtual app dev Nirvana, however, they first must service enable their IT infrastructures. And in spite of the best-laid claims of many ardent proponents, the service-oriented architecture is itself still an inchoate vision.

One reason for this is SOA assumes a more or less portable understanding of what are, from enterprise to enterprise, often wildly different instantiations of traditional business processes. Because of this, service enablement is dependent on the maturation of technologies such as the Web Services Business Process Execution Language, the Business Process Modeling Language and Electronic Business XML.

WSBPEL is the front-runner. It’s sponsored by a consortium of vendors including BEA, IBM, Microsoft, SAP AG and Sun Microsystems, and it’s positioned as an XML-based language, the purpose of which is to define Web services business processes. To a certain extent, some programmers allege, these vendors also hope WSBPEL will help XML-over some of the shortcomings of the current SOA model.

“They hope that BPEL…will enable business analysts to orchestrate business processes directly,” explains Jeff Grigg, an independent programming consultant.

Jonathan House, an IT director with Amirsys, a medical technology company, sees another problem with WSBPEL, however—the fact that some of its proponents—companies including BEA, IBM and Sun—aren’t entirely disinterested parties. “In cases such as this, you have to follow the money, and not very far either,” he argues. “In my opinion, this is a group of vendors that are making an industry for themselves. You will notice that if you want to implement to the BPEL specification, you have to be a licensee.”