cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Date Wed, 29 Sep 2010 13:54:59 GMT
On Wednesday 29 September 2010 4:53:25 am Andrew Dinn wrote:
> Hi Dan,
> I am  afraid I have much shallower knowledge of the CXF code than
> Alessio so I hope you will forgive me asking a rather simple-minded
> question. Could you explain why CXF needs to perform correlation of
> outgoing requests and incoming responses?

There are a few uses cases that I can think of off the top of my head, but all 
relate to request/response use cases with the SAME client proxy:

1) JAX-WS async client callbacks.   We need to correlate the incoming message 
with the outgoing request so we can figure out which call back object to call.  
This correlation could potentially be pushed into the ClientImpl after the 
soap processing and everything is done, but it still needs some way to 

2) JAX-WS handlers - if I remember correctly, if a Handler on the outgoing 
side sets a property on the context, it needs to be available when the handler 
on the incoming side.   Thus, we would need some level of correlation prior to 
handlers being called.   Our own interceptors have the same issue.  For 
example, the Logging interceptors stick an ID # on the exchange so you can 
visually correlate the messages in the logs (although the logging interceptors 
run prior to the MAPCodec, so this probably doesn't work in this case anyway).  
WS-SecurityPolicy also requires this if signature confirmation is enabled.  We 
need to record the signatures that were sent so we can make sure they are 
properly confirmed on the response.  (although, thinking about this, I also 
don't know if that works in the decoupled case)

3) WS-RM - but I don't really know all the details

4) Mapping to the correct Operation for the response - by correlating, we have 
the OperationInfo and such that was used for the request so the response can 
be properly unmarshalled and such based on that OperationInfo.   Without the 
correlation, we'd have to do extra processing to use the body contents to 
figure out the OperationInfo and such.   The problem is that that wouldn't be 
reliable as you can have multiple operations with the same return message (but 
different request messages) and still be compliant.

Hope that helps a bit.  


> regards,
> Andrew Dinn
> -----------
> On 09/28/2010 09:33 PM, Daniel Kulp wrote:
> > On Tuesday 28 September 2010 7:26:24 am Alessio Soldano wrote:
> >>    Hi Dan,
> >> 
> >> On 09/27/2010 08:25 PM, Daniel Kulp wrote:
> >>> Hmm.....   I wonder if we can tackle some of these things kind of piece
> >>> meal, in steps:
> >>> 
> >>> 1) Scenario one is a single Bus, but multiple MAPCodec's.   This should
> >>> be fairly easy.  If the MAPCodec stores it's storage map as a property
> >>> on the Bus, then multple MAPCodecs could share the storage and the
> >>> problem would be solved  for this usecase, right?
> >> 
> >> Right
> >> 
> >>> 2) Scenario two is a single JVM/classlaoder with multiple bus's.  This
> >>> is similar to (1), but the storage could be pre-configured and
> >>> shareable.
> >> 
> >> Yes. Btw this is more or less the scenario we're on right now, as we
> >> could have this storage as a shared facility provided by CXF libraries
> >> which can be seen by all apps using them.
> >> 
> >>> 3) Scenario three would be multiple apps/jvms/classloader.  This is
> >>> trickier. One solution would be to allow configuring in a distrubted
> >>> map implementation for the storage.
> >> 
> >> Yes, this is indeed trickier... and would deal with client and final
> >> response endpoint running on different jvm/classloader.
> >> 
> >> IOW what you're suggesting here is that this might basically be a matter
> >> of having the user configure the storage with the scope/visibility he
> >> needs, right?
> > 
> > Yea.  That's kind of what I was thinking.   This MAY be combinable with
> > your disabling of the correlation check so if the message cannot be
> > correlated in the current storage, just let it through like you
> > originally tried.   To avoid the memory leak, we could timestamp the
> > outgoing exchange and periodically purge the exchanges based on some
> > sort of configurable timeout.   That would at least cover MOST of the
> > issues.

Daniel Kulp

View raw message