OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: My action items: 2010-09-22-1, 2010-09-22-2

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.

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."



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]