The Java Community Process(SM) Program - JSRs: Java Specification Requests

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy

JSR #58
Java^TM 2 Platform, Enterprise Edition 1.3 Specification
Final Approval Ballot
Ballot duration: 2001-08-21 to: 2001-09-04

These are the final results of the Final Approval Ballot for JSR #58. The Executive Committee for SE/EE has approved this ballot.

Votes

SE/EE

Accenture

Apache Software Foundation

Apple Computer, Inc.

BEA Systems

Borland Software Corporation

Caldera Systems

Cisco Systems

Compaq Computer Corporation

Fujitsu Limited

Hewlett-Packard

IBM

Lea, Doug

Oracle

Progress Software

Sun Microsystems, Inc.

WebGain

Icon Legend
Yes
No
Abstain
Not voted

View Vote Log

SE/EE

On 2001-09-04 Progress Software voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-09-04 Lea, Doug voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-09-04 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-08-31 Borland Software Corporation voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-08-28 Compaq Computer Corporation voted Yes with the following comment:
Compaq agrees with many of the points made by IBM.  It is highly desirable to be able to plug third party JMS providers into a J2EE app server.  It is most unfortunate that this capability does not currently exist.  However, it seems that the value of JMS pluggability is understood, and there are plans to provide it in the next revision, J2EE 1.4.  In particular, the work on the next revision of the J2EE Connector Architecture 2.0 (JSR 112) specifically addresses JMS pluggability.

Where Compaq disagrees with IBM is whether a J2EE product should have this capability out of the box.  Message driven beans (MDB) are an important part of the J2EE 1.3 revision and they depend on the JMS capability.  It is critical to have MDB work with a J2EE 1.3 product without the need to purchase an additional product, so that applications can freely use this important feature.  Hence, while we are disappointed that JMS provider pluggability isn't supported, we agree with the notion that some JMS provider should be included with a J2EE 1.3 product.

The truth of the matter is, making JMS pluggable is a nontrivial effort.  We do not think that J2EE 1.3 should be delayed the year or so it would take to design this feature through the JSR process.  Nor do we believe J2EE 1.3 should be rejected due to the lack of JMS pluggability.

Hence, Compaq is voting "Yes" on JSR 58 (and the accompanying JSRs).  We do so with the understanding that JMS provider pluggability will be addressed in the next revision of the J2EE standard.
------------------------------------------------------------------------------
On 2001-08-27 Caldera Systems voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-08-24 WebGain voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-08-22 BEA Systems voted Yes with the following comment:
BEA disagrees with IBM's assessment---From our perspective making JMS optional substantially weakens the value of J2EE. From one view, JMS is indeed a resource manager like a database. However, we are far more convinced by the argument that JMS is also the foundation for asynchronous communications (store/forward, publish/subscribe, and event processing)---that is, JMS is fundamental component of the communications infrastructure of J2EE like Servlets and EJB than it is JDBC. For many uses of JMS (memory-based queuing), there is no need for a separate resource manager. In the future, we expect asynchronous web services and disconnected J2ME clients to make this argument even more compelling. 

We understand that some J2EE vendors may not want to bundle a transactional messaging resource manager with their J2EE product offering. Making JMS a core component of J2EE does not require those vendors to do so. They can either brand with a separate messaging product or ship a light-weight implementation so that Java developers can use key features like message-driven beans and (in the future) asynchronous web services out of the box. Or they can do both. What is more, we already have BEA customers snapping-in a different JMS service provider, so the desired flexibility is already available. 

Lastly, equivalent functionality will be part of .NET, and so we invite unfavorable comparisons with J2EE if we do not offer base JMS functions in the box.
------------------------------------------------------------------------------
On 2001-08-22 Sun Microsystems, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-08-22 IBM voted No with the following comment:
JSR 58 introduces Java Messaging Services (JMS) into the scope of J2EE 1.3. IBM believe that Messaging should be treated in the same way that database access is: namely, there is some flexibility in the provision of an underpinning "resource manager" beneath the API:
- In the case of JDBC,  the application server vendor either requires that one use the JDBC driver implementation provided by the database vendor, or produces and tests a set of drivers that map to driver functions of the DB
vendors. Essentially, a series of alternative databases can be referenced in the J2EE compliant configuration(s).
- JMS support should follow the same model. The application server vendor should either test and rely on the JMS implementation provided by the
messaging infrastructure vendors supporting their platform, or develop and test providers that map to popular products.  Instead, however the current
J2EE specification requires the application vendor to package a messaging resource manager with their application server product.

Resultant implications:

1. Application Server Vendors may be required to change their product packaging. This causes concern, not only through the anomaly with JDBC / Database, but also the future directions of J2EE. As it grows bigger in scope with no "Mix and match" ability (outside database), there may be a steadily reducing number of vendors with the ability to provide the complete functionality.

2. In the same manner but more seriously, the marketplace has suddenly and, in our view, unfairly shrunk for smaller more specialist vendors. If all the major J2EE vendors have to package a Messaging Engine as part of their
J2EE solution, the attractiveness of a standalone messaging product from  a specialist vendor is lessened. This risks a decrease in customer choice for Java-enabled middleware. Again, the JDBC model seems the right one, promoting the "Mix and match" environment, but retaining compliance control.
------------------------------------------------------------------------------