Duane,
I agree with most of this except for the limitation of one service-one description. While a description describes only one service (service version), a single service could have multiple (superseding?) versions because:
- errors corrected in description that do not significantly change the description, e.g. a simple typo;
- corrections that do significantly change description, e.g. the word NOT was missing from the functionality description;
- adding information, e.g. an additional real world effect that was previously considered inconsequential;
- removing information that was previously required or thought useful, e.g. the number of times the service has been used;
- consolidating elsewhere the specifics of some information and replacing the occurrences in the service description by a link to the consolidated location, e.g. version history.
Ken
On Jun 27, 2008, at 2:50 PM, Duane Nickull wrote: 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?
Duane
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)
<image.png>
Now, obviously this is not as simple as saying version 3.2.1, but I'm not convinced we can address much less.
Ken
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.
/d
--
**********************************************************************
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
**********************************************************************
------------------------------------------------------------------------------------------ Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508
|