AGORA: a Layered Architecture for Cooperative Work Environments

Transcription

1 AGORA: a Layered Architecture for Cooperative Work Environments Miguel A. Martínez-Prieto, Pablo de la Fuente GRINBD, Universidad de Valladolid Valladolid (Spain) migumar2,pfuente@infor.uva.es Carlos E. Cuesta Kybele, Universidad Rey Juan Carlos Móstoles, Madrid (Spain) carlos.cuesta@urjc.es Abstract ware systems are closely related with factors which define organization and knowledge of the group. Taking in account these factors are very variable, development and management processes of these systems are complex and need adaptable infrastructure which guarantees their correct evolution. From this need, we propose AGORA as a layered architecture for building flexible cooperative applications in distributed environments. This approach is based on a shared workspace which defines basic resources for groupware systems. This way, a system is responsible to build their services from a specific cooperative operations supplied by AGORA of which functional model is based on components reutilization. 1. Introduction The Agora was an essential part of an ancient Greek polish which concentrated its culture, commerce and politics on this place. It was used as a civil forum in which was held meetings for discussing different issues related with the polish. Therefore, classic concept of Agora defines it as a meeting place for making decisions in community according to a fixed protocol. This idea can be adapted at this time for making decisions and working in groups inside of an organization. These organizations have more sophisticated needs than the Greek polish because their structure is more complex. Therefore, organizations require a robust infrastructure which allows them to perform a fluid communication independently of geographic location of their members. For this purpose, organizations need to use information technologies for building computer systems which enable specific collaboration for groups. These systems can be defined by means of a common term: groupware. It is defined as computer-based systems This work was partially supported by the project TIN C03-02 from MEC (Spain). that support groups of people engaged in a common task (or goal) and that provide an interface to a shared environment [6]. Taking in account the previous definition, this article presents AGORA, an architecture for building cooperative applications. Our approach tries to solve main weakness of groupware systems which are revised in section 2. This section presents also a brief analysis of current environment. Next, we define our architectural approach from a brief introduction which describes a set of key aspects in groupware systems. Considering that AGORA is a layered architecture, next sections present every constituent layer, detailing its structural and functional contribution to the global architecture. Once we have defined the conceptual basis of our model, we present a real application case based on a well-know cooperative service: the workspace. This example allows us to show internal interaction between components of AGORA when a user s request is received in a groupware system built with our architecture. The article finishes with a presentation of the conclusions which we have extracted from our experience with AGORA; moreover, we define our lines of work planned for the future. 2. Current State of ware s Environment The techniques of workgroup have increased their importance in last years. It supposes that many approaches have been proposed in this time. On one hand, the architectural approaches suggest to model groupware systems as sets of related components. These approaches (PAC [4] or CLOVER [8] are examples of them) are concentrated on interactive issues of the systems, but don t define a specify method to add external components that can be demanded by these systems. On the other hand, different frameworks for groupware has been built for making its design and development easy; tools as ANTS [7] or kit [10] are example of them. Applications built with them have an important lack of interoperability and are unable to add efficiently new com-

