The message format

[marklittle]

The core of JBossESB is a messaging abstraction which supports multiple implementations. Most remote communication mechanisms expose their functionality in their interfaces, e.g., by requiring users specify timeout and retry values when constructing the message to be sent. Therefore, designing a messaging abstraction which (dynamically) supports multiple implementations requires selecting an appropriate interface that does not implicitly bind an application to a specific implementation.

An important first step in that direction is to get the message interface right. Within the architecture, there are probably going to be two representations of the message:

? The message that the client/service uses, which is XML based, but the structure of which is outside the scope of JBossESB (it's a payload afterall).

? The message the ESB core uses internally, which is also XML based.

The core ESB message consists of a header, a context and a body, and is shown below:

interface Message
{
public Header getHeader ();
public Context getContext ();
public Body getBody ();
public Fault getFault ();
public Attachment getAttachment ();
}

The header consists of unique message identifier and any necessary routing information. The context consists of information such as transactions, security, etc. Clients and services work in terms of the XML Body component of this message. The rest of the Message is formed by a combination of the plugins and the ESB core.

[schrouf]

Should versioning information be part of the header (versioning as general part of service routing/location) or the body part (versioning as service specific internal feature) ?

[marklittle]

That depends on whether you want to handle it at the application level or as part of the infrastructure.

By the time you get to the on-the-wire message format (with headers, context and body), you'll have translated any logical way in which to reference the service (e.g., "JBoss UDDI") to a physical representation (e.g., http://www.jboss.com/services/durable?UDDI, plus some additional information as mandated by WS-Addressing). If you want the infrastructure to handle the versioning of services, then it will have interceded by this point and ensured that the physical endpoint reference (EPR) points to the right version. Hence, it'll be handled transparently to the message and implicitly within the header.

Now you could handle versioning yourself. Have the same EPR for services indirect to other services on a per message basis: think multiplexing and demultiplexing. In which case, one way you could do this would be to encode some version information within the body, or you could handle this in some other way, outside of the ESB, e.g., by having users of services register their endpoints with your demultiplexer and it switches between real service EPRs based purely on the wsa:From field (so again, it'd be in the header).

Hope this helps.