SlideShare a Scribd company logo
1 of 34
Introduction to
Message-Oriented Middleware


  Invited Talk to University of Limerick
               February ‘05



              Edward Curry
  National University of Ireland, Galway
             edcurry@acm.org
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
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
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
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
Synchronous Communication




 Introduction to Message-Oriented Middleware   6
Asynchronous Communication




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




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




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

 MOM Overview
  – Message Queues
  – Messaging Models
    • Point-to-Point & Publish/Subscribe
    • Comparison of Messaging Models




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




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

Message Filtering
Transactions
Reliable Message Delivery
Guaranteed Message Delivery
Message Formats
Load Balancing
Clustering


        Introduction to Message-Oriented Middleware   23
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
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
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
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
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
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
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
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
Sample SOA Deployment




Introduction to Message-Oriented Middleware   32
SOA Summary




XML + Web Services + MOM
                              = Open Systems
Service Oriented Architecture




      Introduction to Message-Oriented Middleware   33
Summary



All good Distributed Application Deployments (DAD)s
 need a good Message-Oriented Middleware (MOM)
                                                      -Anon.




        Introduction to Message-Oriented Middleware      34

More Related Content

What's hot

Web Services - Architecture and SOAP (part 1)
Web Services - Architecture and SOAP (part 1)Web Services - Architecture and SOAP (part 1)
Web Services - Architecture and SOAP (part 1)
Martin Necasky
 

What's hot (20)

Distributed System-Multicast & Indirect communication
Distributed System-Multicast & Indirect communicationDistributed System-Multicast & Indirect communication
Distributed System-Multicast & Indirect communication
 
Chp2 - SOA
Chp2 - SOAChp2 - SOA
Chp2 - SOA
 
Introduction To RabbitMQ
Introduction To RabbitMQIntroduction To RabbitMQ
Introduction To RabbitMQ
 
Rabbitmq basics
Rabbitmq basicsRabbitmq basics
Rabbitmq basics
 
Message Broker System and RabbitMQ
Message Broker System and RabbitMQMessage Broker System and RabbitMQ
Message Broker System and RabbitMQ
 
Soa & services web
Soa & services webSoa & services web
Soa & services web
 
Chp3 - Les Services Web
Chp3 - Les Services WebChp3 - Les Services Web
Chp3 - Les Services Web
 
SOA
SOASOA
SOA
 
Overview of Message Queues
Overview of Message QueuesOverview of Message Queues
Overview of Message Queues
 
Event-driven Architecture
Event-driven ArchitectureEvent-driven Architecture
Event-driven Architecture
 
Microservice Architecture
Microservice ArchitectureMicroservice Architecture
Microservice Architecture
 
RabbitMQ.ppt
RabbitMQ.pptRabbitMQ.ppt
RabbitMQ.ppt
 
Event-Driven Architecture (EDA)
Event-Driven Architecture (EDA)Event-Driven Architecture (EDA)
Event-Driven Architecture (EDA)
 
Introduction aux systèmes répartis
Introduction aux systèmes répartisIntroduction aux systèmes répartis
Introduction aux systèmes répartis
 
Anypoint mq (mulesoft) introduction
Anypoint mq (mulesoft)  introductionAnypoint mq (mulesoft)  introduction
Anypoint mq (mulesoft) introduction
 
Web Services - Architecture and SOAP (part 1)
Web Services - Architecture and SOAP (part 1)Web Services - Architecture and SOAP (part 1)
Web Services - Architecture and SOAP (part 1)
 
Enterprise Integration Patterns
Enterprise Integration PatternsEnterprise Integration Patterns
Enterprise Integration Patterns
 
What is RabbitMQ ?
What is RabbitMQ ?What is RabbitMQ ?
What is RabbitMQ ?
 
[@NaukriEngineering] Messaging Queues
[@NaukriEngineering] Messaging Queues[@NaukriEngineering] Messaging Queues
[@NaukriEngineering] Messaging Queues
 
Messaging with RabbitMQ and AMQP
Messaging with RabbitMQ and AMQPMessaging with RabbitMQ and AMQP
Messaging with RabbitMQ and AMQP
 

Viewers also liked

Karangan ilmiah ( harits w)
Karangan ilmiah ( harits w)Karangan ilmiah ( harits w)
Karangan ilmiah ( harits w)
Rietz Wiguna
 
