<quote who="ken">
but then wouldn't "shared view" take us right where we want to be.
</quote>
No: two entities can share a state, but the only way in which they can share
a view, is to be the same entity...
Peter
-----Original Message-----
Sent: 12 April 2006 03:01
To: Rex Brooks
Subject: Re: [soa-rm] changing shared state to shared view
I knew this one was going to get sticky. There are two things I believe we
have to deal with:
1. At the MITRE presentation, more people expressed confusion over the use
of the term "state" than anything else. While we didn't get any formal
issues on this, my experience indicates a need for clarification.
2. Lines 277-282
The consequence of invoking a service is a realization of one or more real
world effects (see Section 3.2.3). These effects may include:
1. information returned in response to a request for that information, 2. a
change to the shared state of defined entities, or 3. some combination of
(1) and (2).
and then lines 477-480
Instead we focus on the set of facts shared by the parties – the shared
state. Actions by service providers and consumers lead to modifications of
this shared state; and the real world effect of a service interaction is the
accumulation of the changes in the shared state.
To me, this is an inconsistency and the changes I suggested also addressed
this to bring it more in line with 277-282. Any subsequent changes must
deal with this.
That said, my first impression of Frank's 3-part explanation was
2. Views on the shared state. These are inherently not
shared -- a view is a
view point of a participant.
accurately notes that a view or viewpoint is of a single participant but
then wouldn't "shared view" take us right where we want to be.
Back to basics again, state is a fact or collection of facts that capture
aspects of an entity. These are "real" and not just a view in a context.
State exists whether you explicitly enumerate all its aspects (i.e. all the
possible state elements) or not. (Yes, Frank, you can never enumerate ALL.)
Shared state would be those elements of state we enumerate and we can both
observe. Now if what is exposed in the execution context is a roll-up of
various state elements, is that also a state or a "view" created by
combining states -- one might say an "accumulated view"?
Personally, I knew what we meant when we originally wrote it and I don't
care if it is a state or a view. I feel a responsibility to make a good
faith effort on the first issue above and an imperative to deal with the
second. Other than that, I'm open to miracles.
Ken
On Apr 11, 2006, at 7:48 PM, Rex Brooks wrote:
There was no intentional connection with ISO 10746 part 1, and I
would need to review it to determine if I might think it appropriate Since
that entails a fee, I'll have to take a pass. My main point was simply that
the word "view" has some given implications, such that a "view:edit"
denotes a specific kind of shared state, i.e. an editable window state, and
any changes in that window's contents or a change to a different view, e..g.
"view:help" may also constitute a new shared state. That starts getting very
concrete. That was the reason why I suggested viewpoint might be a better
choice. If viewpoint is also a compatible and appropriate use wrt ISO 10746
part 1, good. If not, not good, and perhaps what we mean by view or
viewpoint needs to be explicit.
Frank's analysis satisfies me, and it looks like it is needed.
Cheers,
Rex
At 12:39 AM +0200 4/12/06, Peter F Brown wrote:
I think Frank's three point summary hits the nail on the
head: to avoid
Rex's dragons, I would guess that the cutoff point between
RM and RA needs
to lie somewhere in the second point...
Rex's suggestion of "viewpoint" is interesting: this is the
terminology used
in ISO 10746 part1 ('viewpoint specifications') - is this
deliberate? is it
appropriate, given the possible dangers flagged up of mixing
an essentially
OO reference model (ODP-RM) with a service-oriented one?
Peter
-----Original Message-----
Sent: 11 April 2006 22:08
To: Rex Brooks
Subject: Re: [soa-rm] changing shared state to shared view
Stirring it a bit here ...
Technically, the strong point is that there *is* shared
state between the
service parties. However, note, that there is a strong
temptation to 'drop
it on the floor', or to 'let it slip between one's fingers'.
The reason is that although the state is shared, it is not possible to share
any *record* of the state; and, furthermore, different
parties have
different views on their state and hence their shared state.
Again, there is an isomorphism between the shared state and
the
conversations (exchange of messages) that give rise to that
shared state.
For example, in the airline booking case, the exchange of
messages about
booking a flight is often used as proof of the commitments
of the parties:
to pay for the ticket and to put a bum on a seat.
I think that there are three things that are separate but
related:
1. Shared state -- shared commitments, shared facts.
2. Views on the shared state. These are inherently not
shared -- a view is a
view point of a participant.
3. Evidence -- messages which imply commitments, shared
facts and so on.
Now, the existing text does not go into this in great
detail, that was
deliberate. However, if this is desirable I can generate a
deeper
explanation based on this analysis.
Frank
On Apr 11, 2006, at 6:54 AM, Rex Brooks wrote:
I can assure you, from the OASIS WSRP TC viewpoint,
re shared-state
"There Be Dragons." Unless you want to take a ride
down the whirlpool,
it is probably wise to steer away from the area
between Scylla and
Charybdis.
I don't think there is an adequate way to avoid
getting very concrete
once you start making statements about shared
state, because you are
immediately in the realm of session state, method-
get v. method-post,
Asp, Jsp, Php, AJAX, etc. Other than saying that it
is possible to
share state and that it will happen when
aggregating services, I
wouldn't open that door. I don't think you want to
skirt the edge of
using the term "view" in anything other than an
utterly abstract
context. I would actually advise using the term
"viewpoint" to move it
further from "view" which is used in very concrete
applications, i.e.
view:help, view:edit, view:admin, etc.
Cheers,
> Rex
At 8:47 AM -0400 4/11/06, Chiusano Joseph wrote:
Just throwing a potential alternative into
the mix:
State alignment (used by BPSS)
Joe
Joseph Chiusano
Associate
Booz Allen Hamilton
700 13th St. NW, Suite 1100
Washington, DC 20005
O: 202-508-6514 C: 202-251-0731
-----Original Message-----
From: Danny Thornton
Sent: Tuesday, April 11, 2006 5:29 AM
Subject: RE: [soa-rm] changing shared state
to shared view
Peter makes an interesting point about
views and state. I think of a
service as containing state (could be
shared state). I think of a
>> consumer as having a view or views of a service and a
service as
being a provider of views. Bob observes a
book from the front and it
is 7 inches wide and 9 inches tall.
Jane observes the same book from the side
and it is 2
inches wide and 9 inches tall. The state
of the book
remains the same for both views. If my
daughter changes the state of
the book by drawing pretty pictures on the
cover, then the views for
Bob and Jane change. If the book is
morphed into a computing
service, Bob an administrator, and Jane a
customer, there are
equivalent computing views for the two
views of the book.
Applying the above example to changes for
lines 141
-144:
[Original 141-144] On the other hand,
public actions result in
changes to the state that 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
state.
Comment: Using the airline example, the
shared state change could be
the consumer's awareness of the seat
availability or the consumer
having reserved a seat.
The consumer has a view of the seats but
does the consumer have state
for the seats? A reader is likely to
understand the intended meaning
of the sentence without having to ask this
question.
[Modified 141-144] 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.
Comment: Using the airline example,
reserving a seat on the airline
changes the view for current and future
consumers. The airline
service has state for the seats and
provides views of the seats, but
does the
airline service itself see views of the
seats? This
takes a little more thought for the reader
to understand.
Danny
wrote:
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
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.
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.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best
spam protection around
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309
---
Ken Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508