cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject Re: Client API, EPRs
Date Fri, 16 Mar 2007 21:05:28 GMT
On 3/16/07, Polar Humenn <> wrote:
> I'm trying to follow this discussion, but I need more info on what a
> "destination" is.

A Destination is something that receives messages. Kind of similar to an
endpoint ;-) It also has a back channel with which to send responses back
(could be asynchronous or sync)

I'll post a summary of my proposal shortly which people can review, as this
discussion is getting a bit convoluted.

However, I'm in agreement with Dan on the Client-Conduit issue.
> I am now just *barely* able to hold onto making a trust decision about
> information that goes out over the wire from the application. At least,
> with the 1 to 1 relationship between the Client and the Condult, there
> is some hope that the code operating the client can say it wants its
> requests to go over a particular conduit it trusts.
> Completely getting rid of that correlation would ruin that ability.
Well, we still need to be able to override the address we're talking to at
runtime via the JAX-WS properties. That should probably result in a new
conduit ala ConduitInitiator.getConduit(EndpointInfo, EPR) instead of
handling the address change inside the Conduit I would think. But I think
you don't like that from a security standpoint if I'm reading correctly.

My question to you is this: you're very concerned about somehow getting a
new conduit which isn't configured with the proper security. But a user can
select a new conduit at any time via the API. Setting the endpoint address
is pretty much equivalent to doing this. Is there really anything we can do
at all in that scenario other than hope that users don't use a conduit they
haven't configured?

- Dan

Dan Diephouse
Envoi Solutions |

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