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.
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;
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 184.108.40.206) 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)
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.
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
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.
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?
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
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
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
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
Issue: why not 'participant' but only 'actor' receiving message ?
Because it is a system level interaction
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
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"
Issue: 'Event Model' missing as per fig 14?
add Event Model in Figure 13
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
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.
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 ..."
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.
seems to be the end of a missing paragraph
correct as appropriate
Duplication of issue 165
heading should be "Authorization", not Authentication
correct as appropriate
First line column included (new line)
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)
accept. Need to write words.
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.
Please let me know if you have any questions.