On 3/19/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
> The "request" messages seems to get sent out over a Conduit, > which is an abstract element that seems to suggest a > "connection" to a particular server (for lack of a better word). > > In this model, the "response" can come back by some other > means (protocol, address, connection orientation, etc), It cannot come by another means. It must be the *same* transport as delivered the outgoing request. I pointed this restriction out to you already in a previous mail. And for similar reasons, I'd venture that it must be the same protocol (e.g. SOAP) also.
Just to be clear, this is a constraint we're imposing. Our architecture does not impose it.
So, I surmise if you are going to do "invocations" in CXF, > you get the Client to do the work of the correlation of > request and response. Once again ... an invocation does not require a Client, neither does the Client have anything to do with correlation.
Again to be clear, I am not advocating that the Client do the correlations.
Therefore The Client should be setting the "response" > endpoints (Destination? BackChannel? DecoupledEndpoint?), > shouldn't it? I disagree. > Your description of the JAX-WS Dispatch stuff being used > means that CXF is used underneath where the Client would use > it. So if there is a correlation of request and response by > JAX-WS Dispatch its implementation should be taking care of > it. So, why isn't it using a Client?
It should be using the Client. I have an open JIRA for this. The problem before was that you were forced to use the Bare/Wrapped/RPC interceptors for databinding, which isn't so amenable to Dispatches. Now we have a nice way to disable this, so I don't see it as much of an issue.
Right now, I see the Conduit as a one way tunnel in which a > Message is sent from a client to any server. I assume that > abstract element on which Messages are received is a "Destination". Your view is incorrect. Unless the replyTo is non-anonymous, there is no backchannel Destination, and the Conduit most certainly is not one-way.
I would like it to be one way, but thats a longer discussion... :-) - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
