Web Service Design Questions

This section describes the choices, and hence decisions, you have for building a Web service using WebLogic Platform.

Web Service Types

The types of Web services essentially differ in the mode of communication employed: synchronous or asynchronous.

Synchronous Web Services

Also known as s imple Web services, synchronous Web services implement a call-and-response Remote Procedure Call (RPC) mode of interaction. In this mode, the caller invokes the Web service, and the business logic behind the Web service executes its behavior while the caller waits for the business logic to complete its operation and return a response or result before proceeding. Hence, this is a synchronous mode of communication. When the business logic is complete, the Web service will return the results to the calling program or the Web service's consumer. During the time that the Web service's business logic is executing, the Web service's consumer thread is blocked and cannot do any other work.

For a simple coarse-grained business process, like the tax rate calculation, this type of service may be acceptable. However, for complex business processes like inventory management, EDI processes, or a long-running transaction that may access multiple back-end legacy systems, the blocking time for the Web service's consumer could be unacceptable. Releasing threads is very important when the consumer is running within a concurrent system where processing threads must be freed quickly to enable high throughput. Figure 29.10 depicts a simple RPC service invocation.

Figure 29.10. A simple RPC Web service invocation.

Asynchronous Web Services

Complex processes require an asynchronous communications mechanism rather than the simple synchronous RPC mechanism currently implemented by most Web service producers . An asynchronous process hands the Web service request to the Web service producer, allowing the Web service client or consumer to continue processing while the Web service producer does its work. The client in this case does not need the result of the service call, not even an error response, to continue. After an appropriate amount of time has passed, the Web service consumer checks back with the Web service producer to see whether the Web service's response has been completed. If the response is completed, the consumer can retrieve the response and go on with its work. Alternatively, the Web service client can configure itself as a listener or provide callbacks for the service producer to inform the client in real-time when results become available.

Asynchronous Web services, also known as "complex" Web services, are useful in cases where a service, by nature, will take an inordinate amount of time or resources to fulfill. Examples of such services are

• Settling payments

• Obtaining a credit score or rating

• Performing intensive computing tasks

• Responding to data mining requests

Figure 29.11 illustrates an asynchronous Web service using a message-driven bean for executing business logic and JMS (Java Messaging Service) to effect acceptance and delivery of client arguments or data.

Figure 29.11. Asynchronous Web service using a message-driven bean for business logic.

Asynchronous communications provide key advantages that are essential for enterprise-class Web services, including providing higher scalability, utilizing threads more efficiently , and providing users with faster feedback response.

Tip

In WebLogic Platform 7.0, a Web service no longer needs to be exclusively RPC or message-style. For your convenience, a single Web service can now contain both RPC and message-style methods .

Synchronous or Asynchronous?

How do you decide if a Web service should be request-response or message-style? In general, it should be considered a candidate for an asynchronous Web service if the service

• Can be considered a "batch" job that usually runs overnight.

• Does not need to return any immediate information or acknowledgment to the client ”for example, calling a service to update an online catalog database. In other words, the nature of the request is one-way.

• Takes an inordinate amount of time to fulfill.

• Involves multiple critical or scarce resources, such as distributed transactions.

All other situations can be implemented as request-response.

Back-End Provider Components

A Java class or an EJB can perform the business logic that needs to be executed to fulfill a Web service request. The only EJB types acceptable as Web service back-end components in WebLogic Server are stateless session beans and message-driven beans.

EJBs

Web service operations implemented with a method of a stateless session EJB are interface driven, which means that the business methods of the underlying stateless session EJB determine how the Web service operation works. That is, if you specify a Web service based on a stateless session EJB, the WebLogic tools will automatically define the Web service operations and their signatures exactly as the methods and their signatures will be defined on the EJB. The danger here is that you expose your application component model as your Web service, which is typically a mistake. The next chapter suggests best practices for Web service design.

Use a stateless session EJB back-end component if your application has the following characteristics:

• The behavior of the Web service can be expressed as an interface.

• The Web service is process oriented rather than data oriented.

• The implementation of the Web service will take advantage of the facilities of EJBs.

Message-driven beans, the other type of EJB on which to base Web services, can be used in conjunction with JMS destinations and queues for implementing asynchronous Web services. You can find more details on this later in this chapter in "Inside an Asynchronous Web Service."

Java Classes

Web service operations implemented with Java classes are similar to those implemented with an EJB method. Creating a Java class is often simpler and faster than creating an EJB. However, there are limitations and restrictions to using a Java class as a back-end component; they will be discussed in the next chapter.

Security

You can secure your Web service in WebLogic Server using the following methods:

• Snoop prevention ” Use the HTTPS transport, which encrypts all traffic between the client and Web service provider.

• Authentication ” When using HTTPS, two-way authentication can be configured so the server has to send credentials to the client, and vice versa. However, this technique authenticates only the client (such as the browser), and not necessarily the user . To accomplish the latter, you can use something similar to digital signatures (such as what the W3C-DSIG working group is developing; go to http://www.w3.org/TR/SOAP-dsig/ for more information).

• Authorization ” Institute username and password login to access a Web service. At a minimum, use the HTTPS protocol if username/password information is required by a Web service.

• Securing the business logic ” Configure permissions for the EJBs that fulfill the Web service request.

Refer to Chapter 30 to see exactly how these security measures are configured into a Web service.