Reusable software components - when properly built, promoted, and tracked - deliver an enormously productive alternative to traditional "built-from-scratch" application development. The benefits are real, tangible, and ultimately reflected in the bottom line for those organizations with the wisdom to recognize software reuse as an adaptation of the same concept that made Henry Ford famous and very, very rich. Web services, when held to the same standards of construction, promotion, and tracking, offer the same benefits. The advantages of component-based development (CBD) apply equally to service-based development (SBD) - better, faster, cheaper creation of software solutions.

The characteristic benefit of software components is their ability to encapsulate functionality within a public interface. Encapsulation allows systems of ever-increasing complexity to be efficiently built, managed, and maintained as a series of high-quality, loosely coupled, interacting parts. Web services exhibit the same characteristics. To be effective, a Web service should only expose or make public those methods necessary for its usage. Other methods or properties should be hidden within the service's "black box." The direct benefit of appropriate encapsulation is simplicity and ease of use.

The Web service interface and methods must be immutable. As with component reuse, you must not change method names after a service has been deployed. An implied contract exists for deployed services that requires constancy of interfaces. This requirement of immutability mandates that the component be extremely well-thought-out prior to deployment.

Other CBD issues that are equally applicable to Web services include granularity, modularity, cohesion, and coupling. In applying the lessons learned in CBD and reuse to the matter of Web services, we know that a Web service's functionality must be properly sized and bounded. If the service is too granular or small, the overhead of multiple connections will have a negative impact on its performance. Conversely, excessively large, monolithic services are confusing, difficult to implement, and unlikely to be reused across applications. The relatedness or cohesion of the service's methods must also be monitored. Services should contain methods related to a common, clearly understandable goal. A multitude of disparate, unrelated methods reduces opportunities for reuse, confuses developers, and again makes the service difficult to manage. Like components, services should be loosely coupled and present the appearance of being entirely self-contained. The primary service may utilize other services to perform a given function, but the application should interact directly and exclusively with the primary Web service. It should never be the application's job to coordinate interaction between multiple services.

Web services must also be flexible - able to support current requirements and still be adaptable to future needs. Business needs are constantly changing, so the adaptability of software systems should always be a core functional requirement. The same adaptability that makes systems flexible within an application also enables reuse across applications. Services should therefore be designed to be customizable, portable, and generic.

One method for incorporating flexibility into services is to provide each service with a set of signatures. Each signature, represented by a variable passed to the service when called, would define a variant of the service's functionality. The signature would tell the service which modality the application was expecting the service to provide. The use of signatures also allows a service to utilize in-place upgrades (subject to standard predeployment testing, of course) where modified functionality can be added without interrupting the service or breaking existing applications.

Services that are intended for use beyond a single initial implementation require a high level of documentation. The documentation set for Web services should include comprehensive method descriptions, sample application code, complete response codes, tutorials, use cases, and architectural models.

Testing is another key piece of documentation required before Web services can be effectively deployed. Any application developer must know the level of reliability of a given service, as well as its specific response characteristics and methods.

Flashline has spent years building expertise in software reuse, which is reflected in the Flashline Component Manager, Enterprise Edition (CMEE). Much of what we have learned about reuse and CBD applies equally and just as effectively to Web services. While significant differences remain, the similarities between CBD and SBD are so striking that to describe the two as parallel methodologies may be inaccurate. Web services may in fact be the next step in the evolution of components.

• Figure 1