What is needed from the JCP to ensure SOAP service portability across all Java SOAP platforms? (was RE: Need suggestions on web service interop and design)

[Anderson Jonathan <an...@bah.com>]

Anne Thomas Manes wrote to axis-user:

>JAX-RPC 1.1 defined standard mappings between Java types and RPC/Encoded,
>but it doesn't do the same for Doc/Literal (even though Sun claims it
does).

>It could be done as part of JAXB 2.0 or JAX-RPC 2.0, but I'm not convinced
>that it belongs in either one. Anyone on this list care to initiate a JSR?

Is there any way to gain visibility into the JAX-RPC 2.0 (JSR 224) design
discussions?  Do I have to become a member of the expert group, or is there
anything open to the public?  I'd be very curious as to their opinions on
this topic.  I'm very much of the opinion that there should be one
standardized and specified set of W3C XML Schema -> Java mappings THAT ALL
JAVA SOAP IMPLEMENTATIONS SHOULD BE MANDATED TO USE.

But hell, webMethods GLUE touts its ElectricXML XML -> Java binding engine
as one of their discriminating features.  WASP likewise touts its robust W3C
schema support (substitution groups, etc).  So am I dreaming of a utopia
that vendors will never agree to?  Is it not in a SOAP platform vendor's
best interest to make SOAP services implemented on their platform
proprietary?

Regards,
Jonathan Anderson
Booz Allen Hamilton

RE: What is needed from the JCP to ensure SOAP service portability across all Java SOAP platforms? (was RE: Need suggestions on web service interop and design)

[Anne Thomas Manes <an...@manes.net>]

Supposedly... according to the latest revision of the JCP bylaws ... future
JCP proceedings will be more "transparent" to developers. 

See http://www.sun.com/smi/Press/sunflash/2004-03/sunflash.20040309.1.html 
and http://www.jcp.org/en/press/news/2_6 

To whit:

"Improved Communications Resources
JCP 2.6 actively encourages more developers to contribute to the JSR
process. For example, the initial review period for each JSR has been opened
to the public, and changed to encourage JSRs to enter review earlier, with
more open issues. This change will ensure Spec Leads get more valuable
feedback at an earlier stage of development. 

"Plus, each Spec Lead, the individual in charge of a JSR, is mandated to
provide maximal process transparency to the JCP Executive Committee members,
community, and the public. 

"As part of JCP 2.6, each new JSR must include a transparency plan, which
outlines the tools and techniques that the Spec Lead will use during the
creation and development of the specification, for communicating JSR
progress at each stage."

For JAX-RPC 2.0, contact Roberto Chinnici and Marc Hadley.
For JAXB 2.0, contact Joe Fialli and Sekhar Vajjhala.

Per the JSR description, JAX-RPC 2.0 is supposed to define standardized
metadata for Java <-> WSDL mapping.

Anne

-----Original Message-----
From: Anderson Jonathan [mailto:anderson_jonathan@bah.com] 
Sent: Thursday, April 15, 2004 4:45 PM
To: axis-user@ws.apache.org
Subject: What is needed from the JCP to ensure SOAP service portability
across all Java SOAP platforms? (was RE: Need suggestions on web service
interop and design)

Anne Thomas Manes wrote to axis-user:

>JAX-RPC 1.1 defined standard mappings between Java types and RPC/Encoded,
>but it doesn't do the same for Doc/Literal (even though Sun claims it
does).

>It could be done as part of JAXB 2.0 or JAX-RPC 2.0, but I'm not convinced
>that it belongs in either one. Anyone on this list care to initiate a JSR?

Is there any way to gain visibility into the JAX-RPC 2.0 (JSR 224) design
discussions?  Do I have to become a member of the expert group, or is there
anything open to the public?  I'd be very curious as to their opinions on
this topic.  I'm very much of the opinion that there should be one
standardized and specified set of W3C XML Schema -> Java mappings THAT ALL
JAVA SOAP IMPLEMENTATIONS SHOULD BE MANDATED TO USE.

But hell, webMethods GLUE touts its ElectricXML XML -> Java binding engine
as one of their discriminating features.  WASP likewise touts its robust W3C
schema support (substitution groups, etc).  So am I dreaming of a utopia
that vendors will never agree to?  Is it not in a SOAP platform vendor's
best interest to make SOAP services implemented on their platform
proprietary?

Regards,
Jonathan Anderson
Booz Allen Hamilton