cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]
Date Tue, 03 Apr 2007 10:25:46 GMT


> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org] 
> Sent: 03 April 2007 00:44
> To: cxf-dev@incubator.apache.org
> Subject: Re: In Process Dispatch [was Re: [PROPOSAL] Client 
> and Conduit changes]
> 
> 
> 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.


Sure, there are lots of degrees of freedom. But I'd wager that it would
be a *very common* case that not only is the same data binding used on
both sides, but also this common data binding is customized in the same
way. For the other cases, i.e. a data binding mismatch, then obviously
all bets are off for just passing the raw Java objects.


> 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.


I've pointed out several times on the preceding threads that this is
DEFINITELY not an automatic thing. Rather its an adaptive thing.

You've read the preceding threads, right?

The interceptor that drives it must be explicitly engaged. So if you
don't want this feature, you don't have to have it. Period.

That being said, I would also question your assertion that the
boundaries of the VM need not be secured. Sure, the process space can be
partitioned so that different security polices are applied to be to
different components. But that is *not* that same thing as allowing any
old (possibly subversive) code run in the VM. Otherwise the most
simple-minded DenialofService attack ... while(true)
myMemoryWastingList.add(new byte[1024*1024]); ... could render the
entire VM a useless bag of OutOfMemoryErrors.


> 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.


Again, I pointed several times in the preceding threads that this
mechanism can easily accommodate the "programmatically access the
Conduit from the Client" use-case. There's a big difference between
allowing application access to the Conduit and mandating that Conduits
*must always* be created up front in order to support that. 


> Eoghan: question for you: If you DO want an "Automatic" 
> thing, could the 
> EndpointReferenceType resolution pluginny thing you added accomplish 
> that? 


Well, that's not the intention of EPR resolution. The touch-point being
used for the co-located detection is an interceptor. That interceptor
has all the info it needs available to it. And the flexibility to modify
the trailing interceptor chain on the fly.


> 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.


The result of the detection could be cached so that it doesn't
necessarily have to be fully repeated for subsequent invocations.

/Eoghan

 
> Anyway, that's my quick thoughts.
> 
> Dan

Mime
View raw message