Dan Diephouse wrote:
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?
The goal is assurance and trust. Assurance in the fact that what I
command, actually happens, and trust in the destination (endpoint) of
information.
The components we have are Client and Conduit.
Apparently, the Client is associated with one conduit to which
information flows. If this is the abstraction we can get at that API
level, we must lay our assurance in those components, such that if the
application selects a client and lays certain requirements (security
properties) on that client and conduit we are assured that the system
will comply with our requirements.
I don't mind the "address" switching within the conduit, provided we
make the security requirements (trust decision) know that can happen.
My formost concern is the Client-Conduit relationship. If the Conduit
were allowed to be switched out from underneath the Client, the Client
should get notified of this before it is actually used, so that the
client, or some object governing the security of the Client has a chance
to review, trust, and assure.
Although I haven't investigated it so thoroughly the issue of
Destinations, EndpointReferenceTypes (EPRs), and back channels, it seems
that an architectural decision to associate one particular Conduit with
a Client is the less complicated approach.
The "assurance" questions are, what *assurances* and/or constraints does
the Conduit bring to the table as far as the Client is concerned?
Endpoint Address stability? Protocol Stability Connection Stability?
Trusted Path Stability (proxies?). And equally as important, how to
these assurances and constraints transcend upwards to the Client and to
the application code using the Client.
Cheers,
-Polar
- Dan
