Шаблоны обмена сообщениями в программной архитектуре

In software architecture, a messaging pattern is an architectural pattern which describes how two different parts of an application, or different systems connect and communicate with each other. There are many aspects to the concept of messaging which can be divided in the following categories: hardware device messaging (telecommunications, computer networking, IoT, etc.) and software data exchange (the different data exchange formats and software capabilities of such data exchange). Despite the difference in the context, both categories exhibit common traits for data exchange.

In telecommunications, a message exchange pattern (MEP) describes the pattern of messages required by a communications protocol to establish or use a communication channel. The communications protocol is the format used to represent the message which all communicating parties agree on (or are capable to process). The communication channel is the infrastructure that enables messages to "travel" between the communicating parties. The message exchange patterns describe the message flow between parties in the communication process, there are two major message exchange patterns — a request–response pattern, and a one way pattern. For example, when viewing content on the Internet (the channel), a web browser (a communicating party) would use the HTTP (the communication protocol) to request a web page from the server (another communicating party), and then render the returned data into its visual form. This is how the request–response messaging pattern operates. Alternatively, in computer networking, we have the UDP network protocol. It is used with the one way messaging pattern, where the sending party is not interested whether the message arrives to any receiving party, nor it expects any of the receiving parties to produce an "answering" message.

This section is about data exchange between hardware devices. In order for the devices to be able to read and exchange data, they would use a hardware specific protocol (such as the radio signal) which is generated by a hardware device acting as a sending party (the radio tower), and can be interpreted by another hardware device which is the receiving party (your kitchen radio for instance). With the example of the radio, we have a one way communication pattern, and the message exchange protocol is the radio signal itself. Device communication may also refer to how the hardware devices in a message exchange system enable the message exchange. For example, when browsing the Internet, a number of different devices work in tandem to deliver the message through the internet traffic—routers, switches and network adapters, which on a hardware level send and receive signals in the form of TCP or UDP packages. Each such package could by itself be referred to as a message if we narrow our view to a pair of hardware devices communicating to one another, while in the general sense of the internet communication, a number of sequentially arranged packages together form a meaningful message, such as an image, or a web page.

Unlike device communications, where the form of the message data is limited to protocols supported by the type and capabilities of the devices involved (for example in computer networking we have the TCP and UDP protocols, a walkie talkie would sending radio waves in specific frequency, and a beacon would be flashing Morse code sequences that a person could read), a software can establish more complex and robust data exchange formats. Those formats would be translated by the sending party in a form deliverable by the underlying hardware, and then decoded by the receiving party from the hardware specific format to a form conforming to the original protocol established by the communicating software systems. This higher level data exchange allows transferring information in a more human readable form, and also enables usage of software encryption and decryption techniques to make messaging secure. Additionally, the software message exchange enables more variations of the message exchange pattern which are no longer limited to the simple request reply and one way approaches. And last, but not least, software communication systems are capable of providing various channels for data exchange which can be used to optimize the message delivery, or to establish complex rules for selection and filtering which help deciding which parties to receive certain messages. This enables the possibility for software orchestrated message routing. As result to the later, the concepts of a topic (where all receiving parties in a targeted group would be delivered a copy of the message) and a queue (where only one party in a targeted group would receive the message) have emerged. As mentioned before, software messaging allows more options and freedom in the data exchange protocols. This, however, would not be very useful unless the communicating parties agree on the details of the protocol involved, and so a number of standardized software messaging protocols exist. This standardization allows different software systems, usually created and maintained by separate organizations, and which could be operating on different hardware devices (servers, computers, smart devices or IoT controllers), to participate in realtime data exchange. Below are listed some of the most popular software messaging protocols, which are still in use today. Each of them provides extended meanings to the messaging concept described in the previous section.

The term message exchange pattern has an extended meaning within the Simple Object Access protocol (SOAP). SOAP MEP types include:
In Only: This is equivalent to one way. A standard one way messaging exchange where the consumer sends a message to the provider that provides do not send any type of response. Robust In Only: This pattern is for reliable one way message exchanges. The consumer initiates with a message to which the provider responds with status. If the response is a status, the exchange is complete, but if the response is a fault, the consumer must respond with a status. In Out: This is equivalent to request–response. A standard two way message exchange where the consumer initiates with a message, the provider responds with a message or fault and the consumer responds with a status. In Optional Out: A standard two way message exchange where the provider's response is optional. Out Only: The reverse of In Only. It primarily supports event notification. It cannot trigger a fault message. Robust Out Only: Similar to the out only pattern, except it can trigger a fault message. The outbound message initiates the transmission. Out In: The reverse of In Out. The provider transmits the request and initiates the exchange. Out Optional In: The reverse of In Optional Out. The service produces an outbound message. The incoming message is optional ("Optional in").

The ØMQ message queueing library provides so called sockets (a kind of generalization over the traditional IP and Unix sockets) which require indicating a messaging pattern to be used, and are optimized for each pattern. The basic ØMQ patterns are:
Request–reply connects a set of clients to a set of services. This is a remote procedure call and task distribution pattern. Publish–subscribe connects a set of publishers to a set of subscribers. This is a data distribution pattern. Push–pull connects nodes in a fan out / fan in pattern that can have multiple steps, and loops. This is a parallel task distribution and collection pattern. Exclusive pair connects two sockets in an exclusive pair. This is a low level pattern for specific, advanced use cases. Each pattern defines a particular network topology. Request reply defines so called "service bus", publish subscribe defines "data distribution tree", push pull defines "parallelised pipeline". All the patterns are deliberately designed in such a way as to be infinitely scalable and thus usable on Internet scale.

The REST protocol is a messaging protocol built on top of the HTTP protocol, and, similarly, uses the request reply pattern of message exchange. While HTTP's primary goal is to deliver web pages and files over the Internet which are targeted for a human end user, the REST protocol is mostly used for communication between different software systems, and has a key role in the microservices software architecture pattern. Among the notable qualities of the REST protocol is that it is versatile enough to represent data in many other formats (typically JSON and XML) and that it provides additional metadata descriptors for the message it represents. The metadata descriptors follow the HTTP standards by being represented as HTTP headers (which are standardized by the underlying HTTP protocol) and so they could be used as instructions for the receiving party on how to interpret the message payload. Because of that, REST greatly improves the development of a software system that is capable of communicating with another software system, since the developers need to be aware only of the higher level format of the message payload (the JSON or XML model). The actual HTTP communication is usually handled by a software library or framework. Another great quality of the REST protocol is that it is suitable to build other protocol semantics on top of it, which is the example with HATEOAS.