Skip to main content

Basic Principles of Service-Oriented Architecture (SOA)

Service-oriented architecture (SOA) is one the most hotly debated topics in IT today. It's hardly new, but it's still one of the most misunderstood concepts among developers – mostly because of its fairly vague definition.

Prove you're a Dev Guru! Take the test now! (opens in new tab)

If you need to find the meaning of a new word, you'd usually refer to the dictionary for a definition. In this case, we need to turn to W3C – the World Wide Web Consortium - for the definition of SOA. W3C defines SOA as “A set of components which can be invoked and whose interface descriptions can be discovered and published” (source: It's a pretty broad definition that leaves a lot of room for interpretation as to what concepts make up SOA.

Microsoft has been publishing articles and white papers regarding its commitment towards SOA. These articles and whitepapers focus on the following principles of service orientation:

• Explicit boundaries

• Autonomous services

• Policy-based compatibility

• Shared schemas and contracts

Explicit boundaries

The concept of explicit boundaries in SOA means that you can deploy the service anywhere, and this service should be easily accessible by other services, regardless of the platform or programming language of the other service. This enables the programmers to develop highly flexible services that are easy to implement and deploy across multiple platforms.

Autonomous services

The principle of autonomous services in SOA states that each service should be independent of other services. Each service should be properly managed and versioned, so that it does not affect other services in the process. Each service should be built to handle changes easily without affecting the current system where it exists.

For instance, you have an online store that uses two services - Order Processing and Order Delivery. These services should be independent of each other. For example, if the Order Delivery service is not available, then it should not affect the Order Processing service. Every precaution should be taken to make sure that service should survive even if its dependent service is not available.

Policy-based compatibility

Policy-based compatibility of SOA states that services which interact with each other should look at each other’s policy, and should only communicate with each other if they satisfy each other’s policy requirements. These policies exist in the form of machine-readable language. If the services need to interact again in future, then the services should check the policy again.

These policies enable the developers to move the service from one platform to another without changing the behaviour of the service.

Shared schemas and contracts

A schema usually represents the data that a service passes. The contract represents the behaviour of the service, and contains information regarding the structure of the message. To enable a loosely coupled system, services pass schemas and contracts instead of classes and objects. Loosely coupled systems can be defined as systems in which the executing environment of a service does not affect another services. The information passed by these services is completely platform-independent.

To demonstrate its interest in SOA, Microsoft released Visual Studio 2005 to aid in the designing of service-oriented applications. Application Designer and Logical Datacenter Designer are among the few tools that help the developers and designers to build service-oriented applications. With the goal of achieving SOA nirvana, Microsoft then developed WCF, a unified framework for developing and distributing connected applications. monitors all leading technology stories and rounds them up to help you save time hunting them down.