Introduction to SOA

SOA (Service Oriented Architecture) is a much discussed architectural model for developing loosely coupled distributed systems. If one asks two people to define SOA one is likely to receive two very different, possibly conflicting, answers. Some describe SOA as an IT infrastructure for business enablement while others look to SOA for increasing the efficiency of IT.

SOA (Service Oriented Architecture) is a much discussed architectural model for developing loosely coupled distributed systems. If one asks two people to define SOA one is likely to receive two very different, possibly conflicting, answers. Some describe SOA as an IT infrastructure for business enablement while others look to SOA for increasing the efficiency of IT. While exactly what defines an SOA is still debated, there is general agreement that it is fundamentally an architectural pattern based on interoperable Services that communicate using messages.

Simple Definition: A loosely-coupled architecture designed to meet the business needs of the organization.
At first glance this definition seems far too simplistic – where is SOAP, web services, WSDL, WS-* and other related standards? A SOA does not necessarily require the use of Web Services – Web Services are, for most organizations, the simplest approach for implementing a loosely coupled architecture.

The fundamental building block of service-oriented architecture is a service. A service is a program that can be interacted with through well-defined message exchanges. Loosely-coupled systems result in loosely-coupled business processes. One of the key benefits of service orientation is loose coupling.

Four Tenets of Service Orientation:
- Explicit Boundaries
- Service Autonomy
- Contract Sharing – Services share schema and contract, not class
- Compatibility Based on Policy

SOA Reference Model: An abstract reference model to describe the various aspects of SOA.
- Expose: A Service Implementation Architecture describes how services are developed, deployed and managed.
- Compose: A Service Integration Architecture describes a set of capabilities for composing services and other components into larger constructs such as business processes.
- Consume: A Service Oriented Application Architecture describes how “composed services” are made available for consumption through as business processes, new services or new end-user applications.

Loose Coupling Is King: Loosely coupled services (it’s actually the consumer and provider that are loosely coupled) have few well-known dependencies, whereas tightly coupled services have many known and, more importantly, unknown dependencies. A system’s degree of coupling directly affects its overall flexibility. The more tightly coupled a system, the more a change in one service will require changes in other services or service consumers.

SOA Benefits and Pitfalls: SOA offers the possibility of being able to plug in new services without disrupting existing operations (business agility). This is especially true if one is using an enterprise service bus.
The potential benefits of adopting service oriented architecture are as follows.
- Faster development and maintenance
- More reusable business logic
- Greater consistency across the enterprise
The potential pitfalls include the following:
- Modelling systems and not the business.
- Ignoring the real users.
- Abstractions at too low a level.
Conclusion: This article is an introduction to SOA. The SOA approach encourages loose coupling between the services that make up an application. While designing services it’s worthwhile to consider the Cohesion and Coupling levels. Low coupling and high Cohesion is often a sign of well structured design.

References:
http://msdn.microsoft.com