cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <>
Subject Re: Client API, EPRs
Date Sun, 11 Mar 2007 21:48:28 GMT

Apologies for the lag here. Too much traveling going on and I wanted to
spend some time thinking through this some more.

Some comments inline.

On 3/6/07, Glynn, Eoghan <> wrote:
> Hi Dan,
> Well if CXF is embedded in another product that *already* exposes an
> endpoint (e.g. a HTTP listsner) from the client process space, then CXF
> could use that to receive decoupled responses.  All the app needs to do
> is to provide an appropriate EPR via AddressingProperties.setReplyTo (),
> set this on the request context, and the CXF WS-A layer won't over-write
> this with any decoupled response endpoint that may (or may not) have
> been configured on the Conduit.
> However, I don't think its reasonable to expect CXF to *actively* launch
> a decoupled response endpoint on the basis of a replyTo EPR provided by
> the application, for a number of reasons:
> 1. the replyTo EPR may not contain all the info that the transport needs
> to initiate receipt of incoming messages, e.g. JMS may need stuff like a
> username/password for the connection factory, maybe a JNDI provider etc.
> This sort of transport-specific stuff may not be suitable for
> shoe-horning into an EPR, and would probably need to be configured in a
> transport-specific way.

First, thats an edge case. Second, people are defining standards to
shoe-horn JMS info into IRIs. Third, when the decoupled destination is being
set up it can still pull configuration from xml files if people need to add
extra configuration info.

2. there's no guarantee that the replyTo EPR specified by the app makes
> any sense, e.g. it may be for a different transport to that used for the
> outbound request (and we discussed the undesirability of mixed transport
> within an MEP on this list a while back).

We should add checks to ensure that this is sane & valid then. Its not that
hard to ensure that the ReplyTo transport is the same as the outgoing one.
We simply need to match up the transport IDs or the protocol part of the

3. its hard to see how to manage the lifecycle of a listener created on
> demand by CXF on foot of an application-provided replyTo. What if the
> app specifies a different replyTo URI for each sucessive request, maybe
> intending that the listener is a one-shot deal (i.e. is only intended to
> accept a single decoupled response). There's no way for the app to
> communicate this intended lifecycle with CXF, so CXF wouldn't know when
> to shutdown the Destination.

Lets ignore the per request case a moment: How would this differ from how
things currently are? Lets say I define a replyTo endpoint in my
cxf.xmlfile. Its not going to get shut down until I specifically shut
it down
myself or until I shut the appserver down. So letting CXF create a
destination automatically would not really be any different. It just makes
it easier for the user to set up the decoupled endpoint via the API. Once
they are done with the client they could call
and release any resources.

(I also would not be opposed to establishing a client life cycle. I.e. a
user can call Client.close() once they are done with everything. This would
allow RM to terminate the sequence at the same time. But maybe that is a
topic for another thread.)

Regarding the per request use case, my initial reaction is that we should
not do any automatic setup here. The main use case that I'm targeting is
creating a standard way to create a decoupled endpoint. If the user is
overriding it at a per request level they probably have a good reason for
doing so and can manage the endpoint creation themselves. I don't see that
as a very common case though.

I don't think there is anything that evil about auto-creating a decoupled
endpoint for the user if they specify it. But it does make it easy for
anyone to do it in a standard way. Which simplifies configuration and

- Dan

Dan Diephouse
Envoi Solutions |

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