cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Polar Humenn <phum...@iona.com>
Subject Re: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]
Date Mon, 02 Apr 2007 17:06:22 GMT
I had thought that Eoghan's original objection was that a Conduit, 
implied the use of a Client when he needed Decoupled Endpoints, because 
Dan want's the Client to manage Decoupled Endpoints, and Eoghan wants 
the Conduit to handle them.

Maybe we need just another abstraction in the middle to satisfy both 
parties?

It seems to me that a Conduit is merely a "one-way" "client" side way of 
talking to an Endpoint. Somethings need to be configured on it, so that 
it does certain things according to protocol, and handles responses(if any).

There might be another entity that handles two-way communication on 
which you can set destinations, decoupled endpoints, that use a conduit 
(or something else?) in the client-to-server direction. This entity 
would be better suited to following security/assurance policies 
regarding two-way communication. Like using a "secure" conduit, with a 
"secure" decoupled endpoint.

A Client can use that entity in a specific default way. And Eoghan can 
use this entity without specifying a Client, but still have the 
flexibility he desires, and the user can still have some opportunity to 
configure/check that things are on the up'n'up.

Does that seem like a plausible approach?

Cheers,
-Polar

Dan Diephouse wrote:
>>
>>
>> Just because you see this as the way to solve your use case doesn't
>> necessarily mean it is the way we should support. I'm certainly want to
>> support this scenario and I'm sure we will come to some agreement 
>> about how
>> to best support it. BUT, there are other goals as well though - like
>> simplicity and coherency. If we've already got mechanisms for this 
>> type of
>> thing, why go inventing others?
>>
>> Do you agree that it is possible to delay the addition of Binding
>> interceptors to the chain inside the Client? Would it maybe be better to
>> delay this decision until later in the chain? This would avoid the
>> introduction of a flag mechanism.
>>
>> If so, then why don't we just allow users to select a different 
>> Binding up
>> to POST_LOGICAL phase? For instance, the ObjectBinding interceptors 
>> could be
>> added if that person wanted to do a local invocation. They could also 
>> select
>> a new Conduit up to this point as well. If the user doesn't select a
>> different binding or conduit, then we'll just use the default ones.
>>
>> In addition to allowing your use case of allowing the interceptor to
>> control the binding, this makes the URI based approach much easier as 
>> well.
>>
>
>
> One last addition, because I didn't address getting the part about 
> getting
> the Conduit up front.
>
> Let me sidestep first to your questions of why your proposal is 
> getting so
> much scrutiny - well there are conflated discussions of whether or not
> Conduits are needed for in process dispatching and whether or not we 
> should
> adopt my proposed client changes. If we say that a Conduit is optional 
> for
> invocations, then that has big ramifications in those areas.
>
> If all we're trying to decide on is creating a way to avoid 
> initializing a
> Conduit by default, then I only have two questions before adopting your
> approach:
> - Why should we have a ConduitInitiatorStrategy as opposed to just 
> setting a
> flag on the Conduit? If someone sets the flag to false the
> MessageSenderInterceptor can always fall back and init a Conduit later 
> using
> the EndpointInfo.
> - Is your only objection that we may not always need the specific Conduit
> that is inited? And that this may consume resources? Or is the motivation
> for this approach that you just don't want to use a Conduit at all. It 
> seems
> like it is mostly the later, which is what all my hubbub is about.
>
> - Dan
>


Mime
View raw message