Introduction to ESB (Enterprise Service Bus)

This article mainly introduces some technical concepts and terminologies related to ESB, as well as some basic knowledge for getting started, and introduces some ESB products. As I was new to ESB, I recorded my learning content and processes! I would like to share with you the progress and improvement together!

[For more information, see http://blog.csdn.net/mahoking]

EAI

 

Enterprise Application Integration): It is a way, methodology, standard, and technology for sharing, exchanging information, and collaboration among various heterogeneous systems, applications, and data sources within and outside the Organization.
The connected applications include various e-commerce systems, enterprise resource planning systems, customer relationship management systems, supply chain management systems, office automation systems, database systems, and data warehouses. The principle of EAI is to integrate multiple systems and ensure that each system does not interfere with each other.

ESB

Enterprise Service Bus): Implemented by middleware infrastructure technologies, event-driven, and XML-based messaging engines, providing Software Architecture structures for complex service-oriented architectures.
The Enterprise Service Bus provides reliable message transmission, service access, protocol conversion, data format conversion, content-based routing, and other functions, shielding the physical location, protocol, and data format of the service.

MQ

Message Queue): It is a communication middleware product. This IBM product is called MQSeries and now webshpere MQ. Microsoft also has MSMQ products, but Microsoft products have platform dependencies. You all know! (. NET) and IBM has done a good job in this aspect. Most operating systems have versions.

MB

MB is websphere_message_broker.IBM's ESB (Enterprise Service Bus) product.

Introduction to MQ and MB

MQ is a message-oriented middleware and MB is an ESB product.
MQ is responsible for transmitting messages between two systems. These two systems can be heterogeneous, in different hardware, operating systems, and written in different languages. Only a few MQ APIs need to be called, you can communicate with each other without considering the complexity of the underlying system and network. As a fist product of IBM, MQ seems simple as a message queue, but it is the core of IBM middleware and an advantage over other vendors (such as BEA. MQ not only has high performance, but also has excellent support for various platforms. MQ has dedicated API support for hardware, operating system platforms and programming languages that you can think.
However, the MQ function is limited to message queues. As for how the message format sent by application a to application B can be parsed by application B, MQ cannot manage it, he only tries his best to send messages to the destination (MQ can cope with various exceptions, such as network congestion and temporary interruptions ). In addition, if the number of applications is large, MQ connections must be established between each other, and the network topology becomes a Spider Network (like the original telephone system ). Therefore, we introduce the star topology of the network into the system architecture, and replace one-to-one MQ with a central node, that is, ESB, and MB is the ibm esb product.
MB is at the center of the system and acts as a bus. All applications are directly connected to MB instead of directly interconnected between applications. This advantage is self-evident and can greatly reduce the coupling between applications. The two core functions of MB are introduced as follows: message routing and data conversion.
Because each application is inserted to MB, application a only throws the message to MB. MB automatically determines who to send the message based on the message field and business logic, like a router, this route the packet to the corresponding address based on the packet header. The internal business logic of MB is set by developers. Of course, using the toolkit of MB, writing business logic is also very simple: drag some nodes and connect them with arrows, just like drawing a flowchart, simple image. Use the MB script language (similar to the SQL script) to implement logical judgment. In other words, it is to determine which logical branch to take (if... else .....). But how are applications connected to MB? MB provides three methods: MQ, file, and Web Service.
The MQ method uses MQ to interconnect MB with applications. The file method specifies a directory, and MB automatically monitors the file directory. Once the file changes, it is considered as a new message, MB automatically reads the content of the specified file, and the Web service does not need to be explained. The Web Service is used for communication directly. MB supports these interconnection methods to maximize compatibility, especially for legacy systems or systems that do not support mainstream communication methods.
Finally, let's talk about a relatively biased ESB product: WebSphere ESB. There may not be many people who have heard of it, Because IBM has a small number of promotions in China. This wesb is like a MB Lite version. It only supports a few J2EE communication methods such as JMS and WS, therefore, it is specially prepared for J2EE. Unlike MB, it supports dozens of platforms and communication methods, such as FTP, and even many old communication protocols that you have never heard. The performance of the two is quite different, and the price is also three or four times different. What's even worse is that what was originally developed on wesb cannot be migrated to MB. IBM seems to be eager to kill us. The only way is to buy another MB, then, we use MQ to connect wesb and MB, and each of them runs separately.

 

[For more information, see http://blog.csdn.net/mahoking]