A Model-Driven Architecture for Interoperable

A Model-Driven Architecture for Interoperable Collaborative Writing Environments Rita Suzana Pitangueira Maciel

Universidade Federal de Pernambuco, Centro de Informática 50732-970 Recife, Pernambuco, Brazil e-mail: [email protected]

Abstract. Groups that work on CSCW, CSCL or cooperative editors frequently construct and provide documents. Although these environments manipulate the same kind of artifact – a document –, they are not normally interoperable due to the implementation of different policies, protocols or software architectures. Therefore, it is not possible for users to use different collaborative systems to work on a single shared document. Towards such an interoperation, we propose the InterDOC Environment. Using InterDOC, group of authors can write a document in their favorite environment and can then make this document available via InterDOC to another group of authors using another environment, or even a single user application. We use OMG MDA to describe InterDOC´s concepts and to show that it is platform-independent. Key Words: Model Driven Architecture, Collaborative Writing, Interoperable Services.

1

Introduction

Interoperability, or the capacity of heterogeneous applications to access procedures and to share data, even when they are in different equipment, is a desirable feature in several computer environments [1]. We are living in a time of mergers and partnerships of organizations, which consequently bring about virtual communities. Virtual communities consist of people that are geographically dispersed, but that share a common topic or interest [2]. Many tasks are being developed cooperatively, by various units in the same organization, and among various different organizations that are potentially distributed on a global scale. In this scenario, it is becoming increasingly necessary for heterogeneous applications to be interoperable in order to provide adequate support to the execution of these tasks. A task that we carry out cooperatively on several occasions, and whose automation has been the topic of research for some time, is the authoring of documents [3,4]. It is estimated that approximately 85% of documents both in academic and business environments are written by more than one person [5]. Collaborative authoring is one of the areas of major interest in relation to the cooperative work support [6]. The collaborative authoring process is normally divided into the planning, authoring, proofreading, edition and closing phases among others. Studies reveal that in the majority of collaborative authoring processes (approximately 75%), an author writes the initial draft of the document, and the collaboration actually starts in the subsequent phases when the other authors revise, make notes, make comments and/or edit this document [3,6]. Collaboration effectively starts in the asynchronous activities of production of a document. The use of groupware tools is largely asynchronous [2]. Due to the particularities of the various phases that constitute this process, as well as the level of flexibility that the tools are supposed to provide, such as different configurations in relation to the preferences of the various group members, studies indicate difficulties in supporting the entire collaborative document creation process [7,8,9]. Accordingly, some tools support only specific phases or tasks of collaborative authoring (e.g. COARSY (Collaborative Editing and Review System) [10], AMAYA (W3C’s Editor/Browser) [11], BSCW (Basic Support for Cooperative Work) [12], etc). The collaborative authoring of documents is the main activity in some applications, such as in cooperative editors. In other applications, this type of activity is secondary, and is merely functionality among several others hosted by the application, such as the CSCW (Computer Supported Cooperative Work) and CSCL (Computer Supported Collaborative Learning) applications. Any application that supports collaborative authoring, whether only in phases of this process, as a principal or secondary requirement, will be referred to in this text as a collaborative authoring supporting application (CWSA). Due to their quantity and diversity, CSWAs are not normally interoperable. As a result, authors should use a single environment to obtain the benefits of computer-supported cooperation. This aspect is extremely limiting, since besides having to adapt to the new aspects of computer-aided collaboration, users also have to use new mechanisms (editors, e-mail tools, interfaces, etc) with which they are not usually

