CSC/ECE 517 Fall 2010/ch6 6j ss

Service-Oriented Architecture

A few years ago, it was realized that eventually software capabilities are going to be delivered and consumed as services. Implementing them as tightly coupled systems was definitely an option, but, a service-based interface was required between the point of usage to the portal, device or another end-point. Thus, there was the need of a service-oriented architecture that would facilitate the management of delivery, acquisition, consumption etc in terms of services that are related. This hinted at changes in how software life cycle is managed —right from requirements specifications as services, designing these services, acquisition and outsourcing in the form of services, asset management of services, and so on. Thus, after moving from modules to objects, to components, now was the time to move to services.

This wiki chapter aims at providing an introduction to the vast and growing field of Service Oriented Architecture. The chapter also discusses the different design patterns[1] currently in practice for the field of Service-Oriented Architecture. The utilization of the concepts of coupling[2] and cohesion[3] in Service-Oriented Architecture are described.

Introduction

Service-oriented architecture (SOA) is a collection or set of services communicating with each other. Two or more services can communicate either via a simple data passing system or could be coordinating on some activity. For these kind of communications to be possible between the services, some means to connect the various services is required.

Service-oriented architectures were existing in the past and are not a new thing. Many people are familiar with the use of DCOM [4] or Object Request Brokers (ORBs) [5] which are based on the CORBA[6] specification.These are the first service-oriented architectures deployed for practical applications. The following section gives a brief description about the evolution of SOA:

Evolution of SOA

In many respects, SOA is an evolution based on the component-based development (CBD). It, in fact, is a quantum leap in bringing business and information technology into closer alignment by supporting business processes. The SOA services are made visible to the consumer, but, the underlying components are kept transparent.

The Internet and XML standardization efforts demanded a service definition and description published by a service provider (SP) that could be located and invoked by a service consumer (SC). The service description can be implemented by different service providers, each offering various choices of qualities of service (QoS). The invocation can be across Internet or intranet in a distributed object connotation and standards such as WSDL[7] and SOAP[8] have been created.

The roles of SC and SP are illustrated in the following figure:

Figure 1: Service Provider and Service Consumer in a SOA

Terminologies

Services

A service is a specific function (business function). For instance, analyzing an individual's credit history or processing a purchase order. It can either provide a single discrete function, such as converting one type of currency into another, or it can perform a set of related business functions, such as handling the various operations in an airline reservations system. Services performing a related set of business functions are said to be coarse grained. Multiple services work in a coordinated way. This aggregated service can be used for a more complex business requirement.

Connections

Web services is the most likely connection technology of SOAs. Web services essentially use XML to create a robust connection. A web service can be defined as a service that communicates with clients through a set of standard protocols and technologies. These are standardized and are implemented in platforms and products from various vendors, giving clients and services an opportunity to communicate in a consistent way across a wide spectrum of platforms and operating environments.

The important concept is service. Web Services are the set of protocols by which Services are discovered, published and put to use in a technology neutral, standard form.

Service Oriented Architecture

Often is the case that one person's needs being met by capabilities offered by someone else. In the world of distributed computing, this scenario can be thought of one computer agent’s requirements being met by a computer agent belonging to a different owner. A one-to-one correlation is not not necessarily needed between these needs and capabilities.

SOA is a view of architecture focusing on services as the action boundaries between the needs and capabilities in order to service discovery and re-purposing. Thus, Service Oriented Architecture (SOA) can be defined as a paradigm for organizing and utilizing distributed capabilities that may be in different ownership domains and implemented using various technology stacks.

SOA is not only an architecture of services (seen from a technology perspective). It includes the policies, practices, and frameworks to ensure the right services are provided and consumed.

Example

This example depicts how an information system scenario could benefit from a migration to SOA. Consider an organization that has an application using three business processes using the same functionality.

Figure 2: Three business processes within one company duplicating functionality

The main disadvantages in the above scenario are:

• The company pays to implement the same functionality multiple times.
• Maintainence issues : Consider the situation wherein, a manager wants to deny a user access to all three processes.This requires three different procedures (one for each of the applications).

This system can be made efficient if common tasks are shared across all three processes. This requires decoupling the functionality from each process or application and making a standalone authentication and user management application that could be accessed as a service. Thus, the service itself is being repurposed, and, applications and the company owning it can now have a central point for maintaining it. This shows a simple example of Service Oriented Architecture in practice. The following diagram depicts the same:

Figure 3: Three business processes repurposing one service for common tasks

Discussion

Benefits of SOA

The following are the primary reasons which encourages an enterprise to take SOA approach:

