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 #67
Java^TM APIs for XML Messaging 1.0
Final Approval Ballot
Ballot duration: 2001-10-30 to: 2001-11-12
These are the final results of the Final Approval Ballot for JSR #67. 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-11-12 Fujitsu Limited voted No with the following comment:
We think that JMS and JAXM are different interface level each other, and JMS is more appropriate API which J2EE should include. In this point, we agree with BEA, Apache and IBM. But, it may be good to remain JAXM in javax as SOAP interface for 
engineers, not included in J2EE. 

However, we do not deny JAXM API, we recommend that the positioning between JMS and JAMX should be clarified so that Java programmers will not be in confusion, and JMS should support SOAP anyway.
------------------------------------------------------------------------------
On 2001-11-12 WebGain voted No with the following comment:
WebGain also believes that two JSRs and therefore different APIs for messaging can be confusing for our developers (and partners) and could create serious confusion within the Java community. We understand that JMS and JAXM are different but there is enough overlap and enough redundancy at this point for us to express major concerns.

Our decision was very difficult to make because we think it is really regretful to raise these issues at this stage and that most of these issues should have been raised earlier either by the EC folks or even better within the effort by the EG.
We also would like to see some of the very good work performed in the JAXM effort used in 
other areas of the JAX Pack and more specifically JAX-RPC. We think the work done around the SOAP
package in JAXM should definitely be reused to serve the JAX Pack and our Web Services strategy
for the Java Platform. We also think that the JMS users should not have to go through the pain of inventing yet another SOAP abstraction they should simply leverage what the JSR 67 SOAP package and hopefully we could leverage that work even if this JSR does not get approved. 
Just like BEA, Apache, Compaq or IBM, we also believe that voting Yes for this JSR is not the only way to get the SOAP work done for JAXM leveraged. 
We can't stress enough how we regret that these concerns are raised so late in the lifecycle of JAXM and would like to see this fixed in the future for other JSRs. It is not fair for the people that have put a lot of very hard work and late hours into JSR 67.
------------------------------------------------------------------------------
On 2001-11-12 Compaq Computer Corporation voted No with the following comment:
Compaq agrees with the issues raised by BEA concerning JSR 67 - JAXM.  The JAXM specification has too much overlap with JMS.  In addition, we have issues with the maturity and directions of the specification.  We believe there are better approaches for delivering the capabilities that JAXM has tried to address.

We believe the needs of the Java community would be better served by using JAX-RPC for synchronous XML/SOAP communication, and by extending JMS to handle XML/SOAP payloads for asynchronous messaging.   The APIs for SOAP (with attachments) should be standardized as part of the JAX-RPC JSR (JSR 101).  An additional effort should be undertaken to add XML/SOAP payloads to JMS.  This should be an easy task, as proven by the large number of applications that are already doing so.  This would create a much more unified approach to messaging that will be easier for the Java community to use and program against.

A difficult aspect of this vote is the all or nothing nature of the outcome.  A lot of good work has been done as a part of this JSR.  In particular, the APIs for accessing and manipulating the SOAP portion of a message are an important byproduct of the JAXM specification that are useful for the JAX-RPC and JMS-SOAP.  We encourage the JAX-RPC JSR  effort to include this portion of the JAXM JSR and assume responsibility for its standardization without major redesign or significantly delay.  We cannot vote for the JAXM JSR simply to get the SOAP manipulation APIs advanced to standardization.  This would be the tail wagging the dog.

We sincerely regret that these concerns are being raised this late in the process.  Such issues would ideally have been addressed at the Community Draft approval stage or in the expert group.  However, we can not ignore the problems with this JSR and hence, respectfully vote no.
------------------------------------------------------------------------------
On 2001-11-12 Borland Software Corporation voted Yes with the following comment:
Borland is in favor of this technology being moved forward, but not as part of J2EE 1.4. We feel that at this point it is too immature to be folded into J2EE. In the future, it could mature enough to warrant inclusion.
------------------------------------------------------------------------------
On 2001-11-11 Apache Software Foundation voted No with the following comment:
ASF agrees with the BEA position on this vote.
------------------------------------------------------------------------------
On 2001-11-09 Oracle voted Yes with the following comment:
Oracle is voting in favor of this JSR despite some sympathy for the issues raised by BEA and IBM.  In particular, we would like to see better alignment between JAXM and JAX-RPC.  However, we do not see this as sufficient justification for voting no at this stage.  Noting that JAX-RPC is only at community review, we are encourage that the expert group already added this issue to their agenda.
------------------------------------------------------------------------------
On 2001-11-09 Lea, Doug voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-11-09 IBM voted No with the following comment:
We are significantly concerned that the introduction of JAX-M as yet another API for calling a service (along with RMI-IIOP, JMS, and the proposed JAX-RPC) is unnecessarily complicating the Java programming model for our developers. Each API, I am sure, can be justified on its own, but as an overall Java based solution, we feel that there is too much overlap and redundancy. The recent (and welcome) adoption of the SOAP Handler classes by the JAX-RPC expert group renders the introduction of this new messaging API in JAX-M even more redundant, we feel.
------------------------------------------------------------------------------
On 2001-11-08 Apple Computer, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-11-08 Progress Software voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-11-06 BEA Systems voted No with the following comment:
We believe that having two Java APIs for messaging is an inherently bad idea and one that will be attacked by our competition as an example of a solution designed by committee. JMS, which was just added to J2EE in 1.3, is being used today for messages with XML payloads, even though there is no explicit XML support. We believe the additional features of XML and SOAP processing in JAXM would be better surfaced as a new release of JMS. We further believe that this issue must be addressed now before developers have the opportunity to use this API or we will never be able to converge them in the future.
------------------------------------------------------------------------------
On 2001-11-02 Cisco Systems voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-11-02 Sun Microsystems, Inc. voted Yes with no comment.
------------------------------------------------------------------------------