Service-oriented architecture

An Introduction to Service-Oriented Architecture

The use of heterogeneous technologies and applications in corporations is a reality. At a time when resources are scarce, IT shops cannot just throw away their existing applications; rather, they must leverage their existing investments. service-oriented architecture (SOA) is popular because it lets you reuse applications and it promises interoperability between heterogeneous applications and technologies.

Service Oriented Architecture is basically an evolution of distributed computing. SOA provides a modularity of business logic, which can be presented as service for clients (client as in client-server architecture). These services are loosely coupled in nature, in the sense the 'User Interface' can remain completely independent of the service layer.

It is an architecture that relies on service-orientation as its fundamental design principle. SOA environment are made available as independent services can be accessed without knowledge of their underlying platform implementation. These concepts can be applied to business, software and other types of producer/consumer systems.

SOA definitions

SOA is a design for linking business and computational resources (principally organizations, applications and data) on demand to achieve the desired results for service consumers (which can be end users or other services). OASIS (the Organization for the Advancement of Structured Information Standards) defines SOA as the following:

A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

What is SOA?

The concept of a service is nothing new, but the notion of an SOA has evolved over the past couple of years. It's an architectural style of building software applications that promotes loose coupling between components so that you can reuse them. Thus, it's a new way of building applications with the following characteristics:

Services are software components that have published contracts/interfaces; these contracts are platform-, language-, and operating-system-independent. XML and the Simple Object Access Protocol (SOAP) are the enabling technologies for SOA, since they're platform-independent standards. Consumers can dynamically discover services. Services are interoperable.

Why SOA?

Today's IT organizations invariably employ disparate systems and technologies. Most analysts predict that J2EE and .NET will continue to coexist in most organizations and the trend of having heterogeneous technologies in IT shops will continue. Moreover, creating applications that leverage these different technologies has historically been a daunting task. SOA provides a clear solution to these application integration issues by allowing systems to expose their functionality via standardized, interoperable interfaces.

Using SOA offers several key advantages. You can:
Adapt applications to changing technologies. Easily integrate applications with other systems. Leverage existing investments in legacy applications. Quickly and easily create a business process from existing services.

SOA principles

The following guiding principles define the ground rules for development, maintenance, and usage of the SOA

Reuse, granularity, modularity, composability, componentization, and interoperability Compliance to standards (both common and industry-specific) Services identification and categorization, provisioning and delivery, and monitoring and tracking The following specific architectural principles for design and service definition focus on specific themes that influence the intrinsic behaviour of a system and the style of its design:

Service Encapsulation - A lot of existing web-services are consolidated to be used under the SOA Architecture. Many a times, such services have not been planned to be under SOA.
Service Loose coupling - Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other
Service contract - Services adhere to a communications agreement, as defined collectively by one or more service description documents
Service abstraction - Beyond what is described in the service contract, services hide logic from the outside world
Service reusability - Logic is divided into services with the intention of promoting reuse
Service composability - Collections of services can be coordinated and assembled to form composite services
Service autonomy – Services have control over the logic they encapsulate
Service optimization – All else equal, high-quality services are generally considered preferable to low-quality ones
Service discoverability – Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms

In addition, the following factors should also be taken into account when defining a SOA implementation:

*SOA Reference Architecture covers the SOA Reference Architecture, which provides a worked design of an enterprise-wide SOA implementation with detailed architecture diagrams, component descriptions, detailed requirements, design patterns, opinions about standards, patterns on regulation compliance, standards templates etc.

*Life cycle management introduces the Services Lifecycle and provides a detailed process for services management though the service lifecycle, from inception through to retirement or repurposing of the services. It also contains an appendix that includes organization and governance best practices, templates, comments on key SOA standards, and recommended links for more information.

*Efficient use of system resources

*Service maturity and performance

*EAI Enterprise Application Integration