[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Conversation vs Joint Action
I guess my pint in this conversation (and I agree its endless)
that There is already a well established notion of service integration with
quite a few publications. Now every time I am trying to introduce something (being
lazy as I am) I am trying to see whether whatever I am proposing is different
from what exists. And I really fail to substantial difference. Sorry From: Peter F Brown
[mailto:peter@peterfbrown.com] Boris: 4 further comments inline From: Lublinsky, Boris
[mailto:boris.lublinsky@navteq.com] See below From: Peter F Brown [mailto:peter@peterfbrown.com]
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;
Conversation is not a semantic engagement – it is request/response
sequence with shared conversational state[Peter:]
I’m sorry but I really think you are using a very limited definition of
‘conversation’ (and we aren’t even defining it in the RAF). I’m not suggesting
that conversation *is* semantic engagement but that semantic engagement takes
the form of a conversation, with exchanges iterated until some common
understanding is achieved… That is the distinction that is useful, IMO, for the
RAF – that there are ‘conversations’ (ecosystem activity, if you will) that
precedes and sometimes accompany joint action(s)… -
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.
Theoretically conversation is endless, in practice it will always
end[Peter:] Touché. You can be annoyingly literal at times!! J but it can remain unfinished, which is my main point –
and in a joint action that is unfinished that would be noticed because it has
not achieved its desired endpoint. Some conversations just go on and on (hmmm,
makes me think….) 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.
Which are all true for conversations[Peter:]
Sigh… what is your point? Let’s just say that I don’t agree – and the third
point clinches it for me: what is the “stated and agreed expected outcome” of
*this* conversation, for example? Buggered if I know…. Peter From: mpoulin@usa.com [mailto:mpoulin@usa.com] 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. - Michael 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. -----Original Message----- In your definition you
effectively equate JA with conversations. Does it mean that: ·
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. From: mpoulin@usa.com [mailto:mpoulin@usa.com] 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) - Michael -----Original Message----- 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. Chris, Couple of comments: 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. Cheers… - Jeff 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]