Messaging and Queuing : The MOM Middleware

February 1, 2008 at 4:02 pm (Unit 1) (, )

  • MOM is a key piece of middleware that is absolutely essential for a class of client/server products.
  • If the application can tolerate a certain level of time-independent responses, MOM provides the easiest path for creating enterprise and inter-enterprise client/server systems.
  • This accumulates outgoing transactions in queue and do a bulk upload when a connection can be established with an office server.
  • MOM allows general purpose messages to be exchanged in a client/server system using message queues.
  • Applications communicate over networks by simply putting messages in queues and getting messages from queues.
  • MOM hides all the nasty communications from applications and typically provides a very simple high-level of API to its services.
  • A MOM consortium was formed in mid-1993 with the goal of creating standards for messaging middleware.
  • Members are product providers including
    • IBM – MQSeries
    • Covia – Communications Integrator
    • Peerlogic – PIPES
    • Horizon Strategies – Message Express
    • System Strategies – ezBridge
  • MOM’s messaging and queuing allows clients and servers to communicate across a network without being linked by a private, dedicated, logical connection.
  • The clients and servers can run at different times.
  • Everybody communicates by putting messages on queues and by taking messages from queues.

MOM 1

  • MOM products provide their own NOS services – including hierarchical naming, security, and a layer that isolates applications from the network.
  • They use virtual memory on the local OS to create their queues.
  • Most messaging products allow the sender to specify the name of the reply queue.
  • The products also include some type of format field that tells the recipient how to interpret the message data.
  • MOM enabled programs do not talk to each other directly, so either program can be busy, unavailable, or simply not running at the same time.
  • The target program can even be started several hours later.

MOM 2

  • Many clients are sending requests to one server queue.
  • The messages are picked off the queue by multiple instances of the server program that are concurrently servicing the clients.
  • The server instances can take messages off the queue either on a FIFO basis or accounting to some priority to load-balancing scheme.
  • The message queue can be concurrently accessed.
  • The servers can also use messaging filters to throw away the messages they don’t want to process, or they can pass them on to other servers.
  • The MOM messaging products provide persistent (logged on disk) and non-persistent (in memory) message queues.
  • Persistent messages are slower, that they can be recovered in case of power failures after a system restart.
  • A message queue can be local to the machine or remote.
  • System administrators can usually specify the number of messages a queue can hold and the maximum message size.

MOM 3

Permalink Leave a Comment

RPC, Messaging and Peer to Peer

January 15, 2008 at 3:27 am (Unit 1) (, , , , )

  • Client/Server applications are split across address spaces, physical machines, networks and operating systems.
  • All NOSs offer peer-to-peer interfaces that let applications communicate using close to the wire send/receive semantics.
  • Most NOSs provide some form of RPC middleware that hides the wire.
  • An alternative type of model – message queueing or simple MOM – incredibly helpful in situations when the tight synchronization is not needed between the clients and servers.

Communication Stacks

Stack

Application

Messaging

RPC

Peer-to-Peer

  

Named Pipes

DCE

SUN

  

Presentation

 

NDR

XDR

 

  

Session

Peer-to-peer service API

  

NetBIOS Sockets TLI CPI-C/APPC

  

Transport

Common Transport Semantics

  

NetBEUI

TCP/IP

SPX/IPX

LU6.2 /APPN

  

Network

  

LLC

IEEE802.2

  

MAC

NDIS (OR) ODI

  

IEEE 802.5 (Token Ring)

IEEE 802.3 (Ethernet)

SDLC

ISDN

  

Physical

Fiber Optic

Coax

Twisted Pair

  
  • Each layer has a well-defined set of APIs and Protocols.
  • With these mix-and-match can be done.
  • Practically, an entire stack of from a single vendor.
  • The lowest layer of the communication software belongs to the device drivers that provide an interface to several types of communication hardware adapters.
  • Real products don’t have any notion of architectural boundaries or reference models – they just get a job done.
  • At the lower layers, they interface to the hardware using MAC protocols defined by IEEE.
  • The LLC provides a common interface to the MACs and a reliable link service for transmitting communication packets between two nodes.
  • The transport layer provides end-to-end delivery service.

Permalink Leave a Comment