[Axis2] tomorrow chat and my take on AXIOM [Re: [Axis2] OM

[Aleksander Slominski <as...@cs.indiana.edu>]

Dennis Sosnoski wrote:

> BTW, the XBIS code also contains timing test implementations so you 
> can see how long it takes to parse a document directly, to parse to 
> the XBIS event store, and to replay the parse from the event store (as 
> well as the document format tests that are the main focus of XBIS). It 
> only supports SAX parser comparisons at present (and SAX parse event 
> stream replay) because that was what I wanted to test against (most 
> widely used, and also the only form supported by the JAXP transform 
> for generating output document text).

i will take a look on XBIS on context of AXIOM and I will also look on 
minimizing memory footprint and reuse such as OMNamespace and directly 
using String as children of OMNode - that should not be too difficult if 
java.util.List as it is very flexible (LinkedList and ArrayList) and 
well tested storage mechanism.

one of the remaining OM API issues is how API to expose SOAP:Body stream 
should look and what we want to do to support MTOM (i look on it as high 
priority) and SAAJ/JAXM (i think it must be layered and not backed into 
AXIOM ...)

thanks,

alek

>
> Dennis Sosnoski wrote:
>
>> Aleksander Slominski wrote:
>>
>>> Dennis Sosnoski wrote:
>>>
>>>> First off, if you really want to keep performance high then I urge 
>>>> you not to build a model. I'd instead suggest something like a 
>>>> parse event store that you can replay on demand using StAX, SAX, or 
>>>> custom APIs. ...
>>>
>>>
>>>
>>>
>>> XmlBeans uses model too (DOM2 like store). it would be interesting 
>>> to see independent performance results including memory footprint
>>
>>
>>
>> I've been meaning to run a test (and include .NET's data binding in 
>> hopes of getting permission to show the results - I think there's 
>> been some legal changes that mean they'll be removing their 
>> restrictions in the future). Hopefully I'll get this done in the next 
>> couple of weeks.
>>
>>>
>>>>
>>>> I've also implemented a simple parse event store for my XBIS 
>>>> project (http://www.xbis.org - the parse event store is currently 
>>>> designed around SAX, and can be found in the eventstore package 
>>>> http://xbis.sourceforge.net/api/index.html). This gave excellent 
>>>> performance (I think replaying the event stream at least 10X parser 
>>>> speed) at a resonable memory cost (about 2X the actual size of the 
>>>> document text for the cases I looked at) without much work on 
>>>> optimization. Working with even an efficient document model is 
>>>> likely going to be both considerably slower and considerably 
>>>> heavier in memory usage.
>>>
>>>
>>>
>>>
>>> i think that is what we try to do but optimized for SOAP where SOAP 
>>> headers are kept in memory and accessible in whatever API is 
>>> needed/standard such as DOM, SAAJ, etc. - we have to optimize for 
>>> this common case however SOAP body can be retrieved by app directly 
>>> as event stream if required.
>>>
>>> currently thinking is around using SAX, StAX, XPP streams but having 
>>> even more optimized stream should only make things better :)
>>
>>
>>
>> Both Srinath's reply and this one clarified this for me. I guess I'd 
>> taken the discussion of a "model" too literally and not looked into 
>> the details of the implementation. Sounds like you're heading in a 
>> good direction (including with the OMNamespace)!
>>
>>>
>>>> If you actually designed a parse event stream interface rather than 
>>>> working with either SAX or StAX you could probably push the 
>>>> efficiency even higher (in other words, use the event store as an 
>>>> adapter between the parser and your own internal event stream API).
>>>
>>>
>>>
>>>
>>>
>>> if you have done all hard work then i see why not try to use it :)
>>>
>>> what is the license for your API/source code? can it be included in 
>>> AXIS2 (either in OM core or as optional component)?
>>>
>> My code's BSD in any case, but I'd gladly donate it to the project if 
>> you think it's useful. The code's in the download and also in 
>> SourceForge CVS from the project site (http://www.xbis.org). I wasn't 
>> referring to my code in particular as the event store, though.
>>
>> Except for the namespace issue I think the XMLPull API is great for 
>> working with this type of store. If you'd extend the XMLPull API to 
>> use namespace objects (which I'd love to see) you could use that 
>> directly. I don't know about StAX - certainly the object API version 
>> is going to add a lot of  overhead, and I don't know the details of 
>> how the StAX low-level API differs from XMLPull.
>>
>>  - Dennis
>
>


-- 
The best way to predict the future is to invent it - Alan Kay