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

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

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


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


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.




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