Top Banner
Introduction to Message-Oriented Middleware Invited Talk to University of Limerick February ‘05 Edward Curry National University of Ireland, Galway [email protected]
34

Introduction to Message-Oriented Middleware

Jan 26, 2015

Download

Technology

Edward Curry

A talk given to the University of Limerick in 2005 on Message-Oriented Middleware
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware

Invited Talk to University of Limerick February ‘05

Edward Curry

National University of Ireland, Galway

[email protected]

Page 2: Introduction to Message-Oriented Middleware

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

Page 3: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 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

Page 4: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 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

Page 5: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 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

Page 6: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 6

Synchronous Communication

Page 7: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 7

Asynchronous Communication

Page 8: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 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)

Page 9: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 9

RPC Deployment

Page 10: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 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

Page 11: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 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

Page 12: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 12

MOM Deployment

Page 13: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 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

Page 14: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 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

Page 15: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 15

Overview MOM

MOM Overview– Message Queues– Messaging Models

• Point-to-Point & Publish/Subscribe• Comparison of Messaging Models

Page 16: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 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

Page 17: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 17

Message Queues

Page 18: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 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

Page 19: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 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

Page 20: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 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§

Page 21: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 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

Page 22: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 22

Comparsion of ModelsMost 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 itTopics can be used to categorize different types

of messages

Pub/Sub model is more powerful messaging model for flexibility, but it is more complex

Page 23: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 23

MOM Services

Message Filtering

Transactions

Reliable Message Delivery

Guaranteed Message Delivery

Message Formats

Load Balancing

Clustering

Page 24: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 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

Page 25: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 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

Page 26: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 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

Page 27: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 27

XMLProgramming 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

Page 28: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 28

Web ServicesWeb 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 mechanismA 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

Page 29: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 29

SOAPThe 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

Page 30: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 30

Developing SOAsThrough 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 formatsAn important aspect of SOAs is message centric

structureOnce initial infrastructure created for the architecture,

the amount of effort to connect to further systems is minimal

Page 31: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 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

Page 32: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 32

Sample SOA Deployment

Page 33: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 33

SOA Summary

SystemsOpen reArchitectu Oriented Service

MOM Services Web XML

Page 34: Introduction to Message-Oriented Middleware

Introduction to Message-Oriented Middleware 34

Summary

All good Distributed Application Deployments (DAD)s

need a good Message-Oriented Middleware (MOM)

-Anon.