proposed Choreography charter - Halloween Draft

Hi,
    This is our (oracle's) latest attempt to draft a proposed charter that 
is responsive to the stated requirements of the WSCG and others to provide 
the AC with a more narrowly focused charter.
    I tried to abstract the essential elements of "the space" referring to 
the public aspects of choreography while still capturing important concepts 
such as state management, correlations, roles, etc. In response to the 
"boil the ocean" remarks and the votes/discussions that have gone on, I 
made the explicit input documents be wsci and bpel, while leaving in the 
broader references in the introductory material

    cheers,
      jeff

/ | %5CArchitecture%5C

Web Services Choreography Working Group Charter - Halloween Draft [v5]
(jm,mc)

- Goals and Scope of the Web
Services Choreography Working Group

- Inputs

- Deliverables

- Out of Scope

- Qualities

- Mappings to Programming
Languages

- Schedule

- Relationships with
Other Work

- W3C Groups and Activities

- External Groups

- Participation, Meetings, and
Logistics

- Participation

- Email Communication

- Group Home Page

- Meetings

- Resources

- W3C Team Involvement

- Intellectual Property

- References

1 Goals and Scope of the Web Services Choreography
Working Group

It has become clear that a next step in the evolution
of Web services will be the ability to compose and describe the relationships
between Web services. Although differing terminology is used in the industry,
such as orchestration, collaboration, coordination, conversations, etc.,
the terms all share a common characteristic of defining linkages and
usage patterns between web services. For the purpose of this document,
and without prejudice, we use the term choreography as a moniker
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 WG 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[6] , and WSCI[2] , have recently been published by the W3C as Technical
Notes. There are other industry efforts in the area of choreography languages,
such as BPML[7] (defined by BPMI.org), BPSS[8] (defined by ebXML.org), IBM's

WSFL[9] , MSFT's XLANG[10] ,
and IBM/MSFT/BEA's BPEL4WS[3] and their companion specifications
WS-Coordination[4] and WS-Transaction[5] ), etc.

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 WG now. This WG
should address the choreography space encompassed by the input documents
and deliverables. This WG should also coordinate with other WGs within
the Web Service Activity, with the aim of developing an interoperable
and open standard for Web service choreography

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 (WSDL).

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:

- Web
Services Architecture [1]

- BPEL4WS
[3] (if made available to the W3C by its owners)

- WSCI [2]

- W3C Choreography Workshop [date tbd]

1.2 Deliverables

The Working Group shall produce the following deliverables:

- A requirements document. including a detailed
description of the factorization of the Choreography space

- Usage scenarios

- One or 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.

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 choregraphy 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 a choreography
instance.

- Lifecycle management (e.g. creation, termination,
etc.)

- 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.

- Activities

- Message exchange interactions between web
services (e.g. receive, invoke, etc.).

- Behavior definitions (e.g. sequencing , looping,
concurrent execution, etc.).

- Assignment semantics.

- Relationships between activities.

- Scoping Rules.

- Nesting Rules.

- State Management

- Definition, manipulation, and query capabilities

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.

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.

November 2002

Working Group chartered

January 2002

W3C Workshop on Web Services
Choreography

February 2002

First Working Group face-to-face meeting

April 2002

First requirements document
for Web services choreography

July 2002

First Working Draft of the
Web services choreography specification.

January 2003

Candidate Recommendation
for the Web services choreography specification.

November 2003

Recommendation for the Web
services choreography specification.

June 2004

Working Group ends

The target duration of the Working Group is 2 years, through June 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. A working draft of this document
is now available. The Working Group will continue to take this document
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 deal with 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

The typing of the messages must be possible
using XML Schema . While no dependencies
other than the one with the XML Schema Working Group are presently identified,
the Web Services Description Working Group should be prepared to coordinate
with the XML Activity as necessary.

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 this project.

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.

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 ):

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.

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 metamodel for business processes that is part of the ebXML
framework.

BPMI.org

BPMI.org is a non-profit working
towards establishing standards for the management of business processes
that span multiple applications, corporate departments and business partners.

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 <[email protected] > 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 <[email protected] >
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 Chair for the Web Services Choreography
Working Group will be XXXX.

5.6 W3C Team Involvement

The W3C Team expects to dedicate the time of the services of one Team Contact , full-time, for the 2-year
duration of the Working Group. XXXX will provide this effort.

5.7 Intellectual Property

W3C promotes an open working environment. Whenever possible, technical
decisions should be made unencumbered by intellectual property right
(IPR) claims. W3C's policy for intellectual property is set out in section 2.2
of the W3C Process document .

Members
of the Working Group are expected to disclose any intellectual property
they have in the area. This WG will work on a royalty-free
basis, as defined in the W3C Current Patent Practice
document. The Working Group is thus obliged to produce a specification which
relies only on intellectual property available on a royalty-free basis.

If it proves impossible to produce specifications implementable on a royalty-free
basis, then a Patent Advisory Group will be launched as described in the
W3C Current Patent
Practice document.

Members disclose patent and other IPR claims by sending email to <[email protected] >, an archived mailing
list that is readable by Members and the W3C Team. Members must disclose
all IPR claims to this mailing list but they may also copy other recipients.
IPR disclosures are expected to be made public; Members should specify
if their disclosure is confidential.

6 References

[1] http://www.w3.org/2002/ws/arch/2/08/wd-wsa-arch-20020821.html

[2] http://www.w3.org/TR/wsci/

[3] http://www-106.ibm.com/developerworks/library/ws-bpel/

[4] http://www-106.ibm.com/developerworks/library/ws-coor/

[5] http://www-106.ibm.com/developerworks/webservices/library/ws-transpec/

[6] http://www.w3.org/TR/wscl10/

[7] http://www.bmpi.org

[8] http://www.ebxml.org/specs/ebBPSS.pdf [9] http://www-3.ibm.com/software/solutions/webservices/pdf/WSFL.pdf

[10] http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm http://www.ebxml.org/specs/ebBPSS.pdf

----------

Team Contact: XXXXX