Clase cultura inglesa final
Clase cultura inglesa finalClase cultura inglesa final
Clase cultura inglesa final
Cyntia Ocañas
 
Etika Bisnis ( kritik iklan)
Etika Bisnis ( kritik iklan)Etika Bisnis ( kritik iklan)
Etika Bisnis ( kritik iklan)
Rietz Wiguna
 
shawnees geometry
shawnees geometryshawnees geometry
shawnees geometry
roslynroom3
 
I kursas bakalaurai
I kursas bakalauraiI kursas bakalaurai
I kursas bakalaurai
zzzdaina
 
Centro Estetico Vicenza - B-IO
Centro Estetico Vicenza - B-IOCentro Estetico Vicenza - B-IO
Centro Estetico Vicenza - B-IO
vitalitysalus
 
Presentation by my Group
Presentation by my GroupPresentation by my Group
Presentation by my Group
kipronobrian
 
Boolean Operators
Boolean OperatorsBoolean Operators
Boolean Operators
gvsulib
 

Viewers also liked (20)

Karangan ilmiah ( harits w)
Karangan ilmiah ( harits w)Karangan ilmiah ( harits w)
Karangan ilmiah ( harits w)
 
1. lipid
1. lipid1. lipid
1. lipid
 
Postgre Diagram
Postgre DiagramPostgre Diagram
Postgre Diagram
 
Clase cultura inglesa final
Clase cultura inglesa finalClase cultura inglesa final
Clase cultura inglesa final
 
第一课 信息概念
第一课 信息概念第一课 信息概念
第一课 信息概念
 
Etika Bisnis ( kritik iklan)
Etika Bisnis ( kritik iklan)Etika Bisnis ( kritik iklan)
Etika Bisnis ( kritik iklan)
 
Bina button di Report menggunakan Macro Builder
Bina button di Report menggunakan Macro Builder Bina button di Report menggunakan Macro Builder
Bina button di Report menggunakan Macro Builder
 
shawnees geometry
shawnees geometryshawnees geometry
shawnees geometry
 
数据监测体系
数据监测体系数据监测体系
数据监测体系
 
dmexco SDL
dmexco SDLdmexco SDL
dmexco SDL
 
I kursas bakalaurai
I kursas bakalauraiI kursas bakalaurai
I kursas bakalaurai
 
Презентация
ПрезентацияПрезентация
Презентация
 
RFID
RFIDRFID
RFID
 
Lead for trainers ls test2
Lead for trainers  ls test2Lead for trainers  ls test2
Lead for trainers ls test2
 
Slovak Consular Services in Belfast, 7 and 8 April_2014
Slovak Consular Services in Belfast, 7 and 8 April_2014Slovak Consular Services in Belfast, 7 and 8 April_2014
Slovak Consular Services in Belfast, 7 and 8 April_2014
 
Centro Estetico Vicenza - B-IO
Centro Estetico Vicenza - B-IOCentro Estetico Vicenza - B-IO
Centro Estetico Vicenza - B-IO
 
Presentation by my Group
Presentation by my GroupPresentation by my Group
Presentation by my Group
 
Boolean Operators
Boolean OperatorsBoolean Operators
Boolean Operators
 
Write your own Web Copy - Webinar with Professional Copywriter, Jackie Barrie
Write your own Web Copy - Webinar with Professional Copywriter, Jackie BarrieWrite your own Web Copy - Webinar with Professional Copywriter, Jackie Barrie
Write your own Web Copy - Webinar with Professional Copywriter, Jackie Barrie
 
Wordcamp 2011-new1
Wordcamp   2011-new1Wordcamp   2011-new1
Wordcamp 2011-new1
 

Similar to Introduction to Message-Oriented Middleware

1. Overview of Distributed Systems
1. Overview of Distributed Systems1. Overview of Distributed Systems
1. Overview of Distributed Systems
Daminda Herath
 
MC0085 – Advanced Operating Systems - Master of Computer Science - MCA - SMU DE
MC0085 – Advanced Operating Systems - Master of Computer Science - MCA - SMU DEMC0085 – Advanced Operating Systems - Master of Computer Science - MCA - SMU DE
MC0085 – Advanced Operating Systems - Master of Computer Science - MCA - SMU DE
Aravind NC
 

