We've already had some discussion about Messages here http://www.jboss.com/index.html?module=bb&op=viewtopic&t=77546 and http://www.jboss.com/index.html?module=bb&op=viewtopic&t=77533. The code for implementing most of this is now in the trunk.
A message consists of the following components:
Header: the header information contains information such as the destination EPR, the sender EPR, where the reply goes etc, i.e., general message-level functional information.
Context: additional information to contextualise the message; for example, transaction or security data, the identity of the ultimate receiver, or HTTP-cookie like information.
Body: the actual payload of the message.
Fault: any fault information associated with the message.
Attachment: any attachments associated with the message.
Properties: any message specific properties.
Each message, once created, has a corresponding element for these 5 components. That element may be empty (NOT NULL). The object representing the element can then be used to act on the corresponding data item in the message.
Messages may contain attachments that do not appear in the main payload body. For example, binary document formats, zip files etc. Handles both 'named' attachment and a list of 'unnamed' attachments.
The message body holds arbitrary information which represents the payload as far as clients and services are concerned. A body may contain:
(i) a byte array for arbitrary data. How that array is interpreted by the service is implementation specific and outside the scope of the ESB to enforce.
(ii) a list of Objects of arbitrary types. How these objects are serialized to/from the message body when it is transmitted is up to the specific Object type. The plan is to add support for various TYPES of Object and the message implementation will use external adapters to externalize/internalize the Objects. Currently we only support Serializable objects.
The context is the section of the message containing information such as session management, transaction information, security data etc. Entries in the context may be ordered.
Faults may be returned from a service in response to receiving and acting upon messages. A fault consists of a unique code (MANDATORY) and a reason string (OPTIONAL).
The message header. Contains such things as routing information.