Jim Murphy wrote:That's essentially what Axis is already doing at different points. AFAIK it's also the only way for handlers to modify *anything* about the message - get the DOM, tweak it, write it out as text, and force Axis to parse the text to replace the current document. Uglier than sin... (actually, I've known some pretty good looking sins, but that's another story).
Why wouldn't a very thin Axis working with several Java
binding/marshaling layers be a compelling approach?
Problem is, I have yet to see a SOAP stack that works this way. "Consuming one stream and producing another" implies that each intermediary node would potentially have to go from XML->Java->XML before the call got passed to another the next intermediary node. This would certainly allow each node to use it's own data binding schema - but think of the serialization performance hits!
Unfortunately, as Alek said, the design of the WS-Security stuff (and the underlying XML-Encryption & XML-Security) may force this type of processing approach for people using these features. Signing an entire message, for instance, requires converting the whole thing to canonical text form, running a digit signature algorithm on the text, and then plugging the signature back into the document. I think the engine Alek has discussed offers a lot of potential for handling such Rube Goldbergish standards. The main point is to make the stored parse event stream (or Infoset, or whatever) as efficient as possible to minimize the overhead, and hopefully design it so that users who avoid using the write-it-out-on-the-blackboard-and-take-a-polaroid-to-sign-and-send-to-me-type standards don't suffer from the performance hits.
- Dennis
Dennis M. Sosnoski Enterprise Java, XML, and Web Services Training and Development Support http://www.sosnoski.com Redmond, WA 425.885.7197
