[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Diagram
This could get boring but I basically agree with Frank. :-) Ken On Dec 7, 2005, at 6:26 PM, Francis McCabe wrote: > 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> > > ------------------------------------------------------------------------ ------------------ Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]