Information Technology Reference
In-Depth Information
and which is then linked to an appropriate external item at the specific point
of use. In this case, a role is referenced in the community behaviour and linked
to the objects filling the role in each particular instance of its use. As a result,
these objects are required to satisfy the behaviour of the community.
The objects lling a community's roles will, in general, each have their
own lifecycle; they may already be engaged in other activities in the enter-
prise before they fill a particular role, and may go on with other activities after
they have ceased to play that role. On the other hand, the responsibilities
of a role may be transferred from one object to another, if the rules of the
community allow. As long as an object satisfies the behavioural conditions
stated in the role definition, it can be assigned to the role and thus partici-
pate in the community, contributing to the community objectives (and also
helping to achieve its own goals). These conditions can be related to certain
competency requirements for joining the community (for example, only an
accredited logistics organization can fulfil the role of logistics provider), to se-
curity policies covering authentication and access control and to performance
obligations such as might be found in the repair services SLA between the
phone repair service and its customers. Formally, this corresponds to each
role having an associated role type, and there being a requirement that the
object filling the role should satisfy this type. Again, we can draw a parallel
here with the rules governing type checking and implicit casting when using
formal parameters in a programming language.
There is a question of modelling style that arises when deciding whether
model elements are expressed in terms of instances or types. An enterprise
modeller may often use a shorthand style, referring simply to the object type,
talking about a Phone User object as filling the User role when they really mean
that there exists some anonymous enterprise object whose type is Phone User
and which fills the User role.
A community's behaviour is stated in terms of actions that the enterprise
objects assigned to the roles are expected to exhibit | that is, constraints on
when the actions may occur. The way this is expressed depends on the style
adopted; some possible techniques are to use state machines, event sequencing
or a process-oriented style.
A role is always defined with respect to its containing community, which
owns the namespace for its roles. This means that roles in different commu-
nities can be distinct in spite of having the same name; for example, it is
legitimate to define a Customer role in both the Phone Repair community and
the Logistics Provision community. However, these will each have their own
behaviour, which is derived in each case from the community in which they
are dened.
At any point in time at most one enterprise object can fill a particular role
in a community, but different objects can fill the same role at different times;
for example, a specific logistics organization is assigned the Logistics Provision
role, as a result of an underlying business contract with the PhoneMob, but
different contracts can be established in different epochs, each with a distinct
