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: [PROPOSAL] Unification of coloc and object bindings
Date Fri, 13 Apr 2007 15:03:04 GMT


> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net] 
> Sent: 13 April 2007 14:43
> To: cxf-dev@incubator.apache.org
> Subject: Re: [PROPOSAL] Unification of coloc and object bindings
> 
> 
> I think I just meant that in order for a server-side 
> (>=logical) interceptor to make use of any information on the 
> Message or Exchange, then the representation of that data -- 
> the data structures used, that is -- has to be the same on 
> the client side as it is on the server side.  


Yep, that's exactly what I was talking about re. the data binding being
identical on both sides. The data binding determines the types of the
raw Java objects representing the parameters of the invocation. JAXB is
just one example of a data binding supported by CXF. So it would be
possible for say the client logic to be using JAXB and the server logic
to be using Aegis, or maybe both side using JAXB but with different
customizations. But I think in practice, this won't be common.


> I'm pretty sure 
> I wasn't referring to JAXB, but now I'm worried if there is a 
> case in which different data bindings were relevant.  For 
> example, could the CXF AuthorizationPolicy XML type end up 
> bound different Java type?  It's a degenerate case, for sure, 
> and one not likely to be seen for a long while, so I'm less 
> concerned about that.


Yep, agreed this case is unusual, and the coloc binding will
transparently revert to a full dispatch (mediated via the real binding)
when the data bindings don't match. 


> I think my only point was that not all information in a 
> request context (Message/Exchange) is symmetric on the client 
> and server side, and post-logical interceptors may require 
> information in the context that's not on the client context.  
> So I'm just noodling about how such an interceptor would make 
> sense out of the limited information it has.
> 
> One other concrete issue has occurred to me, in thinking 
> about this CXF AuthorizationPolicy.  If you look at the 
> documentation annotations for the AuthorizationPolicy XML 
> type, there is an / implication/ that the structure is 
> intended for use with HTTP (witness the term "BASIC").  
> Perhaps the founding fathers had loftier intentions for this 
> type, such that it could be used for any type of 
> username/password authentication (JMS?  CSIv2?), but let's 
> assume the narrow case of HTTP/BasicAuth.
> 
> Now imagine a co-located case, in which a client populates a 
> request context with one of these AuthorizationPolicy instances.


I guess that logic would be engaged in a coloc dispatch if the
AuthorizationPolicy was fully populated in the logical phase on the
client-side, and the server-side interceptor that checks the
username/pass also operates in the logical phase by checking the (same)
AuthorizationPolicy instance.

Though obviously since the forthcoming HttpBasicAuthUserPassSupplier is
only triggered from the HTTPConduit, and I guess the 401-sending on the
server-side is also done in a "close-to-the-wire" interceptor, then we
obviously wouldn't have full basic auth going on. 

Which is fine I think, where we implicitly trust collocated code. For
users who don't, then the solution is clear, just fall back to a full
dispatch over HTTPS.

/Eoghan


> On Apr 12, 2007, at 3:51 PM, Glynn, Eoghan wrote:
> 
> >> Also, one other difference between the 2 approaches is 
> that the coloc 
> >> case seems to require that any information represented on 
> a message 
> >> on the outbound side has to be represented in exactly the 
> same way on 
> >> the inbound side.
> >
> >
> > Do you mean that the data binding is the same on both sides 
> (e.g. JAXB 
> > with identical customizations)?
> 
> 

Mime
View raw message