[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
-- Igor
Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza,
Islandia, NY 11788
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]