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