Al,
Thanks for clarifying your point. I agree with you. Messaging is a simple concept/abstraction. I'd like everyone to see this. This is one of the main goals behind the MDP papers. If we can see the concept/abstraction, we should be able to find ways of implementing it. The concept and the implementation should not be too far from each other. I'm afraid not much work has been done in terms of sub-patterns.
I also agree that the door is wide open for interpretation. I'm
not sure we'll be able to close it. Open doors may be a good think (opportunity). At this point, I'll be happy if everyone sees the idea. I realize that opens doors may lead to confusion and fragmentation in terms of implementation. Messaging is too broad as a concept. It has wide applicability. This also implies a wide range of potential implementations.
The Jt Design Pattern framework is just one of the potential implementation (reference implementation). As I mention earlier, implementation is up to the implementer's imagination. On the other hand, I believe the Jt
Design Pattern framework and the MDP messaging interface give people a good starting point (point of reference).
Messaging as a concept can be implemented in a wide variety of ways in the real world:
Software API (MDP messaging interface) Distributed Component Model JMS/MOM queue. Instant messages Robotic arm sensors Vision/Speech processing systems
If you think in terms of realistic model, Your model needs to match reality. Your implementation should also match reality as closely as possible. All of the areas above use the same messaging concept. On the other hand, the implementation will be different. On the other hand, you'll be able to gain a lot if somehow you are able to provide a "generic"/reusable implementation of the messaging design pattern. The MDP interface helps with this aspect. I discussed the MDP reusability aspects earlier.
I hope you'll have the chance to review the Jt design
pattern framework. This framework is a solid MDP implementation. Several large business critical projects have been implemented based on MDP. The framework implements the MDP distributed component/service model mentioned in the papers. I'm hoping this framework will also answer many of the implementation/feasibility aspects. As I stated in the paper, I have a different take on MDP simplicity:
"The MDP messaging interface is simple but
powerful. The simplicity of this interface can be deceiving. One method with one parameter (message) is all that is needed. It acts as a universal messaging interface that applies to remote and local components. This interface handles any type of message (For instance, the Java Object class). It returns a reply (of any type). In Java, the messaging interface can be declared as follows:
public interface JtInterface { Object processMessage (Object message); }
The message receiver needs to implement this interface in order to receive and process incoming messages."
Here I'm talking specifically about the reference MDP messaging interface. I'm not sure how MDP could be subdivided any further. We'll be happy to hear any suggestions/recommendations. In any case, we'll be discussing implementation concerns in more detail since several people are interested in this particular subject. This is another area that was not in the scope of the original MDP paper (detailed discussion of implementation aspects). On the other hand, I agree with you: it is a key area for a successful MDP implementation. I'm afraid some of the areas that you mention will require additional thought/research.
Best regards,
--- On Wed, 12/15/10, Al Boldi <a1426z AT gawab.com> wrote:
From: Al Boldi <a1426z AT gawab.com> Subject: Re: [patterns-discussion] MDP feasibility questions (was: Messaging Design Patterns (MDP) reusability and QA) To: "Messaging Design Pattern" <dsheppard2k AT yahoo.com> Cc: "Ralph Johnson" <johnson AT cs.uiuc.edu>,
patterns-discussion AT cs.uiuc.edu Date: Wednesday, December 15,
2010, 3:23 PM
Messaging Design Pattern wrote: > Perhaps you could elaborate in terms of why you think the messaging > design pattern is complex (specific examples, etc). I'd like to > understand. I believe it would benefit the discussion. I see it as a > simple pattern (perhaps just me) with wide applicability .
The MDP as a concept is simple, but as a pattern it is complex.
Simple patterns directly map onto the underlying implementation, i.e. the ITERATOR directly maps onto some loop implementation.
OTOH, Complex patterns do not directly map onto the underlying implementation, i.e. the OBSERVER does not have a directly mappable implementation, leaving the door wide open for interpretation. To close this gap, you need to decompose the complex pattern into its sub-patterns until you reach the simple pattern level, which directly maps
onto the
implementation.
It is this decomposition of the complex pattern into its respective simple patterns that should yield a proper understanding of the complex pattern.
In the case of the MDP, what sub-patterns are needed for a successful implementation?
Thanks!
-- Al
|
|