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
_______________________________________________
patterns-discussion mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion
