You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Luciano Resende <lu...@gmail.com> on 2009/05/04 06:46:44 UTC
Plugability of new type of wire format and operation selector to a
binding
The current support for Binding RRB created a new SPI
(ServiceBindingProviderRRB) which delegate the configuration and
injection of the wireFormat and operationSelector interceptor to the
binding. With the current design, it becomes somewhat difficult to
plug new wireFormat/operationSelector types, as the binding
implementation need to somewhat know ahead of time which interceptor
to add. Also, checking the current implementation for Binding.JMS,
this seems to not be a problem, as all the possible
wireFormat/operationSelector types are all defined/implemented inside
the JMS Binding modules.
Is there any specific reason to use this approach, compared to what we
have for Policies and other interceptors (e.g Policy) where the
interceptors get added based on their Phase (see RuntimeWireImpl)
(and btw, it looks like we already have specific phases for wire
formats and operation selectors) ?
I'll give it a try and try to add the same design we are using for
Policies to plug the jsonrpc wireFormat/operationSelector type to the
new HTTP Binding; and for now, this would probably not affect the
current implementation of JMS Binding.
Thoughts ?
--
Luciano Resende
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: Plugability of new type of wire format and operation selector to
a binding
Posted by Simon Laws <si...@googlemail.com>.
On Tue, May 5, 2009 at 4:46 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> There are two factors:
>
> 1) The extensibility for wire formats and operation selectors. We can use
> the extension point and extension pattern so that wire formats or operation
> selectors can be plugged in. The extension point can look up the extensions
> by QName. The extensions will provide the logic to configure the binding
> invocation chain (or create a list of interceptors).
>
> 2) Wire formats or operation selectors may introduce interceptors to
> implement the logic. These interceptors need to be added to the binding
> invocation chain. Two different approaches can be used:
> a. The binding provider is responsible for looking up the "provider
> factory" from the wireformat/operationselector extension point, calling the
> extensions to create one or more interceptors (or configure the binding
> invocation chain), and adding them to the invocation chain.
> b. The core runtime is responsible for querying the binding to get the wire
> format and operation selector and interacting with the wire format and
> operation selector extensions to configure the binding invocation chain.
> This is useful only if the wire format or operation selector is general to
> bindings.
>
> a and b is not exclusive. We can start with a. If a lot of duplicate codes
> start to show up from different bindings, it will be a sign that b is
> needed.
>
Hi
At the moment, with the JMS binding, we have 1) and 2)a.
We chose 2)a. as the JMS binding creates a very binding specific
configuration for the binding wire. The position of the wire format
and operation selector are generic however. So I agree that if we feel
that there is value in the future to moving this out into generic
infrastructure code (the wire) we could look at it.
Simon
Re: Plugability of new type of wire format and operation selector to a binding
Posted by Raymond Feng <en...@gmail.com>.
Hi,
There are two factors:
1) The extensibility for wire formats and operation selectors. We can use
the extension point and extension pattern so that wire formats or operation
selectors can be plugged in. The extension point can look up the extensions
by QName. The extensions will provide the logic to configure the binding
invocation chain (or create a list of interceptors).
2) Wire formats or operation selectors may introduce interceptors to
implement the logic. These interceptors need to be added to the binding
invocation chain. Two different approaches can be used:
a. The binding provider is responsible for looking up the "provider
factory" from the wireformat/operationselector extension point, calling the
extensions to create one or more interceptors (or configure the binding
invocation chain), and adding them to the invocation chain.
b. The core runtime is responsible for querying the binding to get the
wire format and operation selector and interacting with the wire format and
operation selector extensions to configure the binding invocation chain.
This is useful only if the wire format or operation selector is general to
bindings.
a and b is not exclusive. We can start with a. If a lot of duplicate codes
start to show up from different bindings, it will be a sign that b is
needed.
Thanks,
Raymond
--------------------------------------------------
From: "Luciano Resende" <lu...@gmail.com>
Sent: Monday, May 04, 2009 10:58 PM
To: <de...@tuscany.apache.org>
Subject: Re: Plugability of new type of wire format and operation selector
to a binding
> On Mon, May 4, 2009 at 2:18 AM, Simon Laws <si...@googlemail.com>
> wrote:
>> Hi Luciano
>>
>> it becomes somewhat difficult to
>>> plug new wireFormat/operationSelector types, as the binding
>>> implementation need to somewhat know ahead of time which interceptor
>>> to add. Also, checking the current implementation for Binding.JMS,
>>> this seems to not be a problem, as all the possible
>>> wireFormat/operationSelector types are all defined/implemented inside
>>> the JMS Binding modules.
>>
>> The binding should know that it is going to have wire format
>> interceptors and operation selector interceptors but it shouldn't care
>> what particular types are in use. The binding wire configuration is
>> delegated to the binding itself (rather than being constructed
>> completely generically) as there is value in being able to create very
>> binding specific interceptors between which the wire format
>> interceptor and operation selector interceptor slot. Hence the binding
>> implementation is in charge of constructing the binding wire. Do you
>> have some code checked in that shows the problem you are having?
>>
>
> I have managed to put the extension code I wanted inside the
> "configureBindingChain" method and accomplish somewhat the same
> result. For now it should be ok, but this might be a good candidate
> for refactoring to the runtime.
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
Re: Plugability of new type of wire format and operation selector to
a binding
Posted by Luciano Resende <lu...@gmail.com>.
On Mon, May 4, 2009 at 2:18 AM, Simon Laws <si...@googlemail.com> wrote:
> Hi Luciano
>
> it becomes somewhat difficult to
>> plug new wireFormat/operationSelector types, as the binding
>> implementation need to somewhat know ahead of time which interceptor
>> to add. Also, checking the current implementation for Binding.JMS,
>> this seems to not be a problem, as all the possible
>> wireFormat/operationSelector types are all defined/implemented inside
>> the JMS Binding modules.
>
> The binding should know that it is going to have wire format
> interceptors and operation selector interceptors but it shouldn't care
> what particular types are in use. The binding wire configuration is
> delegated to the binding itself (rather than being constructed
> completely generically) as there is value in being able to create very
> binding specific interceptors between which the wire format
> interceptor and operation selector interceptor slot. Hence the binding
> implementation is in charge of constructing the binding wire. Do you
> have some code checked in that shows the problem you are having?
>
I have managed to put the extension code I wanted inside the
"configureBindingChain" method and accomplish somewhat the same
result. For now it should be ok, but this might be a good candidate
for refactoring to the runtime.
--
Luciano Resende
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: Plugability of new type of wire format and operation selector to
a binding
Posted by Simon Laws <si...@googlemail.com>.
Hi Luciano
it becomes somewhat difficult to
> plug new wireFormat/operationSelector types, as the binding
> implementation need to somewhat know ahead of time which interceptor
> to add. Also, checking the current implementation for Binding.JMS,
> this seems to not be a problem, as all the possible
> wireFormat/operationSelector types are all defined/implemented inside
> the JMS Binding modules.
The binding should know that it is going to have wire format
interceptors and operation selector interceptors but it shouldn't care
what particular types are in use. The binding wire configuration is
delegated to the binding itself (rather than being constructed
completely generically) as there is value in being able to create very
binding specific interceptors between which the wire format
interceptor and operation selector interceptor slot. Hence the binding
implementation is in charge of constructing the binding wire. Do you
have some code checked in that shows the problem you are having?
Simon