This chapter discusses a business scenario to illustrate how to apply the various Web services specifications to create effective solutions to real-world problems.
When customers buy hardware, they have the option of selecting additional service packages, called service packs. Service packs are bundled support services, such as on-site repair, hardware warranties, and so on. One can purchase service packs when buying the hardware or later, within certain conditions. The set of service packs that a customer can buy must be validated by the manufacturer to ensure certain criteria are met, including the following:
The service packs are compatible with products that the customer has purchased.
The service packs are consistent with each other. Sometimes interdependencies might exist between service packs.
The service packs selected are available within the country in which the customer is located: Certain service packs are available only in certain countries.
The purchase is within the time period allowed for acquiring additional service packs.
In a large organization consisting of several divisions that offer many hardware products, the systems that perform each of the verifications might be hosted in various locations and operate under different environments.
As it is often the case in intra-enterprise integration scenarios, most of the applications that provide each of the validation steps already exist and have been implemented using various technologies and on different platforms. This situation makes a perfect example for a Web services integration solution. The basic service-oriented architecture approach is to identify the core constituent services and then develop compositions and integrations of those services into additional services and the full solution.
In this case, because each of the steps of the verification and purchase processes is self-contained, typically implemented by separate applications, it is natural to model each one as a service. It is possible to model the actual ordering process as a self-standing service with two main operations: one for validating the service packs that were selected, and a second one to purchase the service pack. Both operations could be implemented as BPEL processes, although this example does not provide a BPEL implementation of the service. The overall architecture of the integrated systems is shown in Figure 16-1.
Each input request might contain multiple orders. The validate operation is a straightforward process that first iterates over the list of ordered items. and, for each item, over the service packs included with the order. For each service pack, a set of tests is executed by invoking the services that the existing applications expose for that purpose. The different tests mentioned in the previous section are sequentially performed for each service pack. As the figure shows, some tests are run against the line item as a whole (validate country and machine model), whereas others are run against individual service packs for each order.
The second operation of this service is a purchase operation that charges the cost of each purchased item (machine plus service packs) to the customer account and updates the customer profile with the purchase, a necessary step to ensure delivery and service and to monitor customer purchasing activity. These two steps are directly related and must be performed atomically as a unit. To do so, the service code starts an atomic transaction before accessing the two backend services; the coordinator of the transaction at the aggregator service interacts with coordinators at each back-end service to ensure the all or none semantics and to roll back completed work as necessary in case of failure.
WS-Security protocols protect the interaction with the client. In the case of the validation operation, messages are signed to ensure integrity; when purchasing the service pack, the messages exchanged are also encrypted. The interaction with back-end services does not require this level of protection because it takes place in a secure environment. The atomic transaction protocol that is specified in WS-AtomicTransactions supports the execution of the purchase operation, as explained previously.
The aggregation service that provides the validation and purchase operations has the following service description. For simplicity and readability, Schema definitions have not been included and namespace declarations have been skipped; as in the previous chapter, the examples are meant to be illustrative rather than executable.
<definitions targetNamespace="...">
<!-- WSDL definitions in this document -->
<!-- referenced using "tns" prefix -->
<types>
<!-- XSD definitions for this service -->
<!-- referenced using "xsd1" prefix -->
<xsd:schema>
<xsd:import
namespace="http://www.purchase.com/xsd/svp-svc">
</xsd:schema>
</types>
<message name="purchaseResponse">
<part name="purchaseResponse"
element="xsd1:PurchaseStatus"/>
</message>
<message name="purchaseRequest">
<part name="purchaseRequest"
element="xsd1:PurchaseRequest"/>
</message>
<message name="ServicePacValidationInput">
<part name="spvDataInput"
element="xsd1:ServicePacValidationData"/>
</message>
<message name="ServicePacValidationOutput">
<part name="spvDataOutput"
element="xsd1:ServicePacValidationData"/>
</message>
<portType name="spvPortType">
<operation name="purchaseServicePacs">
<input name="purchaseInput"
message="tns:purchaseRequest"/>
<output name="purchaseOutput"
message="tns:purchaseResponse"/>
</operation>
<operation name="validateServicePac">
<input name="Input"
message="tns:ServicePacValidationInput"/>
<output name="Output"
message="tns:ServicePacValidationOutput"/>
</operation>
</portType>
name="spvBinding"
type="tns:spvPortType">
<wsp:PolicyReference URI=
"http://www.purchase.com/policies/DSig">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="purchaseServicePacs">
<wsp:PolicyReference URI=
"http://www.purchase.com/policies/Encrypt">
<soap:operation soapAction=
"http://www.purchase.com/spvPortType/purchaseServicePacsRequest"/>
</operation>
<operation name="validateServicePac">
<soap:operation soapAction=
"http://www.purchase.com/spvPortType/validateServicePacRequest"/>
</operation>
</binding>
<service name="spv-svc">
<port name="spv-svc-port" binding="tns:spvBinding">
<soap:address
location="http://www.purchase.com/spv"/>
</port>
</service>
</definitions>
Note that the service binding indicates that all operations that the service offers require messages to be signed; the purchase operation also requires encryption. A policy requiring digital signature of messages is attached to the binding element, and a policy requiring encryption is attached to the purchase operation. As in the previous chapter, this example doesn’t provide explicit policies because policy dialects are still in the process of being developed.
Among the back-end services that are integrated in this example, the focus here is on the services that the purchase operation uses. A simplified definition of the profile update service follows.
<definitions targetNamespace="...">
<!-- WSDL definitions in this document -->
<!-- referenced using "tns" prefix -->
<types>
<!-- XSD definitions for this service -->
<!-- referenced using "xsd1" prefix -->
<xsd:schema>
<xsd:import namespace=
"http://www.purchase.com/xsd/customer-profile"/>
</xsd:schema>
</types>
<message name="addSPVsRqst">
<part name="newSPVs" element="xsd1:newClientSPVs"/>
</message>
<message name="SPVAdditionStatus">
<part name="ret" element="tns:status"/>
</message>
<portType name="SPVProfileUpdatePT">
<operation name="updateProfile">
<input message="tns:addSPVsRqst"/>
<output message="tns:SPVAdditionStatus"/>
</operation>
</portType>
<binding name="ProfileBinding" type="tns:SPVProfileUpdatePT">
<wsp:PolicyReference URI=
"http://purchase.com/policies/ATMandatory">
<soap:binding style="document" transport=
"http://schemas.xmlsoap.org/soap/http"/>
<operation name="updateProfile">
<soap:operation soapAction=
"http://www.purchase.com/SPVProfileUpdatePT/updateProfileRequest"/>
</operation>
</binding>
<service name="spv-customer-profile">
<port name="spv-svc-port" binding="tns:ProfileBinding">
<soap:address
location="http://www.purchase.com/profile"/>
</port>
</service>
</definitions>
In this case, no security policies have been attached based on the fact that the interaction takes place behind the enterprise firewall. However, a policy has been attached to the binding, mandating the use of the atomic transaction protocol. The policy states that a new transaction context must be passed on when the service is invoked. The definition of the purchase service contains a similar binding to support the execution of the application code under an atomic transaction that the invoker service initiates.
<definitions name="Account"
targetNamespace="...">
<!-- WSDL definitions in this document -->
<!-- referenced using "tns" prefix -->
<types>
<!-- XSD definitions for this service -->
<!-- referenced using "xsd1" prefix -->
<xsd:schema>
<xsd:import namespace=
"http://www.purchase.com/xsd/account"/>
</xsd:schema>
</types>
<message name="CreditAccountRequest">
<part name="CreditAccountReq"
element="xsd1:CreditAccountRequest"/>
</message>
<message name="AccountResponse">
<part name="accountResp" element="xsd1:AccountMsg"/>
</message>
<message name="ChargeAccountRequest">
<part name="chargeAccountReq"
element="xsd1:ChargeAccountRequest"/>"
</message>
<message name="InsufficientAccountsFault">
<part name="fault" element="xsd1:AccountFaultInfo"/>
</message>
<portType name="AccountPortType">
<operation name="CreditAccount">
<input name="CreditAccount"
message="tns:CreditAccountRequest"/>
<output name="CreditAccountResponse"
message="tns:AccountResponse"/>
</operation>
<operation name="ChargeAccount">
<input name="ChargeAccount"
message="tns:ChargeAccountRequest"/>
<output name="ChargeAccount"
message="tns:AccountResponse"/>
<fault message="tns:InsufficientAccountsFault"
name="f2"/>
</operation>
</portType>
<binding name="AccountBinding" type="tns:AccountPortType">
<wsp:PolicyReference URI=
"http://purchase.com/policies/ATMandatory">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
</binding>
<service name="accounting">
<port binding="AccountBinding">
<soap:address
location="http://www.purchase.com/account"/>
</port>
</service>
</definitions>
This section concentrates on the messages exchanged as part of the atomic transaction executed by the aggregator service implementation when a customer invokes the purchase operation. This section does not discuss how the security protocols that are used in the interaction with the end user are supported by SOAP headers. Instead, refer to Chapter 15, “Case Study: Car Parts Supply Chain,” where a similar usage of WS-Security is discussed in detail.
As explained previously, the implementation of the purchase operation invokes the “account charge” and the “update customer profile” operations atomically. The aggregation service initiates a new transaction, which results in a series of protocol messages exchanged between the transaction coordinators, in addition to the expected business message exchanges that the WSDL port types describe. Some of the messages received at the account service during this exchange are shown next. The initial invocation of the charge account operation contains a coordination context identifying the transaction and the registration service to use.
<S:Envelope>
<S:Header>
<wsa:To>http://www.purchase.com/account-svc</wsa:To>
<wsa:Action>
http://www.purchase.com/services/AccountPortType/ChargeAccount
</wsa:Action>
<wsa:ReplyTo>
<wsa:Address>
http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous
</wsa:Address>
</wsa:ReplyTo>
<wsa:MessageID>uid:19884704:ff4a653d59:-7fba</wsa:MessageID>
<wsc:CoordinationContext>
<util:Identifier>
http://www.purchase.com/purchase/0000000000000000FF4A64A2CA0902122F00
</util:Identifier>
<wsc:CoordinationType>
http://schemas.xmlsoap.org/ws/2003/09/wsat
</wsc:CoordinationType>
<wsc:RegistrationService>
<wsa:Address>
http://www.purchase.com/purchase/registrationCoordinator
</wsa:Address>
<wsa:ReferenceProperties>
<pch-tx:TransactionId>
http://www.purchase.com/purchase/0000000000000000FF4A64A2CA0902122F00
</pch-tx:TransactionId>
</wsa:ReferenceProperties>
</wsc:RegistrationService>
</wsc:CoordinationContext>
</S:Header>
<S:Body>
<ChargeAccountRequest>
<account>AX2345</account>
<amount>800.0</amount>
</ChargeAccountRequest>
</S:Body>
</S:Envelope>
The coordination context header triggers the registration of the coordinator at the account service with the registration service passed inside the coordination context. The registration service responds with a RegisterResponse protocol message, as follows:
<S:Envelope>
<S:Header>
<wsa:RelatesTo RelationshipType="n1:Reply">
uid:6c154704:ff4a65a8bb:-8000
</wsa:RelatesTo>
<wsa:To>
http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous
</wsa:To>
<wsa:Action>urn:WSCoordination/registrationResponse</wsa:Action>
</S:Header>
<S:Body>
<wsc:RegisterResponse>
<wsc:CoordinatorProtocolService>
<wsa:Address xsi:type="xsd:anyURI">
http://www.purchase.com/purchase/coordinator
</wsa:Address>
<wsa:ReferenceProperties>
<pch-tx:TransactionId>
http://www.purchase.com/purchase/0000000000000000FF4A64A2CA0902122F00
</pch:TransactionId>
<pch-tx:ParticipantId>1</pch:ParticipantId>
</wsa:ReferenceProperties>
</wsc:CoordinatorProtocolService>
</wsc:RegisterResponse>
</S:Body>
</S:Envelope>
If both the account charge and the update profile operations are able to successfully complete their execution, they will return with appropriate application messages to the invoking service, and the coordinator of the transaction will drive it to completion with another set of protocol messages, terminating in a commit message sent to the two participating services. The final example shows a SOAP envelope containing the commit message sent to the account service.
<S:Envelope>
<S:Header>
<wsa:MessageID>uid:19884704:ff4a653d59:-7fb6</wsa:MessageID>
<wsa:To>http://www.purchase.com/purchase/participant</wsa:To>
<wsa:Action>
http://schemas.xmlsoap.org/ws/2003/09/wsat#Commit
</wsa:Action>
<pch-tx:TransactionId>
http://www.purchase.com/0000000000000000FF4A64A2CA0902122F00
</pch-tx:TransactionId>
<pch-tx:ProtocolId>
http://schemas.xmlsoap.org/ws/2003/09/wsat#Durable2PC
</pch-tx:ProtocolId>
</S:Header>
<S:Body>
<wsat:Commit/>
</S:Body>
</S:Envelope>
Service-oriented architecture (SOA) and the stack of Web services protocols provides a component-oriented paradigm for integrating new and existing applications. The impact of Web services in intra-enterprise computing is for that reason as relevant, if not more, as in B2B scenarios. The SOAP messaging protocols provide on the wire interoperability, and WSDL provides standardized representation of service capabilities. Finally, the WS-Transaction, WS-Security, and other QoS specifications support the level of interaction that everyday business interactions require.