SOA, in the simplest form, is the design/platform to develop software in the form of interoperable services.
It has a lot of things in common with SaaS, and some people even say that CloudComputing/PaaS is an offspring of SOA.
Here is a good slide about fundamental of SOA (from Jaguaraci Silva):
Nice explanation – of Enno Shioji – about ‘loose-coupling’ of SOA services:
“Let’s assume you have 4 cooks. In SOA, you assume they hate each other, so you strive to let them have to talk to each other as little as possible.
How do you do that? Well, you will first define the roles and interface — cook 1 will make salad, cook 2 will make soup, cook 3 will make the steak, etc.. Then you will place the dishes well organised on the table (so these are the interfaces) and say, “Everybody please place your creation into your assigned dishes. Don’t care about anybody else.”.
This way, the four cooks have to talk to each other as little as possible, which is very good in software development — not necessarily because they hate each other, but for other reasons like physical location, efficiency in making decisions, etc. . .”
Another good explanation – of AlexKR – about ‘availability’ and ‘specialized services’ in SOA:
“For non technical people I would use the following concept. The whole professional world is service oriented.
– Instead of baking a cookie by youself, you go to the baker.
– Instead of trying to cure yourself, you go to the doctor.
– Instead of writing a program, you ask a programmer to do this for you.
This implies two major advantages: Each one does his job better than if we all were trying to solve all our tasks separately. There is a way, which allows non professionals to communicate with those, who will solve our task (in real world such way is money and business contracts).
In the world of software such architecture is implemented by defining specialized services (applications) which are dedicated to perform specific tasks and by defining protocols, which are solving problem of communications between such applications. When such architecture is deployed, you get some benefits, which can be also mapped to the real world:
– If doctor is unavailable, you cannot be cured but at least you can get a cookie from the bakery! In software this means one failed service does not break the whole system.
– Usually doctors and bakers do not share the same room and this allows them to operate better. Just like in software you can place each service on its own hardware.
For software world this means, better availability, maintainability, reuse, and reduced costs. Good luck!”
It’s fun , isn’t it ?