| One primary value of an SOA is the reusability of services. In an ESB, services are meant to be reusable. An ESB service is an instance of a service type. Reusability can be accomplished by instantiating a particular type of service and applying variable data and conditions through parameterization and configuration. Examples of variable conditions that can affect the behavior of a service are the use of different XSLT stylesheets, different rules for CBR, and different endpoint locations. 7.5.1 Parameterization and Configuration Let's look at a practical-use example. Say an organization creates a business policy dictating that all services that provide data transformation functionality will create an audit trail by logging data to a known location using a specific algorithm for uniquely identifying the message being transformed. A service type can be established for all XSLT-based transformations that always writes audit information in accordance with the established rules. This service type is written once, and instantiations of this new service type can be reused in any number of situations by specifying the XSLT stylesheet and the entry/exit endpoint destinations as configurable parameters. In the transformation service illustrated in Figure 7-7, all the endpoints are configurable, including the entry, exit, fault location, tracking, and rejected message endpoints. The nature of the transform can be determined by the documents that get fed into the service (by configuring the entry endpoint) and the XSLT stylesheet that is supplied (through the directory service). Figure 7-7. Reconfigurable options of a service include endpoint definitions and an XSLT stylesheet 
This new auditing capability of the service may even be introduced as a new requirement after the transformation services are already in production. The new functionality can be introduced in the service type definition and redeployed to service containers using the ESB management framework. If the ESB's management framework supports live redeployment, this can be done without even taking down the container. Figure 7-8 shows a similar example of the various things that can be parameterized and configured administratively for a CBR service type. Figure 7-8. Configurable aspects of a CBR service 
Here, the list of possible choices for exit endpoints is configurable. The routing rules definition, whether XML-based or script-based, and the "helper" functions are also fed into the service as configurable parameters. The isPO( ) and getXPath( ) functions from our previous CBR discussion (Example 7-2) are examples of things that would be implemented in a helper function and reused by multiple routing rule( ) implementations. The exit endpoint can also be dynamically determined from a list of supplied endpoint destinations by logic in the rule( ) implementation. 7.5.2 Reuse via Composition Services can also be reused through composition; specialized services may be connected to form a composite business process. For example, rather than building the auditing function into the translation service type directly, auditing reuse can also be accomplished by creating a separate auditing service, as illustrated in Figure 7-9. Figure 7-9. The auditing reuse function as a separate service 
| 