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