accustomed [7]. In some situations, on account of the huge effort to adapt to a new environment, organizations opt to discard the use of cooperative work supporting environments for the execution of the authoring task. The existence of a vast diversity of CWSA makes the implementation of the interoperability requisite a task with a high cost, both due to the heterogeneity of hardware and software platforms that host them, and to the number of specific solutions (protocols, APIs, components, etc) that some environments make available to make this requirement feasible [13,14,15]. In other words, a specific development could be necessary for each new environment inserted in the context of the task of collaborative authoring, to provide interoperability between them. Developers need high-level interfaces to mask the complexity of platforms, leaving them free to focus on the implementation and specification of the functional requirements of applications [1]. Usually, standards for the information and data models involved are the first step to allow interoperability. However, in order to get high levels of interoperability among different systems, we also need to define software services that support communication among heterogeneous platforms through common accepted and adopted interfaces. This paper presents a model of use and reference architecture for an environment that promotes interoperability between or among asynchronous collaborative authoring tasks executed by authors that use different and heterogeneous CWSAs. Based on the reference architecture, our proposal is to provide a middleware vertical service layer, the InterDoc environment (Environment for Support the Interoperability among Collaborative Document Authoring Tools), which when interposed between the CWSAs and the repositories that store these artifacts (documents), promotes interoperability among several environments. The objective of the reference architecture is to be independent from the platform with weak integration between InterDoc and the applications involved in the authoring process, as high-level information of the same nature is handled. The specified architecture should not contain elements in its description that impose a model of any nature (programming, transaction, persistence, etc), on the applications. Furthermore, it should not be necessary to know any internal feature of the application involved, for the development of the solution. Through the adoption of the environment, heterogeneous CSWAs hosted in different virtual communities will be able to provide their end users (authors) with mechanisms for the execution of authoring tasks in a collaborative fashion. The objective is to attain an environment where the context relating to the collaborative task that is being carried out is preserved as if it were being executed in a single, homogeneous environment. To attain a generic and platform-independent model, the reference architecture is specified via MDA (Model Driven Architecture). MDA proves adequate to describe InterDOC, since it is based on open standards such as MOF (Meta-Object Facility), XMI (XML Metadata Interchange) and UML (Unified Modeling Language) for the description of the software architecture and its implementation solution is based on middleware. The adoption of open standards permits interoperability at the level of definitions of public interfaces of communication and access to the repositories that will contain the information to be shared by the applications. The adoption of middleware permits interoperability at the operational level. The rest of this paper is organized as follows. The next Section analyzes the related work. Section 3 presents the InterDOC model of use and reference architecture. The Section 4 presents the MDA views of InterDOC. In the conclusion we summarize the contribution of the doctoral thesis presented in this paper.

2

Related Work

Motivated by the aspect that forcing all participants of a given task to adhere to the same application is counterproductive and results in resistant attitudes in part of the group, there are several proposals for interoperability among applications, enabling authors that use different collaborative environments to work on a single artifact. Various proposals are based on frameworks for the construction of interoperable collaborative applications. In this case, the applications are developed through a single framework, then becoming interoperable through the instantiation or development of components from the same repository [14, 17, 18]. These components have data structures and/or mechanisms of interaction, communication, replication of common objects and transaction management in common, among other aspects. In those proposals, the applications derived from the same framework but that are instantiated from different repositories of components and data are not promptly interoperable. In other words, mechanisms are not always made

available for the interoperability of applications that wish to share objects, but that are located in different repositories. Other proposals are based on the provisioning of an intermediary software layer, positioned between various environments, including single user applications, which integrates and provides shared functionalities for these environments [15,19,20,21]. This layer captures the outbound data from the applications, transforming them into a common representation. With this common representation, inputs are generated for the other applications involved. Every time there is a new application that the output model is not mapping, a new mapping process should be executed. In some cases low-level mechanisms such as obtaining inputs from the window system are used, which make the proposals susceptible to modifications of the host platforms – platform-dependent. Total interoperability (data model, implementation policies, sharing of components, etc) is difficult to achieve. Conversions, and in many cases modifications of the applications involved, are required to achieve interoperability at this level [13]. Specifications of architectures and interfaces in high-level languages, further to the adoption of public domain standards, make the development of applications more secure and independent. Difference in architecture can also result from level of the layer whose information is shared. The higher the level of this layer, the lower sharing degree supported by the architecture. The adequate architecture depends on several factors such as the layers and the semantics of the shared information and the degree of sharing desired [21]. The provisioning of interoperability among different systems requires the definition of software services that support communication among heterogeneous platforms through common architectures and communication interfaces.

3 InterDOC: Environments

Interoperating

Heterogeneous

Collaborative

Writing

