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.

The following are a few benefits which are not gained from adopting to SOA:

   # Simple software engineering
   # Free integration or interoperability
   # Technology independence
   # Vendor independence
   # The ultimate architecture for the modern enterprise