Ok, that's a good start. What did you mean by ignored. I would have
expected that the WSDL was available in the logical in-memory object model
so that interceptors, binding impls, etc would be able to see what was in
the cT side file.
Dave
----- Original Message -----
From: "Mike Edwards" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, May 09, 2008 7:54 AM
Subject: Re: componentType interfaces and data transforms
Comments inline,
scabooz wrote:
But if the WSDL specified in the componentType is the 'mapped to' WSDL
from the implementation then it does reflect the implementation. I would
then argue that it was a valid componentType.
I agree that it is a valid componentType file.
However, I would expect the Tuscany runtime to ignore it, given that it
gets a componentType by introspection of the implementation that exactly
matches what the implementation is.
I note that at present, Tuscany does not generally do a good job of
merging the introspected component type information with information from
a component type file. Proper merging would "scavenge" additional
information only from the componentType file.
Yours, Mike.
Dave
----- Original Message ----- From: "Mike Edwards"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, May 08, 2008 8:09 AM
Subject: Re: componentType interfaces and data transforms
Scott,
The interpretation here depends on your take on componentType files.
My take has *ALWAYS* been that componentType files are meant to express
something about the implementation rather than express some "design
constraints". Indeed, the separate concept of "constraining type" was
invented for the purpose of expressing design constraints. I also
believe that componentType files are a necessary evil to be tolerated
only for cases where introspection is impossible.
Another term suggested for "componentType" has been "implementationInfo"
which makes this plain.
Viewed in this light:
a) componentType should not be necessary if an implementation can be
introspected
b) componentType can only add information derived from introspection -
it cannot override anything
since the implementation is what it is
Viewed in this light, I'd say that the example componentType you give
falls foul of these rules. The implementation clearly has an
<interface.java clas="xxxx"/>, not an <interface.wsdl.../>. I'd expect
the "componentType merge process" to either:
1) Issue a warning that the componentType file does not match the
implementation
2) Raise an exception for the same issue
Either way, its the <implementation.java.../> that should be used.
Yours, Mike.
Scott Kurz wrote:
Consider the use case where I start with a .componentType file, e.g.:
<componentType xmlns="http://www.osoa.org/xmlns/sca/1.0";>
<service name="HelloWorld">
<interface.wsdl interface="
http://helloworld#wsdl.interface(HelloWorld)" />
</service>
</componentType>
And I proceed to write a Java impl with @Service pointing to a Java
interface.
--------------------------
Well, this is going to cause problems today.
I'm not precisely sure where in the code... I know it has something to
do
with how we build the wire source/target InterfaceContracts in
CompositeActivatorImpl... but somehow the net seems to be that we
assume
that if an interface is specified in the .componentType file then
this .componentType interface will describe something physical on the
wire.
Now, one could argue that it is correct that the use case I started
with is
not supported. I think the words in the OSOA Assembly spec do more
to
suggest the
current interpretation than the one I'm suggesting.
But regardless, I'm arguing that the componentType should be treated as
more
of a logical description in this case than a physical description.
So in the code I'd say we should be basing the wire source/target
interface
contract's on something which is more of a "client/impl
InterfaceContract"
than the componentType
InterfaceContract we're using today.
In particular this allows more of an ability to express top-down,
WSDL-centered, interface design via the componentType file.
Scott
