[wsf-c-dev] AXIOM NG
James Clark
james at wso2.com
Fri Dec 8 06:57:56 PST 2006
> > I forgot to ask one question. Suppose we implemented an AXIOM NG along
> > the lines of what I suggested. How hard would it be to adapt the rest of
> > the code base to use this?
> >
> IMHO, it would not be that hard as long as we can figure out how to map
> the current OM tree traversal mechanisms to the semantics in the new model.
There's not a straightforward mapping. It's a different way of doing
things.
> Just to give an indication on how we use AXIOM now,
> AXIOM_NODE_GET_DATA_ELEMENT is the most frequently used call.
That should become a no-op. It's an artifact of the way you implement
inheritance.
> The next
> in line in terms of frequency are AXIOM_NODE_GET_FIRST_CHILD,
> , AXIOM_NODE_GET_NODE_TYPE, AXIOM_NODE_TO_STRING and
These you would handle by creating an xml_reader over the xml_element.
> AXIOM_NODE_ADD_CHILD
> AXIOM_NODE_SERIALIZE.
These you would handle using an xml_writer.
> There are two main uses of AXIOM in the current Axis2/C engine:
> 1. Parse config files
> 2. Process SOAP messages
> For case one, USE_ONCE would almost always work, as we just need to pick
> parameters and then forget about OM. There could be very few cases where
> we would want keep the stuff in AXIOM format (Kaushalye, do we do that
> for security parameters?)
For a config file, you would parse it using an xml_reader. For any
element that you need to keep around as XML, you would ask the
xml_reader to read the rest of the element and give it you as an
xml_element.
> However, SOAP
> body would be USE_MANY most of the time.
Why? If you're signing I guess it would have to be USE_MANY (unless we
can find some clever way to avoid this), but apart from that, I would
thought it would typically be USE_ONCE; it would up to the application
to make it USE_MANY if it needs to. What does the SOAP engine need to
do with the body apart from signing/encrypting? I guess you sometimes
need the name of root element of the payload for dispatching. What
else?
James
More information about the Wsf-c-dev
mailing list