15.2 Web Services

Team-Fly

---

 

	Internet-Enabled Business Intelligence By William A. Giovinazzo
	Table of Contents
	Chapter 15.  The Road Goes Ever Onward

---

15.2 Web Services

Simply having two systems on the network does not mean that they communicate. We need more than TCP/IP, ASCII, and XML. If we think back to the ISO/OSI reference model, we need to establish communication between systems at the application layer. This is the task of Web services. Web services are similar to objects in an object-oriented programming environment. Just as an object in Java is a self-contained unit or module, a Web service is a self-contained application unit. We can take this unit and publish it over the Internet where others can locate the module and invoke its functionality. Via these Web services, supplier and distributor applications can communicate directly with our own applications.

In the case of Billy Boy, suppliers may be given access to inventory data. When stock levels drop below a certain level, the supplier's application can immediately issue an order. The IEBI system can use past history to predict the appropriate level at which to issue the order. Billy Boy can of course replicate this scheme with his distributors, detecting when their stock levels drop. Distributors in turn can be given access to Billy Boy's finished goods inventory. In essence, Billy Boy's inventory becomes an extension of their own, allowing them to reduce their own stock levels.

Another application of Web services comes into play with third-party information sources. We have discussed the use of demographic information, but where do we get that information? More importantly, how do we integrate that data into our IEBI systems? As one might guess, Web services. Our IEBI system can communicate with the third-party suppliers of demographic information, integrating this information directly into our data warehouse. This holds promise for more than just demographic data. We can use this same strategy to incorporate data from our partner and supplier systems into our data warehouse. As we discussed throughout this text, we want to extend our IEBI system beyond the four walls of our organization; we want to understand the entire value chain. Web services provide us with a means of establishing this level of integration.

Billy Boy also uses a B2B exchange for acquiring indirect materials. We can use Web services to distribute a Request for Proposal (RFP) to different suppliers. They can in turn respond automatically. Billy Boy's system receives these responses and automatically sorts through them, selecting the best response.

Web services employs three XML-based protocols: Web Services Definition Language (WSDL), Universal Description, Discovery, and Integration (UDDI), and Simple Object Access Protocol (SOAP). Basing these protocols on XML, an accepted and popular standard, makes this technology readily accessible. Figure 15.4 presents how these protocols work together to expose services to suppliers, customers, and partners .

Figure 15.4. Web services data flow.

The process begins when the Web service provider publishes the availability of the Web service in a directory, using WSDL. The Web services directory is a UDDI repository of available Web services. Publishing a Web service over the Web entails creating an entry in this repository that describes the service as well as the protocols necessary to acquire the service. A Web service client that requires a service queries the directory and receives in return the WSDL descriptor.

The Web service client uses the information provided in the Web service descriptor to construct a SOAP message. The SOAP message is contained within a SOAP envelope composed of a header, a body, and name space definitions. The header is an optional data structure that describes the data contained within the body. Header data might include user profiles used to grant or limit access to data. The body itself is an XML document that contains the actual request. The name spaces used in the header and body are defined within the SOAP envelope. Once the Web service provider has processed the request, the response is packaged in another SOAP envelope. The response itself is placed in the SOAP body.

Figure 15.5 demonstrates how we can use Web services in an IEBI environment. The process begins, as it does with any good company, with the customer. New visitors to our Web site select and purchase products. As part of this purchasing process, we receive from them registration information. On a periodic basis, the data warehouse extracts customer and clickstream data from the Web store. Upon receiving new customers, the data warehouse data integration process seeks those customers' demographic data. It begins by querying its own private UDDI-based Web services directory for providers of demographic information. This private directory is an extraction of a public directory on the Web. Once the data warehouse has received the WSDL descriptors for the respective suppliers, it sends a SOAP envelope to each, containing a RFQ (Request for Quote) for the demographic data.

Figure 15.5. Web services in an IEBI environment.

The quotation system of the demographic data suppliers responds to this request with its own SOAP envelope containing the quote. The data warehouse system evaluates the quotes based on price and completeness of the data. The system also takes into consideration the quality of the data the system received in the past from each supplier. A vendor is selected and a purchase order is issued. When received by the supplier, the data is sent directly to the data warehouse, where it is integrated into the system.

As we look at this example, we should notice one thing. Other than the consumer of the information in the data warehouse, this isn't necessarily an IEBI example. After all, couldn't these requests have been for powdered creamer for the office kitchen or urinal cakes for the men's room? Exactly! The fact that we are generating requests for demographic data simply shows another application of Web services. What makes this interesting from the IEBI perspective is not the data that is being transmitted between systems, but how that data is being transmitted.

The link between IEBI and Web services is that we now have captured our interactions between our suppliers, distributors, and partners. The Web store gave us insight into our customers' behavior that the brick-and-mortar environment couldn't. It did this by capturing the movements through our store in some electronic structure, the clickstream. We now had a tracking of each and every individual transaction that we could later analyze. This is what Web services do for IEBI. In addition to providing tighter integration between our systems and automating much of the process, it provides us a structure that captures the interactions with the other members of the value chain.

Web services have the potential of being the next big thing in software. So did XML. However, we should be wary of the hype. Web services are a structure by which applications can communicate. In this sense, they are very similar to XML and CWMI. Ultimately, data needs to be placed in this structure. If we place the wrong data in the structure or place the correct data in the wrong places, we still end up with garbage. There is still going to be some up-front investment in making these systems work together. It is not going to happen auto-magically .

At Oracle's 2002 Apps World in San Diego, Larry Ellison described the situation quite clearly. Allow me to paraphrase what he said. Let us say that I call someone, say Francois, in France from the landline in my home, and he picks up on his cell phone. After a brief attempt at conversing , it is clear that Francois speaks only French. Despite 3 years of French in high school with Mr. Lano, I don't understand a word he says. At that point, I hang up and call the same number, but this time from my cell phone. Can we now communicate any better?

The point is clear: It is not the technology that we use to facilitate communication as much as it is what we say to one another. We still need to understand how to speak the same language.

---

Team-Fly

Top