SOA a Little Bit of Everything

I have been reading a few articles on the internet and in various documents that tend to come to the conclusion that web-services and BPEL are the answer to all problems, in much the way that CORBA, RMI, J2EE (insert technology of choice) were touted in previous years. I would suggest to the contrary that there is a swing away from this viewpoint. Twelve months back web-services were the key thing, I cannot tell you how many people I spoke to said that they had made every object a web-service, followed by a knowing smile that all was right with the world. Now I am starting to hear that those same people are adopting a different approach to SOA infrastructure because the overhead of web-services is too high.  Again similar statements were heard after the initial implementations of CORBA and other remoting technologies as people went from theoretical to practical.

Why is the overhead too high? Because every invocation is across the network, XML tends to be heavier than its compiled cousins, such as J2EE. Now apply that cost to every fine grained operation, such as transformation and the overhead of the web-services invoked will soon be higher than the business process that is being implemented. There is also a dollar cost to web-services that many people tend to ignore, such as that associated with hardware load balancers, XML firewalls etc. Now all the web-services that a developer created using their favorite build tool, suddenly do not appear so cheap by the time I get it into production and buy expensive hardware for maintenance.

The key with SOA as with any technology is to ensure it is composed in the correct manner, and a good architect will always strive to do just that. Architects understand the various tradeoffs with each technology and make them fit together for a complete solution. That said, no one technology will solve all the problems, and as such we should remember that SOA is really a way to achieve agility in the enterprise and that comes with some sort of cost. Let's face facts, if we wanted performance over agility we would all be writing in assembly language.

SOA What?

Good software engineers/architects will always be that as long as they apply the reasons that they were good in the first place: keeping an open but skeptical mind. Use SOA for what it is best for; orchestrating various technologies at various levels within the enterprise and more importantly, starting to break down the corporate / technology boundaries to better serve the business. A good solution will consist of more than BPEL and web-services to get the right blend of agility, federation and performance.