cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Polar Humenn <>
Subject Re: Client API, EPRs
Date Mon, 19 Mar 2007 13:59:50 GMT
Dan Diephouse wrote:
> 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?

The goal is assurance and trust. Assurance in the fact that what I 
command, actually happens, and trust in the destination (endpoint) of 

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.


> - Dan

View raw message