Web services scenario: Cross supplier inquiry

 

+

Search Tips   |   Advanced Search

 

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.

  1. In advance, Plants by WebSphere publishes its Web service to a public UDDI registry.

    By publishing the Web service, other retailers are made aware of the inventory Web service available from Plants by WebSphere. In this scenario, Plants by WebSphere enables the Web service to check its own inventory, as well as that of suppliers.

  2. 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.

  3. The re-seller consults the UDDI registry for suppliers whose inventories it can check.

  4. 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.

  5. The re-seller either obtains the out of stock item, or does not.

  6. The re-seller notifies its customer of the outcome, as soon as possible.

 

Web services technologies used in this scenario

This 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

SOAP is the protocol by which the Web service communicates with the supplier over the Internet.

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 or Java class as a Web service. If the client is deployed in the same environment as the service, 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 to apply to the service




 

Related concepts

Overview: Online garden retailer Web services scenarios
Web services scenario: Static inquiry on supplier
Web services scenario: Dynamic inquiry on supplier

 

Related tasks

Task overview: Implementing Web services applications
Use the UDDI registry
Web Services Invocation Framework (WSIF): Enabling Web services
Work with the Web services gateway
Secure Web services for V5.x applications based on WS-Security
Secure Web services applications using JAX-RPC at the message level

 

Related Reference

Specifications and API documentation

 

Related information

Samples page on IBM site