Re: Plugability of new type of wire format and operation selector to a binding

[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

[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