InterDOC should allow the various asynchronous activities of the authoring process to be executed in different tools. InterDOC should be made available as an intermediary layer, which when positioned between the CSWAs and the repositories that store these artifacts, promotes interoperability among various environments. Groups of authors can hold synchronous or asynchronous sessions for the planning, drafting, revision, editing etc of a document in their favorite environment. In any phase of the authoring process, the document can be made available through InterDOC to another group of authors that uses another environment, or even an individual work tool, to perform an activity. Figure 1 shows a plan for the InterDOC model of use. Two Domains (domains 1 and 2) represent different communities. Each domain has a local network, where a specific protocol is used for this network category. These communities are interconnected through a long-distance network. Five layers form the model of use: CSWA applications, Interaction with Applications, Services, Communication between Domains, Interaction with Repositories and finally the Repository layer. Each domain has its CSWAs (Client A and B applications) that are not promptly interoperable in relation to the collaborative authoring tasks, and that form the layer of Applications. In order to become interoperable in this aspect, the applications should have interfaces with InterDOC (Interfaces 1 and 2). The client type A application illustrates the category of applications that have been developed according to the InterDOC reference model. The client type B application illustrates the category of legacy applications, where the interface components were subsequently developed and where external calls are necessary for communication with InterDOC. The layer of Interaction with Applications is formed by components that implement the interfaces between the applications and InterDOC, for the provisioning of documents and information relating to the authoring tasks that are being executed. The Service layer consists of the InterDOC objects that implement the functional requirements of InterDOC. InterDOC provides functionalities for control over access to documents, support to the definition of authors and group formation, support to the authoring activity process and notification of activities to be executed for the authors. The layer of Communication between Domains consists of elements that are responsible for communication between InterDoc instances hosted in different domains. When necessary, messages will be formatted for the interoperability protocol used by the domain (e.g.. SOAP (Simple Object Access Protocol), IIOP (Internet Inter-ORB Protocol), etc).

The layer of Interaction with Repositories has components for the interface with the repositories that are responsible for the validation and provisioning of information to be stored persistently. For InterDOC, collaborative authoring is divided into two large phases: Planning and Writing. The Planning phase is when an author from the group provides the basic information for the description of the authoring project of a document: group of authors, roles of authors in the group, location of the repository Domain 1

CWSA Application

Interactions with Applications

Client Application A

Client Application B

Interface Components

Interface Components

1

2

1

2

5

5

Domain 2

Client Application C

Client Application D

Interface Components

Interface Components

1

2

1

2

Services

5 Communications between domains Interactions with Repositories

Repositories

Legend:

5

InterDOC

4

4

Shared Documents

Activities

5 Protocols of 3 Interoperability

5

5

5

InterDOC

4

Not Shared Documents

Not Shared Documents

Shared Documents and Activities

1 – Documents retrieval and Availability 2 – Register/Search activities 3 – Communication between distinct domains 4 – Access to shared Documents and Informations 5 – InterDOC specific services

Fig 1. InterDOC’s Model of Use. of shared information, etc. The Writing phase is when authors make versions of the document available for other authors to execute activities.

3.1 InterDOC Architecture MDA proposes the construction of a given application based on more generic models in accordance with its category. Specific implementations should follow this model. The construction of a distributed application through MDA starts with the definition of a middleware-independent model called Platform Independent Model (PIM). Then the development platform for this software (e.g., CORBA, EJB, DCOM) is chosen and a specific model called Platform Specific Model (PSM) should be defined. From a single PIM, various PSMs can be derived. InterDOC is a layer that provides a set of middleware vertical services; hence a PIM specifies its architecture. The InterDOC’s PIM has characteristics that guarantee the interoperability of the various derived PSMs through the description standard interfaces of their components. In the MDA process, models of systems are the basis for the resolution of the interoperability problem. The models of the InterDOC architecture is describe through MDA UML Profile for Enterprise Distributed Object Computing (EDOC) [22], using the modeling context through views of RM-ODP. PIM comprise the Enterprise, Information and Computational views. PSM will be described through the Engineering and Technological views. The Enterprise view describes interactions among the different InterDOCs and interactions between the applications, repositories and the InterDOCs. The functionalities that InterDoc realized are described in terms of Business Process (BP) that specifies a complete business task. A BP may contain Activities, which are the pieces of work required to complete a task. Data flows connect different BPs, and Activities in a BP, defining temporal and data dependencies between this elements. These data are modeled as Process Flow Port. InterDOC has two majors BP: Design a Project and Writing that specifies the