2 ponents. These features cause that these applications are poorly extensible. Taking in account the current state of groupware s environment, we deduce that the lack of adaptability is an important weakness in this class of systems. If we consider that groups are highly dynamic entities and their needs are very evolving, we conclude a bit adaptable systems are rigid solutions for an adequate management in time of these requirements. Therefore, groupware systems built for management specific cooperative needs, evolve to outdated tools which are unable to handle requirements associated with new dynamics of the group. Sessions Service Access Control Protocol Register Awareness Service Sessions Awareness Protocol Workflow Engine Shared Environment Cooperative Operations 3 4 Cooperative Tools Cooperative Services Shared Context Access Shared Context Basic Operations for Shared Objects Repository Shared Objects Figure 1. AGORA s global structure Aqueducts From this situation, the use of open systems with a high degree of interoperability [7] is a key factor in processes of cooperative applications design. So, is required a reference architectural model which allows us to build flexible and extensible groupware systems. We consider this model should be concentrated in cooperative dynamic of the group. Taking in account previous consideration, in this article we present AGORA as a layered architecture of software (see Figure 1) designed for building cooperative applications. This architecture is inspired in a service oriented model [9] built upon a specific XML [3] processing model. This model guarantee, from a technological view, that applications built with its resources are highly extensible and adaptable. 3. AGORA as ware System Although a gropuware system provides a distinctive and specific service for the collaboration of the group, all of these systems share a set of common key aspects [1]: communication, group awareness, coordination and group memory. The communication in a groupware system is classified in synchronous and asynchronous according to the moment in which is carried out. Both classes of communication should be performed in such a way that services can benefit of mutual complement existing between them. The group awareness is defined as an understanding of the activities of others, which provides a context for your own activity [5]. If this context isn t available, collaboration is impossible because users don t know behaviour of other members in group. Therefore, this context is used to ensure that individual contributions are relevant to the group s activity. The coordination is a critical issue because the group s activity is realized by means of shared objects. Therefore, the management of these artifacts should be adequately coordinated for avoiding duplications or inconsistencies with the information derived of concurrent accesses bad handled. Finally, the group memory manages the historical information associated with shared objects used in a cooperative application of the group. This information allows understanding the cooperative process from the steps which define all actions realized with shared objects in the application. We consider these aspects as essential features for groupware systems, and AGORA implements all of them by means of the shared environment layer which is used by upper layers for designing and building cooperative applications. In next sections we explain as the layers of the architecture uses these aspects according to their specific structural characterization. 4. Technological Layer: Aqueducts This layer defines the technological basis for building our architecture. For this purpose, we use Aqueducts, an architectural style designed from well-known pipe-filter [2] [11] specifically extended for managing XML data streams. The main reference in current environment of XML processing is XProc [12]: it defines a conceptual model in which Aqueducts is inspired for designing a specific hierarchy of components for XML processing. This hierarchy

3 takes advantage of encapsulation features associated with the concept of software component for defining a new concept: aqueduct. Next sections present functionality and structure of these components in group layer Protocol The component group protocol describes the way used by group members for their collaboration. This component implements specific responsibilities of the group layer by means of four functional modules: The access control module is responsible to determine who can access what and in what manner. Its operation is defined by means of role based policies. Figure 2. Example of Aqueduct We define an aqueduct as a higher-level filter which comprises a non-linear sequence of ordered filters designed from basic processing steps and structural control constructs which handle its internal flow (Figure 2 shows a generic aqueduct). Every aqueduct is a specific provider of service responsible to manage its performance by means of its internal structure. An aqueduct defines an open model for XML processing because it is able to process XML data stream of any kind. This feature allows us to use Aqueducts in different scopes of application; we are currently working in an evolved implementation based on SOA technology. In conclusion, Aqueducts proposes a data (XML) driven model used by distributed applications which are exploited in Internet. Therefore, Aqueducts define a necessary infrastructure for satisfying communication requirements of cooperative applications built with AGORA s resources. 5. Layer: Shared Environment The specific nature of groupware systems forces to develop similar solutions for near problems. This situation is proved by means of the set of key aspects (showed in Section 3) which are common for groupware systems. We consider this set of aspects as the core of our architecture, because it represents the common features that all groupware systems share. Therefore, this layer (named shared environment) is defined as a generic group layer which provides a set of resources which implements all of these key aspects for groupware systems. In conclusion, this layer plays a role of provider for upper layers which use it for building cooperative services and applications. This decision provides us a generic solution for solving similar problems in groupware systems. Resources provided by this layer are given out in three specific components (see Figure 3) which are built by means of the resources provided in technological layer. The sessions handler module manages individual user sessions of work in group applications. The group awareness is responsible to know all activities realized by group members. The information derived of these activities is distributed in the group. The group manager module manages all information associated with the group and its members. It uses a register for storing and querying this information. These modules describes a specific interaction which is detailed in the next section by means of a cooperative service developed in upper layer using resources of this group layer. Access Control Register Sessions Awareness Protocol Shared Environment Cooperative Operations Shared Context Basic Operations for Shared Objects Repository Shared Objects Figure 3. Layer: Shared Environment 5.2. Shared Context The component shared context is based on definition of Ellis [6]; In it, this concept is defined as a set of objects where the objects and the actions performed on the objects are visible to a set of users. The above definition allows us to extract the main responsibilities of this component: on one hand, it stores shared objects used in cooperative processes. On the other hand, this component provides operations used for managing these shared objects. The Figure 3 shows these responsibilities by means of a shared objects repository and a server module which provides the basic operations which manage them

