- SOAP
- Doing Business with SkatesTown
- Inventory Check Web Service
- A Closer Look at SOAP
- The SOAP Messaging Framework
- SOAP Intermediaries
- The SOAP Body
- The SOAP Processing Model
- Versioning in SOAP
- Processing Headers and Bodies
- Faults: Error Handling in SOAP
- Objects in XML: The SOAP Data Model
- The SOAP RPC Conventions
- XML, Straight Up: Document-Style SOAP
- When to Use Which Style
- The Transport Binding Framework
- Using SOAP to Send Binary Data
- Small-Scale SOAP, Big-Time SOAP
- Summary
- 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, Al 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 a solid consumer-oriented online presence. Product and inventory information is fed into an 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's 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 internal 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 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 higher of 5% of purchases 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 isn't suitable for automation. One area that badly needs automation is the process of purchase order submission. Purchase orders are sent to SkatesTown by email. All emails arrive in a single manager's account in operations. The manager manually distributes the orders to several subordinates. They have to open the email, 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 has to be opened, and the XML must be copied and pasted into a reply email message. Simple misspellings of email addresses and cut-and-paste errors are common, and they cost SkatesTown and its partners 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 problems having to do with delayed order processing. Further, purchasing personnel from the partner companies would engage in long email dialogs with operations people at SkatesTown. To improve the situation, SkatesTown built a simple online application that communicates with the company's inventory management system. Partners can log in, browse SkatesTown's products, and check whether certain items are in stock, all via a standard web browser. This was a good start, but now SkatesTown's partners are demanding the ability to have their purchasing applications directly inquire about order availability.
Looking at the two areas that most needed to be improved, Al chose to focus first 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.
The logic for interacting with the inventory system is simple. Looking through the JSP pages that made up the online application, Al easily extracted the key business logic operations. 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. Since most of the example in this chapter will talk to the inventory system, let's take a slightly deeper look at its implementation.
NOTE
A note of caution: this book's example applications demonstrate 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. To keep the code simple, we do as little data validation and error checking as possible without allowing applications to break. We don't define custom exception types or produce long, readable error messages. Also, to get away from the complexities of external system access, we use simple XML files to store data.
SkatesTown's inventory is represented by a simple XML file stored in /resources/products.xml. The inventory database XML format is as follows:
<?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>
By modifying this file, you can change the behavior of the examples. The Java representation of products in SkatesTown's systems is the com.skatestown.data.Product class; it's a simple bean that has one property for every element under product.
SkatesTown's inventory system is accessible via the ProductDB (for product database) class in package com.skatestown.backend. Listing 3.1 shows the key operations it supports. To construct an instance of the class, you pass an XML DOM Document object representation of products.xml. After that, you can get a listing of all products or search for a product by its SKU.
Listing 3.1 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.