[Top] [All Lists]

[ontolog] Web Services Choreography Working Group Charter

To: Ontolog-forums-cim3-net <ontolog@xxxxxxxxxxxxxxx>
From: Leo Obrst <lobrst@xxxxxxxxx>
Date: Thu, 16 Jan 2003 20:29:00 -0500
Message-id: <3E275C5C.281E5123@xxxxxxxxx>
FYI. This has been commented on in a couple of Semantic Web lists today:    (01)

Dr. Leo Obrst  The MITRE Corporation
mailto:lobrst@xxxxxxxxx Intelligent Information Management/Exploitation
Voice: 703-883-6770 7515 Colshire Drive, M/S W640
Fax: 703-883-1379       McLean, VA 22102-7508, USA    (02)

W3C | Architecture Domain

Web Services Choreography Working Group Charter

  1. Goals and Scope of the Web Services Choreography Working Group
    1. Inputs
    2. Deliverables
    3. Choreography Language Specification
    4. Mapping to the Semantic Web
  2. Out of Scope
    1. Qualities
    2. Mappings to Programming Languages
    3. Graphical notation
  3. Schedule
  4. Relationships with Other Work
    1. W3C Groups and Activities
    2. External Groups
  5. Participation, Meetings, and Logistics
    1. Participation
    2. Email Communication
    3. Group Home Page
    4. Meetings
    5. Resources
    6. W3C Team Involvement
    7. Intellectual Property

1 Goals and Scope of the Web Services Choreography Working Group

Existing specifications for Web services describe the indivisible units of interactions. It has become clear that taking the next step in the development of Web services will require the ability to compose and describe the relationships between lower-level services. Although differing terminology is used in the industry, such as orchestration, collaboration, coordination, conversations, etc., the terms all share a common characteristic of describing linkages and usage patterns between Web services. For the purpose of this document, and without prejudice, we use the term choreography as a label to denote this space.

Many presentations at the W3C Workshop on Web services of 11-12 April 2001 pointed to the need for a common interface and composition language to help address choreography. The Web Services Architecture Requirements Working Draft created by the Web Services Architecture Working Group also lists the idea of Web service choreography capabilities as a Critical Success Factor, in support of several different top-level goals for the nascent Web services architecture.

Two technical Submissions, WSCL, and WSCI, have recently been published by the W3C as Technical Notes. There are other industry efforts in the area of choreography languages, such as BPML (defined by BPMI.org), BPSS (defined by ebXML), IBM's WSFL, Microsoft's XLANG, and IBM/Microsoft/BEA's BPEL4WS and their companion specifications WS-Coordination and WS-Transaction, etc. These developments make clear that there is a great deal of interest within the industry in addressing this problem area.

Some observers predict that if no steps are taken to develop a choreography specification in a vendor-neutral forum, the Web services marketplace may be divided into a number of non-interoperable sub-networks. A vendor-neutral choreography specification which commands consensus and wide support, on the other hand, can make it much easier and cheaper to create composite Web services which integrate services from multiple vendors. Small and medium-sized enterprises will be able to create more complex and more useful Web services. This in turn will help the market grow much more vigorously than would be possible without a vendor-neutral specification for choreography.

The problems posed by the lack of a widely adopted choreography specification, the current proliferation of overlapping work, and the time required to complete this effort merit the chartering a new W3C Working Group now. This Working Group should address the choreography space encompassed by the referenced documents. This Working Group should also coordinate with other Working Groups within the Web Service Activity, with the aim of developing an interoperable and open standard for Web service choreography.

WSDL has proved very useful for describing a single service. Currently complex natural language descriptions outlining the obligations of the participants and detailing how to use a service (sequencing, state management, etc.) have to accompany a WSDL description. The next step is to partially replace these somewhat imprecise instructions with precise language. This will simplify the daunting task companies now face when trying to use Web services to integrate their business processes. In a B2B context such a specification could reduce the cost of integrating with new trading partners and responding to changes in existing interfaces. In addition, creating a standard language to describe the relationships between document exchanges will be helpful to other standards bodies, such as RosettaNet or CIDX, giving them a standard infrastructure for message choreography and enabling them to focus on the core competencies relevant to their domain.

