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
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.
Ajit Sagar is the J2EE editor of JDJ and the founding editor of XML-Journal. He is the director of engineering at Controlling Factor, a leading B2B software solutions firm based in Dallas, and is well versed in Java, Web, and XML technologies.