Service Oriented Architecture

Information systems need to support business changes quickly and efficiently. However, they also need to adapt to the fast development of new technologies. The majority of enterprise information systems are heterogeneous, containing a range of different systems, applications, technologies, and architectures. Integration of these technologies is crucial as only integrated information systems can deliver business values, such as efficient decision-making support, instant access to information, data integrity, along with decreased cost of software development and maintenance.

To manage problems related to changing requirements, technology development, and integration, different methods have been proposed and used over time. Service‑oriented architecture is the latest architectural approach related to the integration, development, and maintenance of complex enterprise information systems.

SOA is not a radically new architecture, but rather the evolution of well-known distributed architectures and integration methods. Integration between applications has evolved from early days to well‑defined integration methods and principles, often referred to as EAI (Enterprise Application Integration). EAI initially focused on integration of applications within enterprises (intra-EAI). With the increasing need for integration between companies (B2B, business-to-business), the focus of EAI has been extended to inter-EAI.

SOA improves and extends the flexibility of earlier integration methods (EAI) and distributed architectures, and focuses on reusability of existing applications and systems, efficient interoperability and integration of applications, and composition of business processes out of services (functionalities) provided by applications. An important objective of SOA is also the ability to apply changes in the future in a relatively easy and straightforward way.

SOA defines the concepts, architecture, and process framework, to enable cost-efficient development, integration, and maintenance of information systems through reduction of complexity, and stimulation of integration and reuse. Let us look at the definition of SOA, as provided in a paper by Bernhard Borges, Kerrie Holley, and Ali Arsanjani:

SOA is the architectural style that supports loosely coupled services to enable business flexibility in an interoperable, technology-agnostic manner. SOA consists of a composite set of business-aligned services that support a flexible and dynamically re-configurable end-to-end business processes realization using interface-based service descriptions.

SOA Concepts

SOA is more than just a set of technologies. SOA is not directly related to any technology, although it is most often implemented with web services. Web services are the most appropriate technology for SOA realization. However, using web services is not adequate to build SOA. We have to use web services according to the concepts that SOA defines.

The most important SOA concepts are:

• Services
• Self-describing interfaces with coarse granulation
• Exchange of messages
• Support for synchronous and asynchronous communication
• Loose coupling
• Service registries
• Quality of service
• Composition of services into business processes

Services

Services provide business functionalities, such as an application for a business travel, an application for a loan, etc. This differs considerably from technology-oriented functionalities, such as retrieving or updating a table in a database. Services in SOA must provide business value, hide implementation details, and be autonomous. Service consumers are software entities, which call the service and use its functionality.

Interfaces

Service consumers access the service through its interface. The interface of a service defines a set of public operation signatures. The interface is a contract between the service provider and a service consumer. The interface is separated from the implementation, is self-describing, and platform independent. Interface description provides a basis for the implementation of the service by the service provider and a basis for the implementation of the service consumers. Each interface defines a set of operations. In order to define business services, we need to focus on correct granulation of operations. SOA services are best modeled with coarse granulation.

Messages

Operations are defined as a set of messages. Messages specify the data to be exchanged and describe it in a platform‑ and language‑independent way using schemas. Services exchange only data, which differs considerably from object‑oriented and component approaches, where behavior (implementation code) can also be exchanged. Operations should be idempotent (an operation is idempotent if repeated invocations have the same effect as one invocation). WSDL is a service description language that meets SOA criteria.

Synchronicity

Service consumers access the services through the service bus. This can be either a transport protocol, such as SOAP, or an ESB. Service consumers can use synchronous or asynchronous communication modes to invoke operations of services. In synchronous mode, a service operation returns a response to the service consumer after the processing is complete. The service consumer has to wait for the completion. Usually we use synchronous mode with operations complete processing in a short time. In asynchronous mode a service operation does not return a response to the consumer, although it may return an acknowledgement so that the consumer knows that the operation has been invoked successfully. If a response is needed, usually a callback from the service to the consumer is used. In such a scenario, correlation between messages is needed.

Loose Coupling

Through the self-describing interfaces, coarse granulation, exchange of data structures, and support for synchronous and asynchronous communication modes, loose coupling of services is achieved. Loosely coupled services are services that expose only the necessary dependencies and reduce all kinds of artificial dependencies. This is particularly important when services are subject to frequent changes. Minimal dependencies assure that there will be a minimal amount of changes required to other services when one service is modified. Such an approach improves robustness, makes systems more resilient to changes, and promotes reuse of services.

Registries

To simplify and automate searching for the appropriate service, services are maintained in service registries, which act as directory listings. Service providers publish services in registries; service consumers look up the services in the registries. Lookup can be done by name, service functionality, or business process properties. UDDI is an example of a service registry.

Quality of Service

Services usually have associated quality‑of‑service attributes. Such attributes include security, reliable messaging, transaction, correlation, management, policy, and other requirements. The infrastructure must provide support for these attributes. Quality‑of‑service attributes are often important in large information systems. In web services, quality‑of‑service attributes are covered by WS-* specifications, such as WS-Security, WS-Addressing, WS-Coordination, etc. Quality of service is also provided by the ESB.

Composition of Services into Business Processes

The final, and probably the most important, SOA concept is composition of services into business processes. Services are composed in a particular order and follow a set of rules to provide support for business processes. Composition of services allows us to provide support for business processes in a flexible and relatively easy way. It also enables us to modify business processes quickly and therefore provide support to changed requirements faster and with less effort. For composition, we will use a dedicated language, BPEL, and an engine on which business process definitions will be executed. Only when we reach the level of service composition can we realize all the benefits of SOA.

The figure bellow shows the architectural view of SOA and positions the above-mentioned concepts:

Let us now fill the technologies into the above picture to understand the connection between SOA concepts and technologies that provide means for their realization. Notice that the mere use of a specific technology does not guarantee that we build SOA‑compliant architecture. For example, with web services we can develop business services (for example, a loan application), but we can also develop technology‑focused services (updating the database, for example). So, it is essential that technologies are used according to the guidelines provided by SOA concepts:

For this picture, we can have two views. The bottom-up view of SOA sees different applications exposing their functionalities through business services. This enables access to functionalities (services) of different existing and newly developed applications in a standard way. Access to services is important because a typical enterprise has a large number of applications, which have to be integrated.

Developing business services, either through reuse of existing applications or by new development, is not sufficient. We also need to compose services into business processes—this is the second, the top-down or process-oriented approach to SOA. We would obviously prefer a relatively simple and straightforward way to compose and modify business processes. This is where the BPEL becomes important. In the next section we will discuss service composition and BPEL.