Service-Orientation vs Object-Orientation - can they coexist?

Question

There's been a lot of interest in Service-Oriented Architecture (SOA) at my company recently. Whenever I try to see how we might use it, I always run up against a mental block. Crudely:

• Object-orientation says: "keep data and methods that manipulate data (business processes) together";

• Service-orientation says: "keep the business process in the service, and pass data to it".

Previous attempts to develop SOA have ended up converting object-oriented code into data structures and separate procedures (services) that manipulate them, which seems like a step backwards.

My question is: what patterns, architectures, strategies etc. allow SOA and OO to work together?

---

Edit: The answers saying "OO for internals, SOA for system boundaries" are great and useful, but this isn't quite what I was getting at.

Let's say you have an Account object which has a business operation called Merge that combines it with another account. A typical OO approach would look like this:

Account mainAccount = database.loadAccount(mainId);
Account lesserAccount = database.loadAccount(lesserId);

mainAccount.mergeWith(lesserAccount);

mainAccount.save();
lesserAccount.delete();

Whereas the SOA equivalent I've seen looks like this:

Account mainAccount = accountService.loadAccount(mainId);
Account lesserAccount = accountService.loadAccount(lesserId);

accountService.merge(mainAccount, lesserAccount);
// save and delete handled by the service

In the OO case the business logic (and entity awareness thanks to an ActiveRecord pattern) are baked into the Account class. In the SOA case the Account object is really just a structure, since all of the business rules are buried in the service.

Can I have rich, functional classes and reusable services at the same time?

Answer 1

I really think SOA is only useful for external interfaces (generally speaking, to those outside your company), and even then, only in cases when performance doesn't really matter, you don't need ordered delivery of messages.

In light of that, I think they can coexist. Keep your applications working and communicating using the OO philosophy, and only when external interfaces (to third parties) are needed, expose them via SOA (this is not essential, but it is one way).

I really feel SOA is overused, or at least architectures with SOA are getting proposed too often. I don't really know of any big systems that use SOA internally, and I doubt they could. It seems like more of a thing you might just use to do mashups or simple weather forecast type requests, not build serious systems on top of.

Answer 2

My opinion is that SOA can be useful, at a macro level, but each service probably still will be large enough to need several internal components. The internal components may benefit from OO architecture.

The SOA API should be defined more carefully than the internal APIs, since it is an external API. The data types passed at this level should be as simple as possible, with no internal logic. If there is some logic that belongs with the data type (e.g. validation), there should preferably be one service in charge of running the logic on the data type.

Answer 3

SOA is a good architecture for communicating between systems or applications.

Each application defines a "service" interface which consists of the requests it will handle and the resposes expected.

The key points here are well defined services, with a well defined interface. How your services are actually implemnted is irrelevent as far as SOA is concerned.

So you are free to implement your services uing all the latest and greatest OO tequniques, or any other methodoligy that works for you. ( I have seen extreme cases where the "service" is implmented by actual humans entering data on a screen -- yet everything was still text book SOA!).

Answer 4

I think that this is a misunderstanding of object orientation. Even in Java, the methods are generally not part of the objects but of their class (and even this "membership" is not necessary for object orientation, but that is a different subject). A class is just a description of a type, so this is really a part of the program, not the data.

SOA and OO do not contradict each other. A service can accept data, organize them into objects internally, work on them, and finally give them back in whatever format is desired.

Answer 5

I've heard James Gosling say that one could implement SOA in COBOL.

If you read Alan Kay's own description of the origins of OOP, it describes a bunch of little computers interacting to perform something useful.

Consider this description:

Your X should be made up of Ys. Each Y should be responsible for a single concept, and should be describable completely in terms of its interface. One Y can ask another Y to do something via an exchange of messages (per their specified interfaces).

In some cases, an X may be implemented by a Z, which it manages according to its interface. No X is allowed direct access to another X's Z.

I think that the following substitutions are possible:

Term      Programing       Architecture
----    ---------------    ------------
  X         Program           System
  Y         Objects          Services
  Z      Data structure      Database
----    ---------------    ------------
result        OOP              SOA

If you think primarily in terms of encapsulation, information hiding, loose coupling, and black-box interfaces, there is quite a bit of similarity. If you get bogged down in polymorphism, inheritance, etc. you're thinking programming / implementation instead of architecture, IMHO.

Answer 6

If you allow your services to remember state, then they can just be considered to be big objects with a possibly slow invocation time.

If they are not allowed to retain state then they are just as you've said - operators on data.

It sounds like you may be dividing your system up into too many services. Do you have written, mutually agreed criteria for how to divide?

Adopting SOA does not mean throw out all your objects but is about dividing your system into large reusable chunks.