4 The shared objects repository defines a flexible mechanism for storing objects used in cooperative processes. This element doesn t establish any restriction about of the data logical model used in its description. The server module of basic operations for handling shared objects repository defines a functional component which provides a set of operations for managing objects in repository. These operations allows us generically to insert, update, delete and query objects in the repository; this is possible thanks to the execution of an operation requires the structural model of the object used in them. Therefore, these operations are independent of the specific semantics associated with the different types of shared objects used, although their implementation should be carried out according to the data logical model used in the repository. The result of these operations is expressed in XML; this feature allows us to process these results by means of Aqueducts, that it is specifically designed for this purpose. This component is responsible to manage shared elements, therefore it needs a mechanism of concurrency which guarantees a coordinated management of the shared objects used in cooperative processes; we consider this need as an important question because coordination is a key aspect in groupware systems (see Section 3). Therefore, this component is responsible to implement this aspect considering different mechanisms of concurrency that can be demanded in upper layers of AGORA Cooperative Operations ware systems use this module as an inventory of the functional operations which are cooperatively exploited in the upper layers. In this module, systems build their cooperative operations usind resources available in technological layer. Therefore, every operation is designed by means of an aqueduct (or a combination of aqueducts) which specifically defines its functionality. Taking in account that these operations are used in a cooperative environment, they are complemented by resources provided by the other modules of this layer. Figure 3 shows as this module interacts with the group protocol and the shared context according to the next restrictions: Every request has associated a set of data which defines it. The aqueduct which implements the requested operation interprets this data upon resources of group protocol component. Every cooperative operation uses a fixed object (or set of objects) stored in the shared context. So, generation of contents in the aqueduct which implements the operation is performed by basic operations of shared context. These cooperative operations are defined as modular processing structures according to the conceptual model of Aqueducts which are component oriented. These operations are highly adaptable thanks to this feature; it supposes that a cooperative operation has a high interoperability at levels of data exchange and collaboration between operations. 6. Cooperative Services The two lower layers guarantee necessary resources for defining specific cooperative operations which are used in real interactive environments. At this layer, we present a concept of cooperative service as a method of exploitation of these operations according to a specific semantics of process. These cooperative services should be considered from perspective associated with the space-time taxonomy defined by Ellis [6]. Therefore, this layer must be capable to supply services according to this taxonomy; for this purpose, the Cooperative Services layer uses resources provided by the two lower layers: The technological layer is defined by means of an architectural model which is exploited by distributed systems. Therefore, the spatial prespective can be covered by means of the resources provided in the technological layer of AGORA. Considering refered taxonomy, we define two classes of service in a time perspective: synchronous and asynchronous. Resources provided in group layer allow us to define services of both classes. Therefore systems built with AGORA can be defined all type of services according to the time perspective Building Cooperative Services A cooperative service is a conceptual abstraction with a particular behaviour which is performed by means of a specific type of shared object. This abstraction is realized by a cooperative tool used in a real environment. This definition implies that a cooperative service manages different issues using the set of components showed in Figure 4. The service must define the type of shared objects which uses for performing its functionality; the cooperative service manage this purpose by means of the resources which shared objects repository provides. Taking in account shared context description, when the service defines the schema of representation used by the object, this can be already managed by the basic operations provided by this component. For finishing this step, is only necessary to define the mechanism of concurrency which is used by the operations of the service. All of these responsibilities are managed by means of the shared context access component.

