SOA: Debunking 3 Common Myths
What is SOA's relationship to object-oriented technology, distributed systems, and Web services?
by Tarak Modi
September 1, 2004
Imagine this scenario: Two software professionals are fraternizing over drinks at a cocktail party. One of the software professionals starts describing her product's architecture, and upon seeing a slightly perplexed look on the other professional's face, proudly states that it is a service-oriented architecture (SOA). The look of confusion transforms into one of admiration and satisfaction. After all, everyone knows what an SOA is, right?
Like any other technology that is "better than sliced bread," SOA has its fair share of myths. I'll dispel three common myths surrounding SOA, so that in the worst case, these myths won't manifest themselves as poor architecture or design decisions during an SOA implementation.
Myth 1: SOA is an Object-Oriented Technology
Many eons ago, software developers used a methodology called Structured Programming, which involved continuously dividing the initial problem into smaller pieces until each piece was ultimately implemented as a procedure. You could combine multiple procedures into reusable libraries. A distinguishing characteristic of the procedures was the large number and size of the parameters passed to the procedure call.
Over time, this style was replaced by object-oriented (OO) and then component-based programming. Objects and components that represented real-world concepts and exposed fine-grained properties through getter/setter methods replaced procedures. Today, the world revolves around SOA, and programmers have naturally carried their OO skills to this new realm.
This is a big mistake. The natural tendency is to assume that SOA evolved from OO and is therefore an OO technology. This is a fallacy. SOA has nothing to do with objects and components. It is all about service providers, service consumers, and the services offered by the provider to the consumer. Consumers couldn't care less whether these services are OO or not.
Furthermore, because most SOAs are deployed in a distributed environment (Myth 2 discusses this), creating OO-type services can hurt performance significantly. I have seen many IT teams expose fine-grained objectssuch as Enterprise JavaBean (EJB) components in a J2EE worldand then wonder why their applications face scalability and performance challenges. The correct way to do this would be to introduce an orchestration layer (also known as a Session Façade or a Business Delegate) that exposes services and in turn uses the fine-grained objects.
The net take-away is that services in an SOA are not distributed objects in OO. In fact, you might think of an SOA as a structured layer on top of an OO system.
Back to top