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 2009/08/03 15:12:33 UTC
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
Re: TUSCANY-3166 - Understanding the requirements to use "wrapper
style" interface.wsdl
Posted by Scott Kurz <sc...@gmail.com>.
Luciano,
I think your code is pretty much equivalent to my suggestion of simply doing:
public InterfaceContract getBindingInterfaceContract() {
return service.getService().getInterfaceContract();
}
at least for the cases which we'd expect to work anyway.
In both cases, for a component impl with <interface.java>
componentType we will return the componentType IC from
getBindingInterfaceContract(), and this is what prevents the DTI from
getting set up which we don't want since we do the mediate ourselves.
I guess I like the consistency (with, say, binding.jms) and simplicity
of my approach but this just confirms my point that this should
process of setting up the DTI should be more obvious to binding
authors. That said, I know I've been unable to find the time to come
up with something better in all this time, so can't complain.
Scott
Re: TUSCANY-3166 - Understanding the requirements to use "wrapper
style" interface.wsdl
Posted by Luciano Resende <lu...@gmail.com>.
On Mon, Aug 10, 2009 at 9:02 AM, Scott Kurz<sc...@gmail.com> wrote:
> Do we really even want the path from the service-side binding.atom to
> the service impl to include the DataTransformationInterceptor, given
> that the binding makes its own invocation of the mediator?
>
> What about using the usual trick of returning the componentType
> interface in getBindingInterfaceContrace() via:
> service.getService().getInterfaceContract()
> to disable the DTI?
>
> Is that all we really need to do here (and the analogous bit on the
> reference side)?
>
> Scott
>
Just want make sure we are on the same page here. Are you suggesting
that we check if we have a WSDL Contract, and in this case find the
correspondent Java Interface contract and use it ? I gave this a quick
try (see patch below) and it seems to work fine.... and the test cases
are now passing even with the interface.wsdl
diff --git a/modules/binding-atom-abdera/src/main/java/org/apache/tuscany/sca/binding/atom/provider/AtomServiceBindingProvider.java
b/modules/binding-atom-abdera/src/main/java/org/apache/tuscany/sca/binding/atom/provider/AtomServiceBindingProvider.java
index 0a5a902..d794dd4 100644
--- a/modules/binding-atom-abdera/src/main/java/org/apache/tuscany/sca/binding/atom/provider/AtomServiceBindingProvider.java
+++ b/modules/binding-atom-abdera/src/main/java/org/apache/tuscany/sca/binding/atom/provider/AtomServiceBindingProvider.java
@@ -19,10 +19,12 @@
package org.apache.tuscany.sca.binding.atom.provider;
+import org.apache.tuscany.sca.assembly.Service;
import org.apache.tuscany.sca.binding.atom.AtomBinding;
import org.apache.tuscany.sca.databinding.Mediator;
import org.apache.tuscany.sca.host.http.ServletHost;
import org.apache.tuscany.sca.interfacedef.InterfaceContract;
+import org.apache.tuscany.sca.interfacedef.wsdl.WSDLInterfaceContract;
import org.apache.tuscany.sca.invocation.MessageFactory;
import org.apache.tuscany.sca.provider.ServiceBindingProvider;
import org.apache.tuscany.sca.runtime.RuntimeComponent;
@@ -37,6 +39,7 @@ import org.apache.tuscany.sca.runtime.RuntimeWire;
class AtomServiceBindingProvider implements ServiceBindingProvider {
private RuntimeComponentService service;
+ private InterfaceContract serviceContract;
private AtomBinding binding;
private ServletHost servletHost;
private MessageFactory messageFactory;
@@ -56,10 +59,22 @@ class AtomServiceBindingProvider implements
ServiceBindingProvider {
this.servletHost = servletHost;
this.messageFactory = messageFactory;
this.mediator = mediator;
+
+ // TUSCANY-3166
+ this.serviceContract = service.getInterfaceContract();
+ if (this.serviceContract instanceof WSDLInterfaceContract) {
+ for (Service componentService :
component.getImplementation().getServices()) {
+ if (componentService.getName().equals(service.getName())) {
+ this.serviceContract = (InterfaceContract)
componentService.getInterfaceContract();
+ break;
+ }
+ }
+
+ }
}
public InterfaceContract getBindingInterfaceContract() {
- return service.getInterfaceContract();
+ return serviceContract;
}
public boolean supportsOneWayInvocation() {
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: TUSCANY-3166 - Understanding the requirements to use "wrapper
style" interface.wsdl
Posted by Scott Kurz <sc...@gmail.com>.
Do we really even want the path from the service-side binding.atom to
the service impl to include the DataTransformationInterceptor, given
that the binding makes its own invocation of the mediator?
What about using the usual trick of returning the componentType
interface in getBindingInterfaceContrace() via:
service.getService().getInterfaceContract()
to disable the DTI?
Is that all we really need to do here (and the analogous bit on the
reference side)?
Scott
Re: TUSCANY-3166 - Understanding the requirements to use "wrapper style" interface.wsdl
Posted by Raymond Feng <en...@gmail.com>.
>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" <sc...@gmail.com>
Sent: Monday, August 03, 2009 6:12 AM
To: <de...@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