I never bothered with roadmaps until I was of driving age and began to take trips on my own. Rock climbing drew me to my first trips and involved driving to remote areas of the U.S. It didn't take long to realize that a single wrong turn onto a road in the middle of nowhere meant hours of wasted time. Too many wrong turns soon earned you the nickname Clark Griswold. A wrong turn was especially a problem back in the days when Montana had no speed limit. You could really get nowhere fast back then.
"Nowhere fast" is exactly how I felt when developing distributed applications with Java before the J2EE platform. Originally labeled the Enterprise Java APIs in 1998, the platform was introduced by the Java Community Process (JCP) led by Sun Microsystems and a core team of JSR expert group members.
Since then, the platform: Has been renamed Java 2, Enterprise Edition
Has incorporated many new APIs
Has gained great popularity among the masses of enterprise developers
As of July 2001, more than 27 vendors have licensed J2EE and are actively incorporating the technology into their products. In fact, there have been more than 35,000 downloads of the 1.3 beta release alone.
The current release of the J2EE specification (1.2) has made great strides in moving server vendors from providing half-solutions to providing full platforms for enterprise development. The specification essentially glues together the numerous Enterprise Java APIs, such as EJB, JSP/Servlet, JDBC, JTA/JTS, JNDI, and JavaMail. This movement toward a standard platform has fostered portability across vendors and peace of mind for businesses investing in Java technology, and has guided many a wayfarer to a robust solution built from J2EE's solid architectural blueprint.
The JCP has been instrumental in building the roadmap for the current release of the J2EE specification and it continues to shape the future highway system for J2EE 1.3 and beyond. In case you haven't heard, JSR-58 released the final public draft of version 1.3 on April 9 of this year. It includes some great new features, such as required support for JMS (Java Message Service) and EJB 2.0 (JSR-19), including the new message-driven bean, which takes advantage of the JMS APIs. The J2EE Connector Architecture 1.0, also driven by the JCP (JSR-16), is mandatory, and will allow server vendors to seamlessly connect to enterprise information systems with resource adaptors that manage resource pooling, transactions, and connectivity issues.
The J2EE 1.3 specification included requirements for IIOP and XML, emphasizing portability across the enterprise and between enterprises. The final release of this specification is Q3 2001, and while I look forward to its release, I'm already looking at the future roadmap of the platform.
A gander at the JSR list on JavaSoft's Web site (http://java.sun.com/aboutJava/communityprocess/search.html) will show you where the action is.
While I already noted some of the JSRs that have influenced the J2EE specification to date, many more exciting JSRs are looking to shape the future of the platform. Work is already underway to firm up loose ends with the J2EE Connector Architecture. JSR-112 will have a Community Draft available in Q4 2001. Unfortunately, this means we'll probably have to wait until J2EE 1.4 or so to see its inclusion.
An interesting effort is taking place to define management of J2EE applications. JSR-77 is defining a management model that will:
Allow management of heterogeneous vendors from a single tool
Provide integration with existing management systems
Allow for a single tool to manage heterogeneous vendor implementations
One of the APIs many feel is missing from the J2EE Platform is JMX (Java Management Extension or JSR-3). However, the J2EE platform architects have expressed a more open approach toward management in the J2EE specification and don't directly support JMX over other management technologies. Thus JSR-77 looks to provide standardized management for J2EE applications by including support for existing technologies such as SNMP, JMX, and WBEM. JSR-77's time line is for a Proposed Final Draft in October 2001, with inclusion in the J2EE 1.4 release of the specification.
Next, the mission of JSR-88 (my personal favorite) is to determine requirements for the portable installation and configuration ("deployment"), and removal ("undeployment") of J2EE modules across J2EE servers. J2EE has been adopted at an alarming rate, and enterprises with multiple J2EE vendors have discovered problems deploying applications across their heterogeneous environments. The J2EE specification doesn't address portable deployment of applications across heterogeneous servers; however, with the inclusion of the J2EE Deployment API into the J2EE specification, portable deployments will become reality. JSR-88's milestones are a Public Draft around Q2 2001, and inclusion into J2EE 1.4 when it's released.
Last, JSR-117 (J2EE APIs for Continuous Availability) looks to be an important contributor to the J2EE specification of the future. It will address shortcomings in the current specification around ensuring high availability of J2EE applications, including defining a portable API for failover management, online upgrades of J2EE components, logging conventions for system administrators of J2EE applications to better monitor and read system reports, and error management for system-level exceptions so as to offer automatic recovery of state and transactions. Once this JSR is finalized, it will prove to be a powerful inclusion in the J2EE specification.
As both National Lampoon's Griswold and I know all too well: "Getting there is half the fun!" So if you ever feel you need a roadmap to point you in the right direction, take a look at maps the JCP is providing. If you have the urge to participate in the JCP, don't be shy. Anyone can be a member and contribute to the J2EE specification or other technology roadmaps of the future. Why not you?
Jason Westra, an active member of the Java Community Process, is currently on the expert group for JSR-88, J2EE Deployment API.