General talk about software patterns

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

Dear list members,

I agree that versioning is a realistic problem for many organizations. The messaging Design Pattern (MDP) improves versioning. Versioning is breafly metioned in the paper (one paragraph - consequences section). It will probably require a separate write up (several pages) to explain it in detail.

An analogy may illustrate versioning. Human speech is constantly evolving. New words, acronyms and phrases are being added to the language on a regular basis. Human speech, as a messaging mechanism,  is flexible enough to allow this. For instance
think about the word "smartphone"  (a few years old - the email software  flags it as misspelled). In a sense we are using "new" version of the language (upgrading the language).The language is able to evolve. This is another quality/property of messaging. It
provides for smooth versioning. This works provided that we do it in a backward compatible
way (syntax/semantics of old words and phrases remain unchanged although some may
become obsolete with time). The language evolves becoming more complex
because of the new information being handled. I can imagine the time where the language
was very simple and consisted of a few words. Children start with a single word in their vocabulary.
 
In terms of versioning, components that use MDP messaging behave in a similar fashion. You can add new messages to the communication between components. Traditional O-O technologies that don't rely on messaging present complexity and limitations. Adding a new parameter to a function, and the software won't compile. If you have a library of components, you will need to use the matching version of the component library. Otherwise your software won't compile. You need to keep and maintain several versions of the code. Usually each engineer needs to keep a complete version of the whole software tree. Changes to the code need to be merged. Coupling between components becomes an obstacle here. Both components need to match, in terms of API,  for the software to compile.

In general, under MDP you only need to keep the latest version of the component library as long as the messaging is backward compatible We also need to keep  in mind the complexity of the problem. Let's say that we have 1000 components. Let's say that each component need to makes 5 distint calls to external components. We are talking about about 5000 function API calls (rough estimate number). Under MDP you have one messaging interface (or a few) that doesn't change. You can compile and run against the latest version of the MDP component library. In general, new version of the library doesn't break compilation/running version. This can also give you an idea of simplicity. It is one messaging primitive versus 5000 API calls (very rough estimate). Any changes/versions and the program will not compile under the traditional O-O approach. It becomes a complex problem to manage. If we are using RPCs it becomes even more complicated.
 
Ideally you can also divide the work so that only one person is responsible for a MDP component. This minimizes or avoids merging. The components only need to agree on the syntax/semantic of the messaging being exchanged. In general old code is compatible with new versions of the MDP component(s):

"In general, there is no need to change someone else’s code. The need for creating,
maintaining and merging several versions of the code is also minimized or eliminated."

We can say that our language is becoming more complex on a regular basis. This is probably accurate. It needs to be that way because we are dealing with more information (new words, phrases, etc). I don't believe we can get around this additional complexity. Complexity increases because we need to handle more information. On the other hand, messaging is simpler than the traditional approach.

Notice that when we are listening, we are processing information. We are also
making decisions based on the information received (message subject/topic, tone of the voice, sender, etc.)

Arguably, not much different from MDP components that behave like a state machine and process information (messages) making decisions based on the messaging received:

processMessage (message) // MDP messaging interface


I hope I was able to answer the questions/comments posted so far. Please let me know if I overlooked anything since I received a fair amount of comments and question. Feel free to send me email or post to list if there is anything that needs further clarification.  

Regards

Al