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!

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: http://www.w3c.org/TR/ws-gloss/). 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.