Java Retargets Enterprise
Sometimes it's not how accurately you hit the target, but how fast you can reload. A few years back, Scott McNealy and company introduced the Java Enterprise initiative. At the time, Microsoft had just released Microsoft Message Queuing and a new version of its transaction server. In a relatively scathing article, I wrote that Sun’s Java Enterprise had simply defined a set of interfaces that more or less matched the feature set of existing Microsoft products. It also seemed as though the actual implementation of the original Java Enterprise specification was left as an exercise for the user, vendor, or both. I accused Sun of shooting blanks -- making a lot of noise to take the focus off the real strides Microsoft had made toward a complete enterprise solution.
At the time, many Java fanatics accused me of working for Redmond. Now, Sun now apparently agrees with me. With the release of Java 2 Enterprise Edition (J2EE), compatibility with the original enterprise specification has been broken to accommodate a more thoughtful solution as well as a reference implementation from Sun. Enterprise Java Beans (EJB) vendors now admit that the original EJB specification was so vague that multivendor EJB solutions -- which were supposed to be Java’s big advantage -- became nearly impossible. With the arrival of J2EE and EJB 1.1, Java finally provides a well-considered alternative to Microsoft’s proprietary suite of enterprise tools.
Sun’s J2EE architecture is divided into four distinct pieces:
- A platform, specified as a set of required APIs and policies.
- An application programming model for developing thin, multitier applications.
- A compatibility test suite to verify that the platform is correctly implemented.
- A reference implementation to provide an out-of-the-box operational definition.
The user interface is the most obvious change in J2EE. Gone -- or at least de-emphasized -- is the idea of running a Java Applet on the client. In its place, J2EE has a double-barreled approach to dynamically generating Web pages: Servlets and Java Server Pages (JSPs). Servlets are pure Java programs that run on a Web server and usually produce HTML as a response to an HTTP request. Java Server Pages are a mixture of HTML and server-side Java scripting that make generating dynamic Web pages simpler: Think Microsoft’s Active Server Pages using Java instead of VBScript. I believe this new emphasis on thin clients is a smart move because Applets have a host of tricky deployment and performance issues.
A weapon that’s too complicated won’t fire when you need it, so Java has retooled a number of areas to use XML. XML is simple, human readable, and looks the same on all platforms. The Java Messaging Service now uses XML for asynchronous communication, while EJB uses XML for synchronous communication. XML is also used in J2EE deployment descriptors and can be generated by Servlets and JSPs. Finally, an XML API is available for creating your own XML solutions. It still appears, however, that synchronous interobject communication across the wire uses a binary protocol instead of an XML Remote Procedure Call
(RPC) protocol, such as SOAP. Binary protocols are more efficient, but XML protocols will provide better interoperability.
If you devised a firearm that worked in one place but had to be modified to work elsewhere, you wouldn’t have much confidence in its effectiveness. The original Java Enterprise specification required a lot of deployment-oriented source-code modifications before the solutions would work in a new environment. J2EE, on the other hand, uses declarative information that exists outside the source code to minimize the need for code changes in deployment. Application programmers use declarative security access rules that are applied appropriately based on the particular deployment. Additionally, transaction control semantics and resource linkage are handled at deployment time via the XML deployment descriptor.
Will J2EE score a direct hit on enterprise development? While a number of vendors, SilverStream and Inprise among them, have released J2EE compatible products, not all Java vendors are on board. In fact, since Sun pulled Java from the standards committees, it's hard to get a true consensus on anything Java related, and Redmond is surely chuckling. IBM and Hewlett-Packard are not yet supporting J2EE, and some companies will wait to follow the lead of these two veterans. Additionally, migrations are tricky: You may have to stop your entire enterprise’s EJB 1.1 implementation before you can deploy a J2EE solution. If you are developing a new Web or multitier project, or if you have existing EJB 1.1 solutions, I’d suggest acquiring a J2EE implementation and firing off a few rounds for yourself. --Eric Binary Anderson has led projects at a number of enterprise software companies and is currently the senior architect at IBT financial, an Internet-based training company in Bend, Ore. Contact him at ebinary@columnist.com.