Service-Oriented Architecture - An IT View

we described service-oriented architecture in the previous blog from a business point of view. In this section, we describe SOA from an IT point of view.

Component Model
Service-oriented architecture is a component model that interrelates an application’s different functional units, called services, through well-defined interfaces and contracts between these services. The interface is defined in a neutral manner that should be independent of the hardware platform, the operating system, and the programming language in which the service is implemented. This allows services, built on a variety of such systems, to interact with each other in a uniform and universal manner.

This feature of having a neutral interface definition that is not strongly tied to a particular implementation is known as loose coupling between services. The benefit of a loosely-coupled system is its agility and ability to survive evolutionary changes in the structure and implementation of the internals of each service that makes up the whole application.

Application Architecture
Service-oriented architecture is an application architecture in which all functions, or services, are defined using a description language and have invocable interfaces that are called to perform business processes. Each interaction is independent of each and every other interaction and the interconnect protocols of the communicating devices (that is, the infrastructure components that determine the communication system do not affect the interfaces). Because interfaces are platform-independent, a client from any device using any operating system in any language can use the service.

Though built on similar principles, SOA is not the same as Web services, which indicates a collection of technologies, such as SOAP and XML. SOA is more than a set of technologies and runs independent of any specific technologies.

Integration Architecture
Service-oriented architecture is an integration architecture approach based on the concept of a service. The business and infrastructure functions that are required to build distributed systems are provided as services that collectively, or individually, deliver application functionality to either end-user applications or other services.

SOA specifies that within any given architecture, there should be a consistent mechanism for services to communicate. That mechanism should be coupled loosely and should support the use of explicit interfaces.

A service is representative of a repeatable business task. Services are used to encapsulate the functional units of an application by providing an interface that is well defined and implementation independent. Services can be invoked (consumed) by other services or client applications.

Service orientation defines a method of integrating business applications and processes as linked services.

Service-oriented architecture (SOA) can be different things to different people depending on the persons role and context (business, architecture, implementation, operational). From a business perspective, SOA defines a set of business services composed to capture the business design that the enterprise wants to expose internally, as well as its customers and partners. From an architecture perspective, SOA is an architectural style that supports service orientation. At an implementation level, SOA is fulfilled using a standards based infrastructure, programming model and technologies such as Web services. From an operational perspective, SOA includes a set of agreements between service consumers and providers that specify the quality of service, as well as reporting on the key business and IT metrics.

A composite application is a set of related and integrated services that support a business process built on an SOA.

Drivers for SOA

1.The main driver for SOA is to define an architectural approach that assists in the flexible integration of IT systems. Organizations spend a considerable amount of time and money trying to achieve rapid, flexible integration of IT systems across all elements of the business cycle. The drivers behind this objective include:

2.Increasing the speed at which businesses can implement new products and processes, can change existing ones, or can recombine them in new ways

3.Reducing implementation and ownership costs of IT systems and the integration between them

4.Enabling flexible pricing models by outsourcing more fine-grained elements of the business than were previously possible or by moving from fixed to variable pricing, based on transaction volumes

5.Simplifying the integration work that is required by mergers and acquisitions

6.Achieving better IT utilization and return on investment

7.Achieving implementation of business processes at a level that is independent from the applications and platforms that are used to support the processes

8.SOA prescribes a set of design principles and an architectural approach to achieve this rapid flexible integration

What is a Service?
Having outlined SOA as being an architectural approach to defining integration architectures based on services, it is important to define what is meant by a service in this context in order to fully describe SOA and to understand what can be achieved by using it. A service can be defined as any discrete function that can be offered to an external consumer. This function can be an individual business function or a collection of functions that together form a process.

There are many additional aspects to a service that we must also consider in the definition of a service within an SOA. The most commonly agreed-on aspects are that services:

1.Encapsulate reusable business functions

2.Are defined by explicit, implementation-independent interfaces

3.Are invoked through communication protocols that stress location transparency and interoperability

Reusable Business Functions
A service can be any business function. In an SOA, however, it is preferable that the function is genuinely reusable. The goal of a service in an SOA is that it can be used and reused by one or more systems that participate in the architecture. For example, while the reuse of a Java logging API can be described as design time (when a decision is made to reuse an available package and bind it into application code), the intention of SOA is to achieve the reuse of services at:

Runtime

Each service is deployed in one place and one place only and is invoked remotely by anything that must use it. The advantage of this approach is that changes to the service (for example, to the calculation algorithm or the reference data on which it depends) need only be applied in a single place.

Deployment time

Each service is built once but redeployed locally to each system or to the set of systems that must use it. The advantage of this approach is increased flexibility to achieve performance targets or to customize the service (perhaps according to geography).

Explicit Implementation Independent Interfaces
The use of explicit interfaces to define and to encapsulate service function is of particular importance to making services genuinely reusable. The interface should encapsulate only those aspects of process and behavior that are used in the interaction between the service consumer and the service provider. An explicit interface definition, or contract, is used to bind a service consumer and a service provider. It should specify only the mutual behavior that is required for the interaction and should specify nothing about the implementation of the consumer or the provider.

By explicitly defining the interaction in this way, those aspects of either system (for example the platform on which they are based) that are not part of the interaction are free to change without affecting the other system. This implementation-independent interface allows either system to change implementation or identity freely

Communication Protocols that Stress Location Transparency
SOA does not specify that any specific protocol be used to provide access to a service. A key principle in SOA is that a service is not defined by the communication protocol that it uses but instead, should be defined in a protocol-independent way that allows different protocols to be used to access the same service.

Ideally, a service should only be defined once, through a service interface, and should have many implementations with different access protocols. This type of definition helps to increase the reusability of any service definition.

Refrence :
Building Composite Applications
by Juan R. Rodriguez et al.