Follow up...
Here's a sketch of a proposal (but not inlined as document changes)
for resolving ASSEMBLY-235,
based on the email below for action 09-22-01. This is intended to
generate discussion,
Replace section 6.2.1 #6 (lines 3421-3428 in 1.2-WD01), which
currently reads:
" 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.
"For checking the compatibility of 2 local interfaces which are in
different interface languages, the method of checking compatibility
is defined by the specifications which define those interface types,
which must define mapping rules for the 2 interface types concerned"
To this:
"for checking the compatibility of two interfaces, whether local or
remotable, the two interface descriptions are mapped onto a common
interface description language, and the interfaces are compared on
the basis of the semantics of that common interface description
language."
Or, for more explanatory text:
"for checking the compatibility of two interfaces, whether local or
remotable, the two interface descriptions are mapped onto a common
interface description language, and the interfaces are compared on
the basis of the semantics of that common interface description
language. For example, interfaces sharing the same description
language can be compared directly, whereas two interfaces in
different description languages that can both be mapped to WSDL 1.1
might use that mapping."
Of course, if we agree to the general pattern, a similar pattern
must be applied to 6.2.2 #6, and 6.2.3 #6.
-Eric.
On 10/01/2010 03:45 PM, Eric Johnson wrote:
4CA66492.6050603@tibco.com" type="cite">
I filed issue 235 (http://www.osoa.org/jira/browse/ASSEMBLY-235)
with the understanding that an SCA interface may only be
identified as "remotable" if it is possible to map said interface
to WSDL 1.1.
Turns out, this isn't true. At least, not that I can tell.
Probably Mike has been trying to tell me this for weeks, and I've
missed it.
I tried to nail down the exact problem here a little more
precisely (22-1), and I note the following normative text defines
remotable:
From Section 6.1:
Remotable service Interfaces MUST NOT make use of method or
operation overloading. [ASM80002]
If a remotable service is called locally or remotely, the SCA
container MUST ensure sure that no modification of input messages
by the service or post-invocation modifications to return messages
are seen by the caller. [ASM80003]
That's it - (normatively) remotable really doesn't mean much more
than that.
However, the spec also indirectly makes some assertions about
"remotable". (Define concept X, which relates to Y, then make an
assertion about X, thus hiding that assertion X affects the
meaning of Y.) Specifically, when it defines a compatible
interface, it states (6.2.1, #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." (Added "**"s for
emphasis)
I interpret this as meaning that if I've got a Java reference, and
a Java service, and both are using interface.jmx, then I do not
have to map to WSDL 1.1 in order to determine whether or not
they're compatible, since they start out in the *same* interface
language.
Action: 09-22-02:
This language appears to moot my action 09-22-02, "Produce example
of two different languages using non-WSDL IDL", because whether or
not I produce something what I produce, is by the current
definition, that IDL can already be treated as remotable, so long
as the same IDL is used at both ends of the communication.
Just to wrap this up with a bow, though, here's a link to an
XML-RPC description language, which, obviously, can be used with
C/C++/Python/Ruby/Java.
http://code.google.com/p/xrdl/
Action: 09-22-01:
Going back to 6.2.1 #6, 6.2.2 #6, and 6.2.3 #6, these sections all
have language like:
"For checking the compatibility of 2 local interfaces which are in
different interface languages, the method of checking
compatibility is defined by the specifications which define those
interface types, which must define mapping rules for the 2
interface types concerned."
Problems with the above:
- interface languages are unlikely to define compatibility
with other interface languages. They're likely to define
compatibility with themselves. They might also possibly
define a mapping from themselves to some other language.
- Why is it restricted to local interfaces? I don't really
see that there's a difference between local and remotable
interfaces in this regard.
I don't see any particular reason to be overly constraining here.
Why not just say "The interfaces, whether local or remotable, must
map onto a common interface description language, and that the two
interfaces must be compared on the basis of that common interface
description language."
Comments?
-Eric.
---------------------------------------------------------------------
To
unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|