[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] My stab at an SOA-RM concept map
Oh gosh, now we're opening Pandora's box. First dynamic cmaps, next dynamic UML and a generation of confused software developers :-) On 31-May-05, at 9:01 PM, Chiusano Joseph wrote: > Leverage your recent purchase of Macromedia and make it a Flash > concept > map.:) > > Joe > > Joseph Chiusano > Booz Allen Hamilton > Visit us online@ http://www.boozallen.com > > > >> -----Original Message----- >> From: Matthew MacKenzie [mailto:mattm@adobe.com] >> Sent: Tuesday, May 31, 2005 8:56 PM >> To: SOA-RM >> Subject: Re: [soa-rm] My stab at an SOA-RM concept map >> >> Vikas, >> >> Good idea re: feedback loop. I'm not sure how I would >> represent dynamism in the map though... >> >> -matt >> On 31-May-05, at 6:58 PM, Vikas Deolaliker wrote: >> >> >>> >>> >>> Is semantics the same as context? If it governs almost >>> >> every entity in >> >>> SOA, then perhaps, one could split it up into SemanticGroups. Also >>> there is no feedback loop with semantics i.e. it looks static. >>> Semantics would most likely change over time i.e. dynamic. >>> >>> Thanks >>> Vikas >>> >>> >>> -----Original Message----- >>> From: Frank McCabe [mailto:frank.mccabe@us.fujitsu.com] >>> Sent: Tuesday, May 31, 2005 11:56 AM >>> To: Matthew MacKenzie >>> Cc: SOA-RM >>> Subject: Re: [soa-rm] My stab at an SOA-RM concept map >>> >>> I do, ... >>> >>> To start with ... >>> >>> semantics is much like architecture: it is about concepts and the >>> relationships between them. In our case, however, the semantics of a >>> service is really about the expectations for the service: what do we >>> need to know in order to effectively use the service and >>> >> what will be >> >>> the expected result of using the service. >>> >>> This last aspect is pretty open ended of course: the service model >>> for my son's piggy bank may be identical to the service model for my >>> grown-up bank: but the expected result of a withdrawal is >>> dramatically different. >>> >>> So, I think, that data model, policies, processing model, are all >>> aspects of the semantics of a service. >>> >>> To be able to capture the expected results of using a service >>> requires a deeper modeling of the context in which services are >>> deployed. Speaking personally, I am in favor of such a modeling, but >>> perhaps people may be a little surprised at what would be involved >>> (hint: it brings in concepts such as institutional facts, norms, >>> roles, authority, empowerment) >>> >>> Frank >>> >>> >>> >>> >>> On May 31, 2005, at 11:18 AM, Matthew MacKenzie wrote: >>> >>> >>> >>>> >>>> On 31-May-05, at 2:02 PM, Behera, Prasanta wrote: >>>> >>>> >>>> >>>> >>>>> #1: Can u expand a little bit on the semantics of "govern"? >>>>> Semantics >>>>> "define" and "govern" policy. >>>>> >>>>> >>>>> >>>> >>>> It's just the best verb that popped into my head as I was drawing. >>>> It seemed appropriate, since semantics do form a "glue" of sorts >>>> for the various elements...at least that is my understanding from >>>> discussions I've been part of. Do you have a suggestion to replace >>>> it? >>>> >>>> >>>> >>>> >>>>> >>>>> #2: The relationship between "Data Model" and "Services" -- should >>>>> it be >>>>> more of a association type (line instead of a arrow) >>>>> >>>>> >>>>> >>>> >>>> It's a concept map, I don't think there are association types. In >>>> fact, I mean for there to be arrows on every line. There is a >>>> problem with the drawing tool which I am investigating. The line >>>> you mention may not be necessary, strictly speaking. >>>> >>>> -matt >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> Thanks, >>>>> /Prasanta >>>>> >>>>> -----Original Message----- >>>>> From: Matthew MacKenzie [mailto:mattm@adobe.com] >>>>> Sent: Tuesday, May 31, 2005 9:13 AM >>>>> To: Francis McCabe >>>>> Cc: SOA-RM >>>>> Subject: Re: [soa-rm] My stab at an SOA-RM concept map >>>>> >>>>> Having some problems with arrows in this tool, but I added another >>>>> relationship to contract (attached). >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]