Stax while giving better performance and control may also mean that we underestimate the effort needed to implement the stax parsers. Also the error handling has to be done by the stax parsers (which may be implicitly provided by JAXB processing).
Schema validation in the stax world can be performed using JAXP.
XML Signature/Encryption work on DOM representation of the xml message. So to cater to xml security, one of the representations has to be DOM.
I feel that we should retain our current structure:
- Message appears on the wire. We parse as document (DOM). Then apply xml dsign and enc operations on it. Then convert the dom model/original message to an object model using stax.
- We are sending a response back to requestor. We have the object model. Build a DOM structure. Apply xml security as needed. Then send the DOM message on the wire.
Further work has identified:
(08:41:59 AM) anil: stefan: the SAML object model is very very large which means that we have to reuse the JAXB object model for SAML. We do stax parsing but the JAXB object model. For wst, we can just use your wrappers. (08:42:36 AM) stefan: anil: I see, so you want to reuse the JAXB objects when parsing with Stax (08:43:21 AM) anil: stefan: for saml yeah. it is just too large. (08:43:39 AM) anil: stefan: maybe eventually we can build an object model for the saml specs in parallel. (08:44:05 AM) stefan: anil: what about WS-T? do you think we can replace the object model? (08:47:05 AM) anil: stefan: u have wrapper classes, that should be fine for now. the stax parsing will call ur wrappers. (08:48:08 AM) stefan: anil: I have wrappers for the most complex classes, those with Any elements that accept a large number of options (09:07:25 AM) anil: stefan: if we need anything more, we can add it to the wrappers.