[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Diagram
Actually, I think that an error/fault report is a legitimate RWE! Perhaps it is not the desired effect... Otherwise if you try to distinguish successful interactions from unsuccessful ones you are going to get into an awful tangle. Again, it is not a question of what needs to be visible. But rather that visibility is an inherent aspect of SOA. Visibility may be enhanced by discovery/descriptions etc. but is a separate concept. For one thing, it is inherently consumer/provider neutral. the relationship between service and interaction is one of usage: to use a service is to interact with it. Keep on trucking Frank On Dec 7, 2005, at 3:13 PM, Duane Nickull wrote: > I couldn't find an accurate description of "exchange" in the current > draft and this was what I inferred. We may wish to beef it up to > explain this better. > > I thought about the capability/interaction thing a lot and am not 100% > sure either way. It is really only a successful interaction with a > service that uses the capability that results in a RWE. An > unsuccessful > interaction results in an error/fault etc. This got me also asking if > having an interaction is too concrete? Does this now mean we have an > infrastructure if there are two things interacting. Not sure but > think > this needs more discussion during f2f. > > Exchange may be best represented similar to how UMl class view > diagrams > use association classes. (see attached). The exchange is part of the > association class? > > The intent on visibility ws to effectively depict that there are > certain > animals that need to be visible, discoverable etc (the three are > service, policy and service descrition). I am not happy either > with the > way it is. Any suggestions for a better way? > > I do like this better than the jigsaw but think it needs refinement. > > D > > ******************************* > Adobe Systems, Inc. - http://www.adobe.com > Vice Chair - UN/CEFACT http://www.uncefact.org/ > Chair - OASIS SOA Reference Model Technical Committee > Personal Blog - http://technoracle.blogspot.com/ > ******************************* > > > -----Original Message----- > From: Francis McCabe [mailto:frankmccabe@mac.com] > Sent: Wednesday, December 07, 2005 2:57 PM > To: Duane Nickull > Cc: Ken Laskey; soa-rm@lists.oasis-open.org > Subject: Re: [soa-rm] Diagram > > Duane: > It is not the interaction that results in a real world effect. > It is the use of the capability that does. > Also I don't think its quite accurate to say that the link between > interaction and service is exchange. You interact with a service by > exchanging information. > The execution context includes *everything* needed to support > interaction. > It is not right to say that visibility = policy+service+description > (as implied by the nesting. We currently state that > visibility=awareness+willingness+reachability. > > Frank > P.S. I gave a talk about the RM to OMG yesterday. Went down very > well. People like the simplicity. > P.P.S. Concept maps are very flexible. That is both an advantage and > a risk :) > > > Of course, what is not captured is how the RWE(tm) itself is > modeled... > > On Dec 7, 2005, at 10:13 AM, Duane Nickull wrote: > >> See new revision. >> >> Answering your and Wes's comments, I have realized I made a gross >> inconsistent decision in the graph. If Service description points at >> Functionality, then Wes is right and it should also point at policy. >> For simplistic sake, I would like to recommend we remove the binary >> association between service description and functionality and >> state in >> accompanying text that if the service description describes >> aspects of >> the service, the functionality represented by the service, along with >> the policy MAY be described along with other aspects of a service. >> >> In keeping with the concept of managed transparency, it would be >> best to >> keep this as a MAY IMO. >> >> KISS! >> >> Duane >> >> ******************************* >> Adobe Systems, Inc. - http://www.adobe.com >> Vice Chair - UN/CEFACT http://www.uncefact.org/ >> Chair - OASIS SOA Reference Model Technical Committee >> Personal Blog - http://technoracle.blogspot.com/ >> ******************************* >> >> >> -----Original Message----- >> From: Ken Laskey [mailto:klaskey@mitre.org] >> Sent: Tuesday, December 06, 2005 10:00 AM >> To: Duane Nickull; soa-rm@lists.oasis-open.org >> Subject: Re: [soa-rm] Diagram >> >> Duane, >> >> In general, I like the diagram but have a few suggested mods: >> >> 1. "Capability Metadata" (not included in current diagram) describes >> a Capability, Service Description just describes the >> Service. However, as seems appropriate to the service provider, the >> Service Description can point to and otherwise reference the >> Capability Metadata if that is useful in describing the Service. >> >> 2. More appropriate to say Service accesses Capability rather than >> represents. >> >> A version hacked in Powerpoint is attached. >> >> Ken >> >> At 12:24 PM 12/6/2005, Duane Nickull wrote: >>> I tried to spin the puzzle diagram into a pseudo layered stack. >>> >>> D >>> >>> ******************************* >>> Adobe Systems, Inc. - http://www.adobe.com >>> Vice Chair - UN/CEFACT http://www.uncefact.org/ >>> Chair - OASIS SOA Reference Model Technical Committee >>> Personal Blog - http://technoracle.blogspot.com/ >>> ******************************* >>> >>> >> >> -- >> >> --------------------------------------------------------------------- >> - > >> -- >> --------- >> / Ken >> Laskey > >> \ >> | MITRE Corporation, M/S H305 phone: 703-983-7934 | >> | 7515 Colshire Drive fax: >> 703-983-1379 | >> \ McLean VA 22102-7508 >> / >> >> --------------------------------------------------------------------- >> - > >> -- >> ---------- >> <SOA-RM-Model-August2005.png> > > <Drawing15.png>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]