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.
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.
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?
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.
-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
<>
To:
OASIS SCA Assembly
<>
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
