Notes On a Message Passing Architecture
?Download as PPT, PDF?
2 likes?1,104 views
This document discusses message passing architecture in the context of a single thread of execution. It describes how a thread can generate and receive asynchronous events through an event manager. Some benefits of message passing include loose coupling, scalability, testability and robustness. Challenges include synchronizing asynchronous events within a thread. The document also outlines properties of message-based systems, including immutable and public message types, anonymous message sources, and point-to-multipoint delivery to multiple subscribers.
Notes On a Message Passing Architecture
- 1. Notes on a Message Passing Architecture Jean-Lou Dupont jl >at< jldupont dot com http://jldupont.blogspot.com/
- 2. 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 .
- 3. Single Thread Message Passing Obviously, the Application within a Thread can generate Events to other Threads - Code execution is passed from the "Event Manager" to the "Application" along with details of the originating event - The "Application" subscribes to the "events" it wishes to act upon
- 4. 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 "real world"
- 5. What are the challenges? A Thread (of execution) is "synchronous" in nature Execution flow is continuous from the thread's perspective Events are "asynchronous" in nature Events need to be "serialized" for consumption in a Thread ?
- 6. Event Flow A thread needs to pull ?message events (e.g. from other threads) through an "Event Manager" (sometimes called Event/Message loop)
- 7. 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.
- 8. Properties of a Message system A " Message-type " is immutable the semantics associated with a message is required to be constant A "Message-type" is public no one component owns/controls the type any component can source/emit a message of a type A "Message-type" can have 0 or more subscribers A Message is anonymous anonymous The message source isn't identifiable There is no explicit "destination(s)" ( at least those are the properties I look for in a bus based message system )
- 9. Why "anonymity" ? Because "private" messaging is already covered extensively? Method Calls Sockets Files etc.
- 10. P2MP - hardware hardware view "Point-to-Multi-Point" message delivery? A "source" X? emits emits a message (M) onto a "bus" Multiple "subscribers" (Y, Z) receive the message
- 11. P2P and Broadcast "Point-to-Point" messaging is a degenerate case of P2MP 1 source, 1 subscriber if a conversation must really stay "private" (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 "auto-subscribe" all - useful for critical system events e.g. "shutdown"
- 12. P2MP - software view Execution goes from component X to the Message Bus "object" (method call #1) onwards to component Y and Z successively At the end of the chain, execution control is returned to the "message emitter" i.e. component X
- 13. P2MP - examples Example messages: " Username Changed " " Application shutting down " " Network connectivity lost " etc. Many components of an application can be interested in subscribing to a "message type" e.g. the "network connectivity lost" message can be interesting to: Statistics Agent Communication Agent User Feedback Agent (GUI)
- 14. P2P messaging "Point-to-Point" messaging is a degenerate case of P2MP P2MP with only 1 subscriber ? Not to be confused with "method call with return value"?(see next slides)
- 15. Modeling "Method Call" In a "method call", 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
- 16. Method Call - adapted If one really wishes to extend the Message Passing approach?to method calls, it can easily be done through the "bus object" discussed previsouly #1 - X emits ?"username?" msg #2 - msg is relayed to Y #3 - Y emits "username" msg #4 - bus object relays to X Execution control unwinds ?(returns back) to X step wise e.g. 4 -> 3 -> 2 -> 1 ?
- 17. Method Call "adapted" ... but why? What are the benefits of this design? Extensibility - it is easy to add "subscribers" when needed Maintainability - adding "subscribers" can be done without touching existing code of other components Debugging - monitoring of " method?calls" is as easy as subscribing a component ... but there is no such thing as a "silver bullet".
- 18. Extensibility Segregation of data flows "Closed Groups" Further Separation of Concern :-) "Bus based Messaging" can easily be extended as a "network" would bridging between busses