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.
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"
-Eric.
On 2/23/11 3:42 AM, Mike Edwards wrote:
OF416E8120.666273E7-ON80257840.003D9128-80257840.003FA0F7@uk.ibm.com" type="cite">
Eric,
<eej>
You seem to want it both ways - since it is outside of SCA, we don't control it and shouldn't (and yet the current spec attempts to), and yet you expect my proposal to define how to constrain such outside interface definitions?
I'll turn this around. What constraint do you wish to see defined on the OASIS CSA defined interfaces (interface.wsdl, interface.java - there are no others, right?) that my proposal discards? I could easily wrap up this proposal if I understand that.
</eej>
No - I am not wanting it both ways at all.
I am concerned about what the SCA specifications should say.
The SCA specifications are primarily concerned with what is standardized.
Clearly, any extension such as a new implementation type or a new interface type is outside the scope of the current standards.
What we DO say is how new implementation types and interface types should be added into a composition.
On the other hand, at the moment, the only way of getting to some level of portability and interoperability for a new implementation
type or a new interface type is to define a specification for that new type - and this should ideally be done in some OASIS TC.
Now, if the question is about what should apply to a new STANDARDIZED interface type, then:
a) I am OK with the current wording in the Assembly spec - it appears that you are not.
b) If you want to change the wording in the Assembly spec, then I am asking what wording is intended to be there that addresses this
issue of how we can ensure that any (future) standardized interface type is interoperable and portable.
I don't think that what I am asking for is unreasonable. The current wording is clear, if unacceptable to you.
However, I have not yet seen a proposal for a change that gives any guarantee of portability and interoperability for some new
standardized interface type. Hence my comments about things "being left up to the SCA runtime", which I think is a bad idea.
For stuff that is NOT standardized, I don't think that the SCA specs can say very much. We do have the material about conformance
demanding that IF an SCA runtime chooses to claim conformance on the basis of a non-standard implementation type, that certain
things are required - namely documentation and the passing of an adapted test suite, but that only relates to conformance claims.
I note that if an SCA runtime supported <implementation.java/> and <implementation.foo/>, then currently we make very few
demands on <implementation.foo/> if the runtime is not claiming conformance on the basis of implementation.foo. I think the same
can be said for <interface.foo/>.
So my concern is for any (future) interface types that may need standardizing for the purposes of interoperability and portability.
I think that there should be some wording to address this. And it has to be the Assembly spec that holds those words since I think
that the Assembly spec is the place that binds all these things together.
Meanwhile for non-standardized stuff, what force do the words in the Assembly spec carry? Very little in my opinion.
PS we have interface.c & interface.cpp defined in the current specifications
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 00:49 Subject: Re: [sca-assembly] Summarizing the state of ASSEMBLY-235
Hi Mike,
You say:
<mje>
My observation is that if you are considering things that are simply proprietary to a single vendor, then you can do virtually as you wish - this can be outside any standard, since standards are all about portability and interoperability.
Here you are painting a scenario which involves neither portability nor interoperability, so why do the SCA specifications matter?
</mje>
<eej>
And yet, the current spec does not read that way. It says (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." This is a definition that gets used normatively in MUST level assertions.
As I interpret your statement, you're saying that the implementation is free to ignore this definition in the context of ASM80011, for example, because one or or other of the interfaces happen to be specific to a vendor?
Then we agree! ;-)
I guess the difference is that I want the normative language of the spec to reflect this, rather than confuse the reader as to our intent.
</eej>
<mje>
The simple answer is: you can do as you please within TIBCO. Help yourselves. The specs don't prevent this. There are no issues that I can see.
Of course, I argue that it would be a good idea even for TIBCO to write down the mapping they intend to use between tibcoWSDL20 and tibcoJMX, otherwise the TIBCO customers might get confused. However, that is no concern to the OASIS SCA specifications.
My concern is if ever it is expected that these different interface types are expected to work across SCA runtimes from different vendors. In that case there is a need to define how things are supposed to work. Please give me an idea of what you would put into the SCA specifications to cover this.
</mje>
<eej>
Well, except I believe that the spec doesn't read this way, or I would not have spent all this time trying to clarify the spec. The spec very clearly says that different interface type languages, if "remotable" and considered for compatibility, MUST map to WSDL 1.1 for said comparison.
All my proposed language does is make what you allege is already the case far more clearly the case. The fact that we cannot control what other interface definitions do, and whether they define a mapping at all, seems to speak to the folly of ostensibly requiring that they map to WSDL 1.1 in the first place.
</eej>
<mje>
Fine, but how do you intend that this should be handled in the SCA specifications?
The wording used below in your proposal does nothing that I can see to provide any information about the mappings to be used - it seems to be left up to the SCA runtime to decide. I don't see how this provides any guarantee of portability or interoperability. So why would the SCA specifications want to leave a hole like this?
</mje>
<eej>
You seem to want it both ways - since it is outside of SCA, we don't control it and shouldn't (and yet the current spec attempts to), and yet you expect my proposal to define how to constrain such outside interface definitions?
I'll turn this around. What constraint do you wish to see defined on the OASIS CSA defined interfaces (interface.wsdl, interface.java - there are no others, right?) that my proposal discards? I could easily wrap up this proposal if I understand that.
</eej>
-Eric.
On 2/18/11 2:32 AM, Mike Edwards wrote:
Eric,
Some comments inline as <mje>...</mje>
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: 17/02/2011 22:40 Subject: Re: [sca-assembly] Summarizing the state of ASSEMBLY-235
Hi Mike,
I'm confused by the particular concern related to portability.
If I've built a composite that works with vendor X, using interface.vendorXIntfA and interface.vendorXIntfB, why would I have any expectation that I could take said composite and move it to a different SCA runtime, and have any expectation that it would work?
For that matter, just using interface.vendorXIntfA, and interface.vendorXIntfA, even though SCA 1.1 defines and allows compatibility between these two - even if they don't map to WSDL 1.1, I still wouldn't stand a chance of moving said composite away from vendorX.
<mje>
My observation is that if you are considering things that are simply proprietary to a single vendor, then you can do virtually as you wish - this can be outside any standard, since standards are all about portability and interoperability.
Here you are painting a scenario which involves neither portability nor interoperability, so why do the SCA specifications matter?
</mje>
Now, circling back to the first case, why do I need to know how vendorX determines compatibility between interface.vendorXIntfA & interface.vendorXIntfB? It should be up to the vendor to decide.
The key point here is that with my proposal, vendorX is not required to determine compatibility between instances of vendorXIntfA and vendorXIntfB by mapping to WSDL 1.1. They should be able to map to a different representation, and ought to choose that representation based on what best preserves the semantics. There are numerous ways in which a WSDL 1.1 mapping can drop semantics. That is, unless you start adding all sorts of extension elements to WSDL 1.1, at which point it just becomes yet another interface description that happens to use WSDL 1.1 for a portion of its representation.
<mje>
I actually agree with you for the case that you have here - something purely proprietary to one vendor. In such a case, the vendor can help themselves, do what they please.
In such a case, the SCA specifications can be silent. There is nothing to say.
</mje>
As for a concrete example (completely made up) that you asked for:Why, oh why would I be expected to map both of these to WSDL 1.1 in order to determine compatibility, when I could just map the interface.tibcoJMX instance to interface.tibcoWSDL20?
- interface.tibcoWSDL20 & interface.tibcoJMX
<mje>
The simple answer is: you can do as you please within TIBCO. Help yourselves. The specs don't prevent this. There are no issues that I can see.
Of course, I argue that it would be a good idea even for TIBCO to write down the mapping they intend to use between tibcoWSDL20 and tibcoJMX, otherwise the TIBCO customers might get confused. However, that is no concern to the OASIS SCA specifications.
My concern is if ever it is expected that these different interface types are expected to work across SCA runtimes from different vendors. In that case there is a need to define how things are supposed to work. Please give me an idea of what you would put into the SCA specifications to cover this.
</mje>
Putting this in a chart:
WSDL 1.1 interface.java interface A interface B WSDL 1.1 directly compare map to either map to either map to either interface.java map to either directly compare map to either map to either interface A map to either map to either directly compare map to either interface B map to either map to either map to either directly compare
The above is my proposal, whereas, the next table shows how the spec currently reads:
WSDL 1.1 interface.java interface A interface B WSDL 1.1 directly compare map to WSDL 1.1 map to WSDL 1.1 map to WSDL 1.1 interface.java map to WSDL 1.1 directly compare map to WSDL 1.1 map to WSDL 1.1 interface A map to WSDL 1.1 map to WSDL 1.1 directly compare map to WSDL 1.1 interface B map to WSDL 1.1 map to WSDL 1.1 map to WSDL 1.1 directly compare
The difference lies not on the diagonal, but all the options around that. The problem is that interfaces A & B may have richer semantics than WSDL 1.1. The existing spec'd expectation potentially forces the provider of interface A to declare something incompatible when it isn't, or worse, declare something compatible when it isn't, because semantics can be lost when mapping to WSDL 1.1.
On top of all of that, it happens that there isn't actually a test you can define that normatively verifies any of this, except the top left corner, because SCA currently only defines interface.wsdl & interface.java. If you want, we could further nail down that detail in my proposal. However, I don't see any value in mandating that interface A & interface B have to be converted to WSDL 1.1 before being compared, particularly since we can't test that.
<mje>
Fine, but how do you intend that this should be handled in the SCA specifications?
The wording used below in your proposal does nothing that I can see to provide any information about the mappings to be used - it seems to be left up to the SCA runtime to decide. I don't see how this provides any guarantee of portability or interoperability. So why would the SCA specifications want to leave a hole like this?
</mje>
-Eric.
On 2/17/11 7:47 AM, Mike Edwards wrote:
Eric,
I'm sorry that this has been left lonely and uncommented on. We're clearly enjoying event processing too much.
There is a comment inline. I think that it would also help if you could describe at least one concrete example of
a mapping that you'd like us to support.
Yours, Mike
From: Eric Johnson <eric@tibco.com> To: OASIS SCA Assembly <sca-assembly@lists.oasis-open.org> Date: 15/12/2010 01:26 Subject: [sca-assembly] Summarizing the state of ASSEMBLY-235
In a previous email I proposed something similar to the following change. This time I tried to be more precise, so that this is more than just directional.
Change 6.2.1 #6, 6.2.2 #6, and 6.2.3 #6 in the following pattern:
Replace text that 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."
... with the following ...
"The interfaces, whether local or remotable, must map onto a common interface description language, and that the two interfaces are compared on the basis of that common interface description language. See section Comparing Interface Descriptions of Different Types for a discussion."
... and then add a section 6.2.4:
6.2.4 Comparing Interface Descriptions Of Different Types
A variety of interface descriptions for services exist. Examples of well-known types include XML-RPC, CORBA, REST, WSDL 1.1, WSDL 2.0, SNMP, and JMX. Implementations ought to use the interface type mappings that best preserve the semantics of the underlying exchange.
To establish a basis of comparison between two different interface definition types, the implementation has to map one or both of the interface descriptions to a common definition type. The implementation has to identify that common type, and ought to keep possible conversion errors to a minimum by eliminating spurious conversions, and selecting the form with the best semantic relevance. For example, if one interface description type maps to WSDL 1.1, and the other interface type is WSDL 1.1, then the SCA implementation ought to compare on the basis of WSDL 1.1. When neither interface type can directly convert to the other interface type in question, and conversion to WSDL 1.1 is possible, implementations SHOULD map both interface descriptions to WSDL 1.1.
<mje>
The question is - who defines the mapping?
If I've got <interface.x.../> and <interface.y.../>, who says what the mapping between x and y is for some actual interfaces of each type?
Is this to be described in either or both of the specifications for x and y - or is it simply left to the SCA runtime to pick what it pleases?
I am somewhat concerned by the potential for lack of portability here, if runtimes are left free to choose what they will. I think the current
formulation of the SCA spec aims to get consistency between runtime implementations. How can we ensure this for the relaxed case?
</mje>
Justifications for the above:
The specification already allows for the use of remotable interfaces defined using something other than WSDL 1.1. For example, a Java JMX interface description can be marked remotable. The existing rules only reject the notion of compatibility when the two interfaces being compared are of different types, but don't actually reject the notion of remotability being applied to said interface types. As a possible example, XML-RPC can be represented by a variety of description languages.
The above change relaxes a constraint that imposes on an implementation the need to declare incompatibility where none may exist. Specifically, by allowing additional scenarios to interoperate, the composers will be able to express interface definitions that more closely align to their implementation language, and the semantics of the underlying problem, rather than by restricting themselves to the subset of the interface description that maps to WSDL 1.1.
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