5 The development of the service continues with the definition of its group protocol; this step cover issues related with group handling, sessions handling, group awareness and access control. Taking in account that a cooperative service is a functional abstraction, it doesn t handle the group. We consider that cooperative application that realizes the service in a real environment should be responsible to manage this issue. Sessions handling and group awareness are managed by means of a component: the group protocol handling which contains two specific modules for each responsibility. Sessions Service Protocol Awareness Service Workflow Engine Cooperative Services Shared Context Access Figure 4. Cooperative Services Layer The sessions service control module uses the sessions handler module (in lower layer) as data source. The current module knows (from information supplied) the users that are using the service in a concrete time; these users, identified by their work session, are associated with a global work session of the service. We consider that a session of the service starts when the first user accesses to service s resources and finishes when the last active user ends his activity. The service awareness module is responsible to manage all events produced in active user s sessions associated with a global work session of the service. The information derived of these events is provided by the group awareness module in lower layer which send it when a new event happens in the service. When the current module have this information, should communicate it according to a policy selected by the service; for this purpose is important consider if the service is synchronous or asynchronous for reporting this information. Finally, this module is also responsible to store all events which have happened in the service; this information is later used in a group memory aspect of the groupware system which provides the service. At this point the service is already defined as a provider of a cooperative activity which uses a specific class of shared object. Therefore, the next step is to associate with the services those operations that it performs. For this purpose dynamic of the service is described using a workflow which is interpreted by a workflow engine component. In conclusion, a cooperative service has a set of states and a set of transitions which link states according to the global evolution of the workflow. Each state supplies several cooperative operations according to the specific access control policy defined by means of the access control module in the group layer Features of a Cooperative Service Cooperative service is a key concept in AGORA, because it allows getting a flexible and extensible solution with a high level of adaptation for managing the evolving needs of the group. These features are based on adequate use of the resources provided by the shared environment layer. Taking in account that the shared environment provides a set of resources which implements all key aspects for groupware systems, we own all necessary resources for designing and building cooperative service. Even so, we could need specific cooperative operation which they aren t available in lower layer. This problem is easy to manage, because we only need to define a new operation by means of a new aqueduct which provides the functionality required for it. Once the service is defined, this can be modified if the group requirements evolve. Taking in account previous section, these changes can affect to different features of the service. A type of modification in a service is related with the class of shared objects that it uses. For this purpose we only need to modify their schema of representation in the shared objects repository. According to the functionality of this component, these changes are immediately assimilated by the basic operations which manage them. In this situation, we take in account that existing objects should be update according to their new schema of representation. Other type of modification is related with the dynamic of the service; in this case exists two possible alternatives. On one hand, an existing state can need modification which are directly realized in its configuration. On the other hand, a service can need new states of execution which are added to the initial workflow according to the required conditions. This type of modification has a null impact in previous workflow, because it keeps its features adding those properties derived of this change. Finally, if a cooperative service needs modifications in its group protocol, these are realized in the group layer which provides them. 7. Cooperative Tools It is the top layer in the AGORA s model. It is responsible to build real applications from resources provided by the cooperative service in which is based. If we consider an object oriented metaphor, a cooperative tool defined from a cooperative service is analogous to an instantiated object from a class. A cooperative tool inherits responsibilities related with the group management. For this purpose, it uses a group protocol handling component of the service in which is

