RE: Proposed Draft Charter for Choreography WG

Jeff,
 
It seems that the working group is walking towards a spefication that
describes/combines both the public protocol/interface and the private
implementation (executable workflow language). 
 
If that is the case, shouldn't the requirements for private
implementation also include the need for a transactional model?
Exceptions are really what make execution of compositions/workflows
complex by increasing the variability of the fabric that ties the
services together. As discussed in the mailing list earlier, exceptions
can not be abstracted out of the workflow logic. It seems that the only
way to reduce this complexity and make the solution viable for
production systems is to have a framework for
cancellation/compensation/transactions built into the language.

 
Also visualization/notations are a very important aspect of the problem:
XML is a pretty inhuman programming language and therefore the
goal/dream here is that most of the private implementations will be
generated by visual tools. BPMI for example has be working on a notation
language for about a year or so. BPML learned the hard way that the
notation language was a very important aspect of the usability and
therefore could not be an after thought.
 
Any thoughts?
 
Edwin
 
 
-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
Behalf Of Jeff Mischkinsky
Sent: Thursday, November 07, 2002 1:57 PM
To: www-ws-arch@w3.org
Cc: Steve Bratt; C. M. Sperberg-McQueen
Subject: Proposed Draft Charter for Choreography WG


 


 
 W3C <http://w3.org/Icons/w3c_home> |  Architecture Domain
<http://w3.org/Icons/arch> 

Web Services Choreography Working Group Charter Proposal

1.	Goals and Scope of the Web Services  <> Choreography Working
Group 

1.	Inputs <>  

2.	Deliverables <>  
2.	Out of Scope <>   

1.	Qualities <>  

2.	Mappings to Programming Languages <>  
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 <>  
6.	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

WSDL has proved very useful for describing a single service. Currently
complex natural language describing the obligations of the participants
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 <file:///2002/ws/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  <file:///2002/ws/desc/>
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
<http://www.w3.org/2002/ws/arch/2/08/wd-wsa-arch-20020821.html> Services
Architecture [1] <>  

*	BPEL4WS <http://www-106.ibm.com/developerworks/library/ws-bpel/>
[3] <>  (if made available to the W3C by its owners)


*	WSCI <http://www.w3.org/TR/wscl10/>  [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 specify externally defined constraints.


*	Ability to represent stateful choreographies. 

*	Definition of the identity of a choreography instance. 

*	Lifecycle 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





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.
December 2002
Working Group chartered

January 2003
W3C Workshop on Web Services Choreography
February 2003
First Working Group face-to-face meeting <> 
April  2003
First requirements document for Web services choreography
July 2003
First Working Draft of the Web services choreography specification.
January  2004
Candidate Recommendation for the Web services choreography
specification.
June 2004
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 <http://www.ebxml.org/>  was a joint activity of
UN/CEFACT <http://www.unece.org/>  (the United Nations body responsible
for UN/EDIFACT <http://www.unece.org/trade/untdid/welcome.htm> ) and
OASIS <http://www.oasis-open.org/>  (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 <www-ws-xxx@w3.org
<mailto:www-ws-desc@w3.org> > 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 <w3c-ws-xxx@w3.org
<mailto:w3c-ws-desc@w3.org> > 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
<http://www.w3.org/TR/patent-practice#sec-Licensing>  basis, as defined
in the W3C Current Patent Practice
<http://www.w3.org/TR/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
<http://www.w3.org/TR/patent-practice#sec-PAG> Patent Practice document.

Members disclose patent and other IPR claims by sending email to
<patent-issues@w3.org>, an archived mailing
<http://lists.w3.org/Archives/Member/patent-issues/> 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