E-mail
SOA in a nutshell
SOA stands for Service Oriented Architecture, namely an infrastructure based on a collection of services, each service fulfilling one dedicated function/role for business. Two ideas concur to this design:- separating a function (what can I do with this data?) from its implementation (how is it done?);
- define each service as the smallest available function, then chain them as needed.
Note that in SOA vocabulary, service stands for a business-oriented service, to be distinguished from low-level techical services.
This design brings loosely-coupling between applications, thus making the whole system easier to adapt, more robust and flexible.
What is a Service Oriented Architecture?
In computing, a service-oriented architecture (SOA) is a flexible set of design principles used during the phases of systems development and integration. [...]
Rather than defining an API, SOA defines the interface in terms of protocols and functionality. [...]
SOA separates functions into distinct units, or services[1], which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications.[...]
A deployed SOA-based architecture will provide a loosely-integrated suite of services that can be used within multiple business domains.
Source: Wikipedia
From applications to services
Until a few years ago, organisations acquired softwares as they needed it. They's consider time and money investments, features, security, reliability... But didn't usually put integration within the infrastructure as a prime criterion. Because of this, each new application often meant significant investiments to connect it to the IS.
Furthermore, this new application could be partially redundant in features with another application in same department, or even another department.
With continuous growth of IS, the "infrastructure urbanisation" appeared: keeping an eye on the whole system, as much as a whole as in details, to have a clear view of which application for which use, for who. The objective being to avoid redundancy, and save time, money, while bearing system complexity.
However, one does not have a hand on inner mechanisms of its applications, unless he develops its himself. So, to minimize impact on the IS when upgrading/modifying/removing/adding an application, it's necessary to uncorrelate the data processing result of an application from its actual realisation.
Using applications that processes data in a standard/common format is a first step in the right direction, since it eases interconnection and data transformation. Still, having an application being directly requested for a processing means that each time you do something on it, you cannot access each and every features it provides.
Hence the idea of considering an application as "just the source" for a set of services. When you need a data processing, you call a service. You don't have to know which application will actually do the processing, nor where it is located. Thanks to this system, you can easily swap one business-oriented application for a better one, for example, without blocking ongoing processing. That is called "loosely-coupling".
You can also chain single services to build a coherent, business-oriented process, and modify it as needed to keep it fitted to your needs.
SOA Main benefits
- added interoperability, since it is designed to use standard protocols and formats.
- added flexibility, since you can chain services at will.
- added robustness, since you can duplicate services for added reliability and availability.
Learn more on SOA
Wikipedia information
Pragmatic SOA guidebook - 9 steps to organize your SOA project and get business results
SOA-based projects - 2010 Evolution forecast