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? 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 -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
