Folks,
We agree with the definition of pattern form in terms of tradeoffs. Earlier we
have discussed the issue of tradeoffs and drawbacks. Please find attached my
earlier message. In summary:
It will be challenging to find drawback/tradeoffs with certain abstractions
like "object", messaging, gravity, force, reflection, etc. I also agree that
this is unexpected. On the other hand, it is consistent with reality. It fits
within the context of a realistic model.
We probably need to ask ourselves, what would be the drawbacks/tradeoffs
associated with these abstractions/concepts find everywhere in nature and the
real world ? Gravity for example. What can we use to compare these abstractions
with ? If
we compare themwith man-made ("artificial") concepts/abstractions like RPC
(remote procedure calls)
their advantages become evident (encapsulation, decoupling, resusability,
scalability, versioning, interoperability, etc). On the other hand, the
shortcomings and disadvantages of RPCs also become evident.
We also agree that in general design patterns only appear in certain scenarios.
Strategy for instance. On the other hand, other concepts/abstractions like
"object" and "messaging" appear all the time. In reality, there is a difference
in terms of regularity. Keep in mind that messaging is about transferring
information. It will be hard to find a process where information exchange
"messaging" does not occur. In order to understand this, you
may want to think about how often the concept appears in reality. Obviously
there is a difference between Strategy and Messaging.
Messaging will appear everywhere in the context of a realistic model, this is
not the case for other concepts/patterns like Strategy or Proxy. In reality
they don't appear as often. Obviously, we also should keep in mind that the
reality around us is what we are trying to model using software.
I should warn you that you will have difficulties finding tradeoffs and
drawbacks as I mentioned in my earlier email. In summary:
1) We all agree that "messaging" is everywhere (wide applicability and
context). Messaging is about exchanging or transferring information.
3) Messaging as concept has many qualities: simple, effective, efficient,
versatile, robust, scalable, interoperable, etc. The model inherits these
qualities.
2) Messaging has evolved and improved via natural selection. It has
thrived. It is being employed in nature (everywhere).
4) Not sure what other
concepts can be used for purposes of comparison and/or replacement. Man-made
concepts fall short (RPCs).
3) Imho opinion based purely on faith and observation, I wouldn't bet anything
on being able
to outwit the Designer. In my opinion this effort will prove futile. Many of
us would agree with this. Understand and attempt to copy, these are things that
we can do. Finding drawbacks with these concepts will prove to be difficult, to
say the least. I'm afraid, I'll have to leave it up to others since I don't see
a glimpse of hope when it comes to this aspect.
In order to move the discussion forward on this specific topic
(tradeoffs/drawbacks),
feel free to provide trade-off and drawbacks. Please be as specific as possible
and try to include supporting facts, arguments, technical papers/references,
etc. Obviously I want to make sure that I provide an accurate portrait of the
"messaging" abstraction (based on facts).
I think a tradeoff/drawback should probably be something unique to the
messaging design pattern (MDP) It should probably be something that is not
found in reality. For instance, the decision process (if/case) made after the
messaging is received (processMessage) is only part of the natural processing
of information (messages). This is consistent with reality. Not sure it is
correct to view this as a "potential" drawback. I hope my earlier email
helped clarify this point. You will find that semantics (integral part of
reality) regardless of the approach being used (traditional, SOA, messaging).
On the other hand, these were interesting points for discussion.
By the way, the paper includes some practical tradeoffs related to the
implementation of the concept:
Messaging paradigm and
learning curve. In order to take full advantage of this design pattern, people
need to think in terms of a messaging paradigm when they model, design and
build software applications: independent entities (i.e. components)
interchanging messages among each other.
This may require learning time and training. Although a messaging
approach is natural, intuitive, and consistent with the real world, traditional
approaches are based on method/procedure invocation (both local and remote).
Keep
in mind that messaging, as a concept, has many qualities. MDP inherits or
absorbs these qualities. Therefore it is challenging to find drawbacks
associated with messaging and MDP. This is unexpected within the context of
design patterns. A similar situation
occurs when we look at other real-world concepts that may be part of our
software
model, like gravity and force.
Overhead. Transferring
messages between components introduces a small overhead when compared with
traditional method/procedure invocation. This is especially true when a
messenger
is used. As computers become faster and
faster this becomes a non-issue. Also, the benefits of messaging outweigh this
small performance cost. Notice that the
messenger component is part of many real world problems and applications in
which an intermediary is necessary for message interchange.
Disciplined approach.
MDP encourages a disciplined approach that may have a small impact on the
initial development time of a component. Messaging should be the only channel
of communication between components. External class methods may still be
invoked using the traditional approach.
On the other hand, this should be used sparingly in order to minimize
coupling and maximize encapsulation. An ideal component is a self-contained
unit that interacts with the other components only via messaging. The
additional development time is again outweighed by the benefits introduced by
messaging. Moreover individual components based on messaging can be purchased
or extracted from other applications.
I have to agree that the presentation of the pattern has some elements of a
"sales pitch". Sorry about it. I had to come up with ways to convey messaging
which can be challenging. This is why I'm always trying to find better ways to
convey messaging so everyone gets it right away.
All of the aspects discussed above can be viewed and understood in the context
of a realistic model. In particular, the issue drawbacks and trade-offs. Also,
we are able to understand where each concept shows up and that in reality the
concept of messaging appears more often than the concept of Strategy. Actually
it is ubiquitous.
In the context of realistic model you will utilize specific concepts/patterns
depending on where/when they appear as part of the reality being modeled.
In other words, reality will determine what abstraction to utilize (when,
where, how, why).
For example, it is not a good idea to use messaging to model the Solar system
(obviously). Gravity is the right concept for this. Obviously it is not a good
idea to use "messaging" when the concept does not appear in the reality being
represented. However we all agree that messaging is everywhere. Reality, model
and implementation should go hand and hand (mirror each other). By the same
token, not using the messaging abstraction when it is appropriate and natural
results in complexity and limitations (RPCs fall short). Case in point, the
implementation of a distributed component/service model. Messaging is the
correct
abstraction not Remote Procedure calls (RPCs).
Sorry for the delay. I plan to get to your other questions shortly. I
appreciate
their relevance based on the MDP scope , and the level of detail/insight.
Best regards,
Al
--- On Wed, 12/22/10, Messaging Design Pattern <[email protected]> wrote:
From: Messaging Design Pattern <[email protected]>
Subject: Re: [patterns-discussion] MDP feasibility questions (was:
Messaging Design Patterns (MDP) reusability and QA)
To: "Ralph Johnson" <[email protected]>
Cc: [email protected]
Date: Wednesday, December 22, 2010, 2:27 AM
Ralph,
I hope I've been able to convey why I think the idea of a realistic model
can be useful while modeling software. I think it is something to think about.
As I said earlier, it can prove to be quite useful given the proper
consideration. It can give us a framework to think about problems and their
solutions. It can help us explain concepts. We can extract solutions from
reality. Obviously the model and the reality being represented should go hand
in hand. Specifically it helps illustrate why traditional technologies
including O-O and distributed component technologies need to add messaging
in order to achieve a more complete/accurate model.
You raise a valid point regarding trade-offs. We can ask ourselves, why is
it apparently difficult to find problems/trade-offs with messaging ? A very
simple concept and yet it has wide applicability. Components are everywhere. So
is messaging. Messaging "is". Similar to Gravity and other natural laws, all
these concepts exist in the real world. I'm not sure we can think of objects,
gravity or messaging in terms of trade-offs. In this sense, the messaging
concept doesn't seem to behave like other Design patterns where design
trade-offs need to be made. Messaging is similar to the concept/abstraction of
objects, force and gravity. In the case of messaging, it has been developed and
improved for a long period of time. These communication mechanisms have gone
through a process of natural selection. In the case of messaging between people
(human speech), it is highly effective and efficient.
I'm afraid I cannot give you a better answer based on facts for this
particular question.
We may ask the same question for other concepts like Gravity and Force.
On the other hand, based on observation and faith we can believe that there
is great Designer behind nature and all things in reality. Perfection is not
unattainable. Gravity and Messaging have been put in place. We can only
attempt to understand, model and mimic them. Probably we will never be able to
find flaws or improve upon them.
"We can gain valuable insight from the patterns found in nature and the
real world regarding the inner workings of specific problems and proven
alternatives of solution. Based on our observation of the world around us, we
need to think in terms of a messaging paradigm while designing and building
distributed applications. Software engineering processes are improved as a
result. We need to think not only about self-contained components but also in
terms of the information (i.e. messaging) being exchanged between these
components. In reality, these two aspects are independent and separate from one
another. In our particular scenario, we have been able to employ the messaging
paradigm to define a complete distributed component and messaging model in
which transparent, secure and reliable communication between
components/applications is accomplished. As always, we should praise the wisdom
of the Designer for the versatility and simplicity of
nature’s patterns and beautiful design."
I'll cover implementation aspects shortly. Also, I'll update the MDP paper
based on the comments/questions received. Specifically in the areas where
additional clarification is needed to avoid misinterpretations.
Blessed holidays for all of us.
_______________________________________________
patterns-discussion mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion
