Introduction to shuttle ESB

Background 1

Message-oriented middleware is used in the project. Previously, I implemented it using another colleague's idea: I used the OPC channel to detect front-end messages. Once a new message is found, it is immediately sent to each terminal, and the terminal displays and processes it based on its own business needs. However, many problems occur during system interconnection. For example, many WPF events in the project cannot be triggered. After several explorations, it is still difficult. So, let's change to today's idea.

Background 2

After the technical research, the manager decided to use the shuttle ESB recommended by his colleagues as the message middleware. That is to say, I gave up the previous OPC attempt and used ESB as the message route. That is, data is detected at the front-end monitoring point. Then, messages are sent to various terminals through message-oriented middleware.

Shuttle ESB

Shuttle ESB is a free. Net open source project. It provides a new idea for message-oriented event-driven architecture system development. The rise of the shuttle project was not long, and there was only one case in South Africa.

Shuttle mainly includes the following content:

1. C #-based development (. NET framework3.5 );

2. Core functions do not depend on any third party;

3. supports both command messages and event messages;

4. Integrated message delivery functions;

5. automatic retry, enhancing fault tolerance.

Key Points

The shuttle service bus depends on two things: 1. messages; 2. queues.

The queue infrastructure can be any implementation. Currently, shuttle supports two types of Queues: Microsoft Message Queue MSMQ and SQL Server table-based queues. Shuttle already provides interfaces, which were implemented in the first version of shuttle. To support other queues, you only need to refer to the existing implementation and write an implementation class.

Command Message and event message

Messages in shuttle are divided into command messages and event messages. Command messages are sent to separate endpoints, which requires the command message to send a request with clear requirements. To send a message, you need to know the behavior implemented by that endpoint. Therefore, command messages are highly coupled.

On the contrary, event messages may have no or multiple subscribers. After an event is published, each subscriber receives a message.

PS: Command Message and event message, similar to JMS in Java EE's EJB specification. The command message is similar to the P2P mode, while the event message is similar to the pub/sub mode.

Various ESB products, including shuttle ESB, are SOA software architecture models designed and implemented for interaction between software applications. As a distributed computing software architecture model, shuttle ESB is called a variant of the client server architecture. The main purpose is to integrate enterprises in heterogeneous and complex situations.

Shuttle used in our project

1. Data is detected at the monitoring site and sent to the service terminal as a command message;

2. In the publish/subscribe mode, each terminal displays a message subscription event. After receiving a command message, the Service terminal sends a message to each subscribed terminal;

3. The terminal handles and displays the information.

Reference

Wikipedia-http://en.wikipedia.org/wiki/Event-driven_architecture

Http://en.wikipedia.org/wiki/Extensibility

And

Http://www.infoq.com/articles/Shuttle-Service-Bus