Service-oriented architecture

Introduction

SOA (service-oriented architecture) has become a buzzword of late. The World Wide Web Consortium (W3C) refers to SOA as 'A set of components which can be invoked, and whose interface descriptions can be published and discovered'. Only a technical person can understand this definition. A simplified version of this definition would be -

A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed. The combination of services - internal and external to an organization - makes up a service-oriented architecture.

Although the concepts behind SOA have been around for over a decade now, SOA has gained extreme popularity of late due to web services. Before we dive into the details, let us step back and examine the context for the evolution of SOA. To do that, we have to simply look at the challenges faced by the developers over the past few decades and observe the solutions that have been proposed to solve their problems.

The Problem

Early programmers soon realized that writing software was becoming way too complex. They realised the need of reusing some of the code they were rewriting. Researchers had a new mantra: go-to considered harmful. They introduced the concept of modular design. Modular design deals with the use of routines, sub routines and functions in order to organize and execute specific sets of instructions which helped programmers to reuse their code. This concept was again OK for smaller programs. But as the size and the complexity increased this started to create a maintenance nightmare. When a bug was discovered in a function somewhere, they had to track down all of the applications that used the function and modify the code to reflect the fix. Also, here we lay stress only on the steps of execution, but we are hardly bothered about the data for which all these has been done. This laid the groundwork for thinking new concepts, which would give absolute data security and OOPs evolved.

To solve these problems researchers proposed object-oriented software. Again, as software complexity grew, developers realized that developing and maintaining software was complex and they wanted a way to reuse and maintain functionality, not just code. Researchers offered yet another abstraction layer to handle this complexity -- component-based software. Component-based software is/was a good solution for reuse and maintenance, but it doesn't address all of the complexities developers are faced with today. Today, we face complex issues like distributed software, application integration, varying platforms, varying protocols, various devices, the Internet, etc. Today's software has to be equipped to answer the call for all of the above. In short, SOA (along with web services) provides a solution to all of the above. By adopting a SOA, you eliminate the headaches of protocol and platforms and your applications integrate seamlessly.

Key Components of SOA

The first step in learning something new is to understand its vocabulary. In the context of SOA, we have the terms service, message, dynamic discovery, and web services. Each of these plays an essential role in SOA.

Service

A service in SOA is an exposed piece of functionality with three properties:

1. The interface contract to the service is platform-independent.

2. The service can be dynamically located and invoked.

3. The service is self-contained. That is, the service maintains its own state.

A platform-independent interface contract implies that a client from anywhere, on any OS, and in any language, can consume the service. Dynamic discovery hints that a discovery service (e.g., a directory service) is available. The directory service enables a look-up mechanism where consumers can go to find a service based on some criteria. For example, if some one was looking for a credit-card authorization service, he might query the directory service to find a list of service providers that could authorize a credit card for a fee. Based on the fee, he would select a service (see Figure below). The last property of a service is that the service be self-contained.

Message

Service providers and consumers communicate via messages. Services expose an interface contract. This contract defines the behavior of the service and the messages they accept and return. Because the interface contract is platform- and language-independent, the technology used to define messages must also be agnostic to any specific platform/language. Therefore, messages are typically constructed using XML documents that conform to XML schema. XML provides all of the functionality, granularity, and scalability required by messages. That is, for consumers and providers to effectively communicate, they need a non-restrictive type of system to clearly define messages; XML provides this. Because consumers and providers communicate via messages, the structure and design of messages should not be taken lightly. Messages need to be implemented using a technology that supports the scalability requirements of services. Having to redesign messages will break the interface to providers, which can prove to be costly.

Dynamic Discovery

Dynamic discovery is an important piece of SOA. At a high level, SOA is composed of three core pieces: service providers, service consumers, and the directory service. The role of providers and consumers are apparent, but the role of the directory service needs some explanation. The directory service is an intermediary between providers and consumers. Providers register with the directory service and consumers query the directory service to find service providers. Most directory services typically organize services based on criteria and categorize them. Consumers can then use the directory services' search capabilities to find providers. Embedding a directory service within SOA accomplishes the following:

