|
|
Since a Web service can be developed on many different types of platforms, it can follow many different implementation models. The implementation model it uses depends on the problem it needs to solve and the platforms available to create it. The model for Web service implementations can be grouped into four types: simple service, composite service, middleware service, and service bus.
A simple service, shown in Figure 1.13, is a service-enabled component or servlet that accesses a database or other resource directly. For instance, if a company has a stateless session bean that handles credit-card validation, JAX-RPC can be used to provide a Web service interface. This is an example of a simple Web service. Simple services are most common for green-field development of a small, discrete function.
A composite service, shown in Figure 1.14, fronts other simple or composite services. The composite service does this to create a coarser-grained behavior. For instance, an order-entry service would be a composite service that uses a credit-card authorization service, a customer service, and an order-entry component. The combination of these three functions into a composite service also gives the service consumer the ability to use each service separately or together through the order-entry service.
A Web service that places requests onto a middleware bus is an example of middleware service implementation, shown in Figure 1.15. Many organizations have existing messaging oriented middleware (MOM) systems installed. A MOM system provides third-party binding from the message sender to the message receiver. A message sender places a message on a queue, which is mapped to an endpoint. The sender is not aware of the physical location or implementation of that endpoint.
The service bus, shown in Figure 1.16, is similar to the EAI solution for enterprise application integration. It lets Web services communicate with each other through a third party.
For example, consider a banking application that consists of a banking graphical user interface (GUI) and an account service for processing deposit requests. Upon system startup, the account service registers its interest in deposit requests with a service bus. Let's assume that a banking GUI accepts a deposit request from a user. Rather than a banking GUI communicating with the account service directly, the banking GUI places the request onto the service bus. Because the account service registered its interest in deposit requests, the service bus forwards the request to the account service on the requester's behalf. The account service receives the deposit request from the service bus, processes the request, and places the results back onto the service bus. Then, on behalf of the account service, the service bus forwards the results to the banking GUI for display.
This method of routing messages between Web services is powerful. Not only can the account service get a notification that a message has been placed on the bus it is interested in, but other services can register their interest as well. If a logging service or a customer relationship management service were also interested in deposit to account requests that appeared on the bus, they, too, could register their interest in these transactions. This is a multi-cast method of communication, where a single requester can send messages to multiple services simultaneously. The requester also has no knowledge of what other services are consuming its request. The service bus management software configures the routing of these messages. The service bus also provides many other capabilities of an EAI solution such as transforming requests from one format to another. In all these scenarios, there are distinct benefits to using Web services. The following section explores many of them.
|
|
