Request-responsepattern

Request-responseorrequest-replyis 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 withone-waycomputer 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 amessage exchange patternin 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 purelysynchronousfashion, as inweb servicecalls overHTTP, which holds a connection open and waits until the response is delivered or thetimeoutperiod expires. However, request-response may also be implementedasynchronously, 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 inenterprise application integration(EAI) implementations where slowaggregations, time-intensive functions, orhuman workflowmust be performed before a response can be constructed and delivered.

Publish–subscribe pattern

Insoftware architecture,publish–subscribeis amessaging patternwhere senders ofmessages, 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 themessage queueparadigm, and is typically one part of a largermessage-oriented middlewaresystem. Most messaging systems support both the pub/sub and message queue models in theirAPI, e.g.Java Message Service(JMS).

This pattern provides greater networkscalabilityand a more dynamicnetwork 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 aWorkerThreadAvailableCommandto 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: