|
This is the second charter for the Web Services Description Working Group. The previous charter is still available.
One of the requirements for the development of Web services is the ability to describe the interface, the boundary across which applications (Web services user agents and Web services) communicate. Applications can then interoperate using this interface.
The Web Services Description Working Group, part of the Web Services Activity , is chartered to design the following components of the interface:
Furthermore, the following three general requirements must be met by the work produced by this Working Group:
The remainder of this section describes the requirements and deliverables in more detail.
The Working Group started by developing a requirements document detailing and refining the scope of its work, which is the scope of the WSDL 1.1 specification . It then proceeded by evaluating the technical solutions offered by WSDL 1.1.
If in this process the Working Group finds solutions that are agreed to be improvements over solutions suggested by WSDL 1.1, those improved solutions should be used. However, the Working Group should not make arbitrary changes, i.e. without technical reasons, and it should be easy to convert a WSDL 1.1 description into the new format designed.
In addition to the specification of a description language, the Working Group will produce a primer in order to help novices familiarize themselves with this technology.
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.
Simplicity is a key element in making distributed systems easy
to understand, implement, maintain, and evolve. Although simplicity
can only be measured in relative terms, the Working Group must
ensure that the complexity of any solution produced is comparable
to that of other current and widespread Web solutions. Note that
simplicity should not be confused with
being easy to
understand
.
It is believed that limiting its scope to exclude bindings to existing programming languages will put the Working Group in a better position to achieve its goal of producing a simple mechanism for describing the functionality made available by an application to communicating peers.
Another important aspect of simplicity is ease of deployment. The Working Group will look at various ways of deploying the Web services descriptions in a manner that is compatible with the existing Web infrastructure (see the relationship with other external groups ).
Web services are modeled as interfaces between applications on the World Wide Web. In order to make use of a Web service, one needs to know what information is expected and in what form.
Therefore, the interface needs to be explained for use by remote parties. The structure of the messages accepted and/or generated needs to be described.
The Working Group will define a description language expressed in XML. The description language must describe the messages available via the interface, accepted and generated by the Web service. The language must also describe the error messages generated, if any.
The data exchanged is usually typed and structured. This increases interoperability by having applications agreeing on semantics and also provides some level of error detection.
It is expected that developers will want to use different mechanisms for describing data types and structures, depending on the purpose of the Web service. The Working Group should allow different mechanisms, and must define one based on XML Schema . The Working Group will also take into account the encoding work going on in the XML Protocol Working Group , and will make sure that SOAP Version 1.2 's extensibility mechanism can be expressed.
The description language designed will be used both by applications in order to automatically communicate between each other as well as by programmers developing Web services themselves. The language should therefore provide, in addition to the raw XML definition of the interface, human-readable comment capabilities to allow both applications and developers to make use of them.
Developers are likely to want to extend the functionality of an existing Web service. The Working Group will look into extending interface descriptions in a decentralized fashion, i.e. without priori agreement with the original interface designers.
Interacting using an interface can be done in different ways. Some Web services may accept an incoming message and return a response, others may only generate messages, etc.
The Working Group will define a mechanism which allow a Web service to describe the following set of operations: one-way messages (to and from the service described), request-response and solicit-response, as described in WSDL 2.0 Message Patterns .
The information exchanged to and from a Web service can be carried in a large number of different ways. The action of carrying some XML-based communication in an underlying protocol is called, in the XML Protocol jargon, a binding.
The description language defined should therefore describe how to reach the Web Service in a form which is orthogonal to its message exchange patterns and its messages.
It is expected that in the near-term future, Web services will be accessed largely through SOAP Version 1.2 (the XML-based protocol produced by the XML Protocol Working Group ) carried over HTTP/1.1, or by means of simple HTTP/1.1 GET and POST requests.
However, some organizations may wait until WSDL 2.0 is released as a W3C Recommendation to switch from SOAP 1.1 to SOAP Version 1.2. A binding for SOAP 1.1 will ease the migration from WSDL 1.1 to WSDL 2.0 for organizations describing SOAP 1.1-based services.
The Working Group will describe the following bindings:
The Working Group will also consider developing binding descriptions for HTTP/1.1 PUT and DELETE methods.
The Message Transmission Optimization Mechanism (MTOM) specification is being developed by the XML Protocol Working Group . Support for this mechanism will be provided, unless such support is in conflict with the schedule of WSDL 2.0 .
The Working Group will also ensure that other SOAP bindings can be described.
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. The work of this Working Group is essentially the provision of an ontology for Web services.
One of the tools used by Semantic Web-enabled technologies is RDF . The Working Group will provide a mapping to RDF so that the information described can be easily merged with that of other applications. This mapping will be developed with the help of the RDF Interest Group .
The Working Group will advance to appropriate status the following deliverables:
The Working Group found significant technical merit in removing
the 'message' and 'part' constructs found in WSDL 1.1 and
leveraging the power of XML Schema more directly in describing
message structure, but felt such a significant structural change,
along with all the other improvements, was incompatible with the
expectations set by the name "WSDL 1.2". Therefore, following those
changes, the Working Group decided to name the new version
WSDL 2.0
.
The area of Web services is very broad as it includes everything between a simple remote procedure call using an XML-based protocol to a sequence of N different services interacting in order to provide very advanced functionalities (e.g. a travel reservation service making use of individual services).
It is therefore important to clearly limit the scope of the Working Group.
This section describes out-of-scope work items. In general, the Working Group will also consider items out of scope that are being addressed as part of other W3C Activities , and it will reuse existing specifications wherever possible, including XML Namespaces and XML Schemas, Parts One and Two .
The Working Group maintains an issues list, with issues accepted at the discretion of the Chair, and disposed of by decision of the Working Group. The Chair shall consider the impact on the Working Group schedule when accepting issues, since accepting an issue puts a Working Group decision in the critical path.
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.
Several individual Web services can be composed to provide more complex functionalities. The goal of the Web Services Description Working Group is to describe individual Web services.
Although the Working Group needs to ensure Web services descriptions can be referenced unambiguously and that the language designed does not preclude the description of the composition of individual services, the way two or more services could be composed is considered out of scope.
Once the World Wide Web is populated with Web services, an important aspect will be the discovery of Web services. The Web Services Description Working Group will not look into Web services discovery.
This is the schedule for the WSDL 2.0 W3C Recommendations. Significant changes to the schedule, such as changing the publication dates by more than 3 months, MUST be approved by the W3C Director. The Advisory Committee MUST be notified of any significant schedule changes. This charter is not expected to be extended without prior publication of the WSDL 2.0 W3C Recommendations.
The duration of the Working Group is 2 years, through January 2006.
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.
The Working Group must describe services accessible via SOAP Version 1.2 defined by the XML Protocol Working 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.
The Working Group will participate in the Web Services Coordination Group .
The Working Group will develop a mapping of the language developed to RDF with the help of the RDF Interest Group .
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.
The Working Group will develop a primer and a test suite in order to improve the quality of the documents produced and their implementations.
The Internationalization Working Group will review work to ensure that principles developed by that group are consistently applied.
The work of the Working Group will be subject to review by this project.
The Web Services Description Working Group should liaise with at least the following groups outside W3C (see also W3C liaisons with other organizations ):
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.
The Working Group will attempt to liaise with the Web Services
Interoperability Organization.
The Web Services Interoperability Organization is an open
industry effort chartered to promote Web Services interoperability
across platforms, applications, and programming languages
.
Each organization may have at most two representatives in the Working Group, except as provided below.
If a testing and QA Task Force is created in the Working Group, each Member organization may also designate up to two additional participants for the exclusive purpose of participating in the Task Force. If allowed by the Chair, these participants may participate in general discussions and straw polls that are not directly related to testing or QA.
The Chair decides whether a quorum is present for any working group meeting.
Each participant should expect to spend one day per week on work for this Working Group.
The Working Group will utilize a public mailing list < 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-desc@w3.org > is available for administrative purposes only .
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.
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.
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.
To be successful, we expect the Working Group to have approximately 10 to 15 active participants. A large public review group that will participate in the mailing list discussions is expected.
The Chair for the Web Services Description Working Group is Jonathan Marsh (Microsoft).
The W3C Team expects to dedicate the time of the services of one Team Contact , 0.75 FTE, for the 2-year duration of the Working Group. Hugo Haas is the Team Contact. David Booth serves as alternate Team Contact.
W3C promotes an open working environment. Whenever possible, technical decisions should be made unencumbered by intellectual property right (IPR) claims.
This Working Group is chartered as a Royalty Free Working Group, and operates by the 24 January 2001 Current Patent Practice (CPP) Note as amended by the W3C Patent Policy Transition Procedure. Therefore, please disclose relevant patent claims according to section 6 of the W3C Patent Policy.
Members disclose patent and other IPR claims as defined in by sending email to <patent-issues@w3.org>, an archived mailing list that is readable by Members and the W3C Team.