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
data)
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
wrapper.
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.
Thanks,
Raymond
--------------------------------------------------
From: "Scott Kurz" <[email protected]>
Sent: Monday, August 03, 2009 6:12 AM
To: <[email protected]>
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
