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