Message Oriented Middleware

from Wikipedia, the free encyclopedia

Message-oriented middleware or Message Oriented Middleware ( MOM ) denotes middleware operating on the asynchronous or synchronous communication , ie the transmission of messages ( English messages is based). The format for the messages is not fixed, but in practice XML has become the popular format.

MOM supports three different communication protocols

advantages

  • Asynchronous / synchronous communication
  • Server / service does not have to be available immediately
  • Message queues
  • Mostly faster execution than function call-based programs
  • Loose coupling of server / clients
  • More tolerance for changes to the existing functions
  • Improved availability of the systems
  • Parallel processing of messages possible

disadvantage

  • Failure of the MOM paralyzes all connected systems
  • Designing , testing , debugging and developing components are unfamiliar to synchronous programmers

Standards and formats

Message Oriented Middleware with XML
The use of XML as the language basis for messages in Message Oriented Middleware is widespread in practice. Due to the comparatively self-explanatory and, in contrast to messages in binary format, easily human-readable format, when using XML it is relatively easy to enable communication between middleware systems if they use different languages, as long as the languages ​​are XML-based. In order to enable communication, an XSLT processor can be interposed as a translator, which translates messages from the XML-based language of the source system into the language of the target system with the help of a transformation stylesheet. SOAP is often used as the protocol .
XML
The markup language XML is now widely used in information technology and is used in numerous areas of application. It is not a conceptual requirement for an Enterprise Service Bus (ESB), but it is used in a variety of ways in the majority of ESB products and the implemented ESBs in application landscapes. It often serves as a standardized data format in which messages are transmitted via the message bus in the core of an ESB, but also as a format for the exchange of messages between services and the message bus via the corresponding endpoints and adapters. It is also used in the description of interfaces, for example with the interface specification language WSDL .
XPath and XQuery
XPath and XQuery are query languages with which parts of XML documents can be queried and extracted. They are not a prerequisite for an ESB, but are often used in ESBs in the context of routing services. Routing rules based on control data or the content of messages are often formulated as XPath or XQuery expressions for these messages.
XSLT
XSL Transformation (XSLT) is a programming language for transforming XML documents. XSLT is not a technological requirement for an ESB. The language is often used in transformation services, especially when an ESB uses XML as the standardized data format.
JMS
Java Message Service (JMS) is a standardized programming interface for sending and receiving messages from Java- based applications via a message bus . It is not a requirement for an ESB. ESBs that are strongly anchored in the Java world, for example because they are implemented in Java themselves, often offer standard adapters and standard endpoints so that services can use the ESB via JMS.
JMS is the most widely used standard for MOMs and is supported by almost all manufacturers.
SOAP
SOAP is a network protocol with the help of which data can be exchanged between systems and service interfaces can be used by remote services. SOAP is based on widely used technologies, for example HTTP and SMTP as protocols, XML as data format or WSDL as language for the interface specification . Services that make their interfaces available with the help of this technology, called Web services or Web services . The concept of the Enterprise Service Bus is not limited to web services or SOAP technology. In practice, however, an ESB often integrates distributed services by connecting them to the central message bus with SOAP adapters .
AMQP
Advanced Message Queuing Protocol (AMQP) is a wirelevel protocol that is being developed by a consortium of more than 20 members (including JP Morgan, Microsoft, Red Hat). In May 2010 the draft version 1 was published. In order to take account of the widespread use of JMS, all JMS functions are incorporated into the protocol. This enables developers to continue using the JMS interface, while MOMs can communicate with one another using AMQP.
JBI
With Java Business Integration (JBI) refers to a standard that within the Java Community Process was published (JCP) under JSR number 208th The document standardizes part of the architecture of an Enterprise Service Bus for a specific technical environment, namely software development and IT architecture based on the Java Platform, Enterprise Edition (Jakarta EE). It details the architecture of the subsystem of an ESB, which Chappell called the service container .
Apache OpenWire
A wirelevel protocol, so far only supported by Apache ActiveMQ.
Apache Streaming Text Oriented Messaging Protocol (Stomp)
Very simple text-based protocol. Native support from ActiveMQ (announced for RedHat HornetQ) and xmlBlaster. However, an adapter for JMS middleware is offered so that STOMP clients can communicate via JMS middleware. It should be noted, however, that this only works in one direction (STOMP → JMS) (due to the lack of functionality in STOMP).
Digistan RestMS (RESTful Messaging Service)
RestMS works via pure HTTP / HTTPS and is intended for web applications. So far there are three implementations. In addition, conversions for AMQP 0.9.1 are implemented.

MOM products

The following products are an arbitrary selection of MOM products on the market:

See also

Web links

Individual evidence

  1. ^ Ten-Hove 2005
  2. ↑ Chappell 2004
  3. ↑ Ten-Hove 2005, p. 8. "JBI defines what is sometimes termed a 'service container' in Enterprise Service Bus (ESB) systems."
  4. ↑ Orchestra - sophisticated software that is fun . (PDF 68kB), in Krankenhaus-IT Journal Issue 2/2013, p. 66, accessed February 20, 2015