Shuttle ESB (II)-architecture model Introduction

This part contains the following five parts. This article introduces the first three parts: Concept, message type, and coupling.

I. Concepts

Ii. Message Type

3. Coupling

Iv. Mode

5. message routing

Concept

All codes in the standard are neither a complete example nor a VS solution. It introduces some important concepts in shuttle ESB. InIntroduction to shuttle ESBThere is a simple implementation that integrates these concepts. You can use the examples to understand the concepts in this article.

Basic Components of shuttle ESB: Message, queue, and service bus

Each service bus instance is associated,Therefore, there is only one input queue. Note that there is only one input queue.. This input queue is an inbox. All messages received in the inbox are used by the Service Bus instance.

Message

Shuttle is message-based. These messages are data transmission objects that implement the specified interface. For example:

public class ActivateMemberCommand    {        string MemberId { get; set; }    }public class MemberActivatedEvent    {        string MemberId { get; set; }    }

Queue

All messages in shuttle ESB are processed by handler. When a service bus instance is started, it listens to the queue messages in the inbox.Therefore, the messages processed in the relevant queue must end.. The Inbox configuration is set in the application configuration file.

This message sending method uses the mechanism of sending at least once.This is different from the traditional concept, which accurately transmits an example once.In some critical situations, it may process messages multiple times. However, critical situations of other mechanisms may lead to loss of information (a duplicate message is easier than no message)

It is important that all queues are lossless and there is a validation feedback mechanism.

Therefore, once a message is retrieved from the queue, it may be confirmed that the message is released and returned to the queue.

Service Bus

When each application accesses the service bus, the Service Bus instance is required. Basic components of the Service Bus: associated code, application configuration file, and application custom components. For example:

public class ServiceBusHost : IHost, IDisposable    {        private static IServiceBus bus;public void Start()        {            bus = ServiceBus.Create().Start();        }public void Dispose()        {            bus.Dispose();        }    }

Create and run a service bus instance, and start and configure to exit the application. The service bus can be used in any type of applications. The most typical case is to communicate as a service. Although you can write a service on your own as a service bus, it is unnecessary because you can use a universal Host:Generic Service HOST: http://shuttle.github.io/shuttle-esb/generic-host/index.html

Message Type

Command Message

Because a command is a clear request that requires the execution of a specific function, the command is sent to a separate endpoint. That is to say, to send messages, you need to know the business implementation of an endpoint. Therefore, commands cause high behavior coupling. If the endpoint of the received message is configurable when a message is sent, the endpoint can be changed at any time.

A command message always belongs to a single end. Sending a command will never cause a message to appear in multiple queues.
Although we should minimize the use of this type of message, it is also necessary in special circumstances, such as the example below.

Start an application

In our application, we need to send a createordercommand queue service. This will start the relevant process.

So start with the client code:

bus.Send(new CreateOrderCommand("ClientName", "ProductXYZ"));

If there is no message receiver, this call will fail.

Now we release an event, such as orderreceivedevent and our queue service, which can subscribe to an event or cancel the subscription.

bus.Publish(new OrderOrderReceivedEvent("ClientName", "ProductXYZ"));

If there is no subscriber, the call will not fail.

Therefore, the difference is that messages are used differently. When using events, we select the subscription mode. However, it is more appropriate to use commands when specific behaviors have been identified in a system. Of course, when using a command method, some other systems still know that the other party has received the command, then the Order Service will issue an event.

Underlying method (RPC)

In some cases, an event may fail to pass the intent of an action. For example, when a command is created (or the number of commands exceeds the upper limit), we may send an email to the lead. The email service is responsible for sending emails through the SMTP server. This email cannot be subscribed through the orderreceivedevent event, because the email system needs to adapt to the rules in another system.

In this example, the email system is responsible for sending emails. Any system needs to decide when to send emails. Therefore, this Order Service will send a command to the mail service:

bus.Send(new SendMailCommand                 {                     To = "[email protected]",                     From = "[email protected]",                     Subject = "Important Order Received",                     Body = "Order Details"                 });

Event message

An event message is used to notify all subscription components. Each component subscribes to an event and receives an event message. If there is no subscriber for an event, the user will not be affected.

Document message

A document message is used to send data to a piece of data. As with event messages, document messages are in a certain direction and can be received or not by recipients. However, this does not mean that data is sent to a terminal for no reason. The terminal may need to obtain a document message from some services. Or, the data is automatically sent to some terminals as needed.

Coupling

Behavior Coupling

Behavior coupling refers to the degree of coupling between one system and another. When your system receives a command message, you need it to be used in a specific requirement. This represents a high degree of behavior coupling. However, when an event message is published, no subscriber is waiting to obtain the message. This is a low behavior coupling.
That is to say, an expected event may lead to a specific result. In this case, the coupling of behavior increases.

Space-time Coupling

Space-time coupling refers to the availability of a service. For example, the servicea service depends on the serviceb service. To ensure that servicea can run normally, serviceb must be available at the same time before servicea can run properly. This is a highly space-time coupling. On the contrary, if servicea does not have serviceb and can still run normally, this is a low space-time coupling.
An asynchronous web-service call is an example of high space-time coupling.

Now you may have doubts: In a use case, servicea and serviceb services are required. So, how do they do it separately?
The answer is: Use a queue for asynchronous communication.

You may say that a Web-service call may use Asynchronous Communication, but there is still a problem here. When a client request is not received, servicea may fail to execute. This will cause the web-service call to fail.

We use messages for communication, and messages are often transmitted in one direction. From servicea to serviceb is an action. After it is executed, the action ends. From serviceb to servicea is an action. After it is executed, the action ends again.

Shuttle ESB (II)-architecture model Introduction