General talk about software patterns

[Messaging Design Pattern <dsheppard2k AT yahoo.com>]

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 <dsheppard2k AT yahoo.com> wrote:


    From: Messaging Design Pattern <dsheppard2k AT yahoo.com>
    Subject: Re: [patterns-discussion] MDP feasibility questions (was: Messaging Design Patterns (MDP) reusability and QA)
    To: "Ralph Johnson" <johnson AT cs.uiuc.edu>
    Cc: patterns-discussion AT cs.uiuc.edu
    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.