cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject Re: [PROPOSAL] Client and Conduit changes
Date Tue, 20 Mar 2007 00:23:35 GMT
On 3/19/07, Glynn, Eoghan <> 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 |

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