[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Conversation vs Joint Action
Sorry I mistyped. I really meant conversations. No idea where my brain
was From: mpoulin@usa.com
[mailto:mpoulin@usa.com] +1 I confess, I hate expression "service integration"...
when I use a bus service, do I integrate with the bus (b-brrrrrrrrrrrr) or I
interact with the bus? - Michael -----Original Message----- Boris, I think we have to consider an abstraction that includes the
concrete, but may not be equivalent to the concrete. For example, methods
can be a concrete form of action, but are not the only form of action.
Method is a term that is generally used in the OO or UML community, but not
necessarily in all communities. Action is a more generic term. I feel your pain (and appreciate the lazy attitude ; ) – but
since not all publications agree on terminology, so we may have to satisfy
ourselves with mapping of terms. What is truly important is the concept
(semantics) - the form (syntax) can be mediated fairly easily after semantic
agreement. That being said, joint action is not necessarily an
integration. I think of integration as wiring together two existing
applications. When I link in a library during my development cycle, I
don’t consider that integration as such. If I replace one library with
another one after I’ve already delivered my product, then I think of
integration. Integration carries with it some baggage, because we’ve been
doing “integration” since before I was born. System integrators are very
good at requirements and process flows, etc., though not often as good at SOA. I really like the idea of action model being similar to a
policy, and joint action being similar to a contract. The policy is
one-sided, the contract is between two or more. The contract comes from
the two actors “agreeing” on the policies and bringing them together into the
one thing called the contract. In the same way, the action model is
one-sided, whereas the joint action is between two or more, and comes from the
action model being agreed to and “implemented by” both parties. Integration sounds more to me like wiring together a single
client-server pair vice really applying a “service orientation” to the whole
thing. If we go with joint action, and it maps directly to your
publications’ term of “service integration” then there is no loss of fidelity,
and the fact of another term is of limited consequence (provided that the term
is unambiguously defined). I’m generally suspicious of “well established” stuff in the SOA
world. Well established generally means one major vendor who bought out
all the others, or is limited to a particular community ; ) What we are
trying to establish in the RAF is “standard” stuff that can be referenced and
disambiguated. From: Lublinsky, Boris [mailto:boris.lublinsky@navteq.com] 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. 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]