+!
I’ve
read the rest of the thread that follows and I think
this captures what we need. Yes, it does not
cover 100% of all interpretations of every word but
it does well at capturing the essence.
Ken
---------------------------------------------------------------------------
Dr.
Kenneth Laskey
MITRE
Corporation, M/S
H305Â Â Â Â Â Â Â Â Â Â Â Â Â phone:
703-983-7934
7515
Colshire
Drive                                  Â
fax:Â Â Â Â Â Â Â 703-983-1379
McLean
VA 22102-7508
There are big
differences between JA and conversation:
-
A joint action has a defined and desired
outcome, a conversation does not;
-
A joint action requires intent, collaboration
and trust, a conversation does not require them,
although it can benefit from them;
-
A conversation might occasionally
consist of “1 request, one response†but
it is a process of inquiry – in an SOA
context, one could say that it is semantic
engagement but it is not the same as a joint
action that is identified, agreed to and carried out
as a result of that conversation;
-
The issue of identifying the
“epoch†of any joint action arises
because unlike a conversation (or indeed the process
of semantic engagement) that can be endless and
unfinished, joint action requires a decision point
at which the actors concerned are resolved to do
something. They are engaged. They are, each of them,
in (or have) states that are conducive to executing
their part of the joint action.
The difficulty we seem to
be having would seem to be one of granularity. So,
are any/all of the following “joint
actions�
-
I decide I’m going to buy that book
online after all so I sit down in front of the PC,
open the browser and go to my favourite online
bookstore (app launch, several http and https get
requests and responses, etc… never mind the
router packet sniffing and forwarding, ISP lookup
and forwarding, DNS lookup, etc);
-
I’m prompted for my account details;
-
I find the book, order it and receive
confirmation of the order;
-
The bookstore’s agent confirms a
financial transaction with my credit card company
based on the data on file;
-
The bookstore agent sends an inventory
request to the nearest warehouse to my address to
confirm availability of the book;
-
Etc….
-
A couple of days later, a package with my
book is tossed onto my doorstep
Each of these is a joint
action, IMO. They are require collaboration, intent
and trust. They all result in real world effects. As
a stakeholder, I’m not particularly
interested in any of the detailed actions except the
first, the third and the last – the rest is
detail. I’m only ever interested in those
details (and only usually discover that there is
such detail) when something goes wrong,
there’s no-one willing to help solve it and
we have to play amateur detective to find out.
I could argue academically
that the whole process is a
“conversationâ€Â. What is Important
– to me – is that there is a joint
action between me and the bookseller. What is
important to the bookseller, is that there are a
series of joint actions with me, the credit card
company, their warehouse, postal and courier
services. It is a question of granularity. For me,
once the service is “invoked†(in my
human sense of the term – that is to say,
from the moment I have clicked on the icon to open
my browser, or later clicked on
“confirmâ€Â), the “epoch†of
that particular joint action has started. What
happens thereafter is “under the hoodâ€Â,
“service activityâ€Â, black-box-stuff
until I get what I want.
So, any joint action (and
even what passes for joint action) is in the eye of
the beholder but, unlike a conversation, has
discernable characteristics:
-
There is an intent to “do
something†together with another party, that
you can’t undertake on your own (the core
essence of a service);
-
There is a willingness and capacity to work
together, simultaneously, consecutively, or a
combination of both;
-
There is a stated and agreed expected
outcome;
-
There is a start point and a completion (or
failure) point – it thus has an epoch.
Peter
I have two answers,
Boris:
1) I distiguish between
JA and conversation: JA is always more than
conversation becasye it includes all intornal
actions and activities on both sides in addition
to the exchnage scenario.
2) the simplest case of
conversation is 1 request - 1 response. In this
sense, conversation always present in the JA.
According to the SO Principle that I call (http://www.ebizq.net/blogs/service_oriented/2009/02/principles_of_service_orientation_reviewed.php)
Service
State Management principle
(initially known as Service Statelessness) - any
service has to minimize resource consumption by
deferring the management of state information when
necessary . This clearly states that the service
has to maintain it state and be stateless or
stateful when necessary for the business task
while the "scalability and
often performance" are the IT problems (if you have them,
compensate ithem by other means). Example: all
business services that are implemented as business
processes or orchestrations are stateful; theis
type of services dominates the field of services
in the business area of SOA ecosystem.
P.S. If you say that
stateful services are not welcome in IT because of
the complexity of the task, I would say that this
is the reality, this is the new requirements to
the automation and, thus, new solutions might
needed for scalability and performances.
Technology may replace business and run its own
rules; if the business is not replaced, technology
must provide for the business 'operational
pattern', IMO.
In your definition
you effectively equate JA with
conversations.
· Joint action is
really a conversation?
· All service
invocations are conversational?
If this is the
position I have a big problem with this.
Conversational means state management which
pushes complexity through the roof and
typically kills scalability and often
performance.
Not sure I agree
with Rex (if I've understood correctly).
Joint Action is about actions, not
about spiritual preparation to act. That
is, any JA has its life-time and,
correspondingly, the epoch. An ensemble of
actions, which we also call session,
completes, the JA completes. Since neither
consumer-requester nor the service can
define when RWE of the JA will be consumed
(if at all) but unknown consumers (the
shareable part of the RWE), we cannot tie
the JA to any demobilization
moment; the service may be retired
already and destroyed while the RWE it
produces before may be still in the
public access area.
So, I agree with Chris - every JA
has its epoch. We should not mix it with
multiple service requests that result in
the JA that can exist simultaneously. Any
new request results in its own JA as well
as in the new instance of the service
responding to it (again, the epoch of JA
may be called a session, a business
transaction, or somehow else. This 'thing'
defines which actions are the part of
particular JA and which ones belong to
about JA for the same service)
I think that
attempting to restrict or constrain
the epoch of Joint Action to any
arbitrary time-period, especially post
invocation, is a problem. in my view,
Joint Action is required any time more
than one party is required to move a
service toward invocation or toward
completion once invoked. It stretches
from design time to demobilization.
Therefore, it does not fit into any
specific epoch.
Cheers,
Rex
On 3/11/11 4:05 PM, Estefan, Jeff A
(3100) wrote:
First,
this RAF definition of RWE is
quite a bit different from what it
was defined in the RM, which
really seemed focused on what
happens upon service invocation.
Second,
execution context is not mentioned
at all in Sect 3 of the RAF or at
least not in earlier drafts. How
is that going to play out in the
new updates?
Still
having a hard time with Joint
Action, in particular, determining
its epoch.
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.