We’ve seen a lot of buzz around the SOA acronym lately. Service Oriented Architectures are one of the hottest topics in IT today, and for a series of reasons. Some of them are legitimate, and others not quite.
More and more vendors strive to gain space into the SOA Infrastructure market. They push you ESBs, they push you Portals, they push you Repositories, Registries, they even repackage their fancy old EAI hubs into a new “SOA” packaging and try to get you into believeing it’s a must-have.
Lie #1 – You need SOA Infrastructure
The truth is, SOA can be realized with NO TOOLS. All you need to do is create services while you are developing (Stateless Session EJBs anyone?) in a manner that they are reusable. Reuse and encapsulation (sounds familiar from object orientation principles eh?) are the major drivers for an SOA to be effective, and that can be accomplished without any tools, and more than that, it CANNOT be accomplished through tools alone. You current language of choice probably also provides all you need for out-of-the-box interoperability with other systems through Web Services, but that leads us to lie #2.
Lie #2 – SOAP over HTTP is slow
Some vendors claim that multi-protocol support is a must-have, and preach that HTTP/SOAP is slow. Most of those vendors try to push you into using SOAP over JMS, because it’s oh so much faster. Now think with me, you will be trasmitting XML either way won’t you? So how is JMS faster? OH you know what? They don’t want you using the “new” stuff, because they spent so much money in creating a nifty JMS engine back in the EAI days. That’s why HTTP is slow… get it? 🙂
Lie #3 – The main benefit in SOA is reuse, and using our “governance” tools you can have that
Back from lie #1, you cannot achieve reuse with tools. Reuse depends heavily on developer discipline to check all the available and under construction services before creating a new one. It also depends on the people creating services having a “vision” to not overspecialize services or service operations. Will a service Registry help? Well only as much as a text file with a list of all of your services. Ohh and what about repository, how can I keep track of service artifacts such as documentation? Well, use subversion, as you do for code… Quite obvious and simple isn’t it? You can even create a repository using maven that will be browsable and with just enough metadata in project descriptors (pom.xml) for people to find what they need.
Lie #4 – Portals are the past, present and future of web apps
Lie #5 – You need an ESB to orchestrate your services
Well the problem with this is the ORCHESTRATE word. Web Services Orchestration is covered by a number of specifications, but most notably WS-BPEL. BPEL was concieved from the ground up to represent an orchestration of services in order to achieve a final goal, be it producing a joint message of all the services it invokes, or executing a whole business processes.
Don’t be afraid though, ESBs are not a bad thing. They allow you to centrally manage, secure and monitor your services, while mantaining a service inventory that might even allow you to ditch excel and trust the ESB for you service catalog. They are also useful for infra-structure stuff such as fail-over, load balancing and throttling services, or for adding in asynchronisity to a synchronous service. Service “polishing” is also useful, for turning bad looking WSDLs into a nice canonical model that represents its real goal and not the technology it uses.
Despite all that, Martin Fowler and the ThoughtWorks team seems to think that squid is the only SOA infrastructure you’ll ever need, as can be seen on this presentation. Watch it, and let’s discuss that.