Enterprise messaging system

Last updated

An enterprise messaging system (EMS) or messaging system in brief [1] is a set of published enterprise-wide standards that allows organizations to send semantically precise messages between computer systems. EMS systems promote loosely coupled architectures that allow changes in the formats of messages to have minimum impact on message subscribers. EMS systems are facilitated by the use of structured messages (such as using XML or JSON), and appropriate protocols, such as DDS, MSMQ, AMQP or SOAP with web services.

Contents

EMS usually takes into account the following considerations:

  1. Security: Messages must be encrypted if they travel over public interfaces. Messages must be authenticated or digitally signed if the receiver is to have confidence that the messages have not been tampered with in transit.
  2. Routing: Messages need to be routed efficiently from the sender to the receiver. Intermediate nodes may need to route the messages if the body of the message is encrypted.
  3. Metadata: The body of the document contains information that must be unambiguously interpreted. Metadata registries should be used to create precise definitions for each data element.
  4. Subscription: Systems should be able to subscribe to all messages that match a specific pattern. Messages with a specific content may be routed differently. For example, some messages may have different priority or security policies.
  5. Policy: Enterprise messaging systems should provide some consideration for a centralized policy of messages such as what classes or roles of users can access different fields of any message.

EMS are also known as Message-Oriented Middleware (MOM) [2]

Separation of message header and message body

The design of an EMS is usually broken down into two sections:

  1. Message header design– Message headers contain the information necessary to route messages. Message headers are usually coded in clear text so that intermediate nodes receive all the necessary information they need to route and prioritize the message. Message headers are analogous to the information printed on the outside of a letter (to, from, priority of message etc.)
  2. Message body semantics– Message body semantics include the precise definition of all of the data elements in the body of the message. Message semantics can be aided by the use of a precise data dictionary that documents metadata.

Comparisons

The commonalities between messaging systems (in terms of capabilities and architecture) have been captured in a platform-independent fashion as enterprise integration patterns (a.k.a. messaging patterns). [3]

Although similar in concept to an enterprise service bus (ESB), an EMS places emphasis on design of messaging protocols (for instance, using DDS, MSMQ or AMQP), not the implementation of the services using a specific technology such as web services, DDS APIs for C/C++ and Java, .NET or Java Message Service (JMS).

Note that an Enterprise Messaging System should not be confused with an electronic mail system used for delivering human readable text messages to individual people.

An example of a specific application programming interface (API) that implements an enterprise messaging system is the Java Message Service. Although this is an API it embodies many of the same issues involved in setting up a full EMS.

Policy statements may also be extracted from a centralized policy server. These policy statements can be expressed in the XML Access Control Markup Language (XACML).

See also

Related Research Articles

<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 Jakarta Messaging API is a Java application programming interface (API) for message-oriented middleware. It provides generic messaging models, able to handle the producer–consumer problem, that can be used to facilitate the sending and receiving of messages between software systems. Jakarta Messaging is a part of Jakarta EE and was originally defined by a specification developed at Sun Microsystems before being guided by the Java Community Process.

Middleware in the context of distributed applications is software that provides services beyond those provided by the operating system to enable the various components of a distributed system to communicate and manage data. Middleware supports and simplifies complex distributed applications. It includes web servers, application servers, messaging and similar tools that support application development and delivery. Middleware is especially integral to modern information technology based on XML, SOAP, Web services, and service-oriented architecture.

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.

Enterprise information integration (EII) is the ability to support a unified view of data and information for an entire organization. In a data virtualization application of EII, a process of information integration, using data abstraction to provide a unified interface for viewing all the data within an organization, and a single set of structures and naming conventions to represent this data; the goal of EII is to get a large set of heterogeneous data sources to appear to a user or system as a single, homogeneous data source.

Enterprise application integration (EAI) is the use of software and computer systems' architectural principles to integrate a set of enterprise computer applications.

<span class="mw-page-title-main">Enterprise service bus</span> Communication system in a service-oriented architecture

