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 objects—such as Enterprise JavaBean (EJB) components in a J2EE world—and 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.

Myth 2: SOA Implies a Distributed System
When most developers hear about an SOA, they envision a complex, multitier, distributed system spanning multiple machines possibly spread across multiple locations. Some SOA systems might actually need to be like that, but most don't.

Once again, remember that SOA is an architecture concept that is all about service providers, service consumers, and the services offered by the provider to the consumer. It doesn't necessarily involve components being distributed on separate machines, or for that matter, distributed in any manner at all. As long as an architecture can clearly delineate between services, providers, and consumers, it can be classified as an SOA. Obviously, I assume that the architecture follows other guidelines such as loose coupling and stateless services.

Unfortunately, most developers immediately associate SOA with a distributed system and as a result start designing and implementing the entire middle tier (or the service layer) as EJB or COM+ components. In most cases, these can just as easily be implemented as Singleton objects, such as Plain Old Java Objects (POJOs) in J2EE, with much better application scalability and performance. The reason is that the (often) unnecessary distribution results in performance degradation because cross-machine calls (and even cross-process calls) are exponentially slower than intra-process calls. Of course, you would design the system (using a Service Locator pattern) to support distributed services if they were required in the future.

The net take-away here is that services (and SOA) do not imply any distribution semantics.

Myth 3: SOA Equals Web Services
Most people talk about SOA and Web services interchangeably. This is fine in most cases, but it is important to understand that they are not the same. SOA is an architecture concept, whereas Web services is an implementation concept. This might not seem like a significant difference until you realize that the difference is similar to that between mammals and humans. "Mammals" refers to a class of species with common characteristics (such as a specific type of architecture). All human beings are mammals, but not all mammals are humans. Similarly, all Web service implementations can be classified as SOA, but not all SOA implementations are Web services.

A Web service is a specific implementation of the concepts espoused by SOA that leverages various standards such as XML, SOAP, WSDL, HTTP, and so on. You can also build SOAs using other technologies such as CORBA, J2EE, and Microsoft COM+ (or .NET) without using any Web services. The net take-away is that an architecture does not have to use Web services to be classified as an SOA. In other words, whether you use Web services is a secondary decision you make after you decide to use SOA.

Most SOA articles follow a similar pattern: define SOA; promote its benefits; and optionally provide a few best practices. I deliberately strayed from the rest of the pack by discussing three common and pervasive myths in the SOA world. Sadly, SOA is associated with a myriad of myths beyond these three.

Luckily, as long as you remember that in its simplest form, an SOA is any architecture that can, at least on a logical level, be decomposed into three categories of components—a service, a provider of the service, and a consumer of the service—you won't fall prey to these myths, no matter how tempting they might be.

About the Author
Tarak Modi is a senior specialist with North Highland, a management and technology consulting company. His professional experience includes working with COM, MTS, COM+, .NET, J2EE, and CORBA. He is a coauthor of Professional Java Web Services (Wrox Press, 2002). Visit his personal Web site at http://www.tekNirvana.com.