Section 15.4. Messages and Protocols

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 >            <wsse:Username>            CN=Joe, OU=ordering-system,O=supplier.com, C=US            </wsse:Username>         </wsse:UsernameToken>         <xenc:EncryptedKey >            <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 >         <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 the anonymous URI (indicating, for instance, that one must not send the response over the current connection). Because the confirmation message is sent asynchronously, the ReplyTo endpoint reference must contain an actual address to send the response. The use of the reliable messaging protocol results in two additional headers in this message: the mandatory Sequence header identifying this as the first message in the reliable message sequence, and the AckRequested header requesting that an acknowledgement be returned to the originator of the message.

Finally, the orders that the central warehouse sends to the supplier production plants are executed as an atomic transaction, because they involve coordinated updates in the systems at the two plants. The central warehouse application initiates an atomic transaction, and the coordination service at the central warehouse initiates an exchange with the coordinators at the two plant warehouses. A coordination context in the messages exchanged supports the atomic protocol in this case. Following is one sample application message that the warehouse central service sends to the warehouse service in Plant 1, which carries the coordination context header message that the WS-AtomicTransaction protocol uses. A more complete example of the message's exchange in an interaction of this kind is provided in 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>