Web Services Platform Architecture [Electronic resources] : SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More

Steve Mills

نسخه متنی -صفحه : 149/ 127
نمايش فراداده

15.4. Messages and Protocols

This section provides an overview of how the interactions that are carried out in this example and the specific QoS protocols that are required in each case appear on the wire as SOAP messages. First, note that all SOAP messages that are exchanged in this example are encoded according to the document-literal model. Also, in every case, the WS-Addressing specification dictates a certain set of mandatory headers to be used. Each specific QoS protocol that is used requires particular headers to be encoded. Because the basic elements are common in all the messages that are exchanged, we will show one full example and then indicate the modifications introduced in each specific exchange.

The initial interaction between the Web servicesenabled browser at the dealer and the order service at the manufacturer uses digital signatures to protect message integrity. The interaction between the supplier and the manufacturer inventory service, on the other hand, requires that the messages also be encrypted. The request message used in this interaction incorporates both a digital signature and an encryption section in its WS-Security SOAP header. A sample message is shown next. Again, note that we have omitted namespace declarations; we have also removed most of the digital data corresponding to the digital signature and encrypted body for readability.

<S:Envelope>
<S:Header>
<wsa:To>
http://www.car-manufacturer.com/inventory-svc
</wsa:To>
<wsa:Action>
http://www.car-manufacturer.com/svcs/
inventoryPortType/requestInventoryListRequest
</wsa:Action>
<wsa:ReplyTo>
<wsa:Address>     
http://schemas.xmlsoap.org/ws/2004/03/
addressing/role/anonymous
</wsa:Address>
</wsa:ReplyTo>
<wsse:Security>
<wsse:UsernameToken Id="Username">
<wsse:Username>
CN=Joe, OU=ordering-system,O=supplier.com, C=US
</wsse:Username>
</wsse:UsernameToken>
<xenc:EncryptedKey Id="SecretKey">
<xenc:EncryptionMethod Algorithm=
"http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<dsig:KeyInfo>
<wsse:SecurityTokenReference>
<wsse:Reference URI="#Username"/>
</wsse:SecurityTokenReference>
</dsig:KeyInfo>
<xenc:CipherData>          
<xenc:CipherValue>
HGRO3csrbtFLtMP3iC+s0r/...
</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedKey>
<xenc:ReferenceList>
<xenc:DataReference URI="#BodyContent" />
</xenc:ReferenceList>
</wsse:Security>
</S:Header>
<S:Body>
<xenc:EncryptedData Id="BodyContent">
<xenc:EncryptionMethod Algorithm=
"http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
<dsig:KeyInfo>
<wsse:SecurityTokenReference>
<wsse:Reference URI="#SecretKey" />
</wsse:SecurityTokenReference>
</dsig:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>
F0LXfmjBbaiRtn4I86CVMlrXMgm7OwC0Sf...
</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</S:Body>
</S:Envelope>

Observe how the body is encrypted inside an EncryptedData element. Note also the presence of the mandatory WS-Addressing headersTo, Action, and ReplyTo (because this is a request response interaction)and how the anonymous URI is used in the Address field of the ReplyTo header to indicate that the response needs to be sent back synchronously over the open HTTP connection.

The message exchanges inside the supplier's enterprise network are not secured; however, different protocols ensure reliable processing of the order. First, the order message sent by the ordering application to the central warehouse Web service is exchanged using the reliable messaging protocol. A reliable messaging sequence header is used in this case, and the body is not encrypted.

<S:Envelope>
<S:Header>
<wsa:To>
http://www.supplier.com/warehouse/orders-svc
</wsa:To>
<wsa:Action>
http://www.supplier.com/warehouse/svcs/
warehouseOrderingPortType/placeOrderRequest
</wsa:Action>
<wsa:ReplyTo>
<wsa:Address>
http://www.supplier.com/requests/callback
</wsa:Address>
</wsa:ReplyTo>
<rm:Sequence S:mustUnderstand="1">
<util:Identifier>        
http://www.supplier.com.com/warehouse#0936987027956930
</util:Identifier>
<rm:MessageNumber>1</rm:MessageNumber>
</rm:Sequence>
<rm:AckRequested>
<util:Identifier>        
http://www.supplier.com.com/warehouse#0936987027956930
</rm:Identifier>
<rm:MessageNumber>1</rm:MessageNumber>
</rm:AckRequested>
</S:Header>
<S:Body>
<spx:warehouseOrder>
<spx:Date>2005-10-01</spl:Date>
<spx:Originator>
http://www.supplier.com/sales-id=67
</spl:Originator>
<spx:CustomerId>751-CarM</spl:CustomerId>
<spx:ItemNo>72519-GFa</spl:ItemNo>
<spx:Qty>50</spl:Qty>
</spx:warehouseOrder>
</S:Body>
</S:Envelope>

Observe that this ReplyTo address does not contain Chapter 16, "Case Study: Ordering Service Packs."

<S:Envelope>
<S:Header>
<wsa:To>
http://www.supplier.com/warehouse-1/orders-svc
</wsa:To>
<wsa:Action>
http://www.supplier.com/warehouse/svcs/
warehouseOrderingPortType/placeOrderRequest
</wsa:Action>
<wsa:ReplyTo>
<wsa:Address>
http://www.suplier.com/warehouse/callback
</wsa:Address>
</wsa:ReplyTo>
<wsc:CoordinationContext>
<util:Identifier>
http://www.supplier.com/00000000000FF4A64A2CA0902122F00
</util:Identifier>
<wsc:CoordinationType>
http://schemas.xmlsoap.org/ws/2003/09/wsat
</wsc:CoordinationType>
<wsc:RegistrationService>
<wsa:Address>
http://www.supplier.com/warehouse/registrationCoordinator
</wsa:Address>
<wsa:ReferenceProperties>
<spl-tx:TransactionId>         
http://www.supplier.com/00000000000FF4A64A2CA0902122F00
</spl-tx:TransactionId>
</wsa:ReferenceProperties>
</wsc:RegistrationService>
</wsc:CoordinationContext>
</S:Header>
<S:Body>
<spl:warehouseOrder>
<spl:Date>01102005</spl:Date>
<spl:Originator>
http://www.supplier.com/warehouse-central
</spl:Originator>
<spl:CustomerId>751-CarM</spl:CustomerId>
<spl:ItemNo>72519-GFa</spl:ItemNo>
<spl:Qty>25</spl:Qty>
</spl:warehouseOrder>
</S:Body>
</S:Envelope>