You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Scott Kurz <sc...@gmail.com> on 2008/04/30 20:12:25 UTC
componentType interfaces and data transforms
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
Re: componentType interfaces and data transforms
Posted by scabooz <sc...@gmail.com>.
I'm going to take this off list as we have a disconnect here that is not
Tuscany specific.
Dave
----- Original Message -----
From: "Mike Edwards" <mi...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Friday, May 09, 2008 10:15 AM
Subject: Re: componentType interfaces and data transforms
> scabooz wrote:
>> 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
>>
> Dave,
>
> That is exactly what I would NOT expect to see.
>
> The component type from the implementation has the Java interface.
>
> The <component.../> from the assembly may choose to use a <service.../> or
> <reference.../> element which uses a WSDL for its interface definition
> (this is a configuration choice for the assembler), but to me it makes no
> sense whatsoever to have a component type sidefile which has a WSDL
> interface. To do so would be to lie about the implementation - the
> implementation is using the Java interface and knows nothing about the
> WSDL at all, even if the WSDL is the correct mapping of the Java
> interface.
>
> The interceptors etc can see what comes from the complete composition.
> Again, it is VITAL that they know that the implementation is using a
> particular Java interface. For example, that interface may be annotated
> with important information. The component type sidefile cannot and should
> not be used to "wipe out" the information about the implementation.
>
>
> Yours, Mike.
Re: componentType interfaces and data transforms
Posted by Mike Edwards <mi...@gmail.com>.
scabooz wrote:
> 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
>
Dave,
That is exactly what I would NOT expect to see.
The component type from the implementation has the Java interface.
The <component.../> from the assembly may choose to use a <service.../> or <reference.../> element
which uses a WSDL for its interface definition (this is a configuration choice for the assembler),
but to me it makes no sense whatsoever to have a component type sidefile which has a WSDL interface.
To do so would be to lie about the implementation - the implementation is using the Java interface
and knows nothing about the WSDL at all, even if the WSDL is the correct mapping of the Java interface.
The interceptors etc can see what comes from the complete composition. Again, it is VITAL that they
know that the implementation is using a particular Java interface. For example, that interface may
be annotated with important information. The component type sidefile cannot and should not be used
to "wipe out" the information about the implementation.
Yours, Mike.
Re: componentType interfaces and data transforms
Posted by scabooz <sc...@gmail.com>.
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" <mi...@gmail.com>
To: <tu...@ws.apache.org>
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"
>> <mi...@gmail.com>
>> To: <tu...@ws.apache.org>
>> 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
>>>>
>>>
>>
>>
>
Re: componentType interfaces and data transforms
Posted by Mike Edwards <mi...@gmail.com>.
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"
> <mi...@gmail.com>
> To: <tu...@ws.apache.org>
> 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
>>>
>>
>
>
Re: componentType interfaces and data transforms
Posted by scabooz <sc...@gmail.com>.
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.
Dave
----- Original Message -----
From: "Mike Edwards" <mi...@gmail.com>
To: <tu...@ws.apache.org>
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
>>
>
Re: componentType interfaces and data transforms
Posted by Mike Edwards <mi...@gmail.com>.
Raymond Feng wrote:
> +1 on what Mike said.
>
> We have been trying to avoid the implementation (physical) IC assuming
> the componentType IC would be the same as the implementation IC. Taking
> java component as an example, this is basically to define how a class
> "implements" an interface in the SCA fashion. If we do have the need to
> capture the implementation IC, then it would be the impl class with a
> bunch of methods that match the interface. One example is as follows:
>
> @Service(MyService.class)
> public class MyServiceImpl {
> public String getCustomerId(SDOCustomer customer) {
> ....
> }
> }
>
>
> @Remotable
> public interface MyService {
> String getCustomerId(JAXBCustomer customer);
> }
>
> Is it valid by the SCA spec?
>
> I'm also seeing another extreme use case that the impl class implements
> a generic invocation interface such as InvocationHandler. I'm not sure
> if it's valid.
>
> Thanks,
> Raymond
Raymond,
That's a good example.
Both of the interfaces you quote may well map to the same WSDL, but they are not the same Java.
The component type should reflect the actual interface used by the implementation - if not, then
there could be a failure at runtime.
Regarding your "generic invocation interface", I think I'd need to see a concrete example to be able
to comment any further, but in the services world, I'm not sure that this is going to fly. In the
pub/sub & messaging world, things are very different and generic interfaces are acceptable.
Yours, Mike.
Re: componentType interfaces and data transforms
Posted by Raymond Feng <en...@gmail.com>.
+1 on what Mike said.
We have been trying to avoid the implementation (physical) IC assuming the
componentType IC would be the same as the implementation IC. Taking java
component as an example, this is basically to define how a class
"implements" an interface in the SCA fashion. If we do have the need to
capture the implementation IC, then it would be the impl class with a bunch
of methods that match the interface. One example is as follows:
@Service(MyService.class)
public class MyServiceImpl {
public String getCustomerId(SDOCustomer customer) {
....
}
}
@Remotable
public interface MyService {
String getCustomerId(JAXBCustomer customer);
}
Is it valid by the SCA spec?
I'm also seeing another extreme use case that the impl class implements a
generic invocation interface such as InvocationHandler. I'm not sure if it's
valid.
Thanks,
Raymond
--------------------------------------------------
From: "Mike Edwards" <mi...@gmail.com>
Sent: Thursday, May 08, 2008 5:09 AM
To: <tu...@ws.apache.org>
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
>>
>
Re: componentType interfaces and data transforms
Posted by Mike Edwards <mi...@gmail.com>.
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
>