One of my recent clients had an entire suite of applications that was built on an in-house messaging framework. Several years ago, when not many Java frameworks existed in the market and J2EE was still a few years away, this would have been considered a good thing; today, any new development on a proprietary framework takes the client further away from fully leveraging the facilities offered by J2EE. Although there is definitely a strong push to move to a J2EE enterprise type of environment, migrating legacy systems to J2EE is a formidable undertaking.

While this problem can be tackled in a piecemeal manner, one of the main issues in such an environment is the inability to conceptually move outside the box. Two main thoughts float up in any architecture initiatives ­ EJBs are slow and applets are bad. These opinions are based on some antiquated information, but can also be attributed to slowness on the part of the vendors to support enterprise APIs. Case in point, not all the leading J2EE vendors are EJB 2.0 compliant. And EJB 2.0 is really the first release that makes EJBs worth using in a large enterprise. Alternatives such as JDO have only recently appeared on the horizon.

In the absence of the main mechanisms for synchronous communication, what should you resort to? Messaging, of course. You can achieve every form of integration with a true and tested MOM and, for the most part, synchronous calls can be simulated through messaging. However, there is obviously a price to pay ­ performance. But if this is now the accepted norm, any new development needs to stay in the same box.

How did it come to this? I'd say J2EE vendors are to blame. The Java platform is oversold in terms of its capabilities and promise of future enhancements. Then it takes a long time for the market to catch up on the promise (we all know about the delays in subsequent releases). In the meantime, the enterprise tries out what currently exists in the platform, makes go/no-go decisions, tables the rest for later, and moves on. Moving on means that after evaluating the alternatives, more in-house development takes place than necessary, and product suites are built with an eye on the future and migration strategies in place. However, the longer it takes for the platform to mature, the more the clients become ensconced in temporary solutions.

At the end, when vendors do come with a richer set of offerings that can address enterprise issues, it's too late to move the customer out of the box in which he or she is now comfortably asleep. As a result, full-fledged J2EE application server environments end up being used for only a fraction of their abilities, such as serving up Web pages.

One factor that consolidates the execution and development environment is the right IDE. Disparity in IDEs and their capabilities confuses the issue of the capabilities of J2EE and its execution environment. Fortunately, there are initiatives in the industry for creating a common API for Java development tools. JSR 198 - the Standard Extension API for Integrated Development Environments, recently submitted by Oracle, is an attempt to tackle disparity in IDEs.