W3C Issues "Last Call" on Web Services Descriptions

The W3C has issued its "Last Call" draft defining web services, and laying out the basic code requirements and architecture. This core spec, with final deadline for comment Dec. 31, will put to an end many of the political and technical debates over what a "web service" truly is. Most importantly to integration developers, this W3C doc finally begins to define how to build a web service that will interoperate with other systems.

Tags: Web Service, Protocol, Interface, Data Format, SOAP, Interoperate, Specifies,



"With this latest W3C work, web services developers now have a basic profile that spells out the base requirements for making sure a web service message can be sent, received and interoperate between platforms, said Neil Charney, a co-chair of the WS-I (Web Services Interoperability Organization) told IDN.



"We also will have sample applications that will show developers how to implement the base profile, and make sure their code will interoperate from Java to Microsoft to IBM to BEA," added Charney, who is also a director in Microsoft's .NET platform strategy group. "Depending on the scenario or the security requirements, that may require other [higher level] capabilities, but the base capability to interoperate using SOAP between systems is there."



Here are some of the more notable definitions:



  • Web Service -- a software application identified by a URI [IETF RFC 2396], whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via Internet-based protocols. ]


  • Client -- a software that makes use of a Web Service, acting as its 'user' or 'customer'.]


  • Message -- the basic unit of communication between a Web Service and a Client; data to be communicated to or from a Web Service as a single logical transmission.]


  • Operation -- a sequence of Messages related to a single Web Service action.


  • Interface (AKA Port Type) -- as a logical grouping of operations, this represents an abstract Web Service type, independent of transmission protocol and data format.]


  • InterfaceBinding -- specifies the protocol and/or data format to be used in transmitting Messages defined by the associated Interface. Defines an association between an Interface, a concrete protocol and/or a data format.


  • EndPoint (AKA Port) -- indicates a specific location for accessing a Web Service using a specific protocol and data format. Also helps define an association between a fully-specified InterfaceBinding and a network address, specified by a URI [IETF RFC 2396], that may be used to communicate with an instance of a Web Service.


  • Service -- a collection of EndPoints.


  • Aside from setting definitions, the Last Call documents sets base architectural requirements for building a web service.



    Interface Descriptions must describe messages accepted and generated by a web service, and allow the describing application layer error messages (faults) generated by a service. They will also support descriptions of operations, policies and allow for messages to be abstracted from their message patterns. Description language must also provide "human readable" comments.



    For Interactions with a Service, the language must allow describing the functionality associated with one-way messages (request-response, solicit-response, and faults). (From the Charter. Last revised 28 Feb 2002.) Further, it "should" indicate how long it will take the web service to process the request. [W3C puts it this way: "This is just a hint to the Client, and the Web Service would not be obligated to respect what it advertised."].



    For Messages and Types, messages must be independent from transfer encodings. Further, Messages should be allowed to include references (URIs) to typed referents, both values and Services.



    For Service Types, one Service type should be able to be derived from another by extension of the logical group of InterfaceBindings.



    For InterfaceBindings, the EndPoint location must be described using URIs, and provide for the unambiguous mapping of any on-the-wire Message to an Operation. This includes the specifying of an association between an Interface and one or more concrete protocols and/or data formats. Further, InterfaceBindings must be publishable/describable to other protocols besides those described in the specification.



    Further, binding Interfaces to transports other than HTTP/1.1 will be supported. And the structure of incoming and outgoing SOAP 1.2 messages (contents, encoding, target, and optionality of SOAP 1.2 Header and Body blocks, SOAP RPC blocks, and SOAP Faults) will be described.



    For Reusability, partitioning of a description across multiple files and the use of a description fragment in more than one description must be allowed.



    The Last Call review period ends on 31 December 2002. Comments on this document should be sent to public-ws-desc-comments@w3.org (public archive).






    back