Dear list and conference members, Let me try to clarify additional aspects of the paper.In order to fully undertand MDP Messaging and its consequences we need to think in terms of abstractions. On the other hand, I'd like to use analogies from the real world to convey the concepts. Also keep in mind that the software models should accuratly mimic the reality they try to represent:
"Since computer applications seek to model the real world, it is only natural to design and write applications using a messaging approach. We can argue that messaging provides a better and more accurate representation (i.e. model) of the real world." In abstract terms, a message can be any piece of information: "Message: any piece of information (i.e. data) that needs to be interchanged between sender and recipient." Messages can be anything (any type of energy, light, heat, soundm electronic transactions, checks, receipts, etc). An analog signal is also a message (information) when you think in terms of the concept/abstraction. In terms of software, a message can be any type of object needed to represent the information. In regards to the analogy of watching other people doing something, it can be said that you are actually receivig a stream of visual messages (light). Try to close you eyes and the flow of messaging will stop. You can also say that the light (stream of messages) is being reflected off their bodies before reaching your eyes. A component of your body (eye) has been designed to receive all those messages and transfer them to another component (brain) via your nervous system (messaging pipeline). This also follows a messaging pattern/model. As expected this is very similar to the MDP model. Messaging is everywhere. This analogy can be used to illustrate the Messaging concepts. I agree with the comments regarding the planets (gravitational field). A simulation of this doesn't use messaging. This is not inconsistent with the paper. Messaging is used for the >communication< between entities as the following paragraph describes. On the other hand, the simulation of the planets requires another concept found in the real world (gravity). In order to achieve a complete/realistic of model of this scenario you need to add gravity to your model. Messaging is strictly use for communication (transference of information) within the model. "Conventional implementations, not based on a messaging model, are unable to provide this level of encapsulation, decoupling and reusability. MDP and the messaging model address these shortcomings while at the same time reducing complexity. Actually we can argue that messaging should be the principal mechanism of communication since components are independent entities. Therefore they should be modeled and treated as such, in order to accurately mimic reality." It says "we can ague" because there are other mechanisms that can be used. Remote Procedures Calls (RPC) for instance. RPCs can be used for communication between distributed components. Some people may "argue" that RPCs should be the mechanism to be used. I respect their point of view. On the other hand, I'll have to argue based on a different point of view (messaging model/paradigm). Actually most of the traditional technologies are based on RPCs. The paper dicusses the differences between (Remote procedure calls) RPC and MDP messaging. I'm afraid that RPCs are not based a complete/accurate model. This produces complexity, limitations and shortcomings. By the way, people may use the term "messaging" when they talk about distributed systems. Most of the time they are talking about Remote Procedure Calls. As the paper discusses there is a clear difference between RPCs and MDP messaging: RPC (p1, p2, p3, ..., pn) Remote Procedure Call with n paramenters and sendMessage (component, message) where component is the remote component and message is the object (message) to be passed. The term "messaging" is probably used loosely within the context of Remote Procedure Calls (RPCs). We can argue that is not "true" messaging in the strict sense of the word. The following paper includes complete information: MDP and a distributed Component/Service Model https://jt.dev.java.net/files/documents/5553/149793/MDPdistributedModel.pdf I hope this message clarifies additional aspects of the paper. In summary we need to think in terms of abstractions and a messaging paradigm. On the other hand, analogies from the real world help visualize and convey the concepts involved. The software model should be an accurate portrait of the reality being represented. The MDP messaging model provides a more complete/accurate model of reality. I look forward to any follow-up comments/"messaging" that you may have based on this email. Best regards
_______________________________________________ telecom-patterns mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/telecom-patterns
