When J2EE (Java 2 Enterprise Edition) became a mainstream standard about five or six years ago, EJB (Enterprise Java Bean) technology was sold by many evangelists as the silver bullet for every software problem. Organizations, so we were told, would now be able to minimize development time by utilizing container-provided features. Among those were object persistence and object/relational mapping, transaction handling, security, distributed objects and remote connectivity, etc. Simply put, all the problems that were supposed to be at the top of the priority list of most development organizations were now going to be solved single-handedly by using this new way of writing applications.
Consequently, most development organizations started to use EJBs heavily. Maybe not most of them, but certainly the ones that considered themselves at the forefront of innovation.
In 2001, I worked as a consultant on a trade-and-exchange web application for petroleum products. The client was a dot-com startup. We were using a product, MarketExchange by a company called Idapta. MarketExchange was a Java framework for auction and trade sites, and it was highly praised by the press – probably because it made heavy use of EJBs. As we eventually found out, every bidding transaction was represented internally as an Enterprise bean. Not surprising to us (the more surprising to Idapta’s support staff), the application did not perform, no matter how much hardware you threw at it. If there was more than a handful of users active on the site and bidding concurrently, response time went up into the minute timeframe.
We tried for a while to work with the vendor on the performance problems, but eventually gave up and wrote our own auction engine that did not use EJBs. It did not help the client much (Fuelspot.com), since their business model never produced any revenue, and they went out of business soon thereafter. If you Google fuelspot.com today, you will only get a few press releases and the résumés of former consulants and staff :-).
Needless to say, the vendor of the failing product, Idapta, did not have a bright future, either, and went under without the much predicted success stories. But I am grateful, since a got a trip to Atlanta for a 3-day training class at the Idapta offices out of this engagement, and I have not managed to get back to Atlanta since.
I am bringing these days back into the reader’s memory, because I believe that similar stories happened all over the country, probably all over the world.
I recently took over ownership of a portfolio of applications at an insurance company. Part of my portfolio is a small early-stage SOA infrastructure, and it appears that much of it was done for the sake of SOA, not because it made sense. There is a web service for logging errors to the database, for instance. Not a bad idea, unless you forget to implement any other means of logging in your application. There is another web service that does XML transformations. This one is used by a single application, which is itself heavily coupled with all sorts of XML transformation APIs. There is also a set of services that do useful things, but at what cost! The software engineers who are trying to fix bugs are complaining about three factors that make their work difficult:
- The application code lacks clarity because of its distributed nature
- Debugging is difficult
- The services introduce layers of application complexity that serve no other purpose but to enable services
And so I am learning the hard way what SOA does to my application infrastructure: it makes it awfully difficult to maintain. Unfortunately, it is already there, and it is working. How do I explain to the business that they could have saved hundreds of thousands of dollars by not going SOA? Down the drain go cost-effectiveness, speed to market, openness, and the love of my CIO.
Of course there are many more examples of technology hypes in the software industry. Client-Server, distributed object frameworks, multi-media, object-oriented databases, the list goes on. The pattern is always the same. Someone packages an idea that addresses a particular angst of many software development managers and IT executives who lack the ability to see through the fluff, wraps it into a compelling story, and the media picks it up and spreads it out like news of free beer. Unfortunately, many software development managers and IT executives have a hard time coming up with a sound and sane strategy for successful software applications on their own, and rely on bulls…, pardon, garbage dished to them by semi-knowledgeable journalists, book authors, and most persistently, sales people.
It seems that when used carelessly, EJBs made applications unusable because they did not perform, which was noticeable very soon, during prototyping or after the first components were tested. This made many development projects research alternative approaches before it was too late. With SOA, the problem is in maintainability and the long-term cost of ownership, both of which only hit you when it is too late to correct the course. Finding and retaining SOA-skilled workers who can maintain a complex network of services is only one additional difficulty that I am facing. None of this is apparent during development, though, and it may not become apparent until the first generation of engineers has jumped ship, which can be years after a SOA project is complete.
In my opinion, this makes SOA a hype that is a lot more dangerous than previous ones.
Nobody would design a web application for an auction site today with EJBs. I bet that 5 or 10 years from now, SOA will be a niche technology for very specific integration problems, but it will have disappeared from most middle-of-the-road enterprise applications.
The answer to the question what EJBs and SOA have in common therefore is: both are powerful concepts that were introduced with hyped expectations. Both were/are being used in ways that created poor overall results. The difference is that the performance issues caused by overuse of EJBs were apparent immediately, but that maintainance issues caused by overuse of SOA will not be apparent for some time after they are built.
Disclaimer: For the record, I am not denying the need for application integration, nor am I not recognizing the value of a services-based architecture. In fact, the most elegant application architectures that I have seen were very service-based, albeit written in the sixties using Cobol and CICS. I do criticize, however, the lemming-like adoption of web services and XML as a means of exchanging data, when the overhead can easily be avoided.