• Reusability: SOA allows reuse of business services by enabling developers within an enterprise and/or across enterprises to take the code developed for existing business applications, convert them as web services, and then reuse it to meet new business requirements. This results in huge savings in the cost and time for application development. The more business services get built and get incorporated into different applications, the more are the benefits of reuse.

• Interoperability: One of the main objectives of SOA is to allow clients and services to communicate and understand each other independent of the platform they use. This objective is met when clients and services have a standard and consistent way of communicating with each other. Web services are used for this purpose.

• Scalability: SOA stresses on having few dependencies between the requesting application and the services it uses. Thus, services tend to be coarse-grained, document-oriented, and asynchronous. Coarse-grained services have the advantage of offering a set of related business functions, a document-oriented service accepts a document as input instead of a numeric value or Java object and an asynchronous service doesn't require the client to wait while it performs its processing. This relatively limited interaction from a client for communicating with a coarse-grained, asynchronous service, provides the scope for applications using these services to scale without increasing the communication load on the network.

• Flexibility: SOA discourages sharing semantics, libraries, and often sharing state. This makes it easier for the application to evolve and keep up with changing business requirements.

• Cost Efficiency: As SOA is a standards-based approach, it results in less costly solutions since the integration of clients and services doesn't require the in-depth analysis and unique code of customized solutions. Also, because ervices ins an SOA are less costly to maintain and easier to extend. Also many enterprises have a lot of the Web-based infrastructure for a web services-based SOA, further limiting the cost. The biggest cost saving of all comes from the reusability feature of SOA.

• Agility: Services can now be delivered quickly and need not depend on the larger projects common in the organization. The business can understand systems and requires simpler user interfaces calling on services. This in turn, speeds up the time-to-market.

• Promotes good design as the service is designed independent of who its consumers are or will be.

• Eases documentation and testing by separating them from the issues of the implementation.
  
  

It should be noted that SOA doesn't provide the bebefits mentioned below:

• Simple software engineering

• Free integration or interoperability

• Technology independence

• Vendor independence

• The ultimate architecture for the modern enterprise

Challenges

• Maintaining metadata related to the services is difficult as each service involves various messages used in communicating and an application can involve many such services, generating a huge number of messages. Also, services are delivered by different organizations within the company or different companies and this needs SOA Governance.

• SOA space lacks testing. This indicates that investment is required in a testing framework that would help find the culprit in the architecture.

• As more services get added for extensibility of the system, security models might require changes. Coming up with appropriate levels of security is a concern.

• SOA with Web Services result in addition of XML layers, requiring XML parsing and composition. Applications run slower and require more processing power when used without Remote Procedure Calls(RPC) [9] and thus, increase costs.
  

SOA Principles

There is a set of 10 principles for SOA. The first four are based on Don Box's four tenets. These principles are as listed below:

• Explicit boundaries: Services are inextricably tied to messaging in that the only way into and out of a service are through messages. This means that everything a service would require for its functionality should be passed to it when it is invoked.

• Shared Contract and Schema, not Class: The service consumer and a service provider involved in the contract should have everything they need to consume or provide the service and should not rely upon each other for any kind of reuse.

• Policy- Driven: Since a service can be accessed from various consumers, a policy mechanism is needed. The functional aspects are described in the service interface, and, policies specify the orthogonal, non-functional capabilities and needs.

• Autonomous: It should be possible to change and deploy, version and manage services independent of each other. The consumers need not quickly adapt to the new version.

• Wire Formats: A service must be accessible independent of the platform, as long as the platform supports the exchange of messages adhering to the service interface and policies.

• Document-Oriented: Documents are used to send data to interact with services. These documents might contain redundant information.

• Loosely-Coupled: As far as possible, components must be loosely coupled which enables extensibility, easier maintainence and a better system. But it is not always possible.

• Standard-complaint: Standards for technical aspects like data formats, metadata, transport and transfer protocols etc, must be followed.

• Vendor Independent: It should be possible to build a service provider or service consumer using any technology supporting the appropriate standards.

• Metadata - Driven: The metadata artifacts in the SOA should be discoverable, retrievable and interpretable at both design and run time.

Design Patterns in SOA

Design Patterns describe common problems with their solutions that can be applied repeatedly under a set of constraints. The collection of SOA design patterns forms a master pattern language applicable in various combination and sequences. Compound patterns comprising of multiple individual patterns is also possible. SOA has a huge number of design patterns which can be divided into the following categories:

• Foundational Inventory Patterns
• Logical Inventory Layer Patterns
• Inventory Centralization Patterns
• Inventory Implementation Patterns
• Inventory Governance Patterns
• Foundational Service Patterns
• Service Implementation Patterns
• Service Security Patterns
• Service Contract Design Patterns
• Legacy Encapsulation Patterns
• Service Governance Patterns
• Capability Composition Patterns
• Service Messaging Patterns
• Composition Implementation Patterns
• Service Interaction Security Patterns
• Transformation Patterns
• Common Compound Design Patterns
  