An enterprise service bus (ESB) implements a communication system between mutually interacting software applications in a service-oriented architecture (SOA). It represents a software architecture for distributed computing, and is a special variant of the more general client-server model, wherein any application may behave as server or client. ESB promotes agility and flexibility with regard to high-level protocol communication between applications. Its primary use is in enterprise application integration (EAI) of heterogeneous and complex service landscapes.

The Web Services Invocation Framework (WSIF) supports a simple and flexible Java API for invoking any Web Services Description Language (WSDL)-described service.

The Data Distribution Service (DDS) for real-time systems is an Object Management Group (OMG) machine-to-machine standard that aims to enable dependable, high-performance, interoperable, real-time, scalable data exchanges using a publish–subscribe pattern.

An XML appliance is a special-purpose network device used to secure, manage and mediate XML traffic. They are most popularly implemented in service-oriented architectures (SOA) to control XML-based web services traffic, and increasingly in cloud-oriented computing to help enterprises integrate on premises applications with off-premises cloud-hosted applications. XML appliances are also commonly referred to as SOA appliances, SOA gateways, XML gateways, and cloud brokers. Some have also been deployed for more specific applications like Message-oriented middleware. While the originators of the product category deployed exclusively as hardware, today most XML appliances are also available as software gateways and virtual appliances for environments like VMWare.

Mule is a lightweight enterprise service bus (ESB) and integration framework provided by MuleSoft. The platform is Java-based but can act as broker for interactions between other platforms such as .NET using web services or sockets.

The Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for message-oriented middleware. The defining features of AMQP are message orientation, queuing, routing, reliability and security.

IBM App Connect Enterprise is IBM's premier integration software offering, allowing business information to flow between disparate applications across multiple hardware and software platforms. Rules can be applied to the data flowing through user-authored integrations to route and transform the information. The product can be used as an Enterprise Service Bus supplying a communication channel between applications and services in a service-oriented architecture.

Oracle Enterprise Service Bus, a fundamental component of Oracle's Services-Oriented Architecture suite of products, provides integration of data and enterprise applications within an organisation and their connected enterprises.

Apache Camel is an open source framework for message-oriented middleware with a rule-based routing and mediation engine that provides a Java object-based implementation of the Enterprise Integration Patterns using an application programming interface to configure routing and mediation rules.

<i>Enterprise Integration Patterns</i>

Enterprise Integration Patterns is a book by Gregor Hohpe and Bobby Woolf and describes 65 patterns for the use of enterprise application integration and message-oriented middleware in the form of a pattern language.

A message queueing service is a message-oriented middleware or MOM deployed in a compute cloud using software as a service model. Service subscribers access queues and or topics to exchange data using point-to-point or publish and subscribe patterns.

<span class="mw-page-title-main">Apache Qpid</span> Open-source messaging system

Apache Qpid is an open-source messaging system which implements the Advanced Message Queuing Protocol (AMQP). It provides transaction management, queuing, distribution, security, management, clustering, federation and heterogeneous multi-platform support. The Apache Qpid API supports multiple programming languages and comes with both C++ and Java brokers.

A canonical model is a design pattern used to communicate between different data formats. Essentially: create a data model which is a superset of all the others ("canonical"), and create a "translator" module or layer to/from which all existing modules exchange data with other modules. The canonical model acts as a middleman. Each model now only needs to know how to communicate with the canonical model and dont need to know the implementation details of the other modules.

References

  1. ↑ G. Hohpe. B. Woolf, Enterprise Integration Patterns, Addison Wesley, 2004.
  2. ↑ Curry, Edward. 2004. "Message-Oriented Middleware" [ permanent dead link ]. In Middleware for Communications, ed. Qusay H Mahmoud, 1-28. Chichester, England: John Wiley and Sons. doi : 10.1002/0470862084.ch1. ISBN   978-0-470-86206-3]
  3. ↑ Olaf Zimmermann; Cesare Pautasso; Gregor Hohpe; Bobby Woolf (2016). "A Decade of Enterprise Integration Patterns: A Conversation with the Authors". IEEE Software. 33 (1): 13–19. doi: 10.1109/MS.2016.11 .
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.