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