1. Scalability of services; you can add services incrementally.

2. Decouples consumers from providers.

3. Allows for hot updates of services.

4. Provides a look-up service for consumers.

5. Allows consumers to choose between providers at runtime rather than hard-coding a single provider.

Web Service

Although the concepts behind SOA were established long before web services came along, web services play a major role in a SOA. This is because web services are built on top of well-known and platform-independent protocols. These protocols include HTTP, XML, UDDI, WSDL, and SOAP. It is the combination of these protocols that make web services so attractive. Moreover, it is these protocols that fulfill the key requirements of a SOA. That is, a SOA requires that a service be dynamically discoverable and invokeable. This requirement is fulfilled by UDDI, WSDL, and SOAP. SOA requires that a service have a platform-independent interface contract. This requirement is fulfilled by XML. SOA stresses interoperability. This requirement is fulfilled by HTTP. This is why web services lie at the heart of SOA.

Benefits of SOA

SOAs offer the following advantages over other approaches:

They offer business services across the platforms.

They provide location independence.

Services need not be at a particular system or particular network.

Completely loosely coupled approach.

Authentication and authorization support at every level.

The search and connectivity to other services is dynamic.

Short-term benefits of implementation:

Enhances reliability.

Reduces hardware acquisition costs.

Leverages existing development skills.

Accelerates movement to standards-based server and application consolidation.

Provides a data bridge between incompatible technologies.

Long-term benefits of implementation:

Provides the ability to build composite applications.

Creates a self-healing infrastructure that reduces management costs.

Provides truly real-time decision-making applications.

Enables the compilation of a unified taxonomy of information across an enterprise and its customer and partners.

Benefits from the perspective of Business Value

Ability to more quickly meet customer demands.

Lower costs associated with the acquisition and maintenance of technology.

Management of business functionality closer to the business units.

Leverages existing investments in technology.

Reduces reliance on expensive custom development.

Areas in SOA Implementation where OO Concepts are used

As service oriented architecture gains popularity, it is starting to prove beneficial in places where OOP was inadequate. However, this does not mean an end to the OOP paradigm. Significant OOP principles are required by SOA architects to create interfaces to distributed applications. The main areas where OO concepts come into picture are

1. Interface Orientation The interfaces should be at a higher level of abstraction from service implementation and should be able to provide well defined interfaces in an implementation-independent manner. There should be a comprehensive, uniform service specification with stable and well managed contracts.

2. Interoperability This is of prime concern to ensure seamless integration of applications in a heterogeneous environment. So they have to be interoperable, standard-based interfaces. Such technical standardization, coupled with business standardization will make SOA more effective.

3. Autonomy and Modularity An effective SOA architecture divides the existing architecture into autonomous sub systems. Care is to be taken that resources and functions are grouped together to ensure high cohesion and reduced runtime dependencies through a loosely coupled communication system.

OO Concepts in SOA

A ‘service’ is the main design element of service oriented architecture. It encapsulates existing application logic and can be dynamically combined to form business processes. Services represent abstract software elements and/or interfaces which provide other applications with stable, reusable software functionality at a business-related level of granularity using widely applied standards. The OO design principles and design patterns which come in very handy when designing services are

1. Service loose coupling

This design principle promotes the independent design and evolution of a service’s logic and implementation. But it still guarantees baseline interoperability with consumers that have come to rely on the service’s capabilities. There are numerous types of coupling involved in the design of a service, each of which can impact the content and granularity of its contract. Achieving the appropriate level of coupling requires that practical considerations be balanced against various service design preferences. Coupling should be such that runtime dependencies should be reduced to a minimum

2. Service Abstraction

Abstraction emphasizes the need to hide as much of the underlying details of a service as possible. This contributes in preserving the loosely coupled relationship. Service Abstraction also plays a significant role in the positioning and design of service compositions. Various forms of meta data come into the picture when assessing appropriate abstraction levels. The extent of abstraction applied can affect service contract granularity and can further influence the ultimate cost and effort of governing the service.

