Service-Oriented Architecture

DZone 's Guide to

Service-Oriented Architecture

An overview of service-oriented architecture.

· Performance Zone ·
Free Resource

Service-Oriented Architecture Overview

A service-oriented architecture (SOA) is an architectural pattern in computer software design in which application components provide services to other components via a communications protocol, typically over a network. The principles of service-orientation are independent of any product, vendor or technology.

SOA offerings should provide a solid solution to the problem of complex architecture and code redundancies, enabling efficient interoperability between systems, applications, and services.

What is a Service in SOA?

A service is a self-contained unit of software that performs a specific task. It has three components: an interface, a contract, and implementation. The interface defines how a service provider will perform requests from a service consumer, the contract defines how the service provider and the service consumer should interact, and the implementation is the actual service code itself. Because the interface of a service is separate from its implementation, a service provider can execute a request without the service consumer knowing how it does so; the service consumer only worries about consuming services.

Services in SOA Layers

To get a better sense of the role of services in SOA, you can think of SOA in terms of abstract layers:

  • Enterprise Layer
  • Process Layer

  • Service Layer
  • Component Layer
  • Object Layer

The Object Layer

The first layer, the Object Layer sits at the bottom and consists of legacy systems, including custom-built applications and databases that contain business functionalities. These legacy enterprise objects can be leveraged to build composite services — proof that SOA doesn’t have to mean rip and replace. Just above the Object Layer is the Component Layer consisting of enterprise components. These components are responsible for realizing the functionality of services.

The Service Layer

The middle layer is the Service Layer, which is where exposed services (both individual and composite services) carrying out business functions reside. The Service Layer acts as a bridge between the lower-level layers (the Object Layer and Component Layer) and the higher-level layers (the Process Layer and Enterprise Layer). Enterprise components can be exposed as services in this layer, making reuse a real possibility.

The Process Layer

Next is the Process Layer. Here, the services exposed in the Service Layer are combined through service orchestration or service choreography to create a single application that realizes and automates a business process. The final layer is the Enterprise Layer (also known as a Presentation Layer), which is the end user's point of access to the composite enterprise application, typically over the Internet.

SOA Is Based on Some Key Principles

Loose Coupling: Less dependence on each other. This is one of the main characteristics of web services which just states that there should be as little dependency as possible between the web services and the client invoking the web service. So if the service functionality changes at any point in time, it should not break the client's application or stop it from working.

Standardized Service Contract: Services adhere to a service description. A service must have some sort of description that describes what the service is about. This makes it easier for client applications to understand what the service does.

Service Reusability: Logic is divided into services with the intent of maximizing reuse. In any development, company re-usability is a big topic because obviously, one wouldn't want to spend time and effort building the same code again and again across multiple applications that require them. Hence, once the code for a web service is written it should have the ability to work with various application types.

Service Abstraction: Services hide the logic they encapsulate from the outside world. The service should not expose how it executes its functionality; it should just tell the client application on what it does and not on how it does it.

Statelessness: Ideally, services should be stateless. This means that services should not withhold information from one state to the other. This would need to be done from either the client's application. An example can be an order placed on a shopping site. Now you can have a web service which gives you the price of a particular item. But if the items are added to a shopping cart and the web page navigates to the page where you do the payment, the responsibility of the price of the item to be transferred to the payment page should not be done by the web service. Instead, it needs to be done by the web application.

Discoverability: Services can be discovered (usually in a service registry). We have already seen this in the concept of the UDDI, which performs a registry which can hold information about the web service.

Composability: Services break big problems into little problems. One should never embed all functionality of an application into one single service but instead, break the service down into modules each with separate business functionality.

Interoperability: Services should use standards that allow diverse subscribers to use the service. In web services, standards as XML and communication over HTTP is used to ensure it conforms to this principle.

Autonomy: Services should have control over the logic they encapsulate. The service knows everything on what functionality it offers and hence should also have complete control over the code it contains.

SOA Is Not Web Services

There seems to be a general confusion about the relationship between SOA and Web services. In an April 2003 Gartner report, Yefim V. Natis makes the distinction as follows:

"Web services are about technical specifications, whereas SOA is a software design principle. Notably, Web services' WSDL is an SOA-suitable interface definition standard: this is where Web services and SOA fundamentally connect."

Fundamentally, SOA is an architectural pattern, while Web services are services implemented using a set of standards; Web services are one of the ways you can implement SOA. The benefit of implementing SOA with Web services is that you achieve a platform-neutral approach to accessing services and better interoperability as more and more vendors support more and more Web services specifications.

soa ,service oriented architecture ,esb-based integration ,performance

Published at DZone with permission of Manish Kumar . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}