← Prev in month ← Prev in thread

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

From
Eric Johnson <>
Date
2010-10-01T22:45:00+00:00
ID
Thread
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.

    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.
← Prev in month ← Prev in thread