W3C Issues "Last Call" on Web Services Descriptions
"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:
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 firstname.lastname@example.org (public archive).