RE: [soa-rm] changing shared state to shared view

[Rex Brooks <rexb@starbourne.com>]

As long as we are explicit that our use of "view" does not imply any 
given window state of the display of some service's information at 
any given point in time, I'm fine with it. I think that needs to be 
explicit because otherwise it opens the door for confusion with some 
web services specification usages of the term.

For me shared state is very specific to a set of shared values for 
value pairs in a given data signature and syntax.That's what I was 
getting at with the suggestion of using "viewpoint" instead, although 
now that I have been made aware of the ISO standard that defines 
viewpoint, it seems it may not be a good substitute. However, not 
having the definition to hand, I can't say. It could be spot on. 
However, having read through this discussion again, I think viewpoint 
is the better word because it implies the point at which a viewpoint 
is defined and shared, temporally, and ought to do a better job of 
describing what is shared than "view" alone. However, the need to be 
explicit that it is not referring to a given instance or type of 
viewpoint remains.

>I also suggest that "differentiated" might be better than 
>"accumulated," e.g. "On the other hand, public actions result in 
>changes, some differentiated viewpoint shared at least between those 
>involved in
the current execution context and possibly shared by others." This 
keeps the results (state) and the viewpoint (view of state) in step.

Cheers,
Rex


At 3:30 PM -0400 4/12/06, Metz Rebekah wrote:
>Considering the amount of time we spent determining what pre-conceptions
>ride along with specific word selections, I am looking forward to the
>discussion on the remainder of this thread regarding shared state/shared
>view.
>
>Is it fair to characterize the difference as:
>
>"View" incorporates the concepts of perspective and subjective
>interpretation where as "State" treats these concepts as orthogonal.
>
>
>Rebekah Metz
>Associate
>Booz Allen Hamilton
>Voice:  (703) 377-1471
>Fax:     (703) 902-3457
>
>
>-----Original Message-----
>From: Peter F Brown [mailto:peter@justbrown.net]
>Sent: Monday, April 10, 2006 4:54 PM
>To: 'Ken Laskey'
>Cc: soa-rm@lists.oasis-open.org
>Subject: RE: [soa-rm] changing shared state to shared view
>
>Ken:
>why "accumulated" in "accumulated view"? I think I see where you are
>going but this sounds a bit suspect.
>
>I'm still not convinced about this choice of word, "view":
>
>Firstly, If two entities share the same view, they are standing at the
>same point and looking at the same thing: the point about "shared state"
>is that there are certain characteristics about a service interaction
>that change, including the state of the entities engaged in the
>interaction. They actually might have - probably have - different views
>on their...shared state
>
>Secondly, as a metaphor it doesn't stand up to scrutiny and could be
>confusing: "View" is a question of perspective and subjective
>interpretation of an observer, it does not imply any change to the
>reality being viewed. "State" is - or at least implies - something more
>empirical.
>
>I think shared state is still better...
>
>Peter
>
>-----Original Message-----
>From: Ken Laskey [mailto:klaskey@mitre.org]
>Sent: 09 April 2006 01:55
>To: SOA-RM
>Subject: [soa-rm] changing shared state to shared view
>
>As we came to realize at the end of the call, this may be a better means
>to convey our intent but it was not going to be as trivial as a find and
>replace.
>
>I am including the text of the collected changes below and while it
>looks great in Apple Mail, I have no idea what it will look like in
>Outlook or other email clients. I am also attaching a Word document with
>Track Changes.
>
>Enjoy.
>
>Ken
>
>[lines 138-144]
>The purpose of using a capability is to realize one or more real world
>effects. At its core, an interaction is an act as opposed to an object
>and the result of an interaction is an effect (or a set/series of
>effects). This effect may be the return of information or the change in
>the state of entities (known or unknown) that are involved in the
>interaction. We are careful to distinguish between public actions and
>private actions; private actions are inherently unknowable by other
>parties. On the other hand, public actions result in changes, some
>accumulated view of which is shared at least between 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 view[KL1].
>[lines 277-282]
>The consequence of invoking a service is a realization of one or more
>real world effects (see Section Error! Reference source not found.).
>These effects may include:
>
>1.	information returned in response to a request for that
>information,
>2.	a change to the shared view of defined entities, or
>3.	some combination of (1) and (2).
>
>Note, the service consumer in (1) does not typically know how the
>information is generated, e.g. whether it is extracted from a database
>or generated dynamically; in (2), it does not typically know how the
>changes in the view (or more directly how properties of the entities)
>are effected.
>[lines 464-496]
>Real World Effect
>There is always a particular purpose associated with interacting with a
>service. Conversely, a service provider (and consumer) often has a
>priori conditions that apply to its interactions. The service consumer
>is trying to achieve some result by using the service, as is the service
>provider. At first sight, such a goal can often be expressed as trying
>to get the service to do something. This is sometimes known as the real
>world effect of using a service. For example, an airline reservation
>service can be used to learn about available flights and seating and to
>eventually book travel the desired real world effects being needed
>information and eventually a seat on the right airplane.
>
>As was discussed in Section 3.1, a real world effect can be the response
>to a request for information or the change in the state of some defined
>entities, where the service participants share the combination of state
>information that manifests itself as a shared view [and added to
>Glossary] of the changes. In this context, the shared view does not
>necessarily refer to specific state variables being saved in physical
>storage but rather represent shared information about the affected
>entities. So in the example of the airline reservation, the shared view
>that there is a seat reserved on a particular flight represents a common
>understanding between a future passenger and the airline but the details
>of actual state changes on the part of the passenger (e.g. actions
>required to pay for the ticket) or the airline (e.g. that a seat is sold
>for that flight) are not shared by the other.
>
>
><file://localhost/Users/family/Library/Caches/TemporaryItems/msoclip1/01
>/clip_image002.png>
>
>Figure 1 Real World Effect and shared view[KL2] The internal actions
>that service providers and consumers perform as a result of
>participation in service interactions are, by definition, private and
>fundamentally unknowable. By unknowable we mean both that external
>parties cannot see others private actions and, furthermore, SHOULD NOT
>have explicit knowledge of them. Instead we focus on the set of facts
>shared by the parties the shared view. Actions by service providers and
>consumers lead to modifications of this shared view; and a real world
>effect of a service interaction is the accumulation of the changes
>visible through the shared view.
>
>There is a strong relationship between the shared state and the
>interactions that lead up to that state. The elements of the shared
>state SHOULD be inferable from that prior interaction together with
>other context as necessary. In particular, it is not required that the
>state be recorded; although without such recording it may become
>difficult to audit the interaction at a subsequent time.[KL3]
>
>For example, when an airline has confirmed a seat for a passenger on a
>flight this represents a fact that both the airline and the passenger
>share it is part of their shared view. Thus the real world effect of
>booking the flight is the modification of this shared view the creation
>of the fact of the booking. Flowing from such facts, the passenger, the
>airline, and interested third parties may make inferences for example,
>when the passenger arrives at the airport the airline confirms the
>booking and permits the passenger onto the airplane (subject of course
>to the passenger meeting the other requirements for traveling).
>
>For the airline to know that the seat is confirmed it will likely
>require some private action to record the reservation. However, a
>passenger should not have to know the details of the airline internal
>procedures; likewise, the airline does not know if the reservation was
>made by the passenger or someone acting on the passengers behalf. The
>passengers and the airlines understanding of the reservation is
>independent of how the airline maintains its records or the precise
>individual who initiated the action.
>
>[between lines 885 and 886]
>Shared view
>The combination of state information that manifests itself to service
>participants as a result of interacting with a service.
>
>[KL1]add to Glossary
>[KL2]need to change figure
>[KL3]Frank Im not sure how to work this in because it seems to be
>requiring visibility beyond the shared view. I suggest deleting but I
>will leave it to you to reword.


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309