RE: [wsrf] Modeling Potential Service Groups

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

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