The WS-I Sample Application is just that, a sample application. The original idea was to take an application that was grounded in a real world business scenario where messages would be exchanged between business partners. These business partners will have implementations of the various interfaces defined in the scenario, but they could be based on diverse platforms. This illustrates the interoperability between these platforms, and thus also show the value of the WS-I profiles.
The SA group settled on a simple supply chain management scenario which combines both B2C (business to consumer) and B2B (business to business) aspects. The application consists of a retailer who offers goods to its consumers (B2C), and when the inventory in its warehouses drops below a certain predefined threshold, the retailer will replenish its stock by sending a message to one of the manufacturers that is a supplier of that item.
The real world solution to this problem is actually far more complex than the one defined here, with the manufacturer requesting the components parts from its various suppliers, etc. These intricacies are not the focus of the sample application, however, and it is therefore assumed that a certain amount of squinting can take place to overlook some of these aspects. Section 5 of the Supply Chain Management Use Cases document (found here) contains a list of the assumptions that are made to help simplify the scenario.
On the other hand, certain technological intricacies have also been highlighted by the design. Section 3.3.1 of the Sample Architecture Usage Scenarios document describes one of these intricacies, namely that of an asynchronous message transfer via a callback pattern. At the time that the Sample Application was written, the concept of web services was largely limited to synchronous message exchanges. This is often unacceptable for inter-enterprise communication as businesses would need to tie up their precious resources while waiting for another business to fulfill their request. The Sample Application architecture illustrates how asynchronous messaging can be accomplished through the use of two correlated synchronous message exchanges. Now that WS-Addressing coming soon to a store near you, the asynchronous messaging problem should have a standard solution going forward and the next version of the Sample Application architecture (if and when one is produced) should be sure to revise the document in this area to take advantage of that specification.
Now that the caveats have been made and you’re aware that certain business aspects will be ‘squinted’ away and that certain technology inerrancies will be magnified for illustrative purposes, let’s dive a little deeper into the basic use cases of the sample application and the generic architecture that is intended to support them.
Use Cases
A full description of all of the use cases can be found in the Supply Chain Management Use Cases document found here.Purchase Goods: The first and most obvious use case is that of a consumer purchasing a good that the retailer has in stock. The user logs in to the Retail’s web site, selects a few items to order and then attempts to purchase the items and have them shipped to the address of record. The basic success case will occur when the retailer has the items in stock and is able to ship them to the consumer. Errors will occur if the user attempts to order an unknown product or if the warehouse doesn’t have enough in stock to process the order.
It is assumed (through squinting) that the Retailer has 3 warehouses. These warehouses all implement the same web service interface that will check the level of inventory and ship the goods to the user. The retailer can thus fulfill the order using any one of the warehouses. A basic strategy is to use a round robin algorithm, checking one warehouse to see if they are able to ship and if not, moving to the next one. Since the implementation of this interface should result in the same outcome regardless of platform, a retailer application on one platform, say SAP for example, should be able to send the request to warehouse A on a Microsoft platform, warehouse B on an IBM platform, and warehouse C on a BEA platform. Because all implementations conform to the WS-I profiles, this communication should go without a hitch and demonstrate basic interoperability.
Replenish Stock: In this use case the warehouse inventory has dipped below the predefined threshold and it therefore needs to request that the manufacturer produce more of a given item. Since a manufacturing run can take an indeterminate amount of time, this process should be handled asynchronously. The warehouse sends a purchase order to the manufacturer along with an address to which the manufacturer should send the shipping notice once the production run has finished.
In this scenario it is imperative that both sides implement the requisite services correctly to be interoperable. Unlike the simple request/response pattern illustrated in the purchase goods scenario, this scenario requires a specific sequence of message exchanges to be successful. It is not enough that the warehouse service simply request the manufacturer to produce more goods, but the warehouse must have a second service to wait for the advance shipping notice that will be sent by the manufacturer when the production run is complete. Moreover, the correlation between the initial purchase order request and the subsequent ASN needs to occur. The mechanisms through which this was achieved in the sample application architecture were only one possible way to solve the problem at that point in time. Now WS-Addressing has emerged as the standard technology for achieving this kind of interaction.
Configure and run demo: As mentioned at the start of this article, the goal of the WS-I Sample Application is to demonstrate interoperability between the various vendors platform based on the profiles that WS-I produced. It was therefore decided to add a final use case to the mix, whereby a user could configure a demo environment to use any of the vendor’s implementations for any of the services defined in the Sample Application Architecture document.
This adds a bit of a ‘wow’ factor to the Sample Application. One can use it to demonstrate the interoperability of the participant vendors with a few clicks. Simply choose the web service endpoint of a given vendor for one of the services (Warehouse A, Manufacturer C, etc), and then proceed to your shopping cart. By selecting various quantities of various items you will ultimately go down one of the paths defined by the use cases document. All of this will happen transparently, and you will not notice any difference if you switch which vendor’s implementation is running which service.
Hopefully this overview with a few illustrative use cases has given you a better idea of the generic sample application architecture. In the next part of the series I’ll dive one level deeper and discuss how we implemented this generic architecture on SAP’s NetWeaver platform.
