General talk about software patterns

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

Hi Christian,

I've taken a few days off during the Christmas season. I'm glad that you like the messaging idea/concept. One of the main goals behind the MDP paper was to introduce the messaging concept.  As I mentioned earlier, please keep sending your specific comments/questions regarding any claims you happen to disagree with. I'm asking folks to be as specific as possible. It is best if we advance the discussion based on the content/scope of the papers.

The Jt framework has been utilized for several large mission critical (production quality) applications. I may have mentioned this earlier. The framework implements several technologies including: Secure Web Services, ESB and BPEL. I'll go over the some implementation aspects shortly since several people have manifested an interest. However, this was not in the scope of the initial MDP paper.  I'll include your questions related to implementation, the web services example and the handling of versions.

We may have to agree to disagree in terms of the model. Based on your email, this is your personal opinion (imho). In my view, the models need to be as closed as possible to the reality being represented. That is the main idea behind the concept of a model (mathematical, architectural, software, DNA, biological, physics, astronomical, etc) . It seems obvious to me. I cannot think of any example/model where this does not apply.  I also mentioned that there are many ways in which messaging can be implemented because of its wide applicability).

Semantic Coupling: I sent an email regarding this topic. Based on preliminary observation, this doesn't seem to be a drawback/trade-off. I cannot think of any communication/messaging scenario/system where semantic coupling is not required . Perhaps I should add that this discussion wouldn't be possible without messaging and semantic coupling. Component coupling was in the scope of the paper. We agree that MDP improves this type of decoupling.

Gravity, messaging ,force and other concepts exists in reality. They may need to be part of the software model depending on the application. As I mentioned, I'm not sure we can view these concepts in terms of drawbacks and trade-offs. I'm not sure what concepts we can use to compare with. For instance I'm not sure what the drawbacks of gravity or force are. Same idea applies to messaging. I guess messaging can be compared with RPCs which perhaps isn't a "natural" concept. Then the RPC limitations and drawbacks become clear.

In terms of approaches that don't work as well as messaging, the MDP papers include a comparison between messaging and RPCs. This is one of the main items in the scope of the papers. It has been covered in detail. Feel free to send detailed questions/comments if you happen to disagree with the comparison or any of the related claims.


Best regards,

Al


--- On Wed, 12/22/10, Christian Köppe <christian.koppe AT hu.nl> wrote:

From: Christian Köppe <christian.koppe AT hu.nl>
Subject: MDP feasibility questions
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 22, 2010, 8:53 AM

Hi,

first: could you do me a favor and set your name under your mails, as I don't know if MDP is represented by one or more persons and which  persons that are (I suspect it's the name on the PLoP-paper?). Thank you!

I don't have the time right now to respond to everything you wrote, I'll try to do that later. Just one thing: in my honest opinion you're looking at the Messaging Design Pattern with a real strong bias which doesn't help in making it (and the need of it) understandable. I like the idea but I am still not convinced that this is the "solution" to all the problems as claimed in the paper.

A model is an abstract representation (of whatever, a future software system or the reality). So arguing that because messaging appears in reality it should be part of our model is imho no valid argument. And, as asked before, how  can you be sure that your implementation of messaging is consistent with messaging as it appears in "reality"? You still need to prove that (if you use this as argument).

Patterns are a sort of best (at a certain moment) know practices. It seems that you invented the solution first (which is fine), and now are looking for the fitting problems. I would like to see the following things first:
- applications of MDP in real projects (not small examples). If it's included in a framework, I'd like to see how this is applied in a real project and how MDP helps herein (the last one being important).
- a grounded discussion of why other approaches don't work (the forces of the pattern), there surely is enough research material on these topics, so please use it.

Last point: In your last mail you wrote: "We can ask ourselves, why is it apparently difficult to find problems/trade-offs with messaging?". I mentioned in my last mail a couple of problems and trade-offs which still need to be addressed! So I wonder how you can state this?


I hope that you can use my comments. I wish everybody good days and "einen guten Rutsch in das neue Jahr". ;-)


Christian Köppe
| Docent Informatica | Hogeschool Utrecht | Institute for ICT | Nijenoord 1| kamer D01.20 | T. 030-2388056 | 3552 AS Utrecht | christian.koppe AT hu.nl|

 

---

Van: patterns-discussion-bounces AT cs.uiuc.edu [patterns-discussion-bounces AT cs.uiuc.edu] namens Messaging Design Pattern [dsheppard2k AT yahoo.com]
Verzonden: woensdag 22 december 2010 3:27
Aan: Ralph Johnson
CC: patterns-discussion AT cs.uiuc.edu
Onderwerp: Re: [patterns-discussion] MDP feasibility questions (was: Messaging Design Patterns (MDP) reusability and QA)

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.
 

--- On Wed, 12/15/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: "Al Boldi" <a1426z AT gawab.com>, patterns-discussion AT cs.uiuc.edu
Date: Wednesday, December 15, 2010, 3:17 AM

Ralph,

I agree with you in regards to the benefits of the messaging design pattern (MDP). I appreciate your comments. There are applications (scalability) that did not cross my mind. The main purpose of the MDP papers is to convey this information and the concepts behind MDP. Obviously the MDP papers served their purpose. Several people including yourself get the idea. It makes me glad. I love it. Messaging is a sound idea. This is a fact.

On the other hand, there may be a better way of communicating the messaging idea. I'd like to hear any specific suggestions/recommendations. This would benefit the discussion. The ideal situation would be finding a good of way of communicating it so everyone gets it right away. I always welcome any cooperative efforts (book, research papers, articles, projects, etc). These should help further the communication process. I also have to acknowledge my shortcomings as a writer.

Therefore there is no problem with MDP "messaging". We agree on this. Based on your email, the problem may related to the messenger and how the message is conveyed/presented so to speak. I believe this problem can be overcome. I don't see it as a major obstacle. (Please no crazy ideas about killing the messenger ;-).  

Perhaps we should talk about presentation since this seems to be an area of contention/difficulty.

Please bear with me for a minute. I'm working based on the following premises for my presentation of MDP:

- Software applications are designed to model the real world.
- Therefore 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.
- Messaging is part of the real work. Actually it is everywhere.

Conclusion: Therefore messaging must be part of the model in order to achieve a accurate/complete model. BTW, there are other concepts that are also part of reality ( gravity, forces, etc). Obviously You might want to include these concepts depending on your application.

This line of thinking is what I'd like to convey as well. Messaging is a sound idea. On the other hand, I believe a "realistic model" is also a sound idea. I'll be happy to discuss the validity of the premises and the conclusion. I should also help the discussion.

Messaging and "realistic model" are associated. Actually we need messaging as part of the model because our model needs to be as realistic as possible. Otherwise we'll have to face shortcomings/complexity (RPCs).  I'll plan to expand on this. I also plan to address the rest of you comments shortly. When given the proper time and thought, people should realize that, similar to messaging, this is not a crazy idea either. Actually it may be quite useful while working on software models and design patterns. For instance you can come up with a complete Distributed Component Model (second MDP paper) if you make the following association: what you are trying to achieve is already there in the real world. You just need to look at how your phone/mail/email systems (based on messaging) operate and mimic it.

 
Best regards,