Finnish expert comments for SC7 Curitiba meeting on Enterprise Language May 1999 Item: 1 Clause 6.1.3, lines 2 and 8; lines 4 and 9 Rationale: Inconsistent statements Item: 2 Clause 6.2.,

Suggestion: If the concept is necessary, it could have the name "potential". Item: 3 Clause 7 Rationale: The relationships between enterprise specifications are not clearly enough stated in the current document. Suggested text: The relationships between enterprise specifications can be divided into two essentially different categories: A) relationships that deal with the behaviour of the specified communities; and B) relationships that deal with the production of the enterprise specifications. Both categories comprise several sub-cased where modifications to the enterprise properties (e.g., enterprise policies) are managed differently. In addition, C) communities may interfere with each other at the level of object instances populating roles. A) The behaviour of two or more communities can be related via two basic mechanisms: 1. Communities can be designed to interact. Two or more communities can be interlinked by designing how their policies, interactions, interfaces, and behaviours interleave. The purpose of creating independent communities can be modelling of autonomous domains or modelling of independent service provision. Examples: - the legal domains involved in international goods markets; - a company out-sources the provision of an information service. Cooperation between communities is in this case captured at design time, and requires that the specifications of all involved communities are created, controlled, and modified by the same authority. Any modification to the community specifications need to be taken to all involved specifications equally, to preserve consistency. This must either be done manually, or can be supported by tools. However, the result of the modifications is a new set of specifications, and a new set of communities. 2. Communities can enter a cooperation state through a binding process at the system run-time. Two or more communities can be interlinked through a match-making process that considers they policies, interacting capabilities, interfaces and behaviour descriptions. The involved communities are in this case designed separately without a common controlling authority. Furthermore, the cooperation between the communities does not necessarily create a common authority for them. This case is modelled with the help of community equivalent object (CEO): A community specification is considered as a property description of a class of object instances that are capable of fulfilling the joint responsibilities of all roles in the community. A role in any community specification can thus validly be fulfilled by a CEO. As the binding process can be late and dynamic, a single community specification can be created and modified independently from others. The consistency requirements are checked at the binding time. Modifications to a single community (e.g., policy change) is propagated to other involved communities only if that is separately agreed as an activity between the various communities. Such an activity may be defined as a peer-to-peer negotiation or as a authority-to-subordinate relationship. The example cases for dynamic inter-linkage are similar to the examples given in case 1. B) In the production of enterprise specifications, the interesting relationships include: nesting of communities, and reuse of role specifications. These cases are closely related to A.1. Nesting of communities means, that a partial community is textually separated as a community of it's own, and the textual representation can be reused (by a specification tool) as part of multiple, potentially unrelated community specifications. Reuse of role specifications works similarly, but in this case the isolated textual representation covers only a single role. The role and community specifications can be private to a specification and development environment, or they can be stored to a repository that can be shared by a wider audience of several development environments and groups. C) Object instances may populate roles in more than one community simultaneous. In such a case, the behaviour of the object is restricted by the policies of each community separately. An object should not enter a community (bound to one, designed to be part of one) when contradictory requirements occur. However, the policies of the simultaneously participated communities are not necessarily consistent, but the object may end up into a contradictory situation where it necessarily causes a failure in one of the communities it participates. This case is closely related to the role population process, that also plays an important role in A.2. Item: 4 Clause 7.1., Figure 1 Rationale: The enterprise specification can be primarily structured either by processes or by roles. There is no guaranteed way of mapping all behaviour related groupings between processes and roles, in all specifications. Suggestion: Remove "behaviour" from the illustration, and remove the 1-1-relationship from step to behaviour. Replace steps by a more general activity graph segment. Item: 5 Clause 7.1., Figure 1 Rationale: The current document text explains that community objective is expressed as a set of policies. Suggestion: Draw the relationship between objective and appropriate policies. The appropriate policies include policies governing - process behaviour - role - the whole community (as a CEO) Item: 6 Clause 7.4. Rationale: Only simple communities can be specified with current rules. Suggestion: Re-write the clause in such a way that it is evident that the community life-time does not become interlocked with the objective of the community. Activities within the community can include things for various epochs in the community life-time. Some activities have the nature of terminating the community. Not all communities need to have explicit terminating activities. It is very much a characteristics of each individual community specification. A community can also terminate without reaching its objective: the bank may end up bankrupt. A scale of communities can be created, some of which - live constantly with a general objective. In such cases the objective (policies) can be expressed as a set of thresholds and activities taking corrective actions when a threshold is passed. - die when the objective is reached. In such cases the objective can be expressed as a test of state. - something in between the two mentioned above. Item: 7 Clause 7.5.2.3. Rationale: Consistent style needs to be chosen here: should we follow a formally correct specification style, or try to describe things in an intuitive way. Suggestion: Formal option: Core community is declared as an existing object and the interactions between environment roles are performed with the core community object, not the core roles. Intuitive option: Is almost there, but relating core community with CEO causes confusion. Item: 8 Clause 7.10 Rationale: Answers to some questions Answers: - A community template does not change during its lifetime. - Community membership and other properties can be changed during the community lifetime using those facilities specified in the template. - Community objective may have embedded choises ("parameters") and the community may at different times use a different option. - Enterprise objects can modify their state and behaviour, even policies; or enterprise objects can have those properties changed by authorative orders. Enterprise objects fulfilling a role can be changed to other similar objects during the lifetime of the community.