WS-Addressing Enabling Transport-Neutral Message Addressing and Correlation Jeffrey Hasan, MCSD President Bluestone Partners, Inc.

Talk Agenda What Is “Transport-Neutral”? WSDL and Addressing WS-Addressing Constructs Message Information Headers Endpoint References WSE 2.0 Addressing Namespace WSE 2.0 Messaging Namespace Addressing and Messaging Demos Using HTTP and TCP

What Is “Transport-Neutral”?

WSDL and Addressing

WS-Addressing Constructs

Message Information Headers

Endpoint References

WSE 2.0 Addressing Namespace

WSE 2.0 Messaging Namespace

Addressing and Messaging Demos

Using HTTP and TCP

About Me Jeffrey Hasan [email_address] President, Bluestone Partners Inc. An IT consulting company based in Orange County. We build business applications using .NET. Our speciality is SOA. Author of: Expert Service-Oriented Architecture in C#: Using the Web Services Enhancements 2.0 (APress, 2004) Performance Tuning and Optimizing ASP.NET Applications, APress, 2003. ISBN: 1590590724. ADO.NET Programmer’s Reference, Wrox Press, 2001. Professional .NET Framework, Wrox Press, 2001. Professional VB6 Web Programming, Wrox Press, 1999. Articles for MSDN Magazine and asp.NET Pro Magazine .

Jeffrey Hasan

[email_address]

President, Bluestone Partners Inc.

An IT consulting company based in Orange County. We build business applications using .NET. Our speciality is SOA.

Author of:

Expert Service-Oriented Architecture in C#: Using the Web Services Enhancements 2.0 (APress, 2004)

Performance Tuning and Optimizing ASP.NET Applications, APress, 2003. ISBN: 1590590724.

ADO.NET Programmer’s Reference, Wrox Press, 2001.

Professional .NET Framework, Wrox Press, 2001.

Professional VB6 Web Programming, Wrox Press, 1999.

Articles for MSDN Magazine and asp.NET Pro Magazine .

New SOA / WSE 2.0 Book Expert Service Oriented Architecture in C# Using the Web Services Enhancements 2.0 Published by: APress (August 2004) ISBN: 1590593901 http://www.bluestonepartners.com/soa

Expert Service Oriented Architecture in C#

Using the Web Services Enhancements 2.0

Published by: APress (August 2004)

ISBN: 1590593901

http://www.bluestonepartners.com/soa

What Is “Transport-Neutral?” Traditional Web services communicate over the HTTP protocol and use a traditional request/response communication pattern, in which a client request results in a synchronous, direct service response. This model is very limiting because it does not accommodate long-running service calls that may take minutes, hours, or days to complete. Alternate transport protocols such as TCP are not limited to the request/response communication pattern. SOAP messages must be able to travel over different transport protocols besides HTTP. WSE 2.0 provides support for alternate transport protocols. WS-Addressing applies regardless of the transport protocol.

Traditional Web services communicate over the HTTP protocol and use a traditional request/response communication pattern, in which a client request results in a synchronous, direct service response.

This model is very limiting because it does not accommodate long-running service calls that may take minutes, hours, or days to complete.

Alternate transport protocols such as TCP are not limited to the request/response communication pattern.

SOAP messages must be able to travel over different transport protocols besides HTTP.

WSE 2.0 provides support for alternate transport protocols.

WS-Addressing applies regardless of the transport protocol.

HTTP vs TCP Transport Protocols Here is an example of an HTTP endpoint: http://www.bluestonepartners.com/StockTrader.asmx And here is an example of the equivalent TCP endpoint: soap.tcp://216.70.214.118/StockTrader The HTTP and TCP protocols have one thing in common, which is that they both enable messaging between remote components that are running on separate processes, and on separate domains. TCP is a lower-level protocol that operates on a port rather than a virtual directory, which is a higher-level abstraction of a port. TCP supports several communication models.

Here is an example of an HTTP endpoint:

http://www.bluestonepartners.com/StockTrader.asmx

And here is an example of the equivalent TCP endpoint:

soap.tcp://216.70.214.118/StockTrader

The HTTP and TCP protocols have one thing in common, which is that they both enable messaging between remote components that are running on separate processes, and on separate domains.

TCP is a lower-level protocol that operates on a port rather than a virtual directory, which is a higher-level abstraction of a port.

TCP supports several communication models.

