Web services are great. They allow for loose coupling between applications that use different technologies, are developed and hosted by different organizations, are asynchronous with one another, and so on…all for the low, low price of encoding the request, sending the request over HTTP, deserializing the parameters, serializing the result, sending the result over HTTP, and decoding the result. Well, OK, not that low a price. But what you get for it is pretty impressive.
Sevice-Oriented Architecture (SOA) is the idea of structuring entire applications around web services. Business service implementations are deployed entirely separately from one another and from view/controller implementations, and published as web services. Applications that need to retrieve, analyze, or change data contact the web services to do so. Lots of people love SOA. I’ve even met a fair number who love SOA so much that they think it’s the only reasonable architecture for enterprise applications.
Now, don’t get me wrong here. I’m not anti-SOA. I think it has many, many great use cases, such as:
- You have customers or partners with their own development teams, and they want to be able to make use of your services in their own applications
- You have business services that truly need to be reused in many applications, and those applications are developed using different technologies (you might instead want to consider just sharing stateless EJB session beans, or POJO session facades deployed to a location included in all classpaths, if they’re all Java EE apps)
- You’re in a very large development group, and you need to strictly enforce dependence on interfaces rather than code, and ensure that everyone is coding to the same (deployed) version of the service implementations, rather than a zillion development JARs
- You’re in a disparate development environment, where different applications need to be deployed on different servers and still share business services.
If you’re in any of those situations, which a whole lot of people are, then SOA could be anything from a perfectly reasonable architecture idea up to an absolute architecture must.
But what if you’re not in any of the above situations? Suppose you’re designing one of a small number of web applications, all implemented in Java EE, for a small organization. These applications are for end users, or possibly for very non-technology-oriented partners or client organizations, so the chance of someone wanting to code to your services is small. To make things even more extreme, let’s assume that there are no, or at least very few, places where these applications use the same business functionality; each application is designed to handle a totally different business function. They may share some data, but of course that’s what a DB is for, right? They all do fundamentally different things with the data.
There are an awful lot of people in that situation. If I had to hazard a guess, I’d say that there are more people in that situation then there are people who have any of the use cases above. Should they consider a heavily service-oriented architecture?
Sure, if they like overhead. SOA may be elegant, but the fact is, if all you have is applications where unique services are needed by unique, local, same-technology view/controller application portions, it doesn’t really get you anything. And the costs–encoding, HTTP round trip, serialization, deserialization, decoding–while perfectly reasonable if you have a real use for such amazingly loose coupling–are just a waste of time (both at runtime and design time!) if you don’t.
So, SOA: Really great? Yes. An architecture that supersedes Java EE-style enterprise architecture? Not hardly.