What's the benefits of SOA over OO? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or exper开发者_如何学Pythontise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

I want to know the differences between SOA and OO, and why SOA is going to popular?

---

SOA is getting popular, because it introduces several benefits:

• Makes your system more extensible
• Easier for use by third-party code, for example you client's clients and their systems
• It conserves your business logic and gives the ability to add additional presentation layers easier. This can be achieved in other methods, too.

These are the main benefits of SOA, I think. But you cannot compare OOP and SOA .. they're different things and they are not interchangeable. SOA is software architecture in general, on the other hand OOP is programming paradigm.

---

You can't really compare those two.

OOP is a programming language paradigm. Others are "functional programming" or "procedural programming".

You can use a OO language to use or create a service, but you could also use a functional language to do that.

In a nutshell SOA and OOP are two different things and you can't play them off against each other.

---

To put things in perspective:

• OO is a methodology for building applications in a single address space. The public contract is the API

• SOA is the architecture pattern for building applications that spans multiple address spaces (distributed applications). The public contract is the persistent data (ie. wire format) itself.

Before SOA, there was effort to extend OO to building distributed applications, the effort, called CORBA, utterly failed. One thing people learned is that building distributed application, you have to explict expose the wire format (the data), which OO attempts to hide... don't think services as RPC but instead as message producer and generators.