Home > Articles

The SOAP Protocol

  • Print
  • + Share This
This chapter is from the book

Inventory Check Web Service

SkatesTown's inventory check Web service is simple. The interaction model is that of an RPC. There are two input parameters: the product SKU (a string) and the quantity desired (an integer). The result is a simple Boolean value that's true if more than the desired quantity of the product is in stock and false otherwise.

Choosing a Web Service Engine

Al decided to host all of SkatesTown's Web services on the Apache Axis Web service engine for a number of reasons:

  • The open source implementation guaranteed that SkatesTown won't experience lock-in by a commercial vendor. Further, if any serious problems were discovered, a programmer could look at the code to see what was going on or fix the issue.

  • Axis is one of the best Java-based Web services engines. It's better architected and much faster than its Apache SOAP predecessor. The core Axis team includes Web service gurus from companies such as Macromedia, IBM, Computer Associates, and Sonic Software.

  • Axis is also one of the most extensible Web service engines. It can be tuned to support new versions of SOAP as well as the many types of extensions that current versions of SOAP allow for.

  • Axis can run on top of a simple servlet engine or a full-blown J2EE application server. SkatesTown could keep its current J2EE application server without having to switch.

SkatesTown's CTO, Dean, agreed to have all Web services developed on top of Axis. Al spent some time on http://ws.apache.org/axis learning more about the technology and its capabilities.

Service Provider View

To expose the inventory check Web service, Al had to do two things: implement the service backend and deploy it into the Web service engine. Building the backend for the inventory check Web service was simple because most of the logic was already available in SkatesTown's JSP pages. You can see the service class in Listing 3.2.

Listing 3.2 Inventory Check Web Service Implementation

package com.skatestown.services;

import com.skatestown.data.Product;
import com.skatestown.backend.ProductDB;
import com.skatestown.STConstants;

 * Inventory check Web service
public class InventoryCheck implements STConstants {
    * Checks inventory availability given a product SKU and
    * a desired product quantity.
    * @param sku      product SKU
    * @param quantity   quantity desired
    * @return       true|false based on product availability
    * @exception Exception most likely a problem accessing the DB
   public static boolean doCheck(String sku, int quantity)
      throws Exception
     // Get the product database, which has been conveniently pre-placed
     // in a well-known place (if you want to see how this works,
     // check out the com.skatestown.GlobalHandler class!).
     ProductDB db = ProductDB.getCurrentDB();

     Product prod = db.getBySKU(sku);
     return (prod != null && prod.getNumInStock() >= quantity);

The backend code for this service relies on the fact that some other piece of code has already made the appropriate ProductDB available via a static accessor method on the ProductDB class. We'll unearth the provider of ProductDB in Chapter 5, "Implementing Web Services with Apache Axis."

Once we have the ProductDB, the rest of the service code is trivial; we check if the quantity available for a given product is equal to or greater than the quantity requested, and return true if so.

Deploying the Service

To deploy this initial service, Al chose to use the instant deployment feature of Axis: Java Web service (JWS) files. In order to do so, he saved the InventoryCheck.java file as InventoryCheck.jws underneath the Axis webapp, so it's accessible at http://skatestown.com/axis/InventoryCheck.jws.

The Client View

Once the service was deployed, Al wanted some of SkatesTown's partners to test it. To test it himself, he built a simple client using Axis (see Listing 3.3).

Listing 3.3 The InventoryCheck Client Class

package ch3.ex2;

import org.apache.axis.AxisEngine;
import org.apache.axis.client.Call;
import org.apache.axis.soap.SOAPConstants;

 * Inventory check Web service client
public class InventoryCheckClient {
  /** Service URL */
  static String url = 
   * Invoke the inventory check Web service
  public static boolean doCheck(String sku, int quantity)
    throws Exception {
    // Set up Call object
    Call call = new Call(url);
    // Use SOAP 1.2 (default is SOAP 1.1)
    // Set up parameters for invocation
    Object[] params = new Object[] { sku, new Integer(quantity) };
    // Call it!
    Boolean result = (Boolean)call.invoke("", "doCheck", params);
    return result.booleanValue();
  public static void main(String[] args) throws Exception {
    String sku = args[0];
    int quantity = Integer.parseInt(args[1]);
    System.out.println("Making SOAP call...");
    boolean result = doCheck(sku, quantity);
    if (result) {
        "Confirmed - the desired quantity is available");
    } else {
        "Sorry, the desired quantity is not available.");

The client uses Axis's Call class, which is the central client-side API. When Al constructs the Call class, he passes in the URL of his deployed service so that the Call knows where to send SOAP messages. The actual invocation is simple: He knows he's calling the doCheck() method, so he passes the method name and an array of arguments (obtained from the command line) to the invoke() method on the Call object. The results come back as a Boolean object, and when the client is run, it looks like this:

% java InventoryCheckClient SKU-56 35
Making SOAP call...
Confirmed – the desired quantity is available.
  • + Share This
  • 🔖 Save To Your Account