Web Services

printer-friendly version of this section  Print  e-mail this section  E-Mail  add a public, group or private note  Add Note  add a bookmark about this section  Add Bookmark    

Java APIs for XML Kick Start
By Aoyon Chowdhury, Parag Choudhary

Table of Contents
Chapter 2.  Components of Web Services


Web services are software components that can be executed over the Internet via XML interfaces. These software components are accessed through specific transport protocols, such as HTTP, SMTP, FTP, and so on. The software components have the ability to exchange data and information with each other across firewalls and different platforms without requiring human intervention.

But why do we need Web services? To answer this question, let us look at the changing scenario of business-to-business (B2B) communication.

Web Services and B2B Communication: The Evolving Scenario

All businesses have suppliers and consumers. It is critical for the success of a business to have effective communication systems with its business counterparts.

Let us consider a business, Great Car Parts Company, that sells various car parts and accessories. Owing to market demands, it decides to add car mobile phone chargers to its list. In the classic B2B communication model, somebody in the procurement department, we'll say Jack, will look in the yellow pages to find companies that deal in car mobile phone chargers. After the companies are identified, Jack will send out information requests to the various companies. The suppliers will in turn send the price list to Great Car Parts Company, where Jack will scan through the rival price lists and then reach a decision on from whom to buy the chargers. This process is obviously time consuming and error-prone.

From a business perspective, it would be tremendously beneficial if somehow all this communication and decision-making could be done programmatically. This implies that Great Car Parts Company will have application programs that can somehow find the companies that sell the car mobile phone chargers, and then access their databases for price information.

However, there are issues in accessing the information systems of other enterprises. The information systems in most enterprises are unique, both in terms of the hardware and operating systems in use, as well as the logical schema of the information. Therefore, it is possible that while Great Car Parts Company has its information systems running on a Windows NT platform, the company from which it plans to procure chargers, let's say We Sell Chargers Inc., could be running on Unix. Also, the way information is stored in We Sell Chargers Inc. could be very different from the way information is stored in the databases of Great Car Parts Company. Therefore, there has to be a system in place to ensure that different enterprises can access and exchange data with each other.

One of the first attempts at computer-to-computer integration has been through the use of Electronic Data Interchange and value added networks. However, this often translates to programming solutions being written to access proprietary and incompatible middlewares. Such solutions are time consuming, expensive to set up, and difficult to maintain, thus making it impractical for most businesses. Most small companies like our Great Car Parts Company rely on largely manual methods for doing B2B communications.

The advent of the Web brought two big changes in the B2B communication model. The simplicity of the HTML markup scheme and quick proliferation of Web browsers ensured that companies could publish information in a platform-independent manner. This also saw a part of the communication process being moved out of the human domain into programming solutions.

Going back to our Great Car Parts Company example, after looking in the yellow pages, Jack can now go to the Web sites of the competing vendors and get the price lists from the Web. Although this saves a substantial amount of time, it still requires a human to interface with the Web sites. Of course, to help Jack, one can write programs that parse the contents of a Web page, but there are inherent issues with that. It is important to remember that the Web was, by design, created for presenting data to humans. Therefore, although Jack can easily differentiate data from presentation in a Web page, it's rather painful to write a program to do the same. And even if you did write the program, a small change in the Web page could mean a lot of rework for the programmer of the parsing application.

Therefore, what is needed is a way in which an application can programmatically look up company information that meets its business needs, communicate with those companies and get the desired data, all without human intervention. Using XML interfaces, the Web services architecture fulfills this necessity for computer-to-computer, or more appropriately, application-to-application communication.

Returning to our example, in a pure Web services-enabled situation, an application would look up a Web registry to locate the companies that supply the car mobile phone chargers. Then the application would send a query to the companies for the price list. The companies will have Web applications that will respond to the request for price information and provide the data in a previously agreed upon format. The data received from each company would be parsed by an application in Great Car Parts Company to get the price data from each of the companies. Another application might then compare the prices, and depending on the algorithm, automatically place an order with a particular vendor. At the end of this chapter, we will see how JAX might be used to develop Web services.

Now that a Web service has been defined, we need to understand the main components of the Web service architecture and how they work with each other.

Components of Web Service Architecture

The Web service architecture has three main components:

  • A service provider A service provider is the organization that develops the Web service. A service provider is also responsible for creating and hosting the service descriptions, such as its location, transport protocol, message formats, and so on. For example, We Sell Chargers Inc. could develop and deploy a Web service that responds to the queries received from different companies about charger prices.

  • A service registry A service registry is analogous to the yellow pages. It is essentially a publicly searchable information exchange mechanism, in which service providers register and publish their company information and Web service descriptions. A service requestor can search the registry to find the desired Web service. For example, We Sell Chargers Inc. will need to register itself with a registry to ensure that companies that are looking for charger sellers can find it.

  • A service requestor A service requestor is an application, Web service, or even a human who wants to use a particular Web service. For example, the application program at Great Car Parts Company that looks up the service registry is a typical example of a service requestor.

As shown in Figure 2.1, these three components perform three operations on a Web service, called publish-find-bind.

Figure 2.1. The publish-find-bind operations.

graphics/02fig01.gif

The service provider creates the Web service application using a language such as Java. Next, using XML, the service provider needs to create the service description file for the Web service. After the application has been developed and the service description file has been created, the service provider publishes the service description to a registry.

Next, the service requestor, which wants to run the specific Web service, queries the registry and finds the service description for the Web service. Based on the information gathered from the service registry, the requestor connects to the service provider hosting the Web service using a bind operation, then runs the Web service. All the communication between the service provider, registry, and service requestor is done using XML over some standard Internet protocol, such as HTTP.

The physical representations of the publish-find-bind paradigm are the three XML-based protocols, namely WSDL, UDDI, and SOAP. Figure 2.2 shows how the three protocols are related to each other.

Figure 2.2. The Web Services Protocol Stack.

graphics/02fig02.gif

Let's now look at each of the three XML-based protocols in more detail.


printer-friendly version of this section  Print  e-mail this section  E-Mail  add a public, group or private note  Add Note  add a bookmark about this section  Add Bookmark    
Top

[0672324342/ch02lev1sec1]

 
 


JavaT APIs for XML Kick Start
JAX: Java APIs for XML Kick Start
ISBN: 0672324342
EAN: 2147483647
Year: 2002
Pages: 133

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net