Software Giants Line Up Over Web Services Workflow

Last month, the focus in web service standards was on security. Now, IBM, Microsoft, Sun and other big software names are poised for another debate -- or compromise. See what's is store for the future of workflow and transaction management standards for web services, and get a scorecard to keep track of the players and proposals.

Tags: Web Services, Business, Standards, Business Process, Transaction, Proposals, Developers,

Last month, the focus in web service standards was on security. Now, IBM, Microsoft, Sun and other big software names are poised for another debate -- or compromise. And, this time it will be about the future of web services workflow and transaction management standards.

In preparation for the discussions (and rumors) to follow, Integration Developer News this week gives developers a no-nonsense scorecard, where IDN will lay out the players, the problems, the proposals for fixing them, and the stakes for developers.

Defining Workflow -- The Players
The W3C is now considering how best to deal with the incompatible-yet-overlapping proposals from IBM/Microsoft and a coalition lead by Sun Microsystems for handling workflow and business processes

Earlier this month, IBM and Microsoft (co-authors of the WS-Security proposed standards) sent W3C a set of three proposals aimed at standardizing the end-to-end trip of a web services "event" or "transaction" -- Business Process Execution Language for Web Services (BPEL4WS), WS-Coordination and WS-Transaction. Notably, leading J2EE app server provider BEA Systems joined in the IBM/Microsoft proposal.

As a package, these three proposed specifications seek to define several aspects of a web services transaction, including the underlying business rules and state management that would allow computers to publish and/or subscribe to a service. In turn, the service-based transaction would be manageable across multiple legacy and/or Internet-based systems.

Prior to the IBM/Microsoft/BEA submission, at the start of the summer Sun and BEA (among others) published a specification with similar workflow aims. The Web Service Choreography Interface (WSCI) as an XML-based specification for defining application to application collaboration in conjunction with the WSDL (web services definition language) of a transaction.

According to document definitions, WSCI "does not address the definition and the implementation of the internal processes that actually drive the message exchange," Instead, WCSI describes "the observable behavior of a Web Service by means of a message-flow oriented interface. WSCI was supported by Intalio Inc. and SAP AG, and full copies are available at the websites of all four co-presenters.

Prospects for Agreement Good
Prospects for a vendor agreement on web services workflow and transactions standards are good, as BEA is a co-author on both. In addition, one member of a W3C committee considering the standards told IDN he was optimistic.

"I and others involved in the standards efforts are working hard to create the venue for these discussions," Dave Hollander, co-inventor of XML and now CTO of Contivo, a provider of automated data integration software in Mountain View, Calif. Hollander, who is also on the W3C Web Services Architecture working group, added a few other insights.

"There are lots of overlaps and gaps. Each of the groups defining these specifications have had to factor out the features and functionalities independently. One of the goals of the W3C Web Services Architecture working group is to create an architectural framework that will set a foundation for the factorization and therefore improve the overall interoperability and understandability of complex web services," Hollander told IDN.

"Hopefully our work will help the industry reach the shared goal of consolidating competing specifications," he added.

Despite Hollander's optimism, however, he couldn't put a timeframe to when developers would see the potentially competing standards resolved. "This unity will be the result of a lot of good, hard work and collaboration. Until we have a meaningful discussion with all or at least most of the participants, it would be counter-productive to venture a guess as to how things will consolidate."

Needing Workflow -- The Problem
The major motivator behind the rash of newly proposed workflow and/or transaction standards is simple enough to define -- but tough to accomplish.

For web services to become more accepted for large-scale enterprise applications, these services must be manageable across a number of nodes and applications. This is because these enterprise-caliber web services will be launching, pushing or requesting data and/or applications tied to complex transactions such as money transfers, inventory and ordering, or online commerce.

In today's enterprise, these types of activities are manageable due in large part to the interaction of complex infrastructure, monitoring, exception handling and APIs/adapters developed by major e-commerce and ERP software providers. The web services world, lacking these interrelationships between hardware, software and management systems, needs to define the aspects of a "web services transaction," as well as how the underlying systems supporting the transaction will communicate with one another.

An underlying key to all this is the search to define a flexible and manageable way to provide a transaction (initiated or empowered by a web service) to maintain a degree of "state management," which would help insure that data integrity could be maintained in real-time during a transaction which could change a database. Such "state management" would also ensure better manageability and error handling (e.g. rollbacks, etc.) in the event of a failure in one of the nodes handling the end-to-end transaction.

