We have seen that the lack of alignment between the business and IT is a common occurrence in almost every company. Achieving the alignment by modifying existing applications is in most cases, not successful for two reasons:
Complexity of the IT architecture, which makes modifying existing applications difficult and time consuming
Existing applications must not fail, because companies rely on them for everyday business
The alignment of business and IT is very difficult to achieve using traditional approaches. However, if a mediation layer between the business and the information system is introduced, the alignment between business and IT becomes more realistic — meet the SOA.
To manage problems related to changing requirements, technology developments, and integration, different methods have been proposed and used over time. A 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 into well-defined integration methods and principles, often referred to as EAI (Enterprise Application Integration). EAI initially focused on the 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 the reusability of existing applications and systems, efficient interoperabilities and application integrations, and the 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 the cost-efficient development, integration, and maintenance of information systems by reducing complexity and stimulation of integration and reuse. Let us look at the definition of SOA, as provided by Bernhard Borges, Kerrie Holley, and Ali Arsanjani (http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1006206,00.html):
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.
The following figure shows SOA as a mediator that aligns business and IT more closely. The end-to-end automation of business processes with BPEL fills the gap towards the business system. The services fill the gap towards the information system.
A Service-Oriented Architecture has several goals, but the two most important goals are to:
Provide end-to-end automation of business processes. To achieve end-to-end automation of business processes, SOA introduces a special language, that is, BPEL.
Provide a flexible, adaptable IT architecture, where applications are modularized, consolidated, decoupled, and where business logic is contained in autonomous, encapsulated, loosely-coupled, and reusable components, called services.
Let's look at these two goals more closely.
From the perspective of business systems, it is important that IT provides applications that support business processes from the beginning to the end (or end-to-end). However, such support has to be flexible so that business processes can be modified quickly.
In SOA, this is achieved by introducing a specialized language for business process execution — BPEL. BPEL is the most popular, commonly accepted specialized language for business process automation and the main topic of this book. BPEL is a special language, designed to execute business processes using a special server the process server. BPEL promises to achieve the holy grail of enterprise information systems, to provide an environment where business processes can be developed in an easy and efficient manner, directly executed, monitored, and quickly adapted to the changing needs of enterprises without too much effort.
Achieving adaptable and flexible IT architecture is another important objective of SOA. SOA enables us to develop a modular, loosely coupled architecture, which can overcome the difficulties of existing architectures.
The end-to-end automation of business processes can only be successful if sound, robust, and reliable applications are available underneath. This goal can only be achieved by developing a flexible architecture, where applications consist of modules. In SOA, modules are called services.
Services should be autonomous and should be able to work in different contexts. They should be reusable and loosely coupled. They should be encapsulated and should expose the operations through interfaces. Finally, the application architecture should be consolidated, which means that for a specific functionality, only one service should exist.
In SOA, services become the main building blocks of the overall IT architecture. Services guide us into good development practices and away from monolithic, tightly coupled applications. Services enable better and more efficient integration. They enable us to modify and adapt the applications faster, with less effort and with less negative consequences.
Services are also the main building blocks of BPEL processes. They are the executable artifacts. Those services that expose high-level, coarse-grained operations are called business services. The operations in business services usually represent distinct business activities. They are used in business processes — more exactly, BPEL uses business services to execute process activities. In other words, BPEL processes are compositions of business services. Business services provide the functionality, while BPEL processes contain the process flow.
Business services should be designed in a reusable manner, which means that a single business service can be used by more than one BPEL process. It also means that only one business service with the same functionality should exist in the system, which leads to consolidation.
Note
Although services in SOA are one of the most important building blocks, we should not forget about the architecture. Services will fulfill the promises only if they adhere to the architecture. Architectural design should therefore be the key priority.
There are several possibilities in which we can develop services. They are:
Developing services from scratch. This is appropriate for functionalities that are new and not yet covered by existing applications.
Exposing the functionality of existing applications through services. It is particularly important to reuse the logic in existing applications and to integrate new solutions with existing applications. Today, several possibilities exist for exposing existing applications through services, such as facades, adapters, mediators, and so on.
Using services provided by a third party.
The ability to expose existing applications is particularly important, because it enables those who will adapt SOA to reuse their existing IT assets. Existing applications have an enormous amount of business logic, which should be exposed and reused. SOA provides a standardized way to expose and access the functionalities (business logic) of existing applications through services.
From the technical perspective, services can be developed using a variety of distributed architectures. The requirement to expose the functionalities of applications and access them remotely has resulted in several distributed architectures and middleware products over time. The latest distributed architecture is web services. Web services are the most suitable distributed architecture for exposing the functionality of applications as services.
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 and service abstraction
Self-describing, standardized interfaces with coarse granulation
Exchange of messages
Support for synchronous and asynchronous communication
Loose coupling
Reusability
Service registries and repositories
Quality of service
Composition of services into business processes
Services provide business functionalities, such as an application for business travel, an application for a loan, and so on. This differs considerably from technology-oriented functionalities, such as retrieving or updating a table in a database. Services in SOA must provide business values, hide implementation details, and be autonomous. Services should be abstracted and autonomous. Service consumers are software entities, which call the service and use its functionality.
Service consumers access the service through its interface. The interface of a service defines a set of public operation signatures. It is a contract between the service provider and a service consumer. The interface is separated from the implementation, is self-describing, and is 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 the correct granulation of operations and we should standardize interfaces. SOA services are best modeled with coarse granulation.
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.
Service consumers access 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 the 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 the synchronous mode with operations in order to complete processing in a short time. In an 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, a correlation between messages is needed.
Through the self-describing interfaces, coarse granulation, exchange of data structures, and support for synchronous and asynchronous communication modes, a 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 us that there will be a minimal number of changes required by other services when one service is modified. Such an approach improves robustness, makes systems more resilient to change, and promotes the reuse of services.
SOA is about the consolidation of functionalities. Therefore, the common goal is to have a single service for each business functionality. In other words, we should not have more than one service with equal or similar functionalities. It is essential to achieve this in order to reuse services in different contexts. Reuse is not easy to achieve. First, we have to develop services that are general enough to be useful in different scenarios. Second, developers should first look at existing services, before developing a new one. If an existing service fulfills the need, they should reuse it. Reuse is fostered by registries and repositories.
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. Service registries can improve reuse. In addition to registries, repositories are becoming important for storing artifacts, such as WSDL interfaces, XML schemas, and so on. Registries and repositories play an important role in SOA governance.
Services usually have associated Quality of Service(QoS) 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, and so on. Quality of Service is also provided by the ESB.
The final and probably the most important SOA concept is the composition of services into business processes. Services are composed in a particular order and they follow a set of rules to provide support for business processes. The 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, to provide support to change 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.