OASIS members have formed a new WS-CAF Technical Committee to "define a generic and open framework for applications that contain multiple services used in combination (composite applications)." The TC will continue collaborative work on the Web Services Composite Application Framework (WS-CAF) specification suite recently published by Arjuna Technologies Limited, Fujitsu Software, IONA Technologies PLC, Oracle Corp, and Sun Microsystems.

The proposal notes that "composability is a critical aspect of Web Service specifications; the initial TC members expect the work of the WS-CAF TC, particularly WS-Context, to become building blocks for other Web service specifications and standards. Therefore, the resulting specification must be non-overlapping and have demonstrated composability with other Web Service specifications that are being developed in open, recognized standards setting organizations. The WS-CAF TC will work with these organizations to gather requirements input and to define the relationships between their specifications and this TC's work with the goal of promoting convergence, consistent use, and a coherent architecture."

The anticiated audience for this work includes: "(1) other specification writers that need underlying web service coordination, context and transaction mechanisms; (2) vendors offering web service products; (3) software architects and progammers who design and write distributed applications requiring coordination, context and transaction mechanisms."

The WS-CAF TC Convenor is Mark Little (Arjuna Technologies); the proposed TC Chairs are Martin Chapman (Oracle Corporation) and Eric Newcomer (Iona Technologies). The first meeting of the OASIS WS-CAF TC will held October 31, 2003 as a teleconference.

A general reference document for specifications and standards activities related to the coordination (choreography, orchestration, management) of messages/transactions is available in "Messaging and Transaction Coordination."

From the Announcement and Call for Participation

Multiple web services combined in composite applications require interoperable mechanisms to set the boundaries of an activity (such as start/end, or success/failure), to create, access and manage context information, and to inform participants of changes to an activity. Composite applications might also need to work with a range of transaction models, including simple activity scoping, single and two phase commit ACID transactions, and recoverable long running activities.

The goal of this TC is to define a set of royalty-free related, interoperable and modular specifications that will enable development of composite applications, ranging from simple to complex combinations of web services and encompassing a useful range of transaction and coordination requirements.

In no event shall this Technical Committee finalize or approve any technical specification if it believes that the use, distribution, or implementation of such specification would necessarily require the unauthorized infringement of any third party rights known to the Technical Committee, and such third party has not agreed to provide necessary license rights on perpetual, royalty-free, non-discriminatory terms.

Essential elements of web services are SOAP and WSDL. The specifications to be created will provide WSDL definitions for context, coordination and transactions. Message formats will be specified as SOAP headers and/or body content. The resulting specification must be programming language-neutral and platform-neutral.

Interoperability, ease of implementation, and ease of use will be fundamental characteristics for WS-CAF. The TC's work should build upon similar, existing standards wherever possible and to align where appropriate with other relevant standards. Alignment means any of the following: feature reuse, bindings, guidelines on how to jointly use the specification with other related ones, or addressing requirements from other related standards.

The WS-CAF TC will accept as input the WS-Context, WS-Coordination Framework and WS-Transaction Management specifications published by Arjuna, Fujitsu, Iona, Oracle, and Sun Microsystems on July 28 2003. Other contributions in addition to WS-CAF will be accepted for consideration without any prejudice or restrictions and evaluated on their technical merit, as long as the contributions conform to the goals and scope of this charter.

The benefits and results of this work will be standard and interoperable ways to:

• Demarcate and coordinate web service activities
• Propagate and coordinate context information
• Notify participants of changes in an activity
• Define the relationship of coordinators to each other
• Recover transactions predictably and consistently in a business process execution
• Interact across multiple transaction models (such as are used in CORBA, CICS, Enterprise JavaBeans or .NET environments)

List of Deliverables

• A revised WS-Context specification. Draft due within 6 months of first meeting.
• A revised WS-Coordination Framework specification. Draft due within 10 months of first meeting.
• A revised WS-Transaction Management specification. Draft due within 14 months of first meeting.
• A primer introducing the above specifications, including use cases and scenarios as appropriate.

TC Co-Sponsors

The following persons eligible to participate in OASIS technical committees state that they are committed to the purpose and schedule stated above:

• Jan Alexander (jan.alexander@systinet.com), Systinet
• Doug Bunting (doug.bunting@sun.com), Sun Microsystems
• Martin Chapman (martin.chapman@oracle.com), Oracle Corp.
• Mark Little (mark.little@arjuna.com), Arjuna Technologies
• Jeff Mischkinsky (jeff.mischkinsky@oracle.com), Oracle Corp.
• Dale Moberg (dmoberg@cyclonecommerce.com), Cyclone Commerce
• Ramesh Nagappan (ramesh.nagappan@sun.com), Sun Microsystems
• Eric Newcomer (eric.newcomer@iona.com), IONA Technologies
• Keith Swenson (KSwenson@fsw.fujitsu.com), Fujitsu Software Corp.
• Jim Webber (jim.webber@arjuna.com), Arjuna Technologies
• Pete Wenzel (pete@seebeyond.com), SeeBeyond

