Brian Vargas has a good response to James Avery's ruminations on SOA vs OOP.

In response to this comment in Brian's post:

Use objects when everything is a single whole, and where the interfaces between the subsystems won't be changing much. Even if you're cross-process, if interfaces aren't going to be changing, then just use remoting.

I agree and I disagree. I think the choice between OO and SOA comes down to a question of boundaries (a point brought home from the PDC this year).

Every well-designed system is subdivided by a set of logical boundaries. Sometimes these boundaries are purely logical, and sometimes they also imply a physical separation. The presence of a physical separation is not necessarily an indicator one way or the other; you can use distributed object technologies to span remoting boundaries, and you can use web services to communicate between two processes on the same box. So the architecture of the solution (SOA vs OOP) is not necessarily indicated by the physical deployment scenario.

Every boundary has two sides. The motivation for choosing SOA vs OOP comes not in how far apart those two sides are, but from the assumptions you can make about who controls those two sides. Are both sides part of the same conceptual system? Can you guarantee that they will always evolve together and will be simultaneously versioned, always? Can you guarantee that the boundary you’re creating will never be used for purposes outside of its original design? Will you retain control over both sides for the life of the system, so you can guarantee these assumptions over time? If so, the by all means – use a distributed object technology and knock yourself out.

However, there are many scenarios that warrant an SOA approach. Do you want to be able to evolve both sides of the boundary independently? Will the future bring new consumers of the functionality you’re creating now, and would you like *those* systems to be able to evolve independently of one another?  Do you only retain control over one side of the boundary, so that others may come and use your functionality as they see fit? If you answered “yes” to any of these questions, I think you want to be looking at SOA.

The difference between SOA and distributed objects is the distributed objects are optimized for a client/server scenario consisting of a single application. The classic DO application has two parts: a client and a server, but it's still one logical application. SOA is optimized for the polyapplication model -- the “server“ app and the “client“ app(s) are logically separate entities, each with their own lifecycles. People have tried to build the polyapplication model using DO technologies and got sever headaches -- which is why we have SOA today.

Do nondistributed object heirarchies have a place in SOA? Absolutely. Use services to expose rich functionality via simple interfaces, and use object heirarchies of arbitrary complexity to implement that functionality. However, no external entity should ever be directly exposed with your behavioral object heirarchy -- any cross-boundary interaction that implies behavior should take place via services only.

(on a side note: Vargas, where are your permalinks? your rss feed smells funny...)