[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]