OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[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]
Sent: Tuesday, March 15, 2011 5:10 PM
To: cbashioum@mitre.org; boris.lublinsky@navteq.com; peter@peterfbrown.com; rex.brooks@ncoic.org; jeffrey.a.estefan@jpl.nasa.gov
Cc: soa-rm-ra@lists.oasis-open.org
Subject: Re: Conversation vs Joint Action

 

+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-----
From: Bashioum, Christopher D <cbashioum@mitre.org>
To: Lublinsky, Boris <boris.lublinsky@navteq.com>; peter@peterfbrown.com <peter@peterfbrown.com>; 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 7:59 pm
Subject: RE: Conversation vs Joint Action

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]
Sent: Tuesday, March 15, 2011 3:34 PM
To: peter@peterfbrown.com; 'Lublinsky, Boris'; mpoulin@usa.com; rex.brooks@ncoic.org; jeffrey.a.estefan@jpl.nasa.gov
Cc: soa-rm-ra@lists.oasis-open.org
Subject: [soa-rm-ra] 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]
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 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]
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.


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]