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: [soa-rm-ra] RE: One-pager


I do not mind to put it to rest but it seems that nobody has looked into my comments and questions, and there are more than 1,2 and even three of them. They are in the document attached to my last message where I said I reviewd Peter's papaer...
 
- Michael



-----Original Message-----
From: Rex Brooks <rex.brooks@ncoic.org>
To: Ken Laskey <klaskey@mitre.org>
Cc: peter@peterfbrown.com; mpoulin@usa.com; boris.lublinsky@navteq.com; rex.brooks@ncoic.org; jeffrey.a.estefan@jpl.nasa.gov; soa-rm-ra@lists.oasis-open.org
Sent: Wed, Mar 16, 2011 1:57 pm
Subject: Re: [soa-rm-ra] RE: One-pager

Agreed. I hope we can put this to rest in today's meeting.

Cheers,
Rex

On 3/15/11 2:18 PM, Ken Laskey wrote:
+!
 
I’ve read the rest of the thread that follows and I think this captures what we need.  Yes, it does not cover 100% of all interpretations of every word but it does well at capturing the essence.
 
Ken
 
---------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S H305              phone: 703-983-7934
7515 Colshire Drive                                    fax:        703-983-1379
McLean VA 22102-7508
 
From: Peter F Brown [mailto:peter@peterfbrown.com]
Sent: Tuesday, March 15, 2011 11: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;
-          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
 
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.
 
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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]