In this article we'll analyze a traditional service reuse - reuse "as is." But industry knows another kind of reuse - a container-like reuse. Some of you are probably familiar with J2EE (now JEE) containers for Web and business (EJB) applications and components. The same container can be reused for deploying multiple different components. The container enforces a certain development model by specifying what design elements are possible and impossible to use in the components, such as multithreading.

By analogy to the container, the same service operation can be reused as a channel providing the exchange of different extended messages between service consumer and service provider. Here we'll analyze container-like reuse of the service - reuse via extension.

To complete this observation, let's explain what we mean by a service reuse. If one understands service reuse as a use of the service in multiple projects, it may or may not be service reuse. It depends on how different the projects are.

Assume we are working in financial fund management. The task is to represent historical fund prices to the consumer. To implement this task with services we need, for example, to invoke an authorization service to control access to 1) the related Web page, 2) the business service aggregating historical fund prices, 3) the fund business service, and 4) the data acquisition service to retrieve data from the persistent store. How many reuses do we have in this example? My answer is none. We just used the authorization service several times against different protected entities.

Reuse in the service eco-system means that a service gets used in different execution contexts. For example, a mutual fund valuation service is built into the multinational financial organization. The service may be reused for funds operating in different countries. Even if countries speak the same language, like the U.S.A. and the U.K., the business execution context is different in these two places because of different laws and industry regulations.

Reuse Companion
A question about service interface granularity usually accompanies decisions of service reuse. The granularity of a service interface is a matter of art rather than a strongly regulated practice. It is a tradeoff in every case and has to take into consideration not only coding requirements but also performances, network capabilities, and service lifecycle management.

Indeed, if the interface provides fine-grained operations, like an API, it's suitable for the reuse "as is." Such reuse may reach high numbers at the beginning of a reuse process. However, try to recall the scale of effort required to move to a next version of the API, which is not totally backward-compatible... It's close to a nightmare - and the wider reuse, the worse it is.

If we use a coarse-grained service interface, it's less sensitive to the changes than the fine-grained one. However, some people believe that a coarse-grained service interface promotes the risk of massive programmatic mistakes. They think that such interfaces disallow concrete compilation control over the information passed through the "widely open" operations. I disagree with such a opinion because:

• Control based on operation granularity is inherited from the OOA, which doesn't necessarily work for function-oriented SOA services
• The granularity of operations in a SOA is usually combined with strong types of the messages - message schemas. Following SOA best practices, for a document-style service, the document schema is one of the strongest data-type controls
• The granularity of the operations and message schemas aren't a responsibility of the developer (who can make programmatic mistakes) but rather the design decision. As such, they go through multiple design reviews and controls, which minimize the chance of mistakes.

Service Categories and Reusability
In SOA practice and in some advanced SOA books (e.g., written by Thomas Erl), SOA services are grouped into three major categories: utility, entity, and business service. As the name suggests, utility services are helpers that provide service-oriented environment for other services and applications.

An example of a utility service is a security access control service. It is agnostic to any business processes, entities, tools, instruments, and applications; so, it can be reused in many execution contexts.

Another category is entity services. These services are tricky things - there's is a debate in the SOA community over whether an entity service is a SOA anti-pattern. An entity service represents business data objects in the service world. However, each service consumer has its own "view" of the shared business data object, and each architectural layer and execution context has its own requirements for the business data object. Obviously, we can expect less traditional reuse of the entity services than utility services.

The final category comprises business services. Such services implement business functions, features, units of work, and, occasionally business activities. Business services can work together representing an implementation of a business process. Some business processes may be embedded into the business services. Figure 1 illustrates reuse of the different service categories.

It might surprise some but in the business world we don't see much reuse of business services, i.e. the use of a service in different business contexts or situations. This is because of the business ownership model and the complexity of management across business lines. Currently, a SOA business service is seen as a reflection of the real business world. So business service reuse is less across the enterprise than the early SOA enthusiasts claimed.

Figure 2 depicts the difference in reuse between service categories depending on the reuse model. As described above, traditional reuse degrades due to inflexibility to changes in the business caused by the differences and changes in the execution contexts. On the other hand, coarse-grained service interfaces provide certain flexibility. So, we're looking for a mechanism capable of balancing specific and generic aspects of the service interface. Reuse via extension allows using the strongly typed service operations, typical for fine-grained interfaces simultaneously with flexible, extendable messages, which is closer to the coarse-grained model.

As the graph in Figure 2 shows, reuse via extension doesn't offer many benefits over traditional reuse for utility services. However, the more dynamic a business environment becomes, i.e., the more changes required to keep the business competitive in the market, the more traditional reuse looses to reuse via extension for the entity services and, especially, for the business services. Below we'll discuss one possible way of implementing reuse via extension for Web Services.