Using Web Services: A Real World Example

The following topic describes a problem faced by a fictional company and provides a sketch of a web service solution.

# The Scenario

Imagine that you work for a company that evaluates credit applications for other clients, such as banks and mortgage lenders. These clients come to your company for help in evaluating an applicant's credit history and credit worthiness. Once your company has researched and evaluated an applicant's credit worthiness, you return a credit worthiness score to your client, who then decides whether or not to extend credit to the applicant.

The credit evaluation process involves three steps. First, an applicant is checked against an in-house database of bankruptcies. This database is maintained by your company and is accessible over the company's intranet. Second, a credit history for the applicant is retrieved from an external vendor. The external vendor has set up a web service that provides information about an applicant's credit cards, including how many credit cards she holds and the available credit on each card. Finally, the information retrieved in the first two steps is passed to a credit evaluation formula that returns a credit score indicating whether the applicant is a good or poor credit risk. For this example, the formula is an operation already implemented as an EJB (Enterprise Java Bean) embedded in another software application.

# The Problem

The problem scenario described above contains the following three resources:

1. An in-house database that supplies bankruptcy data

2. Another web service that supplies credit card histories

3. A credit evaluation formula

In order to make the evaluation process consistent and automated, your company now wants to build a credit evaluation process that ties together all of the relevant resources available both externally and internally. WebLogic Workshop is an ideal tool to apply to this problem because WebLogic Workshop is good at two things: (1) Workshop makes it easy to access and coordinate a wide variety of external resources into a single web service, and (2) Workshop makes it easy to expose this web service over networks to other users and software applications. When approaching the particular problem described above, a web service developer can use WebLogic Workshop to create the following solution.

# The Solution

The web service developer begins by deciding what sort of operations she wants her web service to expose to the outside word. In this particular case, the goal is to collect and evaluate information on a particular credit applicant, so the developer decides to expose a single operation of her web service and creates a single method that takes the applicant's Social Security number as a parameter and returns the applicant's credit worthiness score. She then establishes connections between the web service itself and its external resources.

## Controls

To establish these connections between resources, the developer uses tools in WebLogic Workshop, called controls, which manage the communications between a web service and its external resources. The developer would build three separate controls: one to retrieve data from the in-house database, another to retrieve data from the web service providing credit card histories, and a finally one to access the EJB which calculates a credit worthiness score. Once these controls are in place, the developer can write Java code to coordinate all three controls and the pass the final credit score back to the clients of your company.

## User Interface

Because a web service typically does not require a very sophisticated user interface, the developer does not need to spend time developing one. Web services themselves typically have thin user interfaces designed for other software applications to access the web service, rather than for direct human access. For the particular web service described above, there is no sophisticated GUI providing an interface between the web service and a human user. Instead the clients to the web service are responsible for building user interfaces that provide access to the web service.

## Network Latency

Because web services are involved with transmitting data across networks, a web service developer should address the issue of network latency. Latency refers to the time a client must wait for a request to be processed and returned over the network. A number of factors go into determining network latency. A network may have more traffic at certain times of the day, thereby increasing the network latency; or a web service may not be able to complete a process until a human intervenes to input some data or authorize some step in the process.

The web service developer can cope with network latency by building an asynchronous web service, which does not require that the client application halt and wait for the web service to process and return the requested data. Instead, an asynchronous web service immediately returns a simple acknowledgment to the client that a request has been received, and then, at a later time, the web service sends a callback to the client containing the full response. For more information about asynchronous web services see Using Asynchrony to Enable Long-Running Operations.

## Client Applications

The developer should also keep in mind the sort of client applications that will access the web service. The client application that calls the web service might be a JSP page, a Java application, a VisualBasic application, another web service or any software application that can communicate using XML messages. For the web service described above, the developer should consider what sort of client is likely to call the web service and what its capabilities are. If a client of the web service cannot support callbacks, the developer might consider providing a polling interface to allow such clients to access the web service. A polling interface is one where the client periodically calls on the web service until the web service has completed a full response to the client. Once the web service has completed the full response, it is returned to the client as a return value, rather than as a callback. For more information on polling interfaces see Using Polling as an Alternative to Callbacks. For more information about callbacks see Using Callbacks to Notify Clients of Events.

To see step by step instructions for building a web service like the one described above, see Tutorial: Your First Web Service