| 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----- 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
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----- 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
|