Service Oriented Architecture (SOA) is a programming pattern that enables application components to provide services to other components through a communication protocol over a network. It is a development model that incorporates discovery, access control, data mapping, and security features.

There are two primary users of service oriented architecture: the service provider and the service consumer.

Properties Of Service Oriented Architecture

Each component of a service oriented architecture is a discrete unit of functionality that can be accessed and worked on independently. Generally, any SOA component has these four (4) distinct properties:

1. It is self-contained
2. It may consist of other underlying services
3. It represents a business activity with a specific outcome
4. Consumers are not privy to the inner workings of the service

Basic Concepts Of SOA

Since SOA is not a new pattern, it is common to see slightly different implementations of service oriented architecture from one company to another. However, there are some basic concepts that can be found in all businesses.

Six of them are:

1. Flexibility
2. Intrinsic interoperability
3. Business value
4. Shared services
5. Evolutionary refinement
6. Strategic goals

SOA Principles

Service oriented architecture is based on certain universal principles some of which are mentioned below:

• Loose coupling: This means that there should be as little dependency between the web service and the client requesting the service. So that if there is any change in functionality of the web service, it should not affect the client’s application.
• Reusability: In order to save time, energy, and cost, web service code should be able to function across various platforms. And once the code is written, it should be possible to easily reuse it on other applications that may require it.
• Composability: Instead of lumping up all the functionality of a service into one component, it should be broken down into smaller modules with various functions. When a system is composable, it will provide components that can be selected and assembled in various combinations to achieve and satisfy specific business goals.
• Abstraction: Your web service should tell the service user what to do and not how to do it. The logic should be hidden from the outside world.
• Autonomy: The service should have total control over the logic it encapsulates. It should know everything about the functionality of its logic and should not depend on anything external to the service itself. The web service has full control over it’s own code. The end users have no need to know about its implementation.
• Standardized service contract: Web services must offer/follow a standardized service description. A service must have some sort of description which states what the service is about. Thereby making it easier for client applications to understand what exactly the service does.

Pros Of Service Oriented Architecture

• Easy maintenance: Since services operate independently of each other, it is easy to modify and update them without affecting the other services.
• Scalability: Services are inherently scalable. They can grow on to multiple servers within an environment and even across data centers.
• Platform independence: Complex applications can be made by picking services from various sources independent of the platform.
• High availability: SOA architecture requires high availability. This means that service availability is increased using different techniques (like reducing fail-over time and failure detection time through monitoring, etc). So an SOA-based service is readily made available to anyone on request.
• Service reusability: As a result of SOA composability (see above), services can be reused to make various other applications.
• Reliability: It is easier to debug smaller, independent services than it is to debug large codes. Thereby making SOA applications more reliable.

Cons Of Service Oriented Architecture

• Complex management: SOA applications are divided into small services, and each service interacts by sending messages with tasks. It could become a huge task to manage the large number of messages being sent, which sometimes runs into millions.
• High investment: The initial investment required for an SOA application is quite high.
• High overhead: Whenever services interact, an input validation is done on the parameters. This reduces performance and response time.

Components Of SOA Infrastructure

In order to successfully manage an SOA application, you need an infrastructure that supports all the standards and requirements of service oriented architecture.

Let’s look at the various components of a typical SOA infrastructure.

1. SOAP, UDDI, and WSDL: These are the fundamentals pieces to an SOA application. WSDL helps to describe the web service. UDDI is used for registering and looking up services. And SOAP is used as the transport layer for sending messages between service requester and service provider.
2. WS-I Basic Profile: This is needed for service interoperability and testing. It can be used to test service interoperability across different platforms.
3. Java EE and .Net: These are the popular stacks upon which SOA applications are built. However, SOA applications are not limited to these platforms.
4. Quality of Service: SOA services have something called “Quality of Service” (QoS) associated with them. Key QoS elements include reliable messaging, security requirements (like authentication and authorization), and policies on who can invoke a service.
5. Security: This focuses on message integrity, credential exchange, and message confidentiality. It utilizes existing security standards like SAML (etc.) to secure web service messages.
6. Reliability: Typically, various messages are sent between the service consumer and service provider. Standards around managing the delivery of these messages are an important part of service oriented architecture. WS-Reliability and WS-ReliableMessaging are examples of such standards used to achieve reliable messaging.
7. Policy: Service providers oftentimes require service consumers to communicate with certain policies. These requirements are called policy assertions. One policy may comprise of several assertions.
8. Orchestration: When integrating SOA applications, process requirements must be standardized. Orchestration deals with this standardization.
9. Management: A management system that lets system administrators manage the services running in an SOA environment is important.

Where SOA Finds Use

For the most part, SOA is an enterprise-level programming pattern. One which many .Net and Enterprise Java developers are familiar with.

It is useful for these (and many more) cases:

• To improve customer service.
• For a more effective partnership.
• To increase speed in the market.
• To increase agility.
• To loosely couple businesses.
• To manage the workflow.
• To manage data.