There is still a missing
definition – what exactly is a shared state?
Additionally, see comments below
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. MP: Great!
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). I would only add that shared state/RWE is accompanied by the sharable RWE, i.e. the RWE that may be used by unknown consumer in the future and which is not defined in the Service Description ( because the service provider does not know about such use of the service results)
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’ MP: Great!
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
MP: The things listed in the parenthesis should be in the Services Description, exactly as Boris said. The ONLY thing a service provider can discuss with the service consumer is additional/consumer's policies that to be included into the Service Contract. However, if you communicate with stakeholders BEFORE the service is created/defined, yes, you can discuss to-be-service features with them, IMO.
b.
Consumer interacts with a service interface:
i. as a stakeholder, the consumer ‘uses’ (or
‘invokes’) the service MP: Great!
ii. one could say that as a system actor, that same consumer is
actually invoking a service method via that interface; MP: that is, invoking Service because a method does not exist w/o the service (it is not a Wonderland)
iii. execution context is established (and possibly evolves through
execution) which in turn determines the precise service activity that follows; MP: I would be extremely cautions about saying "execution context ... possibly evolves through execution" because a change in the EC constitutes the re-testing case for the service. It is the Federal Case.
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); MP: Great! To me this sounds as a conversation or as an orchestration. Both cases are good.
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; MP: I understand that you are talking about the requester of the service. I would not describe it as a context's customer's one but rather as a sharable RWE, as I mentioned before.
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”) MP: Great! Totally fine with me.
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 MP: OK
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): MP: unclear: the service returns and the shared state is established (even if this is an error returned)
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; MP: yes
ii. for the service provider, as an ecosystem stakeholder, those
changes are deemed to deliver an RWE consistent with expectations as per
service description; MP: yes
iii. for the consumer, as a stakeholder, those changes may or may not be
consistent with their expectation of RWE. MP: Great!
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; MP: While I agree with the final conclusion, a few words caught me: I think that EC determines the condition/constraints of the state change, not "which states are intended to be changed"; also "Execution context provides the ‘paths’ through a service to a desired goal" is incorrect in my opinion because EC does not provide the path but rather affects the path provided by the services itself (affects via context's policies).
6.
Execution context also determines which states are
intended to be shared: (MP: see my comments to 5. EC does not define the state to be shared, IMO.) 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. MP: I do not get the relationship with the context here: EC is the set of policies about technical and business execution, nothing more. So, I would not say "that shareable states are actually shared" but rather that shareable states MAY BE shared by consumers other than the one who requested the service initially.
a.
“shareable” or “public” means
that part of the state of an entity that could be accessible to another actor; MP: YES!
b.
“shared state” means that part of the
shareable/public state of an entity that is actually accessed by another
actor MP: yes, but I try present this in different angle - shared is the one which is predicted by the service provider as a part of the service result. In this way it WILL be actually shared at the end of the service execution
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. MP: I am certainly agree with the first sentence but not with the last one. The changes in the shared state are derived from the service results that are influenced by the EC though they are viewer-independent.
8.
The value of a SOA ecosystem (rather than just a
‘bag’ of disparate systems MP: and solutions=SOA-based system) 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. MP: Great!
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
MP: I have found that the term 'Ecosystem' is missed from the list of definitions. Also, I'd like to propose new term - solutions=SOA-based system - to clearer distinguish it from 'just' (technical) system used in SOA ecosystem.
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
P.O.
Box 49719, Los Angeles, CA 90049, USA
Tel:
+1.310.694.2278