To pick a bizarre case, suppose I have two interface descriptions I wish to support for SCA, say one is for CORBA, and one is for WSDL 2.0.
Suppose I decide that they both need to be standardized. I'm arguing that a direct translation from CORBA to WSDL 2.0 makes much more sense, rather than forcing them both to map to WSDL 1.1 (a mapping, so far as I know, nobody has ever done.)
What you're arguing, it seems to me, is that we cannot trust the authors of those future specifications to define how they optimally interoperate. Instead, we have to tie their hands and map everything to WSDL 1.1.
Assuming there is no complete mapping from WSDL 2.0 to WSDL 1.1, what does that mean?
The options:
a) define a mapping from CORBA to WSDL 2.0, but not to WSDL 1.1. The interfaces will be "standard", but will not be able to claim "conformance". Works, but silly.
b) Map a subset of WSDL 2.0 to WSDL 1.1. Map CORBA to WSDL 1.1. Declare all sorts of situations that might otherwise work as "incompatible" due to the lossy mappings to WSDL 1.1. Yay! Conformance, but at a cost of the end-user encountering unnecessary incompatibility.
c) Change the base spec so that it gives follow-on specifications the opportunity to specifically name the other remotable interface types that they work with, and how they achieve that compatibility. That gives us the best of both worlds, at the risk of introducing some places where the runtime declares incompatibility between two remote interface types.
I think you're arguing for situation (b), whereas I'm arguing for (c). There are costs to each approach. I think (c) is preferable, because I don't think it is in the interests of the base specification to tie the hands of follow-on specifications, since that extra tying doesn't mean less incompatibility, just different incompatibility.
-Eric.
On 2/23/11 9:52 AM, Mike Edwards wrote:
Eric,
From the "Implementation Type Documentation Requirements for SCA Assembly Model
Version 1.1 Specification" , section 2.5:
Describing an Interface Type associated with an Implementation
Type
An implementation type might have an associated interface type which it uses when describing the
interfaces of services and references. If the implementation type is able to use an existing interface type,
e.g., interface.wsdl or interface.java, then the implementation type documentation can simply reference
the documentation for that interface type.
if the implementation type uses an interface type that is not described in the documentation for some
existing implementation type, then the implementation type documentation MUST describe the interface
type. [IMP10017]
For some new interface type, there are at minimum two pieces of information to provide:
• a definition of the interface extension element
• a definition of the mapping of the interface type to interface.wsdl.
All remotable interfaces MUST be mappable to interface.wsdl. [IMP10030]
...
Some other comments inline...
Yours, Mike
Dr Mike Edwards Mail Point 146, Hursley Park STSM Winchester, Hants SO21 2JN SCA & Services Standards United Kingdom Co-Chair OASIS SCA Assembly TC
IBM Software Group
Phone: +44-1962 818014
Mobile: +44-7802-467431 (274097)
e-mail: mike_edwards@uk.ibm.com
From: Eric Johnson <eric@tibco.com> To: Mike Edwards/UK/IBM@IBMGB Cc: OASIS SCA Assembly <sca-assembly@lists.oasis-open.org> Date: 23/02/2011 17:30 Subject: Re: [sca-assembly] Summarizing the state of ASSEMBLY-235
Hi Mike,
It sounds like what you're describing, though is a normative constraint on a interface type description that claims to conform to the SCA specification.
<mje>
Correct - for something claiming CONFORMANCE, I think that is exactly what I'm describing
</mje>
It sounds like we need either a document, or a section analogous to our "Implementation Type Documentation Requirements for SCA Model Version 1.1 Specification", but for interfaces.
The text you're looking for, I think, is on the order of "A definition of an interface must either define how it maps to another defined interface type, and how it maps to WSDL 1.1"
<mje>
I assume you intended "or" rather than"and" here, given the "either" in the earlier part of the sentence.
The problem I see with the earlier part of the either...or is that it is so vague as to be meaningless.
Lets say we already have defined & specified (standardized) <interface.a/> and <interface.b/> Now we want to
introduce <interface.c/>. If they all map to/from WSDL 1.1, things are simple, I believe. If <interface.c/> does not map
to WSDL 1.1, then we will need to define the mapping of <interface.c/> to interface.a and the mapping to <interface.b/>
(in both directions, I think). If this is not done, then there is no guarantee that some wire between 2 components
that use the different interface types will actually work when run on a given SCA runtime,
Perhaps this is what you intend - ie some interface types simply won't work together. To me that is a strange idea of
a service - one where the technology used shows through enough to prevent the use of the service by some clients.
</mje>
-Eric.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
