OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[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.2and 3.1.2.1


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]