A more elaborate list and description of these patterns is available at SOA website[10].

As it can be seen, the SOA design pattern catalog is very broad. These patterns provide design techniques ranging from adjusting minute validation logic in a service contract to design strategies and help structure pools of services across an entire enterprise. An SOA initiative requires attention to the various design details associated with every service delivered, while not loosing the big picture. Design patterns help maintaining this balance by helping overcome common obstacles that have historically inhibited or derailed SOA project plans.

Working with SOA patterns

Here are a few guidelines for utilizing the SOA design patterns to their maximum extent:

• Patterns should be viewed with a Strategic Context
• Governance has to be considered
• Patterns can be applied to various extents
• Some patterns can be evolutionary
• Patterns can relate to other patterns
• Every pattern is not suitable for everyone

Coupling in SOA

Coupling specifies the degree of dependency between 2 or more modules. As we know, coupling can be classified as Loose Coupling and Tight Coupling. Loose coupling can be defined as the state in which the impact of change (change in consumers, providers, or cross-cutting policies) is minimized across dependencies. Loose coupling is important across units of deployment, whereas tight coupling is sufficient within a unit of deployment.

The essence of SOA is building composite distributed systems efficiently. In order for the distributed components to be reusable, reliable, available, scalable and fault tolerant, an appropriate level of loose coupling is needed. The impact of any change or modification and failures should be minimum on the landscape of a system as a whole. Loose coupling provides this property by defining and describing interaction patterns between components and technologies involved. Loose coupling also brings the advantage of versionability in SOA. If A and B depend on each other, loose coupling is needed only when A may version independently from B. That is, if A and B are versioned together, loose coupling between them is unnecessary.

Services in SOA require described interfaces. This provides a measure of loose coupling as the service dependency isn't a software to software dependency; rather it is N software to interface dependencies. This shows the importance of individual interface contracts. If an interface contract allows anything, then it has tight coupling between components.

There is no one way to build useful distributed systems that are completely decoupled, rather a variety of choices have to be considered based on various aspects of the systems. A property of a system can become a trade-off compared to other properties. For example, an asynchronous service usually requires the client open up its address space for a "callback" which increases the coupling. Also, loosely couple Web Services wait for messages via queuing mechanism before taking action. A large number of such services would be required to exceed the system load. So, tight coupling them can be considered. New mechanisms to switch loosely coupled Web Services to tightly coupled Web Services to avoid system overloads of scarce resources are being considered.

In summary, Loose coupling manifests itself in the SOA paradigm as follows:

• Creates an abstraction layer between the service producers and service consumers.
• Promotes flexibility in making changes to the service implementation without impacting the service consumers.
• In the SOA approach, functionality is organized as a set of modular, reusable shared services that have well-defined interfaces and encapsulate the key rules for accessing the services. They're also built without making any assumptions of who will use or consume these services.

Cohesion in SOA

Cohesion is defined as the measure of the relationship between the functionality expressed aby a module and the module itself. It is contrasted with the concept of coupling. High cohesion correlates to loose coupling.

Cohesion can be classified into various types. Below mentioned are the three "good" types of cohesion identified over the years:

• Functional Cohesion: An individual module does only one thing, resulting in low coupling and reusability.
• Sequential Cohesion: A module carries out several ordered tasks.
• Communication Cohesion: A module carries out multiple operations based on the same input and lacks any prescribed ordering requirements.

The following are identified forms of "bad" cohesion:

• Procedural Cohesion: This is similar to Sequential Cohesion with different data to work on for each task.
• Temporal Cohesion: A module's tasks are related only by time.
• Logical Cohesion: Modules sharing common implementations are grouped.
• Coincidental Cohesion: A module's tasks are related only when residing in the same module.

In today's vernacular, low cohesion is termed as coarse-grained. "Buy a car" and "run credit history" are examples of two such coarse-grained services offered in an SOA. SOA's success requires adopting "course-grained" services that can be plug-n-played with other sources interchangeably. But it is very much possible that within coarse-grained services, such as buy a car, there may be smaller or finer-grained services like Check Inventory, Schedule Detailing, etc. that make up the larger service, buy a car. Thus SOA and high cohesion as a principle aren't incongruent with each other. High cohesion is rather the foundation of creating coarse-grained services which is the fundamental element of creating a successful SOA implementation.

Enterprise Architecture Vs SOA

this is enterprise arch vs soa