WSDL Overview Web Services Description Language WS-I Basic Profile (WSDL 1.1) WSDL documents: Operations that the WS supports Messages that the WS exchanges Data types that these messages use both intrinsic and custom Everything is qualified Can be generated from VS .NET

Web Services Description Language

WS-I Basic Profile (WSDL 1.1)

WSDL documents:

Operations that the WS supports

Messages that the WS exchanges

Data types that these messages use

both intrinsic and custom

Everything is qualified

Can be generated from VS .NET

WSDL Elements A WSDL Document contains seven primary XML elements (+ the root <xml> element) Abstract description XML elements that document the Web service interface, including the methods that it supports, the input parameters, and the return types Concrete implementation XML elements that show the client how to physically bind to the Web service and to use its supported operations

A WSDL Document contains seven primary XML elements (+ the root <xml> element)

Abstract description

XML elements that document the Web service interface, including the methods that it supports, the input parameters, and the return types

Concrete implementation

XML elements that show the client how to physically bind to the Web service and to use its supported operations

WSDL Abstract Elements <types /> Equivalent to an XSD schema file <message /> describes a SOAP message, which may be an input, output or fault message for a Web service operation <operation /> Analogous to method definitions; groups associated messages into operations Indicates direction (one-way; notification; request/response) <portType /> Abstract definition of a Web service; provided as a summary of operations

<types />

Equivalent to an XSD schema file

<message />

describes a SOAP message, which may be an input, output or fault message for a Web service operation

<operation />

Analogous to method definitions; groups associated messages into operations

Indicates direction (one-way; notification; request/response)

<portType />

Abstract definition of a Web service; provided as a summary of operations

WSDL Concrete Elements <binding /> Links an abstract Web service definition to an actual Web service, by associating the operation/message definitions to an XML namespace <port /> Documents the physical location (URI) of the Web service Contains a <binding /> element <service /> Encloses one or more <port /> elements Provides a unified service definition of the abstract and concrete service elements

<binding />

Links an abstract Web service definition to an actual Web service, by associating the operation/message definitions to an XML namespace

<port />

Documents the physical location (URI) of the Web service

Contains a <binding /> element

<service />

Encloses one or more <port /> elements

Provides a unified service definition of the abstract and concrete service elements

<portType /> The <portType> element lists all of the operations that a Web service supports. The <portType> element avoids low-level details, such as SOAP message details and binding information. <portType name=&quot;StockTraderServiceSoap&quot;> <operation name=&quot;RequestQuote&quot;> <input message=&quot;tns:RequestQuoteSoapIn&quot; /> <output message=&quot;tns:RequestQuoteSoapOut&quot; /> <fault message=&quot; tns:ExceptionMessage&quot; /> </operation> <operation name=&quot;PlaceTrade&quot;> <input message=&quot;tns:PlaceTradeSoapIn&quot; /> <output message=&quot;tns:PlaceTradeSoapOut&quot; /> </operation> </portType>

The <portType> element lists all of the operations that a Web service supports.

The <portType> element avoids low-level details, such as SOAP message details and binding information.

WS-Addressing Constructs Message information Headers “… convey end-to-end message characteristics including addressing for source and destination endpoints as well as message identity. “ Endpoint References “… a (referenceable) entity, processor, or resource where Web service messages can be targeted. “ Definitions are from the Web Services Addressing (WS-Addressing) Specification, August 10, 2004

Message information Headers

“… convey end-to-end message characteristics including addressing for source and destination endpoints as well as message identity. “

Endpoint References

“… a (referenceable) entity, processor, or resource where Web service messages can be targeted. “

Definitions are from the Web Services Addressing (WS-Addressing) Specification, August 10, 2004

Message Information Headers (001) <S:Envelope xmlns:S=&quot;http://www.w3.org/2003/05/soap-envelope&quot; xmlns:wsa=&quot;http://schemas.xmlsoap.org/ws/2004/08/addressing&quot;> (002) <S:Header> (003) <wsa:MessageID> (004) uuid:6B29FC40-CA47-1067-B31D-00DD010662DA (005) </wsa:MessageID> (006) <wsa:ReplyTo> (007) <wsa:Address>http://business456.example/client1</wsa:Address> (008) </wsa:ReplyTo> (009) <wsa:To>http://fabrikam123.example/Purchasing</wsa:To> (010) <wsa:Action>http://fabrikam123.example/SubmitPO</wsa:Action> (011) </S:Header> (012) <S:Body> (013) ... (014) </S:Body> (015) </S:Envelope> <wsa:To> and <wsa:Action> are the only required elements

