5 Enterprise language

The enterprise language comprises concepts, rules and structures for the specification of an ODP system from the enterprise viewpoint.

An enterprise specification defines the purpose, scope and policies of an ODP system.

In this Reference Model, prescription in the enterprise viewpoint is restricted to a small basic set of concepts and rules addressing the scope and nature of enterprise specifications.

The enterprise language contains the concepts of ITU-T Rec. X.902 | ISO/IEC 10746-2 and those defined here, subject to the rules of 5.2.

5.1.1 Community: A configuration of objects formed to meet an objective. The objective is expressed as a contract which specifies how the objective can be met.

5.1.2 <X> federation: A community of <x> domains.

An enterprise specification defines, and the enterprise language is able to express, the purpose, scope and policies of an ODP system in terms of each of the following items:

-- roles played by the system;

-- activities undertaken by the system;

-- policy statements about the system, including those relating to environment contracts.

In an enterprise specification, an ODP system and the environment in which it operates are represented as a community. At some level of description the ODP system is represented as an enterprise object in the community. The objectives and scope of the ODP system are defined in terms of the roles it fulfils within the community of which it is part, and policy statements about those roles. A community is defined in terms of each of the following elements:

-- the enterprise objects comprising the community;

-- the roles fulfilled by each of those objects;

-- policies governing interactions between enterprise objects fulfilling roles;

-- policies governing the creation, usage and deletion of resources by enterprise objects fulfilling roles;

-- policies governing the configuration of enterprise objects and assignment of roles to enterprise objects;

-- policies relating to environment contracts governing the system.

A role is defined in terms of the permissions, obligations, prohibitions and behaviour of the enterprise object fulfilling the role. An enterprise object can fulfil one or more roles in a community, and the roles which it can fulfil are determined by the contract on which the community is based. While it is part of one community the enterprise object can continue to fulfil roles in other communities, subject to the provisions in the contracts of the communities involved. The enterprise object can fulfil different roles in different communities. Interactions between enterprise objects fulfilling appropriate roles within different communities can be considered as interactions between those communities.

NOTES

1 Examples of roles include policy administrator, president, service provider, owner, manager, shareholder, consumer.

2 Examples of environment contracts in enterprise specifications include safety requirements, legislative requirements and codes of practice.

3 In an enterprise specification the term "<x> object", where <x> is a role, is interpreted as meaning "an enterprise object fulfilling an <x> role"; where an enterprise object fulfils multiple roles, the names can be concatenated, e.g., "owner driver object".

When fulfilling a role, an object becomes subject to permissions, obligations and prohibitions by delegation or transfer. In some roles, objects are permitted to change policy. There are five fundamental types of actions with respect to contractual matters:

-- an object incurs an obligation to another object (it must currently be permitted to incur the obligation);

-- an object fulfils an obligation to another object;

-- an object waives an obligation to another object;

-- an object acquires permission from another object to perform some action it was previously forbidden to perform;

-- an object is forbidden to perform an action it was previously permitted to perform.

NOTE - An important special case of acquisition is where the permitted action is performative, i.e., when an object in a subordinate role is enabled to issue further permissions or obligations on behalf of an object fulfilling a superior role. This leads to the notion of agency or delegation.

Obligations include accounting and charging for the use of resources. Billing and payment is modelled as the reassignment of resources between objects in accordance with the roles they fulfil.

A resource is either consumable or non-consumable. A consumable resource deletes itself after some amount of use. In <x> federation, the objective defines the resources each <x> domain in the federation shares with the other members of the federation. The objective can leave each domain with a defined degree of autonomy in the use of its own resources. The establishing behaviour for an <x> federation can allow autonomy for each participating <x> domain in deciding whether or not to become part of the federation.

Conformance statements in the enterprise language require that the behaviour of an ODP system is conformant to a particular set of objectives and policies.

An implementor claiming conformance must identify the engineering reference points which give access to the system and the engineering, computational and information specifications which apply at them. By this act the identified reference points become conformance points. The interactions at these conformance points can then be interpreted in enterprise language terms to check that the enterprise specification is not violated.

Enterprise specifications can be applied to all four classes of reference point (programmatic, perceptual, interworking and interchange reference points) identified in ITU-T Rec. X.902 | ISO/IEC 10746-2.