I'm trying to pick up the discussion of the edge pipe designs.
- StreamBasedMessage. Paul suggested that we should parameterize
Packet with the actual message type 'T' (where T could be things
like Message or StreamBasedMessage), but because Packet is highly
visible, I'd like to keep it as is.
The current StreamBasedMessage.properties works (except that
it's ugly, since its message field will always be empty.)
- XMLStreamReaderMessage processStreamReader(Packet packet) makes sense,
as a Message is an XML infoset anyway, but I'm not sure about the
versions that take InputStreamMessage.
The first concern is that this breaks the encoder pluggability. At
least we need some negotiation phase so that the security pipe (SP)
can check if the encoding in use is really what it supports.
Also, I'm convinced enough that going down to the infoset level would
give a performance improvement to SP, but I'm not so convinced about
going down to the stream level. I mean, it seems like SP needs to be
fairly sophisticated to use this correctly. You'd have to produce the
UTF-8 encoded canonical text for the signed portion, keep it on the
side, compute the digest as a filter, then produce headers, then the
buffered body. Is the security team really committed to do this?
If they aren't planning to do so right away, we can always defer this
until it's necessary.
Lastly, using InputStreamMessage seems to imply that SP is going to
cache the whole message in memory (unless SP is very smart and
implement the whole logic inside out in a InputStream class.) Is that
what's planned, or am I missing something?
Instead, wouldn't it be better for the ClientEdgePipe to give SP
a XMLStreamWriter to write to (thus conceptually set the layer to
the infoset layer, not below)?
XMLStreamWriter would then expose a hint that it's writing to UTF-8
OutputStream in a plain XML (or perhaps also MTOM), and then SP
can switch to write to OutputStream directly. We can use this for
JAXB, too.
I think this is cleaner in the sense that I'm only breaking the
abstraction one at a time (instead of going straight from Message
to stream), and each short-cut is usable for other things.
- I think similar thing applies to ServerEdgePipe, but let's settle on
ClientEdgePipe first, and we can just apply the same design to SEP.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com