Differences in SAAJ versions

The SOAP with Attachments API for Java (SAAJ) interface Version 1.3 expands the support of SOAP 1.2 messages in a web services environment. There are several differences between SAAJ 1.2 and SAAJ 1.3 presented in this topic.

In a typical web services environment, you rely on the underlying code based on Java standards to translate a set of Java objects. The SAAJ interface provides APIs to read, write, send and receive SOAP messages, and advocates binary content sent as an attachment to a SOAP message.

SAAJ 1.3 aligns with SOAP 1.1 and SOAP 1.2 messages and is supported by the JAX-WS programming model and the Java API for XML-Based RPC (JAX-RPC) programming model. SAAJ 1.2 works with SOAP 1.1 messages only.

If we migrate the code from SOAP 1.1 to SOAP 1.2, we can continue to use the existing SOAP 1.1 code, if the message is a SOAP 1.2 message. If we upgrade the base code to use SAAJ 1.3, then we can continue to use the existing code that operates on a SOAP 1.1 message. An example of these differences is in SOAP 1.1, where the human readable text of a fault is stored in the faultString element. In SOAP 1.2, the human readable text is stored in the Reason element. Your code might look like the following example:

String text = soapFault.getFaultString();

The getFaultString () returns the faultString value if the message is based on SOAP 1.1. If we are using SOAP 1.2, the getFaultString () returns the Reason value. In addition, the SAAJ 1.3 interface provides a new method, getReasonText (Locale), that gets a specific Reason value. The getReasonText (Locale) method returns a documented exception if the message is based on SOAP 1.1. The SAAJ 1.3 interface supports existing code to process both SOAP 1.1 and SOAP 1.2 messages.

Other differences between SAAJ 1.2 and SAAJ 1.3 are in the following list:

• SAAJMetaFactory interface

  The SAAJMetaFactory SPI is introduced to support creating SOAP factory classes in a single place.

• SAAJResult class

  The SAAJResult object acts as a holder for the results of a Java API for XML Processing (JAX-P) transformation or a JAXB marshalling, in the SAAJ tree. The SAAJResult class is introduced for improved usability when transformation results are expected to be a valid SAAJ tree.

• Overloaded methods that accept a QName instead of a Name

  It is preferred that a QName represents an XML-qualified name. Therefore, overloaded methods are introduced in all of the SAAJ APIs, where a corresponding method accepts a javax.xml.soap.Name name as an argument.

• New methods in AttachmentPart, SOAPBody and SOAPElement interfaces and classes

  Use these new methods to assist you when we are working with the new SOAP features.

• SOAPPart is now a javax.xml.soap.Node method.

  The SOAPPart object is now also considered to be a SOAP node method.

Related concepts

SOAP with Attachments API for Java interface

Web services specifications and APIs