Hi, I was in the PLoP 2010 writers workshop which also included the Messaging Design Pattern. Unfortunately the author didn't made it to the workshop. But I talked with other participants about the MDP.
My first impression was that someone had found a silver bullet. Huge claims were made, and I therefore expected that these were grounded on a solid foundation. Unfortunately, I couldn't find any proofs, but only more claims and examples which didn't tell me why it is better to you use MDP here instead of conventional solutions. Actually, I miss the forces and I miss the real and general problem(s) (which can't be solved in other ways effectively). It is true that messaging is everywhere around us and therefore part of the real world. But, as the author states himself in the last mail, so are many other things. So the argument that because messaging is part of the real world and should therefore also be part of the software is imho not applicable.The other question (which is not discussed by the author) is: represents MDP the messaging concept in an appropriate way? Why are conventional interfaces (or other known techniques) not enough? I also would like to see a discussion of the impact of the obvious overhead of defining message formats AND how this can be shared between components. In my opinion, components using MDP are syntactically decoupled, but at the same time introduce a much higher semantic coupling. Which one is worse? Also, if the amount of different possible messages handled by one MDP-interface increases, the complexity to handle these also increases (if-then chains or similar solutions). This is not discussed in the paper. The example given is really simple, but triggers more questions: if MDP is used for the Proxy, why aren't all messages send to the proxy sent via the messenger (as expected)? setURL and setClassname still have to be called directly, so coupling is not decreased here (as claimed). The program has to know that the proxy only can handle one message and it therefore doesn't has to provide a messagetype, but only the message-string. This is semantic coupling. The same goes for that the program has to know that this message returns a String. What happens if the proxy (or the component where it stands for) returns something else than a String? This shows to me also one big disadvantage of MDP: through purely semantic coupling can changes in components (and their interfaces) only be detected at runtime, not compiletime. How can you be sure that you fixed all calling parts of your software? This, imho, asks for version management AND really good knowledge sharing between developers, which is still a realistic problem in many organizations. But the author states in his work: "In general, there is no need to change someone else’s code. The need for creating, maintaining and merging several versions of the code is also minimized or eliminated.". I don't agree with that. I hope that the author welcomes my questions and comments as feedback to improve his work. Regards, Christian Köppe | Docent Informatica | Hogeschool Utrecht | Institute for ICT | Nijenoord 1| kamer D01.20 | T. 030-2388056 | NL-3552 AS Utrecht | [email protected]| ________________________________ Van: [email protected] [[email protected]] namens Messaging Design Pattern [[email protected]] Verzonden: woensdag 15 december 2010 4:17 Aan: Ralph Johnson CC: [email protected] Onderwerp: Re: [patterns-discussion] MDP feasibility questions (was: Messaging Design Patterns (MDP) reusability and QA) Ralph, I agree with you in regards to the benefits of the messaging design pattern (MDP). I appreciate your comments. There are applications (scalability) that did not cross my mind. The main purpose of the MDP papers is to convey this information and the concepts behind MDP. Obviously the MDP papers served their purpose. Several people including yourself get the idea. It makes me glad. I love it. Messaging is a sound idea. This is a fact. On the other hand, there may be a better way of communicating the messaging idea. I'd like to hear any specific suggestions/recommendations. This would benefit the discussion. The ideal situation would be finding a good of way of communicating it so everyone gets it right away. I always welcome any cooperative efforts (book, research papers, articles, projects, etc). These should help further the communication process. I also have to acknowledge my shortcomings as a writer. Therefore there is no problem with MDP "messaging". We agree on this. Based on your email, the problem may related to the messenger and how the message is conveyed/presented so to speak. I believe this problem can be overcome. I don't see it as a major obstacle. (Please no crazy ideas about killing the messenger ;-). Perhaps we should talk about presentation since this seems to be an area of contention/difficulty. Please bear with me for a minute. I'm working based on the following premises for my presentation of MDP: - Software applications are designed to model the real world. - Therefore software models should be as close to reality as possible (realistic model) in order to achieve an accurate portrait. The more realistic the model is, the better off your application will be. - Messaging is part of the real work. Actually it is everywhere. Conclusion: Therefore messaging must be part of the model in order to achieve a accurate/complete model. BTW, there are other concepts that are also part of reality ( gravity, forces, etc). Obviously You might to include this concepts depending on your application. This line of thinking is what I'd like to convey as well. Messaging is a sound idea. On the other hand, I believe a "realistic model" is also a sound idea. I'll be happy to discuss the validity of the premises and the conclusion. I should also help the discussion. Messaging and "realistic model" are associated. Actually we need messaging as part of the model because our model needs to be as realistic as possible. Otherwise we'll have to face shortcomings/complexity (RPCs). I'll plan to expand on this. I also plan to address the rest of you comments shortly. When given the proper time and thought, people should realize that, similar to messaging, this is not a crazy idea either. Actually it may be quite useful while working on software models and design patterns. For instance you can come up with a complete Distributed Component Model (second MDP paper) if you make the following association: what you are trying to achieve is already there in the real world. You just need to look at how your phone/mail/email systems (based on messaging) operate and mimic it. Best regards, --- On Tue, 12/14/10, Ralph Johnson <[email protected]> wrote: From: Ralph Johnson <[email protected]> Subject: Re: [patterns-discussion] MDP feasibility questions (was: Messaging Design Patterns (MDP) reusability and QA) To: "Al Boldi" <[email protected]> Cc: "Messaging Design Pattern" <[email protected]>, [email protected] Date: Tuesday, December 14, 2010, 10:25 AM On Sat, Dec 11, 2010 at 9:46 AM, Al Boldi <[email protected]> wrote: Can the MDP be used to replace the Observer Design Pattern? The MDP is not a replacement for Observer. They solve different problems, and can work together (or not). Suppose you are programming in C++. The big idea of MDP is to define one interface with one virtual function, which will have a name like handle() or execute(), or processMessage(). It has one argument, a "message", which might be a C++ object, or a string, or maybe an array of integers. So, you take your beautiful object-oriented design, with a carefully designed set of interfaces, and replace each interface with a single interface with a single operation. Of course, processMessage turns into something like a case statement, since you have to do something different for each kind of message. Your natural reaction *should* be "This is crazy! What a stupid idea!" But it is not a stupid idea. There are times that it is a really good idea. The problem with the pattern descriptions is that it doesn't explain when this is a bad idea and when it is a good idea. You would never want to use MDP for a small C++ program. You might use it in a small program written in a non-object-oriented language, where you wanted to implement objects more clearly. But its main use is in large programs, where you want to make sure that there is loose coupling between subsystems. Static typing doesn't scale. Suppose your system runs on a hundred servers. It uses hundreds of different interfaces. Suppose you want to improve one of them by adding a new operation to it. You don't want to have to reboot all your servers with a new version of your software. You'd like to be able to add it to one and then gradually change one component after another to use it. MDP lets you do this. MDP makes it easy to run components on different machines. Or on the same one. It works for any language, allowing non-OO ones to pretend to be OO. On the other hand, MDP defeats static type checking. It does not take advantage of OO features built into language, so it can be verbose and indirect. You wouldn't want to do it everywhere, but in the right places, it can be very effective. >The MDP papers are mainly geared towards the messaging concept based on a >realistic model. >I tend to place a lot of emphasis on the concept, abstraction and realistic >model. In my opinion, >concept and interface are the main aspects in order to achieve a successful >implementation. I think your papers are not working. Most people don't get the idea after reading them. I think the problem is that you focus too much on this "realistic model". The problem is that the realistic model can be interpreted in many ways, and MDP is only one of them. Smalltalk programmers ALL use the same model. When I read your paper for the first time, I thought you were just talking about the classic OO model that we Smalltalkers have loved for 30 years. You need to try to write things that cannot be misinterpreted. I think you are trying to avoid having people say "You are crazy!" right away, but if they properly understand what you are saying (and they have not seen this pattern used properly before) then they will say it. They ought to say it. When people say "You are crazy!" then you know that they are starting to understand. Your job is to convince them that you are not crazy, that this is in fact often a valuable pattern. -Ralph Johnson
_______________________________________________ patterns-discussion mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion
