On Fri, May 15, 2009 at 11:38 AM, Simon Laws <[email protected]> wrote: > On Fri, May 15, 2009 at 1:12 AM, Scott Kurz <[email protected]> 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