The Web Services Choreography Working Group, part of the Web Services Activity, is chartered to create the definition of a choreography, language(s) for describing a choreography, as well as the rules for composition of, and interaction among, such choreographed Web services. The language(s) should build upon the foundation of the Web Service Description Language 1.2 (WSDL 1.2).

1.1 Inputs

The Working Group shall start by considering the various input documents listed below and refine the scope and factorization of the choreography space. The Working Group is also expected to be aware of other work that has been published in this area, although it is not a formal input.

The Working Group shall consider, at a minimum, as input:

The Working Group will also consider additional input it sees fit.

1.2 Deliverables

The Working Group shall produce the following deliverables:

  • A requirements document, including a description of the factorization of the choreography space.
  • Usage scenarios.
  • One of more specifications of choreography language(s) and its XML Schema.
  • A primer.
  • A test suite:
    A test suite will be developed by the Working Group in order to assess advancement to Proposed Recommendation stage and to promote interoperability. The Working Group is expected to demonstrate two interoperable implementations during the Candidate Recommendation phase. Conformance requirements must be clearly stated in the specification produced.

1.3 Choreography Language Specification

The choreography specification(s) shall define (at a minimum) the behavior and language constructs for the following key concepts:

  • Composition features
    • The ability to define a choreography as a Web service, i.e. a recursive composition model.
    • Definition of the choreography's externally observable behavior.
    • Ability to represent stateful choreographies.
    • Definition of the identity of an instance of an execution of a choreography.
    • Life-cycle management (e.g. creation, termination, etc.)
    • Message exchange interactions between Web services (e.g. receive, invoke, etc.).
    • Behavior definitions (e.g. sequencing , looping, concurrent execution, etc.).
    • Scoping rules.
    • Activities.
  • Associations
    • Roles based on Web service use.
    • Linkages between Web services.
    • References to Web services.
  • Message exchanges
    • Conversations - correlated message exchanges that define interactions between Web services.
    • Correlations and their life cycle management.
    • Correlation relationships with choreography instances and state.
  • State Management
    • Definition, manipulation, and query capabilities.

There are two aspects to Web services choreography:

  • the process interface, external, description: this concerns the interactions with other services.
  • the process execution, internal, description: this concerns the internal behavior of the service.

The Working Group will concentrate on addressing the external description, taking into account the separation between those two aspects and their relationship, and defining the necessary process execution hooks for enabling the external interface description.

1.4 Mapping to the Semantic Web

The Choreography Working Group is strongly encouraged to provide a semantic mapping using the RDF and OWL technologies. Such a mapping will allow the information described by the choreography language to be easily combined with that of other applications. Also, as the Semantic Web languages allow the application of formal techniques to the analysis of the meaning of vocabularies, such a mapping would facilitate the understanding of the choreography language itself. The Working Group will consider the impact of each of its design choices on the ability to produce this mapping.

