Notes On a Message Passing Architecture
Upcoming SlideShare
Loading in...5
×
 

Notes On a Message Passing Architecture

on

  • 2,505 views

Notes on a Message Passing design architecture

Notes on a Message Passing design architecture

Statistics

Views

Total Views
2,505
Views on SlideShare
2,498
Embed Views
7

Actions

Likes
1
Downloads
26
Comments
0

2 Embeds 7

http://www.slideshare.net 6
http://www.slashdocs.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Notes On a Message Passing Architecture Notes On a Message Passing Architecture Presentation Transcript

  • Notes on a Message Passing Architecture Jean-Lou Dupont jl >at< jldupont dot com http://jldupont.blogspot.com/
  • Introduction
    • These notes are mainly aimed at the architectural issues related to a Message Passing design and more specifically in the context of a single thread of execution .
  • Single Thread Message Passing
    • Obviously, the Application within a Thread can generate Events to other Threads
    - Code execution is passed from the &quot;Event Manager&quot; to the &quot;Application&quot; along with details of the originating event - The &quot;Application&quot; subscribes to the &quot;events&quot; it wishes to act upon
  • Why Message Passing?
      • It is a good practice when it comes to following the Separation of Concern  architectural principle
        • Loose Coupling helps scalability
        • Helps testability
        • Helps robustness
        • Helps model the &quot;real world&quot;
  • What are the challenges?
      • A Thread (of execution) is &quot;synchronous&quot; in nature
        • Execution flow is continuous from the thread's perspective
      • Events are &quot;asynchronous&quot; in nature
        • Events need to be &quot;serialized&quot; for consumption in a Thread
    •  
  • Event Flow
      • A thread needs to pull  message events (e.g. from other threads) through an &quot;Event Manager&quot; (sometimes called Event/Message loop)
  • What is a Message ?
    • In the context of this document, a message  is really an idiom for representing information   packaged for distribution within a software system.
  • Properties of a Message system
      • A &quot; Message-type &quot; is immutable
        • the semantics associated with a message is required to be constant
      • A &quot;Message-type&quot; is public
        • no one component owns/controls the type
        • any component can source/emit a message of a type
      • A &quot;Message-type&quot; can have 0 or more subscribers
      • A Message is
      • anonymous
      • anonymous
        • The message source isn't identifiable
        • There is no explicit &quot;destination(s)&quot;
    • ( at least those are the properties I look for in a bus based message system )
  • Why &quot;anonymity&quot; ?
    • Because &quot;private&quot; messaging is already covered extensively 
      • Method Calls
      • Sockets
      • Files
      • etc.
  • P2MP - hardware hardware view
    • &quot;Point-to-Multi-Point&quot; message delivery 
      • A &quot;source&quot; X 
      • emits
      • emits a message (M) onto a &quot;bus&quot;
      • Multiple &quot;subscribers&quot; (Y, Z) receive the message
  • P2P and Broadcast
    • &quot;Point-to-Point&quot; messaging is a degenerate case of P2MP
      • 1 source, 1 subscriber
      • if a conversation must really stay &quot;private&quot; (i.e. closed group), then
        • Another bus  can be used
        • Another design technique can be used (e.g. the usual method-call)
      • Broadcasting is a special case of P2MP
        • Can &quot;auto-subscribe&quot; all - useful for critical system events e.g. &quot;shutdown&quot;
  • P2MP - software view
      • Execution goes from component X to the Message Bus &quot;object&quot; (method call #1) onwards to component Y and Z successively
      • At the end of the chain, execution control is returned to the &quot;message emitter&quot; i.e. component X
  • P2MP - examples
    • Example messages:
      • &quot; Username Changed &quot;
      • &quot; Application shutting down &quot;
      • &quot; Network connectivity lost &quot;
      • etc.
    • Many components of an application can be interested in subscribing to a &quot;message type&quot; e.g. the &quot;network connectivity lost&quot; message can be interesting to:
      • Statistics Agent
      • Communication Agent
      • User Feedback Agent (GUI)
  • P2P messaging
      • &quot;Point-to-Point&quot; messaging is a degenerate case of P2MP
        • P2MP with only 1 subscriber
      •   Not to be confused with &quot;method call with return value&quot; (see next slides)
  • Modeling &quot;Method Call&quot;
      • In a &quot;method call&quot;, execution control follows temporarily (from X to Y in the example) a different path and upon return, a value is passed back (nothing new here, this is how procedural programming works)
      •  This process can also be adapted to a message bus
  • Method Call - adapted
      • If one really wishes to extend the Message Passing approach to method calls, it can easily be done through the &quot;bus object&quot; discussed previsouly
      • #1 - X emits  &quot;username?&quot; msg
      • #2 - msg is relayed to Y
      • #3 - Y emits &quot;username&quot; msg
      • #4 - bus object relays to X
      • Execution control unwinds  (returns back) to X step wise e.g.
        • 4 -> 3 -> 2 -> 1  
  • Method Call &quot;adapted&quot; ... but why?
    • What are the benefits of this design?
      • Extensibility - it is easy to add &quot;subscribers&quot; when needed
      • Maintainability - adding &quot;subscribers&quot; can be done without touching existing code of other components
      • Debugging - monitoring of &quot; method calls&quot; is as easy as subscribing a component
    • ... but there is no such thing as a &quot;silver bullet&quot;.
  • Extensibility
      • Segregation of data flows
        • &quot;Closed Groups&quot;
        • Further Separation of Concern :-)
    • &quot;Bus based Messaging&quot; can easily be extended as a &quot;network&quot; would
      • bridging between busses