3. Service Reusability

Reuse is a core part of typical service analysis and design processes, and also forms the basis for key service models. It emphasizes the positioning of services as enterprise resources with agnostic functional contexts. Numerous design considerations are raised to ensure that individual service capabilities are appropriately defined in relation to an agnostic service context, and to guarantee that they can facilitate the necessary reuse requirements.

4. Service Autonomy

The principle of Service Autonomy supports the extent to which other design principles can be effectively realized in real world production environments by fostering design characteristics that increase a service’s reliability and behavioral predictability. This principle raises various issues that pertain to the design of service logic as well as the service’s actual implementation environment. Isolation levels and service normalization considerations are taken into account to achieve a suitable measure of autonomy, especially for reusable services that are frequently shared.

5. Service Composability

As the level of sophistication and complexity in the design of a service grows, the ability to effectively compose services is a critical. Complex service compositions place demands on service design that need to be anticipated to avoid massive retro-fitting efforts. Services are expected to be capable of participating as effective composition members, regardless of whether they need to be immediately enlisted in a composition.

Cohesion in SOA

Cohesion, a quality to be maximized, focuses on the relationships between the activities performed by each module. There are different forms of coupling cohesion. The following three of these forms are considered safe -

Functional cohesion occurs when a module does only one thing. Such modules that also display low coupling are highly reusable because they are self-contained and largely independent of any surrounding code.

Sequential cohesion occurs when a module carries out several tasks, and the input of one task feeds into another, perhaps modifying the data as it passes through. A sequentially cohesive module or service is often a wrapper around other modules or services, chaining them together to perform a larger function.

Communicational cohesion is when a module carries out multiple operations based on the same input or output data. Such cohesion often results from the desire to operate only once on a complex set of data, calculating in one pass everything that the rest of the application might possibly want to retrieve or derive from it.

In contrast to the “good” forms of cohesion, the following four forms are frowned upon:

Procedural cohesion is similar to sequential cohesion except that the data feeding each of the tasks is different. Such cohesion often results from artificially grouping activities of an application together into catch-all functions in a misguided attempt to reduce coupling.

Temporal cohesion occurs when a module’s tasks are related only by the time they’re carried out. Such modules cause maintenance problems if one of the tasks needs to be performed at a different time.

Logical cohesion is a condition in which a module’s activities are grouped together because they appear to be able to share common implementations. This results in a strange or awkward interface for the module, thereby punishing all of its users, just to ease the implementer’s job.

Coincidental cohesion represents the bottom of the cohesion barrel, in which a module’s tasks are related only by the fact that they reside together in that module.

Coupling in SOA

Coupling is a measure of interdependencies between modules, which should be minimized. Hence, quality systems tend to exhibit “loose” rather than “tight” coupling. The following forms are referred to as normal coupling -

Data coupling occurs when modules pass data between each other, such as when a variable is passed as a parameter to a function call.

Stamp coupling is like data coupling but with composite parameters. The difference is that the composite structure’s fields are passed somewhat invisibly. Passing a whole structure allows the called module to manipulate all fields contained therein, which can be undesirable if the module really only needs access to one or two fields.

Control coupling occurs when one module knows something about and passes information that’s intended to control the logic of another. Such an arrangement make it harder to change the decisions, and also implies reduced module cohesion as well.

The following forms are to be avoided -

Common coupling occurs when two modules share a common data area, such as global variables. Consider the services that share directories, registries, or databases.

Content coupling describes the situation in which one module directly refers to another’s innards. Modern form is generally known as implementation coupling, in which one module depends on the implementation details of another. It means that changes to one module or service will almost certainly require modifications to the other.

Interface coupling refers to the degree to which one module depends on another’s interface. Objects and packages generally offer multiple methods, and it’s not unusual for code using an object or package to depend on many or all of its methods.

