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 2008/10/02 14:45:00 UTC
Re: Request Response Binding - was: Re: Tuscany data binding framework enhancements
On Mon, Sep 29, 2008 at 2:35 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Thu, Sep 11, 2008 at 2:29 PM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Tue, Sep 9, 2008 at 6:00 AM, Jean-Sebastien Delfino <
>> jsdelfino@apache.org> wrote:
>>
>>> From: Simon Laws
>>>>
>>> ...
>>>
>>>> Leading on from this we seem to need to hold header info in the Tuscany
>>>> message. I've added the following to the message interface to support some
>>>> policy experiments I've been doing but am open to suggestions...
>>>>
>>>> Map<String, Object> getHeader();
>>>>
>>>>
>>> Here's a suggestion:
>>>
>>> List<Object> getHeaders();
>>>
>>> - there's multiple headers (the trailing 's' makes that clear)
>>> - a List supports multiple instances of a named header
>>> - and is closer to a JAXB representation of XML <header>*
>>>
>>> Hope this helps.
>>> --
>>> Jean-Sebastien
>>>
>>
>> Apologies Sebastien, I didn't come back to you on this suggestion. I had
>> in the back of my mind that having multiple headers with the same name could
>> cause problems in terms of knowing what to do with them as they are
>> extracted from the native message. If we're just pushing message headers
>> into the Tuscany message then duplicates aren't a problem I guess. If we're
>> trying to map them to operation parameters then it could be more problematic
>> as it's difficult to tell which named header maps to which parameter. I may
>> be talking my way into agreeing that multiple headers with the same name in
>> the Tuscany specific message is OK though with it being a binding problem if
>> it can't then translate that into something sensible on the native wire.
>>
>> Simon
>>
>
> Hi
>
> This thread has been quiet for a couple of weeks, I notice in the mean time
> that Raymond and Ant have added more details to the wiki page on this
> subject [1]. I've re-organized the page to start pulling the Request
> Response Binding ideas together using the JMS binding as an example.
>
> Regardless of how the OASIS TC decide to specify the selection of, for
> example, wire format, I'd like to do some more work on how we might add
> binding specific interceptors to our runtime assuming that the model
> contains approriate information. Raymond made a proposal [1] but we need to
> look at the details. Specifically how are interceptors chosen and called?
>
> The binding provide knows what's in the model and could be extended to give
> it more control for organizing interceptors so I'd like to start there to
> see what can be done.
>
> Regards
>
> Simon
>
> [1]
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Request+Response+Binding
>
So if we imagine that the wireFormat/operationSelection proposal comes to
pass in the various binding specifications in OASIS I'm interested in what
the implications would be for the Tuscany runtime.
A binding would contain some extensibility elements the result of which
would be additional/alternative message interceptors for doing wire format
and message selection processing at the reference and service. How are these
interceptors get created and how are they placed on the wire.
Taking wire formats as an example I would imagine that there are two
mechanisms;
1. For default transformations the reference or service binding provider can
look up the default interceptor based on the wire format element name in the
binding
2. For custom transformations we need to allow the class name of the
interceptor to be specified somewhere. What OASIS come up could have a
bearing on this. If it really is a class name the interceptor could be
loaded directly by the binding provider. If it was abstract in some way then
another provider structure would be required.
I've started expanding the notes at
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Request+Response+Bindingwith
scenarios that look at some possibilities. I'm particularly interested
in those who put the provider framwork in place see the addition of binding
configuration see this as an extension of the binding providers or see this
as a new set of providers?
Regards
Simon
Re: Request Response Binding - was: Re: Tuscany data binding framework enhancements
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Nov 4, 2008 at 10:49 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Thu, Oct 23, 2008 at 3:55 PM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Thu, Oct 23, 2008 at 8:12 AM, Simon Laws <si...@googlemail.com>wrote:
>>
>>>
>>>
>>> On Thu, Oct 23, 2008 at 12:11 AM, Raymond Feng <en...@gmail.com>wrote:
>>>
>>>> Hi,
>>>>
>>>> I checked in a change under r707218.
>>>>
>>>> 1) Add getBindingInvocation() method to RuntimeWire to build up an
>>>> invocation for the binding endpoint.
>>>> 2) Define two more stages (reference.binding and service.binding) and a
>>>> few built-in phases for these two stages.
>>>>
>>>> I think there are opportunities to further rationalize/cleanup the
>>>> following interfaces:
>>>>
>>>> Endpoint and EndpointReference
>>>> RuntimeWire and EndpointWire
>>>>
>>>> Thanks,
>>>> Raymond
>>>>
>>>> From: Simon Laws
>>>> Sent: Tuesday, October 21, 2008 6:32 AM
>>>> To: dev@tuscany.apache.org ; antelder@apache.org
>>>> Subject: Re: Request Response Binding - was: Re: Tuscany data binding
>>>> framework enhancements
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Oct 17, 2008 at 10:36 AM, Simon Laws <si...@googlemail.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Oct 17, 2008 at 10:16 AM, ant elder <an...@apache.org>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Oct 7, 2008 at 9:07 AM, ant elder <an...@apache.org> wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Oct 6, 2008 at 6:07 PM, Simon Laws <si...@googlemail.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Oct 6, 2008 at 5:49 PM, ant elder <an...@apache.org> wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Oct 6, 2008 at 1:58 PM, Simon Laws <si...@googlemail.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Oct 3, 2008 at 8:35 AM, ant elder <an...@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Oct 2, 2008 at 1:45 PM, Simon Laws <si...@googlemail.com>
>>>> wrote:
>>>>
>>>> <snip>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I'm particularly interested in those who put the provider framwork in
>>>> place see the addition of binding configuration see this as an extension of
>>>> the binding providers or see this as a new set of providers?
>>>>
>>>>
>>>>
>>>> This is looking like a new type of extension to me, people should be
>>>> able to contribute new wireFormatters and have them made available for use
>>>> within the Tuscany runtime. Its also looking like this should be possible to
>>>> do at the application level.
>>>>
>>>> So Tuscany would come with a bunch of wireFormat extensions just like it
>>>> already has a bunch of binding and implementation extensions. Something
>>>> somewhere would define what the default wireFormat extension is to use with
>>>> each binding when no <wireFormat> element is in the SCDL. So there would be
>>>> a self contained JMS wireformat extension which implements the defaults as
>>>> defined in section 5.2 in the JMS binding spec and you'd be able to do:
>>>>
>>>> <reference ...>
>>>> <binding.jms>
>>>> <wireFormat.jms/>
>>>> </binding.jms>
>>>> </reference>
>>>>
>>>> but that would be the default so the same as:
>>>>
>>>> <reference ...>
>>>> <binding.jms />
>>>> </reference>
>>>>
>>>> Users could also do
>>>>
>>>> <reference ...>
>>>> <binding.jms>
>>>> <wireFormat.myFunkyFormatter/>
>>>> </binding.jms>
>>>> </reference>
>>>>
>>>> and have the 'myFunkyFormatter' extension as part of their application
>>>> not some jar that needs to be added to the Tuscany runtime.
>>>>
>>>> We could use the definitions.xml file to define things like the default
>>>> formatter for a binding, it also seems like that old discussion on using the
>>>> definitions.xml file to declare the extensions would help with the
>>>> myFunkyFormatter case as described at:
>>>> http://apache.markmail.org/message/unubgkqdcwwch66m
>>>>
>>>> ...ant
>>>>
>>>>
>>>>
>>>>
>>>> So there are two points here then
>>>>
>>>> 1. wireFormat as a separate extension point.
>>>>
>>>> Ok so that could work. We would need the usual provider structure for
>>>> wireFormat and operationSelection. Then we need some new bits to get the
>>>> associated interceptors in the right place.
>>>>
>>>> - A wire structure managed by the bindingListener/bindingInvoker
>>>> - some predefined "wire format" and "operation selection" phases on the
>>>> new wire that ensure that the interceptors get put in the correct place
>>>> - A mechanism where, as you suggest, the binding can instigate defaults
>>>> when no specifics are included in the SCDL. This could be as easy as
>>>> completing the model based on definitions.xml entries
>>>> - Code to read the model, select the appropriate factory and popoulate
>>>> the new wire with interceptors from the binding and from wireFormat and
>>>> operationSelector
>>>>
>>>> 2. extension points (wireFormat in this case) provided in SCA
>>>> contributions
>>>>
>>>> Personally I'd like to keep this separate from 2 for the time being.
>>>> Only because it's easier in the first instance to go with adding extensions
>>>> via the META-INF/services mechanisms while we work out what the extension
>>>> points should look like. Having looked back over the ML conversation on
>>>> definitions.xml though it does seem that there was a desire to allow some
>>>> extensions to be added to the runtime as part of a contribution. We can't
>>>> even do this with policy today so something like wireFormat would be a
>>>> isolated case to look at. I still want to get the extension point right
>>>> first though. Doesn't stop others looking at this if they want to of course.
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>> Do you mean do this with a stepping stone approach, so do (1) then do
>>>> (2), or do you mean only do (1) and if someone out there in the community
>>>> ever feels like contributing (2) then good for them and we'd probably take
>>>> it? I'm asking because if users can't contribute a custom wireFormat then
>>>> we'll need to provide a way to configure some Tuscany specific one, and if
>>>> thats all we're doing how is that better than Tuscany's current approach of
>>>> having some Tuscany specific attributes on the binding.jms element?
>>>>
>>>> ...ant
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Yes, as a stepping stone. I was just presenting how I would approach it
>>>> while trying to make space for anyone who might have a real urge to get on
>>>> an look at the user provided extension point part.
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>> Sounds good.
>>>>
>>>> ...ant
>>>>
>>>>
>>>>
>>>> I'm doing some refactoring of the jms binding to make some function more
>>>> plugable for various runtime environments (eg running in Geronimo and using
>>>> Geronimo JMS provider) so while i'm doing this i thought i'd make a start at
>>>> adding support for some wireFormat based on whats been discussed in this
>>>> thread. Mainly refactoring things like the current databinding and message
>>>> processor support out into clear and separate peices so this should make it
>>>> easier to plug in/replace the function when the wireFormat support gets
>>>> added to the Tuscany core runtime.
>>>>
>>>> ...ant
>>>>
>>>>
>>>> Sounds good ant. Am working on JMS tests and some initial infrastructure
>>>> changes to demonstrate the wire format support at the moment but stuck with
>>>> a very peculiar ant build problem atm so don't have anything to check in
>>>> just yet.
>>>>
>>>> Simon
>>>>
>>>>
>>>> Hi, I just checked in (r706620) some early experiments in representing
>>>> wireFormat and operationSelection as interceptors on a binding chain. My
>>>> first impression when trying to implement our thoughts from this thread and
>>>> recorded at [1] is that it doesn't work very well.
>>>>
>>>> The JMS binding is a good motivator for this exercise primarily because
>>>> the wire format and operation selection processing is relatively
>>>> complicated. The reason that the wire based approach is not immediately
>>>> effective is that the JMS binding simulates RPC behavior by initiating
>>>> response messages. You can configure the JMS binding with a response
>>>> destination and a wireFromat no doubt (no OASIS word on this but you can
>>>> imagine it happening) and hence the processing of a response is not
>>>> necessarily as simple as unwinding the stack on a chain of intercpetors. The
>>>> interceptors may need to be different for requests and responses.
>>>>
>>>> Easy enough to make this happen. Just invent request interceptors and
>>>> response interceptors and install the right ones. However it's starting to
>>>> get complicated.
>>>>
>>>> To get a feel for what this means I have been experimenting with the
>>>> service side of the JMS binding. I've created a new binding listener
>>>> (RRBJMSBindingListener) that is only fired up if a wireFormat is found in
>>>> the SCDL. This gives rise to wireFormat and operationSelection interceptors
>>>> being installed on a binding wire. The binding wire is currently represented
>>>> inside of RRBJMSBindingListener and in fact there are two. A request wire
>>>> and a response wire. There is also a BindingInterceptor interface that
>>>> allows the request and response processing to be called independently and
>>>> which doesn't assume that the Interceptors are chained.
>>>>
>>>> The next thing I'm going to do is enable the JMSBytes wire format so I
>>>> have two options to play with and then look at how the reference side should
>>>> work. With this info we can look at whether this is going to fly and how
>>>> this binding wire support should be factored.
>>>>
>>>> Simon
>>>>
>>>> [1]
>>>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Request+Response+Binding
>>>>
>>>
>>> Hey, thanks Raymond. Let me try and merge the two pieces together.
>>>
>>> Simon
>>>
>>
>> Looks good Raymond I've done the initial merge (r707394). A couple of
>> initial comments:
>>
>> - I notice that the InterceptorChain asserts that the operations are
>> non-null but null is passed in in the binding chain case. I've commented out
>> the assertions for now.
>> - I've changed the RuntimeWireInvoker to be and invoker so that I can add
>> it to the end of the binding chain on the service side. The runtime wire
>> invoker needs refactoring as we promised to do ages ago, i.e. conversation,
>> callback interceptors
>> - The response path from the invcation chain to the binding chain is a bit
>> unatural as the response object is taken out of the response message and I
>> then (hackily) stuff it back in the request message. This set of invoke
>> methods need refactoring.
>>
>> Still lots of other things to do. In the short term this is my list.
>>
>> - Create a JMS binding context to pass around in the message header to
>> contain JMS message and session etc. (would be followed by other contexts,
>> such as security)
>> - Do a little bit of tidying on the response path from InvocationChain to
>> BindingChain
>> - Create the reference side interceptors for the jms binding and fix up
>> the binding to place them on the binding chain and use it
>> - Review all these new interceptors to see if the separation of function
>> is correct
>> - Create another jms binding wire format for comparison
>>
>> In the medium term I agree with your list of things to rationalize and I
>> would add another;
>>
>> Endpoint and EndpointReference
>> RuntimeWire and EndpointWire
>> RuntimeWireInvoker
>>
>> The test I'm using for this is itest/jms-format. It's not in the main
>> build yet.
>>
>> Regards
>>
>> Simon
>>
>
> Update on where I have got to. I went through the short term list of TODOs
>
> - Create a JMS binding context to pass around in the message header to
> contain JMS message and session etc. (would be followed by other contexts,
> such as security)
> - Do a little bit of tidying on the response path from InvocationChain to
> BindingChain
> - Create the reference side interceptors for the jms binding and fix up the
> binding to place them on the binding chain and use it
> - Review all these new interceptors to see if the separation of function is
> correct
> - Create another jms binding wire format for comparison
>
> The JMS binding is now running with a binding wire and with the function
> from the invoker and listener spread out across a number of binding wire
> interceptors thus;
>
> Reference .... JMSBindingInoker -> Wire format -> Policy -> Transport
> ---------->
> --------------> BindingListener -> Transport -> OperationSelection ->
> WireFormat -> Policy -> RuntimeWireInvoker ....Service
>
> This new function can easily be turned of with to on line changes in the
> jms binding providers.
>
> Some thoughts on where we are now.
>
> 1) I'm not absolutely convinced we need the binding wire construct. If it
> were not for operation selection we could retain the wire per operation
> model end to end. We could replace RuntimeWireInvoker with pluggable
> OperationSelection
>
> 2) WireFormat is conceptually problematic. We need to be really clear on
> it's role compared to databinding and how the end to end data transformation
> is controlled by binding and service contracts.
>
> 2.1) The code, on the service side, currently is as follows.
>
> BindingListener (BindingContract) -> Transport -> OperationSelection
> -> WireFormat -> Policy -> RuntimeWireInvoker -> DataBinding -> Service
> (ServiceImplementationContract)
>
> Databinding - translated data between the format indicated by the
> BindingContract and the ServiceImplementatonContract.
> WireFormat - takes data off the wire and converts it to the in memory
> form required by the BindingContract.
>
> I'd like to understand a bit more about how the databinding decides
> what transformation is required. AFAICT it just looks at the databinding
> information associated with the BindingContract and
> ServiceImplementationContract.
>
> 2.2) There is a notion in the OASIS spec that the wire format of the
> reponse could be different for that of the request. This is problematic in
> the sense that some wire formats imply a service implementation interface
> style. It seems that we only have one slot to record a databinding
> preference for an interface. Again I need to know more about databinding.
> I'm looking but some help here would be appreciated.
>
> 3) There is awful lot more code doing things this way.
> 3.1) I would like to get rid of the policy/WireFormat/OperationSelector
> provides and just have the factories create the interceptors. Providers
> don't seem to add value here
> 3.2) I maybe overfactored some of the binding code out of the
> listener/invoker when maybe it could have stayed. Now it's up an runnning am
> going to review.
>
> 4) I've created a JMS context that gets passed in the tuscany message as
> part of the header. This works well. It defined the SPI for the binding
> information and sets the scene for other contexts that could be provided in
> the future e.g. security. With the header being a list I put it in a set
> position so I don't have to cycle through the list in each interceptor. I'd
> prefer it if we had a bindingcontext field on the tuscany message though.
>
> 5) If we decide to go ahead with the OASIS related stuff we need to get the
> OASIS license, etc. into the schema that have been extended with these
> items. core and jms binding
>
> Anyhow, this is long enough already. Toughts and comment most welcome. I'll
> post again as I find out more.
>
> Simon
Another update. I checked some more changes into the JMS binding to support
request/response binding[1]. I've changed the following.
I've removed the OAISIS schema definitions and the support in the code
currently relies on Tuscany specific wire format and operation selection
elements only. This leverages the extensibility of the binding element and
hence the wire format elements are not validated against the schema
I moved the model parts to the binding-jms module
I've plugged in the wireFormat function into the message process selection
so that regarless of how you configure the JMS binding now it will use the
new interceptors.
I added text and object wire formatters so that all of the existing tests
still run
The response specific wire format is not plugged into databinding yet but
I'm waiting to see what OASIS come up with before committing to doing that
I've pretty much got to where I wanted to get to with the JMS binding. Now
that the basic support for this is in the next things I want to look at are
(in no particular order).
- Converting policy support to use the binding wire
- Converting conversation and callback support into interceptors
- Endpoints and the inpact of this and the thoughts that have been raised
previously about extended their application
Any thoughts/comments are most welcome.
Simon
[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Request+Response+Binding
Re: Request Response Binding - was: Re: Tuscany data binding framework enhancements
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Oct 23, 2008 at 3:55 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Thu, Oct 23, 2008 at 8:12 AM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Thu, Oct 23, 2008 at 12:11 AM, Raymond Feng <en...@gmail.com>wrote:
>>
>>> Hi,
>>>
>>> I checked in a change under r707218.
>>>
>>> 1) Add getBindingInvocation() method to RuntimeWire to build up an
>>> invocation for the binding endpoint.
>>> 2) Define two more stages (reference.binding and service.binding) and a
>>> few built-in phases for these two stages.
>>>
>>> I think there are opportunities to further rationalize/cleanup the
>>> following interfaces:
>>>
>>> Endpoint and EndpointReference
>>> RuntimeWire and EndpointWire
>>>
>>> Thanks,
>>> Raymond
>>>
>>> From: Simon Laws
>>> Sent: Tuesday, October 21, 2008 6:32 AM
>>> To: dev@tuscany.apache.org ; antelder@apache.org
>>> Subject: Re: Request Response Binding - was: Re: Tuscany data binding
>>> framework enhancements
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Oct 17, 2008 at 10:36 AM, Simon Laws <si...@googlemail.com>
>>> wrote:
>>>
>>>
>>>
>>>
>>> On Fri, Oct 17, 2008 at 10:16 AM, ant elder <an...@apache.org> wrote:
>>>
>>>
>>>
>>>
>>> On Tue, Oct 7, 2008 at 9:07 AM, ant elder <an...@apache.org> wrote:
>>>
>>>
>>>
>>>
>>> On Mon, Oct 6, 2008 at 6:07 PM, Simon Laws <si...@googlemail.com>
>>> wrote:
>>>
>>>
>>>
>>>
>>> On Mon, Oct 6, 2008 at 5:49 PM, ant elder <an...@apache.org> wrote:
>>>
>>>
>>>
>>>
>>> On Mon, Oct 6, 2008 at 1:58 PM, Simon Laws <si...@googlemail.com>
>>> wrote:
>>>
>>>
>>>
>>>
>>> On Fri, Oct 3, 2008 at 8:35 AM, ant elder <an...@gmail.com> wrote:
>>>
>>>
>>>
>>>
>>> On Thu, Oct 2, 2008 at 1:45 PM, Simon Laws <si...@googlemail.com>
>>> wrote:
>>>
>>> <snip>
>>>
>>>
>>>
>>>
>>>
>>> I'm particularly interested in those who put the provider framwork in
>>> place see the addition of binding configuration see this as an extension of
>>> the binding providers or see this as a new set of providers?
>>>
>>>
>>>
>>> This is looking like a new type of extension to me, people should be able
>>> to contribute new wireFormatters and have them made available for use within
>>> the Tuscany runtime. Its also looking like this should be possible to do at
>>> the application level.
>>>
>>> So Tuscany would come with a bunch of wireFormat extensions just like it
>>> already has a bunch of binding and implementation extensions. Something
>>> somewhere would define what the default wireFormat extension is to use with
>>> each binding when no <wireFormat> element is in the SCDL. So there would be
>>> a self contained JMS wireformat extension which implements the defaults as
>>> defined in section 5.2 in the JMS binding spec and you'd be able to do:
>>>
>>> <reference ...>
>>> <binding.jms>
>>> <wireFormat.jms/>
>>> </binding.jms>
>>> </reference>
>>>
>>> but that would be the default so the same as:
>>>
>>> <reference ...>
>>> <binding.jms />
>>> </reference>
>>>
>>> Users could also do
>>>
>>> <reference ...>
>>> <binding.jms>
>>> <wireFormat.myFunkyFormatter/>
>>> </binding.jms>
>>> </reference>
>>>
>>> and have the 'myFunkyFormatter' extension as part of their application
>>> not some jar that needs to be added to the Tuscany runtime.
>>>
>>> We could use the definitions.xml file to define things like the default
>>> formatter for a binding, it also seems like that old discussion on using the
>>> definitions.xml file to declare the extensions would help with the
>>> myFunkyFormatter case as described at:
>>> http://apache.markmail.org/message/unubgkqdcwwch66m
>>>
>>> ...ant
>>>
>>>
>>>
>>>
>>> So there are two points here then
>>>
>>> 1. wireFormat as a separate extension point.
>>>
>>> Ok so that could work. We would need the usual provider structure for
>>> wireFormat and operationSelection. Then we need some new bits to get the
>>> associated interceptors in the right place.
>>>
>>> - A wire structure managed by the bindingListener/bindingInvoker
>>> - some predefined "wire format" and "operation selection" phases on the
>>> new wire that ensure that the interceptors get put in the correct place
>>> - A mechanism where, as you suggest, the binding can instigate defaults
>>> when no specifics are included in the SCDL. This could be as easy as
>>> completing the model based on definitions.xml entries
>>> - Code to read the model, select the appropriate factory and popoulate
>>> the new wire with interceptors from the binding and from wireFormat and
>>> operationSelector
>>>
>>> 2. extension points (wireFormat in this case) provided in SCA
>>> contributions
>>>
>>> Personally I'd like to keep this separate from 2 for the time being. Only
>>> because it's easier in the first instance to go with adding extensions via
>>> the META-INF/services mechanisms while we work out what the extension points
>>> should look like. Having looked back over the ML conversation on
>>> definitions.xml though it does seem that there was a desire to allow some
>>> extensions to be added to the runtime as part of a contribution. We can't
>>> even do this with policy today so something like wireFormat would be a
>>> isolated case to look at. I still want to get the extension point right
>>> first though. Doesn't stop others looking at this if they want to of course.
>>>
>>> Simon
>>>
>>>
>>>
>>> Do you mean do this with a stepping stone approach, so do (1) then do
>>> (2), or do you mean only do (1) and if someone out there in the community
>>> ever feels like contributing (2) then good for them and we'd probably take
>>> it? I'm asking because if users can't contribute a custom wireFormat then
>>> we'll need to provide a way to configure some Tuscany specific one, and if
>>> thats all we're doing how is that better than Tuscany's current approach of
>>> having some Tuscany specific attributes on the binding.jms element?
>>>
>>> ...ant
>>>
>>>
>>>
>>>
>>>
>>> Yes, as a stepping stone. I was just presenting how I would approach it
>>> while trying to make space for anyone who might have a real urge to get on
>>> an look at the user provided extension point part.
>>>
>>> Simon
>>>
>>>
>>>
>>> Sounds good.
>>>
>>> ...ant
>>>
>>>
>>>
>>> I'm doing some refactoring of the jms binding to make some function more
>>> plugable for various runtime environments (eg running in Geronimo and using
>>> Geronimo JMS provider) so while i'm doing this i thought i'd make a start at
>>> adding support for some wireFormat based on whats been discussed in this
>>> thread. Mainly refactoring things like the current databinding and message
>>> processor support out into clear and separate peices so this should make it
>>> easier to plug in/replace the function when the wireFormat support gets
>>> added to the Tuscany core runtime.
>>>
>>> ...ant
>>>
>>>
>>> Sounds good ant. Am working on JMS tests and some initial infrastructure
>>> changes to demonstrate the wire format support at the moment but stuck with
>>> a very peculiar ant build problem atm so don't have anything to check in
>>> just yet.
>>>
>>> Simon
>>>
>>>
>>> Hi, I just checked in (r706620) some early experiments in representing
>>> wireFormat and operationSelection as interceptors on a binding chain. My
>>> first impression when trying to implement our thoughts from this thread and
>>> recorded at [1] is that it doesn't work very well.
>>>
>>> The JMS binding is a good motivator for this exercise primarily because
>>> the wire format and operation selection processing is relatively
>>> complicated. The reason that the wire based approach is not immediately
>>> effective is that the JMS binding simulates RPC behavior by initiating
>>> response messages. You can configure the JMS binding with a response
>>> destination and a wireFromat no doubt (no OASIS word on this but you can
>>> imagine it happening) and hence the processing of a response is not
>>> necessarily as simple as unwinding the stack on a chain of intercpetors. The
>>> interceptors may need to be different for requests and responses.
>>>
>>> Easy enough to make this happen. Just invent request interceptors and
>>> response interceptors and install the right ones. However it's starting to
>>> get complicated.
>>>
>>> To get a feel for what this means I have been experimenting with the
>>> service side of the JMS binding. I've created a new binding listener
>>> (RRBJMSBindingListener) that is only fired up if a wireFormat is found in
>>> the SCDL. This gives rise to wireFormat and operationSelection interceptors
>>> being installed on a binding wire. The binding wire is currently represented
>>> inside of RRBJMSBindingListener and in fact there are two. A request wire
>>> and a response wire. There is also a BindingInterceptor interface that
>>> allows the request and response processing to be called independently and
>>> which doesn't assume that the Interceptors are chained.
>>>
>>> The next thing I'm going to do is enable the JMSBytes wire format so I
>>> have two options to play with and then look at how the reference side should
>>> work. With this info we can look at whether this is going to fly and how
>>> this binding wire support should be factored.
>>>
>>> Simon
>>>
>>> [1]
>>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Request+Response+Binding
>>>
>>
>> Hey, thanks Raymond. Let me try and merge the two pieces together.
>>
>> Simon
>>
>
> Looks good Raymond I've done the initial merge (r707394). A couple of
> initial comments:
>
> - I notice that the InterceptorChain asserts that the operations are
> non-null but null is passed in in the binding chain case. I've commented out
> the assertions for now.
> - I've changed the RuntimeWireInvoker to be and invoker so that I can add
> it to the end of the binding chain on the service side. The runtime wire
> invoker needs refactoring as we promised to do ages ago, i.e. conversation,
> callback interceptors
> - The response path from the invcation chain to the binding chain is a bit
> unatural as the response object is taken out of the response message and I
> then (hackily) stuff it back in the request message. This set of invoke
> methods need refactoring.
>
> Still lots of other things to do. In the short term this is my list.
>
> - Create a JMS binding context to pass around in the message header to
> contain JMS message and session etc. (would be followed by other contexts,
> such as security)
> - Do a little bit of tidying on the response path from InvocationChain to
> BindingChain
> - Create the reference side interceptors for the jms binding and fix up the
> binding to place them on the binding chain and use it
> - Review all these new interceptors to see if the separation of function is
> correct
> - Create another jms binding wire format for comparison
>
> In the medium term I agree with your list of things to rationalize and I
> would add another;
>
> Endpoint and EndpointReference
> RuntimeWire and EndpointWire
> RuntimeWireInvoker
>
> The test I'm using for this is itest/jms-format. It's not in the main build
> yet.
>
> Regards
>
> Simon
>
Update on where I have got to. I went through the short term list of TODOs
- Create a JMS binding context to pass around in the message header to
contain JMS message and session etc. (would be followed by other contexts,
such as security)
- Do a little bit of tidying on the response path from InvocationChain to
BindingChain
- Create the reference side interceptors for the jms binding and fix up the
binding to place them on the binding chain and use it
- Review all these new interceptors to see if the separation of function is
correct
- Create another jms binding wire format for comparison
The JMS binding is now running with a binding wire and with the function
from the invoker and listener spread out across a number of binding wire
interceptors thus;
Reference .... JMSBindingInoker -> Wire format -> Policy -> Transport
---------->
--------------> BindingListener -> Transport -> OperationSelection ->
WireFormat -> Policy -> RuntimeWireInvoker ....Service
This new function can easily be turned of with to on line changes in the jms
binding providers.
Some thoughts on where we are now.
1) I'm not absolutely convinced we need the binding wire construct. If it
were not for operation selection we could retain the wire per operation
model end to end. We could replace RuntimeWireInvoker with pluggable
OperationSelection
2) WireFormat is conceptually problematic. We need to be really clear on
it's role compared to databinding and how the end to end data transformation
is controlled by binding and service contracts.
2.1) The code, on the service side, currently is as follows.
BindingListener (BindingContract) -> Transport -> OperationSelection ->
WireFormat -> Policy -> RuntimeWireInvoker -> DataBinding -> Service
(ServiceImplementationContract)
Databinding - translated data between the format indicated by the
BindingContract and the ServiceImplementatonContract.
WireFormat - takes data off the wire and converts it to the in memory
form required by the BindingContract.
I'd like to understand a bit more about how the databinding decides what
transformation is required. AFAICT it just looks at the databinding
information associated with the BindingContract and
ServiceImplementationContract.
2.2) There is a notion in the OASIS spec that the wire format of the reponse
could be different for that of the request. This is problematic in the sense
that some wire formats imply a service implementation interface style. It
seems that we only have one slot to record a databinding preference for an
interface. Again I need to know more about databinding. I'm looking but some
help here would be appreciated.
3) There is awful lot more code doing things this way.
3.1) I would like to get rid of the policy/WireFormat/OperationSelector
provides and just have the factories create the interceptors. Providers
don't seem to add value here
3.2) I maybe overfactored some of the binding code out of the
listener/invoker when maybe it could have stayed. Now it's up an runnning am
going to review.
4) I've created a JMS context that gets passed in the tuscany message as
part of the header. This works well. It defined the SPI for the binding
information and sets the scene for other contexts that could be provided in
the future e.g. security. With the header being a list I put it in a set
position so I don't have to cycle through the list in each interceptor. I'd
prefer it if we had a bindingcontext field on the tuscany message though.
5) If we decide to go ahead with the OASIS related stuff we need to get the
OASIS license, etc. into the schema that have been extended with these
items. core and jms binding
Anyhow, this is long enough already. Toughts and comment most welcome. I'll
post again as I find out more.
Simon
Re: Request Response Binding - was: Re: Tuscany data binding framework enhancements
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Oct 23, 2008 at 8:12 AM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Thu, Oct 23, 2008 at 12:11 AM, Raymond Feng <en...@gmail.com>wrote:
>
>> Hi,
>>
>> I checked in a change under r707218.
>>
>> 1) Add getBindingInvocation() method to RuntimeWire to build up an
>> invocation for the binding endpoint.
>> 2) Define two more stages (reference.binding and service.binding) and a
>> few built-in phases for these two stages.
>>
>> I think there are opportunities to further rationalize/cleanup the
>> following interfaces:
>>
>> Endpoint and EndpointReference
>> RuntimeWire and EndpointWire
>>
>> Thanks,
>> Raymond
>>
>> From: Simon Laws
>> Sent: Tuesday, October 21, 2008 6:32 AM
>> To: dev@tuscany.apache.org ; antelder@apache.org
>> Subject: Re: Request Response Binding - was: Re: Tuscany data binding
>> framework enhancements
>>
>>
>>
>>
>>
>> On Fri, Oct 17, 2008 at 10:36 AM, Simon Laws <si...@googlemail.com>
>> wrote:
>>
>>
>>
>>
>> On Fri, Oct 17, 2008 at 10:16 AM, ant elder <an...@apache.org> wrote:
>>
>>
>>
>>
>> On Tue, Oct 7, 2008 at 9:07 AM, ant elder <an...@apache.org> wrote:
>>
>>
>>
>>
>> On Mon, Oct 6, 2008 at 6:07 PM, Simon Laws <si...@googlemail.com>
>> wrote:
>>
>>
>>
>>
>> On Mon, Oct 6, 2008 at 5:49 PM, ant elder <an...@apache.org> wrote:
>>
>>
>>
>>
>> On Mon, Oct 6, 2008 at 1:58 PM, Simon Laws <si...@googlemail.com>
>> wrote:
>>
>>
>>
>>
>> On Fri, Oct 3, 2008 at 8:35 AM, ant elder <an...@gmail.com> wrote:
>>
>>
>>
>>
>> On Thu, Oct 2, 2008 at 1:45 PM, Simon Laws <si...@googlemail.com>
>> wrote:
>>
>> <snip>
>>
>>
>>
>>
>>
>> I'm particularly interested in those who put the provider framwork in
>> place see the addition of binding configuration see this as an extension of
>> the binding providers or see this as a new set of providers?
>>
>>
>>
>> This is looking like a new type of extension to me, people should be able
>> to contribute new wireFormatters and have them made available for use within
>> the Tuscany runtime. Its also looking like this should be possible to do at
>> the application level.
>>
>> So Tuscany would come with a bunch of wireFormat extensions just like it
>> already has a bunch of binding and implementation extensions. Something
>> somewhere would define what the default wireFormat extension is to use with
>> each binding when no <wireFormat> element is in the SCDL. So there would be
>> a self contained JMS wireformat extension which implements the defaults as
>> defined in section 5.2 in the JMS binding spec and you'd be able to do:
>>
>> <reference ...>
>> <binding.jms>
>> <wireFormat.jms/>
>> </binding.jms>
>> </reference>
>>
>> but that would be the default so the same as:
>>
>> <reference ...>
>> <binding.jms />
>> </reference>
>>
>> Users could also do
>>
>> <reference ...>
>> <binding.jms>
>> <wireFormat.myFunkyFormatter/>
>> </binding.jms>
>> </reference>
>>
>> and have the 'myFunkyFormatter' extension as part of their application not
>> some jar that needs to be added to the Tuscany runtime.
>>
>> We could use the definitions.xml file to define things like the default
>> formatter for a binding, it also seems like that old discussion on using the
>> definitions.xml file to declare the extensions would help with the
>> myFunkyFormatter case as described at:
>> http://apache.markmail.org/message/unubgkqdcwwch66m
>>
>> ...ant
>>
>>
>>
>>
>> So there are two points here then
>>
>> 1. wireFormat as a separate extension point.
>>
>> Ok so that could work. We would need the usual provider structure for
>> wireFormat and operationSelection. Then we need some new bits to get the
>> associated interceptors in the right place.
>>
>> - A wire structure managed by the bindingListener/bindingInvoker
>> - some predefined "wire format" and "operation selection" phases on the
>> new wire that ensure that the interceptors get put in the correct place
>> - A mechanism where, as you suggest, the binding can instigate defaults
>> when no specifics are included in the SCDL. This could be as easy as
>> completing the model based on definitions.xml entries
>> - Code to read the model, select the appropriate factory and popoulate the
>> new wire with interceptors from the binding and from wireFormat and
>> operationSelector
>>
>> 2. extension points (wireFormat in this case) provided in SCA
>> contributions
>>
>> Personally I'd like to keep this separate from 2 for the time being. Only
>> because it's easier in the first instance to go with adding extensions via
>> the META-INF/services mechanisms while we work out what the extension points
>> should look like. Having looked back over the ML conversation on
>> definitions.xml though it does seem that there was a desire to allow some
>> extensions to be added to the runtime as part of a contribution. We can't
>> even do this with policy today so something like wireFormat would be a
>> isolated case to look at. I still want to get the extension point right
>> first though. Doesn't stop others looking at this if they want to of course.
>>
>> Simon
>>
>>
>>
>> Do you mean do this with a stepping stone approach, so do (1) then do (2),
>> or do you mean only do (1) and if someone out there in the community ever
>> feels like contributing (2) then good for them and we'd probably take it?
>> I'm asking because if users can't contribute a custom wireFormat then we'll
>> need to provide a way to configure some Tuscany specific one, and if thats
>> all we're doing how is that better than Tuscany's current approach of having
>> some Tuscany specific attributes on the binding.jms element?
>>
>> ...ant
>>
>>
>>
>>
>>
>> Yes, as a stepping stone. I was just presenting how I would approach it
>> while trying to make space for anyone who might have a real urge to get on
>> an look at the user provided extension point part.
>>
>> Simon
>>
>>
>>
>> Sounds good.
>>
>> ...ant
>>
>>
>>
>> I'm doing some refactoring of the jms binding to make some function more
>> plugable for various runtime environments (eg running in Geronimo and using
>> Geronimo JMS provider) so while i'm doing this i thought i'd make a start at
>> adding support for some wireFormat based on whats been discussed in this
>> thread. Mainly refactoring things like the current databinding and message
>> processor support out into clear and separate peices so this should make it
>> easier to plug in/replace the function when the wireFormat support gets
>> added to the Tuscany core runtime.
>>
>> ...ant
>>
>>
>> Sounds good ant. Am working on JMS tests and some initial infrastructure
>> changes to demonstrate the wire format support at the moment but stuck with
>> a very peculiar ant build problem atm so don't have anything to check in
>> just yet.
>>
>> Simon
>>
>>
>> Hi, I just checked in (r706620) some early experiments in representing
>> wireFormat and operationSelection as interceptors on a binding chain. My
>> first impression when trying to implement our thoughts from this thread and
>> recorded at [1] is that it doesn't work very well.
>>
>> The JMS binding is a good motivator for this exercise primarily because
>> the wire format and operation selection processing is relatively
>> complicated. The reason that the wire based approach is not immediately
>> effective is that the JMS binding simulates RPC behavior by initiating
>> response messages. You can configure the JMS binding with a response
>> destination and a wireFromat no doubt (no OASIS word on this but you can
>> imagine it happening) and hence the processing of a response is not
>> necessarily as simple as unwinding the stack on a chain of intercpetors. The
>> interceptors may need to be different for requests and responses.
>>
>> Easy enough to make this happen. Just invent request interceptors and
>> response interceptors and install the right ones. However it's starting to
>> get complicated.
>>
>> To get a feel for what this means I have been experimenting with the
>> service side of the JMS binding. I've created a new binding listener
>> (RRBJMSBindingListener) that is only fired up if a wireFormat is found in
>> the SCDL. This gives rise to wireFormat and operationSelection interceptors
>> being installed on a binding wire. The binding wire is currently represented
>> inside of RRBJMSBindingListener and in fact there are two. A request wire
>> and a response wire. There is also a BindingInterceptor interface that
>> allows the request and response processing to be called independently and
>> which doesn't assume that the Interceptors are chained.
>>
>> The next thing I'm going to do is enable the JMSBytes wire format so I
>> have two options to play with and then look at how the reference side should
>> work. With this info we can look at whether this is going to fly and how
>> this binding wire support should be factored.
>>
>> Simon
>>
>> [1]
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Request+Response+Binding
>>
>
> Hey, thanks Raymond. Let me try and merge the two pieces together.
>
> Simon
>
Looks good Raymond I've done the initial merge (r707394). A couple of
initial comments:
- I notice that the InterceptorChain asserts that the operations are
non-null but null is passed in in the binding chain case. I've commented out
the assertions for now.
- I've changed the RuntimeWireInvoker to be and invoker so that I can add it
to the end of the binding chain on the service side. The runtime wire
invoker needs refactoring as we promised to do ages ago, i.e. conversation,
callback interceptors
- The response path from the invcation chain to the binding chain is a bit
unatural as the response object is taken out of the response message and I
then (hackily) stuff it back in the request message. This set of invoke
methods need refactoring.
Still lots of other things to do. In the short term this is my list.
- Create a JMS binding context to pass around in the message header to
contain JMS message and session etc. (would be followed by other contexts,
such as security)
- Do a little bit of tidying on the response path from InvocationChain to
BindingChain
- Create the reference side interceptors for the jms binding and fix up the
binding to place them on the binding chain and use it
- Review all these new interceptors to see if the separation of function is
correct
- Create another jms binding wire format for comparison
In the medium term I agree with your list of things to rationalize and I
would add another;
Endpoint and EndpointReference
RuntimeWire and EndpointWire
RuntimeWireInvoker
The test I'm using for this is itest/jms-format. It's not in the main build
yet.
Regards
Simon
Re: Request Response Binding - was: Re: Tuscany data binding framework enhancements
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Oct 23, 2008 at 12:11 AM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> I checked in a change under r707218.
>
> 1) Add getBindingInvocation() method to RuntimeWire to build up an
> invocation for the binding endpoint.
> 2) Define two more stages (reference.binding and service.binding) and a few
> built-in phases for these two stages.
>
> I think there are opportunities to further rationalize/cleanup the
> following interfaces:
>
> Endpoint and EndpointReference
> RuntimeWire and EndpointWire
>
> Thanks,
> Raymond
>
> From: Simon Laws
> Sent: Tuesday, October 21, 2008 6:32 AM
> To: dev@tuscany.apache.org ; antelder@apache.org
> Subject: Re: Request Response Binding - was: Re: Tuscany data binding
> framework enhancements
>
>
>
>
>
> On Fri, Oct 17, 2008 at 10:36 AM, Simon Laws <si...@googlemail.com>
> wrote:
>
>
>
>
> On Fri, Oct 17, 2008 at 10:16 AM, ant elder <an...@apache.org> wrote:
>
>
>
>
> On Tue, Oct 7, 2008 at 9:07 AM, ant elder <an...@apache.org> wrote:
>
>
>
>
> On Mon, Oct 6, 2008 at 6:07 PM, Simon Laws <si...@googlemail.com>
> wrote:
>
>
>
>
> On Mon, Oct 6, 2008 at 5:49 PM, ant elder <an...@apache.org> wrote:
>
>
>
>
> On Mon, Oct 6, 2008 at 1:58 PM, Simon Laws <si...@googlemail.com>
> wrote:
>
>
>
>
> On Fri, Oct 3, 2008 at 8:35 AM, ant elder <an...@gmail.com> wrote:
>
>
>
>
> On Thu, Oct 2, 2008 at 1:45 PM, Simon Laws <si...@googlemail.com>
> wrote:
>
> <snip>
>
>
>
>
>
> I'm particularly interested in those who put the provider framwork in place
> see the addition of binding configuration see this as an extension of the
> binding providers or see this as a new set of providers?
>
>
>
> This is looking like a new type of extension to me, people should be able
> to contribute new wireFormatters and have them made available for use within
> the Tuscany runtime. Its also looking like this should be possible to do at
> the application level.
>
> So Tuscany would come with a bunch of wireFormat extensions just like it
> already has a bunch of binding and implementation extensions. Something
> somewhere would define what the default wireFormat extension is to use with
> each binding when no <wireFormat> element is in the SCDL. So there would be
> a self contained JMS wireformat extension which implements the defaults as
> defined in section 5.2 in the JMS binding spec and you'd be able to do:
>
> <reference ...>
> <binding.jms>
> <wireFormat.jms/>
> </binding.jms>
> </reference>
>
> but that would be the default so the same as:
>
> <reference ...>
> <binding.jms />
> </reference>
>
> Users could also do
>
> <reference ...>
> <binding.jms>
> <wireFormat.myFunkyFormatter/>
> </binding.jms>
> </reference>
>
> and have the 'myFunkyFormatter' extension as part of their application not
> some jar that needs to be added to the Tuscany runtime.
>
> We could use the definitions.xml file to define things like the default
> formatter for a binding, it also seems like that old discussion on using the
> definitions.xml file to declare the extensions would help with the
> myFunkyFormatter case as described at:
> http://apache.markmail.org/message/unubgkqdcwwch66m
>
> ...ant
>
>
>
>
> So there are two points here then
>
> 1. wireFormat as a separate extension point.
>
> Ok so that could work. We would need the usual provider structure for
> wireFormat and operationSelection. Then we need some new bits to get the
> associated interceptors in the right place.
>
> - A wire structure managed by the bindingListener/bindingInvoker
> - some predefined "wire format" and "operation selection" phases on the new
> wire that ensure that the interceptors get put in the correct place
> - A mechanism where, as you suggest, the binding can instigate defaults
> when no specifics are included in the SCDL. This could be as easy as
> completing the model based on definitions.xml entries
> - Code to read the model, select the appropriate factory and popoulate the
> new wire with interceptors from the binding and from wireFormat and
> operationSelector
>
> 2. extension points (wireFormat in this case) provided in SCA contributions
>
> Personally I'd like to keep this separate from 2 for the time being. Only
> because it's easier in the first instance to go with adding extensions via
> the META-INF/services mechanisms while we work out what the extension points
> should look like. Having looked back over the ML conversation on
> definitions.xml though it does seem that there was a desire to allow some
> extensions to be added to the runtime as part of a contribution. We can't
> even do this with policy today so something like wireFormat would be a
> isolated case to look at. I still want to get the extension point right
> first though. Doesn't stop others looking at this if they want to of course.
>
> Simon
>
>
>
> Do you mean do this with a stepping stone approach, so do (1) then do (2),
> or do you mean only do (1) and if someone out there in the community ever
> feels like contributing (2) then good for them and we'd probably take it?
> I'm asking because if users can't contribute a custom wireFormat then we'll
> need to provide a way to configure some Tuscany specific one, and if thats
> all we're doing how is that better than Tuscany's current approach of having
> some Tuscany specific attributes on the binding.jms element?
>
> ...ant
>
>
>
>
>
> Yes, as a stepping stone. I was just presenting how I would approach it
> while trying to make space for anyone who might have a real urge to get on
> an look at the user provided extension point part.
>
> Simon
>
>
>
> Sounds good.
>
> ...ant
>
>
>
> I'm doing some refactoring of the jms binding to make some function more
> plugable for various runtime environments (eg running in Geronimo and using
> Geronimo JMS provider) so while i'm doing this i thought i'd make a start at
> adding support for some wireFormat based on whats been discussed in this
> thread. Mainly refactoring things like the current databinding and message
> processor support out into clear and separate peices so this should make it
> easier to plug in/replace the function when the wireFormat support gets
> added to the Tuscany core runtime.
>
> ...ant
>
>
> Sounds good ant. Am working on JMS tests and some initial infrastructure
> changes to demonstrate the wire format support at the moment but stuck with
> a very peculiar ant build problem atm so don't have anything to check in
> just yet.
>
> Simon
>
>
> Hi, I just checked in (r706620) some early experiments in representing
> wireFormat and operationSelection as interceptors on a binding chain. My
> first impression when trying to implement our thoughts from this thread and
> recorded at [1] is that it doesn't work very well.
>
> The JMS binding is a good motivator for this exercise primarily because the
> wire format and operation selection processing is relatively complicated.
> The reason that the wire based approach is not immediately effective is that
> the JMS binding simulates RPC behavior by initiating response messages. You
> can configure the JMS binding with a response destination and a wireFromat
> no doubt (no OASIS word on this but you can imagine it happening) and hence
> the processing of a response is not necessarily as simple as unwinding the
> stack on a chain of intercpetors. The interceptors may need to be different
> for requests and responses.
>
> Easy enough to make this happen. Just invent request interceptors and
> response interceptors and install the right ones. However it's starting to
> get complicated.
>
> To get a feel for what this means I have been experimenting with the
> service side of the JMS binding. I've created a new binding listener
> (RRBJMSBindingListener) that is only fired up if a wireFormat is found in
> the SCDL. This gives rise to wireFormat and operationSelection interceptors
> being installed on a binding wire. The binding wire is currently represented
> inside of RRBJMSBindingListener and in fact there are two. A request wire
> and a response wire. There is also a BindingInterceptor interface that
> allows the request and response processing to be called independently and
> which doesn't assume that the Interceptors are chained.
>
> The next thing I'm going to do is enable the JMSBytes wire format so I have
> two options to play with and then look at how the reference side should
> work. With this info we can look at whether this is going to fly and how
> this binding wire support should be factored.
>
> Simon
>
> [1]
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Request+Response+Binding
>
Hey, thanks Raymond. Let me try and merge the two pieces together.
Simon
Re: Request Response Binding - was: Re: Tuscany data binding framework enhancements
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I checked in a change under r707218.
1) Add getBindingInvocation() method to RuntimeWire to build up an
invocation for the binding endpoint.
2) Define two more stages (reference.binding and service.binding) and a few
built-in phases for these two stages.
I think there are opportunities to further rationalize/cleanup the following
interfaces:
Endpoint and EndpointReference
RuntimeWire and EndpointWire
Thanks,
Raymond
From: Simon Laws
Sent: Tuesday, October 21, 2008 6:32 AM
To: dev@tuscany.apache.org ; antelder@apache.org
Subject: Re: Request Response Binding - was: Re: Tuscany data binding
framework enhancements
On Fri, Oct 17, 2008 at 10:36 AM, Simon Laws <si...@googlemail.com>
wrote:
On Fri, Oct 17, 2008 at 10:16 AM, ant elder <an...@apache.org> wrote:
On Tue, Oct 7, 2008 at 9:07 AM, ant elder <an...@apache.org> wrote:
On Mon, Oct 6, 2008 at 6:07 PM, Simon Laws <si...@googlemail.com>
wrote:
On Mon, Oct 6, 2008 at 5:49 PM, ant elder <an...@apache.org> wrote:
On Mon, Oct 6, 2008 at 1:58 PM, Simon Laws <si...@googlemail.com>
wrote:
On Fri, Oct 3, 2008 at 8:35 AM, ant elder <an...@gmail.com> wrote:
On Thu, Oct 2, 2008 at 1:45 PM, Simon Laws <si...@googlemail.com>
wrote:
<snip>
I'm particularly interested in those who put the provider framwork in place
see the addition of binding configuration see this as an extension of the
binding providers or see this as a new set of providers?
This is looking like a new type of extension to me, people should be able to
contribute new wireFormatters and have them made available for use within
the Tuscany runtime. Its also looking like this should be possible to do at
the application level.
So Tuscany would come with a bunch of wireFormat extensions just like it
already has a bunch of binding and implementation extensions. Something
somewhere would define what the default wireFormat extension is to use with
each binding when no <wireFormat> element is in the SCDL. So there would be
a self contained JMS wireformat extension which implements the defaults as
defined in section 5.2 in the JMS binding spec and you'd be able to do:
<reference ...>
<binding.jms>
<wireFormat.jms/>
</binding.jms>
</reference>
but that would be the default so the same as:
<reference ...>
<binding.jms />
</reference>
Users could also do
<reference ...>
<binding.jms>
<wireFormat.myFunkyFormatter/>
</binding.jms>
</reference>
and have the 'myFunkyFormatter' extension as part of their application not
some jar that needs to be added to the Tuscany runtime.
We could use the definitions.xml file to define things like the default
formatter for a binding, it also seems like that old discussion on using the
definitions.xml file to declare the extensions would help with the
myFunkyFormatter case as described at:
http://apache.markmail.org/message/unubgkqdcwwch66m
...ant
So there are two points here then
1. wireFormat as a separate extension point.
Ok so that could work. We would need the usual provider structure for
wireFormat and operationSelection. Then we need some new bits to get the
associated interceptors in the right place.
- A wire structure managed by the bindingListener/bindingInvoker
- some predefined "wire format" and "operation selection" phases on the new
wire that ensure that the interceptors get put in the correct place
- A mechanism where, as you suggest, the binding can instigate defaults when
no specifics are included in the SCDL. This could be as easy as completing
the model based on definitions.xml entries
- Code to read the model, select the appropriate factory and popoulate the
new wire with interceptors from the binding and from wireFormat and
operationSelector
2. extension points (wireFormat in this case) provided in SCA contributions
Personally I'd like to keep this separate from 2 for the time being. Only
because it's easier in the first instance to go with adding extensions via
the META-INF/services mechanisms while we work out what the extension points
should look like. Having looked back over the ML conversation on
definitions.xml though it does seem that there was a desire to allow some
extensions to be added to the runtime as part of a contribution. We can't
even do this with policy today so something like wireFormat would be a
isolated case to look at. I still want to get the extension point right
first though. Doesn't stop others looking at this if they want to of course.
Simon
Do you mean do this with a stepping stone approach, so do (1) then do (2),
or do you mean only do (1) and if someone out there in the community ever
feels like contributing (2) then good for them and we'd probably take it?
I'm asking because if users can't contribute a custom wireFormat then we'll
need to provide a way to configure some Tuscany specific one, and if thats
all we're doing how is that better than Tuscany's current approach of having
some Tuscany specific attributes on the binding.jms element?
...ant
Yes, as a stepping stone. I was just presenting how I would approach it
while trying to make space for anyone who might have a real urge to get on
an look at the user provided extension point part.
Simon
Sounds good.
...ant
I'm doing some refactoring of the jms binding to make some function more
plugable for various runtime environments (eg running in Geronimo and using
Geronimo JMS provider) so while i'm doing this i thought i'd make a start at
adding support for some wireFormat based on whats been discussed in this
thread. Mainly refactoring things like the current databinding and message
processor support out into clear and separate peices so this should make it
easier to plug in/replace the function when the wireFormat support gets
added to the Tuscany core runtime.
...ant
Sounds good ant. Am working on JMS tests and some initial infrastructure
changes to demonstrate the wire format support at the moment but stuck with
a very peculiar ant build problem atm so don't have anything to check in
just yet.
Simon
Hi, I just checked in (r706620) some early experiments in representing
wireFormat and operationSelection as interceptors on a binding chain. My
first impression when trying to implement our thoughts from this thread and
recorded at [1] is that it doesn't work very well.
The JMS binding is a good motivator for this exercise primarily because the
wire format and operation selection processing is relatively complicated.
The reason that the wire based approach is not immediately effective is that
the JMS binding simulates RPC behavior by initiating response messages. You
can configure the JMS binding with a response destination and a wireFromat
no doubt (no OASIS word on this but you can imagine it happening) and hence
the processing of a response is not necessarily as simple as unwinding the
stack on a chain of intercpetors. The interceptors may need to be different
for requests and responses.
Easy enough to make this happen. Just invent request interceptors and
response interceptors and install the right ones. However it's starting to
get complicated.
To get a feel for what this means I have been experimenting with the service
side of the JMS binding. I've created a new binding listener
(RRBJMSBindingListener) that is only fired up if a wireFormat is found in
the SCDL. This gives rise to wireFormat and operationSelection interceptors
being installed on a binding wire. The binding wire is currently represented
inside of RRBJMSBindingListener and in fact there are two. A request wire
and a response wire. There is also a BindingInterceptor interface that
allows the request and response processing to be called independently and
which doesn't assume that the Interceptors are chained.
The next thing I'm going to do is enable the JMSBytes wire format so I have
two options to play with and then look at how the reference side should
work. With this info we can look at whether this is going to fly and how
this binding wire support should be factored.
Simon
[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Request+Response+Binding
Re: Request Response Binding - was: Re: Tuscany data binding framework enhancements
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Oct 17, 2008 at 10:36 AM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Fri, Oct 17, 2008 at 10:16 AM, ant elder <an...@apache.org> wrote:
>
>>
>>
>> On Tue, Oct 7, 2008 at 9:07 AM, ant elder <an...@apache.org> wrote:
>>
>>>
>>>
>>> On Mon, Oct 6, 2008 at 6:07 PM, Simon Laws <si...@googlemail.com>wrote:
>>>
>>>>
>>>>
>>>> On Mon, Oct 6, 2008 at 5:49 PM, ant elder <an...@apache.org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Oct 6, 2008 at 1:58 PM, Simon Laws <si...@googlemail.com>wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Oct 3, 2008 at 8:35 AM, ant elder <an...@gmail.com>wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Oct 2, 2008 at 1:45 PM, Simon Laws <
>>>>>>> simonslaws@googlemail.com> wrote:
>>>>>>>
>>>>>>> <snip>
>>>>>>>
>>>>>>>
>>>>>>>> I'm particularly interested in those who put the provider framwork
>>>>>>>> in place see the addition of binding configuration see this as an extension
>>>>>>>> of the binding providers or see this as a new set of providers?
>>>>>>>>
>>>>>>>>
>>>>>>> This is looking like a new type of extension to me, people should be
>>>>>>> able to contribute new wireFormatters and have them made available for use
>>>>>>> within the Tuscany runtime. Its also looking like this should be possible to
>>>>>>> do at the application level.
>>>>>>>
>>>>>>> So Tuscany would come with a bunch of wireFormat extensions just like
>>>>>>> it already has a bunch of binding and implementation extensions. Something
>>>>>>> somewhere would define what the default wireFormat extension is to use with
>>>>>>> each binding when no <wireFormat> element is in the SCDL. So there would be
>>>>>>> a self contained JMS wireformat extension which implements the defaults as
>>>>>>> defined in section 5.2 in the JMS binding spec and you'd be able to do:
>>>>>>>
>>>>>>> <reference ...>
>>>>>>> <binding.jms>
>>>>>>> <wireFormat.jms/>
>>>>>>> </binding.jms>
>>>>>>> </reference>
>>>>>>>
>>>>>>> but that would be the default so the same as:
>>>>>>>
>>>>>>> <reference ...>
>>>>>>> <binding.jms />
>>>>>>> </reference>
>>>>>>>
>>>>>>> Users could also do
>>>>>>>
>>>>>>> <reference ...>
>>>>>>> <binding.jms>
>>>>>>> <wireFormat.myFunkyFormatter/>
>>>>>>> </binding.jms>
>>>>>>> </reference>
>>>>>>>
>>>>>>> and have the 'myFunkyFormatter' extension as part of their
>>>>>>> application not some jar that needs to be added to the Tuscany runtime.
>>>>>>>
>>>>>>> We could use the definitions.xml file to define things like the
>>>>>>> default formatter for a binding, it also seems like that old discussion on
>>>>>>> using the definitions.xml file to declare the extensions would help with the
>>>>>>> myFunkyFormatter case as described at:
>>>>>>> http://apache.markmail.org/message/unubgkqdcwwch66m
>>>>>>>
>>>>>>> ...ant
>>>>>>>
>>>>>>>
>>>>>> So there are two points here then
>>>>>>
>>>>>> *1. wireFormat as a separate extension point.*
>>>>>>
>>>>>> Ok so that could work. We would need the usual provider structure for
>>>>>> wireFormat and operationSelection. Then we need some new bits to get the
>>>>>> associated interceptors in the right place.
>>>>>>
>>>>>> - A wire structure managed by the bindingListener/bindingInvoker
>>>>>> - some predefined "wire format" and "operation selection" phases on
>>>>>> the new wire that ensure that the interceptors get put in the correct place
>>>>>> - A mechanism where, as you suggest, the binding can instigate
>>>>>> defaults when no specifics are included in the SCDL. This could be as easy
>>>>>> as completing the model based on definitions.xml entries
>>>>>> - Code to read the model, select the appropriate factory and popoulate
>>>>>> the new wire with interceptors from the binding and from wireFormat and
>>>>>> operationSelector
>>>>>>
>>>>>> *2. extension points (wireFormat in this case) provided in SCA
>>>>>> contributions*
>>>>>>
>>>>>> Personally I'd like to keep this separate from 2 for the time being.
>>>>>> Only because it's easier in the first instance to go with adding extensions
>>>>>> via the META-INF/services mechanisms while we work out what the extension
>>>>>> points should look like. Having looked back over the ML conversation on
>>>>>> definitions.xml though it does seem that there was a desire to allow some
>>>>>> extensions to be added to the runtime as part of a contribution. We can't
>>>>>> even do this with policy today so something like wireFormat would be a
>>>>>> isolated case to look at. I still want to get the extension point right
>>>>>> first though. Doesn't stop others looking at this if they want to of course.
>>>>>>
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>
>>>>> Do you mean do this with a stepping stone approach, so do (1) then do
>>>>> (2), or do you mean only do (1) and if someone out there in the community
>>>>> ever feels like contributing (2) then good for them and we'd probably take
>>>>> it? I'm asking because if users can't contribute a custom wireFormat then
>>>>> we'll need to provide a way to configure some Tuscany specific one, and if
>>>>> thats all we're doing how is that better than Tuscany's current approach of
>>>>> having some Tuscany specific attributes on the binding.jms element?
>>>>>
>>>>> ...ant
>>>>>
>>>>>
>>>>>
>>>> Yes, as a stepping stone. I was just presenting how I would approach it
>>>> while trying to make space for anyone who might have a real urge to get on
>>>> an look at the user provided extension point part.
>>>>
>>>> Simon
>>>>
>>>
>>> Sounds good.
>>>
>>> ...ant
>>>
>>
>> I'm doing some refactoring of the jms binding to make some function more
>> plugable for various runtime environments (eg running in Geronimo and using
>> Geronimo JMS provider) so while i'm doing this i thought i'd make a start at
>> adding support for some wireFormat based on whats been discussed in this
>> thread. Mainly refactoring things like the current databinding and message
>> processor support out into clear and separate peices so this should make it
>> easier to plug in/replace the function when the wireFormat support gets
>> added to the Tuscany core runtime.
>>
>> ...ant
>>
>> Sounds good ant. Am working on JMS tests and some initial infrastructure
> changes to demonstrate the wire format support at the moment but stuck with
> a very peculiar ant build problem atm so don't have anything to check in
> just yet.
>
> Simon
>
Hi, I just checked in (r706620) some early experiments in representing
wireFormat and operationSelection as interceptors on a binding chain. My
first impression when trying to implement our thoughts from this thread and
recorded at [1] is that it doesn't work very well.
The JMS binding is a good motivator for this exercise primarily because the
wire format and operation selection processing is relatively complicated.
The reason that the wire based approach is not immediately effective is that
the JMS binding simulates RPC behavior by initiating response messages. You
can configure the JMS binding with a response destination and a wireFromat
no doubt (no OASIS word on this but you can imagine it happening) and hence
the processing of a response is not necessarily as simple as unwinding the
stack on a chain of intercpetors. The interceptors may need to be different
for requests and responses.
Easy enough to make this happen. Just invent request interceptors and
response interceptors and install the right ones. However it's starting to
get complicated.
To get a feel for what this means I have been experimenting with the service
side of the JMS binding. I've created a new binding listener
(RRBJMSBindingListener) that is only fired up if a wireFormat is found in
the SCDL. This gives rise to wireFormat and operationSelection interceptors
being installed on a binding wire. The binding wire is currently represented
inside of RRBJMSBindingListener and in fact there are two. A request wire
and a response wire. There is also a BindingInterceptor interface that
allows the request and response processing to be called independently and
which doesn't assume that the Interceptors are chained.
The next thing I'm going to do is enable the JMSBytes wire format so I have
two options to play with and then look at how the reference side should
work. With this info we can look at whether this is going to fly and how
this binding wire support should be factored.
Simon
[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Request+Response+Binding
Re: Request Response Binding - was: Re: Tuscany data binding framework enhancements
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Oct 17, 2008 at 10:16 AM, ant elder <an...@apache.org> wrote:
>
>
> On Tue, Oct 7, 2008 at 9:07 AM, ant elder <an...@apache.org> wrote:
>
>>
>>
>> On Mon, Oct 6, 2008 at 6:07 PM, Simon Laws <si...@googlemail.com>wrote:
>>
>>>
>>>
>>> On Mon, Oct 6, 2008 at 5:49 PM, ant elder <an...@apache.org> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Oct 6, 2008 at 1:58 PM, Simon Laws <si...@googlemail.com>wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Oct 3, 2008 at 8:35 AM, ant elder <an...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Oct 2, 2008 at 1:45 PM, Simon Laws <simonslaws@googlemail.com
>>>>>> > wrote:
>>>>>>
>>>>>> <snip>
>>>>>>
>>>>>>
>>>>>>> I'm particularly interested in those who put the provider framwork
>>>>>>> in place see the addition of binding configuration see this as an extension
>>>>>>> of the binding providers or see this as a new set of providers?
>>>>>>>
>>>>>>>
>>>>>> This is looking like a new type of extension to me, people should be
>>>>>> able to contribute new wireFormatters and have them made available for use
>>>>>> within the Tuscany runtime. Its also looking like this should be possible to
>>>>>> do at the application level.
>>>>>>
>>>>>> So Tuscany would come with a bunch of wireFormat extensions just like
>>>>>> it already has a bunch of binding and implementation extensions. Something
>>>>>> somewhere would define what the default wireFormat extension is to use with
>>>>>> each binding when no <wireFormat> element is in the SCDL. So there would be
>>>>>> a self contained JMS wireformat extension which implements the defaults as
>>>>>> defined in section 5.2 in the JMS binding spec and you'd be able to do:
>>>>>>
>>>>>> <reference ...>
>>>>>> <binding.jms>
>>>>>> <wireFormat.jms/>
>>>>>> </binding.jms>
>>>>>> </reference>
>>>>>>
>>>>>> but that would be the default so the same as:
>>>>>>
>>>>>> <reference ...>
>>>>>> <binding.jms />
>>>>>> </reference>
>>>>>>
>>>>>> Users could also do
>>>>>>
>>>>>> <reference ...>
>>>>>> <binding.jms>
>>>>>> <wireFormat.myFunkyFormatter/>
>>>>>> </binding.jms>
>>>>>> </reference>
>>>>>>
>>>>>> and have the 'myFunkyFormatter' extension as part of their application
>>>>>> not some jar that needs to be added to the Tuscany runtime.
>>>>>>
>>>>>> We could use the definitions.xml file to define things like the
>>>>>> default formatter for a binding, it also seems like that old discussion on
>>>>>> using the definitions.xml file to declare the extensions would help with the
>>>>>> myFunkyFormatter case as described at:
>>>>>> http://apache.markmail.org/message/unubgkqdcwwch66m
>>>>>>
>>>>>> ...ant
>>>>>>
>>>>>>
>>>>> So there are two points here then
>>>>>
>>>>> *1. wireFormat as a separate extension point.*
>>>>>
>>>>> Ok so that could work. We would need the usual provider structure for
>>>>> wireFormat and operationSelection. Then we need some new bits to get the
>>>>> associated interceptors in the right place.
>>>>>
>>>>> - A wire structure managed by the bindingListener/bindingInvoker
>>>>> - some predefined "wire format" and "operation selection" phases on the
>>>>> new wire that ensure that the interceptors get put in the correct place
>>>>> - A mechanism where, as you suggest, the binding can instigate defaults
>>>>> when no specifics are included in the SCDL. This could be as easy as
>>>>> completing the model based on definitions.xml entries
>>>>> - Code to read the model, select the appropriate factory and popoulate
>>>>> the new wire with interceptors from the binding and from wireFormat and
>>>>> operationSelector
>>>>>
>>>>> *2. extension points (wireFormat in this case) provided in SCA
>>>>> contributions*
>>>>>
>>>>> Personally I'd like to keep this separate from 2 for the time being.
>>>>> Only because it's easier in the first instance to go with adding extensions
>>>>> via the META-INF/services mechanisms while we work out what the extension
>>>>> points should look like. Having looked back over the ML conversation on
>>>>> definitions.xml though it does seem that there was a desire to allow some
>>>>> extensions to be added to the runtime as part of a contribution. We can't
>>>>> even do this with policy today so something like wireFormat would be a
>>>>> isolated case to look at. I still want to get the extension point right
>>>>> first though. Doesn't stop others looking at this if they want to of course.
>>>>>
>>>>>
>>>>> Simon
>>>>>
>>>>
>>>> Do you mean do this with a stepping stone approach, so do (1) then do
>>>> (2), or do you mean only do (1) and if someone out there in the community
>>>> ever feels like contributing (2) then good for them and we'd probably take
>>>> it? I'm asking because if users can't contribute a custom wireFormat then
>>>> we'll need to provide a way to configure some Tuscany specific one, and if
>>>> thats all we're doing how is that better than Tuscany's current approach of
>>>> having some Tuscany specific attributes on the binding.jms element?
>>>>
>>>> ...ant
>>>>
>>>>
>>>>
>>> Yes, as a stepping stone. I was just presenting how I would approach it
>>> while trying to make space for anyone who might have a real urge to get on
>>> an look at the user provided extension point part.
>>>
>>> Simon
>>>
>>
>> Sounds good.
>>
>> ...ant
>>
>
> I'm doing some refactoring of the jms binding to make some function more
> plugable for various runtime environments (eg running in Geronimo and using
> Geronimo JMS provider) so while i'm doing this i thought i'd make a start at
> adding support for some wireFormat based on whats been discussed in this
> thread. Mainly refactoring things like the current databinding and message
> processor support out into clear and separate peices so this should make it
> easier to plug in/replace the function when the wireFormat support gets
> added to the Tuscany core runtime.
>
> ...ant
>
> Sounds good ant. Am working on JMS tests and some initial infrastructure
changes to demonstrate the wire format support at the moment but stuck with
a very peculiar ant build problem atm so don't have anything to check in
just yet.
Simon
Re: Request Response Binding - was: Re: Tuscany data binding framework enhancements
Posted by ant elder <an...@apache.org>.
On Tue, Oct 7, 2008 at 9:07 AM, ant elder <an...@apache.org> wrote:
>
>
> On Mon, Oct 6, 2008 at 6:07 PM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Mon, Oct 6, 2008 at 5:49 PM, ant elder <an...@apache.org> wrote:
>>
>>>
>>>
>>> On Mon, Oct 6, 2008 at 1:58 PM, Simon Laws <si...@googlemail.com>wrote:
>>>
>>>>
>>>>
>>>> On Fri, Oct 3, 2008 at 8:35 AM, ant elder <an...@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Oct 2, 2008 at 1:45 PM, Simon Laws <si...@googlemail.com>wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>>>
>>>>>> I'm particularly interested in those who put the provider framwork in
>>>>>> place see the addition of binding configuration see this as an extension of
>>>>>> the binding providers or see this as a new set of providers?
>>>>>>
>>>>>>
>>>>> This is looking like a new type of extension to me, people should be
>>>>> able to contribute new wireFormatters and have them made available for use
>>>>> within the Tuscany runtime. Its also looking like this should be possible to
>>>>> do at the application level.
>>>>>
>>>>> So Tuscany would come with a bunch of wireFormat extensions just like
>>>>> it already has a bunch of binding and implementation extensions. Something
>>>>> somewhere would define what the default wireFormat extension is to use with
>>>>> each binding when no <wireFormat> element is in the SCDL. So there would be
>>>>> a self contained JMS wireformat extension which implements the defaults as
>>>>> defined in section 5.2 in the JMS binding spec and you'd be able to do:
>>>>>
>>>>> <reference ...>
>>>>> <binding.jms>
>>>>> <wireFormat.jms/>
>>>>> </binding.jms>
>>>>> </reference>
>>>>>
>>>>> but that would be the default so the same as:
>>>>>
>>>>> <reference ...>
>>>>> <binding.jms />
>>>>> </reference>
>>>>>
>>>>> Users could also do
>>>>>
>>>>> <reference ...>
>>>>> <binding.jms>
>>>>> <wireFormat.myFunkyFormatter/>
>>>>> </binding.jms>
>>>>> </reference>
>>>>>
>>>>> and have the 'myFunkyFormatter' extension as part of their application
>>>>> not some jar that needs to be added to the Tuscany runtime.
>>>>>
>>>>> We could use the definitions.xml file to define things like the default
>>>>> formatter for a binding, it also seems like that old discussion on using the
>>>>> definitions.xml file to declare the extensions would help with the
>>>>> myFunkyFormatter case as described at:
>>>>> http://apache.markmail.org/message/unubgkqdcwwch66m
>>>>>
>>>>> ...ant
>>>>>
>>>>>
>>>> So there are two points here then
>>>>
>>>> *1. wireFormat as a separate extension point.*
>>>>
>>>> Ok so that could work. We would need the usual provider structure for
>>>> wireFormat and operationSelection. Then we need some new bits to get the
>>>> associated interceptors in the right place.
>>>>
>>>> - A wire structure managed by the bindingListener/bindingInvoker
>>>> - some predefined "wire format" and "operation selection" phases on the
>>>> new wire that ensure that the interceptors get put in the correct place
>>>> - A mechanism where, as you suggest, the binding can instigate defaults
>>>> when no specifics are included in the SCDL. This could be as easy as
>>>> completing the model based on definitions.xml entries
>>>> - Code to read the model, select the appropriate factory and popoulate
>>>> the new wire with interceptors from the binding and from wireFormat and
>>>> operationSelector
>>>>
>>>> *2. extension points (wireFormat in this case) provided in SCA
>>>> contributions*
>>>>
>>>> Personally I'd like to keep this separate from 2 for the time being.
>>>> Only because it's easier in the first instance to go with adding extensions
>>>> via the META-INF/services mechanisms while we work out what the extension
>>>> points should look like. Having looked back over the ML conversation on
>>>> definitions.xml though it does seem that there was a desire to allow some
>>>> extensions to be added to the runtime as part of a contribution. We can't
>>>> even do this with policy today so something like wireFormat would be a
>>>> isolated case to look at. I still want to get the extension point right
>>>> first though. Doesn't stop others looking at this if they want to of course.
>>>>
>>>>
>>>> Simon
>>>>
>>>
>>> Do you mean do this with a stepping stone approach, so do (1) then do
>>> (2), or do you mean only do (1) and if someone out there in the community
>>> ever feels like contributing (2) then good for them and we'd probably take
>>> it? I'm asking because if users can't contribute a custom wireFormat then
>>> we'll need to provide a way to configure some Tuscany specific one, and if
>>> thats all we're doing how is that better than Tuscany's current approach of
>>> having some Tuscany specific attributes on the binding.jms element?
>>>
>>> ...ant
>>>
>>>
>>>
>> Yes, as a stepping stone. I was just presenting how I would approach it
>> while trying to make space for anyone who might have a real urge to get on
>> an look at the user provided extension point part.
>>
>> Simon
>>
>
> Sounds good.
>
> ...ant
>
I'm doing some refactoring of the jms binding to make some function more
plugable for various runtime environments (eg running in Geronimo and using
Geronimo JMS provider) so while i'm doing this i thought i'd make a start at
adding support for some wireFormat based on whats been discussed in this
thread. Mainly refactoring things like the current databinding and message
processor support out into clear and separate peices so this should make it
easier to plug in/replace the function when the wireFormat support gets
added to the Tuscany core runtime.
...ant
Re: Service/Reference Endpoints and Request Response Binding
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Oct 13, 2008 at 2:18 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Mon, Oct 13, 2008 at 2:10 PM, ant elder <an...@gmail.com> wrote:
>
>>
>>
>> On Mon, Oct 13, 2008 at 2:08 AM, Raymond Feng <en...@gmail.com>wrote:
>>
>>> I'm wondering if we can combine the Endpoint and RRB efforts together.
>>> Here are some ideas:
>>>
>>> 1) An SCA service has a list of Endpoints representing the end point for
>>> each binding protocol.
>>>
>>> 2) An SCA reference has 0..N Endpoints depending on the multiplicity of
>>> the reference.
>>>
>>> 3) Each endpoint has a binding interface contract. If it's not known
>>> before the operation selector, then it's an "Any" interface with an "Any"
>>> operation.
>>>
>>> 4) There is one invocation chain for each endpoint (based on the binding
>>> interface contract) and one for the SCA service or reference. The two
>>> invocation chains are connected as we described on the wiki page. For a SCA
>>> service configured with multiple bindings, there will be multiple endpoint
>>> invocation chains connecting to the same service invocation chain. It's
>>> similar for SCA references.
>>>
>>> Thanks,
>>> Raymond
>>>
>>>
>> From all the discussion I know what the RRB is but are there any emails or
>> doc you could point to saying what the endpoint effort is about? Or if there
>> are not yet could you give a quick summary?
>>
>> ...ant
>>
>>
> Hi Ant
>
> Touche, you got this mail precisely the same time as I did:-) We talked
> about extending the endoint support a while back (It's on the roadmap page
> [1]) and it was discussed on the ML back in June [2]. Sebastien subsequently
> raised a JIRA and referenced the mail list [3]. I think it's a good idea to
> bring this up again now as it is related to the RRB work.
>
> Simon
>
> [1]
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Roadmap+Discussion
> [2] http://marc.info/?l=tuscany-dev&m=121318046912690&w=2
> [3] http://issues.apache.org/jira/browse/TUSCANY-2382
>
And I managed to reply to your mail without giving a summary of what one of
the Endpoints we are talking about is. It's basically the result of
combining a reference with a binding or a service with a binding. It
describes the physical Endpoint (for want of a better word) that produces
or consumes messages. Originally instigated to straighten out the
binding/reference multiplicity confusion but could be applied to services
also. Needs reviewing now in light of the RRB discussion, mainly because
wires also have endpoints but they are slightly different.
Hope that helps.
Simon
Re: Service/Reference Endpoints and Request Response Binding
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Oct 13, 2008 at 2:10 PM, ant elder <an...@gmail.com> wrote:
>
>
> On Mon, Oct 13, 2008 at 2:08 AM, Raymond Feng <en...@gmail.com> wrote:
>
>> I'm wondering if we can combine the Endpoint and RRB efforts together.
>> Here are some ideas:
>>
>> 1) An SCA service has a list of Endpoints representing the end point for
>> each binding protocol.
>>
>> 2) An SCA reference has 0..N Endpoints depending on the multiplicity of
>> the reference.
>>
>> 3) Each endpoint has a binding interface contract. If it's not known
>> before the operation selector, then it's an "Any" interface with an "Any"
>> operation.
>>
>> 4) There is one invocation chain for each endpoint (based on the binding
>> interface contract) and one for the SCA service or reference. The two
>> invocation chains are connected as we described on the wiki page. For a SCA
>> service configured with multiple bindings, there will be multiple endpoint
>> invocation chains connecting to the same service invocation chain. It's
>> similar for SCA references.
>>
>> Thanks,
>> Raymond
>>
>>
> From all the discussion I know what the RRB is but are there any emails or
> doc you could point to saying what the endpoint effort is about? Or if there
> are not yet could you give a quick summary?
>
> ...ant
>
>
Hi Ant
Touche, you got this mail precisely the same time as I did:-) We talked
about extending the endoint support a while back (It's on the roadmap page
[1]) and it was discussed on the ML back in June [2]. Sebastien subsequently
raised a JIRA and referenced the mail list [3]. I think it's a good idea to
bring this up again now as it is related to the RRB work.
Simon
[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Roadmap+Discussion
[2] http://marc.info/?l=tuscany-dev&m=121318046912690&w=2
[3] http://issues.apache.org/jira/browse/TUSCANY-2382
Re: Service/Reference Endpoints and Request Response Binding
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Oct 13, 2008 at 2:08 AM, Raymond Feng <en...@gmail.com> wrote:
> I'm wondering if we can combine the Endpoint and RRB efforts together. Here
> are some ideas:
>
> 1) An SCA service has a list of Endpoints representing the end point for
> each binding protocol.
>
> 2) An SCA reference has 0..N Endpoints depending on the multiplicity of the
> reference.
>
> 3) Each endpoint has a binding interface contract. If it's not known before
> the operation selector, then it's an "Any" interface with an "Any"
> operation.
>
> 4) There is one invocation chain for each endpoint (based on the binding
> interface contract) and one for the SCA service or reference. The two
> invocation chains are connected as we described on the wiki page. For a SCA
> service configured with multiple bindings, there will be multiple endpoint
> invocation chains connecting to the same service invocation chain. It's
> similar for SCA references.
>
> Thanks
> Raymond
>
>
Hi Raymond,
+1 from me.
Working with your list here are some more thoughts...
1) An SCA service has a list of Endpoints representing the end point for
each binding protocol.
The builder can be extended to generate this list. Initially based on
configured bindings. Ultimately I'd like to see the list populated with
promoted endpoints as well rather than relying on $promoted$ services. Not
something for the first iteration though.
2) An SCA reference has 0..N Endpoints depending on the multiplicity of the
reference.
This is already in place. The endpoints are currently created by the
builders and the output of the endpoint processing is used to
populate the computed binding list. We need to remove this second stage
and updated the activators just to work off of Endpoints. Currently the
activators only work off Endpoints if the referenced service can't be found
3) Each endpoint has a binding interface contract. If it's not known before
the operation selector, then it's an "Any" interface with an "Any"
operation.
In what situation isn't the binding interface contract known. It anything
I'd say it was a question of wireFormat rather than operationSelection but
I'm probably missing something here.
4) There is one invocation chain for each endpoint (based on the binding
interface contract)
Can we merge the Endpoints we are discussing here with the EndpointRefs
that are held currently by wires?
4a) The endpoint model on the reference side should give rise to an
EndpointProvider (I'm probably convinced that we should change Resolver back
to Provider) which in turn gathers binding specific endpoint providers that
can be used to resolve the Endpoint (find the referenced service) in a
binding specific way if required.
4b) the endpoint model in the service side should also give rise to an
EndpointProvider. I can see that on the service side we can have the multple
endpoint invocation chains call into the single service invocation chain.
However on the reference side I don't think this is the case as a proxy will
be targeting a particular service over a specific binding. Hence we need to
associate the end of the reference chain with a specific binding invoker.
Won't it be better to stick with a full set of chains for each Endpoint?
I think we can leverage the endpoint idea to help us build out the RRB wires
without messing up the runtime in the mean time.
Regards
Simon
Re: Service/Reference Endpoints and Request Response Binding
Posted by ant elder <an...@gmail.com>.
On Mon, Oct 13, 2008 at 2:08 AM, Raymond Feng <en...@gmail.com> wrote:
> I'm wondering if we can combine the Endpoint and RRB efforts together. Here
> are some ideas:
>
> 1) An SCA service has a list of Endpoints representing the end point for
> each binding protocol.
>
> 2) An SCA reference has 0..N Endpoints depending on the multiplicity of the
> reference.
>
> 3) Each endpoint has a binding interface contract. If it's not known before
> the operation selector, then it's an "Any" interface with an "Any"
> operation.
>
> 4) There is one invocation chain for each endpoint (based on the binding
> interface contract) and one for the SCA service or reference. The two
> invocation chains are connected as we described on the wiki page. For a SCA
> service configured with multiple bindings, there will be multiple endpoint
> invocation chains connecting to the same service invocation chain. It's
> similar for SCA references.
>
> Thanks,
> Raymond
>
>
>From all the discussion I know what the RRB is but are there any emails or
doc you could point to saying what the endpoint effort is about? Or if there
are not yet could you give a quick summary?
...ant
Service/Reference Endpoints and Request Response Binding
Posted by Raymond Feng <en...@gmail.com>.
I'm wondering if we can combine the Endpoint and RRB efforts together. Here
are some ideas:
1) An SCA service has a list of Endpoints representing the end point for
each binding protocol.
2) An SCA reference has 0..N Endpoints depending on the multiplicity of the
reference.
3) Each endpoint has a binding interface contract. If it's not known before
the operation selector, then it's an "Any" interface with an "Any"
operation.
4) There is one invocation chain for each endpoint (based on the binding
interface contract) and one for the SCA service or reference. The two
invocation chains are connected as we described on the wiki page. For a SCA
service configured with multiple bindings, there will be multiple endpoint
invocation chains connecting to the same service invocation chain. It's
similar for SCA references.
Thanks,
Raymond
Re: Request Response Binding - was: Re: Tuscany data binding framework enhancements
Posted by ant elder <an...@apache.org>.
On Mon, Oct 6, 2008 at 6:07 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Mon, Oct 6, 2008 at 5:49 PM, ant elder <an...@apache.org> wrote:
>
>>
>>
>> On Mon, Oct 6, 2008 at 1:58 PM, Simon Laws <si...@googlemail.com>wrote:
>>
>>>
>>>
>>> On Fri, Oct 3, 2008 at 8:35 AM, ant elder <an...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Oct 2, 2008 at 1:45 PM, Simon Laws <si...@googlemail.com>wrote:
>>>>
>>>> <snip>
>>>>
>>>>
>>>>> I'm particularly interested in those who put the provider framwork in
>>>>> place see the addition of binding configuration see this as an extension of
>>>>> the binding providers or see this as a new set of providers?
>>>>>
>>>>>
>>>> This is looking like a new type of extension to me, people should be
>>>> able to contribute new wireFormatters and have them made available for use
>>>> within the Tuscany runtime. Its also looking like this should be possible to
>>>> do at the application level.
>>>>
>>>> So Tuscany would come with a bunch of wireFormat extensions just like it
>>>> already has a bunch of binding and implementation extensions. Something
>>>> somewhere would define what the default wireFormat extension is to use with
>>>> each binding when no <wireFormat> element is in the SCDL. So there would be
>>>> a self contained JMS wireformat extension which implements the defaults as
>>>> defined in section 5.2 in the JMS binding spec and you'd be able to do:
>>>>
>>>> <reference ...>
>>>> <binding.jms>
>>>> <wireFormat.jms/>
>>>> </binding.jms>
>>>> </reference>
>>>>
>>>> but that would be the default so the same as:
>>>>
>>>> <reference ...>
>>>> <binding.jms />
>>>> </reference>
>>>>
>>>> Users could also do
>>>>
>>>> <reference ...>
>>>> <binding.jms>
>>>> <wireFormat.myFunkyFormatter/>
>>>> </binding.jms>
>>>> </reference>
>>>>
>>>> and have the 'myFunkyFormatter' extension as part of their application
>>>> not some jar that needs to be added to the Tuscany runtime.
>>>>
>>>> We could use the definitions.xml file to define things like the default
>>>> formatter for a binding, it also seems like that old discussion on using the
>>>> definitions.xml file to declare the extensions would help with the
>>>> myFunkyFormatter case as described at:
>>>> http://apache.markmail.org/message/unubgkqdcwwch66m
>>>>
>>>> ...ant
>>>>
>>>>
>>> So there are two points here then
>>>
>>> *1. wireFormat as a separate extension point.*
>>>
>>> Ok so that could work. We would need the usual provider structure for
>>> wireFormat and operationSelection. Then we need some new bits to get the
>>> associated interceptors in the right place.
>>>
>>> - A wire structure managed by the bindingListener/bindingInvoker
>>> - some predefined "wire format" and "operation selection" phases on the
>>> new wire that ensure that the interceptors get put in the correct place
>>> - A mechanism where, as you suggest, the binding can instigate defaults
>>> when no specifics are included in the SCDL. This could be as easy as
>>> completing the model based on definitions.xml entries
>>> - Code to read the model, select the appropriate factory and popoulate
>>> the new wire with interceptors from the binding and from wireFormat and
>>> operationSelector
>>>
>>> *2. extension points (wireFormat in this case) provided in SCA
>>> contributions*
>>>
>>> Personally I'd like to keep this separate from 2 for the time being. Only
>>> because it's easier in the first instance to go with adding extensions via
>>> the META-INF/services mechanisms while we work out what the extension points
>>> should look like. Having looked back over the ML conversation on
>>> definitions.xml though it does seem that there was a desire to allow some
>>> extensions to be added to the runtime as part of a contribution. We can't
>>> even do this with policy today so something like wireFormat would be a
>>> isolated case to look at. I still want to get the extension point right
>>> first though. Doesn't stop others looking at this if they want to of course.
>>>
>>>
>>> Simon
>>>
>>
>> Do you mean do this with a stepping stone approach, so do (1) then do (2),
>> or do you mean only do (1) and if someone out there in the community ever
>> feels like contributing (2) then good for them and we'd probably take it?
>> I'm asking because if users can't contribute a custom wireFormat then we'll
>> need to provide a way to configure some Tuscany specific one, and if thats
>> all we're doing how is that better than Tuscany's current approach of having
>> some Tuscany specific attributes on the binding.jms element?
>>
>> ...ant
>>
>>
>>
> Yes, as a stepping stone. I was just presenting how I would approach it
> while trying to make space for anyone who might have a real urge to get on
> an look at the user provided extension point part.
>
> Simon
>
Sounds good.
...ant
Re: Request Response Binding - was: Re: Tuscany data binding framework enhancements
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Oct 6, 2008 at 5:49 PM, ant elder <an...@apache.org> wrote:
>
>
> On Mon, Oct 6, 2008 at 1:58 PM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Fri, Oct 3, 2008 at 8:35 AM, ant elder <an...@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Oct 2, 2008 at 1:45 PM, Simon Laws <si...@googlemail.com>wrote:
>>>
>>> <snip>
>>>
>>>
>>>> I'm particularly interested in those who put the provider framwork in
>>>> place see the addition of binding configuration see this as an extension of
>>>> the binding providers or see this as a new set of providers?
>>>>
>>>>
>>> This is looking like a new type of extension to me, people should be able
>>> to contribute new wireFormatters and have them made available for use within
>>> the Tuscany runtime. Its also looking like this should be possible to do at
>>> the application level.
>>>
>>> So Tuscany would come with a bunch of wireFormat extensions just like it
>>> already has a bunch of binding and implementation extensions. Something
>>> somewhere would define what the default wireFormat extension is to use with
>>> each binding when no <wireFormat> element is in the SCDL. So there would be
>>> a self contained JMS wireformat extension which implements the defaults as
>>> defined in section 5.2 in the JMS binding spec and you'd be able to do:
>>>
>>> <reference ...>
>>> <binding.jms>
>>> <wireFormat.jms/>
>>> </binding.jms>
>>> </reference>
>>>
>>> but that would be the default so the same as:
>>>
>>> <reference ...>
>>> <binding.jms />
>>> </reference>
>>>
>>> Users could also do
>>>
>>> <reference ...>
>>> <binding.jms>
>>> <wireFormat.myFunkyFormatter/>
>>> </binding.jms>
>>> </reference>
>>>
>>> and have the 'myFunkyFormatter' extension as part of their application
>>> not some jar that needs to be added to the Tuscany runtime.
>>>
>>> We could use the definitions.xml file to define things like the default
>>> formatter for a binding, it also seems like that old discussion on using the
>>> definitions.xml file to declare the extensions would help with the
>>> myFunkyFormatter case as described at:
>>> http://apache.markmail.org/message/unubgkqdcwwch66m
>>>
>>> ...ant
>>>
>>>
>> So there are two points here then
>>
>> *1. wireFormat as a separate extension point.*
>>
>> Ok so that could work. We would need the usual provider structure for
>> wireFormat and operationSelection. Then we need some new bits to get the
>> associated interceptors in the right place.
>>
>> - A wire structure managed by the bindingListener/bindingInvoker
>> - some predefined "wire format" and "operation selection" phases on the
>> new wire that ensure that the interceptors get put in the correct place
>> - A mechanism where, as you suggest, the binding can instigate defaults
>> when no specifics are included in the SCDL. This could be as easy as
>> completing the model based on definitions.xml entries
>> - Code to read the model, select the appropriate factory and popoulate the
>> new wire with interceptors from the binding and from wireFormat and
>> operationSelector
>>
>> *2. extension points (wireFormat in this case) provided in SCA
>> contributions*
>>
>> Personally I'd like to keep this separate from 2 for the time being. Only
>> because it's easier in the first instance to go with adding extensions via
>> the META-INF/services mechanisms while we work out what the extension points
>> should look like. Having looked back over the ML conversation on
>> definitions.xml though it does seem that there was a desire to allow some
>> extensions to be added to the runtime as part of a contribution. We can't
>> even do this with policy today so something like wireFormat would be a
>> isolated case to look at. I still want to get the extension point right
>> first though. Doesn't stop others looking at this if they want to of course.
>>
>>
>> Simon
>>
>
> Do you mean do this with a stepping stone approach, so do (1) then do (2),
> or do you mean only do (1) and if someone out there in the community ever
> feels like contributing (2) then good for them and we'd probably take it?
> I'm asking because if users can't contribute a custom wireFormat then we'll
> need to provide a way to configure some Tuscany specific one, and if thats
> all we're doing how is that better than Tuscany's current approach of having
> some Tuscany specific attributes on the binding.jms element?
>
> ...ant
>
>
>
Yes, as a stepping stone. I was just presenting how I would approach it
while trying to make space for anyone who might have a real urge to get on
an look at the user provided extension point part.
Simon
Re: Request Response Binding - was: Re: Tuscany data binding framework enhancements
Posted by ant elder <an...@apache.org>.
On Mon, Oct 6, 2008 at 1:58 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Fri, Oct 3, 2008 at 8:35 AM, ant elder <an...@gmail.com> wrote:
>
>>
>>
>> On Thu, Oct 2, 2008 at 1:45 PM, Simon Laws <si...@googlemail.com>wrote:
>>
>> <snip>
>>
>>
>>> I'm particularly interested in those who put the provider framwork in
>>> place see the addition of binding configuration see this as an extension of
>>> the binding providers or see this as a new set of providers?
>>>
>>>
>> This is looking like a new type of extension to me, people should be able
>> to contribute new wireFormatters and have them made available for use within
>> the Tuscany runtime. Its also looking like this should be possible to do at
>> the application level.
>>
>> So Tuscany would come with a bunch of wireFormat extensions just like it
>> already has a bunch of binding and implementation extensions. Something
>> somewhere would define what the default wireFormat extension is to use with
>> each binding when no <wireFormat> element is in the SCDL. So there would be
>> a self contained JMS wireformat extension which implements the defaults as
>> defined in section 5.2 in the JMS binding spec and you'd be able to do:
>>
>> <reference ...>
>> <binding.jms>
>> <wireFormat.jms/>
>> </binding.jms>
>> </reference>
>>
>> but that would be the default so the same as:
>>
>> <reference ...>
>> <binding.jms />
>> </reference>
>>
>> Users could also do
>>
>> <reference ...>
>> <binding.jms>
>> <wireFormat.myFunkyFormatter/>
>> </binding.jms>
>> </reference>
>>
>> and have the 'myFunkyFormatter' extension as part of their application not
>> some jar that needs to be added to the Tuscany runtime.
>>
>> We could use the definitions.xml file to define things like the default
>> formatter for a binding, it also seems like that old discussion on using the
>> definitions.xml file to declare the extensions would help with the
>> myFunkyFormatter case as described at:
>> http://apache.markmail.org/message/unubgkqdcwwch66m
>>
>> ...ant
>>
>>
> So there are two points here then
>
> *1. wireFormat as a separate extension point.*
>
> Ok so that could work. We would need the usual provider structure for
> wireFormat and operationSelection. Then we need some new bits to get the
> associated interceptors in the right place.
>
> - A wire structure managed by the bindingListener/bindingInvoker
> - some predefined "wire format" and "operation selection" phases on the new
> wire that ensure that the interceptors get put in the correct place
> - A mechanism where, as you suggest, the binding can instigate defaults
> when no specifics are included in the SCDL. This could be as easy as
> completing the model based on definitions.xml entries
> - Code to read the model, select the appropriate factory and popoulate the
> new wire with interceptors from the binding and from wireFormat and
> operationSelector
>
> *2. extension points (wireFormat in this case) provided in SCA
> contributions*
>
> Personally I'd like to keep this separate from 2 for the time being. Only
> because it's easier in the first instance to go with adding extensions via
> the META-INF/services mechanisms while we work out what the extension points
> should look like. Having looked back over the ML conversation on
> definitions.xml though it does seem that there was a desire to allow some
> extensions to be added to the runtime as part of a contribution. We can't
> even do this with policy today so something like wireFormat would be a
> isolated case to look at. I still want to get the extension point right
> first though. Doesn't stop others looking at this if they want to of course.
>
>
> Simon
>
Do you mean do this with a stepping stone approach, so do (1) then do (2),
or do you mean only do (1) and if someone out there in the community ever
feels like contributing (2) then good for them and we'd probably take it?
I'm asking because if users can't contribute a custom wireFormat then we'll
need to provide a way to configure some Tuscany specific one, and if thats
all we're doing how is that better than Tuscany's current approach of having
some Tuscany specific attributes on the binding.jms element?
...ant
Re: Request Response Binding - was: Re: Tuscany data binding framework enhancements
Posted by Raymond Feng <en...@gmail.com>.
+1 on Simon's proposal.
Thanks,
Raymond
From: Simon Laws
Sent: Monday, October 06, 2008 5:58 AM
To: dev@tuscany.apache.org ; antelder@apache.org
Subject: Re: Request Response Binding - was: Re: Tuscany data binding
framework enhancements
On Fri, Oct 3, 2008 at 8:35 AM, ant elder <an...@gmail.com> wrote:
On Thu, Oct 2, 2008 at 1:45 PM, Simon Laws <si...@googlemail.com>
wrote:
<snip>
I'm particularly interested in those who put the provider framwork in place
see the addition of binding configuration see this as an extension of the
binding providers or see this as a new set of providers?
This is looking like a new type of extension to me, people should be able to
contribute new wireFormatters and have them made available for use within
the Tuscany runtime. Its also looking like this should be possible to do at
the application level.
So Tuscany would come with a bunch of wireFormat extensions just like it
already has a bunch of binding and implementation extensions. Something
somewhere would define what the default wireFormat extension is to use with
each binding when no <wireFormat> element is in the SCDL. So there would be
a self contained JMS wireformat extension which implements the defaults as
defined in section 5.2 in the JMS binding spec and you'd be able to do:
<reference ...>
<binding.jms>
<wireFormat.jms/>
</binding.jms>
</reference>
but that would be the default so the same as:
<reference ...>
<binding.jms />
</reference>
Users could also do
<reference ...>
<binding.jms>
<wireFormat.myFunkyFormatter/>
</binding.jms>
</reference>
and have the 'myFunkyFormatter' extension as part of their application not
some jar that needs to be added to the Tuscany runtime.
We could use the definitions.xml file to define things like the default
formatter for a binding, it also seems like that old discussion on using the
definitions.xml file to declare the extensions would help with the
myFunkyFormatter case as described at:
http://apache.markmail.org/message/unubgkqdcwwch66m
...ant
So there are two points here then
1. wireFormat as a separate extension point.
Ok so that could work. We would need the usual provider structure for
wireFormat and operationSelection. Then we need some new bits to get the
associated interceptors in the right place.
- A wire structure managed by the bindingListener/bindingInvoker
- some predefined "wire format" and "operation selection" phases on the new
wire that ensure that the interceptors get put in the correct place
- A mechanism where, as you suggest, the binding can instigate defaults when
no specifics are included in the SCDL. This could be as easy as completing
the model based on definitions.xml entries
- Code to read the model, select the appropriate factory and popoulate the
new wire with interceptors from the binding and from wireFormat and
operationSelector
2. extension points (wireFormat in this case) provided in SCA contributions
Personally I'd like to keep this separate from 2 for the time being. Only
because it's easier in the first instance to go with adding extensions via
the META-INF/services mechanisms while we work out what the extension points
should look like. Having looked back over the ML conversation on
definitions.xml though it does seem that there was a desire to allow some
extensions to be added to the runtime as part of a contribution. We can't
even do this with policy today so something like wireFormat would be a
isolated case to look at. I still want to get the extension point right
first though. Doesn't stop others looking at this if they want to of course.
Simon
Re: Request Response Binding - was: Re: Tuscany data binding framework enhancements
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Oct 3, 2008 at 8:35 AM, ant elder <an...@gmail.com> wrote:
>
>
> On Thu, Oct 2, 2008 at 1:45 PM, Simon Laws <si...@googlemail.com>wrote:
>
> <snip>
>
>
>> I'm particularly interested in those who put the provider framwork in
>> place see the addition of binding configuration see this as an extension of
>> the binding providers or see this as a new set of providers?
>>
>>
> This is looking like a new type of extension to me, people should be able
> to contribute new wireFormatters and have them made available for use within
> the Tuscany runtime. Its also looking like this should be possible to do at
> the application level.
>
> So Tuscany would come with a bunch of wireFormat extensions just like it
> already has a bunch of binding and implementation extensions. Something
> somewhere would define what the default wireFormat extension is to use with
> each binding when no <wireFormat> element is in the SCDL. So there would be
> a self contained JMS wireformat extension which implements the defaults as
> defined in section 5.2 in the JMS binding spec and you'd be able to do:
>
> <reference ...>
> <binding.jms>
> <wireFormat.jms/>
> </binding.jms>
> </reference>
>
> but that would be the default so the same as:
>
> <reference ...>
> <binding.jms />
> </reference>
>
> Users could also do
>
> <reference ...>
> <binding.jms>
> <wireFormat.myFunkyFormatter/>
> </binding.jms>
> </reference>
>
> and have the 'myFunkyFormatter' extension as part of their application not
> some jar that needs to be added to the Tuscany runtime.
>
> We could use the definitions.xml file to define things like the default
> formatter for a binding, it also seems like that old discussion on using the
> definitions.xml file to declare the extensions would help with the
> myFunkyFormatter case as described at:
> http://apache.markmail.org/message/unubgkqdcwwch66m
>
> ...ant
>
>
So there are two points here then
*1. wireFormat as a separate extension point.*
Ok so that could work. We would need the usual provider structure for
wireFormat and operationSelection. Then we need some new bits to get the
associated interceptors in the right place.
- A wire structure managed by the bindingListener/bindingInvoker
- some predefined "wire format" and "operation selection" phases on the new
wire that ensure that the interceptors get put in the correct place
- A mechanism where, as you suggest, the binding can instigate defaults when
no specifics are included in the SCDL. This could be as easy as completing
the model based on definitions.xml entries
- Code to read the model, select the appropriate factory and popoulate the
new wire with interceptors from the binding and from wireFormat and
operationSelector
*2. extension points (wireFormat in this case) provided in SCA contributions
*
Personally I'd like to keep this separate from 2 for the time being. Only
because it's easier in the first instance to go with adding extensions via
the META-INF/services mechanisms while we work out what the extension points
should look like. Having looked back over the ML conversation on
definitions.xml though it does seem that there was a desire to allow some
extensions to be added to the runtime as part of a contribution. We can't
even do this with policy today so something like wireFormat would be a
isolated case to look at. I still want to get the extension point right
first though. Doesn't stop others looking at this if they want to of course.
Simon
Re: Request Response Binding - was: Re: Tuscany data binding framework enhancements
Posted by ant elder <an...@gmail.com>.
On Thu, Oct 2, 2008 at 1:45 PM, Simon Laws <si...@googlemail.com>wrote:
<snip>
> I'm particularly interested in those who put the provider framwork in
> place see the addition of binding configuration see this as an extension of
> the binding providers or see this as a new set of providers?
>
>
This is looking like a new type of extension to me, people should be able to
contribute new wireFormatters and have them made available for use within
the Tuscany runtime. Its also looking like this should be possible to do at
the application level.
So Tuscany would come with a bunch of wireFormat extensions just like it
already has a bunch of binding and implementation extensions. Something
somewhere would define what the default wireFormat extension is to use with
each binding when no <wireFormat> element is in the SCDL. So there would be
a self contained JMS wireformat extension which implements the defaults as
defined in section 5.2 in the JMS binding spec and you'd be able to do:
<reference ...>
<binding.jms>
<wireFormat.jms/>
</binding.jms>
</reference>
but that would be the default so the same as:
<reference ...>
<binding.jms />
</reference>
Users could also do
<reference ...>
<binding.jms>
<wireFormat.myFunkyFormatter/>
</binding.jms>
</reference>
and have the 'myFunkyFormatter' extension as part of their application not
some jar that needs to be added to the Tuscany runtime.
We could use the definitions.xml file to define things like the default
formatter for a binding, it also seems like that old discussion on using the
definitions.xml file to declare the extensions would help with the
myFunkyFormatter case as described at:
http://apache.markmail.org/message/unubgkqdcwwch66m
...ant