I think that Service result is separate. If we take it out of
equation, based on your definition, shareable state can not change as a result
of a service invocation and hence shareable state is RWE which does no change.
Is this what we are saying?
Boris,
I would prefer going with two notions: 'sharable' and 'shared'.
A state may be shared as the actual fact. An element of or an
entity in the SOA ecosystem may be 'shareable' (aka adjective-based naming
convention used for Java interfaces).
So, some examples of 'shared': RWE, service result (between
consumer and service), Service Contract, service mediator, trust, social fact,
state of the SOA ecosystem
So, some examples of 'sharable': RWE,
Service Description, service interface, commitment, willingness, fact,
identifier, ownership, policy, risk, social action, service
provider, service action, role
Non-sharable examples: service body/implementation,
capability
There examples are only in my view but I may be mistaken in
the categorization.
Regarding "...known
information of service and consequently should not change as a result of
invocation. So it can’t be RWE". If the shared
state is a known information about service, a service execution changes this
information, IMO, e.g., a number of service use has increased and the de
facto service ROI increased. That is, the information about the service
changes while the service implementation, Service Description and Contracts do
not. RWE, in this case, includes the information about the service, i.e. it
changes even at the level of the service itself, IMO.
I think we talk about the state of the SOA ecosystem, which
includes "a
known information of service " among known information
about many other things such as consumers, stakeholders, service
mediators, Registries/Repositories, policies, and so on. So, RWE (if we drop
the issue of public/private) is generated as the result of any service
invocation and realises in the change of the state of the SOA ecosystem, at
least.
Guys, can either of you define shared state and give an example?
I do not believe that this thing is anything than a known information of
service and consequently should not change as a result of invocation. So it
can’t be RWE
I feel, Ken we about 9 to 10 out of 10 have a match now (Ohh)
If a service can be used in the ecosystem, the service is
public è not sure yet: if service provider has produced a service
exclusively for particular consumer, is it public or private? I cannot deny
such service though it is not dedicated to access by arbitrary consumers. So, I
do not know. We are saying that all services better be registered in public
Registries to be available to wider audience and this is the Best Practice. Can
we, in this case say that there may be private Service Registries and private
services will be registered in there? I do not know.
A particular use of the service may include
confidential information and the values exchanged as part of the interaction
may be private, but the fact that information is exchanged when using the service
is public. è more
agree than not. See my comments above: I can imagine a VPN and, in this case,
the fact that information is exchanged may be also private. Am I correct?
Some subset of results are RWE as
defined as changes in shared state. è more agree than not. Chris has found a sharing/shared state in
between consumer and service within a service interaction. That is, we have a
change in the shared state that is a part of RWE AND the shared state
that that is not.
To be shared, the knowledge that
these states exist is public but the actual changes, i.e. the “values” during a
given use, may be private è agree
“accessible with no restrictions”. So, if the information is
available as a 7 TB download that would be cut off by most providers, is it
still public? If we require someone to leave an email address, is it
still public? If the information is owned by someone and anyone who is
willing to pay a nominal access fee to cover costs can access it, is it still
public? I expect we will see much in the way of such debates.
Back to our SOA ecosystem. If a service can be used in the
ecosystem, the service is public. A particular use of the service may
include confidential information and the values exchanged as part of the
interaction may be private, but the fact that information is exchanged when
using the service is public. Some subset of results are RWE as defined as
changes in shared state. To be shared, the knowledge that these states
exist is public but the actual changes, i.e. the “values” during a given use,
may be private.
Yes, it is definitely public because it is the status of the
thing , not the status of potential consumers. At least, this is the exact
definition in the UK (Freedom of Information Act in absence of Library of
Congress). Public knowledge is public not because everybody know it
(like Merriam-Webster Dictionary) but because it is available and accessible
with no restrictions.
I do not think the everything is private even in the limit: service
provider is a public entity, Service Description document is public by nature
while Service Contract may be public or private depending on
the agreement while the default state is private.
I seriously think that we have to take the viewpoint when define
public/private: relationship of all things in the ecosystem to the ecosystem is
public for the ecosystem. If we look at anything from this viewpoint, we can
define and explain all things even those that are private by nature like intent
and willingness. If we take a viewpoint of any entity inside the ecosystem onto
another entity inside the ecosystem, it may be public or private. For
example, an intent of a consumer to invoke a service is a private thing while
the fact of invocation itself may be (as default) a public thing since the
service registry is public. And so on.
As I said before, with current definition of 'private', it will be
next to impossible to approach Business with SOA ecosystem.
I believe your argument fails at the other extreme. Is
something public if it is accessible but lots of potential users don’t know it
exists or how to get to it? By your definition, if circumstances limit
access, then it is private and, in the limit, everything is private.
If so (I disagree with this explanation of public), what is
private? What could be private at all?
If the thing belongs to SOA ecosystem, everything is public for
the ecosystem. I accept this. But it may be not public inside the
ecosystem for some of its elements and, in this case, it is private in
the ecosystem.
Some internal Corporate Policies are private in the market but
'public' inside the corporation. In the country, all corporate internals must
be accessible (public) by the government but they may be non-accessible for
other corporations.
We are talking absolutely trivial things. I am confused.
Your getting the book and you now owning the book are
public. The book itself is a book. You writing your name on your
book when you receive it is private.
Agree, "The
... delivery is RWE for anyone involved"
but the book itself is not a part of this RWE because it is my private
thing.
Or, there are no 'private' and 'non-shared' things in SOA
ecosystem?
The book delivery is RWE for anyone involved for which the book
delivery or some part of the process is of interest. The delivery car
amortization is RWE for those dealing with the car financing. Both are
RWE, although likely unrelated, for the business entity delivering the book.
Chris, why do you think that appearance of the book in the postal
package (i.e. nobody knows it is the book) at your doorstep is a RWE (" if I want a book to show up on my doorstep, I may need to
go through several interactions or method calls to get that RWE")?
According to Ken, the delivery car amortization is the RWE, but the book is the
private Result of the service known to you - customer - and to the service
only, i.e. it is not a RWE.
If RWE includes only public/shared things - we are diving into
absurd, don't we? So, if it is me who does not see the forest behinds the trees
then, probably, these trees are Sequia while the forest comprises only Karelian
Birch
I think there are some subtleties that still need to be teased out.
In order to try and get to the concept, I will speak very concretely.
First, a given RWE is not necessarily triggered by a method
call. turns out that a sequence of successful method calls will likely be
necessary, and different sequences may result in different "aspects?"
of a given service. So, if I want a book to show up on my doorstep, I may
need to go through several interactions or method calls to get that RWE, all of
which may be part of the same interface. This is what Ken was referring to
when he spoke of process model on the TC call today.
So ... I think I invoke a service, and invoking a service may be
accomplished by sending multiple messages to multiple "methods" in a
service interface. Each message to each method may trigger a corresponding
action, but the RWE I'm after is the end result of the aggregate of the
actions. Note that an error code, in my mind, is not a RWE, it is an
error and I didn't get the RWE.
In some cases, the information returned is the RWE. Using
the calculator example, let's suppose the calculator has 3 methods. The
first takes operand a, the second takes operand b, and the third takes the
operator (+, -, * or /). The RWE I want is the result of the aggregate of
the method calls. If I get an error code because I send a letter instead
of a number for one of the operands, I won't get the RWE. The RWE is in
this case the return of information.
One could suggest that RWE is, at least in part, in the eye of
the consumer.
Another thought ... I think we have to be careful in our
conceptual model to keep distinct the difference between a service and a
"good" vs. "bad" service. So ... if I design a
"bad" service, is it still a service? This pokes at the
essence of what a service "is".
As for the interface, it turns out that message processing logic
is more than an interface. The RM tries to distinguish the message
processing logic from the business logic. You really need both to have a
service. If you have a great set of business logic, but nobody can get to
it, you don't have a service. If you have a great set of message
processing logic, but no business logic, you don't have a service.
I really liked Jeff's summary on the TC today, where he talked
about interaction being all throughout the lifecycle and ecosystem, but
"service activity" begins at the point that the consumer is actually
invoking the service. The interactions must occur prior to the activity,
and is where the ecosystem stuff comes into play. In which case, the
service action must take into account the activity and process models of the
service that the RM points out.
Is there any major damage by my using red wording inline below?
As for importance of RWE, it is what someone wants and why they
use service. The RWE of a calculator is the result it displays.
·
In accepted terms a service has an interface(s) – Service
interface
·
Service interface has method(s) – Service methods. Service
interface defines message exchange with service
·
A service method (not a service) can be invoked. Message to
service Interface triggers service action through corresponding private actions
·
Service method provides an execution result. Triggering
a service action lead to results.
·
An execution result can either change a service state or return
an error Public Results are changes in states or a return of information
·
A change in a service state may (or not) produce RWE Changes
to public states produce RWE
So far this is excepted set of thing that most of practitioners
will relate to
Now here is a list of questions:
·
How is service action relates to the above? is it a service
method invocation?
·
Why do we care so much about RWE? A calculator is a useful
service with no RWE
Let’s try it this way: a service action (by which I mean
an action from the Action Model) results in the change of public and possibly
private states. The change in public states is RWE, the change in private
states is unknown to the SOA ecosystem unless these become public at a later
time.
I gave this example as an evidence of inconsistency and
brocken/forgotten dependency between definitions.
I have to be more accurate: "then we have said that that result is outside the scope of our
consideration" is not the same as "we just said it is not what we are considering under RWE".
The latter I is true if RWE is public only BUT the former may be understood as
that private service result is out of the scope of RAF! This I cannot agree
with because BOTH types of result belong to the SOA ecosystem.
Service Action produces private (always) and public (sometimes)
results and only the public one is RWE. If you agree with this statement, than
the purpose of the service is to produce Result whether public or
private, or both.
I agree with most of your points, except the final one on
RWE. Someone may use a service to satisfy some private need but if the
result is only known privately, then we have said that that result is outside
the scope of our consideration. We didn’t say the private result didn’t
occur, we just said it is not what we are considering under RWE.
---------------------------------------------------------------------------
MITRE Corporation, M/S
H305
phone: 703-983-7934
7515 Colshire
Drive
fax: 703-983-1379
Before going through details and definitions, I think we have to
agree on the a few principles.
Since RAF is about SOA ecosystem and we agreed that this one
includes both business and technology then:
1) we cannot operate with definitions from RM with no changes
because RM did not considered ecosystem. However, the changes of RM
definitions should not deny the original definitions but may modify/extend them
for the new context - ecosystem
2) all definitions we use have to be either meaningful/"interepretable"
in both Business and Technology or we have explicitly identify
the scope of the definition and justify that it does not work in the entire
ecosystem ( in this case we will never confuse SOA-based system with
'just'/technical system
3) we have to draw a relationship/dependency lines (like in
Value Networks) between our definitions to see consistency and influence
between them.
This better be not in a table format but in a map format. For
example, in one place we say that service purpose is to provide a RWE; in
another place we say that RWE is only shared/pubic thing; this leads to the
conclusion that the purpose of service is to provide only shared/pubic thing, which is incorrect.
If we can agree on these
principles and approach, we can eliminate a lot of unnecessary
discussions
As promised, attached is a comparison of the terms defined in the
28 July 2010 draft alongside the definitions used in the latest draft (in Excel
and .ods formats)
As you will see, there are precious few instances of where the
definitions match exactly, although in many cases it was more a case of
cleaning up the wording (particularly to conform with standards for
definitions, eg ISO 1087) than actually changing the definition.
Transforming our Relationships with Information Technologies
Blog
pensivepeter.wordpress.com
P.O. Box 49719, Los Angeles, CA 90049, USA
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.
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.
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.