Before I state my beliefs, perhaps I should clarify that when it comes to SOA I am still a relative beginner and am going on what I have read from people like Clemens Vasters.

As a developer, one thing I truly appreciate about SOAs are the seperation between data and the operations that can/can’t be done on that data. In a world where sharing data is becoming increasingly easy and important, I think this is a vital distinction to make. The only reason I was pointing out the difference between OOA and OOP, was to say that the implementation of the services themselves can often take advantage of different aspects of OOP.

As for implementing an SOA vs OOA, I think there are other issues that need to be considered other than just making the problem disappear. I think an important thing to consider is simplicity vs. simplexity. There is no “silver bullet” that will solve all problems. I believe there are simply situations that an SOA is overkill for. For example, a personal website, or a simple RSS feed generator. However, when dealing with a series of (perhaps complex) business rules for an enterprise application, I think an SOA is a better fit by default then an OOA. This may very well be common sense and I may be “preaching to the choir” but I thought I would lay that out there.

Overall, I would just say keep up the great work and I look forward to hearing what you have to say in the future.

The reason that I refer to the OO paradigm, and not just to OOA, is because of the statement that “everything is an object”. The “everything” points me in the wrong direction. Although it doesn’t explicitly state that I should interact with objects directly all the time, style RMI, I find that that’s exactly what happens. This introduces all sorts of problems.

When I see a problem, my first reaction is not to look for the “tool” to fix it – AOP for interception in order to enforce business rules – but rather try to make the problem disappear by itself by changing my way of viewing the world. As was shown in the article, the business rules “problem” of interception just disappears when going the SOA route.

Because of this perception of the world, I am constantly looking for problems that I am currently having that can be evaporated ( TOC ). I am even proactive, currently looking for problems in the SOA that may be evaporated in yet another world view.

Just a quick note, I think the line should be drawn between SOA and OOA, not SOA and an OO paradign. This is because the actual implementation of the services are in an OO paradigm. That’s just knit-picking though. Greg opinions!