Web services scenario: Cross supplier inquiry
This document describes a scenario in which an online garden supply retailer uses Web services to integrate its inventory system with the inventory systems of other retailers. Also using Web services, the main Internet storefront can check supplier inventories on behalf of itself or other retailers.
The marketers at Plants by WebSphere confirm with market data that people are likely to purchase plants and gardening supplies in tandem with purchases of other goods, such as gardening books. To increase the visibility of Plants by WebSphere, the company arranges with various other merchant sites to include Plants by WebSphere inventory as part of their own.
At one site, Web services and other technologies are used to insert data about Plants by WebSphere items into Web pages that match the look and feel of the rest of the site. When a customer orders a Plants by WebSphere item at a site other than Plants by WebSphere, the second site relies on the Plants by WebSphere inventory Web service to make sure that the item is in stock, and to query suppliers as needed.
The second site does not have to implement its own Web services to perform the same function as those developed by Plants by WebSphere. The second site might want to implement sophisticated function by creating its own Web service.
How out of stock items are handled
The following events happen when a customer orders an item from one of the sites that re-sells items from Plants by WebSphere.
- In advance, Plants by WebSphere publishes its Web service to a public UDDI registry.
In this way, other retailers are made aware of the inventory Web service available from Plants by WebSphere. In this scenario, Plants by WebSphere probably will enable the Web service to check its own inventory as well as that of suppliers.
- The re-seller checks the Plants by WebSphere inventory.
The application powering the Web site checks the Plants by WebSphere inventory database. It discovers that the item is not in stock.
- The re-seller consults the UDDI registry for suppliers whose inventories it can check.
- The re-seller uses the Web services to check the supplier inventories.
The application invokes a Web services for J2EE or JAX-RPC SOAP client that communicates with a SOAP server at the supplier site to ascertain whether the supplier has the item in stock. The supplier data is sent to the reseller.
- The re-seller either obtains the out of stock item, or does not.
- The re-seller notifies its customer of the outcome, as soon as possible.
Web services technologies used in this scenarioThis
scenario uses the following Web services technologies.
- XML (Extensible Markup Language)
- XML is used to standardize the exchange of data between Plants by WebSphere and its supplier.
- WSDL (Web Services Description Language)
- WSDL is used to turn the existing application into a Web service, by acting as the interface between the underlying application and other Web-enabled applications.
- SOAP (Simple Object Access Protocol)
- SOAP is the protocol by which the Web service communicates with the supplier over the Internet.
- A Universal Description, Discovery and Integration (UDDI) registry
By publishing their Web services to UDDI, suppliers make them available for Plants by WebSphere and other retailers to discover and reuse. This saves development time, effort and cost, and helps minimize the need to maintain several different implementations of the same application at Plants by WebSphere and various other retailers who need to contact the suppliers for inventory data.
Public UDDI registries are run by a consortium named UDDI Operators Council, which includes IBM, NTT, SAP, and Microsoft.
Particular editions of WAS provide a private UDDI registry that can be used in an intranet environment.
- Web Services Invocation Framework (WSIF)
In addition to publishing SOAP/HTTP bindings to the public UDDI registry for use by other vendors, Plants by WebSphere might also have published to an internal private UDDI registry with additional optimized bindings. A Web service provider such as Plants by WebSphere might offer a SOAP binding for the service and a local Java binding that allows you to treat the local service implementation (a Java class) as a Web service. If the client is deployed in the same environment as the service, then the local Java binding for the service can be used. This provides more efficient communication with the service by making direct Java calls rather than using the SOAP binding.
- Web services gateway
Plants by WebSphere could use a gateway to handle Web service invocations between Internet and Intranet environments. A Web services gateway makes the internal Web service available externally. It takes care of these considerations:
- The transport mechanisms (or channels) on which messages can be carried to and from the service
- The filters (if any) that act upon these incoming and outgoing messages
- The UDDI registries (if any) to which to publish the service
- The levels of security that you want to apply to the service
See Also
Overview: Online garden retailer Web services scenarios
Web services scenario: Static inquiry on supplier
Web services scenario: Dynamic inquiry on supplier
Related Tasks
Implementing Web services applications
Using the UDDI Registry
Web Services Invocation Framework (WSIF): Enabling Web services
Working with the Web services gateway
Securing Web services for v5.x applications based on WS-Security
Related Information
Samples page on IBM site