for editing or viewing for certain roles and based on
the next layer, represented by the rendering rules, an
export format can be generated. From a technical
point of view, an export format can be an XForms
application, a PDF or a HTML document.
An additional optional layer is implemented in
order to provide document level utilities (e.g. notes,
comments) that can support creativity and improve
collaboration. When using XForms as export format
the presence of these utility elements is marked with
an appropriate symbol, the content being loaded on
request.
The Document Interaction component represents
the access point to all this functionality, providing
the required interface in order to allow the users and
the system to interact with the documents. Access is
provided in respect to user's role, the component
working closely with the local policy enforcement
point (PEP). The local PEP manages access based on
project policies, being able to grant or deny access to
functionality and resources (the local PEP can be
regarded as an Access Manager delegate that
guaranties that the policies defined at project and
system level are applied).
In order to be able to manage all layers required
to generate an export document, the roles involved
in the document level workflow and document type
definitions, the Metadata Manager component
defines a vocabulary that organises all this
information concerning a document. In this respect,
a document consists mainly in data that describes it's
nature and links to files that hold the content of each
of it's layers. This component handles the definition
of metadata associated with a document and works
in close relation with the Document Interaction pipe
based system. It thus provides all required
information in order to process the document layers
and apply them the proper transformation,
representing at document level an integration
component.
The Workflow Manager component handles de
definition and execution of sequences of operations
required by a particular functionality at system or
project level. The system and project workflow
execution implies orchestrating the functionality
provided by the other components, representing the
level where the integration of the system as a whole
is acquired.
The sequences of operations that aggregate
functionality in order to create a process can be
defined by the appropriate roles using the Workflow
Designer component. This component provides the
proper means to combine resources, roles and
actions (functionality provided by the rest of the
system) in a coherent symphony that defines a
process either at system or project level. Processes
like creating a new account, consulting the list of
active projects (system level) or editing and
exporting a document (project level) can be defined
using a graphical user interface. In order to facilitate
the understanding of a process that is executed at a
particular moment of time, this component can
provide also a visual representation of the workflow
involved.
The orchestration of a process represents the
automatic coordination and execution of a set of
services required in order to obtain a certain output.
Each process the system is required to execute
(either at system or project level) must have a
workflow definition schema in order to be
implementable. Taking in consideration that all main
components provide a interface in order to
communicate one with another, this approach
sustains a loose coupled integration of the system.
Similar to the Document Manager, the access to the
functionality provided by these components is
controlled by a local PEP.
The framework manages access through the
Access Manager component which represents the
level where decisions regarding the set of permitted
operations that can be executed by a particular user
during a certain work session are taken. This
component implements a role based access control
(RBAC) model (Ferraiolo, 2001), relying thus on
concepts like users, roles, permissions, objects and
sessions. Users are assigned to a particular role and
roles are associated with a set of permissions, users
being able to execute operations in virtue to the
assigned role. Roles represent m-n relationships
between users and permissions (taking in
consideration the fact that a user can have one or
more roles, but just one of them can be activated
during a certain work session) and permissions
represent the authorization to execute a set of actions
upon protected object. A great advantage of this
model is that it allows the definition of hierarchic
levels inside the system, being able to emphasize the
authority and responsibility layers. In order to
eliminate issues like interest conflicts deriving from
multiple inheritances, the RBAC model introduces
the concepts of static and dynamic separation of
duty (a user being able to activate just one role
during a particular work session, or multiple roles
and define conflictual situations).
Using both static and dynamic separation of duty
the system gains a great degree of flexibility when
applying access policies, being able thus to simulate
more realistically real life organizational model.
AN XML-BASED APPROACH FOR CONTENT MANAGEMENT IN VIRTUAL ORGANISATIONS
255