Notes on a Message Passing Architecture Jean-Lou Dupont jl >at< jldupont dot com http://jldupont.blogspot.com/
Introduction <ul><li>These notes are mainly aimed at the architectural issues related to a  Message Passing  design and mo...
Single Thread Message Passing <ul><li>Obviously, the Application within a Thread can generate Events to other Threads </li...
Why Message Passing? <ul><ul><li>It is a good practice when it comes to following the  Separation of Concern  architectura...
What are the challenges? <ul><ul><li>A Thread (of execution) is &quot;synchronous&quot; in nature </li></ul></ul><ul><ul><...
Event Flow <ul><ul><li>A thread needs to  pull  message events (e.g. from other threads) through an &quot;Event Manager&qu...
What is a  Message ? <ul><li>In the context of this document, a  message  is really an idiom for representing  information...
Properties of a Message system <ul><ul><li>A &quot; Message-type &quot; is  immutable </li></ul></ul><ul><ul><ul><li>the s...
Why &quot;anonymity&quot; ? <ul><li>Because &quot;private&quot; messaging is already covered extensively  </li></ul><ul><u...
P2MP -  hardware hardware  view <ul><li>&quot;Point-to-Multi-Point&quot; message delivery  </li></ul><ul><ul><li>A &quot;s...
P2P and Broadcast <ul><li>&quot;Point-to-Point&quot; messaging is a degenerate case of P2MP </li></ul><ul><ul><li>1 source...
P2MP - software view <ul><ul><li>Execution goes from component X to the Message Bus &quot;object&quot; (method call #1) on...
P2MP - examples <ul><li>Example messages: </li></ul><ul><ul><li>&quot; Username Changed &quot; </li></ul></ul><ul><ul><li>...
P2P messaging <ul><ul><li>&quot;Point-to-Point&quot; messaging is a degenerate case of P2MP </li></ul></ul><ul><ul><ul><li...
Modeling &quot;Method Call&quot; <ul><ul><li>In a &quot;method call&quot;, execution control follows temporarily (from X t...
Method Call - adapted <ul><ul><li>If one really wishes to extend the Message Passing approach to method calls, it can easi...
Method Call &quot;adapted&quot; ... but why? <ul><li>What are the benefits of this design? </li></ul><ul><ul><li>Extensibi...
Extensibility <ul><ul><li>Segregation of data flows </li></ul></ul><ul><ul><ul><li>&quot;Closed Groups&quot; </li></ul></u...
Upcoming SlideShare
Loading in …5
×

Notes On a Message Passing Architecture

2,296 views

Published on

Notes on a Message Passing design architecture

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,296
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
43
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Notes On a Message Passing Architecture

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

×