As to removing support for WSDL 2.0 from binding.ws

[Eric Johnson <eric@tibco.com>]

I understand that voting on a resolution was deferred on my behalf.  For that, I that I must send out a thank you.

Having reviewed the assembly specification, the java specifications, and the policy specification with respect to "remotable", and conferred with my colleagues on the various TCs, I am satisfied with where the bindings specification is now.  I'm also satisfied with the notion of removing all references to WSDL 2.0 from the binding.ws specification.

Laurent mentions to me that in the call of last week, there was at least one person that was insistent that "remotable" implies "maps to WSDL portType".  (I've omitted names, in part because this knowledge is hearsay, and therefore probably somewhat inaccurate, and also leaves open the possibility that others might concur).

My review of the specifications does not show any such implication.  To slightly oversimplify, my reading of the assembly spec is that an interface is remotable if the interface says it is.  On top of that, there is no stated expectation, normative or not, that any given remotable interface can actual map to WSDL, either WSDL 1.1 or WSDL 2.0.  (If I've read the specs incorrectly, please advise.)

In case the implications of this are not clear, this means that it is possible to define remotable interfaces that don't necessarily map to WSDL - and consequently, although they are remotable, they probably cannot be used with binding.ws.  Some examples that immediately occur to me:

• interface.java-rmi
• interface.wsdl20
• interface.rest

Now, not "mapping" to WSDL could be considered a somewhat squishy limitation, in that it is at least always theoretically possible to add arbitrary extension elements to WSDL 1.1 and have any number of transformations, mappings, and whatnot implied such that you could at least claim that a WSDL 1.1 mapping exists.  However, in the case of WSDL 2.0, at least, it is pretty clear to me that WSDL 2.0 has standardized some notions (particularly MEPs) that simply are not standard with WSDL 1.1.  Forcing such an extension back into the WSDL 1.1 space is manifestly silly, given the availability of a perfectly good replacement standard.  More generally, one point of using a new "interface" description is most valuable precisely at the point where that new interface description introduces new aspects that do not map cleanly, or at all, to existing WSDL 1.1.

This limitation of the current specifications, that a remotable interface may not map to WSDL 1.1, cleanly, if at all, seems very much like a feature of the specifications.  My take is that interface mapping of any kind to a transport - which also must map back to an implementation of that interface in an arbitrary programming language, is generally a complex problem with no easy solutions.  In other words, it is a space ripe for vendor enhancement, and is premature for standardization.

That's my perspective, and puts the context behind why I'm willing to simply remove WSDL 2.0 support from binding.ws.

-Eric.

P.S. - My pet peeve of the Java to XML binding space, for example, is that in Java, it is legal to have characters in a Java String object that cannot legally be serialized to XML.  It is possible to define an additional escaping mechanism that enables expressing the illegal characters, but those escaping mechanisms are not standardized.  So even in the space where we think the "mapping" problem has been addressed, there are some subtle differences between "interface.java" that happens to be remotable and maps to WSDL, and "interface.wsdl", which clearly can work with binding.ws with no issues.  And yes, TIBCO has definitely had customers that have run into these kinds of limitations in a non-SCA context.