CSC/ECE 517 Fall 2010/ch6 6j ss: Difference between revisions
| Line 1: | Line 1: | ||
'''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. | 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. | ||
Revision as of 18:29, 15 November 2010
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:
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.