The goal of the Semantic Web is to enhance the utility of the Web as a machine-processable information space. The Semantic Web builds on the current Web infrastructure (XML, URI's, HTTP) and provides a standardized representation for data (XML/RDF) and for the conceptual structures behind that data (RDF Schema, Web Ontology Language). Web services are aiming at enabling automated distributed computing on the World Wide Web. It is important for both Web Services and for the Semantic Web that the semantics of the choreography language be clear and precise.

2 Out of Scope

2.1 Qualities

It is obvious that transactions, security, reliability, availability, and other such qualities are intimately related with Web service choreography, some more than others. It is not the goal of this group to define these mechanisms, but it must clearly articulate the boundaries.

2.2 Mappings to Programming Languages

Web services are composed of interfaces to applications, which can be written in different programming languages. The purpose of the Working Group is to provide a framework that supports a wide variety of applications and programming languages and is not geared towards any programming language. Given the wide variety of programming languages, the Working Group should not define mappings to any programming languages.

2.3 Graphical notation

One aspect of modeling choreographies will be to represent them graphically. It is out of the scope of the Working Group to define such a graphical notation.

3 Schedule

These are subject to revision due to editorial needs and external scheduling issues; updates will be negotiated with the related groups and recorded on the Web Services Choreography Working Group home page. Meeting dates are mentioned here for planning purposes.

January 2003
Working Group created.
March 2003
First Working Group face-to-face meeting, with presentation of the existing work in this area at the invitation of the Working Group Chairs..
April 2003
First requirements document for Web services choreography.
July 2003
First Working Draft of the Web services choreography specification.
January 2004
Last Call Working Draft of the Web services choreography specification.
April 2004
Candidate Recommendation for the Web services choreography specification.
July 2004
Recommendation for the Web services choreography specification.
December 2004
Working Group ends.

The target duration of the Working Group is 2 years, through December 2004. Experience suggests that 6 months of contingency should be allowed to accommodate unexpected obstacles to progress.

4 Relationship with Other Work

4.1 W3C Groups and Activities

XML and XML derived activities have become a strategic technology in W3C and elsewhere. Each deliverable of any Working Group must satisfy the dependencies from other W3C Working Groups before it can advance to Candidate Recommendation.

Web Services Activity
The Web Services Architecture Working Group has been chartered to create a document describing the architecture of Web services. The Working Group will continue to take the Web Services Architecture into account while designing the choreography language in order to make sure that Web services can be deployed in an optimal way, as recommended by the Web Services Architecture Working Group.
The Working Group must describe services accessible via WSDL 1.2 defined by the Web Services Description Group.
It is expected that other Working Groups will be formed to address different aspects of the Web services architecture. The Working Group will closely coordinate its work with any other Working Group formed within the Web Services Activity and generally in the Web services area, as well as with relevant Working Groups outside of the Web Services Activity.
The Working Group will participate in the Web Services Coordination Group.
XML Activity
There are similarities between the definition of a Web service choreography and an XML processing model. The Web Services Choreography Working Group should consider the wide field of use of a choreography language. The Working Group will pay attention to any related effort going on in the XML Activity.
Semantic Web Activity
The Semantic Web aims at transforming the Web into a completely machine-processable information space. Web services are aiming at enabling automated distributed computing on the World Wide Web.
QA Activity
The Working Group will develop a primer and a test suite in order to improve the quality of the documents produced and their implementations.
Internationalization Activity
The Internationalization Working Group will review work to ensure that principles developed by that group are consistently applied.
Web Accessibility Initiative
The work of the Working Group will be subject to review by WAI.
XForms Working Group
XForms can be seen as providing a user interface for Web services. The Working Group will call for requirements from the XForms Working Group, if any.
Security-related Working Groups (XML Signature, XML Encryption, XML Key Management)
Like other work in the Web Services Activity, Web services choreography should be developed with security requirements in mind. The security-related Working Groups of W3C will be asked to review the work of the Web Services Choreography Working Group to ensure that suitable security mechanisms can be applied. The Choreography Working Group may formulate requirements for further work on security-related mechanisms.
Platform for Privacy Preferences Project
Like other work in the Web Services Activity, Web services choreography has privacy implications; some of them have been identified by the Web Services Architecture Working Group. P3P will be asked to review the work of the Web Services Choreography Working Group to ensure that suitable privacy mechanisms can be applied. The Web Services Choreography Working Group may formulate requirements for further work on privacy issues.

4.2 External Groups

The Web Services Choreography Working Group should liaise with at least the following groups outside W3C (see also W3C liaisons with other organizations):

The Business Process Management Initiative
The Business Process Management Initiative is a non-profit working towards establishing standards for the management of business processes that span multiple applications, corporate departments and business partners.
DAML Services
The DAML Services arm of the DAML program is developing a DAML-based Web Service Ontology (currently named DAML-S), as well as supporting tools and agent technology to enable automation of services on the Semantic Web. DAML-S supplies Web service providers with a core set of markup language constructs for describing the properties and capabilities of their Web services in unambiguous, computer-interpretable form.
ebXML Joint Co-Ordination Committee
The ebXML initiative was a joint activity of UN/CEFACT (the United Nations body responsible for UN/EDIFACT) and OASIS (Organization for the Advancement of Structured Information Standards). Their charter was to develop an XML-based infrastructure for electronic commerce, with a particular focus on making connections between EDI and XML. While the original ebXML initiative's charter ended in May of 2001, the work transitioned to the respective sponsoring organizations (OASIS and UN/CEFACT) under the auspices of an MOU signed by the two in May of 2001.
Foundation for Intelligent Physical Agents
FIPA is a non-profit organisation founded in 1996 aimed at producing standards for the interoperation of heterogeneous software agents.
Global Grid Forum
The Working Group will attempt to liaise with the Global Grid Forum. The Global Grid Forum is a community-initiated forum of individual researchers and practitioners working on distributed computing technologies.
Organization for the Advancement of Structured Information Standards
OASIS is a not-for-profit, global consortium that drives the development, convergence and adoption of e-business standards. OASIS's work on business transactions will be taken into account by the Working Group to put choreographies in perspective with regards to transactions.
UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business)
The International Trade and Business Processes Group (TBG) maintains ebXML Business Process Specification Schema, a meta-model for business processes that is part of the ebXML framework.
Workflow Management Coalition
The Workflow Management Coalition, founded in August 1993, is a non-profit, international organization of workflow vendors, users, analysts and university/research groups. The Coalition's mission is to promote and develop the use of workflow through the establishment of standards for software terminology, interoperability and connectivity between workflow products.

