> -----Original Message----- > From: Daniel Kulp [mailto:[EMAIL PROTECTED] > Sent: 03 April 2007 00:44 > To: [email protected] > 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
