Patience please – read what I said at the end! J
From: Lublinsky, Boris [mailto:boris.lublinsky@navteq.com]
Sent: Monday, 31 January, 2011 10:31
To: peter@peterfbrown.com; soa-rm-ra@lists.oasis-open.org
Subject: RE: [soa-rm-ra] State, RWE and execution context
There is still a missing definition – what exactly is a shared state?
Additionally, see comments below
From: Peter F Brown [mailto:peter@peterfbrown.com]
Sent: Monday, January 31, 2011 11:54 AM
To: soa-rm-ra@lists.oasis-open.org
Subject: [soa-rm-ra] State, RWE and execution context
All:
As promised, here are notes on some further discussion with the editors and following a lengthy exchange between Boris and Michael on the issues of state, RWE and execution context.
1. RM definitions are sometimes inadequate as RM doesn’t take account of the wider ecosystem. RM definitions should not be contradicted but may need to be enhanced and extended to fulfil this wider context.
2. Invocation of a service (method) is intended to lead to (a series of) changes in (pertinent) shared state – these system changes should align in the ecosystem with an expected RWE – this is the service provider’s “offer” to the consumer. A ‘good’ service will be one that clearly documents and explicitly states the expected outcome of its use in terms of intended RWE (and not just in terms of shared state changes) and subject to obvious conditions (contract, normal use within tolerated contexts, etc).
3. Shared state changes are aligned with RWE by a series of assumptions regarding ‘normal’/expected execution; expected outcomes, a provider’s assumptions that a given set of changes actually deliver a desired RWE; service descriptions and contract terms - Semantic engagement is important precisely as it helps the consumer and provider establish a level of ‘understanding’ of need and capability; state change and RWE; to see whether there is a ‘fit’
4. ‘Steps’ in service:
a. ‘pre-invocation’ communication between stakeholders (usually service consumer and provider, often also mediator), that also help establish a specific execution context (I’m working with a mobile device; I need delivery to a P.O. Box; I want a seat today, I will be offline tomorrow, you can only deliver to the continental USA, etc)
I am sorry, this is still extremely vague. All that you are describing here should be in the service definition and set of parameters
b. Consumer interacts with a service interface:
i. as a stakeholder, the consumer ‘uses’ (or ‘invokes’) the service
ii. one could say that as a system actor, that same consumer is actually invoking a service method via that interface;
iii. execution context is established (and possibly evolves through execution) which in turn determines the precise service activity that follows;
When you are talking like this I read conversation, which is a specific case
iv. service activity will consist of one or more actions and/or joint actions (of 2-n actors acting together) any of which could themselves be invocations of other services (service methods);
This again sounds like conversation
v. there may be some ‘RWE’ for any stakeholder along the way (an online bookstore runs out of stock of a book – an RWE for the warehouse – and has to order more from the publisher – another service) which is not the context’s customer’s RWE;
Now you are talking about two things – service internals (invisible) and returns, that should be described in service definition
vi. The consumer may further interact as the service execution proceeds (‘This item cannot be delivered to the International Space Station – do you have an alternative delivery address”)
Again, this is a case of conversation, which is a special case
c. service activity ensues, other methods are invoked, possible composition/orchestration/choreography, until
This should be opaque for the service consumer
d. the ‘sum’ (culmination?) of this service activity returns a (set of) shared state change(s) (or an error or handles exception conditions):
This state changes again. What does this mean? In the case of conversation, I do understand, but for a straight service invocation it is just a straight response
i. for the service provider, as a service actor, any changes in shared state will be consistent with its action and process models and the particular execution context;
ii. for the service provider, as an ecosystem stakeholder, those changes are deemed to deliver an RWE consistent with expectations as per service description;
iii. for the consumer, as a stakeholder, those changes may or may not be consistent with their expectation of RWE.
5. The Execution Context determines which states are intended to be changed – it (execution context) does not itself specify actual RWE. Intended RWE is tied to expectation of shared state changes under normal execution conditions (Execution context provides the ‘paths’ through a service to a desired goal – like in a use case scenario – including the successful outcomes and variants, controlled failures/errors and unhandled exceptions) but actual RWE may be more than the sum of one or more changes in shared state;
6. Execution context also determines which states are intended to be shared: hence, the importance of the proposed distinction between “shared state” and “shareable state”. We’re not sure if there is a difference between “shareable state” and “public state” as previously discussed – but the importance to the SOA ecosystem is that shareable states are actually shared according to different contexts.
a. “shareable” or “public” means that part of the state of an entity that could be accessible to another actor;
b. “shared state” means that part of the shareable/public state of an entity that is actually accessed by another actor
7. The RWE that results from a ‘normal’ execution of a service (method) will be context-specific and viewer-dependent, as it is perceived by a stakeholder. The changes in shared state are not context specific and are viewer-independent.
8. The value of a SOA ecosystem (rather than just a ‘bag’ of disparate systems) is that it is an approach that codifies everyday experiences of consumer stakeholders with varying needs together with a range of services and service ‘components’ (in reality distinct services) that can respond to those needs by delivering a range of RWE’s. The value of adding any single service to such an ecosystem is a n+1 ‘network effect’, providing an exponential increase in possible service compositions and RWEs that the ecosystem is able to deliver.
In order to be consistent with our current action item to conclude on some core definitions, it would seem that the above comments touch on the following concepts, which therefore need to be clearly defined and described:
Action
Execution Context
Joint Action
RWE
Service (cf Service Method?)
Service Activity
Shareable or Public State
Shared State
I will update the definitions table in line with this which can then hopefully be used as a reference point for discussions on call on Wednesday (which I will miss as previously announced)
Regards,
Peter
Peter F Brown
Independent Consultant
Transforming our Relationships with Information Technologies
Blog pensivepeter.wordpress.com
LinkedIn www.linkedin.com/in/pensivepeter
Twitter @pensivepeter
P.O. Box 49719, Los Angeles, CA 90049, USA
Tel: +1.310.694.2278
The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.