cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject Re: In Process Dispatch [was Re: [PROPOSAL] Client and Conduit changes]
Date Mon, 02 Apr 2007 16:10:46 GMT
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

Dan Diephouse
Envoi Solutions |

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message