Simplifying SOA

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

Sincerely put, and you may already have read it in this blog, server-side web UIs are dead. It’s just too cumbersome to create and control a server-side UI while all the action is going on the client side. In the case of browsers, this mean we will be, and already are, writing a lot more JavaScript than in the past, and the creation of client-side frameworks such as dojo, Prototype, jQuery, etc, make it even more clear that JavaScript is the de-facto interactive language for the browser. People want richer and faster UIs, and that means they don’t want to wait for a page post after they do something as simple as creating a record in some database application.

Google has created an specification that is being widely adopted for web 2.0 applications. It has a lot of nifty “social” stuff, but it also has one main component, the Widget Container. Everyone reading this blog must be familiar already with iGoogle, yourminis, pageflakes, or some other sort of start page that contains a lot of widgets. Well in my own vision, that is the portal of the future. A couple small, JavaScript driven applications that are aggregated and served together, client-side. An implementation of this is available TODAY under the Apache Shindig project.

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.

Leave a Reply

Your email address will not be published. Required fields are marked *