situations described in Section 2. Figure 2a presents the diagram of Design a Project. The diagram is described with EDOC Business Process sub profile. Design a Project has two Activities: Form a Group and Register a Project. To initiate this process, first its necessary to define a group with the authors information and the roles that the authors will realize in this project. The Port Authors and Role Information fulfill this data. This process is finished when a group reference, that identifies the group uniquely, is generated. To initiate the Register of a Project, its necessary the group reference and the information about the workspace that will store the sharing information. Design a Project

Form a Group

Aplication

Group Reference IAplicationService (from oldcomponents)

Project Reference Authors – Role Informations

InterDoc > DocumentSharingService (from InterDoc) Ac tivitiesNotificat ionService ProjectManagerService (f rom InterDoc)

(from InterDoc)

ComunicationInterDom ainsService (from In terDoc)

Workspace and Project Information

AuthoringAct ivitiesService (from InterDoc)

AuthorGroupService (from InterDoc)

Register a Project IRepositoryService > Repository

Fig. 2a Business Process Design a Project.

(from oldcomponents)

IInterDomain Service

Fig. 2b. InterDOC Composition Collaboration Diagram.

The Information view provides the static description of objects that InterDOC will handle internally such as: document, authors, group of authors, the restrictions to guaranteeing the maintenance of these objects’ integrity, as well the ports data definitions. The Computational view describes the components that will form InterDOC. The structure of the component in terms of communication interfaces and the data that these handle are described in the models of this view. One or more Process Components (PC) will execute each BP or Activities. A PC represents an active processing unit. InterDOC has six majors PC: DocumentSharingService, ProjetcManagerService, AuthoringActivitiesService, ActivitiesNotificationService; AuthorGroupService and CommunicationInterDomainService (figure 2b). The Engineering view details the components specified in the Computational view in terms of the description of interfaces and of the strategies and policies to perform the distributed processing of components. The components that will be accessible via the network, the scopes of transactions, the elements to be persisted and the type of mapping for repositories are defined in this view. The technology view maps the objects and components for each specific platform. This view should be mapped according to the chosen middleware platform – e.g. if CORBA Component Model (CCM) is chosen, the profile will be the UML Profile for CCM.

4

Conclusion

This thesis presents a model of use and reference architecture of the InterDOC environment. InterDOC provides middleware services for the interoperability among CSWAs, which are different and heterogeneous, in relation to the performance of asynchronous collaborative authoring tasks. The goal is to enhance the flexibility of the authoring process for the users of heterogeneous collaborative applications, as they do not need a high adaptability cost in the execution of this process. The proposal aims to improve the CSWA development process through the specification of a reference architecture for the interoperability of these environments. The specification of architecture as a

mechanism for attaining interoperability among heterogeneous environments, instead of frameworks or simply APIs, makes the model of public knowledge, consequently evolutionary and extendable due to the fact that developers of applications and InterDOC, know their external mechanisms (interfaces) and internal mechanisms (specific services). The reference architecture permits different implementations to be obtained in heterogeneous computer environments. Interoperability appears as a consequence of the definition of interfaces for accessing specific services. The adoption of a common architecture for the provisioning of interoperability also avoids the need to develop specific interoperability mechanisms for each one of the applications involved in the process for each new application that a group member wishes to use. The positioning of InterDOC as an intermediary layer between the applications and the repositories of shared information determines a low level of coupling and an adequate degree of flexibility for the applications, since these can, and are free to define their own architecture. The Computer view is currently being finalized; thus we will have completed the PIM specification. The development environment, i.e., OpenCCM, is properly configured and component implementation tests have already been conducted. Our next steps will be the specification of PSM in CCM, the implementation of an InterDOC prototype and the organization of a test scenario based on the model of use.

References 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

14. 15. 16. 17. 18. 19. 20. 21. 22.