Similar to Introduction to Message-Oriented Middleware (20)

Enterprise messaging with jms
Enterprise messaging with jmsEnterprise messaging with jms
Enterprise messaging with jms
 
Designing Application over mobile environment
Designing Application over mobile environmentDesigning Application over mobile environment
Designing Application over mobile environment
 
1. Overview of Distributed Systems
1. Overview of Distributed Systems1. Overview of Distributed Systems
1. Overview of Distributed Systems
 
Mq Lecture
Mq LectureMq Lecture
Mq Lecture
 
MOM - Message Oriented Middleware
MOM - Message Oriented MiddlewareMOM - Message Oriented Middleware
MOM - Message Oriented Middleware
 
Manish tripathi-e-commerce-middleware
Manish tripathi-e-commerce-middlewareManish tripathi-e-commerce-middleware
Manish tripathi-e-commerce-middleware
 
12-middleware.ppt
12-middleware.ppt12-middleware.ppt
12-middleware.ppt
 
middleware
middlewaremiddleware
middleware
 
On MQ Series & JMS
On MQ Series & JMSOn MQ Series & JMS
On MQ Series & JMS
 
Message oriented middleware
Message oriented middlewareMessage oriented middleware
Message oriented middleware
 
Topic 5- Communications v1.pptx
Topic 5- Communications v1.pptxTopic 5- Communications v1.pptx
Topic 5- Communications v1.pptx
 
Inter-Process Communication in distributed systems
Inter-Process Communication in distributed systemsInter-Process Communication in distributed systems
Inter-Process Communication in distributed systems
 
Velocity Conference '13: Asynchronous messaging for performance optimization,...
Velocity Conference '13: Asynchronous messaging for performance optimization,...Velocity Conference '13: Asynchronous messaging for performance optimization,...
Velocity Conference '13: Asynchronous messaging for performance optimization,...
 
B0960512
B0960512B0960512
B0960512
 
MC0085 – Advanced Operating Systems - Master of Computer Science - MCA - SMU DE
MC0085 – Advanced Operating Systems - Master of Computer Science - MCA - SMU DEMC0085 – Advanced Operating Systems - Master of Computer Science - MCA - SMU DE
MC0085 – Advanced Operating Systems - Master of Computer Science - MCA - SMU DE
 
E health interoperability layer through kafka
E health interoperability layer through kafkaE health interoperability layer through kafka
E health interoperability layer through kafka
 
RabbitMQ.pptx
RabbitMQ.pptxRabbitMQ.pptx
RabbitMQ.pptx
 
Cis017 6 revision-2015_distributed
Cis017 6 revision-2015_distributedCis017 6 revision-2015_distributed
Cis017 6 revision-2015_distributed
 
Message passing in Distributed Computing Systems
Message passing in Distributed Computing SystemsMessage passing in Distributed Computing Systems
Message passing in Distributed Computing Systems
 
Ch06
Ch06Ch06
Ch06
 

Recently uploaded

+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
?#DUbAI#??##{{(☎️+971_581248768%)**%*]'#abortion pills for sale in dubai@
 

Recently uploaded (20)

GenAI Risks & Security Meetup 01052024.pdf
GenAI Risks & Security Meetup 01052024.pdfGenAI Risks & Security Meetup 01052024.pdf
GenAI Risks & Security Meetup 01052024.pdf
 
Apidays New York 2024 - The value of a flexible API Management solution for O...
Apidays New York 2024 - The value of a flexible API Management solution for O...Apidays New York 2024 - The value of a flexible API Management solution for O...
Apidays New York 2024 - The value of a flexible API Management solution for O...
 
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
 
Driving Behavioral Change for Information Management through Data-Driven Gree...
Driving Behavioral Change for Information Management through Data-Driven Gree...Driving Behavioral Change for Information Management through Data-Driven Gree...
Driving Behavioral Change for Information Management through Data-Driven Gree...
 
A Year of the Servo Reboot: Where Are We Now?
A Year of the Servo Reboot: Where Are We Now?A Year of the Servo Reboot: Where Are We Now?
A Year of the Servo Reboot: Where Are We Now?
 
