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.
#yiv150328688 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 <[email protected]> wrote:
From: Al Boldi <[email protected]>
Subject: Re: [patterns-discussion] MDP feasibility questions (was: Messaging
Design Patterns (MDP) reusability and QA)
To: "Messaging Design Pattern" <[email protected]>
Cc: "Ralph Johnson" <[email protected]>, [email protected]
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
_______________________________________________
patterns-discussion mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion
