I totally agree with "defining a versioning scheme from having a standard way to
indicate the version scheme being used". This means, we, probably, have
to point onto the version scheme mapper element of SOA infrastructure w/o
further details.
The original issue of this discussion thread - how to
collect information about service changes that have not been reflected in the
service version changes - is not that simple. In particular, if we consider just
historical interest in the changes, we can collect the information in a
repository. However, if the change might eventually end up with "someone using the service finds
something isn't working just right" and we have not changed the version,
it becomes an ambiguous case. Therefore, any change must reflect in the
version number.Ken's idea about additional section in the version is good
especially if we can add a version meta-model definition about
mandatory/optional status of each section of the version number.
For example, we have a version value of 10.4.8.217 and the last
position (of value 217), reflecting minor change which does not affect
functionality (as the provider suggests), is optional. It will not affect
consumer's code if we use rule-based version compatibility control model but we
can demonstrate that the change was recognized and managed properly from
the service provider side.
- Michael
OK, replying to everything that been said to this point.
What I'm looking for is a consistent way to capture changes that we agree
do not affect the version number. However, if someone using the service
finds something isn't working just right, they can look back to the log for
clues as to what may be causing the supposed glitch.
My first idea was to extend Michael's idea by adding another version
field that indicates changes in the log. Supposedly, a log entry will
not affect use or interoperability but provides a way for interested parties
to know something changed. So two version numbers may look like
10.4.8.217 and 10.4.8.220. The important thing is the 10.4.8 (or maybe
just the 10.4) and the fourth number (which I expect to iterate more often
than the others) would usually be irrelevant.
Now, I also want, to the greatest extent possible, to maintain opacity,
and I appreciate I'll never be able nor would I want to catch
"everything".
A final note on the rathole: I want to separate defining a
versioning scheme from having a standard way to indicate the version scheme
being used. Following the pattern I roughly lay out under Service
Description, the value object includes both the value and an explicit
indication of its semantics. Thus, we can battle for all eternity on what is
the perfect versioning scheme, but in the meantime we can use whatever we have
on hand, and we can develop mappings between the ones most commonly
used.
We still need to give this more thought.
Ken
I am with you, Duane; I do not want to get down
into bottomless whole (like Alice in the Wonderworld). Let's assume we deal
with the version per se; how new version differs from new object - is out of
the scope.
Subscription to the version change event is a good
mechanism, I agree. However, when a notification is obtained, the decision
has to be made - to call the service in new version or don't. In the
rule-based version control, I address this exact moment - the decision
making. Nothing more. If new version requires the consumer code change to
match new version value, the rule-based version control allows running w/o
such change (becuase the version value has to be inside of a range of
values). If version change
gets unacceptable for the consumer (i.e. new version value ought to be
denied by existing rule), we have two choices: either change the consumer
code to meet new service version or review and adjust the rule w/o code
change (if new version is still acceptable for the consumer but its rule was
not previously formulated to accept such version value change).
- Michael
------------------------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305
phone: 703-983-7934
7515 Colshire Drive
fax:
703-983-1379
McLean VA 22102-7508
|