WS-â€Addressing - ServiceTechnologies

WS-‐Addressing

1

Thursday, March 22, 12

What is WS-Addressing?

• SOAP does not provide a standard way to specify

– Where a message is targeted (destination)

– How to return a response

– Where to report an error

• Those details are left up to the transport layer

– When a standard SOAP request is sent over HTTP, the URI of the HTTP request serves as the message's destination

– The message response is packaged in the HTTP response and received by the client over the HTTP connection

2


Classical SOAP

• SOAP Messages depend on the transport protocol

POST /InStock HTTP/1.1Host: www.stock.orgContent-Type: application/soap+xml charset=utf-8Content-Length: nnnSOAPAction: "www.stock.org/GetStockPrice"

<?xml version="1.0"?><soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body xmlns:m="http://www.stock.org/stock"> <m:GetStockPrice> <m:StockName>PoliMi</m:StockName> </m:GetStockPrice> </soap:Body></soap:Envelope>

The type

Host URI

SOAP

3


Interoperable Constructs

• WS-Addressing defines two interoperable constructs

– usually given by transport protocols and messaging systems

– they normalize the information to a common format

– processable independently of transport or application

• Endpoint:

– referenceable entity, processor or resource

– Web service messages can be target to an endpoint

• Messaging Information Headers:

– allow us to use endpoints for addressing individual messages

– more complex protocols

4


WS-Addressing

• WS-Addressing Core

– Endpoint Reference

– Message addressing properties

• WS-Addressing SOAP Binding

– How to use WS-Addressing with SOAP

• WS-Addressing WSDL Binding

– How to use WS-Addressing with WSDL

5


Endpoint References

• Aim is to extend Web Services to support

– Dynamic generation and customization of endpoint descriptions

– Identification and description of specific service instances that are created during stateful interactions

– Flexible and dynamic exchange of endpoint information in tightly coupled environments where policies are the same

– Enable a wider range of transport protocols (with respect to WSDL 1.1)

– Easier and more flexible asynchronous communication

• The extension is to the WSDL description model

– Endpoints are used instead of the contents of <service>

6


Endpoints

<wsa:EndpointReference> <wsa:Address>...</wsa:Address><wsa:ReferenceProperties>...</wsa:ReferenceProperties><wsa:ReferenceParameters>...</wsa:ReferenceParameters><wsa:PortType>...</wsa:PortType><wsa:ServiceName PortName=”...”>...</wsa:ServiceName><wsa:Policy>...</wsa:Policy>

</wsa:EndpointReference>

7


Defining endpoints

• Address (mandatory)

– URI identifying the endpoint

– network address or logical address

• ReferenceProperties

– properties required to identify the entity

• ReferenceParameters

– parameters used to facilitate an interaction

• PortType

– QName of the primary portType being conveyed

• ServiceName

– identifies the WSDL service element that contains the endpoint being conveyed

• Policy

– described in WS-Policy

8


Binding Endpoint References

• When addressing a message

– the information is mapped to the message

– the mapping depends on the protocol and data representation being used

• The standard defines a mapping for SOAP messages

– address: copied in the destination header field of the SOAP message

– reference property: becomes a header block in the SOAP message

– reference parameters: becomes a header block in the SOAP message

9


Endpoint Example

<wsa: EndpointReference xmlns:”...” xmlns:fabrikam=”...”> <wsa:Address>http://fabrikam.com/acct</wsa:Address> <wsa:ReferenceProperties> <fabrikam:CustomerKey>123456789</fabrikam:CustomerKey> </wsa:ReferenceProperties> <wsa:ReferenceParameters> <fabrikam:ShoppingCart>ABCDEFG</fabrikam:ShoppingCart> </wsa:ReferenceParameters></wsa:EndpointReference>

10


11

<soap:Envelope xmlns:S=http://www.w3.org/2003/05/soap-envelope” xmlns:wsa”...” xmlns:fabirkam>=”...”>

<soap:Header> <wsa:To>http://fabrikam.com/acct</wsa:To> <fabrikam:CustomerKey>123456789</fabrikam:CustomerKey> <fabrikam:ShoppingCart>ABCDEFG</fabrikam:ShoppingCart> </soap:Header>

<soap:Body> ... </soap:Body>

</soap:Envelope>

SOAP Example


Comparing Endpoints

• During the interactions we can

– receive multiple endpoint references

– receive different copies for the same endpoint reference

• Rule

– two endpoints that accept the same messages, and follow the same policies (XML Schemas, WSDL, and WSPolicy) are the same

– reference properties are equal if

• they contain the same number of individual properties

• for each reference property in one endpoint there exists an equivalent reference property in the other

– they are equivalent if their byte streams are equal

12


Message Information Headers

• Augment a message with abstract properties for

– the identification and location of the endpoints involved in an interaction

– the basic interaction is “one-way”

– we will also look at “request-reply”

• replies are regular messages or faults

13

<wsa:MessageID>...</wsa:MessageID>

<wsa:RelatesTo>...</wsa:RelatesTo>

<wsa:To>...</wsa:To>

<wsa:Action>...</wsa:Action>

<wsa:From>...<wsa:From>

<wsa:ReplyTo>...</wsa:ReplyTo>

<wsa:Fault>...</wsa:Fault>


Defining the Headers• Destination (mandatory)

– URI

• Source endpoint

– EPR that originated the message

• Reply endpoint

– EPR that identifies the intended receiver

• Fault endpoint

– EPR that identifies the intended receiver of faults

• Action (mandatory)

– URI that identifies the semantics of the message

– input, output, fault message from a WSDL portType

• Message ID

– URI that identifies the message in time and space

