tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raymond Feng" <enjoyj...@gmail.com>
Subject Re: TUSCANY-3166 - Understanding the requirements to use "wrapper style" interface.wsdl
Date Mon, 03 Aug 2009 22:21:02 GMT
>From the data transformation perspective, the interface on the component 
type decides what data representation will be accepted by the target 
component. In this case, we have "different" interfaces on the component and 
component type.

a) component service: interface.wsdl (document-literal-wrapper style)
b) component type service: interface.java (generated from the WSDL, but it 
sets the wrapper style flag to false to indicate that it expects unwrapped 

If the target component is BPEL, then the component type service can be the 
same as a). The BPEL should consume the input wrapper and produce the output 

I assume a) and b) are compatible but it does require the 
wrapping/unwrapping between the two. The databinding framework should use 
the operation signature from b) as the target to perform the transformation 
against the binding layer's data representation. Can you guys find out if 
this is how the code behave? If not, we should try to fix the 
DataTransformationInterceptor use the interface from the component type.

In the case of binding.atom and for the "Collection" wsdl, the binding layer 
expects to see the unwrapped data. So it can derive the "binding" interface 
contract from the target interface but forcing the wrapper style to be 
false.  If the target interface is b), then no wrapping/unwrapping is 
needed. If the target interface is a), then the request data from atom 
binding will be wrapped and the response data from the target component will 
be unwrapped.

From: "Scott Kurz" <scottkurz@gmail.com>
Sent: Monday, August 03, 2009 6:12 AM
To: <dev@tuscany.apache.org>
Subject: Re: TUSCANY-3166 - Understanding the requirements to use "wrapper 
style" interface.wsdl

> Luciano,
> The case I mentioned was more of a bottom-up case , in that we started
> with the Java REST-like interface.
> So say I start with this interface, write a Java impl, expose a
> service over <binding.atom>.  Now in order to invoke this same impl
> over a different binding like <binding.ws>, I generate an
> <interface.wsdl> and place this configuration on my component service
> description.
> To me it sounds like you're assuming this would have an impact on the
> actual wireformat of the binding.atom invocation of the existing
> service.   My assumption was that it would NOT impact the wireformat
> at all.   So the presence of a doc-lit-wrapped <interface.wsdl> does
> not necessarily mean that a wrapper element will appear in the payload
> XML.  The WSDL interface is abstract and the concrete "binding" to a
> binding-specific format is something for us to define.
> I'm not saying that should be the final word on the subject... just
> explaining my assumptions.   But this also explains why I viewed this
> as more of a tweak in using the right Tuscany databinding APIs rather
> than adding support to handle a fundamentally new type of wire format.
> After working on the JMS binding with its spec-defined default
> wireFormat where a doc-lit-wrapped WSDL doesn't necessarily result in
> a wrapper element being serialized onto the wire (for a single
> parm)... I guess at least there is some precedent for the idea that a
> doc-lit-WSDL doesn't, for all bindings, result in serializing a
> document literally conforming to the message part schema.   But it
> does all seem a bit ugly to me I admit...
> Scott 

View raw message