To me, the primary goal of an ESB is to provide a powerful, scalable, and easily extensible integration backbone.
“Integration” here means between end-points, applications, trading partners, etc… The basic premise is that you can throw a message at the ESB happens, and somehow that message finds its way to the correct endpoint(s), perhaps with a protocol hop or transformation occurring along the way, and maybe with a business process or two being invoked. In other words, throw a message at the ESB, and magic happens.
But, this is software, and there is no magic in software.
In order for us to process a message, we need to know what has to happen to it, which means we need some data (hereinafter: metadata) associated with the message that defines how a given message will move through the ESB.
Conceptually, you can think of this as an “envelope” for ESB messages. However, I am reluctant to use that term because it has different connotations for BizTalk developers. So, let’s just say “metadata”.
There are three ways I can think of (there are certainly more, but none I seriously considered) to potentially associate metadata with a message:
- Use an external metadata store
- Use context properties
- Use a multipart message
Let’s look at each option….
External Metadata store
Concept: Steps that happen are stored in some external store such as SQL Server, a controlling assembly, an XML document, etc.
I don’t like this and didn’t seriously consider it. You could do this, have a table somewhere that defines what to do with messages, but this just “feels” wrong. That information is related to a given message, and should travel with it as a message moves through the system. Consider: how would you version this? What about the latency you’d inject into the process as you look up what needs to happen? The more you think about what needs to be done, the more work and problems it starts sounding like. So, this was not a serious contender. This approach could work if the same set of properties were applied to all messages of a given type (think: “class variables”), but, in our ESB, we want a set of properties to be associated with each individual message (think: “instance variables”). Nice idea, wrong place to use it.
Using Context Properties
Concept: create our own message context properties that travel with a message through the ESB
This is how BizTalk does it. Data can be “promoted” from the message into message context properties or “demoted” from context properties into the message body. Context properties travel with a message for its lifetime, until it leaves BizTalk.
Using Multipart Messages
Concept: use BizTalk multipart-messages (a message constructed of multiple [maybe] instances of multiple [maybe] schemas, clear?)
This is much the same as above. This is perfectly viable, and would work, although promotion/demotion would be a little bit more complicated. Benefit is that you wouldn’t run into the 256 character limit that promoted properties are subject to. However, to me, a significant disadvantage would be that anyone applying maps in the ESB would need to map to/from a multipart message, meaning they would need to be aware of the multipart message format. With context properties, this would be transparent to a map developer, and maps could potentially be re-used outside the ESB.
What I chose
In the end, I opted to go with the context property approach, following the lead of the BizTalk team.
<P class=MsoNormal style="MARGIN: 0in 0