Endpoint References I Schema: <wsa:EndpointReference> <wsa:Address>xs:anyURI</wsa:Address> <wsa:ReferenceProperties>... </wsa:ReferenceProperties> ? <wsa:ReferenceParameters>... </wsa:ReferenceParameters> ? <wsa:PortType>xs:QName</wsa:PortType> ? <wsa:ServiceName PortName=&quot;xs:NCName&quot;?>xs:QName</wsa:ServiceName> ? <wsp:Policy> ... </wsp:Policy>* </wsa:EndpointReference> Example: <wsa:EndpointReference xmlns:wsa=&quot;...&quot; xmlns:fabrikam=&quot;...&quot;> <wsa:Address>http://www.fabrikam123.example/acct</wsa:Address> <wsa:PortType>fabrikam:InventoryPortType</wsa:PortType> </wsa:EndpointReference>

Endpoint References II <wsa:EndpointReference> <wsa:Address>soap.tcp://stocktrader.com/StockTrader</wsa:Address> <wsa:ReferenceProperties> <st:AccountID>123A</st:AccountID> </wsa:ReferenceProperties> <wsa:PortType>st:StockTraderSoap</wsa:PortType> <wsp:Policy /> </wsa:EndpointReference> Endpoint “To” References are mapped into a SOAP message as Message Information Headers: <S:Envelope xmlns:S=&quot;http://www.w3.org/2003/05/soap-envelope&quot; xmlns:wsa=&quot;...&quot; xmlns:st=&quot;... &quot;> <S:Header> ... <wsa:To>soap.tcp://stocktrader.com/StockTrader</wsa:To> <st:AccountID>123A</st:AccountID> </S:Header> <S:Body> ... </S:Body> </S:Envelope>

SOAP Envelope w/ Addressing <s:Envelope xmlns:s=&quot;...&quot; xmlns:wsa=&quot;...“ xmlns:st=“…”> <s:Header> <wsa:Action>http://bluestonepartners.com/StockTrader/RequestQuote</wsa:Action> <wsa:To>http://bluestonepartners.com/StockTrader/StockTrader.asmx</wsa:To> <wsa:From> <wsa:Address>http://stockquote.com/getquote.asmx</wsa:Address> <wsa:ReferenceProperties> <st:id>647362</st:id> <st:symbol>MSFT</st:symbol> </wsa:ReferenceProperties> </wsa:From> <wsa:FaultTo> <wsa:Address>http://stockquote.com/fault/error.asmx</wsa:Address> <wsa:ReferenceProperties> <st:id>647362</st:id> <st:symbol>MSFT</st:symbol> </wsa:ReferenceProperties> </wsa:FaultTo> </s:Header> <s:Body xmlns:st=&quot;http://bluestonepartners.com/StockTrader&quot;> <st:GetQuote>MSFT</st:GetQuote> </s:Body> </s:Envelope>

WSE 2.0: Addressing Namespace Stores the reply to address for the response as an endpoint reference. ReplyTo Stores the destination address as an endpoint reference. From Stores the source address as a URI To Indicates the collection of properties that add additional description elements for an endpoint. ReferenceProperties Stores endpoint reference information, which is binding information for a service. EndPointReference Occurs when there is an invalid WS-Router header in the message, or when an exception occurs along the message path. AddressingFault Indicates the collection of properties that address a message, including To, From, ReplyTo, and MessageID. AddressingHeaders Stores a binding-specific address, and may be assigned to other classes, including To, From, and ReplyTo. The properties of the Address class correspond to classes that are based on endpoint references. For example, the Address.To property corresponds to the WS-Addressing To class, which is an endpoint reference. Address Specifies the XML qualified name of the operation that the SOAP message is intended for. Action Description Class

Addressing Namespace Usage You will not often need to instance these classes directly. Instead, it is more likely that you will access them via properties on other classes. For example, the SoapEnvelope class (in Microsoft.Web.Services2) provides a Context.Addressing property that exposes the AddressingHeaders class. Here, you can directly set message addressing information, such as From, To, ReplyTo, and Action properties. The Addressing classes are independent of the underlying transport protocol. It does not matter if the addressed SOAP message is transported over HTTP, TCP, or SMTP. The addressing headers and references will apply, regardless of how the message is transported.

You will not often need to instance these classes directly. Instead, it is more likely that you will access them via properties on other classes. For example, the SoapEnvelope class (in Microsoft.Web.Services2) provides a Context.Addressing property that exposes the AddressingHeaders class. Here, you can directly set message addressing information, such as From, To, ReplyTo, and Action properties.

