WSIF API reference: Creating a message for sending to a port

For message management (that is, message construction and parsing) the underlying API is modeled on WSDL semantics. There is a simple and direct mapping from the WSDL model to WSIF classes.

In WSDL, a Message describes the abstract type of the input or output to an operation. The corresponding WSIF class is WSIFMessage, which represents in memory the actual input or output of an operation. A WSIFMessage is a container for a set of named parts. The WSIFMessage interface separates the actual representation of the data from the abstract type defined by WSDL. WSDL defines Messages as XML Schema types. There are two natural ways to represent a WSDL message in a runtime environment:

• The generated Java class based on a WSDL to Java mapping such as that provided by JAX-RPC.
• The XML representation of the data, for example using SOAP Encoding.

Each option offers benefits in different scenarios. The Java class is the natural approach when WSIF is being used in a standard Java client. However, in other scenarios where WSIF is being used in an intermediary, it may be more efficient to keep a WSDL Message in the SOAP encoded format.

The style used to define messages must be consistent within the message, so all the parts in one message must be consistent. A string - getRepresentationStyle() - always returns null. This indicates that parts on this WSIFMessage are represented as Java objects.

Parts are added to a WSIFMessage with setObjectPart or setTypePart. Each part is named. Part names within a message are unique. If a part is set multiple times, the last time is the one that stands.

Parts are retrieved from a WSIFMessage by name with getObjectPart or getTypePart. If the named part does not exist, the getXXXXPart method returns a WSIFException.

Parts can be retrieved from the Message by use of Iterators through the getParts() and getPartNames() methods.

The order in which parts are set is not currently important, but the Message implementation may be more efficient if the parts are set in the parameter order specified by WSDL.

WSIFMessages are cloneable and serializable. If the parts set are not cloneable, the implementation should try to clone them using serialization. If the parts are not serializable either, then a CloneNotSupportedException will be thrown if cloning is attempted.

WSIFMessages can be sent between JVMs.

In addition to the containing parts, a WSIFMessage also has a message name. This is required for operation overloading - which is supported by WSDL and WSIF.

Here is the Javadoc for the WSIFMessage interface.