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

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

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


Subject: Re: [soa-rm] versioning


For the second, a new version is needed if the results could be different even if other "externally visible properties" are the same.  For example, the service is essentially the same but now uses a different underlying data source and there may be a discontinuity between results seen with the old source and results seen with the new one.  The consumer needs to be aware that the discontinuity may occur and then the consumer can decide what actions should be taken for their use.  If this is intended to fall under "externally visible properties", then we're all on the same page.

I tend to follow Michael's approach for the first question.  However, the challenge is less of having a sharp line between new artifact vs. new version and more to have a principled way of consumers knowing when there are changes and that there are new/modified offerings.

Ken

On Dec 8, 2009, at 9:50 AM, mpoulin@usa.com wrote:

I went though the same discussions as Duane has mentioned with my colleagues back in JP Morgan and Fidelity 3 years ago. We also concluded the same as Duane said about the second question.

However, our conclusion for the first question was a bit different. We did not bulk "... major functional properties, attributes or operations". Instead, we have said that if the major business function (i.e. its properties and attributes) stays the same but operations change, it is still a new version; if the major properties or attributes change and this results in re-classification of the business functionality (i.e. the functionality changes, not operations on it), then it is a new functionality, i.e. new artifact (by Duane).

- Michael 


-----Original Message-----
From: Duane Nickull <dnickull@adobe.com>
To: mpoulin@usa.com <mpoulin@usa.com>; boris.lublinsky@navteq.com <boris.lublinsky@navteq.com>; soa-rm@lists.oasis-open.org <soa-rm@lists.oasis-open.org>
Sent: Mon, Dec 7, 2009 2:25 pm
Subject: Re: [soa-rm] versioning

For both UDDI and the ebXML registry-repository standards, there was work done on the topic of versioning artifacts in a registry-repository.  There was also some high level attributes in the ISO/IEC 11179 metadata facility to denote versioning and some form of statement mentioning that implementers must address the subject of versioning of artifacts.

The biggest question that loomed during development of these standards was “does a changed version of an artifact represent a new artifact or a newer version of an existing artifact?”.  Like wise, the question of “what constitutes a significant enough change to warrant a version upgrade” also loomed.

For the second question, I had suggested that if any externally visible properties of an artifact changed, the artifact should be re-versioned.  For the first question, my position had been that if the artifact added or removed major functional properties, attributes or operations, it “might” constitute grounds for a new artifact.

Neither was resolved in the older standards work.

Duane


On 12/7/09 5:12 AM, "mpoulin@usa.com" <mpoulin@usa.com> wrote:

I still do not see a versioning  paper that would taken a consumer perspective and put constraint on the development versioning (I wrote about this in Service Versioning For SOA | <http://soa.sys-con.com/node/250503> (http://soa.sys-con.com/node/250503)

- Michael


-----Original Message-----
From: Lublinsky, Boris <boris.lublinsky@navteq.com>
To: soa-rm@lists.oasis-open.org <soa-rm@lists.oasis-open.org>
Sent: Wed, Nov 18, 2009 5:50 pm
Subject: [soa-rm] versioning

Another versioning paper
 
http://msdn.microsoft.com/en-us/library/bb491124.aspx
 

The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above.  If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited.  If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.
 


---
Adobe LiveCycle Enterprise Architecture - http://www.adobe.com/products/livecycle/
My Band – http://22ndcenturyofficial.com/
Twitter – http://twitter.com/duanechaos
Blog – http://technoracle.blogspot.com/


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