New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
SAAJ - Fine in Theory, Broken in Practice?
Posted by Stefan Tilkov on May 19, 2008
SAAJ, the SOAP with Attachments API for Java™, is the standard API used by Java Web services developers to work directly with a SOAP message. Since version 1.2, the SAAJ javax.xml.soap interfaces extend the appropriate DOM interfaces, enabling developers to use standard JAXP processing to create or work with an XML payload that is sent or received using SOAP.
Unfortunately, many application servers seem to support SAAJ 1.2 only half-heartedly. Spring Web Services lead developer Arjen Poutsma has written a small test that uses SAAJ to create a SOAP message and DOM to create the body, and Geronimo, JBoss, OC4J and Weblogic all failed to process it correctly (see Arjen’s blog post for the table with details).
Developers who prefer to work with XML directly instead of relying on a databinding technology (such as JAXB, XMLBeans or Castor) have a wide variety of choices in terms of which XML API they want to use (including JDOM, XOM, dom4j, or the Axis2 Axiom library). Sadly, the only one of these that is standardized is DOM, which apart from being cumbersome to use does not provide the portability one would expect in this case.
What is your preferred way to work with SOAP messages in Java? Did you run into the problem Arjen describes?
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
No comments
Watch Thread Reply