What exactly is SOA?

SOA stands for service-oriented architecture, and that’s about all everyone involved agrees on. I can say without hesitation that it’s one of the biggest buzzwords of recent years, splitting the IT world into devotees and detractors. I’ll try to set any sympathy for either side aside and explain what SOA means to me.

Put simply, SOA sets boundaries for the architecture of an application or part of one. The application makes certain services available to the outside world. The service is the smallest unit the application exposes. What, then, is a service? It could be anything, from this blog’s RSS feed to Google search or a warehouse application’s inventory report.

SOA sets no standard for how a service must be exposed, for instance which communication protocol it uses. It says even less about how to implement the service itself. There are a few criteria a service should meet. The really important one is to define its contract. That matters to both the service and its client, because it defines the interface the provider and consumer use to communicate.

Provider and consumer are two more terms SOA introduces. A service interface should meet several criteria.

• Platform independence. The service puts no implementation requirements on clients, so it can interoperate with clients in different environments.
• Hide the implementation. The service strictly encapsulates its implementation so it can be changed without affecting the client.
• Document it. The documentation is the only description the consumer has and the one it must follow. It can’t look inside the service, and even if it could, it shouldn’t rely on what it finds.

Take this blog’s RSS feed as an example of a service.

• It’s platform-independent because it’s XML.
• It hides its implementation. The client doesn’t know who or what produces it, or how.
• It’s documented by the W3C RSS specification.

A client needs nothing else to use the service. The blog metadata supplies its endpoint, the address where it runs.

There are plenty of myths and half-truths about SOA. One is that SOA means web services. Web services are simply one way of implementing a service contract. Google’s service contracts today, for example, are defined using REST, which is more interoperable and asks less of clients.

Another myth is that SOA is for large applications so they can talk to one another. Service orientation has to do with the application’s requirements, regardless of its size. On the web it’s been given another buzzword, Web 2.0. You can see it as an ordinary evolution in application architecture. A strong argument for services is that they make things far more reusable at the application level.

Service orientation has also led to growth in related areas. Service orchestration, for example, lets you combine services into larger units. That’s an addition on top of the basic idea. A lot of companies try to make money from it while blowing more air into the SOA bubble.

SOA isn’t rocket science and won’t become it. Don’t let anyone pull the wool over your eyes. I recently read about a report from an analyst firm I won’t name claiming that SOA will kill enterprise Java. That’s nonsense, to put it mildly. Java already has everything you need to build service-oriented applications.