General talk about software patterns

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

Christian,

I hope you will have the chance to review the second MDP paper:

Messaging Design Pattern and a Distributed Component/Services Model
https://jt.dev.java.net/files/documents/5553/149793/MDPdistributedModel.pdf

As I mentioned before, it includes a detailed comparison between Messaging and RPC.
I you happen to disagree with any of the premises/conclusions, please let me know.
The RPC example (first paper) also includes some level of detail. The implementation of other design patterns using MDP is also covered in detail.

I agree with your regarding syntactic decoupling. MDP messaging improves component decoupling as presented in the paper. This is fact. In terms of semantic decoupling.   I guess you are asking because semantic coupling has been mentioned as one of the "potential" criticisms against SOA technologies in general. I plan to use the realistic model idea to attempt to give you an answer. Keep in mind that "semantic" coupling concerns were not in the scope of the original MDP paper. The main focus was on component decoupling. Also, keep in mind that the following is based on a preliminary observation of your question and its context. I haven't done a lot of work in this area. 

Realistic Model:

1) Software applications are designed to model the real world.
2) 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.
3) Messaging is part of the real world. Actually it is everywhere (Ubiquitous)

.

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

Based on a preliminary observation, I can tell you that semantic coupling is found in the real word (Premise 3). This is true for the scenarios that I can think of (Speech, communication protocols, transactions in a banking system). Semantic coupling doesn't seem to  be a problem.

I'll try to use an analogy form the real world to illustrate my point. Consider a child leaning a language (speech) from his/her parents or an adult learning a new language.
In order for the communication ("Messaging")  to happen there needs to be semantic coupling. In other words, the sender and the receiver need to share the same language (same semantic context if you will). As far as I can see, this is the only way in which the message can be communicated and the information transferred. Obviously If someone speaks to us using a language that we don't understand, communication of information won't take place. For this particular real world scenario, lack of semantic coupling means no communication/messaging.

I can think of many other real world scenarios where the same principles apply (communications protocols, transactions in a banking system) . Based on a realistic model applied to this particular scenario (speech) we can reach the following preliminary observations and conclusions:

- Semantic coupling is part of the real world. Therefore it will be needed as part of your model for these particular applications.
- It seems to be required. I don't see any other way in which communication(interchange of information) can be achieved. Also, keep in mind that this messaging/communication mechanism (speech) is highly effective/efficient. It is being developed and improved for thousands of years.  I'm not sure we'll be able to find a better way of doing things.
- Semantic coupling seems to be a good thing for this particular scenario. The more the adult/child learns about the semantic of the new language, the more efficient the communication can become. Fewer words are needed. The words can convey precise meaning, minimum overhead, etc.
- It doesn't seem that we can avoid defining message formats. The is another aspect (related to syntax) that we can't avoid in order to achieve effective/efficient communication. I'm no sure this can be considered overhead. It looks like this is just a required aspect of an efficient communication/messaging mechanism. Perhaps we can say that the "overhead" is kept to a minimum. 
- Semantic coupling can be improved by a learning process.

This is another reason why I like the idea of a realistic/real model. Based of our knowledge and observation of the real world, we can quickly make inferences that may be applicable to software. At the very least, it gives us a tool (framework of reference) to look at communication/messaging problems in the software realm.

Based on preliminary observation, "it looks" like semantic coupling is a good thing (perhaps required) withing the context of software communication. On the hand, in the real world, components are decoupled (independent entities) and communicate via messaging. 

I'm afraid I can give up on this idea of a realistic model. I think there is something here that deserves careful consideration and thought. Similar to messaging, this idea can prove to be useful. For this particular question, it allows me to quickly frame the question and provide an answer to it based on messaging application found in the real world.

I hope this makes sense. I'm afraid I haven't done a lot of work in the area of semantic coupling. Feel free to send any additional comments or questions based on this reply. I plan to cover all the implementation questions using a separate email.

Best regards

 

 




 


Best regards,





