 |
|
|
Abstract
This paper describes the SOAP 1.2 extensibility mechanism. This mechanism is based on features and MEPs. The paper also explains how features and MEPs are likely to be supported in WSDL 1.2. Features provide reusable functionality at the middleware level. MEPs describe patterns of interactions between nodes on the network.
Keywords
Table of Contents
SOAP is the protocol that provides the Web Services backbone. Since Web services can be used in very diverse situations, it is of primary importance that SOAP be easily extensible. Furthermore, extensibility must not require a central authority, but be achievable in an ad-hoc, decentralized manner. The SOAP 1.2 extensibility model is based on the concept of features. A feature is an abstract piece of functionality that represents some processing to be performed. It does not indicate how the processing is carried out in practice.
WSDL is a language for describing Web services. The current version of WSDL does not support features. WSDL 1.2 will, however, include such support.
This paper describes SOAP 1.2 and WSDL 1.2 and in particularly features and MEPs.
SOAP is an XML-based protocol for exchanging structured messages between computers.
A SOAP message originates at an initial sender, circulates through zero or more intermediaries, and stops at a final receiver. The initial sender is responsible for creating and sending the message. The final receiver performs the main operation prescribed by the message. Intermediaries perform additional processing en route to alleviate or complement that done by the final receiver. For example, a security intermediary can authenticate users and verify message integrity, thereby allowing the final receiver to concentrate on its core competence.
A SOAP message consists in an envelope, zero or more attachments and zero or more protocol header fields. The envelope contains the application's data, encoded in XML. Attachments are generally data that does not fit well into the envelope, for example a very large X-Ray. Protocol header fields generally contain protocol data used by the recipient to decode, route or otherwise help process the message.
A SOAP envelope is further decomposed into blocks. Blocks can be thought of as encoding multiple independent or interrelated requests. Blocks are the basic unit of encoding and exchange between SOAP nodes. Blocks fall into two categories: header blocks and body blocks. Body blocks contain the message's main content, its real intent, and are meant for the final receiver only. Header blocks, on the other hand, contain data generally aimed at intermediaries. In certain circumstances, and depending upon design decisions, header blocks may also contain data targeted at the final receiver. For example, a remote image processing Web service might require "image processing" options to reside in a header block rather than within the body itself.
Blocks are targeted to a node -either an intermediary or the final receiver- via the "role" attribute. The value of the role attribute is either an address or a role name (both URIs). An address allows targeting a block to a specific receiver, known by its address. A role name allows targeting a block to any receiver that performs the type of processing identified by the role name. For example, a role name can identify either a very specific authentication intermediary (address) or any authentication intermediary on the message path (name). Header blocks can be targeted to any node, including the final receiver; whist body blocks can only be targeted to the final receiver (and are indeed targeted so automatically).
The processing of SOAP messages is governed by the SOAP processing model. Before processing a message, a receiver must first decide which roles to play for the processing of that message. The set of roles played depends on the receiver's configuration, its environment, the message's type and the message's content. The simultaneous presence of two given header blocks in an envelope might prompt, for example, an intermediary to play a role it would not have played if only one of the two header blocks had been present.
Once the intermediary has determined the set of roles played, it processes the blocks targeted to these roles. Processing starts with mandatory header blocks first, i.e. with blocks carrying a "mustUnderstand" attribute with a value of "true". In the absence of errors, processing continues with the other blocks. Processing is generally application dependent; however, certain SOAP implementation might process well-known blocks with little or even no application intervention.
Once processing is complete (and in the absence of any error), the message is trimmed down, i.e. all blocks processed are removed from the envelope. New blocks are added, if necessary, for example blocks that contain the results of the processing just performed.
Once trimmed downed, the message is forwarded to the next node for further processing. The next node is either the next intermediary in the chain or the final receiver. How the next node is determined is outside the scope of the SOAP specification. Eventually, the message reaches the final receiver and processing stops, unless a response is required, in which case a response message flows in the opposite direction.
Header blocks are SOAP 1.1 primary extension mechanism. In SOAP 1.2, header blocks have been generalized and an extended extension mechanism is provided, based on the central concept of features. In this model, header blocks are just one but a particular type of feature.
A feature is an abstract piece of functionality that represents some processing to be performed, some option to be set or some interaction pattern to be engaged. Features extend the basic SOAP processing model with semantics like reliability, security, correlation, routing, request/response, one-way or peer-to-peer interactions.
A feature has a name (a URI), which uniquely identifies the feature, and a set of properties. The name can be used by an application to determine if the local SOAP node, or some other SOAP node, supports the feature. For example, an application might ask if the ultimate receiver supports the "secure-channel" feature. A feature's name can also be used by other feature specifications to refer to a specific feature. For example, a strong authentication feature might refer to a basic authentication feature, from which it borrows requirements or properties.
Features have one or more properties. Properties act as virtual inputs and outputs to the processing specified by the feature. They allow specifying, constraining and controlling the processing to be performed or the type of interaction to be engaged. For example, the SOAP Request-Response message exchange pattern has properties for accessing the inbound or outbound messages, the immediate sender and the next destination. These properties are listed below.
http://www.w3.org/2003/soap/mep/InboundMessage
http://www.w3.org/2003/soap/mep/OutboundMessage
http://www.w3.org/2003/soap/mep/ImmediateDestination
http://www.w3.org/2003/soap/mep/ImmediateSender
Features often specify the processing to be performed on more than one node and are thus generally described by an (abstract) distributed state machine. For example, the SOAP Request-Response message exchange pattern is specified by two coordinated state machines, which indicate how requests and responses are exchanged and synchronized.
To be useable, features must be implemented somehow. SOAP provides two mechanisms for implementing features: header blocks and protocol bindings. In the first case, the feature is implemented via one or more header blocks. Such header blocks are subject to the standard SOAP processing model. For example, the "secure-channel" feature above might be implemented via an encryption header block.
In the second case, the feature is implemented directly by the protocol binding. The protocol binding is the layer that maps to the underlying protocol. In most cases, this is a thin layer that adapts the underlying protocol to SOAP's specific needs. For example, the "secure-channel" feature might be implemented directly by a SOAP HTTPS binding.
Both types of features have their merits and drawbacks. Features implemented as header blocks provide protocol independence, increased reusability, and behave gracefully even when the underlying protocol changes at a node further downstream. However, they can increase message size. Features implemented as protocol bindings are generally more efficient, but are less immune to protocol changes midstream. It is up to an application to decide which type of feature best fits its need. Often, an application has no choice but to use the features available at the local node.
There is a third type of feature: Message Exchange Patterns (MEPs). A MEP describes a particular type of interaction between two or more SOAP nodes (the flow of messages between these nodes) and the associated processing. For example, the SOAP Request-Response MEP describes the classical request-response pattern for two adjacent SOAP nodes. A multicast MEP might describe the simultaneous exchange of messages from one node to several. A purchase MEP might describe the complex interactions between a buyer, a seller, a broker, a financial institution and an authentication server.
MEPs, like other abstract features, are implemented either as header blocks or via protocol bindings. For example, the request-response MEP is natively implemented by the HTTP protocol binding; but it might also be implemented via a "correlation" header block, which "converts" a one-way protocol binding (like for example a TCP binding) into a request-response protocol binding.
Features are useful for providing an application with a degree of independence from the local or the remote SOAP protocol environments. Consider for example a secure financial application which interacts with a remote Web service via SOAP. In a typical environment today, the application has to specify the exact protocol and security mechanism to be used. In a feature-based environment, the application simply indicates its security constraints -the name of the (abstract) security feature to be engaged-, and the underlying machinery automatically determines and engages the protocol or header block that provides the desired level of security (the determination might involve querying the ultimate receiver for the list of features it supports). In such an environment, protocol bindings are pluggable, self-describing "modules". On request, they provide the list of features they support.
The Web Service Description Language (WSDL) is a language for describing Web services in general and SOAP services in particular.
A WSDL document is an XML document that describes a particular Web service. It is divided into two main parts: an abstract part and a concrete part. The abstract part describes the service abstractly, independently of the protocol and serialization format used to implement the service. The concrete part describes how the service is actually delivered, using a particular protocol and serialization method.
The abstract part of a WSDL document is made of four main components.
A message component lists the elementary messages and their types. The following example describes a message to request a quantity in stock for a given product. The product is identified by its part number.
<message name="getQuantityInStockRequest">
<part name="PartNumber" />
</message>
An operation component combines elementary messages into a logical operation. A logical operation can be thought of as an elementary Web service. The following example describes an operation to obtain a quantity in stock. The operation combines two elementary messages, one to request the quantity in stock, the other to return the answer:
<operation name="getQuantityInStock">
<input message="getQuantityInStockRequest"/>
<output message="getQuantityInStockResponse"/>
</operation>
The concrete part of a WSDL document is made of two main components: a binding component and a service component.
A binding component indicates how messages are actually serialized and what transport protocol is used. For example, the following binding indicates that the service is accessible via SOAP and that part numbers are serialized as SOAP body blocks.
A WSDL binding should not be confused with a SOAP protocol binding.
<binding name="stockMgtSoap" type="stockMgt">
<soap:binding uri="http://www.w3.org/2003/soap/bindings/HTTP/"/>
<operation name="getQuantityInStock">
<input>
<soap:body part="PartNumber"/>
</input>
<output>
<soap:body part="PartNumber"/>
<soap:body part="QuantityActuallyInStock"/>
</output>
</operation>
</binding>
WSDL 1.1 supports SOAP 1.1, not SOAP 1.2. Consequently, WSDL 1.1 does not support features, only header blocks. WSDL is currently being revised to add such support. The following sub-sections give an indication of the progress made to date.
The final WSDL 1.2 specification may differ significantly from the material presented here.
Features have been promoted to first class citizens in WSDL 1.2. New syntax allows a service to describe the features it supports. Features have also been generalized and made available to any Web service, not just a SOAP Web service.
A feature is described via its name (a URI). The "required" attribute indicates whether the feature's use is mandatory or not. Marking a feature "required" indicates that the service provider does support the feature and that the client is required to use it. The following example describes a mandatory correlation feature:
<feature uri="http://example.org/feature/correlation" required="true"/>
Features can appear either at the abstract level or at the concrete level.
At the abstract level, features can be global to an interface or specific to a given operation. In the first case, all operations in the interface support the feature. In the second case, only this operation supports the feature.
At the concrete level, features can be global to a binding or specific to a given operation. In the first case, the feature applies to all operations in the binding. In the second case, the feature applies to this operation only.
Features that appear at the abstract level apply to all bindings that "implement" the interface. Features that appear at the concrete level apply only to a specific binding. For example, a correlation feature listed in an interface A applies both to the TCP and SOAP bindings that implement the interface. The same feature listed in the SOAP binding only applies to this binding only.
Properties are represented like features. A property can appear either at the abstract level or at the concrete level. At the abstract level, a property can be global to an interface or specific to a particular operation. At the concrete level, a property can be global to a binding or specific to a specific operation in the binding. So, a property will either be available for all operations and all bindings, for all bindings but only for a particular operation, for all operations but only one binding, or for a single operation within a single binding.
Properties are described by their name (a URI). A property description contains either a specific value or a restriction on possible values. A specific value indicates that the service requires the value to be that listed, for proper operation. In the following example, the traffic light "colour" property must be used at run-time with a value of green:
<property name="http://example.org/feature/trafficLight/colour">
<value>green</value>
</property>
Unlike a value, a property constraint does not indicate a specific value but the range of possible values. In the following example, the traffic light "colour" property accepts only green and red values. (It is assumed that the specification for the corresponding feature also allowed orange.)
<property
name=http://example.org/feature/trafficLight/colour
constraint="RedAndGreen"/>
where "RedAndGreen" is defined as:
<xs:simpleType name="RedAndGreen">
<xs:restriction base="xs:string">
<xs:enumeration value="red"/>
<xs:enumeration value="green"/>
</xs:restriction>
</xs:simpleType>
WSDL 1.1 had hardwired support for MEPs. Only four types of MEPs were supported: input-output, output-input, input only and output only. These MEPs correspond roughly to the following traditional interaction patterns: request-response, publish-subscribe, one-way and event. WSDL is currently being revised to support additional MEPs.
WSDL MEPs are called patterns, not MEPs, essentially for differentiation with SOAP MEPs. WSDL patterns define the sequence, direction, and cardinality of abstract messages sent or received by an operation. They abstract out information like the particular type of message sent or received, the timing between messages, whether the pattern is synchronous or asynchronous, and whether messages are sent over a single or multiple channels. WSDL patterns can be seen as abstracted SOAP MEPs.
Patterns are named with a URI. Each operation specifies the pattern used via the "pattern" attribute. The following example describes an operation to obtain a quantity in stock. The operation uses the pattern in-out, which is analogous to the traditional request-response pattern (see next section).
<operation
name="getQuantityInStock"
pattern="http://www.w3.org/2003/wsdl/pattern/in-out">
<input message="getQuantityInStockRequest"/>
<output message="getQuantityInStockResponse"/>
</operation>
The following eight patterns are currently under consideration for inclusion in WSDL 1.2: in-only, in-out, request-response, in-multi-out, out-only, out-in, out-multi-in and multicast-solicit-response.
The in-only pattern consists in a single input message.
The in-out pattern consists in an input message followed by an output message.
The request-response pattern is identical to the in-out pattern, with the exception that the input and output messages travel on the same channel.
The in-multi-out pattern consists in an input message followed by one or more output messages.
The out-only pattern consists in a single output message.
The out-in pattern consists in an output message followed by an input message.
The out-multi-in pattern consists in an output message followed by multiple input messages.
The multicast-solicit-response pattern consists in an output message followed by one or two input messages.
As can be seen from the list above, WSDL 1.2 has built-in support for patterns that involve at most two nodes. However, the definition of the "pattern" attribute does not restrict the type of pattern that can be used. Hence, the "pattern" attribute can reference, for example, a pattern that involve four nodes.
Extensibility in SOAP 1.2 is achieved via features. A feature is an abstract piece of functionality that represents some processing to be performed. A feature has a name and a set of properties. Features are made concrete -implemented- via header blocks or protocol bindings. MEPs are a special type of feature that describes a particular interaction pattern between SOAP nodes.
WSDL 1.2 has been extended to support the concept of feature. Features appear at the interface level or at the binding level. Features indicate the functionality which must be engaged for a particular operation. The "pattern" attribute is used to indicate the type of message interaction implemented by an operation. WSDL 1.2 currently defines eight patterns. Other patterns can be referenced via the "pattern" attribute.
[SOAP12 Part1] W3C Proposed Recommendation "SOAP Version 1.2 Part 1: Messaging Framework", Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau, Henrik Frystyk Nielsen, http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part1.html
[SOAP12 Part2] W3C Proposed Recommendation "SOAP Version 1.2 Part 2: Adjuncts", Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau, Henrik Frystyk Nielsen, http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part2.html
[WSDL12 Part1] W3C Editor Copy "Web Services Description Language (WSDL) Version 1.2", R. Chinnici, M. Gudgin, J-J. Moreau, S. Weerawarana, Editors. World Wide Web Consortium, http://www.w3.org/2002/ws/desc/wsdl12
[WSDL12 Part2] W3C Editor Copy "Web Services Description Language (WSDL) Version 1.2: Patterns", M. Gudgin, A. Lewis, J. Schlimmer, Editors. World Wide Web Consortium, http://www.w3.org/2002/ws/desc/wsdl12-patterns
[WSDL12 Part3] W3C Editor Copy "Web Services Description Language (WSDL) Version 1.2: Bindings", J-J. Moreau, J. Schlimmer, Editors. World Wide Web Consortium, http://www.w3.org/2002/ws/desc/wsdl12-bindings
[XML 1.0] W3C Recommendation "Extensible Markup Language (XML) 1.0 (Second Edition)", Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 6 October 2000, http://www.w3.org/TR/2000/REC-xml-20001006
[Namespaces in XML] W3C Recommendation "Namespaces in XML", Tim Bray, Dave Hollander, Andrew Layman, 14 January 1999, http://www.w3.org/TR/1999/REC-xml-names-19990114/
[XML InfoSet] W3C Recommendation "XML Information Set", John Cowan, Richard Tobin, 24 October 2001, http://www.w3.org/TR/2001/REC-xml-infoset-20011024/
[XML Schema Part1] W3C Recommendation "XML Schema Part 1: Structures", Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 2 May 2001, http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
[RFC 2396] IETF "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter, August 1998, http://www.ietf.org/rfc/rfc2396.txt
  |
Design & Development by deepX Ltd. |