There are a number of alternatives to be considered relative to deciding how to realize services (see figure below). This is not the straightforward build versus buy decision; other interesting options come into the picture. “Transform”-ation uses a combination of techniques including business rules extraction to pull out a segment of functionality to be used independently for the realization of the component’s service. “Integrate” is the “wrappering” of legacy functionality to achieve functionality; integration is invocation-based. Subscription is based on the availability of a publish-subscribe model (in a message-oriented middleware context) in which a consumer subscribes to the services provided by the provider. One of the options is to outsource (e.g., Payroll) the functionality out to some other business. As the web services and business-to-business integration becomes more prevalent, this option will also be considered for use on a wider basis.

• Build - for various reasons, the decision is to go-ahead and develop the service in-house.
• Buy - purchase a service that may be deployed and hosted internally.
• Transform - uses a combination of techniques including business rules extraction to pull out a segment of functionality to be used independently for the realization of the component’s service.
• Subscribe - is based on the availability of a publish-subscribe model (in a message-oriented middleware context) in which a consumer subscribes to the services provided by the provider.
• Integrate - is the wrappering of legacy functionality to achieve functionality; integration is invocation-based.
• Outsource - as Web Services and business-to-business integration becomes more prevalent, this option will also be considered for use on a wider basis.

Service Realization Decisions are associated with service components. Each service component can be considered a container of functionality that is needed to realize a service. It is composed of or uses both functional and technical components. It is important to decide how these service components will be realized. It is not a simple “buy or build” decision. There are other considerations that need to be looked at such as:

• Transformation which may involve extraction of rules or making a clone of existing code and rewriting it to perform as a component with defined interface.
• Integration with messaging or with wrappers.

Example

We wish to capture the realization decisions for the Rent-a-Car example, though it is hard to do this in the UML model we have been using in a number of examples. To help in this process, the Realization Matrix template can be used to document the result of these decisions, as shown in the figure below.

The advantage of the choices described are that whichever choice you make, there is a connection between each in terms of traceability from the use-case model to a design model and then to implementation.

It is our recommendation that the service model be realized using a design model. This provides the ability for the Designer and Implementer to apply patterns to the design model and model additional capabilities and structures before generating implementation artifacts.

One must not forget that very few solutions are built without consideration to existing applications that either will provide functionality to support the solution or with which the solution must interact. As such it is vital that existing legacy applications that will be reused as part of any solution be catalogued and their functionality identified. With a service-oriented solution, we are able to take a number of routes to integrate new services with existing functionality. These are demonstrated in the figure below:

• Wrap existing function as a service. In this case, we are looking to leave the function as-is, but use tools or middleware to expose the existing function as a service. For example, IBM provides the capability to expose legacy CICS transactions as SOAP Web services.
• Wrap and replace existing function with a service. In this case, we wrap a function as above, but we use the resulting service specification to redevelop the service at a later date, replacing the original service and having clients redirected to the new implementation.
• Use an adapter more amenable to service invocation. In some cases, it is not possible to wrap a function and expose it as a service, but may be possible to wrap the function in something more able to integrate, such as a message queuing interface or the Java Connector Architecture (JCA). This allows new services to access the function in-place.
• Integrate the function into the service. Obviously in some cases, it is possible for the new service to access the legacy function in-place, simply using the function as a logical component within the implementation of the service.

It should be considered that the third and fourth options provide the most flexibility because they use the existing function but do not continue to expose the function as-is to clients. On the other hand, the first and second options may introduce issues with the wrapping of existing functions as services because the performance of Web-service protocols and mismatches between native data formats and XML may introduce performance concerns.

Existing software assets and their dependencies and interfaces will have to be analyzed to determine if changes are required to support the business functionality.  For example, in order to create a web services interface for a legacy implementation of a business function, analysis may involve the examination of the composition and flow of online transactions or batch jobs, or persistent data stores that help perform that function.  The current design of these existing applications may have to change to support the functionality.  There is also a need to identify any potential barriers to creating a web services interface with the desired quality of service.  For example, a monolithic batch implementation of a business function may require sub second response time when invoked as a service.  

Wrapping Existing Assets as a Services Pattern

In some cases, however, it is expedient to develop a legacy service partition where a set of low-level legacy functions are exposed individually as services. This partition is only accessible to higher level services that utilize them in presenting a more granular business-aligned specification to consumers. This encapsulation of the legacy functions should be seen as a temporary solution and should only be undertaken if the performance characteristics of the wrapping technology is well understood. For more information see the concept Solution Partitioning.

One way to look at the wrapping of a legacy function is a very simplified form of the Service Provider model element, with a single service realizing a single specification with only a single operation. The following diagram demonstrates this pattern for the legacy function "UpdateCustomerAddress".

In tailoring this pattern, you may wish to do the following:

• It is likely that a set of existing functions will be provided by the same component so the same service provider should be used.
• The pattern above was generated automatically; it might be preferable to rename the default operation name from "exec${service}".
• Similarly, it would be valuable to rename the default generated messages; also at this point, the message structures should be modeled.
• The default pattern assumes the operation takes a message input and return a message; it may be that the legacy function returns no message or is a notification only and the signature of the operation generated should be amended.
• The architect/designer should ensure that the correct values are specified for the "allowedBindings" property on the service provider.