Are SOAP Web Services the next EJB?

The Gartner Group has a device they call a Hype Chart that intends to show how expectations of a new technology effect adoption and acceptance. Here is an example Hype Chart:


Notice that when a new technology is born there is a flurry of excitement as expectations peak. During this phase industry pundits rave about how the new technology will transform the IT landscape making developers more productive, smarter, what have you. You’ve seen it a hundred times before, me too.

During the peak many companies adopt the technology, implement it, and start looking for the huge productivity gains (or cost reductions) that are sure to come. Only, they don’t seem to come, at least not in the quantities expected. At this point the technology enters the Trough of Disillusionment. What a cool name! This is when people start to realize that there really isn’t a magic solution to all their problems. The new technology may help but it still takes a lot of hard work to realize any gains.

Finally people determine how best to use a technology (or not use it) and enter the Plateau of Productivity where the usefulness of the technology is understood and expectations are in line with reality.

OK, so what does this have to do with EJB and/or SOAP Web Services. Well both of these technologies are are some point on this curve and are, in my opinion, headed for very similar endpoints.

Let’s start with EJB as it is the older technology and further along on this Hype Chart in terms of maturity. Let me start by saying that I believe EJB to be a major failure as a technology. If this pisses you off you might want to quit now while you can remain hating me just a little bit.

First let’s look at the problems EJB was intended to solve for enterprise developers. EJB was envisioned as a container for business components. The idea was that building enterprise class software is hard and enterprise developers aren’t really up to the task. EJB’s goal was basically to dumb down the process and encapsulate all the hard stuff like transactions, remote access, state management, thread management, etc.

Not only did EJB not dumb down the process, in many cases it made it much more complex. In addition it turned out that EJB containers were not all that smart and that many of the decisions they were making on behalf of developers were not that great. The result of this was for Sun to come out with a new version of EJB that was even more complex from the developers viewpoint to give the EJB container more information for make decisions with. In some cases things got a little better, in others they just got more complex.

I could go on but to what end? The general idea is that the whole implementation of EJB through about 5 versions went from bad to worse and many developers, including myself, who were big fans during hype peak became disillusioned and stopped using the technology. Lighter weight, open technologies like Spring came forward that offered most, if not all, the promised benefits of EJB without the mass of complexity.

If you’d like more information on this subject read Rod Johnson’s books:

1. Expert One-on-One J2EE Design and Development
2. Expert One-on-One J2EE Development without EJB

OK, now to the point of this article. It is my opinion that SOAP based Web Services are following the same hype cycle as EJB. Currently SOAP Web Services are all the rage and industry pundits are raving about how they, through the guise of SOA, are going to revolutionize the IT industry. Folks, it just isn’t going to happen.

Let me make a side comment here. Many people think that SOAP Web Services and SOA are the same thing. That is just not the case. SOA is a system architecture which encapsulates business functionality and offers it as a service to other applications. SOAP Web Service are just one of numerous ways to expose these services.

I think SOAP Web Services suffer from the same ills that plague EJB. They are complex and hard to debug. Generally errors are embedded under so many layers of generated code that the average developer has no chance of finding them. In addition, SOAP Web Services perform poorly in comparison to simpler technologies.

My guess is that over the next couple of years many people will become disillusioned with SOAP Web Services and move to simpler more effective technologies like REST Web Services or Hessian. I think I may be ahead of the curve on this one. I think these technologies, along with a few others, are the wave of the future and I am starting to move my work in that direction. In fact, given that most of my work with Web Services revolves around Java clients talking to remote Java services I’ve built a transport that is even simpler for the developer and works like a charm so far. I’m not trying to claim any big credit or anything, my solution is built on top of freely available and stable technologies like Apache Commons HttpClient, Java Reflection, and XStream. Incidentally, there is now a C# version of XStream.NET now so maybe this solution is not as platform specific as it seems.

Maybe I’ll write an article on it if there is any interest.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: