Shuttle Bus体系架构的特征

Request-response pattern

Request-response or request-reply is one of the basic methods computers use to talk to each other. When using request-response, the first computer requests some data and the second computer responds to the request. Usually there is a series of such interchanges until the complete message is sent. Browsing a web page is an example of request-response communication. One can think of request-response as being like a telephone call, where you call someone and they answer the call. Compare this with one-way computer communication, which is like the push-to-talk or "barge in" feature found on some phones and two-way radios, where a message is sent without waiting for a response. Sending an email is an example of one-way communication. 

Request-response, also known as request-reply, is a message exchange pattern in which a requestor sends a request message to a replier system which receives and processes the request, ultimately returning a message in response. This is a simple, but powerful messaging pattern which allows two applications to have a two-way conversation with one another over a channel. This pattern is especially common in client-server architectures.^[1]

For simplicity, this pattern is typically implemented in a purely synchronous fashion, as in web service calls over HTTP, which holds a connection open and waits until the response is delivered or the timeout period expires. However, request-response may also be implemented asynchronously, with a response being returned at some unknown later time. This is often referred to as "sync over async", or "sync/async", and is common in enterprise application integration (EAI) implementations where slow aggregations, time-intensive functions, or human workflow must be performed before a response can be constructed and delivered.

Publish–subscribe pattern

In software architecture, publish–subscribe is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers. Instead, published messages are characterized into classes, without knowledge of what, if any, subscribers there may be. Similarly, subscribers express interest in one or more classes, and only receive messages that are of interest, without knowledge of what, if any, publishers there are.

Pub/sub is a sibling of the message queue paradigm, and is typically one part of a larger message-oriented middleware system. Most messaging systems support both the pub/sub and message queue models in their API, e.g. Java Message Service (JMS).

This pattern provides greater network scalability and a more dynamic network topology.

-----------------------------------------------------------------------------------------------------------------------

PS：以上内容主要摘自维基百科。

Message Distribution

It is conceivable that an endpoint can start falling behind with its processing if it receives too much work. In such cases it may be changed to distribute messages to worker nodes.

The endpoint that you would like to have message distributed on would require a control inbox configuration since all Shuttle messages should be processed without waiting in a queue like the inbox proper behind potentially thousands of messages. Each worker is identified as such in its configuration and the control inbox of the endpoint performing the distribution is required。

Any message that is sent to the distributor will be sent on to an available worker. Each thread running on a worker will send a WorkerThreadAvailableCommand to the distributor's control inbox once it becomes idle. The distributor will then be able to send on a message for each available thread oo the worker.

 ========================== 分割线 ===================

Pipeline-based processing（管道，事件，观察者）

Shuttle makes use of event-based pipelines for:

• Sending messages
• Receiving / handling messages
• Outbox processing
• Distributor processing
• Service bus startup

You can even add your own event anywhere in the pipeline. Various observers handle these events so you can add an observer to any event: