On Thu, Oct 23, 2008 at 12:11 AM, Raymond Feng <[EMAIL PROTECTED]> 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: [email protected] ; [EMAIL PROTECTED] > Subject: Re: Request Response Binding - was: Re: Tuscany data binding > framework enhancements > > > > > > On Fri, Oct 17, 2008 at 10:36 AM, Simon Laws <[EMAIL PROTECTED]> > wrote: > > > > > On Fri, Oct 17, 2008 at 10:16 AM, ant elder <[EMAIL PROTECTED]> wrote: > > > > > On Tue, Oct 7, 2008 at 9:07 AM, ant elder <[EMAIL PROTECTED]> wrote: > > > > > On Mon, Oct 6, 2008 at 6:07 PM, Simon Laws <[EMAIL PROTECTED]> > wrote: > > > > > On Mon, Oct 6, 2008 at 5:49 PM, ant elder <[EMAIL PROTECTED]> wrote: > > > > > On Mon, Oct 6, 2008 at 1:58 PM, Simon Laws <[EMAIL PROTECTED]> > wrote: > > > > > On Fri, Oct 3, 2008 at 8:35 AM, ant elder <[EMAIL PROTECTED]> wrote: > > > > > On Thu, Oct 2, 2008 at 1:45 PM, Simon Laws <[EMAIL PROTECTED]> > 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
