Al, I'll be glad to clarify. The main purpose of this discussion is to clarify all the aspects of MDP based on facts. I apreciate the degree detail found in your questions based on the scope of the messaging design pattern (MDP) paper. I'm also glad that we are thinking in terms of a realistic model. As I said earlier, I believe this is a good way to fully understand the messaging design pattern (concept, consequences, implementation, best practices, applicability, cost, etc. After all, MDP exists because messaging is part of reality.
Based on a realistic model, I can frame your questions and quickly give you answers: a) In the context of reality, messaging and proxy are two separate and distinct concepts/abstractions. Messaging does not require a proxy (or messenger). Direct messaging/communication is possible. On the other hand, they usually work cooperatively. b) The technical literature covers two types of messaging: synchronous and asynchronous. It is true that many of the countless real-world analogies use asynchonous messaging (human speech, email, postal services, etc). On the other hand, many of the more widely-known communications protocols operate synchronously. The HTTP protocol used in the World Wide Web and in web services offers an examples where a user sends a request for a web page and then waits for a reply. Both modes of communication are useful from a practical standpoint. The paper covers both styles of messaging. Synchronous messaging does not require a queue or separate threading mechanism. Our communication with a computer (browser, command line, etc) can also be viewed as synchronous communication. The following is the simplest form of messaging: - sender: sendMessage (component, message) // Synchronous messaging without message queue. - receiver: processMessage (message) c) I'm not sure I completely understood you next question. I believe that you are looking for a comparison between messaging and conventional parameter passing. It is true, procedure calls transfer information via parameters. On the other hand, we can argue that it is not "real messaging" because in reality, component, message and messaging mechanism are entities fully independent and decoupled. Parameter passing doesn't meet this criteria. This results in limitations and drawbacks. It is sort of artificial. As a consecuence of messaging we are able to realize many advantages. As we all agree: simplicity of concept, decoupling, interoperability, scalability, etc. I'll elaborate on these answers. I'll use your real-world analogy. The email system uses the messaging abstraction (asynchronous messaging). Although they are related, there is a difference between the messaging abstraction and the MDP model. They are separate entities. Also, MDP covers both: synchornous and asynchornous messaging. Let's say that you want to send a message to a second friend. Your friend acts as a proxy. In general, the role of proxy is the transference of information (messaging) to the real subject. On the other hand, notice that messaging is also present here. We all agree that messaging is everywhere (ubiquitous). Keep in mid that messaging is about transference of information. You will be challenged to find processes or applications where infomation (messaging) is not transferred. Proxies usually need to communicate with the subject. This calls for messaging. Messaging and Proxy are also sort of atomic/primitive concepts. A complete model should include both concepts. If we overlook the appropriate concepts, we'll find limitations and drawbacks (RPC abstraction with parameter passing). On the other hand, you can have direct messaging with the use of a Proxy or messenger. Also notice the close relationship between information and messaging. You mentioned the observer pattern in a previous email. Observer requires notifications. These notifications also imply messaging. The same principles use in your email analogy can be used for the implementation of a complete distributed service/model based on MDP messaging. Both problems follow the same pattern. The second MDP paper covers this distributed service/component model. The MDP papers also discusses how messaging can be utilized for the implementation of other design patterns. Again this is feasible and recommendable because as we all agree, messaging is everywhere. Also, design patterns generally consists of several components that need to communicate with each other. This communication implies messaging. Conceptually there is clear differences between messaging and parameter passing (procedure calls): 1) RPC1 (parameter1, parameter2, , parametern) RPC2 (parameter1, parameter2, , parametern) RPCN (parameter1, parameter2, , parametern) 2) sendMessage (proxy, message) where proxy is the local proxy to the remote component. Notice the clear separation between components, message and messaging mechanism (option 2). It is not the case for the conventional Remote Procedure Calls. If you look at the real-world messaging analogies, you will find a clear separation. Notice that message (email message, word, mail piece ), entities and the communication mechanism (email system, sound, postal service ) are fully independent and decoupled. A realistic model helps clarify the difference between "true" messaging and parameter passing. It should be clear that Remote Procedure Calls are disconnected from the reality they seek to represent. The RPC abstraction is disconnected from reality which is based on a messaging abstraction. Feel free to send any follow-up comments or questions. Regards, Al --- On Wed, 2/9/11, Al Boldi <[email protected]> wrote: From: Al Boldi <[email protected]> Subject: Re: [patterns-discussion] Fw: RE: MDP feasibility questions (processMessage) To: "Messaging Design Pattern" <[email protected]>, "phillip henry" <[email protected]> Cc: [email protected] Date: Wednesday, February 9, 2011, 1:25 PM Messaging Design Pattern wrote: > As a point of information, a messaging queue is not needed unless we are > dealing with asynchronous messaging and/or multithreading. We haven't > discussed this so far. The versioning example only discusses synchronous > communication (no message queue required). processMessage (message) is the > only API/functionality required. In the absence of a messaging queue, your MDP becomes a mere PROXY Pattern. If your aim is only to de-couple systems, then there are a few other patterns already available to aid in this respect. By definition, messaging is asynchronous, and to put it in your words: "In REALITY the message you are reading right now has been delivered to you through many messaging queues, and to mirror this REALITY we use the MDP." So when you start to strip the MDP from its core functionality, which is message queuing for the sake of message management, you get the sub-patterns that make-up the MDP, i.e.: processMessage(message) is not the MDP, it's a sub-pattern, a PROXY Pattern in this case. Also, the mere fact that you are sending a message does not constitute messaging, or else any function parameter could be construed as messaging. I think a clarification on your part would be advisable. Thanks! -- Al
_______________________________________________ patterns-discussion mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion
