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.