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] Updated definitions and definition table


Peter, 
I have not found a definition in the spreadsheet for:

- Michael

-----Original Message-----
From: Peter F Brown <peter@peterfbrown.com>
To: mpoulin@usa.com; soa-rm-ra@lists.oasis-open.org
Sent: Tue, Feb 1, 2011 1:32 am
Subject: RE: [soa-rm-ra] Updated definitions and definition table

Michael:
Comments inline below
 
From: mpoulin@usa.com [mailto:mpoulin@usa.com]
Sent: Monday, 31 January, 2011 16:01
To: peter@peterfbrown.com; soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] Updated definitions and definition table
 
After long and intense exchange of messages I had an impression that we dropped definition of "Public State", as well as everything that related to public vs. private.
[Peter:] I honestly don’t care what we call ‘it’ (shareable state or public state) but in your exchanges with Boris and others you did distinguish between shared and shareable and they both seem important and thus merit clear distinction and definition.
 
IMO, we cannot define "Shared State’ : “the parts of the Public State of an entity accessed by another actor” " because we do not define (any more) public vs. private
[Peter:] You say that we can’t define shared state as I have proposed ‘because we do not define (any more) public vs. private’ but that is precisely why I do propose to define them separately!  Please read what I write.
 
and we do not know whether the that state has been accessed already.
[Peter:] irrelevant, I agree
We can say only that the entire state is shareable, but those parts of it that particular Participant assumes to be accessed we can call 'shared'.
[Peter:] …which is why we need to define those ideas, no?
 
I do not recall the reasons for not defining EC explicitly and curious about them. I think that EC is VERY important element of SOA ecosystem and it is the one that clearly distinguishes OO solutions from SO solutions.
[Peter:] Agree, just not sure whether we need a specific definition of execution context as a concept – which is what I said.
 
I would argue that Joint Action may be equally understood and presented via orchestration and via choreography. The latter two are two coupled mechanisms of the service interaction - we cannot execute choreography w/o orchestration  and vise verse.
[Peter:] I agree
 
Also, I would object defining ‘Service Method’ and using  anywhere in the RAF because it is a detail of service interface at the lower level than we define things. I agree with Peter's view on this topic.
[Peter:] I have no problem with that
 
 
- Michael
 
-----Original Message-----
From: Peter F Brown <peter@peterfbrown.com>
To: soa-rm-ra@lists.oasis-open.org
Sent: Mon, Jan 31, 2011 7:17 pm
Subject: [soa-rm-ra] Updated definitions and definition table
All:
As promised in my last mail, attached is an updated view of the definitions comparison table. I’ve tried to remember to highlight in green the changes and recommendations made compared with the original table sent out.
 
I propose:
-          To keep the 17 January definitions of ‘Action’, ‘Real World Effect’,
-          To reintroduce the 28 July definition of ‘Joint Action’ – this will mean rolling back some of the deletions in the 17 January text, where the original use of ‘joint action’ is consistent with this definition;
-          To keep the 17 January definition of ‘service activity’ as a generic concept but roll back some of the blanket changes of ‘joint action’ as per previous point – ‘service activity’ is concerned with coordination of all actions within a service; whereas choreography is concerned specifically with joint actions;
-          Definition and text related to ‘Shared State’ needs to be revised: at line 909 of 17 January text, we say that “shared state does not imply that the state is accessible to all actors” only that it “may be accessed”. This should correctly belong to a new definition of ‘Public State’ or ‘Shareable State’.
o   ‘Public State’ or ‘Shareable State’ : “that part of an entity’s state that is knowable to other actors”; and
o   ‘Shared State’ : “the parts of the Public State of an entity accessed by another actor” (modify definition at line 906 of 17 January text); This does imply that shared state can vary in the ‘eye of the beholder’, as different actors may access different parts of the public state – is this correct? And what we intend?
-          For ‘Execution Context’ – keep the narrative in section 4.1.2.1.3 which describes the concept adequately without a formal definition
-          To modify the text at lines 1068-1069 in the 17 January text to read: “Service is therefore the realisation of such business functionality and accessible through a defined interface.”
 
In addition, the following dependent concepts would be impacted and are thus asserted or modified:
-          ‘Business Transaction’ (use the term ‘activity’ in the definition rather than ‘joint action’ or ‘service activity’)
-          ‘Choreography’ – keep existing text but remove definition at lines 2731-2734 (17 Jan pdf). If it is to be defined, use definition in 28 July text (lines 1395-1397: “A choreography is a description of the individual actions to be performed by actors in order to successfully participate in one or more joint actions”)
-          We may also want to re-introduce currently deleted text at lines 1238-1246 explaining relevance of choreography and joint action.
-          ‘Willingness’: keep text at lines 1250-51 in 17 January draft. Can be quickly ‘converted’ to a formal definition if required (just a ‘callout’ and formatting issue)
-          ‘Requirement’ – use 17 January definition
-          ‘Objective’ – modify 17 January definition to: “An objective is the real world effect that a participant seeks as a result of using a service” (rather than “..as a result of service activity”)
 
‘Skill’ – I initially favoured deleting the whole part relating to skill, at lines 798-826, asking what it brings to our draft. I see that we could weave into the text an understanding that (human) skills are relevant in a SOA ecosystem precisely because of the interaction between human and machines; and the need for those humans to act as participants, which implies behaving both as stakeholders in the ecosystem and actors in the system - this does require skill.
 
Note: ‘Service Method’ is not defined anywhere in the text, either in 28 July or 17 January drafts. If we insist in referring to ‘invocation of service method’ rather than ‘invocation of service’, this would need to be defined. We currently refer to invoking actions against a service. I propose to keep this approach and not open a new problem area.
 
Best regards,
Peter
 
Peter F Brown
Independent Consultant
Transforming our Relationships with Information Technologies
Web         www.peterfbrown.com
Blog          pensivepeter.wordpress.com
Twitter     @pensivepeter
P.O. Box 49719, Los Angeles, CA 90049, USA
Tel: +1.310.694.2278
 
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 


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