[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