Messaging pattern

Last updated

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.

Contents

General concepts of the messaging pattern

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, [1] 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.

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 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.

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.

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.

SOAP

The term message exchange pattern has an extended meaning within the Simple Object Access protocol (SOAP). [2] [3] SOAP MEP types include:

  1. 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.
  2. 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.
  3. 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.
  4. In-Optional-Out: A standard two-way message exchange where the provider's response is optional.
  5. Out-Only: The reverse of In-Only. It primarily supports event notification. It cannot trigger a fault message.
  6. Robust Out-Only: Similar to the out-only pattern, except it can trigger a fault message. The outbound message initiates the transmission.
  7. Out-In: The reverse of In-Out. The provider transmits the request and initiates the exchange.
  8. Out-Optional-In: The reverse of In-Optional-Out. The service produces an outbound message. The incoming message is optional ("Optional-in").

ØMQ

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: [4]

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. [5]

REST

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 built other protocol semantics on top of it, which is the example with HATEOAS.

See also

Related Research Articles

<span class="mw-page-title-main">Client–server model</span> Distributed application structure in computing

The client–server model is a distributed application structure that partitions tasks or workloads between the providers of a resource or service, called servers, and service requesters, called clients. Often clients and servers communicate over a computer network on separate hardware, but both client and server may reside in the same system. A server host runs one or more server programs, which share their resources with clients. A client usually does not share any of its resources, but it requests content or service from a server. Clients, therefore, initiate communication sessions with servers, which await incoming requests. Examples of computer applications that use the client–server model are email, network printing, and the World Wide Web.

Electronic data interchange (EDI) is the concept of businesses electronically communicating information that was traditionally communicated on paper, such as purchase orders, advance ship notices, and invoices. Technical standards for EDI exist to facilitate parties transacting such instruments without having to make special arrangements.

In distributed computing, a remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to execute in a different address space, which is coded as if it were a normal (local) procedure call, without the programmer explicitly coding the details for the remote interaction. That is, the programmer writes essentially the same code whether the subroutine is local to the executing program, or remote. This is a form of client–server interaction, typically implemented via a request–response message-passing system. In the object-oriented programming paradigm, RPCs are represented by remote method invocation (RMI). The RPC model implies a level of location transparency, namely that calling procedures are largely the same whether they are local or remote, but usually, they are not identical, so local calls can be distinguished from remote calls. Remote calls are usually orders of magnitude slower and less reliable than local calls, so distinguishing them is important.

The Session Initiation Protocol (SIP) is a signaling protocol used for initiating, maintaining, and terminating communication sessions that include voice, video and messaging applications. SIP is used in Internet telephony, in private IP telephone systems, as well as mobile phone calling over LTE (VoLTE).

<span class="mw-page-title-main">SOAP</span> Messaging protocol for web services

SOAP is a messaging protocol specification for exchanging structured information in the implementation of web services in computer networks. It uses XML Information Set for its message format, and relies on application layer protocols, most often Hypertext Transfer Protocol (HTTP), although some legacy systems communicate over Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.

<span class="mw-page-title-main">Web server</span> Computer software that distributes web pages

A web server is computer software and underlying hardware that accepts requests via HTTP or its secure variant HTTPS. A user agent, commonly a web browser or web crawler, initiates communication by making a request for a web page or other resource using HTTP, and the server responds with the content of that resource or an error message. A web server can also accept and store resources sent from the user agent if configured to do so.

In computing, a handshake is a signal between two devices or programs, used to, e.g., authenticate, coordinate. An example is the handshaking between a hypervisor and an application in a guest virtual machine.

<span class="mw-page-title-main">Email client</span> Computer program used to access and manage a users email

An email client, email reader or, more formally, message user agent (MUA) or mail user agent is a computer program used to access and manage a user's email.

The Address Resolution Protocol (ARP) is a communication protocol used for discovering the link layer address, such as a MAC address, associated with a given internet layer address, typically an IPv4 address. This mapping is a critical function in the Internet protocol suite. ARP was defined in 1982 by RFC 826, which is Internet Standard STD 37.

A web service (WS) is either:

<span class="mw-page-title-main">Inter-process communication</span> How computer operating systems enable data sharing

