[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsdm][OMod] On the updated Mows data model with versioning
Some observations on the latest (Igor's email of 2003-11-14) MOWS data model with versioning:
1. The cardinality of the predecessor/successor relationship between Revisions should be Many-Many or at least 1-Many. A 1-1 relationship would work fine if revisions were linear, but in real life Revisions normally form a tree and occasionally a graph. A 1-Many relationship would be able to represent two (or more) successors, for example, Rev 1.5 could have a successor, patch release 1.5.1, and also have a successor, major upgrade release 2.0.0. I believe a 1-Many relationship would cover most real-world cases. A Many-Many relationship woule be used to represent a "merge" or convergence of two or more earlier branches. For example, due to time and resource constraints, we may have had to release patch release 1.5.1 while our manyor development thread was released as 2.0.0, but we plan to bring these branches together in the 2.0.1 release. While tracking thay type of merge relationship is critical for source code, it is useful, but less critical for releases. So,1-Many would handle most cases, Many-Many would provie
2. I'd like to elaborate on the notion of Revision, as we may want to give it a broader name. A concept that we should be incorporating is the notion of a package of consistent services. I'm thinking that the Revision entity type may serve as a way to represent a package (i.e. collection) of consistent services, interfaces, etc., but we may want to broaden its name to something like Release Package. So I'd like to hear the group's comments on whether Revision can serve as the "Release Package" role or we need another mechanism to represent a collection of consistent pieces and parts.
Regards,
Brian
Brian Carroll
Sr. Dir., Architecture
Merant
(ofc) (503) 617-2436
(cell) (503) 318-2017
brian.carroll@merant.com
-----Original Message-----
From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
Sent: Friday, November 14, 2003 8:58 AM
To: fred.carter@amberpoint.com
Cc: Brian Carroll; wsdm@lists.oasis-open.org; Andreas Dharmawan
Subject: RE: [wsdm][OMod] Updated Mows data model with versioning
Here is the diagram to match Fred's words and our discussion. Note that change is an association class. That is what it should be according to UML 2.0.
I don't particularily like 'represents', but could live with it. I would better use 'is about' or something like that.
-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
-----Original Message-----
From: Fred Carter [mailto:fred.carter@amberpoint.com]
Sent: Tuesday, November 11, 2003 2:29 PM
To: fred.carter@amberpoint.com
Cc: Sedukhin, Igor S; Brian Carroll; wsdm@lists.oasis-open.org; Andreas Dharmawan
Subject: Re: [wsdm][OMod] Updated Mows data model with versioning
Sorry to reply to myself. (no I'm not! ;-) )
Thus quoth Fred Carter (~ 11-Nov-03 11:07 AM ~)...
> [On OMod call, I expressed concern about the knowledge within a
> versioned component of its revision since that wants to know about
> successor, etc.]
>
> Might we improve things by changing the arrow between "versioned
> component" and "revision" labeled "has" to 1) point the other way, and
> 2) be labeled "represents". Then the "version tracking subsystem" is
> separate and pointing into the WSDL stuff, not the other way around --
> and doesn't require the changing of an old version to make a new one...
Assuming picture change is acceptable, updates to your wording follow.
I've also attempted to separate the notion of namespace [representing only "sameness"] from versions, /per se/ -- following some of the comments in this thread.
The elements of the Web services architecture, expressed in WSDL, could be versioned. For example description, interface, service and endpoint could be defined in their own namespaces (not necessarily the same). The namespace differences represent that associated component is different.
In this case, the difference is one of version. Therefore, those elements, conceptually become versioned. For example a versioned service is a service that is also a versioned component that has a version attribute. Note that the "versioned component" is a primarily a conceptual notion, not necessarily represented by any structural element of a WSDL description.
However, a versioned component is represented by a revision. Revisions are related to each other via changes that happened between revisions.
Each revision will be associated with a versioned component. Each change indicates a predecessor and successor (if any) revisions. Each change may aggregate multiple change descriptions. Each change description may be looked at as a document or a separate statement of some sort (e.g.
"new interface was implemented").
>
> Thus quoth Sedukhin, Igor S (~ 04-Nov-03 10:31 AM ~)...
>
>> Brian,
>>
>> I don't disagree with the concepts that you were expressing, but
>> according to our earlier discussion
>> (http://lists.oasis-open.org/archives/wsdm/200310/msg00085.html)
>>
>> 1. The versioning was to be expressed in a detail diagram, *in
>> addition* to the concepts diagram. Otherwise the concepts diagram
>> becomes cluttered with way too many things. Also today, per core
>> WSDL there is nothing like what was expressed. We have to keep a
>> practical, concrete point of reference.
>> 2. The diagram had to express that a "versioned element X is an
>> element X", not the vice versa. In your diagram, for example, it is
>> expressed that a "functional interface" is an "interface version"
>> which is not excatly true, IMO.
>>
>> So, I attemted to reformulate your diagram with the above two
>> concerns. The diagram is attached. The words to follow the diagram
>> are as follows.
>>
>> "
>> The elements of the Web services acrhitecture, expressed in WSDL,
>> could be versioned. For example description, interface, service and
>> endpoint could be defined in their own namespaces (not necessarily
>> the same). The namespace could be used to contain the version.
>> Therefore, those elements, conceptually become veriosned. For example
>> a versioned service is a service that is also a versioned component
>> that has a version attribute.
>>
>> Versioned components have revisions that are related to each other
>> via changes that happened between revisions. Each change indicates a
>> predcessor and sucessor (if any) revisions. Each change may aggregate
>> multiple change descriptions. Each change description may be looked
>> at as a document or a separate statement of some sorts (e.g. "new
>> interface was implemented").
>> "
>>
>> --* **Igor Sedukhin* .. (igor.sedukhin@ca.com)
>> --* (631) 342-4325* .. 1 CA Plaza, Islandia, NY 11788
>>
>>
>>
>> ---------------------------------------------------------------------
>> ---
>> *From:* Brian Carroll [mailto:Brian.Carroll@merant.com]
>> *Sent:* Tuesday, November 04, 2003 10:57 AM
>> *To:* wsdm@lists.oasis-open.org; 'Andreas Dharmawan'
>> *Subject:* RE: [wsdm][OMod] Updated Mows data model with versioning
>>
>> Igor and all,
>>
>> Here is an updated slide for the overall MOWS data model that
>> includes versioning. Sorry for the delay, but I just obtained Visio
>> 2003 yesterday.
>>
>> The Change entity relates two Service Versions. For clarity, I've
>> taken Zulah's comments to heart and renamed the relationships between
>> versions as "predecessor and successor".
>>
>> Igor, I will send the updated Visio file to you in a separate e-mail.
>>
>> Regards,
>> Brian
>>
>> Notice: This email transmission and/or the attachments accompanying
>> it may contain confidential information belonging to Merant. The
>> information is only for the use of the intended recipient. If you
>> have received this transmission in error, please notify the sender
>> immediately by reply email, and then destroy all copies of the
>> transmission.
>>
>>
>>
>> ---------------------------------------------------------------------
>> ---
>>
>>
>> ---------------------------------------------------------------------
>> ---
>>
>> To unsubscribe from this mailing list (and be removed from the roster
>> of the OASIS TC), go to
>> http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgroup.php.
>>
>
>
>
--
Fred Carter / AmberPoint, Inc.
mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301
Notice: This email transmission and/or the attachments accompanying it may contain confidential information belonging to Merant. The information is only for the use of the intended recipient. If you have received this transmission in error, please notify the sender immediately by reply email, and then destroy all copies of the transmission.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]