[Design of JBoss ESB] - Re: Overview of Messages in 4.0
by mark.little＠jboss.com
Until Messages need to be transmitted between address spaces, they are internally represented as Java objects. However, at some point, some form of externalisation of the Message is required. Typically this is part of the normalization process for messages.
We don't support a single external format for Messages. Rather, we provide support for an arbitrary number of them and give two specific instances out-of-the-box.
You get a message of a specific type when you need it from a Message Factory. Obviously that type may not be suitable for the service (hopefully you've got that contractual information a priori, but maybe not) and in which case some translation/transformation may be necessary.
Types of Message externalised representations are uniquely identified (URIs). MessagePlugin is used to plug in new message formats dynamically. Each plugin is responsible for returning a message implementation that knows how to externalise its state in a specific manner, e.g., XML or ASN.1.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975451#3975451
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975451
19 years
[Design of JBoss ESB] - Overview of Messages in 4.0
by mark.little＠jboss.com
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#3975450
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975450
19 years