Messaging pattern

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 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. ===SOAP=== 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 does 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"). ===Ø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: 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. ===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== Push technology Pull technology Distributed data flow Enterprise Integration Patterns Client–server model Peer-to-peer Publish–subscribe pattern ==References== ==External links== Messaging Patterns in Service-Oriented Architecture Enterprise Integration Patterns - Pattern Catalog

Text derived from https://en.wikipedia.org/w/index.php?oldid=1352246840 under CC BY-SA 4.0; modifications have been made.