OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [soa-rm-ra] quick thought on versioning and description

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  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

From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: 11 March 2007 18:43
To: michael.poulin@uk.fid-intl.com
Cc: soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] quick thought on versioning and description

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 and  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.


On Mar 11, 2007, at 12:33 PM, michael.poulin@uk.fid-intl.com wrote:

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]