We've already had some discussion about Messages here
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=77546[/url] and
[
url]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.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975450#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...