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 communication paired with service level guarantees (reiability etc) need a mediating element aka broker to deliver this capability :-). Ain't no way around it... 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 > ----- --- Ashwin Karpe, Principal Consultant, PS - Opensource Center of Competence Progress Software Corporation 14 Oak Park Drive Bedford, MA 01730 --- +1-972-304-9084 (Office) +1-972-971-1700 (Mobile) ---- Blog: http://opensourceknowledge.blogspot.com/ -- View this message in context: http://www.nabble.com/EIP---Message-Broker-Pattern-tp25676225p25706980.html Sent from the Camel - Users mailing list archive at Nabble.com.
