I am new to EAI and read that there are 2 ways to achieve EAI
1) Broker/ hub-spoke model 2) ESB
Is broker model a JMS?
I worked on Spring-integration which is lightweight ESB so have some Idea how ESB works.
But not sure about Broker model
Anyone who can ellaborate Broker model and how to implement it.
Thanks in advance
Regards Ramandeep S.
A Broker or hub and spoke is a integration pattern based on a centralized middleware.
And yes, JMS is an implementation of this pattern. See this:
Integration Hubs
... When translating the concept of hub and spoke to the world of integration it is useful to have a closer look at what a connection between two systems really entails, i.e. what does the line between two boxes really represent? In some cases, the line might be a message queue, in other cases it might be a publish-subscribe topic or in yet other cases it might be the URI. So depending on the system, having a lot of lines might now immediately a problem. While it sure would be a pain to setup a lot of message queues, publish-subscribe topics and URI's are largely logical concepts and having a lot of them night mean a bit more maintenance but is unlikely to be the end of the world.
But the Hub-and-Spoke architecture also provides another significant benefit -- it decouples sender and receiver by inserting an active mediator in the middle - the hub. For example, this hub can perform the important function of routing incoming messages to the correct destination. As such, it decouples the sender of the message from having to know the location of the receiver. Having all messages travel though a central component is also great for logging messages or to control message flow. The Hub-and-Spoke style applied in this manner is commonly referred to as Message Broker because the hub brokers messages between the participants.
Data Format Considerations
A Message Broker should also include a protocol translation and data transformation function. For example, a message may arrive via a message queue, but has to be passed on via HTTP. Also, location transparency is only an illusion unless data format translation is also provided. Otherwise, a change in the destination (i.e. a request in form of a message is now being serviced by another component) is very likely to require a change in the message data format. Without a Message Translator in between, the message originator would also have to be changed. Therefore, the implementation of this type of Hub-and-Spoke architecture typically includes data format translation capabilities.