TrustArc Webinar - Stay Ahead of US State Data Privacy Law Developments
TrustArc Webinar - Stay Ahead of US State Data Privacy Law DevelopmentsTrustArc Webinar - Stay Ahead of US State Data Privacy Law Developments
TrustArc Webinar - Stay Ahead of US State Data Privacy Law Developments
 
Understanding Discord NSFW Servers A Guide for Responsible Users.pdf
Understanding Discord NSFW Servers A Guide for Responsible Users.pdfUnderstanding Discord NSFW Servers A Guide for Responsible Users.pdf
Understanding Discord NSFW Servers A Guide for Responsible Users.pdf
 
Powerful Google developer tools for immediate impact! (2023-24 C)
Powerful Google developer tools for immediate impact! (2023-24 C)Powerful Google developer tools for immediate impact! (2023-24 C)
Powerful Google developer tools for immediate impact! (2023-24 C)
 
Automating Google Workspace (GWS) & more with Apps Script
Automating Google Workspace (GWS) & more with Apps ScriptAutomating Google Workspace (GWS) & more with Apps Script
Automating Google Workspace (GWS) & more with Apps Script
 
presentation ICT roal in 21st century education
presentation ICT roal in 21st century educationpresentation ICT roal in 21st century education
presentation ICT roal in 21st century education
 
From Event to Action: Accelerate Your Decision Making with Real-Time Automation
From Event to Action: Accelerate Your Decision Making with Real-Time AutomationFrom Event to Action: Accelerate Your Decision Making with Real-Time Automation
From Event to Action: Accelerate Your Decision Making with Real-Time Automation
 
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
 
🐬 The future of MySQL is Postgres 🐘
🐬  The future of MySQL is Postgres   🐘🐬  The future of MySQL is Postgres   🐘
🐬 The future of MySQL is Postgres 🐘
 
Apidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, Adobe
Apidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, AdobeApidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, Adobe
Apidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, Adobe
 
Partners Life - Insurer Innovation Award 2024
Partners Life - Insurer Innovation Award 2024Partners Life - Insurer Innovation Award 2024
Partners Life - Insurer Innovation Award 2024
 
Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024
Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024
Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024
 
What Are The Drone Anti-jamming Systems Technology?
What Are The Drone Anti-jamming Systems Technology?What Are The Drone Anti-jamming Systems Technology?
What Are The Drone Anti-jamming Systems Technology?
 
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
 
2024: Domino Containers - The Next Step. News from the Domino Container commu...
2024: Domino Containers - The Next Step. News from the Domino Container commu...2024: Domino Containers - The Next Step. News from the Domino Container commu...
2024: Domino Containers - The Next Step. News from the Domino Container commu...
 
How to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected WorkerHow to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected Worker
 

Introduction to Message-Oriented Middleware

  • 1. Introduction to Message-Oriented Middleware Invited Talk to University of Limerick February ‘05 Edward Curry National University of Ireland, Galway edcurry@acm.org
  • 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
  • 6. Synchronous Communication Introduction to Message-Oriented Middleware 6
  • 7. Asynchronous Communication Introduction to Message-Oriented Middleware 7
  • 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
  • 9. RPC Deployment Introduction to Message-Oriented Middleware 9
  • 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
  • 12. MOM Deployment Introduction to Message-Oriented Middleware 12
  • 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
  • 15. Overview MOM  MOM Overview – Message Queues – Messaging Models • Point-to-Point & Publish/Subscribe • Comparison of Messaging Models Introduction to Message-Oriented Middleware 15
  • 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
  • 17. Message Queues Introduction to Message-Oriented Middleware 17
  • 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
  • 23. MOM Services Message Filtering Transactions Reliable Message Delivery Guaranteed Message Delivery Message Formats Load Balancing Clustering Introduction to Message-Oriented Middleware 23
  • 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
  • 32. Sample SOA Deployment Introduction to Message-Oriented Middleware 32
  • 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

  1. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  2. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  3. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  4. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  5. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  6. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  7. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  8. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  9. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  10. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  11. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  12. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  13. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  14. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  15. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  16. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  17. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  18. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  19. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  20. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  21. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  22. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  23. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  24. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  25. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  26. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  27. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  28. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  29. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  30. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  31. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\
  32. Edward Curry, ARMAdA: Creating a Reflective Fellowship\\\\