• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
WS-Addressing: Enabling Transport-Neutral Message Addressing and Correlation

WS-Addressing: Enabling Transport-Neutral Message Addressing and Correlation



My presentation discusses the principles of the WS-Addressing specification, which enables Transport-Neutral Message Addressing and Correlation in SOA

My presentation discusses the principles of the WS-Addressing specification, which enables Transport-Neutral Message Addressing and Correlation in SOA



Total Views
Views on SlideShare
Embed Views



2 Embeds 16

http://www.slideshare.net 11
http://www.linkedin.com 5



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    WS-Addressing: Enabling Transport-Neutral Message Addressing and Correlation WS-Addressing: Enabling Transport-Neutral Message Addressing and Correlation Presentation Transcript

    • 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
    • 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 .
    • 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
    • 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.
    • 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://
      • 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
    • 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
    • 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
    • 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
    • <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>
    • 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 (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.
    • 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
    • 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.