A look at the technical approaches to each of the pending proposals, and you'll start to see how each company defines these problems, and approaches a solution.

Governing Workflow - The Proposals
  • BPEL4WS -- Business Process Execution Language for Web Services is a marriage of Microsoft's Xlang and IBM's Web Services Flow Language. BPEL4WS (which is the acronym for BPEL for web services), looks to define how business/workflow processes and rules would be imported and exported across nodes using web services interfaces exclusively.

  • To understand the purpose of BPEL4WS, it helps to know about the principals of modeling business rules and protocols. Backers of the spec define a "business process" as modeling the behavior of a participant in a business interaction, while the define a "business protocol" as using process descriptions that specify the message exchange (and behavior) between the parties without revealing their internal behavior.

    BPEL4WS is meant to be used to model the behavior of both executable and abstract processes. To do both in one, BPEL4WS looks provides a language for the formal specification of business processes and business interaction protocols. By doing so, it extends the Web services interaction model and enables it to support business transactions.

    In specific, BPEL4WS would be layered on top of several XML specifications: WSDL 1.1, XML Schema 1.0, and XPath1.0. WSDL messages and XML Schema type definitions provide the data model used by BPEL4WS processes. XPath provides support for data manipulation. All external resources and partners are represented as WSDL services. BPEL4WS provides extensibility to accommodate future versions of these standards, specifically the XPath and related standards used in XML computation.

  • WS-Coordination -- The WS-Coordination specification describes an extensible framework for providing protocols that coordinate the actions of distributed applications. So, the WS-Coordination framework is a coordination service for web services activities.

  • [The WS-Coordination proposal defines "activity" as "large distributed computational units...{enabled} by the current set of web services specifications for WSDL and SOAP."]

    With the aim of enabling an "activity" to be shared with other services/nodes, the WS-Coordination framework as proposed consists of three (3) services:
  • An Activation service with an operation that enables an application to create a coordination instance or context.
  • A Registration service with an operation that enables an application to register for coordination protocols.
  • A coordination type specific set of coordination protocols.

  • In addition, the WS-Coordination framework would provide a backward-compatible environment to allow for inbound/outbound seamless sharing with legacy assets. In specific, WS-Coordination aims to enable already existing (legacy) transaction processing, workflow, and other systems to hide their proprietary protocols for better coordination with newly-created web services.

    WS-Coordination depends on current SOAP and WSDL specs, as well as the element defined in WS-Security and on 'Context' and 'PortReference' definitions contained in the appendices of this document.

  • WS-Transaction -- The WS-Transaction specification is designed to work in conjunction with WS-Coordination, defines two coordination types: Atomic Transaction and Business Activity.

  • An atomic transaction is used to coordinate "activities" having a short duration and executed within limited trust domains. They are called atomic transactions because they have an "all or nothing" property. The Atomic Transaction specification defines protocols that enable existing transaction processing systems to wrap their proprietary protocols and interoperate across different hardware and software vendors.

  • A business activity is used to coordinate activities that are long in duration and desire to apply business logic to handle business exceptions. The long duration prohibits locking data resources to make actions tentative and hidden from other applications. Instead, actions are applied immediately and are permanent.

    The Business Activity specification defines protocols that enable existing business process and work flow systems to wrap their proprietary mechanisms and interoperate across trust boundaries and different vendor implementations.
    Developers can use either or both of these coordination types when building applications that require consistent agreement on the outcome of distributed activities A Web services application can include both atomic transactions and business activities.

  • Web Service Choreography Interface -- WSCI is an XML-based interface description language that describes the flow of messages exchanged by a Web Service participating in choreographed interactions with other services.

  • Backers of WSCI claim, which also include BEA, SAP and Intalio, that without something like WSCI, it is not possible to understand how the services interoperate and thus it is also impossible to:
  • Verify if the service behaved as stated by a given process specification;
  • Derive the choreography of the overall process to describe and thus, potentially, to modify it; or
  • Monitor the behavior of the service on respect to all other participants in the message exchange.

  • As to operation, WSCI describes how Web Service operations - such as those defined by WSDL [WSDL]- can be choreographed in the context of a message exchange in which the Web Service participates. Interactions between services - either in a business context or not - always follow and implement choreographed message exchanges (processes).

    WSCI is the first step towards enabling the mapping of services as components realizing those processes. WSCI also describes how the choreography of these operations should expose relevant information, such as message correlation, exception handling, transaction description and dynamic participation capabilities.

    After a public review period, WSCI will be submitted, on a royalty-free basis, to an industry standards body, the companies said. The WSCI specification is available royalty free for download from BEA as well as the other co-editors' sites.

  • ebXML -- ebXML is set of specifications that together enable a modular , end-to-end electronic business framework. The vision of ebXML is to enable a global electronic marketplace where enterprises of any size and in any geographical location can meet and conduct business with each other through the exchange of XML-based messages. Many of the aspects of ebXML are also addressed in part by the other proposals above, including sharing business rules, coordination and state management.

    In specific, ebXML seeks to define in various sections the following features and functions

    Registry: A central server that stores a variety of data necessary to make ebXML work. Amongst the information a Registry makes available in XML form are: Business Process & Information Meta Models, Core Library, Collaboration Protocol Profiles, and Business Library. Basically, when a business wants to start an ebXML relationship with another business, it queries a Registry in order to locate a suitable partner and to find information about requirements for dealing with that partner.

    Business Processes: Activities that a business can engage in (and for which it would generally want one or more partners). A Business Process is formally described by the Business Process Specification Schema (a W3C XML Schema and also a DTD), but may also be modeled in UML.

    Collaboration Protocol Profile (CPP): A profile filed with a Registry by a business wishing to engage in ebXML transactions. The CPP will specify some Business Processes of the business, as well as some Business Service Interfaces it supports.

    Business Service Interface: The ways that a business is able to carry out the transactions necessary in its Business Processes. The Business Service Interface also includes the kinds of Business Messages the business supports and the protocols over which these messages might travel.

    Business Messages: The actual information communicated as part of a business transaction. A message will contain multiple layers. At the outside layer, an actual communication protocol must be used (such as HTTP or SMTP). SOAP is an ebXML recommendation as an envelope for a message "payload." Other layers may deal with encryption or authentication.

    Core Library: A set of standard "parts" that may be used in larger ebXML elements. For example, Core Processes may be referenced by Business Processes. The Core Library is contributed by the ebXML initiative itself, while larger elements may be contributed by specific industries or businesses.

    Collaboration Protocol Agreement (CPA): In essence, a contract between two or more businesses that can be derived automatically from the CPPs of the respective companies. If a CPP says "I can do X," a CPA says "We will do X together."

    Watching The Process -- The Developers' Stake
    IDN polled several leading developer/integration firms to ask their opinion of how important the standards are, and what developers should watch for in the coming weeks.

    Many of those we contacted said developers should pay attention to these standards now -- and not after the debate is finished. One developer and CTO told IDN that early attention will give developers more voice in what the finished standards look like.

    "Before dominant implementations of the standards emerge, there will be a tendency from the community to gravitate towards the solution that solves most problems rather than adheres strictly to a single proposal, said Mukund Balasubramanian, co-Founder and CTO of Infravio Inc., a provider of Web Services management software.

    But, he added, early attention doesn't mean developers need to get wrapped up in reviewing abstracts and spec language. There are hands-on opportunities to see if these standards will meet muster, Balasubramanian said.

    "Proposals tend to be succeeded rapidly by bleeding edge implementations that give the developers a taste for what is to come," he said, and noted that IBM released a sample toolkit and engine for BPEL the day after that press release. More early implementations of proposed specs will probably be released, Balasubramanian said because "feedback from the developer community is important in shaping the standard (or proposed standard) before it matures into a product."

    Avi Hoffer, chairman and VP of strategic alliances at Metastorm, a provider of business process management technologies based in Severna Park, Md., said the latest IBM/Microsoft/BEA proposals merit attention because they "address messaging services, transactions management systems, security, identification, and authorization, and the identification of business rules." Hoffer told IDN he was hopeful there would be cooperation between the two groups because,

    "All are trying to fix the same problem, but they approach it only slightly differently." Metastorm's CTO Steve Brown added, "The longer the current pandemonium of standards continues, the more confusing life becomes for customers and software vendors alike."

    IDN will continue to update readers, as talks continue to smooth out the conflicts between these multiple standards. Until then, hold onto your scorecard.