You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2009/05/15 12:38:47 UTC
Re: issue with binding.jms: interface.wsdl with either obj, bytes,
text wireFormat
On Fri, May 15, 2009 at 1:12 AM, Scott Kurz <sc...@gmail.com> wrote:
> I was just noticing that in the WireFormatJMSObjectServiceProvider ctor, we do:
>
> // just point to the reference interface contract so no
> // databinding transformation takes place
> interfaceContract = service.getInterfaceContract();
>
> So, with an <interface.java> componentType, this is fine as long as we
> have a component service interface which is also <interface.java>...
> however, what if someone configures an <interface.wsdl>? In this
> case, we will end up configuring the wire so that there IS a
> DataTransformationInterceptor configured... which is not what we want.
> A confusing error happens later....
>
> So do we want to consider this a user error (in which case we might
> detect it better at least)? That's seems justified, in that if you
> expect the component service interface to correspond somewhat closely
> to the actual wireFormat, then there's not much justification for
> using an <interface.wsdl> to describe the service.
>
> That being said, we don't take that "strict" view when it comes to a
> <binding.ws> combined with an <interface.java>, in which case we allow
> the component service <interface.java> in spite of the fact that the
> binding wire format is ultimately described by a WSDL interface.
>
> If we continue this view that only the componentType and binding
> interfaces are "concrete" whereas the component interfaces are only
> "abstract", then it seems we should allow the WSDL interface.
>
> I admit this isn't an extremely common case, but you might end up with
> this combination if, say, you started from a WSDL interface and
> produced types that could be serialized with either Java serialization
> or something like JAXB serialization. I also just like to bring this
> up now and then to ensure we're all still on the same page here.
>
> Scott
>
Good spot Scott. I agree we shouldn't be restricting the users ability
to describe service/reference interfaces based on the wire format they
choose. We are making some assumptions with wireFormat.jmsObject, i.e
that the message parameters are serializable Java objects so the the
provider needs to ensure that the selected interface doesn't give rise
to a data transformation that leads to something other than a Java
object.
In this particular case we need to look at how we get the wire format
provider to ignore the specified service WSDL interface and assume a
java interface for the binding by forcing a configuration where no
data transformation is required. Needs a bit of investigation.
I'm wondering what happens in a slightly different case though if you
have something like...
<component ...>
<implementation.bpel process="">
<service ...>
<binding.jms>
<wireFormat.jmsObject/>
In this case it is natural to assume that the interface on the service
implementation is WSDL defined (even though I haven't specified it
here). Here the problem is that a transformation is required.
A message arriving will be extracted from the JMS message but what
next? Java deserialization will create a POJO based on what is
available to it on the current classpath but when it comes time to
push this through the Databinding layer to have it converted into the
correct structure to be read by BPEL will Databinding understand the
incoming object? Maybe databinding is smart enough to do something
here by treating any input as a POJO but I don't know.
Simon
Re: issue with binding.jms: interface.wsdl with either obj, bytes,
text wireFormat
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Jun 25, 2009 at 4:55 PM, Scott Kurz<sc...@gmail.com> wrote:
> I'm not suggesting generating one from WSDL yet, until we understand
> the use case(s) we'd need this in more detail. It might be nice to
> throw an error if a Java interface is unavailable however.
>
> Obviously we have a lot of bindings today and people have figured out
> the trick... just seemed nicer to have a method clearly intended for
> this purpose.
>
> Scott
>
Hi Scott
Ok, I understand. I guess we could add it as a helper so if the
extension developer were really expecting a Java interface then we
could test that a Java interface is available.
Simon
Re: issue with binding.jms: interface.wsdl with either obj, bytes,
text wireFormat
Posted by Scott Kurz <sc...@gmail.com>.
I'm not suggesting generating one from WSDL yet, until we understand
the use case(s) we'd need this in more detail. It might be nice to
throw an error if a Java interface is unavailable however.
Obviously we have a lot of bindings today and people have figured out
the trick... just seemed nicer to have a method clearly intended for
this purpose.
Scott
Re: issue with binding.jms: interface.wsdl with either obj, bytes,
text wireFormat
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Jun 25, 2009 at 3:23 PM, Scott Kurz<sc...@gmail.com> wrote:
> Picking this thread up again, I wonder if a starting point might be to
> define a new SPI that a binding could use to obtain a Java
> InterfaceContract in the cases where we expect/require the
> componentType IC to be Java.
>
> E.g. in org.apache.tuscany.sca.binding.jms.wireformat.jmsobject.runtime.WireFormatJMSObjectServiceProvider
> we have:
>
> List<Operation> opList =
> service.getService().getInterfaceContract().getInterface().getOperations();
>
> what if:
>
> service.getService().getInterfaceContract()
>
> were replaced by:
>
> service.getJavaInterfaceContract()
>
> I realize that's not exactly a giant leap forward in the
> discussion....just didn't want to let the idea die as I've noticed
> this is a very important step required to implement certain Tuscany
> bindings correctly, but you just have to know this "trick" rather than
> using a potentially clearer SPI.
>
> Scott
>
Hi Scott
And is the suggestion here to test, inside
service.getJavaInterfaceContract(), that there is a Java interface
contract available? We either throw an error if there isn't or
generate one from WSDL (we don't have this generated code in the
runtime now).
Simon
Re: issue with binding.jms: interface.wsdl with either obj, bytes,
text wireFormat
Posted by Scott Kurz <sc...@gmail.com>.
Picking this thread up again, I wonder if a starting point might be to
define a new SPI that a binding could use to obtain a Java
InterfaceContract in the cases where we expect/require the
componentType IC to be Java.
E.g. in org.apache.tuscany.sca.binding.jms.wireformat.jmsobject.runtime.WireFormatJMSObjectServiceProvider
we have:
List<Operation> opList =
service.getService().getInterfaceContract().getInterface().getOperations();
what if:
service.getService().getInterfaceContract()
were replaced by:
service.getJavaInterfaceContract()
I realize that's not exactly a giant leap forward in the
discussion....just didn't want to let the idea die as I've noticed
this is a very important step required to implement certain Tuscany
bindings correctly, but you just have to know this "trick" rather than
using a potentially clearer SPI.
Scott
Re: issue with binding.jms: interface.wsdl with either obj, bytes,
text wireFormat
Posted by Simon Laws <si...@googlemail.com>.
On Fri, May 15, 2009 at 3:59 PM, Scott Kurz <sc...@gmail.com> wrote:
> Thanks Simon,
>
> So we already support the mirror image case today where we need a WSDL
> intf for the binding but have only a Java intf in the component; we
> generate a WSDL if necessary.
>
> So for the wf.jmsObject plus impl.bpel case, I suppose we could just
> generate Java as well.
>
> So each binding requiring this could, in all cases, call a new SPI
> named something like getJavaInterfaceContractForBinding() which would
> first look at the app for a Java interface, and if one is not present,
> we could generate one from the WSDL interface we would presumably
> have.
>
> I purposely phrased that as "look at the app for a Java interface"
> because I think we'd need to think through the details of which to
> look at: component interface, componentType interface, or possibly
> both.
>
> Scott
>
Right Scott, and that's all together a bigger issue. I've checked in
some changes for the first problem and closed of the JIRA. Lets
address this second issue separately. It needs some thought and some
examples.
Simon
Re: issue with binding.jms: interface.wsdl with either obj, bytes,
text wireFormat
Posted by Scott Kurz <sc...@gmail.com>.
Thanks Simon,
So we already support the mirror image case today where we need a WSDL
intf for the binding but have only a Java intf in the component; we
generate a WSDL if necessary.
So for the wf.jmsObject plus impl.bpel case, I suppose we could just
generate Java as well.
So each binding requiring this could, in all cases, call a new SPI
named something like getJavaInterfaceContractForBinding() which would
first look at the app for a Java interface, and if one is not present,
we could generate one from the WSDL interface we would presumably
have.
I purposely phrased that as "look at the app for a Java interface"
because I think we'd need to think through the details of which to
look at: component interface, componentType interface, or possibly
both.
Scott
Re: issue with binding.jms: interface.wsdl with either obj, bytes,
text wireFormat
Posted by Simon Laws <si...@googlemail.com>.
On Fri, May 15, 2009 at 11:38 AM, Simon Laws <si...@googlemail.com> wrote:
> On Fri, May 15, 2009 at 1:12 AM, Scott Kurz <sc...@gmail.com> wrote:
>> I was just noticing that in the WireFormatJMSObjectServiceProvider ctor, we do:
>>
>> // just point to the reference interface contract so no
>> // databinding transformation takes place
>> interfaceContract = service.getInterfaceContract();
>>
>> So, with an <interface.java> componentType, this is fine as long as we
>> have a component service interface which is also <interface.java>...
>> however, what if someone configures an <interface.wsdl>? In this
>> case, we will end up configuring the wire so that there IS a
>> DataTransformationInterceptor configured... which is not what we want.
>> A confusing error happens later....
>>
>> So do we want to consider this a user error (in which case we might
>> detect it better at least)? That's seems justified, in that if you
>> expect the component service interface to correspond somewhat closely
>> to the actual wireFormat, then there's not much justification for
>> using an <interface.wsdl> to describe the service.
>>
>> That being said, we don't take that "strict" view when it comes to a
>> <binding.ws> combined with an <interface.java>, in which case we allow
>> the component service <interface.java> in spite of the fact that the
>> binding wire format is ultimately described by a WSDL interface.
>>
>> If we continue this view that only the componentType and binding
>> interfaces are "concrete" whereas the component interfaces are only
>> "abstract", then it seems we should allow the WSDL interface.
>>
>> I admit this isn't an extremely common case, but you might end up with
>> this combination if, say, you started from a WSDL interface and
>> produced types that could be serialized with either Java serialization
>> or something like JAXB serialization. I also just like to bring this
>> up now and then to ensure we're all still on the same page here.
>>
>> Scott
>>
>
> Good spot Scott. I agree we shouldn't be restricting the users ability
> to describe service/reference interfaces based on the wire format they
> choose. We are making some assumptions with wireFormat.jmsObject, i.e
> that the message parameters are serializable Java objects so the the
> provider needs to ensure that the selected interface doesn't give rise
> to a data transformation that leads to something other than a Java
> object.
>
> In this particular case we need to look at how we get the wire format
> provider to ignore the specified service WSDL interface and assume a
> java interface for the binding by forcing a configuration where no
> data transformation is required. Needs a bit of investigation.
>
> I'm wondering what happens in a slightly different case though if you
> have something like...
>
> <component ...>
> <implementation.bpel process="">
> <service ...>
> <binding.jms>
> <wireFormat.jmsObject/>
>
> In this case it is natural to assume that the interface on the service
> implementation is WSDL defined (even though I haven't specified it
> here). Here the problem is that a transformation is required.
>
> A message arriving will be extracted from the JMS message but what
> next? Java deserialization will create a POJO based on what is
> available to it on the current classpath but when it comes time to
> push this through the Databinding layer to have it converted into the
> correct structure to be read by BPEL will Databinding understand the
> incoming object? Maybe databinding is smart enough to do something
> here by treating any input as a POJO but I don't know.
>
> Simon
>
I went ahead and created TUSCANY-3031 for the jms object part. I note
the same code appears in some of the other no transforming wire
formats so we will likely want to fix them as well.
I think the solution is to use the interface from the component type
in the case you have outlined. But need to think if this has adverse
effects when the implementation is not Java
Simon