- Chapter 3: Simple Object Access Protocol (SOAP)
- Simple Object Access Protocol (SOAP)
- Doing Business with SkatesTown
- Inventory Check Web Service
- SOAP Envelope Framework
- Taking Advantage of SOAP Extensibility
- SOAP Intermediaries
- Error Handling in SOAP
- SOAP Data Encoding
- Architecting Distributed Systems with Web Services
- Purchase Order Submission Web Service
- SOAP Protocol Bindings
- Summary
- The Road Ahead
- Resources
This chapter is from the book
This chapter is from the book
This chapter is from the book
Doing Business with SkatesTown
When Al Rosen of Silver Bullet Consulting first began his engagement with SkatesTown, he focused on understanding the e-commerce practices of the company and its customers. After a series of conversations with SkatesTown's CTO Dean Caroll, he concluded the following:
SkatesTown's manufacturing, inventory management, and supply chain automation systems are in good order. These systems are easily accessible by SkatesTown's Web-centric applications.
SkatesTown has solid consumer-oriented online presence. Product and inventory information is fed into the online catalog that is accessible to both direct consumers and SkatesTown's reseller partners via two different sites.
Although SkatesTown's order processing system is sophisticated, it is poorly connected to online applications. This is a pain point for the company because SkatesTown's partners are demanding better integration with their supply chain automation systems.
SkatesTown's purchase order system is solid. It accepts purchase orders in XML format and uses XML Schema-based validation to guarantee their correctness. Purchase order item stock keeping units (SKUs) and quantities are checked against the inventory management system. If all items are available, an invoice is created. SkatesTown charges a uniform 5% tax on purchases and the highest of 5% of the total purchase or $20 for shipping and handling.
Digging deeper into the order processing part of the business, Al discovered that it uses a low-tech approach that has a high labor cost and is not suitable for automation. He noticed one area that badly needed automation: the process of purchase order submission. Purchase orders are sent to SkatesTown by e-mail. All e-mails arrive in a single manager's account in operations. The manager manually distributes the orders to several subordinates. They have to open the e-mail, copy only the XML over to the purchase order system, and enter the order there. The system writes an invoice file in XML format. This file must be opened, and the XML must be copied and pasted into a reply e-mail message. Simple misspellings of e-mail addresses and cut-and-paste errors are common. They cost SkatesTown and its partners both money and time.
Another area that needs automation is the inventory checking process. SkatesTown's partners used to submit purchase orders without having a clear idea whether all the items were in stock. This often caused delayed order processing. Further, purchasing personnel from the partner companies would engage in long e-mail dialogs with operations people at SkatesTown. This situation was not very efficient. To improve it, SkatesTown built a simple online application that communicates with the company's inventory management system. Partners could log in, browse SkatesTown's products, and check whether certain items were in stock. The application interface is shown in Figure 3.1. (You can access this application as Example 1 under Chapter 3 in the example application on this book's Web site.) This application was a good start, but now SkatesTown's partners are demanding the ability to have their purchasing applications directly inquire about order availability.
){kind=link}
Figure 3.1 SkatesTown's online inventory check application.
Looking at the two areas that most needed to be improved, Al Rosen chose to focus on the inventory checking process because the business logic was already present. He just had to enable better automation. To do this, he had to better understand how the application worked.
Interacting with the Inventory System
The logic for interacting with the inventory system is very simple. Looking through the Java Server Pages (JSPs) that made up the online application, Al easily extracted the key business logic operations from /ch3/ex1/inventoryCheck.jsp. Here is the process for checking SkatesTown's inventory:
import bws.BookUtil; import com.skatestown.data.Product; import com.skatestown.backend.ProductDB; String sku = ...; int quantity = ...; ProductDB db = BookUtil.getProductDB(...); Product p = db.getBySKU(sku); boolean isInStock = (p != null && p.getNumInStock() >= quantity);
Given a SKU and a desired product quantity, an application needs to get an instance of the SkatesTown product database and locate a product with a matching SKU. If such a product is available and if the number of items in stock is greater than or equal to the desired quantity, the inventory check succeeds. Because most of the examples in this chapter talk to the inventory system, it is good to take a deeper look at its implementation.
NOTE
A note of caution: this book's sample applications demonstrate realistic uses of Java technology and Web services to solve real business problems while, at the same time, remaining simple enough to fit in the book's scope and size limitations. Further, all the examples are directly accessible in many environments and on all platforms that have a JSP and servlet engine without any sophisticated installation. To meet these somewhat conflicting criteria, something has to give. For example:
To keep the code simple, we do as little data validation and error checking as possible without allowing applications to break. You won't find us defining custom exception types or producing long, readable error messages.
To get away from the complexities of external system access, we use simple XML files to store data.
To make deployment easier, we use the BookUtil class as a place to go for all operations that depend on file locations or URLs. You can tune the deployment options for the example applications by modifying some of the constants defined in BookUtil.
All file paths are relative to the installation directory of the example application.
SkatesTown's inventory is represented by a simple XML file stored in /resources/products.xml (see Listing 3.1). By modifying this file, you can change the behavior of many examples. The Java representation of products in SkatesTown's systems is the com.skatestown.data.Product class. It is a simple bean that has one property for every element under product.
Listing 3.1 SkatesTown Inventory Database
<?xml version="1.0" encoding="UTF-8"?>
<products>
<product>
<sku>947-TI</sku>
<name>Titanium Glider</name>
<type>skateboard</type>
<desc>Street-style titanium skateboard.</desc>
<price>129.00</price>
<inStock>36</inStock>
</product>
...
</products>
SkatesTown's inventory system is accessible via the ProductDB (for product database) class in package com.skatestown.backend. Listing 3.2 shows the key operations it supports. To construct an instance of the class, you pass an XML DOM Document object representation of products.xml. (BookUtil.getProductDB() does this automatically.) After that, you can get a listing of all products or you can search for a product by its SKU.
Listing 3.2 SkatesTown's Product Database Class
public class ProductDB
{
private Product[] products;
public ProductDB(Document doc) throws Exception
{
// Load product information
}
public Product getBySKU(String sku)
{
Product[] list = getProducts();
for ( int i = 0 ; i < list.length ; i++ )
if ( sku.equals( list[i].getSKU() ) ) return( list[i] );
return( null );
}
public Product[] getProducts()
{
return products;
}
}
This was all Al Rosen needed to know to move forward with the task of automating the inventory checking process.