Target: sca-assembly-1.2-spec-wd01.doc
Title: Remotable interface compatibility should not be restricted to a
WSDL 1.1 mapping
Description:
The latest version of the Assembly specification
(sca-assembly-1.1-spec-cd05), in section 6.2, defines interface
compatibility in section 6.2.1, item #6 "for checking the compatibility
of 2 remotable interfaces which are in different interface languages,
both are mapped to WSDL 1.1 (if not already WSDL 1.1) and compatibility
checking is done between the WSDL 1.1 mapped interfaces."
There are various reasons why this will fall over and not behave as
expected.
False positives:
- Some other interface kind may impose data type semantic
restrictions which are not apparent in a WSDL 1.1 representation. WSDL
1.1 uses XML Schema 1.0 types for its representation of data.
Unfortunately, there are limitations here, where XML Schema largely
focuses on the syntactic representation, and not as much on the
semantic values. Some random examples:
- all odd numbers/all even numbers
- string validation via regular expressions, where some semantic
is required on a portion of the string. Example - credit card
numbers
- string contents - XML Schema "string" type allows for a subset
of all possible characters. This means that certain characters cannot
be represented in XML Schema representations, and must be somehow
mapped.
- Object networks - representing a network of objects serialized to
XML, certain objects should be serialized at most once, and then
referenced. Creating and enforcing the linking of representations is
at best an imperfect alignment, as there are numerous ways that this
can be accomplished, depending on the type of the object network.
Unfortunately, something conforming to the XML Schema requirements
could easily not align on the semantic requirements, either in
generating a request, or receiving a response.
False negatives:
- Intrinsic to mapping to WSDL are choices about how that mapping
might be done. For example, implementations might map JMX to WSDL in
myriad ways. Forcing the consumer and provider to do so in a way that
offers up a WSDL 1.1 mapping as part of the component type could lead
to a declaration of "incompatible" even where the JMX interfaces are,
in fact compatible (albeit, at runtime, the implementation of the JMX
conduit must be shared)
- Bad compromises - certain existing bindings (binding.jms) allow
for possibility of sending Java Objects via JMS. To not be
able to call these bindings remotable is a mockery of the notion of
"remote", however, forcing a mapping of a generic Java Object to some
XML representation will have "binding" trade-offs. Implementers will
then have to invest time to "maximize compatibility", whereas if they
simply used existing interfaces compatiblity would simply be there.
(Partial) Proposal:
Remoting compatibility should not be restricted to WSDL 1.1 mappings.
Interface type definitions ought to be allowed to at least define a
compatible relationship with themselves.
-Eric.
|