[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]