Overview: Online garden retailer Web services scenarios : WAS v5.1

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.

Before Web services
As featured in the Samples Gallery, the Plants by WebSphere application already has Web services capabilities. See below for a description of how the online garden retailer might have operated prior to adopting Web services technology. Key Web services components are introduced. To determine which components are available with the particular editions of WAS that you have purchased, consult the documentation for each edition.
Static inquiry on supplier
In this scenario, the garden retailer turns the existing web application (.war) into a Web service for checking the inventory of its main wholesale garden supplier.
Dynamic inquiry on supplier
In this scenario, the garden retailer uses Web services to perform an inventory search of several wholesale suppliers.
Cross supplier inquiry
In this scenario, the garden retailer makes its Web service available for use by others who need the service.
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:

XML (Extensible Markup Language)
XML solves the problem of data independence. You use it to describe data, and also to map that data into and out of any application or programming language.
To have their applications exchange information such as merchandise price and availability, Plants by WebSphere and its supplier will put the data in a set of XML tags to which both parties agree.
WSDL
Use the WSDL language to create a description of an underlying application. It is this description that turns an application into a Web service, by acting as the interface between the underlying application and other Web-enabled applications.
Plants by WebSphere has an application capable of querying the supplier inventory. To enable communication with the supplier over the Internet, the company turns the application into a Web service.
SOAP (Simple Object Access Protocol)
SOAP is the core communications protocol for the Web, and most Web services use this protocol to talk to each other.
SOAP is an XML format for Web services requests. According to the SOAP specification, SOAP is "a lightweight protocol for exchange of information in a decentralized, distributed environment. SOAP is an XML based protocol that consists of three parts:

An envelope that defines a framework for describing what is in a message and how to process it
A set of encoding rules for expressing instances of application-defined datatypes
A convention for representing remote procedure calls and responses.

SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework.
Because they are external to the Plants by WebSphere intranet, communications with its suppliers will utilize SOAP over HTTP. Web services operating within the company intranet can use other transports, such as local Java bindings. The Web Services Invocation Framework (WSIF) component can help Plants by WebSphere applications dynamically choose the optimal transport mechanism for a given situation.
Web Services for J2EE
Web Services for J2EE, also known as JSR-109, defines how J2EE applications create and access Web services.
Using Web services based on Web Services for J2EE describes how to implement a Web service interface to an existing application, then deploy your Web service within the appserver.
Java API for Remote Procedure Calls
JAX-RPC, also known as JSR-101, defines how Java applications access Web services.

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.

Notes

Default ports

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

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

To change the host/port of the Web service of the Supplier, edit...
$WAS_HOME/samples/properties/pbw.properties

...and edit the line that begins with...
portaddress=http://localhost:9080.

To rebuild and reinstall the PlantsByWebSphere.ear and Supplier.ear files with different hosts/ports, edit...
$WAS_HOME/samples/src/PlantsByWebSphere/PBWProject/build.xml

...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...
samples/src/PlantsByWebSphere/SupplierProject/build.xml
...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...
com.ibm.websphere.rsadapter.DB2DataStoreHelper

This can cause unpredictable results.
Set the data source helper class name for PLANTSDB and TechSamp data sources under Samples Cloudscape JDBC provider to...
com.ibm.websphere.rsadapter.CloudscapeDataStoreHelper

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

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.