cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: Handling non-Client directed messages/AOP for Services & Clients
Date Wed, 25 Oct 2006 11:17:28 GMT
 

> -----Original Message-----
> What you say makes sense. I have two additional thoughts:
> 1. There could be some error which would leave no Exception 
> or no response objects in the Message, in which case it would 
> qualify as a partial response and block. 

Well I'd hope we'd have a bullet proof try...catch clause in the
interceptor chain traversal, that would ensure any exception thrown is
caught and set as message content of type Exception.class. So I think we
can avoid the possibility of a full response being misinterpreted as a
partial response due an exception being thrown.

However, I could see where the converse case could occur ... e.g. when
reading the body of a partial response, say the connection is dropped,
an IOException is thrown and this is set as the message content causing
the partial response being misinterpreted as a full response.

So yes, I agree, it would actually be better to explicitly mark the
response as having a null body via a message property set in say the
RPCInInterceptor (or whatever interceptor is responsible for
unmarshalling the response body and setting the message content). 

> I think making some 
> stronger mechanism would be beneficial. This mechanism would 
> allow an interceptor to say "Don't actually send this message 
> all the way to the client/server".
>
> 2. This is a general pattern beyond partial responses. It 
> almost seems like we might want to create some higher level 
> AOP like mechanism around operations/services (instead of a 
> low level interceptor). For instance, if we are doing WS 
> transactions, we might receive transaction messages on the 
> Client.onMessage(), in which case we'd want to redirect it some where.

Yep, I can see where this would be useful, e.g. for a server-side RM
interceptor to mark an incoming ACK as not requiring a dispatch to an
implementor.

In the old Celtix codebase we achieved this by simply setting a property
on the context to indicate that the dispatch should be suppressed.

However we didn't really need to redirect the incoming messages anywhere
(say to another chain or observer) - instead the interceptor/handler
responsible simply did what needed to be done, and then essentially
marked the message as having been dealt with. So for example the RM
interceptor would react to an incoming ACK by evicting the relevant
message from the retransmission queue, and then set the
DISPATCH_PROPERTY to false to indicate that when the message got to the
end of the interceptor/handler chain it should not be dispatched any
further.

/Eoghan 
 
> I'm not sure what such an AOP mechanism would look like or if 
> there would be some additional interfaces/classes needed, but 
> it seems like it might be a helpful thing. Thoughts?
> 
> - Dan
> 
> Glynn, Eoghan wrote:
> >  
> > Dan,
> >
> > I've made several attempts to send this, but for some 
> reason its not 
> > showing up on the cxf-dev list.
> >
> > Apparently the Apache infrastructure had some downtime 
> scheduled for 
> > last Saturday thru Monday. Dunno if this mail list 
> flakiness is related.
> >
> >
> > /Eoghan
> >
> > -----Original Message-----
> > From: Glynn, Eoghan
> > Sent: 23 October 2006 13:54
> > To: 'cxf-dev@incubator.apache.org'
> > Subject: RE: Need Help with WS-A systest
> >
> >
> > Dan,
> >
> > I'm just back from paternity leave, so I'm only seeing this 
> mail now.
> >
> > Yes, the MAPAggreator does the correlation. This is the 
> most natural 
> > place for it to be done, as the correlation is based on 
> wsa:RelatesTo 
> > header.
> >
> > I don't agree with your point about partial response 
> handling. First, 
> > partial responses are not necessarily exclusive to RM, 
> other services 
> > could leverage this facility. Second, the related code in 
> ClientImpl 
> > is simply there in order to distinguish partial from full 
> responses, 
> > so that control is only returned to the invoking thread when the 
> > latter is available. Note that partial and full responses 
> may arrive 
> > at the ClientImpl in either order. So this check is required and 
> > should not have been removed. Third, I don't see how a 
> single line of 
> > code in
> > ClientImpl.isPartialResponse() to check whether the inMessage has 
> > content of type List or Exception is any more complicated 
> than setting 
> > a PARTIAL_RESPONSE property elsewhere and then checking 
> whether this 
> > is set.
> >
> > /Eoghan
> >
> >   
> >> -----Original Message-----
> >> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> >> Sent: 18 October 2006 06:16
> >> To: cxf-dev@incubator.apache.org
> >> Subject: Need Help with WS-A systest
> >>
> >> I just committed a bunch of code to enable client side 
> fault handling.
> >>     
> >
> >   
> >> I got side tracked with correlation, but then decided the 
> crap that I 
> >> wrote was completely unncessary as we're already doing 
> correlation in 
> >> MAPAggregator... Somewhere along the way I seem to have 
> broken WS-A 
> >> as
> >>     
> >
> >   
> >> the systest no longer passes, but I can't for the life of 
> me figure 
> >> out what I did.
> >>
> >> There were two main changes. First, I set things up so that the 
> >> transport is responsible for correlating the exchange (if 
> possible - 
> >> obviously its not always). This means the transport needs 
> to set both 
> >> the message.exchange and exchange.inMessage. Setting the 
> >> exchange.inMessage actually does both, so I switched everything to 
> >> use
> >>     
> >
> >   
> >> that.
> >>
> >> Second, I removed the partial response handling from 
> ClientImpl. As I 
> >> said in the commit message, it seems that the ws-rm implementation 
> >> should provide its own MessageObserver. Or at the very least, we 
> >> should provide some better way of figuring out if its a partial 
> >> response. One option woudl be setting a PARTIAL_RESPONSE 
> property in 
> >> the message.
> >> Another would be creating a different message label - i.e. 
> >> exchange.setMessage("partial", message) - and then we can 
> test if the 
> >> received message equals exchange.inMessage.
> >> Regardless, I tried adding the partial response checking 
> back in and 
> >> it still didn't work.
> >>
> >> Can someone more familiar with the WS-A code help shed some light? 
> >> I'm
> >>     
> >
> >   
> >> thoroughly stumped. Most likely I'm doing something insanely stupid
> >> :-)
> >>
> >> - Dan
> >>
> >> --
> >> Dan Diephouse
> >> (616) 971-2053
> >> Envoi Solutions LLC
> >> http://netzooid.com
> >>
> >>
> >>
> >>     
> 
> 
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com
> http://netzooid.com/blog
> 
> 
> 

Mime
View raw message