
 
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