- From: Doug Bunting <db134722@iplanet.com>
- Date: Thu, 07 Nov 2002 15:08:09 -0800
- To: edwink@collaxa.com
- Cc: "'Jeff Mischkinsky'" <jeff.mischkinsky@oracle.com>, www-ws-arch@w3.org
- Message-id: <3DCAF259.7020808@iPlanet.com>
Edwin,
In earlier teleconferences, the group consensus seemed to head away from
the distinction you're making. Public and private are recursive
contexts in this domain. Even in the most widely distributed
choreography use case, some aspects of the "private" description may be
important to all participating services because they are operating as
peers. The business use case David Burdett forwarded shows this
relatively clearly: The three companies and their tools need to know
more than "just" the separate interfaces to the other companies. As
well, decisions made rely on information "internal" to the choreography
all are involved in.
I believe the current charter is appropriately silent on this
distinction and that it reflects our thinking. Please let us know if
I'm mis-remembering something or misinterpreting your comments.
thanx,
doug
Edwin Khodabakchian wrote:
> 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 </>| Architecture Domain <%5CArchitecture%5C>
>
>
> Web Services Choreography Working Group Charter Proposal
>
> 1. Goals and Scope of the Web Services Choreography Working
> Group <#scope>
> 1. Inputs <#inputs>
> 2. Deliverables <#deliverables>
> 2. Out of Scope <#outofscope>
> 1. Qualities <#qualities>
> 2. Mappings to Programming Languages <#prog>
> 3. Schedule <#schedule>
> 4. Relationships with Other Work <#relationships>
> 1. W3C Groups and Activities <#internal>
> 2. External Groups <#external>
> 5. Participation, Meetings, and Logistics <#mml>
> 1. Participation <#participation>
> 2. Email Communication <#email>
> 3. Group Home Page <#home>
> 4. Meetings <#meetings>
> 5. Resources <#resources>
> 6. W3C Team Involvement <#w3t>
> 7. Intellectual Property <#ipr>
> 6. References <#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] <#ref-6>, and WSCI[2]
> <#ref-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] <#ref-7> (defined by
> BPMI.org), BPSS[8] <#ref-8> (defined by ebXML.org), IBM's
> WSFL[9] <#ref-9>, MSFT's XLANG[10] <#ref-10>, and IBM/MSFT/BEA's
> BPEL4WS[3] <#ref-3> and their companion specifications
> WS-Coordination[4] <#ref-4> and WS-Transaction[5] <#ref-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
> Description Language <file:///2002/ws/desc/> (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
> <http://www.w3.org/2002/ws/arch/2/08/wd-wsa-arch-20020821.html>
> [1] <#ref-1>
> * BPEL4WS
> <http://www-106.ibm.com/developerworks/library/ws-bpel/> [3]
> <#ref-3> (if made available to the W3C by its owners)
> * WSCI <http://www.w3.org/TR/wscl10/> [2] <#ref-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
> o The ability to define a choregraphy as a web service,
> i.e. a recursive composition model.
> o Definition of the choreography's externally observable
> behavior.
> o Ability to specify externally defined constraints.
> o Ability to represent stateful choreographies.
> o Definition of the identity of a choreography instance.
> o Lifecycle management (e.g. creation, termination, etc.).
> o Message exchange interactions between web services
> (e.g. receive, invoke, etc.).
> o Behavior definitions (e.g. sequencing, looping
> concurrent execution, etc.).
> o Scoping rules.
> o Activities.
> * Associations
> o Roles based on web service use.
> o Linkages between web services.
> o References to web services.
> * Message exchanges
> o Conversations - correlated message exchanges that
> define interactions between web services.
> o Correlations and their life cycle management.
> o Correlation relationships with choreography instances
> and state.
> * State Management
> o 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 <#relationships> and recorded on the Web Services
> Choreography Working Group home page <%5C2002%5Cws%5CXXX>. 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 <#meetings>
>
> 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 <..%5Cws%5C>
>
> The Web Services Architecture Working Group
> <%5C2002%5Cws%5Carch%5C> 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
> <%5C2002%5Cws%5Cdesc%5C>.
>
> 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 <%5C2002%5Cws%5Ccg%5C>.
>
> XML Activity <%5CXML%5C>
>
> The typing of the messages must be possible using XML Schema
> <%5CXML%5CSchema>. 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 <%5CQA%5C>
>
> 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 <%5CInternational%5C>
>
> The Internationalization Working Group will review work to ensure
> that principles developed by that group are consistently applied.
>
> Web Accessibility Initiative <%5CWAI%5C>
>
> The work of the Working Group will be subject to review by this
> project.
>
> XForms Working Group <%5CMarkUp%5CForms%5C>
>
> 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 <%5C2001%5C11%5CStdLiaison>):
>
> 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
> <%5CConsortium%5CProcess-20010719%5Cgroups#JoinGroups> 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 <#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 <%5C2002%5Cws%5Cxxx%5C> 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 <%5CGuide%5Cchair-roles> 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 <%5CGuide%5Cstaff-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
> <%5CConsortium%5CProcess-20010719%5Cpolicies.html#ipr>.
>
> 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 Patent Practice
> <http://www.w3.org/TR/patent-practice#sec-PAG> document.
>
> Members disclose patent and other IPR claims by sending email to
> <patent-issues@w3.org <mailto:patent-issues@w3.org>>, an archived
> mailing list <http://lists.w3.org/Archives/Member/patent-issues/>
> 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 <%5CPeople%5CXXXX>
>
>
>
>
>
>
>
>
>
>
>
Received on Thursday, 7 November 2002 18:08:52 UTC