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


Title: Re: [soa-rm-ra] quick thought on versioning and description
IN previous work, there was a notion of an “auditable event” which happened in a metadata registry and users of the instances of the objects described by the metadata could subscribe to the auditable events that were important to them.  There were many technical issues with this but the general mechanism was well accepted as useful.

What was not agreed to was the semantics of versioning.  What constitutes a new object vs. a new version of an existing object.  
<warning>
This discussion is a rathole with no bottom.
</warning>

I suggest we don’t get bogged down into this discussion.

D



On 3/9/07 2:47 AM, "Poulin, Michael" <Michael.Poulin@uk.fid-intl.com> wrote:

I think, Duane describes a version control mechanism where consumers subscribe to the notifications about service version changes. If so, we are talking about constant version control adjustment even for minor changes. Moreover, until the adjustment happens, the consumer cannot use the service (having some downtime) and this affects the consumers that do not use changed feature/function, which is not acceptable for them.

If the version control is based on the explicit version matching mechanism, it results in "Many people whining about service management talk about this but there is no clear convention on  major version/minor version upgrade or what scheme would be used to denote such." This is why I proposed a rule-based version compatibility control that allows for acceptance of several/certain version changes without adjustment for the consumer software (this depends on the consumer needs). The rules are based on the informal or contract related knowledge of the up-coming changes while the rule management is quite formal and may be automated. This is a quick overview of the article Ken mentions.

- Michael

Fidelity Investments - Web Delivery
Phone: +44-173-783-6038
E-mail: michael.poulin@uk.fid-intl.com <BLOCKED::BLOCKED::mailto:michael.poulin@uk.fid-intl.com>  
Web: http://www.fidelity.co.uk/ <BLOCKED::BLOCKED::http://www.fidelity.co.uk/>

Important: Fidelity Investments International (Reg. No.1448245), Fidelity Investment Services Limited (Reg. No. 2016555), Fidelity Pensions Management (Reg. No. 2015142) and Financial Administration Services Limited (Reg. No. 1629709, a Fidelity Group company) are all registered in England and Wales, are authorised and regulated in the UK by the Financial Services Authority and have their registered offices at Oakhill House, 130 Tonbridge Road, Hildenborough, Tonbridge, Kent TN11 9DZ. Tel 01732 361144. Fidelity only gives information on products and does not give investment advice to private clients based on individual circumstances. Any comments or statements made are not necessarily those of Fidelity. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any computer. All e-mails sent from or to Fidelity may be subject to our monitoring procedures. Direct link to Fidelity’s website -
http://www.fidelity-international.com/world/index.html <http://www.fidelity-international.com/world/index.html>


 

From: Duane Nickull  [mailto:dnickull@adobe.com]
Sent: 08 March 2007 17:38
To:  Ken Laskey; soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra]  quick thought on versioning and description

 
I would say yes.  While the myth of late binding  has sort of been debunked, there are certain situations where auditable events  updating a services description could be subscribed to by consumers and  changes could automatically happen.  Such instances would probably be  limited to minor technical reconfigurations rather than wholesale changes in  data models, yet we should definitely consider it a core function.  Many  people whining about service management talk about this but there is no clear  convention on  major version/minor version upgrade or what scheme would  be used to denote such.

D


On 3/8/07 5:59 AM, "Ken Laskey"  <klaskey@mitre.org> wrote:

 
Would it make sense to add a change log to  description where the service provider would list changes that we decide do  not constitute the need to update the service version?  Would the  version number of the service contain an extra field (thinking of this as an  extension to Michael's paper) that indicated a log change but not really  anything else?

Not sure where I'd go with this but wanted to capture  the thought before it  disappeared.

Ken

 
------------------------------------------------------------------------------------------
Ken  Laskey
MITRE Corporation, M/S H305      phone:  703-983-7934
7515 Colshire Drive                          fax:        703-983-1379
McLean VA  22102-7508



 




--  
**********************************************************
Sr.  Technical Evangelist - Adobe Systems, Inc.            *
Chair - OASIS  SOA Reference Model Technical Committee    *
Blog: http://technoracle.blogspot.com                     *
Music:  http://www.mix2r.com/audio/by/artist/duane_nickull*
**********************************************************



--
**********************************************************
Sr. Technical Evangelist - Adobe Systems, Inc.           *
Chair - OASIS SOA Reference Model Technical Committee    *
Blog: http://technoracle.blogspot.com                    *
Music: http://www.mix2r.com/audio/by/artist/duane_nickull*
**********************************************************


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