WS-Addressing

ebPML.org Carnets de bord
Search for Web ebpml.org	WS-Addressing This new submission to the W3C defines two important concepts of the WS-stack in a transport independent way: endpoint references message header information What is very important to understand is that WSDL and SOAP were never designed to model complex interactions. The limitations include no (standard) ways to: Define a "unit of work" spanning multiple operation invocations (begin / end) Specify the sequence in which operation needs to be invoked Correlate operations invocations as part of a unit of work In other words, WSDL assumes that operations do not participate in any form of session (I don't want to use "stateless"). WS-Addressing initiates a major transformation of the web services landscape with the advent of the "end-point". WSDL let you defines the interface and the classes that implement a particular interface whole an end-point maps to an instance that conform a particular class. As such, end points can be and are generally dynamically created. An end-point is uniquely identified by its "address" and properties. Note that the end-point address may and is generally different from the service port address. Logically, properties should be exclusively used to convey (instance) correlation information, though I am pretty sure they will be abused to convey context as well. In addition to specifying an end-point definition, WS-Addressing specifies also the way end-points are used and mapped within SOAP 1.2. In this section the specification introduces the notion of "Action". Actions are related to operations implicitly (via a pattern including amongst other things operation and input or output names), or explicitly, as a WSDL extension in the port type definition where the action names are added to the operation input and output. The concept of action creates an interesting side effect by diminishing the importance of the message type associated to an input or output. Now that WS-* offer an unambiguous way to specify the intent of a SOAP message, we don't need to rely on the message type to figure it out. I will not be surprised if over time people people keep message types completely open -as it happens today already-, or maybe being a little bit cleaner, if they associate multiple message types to a given operation input or output. WS-Addressing was long overdue as a commonly agreed way of specifying service invocation instances. I will not be surprised if the wide adoption of this specification changes dramatically the way people have been using web services while enabling a new class of applications of web services technologies.

ebPML.org

Carnets de bord

WS-Addressing

This new submission to the W3C defines two important concepts of the WS-stack in a transport independent way:

endpoint references

message header information

What is very important to understand is that WSDL and SOAP were never designed to model complex interactions. The limitations include no (standard) ways to:

Define a "unit of work" spanning multiple operation invocations (begin / end)

Specify the sequence in which operation needs to be invoked

Correlate operations invocations as part of a unit of work

In other words, WSDL assumes that operations do not participate in any form of session (I don't want to use "stateless").

WS-Addressing initiates a major transformation of the web services landscape with the advent of the "end-point". WSDL let you defines the interface and the classes that implement a particular interface whole an end-point maps to an instance that conform a particular class. As such, end points can be and are generally dynamically created.

An end-point is uniquely identified by its "address" and properties. Note that the end-point address may and is generally different from the service port address. Logically, properties should be exclusively used to convey (instance) correlation information, though I am pretty sure they will be abused to convey context as well.

In addition to specifying an end-point definition, WS-Addressing specifies also the way end-points are used and mapped within SOAP 1.2.

In this section the specification introduces the notion of "Action". Actions are related to operations implicitly (via a pattern including amongst other things operation and input or output names), or explicitly, as a WSDL extension in the port type definition where the action names are added to the operation input and output.

The concept of action creates an interesting side effect by diminishing the importance of the message type associated to an input or output. Now that WS-* offer an unambiguous way to specify the intent of a SOAP message, we don't need to rely on the message type to figure it out. I will not be surprised if over time people people keep message types completely open -as it happens today already-, or maybe being a little bit cleaner, if they associate multiple message types to a given operation input or output.

WS-Addressing was long overdue as a commonly agreed way of specifying service invocation instances. I will not be surprised if the wide adoption of this specification changes dramatically the way people have been using web services while enabling a new class of applications of web services technologies.