| Christian,
I welcome your comments and questions.I've been given careful thought to all the
comments/questions that I have received. In my view having an open and direct discussion about the messaging design pattern (MDP) is very beneficial. You also have very specific questions based on the paper. In general, I'm asking folks to be as specific as possible so I can provide detailed answers. Feel free to include specific sections of the paper.
Once we get the messaging abstraction, we can agree on
the validity of the concept. You raise a valid point related to the comparison with traditional solutions. I'm afraid this comparison was not part of the scope of the original MDP paper. The first paper only includes an example comparing MDP and RPCs. There are several facts/benefits covered there. As I mentioned earlier, it is impossible to cover all the aspects of MDP with a single paper (wide applicability). Many aspects are only briefly mentioned. The second MDP paper covers a complete comparison of MDP with traditional RPCs:
Messaging Design Pattern and a Distributed Component/Services
https://jt.dev.java.net/files/documents/5553/149793/MDPdistributedModel.pdf
You should find facts and solid arguments/foundation there in terms of the benefits of MDP when compared with traditional RPCs. Otherwise I'd
like to know the specific aspects that you may disagree with so I can send you a detailed answer. Also, you may want to review some of the comments contributed to the discussion in order to visualize the benefits of MDP. The first paper also discusses in detail the implementation of design patterns using MDP. This is another area where detailed arguments/facts have been provided so far.
BTW, the Jt design pattern framework (reference MDP implementation) may also be useful when comparing MDP with other technologies.
In my view, in order to fully understand the messaging design pattern (concept, abstractions, implementations, applicability, feasibility, efficiency, etc) we need to understand the following premises and conclusion. Folks bear with me for a minute and think about it carefully. BTW, as I mentioned earlier, if there is a better way of communicating "messaging" I'd love to hear it so everyone gets it right
away.
Realistic Model:
1) Software applications are designed to model the real world.
2) 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.
3) Messaging is part of the real world. Actually it is everywhere (Ubiquitous).
- Conclusion:
Therefore messaging must be part of the software model in order to achieve an
accurate/complete model. BTW, there are other concepts that are also
part of reality ( gravity, forces, etc). Obviously you might need to include
these concepts depending on your application.
We agree that messaging is everywhere (premise 3). This is a fact. We also agree that many other concepts (gravity, etc) are part of the real world (fact). There is no inconsistency between this fact and the premises/conclusion above. As stated earlier "Obviously you might need to include
these concepts depending on your application."
Let's use the concept of Gravity to illustrate this point. It is also part of the real world. On the other hand, you don't need it as part of your model for a Distributed Component/Service model (second MDP paper) or a standard business application. In general these applications don't need to deal with the concept of Gravity. Gravity doesn't need to be part of your model in this particular scenario. Usually what you find for these applications is many components "communicating" with each other. This "communication" implies "messaging". Messaging needs to be part of the model for these types of applications in order to achieve a complete/realistic model.
Now let's say that you are trying to model a highly interactive game where characters need to communicate ("Messaging") with each other. They also can jump (Gravity) and move around. They can also collide and bounce (Force), etc. Based on premises 1 and 2 above, you need to arrive to the
following conclusion. There is not inconsistency with any of the premises or the conclusion above. For premise 3 you need to realize that Gravity and Force are also part of the real world (no inconsistency):
Premise 3: Messaging, Gravity and Force are part of the real world.
Conclusion:We need to include the concepts of messaging, gravity and force to achieve a realistic model for this specific application. They are part of the reality being modeled. Therefore they should be part of the software model.
In you think in terms of a realistic model, the difference between messaging and other concepts (force, gravity) is that messaging is ubiquitous. It is needed for most of the common applications (business, Distributed Component/Service Model). Gravity, force and other concepts are not. This is the main difference.
I'm afraid I was unable to attend the conference. I hope this makes sense. Feel free to send any
additional comments/questions based on this reply.
I plan to address your other questions/comments shortly. I hope the second MDP paper will provide additional/detailed information in terms of comparison between MDP and other technologies (RPCs/Web services).
Best regards,
--- On Wed, 12/15/10, Christian Köppe <christian.koppe AT hu.nl> wrote:
From: Christian Köppe <christian.koppe AT hu.nl>
Subject: RE: [patterns-discussion] MDP feasibility questions (was: Messaging Design Patterns (MDP) reusability and QA)
To: "Messaging Design Pattern" <dsheppard2k AT yahoo.com>, "Ralph Johnson" <johnson AT cs.uiuc.edu>
Cc: "patterns-discussion AT cs.uiuc.edu" <patterns-discussion AT cs.uiuc.edu>
Date: Wednesday, December 15, 2010, 9:27 AM
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 | christian.koppe AT hu.nl|
|
|
|
