Service-Oriented Architecture

(SOA) Pattern
Home > Architecture Library > Review by Architecture Type > Technology
Architecture > Service-Oriented Architecture (SOA) Pattern

Description
A service-oriented architecture (SOA) is an application topology in which the
business logic of the application is organized in modules (services) with clear identity,
purpose and programmatic-access interfaces. Services behave as "black boxes" where
their internal design is independent of the nature and purpose of the requestor. In
SOA, data and business logic are encapsulated in modular business components with
documented interfaces. This clarifies design and facilitates incremental development
and future extensions. A SOA application can also be integrated with heterogeneous,
external legacy and purchased applications more easily than a monolithic, non-SOA
application can. Applications that have separate business layers are more suitable to
access a SOA environment.

This pattern consists of four core elements:

• Service registry - describes the services available in its domain

and service providers register their service in the registry.
• Service provider - function that performs a service in response to
a request from a consumer.
• Service consumer - function that consumes the result of a service
supplied by a provider.
• Service interface - defines the programmatic access "contract" of
the service, establishes the identity of the service and the rules of the
service invocation.

The relationship between a service provider and consumer is dynamic and established
at runtime by a binding mechanism. This dynamic binding minimizes the
dependencies between the service consumer and service provider.

The pattern can be subdivided into two sets of activities:

• Design/Development/Configuration Events – During the design

and development of a service provider and service consumer, there
are several steps that facilitate the reuse of the service and rapid
development of service consumer applications. As shown in the
figure, a service developer, usually part of project team, develops a
service that meets a defined interface (step A). At NIH this interface
will be specified through the use of Web Service Definition
Language (WSDL). Once the service is developed the registry
administrator, a member of NIH’s Integration Competency Center
(ICC), will register the interface in NIH’s service registry (step
 B). The developer of a service consumer or client application may
then retrieve the interface information from the registry (step C), and
develop the application (step D). Development tools can help
automate some of the development associated with creating the client
application if there is an interface specified using a standard interface
definition language (IDL) like WSDL.
• Runtime Events - At runtime, the client application can access
information about the service including the bindings that it supports
and the network address of the server on which it is running. The
client can also choose from a variety of service providers at runtime
as long as they support the service interface that the client has been
developed to use. This creates a loose coupling between the client
application and the specific service implementation being used. As
shown in the figure, at runtime, the service providers can register the
instance of the service in the registry making it available to service
consumers (step1). The service consumer may then query the registry
in order to retrieve the binding information required to access the
service (steps 2 and 3). The service consumer then invokes the
service (step 4).

The value of SOA is derived from both the runtime and design / development /
configuration activities. The development process is accelerated through the reuse of
services. Dynamic discovery and binding at runtime supports loose coupling leading
to more stable, reliable production applications.

This pattern works by the service consumer invoking services stored in the registry
and leveraging the interface to use the business logic of the service provider, to trigger
an event or process.

Please view the Service-Oriented Architecture (SOA) Pattern below:

Diagram
View Larger Image | Instructions for Viewing and Printing Images

Benefits
• Reuse of services enabled by the decoupling of service providers
and service consumers, the structured description of interfaces, and
the discoverability of services through the registry.
• Incremental deployment and maintenance allowing for a phased
approach to the implementation of SOA and the leverage of legacy
capabilities.
• Architectural partitioning that allows the service provider to be
modified or even replaced without impact to the service consumer as
long as the same service interface is maintained.
• Flexibility and agility is facilitated by allowing multiple services
to be composed quickly into more complex services and allowing the
process flow between services to configured dynamically.

Limitations
• A central registry of service information should be used to
promote reuse.
• Policies for the management of the service registry must be
defined and implemented.
• Service level agreements between service providers and service
consumers should be defined.
• Requirements processes must focus on service interfaces in
addition to end-user interactions with systems.
• Testing processes must be geared toward repeatable testing of
service interfaces.
• Development processes must emphasize reuse of services to
compose new application rather than starting from scratch.
 • ICC will need to define the management processes associated
with SOA addressing many of these implications..

Recommended Usage
A service-oriented architecture is preferred in the following cases:

• When there is a need for request-reply, real time integration

between systems.
• When more than two systems are involved in the integration.
• When a service being provided is a likely candidate for reuse.
• When service implementation requires no advanced knowledge
of the service client.