RE: [wsrf] Modeling Potential Service Groups

["Andrea Westerinen \(andreaw\)" <andreaw@cisco.com>]

Replies inline.
Andrea 

> -----Original Message-----
> From: Wilson, Kirk D [mailto:Kirk.Wilson@ca.com] 
> Sent: Monday, June 06, 2005 5:30 PM
> To: wsrf@lists.oasis-open.org
> Subject: RE: [wsrf] Modeling Potential Service Groups
> 
> Andrea,
> 
> Your comment forced me to go back and review the precise 
> semantics of composition according to UML 1.0.  You may be 
> correct that composition is not the perfect way to represent 
> the relationship between printer and jobs, but not for the 
> reason you give.  In a rather curious move in UML 1.0, 
> responsibility for a composite part may be delegated to 
> another object.  From the UML Reference Manual (p. 227): "If 
> the composite is destroyed, it must either destroy all its 
> parts *or else give responsibility for them to other 
> objects*."  (I always thought that was a little strange, but 
> there it is!)  

In UML2.0, the definition has changed a bit to "A form of aggregation
which requires that a part instance be included in at most one composite
at a time, and that the composite object is responsible for the creation
and destruction of the parts. Composition may be recursive."  Whenever I
think of composition, I think of whole/part relationships - and a print
job is not part of the printer :-).

> Actually, the lifetime semantics of a UML 
> composition and a printer/job relationship may not QUITE 
> match, but, on the other hand, I'm less sure of what UML 
> dependency I would characterize the relationship as exemplifying.

When I say "Dependency", I am thinking of the DMTF CIM Dependency -
which is a "uses" relationship.  In UML 2.0, the definition of
dependency is "A relationship between two modeling elements, in which a
change to one modeling element (the independent element) will affect the
other modeling element (the dependent element)."  So, for me, the print
job is dependent on the current printer (the independent).

> 
> My suggestion might be that the SVG membership may need a 
> semantic qualifier to better express the type of relationship 
> between the group and its members.  Does that sound as if it 
> would be value in this situation?  

My fear would be that you quickly go down the slippery slope of model
semantics, and are then no longer model-agnostic.  You could certainly
carry the general UML association semantics (dependency, aggregation,
composition, etc.) but more semantics than this is certainly a slippery
slope.  

> 
> Kirk Wilson
> Office of the CTO
> 603 823 4023
>  
>  
> 
> -----Original Message-----
> From: Andrea Westerinen (andreaw) [mailto:andreaw@cisco.com]
> Sent: Monday, June 06, 2005 6:09 PM
> To: Wilson, Kirk D; wsrf@lists.oasis-open.org
> Subject: RE: [wsrf] Modeling Potential Service Groups
> 
> Kirk, There is another dimension to printers and jobs that is 
> not appropriately captured by either a component or an 
> aggregation relationship.  If a printer goes down, then its 
> current execution of a job is lost - but the job itself could 
> be sent to another printer.
> Therefore, I would not have used the component relationship 
> at all, but perhaps a dependency.
> 
> BTW, within Cisco, we have a concept of a Collection with a 
> property that indicates if it is explicit (by explicit 
> reference) or implicit (by virtue of execution of a query).  
> This has worked well for us, so far.
> 
> Andrea  
> 
> > -----Original Message-----
> > From: Wilson, Kirk D [mailto:Kirk.Wilson@ca.com]
> > Sent: Monday, June 06, 2005 1:13 PM
> > To: wsrf@lists.oasis-open.org
> > Subject: [wsrf] Modeling Potential Service Groups
> > 
> > All,
> > 
> > Just an additional thought on the problems we were 
> discussing on the 
> > use of Service Groups to model various "real" things like 
> printers and 
> > shopping carts:
> > 
> > While the discussion focused on the difference between 
> collections by 
> > value and collections by reference, there's another 
> dimension to the 
> > issue (of collections by reference) that may be being 
> ignored in the 
> > Service Group specification but which inevitably enters into the 
> > discussion.  And that dimension is the semantics of the membership
> > (part/whole) relationship itself.  UML 1.0 had struggled with this 
> > problem (some would perhaps say, not too successfully) in its 
> > distinction between aggregation and composition.  But the 
> same issues 
> > came up in the conference call.  For example, the 
> relationship between 
> > a printer and its jobs might be modeled in UML 1.0 as composition 
> > because of the lifetime dependency implications of the 
> relationship.  
> > Arbitrary containership, which characterizes the 
> relationship between 
> > a shopping cart and its contents, would constitute yet a third 
> > semantics (which UML apparently did not feel was important 
> enough to 
> > provide built-in modeling).
> > 
> > It seems to me, in just reading the spec, that the intended 
> > relationship is rather loose.  Which implies that we can't 
> expect it 
> > to model every (any - ??) part/whole relationship with 
> accuracy.  And 
> > it may be necessary to explicitly acknowledge the semantics 
> "mismatch" 
> > in things that are modeled as Service Groups.  We need to 
> answer the 
> > questions:
> > "What is the expected semantics of the SVG membership relationship?"
> > and "How do real world relationships differ from it?"
> > 
> > Kirk Wilson
> > Office of the CTO
> > 603 823 4023
> >  
> >  
> > 
>