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 16:36:42 GMT
This is all too daunting to understand. I see some things that would 
have to be done if the Conduit is selected at the MessageSenderInterceptor.

Currently the client can configure the Conduit to set certain contracts. 
For instance,

(HTTPConduit) Conduit con =
       (HTTPConduit) ClientProxy.getClient(proxy).getConduit();
con.setAuthorizationPolicy( .... );
con.setSslClient(.....);
proxy.sayHi();

You have incurred some setup time at the creation of the client to 
select a conduit, then take some time to configure it (or *check* its 
configuration), then make the invocation with some hope (assurance?) 
that the underlying system will follow through with your requirements.

To do it another way, you would have to "invent" a policy language to 
give the invoker some assurance that the correct Conduit will be 
selected/created down the road. Okay, so it looks like the same thing. 
It's about about what you want to call a conduit or a "conduit policy" 
in this case.

However, if you go the "delayed" route then you would really need a 
callback mechanism to the client so that it can *check* the conduit 
configuration before the invocation went out.

I'm coming from an security and assurance point of view.

So, that's extra overhead as well.

Cheers,
-Polar

Glynn, Eoghan wrote:
> OK I'm going to take one last shot at clarifying this use-case ... deep
> breath :)
>
> You've set me a *lot* of questions (nobody expects the spanish
> inquisition :), so please excuse the brevity of my answers as I've
> already burned a lot of time on this, and I don't have much more to
> spare ...
>
>
>   
>> -----Original Message-----
>> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
>> Sent: 02 April 2007 05:41
>> To: cxf-dev@incubator.apache.org
>> Subject: Re: In Process Dispatch [was Re: [PROPOSAL] Client 
>> and Conduit changes]
>>
>> To follow up with my own email... (feel free to cut and paste 
>> into another message so you don't have to reply to two emails)
>>     
>
>
> First I've pasted in your set of questions for your previous mail ...
>
>
>   
>>> Here the binding and interceptor chain would be set up exactly the 
>>> same way, regardless of whether the target is local or 
>>>       
>> remote. Where 
>>     
>>> the target really is remote, then everything just works. If 
>>>       
>> the target 
>>     
>>> happens to be instantiated within the local process space, 
>>>       
>> then I want 
>>     
>>> to detect this and adapt accordingly, *without any static 
>>>       
>> changes* (to 
>>     
>>> config, WSDL, policies, code, whatever). Then maybe the target 
>>> migrates to another container instance and everything 
>>>       
>> reverts to work as before.
>>
>>
>> OK, this clarifies what you're looking to do for me quite a 
>> bit. If you're looking to do an in process dispatch with an 
>> existing endpoint that has been created (i.e. an HTTP 
>> endpoint) that is a completely different story. 
>>     
>
>
> It doesn't matter if it's a HTTP endpoint, or any other transport for
> that matter. We'd short-circuit the dispatch so that a transport is not
> involved in any capacity.
>
>
>   
>> It isn't very 
>> clear to me how the mechanics of such a thing would work. 
>> Could you maybe supply a little more information about how 
>> you would see the following working:
>>
>> How would we determine if the endpoint is in the local 
>> process space? For instance, if I have a Client talking to an 
>> HTTP Server endpoint, how does it know to shortcut and talk 
>> to the server directly?
>>     
>
>
> If the endpoint has been publish()ed in the local process space, then an
> interceptor can detect this via the ServerRegistry.
>
>  
>   
>> Would the Binding interceptors would be run?
>>     
>
>
> Nope.
>
>
>   
>> Would your solution require the modification of the current 
>> binding interceptors to support auto-detection of in process dispatch?
>>     
>
>
> Nope.
>  
>
>   
>> How do we determine which user level interceptors to run? 
>>     
>
>
> We'd only run "logical" interceptors, and by-pass everything from the
> protocol layer on down thru' the chain.
>
>
>   
>> Say I enable WS-Security - what mechanisms would there be to 
>> determine that it should not be run for the local invocation 
>> case?  
>>     
>
>
> The interceptors are simply by-passed. We can do this without
> introducing a security hole as its all happening with the local process
> space. So trust is implied.
>
> However we can mark the Message via a property as originating from
> within the local process space. So that logical-level security
> interceptors on the receiving side can make decisions on that basis. 
>
> But we wouldn't force the intensely paranoid to use this mechanism if
> they find the by-passing of security to be objectionable ... i.e. the
> application developer/deployer would have to make a conscious decision
> to enable this adaptive behavior.
>
>
>   
>> Or what if a user writes a transformation interceptor. 
>> How would the transformation be performed or would it not be?
>>     
>
>
> It wouldn't.
>
>  
>   
>> If a server requires HTTP security, will we just bypass it? 
>>     
>
>
> Yes. Trust is implied.
>
>
>   
>> For instance, lets say that we have a website which 
>> communicates with its backend via a soap service. The client 
>> uses the website's username/password to authenticate against 
>> the server. If we just bypass that authentication, that would 
>> be a security hole.
>>     
>
>
> Are you talking about a delegation of credentials scenario? i.e. client
> -invokes-> mid-tier -invokes-> backend, where the username/passwd for
> the first invocation are delegated onto the second leg? 
>
> If so, then this can still be achieved, by passing the creds via the
> BindingProvider.USERNAME/PASSWORD_PROPERTY or the AuthorizationPolicy
> set on the Message.
>
> Also, if the mid-tier->backend leg is protected by HTTP basic auth, then
> even if the creds weren't available to the mid-tier, this wouldn't open
> a security hole. The backend should reject the forwarded message with
> 401 or 403 or some-such.
>
>
>   
>> What if the server & the client use different databindings?
>>     
>
>
> Data-bindings don't come into the picture.
>
>
>   
>> On the client side, when do we make the decision about 
>> whether or not the endpoint is "in process"? During a client 
>> creation? 
>>     
>
>
> No.
>
>
>   
>> Or during each invocation? 
>>     
>
>
> Yes.
>
>
>   
>> Can the decision happen mid invocation?
>>     
>
>
> Well the decision would be made in an interceptor, if that's what you
> mean by mid-invocation.
>
>  
>   
>> [First Impressions]
>> My first impression (based on what I understand you're trying 
>> to achieve at this point) is that any solution:
>> a) Will require the use of different binding interceptors. 
>>     
>
>
> No. The binding interceptors don't need to change. Instead they'd be
> by-passed.
>
>
>   
>> Obviously we don't want to go invoking soap interceptors for 
>> a local dispatch.
>>     
>
>
> Obviously.
>
>
>   
>> b) Will have some major affects on how their service is 
>> invoked and possibly some security issues. It sounds like the 
>> user should make a conscious decision about whether or not to use it.
>>     
>
>
> Yep, of course they should. And they would do so by configuring an extra
> interceptor into the chain to drive this. Which would have the effect of
> using an optimized form of dispatch *if and only if* the target happens
> to currently exist in the local process space. If, on the other hand,
> the target really is remote, then the normal route is followed.
>
> So this wouldn't be foisted on anyone. But neither does the user have to
> *statically* choose either a local or remote style of dispatch. Once
> they've enabled the adaptive selection mechanism, then it just works.
>
>
>   
>> c) Will have to make the decision about whether or not the 
>> Client is invoking a local service or a remote service before 
>> the interceptor chain is invoked. 
>>     
>
>
> I disagree.
>
>
>   
>> In other words, we will 
>> have to add logic to the Client to detect this. 
>>     
>
>
> Disagree, it can be done in an interceptor.
>
>
>   
>> If this is 
>> done during the interceptor chain we may already have invoked 
>> binding interceptors.
>>     
>
>
> Isn't that phases are for?
>
> We could just ensure this extra interceptor is run before any
> binding-level interceptors.
>
>
>   
>> d) Does not implicitly require that we ditch 
>> Conduits/Destinations for in this type of in process 
>> dispatching (if you agree to b, I think this follows 
>> relatively easily. Proposed solution below.)
>>     
>
>
> It doesn't *require* that we "ditch Conduits/Destinations". Its just a
> different way of doing it. It might not be the way you would have chosen
> to implement it, but remember ... broad church, diversity of ideas and
> all that ...
>
>
>   
>> After re-reading your emails, it seems that you want to 
>> select this at invocation time, not at client creation time.
>>     
>
>
> Yes.
>
>
>   
>> I don't think we can do this after the chain has been 
>> dispatched. If we did so this would mean we change our 
>> Bindings pretty extensively to support detection. 
>>     
>
>
> I don't think the bindings need to change at all.
>
>
>   
>> This would 
>> complicate binding creation and seems pretty unnecessary 
>> since this is what bindings are for - to control how a 
>> service is bound to a protocol. It also could be disastrous 
>> as we might have already written part of the message.
>>     
>
>
> Not if the interceptor traversal phases are used correctly. 
>
>  
>   
>> So it seems to imply that a per invocation approach would 
>> require changes to the ClientImpl class. If we selected that 
>> we want to use in process dispatch via a URI or flag or some 
>> other mechanism then we would need to find a different 
>> binding and use that instead.
>>     
>
>
> I don't think the Client needs to be involved in the decision making.
>
>  
>   
>> I'm not sure why we wouldn't want to use a 
>> Conduit/Destination still. They seem like a perfectly good 
>> way to dispatch a message from a client to a service. Why 
>> should we invent another one?
>>     
>
>
> Getting as far the Conduit on the outbound chain implies that we've
> traversed a bunch of other unnecessary stuff, the whole point of the
> exercise being to avoid this.
>
>  
>   
>> Also, on the Conduit auto-init issue, if we have logic inside 
>> ClientImpl.invoke to detect whether or not we're doing an 
>> in-process dispatch, can't we use that same logic to 
>> determine whether or not we should auto-create the Conduit?
>>     
>
>
> Because, I don't think we need the inprocess-dispatch detection logic in
> the Client. The whole point of an interceptor architecture is to allow
> arbitrary "processing units" to swapped in and out of the dispatch
> chain. 
>
>  
>   
>> I'm envisioning that a user sets an endpoint address of 
>> "endpoint:fooEndpoint". We can detect that this property has 
>> been set inside the ClientImpl and not create the Conduit. We 
>> can create that Conduit in MessageSenderInterceptor.  The 
>> same applies if they're using a different remote endpoint as well.
>>     
>
>
> The whole point is to allow apps take advantage of this without any
> static changes (like requiring the app to set a "endpoint:fooEndpoint"
> property).
>
>  
>   
>> Can you detail more about how you see the logic inside 
>> ClientImpl chainging?
>>     
>
>
> IMO the Client doesn't need to be involved in the in-process dispatch
> detection.
>
> The only Client change required is in the conduit retrieval as outlined
> in my "Pluggable Conduit Initiation Strategy" mail.
>
> Cheers,
> Eoghan
>
>  
>   
>> - Dan
>>
>> --
>> Dan Diephouse
>> Envoi Solutions
>> http://envoisolutions.com | http://netzooid.com/blog
>>
>>     


Mime
View raw message