Re: [sca-assembly] Summarizing the state of ASSEMBLY-235

[Mike Edwards <mike_edwards@uk.ibm.com>]

Eric,

Comments inline...

Yours, Mike

Dr Mike Edwards		Mail Point 137, 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:	07/03/2011 20:26
Subject:	Re: [sca-assembly] Summarizing the state of ASSEMBLY-235

---

Hi Mike,

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.

<mje>
This is a fine example
</mje>

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.

<mje>
That is not what I am saying
at all.
What I want is to have
wording that does require the authors of these specs to make statements
about interoperability.

I'm not saying that mapping
to WSDL 1.1 is the only way of achieving this, but if you want to provide
for other ways of
ensuring interoperability,
then I do think that we need a form of words in the Assembly spec that
put the appropriate
requirements in place.
 So far, I've not seen a form of words that I found acceptable.
</mje>

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.

<mje>
Works for that pair of
interfaces, but what about other pairings amongst the standardized i/f
types eg interface.java to interface.corba (etc)?

Are they mappable - or
do you think it is permissible for such pairings to not work?  If
they are mappable, where is the mapping defined?
</mje>

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.

<mje>
That sounds like you're
in favour of having interface type pairings that don't interoperate.  Can't
say that I'm keen on that.  Having Edge cases that don't map may be
a harsh reality, but I'd then prefer
those edge cases to be
well described somewhere and the SCA interface specs to point at those
descriptions.

Even for that case, I want
to see a requirement expressed in Assembly that is placed on the folk who
write the specs for new interface types to define interoperability - ie
how the interface type maps
That sounds reasonable
to me.  What I dont want is lack of portability/interoperability caused
by different SCA runtimes having different mappings for particular pairings
of interface types.
</mje>

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

---

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