> -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: 02 April 2007 17:11 > To: [email protected] > Subject: Re: In Process Dispatch [was Re: [PROPOSAL] Client > and Conduit changes] > > On 4/2/07, Glynn, Eoghan <[EMAIL PROTECTED]> 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?
All users do not need to check if this is enabled. Just the interceptor that does the adaptive diversion. The existance of this interceptor in the chain is the "flag" in that sense. > We already have isGET which seriously gets on my nerves. Why > should people be checking these flags all the time? People don't need to check this "flag" (i.e. property on the message indicating in-process dispatch) all the time. The only place I'd see a definite need for checking is in the receiver-side security interceptors. > > 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) Exactly. Trust is implied. So the unauthenticated client application running in the local process space is implicitly authenticated. That's exactly the intention. And this has been run by the in-house security experts, so I'm not just speaking as a layman here. Obviously only to be used where the boundaries of the process are secure. Which I'd imagine is a sortta basic prereq for a secure application, no? I mean you wouldn't call a tomcat deployment "secure" if any old Tom, Dick or Harry could just cp anything they liked to the webapps dir, or? You could think of it like a regional airport. No need for passport control as only domestic flights are arriving and leaving. So we assume the passengers are either native to the country, or underwent passport control earlier when they entered the country at an international airport. Of course this assumes the country's borders are secure. Anyway just a dumb analogy. Lets not get bogged down on how airport security really works in these days of shoe-checking :) If the "secure process borders" condition doesn't hold, then this mechanism shouldn't be used. > > 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. Part of the transparent detection as to whether this form of dispatch is possible would I guess have to include a check as to whether the data bindings match and so could be by-passed. So that the raw Java objects could be passed directly. > > > [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??? By removing the binding-level interceptors from the chain. > 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? The in-process message property has nothing to do with the switching out of the binding interceptors from the chain. This is effectuated by a prior interceptor in the chain. The property simply marks the message as having undergone this specialized form of dispatch. It doesn't cause this form of dispatch to occur in the first place. > > 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? No. The extra config simply enables the adaptive smarts. The goal is to avoid having to make a static change to reflect the endpoint being in the local process space, and then statically undo the change if the endpoint migrates elsewhere. > > > 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. The same principle applies to you, no? > 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. So let me get this straight. You hold it as an article of faith that the Conduit selection *MUST* be done upfront in the Client, but you're prepared to allow the binding selection to be deferred? > 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. What would an ObjectBinding give us that a totally by-passed binding wouldn't? Other than the comfort factor of "hey we gotta have a binding, right?" Of course there are always different approaches that could achieve a similar result. /Eoghan
