You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2009/03/10 16:40:28 UTC
[1.x][2.x] separate wireFormats for request and response paths
We have some code in the wireFormat framework that takes steps towards
allowing different wire formats on requests and responses. However
this doesn't work yet as the databinding framework also needs suitable
configuration. Currently it seems that the databinding framework
configuration is driven by the interface contract on the binding
provider and hence doesn't allow for separate request and response
configurations.
This is also embodied in the wire and interface structures. The base
InterfaceImpl resetDataBinding() operation sets the databing for input
and output parameters to be the same.
The databinding framework itself does seem to allow for this in its
detailed structures but its not clear how to enable it without making
changes.
Has this been considered in the past and discounted?
Is there a way to suitably configure the databinding framework?
Regards
Simon
Re: [1.x][2.x] separate wireFormats for request and response paths
Posted by Scott Kurz <sc...@gmail.com>.
On Tue, Mar 24, 2009 at 7:34 AM, Simon Laws <si...@googlemail.com> wrote:
> So, base on comments from Scott and Raymond, these are the changes I'm planning
>
> - Fix up the binding.jms XSD to allow "any" content within the
> <response> . This will allow wireFormat elements from the Tuscany
> namespace to be included here which can't be done at the moment. Any
> concerns about this schema modification?
Just wanted to mention there's an OASIS JIRA open here:
http://www.osoa.org/jira/browse/BINDINGS-71
though since in 1.x we haven't introduced WireFormatType, etc., right?
so maybe "any" is better for now.
> - Change the jms binding providers to create a local interface
> contract by cloning the interface contract from the local reference or
> service
So I think this amounts to saying that the question of whether or not
a DataTransformationInterceptor will still be satisfactorily answered
by DataBindingRuntimeWireProcessor, (once we at least clone the
original IC), given that the DTI itself has the ability to no-op when
both sides' DataType(s) are equals(). I was wondering if this were
the case, sounds like you've given it some thought, so if it pans out
this way, great.
> - Change the wire format interface to support a method to reconfigure
> the binding interface contract. The wire format providers will then
> have the opportunity to reset the binding interface contract, in
> either the request or response direction, based on the interface
> contract style and data format they expect
Sounds good.
> - Change the interface implementation to allow operation input types
> and output types/faults to be reset independently.
Sounds helpful. I guess probably better to break apart outputs &
faults in anticipation of them using different databindings in a
future use case.
> - Change the operation model to represent separate input and output
> wrappers rather than the single wrapper info based model that we have
> at the moment. This will require a number of changes elsewhere to take
> account of this
I can't think of anything helpful to add, except to say thanks for
tackling this, since this last task seems like the hardest part.
Scott
Re: [1.x][2.x] separate wireFormats for request and response paths
Posted by Simon Laws <si...@googlemail.com>.
So, base on comments from Scott and Raymond, these are the changes I'm planning
- Fix up the binding.jms XSD to allow "any" content within the
<response> . This will allow wireFormat elements from the Tuscany
namespace to be included here which can't be done at the moment. Any
concerns about this schema modification?
- Change the jms binding providers to create a local interface
contract by cloning the interface contract from the local reference or
service
- Change the wire format interface to support a method to reconfigure
the binding interface contract. The wire format providers will then
have the opportunity to reset the binding interface contract, in
either the request or response direction, based on the interface
contract style and data format they expect
- Change the interface implementation to allow operation input types
and output types/faults to be reset independently.
- Change the operation model to represent separate input and output
wrappers rather than the single wrapper info based model that we have
at the moment. This will require a number of changes elsewhere to take
account of this
Any comments/concerns are most welcome.
Regards
Simon
Re: [1.x][2.x] separate wireFormats for request and response paths
Posted by Simon Laws <si...@googlemail.com>.
I checked in an initial pass at a test to motivate this work. You can
find it here [1] but of course it doesn't do anything useful yet as
the code doesn't actually work. The composite for this test shows
wireFormat.jmsTextXML being used on request messages and
wireFormat.jmsObject being used on response messages.
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
targetNamespace="http://helloworld"
xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0"
xmlns:hw="http://helloworld"
name="helloworld">
<component name="HelloWorldReferenceComponent">
<implementation.java
class="org.apache.tuscany.sca.binding.jms.format.jmstextxmlinjmsobjectout.helloworld.HelloWorldReferenceImpl"
/>
<reference name="helloWorldService1" >
<binding.jms>
<destination name="HelloWorldService1"/>
<response>
<tuscany:wireFormat.jmsObject/>
</response>
<tuscany:wireFormat.jmsTextXML/>
</binding.jms>
</reference>
</component>
<component name="HelloWorldServiceComponent1">
<implementation.java
class="org.apache.tuscany.sca.binding.jms.format.jmstextxmlinjmsobjectout.helloworld.HelloWorldServiceImpl"
/>
<service name="HelloWorldService">
<binding.jms>
<destination name="HelloWorldService1"/>
<response>
<tuscany:wireFormat.jmsObject/>
</response>
<tuscany:wireFormat.jmsTextXML/>
</binding.jms>
</service>
</component>
</composite>
With binding.jms this could be useful as the response destination may
be completely divorced from the source of the request message and
therefore have different requirements.
Regards
Simon
[1] http://svn.apache.org/repos/asf/tuscany/branches/sca-java-1.x/itest/jms-format/src/test/java/org/apache/tuscany/sca/binding/jms/format/FormatJMSTextXMLInJMSObjectOutTestCase.java
Re: [1.x][2.x] separate wireFormats for request and response paths
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Mar 16, 2009 at 3:53 PM, Simon Laws <si...@googlemail.com> wrote:
> snip...
>> I think an interesting question to ask is: am I requiring that the
>> application/componentType databinding be split out into an
>> input/output introspection/calculation in my motivating use case. A
>> quick review makes me think the answer is 'no'. Maybe I'm not
>> thinking this through all the way yet, but if I'm right then we only
>> have to worry about a new granularity in configuring the binding
>> interface model.
>
> Right, I think the binding interface model is the one we need to
> update. The component type should remain the same as we nee to
> transform to/from those types as specified.
>
>>
>> In the WF cases in which we bypass the DataTransformationInterceptor
>> today, I'm not sure if it's because of some non-trivial code which
>> would need to be written to do so or is it just because of convenience
>> (or performance?). I can see in
>> DataTransformationInterceptor.transform() that we already have a path
>> to do a no-op in case the two DataType(s) are equals(), so it seems
>> some part of the functionality must be there to let DTI do a no-op
>> rather than bypassing DTI altogether by not establishing it as an
>> interceptor on the chain.
>
> Not sure why it is as it is. I suppose it is a small performance
> optimization in missing out the interceptor altogether.
>
> Simon
>
Right I'm going to have a go at this so have raised TUSCANY-2931 to
track changes.
Simon
Re: [1.x][2.x] separate wireFormats for request and response paths
Posted by Simon Laws <si...@googlemail.com>.
snip...
> I think an interesting question to ask is: am I requiring that the
> application/componentType databinding be split out into an
> input/output introspection/calculation in my motivating use case. A
> quick review makes me think the answer is 'no'. Maybe I'm not
> thinking this through all the way yet, but if I'm right then we only
> have to worry about a new granularity in configuring the binding
> interface model.
Right, I think the binding interface model is the one we need to
update. The component type should remain the same as we nee to
transform to/from those types as specified.
>
> In the WF cases in which we bypass the DataTransformationInterceptor
> today, I'm not sure if it's because of some non-trivial code which
> would need to be written to do so or is it just because of convenience
> (or performance?). I can see in
> DataTransformationInterceptor.transform() that we already have a path
> to do a no-op in case the two DataType(s) are equals(), so it seems
> some part of the functionality must be there to let DTI do a no-op
> rather than bypassing DTI altogether by not establishing it as an
> interceptor on the chain.
Not sure why it is as it is. I suppose it is a small performance
optimization in missing out the interceptor altogether.
Simon
Re: [1.x][2.x] separate wireFormats for request and response paths
Posted by Scott Kurz <sc...@gmail.com>.
On Mon, Mar 16, 2009 at 11:09 AM, Simon Laws <si...@googlemail.com> wrote:
>
> Currently the infrastructure relies on resetting the databinding on
> the interface for a service or reference and the wire format providers
> take charge of doing this. However the function is such at the moment
> that it resets the data binding en-masse for all operations and all
> input and output parameters.
>
> Raymond has suggested, I think, that extra function could be added to
> provided this extra fidelity.
Right. Raymond was suggesting that, rather than relying on the
convenience of resetDataBinding, we might need to configure the
input/output of the binding interface models separately.
I think an interesting question to ask is: am I requiring that the
application/componentType databinding be split out into an
input/output introspection/calculation in my motivating use case. A
quick review makes me think the answer is 'no'. Maybe I'm not
thinking this through all the way yet, but if I'm right then we only
have to worry about a new granularity in configuring the binding
interface model.
In the WF cases in which we bypass the DataTransformationInterceptor
today, I'm not sure if it's because of some non-trivial code which
would need to be written to do so or is it just because of convenience
(or performance?). I can see in
DataTransformationInterceptor.transform() that we already have a path
to do a no-op in case the two DataType(s) are equals(), so it seems
some part of the functionality must be there to let DTI do a no-op
rather than bypassing DTI altogether by not establishing it as an
interceptor on the chain.
Scott.
Re: [1.x][2.x] separate wireFormats for request and response paths
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Mar 10, 2009 at 6:42 PM, Scott Kurz <sc...@gmail.com> wrote:
> On Tue, Mar 10, 2009 at 12:26 PM, Raymond Feng <en...@gmail.com> wrote:
>>
>> * Having an example will help us better understand the requirements.
>> * For each operation, there is an inputType and an outputType. They can be
>> configured with different databindings. It's up to the binding provider to
>> understand the wireFormat for requests and responses and then reflect that
>> in the Operation model.
>
> What about, as a motivating example, a case where a service with a
> 2-way operation is bound with binding.jms with a SCDL-specified
> response destination, but it is not really a "response" but more of a
> "forward" to a new message consumer. This might make it appear more
> natural to use a different WF for req/resp.
>
> One thing to note is that, if we mix-and-match the JMS WFs we support
> today, we don't really end up with any cases where the
> DataTransformationInterceptor needs to be used for both req/resp, but
> in different ways. We only end up with cases where one way uses the
> interceptor and the other needs to bypass it completely. Not to say
> it wouldn't be worth to think about a more general solution, but a
> motivation isn't leaping to mind immediately.
>
> Scott
>
Hi, issue with data transformation isn't so much that the
DataTransformationInterceptor has to do different things in each
direction (although, as you suggest, in may only have to operate in
one direction) it's a question of how we tell it what to do. Even in
the case of doing something or nothing.
Currently the infrastructure relies on resetting the databinding on
the interface for a service or reference and the wire format providers
take charge of doing this. However the function is such at the moment
that it resets the data binding en-masse for all operations and all
input and output parameters.
Raymond has suggested, I think, that extra function could be added to
provided this extra fidelity.
Re. your specific example. It think you are suggesting something like
request
-----------
reference---> wireFormat.jmsTextXML ----> Axiom/JAXB transform ----> service
response
------------
some response target <---- wireFormat.jmsText <----- no transform <---- service
Regards
Simon
Re: [1.x][2.x] separate wireFormats for request and response paths
Posted by Scott Kurz <sc...@gmail.com>.
On Tue, Mar 10, 2009 at 12:26 PM, Raymond Feng <en...@gmail.com> wrote:
>
> * Having an example will help us better understand the requirements.
> * For each operation, there is an inputType and an outputType. They can be
> configured with different databindings. It's up to the binding provider to
> understand the wireFormat for requests and responses and then reflect that
> in the Operation model.
What about, as a motivating example, a case where a service with a
2-way operation is bound with binding.jms with a SCDL-specified
response destination, but it is not really a "response" but more of a
"forward" to a new message consumer. This might make it appear more
natural to use a different WF for req/resp.
One thing to note is that, if we mix-and-match the JMS WFs we support
today, we don't really end up with any cases where the
DataTransformationInterceptor needs to be used for both req/resp, but
in different ways. We only end up with cases where one way uses the
interceptor and the other needs to bypass it completely. Not to say
it wouldn't be worth to think about a more general solution, but a
motivation isn't leaping to mind immediately.
Scott
Re: [1.x][2.x] separate wireFormats for request and response paths
Posted by Raymond Feng <en...@gmail.com>.
Please see my comments inline.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <si...@googlemail.com>
Sent: Tuesday, March 10, 2009 8:40 AM
To: "tuscany-dev" <de...@tuscany.apache.org>
Subject: [1.x][2.x] separate wireFormats for request and response paths
> We have some code in the wireFormat framework that takes steps towards
> allowing different wire formats on requests and responses. However
> this doesn't work yet as the databinding framework also needs suitable
> configuration. Currently it seems that the databinding framework
> configuration is driven by the interface contract on the binding
> provider and hence doesn't allow for separate request and response
> configurations.
* Having an example will help us better understand the requirements.
* For each operation, there is an inputType and an outputType. They can be
configured with different databindings. It's up to the binding provider to
understand the wireFormat for requests and responses and then reflect that
in the Operation model.
>
> This is also embodied in the wire and interface structures. The base
> InterfaceImpl resetDataBinding() operation sets the databing for input
> and output parameters to be the same.
>
* We should take "resetDataBinding" as a convenient method to set a uniform
databinding for all types used by the interface. It's still possible that we
set different databindings for types used by the interface/operation.
> The databinding framework itself does seem to allow for this in its
> detailed structures but its not clear how to enable it without making
> changes.
>
> Has this been considered in the past and discounted?
> Is there a way to suitably configure the databinding framework?
* We had some discussions before on this ML about the granularity. Some
people viewed that having parameters or return value of the same operation
use different databindings is a bit crazy :-). I'm open to any valid use
cases though.
>
> Regards
>
> Simon