On 3/16/07, Polar Humenn <[EMAIL PROTECTED]> 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 http://envoisolutions.com | http://netzooid.com/blog
