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 <[email protected]> To: phillip henry <[email protected]> Cc: [email protected] 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 <[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: "Christian Köppe" <[email protected]> >Cc: "[email protected]" <[email protected]> >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 > > > > > >> >> >> >> >> >>> >>> >>> >>> >>> >>> >> >
_______________________________________________ patterns-discussion mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion
