4.2.29. Advice on Serializing Messages

Although each enterprise service bus component treats every message as a collection of Java objects, you will find it is often necessary to serialize these messages. Do so when:
  • the data is to be stored
  • the message is to be sent between different ESB processes
  • you are debugging.
The JBoss Enterprise SOA Platform does not impose a single, specific format for message serialization because requirements will be influenced by the unique characteristics of each deployment. You can obtain the various implementation of the org.jboss.soa.esb.message.Message interface from the org.jboss.soa.esb.message.format.MessageFactory class:
  public abstract class MessageFactory
{
	public abstract Message getMessage ();
	public abstract Message getMessage (URI type);
	public abstract void reset();
	public static MessageFactory getInstance ();
}
Uniform resource indicators uniquely identify message serialization implementations. Either specify the implementation when creating a new instance or use the pre-configured default.
There are two serialized message formats, JBOSS_XML and JBOSS_SERIALIZED.
MessageType.JBOSS_XML
This implementation uses an XML representation of the message. The schema for the message is defined in the schemas/message.xsd file. Arbitrary objects may be added to the message: in other words, they do not have to be serializable. Therefore, it may be necessary to provide a mechanism to marshal and un-marshal such objects to and from XML when the message needs to be serialized. Do this through the org.jboss.soa.esb.message.format.xml.marshal.MarshalUnmarshalPlugin:
          public interface MarshalUnmarshalPlugin
{
	public static final String MARSHAL_UNMARSHAL_PLUGIN =
				 "org.jboss.soa.esb.message.format.xml.plugin";
	public boolean canPack(final Object value);
	public boolean marshal (Element doc, Object param)
											throws MarshalException;

	public Object unmarshal (Element doc) throws UnmarshalException;

	public URI type ();
}
MessageType.JAVA_SERIALIZED
This is the default. This implementation requires that every component of the message be serializable. It also requires that the message recipients have sufficient information (via the Java classes) to be able to de-serialize it. Its URI is urn:jboss/esb/message/type/JAVA_SERIALIZED.
It uses an XML representation of the message. The message's schema is defined in the schemas/message.xsd file. Its URI is urn:jboss/esb/message/type/JBOSS_XML.
It also requires that all of the contents be Java-serializable. Any attempt to add a non-serializable object to the message will result in an IllegalParameterException error.
Its URI is urn:jboss/esb/message/type/JAVA_SERIALIZED.

Important

Be wary about using the JBOSS_SERIALIZED version of the message format because it can tie your applications to specific service implementations.
You can provide other message implementations at runtime through the org.jboss.soa.esb.message.format.MessagePlugin:
    public interface MessagePlugin
{
	public static final String MESSAGE_PLUGIN =	
						 "org.jboss.soa.esb.message.format.plugin";
	public Object createBodyType(Message msg, String type);
	public Message getMessage ();
	public URI getType ();
}
Each plug-in must uniquely identify the type of message implementation it provides (via getMessage), using the getType method. Plug-in implementations must be identified to the system via the jbossesb-properties.xml file. (Use the property names that have the org.jboss.soa.esb.message.format.plugin extension.)