General talk about software patterns

[phillip henry <ph1ll1phenry AT yahoo.com>]

Indeed semantic coupling is an an interesting problem. But as I see it, your suggestion makes the problem worse.

With 5000 API methods, I know at compile time if a method is there - say, some other developer says he is adding setAnnouncedDateOnTranche(date, trancheId).

With your suggestion, I do not know at compile time if the other developer has implemented this functionality. With an explicit API method, there is far less ambiguity and it's clear what this method is trying to do.

I also look forward to your reply regarding the 5000 if/else blocks.

Phill

---

From: Messaging Design Pattern <dsheppard2k AT yahoo.com>
To: phillip henry <ph1ll1phenry AT yahoo.com>
Cc: patterns-discussion AT cs.uiuc.edu
Sent: Thu, 27 January, 2011 4:31:23
Subject: [patterns-discussion] Fw: RE: MDP feasibility questions (Semantic Coupling)

Hi Phill,

I sent an email covering the semantic coupling question. I've attached my reply.
In summary:

1) Semantic coupling has been mentioned as "potential" criticism of SOA
technologies. This not limited to MDP. Notice the word potential. 
2) Based on the reasons exposed in my earlier email, I not sure "semantic coupling" is a real issue/problem. Based on quick observation, I cannot find any communication mechanism that doesn't require semantic coupling. Semantic coupling seems to be escential  for communication to happen.
3) Semantic coupling is not a part of the scope of the original MDP papers.

My earlier reply should provide additional details. I not sure I have much more to add to the topic of semantic coupling. The only additional aspect may be the fact that procedure/function calls also require semantic coupling. For instance the function (or RPC) component.function (x,y,z). For this to work, both components need to agree on the semantic of the function call and the parameters (not only the syntax). The traditional approach also requires semantic coupling which doesn't surprise me.


Please feel free to send additional information about semantic coupling directly to the email (papers, references, etc). Sources that can be checked online. In terms of the MDP discussion, it is better if we stay on topic based on the MDP papers (content, scope, etc). Also, I don't expect us to agree on everything. The semantic coupling idea may be an area where we may have to agree to disagree. I'll get to your other questions shortly.

As I mention earlier, I'm asking people to send questions with as much detailed as possible based on the scope of covered by MDP papers. So far, I have received very good questions and comments. Obviously, "thoughtful" messaging goes without saying.


Regards,

Al
 



--- On Sun, 12/19/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: Sunday, December 19, 2010, 5:33 PM

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