BERNSTEIN, Philip A. Middleware: A Model for Distributed System Services. Communication of the ACM. New York. v 39. n 2. p 86-98. February 1996. STEVES, Michelle; MORSE, Emile. Looking at the Whole Picture: A Case Study of Analyzing a Virtual Workplace. In: IEEE International Workshop On Enabling Technologies: Infrastructures for Collaborative Enterprises, 10 th, 2001, Massachusetts. Proceedings … June 2001. p. 96-101. KIM, Hee-Cheol; EKLUNDH, Kerstein. Reviewing Practices in Collaborative Writing. In: Computer Supported Cooperative Work (10), Netherlands: Kluver Academic Publishers. 2001. p 247-259. BECK, Eevi. Practices of Collaboration in Writing and Their Support. 1994. 174 p. Ph. D. Dissertation (Cognitive Science). 1994. University of Sussex at Brighton. BAECKER, Ron et al. Sasse: The Collaborative Editor (vídeo tape transcript). In: Conference Companion on Human Factors in Computing Systems (CHI´94), Massachusetts. Proceedings… April 1994. CERRATTO, Teresa. Instrumenting Collaborative Writing and Its Cognitive Tools. In: Human Centered Process Conference, 1999, France. Proceedings… September. 1999. p.41-147. NOEL, Sylvie; ROBERT, Jean-Marc. Empirical Study on Collaborative Writing: What Do Co-authors Do, Use, and Like?. In: Computer Supported Cooperative Work (13), Netherlands: Kluver Academic Publishers. 2004. p 63-89. LOWRY, Paul Benjamin; NUNAMAKER, Jay F. Using the Thinklet Framework to Improve Collaborative Writing. In: IEEE Hawaii International Conference on System Sciences(HICSS’02), 35th., Big Island-Hawaii, Proceedings… January 2002.10p. NEUWIRTH, Christine et al. Computer Support for Distributed Collaborative Writing: A Coordination Science Perspective. Coordination Theory and Collaboration Technology. Computers, Cognition and Work Series. Lawrence Erlbaum Assoc. May 2000. RUIZ, Diana, FAVELA, Jesus. Collaborative Review and Edition of HTML Documents. In: International Workshop on Groupware (CRIWG’98), 4 th, Búzios, Proceedings… September, 1998. p. 113-127. WORLD WIDE WEB CONSORTIUM – W3C. AMAYA W3C’s Editor/Browser. http://www.w3c.org/Amaya. APPELT, Wolfgang. WWW Based Collaboration with the BSCW System. In: Conference on Current Trends in Theory and Practice of Informatics, (SofSem’99), Proceedings… December 1999. p.66-78. DEWAN, Prasun; SHARMA, Anshu. An Experiment in Interoperating Heterogeneous Collaborative Systems. In: European Conference on Computer-Supported Cooperative Work(ECSW’ 99), 6 th, 1999, Copenhagen. Proceedings… September 1999. p.11-20. TIETZE, Daniel. A Framework for Developing Component-based Co-operative Applications. 178 p. Ph. D. Dissertation (Computer Science), Technischen Universität Darmstadt, Germany, 2001. LI, Du et al. Using Familiar Single-Users Editors for Collaborative Editing. In: Hawaii International Conference on System Sciences(HICSS’ 03), 36 th, 2003, Hawaii. Proceedings… January 2003. 10 p. OBJECT MANAGEMENT GROUP. MDA Guide Version 1.0. 2003 GROOVE NETWORKS. Is Groove the Desktop of the Future ? Research Note. 2001.http://www.groove.net. STIEMERLING, Oliver; CREMERS, Armim. The Evolve Project: Component-Based Tailorability for CSCW Applications. AI & Society, London, 2000, p. 120-141. DOURISH, Paul. EDWARDS, Keith; LAMARCA, Anthony. Extending Document Management Systems with User-Specfic Active Properties. ACM Transactions on Information’ s Systems, v.18, n.2, p.140-170, April 2000. PALFREYMAN, Kevin. RODDEN, Tom. TREVOR, Jonathan. PSI: A platform for Shared Interaction. In: European Conference on Computer-Supported Cooperative Work(ECSW’ 99), 6 th, Copenhagen, Denmark. Proceedings... September 1999. p. 351-270. CHUNG, Goopeel. DEWAN, Prasun. Flexible Support for Application-Sharing Architectures. In: European Conference on Computer-Supported Cooperative Work (ECSW’ 01), 7 th, 2001, Bonn. Proceedings… September 2001. p.99-118. OBJECT MANAGEMENT GROUP. UML Profile for Enterprise Distributed Object Computing Specification. OMG Adopted Specification (ptc/02-02-05). 2002.