Benefits of Web Services

For any new idea to be adopted by industry, it must have distinct benefits over other solutions. So far in this chapter, we have explored the evolution to Web services and some of the ways to implement a Web service. Many of the benefits have been implied, but now we lay them out explicitly (Stevens 2002).

Reusability

The promise of reusable legacy applications, databases, objects, and components have been largely unrealized. Web services can play a significant role in improving software reusability within organizations. Web services can wrap legacy applications, databases, objects, and components and expose them as reusable services. The likelihood of reusability depends on several factors that Web services improve on: interoperability, modularity, central registry, and reduced compile-time dependencies.

Interoperable technology improves reuse. For instance, if it is difficult for an application to connect to and use a component, it is unlikely the component will be reused. Web services are built on open, interoperable, and ubiquitous standards, which maximizes their potential for reuse.

The creation of a robust service layer improves reusability, which leads to a better return on the investment. Services map to distinct business domains. For example, a company might create an inventory service that has all the methods necessary to manage the company's inventory. Placing the logic into a separate layer allows the layer to exist well beyond the lifetime of any system into which it is composed.

Developers have two options when they create functionality. They can either develop the functionality as part of the application that needs it or as a separate service. A function developed as a separate component and used as a service is more likely to outlive the original application.

Location Transparency

A service environment achieves location transparency, because the location is stored in a registry. A client finds and binds to a service and does not care where the service is located. Therefore, an organization has the flexibility to move services to different machines or to move a service to an external provider.

It is also possible to move code from one platform to another. Service-oriented architecture requires that the service support the published contract. The way the service is implemented is irrelevant. Therefore, if it becomes necessary to move a service from a J2EE platform to a .NET platform, no changes to the clients should be necessary.

"Wrap and replace" is a powerful pattern in a service-oriented environment. It gives an organization the flexibility to service-enable current legacy systems without losing the ability to sunset the systems later. A service-enabled legacy system can be replaced with a new component or system without requiring changes to the clients who use the service.

Composition

Developers assemble applications from a preexisting catalog of reusable services. Services do not depend on the applications into which they are composed. Because services are independent, developers will logically reuse these services in many applications. The interface design process promotes the design of interfaces that are modular and independent from the application for which they are designed. Properly designed interfaces and the creation of independent components will also maximize these items' potential for composition into other applications.

Developers by nature want to reuse software unless it is more difficult to reuse than to build from scratch. One of the greatest impediments to reuse is determining the software available for reuse. The registry in a service-oriented architecture provides this single place to store service descriptions.

Scalability and Availability

A system is scalable if the overhead required to add more computing power is less than the benefit the additional power provides. Because service clients know only about the service interface and not its implementation, changing the implementation to be more scalable and available requires little overhead. Typical Java implementations of Web services are deployed into a clustered environment, where the servlets and entity beans that implement the service logic are replicated, and requests are dynamically routed to instances of each, based on load.

Even without a clustered execution environment, a Web service that receives a request may route that request to multiple endpoints for execution. The logic for routing may be based on the identity of the requestor. For instance, the Web service may route VIP customer requests to a high-speed server and other customer requests to a lower-powered server. A request-dispatcher Web service can forward requests to different servers, because one of the requirements of service-oriented architecture is location transparency. This feature promotes scalability, because a load balancer may forward requests to multiple service instances without the knowledge of the service client.

Maintaining Investment in Legacy Applications

Services help maintain investments in legacy applications because they specify only the method of interaction, not the method of implementation. Legacy systems can be wrapped in a service fa ade. This method of creating services has the advantage of allowing organizations to replace legacy applications without changing the way that consumers access the service.

Reduced Vendor Dependence

As long as the platform used to build the application supports Web services standards, it is irrelevant to the consumer of the service. Web services allow organizations to make decisions about which platform to use based on the merits of the platform rather than vendor lock-in. Web services represent a major shift in power from the software and hardware vendor to the software and hardware consumer.