[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] changing shared state to shared view
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-----
>From: Frank McCabe [mailto:frank.mccabe@us.fujitsu.com]
>Sent: 11 April 2006 22:08
>To: Rex Brooks
>Cc: Chiusano Joseph; soa-rm@lists.oasis-open.org
>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
>>> Visit us online@ http://www.boozallen.com
>>>
>>> -----Original Message-----
>>> From: Danny Thornton [mailto:danny_thornton2@yahoo.com]
>>> Sent: Tuesday, April 11, 2006 5:29 AM
>>> To: soa-rm@lists.oasis-open.org
>>> 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
>>>
>>> --- Peter F Brown <peter@justbrown.net> 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 [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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Tired of spam? Yahoo! Mail has the best spam protection around
>>> http://mail.yahoo.com
>>
>>
>> --
>> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]