Kohsuke Kawaguchi wrote:
>
> 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.
>
But i thought that was what generics were for :-) from the developer POV
there is no change.
If we stay with the existing approach it is necessary to duplicate all
the functionality in Packet? or can it be a subset?
> 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?
>
Some of this has already been implemented in SAAJ and gives a boost.
The key is to avoid two serializations of what is signed. When using
crypto-hardware to produce the digest i think this will be quite effective.
> 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?
>
My presumption was that the whole message would be cached based on the
case of WCF where signing of all headers and body i.e. most of the
message requires signing.
> 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.
>
Yes, i think that would be better. It is easier to get the hint of when
to go to the encoding.
Shall we add such a method(s) to XMLStreamWriterEx?
>
> - I think similar thing applies to ServerEdgePipe, but let's settle on
> ClientEdgePipe first, and we can just apply the same design to SEP.
>
Yes, essentially the reverse direction.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109