2. Further Information
Message-Oriented Middleware
in Middleware for Communications,
Q. H. Mahmoud, Ed. Chichester,
England: John Wiley and Sons,
2004, pp. 1-28.
Full text available at:
http://www.edwardcurry.org/publications/curry_MfC_MOM_04.pdf
3. Presentation Outline
Interaction Models
– Synchronous & Asynchronous Communication
Introduction to the Remote Procedure Call (RPC)
Introduction to Message-Oriented Middleware (MOM)
– When to use MOM or RPC
MOM Overview
– Message Queues
– Messaging Models
• Point-to-Point & Publish/Subscribe
• Comparison of Messaging Models
Service-Oriented Architectures
– Role of XML, Web Services, SOAP, MOM
– Developing Service-Oriented Architectures
Introduction to Message-Oriented Middleware 3
4. Challenges of Distributed Computing
Direct Remote Procedure Call (RPC)
mechanisms struggle in large-scale widely
distributed deployments
Alternative to RPC has emerged
Message-Oriented Middleware
–any middleware infrastructure providing messaging
capab.
–peer-to-peer relationship between individual clients
–each peer can send/receive messages to/from
other peers
Introduction to Message-Oriented Middleware 4
5. Interaction Models
Two model dominate distributed computing environments
– synchronous and asynchronous communication
– a solid knowledge of models is key to understanding benefits and
differences between MOM and other forms of distribution
Synchronous Interaction
– caller must block & wait (suspend processing) until the called
completes
– participants do not have processing control independence
• they rely on the return of control from the called systems
Asynchronous Interaction
– caller retains processing control, does not need to block
– requires an intermediary to handle the exchange of requests
– participants retain processing independence (continue processing)
regardless of the state of the others
Introduction to Message-Oriented Middleware 5
8. Introducing RPC
Traditional Distribution model
– Utilized in middleware platforms including
• CORBA, Java RMI, Microsoft DCOM & XML-RPC
– Based on the synchronous interaction model
RPC creates a facade, making both processes believe
they are in the same process space
– Similar to a local procedure call
• control is passed to procedure in sequential
synchronous manner
Direct conversation between two parties
– (similar to a person-to-person telephone
conversation)
Introduction to Message-Oriented Middleware 8
10. RPC Cont.
Coupling
– invasive mechanism of distribution
– works on object or function interfaces, producing tightly coupled systems
– Inflexible method of integrating multiple systems
Reliability
– most impl. provide little or no guaranteed reliable communication capability
– very vulnerable to service outages
Scalability
– blocking nature of RPC can adversely affect performance
– subsystems do not scale equally, effectively slows whole system down to the
maximum speed of slowest participant
– synchronous interactions use more bandwidth (several calls are needed)
Availability
– systems built using the RPC model are interdependent
– require simultaneous availability of all subsystems
Introduction to Message-Oriented Middleware 10
11. MOM
Based on the asynchronous interaction model
– not required to block and wait on a message send
Allows delivery of messages when the sender or receiver is
– not active or available to respond at the time of execution
Supports delivery for messages that may take minutes to deliver
– as apposed to RPC that delivers in milliseconds or seconds
• ( ! 100% True)
Sending application has no guarantee message will be read nor
is it given guarantee about the time it will take to deliver
– these aspects are mainly determined by the receiving application
Similar to the postal service
– Messages are delivered to the post office; the postal service then
takes responsibility for safe delivery of the message
Introduction to Message-Oriented Middleware 11
13. MOM
Coupling
– creates loose coupling between participants in a system
• independent layer acts as an intermediary to exchange messages
• ability to link systems without adapting source and target systems
Reliability
– guarantee message delivery to each intended recipient exactly once
• message loss is prevented by using a store and forward mechanism
– high-level of reliability (typically configurable)
Scalability
– decouples performance characteristics of the subsystems from each other
• subsystems can scale independently
– messaging models contain natural traits for effective load balancing (…)
Availability
– high availability capabilities
– does not require simultaneous or “same-time” availability of all subsystems
Introduction to Message-Oriented Middleware 13
14. When to use RPC or MOM
RPC
– suffers from inflexibility and tight coupling
– problematic to scale parts of the system and deal with service outages
– assumes simultaneously available
– require more bandwidth than a similar MOM interaction
– designed on the notion of a single client talking to a single server, traditional RPC
has no built in support for one-to-many communications
– simplicity of the mechanism and straightforward implementation
– guarantee of sequential processing - RPC is slow but consistent
• work is always carried out in the correct order.
• important considerations for systems that requires 100% temporal integrity
– temporal inaccuracies
RPC is ideal if you want a strongly-typed/OO system with tight coupling,
compile-time semantic checking and more straightforward impl.
MOM is an ideal solution if the systems will be a geographically dispersed
deployment with poor network connectivity and stringent demands in
reliability, flexibility and scalability
Introduction to Message-Oriented Middleware 14
16. Message Queues
Queues provide ability to store messages on MOM
Queue are sorted in a particular order
– standard queue is the First-In First-Out (FIFO) queue
Other Types of Queues
– Public Queue
– Private Queue
– Temporary Queue
– Journal Queues
– Connector/Bridge Queue
– Dead-Letter/Dead-Message Queue
Introduction to Message-Oriented Middleware 16
18. Messaging Models
Two main message models are commonly available
– point-to-point
– publish/subscribe
Both are based on the exchange of messages
through a channel (queue)
Typical system will utilize a mix of these models to
achieve different messaging objectives
Introduction to Message-Oriented Middleware 18
19. Point-to-Point Model
Straightforward asynchronous exchange of messages
– message routed to consuming clients via a queue
– no restriction on number of publishing clients
– usually only a single consuming client (not a strict requirement)
• each message is delivered only once to only one receiver
Messages are always delivered and will be stored in the
queue until a consumer is ready to retrieve them
Introduction to Message-Oriented Middleware 19
20. Publish Subscribe Models
One-to-many and many-to-many distribution mechanism
– allows single producer to send a message to one user or potentially
hundreds of thousands of consumers
Clients "publish" to a specific topic or channel
Channels are “subscribed” to by clients to consume msgs
No restriction on the role of a client
– may be both a producer and consumer of a channel§
Introduction to Message-Oriented Middleware 20
21. Hierarchical Channels
Hierarchical channels (topics)
– Destination grouping mechanism in pub/sub
model
– Structure allows channels to be defined in a
hierarchical fashion
– Each sub-channel offers a more granular
selection of the messages contained in its parent
– Clients subscribe to the most appropriate level of
channel
In large-scale systems, grouping of
messages into related types (i.e. into
channels) helps to manage large volumes
of different messages
Introduction to Message-Oriented Middleware 21
22. Comparsion of Models
Most messaging objectives can be achieved
using either model or combination of both
Fundamental difference
– publish/subscribe model
• every consumer to a topic/channel will receive a
message published to it
– point-to-point model
• only one consumer will receive it
Topics can be used to categorize different
types of messages
Pub/Sub model is more powerful messaging
model for flexibility, but it is more complex
Introduction to Message-Oriented Middleware 22
24. Programming MOM
A large number of MOM implementations exist
– WebSphere MQ (formerly MQSeries), TIBCO, SonicMQ,
Hermes, SIENA, Gryphon, JEDI, REBECCA, OpenJMS, etc
Java Message Service (JMS)
– Common way for Java programs to create, send, receive and
read MOM messages
– JMS specification defines
• general purpose Application Programming Interface (API)
• set of semantics that describe the interface and general
behaviour of a messaging service
Write code once using API and plug-in desired MOM
– makes client-messaging code portable between MOM
providers
Introduction to Message-Oriented Middleware 24
25. Service Oriented Architecture
The problems and obstacles encountered during system
integration pose major challenges for IT departments:
“70% of the average IT department budget is devoted to data
integration projects”
–IDC
“PowerPoint engineers make integration look easy with lovely
cones and colorful boxes”
– Sean McGrath, CTO, Propylon
“A typical enterprise will devote 35% - 40% of its programming
budget to programs whose purpose is solely to transfer
information between different databases and legacy systems”-
Gartner Group
Introduction to Message-Oriented Middleware 25
26. Service Oriented Architecture
MOM used to create highly open and flexible systems
that allow the seamless integration of subsystems
MOM solves many of the transport issues with integration
However, major problems still exist with the
representation of data, its format and structure
To develop a truly open system, MOM requires the
assistance of additional technologies such as XML and
Web Services
Introduction to Message-Oriented Middleware 26
27. XML
Programming language and platform independent
format for representing data
– eliminates any networking, operating system or platform
binding that a binary proprietary protocol would use
Once data is expressed in XML, it is trivial to change
the format
To use XML as a message exchange medium,
standard formats need to be defined to structure the
XML messages
– i.e. ebXML andOASIS Universal Business Language (UBL)
• With UBL, you convert your internal message formats to
the standard UBL format and export to the external
environment
Introduction to Message-Oriented Middleware 27
28. Web Services
Web Services
– platform and language independent standards
defining protocols for heterogeneous integration
Can be seen in a number of ways
– Business-to-business/enterprise application
integration tool
– natural evolution of basic RPC mechanism
A key benefit of a web services deployment is that
they act as a facade to the underlying language or
platform
Web services which are often touted as a
replacement for traditional RPC
– Viewed in this light they still suffer from many of its
shortcomings
Introduction to Message-Oriented Middleware 28
29. SOAP
The Simple Object Access Protocol (SOAP)
– simple and lightweight mechanism for exchanging structured
and typed information between peers in a decentralized,
distributed environment using XML
– allows you to bind it to a transport mechanism
• SMTP, HTTP, or JMS
Has a number of uses
– document exchange protocol
– heterogeneous interoperability standard
– wire protocol standard (something not defined in JMS)
– RPC mechanism
In this talk we SOAP see as a document exchange
protocol between heterogeneous systems
Introduction to Message-Oriented Middleware 29
30. Developing SOAs
Through a combination of XML, SOAP and WS, we
are able to create Service-Oriented Architectures
(SOA)
A service is a set of input messages sent to a single
or composition of objects, with the return of causally
related output messages
–fundamental design concept is to reduce
processing to logic black boxes
–standard XML format for input and output formats
An important aspect of SOAs is message centric
structure
Once initial infrastructure created for the architecture,
the amount of effort to connect to further systems is
minimal
Introduction to Message-Oriented Middleware 30
31. XML Transformation Pipelines
Where message formats differ
– XML based integration can convert the message to
and from the format using XML transformation pipeline
– data transformation can be seen as just another
assembly line problem
– with transformations taking place outside of the
applications it a non-invasive method of integration
Introduction to Message-Oriented Middleware 31
33. SOA Summary
XML + Web Services + MOM
= Open Systems
Service Oriented Architecture
Introduction to Message-Oriented Middleware 33
34. Summary
All good Distributed Application Deployments (DAD)s
need a good Message-Oriented Middleware (MOM)
-Anon.
Introduction to Message-Oriented Middleware 34
Editor's Notes
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\