These are the final results of the JSR Review Ballot for JSR #101. The Executive Committee for SE/EE has approved this ballot.
JSR101
StageJSR Review Ballot
Ballot durationJan 30, 2001 to Feb 12, 2001
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
Vote Log

SE/EE

On 2001-02-12 Fujitsu Limited voted No with the following comment:
It is necessary to develop APIs for ebXML TR&P and W3C XML Protocol. These APIs should be an open. I think it is better for ebXML group and
W3C group to define these APIs, if possible.
We have voted 'YES' on JSR101, with my expectation that JSR 101 expert group will take care of this issue. However, NOW, we agree with IBM's position to discuss this important direction and the possibility of combining with "XML messaging" in the EC group.
------------------------------------------------------------------------------
On 2001-02-12 Apache Software Foundation voted No with the following comment:
While JSR 101 references the emerging XP standard, the scope of the expert group to be formed is clearly limited to Java and RPC applications.  Arguably, the expert group could choose to ignore this and define a proposal which is fully in line with XP and interoperable with other implementations, and perhaps this would be acceptable to the EC down the road, but in our opinion it would be wise for the scope to be established correctly from the outset.
------------------------------------------------------------------------------
On 2001-02-12 Hewlett-Packard voted No with the following comment:
See detailed comments on SE/EE reflector.
- SOAP as an underlying protocol must be supported by APIs coming out of this JSR. The related alignment with W3C XP WG work is also non-negotiable. W3C is where the XMP RPC protocol work should take place and this JSR should ask for APIs for at least the protocol that emerges from W3C.
- This JSR faces some of the same pitfalls that JSRs 76 & 78 faced in the requirement for clear separation of APIs between protocol dependent and protocol independent parts and the need to have a single protocol independent API layer which can be used to do RMI over the three possible underlying RPC protocols - JRMP, IIOP and XML-RPC. We would like to see a clear statement of position regarding this architectural issue.
- JSR 67 XML-Messaging and this JSR need to be aligned.
- It makes sense to delay issuing this JSR until JSR 76 & 78 final results are out to incorporate lessons learned.
------------------------------------------------------------------------------
On 2001-02-12 BEA Systems voted No with the following comment:

Like the other no voters, BEA would like to see JSR-101 folded into JSR-067. Much of the positive reaction to SOAP is a result of the elegance of treating RPC and messaging under a unified programming model. We believe having a single expert group is the best way to ensure we acheive this. We (perhaps ignorantly) think this should be easy to achieve procedurally (e.g., couldn't we withdraw 67 and submit a merged 101 JSR including the 67 expert group and existing work?).
------------------------------------------------------------------------------
On 2001-02-11 Sun Microsystems, Inc. voted Yes with the following comment:
Sun is in agreement with the technical goals expressed
by Oracle and IBM.  We believe that this JSR is aligned
with those goals.

The procedural issue is that JSR-067 for XML Messaging
is already in flight.  It's charter does not cover RPC,
and left to itself it will only solve half of the problem.
We are attempting to remedy that omission by adding this
second JSR.

We agree completely that the Messaging and RPC JSRs
should be tightly aligned, and may share many APIs.
We would be happy to have a discussion with EC members
on the best ways of aligning the two JSR expert groups,
perhaps by techniques like joint meetings.  But we
believe that we need to get the ball rolling, and
start making progress.
------------------------------------------------------------------------------
On 2001-02-09 Oracle voted No with the following comment:
We agree with IBM's position and would like to see one specification that deals with synchronous one-way and RPC as well as asynchronous messaging.  Although there will be API differences between these models, we believe that more than 50% of the infrastructure work can be common.  Ideally, we would like to see a design that supports plug-ability by means of an SPI-like interface that supports multiple protocols, (currently ebXML and SOAP) and is extensible to future protocols as well.  We believe that many of the differences between the protocols can be masked by a properly designed interface.

------------------------------------------------------------------------------
On 2001-02-08 IBM voted No with the following comment:
Full details are set out in the memo to EC members on 8 Feb 01. XML RPC should not be specified in a different JSR from XML messaging. 
1. There is considerable overlap in the likely APIs for RPC vs. messaging. A unified API is both possible and desirable.
2. The XML Protocol working group in W3C is making efforts to bring together ebXML messaging with SOAP and create a combined protocol that handles both messaging and RPC.  SOAP already encompasses both RPC and messaging models.  By combining these activities in a single JSR, we can and should ensure that divergence does not occur.
3. A combined JSR for Java bindings to the W3C XML Protocol would produce a single RI of a protocol engine that supports both synchronous and asynchronous messaging over a common protocol, greatly to be preferred over two separate RI's.
4. The JSR is much too vague.  JSR101 should be reissued as Java bindings to the emerging W3C XML Protocol specification for both synchronous and asynchronous messaging.
------------------------------------------------------------------------------
On 2001-02-04 Caldera Systems voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-02-03 Cisco Systems voted Yes with no comment.
------------------------------------------------------------------------------
On 2001-02-01 Progress Software voted Yes with no comment.
------------------------------------------------------------------------------