cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Polar Humenn <>
Subject Re: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]
Date Mon, 02 Apr 2007 16:48:25 GMT
Dan Diephouse wrote:
> On 4/2/07, 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 ...
> You and me both. Its not fun, but its part of the Apache process.
>> 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.
> So now all the users need to check to see if this flag is enabled?
> We already have isGET which seriously gets on my nerves. Why should 
> people
> be checking these flags all the time?

yeah, what's that about? in AbstractPhaseInterceptor? Right? 
Why is HTTP functionality in an interceptor at all?


>> If a server requires HTTP security, will we just bypass it?
>> Yes. Trust is implied.
> I don't agree. Here is a better scenario. Acme industries has an a 
> service
> which gives detailed financial information of users. Due to security
> restrictions only certain applications & developers have access to this
> financial information. Trust is authenticated on the basis of  
> pub/private
> keys. If we have a client application running in the local process space
> which is not authenticated, then your scenario would implicitly grant 
> it. (I
> have seen such a scenario BTW)

These boundaries are all artificial.  One can make the same argument 
that since all processes run on the same machine that trust *is* be 
implied. Sure trust "can" be implied, but it's not a definite.

And it's not always the "trust" that is important, but more lower level 
details, like the proof of the validity of certificates, keys, and their 


>> What if the server & the client use different databindings?
>> Data-bindings don't come into the picture.
> How is that? If my server uses Aegis and my client uses JAXB, then it 
> seems
> you're trying to bypass the XML step which is needed. This is OK if it
> requires conscious enablement by the user, but automatic is another 
> story.
>> =
>> > [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.
> How??? The flag? This is exactly what Bindings are for though. Why 
> don't we
> just switch bindings? Or we could delay the addition of the Binding. 
> But a
> message flag?
>> 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.
> Doesn't this violate your goal of not having the user make any static
> changes at all?
>> > 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 ...
> 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.
> - Dan

View raw message