Re: [soa-rm] Groups - Editor's draft of PR2 (soa-rm pr2 changes.pdf) uploaded

[Ken Laskey <klaskey@mitre.org>]

Frank,

I'm in Scotland (arrived last week) and can't even tell if I'm jet
lagged.  The email was composed right after I got here so let me see
if I can clarify.

At 04:55 PM 5/23/2006, Frank McCabe wrote:
> Ken:
>  I am a little confused about some of your comments:
>
>
> On May 19, 2006, at 3:40 PM, Ken Laskey wrote:
>
> >
> - Issue 539:
> Proposed Disposition was modified when edits made and  
> this led to some side effects

[snip]

> >   (3) some wording intended
> > to improve consistency of information  
> > return as an aspect of real world effect was lost
>
> do not know what you are referring to here

see Issues-9, cell M33 for PD.  Below are specifics. 
(Note, don't believe any change intended in italics but I think some got
lost in all the cut and paste.)

---

[last 3 sentences of PD for PR1 lines 138-144 (edit by Peter because
original may be easy to misread)]
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 to the state, that state being
shared between at least 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.

[PR2 164-167]
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 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.

---

[PD for PR1 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 eventually to book travel – the desired real world effects
being needed information and eventually a seat on the right
flight.

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 shared by the service participants. In this context, the shared
state 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 state  - that there is a seat reserved on a particular
flight - represents a common understanding between a future passenger and
the airline. The details of actual state changes – whether on the part of
the passenger (e.g. fund balances required to pay for the ticket) or of
the airline (e.g. that a seat is sold for that flight)  - are not
shared by the other.

[figure here]

Figure 1 Real World Effect and shared state

In addition, 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. Actions by service providers
and consumers lead to modifications of this shared state; and a real
world effect of a service interaction is the accumulation of the changes
visible through the shared state.

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 state.  Thus the real world
effect of booking the flight is the modification of this shared state –
the creation of the fact of the booking.  Flowing from the shared
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 passenger’s behalf.  The
passenger’s and the airline’s understanding of the reservation is
independent of how the airline maintains its records or who initiated the
action.

[PR2 lines 517-561]
3.2.3 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 in order
to book travel – the desired real world effect being a seat on the right
airplane.

[figure here]

Figure 1 Real World Effect and shared state

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

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.

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 state. Thus the real world effect of
booking the flight is the modification of this shared state – the
creation of the fact of the booking. Flowing from the shared 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.
The passenger’s understanding of the reservation is independent of how
the airline maintains its records.
Likewise, the
airline does not know if the reservation was made by
the
passenger or someone
acting on the passenger’s behalf. The passenger’s and the
airline’s
understanding of the
reservation is independent of how the airline maintains its records or
who
initiated the
action.

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 shared by the service
participants.
In this context, the
shared state 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 state - that there is a seat reserved on
a particular
flight - represents
a common understanding between a future passenger and the airline.
The
details of actual
state changes – whether on the part of the passenger (e.g. fund
balances
required to pay for
the ticket) or of the airline (e.g. that a seat is sold for that flight)
- are not
shared by the
other.


> >   (4) other agreed
> > clarifications were lost
>
> Ditto

covered above

> > The discussion leading to PD was
> > email thread concluding 4/26/2006  
> > with my accepting Peter's final changes.  This version is
> > reflected  
> > in the spreadsheet.

covered above

> > - Issue 567 (or 534-4):
> > resolution during May 3 call was not to  
> > change (now line 311).  Believe this also applies to line 595.
>
> Totally confused here. I though that we agreed to remove the "one
> or  
> more" reference

The minutes say, "Leave line 262 as is."  As noted, this
also applies to change to line 595.



> > Other things noticed:
> > - Text added in the Abstract references Figure 1.  Should the 
> > Abstract directly reference rather than just summarize the body of 
> > the document?
> This is probably weird; but it was agreed! I
> can take out the  
> reference easily

I don't have notes that apply to this, so I'm not sure what said. 
If others agree this is weird, I'd drop it.

> > - Section 1.5.1
> >   -- line 106: is there a reason Concept is
> > capitalized?
>
> Its in the diagram ..
>
> >   -- lines 110-112: more
> > accurately, "The relationships between  
> > concepts in this document are not labeled;  the relationship
> > is  
> > described in the immediately preceding or subsequent
> > text."
> fixed
>
> >   -- lines 113-117: all of
> > our relationships have arrows, so is  
> > there any need for these lines?
> leave it in, just in
> case?
>
> >   -- suggest combining
> > Figures 2 and 4, deleting Figure 3 and  
> > saying, "Concept maps are used within this document to
> > indicate  
> > concepts and relationships being discussed in the surrounding  
> > text.  There is no normative convention for interpreting
> > concept  
> > maps.  As used in this document a line between two concepts 
> > represents a relationship, where the relationship is not labeled 
> > but rather is described in the text immediately preceding or  
> > following the figure.  The arrow on a line indicates an  
> > asymmetrical relationship, where the concept to which the arrow 
> > points (Concept 2 in Figure 2) can be interpreted as depending in 
> > some way on the concept from which the line originates (Concept 
> > 1).  The text accompanying each graphic describes the nature
> > of  
> > each relationship."
>
> Agreed.

So this last would supersede the previous comments on the concept map
description.  Right?


> > Now starting to work on all the
> > responses I've got actions on.
> >
> > Ken
> >
> > At 04:35 AM 5/16/2006, frank.mccabe@us.fujitsu.com wrote:
> > > Please review.
> > > Figure 1 has an outstanding edit; otherwise all dispositions 
>
> > > agreed to should be accounted
> > > for. -- Dr. Francis McCabe The  
> > > document named Editor's draft of PR2 (soa-rm pr2 changes.pdf) has 
> > > been submitted by Dr. Francis McCabe to the OASIS SOA Reference 
> > > Model TC document repository. Document Description: This is an 
> > > editor's draft of the second Public Review of the RM v. 1
> > > This has markup to highlight the differences between this version 
> > > and PR1. View Document Details:
> > >
> > > http://www.oasis-open.org/apps/org/
> > > workgroup/soa-rm/document.php?document_id=18173 Download Document: 
> > > http://www.oasis-open.org/apps/org/workgroup/soa-rm/download.php/
> > > 18173/soa-rm%20pr2%20changes.pdf PLEASE NOTE:  If the above
> > > links  
> > > do not work for you, your email application may be breaking the 
> > > link into two pieces.  You may be able to copy and paste the 
> > > entire link address into the address field of your web browser. - OASIS
> > > Open Administration br

--
     ---------------------------------------------------------------------------------
  /   Ken Laskey                                                                \
 |    MITRE Corporation, M/S H305    phone:  703-983-7934   |
 |    7515 Colshire Drive                    fax:      703-983-1379   |
  \   McLean VA 22102-7508                                              /
    ----------------------------------------------------------------------------------