Messaging pattern: Difference between revisions

Revision as of 19:48, 28 July 2021

Latest revision as of 09:52, 30 June 2025

(15 intermediate revisions by 13 users not shown)

Line 1:

{{Short description|Architectural pattern describing communication between systems}}

{{confusing|date=March 2019}}

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.

== General concepts of the messaging pattern ==

In [[telecommunications]], a '''message exchange pattern''' ('''MEP''') describes the [[pattern]] of [[Message passing|messages]] required by a [[communications protocol]] to establish or use a [[communication channel]]. The ''communications protocol'' is the a 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 [[Hypertext Transfer Protocol|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.

Line 13 ⟶ 14:

== Device communication ==

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 interpetedinterpreted 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 -- routerstraffic—routers, switches and network adapters, which on a hardware level send and receive signals in the form of [[Transmission Control Protocol|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.

== Software communication ==

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.

This section describes the concept of messaging communication among software systems. 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.

Line 27 ⟶ 29:

===SOAP===

The term ''message exchange pattern'' has an extended meaning within the '''Simple Object Access protocol''' ([[SOAP]]).<ref>http://www.w3.org/TR/soap12-part1/#soapmep SOAP MEPs in SOAP W3C Recommendation v1.2</ref><ref>[http://www.w3.org/TR/wsdl20-additional-meps/ Web Services Description Language (WSDL) Version 2.0: Additional MEPs<!-- Bot generated title -->]</ref> 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 providesdoes onlynot asend statusany 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.

Line 37 ⟶ 39:

===ØMQ===

The [[ØMQ]] message queuingqueueing library provides so-called ''sockets'' (a kind of generalization over the traditional [[Internet socket|IP]] and [[Unix ___domain socket|Unix sockets]]) which require indicating a messaging pattern to be used, and are optimized for each pattern. The basic ØMQ patterns are:<ref>[http://www.zeromq.org/docs:user-guide ØMQ User Guide]</ref>

*'''[[Request–response|Request–reply]]''' connects a set of clients to a set of services. This is a [[remote procedure call]] and task distribution pattern.{{clarify|date=November 2010}}

*'''[[Publish–subscribe pattern|Publish–subscribe]]''' connects a set of publishers to a set of subscribers. This is a data distribution pattern.{{clarify|date=November 2010}}

*'''Push–pull''' connects nodes in a [[Fan-out_out (software)|fan-out]] / fan-in pattern that can have multiple steps, and loops. This is a parallel task distribution and collection pattern.{{clarify|date=November 2010}}

*'''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.<ref>[{{Cite web |url=http://www.250bpm.com/hits |title=Scalability Layer Hits the Internet Stack] |access-date=2011-02-03 |archive-date=2019-05-28 |archive-url=https://web.archive.org/web/20190528130558/http://250bpm.com/hits |url-status=dead }}</ref>

===REST===

The [[Representational State Transfer|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 builtbuild other protocol semantics on top of it, which is the example with [[HATEOAS]].

==See also==