• Relationship

– QName, URI that identify how the message relates to another message

– QName is the type, URI is the other message

– Only one predefined type - wsa:Reply14


Message Dispatching

• Dispatching is based on two properties:

– mandatory destination

– mandatory action

• Due to NAT, DHCP, etc. sometimes it is impossible to use global URIs

– Use of “Anonymous” endpoints

– http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous

• The use of the anonymous endpoint requires out-of-band mechanism for delivering replies/faults

– same transport connection - HTTP GET/POST

15


Simplest use of Addressing

<?xml version="1.0"?><soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding" xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing">

<soap:Header> <wsa:To>http://www.stock.org/InStock</wsa:To> <wsa:Action>http://www.stock.org/GetStockPrice</wsa:Action> </soap:Header> <soap:Body xmlns:m="http://www.stock.org/stock"> <m:GetStockPrice> <m:StockName>IBM</m:StockName> </m:GetStockPrice> </soap:Body></soap:Envelope>

16


Formulating a Response

• Reply to a WS-Addressing compliant request must be WS-Addressing compliant

• Request

17

<S:Envelope xmlns= ... > <S:Header> <wsa:MessageID>uuid:aaaabbbb-cccc-dddd-eeee-ffffffffffff</wsa:MessageID> <wsa:ReplyTo> <wsa:Address>http://business456.example/client1</wsa:Address> </wsa:ReplyTo> <wsa:To>mailto:[email protected]</wsa:To> <wsa:Action>http://fabrikam123.example/mail/Delete</wsa:Action> </S:Header> <S:Body> <f123:Delete> <maxCount>42</maxCount> </f123:Delete> </S:Body></S:Envelope>


Formulating a Response

• Response

18

<S:Envelope xmlns= ...> <S:Header> <wsa:MessageID>uuid:aaaabbbb-cccc-dddd-eeee-wwwwwwwwwww</wsa:MessageID> <wsa:ReplyTo>uuid:aaaabbbb-cccc-dddd-eeee-ffffffffffff</wsa:ReplyTo> <wsa:To>http://business456.example/client1</wsa:To> <wsa:Action>http://fabrikam123.example/mail/DeleteAck</wsa:Action> </S:Header> <S:Body> <f123:DeleteAck/> </S:Body></S:Envelope>


Associating actions to WSDL

• Two mechanisms are provided

– Explicit association

19

<definitions targetNamespace="http://example.com/stockquote" ...> ... <portType name="StockQuotePortType"> <operation name="GetLastTradePrice"> <input message="tns:GetTradePricesInput" wsa:Action="http://example.com/GetQuote"/> <output message="tns:GetTradePricesOutput" wsa:Action="http://example.com/Quote"/> </operation> </portType> ...</definitions>



• Two mechanisms are provided

– Default association (for when an explicit one is absent)

• [target namespace]/[port type name]/[input|output name]

– For fault messages we use the default URI

• http://schemas.xmlsoap.org/ws/2004/08/addressing/fault

20

<definitions targetNamespace="http://example.com/stockquote" ...> <portType name="StockQuotePortType"> <operation name="GetLastTradePrice"> <input message="tns:GetTradePricesInput" name="GetQuote"/> <output message="tns:GetTradePricesOutput" name="Quote"/> </operation> </portType></definitions>

input action = http://example.com/stockquote/StockQuotePortType/GetQuote

output action = http://example.com/stockquote/StockQuotePortType/Quote



• If the name attribute is missing

– input of a request response operation: name of the operation + "Request" appended

– output of a request response operation: name of operation + “Response” appended

21

<definitions targetNamespace="http://example.com/stockquote" ...> <portType name="StockQuotePortType"> <operation name="GetLastTradePrice"> <input message="tns:GetTradePricesInput"/> <output message="tns:GetTradePricesOutput"/> </operation> </portType></definitions>

input action = http://example.com/stockquote/StockQuotePortType/GetLastTradePriceRequest

output action = http://example.com/stockquote/StockQuotePortType/GetLastTradePriceResponse


Managing faults

• Faults are sent to:

– the fault EPR if it is present

– the reply to EPR if the fault EPR is not present

– the source EPR if neither of the above are present

• Fault messages are correlated as “replies” using the relationship property

• Fault messages have a default action property

– http://schemas.xmlsoap.org/ws/2004/08/addressing/fault

• Faults are defined through

– code

– subcode

– reason expressed in natural language

– detail

22


Types of Faults

• Invalid message information header (cannot be processed)

– code: S:Sender

– subcode: wsa:InvalidMessageInformationHeader

– reason: structural or semantic

• [destination] that is not a URI

• [relationship] to a [message id] that was never issued

– detail: invalid header

• Message information header required

– code: S:Sender

– subcode: wsa:MessageInformationHeaderRequired

– reason: A required message information header, To, MessageID, or Action, is not present

– detail: missing header QName

23


Types of Faults

• Destination Unreachable

– code: S:Sender

– subcode: wsa:DestinationUnreachable

– reason: No route can be determined

– detail: empty

• Action Not Supported

– code: S:Sender

– subcode: wsa:ActionNotSupported

– reason: The action cannot be processed at the receiver

– detail: action

24


Types of Faults

• Endpoint Unavailable

– Endpoint cannot process message due to transient or permanent failure

– code: S:Receiver

– subcode: wsa:EndpointUnavailable

– reason: message cannot be processed at this time

– detail: <wsa:RetryAfter ...>[xs:NonNegativeInteger]</wsa:RetryAfter>

25


Date post:	09-Feb-2022
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

WS-â€Addressing - ServiceTechnologies

Documents