Service-Oriented Architecture (SOA) Pattern

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:

 

View Larger Image | Instructions for Viewing and Printing Images

• 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.

• 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

• 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.