WS-CAF Specification Set Summary as Initially Published

The Web Services Composite Application Framework (WS-CAF) has been published with a Primer and three principal specifications; XML Schemas and WSDLs are available in the ZIP archive distribution files.

Web Service Context (WS-CTX) is "a lightweight framework for simple context management that helps enable all Web services participating in an activity share a common context and exchange information about a common outcome."

The ability to scope arbitrary units of work is a requirement in a variety of aspects of distributed applications such as workflow and business-to-business interactions. By scoping work, we mean that it is possible for business activity participants to be able to determine unambiguously whether or not they are participating in the same activity.

In order to correlate the work of participants within the same activity, it is necessary to propagate additional information know as the context to each participant. The context contains information (such as a unique identifier) that allows a series of operations to share a common outcome. For example, in a Web services-based application, a SOAP header block might contain contextual information that is propagated when invoking an operation on a Web Service, or when multiple participants exchange SOAP messages in order to create a larger interaction such as a process flow.

A Web Services Context Service maintains a repository of context information and tracks contexts shared between multiple participants in Web services interactions. An Context Service can also be a participant within an activity, creating a tree to further propagate the context. A Web Services Context Service accepts and emits SOAP messages for interoperability with any type of participant, regardless of operating system, programming language, or platform -- and is independent of underlying transfer or transport protocols.

Context is always propagated in addition to application payload, where context information travels within the SOAP header blocks while application payload (that is, the content intended for processing by a SOAP node playing the ultimateReceiver role) is propagated inside the SOAP body.

The context information is specific to the type of activity being performed, such as to identify a transaction coordinator, the other participants in an activity, or recovery information in the event of a failure, etc. Therefore, a single context type is not sufficient for all types of activity that a Context Service may be required to support. Hence, the capabilities of the Context Service must be extensible in an application specific manner and services must be able to augment the context as they require to suit their own particular application domains...."

Web Service Coordination Framework (WS-CF) is "a sharable mechanism that manages context augmentation and lifecycle and provides the notification of outcome messages to Web services participating in a particular transaction."

Coordination is a requirement present in a variety of different aspects of distributed applications. For instance, workflow, atomic transactions, caching and replication, security, auctioning, and business-tobusiness activities all require some level of what may be collectively referred to as 'coordination.' For example, coordination of multiple Web services in choreography may be required to ensure the correct result of a series of operations comprising a single business transaction.

Whenever coordination occurs, the propagation of additional information (the coordination context) to coordinated participants is required. The coordination context contains information such as a unique ID that allows a series of operations to share a common outcome. The outcome is typically defined in terms of coordinated state persistence operations. For example, in a Web services-based architecture, a SOAP header block might contain context information that is propagated when interacting with a coordinator, or when multiple participants exchange SOAP messages in order to create a larger interaction such as a process flow or other aggregation of services...

Coordination is a fundamental requirement of many distributed systems, including Web Services. However, the type of coordination protocol that is used may vary depending upon the circumstances (e.g., two-phase versus three-phase). Therefore, what is needed is a standardization on a coordination framework (coordination service) that allows users and services to register with it, and customize it on a per service or per application basis. Such a coordination service would also support newly emerging Web service standards such as workflow and transactions and builds on the Web services CTX Service.

Web Services Transaction Management (WS-TXM) "is comprised of three distinct, interoperable transaction protocols that can be used across multiple transaction managers. WS-TXM supports multiple transaction models to help enable participants to negotiate outcomes with each other and make a common decision about how to behave, especially in the case of failure, regardless whether the execution environment is CORBA, Enterprise JavaBeans (EJB), .NET, Java Message Service (JMS), or some combination.

An increasing number of applications are being constructed by combining or coordinating the execution of multiple Web services, each of which may represent an interface to a different underlying technology. The resulting applications can be very complex in structure, with complex relationships between their constituent services. Furthermore, the execution of such an application may take a long time to complete, and may contain long periods of inactivity, often due to the constituent services requiring user interactions. In the loosely coupled environment represented by Web services, long running applications will require support for recovery and compensation, because machines may fail, processes may be cancelled, or services may be moved or withdrawn. Web services transactions also must span multiple transaction models and protocols native to the underlying technologies onto which the Web services are mapped.

A common technique for fault-tolerance is through the use of atomic transactions, which have the well know ACID properties, operating on persistent (long-lived) objects. Transactions ensure that only consistent state changes take place despite concurrent access and failures. However, traditional transactions depend upon tightly coupled protocols, and thus are often not well suited to more loosely-coupled Web services based applications, although they are likely to be used in some of the constituent technologies. It is more likely that traditional transactions are used in the minority of cases in which the cooperating Web services can take advantage of them, while new mechanisms, such as compensation, replay, and persisting business process state, more suited to Web services are developed and used for the more typical case.

WS-TXN provides a suite of transaction models, each suited to solving a different problem domain. However, because WS-TXN leverages WS-CF, it is intended to allow flexibility in the types of models supported. Therefore, if new models are required for other problem areas, they can be incorporated within this specification.