cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Dushin <f...@dushin.net>
Subject Accessing Connection-based info from the transport
Date Fri, 02 Mar 2007 17:12:57 GMT

I'd like to get access to some connection-based information from the  
transport -- in particular, properties relating to any security  
context established at the transport (e.g., via an SSL handshake, or  
via a GSS-Accept) --

Primarily I'm thinking about the server-side of an invocation, though  
I suspect there may be client-side requirements, as well, though at  
present they are not as pressing for me.  (They may be later).

In any event, I've found that the transport is not populating the  
Message with any of the information I need, so I'd like to propose  
what I think should be a simple solution.

First, I understand the fact that there are potentially many  
different transport implementations, even perhaps for the same  
protocols.  So in some cases, this information may not be accessible  
by the transport, which is unfortunate (and perhaps motivation for  
not using the transport all together, depending on the business  
requirements).  So the solution should allow for the possibility that  
some transports can't provide the needed info, so that consumers of  
the information can code defensively in these situations (throw an  
exception, log a warning, whatever).

I can see how the transport destination implementations are  
instantiating the Message structures, which in turn get passed to the  
various interceptors (again, talking about the server-side here).  So  
I'd like the transports, as the divine creators of Messages, to  
populate said messages with the contextual information I need.  The  
question then becomes, what should this information look like, and  
how should it be keyed on the Message?

We have several alternatives, which I'd like suggestions on before  
submitting a patch.

First, I assume for purely organizational purposes we don't want a  
*huge* collection of tags on the Message.  Not that it matters much  
(the Message is currently implemented as a HashMap, so adding a lot  
of data should not have an impact on lookup), but perhaps for purely  
aestheic reasons, it would be better to aggregate this information in  
some comprehensible manner.

Going on that assumption, we have some options.  We could define a  
type or collection thereof, each of which has a collection of  
accessors (and mutators, for the benefit of our transports), which  
define which data is available, where the types stowed on these  
structs are common, well-known, and guaranteed likely-to-exist types,  
e.g.,

class/interface TLSTransportInfo {
     java.security.cert.Certificate[] getPeerCertificateChain() ...
}

I started to do this, but the LISP programmer in me said "there has  
to be a better way".  (I have an innate repulsion to vacuous code,  
but I'm old-fashioned that way :)  So I turned to our good friend  
java.util.Map for inspiration (who needs types when you have a  
cons!).  Why not define leverage a Map<String, Object>, and define a  
contract for what the structure of the map needs to be -- what tags  
are associated which what values, which entries are required, vs  
which are optional.  Hey, they might even be able to be recursive  
structures, if that's not too difficult for consumers to manage.  The  
idea is that the data contract is all documented somewhere, so the  
producers and consumers of the information just need to consult the  
docs for the expected behavior.

This has the advantage that we don't have to hand-write all these  
structs, which are nothing but a collection of accessors and  
mutators, results in fewer types, and in general just seems a lot  
cleaner to me.  (I suppose if we could *codegen* these structs, then  
that would be an advantage, but I'm not sure if you can codegene  
structs from schema, where the objects stored on the structs are  
native Java objects.)

I realize that the Message type is a lot like this (it implements  
Map<String, Object>), but the semantics of "Message" are probably not  
appropriate for this use.  Perhaps this new type could be a base-type  
for Message, so that it has better visibility/use in CF as a whole.   
Then a Message would extend this type, which it may also contain.   
Nothing like confusing our users! :)

Anyway, do folks see this as a potentially valuable addition to CXF?   
Either way, I need the information from the transport.  I think it  
just boils down to how we want that information to be represented.

Thanks,
-Fred

Mime
View raw message