A SOAPMessage object consists of a SOAP part and optionally
one or more attachment parts. The SOAP part for a SOAPMessage
object is a SOAPPart object, which contains information used
for message routing and identification, and which can contain
application-specific content. All data in the SOAP Part of a message must be
in XML format.
A new SOAPMessage object contains the following by default:
SOAPPart sp = message.getSOAPPart();
SOAPEnvelope se = sp.getEnvelope();
SOAPBody sb = se.getBody();
SOAPHeader sh = se.getHeader();
In addition to the mandatory SOAPPart object, a SOAPMessage
object may contain zero or more AttachmentPart objects, each
of which contains application-specific data. The SOAPMessage
interface provides methods for creating AttachmentPart
objects and also for adding them to a SOAPMessage object. A
party that has received a SOAPMessage object can examine its
contents by retrieving individual attachment parts.
Unlike the rest of a SOAP message, an attachment is not required to be in
XML format and can therefore be anything from simple text to an image file.
Consequently, any message content that is not in XML format must be in an
A MessageFactory object may create SOAPMessage
objects with behavior that is specialized to a particular implementation or
application of SAAJ. For instance, a MessageFactory object
may produce SOAPMessage objects that conform to a particular
Profile such as ebXML. In this case a MessageFactory object
might produce SOAPMessage objects that are initialized with
In order to ensure backward source compatibility, methods that are added to
this class after version 1.1 of the SAAJ specification are all concrete
instead of abstract and they all have default implementations. Unless
otherwise noted in the JavaDocs for those methods the default
implementations simply throw an UnsupportedOperationException
and the SAAJ implementation code must override them with methods that
provide the specified behavior. Legacy client code does not have this
restriction, however, so long as there is no claim made that it conforms to
some later version of the specification than it was originally written for.
A legacy class that extends the SOAPMessage class can be compiled and/or run
against succeeding versions of the SAAJ API without modification. If such a
class was correctly implemented then it will continue to behave correctly
relative to the version of the specification against which it was written.