Service Oriented Architecture (SOA)
Service oriented architecture (SOA) is an architecture where independent systems and applications communicate with each other by exposing and using services. Services are defined using open standards, making inter-communication much easier to implement, and less dependent on proprietary communication protocols.
From DOA to SOA
SOA follows the idea of a Distributed Object Architecture (DOA) where objects in applications could move around freely between servers and call each other remotely etc. The idea was that an object calling another object should not have to know whether the called object was residing locally, or remotely. This should be transparent to the calling object.
This architecture is slowly being abandoned, as too fine grained distributed object communication is both very complex, and does not perform well.
Distributed objects are complex because there are more error possibilities when calling a remote object, than when calling a local. For instance, you typically need two phase commit transactions to coordinate a distributed transaction, where a single phase transaction may do locally.
Additionally, you had less control over the communication overhead incurred from unnecessary out-of-process communication, and from moving objects between "containers" or "servers" behind your back. Thus application designers wanted to be able to control location of objects, to lower complexity and increase performance.
|A distributed object architecture.|
Instead larger grained less mobile services have been introduced - SOA. Service can move, but they typically do not move as dynamically as people imagined distributed objects would. Additionally, when you call a service you are typically aware that you are calling a remote entity. This means that you have better control of both complexity and performance.
|A service oriented architecture.|
Some people sarcastically say that SOA stands for "Same Old Architecture" - which is actually not that far from the truth. Todays services are strikingly alike yesterdays remote procedure call protocols. The main difference is that today services are more and more communicating via open standards, like SOAP, REST etc. meaning the communication layer becomes easier to implement. SOA is not, however, the big increaser of "Return on Investment" as some authors wants you to believe.
Another difference is that SOA introduces a set of new concepts, and attempts to standardize some existing concepts across the industry. Some of these concepts are:
- Enterprise Service Bus
- Service Composition
- Service Transactions
- Service Repositories
- Service Orchestration
I will get into many of these concepts in later texts in this trail.