--- On Thu, 12/16/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: "Christian Köppe" <christian.koppe AT hu.nl>
Cc: "patterns-discussion AT cs.uiuc.edu" <patterns-discussion AT cs.uiuc.edu>
Date: Thursday, December 16, 2010, 7:46 PM

Christian,

I welcome your comments and questions.I've been given careful thought to all the comments/questions that I have received. In my view having an open and direct discussion about the messaging design pattern (MDP) is very beneficial. You also have very specific questions based on the paper. In general, I'm asking folks to be as specific as possible so I can provide detailed answers. Feel free to include specific sections of the paper.

Once we get the messaging abstraction, we can agree on the validity of the concept. You raise a valid point related to the comparison with traditional solutions. I'm afraid this comparison was not part of the scope of the original MDP paper. The first paper only includes an example comparing MDP and RPCs. There are several facts/benefits covered there. As I mentioned earlier, it is impossible to cover all the aspects of MDP with a single paper (wide applicability). Many aspects are only briefly mentioned.  The second MDP paper covers a complete comparison of MDP with traditional RPCs:

Messaging Design Pattern and a Distributed Component/Services Model
https://jt.dev.java.net/files/documents/5553/149793/MDPdistributedModel.pdf

You should find facts and solid arguments/foundation there in terms of the benefits of MDP when compared with traditional RPCs.  Otherwise I'd like to know the specific aspects that you may disagree with so I can send you a detailed answer. Also, you may  want to review some of the comments contributed to the discussion in order to visualize the benefits of MDP. The first paper also discusses in detail the implementation of design patterns using MDP. This is another area where detailed arguments/facts have been provided so far.

BTW, the Jt design pattern framework (reference MDP implementation) may also be useful when comparing MDP with other technologies.

In my view, in order to fully understand the messaging design pattern (concept, abstractions, implementations, applicability, feasibility, efficiency, etc)  we need to understand the following premises and conclusion. Folks bear with me for a minute and think about it carefully. BTW, as I mentioned earlier, if there is a better way of communicating "messaging" I'd love to hear it so everyone gets it right away.

Realistic Model:

1) Software applications are designed to model the real world.
2) 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.
3) Messaging is part of the real world. Actually it is everywhere (Ubiquitous).

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

We agree that messaging is everywhere (premise 3). This is a fact. We also agree that many other concepts (gravity, etc) are part of the real world (fact). There is no inconsistency between this fact and the premises/conclusion above. As stated earlier "Obviously you might need to include these concepts depending on your application."

Let's use the concept of Gravity to illustrate this point. It is also part of the real world. On the other hand, you don't need it as part of your model for a Distributed Component/Service model (second MDP paper) or a standard business application. In general these applications don't need to deal with the concept of Gravity. Gravity doesn't need to be part of your model in this particular scenario. Usually what you find for these applications is  many components "communicating" with each other. This "communication" implies "messaging". Messaging needs to be part of the model for these types of applications in order to achieve a complete/realistic model.

Now let's say that you are trying to model a highly interactive game where characters need to communicate ("Messaging") with each other. They also can jump (Gravity) and move around. They can also collide and bounce (Force), etc. Based on premises 1 and 2 above, you need to arrive to the following conclusion. There is not inconsistency with any of the premises or the conclusion above. For premise 3 you need to realize that Gravity and Force are also part of the real world (no inconsistency):

Premise 3: Messaging, Gravity and Force are part of the real world.

Conclusion:We need to include the concepts of messaging, gravity and force to achieve a realistic model for this specific application. They are part of the reality being modeled. Therefore they should be part  of the software model.
 
In you think in terms of a realistic model, the difference between messaging and other concepts (force, gravity) is that messaging is ubiquitous. It is needed for most of the common applications (business, Distributed Component/Service Model). Gravity, force and other concepts are not. This is the main difference.


I'm afraid I was unable to attend the conference. I hope this makes sense. Feel free to send any additional comments/questions based on this reply. I plan to address your other questions/comments shortly. I hope the second MDP paper will provide additional/detailed information in terms of comparison between MDP and other technologies (RPCs/Web services).


Best regards,

---

r