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

<span class="mw-page-title-main">HTTP</span> Application protocol for distributed, collaborative, hypermedia information systems

HTTP is an application layer protocol in the Internet protocol suite model for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web, where hypertext documents include hyperlinks to other resources that the user can easily access, for example by a mouse click or by tapping the screen in a web browser.

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.

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">Universal Plug and Play</span> Set of networking protocols

Universal Plug and Play (UPnP) is a set of networking protocols on the Internet Protocol (IP) that permits networked devices, such as personal computers, printers, Internet gateways, Wi-Fi access points and mobile devices, to seamlessly discover each other's presence on the network and establish functional network services. UPnP is intended primarily for residential networks without enterprise-class devices.

In computer science, message queues and mailboxes are software-engineering components typically used for inter-process communication (IPC), or for inter-thread communication within the same process. They use a queue for messaging – the passing of control or of content. Group communication systems provide similar kinds of functionality.

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.

AS2 is a specification on how to transport structured business-to-business data securely and reliably over the Internet. Security is achieved by using digital certificates and encryption.

Real-Time Messaging Protocol (RTMP) is a communication protocol for streaming audio, video, and data over the Internet. Originally developed as a proprietary protocol by Macromedia for streaming between Flash Player and the Flash Communication Server, Adobe has released an incomplete version of the specification of the protocol for public use.

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.

<span class="mw-page-title-main">Wireless Application Protocol</span> Technical standard for accessing information over a mobile wireless network

Wireless Application Protocol (WAP) is a now obsolete technical standard for accessing information over a mobile wireless network. Introduced in 1999, WAP allowed at launch users with compatible mobile devices to browse content such as news, weather and sports scores provided by mobile network operators, specially designed for the limited capabilities of a mobile device. The Japanese i-mode system offered another major competing wireless data standard.

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

Port Control Protocol (PCP) is a computer networking protocol that allows hosts on IPv4 or IPv6 networks to control how the incoming IPv4 or IPv6 packets are translated and forwarded by an upstream router that performs network address translation (NAT) or packet filtering. By allowing hosts to create explicit port forwarding rules, handling of the network traffic can be easily configured to make hosts placed behind NATs or firewalls reachable from the rest of the Internet, which is a requirement for many applications.

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.