6 based. These responsibilities are the maintenance of the group and the definition of roles policies used by the tool. Taking in account that all tools are related with a group, all member of this group can use them. A member of the group has rights of use according to his role and taking in account the state of execution in which the service is in each moment. 8. AGORA in action In this article we have presented each layer of AGORA s model. From this information, in current section we design a cooperative service which instructs the operation of previous concepts in a real environment. For this purpose, we have selected a workspace service inspired in a well-known tool: BSCW 1. We propose a service which takes basic features of BSCW; from them, users publish documents in cooperative work zones which make easy asynchronous interaction between members of the group. This interaction is restricted according to the user s credentials (identity and role) Shared Objects This service defines its behaviour by means of specific types of shared objects which allow users to cooperate. Taking in account specific needs of the workspace, we define two classes of shared objects with a specific schema which represents next concepts: Work zone: describes a structure which the service needs for storing information associated with an specific theme of cooperation. Moreover, this structure requires a flexible method for storing in it all contents published as a result of interaction process in this zone. Published content: describes the structure of information exchanged in the service. In this structure, the service stores data and metadata. Stored data defines the content published and metadata saves information related with the identification of the user and the moment in which the content is published. Moreover, this content allows to link external documents which are part of this object too. These types of shared objects guarantee adequate function of the service by means of the basic operations supplied by the shared environment. Taking in account that this is an asynchronous service, its concurrency can be managed by means of a simple mechanism based on a simple lock policy [6]. This policy, which is available in the shared context, is used by the service according to the specific access control policy defined by the tool Protocol The group protocol is presented in Section 5.1 as the way used by group members for their collaboration. On one hand, the workspace service requires to define the awareness group module according to its asynchronous characterization. On the other hand, this service defines two roles for its access control; this roles (use and administration) are later specified by the tool which implements the service Workflow This service requires a simple dynamic which is built by means of a workflow with an unique state. Inside of this state, we can use all operations defined in the service. These operations can be classified in two groups according to the shared object which use. On one hand, we consider a set of operations which manage work zone objects; these operations can be only used by users who play an administration role. Next enumeration defines these operations: New Zone operation inserts a new work zone object with the data supplied. For this purpose, it uses the basic operation new object. View Zone operation shows data stored in work zone object and published content objects contained in it. This operation uses the basic operation view object. Update Zone operation updates data stored in work zone object with new data supplied. For this purpose, it uses the basic operation update object. Delete Zone operation deletes he work zone object and all published content objects contained in it. This operation uses the basic operation delete object. On the other hand, we consider a set of operations which manage published content objects. These operations are: New Content operation inserts a new published content object with the data supplied. For this purpose, it uses the basic operation new object. View Content operation shows data stored in published content object by means of the basic operation update object. Update Content operation updates data stored in published content object with new data supplied. This operation uses the basic update object. Delete Content operation deletes he published content object by means of the basic operation delete object.

7 All members of the group can define a new content and can visualize all contents published in a work zone. Delete and update operations of published contents have any limitations in their use; so, these operations can be only executed by the user which published the content or by the administrator user. Figure 5. Example of Cooperative Tool 8.4. Defining a Cooperative Tool We consider that the workspace service can be used in educative environments; for example, we have used it for building a cooperative tool which supports projects of software development in groups of teaching practice. In these projects, students build, in a cooperative way, necessary artifacts in a process of software development. Therefore, this tool concretes roles of workspace service associating the user role with the concept of student and the administrator role with the concept of teacher. In conclusion, the group is composed by two sets of users that can use the tool according to the access control policy which the service defines for each role. The Figure 5 shows an example of these tool for the new content operation Using a Cooperative Tool A student is using the presented tool in a certain time. This situation implies that the student is already authenticated as a valid user in the application and he has a work session with a student role associated. In this tool, exists a work zone in which the members of the group cooperate for writing a software requirements specification document. In a certain time, the introduced student requests to publish a new content in this work zone; this request have associated information of the user s session and specific data for publishing the new content. The processing starts when this request is received in the tool. First, this request is validated respect to the group protocol which defines the tool. For this purpose, it checks the validity of the user s session and afterwards, it evaluates the state pf the workflow for checking that the requested operation can be performed. If the request passes these requirements, the system registers the event associated with the request, and communicates it by means of the service awareness. This information is received by all active users in tool. Once these validations are passes, next step performs the specific cooperative operation which satisfies the user s request. For this purpose, the tool uses the basic operation new object with the published content schema and specific values which defines the new object. Taking in account this operation creates an object; it doesn t need special control of concurrency, because the object doesn t previously exist. When the new object operation finishes, it send its result to the aqueduct which implements the cooperative operation. This aqueduct takes this result and continues its execution from it for getting the specific result of the operation. This result is later sent to the user as response of his request; in it, the application reports a correct publication of the content which is already available for all users that can use it according to the access control policy associated. This example shows a generic behaviour of AGORA when a user s request is received. By means of this process, we instruct the way in which AGORA s components interacts, taking in account that each cooperative tool uses the shared environment according to this needs. 9. Conclusions and Future Work This article defines AGORA as specific software architecture for building adaptable groupware systems; by means of them, we can design and exploit flexible and extensible cooperative applications. Therefore, these applications are competitive in real environments and have a high level of quality to manage the evolving dynamic of groups which use them. AGORA is a layered architecture technologically based on a processing model of XML data streams. By means of it, the architecture defines a shared environment which provides a complete set of resources which abstract main features of groupware. This environment allows us to build flexible cooperative services which are realized by means of cooperative tools that allow users to interact in workgroup environments. Our future work has two main orientations: on one hand, we pretend to complete concepts in which are based the architecture. This decision implies that we work in features provided by the shared environment for making applications development easier. Moreover, we specifically work

