« First there was sliced bread - now Axis2 :) | Main | [ANN] [Axis2] Axis2 1.0 Released »

AXIOM - Thanks Elliotte

Elliotte,

Thanks for the feedback on AXIOM. We have enormous respect for your work and am i have been an avid follower of your Cafe Con Leche and Cafe Au Lait for years now. I personally tried to contact you way back in Oct, 2002 about Axis 1.0 Release and got promptly snubbed. The emails you sent me privately will remain private. No need to bring them up again :)

Let's switch to the topic of interest now.

- Duly noted and agreed to the subtle distinction on phrasing for XOP/MTOM in our announcement. Very few of us are native English speakers.
- "The Axiom API itself is too complex". Please see the Goals, Use cases and Requirements from our *OLD* wiki pages, we ask for too much from AXIOM w.r.t usage when developing web services.
- The specific example you picked, the need for using a factory is because we wanted to be able to plugin a link list implementation or a array backed implementation and hence we used a factory.
- I've created a bug report (WS-COMMONS-18) for the "use relative namespace URIs" issue.
- Please give us a pointer to the locations where you found "Incorrect white space handling, and some serious mistakes with encoding detection" and we will fix it. Easiest way is to open a JIRA issue here.

Now let me give u the spiel from our end:
- AXIOM operates at various levels. Our Nightmare scenario is having to build the whole tree from the incoming stream.
- AXIOM can give you an XMLStreamReader which is a composite of already built nodes as well as the original stream which is still unread. Xerces can't do that!.
- Please see the following bug report (AXIS2-533) for a detailed analysis of the speed comparison between DOM4J, JDOM, Xerces2 and AXIOM in our *NIGHTMARE* scenario. Some performance charts are here. Please click on all 3 sheets tabs at the bottom.
- Since we do so well in our *NIGHTMARE* scenario, obviously we do much better in the scenarios where we dont' need/have-to build the whole tree.
- We have build a SOAP1.1 object model, a SOAP1.2 object model, a DOM3 object model and a SAAJ object model on top of the underlying llom (Linked List) implementation with minimal overhead in terms of performance.
- We have integrated XmlBeans which is stax based as our databinding in Axis2, we also have our own native databinding called ADB. We have gotten AXIOM to work even with JaxMe using a SAX Bridge. There is support for JAXB 2.0 in the works. So as u can see AXIOM was built specifically to be able to work with existing data binding tools.
- If you look at the OMDataSource, you can plug-in your own data binding with zero effort and make it work seamlessly with AXIOM
- Guess what? You can build a Servlet endpoint for accepting SOAP messages with MTOM attachments using just AXIOM and nothing else.

Thanks for listening.

TrackBack

TrackBack URL for this entry:
http://blogs.cocoondev.org/MT/mt-tb.cgi/3124

Comments

Elliotte,
Thanks a ton for the feedback.

Team,
After a few iterations off-list with Elliotte, here's the list of
problems and resolutions.

- OMTutorial's examples show prettified output : FIXED (updated site
with non-pretty output)
- Using FileReader in OMTutorial is bad practice as it causes problems
with non UTF-8 xml documents : FIXED (used FileInputStream instead of
FileReader)
- Warn/Throw error when users use relative namespace URIs : (Created
an issue - WS-COMMONS-18 [1]). We need to decide how to handle this.

Thanks,
dims

[1] http://issues.apache.org/jira/browse/WSCOMMONS-18

Post a comment