5 Participation, Meetings, and Logistics

5.1 Participation

To join the Web Services Choreography Working Group, please follow the instructions of section 4.2.3 of the Process Document, sending email to the Working Group Chair and the W3C Team contact. The nomination must include explicit agreement to this charter, including its goals, an IPR disclosure and the level of effort required of the representative.

Each Member organization may have at most two participants in the Working Group. Only Working Group participants may engage in formal votes on substantive issues. When a formal vote is required, each Member organization or group of related Members is allowed one vote, even though the Member may have several participants in the Working Group.

The W3C Team is expected to have at most two participants in the Working Group (including the Team contact). When a formal vote is required, the Team is allowed one vote.

Membership is also open to invited experts from the community, selected by the Chair in order to balance the technical experience of the group.

Each participant should expect to spend one day per week on work for this Working Group.

5.2 Email Communication

The Working Group will utilize a public mailing list <public-ws-chor@xxxxxx> for its technical email communications. It is referred to in the rest of this document as the Working Group mailing list.

A Member-only mailing list <member-ws-chor@xxxxxx> is available for administrative purposes only.

5.3 Group Home Page

The Working Group has a home page that records the history of the group, provides access to the archives, meeting minutes, updated schedule of deliverables, membership list, and relevant documents and resources. The page is available to the public and should be maintained by the Chair in collaboration with the W3C Team contact.

5.4 Meetings

The Working Group will have distributed and face-to-face meetings.

A one- to two-hour Working Group distributed meeting will be held every week. When necessary to meet agreed-upon deadlines, distributed meetings may be held twice a week.

The Working Group may schedule face-to-face meetings in a manner that maximizes co-location with events that Working Group members would be attending anyway.

Participation in meetings (distributed or face-to-face) is limited to participants in good standing and individuals invited at the discretion of the Chair to specific meetings.

Decisions taken in meetings must be announced on the Working Group mailing list. Observers may take part in decision-making at the discretion of the Chair.

Meeting records must include attendance, the results of group decisions, and action items. They must be made publicly available except for non-technical issues that do not directly affect the output of the Working Group. The Chair will decide which issues are not made public.

5.5 Resources

To be successful, we expect the Working Group to have approximately 20 to 30 active participants. A large public review group that will participate in the mailing list discussions is expected.

The Chairs for the Web Services Choreography Working Group are Martin Chapman (Oracle Corporation) and Steve Ross-Talbot (Enigmatec Corporation).

5.6 W3C Team Involvement

The W3C Team Contact for this Working Group is Yves Lafon. The W3C Alternate Team Contact is Hugo Haas. It is expected that the total Team resources devoted to this Working Group will be about six tenths of a full-time engineer.

5.7 Intellectual Property

W3C promotes an open working environment. Whenever possible, technical decisions should be made unencumbered by intellectual property right (IPR) claims.

This is a Royalty Free Working Group, as described in W3C's Current Patent Practice, dated 24 January 2002.

Working Group participants disclose patent claims by sending email to <patent-issues@xxxxxx>; please see Current Patent Practice for more information about disclosures.

Chairs: Martin Chapman & Steve Ross-Talbot
Team Contacts: Yves Lafon & Hugo Haas
$Id: wscwg-charter.html,v 1.25 2003/01/14 21:21:53 cmsmcq Exp $
<Prev in Thread] Current Thread [Next in Thread>
  • [ontolog] Web Services Choreography Working Group Charter, Leo Obrst <=