camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tnabil <>
Subject Re: EIP - Message Broker Pattern
Date Mon, 05 Oct 2009 13:52:58 GMT

Thanks, Ashwin, for your response.

It's exactly the federated approach (what you referred to as a network of
brokers) that I'm interested in.

In particular, how are the channels (or virtualized services for all that
matters) structured? Are they replicated across all the brokers in the

If yes, should the different brokers manage the routing among them
automatically? Do the current products in the market support that?

Ashwin Karpe wrote:
> Hi,
> Yes, a Message Broker has several responsibilities that can get difficult
> and unwieldy to manage as demands on the broker grow.
> The Message Broker not only has to manage channel lifecycles, message
> routing, message persistence in case App2 does not consume messages at the
> rate App1 sends messages etc. These demands if not carefully measured for
> performance degradation can cause a message broker to reach a point of
> diminishing returns. It is more effective to split the broker at his point
> into a network of cooperative brokers that take bring the problem back
> under control by improving scale and delegating processing, management and
> client support responsibilities to other brokers in the network.
> The interesting fact is that any communication paradigm that has need for
> asynchronous transport paired with service level guarantees (reliability,
> message expiry etc) need a mediating element aka broker to transparently
> deliver this capability :-). 
> Ain't no way around it... Any attempt to change this simply forces
> synchrony and complexity into the transport layer. %-|
> Cheers,
> Ashwin...
> tnabil wrote:
>> Hi,
>> As agreed, I'm prefixing the title of this post with "EIP" to denote that
>> it's a general post on Enterprise Integration Patterns (not Camel
>> specific).
>> Message Broker is one of the patterns described in the EIP book. I
>> believe that this pattern is also the basis of ESB products currently
>> being marketed by most vendors. From the EIP site, I quote:
>>> Use a central Message Broker that can receive messages from multiple
>>> destinations, determine the correct destination and route the message to
>>> the correct channel. Implement the internals of the Message Broker using
>>> the design patterns presented in this chapter.
>> In the book, the author admits that the usage of this pattern may result
>> in a bloat in the amount of functionality implemented inside the broker
>> and suggests a federated approach to solve this problem.
>> Nevertheless, I found the treatment of this federated approach to be very
>> thin.
>> For example, if an application App1 is connected to broker B1 and needs
>> to send a message of type M2 which is handled by an application App2
>> connected to broker B2, then how are the different channels configured to
>> support this?
>> Does there need to be a channel on B1 which will accept messages of type
>> M2 and then B1 would route it to B2 which would in turn route it to App2?
>> Wouldn't that mean that each broker would need to have channels for all
>> messages which are sent by applications connected to it to other
>> applications connected to other borkers? Wouldn't that have an impact on
>> the number of channels, the amount of routing configuration and the
>> managability of the solution?
>> Or is it that a borker would have a single channel which is not a
>> Datatype Channel and all applications connected to it would send all
>> messages to this channel and then the broker would determine whether
>> they're to be routed to an application connected to it or through another
>> broker? Wouldn't that make the required routing conifguration for this
>> channel quite complex?
>> Isn't that why most people find ESB implementations to be bloated?
>> Wouldn't the broker in general become a single point of failure for all
>> applications connected to it?
>> Is there a better approach for implementing this pattern? Has anyone
>> covered this topic in more detail?
>> I'd appreciate your thoughts on the subject.
>> Thanks,
>> Tarek Nabil

View this message in context:
Sent from the Camel - Users mailing list archive at

View raw message