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
