cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]
Date Mon, 02 Apr 2007 23:44:04 GMT

I just want to chime in hear and say I completely agree with most of what 
Dan is saying.

First off, I don't see any way in which we can reliably detect whether we 
can "automatically" wire up the co-located case.   We have multiple 
frontends (jaxws, simple, javascript, more to come) and multiple 
databindings (aegis, jaxb, e4x, more to come).   Not only that, but the 
ones we do support have several customization options that can easily 
make it that code generated for the client won't work against a server.    
One example is the mime bindings.   A server that just deals with a 
database or files or something may prefer to just keep the byte[] for 
the mime types.   The client, on the other hand, may prefer Source 
objects or something.   The customizations allow that. 

With JAX-WS, pretty much everything is customizable.   The package names, 
the classnames, the method names, the classnames for the faults, etc...    
Anyway, trying to detect all that will NOT be fun.   Having the user 
specify that that know it will work is, IMO, the better way to go.

Second, in JSEE/Java world, you DON'T generally secure the boundary of 
the VM.  You Secure the boundary of the Service.   Each service in the 
VM can/may have it's own security settings and such.    By bypassing the 
security stuff, one service automatically would inherit the security of 
a different service.   I am DEFINITELY not comfortable with that.   
Again, if the user specifically says "I want it to do that", maybe.   
But definitely not automatically.

In regards to the "up front" or "delayed" Conduit creation...   I really 
don't care.   That said, a user definitely needs to be able to call 
something akin to client.getConduit().configure(...) to configure 
things.  XML based config is definitely not for everyone.

Eoghan: question for you: If you DO want an "Automatic" thing, could the 
EndpointReferenceType resolution pluginny thing you added accomplish 
that?  Couldn't it detect if it's co-located and return a ERT that sets 
up an "ObjectBinding" and "LocalConduit" combination?  Yes, that's 
an "upfront" resolution, not per-invocation, but with how expensive that 
detection is going to be (see the above databinding discussion), I don't 
think we want it per-invocation anyway.

Anyway, that's my quick thoughts.


On Monday 02 April 2007 12:10, 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?
> > 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)
> > 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

J. Daniel Kulp
Principal Engineer
P: 781-902-8727    C: 508-380-7194

View raw message