OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Interim Editors' Draft; Action, State, RWE


Dear colleagues:

“There arises from a bad and unapt formation of words a wonderful obstruction to the mind” – Francis Bacon

 

We think that we have faithfully incorporated all change requests, edits and redrafts that the TC has asked for to date with the exception of the ongoing discussion regarding action, state and RWE. Attached is a sort of “interim draft” that shows the changes we have proposed compared with the 21 Dec version. This is provided to give visibility to the work we have done since the last draft – we will however produce another stable version following tomorrow’s meeting and it should be to that next stable draft that further comments should be addressed.

 

Also attached is a brief diagrammatic representation of an “onion ring” view of the ecosystem, with the capability at the ‘core’. It is *not* a layer model but intended just to highlight where stakeholder, participant and actor fit.

 

Below, we try to further the debate on action, state and RWE and believe the changes proposed are critical to a coherent model. A number of people raise the general issue also about whether we want to include both general concepts and show their specializations to SOA-based systems or just stick with the latter.  There seems to be a fairly strong preference for the latter and that it be a compromise between a higher abstraction level and pragmatism.

 

Chris and I have had long discussions – also with a number of members of the TC – to try to clarify the intent of a number of core concepts. We both feel that there are currently loose ends and vague, sometimes contradictory, statements in the text, mainly around action, state and RWE. I had hoped to do a note that synthesises all the different concerns but lack of time means that what follows is still mainly Chris and my PoV with a few changes and some additional commentary from us and others (Jeff, Ken,

 

We have unresolved issues with Action. Firstly, we should be unambiguous in stating that our definition of Action involves only Actors acting in a System. We also need to distinguish equally clearly:

-        Private Action is and must remain, like a private state, opaque to the SOA-based system. A Private Action can only impact the Private State of that Actor;

-        A Private Action may also lead to (trigger?) a Public Action of the same (and only the same) Actor – this is necessary when an Action needs to be ‘exposed’ to other Actors in a System;

-        A Public Action of an individual Actor, is visible to and measurable by other Actors in a System, can lead to a change of either the Private or Public State of the Actor in question, and could contribute to a change in some Shared State of which the Actor’s Public State is part;

-        A Joint Action is the Composition of two or more Public Actions, and which can also contribute to any State (Private or Public) of an Actor or to a particular Shared State of two or more Actors. A Joint Action may involve Private Actions, but that fact is not pertinent to this viewpoint.  However, pertinent to this viewpoint is that in order to be joint, there must be public actions involved.

 

(Note: interaction can be a series of actions, each discrete; a joint action from the outset is a deliberate ‘composition’)

 

o   A ‘Communicative Action’ is really just a communication.  Actions may be performed via communications (probably, these are est defined as interactions), but calling it a ‘Communicative Action’ doesn’t really help, and in fact results in more confusion than help.

o   Since we don’t have communicative action a ‘Service Action’ is just Action.

We would propose therefore to replace the term communicative action with communication, and modify any dependent text accordingly; and make references to “service action” be simply “action”.

 

We have already defined State as a complex “set of facts” (even if we are only concerned with the “subset of the State of an entity that is potentially measurable and useful in a given context”). To be coherent and clearer we would propose four distinctions regarding State:

Firstly, that part of the overall State of an Actor that is hidden from all other actors is private.  The set-complement part of the overall state is public. Period.  (This implies that those elements of the overall state of an actor that are knowable to at least one other actor are considered part of the first actor’s public state).

-        The Private state of any actor is by definition that part of the set of facts of an Actor’s complete state that is opaque to any other actor in a system or beyond;

-        The *Public* state (and not Shared State) is that part of the set of facts of an actor’s complete state that is visible to at least one other actor.

So,

Secondly, Shared State should thus be more accurately defined as being “an aggregation of the pertinent parts of the Public States of two or more actors”. This is, we think, a more precise/concrete definition of shared state than what is in the RM.

Thirdly, as presently defined in the RAF, “Shared State” can be limited to the ‘non-private’ state of a *single* actor which is contrary to common sense and seems plain wrong.  We are asserting that Shared State requires more than one actor.

Fourthly, either the Public State of a single Actor, or the Shared State of two or more Actors, can “contribute to”, “result in”, or “equal” a RWE in the ecosystem (exact relationship needs defining – see below).

 

Another problem: RWE.

We do not adequately define (either in the RAF or in the RM) the relationship between state and RWE, so here goes…

State and Shared State are issues related to Actors and thus belong to the scope of a system, whereas RWE is related to the ecosystem:

-        An Actor has State and its State change is a result of Actions within the System;

-        Stakeholders are concerned with outcomes - needs being satisfied by a RWE, not with the details of State changes.

We should not talk about the “shared state of the ecosystem” – taken literally it is probably immeasurable, changes all the time and if it could be measured, it rarely will tell us anything useful. The actual RWE does, on the other hand, exist in the ecosystem, and that is what Stakeholders are interested in.

We currently have two (partly conflicting) definitions of RWE, one of which (“a measurable change to the shared state of one or more participants”) would have to be dropped if our new approach is agreed. A Participant qua Actor would have a change in State, but a Participant qua Stakeholder does not.

The second definition is closer to the mark: a “measurable change in the overall state of the SOA ecosystem”.

We would propose therefore to define Real World Effect as “(the result of?) a measurable change in the Shared State of two or more Actors that is relevant to Stakeholders and effected in the Ecosystem.” One open question is whether the RWE *is* the (relevant parts of) the change in shared state or is something distinct “caused by” that state change…

 

An example of this would be someone ordering a book.  The need is for a book.  The joint action is the ordering of the book.  The bookseller performs private actions and public actions.  One of the public actions is to charge the requestor’s credit card, and the other is to send a package with a book in it to the requestor’s address.  The RWE, on the other hand, is the book getting to the requestor’s porch.  The shared state was a charge on the requestor’s account, and a book in transit. 

 

Some other comments:

The distinction between (SOA-based) system and (SOA) ecosystem is necessary to anchor the SOA paradigm in the real world – it’s not just systems talking to other systems and doing great stuff through joint actions – the actions have an impact in the real world of humans and meatspace – that’s RWE for me… and also why execution context is critical – I agree with Dave that this is still not adequately addressed.

 

Note that stakeholders in the ecosystem are interested in the RWE.  Actions and shared state are what happens in the SOA-based system (i.e., are system-level things).  We (Peter and Chris) think that making this distinction better connects/aligns the system level to the ecosystem-level (i.e., the automation to the business), and is really the core of the “participating in a SOA ecosystem” viewpoint.

 

This raises another question for me: Are all actions in a SOA-based system concerned with delivering RWE? I think it is potentially dangerous to miss out the ‘link’ between system and ecosystem. This is why participant is such a key concept, as they are both stakeholder and actor but the two roles have different modelling implications: for example, a consumer/user – they play the role of ‘actor’ in which the computer is a delegated agent, to perform some online purchase; but at the same time, they are also a stakeholder, looking for a RWE as outcome.

 

A shared state may be changed (and thus the system engineer is satisfied that everything is working according to specs) but the shared state may still not deliver the desired RWE that the stakeholder expects and for any number of reasons. It is the ‘short-circuiting’ (or bundling together) of those steps that are the source of many system failures to deliver RWE, IMO…

 

These issues are also important with regard to trust: The ecosystem basically exists to satisfy human needs, even if a lot of the mechanics is automated.  The ecosystem doesn’t work without trust and delegates as the instantiation of automation don’t alone manifest trust. The ‘chain of trust’ has to be traced back to the ecosystem stakeholder and not left at a system-level actor. Trust is not system-level (where we’re assuming system-level means implementation) but is connected with the ultimate user that has the need and defines what actions it has willingness to conduct.

 

Further issues:

We may have some modelling issues to deal with, and that may not be possible using only UML Class Diagrams:

‘Participant’ is a mongrel, both Stakeholder and Actor (which is correct) but is difficult to model cleanly. For example, if we take our book-buying scenario, the participant, in the role of a consumer, is both an Actor – the ‘agent’ interacting with a computer, clicking buttons and filling text fields in an online bookstore’s web site and a Stakeholder – looking forward to a need being fulfilled when an ordered book arrives. The modelling of their interaction as an Actor is necessarily different from the modelling of their behaviour and actions as a Stakeholder.

UML only properly covers actively interacting ‘actors’ and ‘operational roles’. It doesn’t model Stakeholders in our broader ecosystem view. We may need to use a Context Diagram (not supported in UML) to show the onion-like layers of capability, system, service, ecosystem and the context of actors and stakeholders. We would then be able to see and understand why and how participants ‘straddle’ these different layers.

We might also benefit from UML State Machine or Activity diagrams to help visualise the relationship between action, state (change) and RWE (maybe using a swimlane model to show actor, participant and stakeholder too).

 

Recommendations:

-        Open discussion in the TC meeting around these concepts and issues;

-        redraft the references to action, state and RWE in line with this approach above and/or the results of the TC discussion

-        accept the new draft of section 3 (Jeff, maybe you could join us with 1 & 2?) as the new “line in the sand”, making this the new “reference draft” to continue to work from. If there are disagreements, we at least have all the previous iterations and materials to fall back on as needed.

 

We have also some minor editorial concerns: Large chunks still read like an academic treatise and not like a standard using core conformance terminology. We intend to check in the text on the use of all modal verbs (will, may, might) and conformance terms (MAY, SHALL, etc.). For example, the use of ‘…will…”: it is often not clear if this is an implicit assumption (“it ought to..”); we are making a statement of fact (descriptive, “it is…”); or indicating what we wish (prescriptive, “it SHALL…”). There are many, many such instances and they need to be disambiguated. Some have already been highlighted in the attached interim version.

 

Best regards and talk on the call tomorrow,

Peter

 

Peter F Brown

Independent Consultant

Description: Description: cid:image002.png@01CB9639.DBFD6470

Transforming our Relationships with Information Technologies

Web       www.peterfbrown.com

Blog        pensivepeter.wordpress.com

Twitter   @pensivepeter

P.O. Box 49719, Los Angeles, CA 90049, USA

Tel: +1.310.694.2278

 

Editors' Interim Draft-2011-01-06.pdf

Action, State and RWE.pptx



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]