sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-assembly] Summarizing the state of ASSEMBLY-235
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: OASIS SCA Assembly <sca-assembly@lists.oasis-open.org>
- Date: Fri, 18 Feb 2011 10:32:34 +0000
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:
- interface.tibcoWSDL20 & interface.tibcoJMX
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?
<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
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]