The Addressing classes are independent of the underlying transport protocol. It does not matter if the addressed SOAP message is transported over HTTP, TCP, or SMTP. The addressing headers and references will apply, regardless of how the message is transported.

WSE 2.0: Messaging Namespace The Context property enables you to modify the SOAP message contents within a custom WSE filter; or to process the SOAP message contents within a SoapReceiver processing class. SoapContext Context Retrieves the SOAP fault from the envelope, if there is one, and returns an Exception class. Exception Fault The header contains optional extended information for the SOAP message. The WS-Specification settings are stored in the header. XmlElement Header The body element is required for all SOAP messages. It contains qualified XML for the request and response messages. XmlElement Body The envelope is the root element of the message XML. It contains the message body and message header elements. XmlElement Envelope Description Type Property

WSE 2.0: SoapEnvelope SoapEnvelope message = CreateSoapMessage(); Uri toUri = new Uri( http://bluestonepartners.com/StockTrader.asmx ); SoapSender soapSender = new SoapSender(toUri); soapSender.Send(message); public SoapEnvelope CreateSoapMessage() { SoapEnvelope message = new SoapEnvelope(); RequestQuote q = new RequestQuote(); RequestQuote.Symbol = &quot;MSFT&quot;; message.SetBodyObject(q); // Assign the addressing SOAP message headers message.Context.Addressing.Action = new Action( &quot;http://bluestonepartners.com/schemas/StockTrader/RequestQuote&quot;); message.Context.Addressing.From = new From(fromUri); message.Context.Addressing.ReplyTo = new ReplyTo(fromUri); return message; }

Addressing and Messaging Demos

WS-Routing vs. WS-Addressing Reprinted from “Moving from WS-Routing to WS-Addressing Using WSE 2.0” by Aaron Skonnard, MSDN: Web Services Developer Center

WSDL Overview Web Services Description Language WS-I Basic Profile (WSDL 1.1) WSDL documents: Operations that the WS supports Messages that the WS exchanges Data types that these messages use both intrinsic and custom Everything is qualified Can be generated from VS .NET

Web Services Description Language

WS-I Basic Profile (WSDL 1.1)

WSDL documents:

Operations that the WS supports

Messages that the WS exchanges

Data types that these messages use

both intrinsic and custom

Everything is qualified

Can be generated from VS .NET

WSDL Document Structure

WSE Overview

WSE Specifications

WSE Overview WS-Security : A wide-ranging specification that integrates a set of popular security technologies, including digital signing and encryption based on security tokens, including X.509 certificates. WS-Policy : Allows Web services to document their requirements, preferences and capabilities for a range of factors, though mostly focused on security. For example, a Web service policy will include its security requirements, such as encryption and digital signing based on an X.509 certificate. WS-Addressing : Identifies service endpoints in a message and allows for these endpoints to remain updated as the message is passed along through two or more services. It largely replaces the earlier WS-Routing specification. WS-Messaging : Provides support for alternate transport channel protocols besides HTTP, including TCP. It simplifies the development of messaging applications, including asynchronous applications that communicate using SOAP over HTTP. WS-Secure Conversation : Establishes session-oriented trusted communication sessions using security tokens. WS-Reliable Messaging : Provides mechanisms to help ensure the reliable delivery of messages even when one or more services in the chain are unavailable. This specification includes message delivery notifications so that a sender knows whether a receiver has successfully obtained a sent message.

WS-Security : A wide-ranging specification that integrates a set of popular security technologies, including digital signing and encryption based on security tokens, including X.509 certificates.

WS-Policy : Allows Web services to document their requirements, preferences and capabilities for a range of factors, though mostly focused on security. For example, a Web service policy will include its security requirements, such as encryption and digital signing based on an X.509 certificate.

WS-Addressing : Identifies service endpoints in a message and allows for these endpoints to remain updated as the message is passed along through two or more services. It largely replaces the earlier WS-Routing specification.

WS-Messaging : Provides support for alternate transport channel protocols besides HTTP, including TCP. It simplifies the development of messaging applications, including asynchronous applications that communicate using SOAP over HTTP.

WS-Secure Conversation : Establishes session-oriented trusted communication sessions using security tokens.

WS-Reliable Messaging : Provides mechanisms to help ensure the reliable delivery of messages even when one or more services in the chain are unavailable. This specification includes message delivery notifications so that a sender knows whether a receiver has successfully obtained a sent message.