Guideline: Making Realization Decisions
This guideline provides advice and commentary to help in deciding how to realize
service components.
Relationships
Main Description

Sourcing approaches

Each service eventually is realized by using a Service Component.  Each service component can be considered to be 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, such as these alternative sourcing approaches: 

  • Build: For various reasons, the decision is to develop the service in-house.
  • Buy: Purchase a service that can be deployed and hosted internally.
  • Transform: Use 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: Pay for time-limited services provided by a supplier. This is based on the availability of a publish-subscribe model (in a message-oriented middleware context).
  • Integrate: Put legacy functionality in wrappers to achieve functionality. Integration is invocation-based.
  • Outsource: Contract with other companies or providers. As Web Services and business-to-business integration becomes more prevalent, this option will also be considered more widely.

You need to make a sourcing decision for each service component. 

Example: Rent-a-Car Realization Matrix presents a simple tabular format that can be used to document sourcing decisions.

Development approaches to support sourcing decisions 

Each of the previously mentioned approaches to sourcing has its own set of appropriate options for development. We will touch briefly upon a few of these options.

Transform involves identifying, out of a larger mass of functionality, a nugget of reusable functionality that is to be factored out and transformed into a component for use in the realization of a service component. The assessment and capture of what is reusable generally involves use of automated support to perform code dependency analyses, code extraction, and refactoring.  

For Build, service component development needs to conform to best practices for component design and construction. The IBM® Practice Library's practice on Component-Based Software Architecture provides useful guidance on component-based design. Component development can be accelerated by using, for example, Pattern-Based Engineering (PBE) approaches [GRK09] or more conventional model-driven development (MDD) techniques (see IBM® Redbook®: Building SOA Solutions Using the Rational SDP), whereby abstractions (such as design models) are automatically translated into implementation artifacts. Several service component patterns, which are amenable to automation using either PBE or MDD, are illustrated in Guideline: Service Component Patterns

Integrate involves several service-enablement techniques and technologies that are discussed in the next section of this guideline.

Integrating existing assets

Several routes are available to realize new services with existing functionality:

  • Wrap existing function as a service. Leave the function as-is, but use tools or middleware to expose the existing function as a service. For example, capabilities exist to expose legacy CICS transactions as SOAP Web services.
  • Wrap and replace existing function with a service. Wrap a function as described, but use the resulting service specification to redevelop the service at a later date, thereby 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. It might 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. In some cases, it is possible for the new service to access the legacy function in-place, simply by using the function as a logical component within the implementation of the service. This is discussed further in Pattern 07: Service-enable Non-service-oriented Legacy

These alternatives are demonstrated in this figure:

Diagram is described in the textual content.

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. The first and second options might 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 might 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 might involve examining the composition and flow of online transactions or batch jobs, or else persistent data stores that help perform that function. The current design of these existing applications might 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 might require sub-second response time when invoked as a service

More Information