You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Luciano Resende <lu...@gmail.com> on 2009/05/05 07:54:15 UTC

Databinding & Operation Selector and Wire Formats

The JSONRPC binding, used to perform some databinding related
operations such as cloning the interface contract, and resetting the
service interface databinding to JSON in the JSONRPC
ServiceBindingProvider. Now that we are going to use operation
selectors and wire formats, where these operations should be performed
? I have tried to perform them in the
WireFormatServiceProvider.configureWireFormatInterfaceContract and
also inside the JSONRPCWireFormatInterceptor without much success...
and as a result, I'm not being able to successfully run some JSONRPC
tests related to transforming pojos to json and vice versa.

Any hints ?

-- 
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: Databinding & Operation Selector and Wire Formats

Posted by Luciano Resende <lu...@gmail.com>.
On Tue, May 5, 2009 at 2:42 AM, Simon Laws <si...@googlemail.com> wrote:
> Hi Luciano
>
> In the JMS binding we do this sort of thing in the binding providers.
> I.e it happens once when the runtime artifacts for the binding are
> created and not each time  a message is received. If you look in, for
> example, the JMSBindingServiceBindingProvider constructor you'll see
> some code like...
>
>
>        // create an interface contract that reflects both request and response
>        // wire formats
>        try {
>            interfaceContract =
> (InterfaceContract)service.getInterfaceContract().clone();
>
>            requestWireFormatProvider.configureWireFormatInterfaceContract(interfaceContract);
>            responseWireFormatProvider.configureWireFormatInterfaceContract(interfaceContract);
>        } catch (CloneNotSupportedException ex){
>            interfaceContract = service.getInterfaceContract();
>        }
>
> The trick here is that firstly we delegate to the wire format provider
> to determine how the interface contract should be configured. This is
> because it's only the wire format that really knows.

Ok, I had the code in the wire format method that configures the
interface contract, but I missed the part that the
bindingServiceProvider had to explicitly call it. Much better now...

Thank you.

-- 
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: Databinding & Operation Selector and Wire Formats

Posted by Simon Laws <si...@googlemail.com>.
On Tue, May 5, 2009 at 6:54 AM, Luciano Resende <lu...@gmail.com> wrote:
> The JSONRPC binding, used to perform some databinding related
> operations such as cloning the interface contract, and resetting the
> service interface databinding to JSON in the JSONRPC
> ServiceBindingProvider. Now that we are going to use operation
> selectors and wire formats, where these operations should be performed
> ? I have tried to perform them in the
> WireFormatServiceProvider.configureWireFormatInterfaceContract and
> also inside the JSONRPCWireFormatInterceptor without much success...
> and as a result, I'm not being able to successfully run some JSONRPC
> tests related to transforming pojos to json and vice versa.
>
> Any hints ?
>
> --
> Luciano Resende
> Apache Tuscany, Apache PhotArk
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>

Hi Luciano

In the JMS binding we do this sort of thing in the binding providers.
I.e it happens once when the runtime artifacts for the binding are
created and not each time  a message is received. If you look in, for
example, the JMSBindingServiceBindingProvider constructor you'll see
some code like...


        // create an interface contract that reflects both request and response
        // wire formats
        try {
            interfaceContract =
(InterfaceContract)service.getInterfaceContract().clone();

            requestWireFormatProvider.configureWireFormatInterfaceContract(interfaceContract);
            responseWireFormatProvider.configureWireFormatInterfaceContract(interfaceContract);
        } catch (CloneNotSupportedException ex){
            interfaceContract = service.getInterfaceContract();
        }

The trick here is that firstly we delegate to the wire format provider
to determine how the interface contract should be configured. This is
because it's only the wire format that really knows. In the JMS case,
for example, some wire formats use XML to format message some use Java
object serialization etc. These all require very specific databinding
configuration. The other thing to notice in this case is that the
request and response wire formats are treated independently. This may
not be the case with binding.http but with JMS it is possible that
request message may be formatted differently from response messages
and hence we have to take account of that. This leads to an interface
contract where the input and output elements are configured
independently from a databinding point of view.

If you look inside one of the wire format, for example, lets take an
interesting one such as WireFormatJMSTextXMLServiceProvider you will
see a couple of things happening. First, in the constructor, an
interface contract is constructed assuming that the wire format will
apply to both request and response messages.

        // create a local interface contract that is configured specifically to
        // deal with the data format that this wire format is
expecting to send to
        // and receive from the databinding interceptor. The
request/response parts of
        // this interface contract will be copied into the binding
interface contract
        // as required
        WebServiceBindingFactory wsFactory =
registry.getExtensionPoint(WebServiceBindingFactory.class);
        WebServiceBinding wsBinding = wsFactory.createWebServiceBinding();
        BindingWSDLGenerator.generateWSDL(component, service,
wsBinding, registry, null);
        interfaceContract = wsBinding.getBindingInterfaceContract();
        interfaceContract.getInterface().resetDataBinding(OMElement.class.getName());

You will not that what is happening here is that a WSDL interaface
contract is being fluffed up for the service as this particular wire
format expects data to be passed as XML and hence we need the schema
etc. Lastly not that the databinding for the interface contract is set
to OMElement to force the databinding layer to do XML <-> Java
transformations.

Once this is done the configureWireFormatInterfaceContract is used to
configure request and response contract information...

    public InterfaceContract
configureWireFormatInterfaceContract(InterfaceContract
interfaceContract){

        if (this.interfaceContract != null) {
            if (this.binding.getRequestWireFormat() instanceof
WireFormatJMSTextXML){
                // set the request data transformation

interfaceContract.getInterface().resetInterfaceInputTypes(this.interfaceContract.getInterface());
            }
            if (this.binding.getResponseWireFormat() instanceof
WireFormatJMSTextXML){
                // set the response data transformation

interfaceContract.getInterface().resetInterfaceOutputTypes(this.interfaceContract.getInterface());
            }
        }

        return interfaceContract;
    }

Notice here that input and output types are set independently. Again,
in your case, where you have JSON going in and out you should only
need to set the interface as a whole and not the inputs and output
independently.

The interceptors then have no responsibility for setting interface
contract configuration.

Hope that helps.

Simon