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

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-comment message

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


Subject: need submitter feedback [was: [soa-rm-comment] comments on the SOA RAF Committee Specification Draft 3/Public Review Draft 3[


Zoran,

 

This is a reminder that I sent you the attached spreadsheet containing the cognizant editor's response to your comments.  Please use column I to indicate your acceptance of the response or your further comments.  If you cannot respond within the next few days, please send a short email providing the timeframe for your response so we can plan for activities to resolve any items requiring additional discussion.

 

Thank you again for taking the time to review the SOA-RAF.

 

Ken Laskey, chair

 

---------------------------------------------------------------------------

Dr. Kenneth Laskey

MITRE Corporation, M/S H305              phone: 703-983-7934

7515 Colshire Drive                                    fax:        703-983-1379

McLean VA 22102-7508

 

From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: Monday, November 21, 2011 9:12 PM
To: 'Zoran Milosevic'; soa-rm-comment@lists.oasis-open.org
Subject: RE: [soa-rm-comment] comments on the SOA RAF Committee Specification Draft 3/Public Review Draft 3

 

Zoran,

 

Thank you for your comments.  These have undergone a first review by the responsible editor and the first response is included in the Editor’s Response column.

 

Please review the entries below from the consolidated spreadsheet and indicate for the Commenter Rebuttal column whether you agree with the Editor’s Response.  If there is still disagreement, you can enter a brief note on the points under debate and I will forward to the editor as a first step to a discussion with the Editor and trying to resolve.  If there is an impasse,  the issue will be discussed by the full SC.  If this is needed, I ask that the Editor provide a summary for discussion under Editor's Summary of Issue for SC Discussion.  If such a discussion is happening, I will let you know and give you a chance to express your view.  For the sake of expediency and limited cycles on the part of all, I ***STRONGLY*** encourage (both to the submitter and the editor) minimizing the issues that require full SC discussion;

 

 

Issue Number

Initial Page

First Line

Lines/Range

Submitter

Issue/Comment

Proposed Change

Editor's Response

Commenter Rebuttal

280

21

444

596

Zoran Milosevic
<zoran@deontik.com>

Comment: The statement in the footnotes 3 and 5, saying: " ‘People’  and  ‘person’  must  be  understood  as  both  human  actors  and  ‘legal  persons’,  such  as  companies,  who  have   rights  and  responsibilities  similar  to  ‘natural  persons’  (humans)' ", can be expressed using the ODP concept of Party. This concept describes broader responsibilities of legal entities derived from some social or legal framework, independent of their participation in any social structure and participation conditions should be described by the corresponding policies.  (see ODP community concept discussed in issue 3). In addition, Party is one of several ODP accountability concepts introduced to model various aspects of responsibility and these concepts can add  further level of detail to the governance and management models in section 5 - linking them with the concept of action. Several type of accountability actions are defined in ODP, namely commitment (an action that results in an obligation by the object performing the action to comply with a rule or perform a contract); delegation (an action through which obligation is passed by the current holder (principal, as a kind of party) to an agent (kind of an enterprise object); declaration (an action that establishes a state of affairs in the environment of the object making declaration); evaluation (an action that assess value of something); prescription (an action that establishes a rule). Note that these actions and their ordering can provide a way of analyzing how responsibilities evolve between participants in the social structure, e.g. beginning from accepting responsibility, transferring responsibility, assessing performance of someone's obligations or defining new rules. These sets of concepts can be provide input in expressing behavior of  parties when fulfilling roles in  governance frameworks. It is important to note that Party has an independent life of any 'community' in which it fulfills the community role, as described in the comment 3.

Consider introducing the ODP concept of Party ( from the meta-model in the ODP Enterprise Language standard), defined as 'an enterprise object modeling a natural person or any other entity considered to have some of the rights, powers and duties of a natural person'. This can perhaps go in section 3.1.1. As a result, Fig 4 can then be modified by adding Party, a generalization of Stakeholder. Delegation can also be added as a separate meta-class, to be a specialization of Action, and with which Participant can have a principal association end, and with which  Delegate can have agent association end; this would also mean removing 'employs' relationship.  Consider also introducing the accountability actions (mentioned in the adjacent Comment cell), explaining traceability to Party. The accountability actions  could be perhaps detailed  in the governance section (say before 5.1.2.2) and could be used in the sections presenting governance, change management and security concerns . For example, the accountability actions can be used in the existing diagrams (e.g. 'promulgates' -> 'declares' in fig 36, 'generates consistent' -> 'prescribes' in fig 35 ).

In correspondence, Zoran suggesting using elements from the X.911 standard (ISO 15414), particularly the concept of "Party" (see figure aside).

I think this is too broad for our use and could lead to misunderstanding or confusion between Stakeholder, Participant and Actor (all of whom could be "Parties" by this definition)

281

518

1839

Zoran Milosevic
<zoran@deontik.com>

Comment: At present RAF's emphasis appear to be on the way social structure is described in terms of participants, rather than in terms of roles which define constraints for participants wishing to participate in the social structure. The emphasis on roles would allow describing expected behavior in community in terms of actions of roles and in terms of policies that constrain role behavior. The emphasis on roles would also support _expression_ of complex rules of how parties (participants) fulfill roles in the community, which is important for many business constraints such as separation of duty or security policies.   The ODP concept of community has a well developed semantics and it would be relatively straightforward to align the existing RAF model to it. 

Consider introducing a description and meta-model of the ODP community concept perhaps in section 3.1. including concepts of community (social structure), role(s) defined by community, party (participant) filling roles, processes in which parties filling roles are involved, business services that they provide (within and outside community), policies that constraint behavior in the community etc. and provide clarifications where appropriate. The emphasis on roles can either be achieved by starting with Fig 5 and related concepts followed by  figure 3 (showing the fact of participant already fulfilling role in the community) or by merging Figs 3 and 5.  The emphasis on roles would lead to downstream benefits of expressing  dynamic and policy-controlled changes of the rules in community,  which is related to governance and management, description of domains and federation (both of which are special kind of community) and relationship between communities. Note that  Community is a key ODP EL concepts but there is much to it and one should look at the EL standard (as listed above) or reference it - I would be happy to further help on this.

I think Community is the wrong word and to use it would give the wrong or mixed message. In ODP, a "community" is very explicitly a configuration of any type of "object" formed with a purpose to meet an objective, expressed as a contract.

282

32

839

842

Zoran Milosevic
<zoran@deontik.com>

Comment: Policy is a constraint on behavior for the participants filling roles in the community

Figure 9 could benefit by showing the affected behavioral elements by policy, e.g. processes, roles and interactions

Agreed

283

58

1794

1889

Zoran Milosevic
<zoran@deontik.com>

Issue: There is no definition of Community in RAF. This concept appears to be focused on service delivery, but apart from that it seems to be similar as concept of Social Structure. Is there really a need to separate these?

Consider  consolidation between RAF Social Structure and RAF Community concepts. ODP community is sufficiently general to describe both

Reject per ODP comment.

284

73

2301

2377

Zoran Milosevic
<zoran@deontik.com>

Issue: How are policies applied to behavior (actions, joint actions) of participants filling roles in the social context (community)?

Add those elements in community (social context) which were affected by policy, e.g. roles, actions, joint actions; this would for example link Permissions and Obligations  which are described in terms of constraints on actions (see lines 664 and 671) with the behavior which is expressed in terms of actions

This is a good idea but it would require adding sections and diagrams.  Are there volunteers?

285

32

840

847

Zoran Milosevic
<zoran@deontik.com>

Comment: an 'assertion' in policy definition is a type of prescription (being an accountability action from comment 1)

If accountability meta-model is introduced, add 'policy assertion' as a special kind of 'prescription' in Fig 9 and link it to the stakeholder element

Needs further discussion

286

32

840

842

Zoran Milosevic
<zoran@deontik.com>

Comment: a policy can be taken in a more generic sense, to identify an element in specification that a designer anticipate may change over time. This can cover both 'system design contract' and also 'enterprise policies', i.e. permissions and obligations

Consider the broader definition of policy from ODP (part 2, ODP Foundations), which includes policy description, policy envelope, policy value, policy setting behavior and affected behavior.

Awaiting further information from submitter

287

23

518

569

Zoran Milosevic
<zoran@deontik.com>

Comment: In line 518, social structure is composed out of participants, but in line 569 they have stakeholders

Clarify the composition of social structure. If the ODP community is introduced, this may not be an issue, because both stakeholders and participants (as parties) can fulfill roles in community

It would indeed be more accurate to talk about Stakeholders as being the main "component" of a social structure. Whole sub-section would need to be reviewed

288

27

664

671

Zoran Milosevic
<zoran@deontik.com>

Issue: why permissions and obligations do not apply to participants, but only actors ?

replace 'actor' with 'participant' in both definitions

Reject. Participants *are* actors, but Actors also covers Delegates, as intended

289

33

876

876

Zoran Milosevic
<zoran@deontik.com>

Issue: why not 'participant' but only 'actor' receiving message ?

Because it is a system level interaction

290

43

1283

Zoran Milosevic
<zoran@deontik.com>

Issue: Are Consumer Description and Provider Descriptions in fact role descriptions (as per Fig 6) ? Do we describe participants or the roles they will undertake? I think the latter as this yields long term specifications.

Clarify in the text

need suggested text

291

45

1334

1334

Zoran Milosevic
<zoran@deontik.com>

Issue: Care should be taken in including 'role' as an example of 'party' ; in ODP and in real life these are two distinct concepts

The use of role in community and party, if introduced through the concept of community, should prevent this use

accept. Suggest change "party" to "participant"

292

46

1365

1365

Zoran Milosevic
<zoran@deontik.com>

Issue: 'Event Model' missing as per fig 14?

add Event Model in Figure 13

accept

293

46

1365

1365

Zoran Milosevic
<zoran@deontik.com>

Issue: 'Service' modeling element has not been defined, although was used in several meta-models

Define exactly what a Service is and how it fits the existing meta-models

accept.

service is not part of this model but service along with SOA ecosystem and SOA-based system should be included in some model(s), most likely in the ecosystem view.

294

58

1779

Zoran Milosevic
<zoran@deontik.com>

Issue: Are these roles in a social context/community as opposed to participants that fill these roles, according to the role-filling (membership) policies?

Clarify this in text and if necessary modify figure 21 as per role vs. party distinction established earlier

The names Service Consumer, Mediator, and Service Provider define the role of the participants in the context of Figure 21.  Using Role in the diagram is too detailed for the diagram.  To tie in Figure 5, Roles in Social Structures, the text could state something like "The participants acting in the roles of Service Consumer, Mediator, and Service Provider ..."  This could start with sentence 1768, "Service consumers and service providers ..."

295

76

2426

2855

Zoran Milosevic
<zoran@deontik.com>

Comment (observation): Detail of Governance is beyond scope of the ODP standard, but the ODP Enterprise Language concepts can be used to directly support _expression_ of governance framework (as also done in Hl7 SAIF) as well as some management concepts such as contract management and monitoring and reporting. They include a minimal, yet expressive set of formal concepts for expressing key  governance concerns described in section 5.1, e.g. roles in a governance framework, policies (obligations, permissions, authorization and prohibition) that apply to the participants (ODP parties) filling the roles; as well as processes in which the (parties filling the) roles are involved. In addition, the ODP Enterprise Language provides quite an expressive way of various accountability concepts, such as principal/agent relationship, passing the objects carrying permissions, obligation and prohibition statements, as well as defining authority roles, such as leadership.

If the ODP EL concepts (community and accountability actions) are added/reflected on in the participation section, consider providing some text explaining their use for the governance framework. This would be of value for builders of SOA based tools in support of their approach to management and monitoring of accountability actions .

Consider in context of changes to section 3.  Also, may want to show some explicit parallels in the text on coordination even is do not change terms used.

296

88

2909

2909

Zoran Milosevic
<zoran@deontik.com>

seems to be the end of a missing paragraph

correct as appropriate

Duplication of issue 165

297

88

2912

2912

Zoran Milosevic
<zoran@deontik.com>

heading should be "Authorization", not Authentication

correct as appropriate

Duplication

298

120

4209

as required

First line column included (new line)

Zoran Milosevic
<zoran@deontik.com>

Comment: there appears to be a significant alignment and synergy between OASIS SOA RAF specification and ODP specifications, in particular ODP Enterprise Language, that it would be useful to provide commentary about this and also references to ODP standards

Consider providing a separate Appendix about Relationship to ISO/IEC/ITU- ODP standards. These are: 1) ODP-RM - Foundations (ISO/IEC 10746-2 | ITU-T X.902), 2) ODP-RM Enterprise Language (ISO-IEC 15414 | ITU-T X.911)

Ken:
accept.  Need to write words.

in process

299

102

3465

Zoran Milosevic
<zoran@deontik.com>

Comment: there may be a need to support broader and more formalised third-party testing, as part of conformity assurance processes. The RM-ODP standards have a well established framework for this as well as the ISO standards on conformity assurance - both of which were also considered as part of the HL7 SAIF standardisation

Consider the use or reference of the ODP Conformance and Compliance framework or appropriate other standards.

Accept

 

For reference,

 

165

88

2909

2909

Marco van Zwetselaar
<zwets@zwets.com>

seems to be the end of a missing paragraph

correct as appropriate

Accept

166

88

2912

2912

Marco van Zwetselaar
<zwets@zwets.com>

heading should be "Authorization", not Authentication

correct as appropriate

Duplication

 

Please let me know if you have any questions.

 

Ken Laskey, chair

 

---------------------------------------------------------------------------

Dr. Kenneth Laskey

MITRE Corporation, M/S H305              phone: 703-983-7934

7515 Colshire Drive                                    fax:        703-983-1379

McLean VA 22102-7508

 

From: Zoran Milosevic [mailto:zoran@deontik.com]
Sent: Tuesday, October 25, 2011 6:52 AM
To: soa-rm-comment@lists.oasis-open.org
Subject: [soa-rm-comment] comments on the SOA RAF Committee Specification Draft 3/Public Review Draft 3

 

Dear SOA RAF TC,

Please find attached my comments for the Committee Specification Draft 03 / Public Review Draft.

My comments were done from the point of view of alignment of this specification with the ISO/IEC ITU-T RM-ODP standards (Reference Model for Open Distributed Processing).

My analysis shows a great deal of alignment. I have only identified two key concepts that may need to be reinforced in the RAF specification, in particular the RM-ODP community concept (with all its elements) and RM-ODP accountability concepts.

Note that the RM-ODP standards are also used as part of the recent HL7 Service Aware Interoperability Framework standardisation efforts - to provide underlying semantics of expressing behavioural, governance and conformance aspects of a service aware specifications in eHealth applications.

Kind Regards,

Zoran Milosevic, PhD

Deontik Pty Ltd, http://deontik.com
(m) +61 410 481837


--
This publicly archived list offers a means to provide input to the
OASIS SOA Reference Model TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: soa-rm-comment-subscribe@lists.oasis-open.org
Unsubscribe: soa-rm-comment-unsubscribe@lists.oasis-open.org
List help: soa-rm-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/soa-rm-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
Join OASIS: http://www.oasis-open.org/join/

Attachment: Zoran SOA-RAF comments.xlsx
Description: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet

Attachment: smime.p7s
Description: S/MIME cryptographic signature



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