:-D
On 3/15/11 3:00 PM, Duane Nickull wrote:
Is your “pint” a Fruedian slip? How
British!
;-p
On 3/15/11 11:33 AM, "Lublinsky, Boris" <boris.lublinsky@navteq.com>
wrote:
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]
Sent: Tuesday, March 15, 2011 2:11 PM
To: 'Lublinsky, Boris'; mpoulin@usa.com; rex.brooks@ncoic.org;
jeffrey.a.estefan@jpl.nasa.gov
Cc: soa-rm-ra@lists.oasis-open.org
Subject: Conversation vs Joint Action
Boris:
4 further comments inline
From:
Lublinsky, Boris [mailto:boris.lublinsky@navteq.com]
Sent: Tuesday, 15 March, 2011 11:42
To: peter@peterfbrown.com;
mpoulin@usa.com;
boris.lublinsky@navteq.com;
rex.brooks@ncoic.org;
jeffrey.a.estefan@jpl.nasa.gov
Cc: soa-rm-ra@lists.oasis-open.org
Subject: RE: [soa-rm-ra] RE: One-pager
See
below
From:
Peter F Brown [mailto:peter@peterfbrown.com]
Sent: Tuesday, March 15, 2011 10:37 AM
To: mpoulin@usa.com; boris.lublinsky@navteq.com;
rex.brooks@ncoic.org;
jeffrey.a.estefan@jpl.nasa.gov
Cc: soa-rm-ra@lists.oasis-open.org
Subject: RE: [soa-rm-ra] RE: One-pager
There
are big differences between JA and conversation:
- A joint action has a defined and
desired outcome, a conversation does not;
But it does. You always have a desired
outcome [Peter:] I
disagree that, in order for something to qualify as a
conversation, there must be a desired outcome. That is
my point (and see my 4th comment below)
- 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]
Sent: Tuesday, 15 March, 2011 03:02
To: boris.lublinsky@navteq.com;
rex.brooks@ncoic.org;
jeffrey.a.estefan@jpl.nasa.gov
Cc: soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] RE: One-pager
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
<http://www.ebizq.net/blogs/service_oriented/2009/02/evolution_of_principles_of_service_orientation_service_statelessness_part_6.php>
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-----
From: Lublinsky, Boris <boris.lublinsky@navteq.com>
To: mpoulin@usa.com
<mpoulin@usa.com>;
rex.brooks@ncoic.org
<rex.brooks@ncoic.org>;
jeffrey.a.estefan@jpl.nasa.gov
<jeffrey.a.estefan@jpl.nasa.gov>
Cc: soa-rm-ra@lists.oasis-open.org
<soa-rm-ra@lists.oasis-open.org>
Sent: Tue, Mar 15, 2011 1:06 am
Subject: RE: [soa-rm-ra] RE: One-pager
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
<mailto:mpoulin@usa.com?>
]
Sent: Monday, March 14, 2011 4:52 PM
To: rex.brooks@ncoic.org; jeffrey.a.estefan@jpl.nasa.gov
Cc: soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] RE: One-pager
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-----
From: Rex Brooks <rex.brooks@ncoic.org>
To: Estefan, Jeff A (3100) <jeffrey.a.estefan@jpl.nasa.gov>
Cc: soa-rm-ra@lists.oasis-open.org
<soa-rm-ra@lists.oasis-open.org>
Sent: Mon, Mar 14, 2011 6:40 pm
Subject: Re: [soa-rm-ra] RE: One-pager
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:
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.
---
Adobe LiveCycle Enterprise Architecture - http://www.adobe.com/products/livecycle/
TV Show - http://tv.adobe.com/show/duanes-world/
Blog – http://technoracle.blogspot.com/
Music – http://22ndcenturyofficial.com/
Twitter – http://twitter.com/duanechaos/
“That’s all I have time for”
|