8 in the implementation of the shared context; taking in account our experience in digital libraries, we are analyzing the possibility of design a specific digital library for managing the responsibilities of this component. Thanks to this decision, the modules of the shared context get important benefits from digital libraries features. On the other hand, we consider that AGORA is already a functional model and we want to check its performance in real environments. We are designing new types of services (synchronous and asynchronous) that allow us to build cooperative tools which will be used in virtual environments of learning. We are currently working in specific services which manage educational objects designed from e-books contents. By means of these services, we want to help with reading s processes of Spanish classic literature in educational environments, complementing them with collaborative activities. [11] M. Shaw and D. Garlan. Software Architecture: Perspectives on an Emerging Discipline. Prentice Hall, New Jersey, [12] N. Walsh and A. Milowski. XProc: An XML Pipeline Language. W3C Working Draft, April References [1] R. Araújo, M. Dias, and M. Borges. A framework for the classification of computer supported colaborative design approaches. In Proceedings of III International Workshop on Gorupware (CRIWG 97), pages , San Lorenzo del Escorial (Madrid), Spain, October [2] L. Bass, P. Clements, and R. Kazman. Software architecture in practice. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, [3] T. Bray, J. Paoli, C. Sperberg-McQueen, E. Maler, and F. Yergeau. Extensible Markup Language (XML) 1.0 (Fourth Edition). W3C Recommendation. Available at August [4] J. Coutaz. PAC-ing the Architecture of Your User Interface. In M. D. Harrison and J. C. Torres, editors, Design, Specification and Verification of Interactive Systems 97, pages 13 27, Wien, Springer-Verlag. [5] P. Dourish and V. Bellotti. Awareness and coordination in shared workspaces. In CSCW 92: Proceedings of the 1992 ACM conference on Computer-supported cooperative work, pages , New York, NY, USA, ACM Press. [6] C. A. Ellis, S. J. Gibbs, and G. Rein. ware: some issues and experiences. Commun. ACM, 34(1):39 58, [7] P. García and A. F. Gómez-Skarmeta. ANTS Framework for Cooperative Work Environments. Computer, 36(3):56 62, [8] Y. Laurillau and L. Nigay. Clover architecture for groupware. In CSCW 02: Proceedings of the 2002 ACM conference on Computer supported cooperative work, pages , New York, NY, USA, ACM Press. [9] M. A. Martínez-Prieto, C. E. Cuesta, and P. de la Fuente. Una arquitectura para el desarrollo de aplicaciones cooperativas en entornos heterogéneos. In Proceedings of IV Taller en Sistemas Hipermedia Colaborativos y Adaptativos, pages 41 50, Sitges (Barcelona), Spain, October [10] M. Roseman and S. Greenberg. Building real-time groupware with Kit, a groupware toolkit. ACM Transactions on Computer-Human Interaction, 3(1):66 106, 1996.