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.
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:
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:
From:
Eric Johnson
<>
To:
Mike
Edwards/UK/IBM@IBMGB
Cc:
OASIS SCA Assembly
<>
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:
From:
Eric
Johnson <>
To:
Mike
Edwards/UK/IBM@IBMGB
Cc:
OASIS SCA Assembly <>
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
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
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
