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

Title: Re: [soa-rm-ra] Version
I have been doing some more logical thinking re: versioning Descriptions.

1. Logically, a service description describes a service.
2. If a service is versioned (meaning one or more of its’ externally visible properties has changed), a new description must be done describing those changes
3. In no case should a service have multiple versions of a service description describing the same service/version combination.  There may be multiple service descriptions but not multiple versions of each.  
4. If something changes in the service, a new service description should be made/generated for that new, unique combination.

Does this make sense?


On 27/06/08 10:48 AM, "Ken Laskey" <klaskey@mitre.org> wrote:

The Resource model says Identity denotes a Resource, and Identity is composed of one or more Identifiers.  I might want to quibble about whether composed of is the proper relationship, but certainly a version designator can be one of the Identifiers.

The Resource model also says Description references Identifiers (without any noted cardinality, and only implies that a given Description does not have to reference all Identifiers), by which we mean it references the value given to Version but does not "describe" Version itself.

Also, we don't touch on (although it is noted in the RM) that Identifiers may have to be used together to resolve to an unambiguous Identity, e.g. it is often composed of an immutable name (e.g. example.txt) and a varying string of nonnegative integers separated by decimal points (e.g. 3.2.1).

However, I believe in SOA we need more from Version.  

1. Versioning is the process of systematically cataloguing the changes to a resource. This implies an identifiable resource, a specific set of revisions to that resource, and a modified resource that is the result of applying the revisions to the original.

2. Not only SHOULD a version be specified through use of a version identifier, but documentation SHOULD be available on how the identifier is to be interpreted.

3. Given versions are often defined with some intent to indicate backward and/or forward compatibility, it is not only necessary to have a versioning strategy that defines the semantics of the version identifier used by any resource, but it is also necessary to have versioning policies that define what compatibility approach is appropriate when interacting across versions.  This is not part of the version but may be prescribed for those using versions of the Resource as part of their Policies.

Following this, my suggested model for Version would be (the embedded or attached)

Now, obviously this is not as simple as saying version 3.2.1, but I'm not convinced we can address much less.


On Jun 26, 2008, at 8:50 PM, Duane Nickull wrote:

How about a much simpler version (no pun intended.  Well maybe)
 1. Resources have versions.  
 2. A service (which is a specialized type of resource), therefore also has versions
 3. A service description describes the service, and therefore must describe any properties such as “version”
 4. An identifier identifies a unique service/version
 Why?  Versions are usually only used for “externally visible property changes”.  It is not necessary to version services based solely on time or space.
 Comments inline:
 On 25/06/08 3:19 PM, "Francis McCabe" <frankmccabe@mac.com> wrote:
Here is why I thought that version was connected to identity:
 A resource is a time varying entity that has value to someone (or something)
 DN: everything varies with time so it is not unique, therefore why mention it.
 A version identifies a particular state of the resource at a particular moment in time (could include space too).
 DN: agree
 The resource may or may not have any 'awareness' of its versions. In fact, I would argue that most of the time it does not.
 DN: this is orthogonal.  I think most version changes really represent different states visible outside the service, not necessarily what powers them.
 Consider a description of a service. That description will have many aspects to it. It may also identify which version of the service the description pertains to.
 Now, consider versioning the description itself. In the case of a description, it is a structure artifact and so it may be possible to 'fit' any version identification of the description into the description itself. But, if the description was designed to a specification that neither enabled versioning nor enabled extensions, then you could not embed version info into the description artifact (straw man I now, but other resources have no space for version info).
 DN: I would not consider versioning the description.  I think it is simpler if you describe the service and any unique service/version instances.

 BTW – here are the minutes – please add any changes before committing.  Sorry I had to run earlier.

 Senior Technical Evangelist - Adobe Systems, Inc.
 Duane's World TV Show - http://www.duanesworldtv.org/
 Blog - http://technoracle.blogspot.com
 Community Music - http://www.mix2r.com
 My Band - http://www.myspace.com/22ndcentury
 Adobe MAX 2008 - http://technoracle.blogspot.com/2007/08/adobe-max-2008.html
  <Meeting Minutes from June 25.docx>




Ken Laskey

MITRE Corporation, M/S H305     phone:  703-983-7934

7515 Colshire Drive                        fax:        703-983-1379

McLean VA 22102-7508


Senior Technical Evangelist - Adobe Systems, Inc.
Duane's World TV Show - http://www.duanesworldtv.org/
Blog - http://technoracle.blogspot.com
Community Music - http://www.mix2r.com
My Band - http://www.myspace.com/22ndcentury
Adobe MAX 2008 - http://technoracle.blogspot.com/2007/08/adobe-max-2008.html

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