[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] suggested rewording and comments for sections 3.1.2 and 3.1.2.1
Frank, In general I agree with you and the phrase with which you took umbrage was not as precisely worded as it might have been. However, if we do not "stick with the RM definition of a term", we need to be very clear how we changed it, why we changed it, and what it means when someone reads the RM with the previous definition. Ken On Jan 19, 2010, at 4:15 PM, Francis McCabe wrote: > I have a strong reaction to: > >> where the relationship can be that the RAF term is new and the RM >> didn't need that level of detail. > > This presupposes that the RAF is the RM but more so. I do not see > the relationship between the RM and the RAF in that way. > The RM stands on its own, as a description of the key vocabulary > around service and service orientation. > > The RAF is not such a vocabulary. It is an architectural description > of the SOA paradigm. (Jeff puts it better). What are the key pieces > of the SOA ecosystem, and how do they relate to each other. > > The RAF does have to go into more detail than the RM; but that is > actually not the primary basis of the relationship between the two: > the RAF is doing something quite different to the RM. > > The RAF also has to touch on areas that were strictly verboten in > the RM. It has to, for example, explain how governance is going to > work. It also has to explain how a SOA system fits into the way > people do their business. (In the RM, it was enough to say that > business was done) > > As such I think that there may well be times when we define a RM > term more crisply than was done there. There are also, a whole ton > of 'new' concepts that do not show up at all in the RM (e.g. > governance, testing, social structure, etc. etc). > > While we should not do so egregiously, or capriciously (getting the > dictionary out here!), I feel no particular compulsion to stick with > the RM definition of a term if we need a better one. > > On Jan 19, 2010, at 12:05 PM, Ken Laskey wrote: > >> Drat the day we didn't take Jeff's advice and ditch the glossary in >> the RM! I remember us going over the glossary carefully but >> obviously not carefully enough. >> >> I would go for a *careful* definition that we are sure is >> consistent with the RM, and we should directly quote the RM when >> possible. A "quick paraphrase" would just make things worse. >> Again, we should avoid RAF-specific terms that don't clearly derive >> from or have an unambiguous relationship with RM terms, where the >> relationship can be that the RAF term is new and the RM didn't need >> that level of detail. >> >> Ken >> >> On Jan 19, 2010, at 1:05 PM, Rex Brooks wrote: >> >>> The problem is the Glossary again. It's the only place RM terms are >>> defined, except of course that the text supercedes the definition. >>> Someone may not have read the RM and if they go looking for the >>> definition, they'll likely end up at the Glossary since they're >>> probably >>> not stimulated by the RAF to actually read and study the RM. >>> Unfortunately the definition in the RM Glossary is not sufficient >>> for >>> the notion of change to shared state. Otherwise, I'd agree. However >>> leaving "effect" out at that point in the RAF leaves a gap that I >>> don't >>> think we can expect a reader who has not studied the RM to fill >>> correctly. How we fill that gap could just as well be a quick >>> paraphrase >>> citing the text of the RM, and I'd be satisfied with that rather >>> than a >>> new RAF-specific definition. >>> >>> Cheers, >>> Rex >>> >>> Ken Laskey wrote: >>>> Rex, >>>> >>>> My point is they are not at odds and are virtually the same. So, we >>>> should either solely use the RM term throughout or, if we feel a >>>> distinction is necessary, then we need to make the distinction >>>> explicit. I lean to the former under the banner of parsimony. >>>> >>>> Ken >>>> >>>> On Jan 18, 2010, at 8:12 PM, Rex Brooks wrote: >>>> >>>>> RE: KL2&3: It's a little awkward to use effect after eliminating >>>>> its >>>>> definition. I don't see where "a measurable change in the state >>>>> of the >>>>> ecosystem" (RAF) is at odds with "...changes to the state that >>>>> is shared >>>>> between at least those involved in the current execution context >>>>> and >>>>> possibly shared by others. Real world effects are, then, couched >>>>> in >>>>> terms of changes to this shared state." (RM). >>>>> >>>>> I don't have a problem with stating explicitly that effect is >>>>> defined >>>>> more narrowly here in the RAF but is still consistent with the >>>>> RWE from >>>>> RM. However, leaving it out leaves a gap in the thread from from >>>>> intent >>>>> and goal to event. >>>>> >>>>> My opinion: it is better to have this delineation included at >>>>> this point >>>>> in the RAF to connect the thread from intent and goal to event. >>>>> It is >>>>> limited to effect v. RWE, and is not at cross-purposes with the >>>>> RM, and >>>>> leaving it out loses that connection. >>>>> >>>>> I don't mind losing the rest. >>>>> >>>>> Cheers, >>>>> Rex >>>>> >>>>> Ken Laskey wrote: >>>>>> Strikethru text is text I suggest replacing. Normal text is >>>>>> proposed >>>>>> changes incorporated into remaining original text. >>>>>> >>>>>> >>>>>> 3.1.2 Action and Joint Action >>>>>> >>>>>> Entities act in order to achieve their *goal*s. In this model, >>>>>> we look >>>>>> at the most basic form of action – an action performed by a >>>>>> single >>>>>> actor – and the case of joint action as required by SOA >>>>>> participants >>>>>> to realize desired real world effects. >>>>>> >>>>>> >>>>>> 3.1.2.1 Action and Actors >>>>>> >>>>>> Figure 6 depicts a model of action showing the relationships >>>>>> between >>>>>> action, goals and effects of action. Here, we focus on the >>>>>> actions of >>>>>> individual entities. However, we should remark that for the >>>>>> most part >>>>>> within a SOA ecosystem, the actions we are most interested in are >>>>>> actions involving multiple participants – we address this >>>>>> further in >>>>>> Section 3.1.2.2. >>>>>> >>>>>> Action >>>>>> >>>>>> Figure 6 Actions, Real World Effect and Events >>>>>> >>>>>> The most important concept in any model of actions and effects >>>>>> is that >>>>>> of *action* itself: >>>>>> >>>>>> Action >>>>>> >>>>>> An *action* is the application of *intent* to achieve a real >>>>>> world >>>>>> *effect* (within the SOA ecosystem). >>>>>> >>>>>> This concept is simultaneously one of the fulcrums of the Service >>>>>> Oriented Architecture and a touch point for many other aspects >>>>>> of the >>>>>> architecture: such as policies, service descriptions, management, >>>>>> security and so on. >>>>>> >>>>>> The aspect of *action* that distinguishes it from mere force or >>>>>> accident is that someone or something intended the *action* to >>>>>> occur. >>>>>> >>>>>> Goal >>>>>> >>>>>> A *goal* is a measurable state of the ecosystem that an actor is >>>>>> seeking to establish. >>>>>> >>>>>> Goals are conditions that people, and more generally actors, are >>>>>> seeking to satisfy. A key aspect of goals is measurability: it >>>>>> should >>>>>> be possible to know if a goal has been satisfied. >>>>>> >>>>>> Intent >>>>>> >>>>>> *Intent* is the commitment of an *actor* to achieve a *goal*. >>>>>> >>>>>> An actor’s *intent* in performing an *action* is to further one >>>>>> or >>>>>> more of the actor’s *goals*. >>>>>> >>>>>> Although *action* causes real world effects and *intent* can be >>>>>> seen >>>>>> in terms of desired real world effects, it is possible that the >>>>>> real >>>>>> world effect caused by an action may not be the one(s) >>>>>> intended. In >>>>>> extreme situations, the actual effects will include unintended >>>>>> consequences that fall outside of, and may run counter to, the >>>>>> intent >>>>>> of the actor. A key aspect of goals is measurability: it should >>>>>> be >>>>>> possible to know if a goal has been satisfied, and this is most >>>>>> often >>>>>> accomplished by examining whether the desired real world effects >>>>>> occurred. >>>>>> >>>>>> In some situations it may be difficult to determine an *actor*’s >>>>>> actual *intent*. This is particularly true for social actions >>>>>> such as >>>>>> those performed within a SOA-based system. >>>>>> >>>>>> However, in most cases, entities in a SOA ecosystem make an >>>>>> assumption >>>>>> of /implied intent/. I.e., if an *actor* performs an *action*, >>>>>> it is >>>>>> assumed that the *actor* also intended to perform the *action* >>>>>> – it >>>>>> was not an accident, or the action of another actor. >>>>>> >>>>>> [KL1] <#_msocom_1> Much of the infrastructure of interaction is >>>>>> there >>>>>> to eliminate the potential for accidental or malicious actions. >>>>>> [KL2] >>>>>> <#_msocom_2> >>>>>> >>>>>> Effect >>>>>> >>>>>> An *effect* is a measurable change in the state of the ecosystem. >>>>>> >>>>>> [KL3] <#_msocom_3> Note the normal *intent* of applying an >>>>>> *action* is >>>>>> to cause an *effect* that reflects the actor’s goals. However, >>>>>> there >>>>>> is often the possibility that the actual effects will include >>>>>> unintended consequences that fall outside of, and may run >>>>>> counter to, >>>>>> the intent of the actor. >>>>>> >>>>>> Changes in the ecosystem may be /reported/ by means of *event*s: >>>>>> >>>>>> Event >>>>>> >>>>>> An *event* is the report of an *effect* of which at least one >>>>>> participant has an interest in being aware. >>>>>> >>>>>> An *event* is a corollary to *action*, where actions result in >>>>>> changes >>>>>> to the state of ecosystem (primarily changes to the states of >>>>>> individual *participant*s)[KL4] <#_msocom_4> ;, and these >>>>>> changes may >>>>>> be manifested as *events* of which participants in the >>>>>> ecosystem have >>>>>> an awareness. >>>>>> >>>>>> Note that, while performing an *action* may be an *event* in >>>>>> which >>>>>> other participants have an interest, an *event* that reports an >>>>>> *action* is not the same as the *action* itself. >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> [KL1] <#_msoanchor_1>Disagree! Part of establishing trust is >>>>>> deciding >>>>>> whether an actor is reliable and not prone to error. It cannot be >>>>>> assumed ahead of time, any more (or less) than one can make this >>>>>> assumption in typical experiences. >>>>>> >>>>>> [KL2] <#_msoanchor_2> >>>>>> >>>>>> [KL3] <#_msoanchor_3>should state things in terms of the RM >>>>>> concept of >>>>>> RWE or need to explicitly relate effect to RWE. >>>>>> >>>>>> [KL4] <#_msoanchor_4>It would be difficult to argue the states >>>>>> changed >>>>>> are “primarily” those of participants and not the states of >>>>>> things, >>>>>> e.g. data objects. >>>>>> >>>>>> >>>>>> >>>>>> ----------------------------------------------------------------------------- >>>>>> >>>>>> Ken Laskey >>>>>> MITRE Corporation, M/S H305 phone: 703-983-7934 >>>>>> 7515 Colshire Drive fax: 703-983-1379 >>>>>> McLean VA 22102-7508 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Rex Brooks >>>>> President, CEO >>>>> Starbourne Communications Design >>>>> GeoAddress: 1361-A Addison >>>>> Berkeley, CA 94702 >>>>> Tel: 510-898-0670 >>>>> >>>> >>>> ----------------------------------------------------------------------------- >>>> >>>> Ken Laskey >>>> MITRE Corporation, M/S H305 phone: 703-983-7934 >>>> 7515 Colshire Drive fax: 703-983-1379 >>>> McLean VA 22102-7508 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> Rex Brooks >>> President, CEO >>> Starbourne Communications Design >>> GeoAddress: 1361-A Addison >>> Berkeley, CA 94702 >>> Tel: 510-898-0670 >>> >> >> ----------------------------------------------------------------------------- >> Ken Laskey >> MITRE Corporation, M/S H305 phone: 703-983-7934 >> 7515 Colshire Drive fax: 703-983-1379 >> McLean VA 22102-7508 >> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/ >> my_workgroups.php >> > ----------------------------------------------------------------------------- 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]