MQ is a message middleware, MB is an ESB product, and MQ is responsible for transferring messages between two systems. These two systems can be heterogeneous, in different hardware, different operating systems, and written in different languages, and only need a simple call Several MQ APIs can communicate with each other, and you do not have to consider the complexity of the underlying system and network. As a flagship product of IBM, although the function looks very simple, it is a message queue, but it is the core of IBM middleware, and it is also an advantage compared to other manufacturers (such as BEA). MQ not only has high performance, but also supports various platforms very well. Almost every hardware and operating system platform and programming language you can think of, MQ has dedicated API support.
However, the function of MQ is limited to the message queue. As for the format of the message sent by application A to application B, and whether it can be parsed by application B, MQ can't control it, he just tries his best to send the message to the destination (MQ can handle a variety of exceptions circumstances, such as network congestion, temporary outages, etc.). In addition, if the number of applications is large, MQ connections must be established between each other, and the network topology will become a spider web (like the original telephone system)
Therefore, we introduce the star topology of the network into the system architecture, and replace the one-to-one MQ with a central node, namely ESB, and MB is IBM's ESB product.
The MB is at the center of the system and acts as a bus. All applications are directly connected to the MB, rather than directly interconnecting between applications. This benefit is self-evident and can greatly reduce the coupling between applications. This leads to the two core functions of MB: message routing and data conversion. Because each application is inserted into the MB, application A just throws the message to the MB, and the MB automatically determines who to give the message to based on the message fields and business logic. route to the corresponding address. The internal business logic of MB is set by developers. Of course, using MB Toolkit, writing business logic is also very simple: drag some nodes and connect them with arrows, just like drawing a flowchart, which is very simple and vivid. Then use MB's scripting language (similar to sql script) to realize logical judgment. In layman's terms, it is to judge which logical branch to go (if...else...). But how does each application connect to MB? MB provides three ways: MQ, file and web service
The MQ mode is to use MQ to connect the MB to the application; the file mode is to specify a certain directory, and the MB will automatically monitor that file directory. Once the file changes, it will be considered as a new message, and the MB will automatically read the contents of the specified file; The web service does not need to be explained, and uses the web service to communicate directly. MB supports these interconnections to maximize compatibility, especially for legacy systems or systems that do not support mainstream communication methods
Finally, let's talk about a more partial ESB product: websphere ESB. Not many people have heard of it, because IBM has not promoted it in China. This WESB is very similar to the simplified version of MB. It only supports a few J2EE communication methods such as JMS and WS, so it is specially prepared for J2EE. Unlike MB, it supports dozens of platforms and communication methods, such as FTP, and even many ancient communication protocols that you have never heard of. The performance of the two is quite different, and the price is also three or four times the difference. What's worse is that things originally developed on WESB cannot be migrated to MB. IBM seems to be determined to slaughter us. The only way is to buy another MB, and then use MQ to connect WESB and MB. , each run its own.