Overview: Online garden retailer Web services scenarios
This set of scenarios is inspired by an online retailer called Plants by WebSphere. Plants by WebSphere uses Web services support in WAS to improve communications with its suppliers. The more advanced scenarios describe Web services support available only in particular editions of WebSphere Application Server. 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 one 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 WebSphere Application Server 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 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, Web applications 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.
For more information, see the XML specification on www.w3.org.
- WSDL (Web Services Description Language)
You use this XML-based 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.
For more information, see the WSDL specification on www.w3.org
- 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. It 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, and 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 described below can help Plants by WebSphere applications dynamically choose the optimal transport mechanism for a given situation.
For more information, see the SOAP specification on www.w3.org.
- Web Services for J2EE
Web Services for J2EE, also known as JSR-109, defines how J2EE applications create and access Web services.
Implementing Web services applications describes how to implement a Web service interface to an existing application, then deploy your Web service within the application server.
- 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 application server - 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) you should 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.
For more information, see Securing Web services for v5.x applications based on WS-Security.
See also
Web services scenario: Static inquiry on supplier
Web services scenario: Dynamic inquiry on supplier
Web services scenario: Cross supplier inquiry
Related Information
Samples page on IBM site