In computer science, inter-process communication or interprocess communication (IPC) refers specifically to the mechanisms an operating system provides to allow the processes to manage shared data. Typically, applications can use IPC, categorized as clients and servers, where the client requests data and the server responds to client requests. Many applications are both clients and servers, as commonly seen in distributed computing.

Message-oriented middleware (MOM) is software or hardware infrastructure supporting sending and receiving messages between distributed systems. MOM allows application modules to be distributed over heterogeneous platforms and reduces the complexity of developing applications that span multiple operating systems and network protocols. The middleware creates a distributed communications layer that insulates the application developer from the details of the various operating systems and network interfaces. APIs that extend across diverse platforms and networks are typically provided by MOM.

In computer science and networking in particular, a session is a time-delimited two-way link, a practical layer in the TCP/IP protocol enabling interactive expression and information exchange between two or more communication devices or ends – be they computers, automated systems, or live active users. A session is established at a certain point in time, and then ‘torn down’ - brought to an end - at some later point. An established communication session may involve more than one message in each direction. A session is typically stateful, meaning that at least one of the communicating parties needs to hold current state information and save information about the session history to be able to communicate, as opposed to stateless communication, where the communication consists of independent requests with responses.

Internet fax, e-fax, or online fax is the use of the internet and internet protocols to send a fax (facsimile), rather than using a standard telephone connection and a fax machine. A distinguishing feature of Internet fax, compared to other Internet communications such as email, is the ability to exchange fax messages with traditional telephone-based fax machines.

OMA Device Management is a device management protocol specified by the Open Mobile Alliance (OMA) Device Management (DM) Working Group and the Data Synchronization (DS) Working Group. The current approved specification of OMA DM is version 1.2.1, the latest modifications to this version released in June 2008. The candidate release 2.0 was scheduled to be finalized in September 2013.

<span class="mw-page-title-main">H.323</span> Audio-visual communication signaling protocol

H.323 is a recommendation from the ITU Telecommunication Standardization Sector (ITU-T) that defines the protocols to provide audio-visual communication sessions on any packet network. The H.323 standard addresses call signaling and control, multimedia transport and control, and bandwidth control for point-to-point and multi-point conferences.

Wireless Application Protocol (WAP) is a technical standard for accessing information over a mobile wireless network. A WAP browser is a web browser for mobile devices such as mobile phones that use the protocol. Introduced in 1999, WAP achieved some popularity in the early 2000s, but by the 2010s it had been largely superseded by more modern standards. Almost all modern handset internet browsers now fully support HTML, so they do not need to use WAP markup for web page compatibility, and therefore, most are no longer able to render and display pages written in WML, WAP's markup language.

In computer science, request–response or request–reply is one of the basic methods computers use to communicate with each other in a network, in which the first computer sends a request for some data and the second responds to the request. More specifically, it 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. It is analogous to a telephone call, in which the caller must wait for the recipient to pick up before anything can be discussed. This is a simple but powerful messaging pattern which allows two applications to have a two-way conversation with one another over a channel; it is especially common in client–server architectures.

A communication protocol is a system of rules that allows two or more entities of a communications system to transmit information via any kind of variation of a physical quantity. The protocol defines the rules, syntax, semantics and synchronization of communication and possible error recovery methods. Protocols may be implemented by hardware, software, or a combination of both.

Constrained Application Protocol (CoAP) is a specialized Internet application protocol for constrained devices, as defined in RFC 7252. It enables those constrained devices called "nodes" to communicate with the wider Internet using similar protocols. CoAP is designed for use between devices on the same constrained network, between devices and general nodes on the Internet, and between devices on different constrained networks both joined by an internet. CoAP is also being used via other mechanisms, such as SMS on mobile communication networks.

References

  1. ↑ Erl, Thomas (2005). Service Oriented Architecture: Concepts, Technology, and Design. Indiana: Pearson Education. p. 171. ISBN   0-13-185858-0.
  2. ↑ http://www.w3.org/TR/soap12-part1/#soapmep SOAP MEPs in SOAP W3C Recommendation v1.2
  3. ↑ Web Services Description Language (WSDL) Version 2.0: Additional MEPs
  4. ↑ ØMQ User Guide
  5. ↑ "Scalability Layer Hits the Internet Stack". Archived from the original on 2019-05-28. Retrieved 2011-02-03.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.