Web Services Big Three Attempt Lock On Standards

Current Analysis takes a slightly positive stance on IBM, Microsoft, and BEAs release of new BPM and transaction specs. The standards, in the area of business process management, transactions, and coordination, consolidate some competing work and have a good chance of succeeding due to the influence of the three vendors involved. Ultimately, users will find it easier to implement high volume, mission-critical Web Services through the specs. The group, however, needs to set priorities and finish up work on security specs first. It also needs to include third-parties and reconcile standards put forth by Sun and HP.

Since the initial success of SOAP, WSDL, and UDDI, vendors have been attempting to fill in gaps in Web Services standards identified by users in the first wave of implementations. For instance, a Web Services security standard has been promoted by users and vendors because it will eliminate the need for users to agree upon security and identity procedures between participants. Hence, SOAP message security and federated identity has been proposed by various parties. Business processes have also been identified as a necessary component to deliver a Web Service, as well as some level of transaction integrity. A standard way to achieve transaction integrity and interoperability between business flows is helpful (but not a prerequisite) for Web Services development, hence, the current effort to impose a standard in this area. The efforts are not entirely new. HP, through its Business Transaction Protocol (BTP), and Sun through its Web Services Choreography Interface (WSCI) have proposed standards, as has IBM and others through WSFL (Web Services Flow language) and BPML (Business Process Management language).

There are a number of positive effects that will come out of the IBM, Microsoft, and BEA effort to impose standards. In the area of BPM, IBM and Microsoft are merging XLANG and WSFL into the BPEL4WS (Business Process Execution Language for Web services). Judging by the support already thrown behind WSFL, it is likely the industry will coalesce behind BPEL4WS (although it is hoped a shorter acronym will emerge!). This will make it easier for business flows to run on different execution platforms and to interact with each other. A transaction spec, if widely implemented, will again allow interoperability and ensure scalable, reliable Web Services implementations. All in all, there will be greater user confidence in Web Services as a method to solve all kinds of business problems.

On the negative side, we question the urgency of these specifications, particularly the transaction spec. There are numerous ways to guarantee delivery of transactions through database, messaging, EAI, and other technologies, all of them available today and all of them functionally interoperable. Some are even standards-based (for example, JTS). Having a separate transaction standard for Web Services is of nominal value and should be given a lower priority. We also recommend it be based on JTS or at least be similar to JTS. A standard language for business flows is of more practical value (although passing transactions through different message flows is possible through XML and various adapters). However, Sun (and BEA incidentally) have also proposed WCSI, and there should be a reconciliation of these two efforts. Finally, security issues the most urgent of the Web Services standards are still unresolved. As a priority, IBM, Microsoft, BEA, and Sun should work to resolve these, possibly by including the Liberty Alliances federated identity management spec in WS-Security.

The impact on the market will be high due to the influence of these three vendors. In particular, EAI and BPM vendors should be prepared to support BPEL4WS and possibly one of the other two specs (WSCI or BPML). Competitors should demand more participation in BPEL4WS in exchange for support. Users should also plan on purchasing BPM technology that will conform to BPEL4WS. However, at this stage, users should proceed with current technologies for ensuring transaction integrity.