| Duane,
Let me clarify. A resource may have more than one description where the individual descriptions make visible different aspects of the resource. This follows the RM in saying you can never describe everything, and it would make no sense to say everything you can/want to describe should be in the same place. Our only requirement is the multiple descriptions be consistent, since they are describing the same thing.
Now given a description for one aspect, or equivalently if we talk about the service description as described in the RA, we can say we have one such description for one version of the service, where a version of the service can be defined as an identifiable configuration of resources. Lots of folks won't care about the details of the configuration, but it needs to exist. Now I have a RA service description for one version of the service. Not a problem.
Let's look at the other permutations. Does it make sense to have more than one service version described by a given service description? Now an example could be if I find a bug in version 5 and fix that in version 6 without doing anything else different; in effect, version 6 does what version 5 was supposed to do. I would argue that service version 6 should have a different service description because it is important that the fix be acknowledged. So the only difference in the service description for the version 6 service will be something in the description saying it's for version 6. So, a service description should only be associated with one service version.
Now what about more than one service description for a given service. The list I gave in my previous email illustrated examples where that might make sense. What I conclude from that is the service description also needs to be versioned because it is important for folks to know the description changed even if the service it describes has not. So, a service version may have different versions of its service description but each subsequent version supersedes the previous one.
This said, both the service and its associated service description need to be versioned in a way that is consistent must allows the service description to change for a given service version.
Ken
On Jun 27, 2008, at 3:37 PM, Duane Nickull wrote: Ken:
This is not quite what I said.
“I agree with most of this except for the limitation of one service-one description”
There may be multiple descriptions of any service. The place where logic is undeniable is that there should never be different versions of a service description. If the service has encountered a change that is externally visible, the service description for that specific version of that service should be in alignment or if the service itself is versioned, then a new service description generated. Having multiple service description versions describing the same thing makes no sense.
Duane
On 27/06/08 12:13 PM, "Ken Laskey" <klaskey@mitre.org> wrote:
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
--
**********************************************************************
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 |