Design Patterns in SOA

A ‘service’ is the main design element of service oriented architecture. It encapsulates existing application logic and can be dynamically combined to form business processes. Services represent abstract software elements and/or interfaces which provide other applications with stable, reusable software functionality at a business-related level of granularity using widely applied standards. The OO design principles and design patterns which come in very handy when designing services are

1. Service loose coupling

This design principle promotes the independent design and evolution of a service’s logic and implementation. But it still guarantees baseline interoperability with consumers that have come to rely on the service’s capabilities. There are numerous types of coupling involved in the design of a service, each of which can impact the content and granularity of its contract. Achieving the appropriate level of coupling requires that practical considerations be balanced against various service design preferences. Coupling should be such that runtime dependencies should be reduced to a minimum.

2. Service Abstraction

Abstraction emphasizes the need to hide as much of the underlying details of a service as possible. This contributes in preserving the loosely coupled relationship. Service Abstraction also plays a significant role in the positioning and design of service compositions. Various forms of meta data come into the picture when assessing appropriate abstraction levels. The extent of abstraction applied can affect service contract granularity and can further influence the ultimate cost and effort of governing the service.

3. Service Reusability

Reuse is a core part of typical service analysis and design processes, and also forms the basis for key service models. It emphasizes the positioning of services as enterprise resources with agnostic functional contexts. Numerous design considerations are raised to ensure that individual service capabilities are appropriately defined in relation to an agnostic service context, and to guarantee that they can facilitate the necessary reuse requirements.

4. Service Autonomy

The principle of Service Autonomy supports the extent to which other design principles can be effectively realized in real world production environments by fostering design characteristics that increase a service’s reliability and behavioral predictability. This principle raises various issues that pertain to the design of service logic as well as the service’s actual implementation environment. Isolation levels and service normalization considerations are taken into account to achieve a suitable measure of autonomy, especially for reusable services that are frequently shared.

5. Service Composability

As the level of sophistication and complexity in the design of a service grows, the ability to effectively compose services is a critical. Complex service compositions place demands on service design that need to be anticipated to avoid massive retro-fitting efforts. Services are expected to be capable of participating as effective composition members, regardless of whether they need to be immediately enlisted in a composition.

Service Oriented Architecture in contrast with Enterprise Architecture

Similarities

SOA and EA domains share many similarities.

Both address similar architectural domains.

Both are intended to closely align IT with business.

Both use input based on business objectives.

Both require similar strategies and planning activities.

Differences

While the focus of the EA architecture domains is on the macro level, the SOA architecture domains work on a micro level. More specifically:

EA focuses on defining business components, while SOA focuses on business services.
EA deals with application frameworks and enterprise applications, while SOA's scope is on service modeling only.
EA deals with enterprise-level infrastructure including servers, databases, and so on, while SOA focuses on the infrastructure that supports services, namely the Enterprise Service Bus.
EA addresses enterprise integration patterns and when they should be used, including point-to-point integration; file transfer, and other traditional application integration approaches. SOA provides an integration approach based on using services. Though the SOA approach to integration may prove to be the most flexible and recommended approach, you should consider it as one of the approaches EA needs to define and support.

Service Oriented Architecture	Enterprise Architecture
Focus on ‘service’	Focus on business components
Scope limited to service modeling	Also focuses on Application frameworks
Focus on infrastructure providing services, ie Enterprise Service Bus	Deals with enterprise level infrastructure components like servers, databases, etc.
Provides an integration approach based on using services	Addresses integration patters like point-to-point integration; file transfer, and other traditional application integration approaches

Conclusion

Even though we have decades of experience in software development, we have yet to solve the mysteries of software complexity. As complexity grows, researchers find more innovative ways to answer the call. SOA, in combination with web services, is the latest answer. Application integration is one of the major issues companies face today; SOA can solve that. System availability, reliability, and scalability continue to bite companies today; SOA addresses these issues. Given today's requirements, SOA is the best scalable solution for application architecture.