By early next year, most J2EE vendors will be releasing their J2EE 1.4 certified application servers. The proposed final draft of version 1.4, which was released this past August, includes major updates to the three core Java application server standards.
Now is an excellent time to review the changes to the specification, what it means for application developers, and how the application server vendor landscape will likely change over the next few months.
Updates to the core specification
The J2EE specification has three core standards: Enterprise Java Beans (EJB), Java Servlets, and Java Server Pages (JSP). The new version of EJB, 2.1, adds query language enhancements that make aggregation and sorting more efficient, new stateless session beans that are exposed through a Web services interface, and a new timer service that allows development of workflow services or other systems that require scheduled operations. JSP 2.0 includes some major changes.
The new standard tag library includes built-in database access and XML data manipulation in addition to other key enhancements. This update also allows developers to write their own custom tags in JSP. New developers can also write JSP applications faster by using a new simple expression language instead of writing the applications in Java. The Java Servlet 2.4 updates make deployment simpler and include APIs to manage application logoffs.
After specification approval, Sun will update its J2EE reference implementation and issue new versions of the compatibility test suite. Other application server vendors will then need to recertify their implementations for the 1.4 version. Most vendors will be able to complete the process by the end of the year, meaning that new versions of their application servers will be available in the first quarter of 2003. Developers are anxious to get their hands on version 1.4 because of the new SOAP support.
SOAP: Developer nirvana
Now that the rest of the industry has standardized on SOAP as the heir apparent to various competing remote procedure call (RPC) mechanisms—including COM, CORBA, and Java RMI—it’s about time that Sun released a version of the core J2EE specification that supports the standard in a consistent, predictable way.
Without a standard on which to build a standard SOAP interface, the J2EE application vendors and third parties have been promoting their own intermediate standards and products to allow developers to add SOAP interoperability. Companies that have done any serious development using these intermediate standards or products will have to migrate their applications to the new version 1.4 specifications to maintain stricter J2EE standards support going forward.
So what’s the big deal about SOAP standardization? In the current J2EE 1.3 implementation, developers access Enterprise Java Beans using Java’s Remote Method Invocation (RMI) interface or from a CORBA application through the Inter-ORB protocol. SOAP support will allow developers to access EJBs with SOAP over HTTP, not only making communications between EJBs simpler but also developing systems composed of both EJBs and Microsoft .NET components exposed through the SOAP interfaces built into the Microsoft .NET framework.
While the J2EE 1.4 specification adds SOAP support, the SOAP standard itself still doesn’t include all the necessary support for advanced enterprise applications. Standards for cross-machine transaction, routing, and security management all have to be agreed on, ratified, and implemented in application servers from J2EE vendors and Microsoft before anything but the most basic interoperability can be achieved. Support for these advanced standards will be one of the key differentiators between J2EE vendors. This is one area where Sun still has a lot of catching up to do.
The status of server vendors
When Microsoft, IBM, VeriSign, and over 50 other vendors got together to form the Web Services Interoperability (WS-I) group, the goal was to establish a set of standards that would ensure a long life for SOAP and Web services as an industry standard replacement for proprietary RPC protocols.
Moreover, by tackling the difficult problems of multisystem transaction management, as well as delegated security and increased redundancy, the WS-I could usher in a new computing fabric within which applications from multiple vendors could work together “out of the box.”
After living through the progression of tape swapping, message buses, and now XML-based Enterprise Application Integration systems (like BizTalk and Web Methods), the promise of WS-I has CIOs salivating over the prospect of simple plug-and-play application interoperability.
Every major application server vendor has signed on to the WS-I vision except Sun. Sun’s recent grudging participation in the WS-I takes place simultaneously with its support of competing security recommendations and, ironically enough, a rapidly decreasing stock price.
Given Sun’s track record with updating the J2EE specification, it’s likely to be another 18 to 24 months before agreed-on WS-I standards make it into the specification officially. Given that Microsoft, IBM, and other J2EE application server vendors want the functionality sooner, most companies basing their strategy on J2EE implementations will be forced to use one of the application server vendors’ proprietary implementations of WS-I standards just as they used proprietary SOAP implementations while waiting for J2EE 1.4.
These decisions are likely to drive CIOs and development managers into the arms of the dominant provider of J2EE implementations today—IBM. It’s beginning to look more like the early 1980s all over again, with IBM and Microsoft dominating the computer landscape.
I still believe Sun won’t be around three years from now to enjoy the investment it has made in its Java effort.
When IBM buys Sun and takes over the stewardship of Java in the next 24 months, the industry will benefit from two major computing platforms (J2EE and .NET) that will have interoperability built in from the ground up.
So to Java, I say: Welcome to the Web services party! We’ve been waiting for you. And to Sun, I say: Welcome to the Web services party! Just don’t hang up your coat: You won’t be around long enough to enjoy it.