Overview: Online garden retailer Web services scenarios



Search Tips   |   Advanced Search


This set of scenarios is inspired by an online retailer called Plants by WebSphere. Plants by WebSphere uses Web services support in WebSphere Application Server to improve communications with its suppliers. The more advanced scenarios describe Web services support available only in particular editions of WAS. Consult your product documentation to confirm what is supported by your edition.

You might recognize Plants by WebSphere as a sample application available in the WebSphere Samples Gallery. These scenarios are loosely related. They describe how the fictional online retailer could use a variety of Web services technologies, some of which are beyond those currently demonstrated by the sample.

Web services are middleware. Using Web services you can connect applications together, no matter how each application is implemented or where it is located. For example, Web services can connect retailers to wholesale suppliers. Middleware is not new. What is new in Web services is that this connectivity is based upon open standards and Web technologies. Web services operate at a level of abstraction that is similar to the Internet, and they can work with any operating system, hardware platform or programming language that can be Web-enabled.

The Plants by WebSphere storefront sells plants and gardening supplies. As customers order merchandise, the site checks the merchandise availability in its inventory database. The scenarios show how the inventory system can grow in stages, using various Web services technologies to improve its capabilities.

At present, these scenarios provide descriptions rather than step by step instructions. To gain experience with Web services coding, see the WebSphere Samples Gallery. It provides detailed instructions for building, configuring, and running the Plants by WebSphere sample application and others.


Before Web services

Suppose that the Plants by WebSphere storefront does not use Web services. The garden retailer has established an impressive Internet storefront enabling customers to shop and order merchandise. To determine whether a customer order can be filled, Webapplications rely on enterprise beans to query the Plants by WebSphere inventory database. If the item is in stock, the site confirms the order to the customer.

If a customer orders an item that is out of stock, the site notifies the customer that the item is out of stock, and encourages the customer to place the item on backorder. Later, long after the customer has left the Plants by WebSphere site, the site administrator or inventory manager might call or fax the supplier to obtain more inventory.


Introducing Web services

Web services could give Plants by WebSphere an automated way to have out of stock items shipped to its warehouse or directly to customers. If suppliers can be contacted quickly enough, Plants by WebSphere does not have to inform its customers that the item was out of stock. Plants by WebSphere could begin to reduce its own inventory if doing so is a desirable business move.

Web services is built on the following core technologies:

The WebSphere product line provides these additional components to help you get the most out of your Web services. The scenarios describe in greater detail how Plants by WebSphere uses each one.

A private Universal Description, Discovery and Integration (UDDI) registry

A private UDDI registry provides a way to publish and discover information about the Web services that are available within your organization. It does the same job for Web services that a business telephone directory does for business addresses and telephone numbers.

If you publish your Web service to UDDI, you make it available for other people to discover and reuse. Reuse of the service saves cost and effort, and publication minimizes the risk of duplicate services being developed

You publish your Web service to UDDI after you have deployed it to the appserver - unless you are also using the Web services gateway, in which case you use the gateway to publish the service to UDDI.

A Web Services Invocation Framework (WSIF)

SOAP bindings for Web services are part of the WSDL specification. So when you think of using a Web service, you probably think of assembling a SOAP message and sending it across the network to the service endpoint, using some SOAP client API. But if you invoke a Web service using WSIF, then a client application can dynamically choose the optimal transport mechanism to use to invoke Web service operations.

For example, a Web service provider 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.

To deploy a Web service as a WSIF-enabled service, you first develop and deploy the Web service, then you develop the WSIF client based on the WSDL document for that Web service - unless you are also using the Web services gateway, in which case the gateway automatically redeploys your Web service as a WSIF-enabled service.

A Web services gateway You use the gateway to handle Web service invocations between Internet and Intranet environments. You use it to make your internal Web services available externally, and to make external Web services available to your internal systems. You also use it to specify...

  • 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 you want the service to be published

  • The levels of security that you want to apply to the service.

When you deploy a Web service to the gateway, the gateway creates a copy of the WSDL file for that service and stores it at a new Web address. Users of the service through the gateway then use the gateway copy of the WSDL file. So (if possible) decide whether or not you want to use the gateway before you make the Web addresses of your deployed services available to others.

WS-Security (Web services security)

Web services security for WAS is based on standards included in the Web services security (WS-Security) specification that address how to provide protection for messages exchanged in a Web service environment. It defines the core facilities for protecting the integrity and confidentiality of a message and provides mechanisms for associating security-related claims with the message. Web services security is a message-level standard based on securing SOAP messages through XML digital signature, confidentiality through XML encryption, and credential propagation through security tokens.




Default ports

The Web service function between the "Plants by WebSphere" and "Supplier" samples defaults to port 9080. To change, edit....


...and change the line that begins with...


To change the host/port of the Web service of the Supplier, edit...


...and edit the line that begins with...


To rebuild and reinstall the PlantsByWebSphere.ear and Supplier.ear files with different hosts/ports, edit...


...and change the line that begins with location="http://localhost:9080.

To change host/port of the of the Web service of the Plants by WebSphere, edit...

...and change the line that begins with location="http://localhost:9080.

The host name and the port must match the virtual host where the HTTP router Web modules of the Plants by WebSphere and Supplier applications are deployed. The default is default_host.


Set the data source helper class name for PLANTSDB and TechSamp data sources to the correct value

The data source helper class name for PLANTSDB and TechSamp data sources under Samples Cloudscape JDBC provider is set to...


This can cause unpredictable results.

Set the data source helper class name for PLANTSDB and TechSamp data sources under Samples Cloudscape JDBC provider to...



Add to cart resets the quantity of an item to one in Pet Store Sample

When an item is added to the shopping cart, the item is added with an initial quantity of one. You can adjust the quantity to a higher number in the shopping cart. If that same item is added again to the shopping cart, the adjusted quantity is reset to one.


Passwords are not compared when creating a new account in Pet Store Sample

When creating a new account, provide a new password. The first Password field is not compared for a match with the second Password (Repeat) field.


Pet Store pages do not show animal pictures or details when HTTP transport is reconfigured to use a port other than 9080

If the Pet Store pages do not show animal pictures or details when you reconfigure the IBM WAS to use an HTTP transport other than port 9080, update the URL of Pet Store Catalog DAOSQLURL to use the new port.

You can reconfigure the URL resource to use the new port with the IBM WAS console. Go to...

Resources | URL Providers (set scope to your Server) | Samples URL Provider - HTTPs | URLs | Pet Store Catalog DAO SQL URL

The port number is in the Specification field.


Forceful repopulating of Pet Store database fails

The option to forcefully repopulate the Pet Store database fails with an internal server error HTTP 500 - The page cannot be displayed.

Do not use this option.


See Also

Web services scenario: Static inquiry on supplier
Web services scenario: Dynamic inquiry on supplier
Web services scenario: Cross supplier inquiry
Mapping between Java and WSDL XML
WSDL language