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:
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
|