RE: JaxwsInterceptorRemoverInterceptor and RM

["Glynn, Eoghan" <eo...@iona.com>]

 

> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com] 
> Sent: 23 December 2006 03:00
> To: cxf-dev@incubator.apache.org
> Subject: Re: JaxwsInterceptorRemoverInterceptor and RM
> 
> Hi Eoghan,
> 
> On 12/19/06, Glynn, Eoghan <eo...@iona.com> wrote:
> >
> >
> >
> > OK, conceptually I agree with your picture of the RM out-of-band 
> > protocol messages (such as the CreateSequence) being akin to 
> > invocations on a separate service.
> >
> > However, in practice I'm not sure as to what exactly we'd gain over 
> > the current implementation (where the RM interceptor effectively 
> > services these invocations directly itself).
> 
> 
> By not jumping between chains to dispatch the RM out-of-band 
> invocation,
> > we avoid having to make the error-prone decision as to exactly what 
> > interceptors this special chain should include. This 
> question is not 
> > straight-forward, as the request will already have been partially 
> > dispatched on the normal chain, so the special RM chain 
> would have to 
> > take cognizance of this.
> >
> > In fact by the time the request has reached the RM 
> interceptor, i.e. 
> > the point at which we recognize it as an RM out-of-band protocol 
> > message as opposed to an application-level request, most of 
> the work 
> > has already being done ... so there wouldn't be many (if any) 
> > interceptors that it would make sense to include in a 
> special chain to 
> > handle the out-of-band messages.
> 
> 
> I see your point. The flip side of this though is that there 
> aren't many frontend specific interceptors in the beginning 
> of the chain though.  The holder/wrapper/logicla interceptors 
> are at the end at least.
> 
> (On a separate note - should the SOAPHandlers even be invoked on an RM
> createsequence??)

Hmmm ... that's arguable. 

It was certainly needed in Celtix, as the RM layer was partially
implemented as a JAX-WS SoapHandler, as was the WS-A layer. So these
handlers definitely needed to partipate in the dispatch of out-of-band
RM messages like CreateSequence.

On the other, a developer might be surprised to see their
application-level JAX-WS Handlers traversed for what they'd consider
"under the hood" messages (like the RM CreateSequence, or say some
WS-AtomicTransactions out-of-band interaction with a txn coordinator).
But such a surprise could only be educational for them :)

As things stand however, the JAX-WS handler interceptors do not sit well
with RM, or at least with the logging interceptors used by the RM system
test. Hence they're stripped from the chain by the
JaxWSInterceptorRemover.
 
> However, I'd agree that the current practice in the RM 
> implementation of
> > scanning the remainder of the chain to remove problematic 
> interceptors 
> > is bad, not least as its dependent on the implementation 
> details of a 
> > specific (JAX-WS) frontend. So we have to come up with a 
> better way of 
> > doing this, and if possible I'd prefer to leave these 
> interceptors in 
> > place in the normal chain, but make them more robust in the 
> sense of 
> > being tolerant to unexpected message content.
> >
> > So your proposal is to make the current interceptors more 
> tolerant of
> messages not bound to them?  So if I was a 
> WrapperClassInInterceptor I would check to make sure the 
> service being invoked was actually a JAX-WS service?
> Can you elaborate on how exactly you see this thing working?

Well I was thinking of something even more simple ... the interceptors
should be coded defensively to "expect the unexpected" and simply step
out of the way when that occurs ... e.g. instead of the
HolderOutInterceptor just doing a straight cast of the message parts to
Holder and barfing with ClassCastException on any other type, it would
first check with instanceof to ensure the cast succeeds and otherwise
bail out from handleMessage() immediately.

Note that these issues don't just arise in the RM use-case. AFAIK the
Yoko folks ran into similar problems with the JAX-WS interceptors when
mediating a CORBA dispatch.

/Eoghan

Re: JaxwsInterceptorRemoverInterceptor and RM

[Andrea Smyth <an...@iona.com>]

Glynn, Eoghan wrote:

> 
>
>  
>
>>-----Original Message-----
>>From: Dan Diephouse [mailto:dan@envoisolutions.com] 
>>Sent: 23 December 2006 03:00
>>To: cxf-dev@incubator.apache.org
>>Subject: Re: JaxwsInterceptorRemoverInterceptor and RM
>>
>>Hi Eoghan,
>>
>>On 12/19/06, Glynn, Eoghan <eo...@iona.com> wrote:
>>    
>>
>>>
>>>OK, conceptually I agree with your picture of the RM out-of-band 
>>>protocol messages (such as the CreateSequence) being akin to 
>>>invocations on a separate service.
>>>
>>>However, in practice I'm not sure as to what exactly we'd gain over 
>>>the current implementation (where the RM interceptor effectively 
>>>services these invocations directly itself).
>>>      
>>>
>>By not jumping between chains to dispatch the RM out-of-band 
>>invocation,
>>    
>>
>>>we avoid having to make the error-prone decision as to exactly what 
>>>interceptors this special chain should include. This 
>>>      
>>>
>>question is not 
>>    
>>
>>>straight-forward, as the request will already have been partially 
>>>dispatched on the normal chain, so the special RM chain 
>>>      
>>>
>>would have to 
>>    
>>
>>>take cognizance of this.
>>>
>>>In fact by the time the request has reached the RM 
>>>      
>>>
>>interceptor, i.e. 
>>    
>>
>>>the point at which we recognize it as an RM out-of-band protocol 
>>>message as opposed to an application-level request, most of 
>>>      
>>>
>>the work 
>>    
>>
>>>has already being done ... so there wouldn't be many (if any) 
>>>interceptors that it would make sense to include in a 
>>>      
>>>
>>special chain to 
>>    
>>
>>>handle the out-of-band messages.
>>>      
>>>
>>I see your point. The flip side of this though is that there 
>>aren't many frontend specific interceptors in the beginning 
>>of the chain though.  The holder/wrapper/logicla interceptors 
>>are at the end at least.
>>
>>(On a separate note - should the SOAPHandlers even be invoked on an RM
>>createsequence??)
>>    
>>
>
>Hmmm ... that's arguable. 
>
>It was certainly needed in Celtix, as the RM layer was partially
>implemented as a JAX-WS SoapHandler, as was the WS-A layer. So these
>handlers definitely needed to partipate in the dispatch of out-of-band
>RM messages like CreateSequence.
>
>On the other, a developer might be surprised to see their
>application-level JAX-WS Handlers traversed for what they'd consider
>"under the hood" messages (like the RM CreateSequence, or say some
>WS-AtomicTransactions out-of-band interaction with a txn coordinator).
>But such a surprise could only be educational for them :)
>
>As things stand however, the JAX-WS handler interceptors do not sit well
>with RM, or at least with the logging interceptors used by the RM system
>test. Hence they're stripped from the chain by the
>JaxWSInterceptorRemover.
>  
>

We could drop all interceptors belong to the "user" phases USER_LOGICAL 
(e.g. LogicalHandlerInterceptor), USER_PROTOCOL (that is the phase to 
which the SOAPHandlerInterceptor SHOULD belong, it is currently however 
in phase PRE_PROTOCOL, don't know why, IMO that's wrong).
Doing so does not depend on the frontend, and therefore would not 
pollute dependencies.
We could even make this dropping of user phase interceptors for RM 
protocol messages optional.  It would happen at the earliest point 
possible, which is in the RMSoapInterceptor, in which by looking at the 
now decoded WS-A action header the message can be identified as an RM 
protocol message. As the RMSoapInterceptor belongs to phase 
PRE_PROTOCOL, which (inbound) comes before USER_PROTOCOL, and USER_LOGICAL.
It's not possible however to remove the USER_STREAM interceptors, as 
they are one of the first in the inbound chain and are traversed before 
we can actually detect that the message is an RM protocol message.

> 
>  
>
>>However, I'd agree that the current practice in the RM 
>>implementation of
>>    
>>
>>>scanning the remainder of the chain to remove problematic 
>>>      
>>>
>>interceptors 
>>    
>>
>>>is bad, not least as its dependent on the implementation 
>>>      
>>>
>>details of a 
>>    
>>
>>>specific (JAX-WS) frontend. So we have to come up with a 
>>>      
>>>
>>better way of 
>>    
>>
>>>doing this, and if possible I'd prefer to leave these 
>>>      
>>>
>>interceptors in 
>>    
>>
>>>place in the normal chain, but make them more robust in the 
>>>      
>>>
>>sense of 
>>    
>>
>>>being tolerant to unexpected message content.
>>>
>>>So your proposal is to make the current interceptors more 
>>>      
>>>
>>tolerant of
>>messages not bound to them?  So if I was a 
>>WrapperClassInInterceptor I would check to make sure the 
>>service being invoked was actually a JAX-WS service?
>>Can you elaborate on how exactly you see this thing working?
>>    
>>
>
>Well I was thinking of something even more simple ... the interceptors
>should be coded defensively to "expect the unexpected" and simply step
>out of the way when that occurs ... e.g. instead of the
>HolderOutInterceptor just doing a straight cast of the message parts to
>Holder and barfing with ClassCastException on any other type, it would
>first check with instanceof to ensure the cast succeeds and otherwise
>bail out from handleMessage() immediately.
>  
>
I'd be very much in favour of this - hence my question: Is it OK to make 
the HolderInInterceptor robust by performing a type check before casting 
to Holder? Or is there a more efficient way, e.g. check the parameter 
type for INOUT first, and only then attempt the cast?

Andrea.

>Note that these issues don't just arise in the RM use-case. AFAIK the
>Yoko folks ran into similar problems with the JAX-WS interceptors when
>mediating a CORBA dispatch.
>
>/Eoghan
>  
>