This section describes the choices, and hence decisions, you have for building a Web service using WebLogic Platform. Web Service TypesThe types of Web services essentially differ in the mode of communication employed: synchronous or asynchronous. Synchronous Web ServicesAlso 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 ServicesComplex 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
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
All other situations can be implemented as request-response. Back-End Provider ComponentsA 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. EJBsWeb 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:
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 ClassesWeb 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. SecurityYou can secure your Web service in WebLogic Server using the following methods:
Refer to Chapter 30 to see exactly how these security measures are configured into a Web service. |