Thomas Erl defines SOA as follows in his site:
Service-oriented computing represents a new generation distributed
computing platform. As such, it encompasses many things, including its
own design paradigm and design principles, design pattern catalogs,
pattern languages, a distinct architectural model, and related
concepts, technologies, and frameworks.
This definitely sounds like a whole new category which is parallel to object orientation. Almost one in which you would expect an entirely new language to exist for. Like procedural C and object oriented C#.
Here is my understanding:
In real life, we don’t have entirely new language for SOA. And most application which have SOA architecture have an object oriented design underneath it. SOA is a “strategy” to make the entire application/service distributed and reliable. SOA needs OOPS working underneath it.
Is this correct? Where does SOA (if at all it does) fit in with object oriented programming practices?
Edit: I have learnt through answers that OOA and SOA work with each other and cannot be compared (in a “which is better” way). I have changed the title to “Relationship between SOA and OOA” rather than “comparison”.
2
OOP is a programming paradigm. SOA is a system architecture concept.SOA can be implemented using OO code (or any other type of coding, it does not matter). OOP can be part of a SOA architecture or can be used outside of that architecture. OO and SOA are two different concepts (level wise). We could for example compare SOA based architecture to non-SOA based architecture or compare OOP to Procedural Programming used in languages such as COBOL II. However, comparing SOA to OO would not be valid.
SOA needs OOPS working underneath it.
I don’t agree. OOP is optional.
SOA is a “strategy” to make the entire application/service distributed and reliable
True (purists may argue about exactness of the wording though…).
Edit:
I have added this section in response to first comment below:
Think of a Service as a black box. The way the service is built internally is not your concern (this is generally a good thing). You mainly focus on consuming the service via its API. Whether you do this via classes in an OO program or even via URL request on the browser as in this example: http://ichart.finance.yahoo.com/table.csv?s=IBM&a=1&b=1&c=2010&d=1&e=1&f=2012&g=d&ignore=.csv, if you click this link Yahoo Finance will get you a CSV file of stock information. No class on the client was required. The magic is hidden inside the service.
Frameworks such as Microsoft WCF provide means of communicating with services via different methods and handles lots of the details required to build a rich service environment. You may want to look for more details on WCF.
2
Well, I think your question falls somewhat into the domain of this question: What’s the next level of abstraction?
There I’ve made a similar inquiry (in the comments) regarding Aspect Oriented Programming, i.e. is it a different level of abstraction (other than OOP) or not. The conclusion there was that it’s not, it’s simply a different approach to using OOP. I think the same goes for SOA. The data and algorithm abstractions needed for something that could be called SOA are pretty much the same as those used for something that can be cathegorized as OOP.
Continuing on this idea, what you’d need to better develop SOA software is libraries and frameworks that deal with the boiler plate code, rather than a new language, and I believe this is the case today, you have such frameworks as Mule ESB and Spring Framekwork.
Here’s an interesting discussion of different way to take on SOA, and how Spring helps you with it:
http://forum.springsource.org/showthread.php?25892-SOA-Vs-Spring
1