Figure 1: Extract from the Shared Hypermedia Data Model
Business processes in distributed organizations are usually performed by distributed teams. Team members cooperate on a business process by partitioning it into activities. An activity typically generates one of more work items that need to be processed by working on them separately or jointly. Today, these two types of cooperative work are addressed by different technologies. Workflow management systems (WFMS) [33] support automatic enactment of asynchronous cooperative work, where the flow of work is either strictly predefined or may emerge during run-time. Cooperation-aware synchronous groupware systems usually aim at cooperative work, where collaborators work on shared objects and organize their cooperation themselves. We argue in this paper that executing cooperative activities requires both types of cooperation support. According to our experiences in a European research project, support for joint re-definition and flexible execution of emerging cooperative activities is crucial. However, current WFMS and groupware systems do not address these requirements.
Our approach extends the WWW with shared hypermedia workspaces, which support joint (re)definition of emerging activity breakdown structures and their flexible interactive execution. This means that participants can adapt and complement the running workflow cooperatively, and that enhanced execution support is provided for incorporating synchronous group work. For this we integrate flexible workflow management and cooperation-aware synchronous groupware mechanisms.
The remainder of this paper is organized as follows: The next section deals with a problem analysis and identifies important requirements for supporting cooperative activities. Then, we present how our approach, which is based on cooperative hypermedia and combines different hypertext domains, addresses the identified requirements. Afterwards, we present a use case and early usage experiences. Then, we compare our work to related work. The paper ends with conclusions and plans for future work.
The background of this research is to support the cooperative modeling and operation of extended enterprises. The Extended Enterprise is a concept for time-limited cooperation between business partners using a networked knowledge-sharing infrastructure. Our use case scenarios come from the EXTERNAL IST-1999-10091 project funded by the European Union [7]. EXTERNAL and follow-up initiatives develop an infrastructure, tools and a methodology for supporting the formation and operation of extended enterprises. In the EXTERNAL project, one of the use case scenarios has been to support cooperative project planning and cooperative work execution.
The EXTERNAL team consists of members from five companies located in three countries. Work has been split into 9 work packages each lead by a work package manager and staffed by members from several companies. The project plan can be interpreted as the core business process, which the team has been performing.
On the one hand, this business process addresses well-defined activities, i.e. activities that are followed regularly and only need little change, such as the preparation of progress reports. On the other hand, it addresses evolving activities, i.e. activities, which require frequent redefinition - even at runtime, such as software development activities that emerge as more complex than initially assumed. Thus, the cooperative (re)definition of activities is crucial:
R1. Joint work on activity definitions as well as jointly performing activities must be supported. This is needed in order to resolve ambiguities and conflicts as well as to reach agreement and acceptance. To do so, asynchronous and synchronous collaborative work must be facilitated.
Moreover, the business process includes ad hoc activities, i.e. activities that are more creative, rather than well defined. People usually produce documents when working on ad hoc activities. They use either classical applications like spreadsheets or word processors or cooperation-aware synchronous groupware tools like brainstorming or cooperative mind mapping. The latter is due to the fact that cooperation is part of the very nature of ad hoc activities. In order to support ad hoc activities and to collect important information in the context of a specific activity, information objects are very important:
R2. The collaborative workflow definition needs to be able to reference any type and number of information objects¾that might be documents in the classical sense or shared artifacts. In addition, flexible means for annotations and explanations of the workflow definition are required.
For activities that cannot be completely prescribed interactive execution is needed, i.e. users contribute to the interpretation of the collaborative workflow by completing the definition and making co-decisions when it is necessary:
R3. For executing cooperative activities the interaction between the participants and the system (the workflow engine) is important so that participants can adapt and complement the running collaborative workflow [12].
The interaction between participants and the engine is one important aspect of interactive execution. Cooperative activities need, in addition, support for the interaction between participants. Activities, such as weekly meetings, require support for synchronous group work. Such activities can be prescribed, e.g. in the context of a fixed agenda, or they may be flexible:
R4. The execution of cooperative activities requires special execution support, which goes beyond the classical document flow and invocation of single-user applications. Examples are the initialization of synchronous sessions and specific awareness support.
The activity-support environment needs to be easily accessible from everywhere. Thus, we decided to enhance a Web-based system with the necessary cooperation support.
Our approach is based on cooperative hypermedia and combines different hypertext domains in order to address the identified requirements. In the following, we describe the cooperative definition of collaborative workflows based on our shared hypermedia data model. In addition, we explain the cooperative interactive execution of collaborative workflows. Finally, we describe an implementation of our approach.
We model collaborative workflows using cooperative hypermedia integrated with process support [27]. This supports participants in creating and manipulating shared and persistent hypermedia objects, either synchronously or asynchronously (see R1). Figure 1 shows a simplified extract from our shared hypermedia data model. It is based on the Dexter hypertext reference model [10]. Our data model uses special node and link types ("Activity", "Process Relation", and sub-types) for representing workflow structures explicitly. Activity objects are composite objects and can thus contain other nodes and links in order to model nested structures. For sub-activities we are using inclusion containment with the characteristics of single containment, single membership, and no ordering [32] since a sub-activity is part of one unique parent-activity. To reuse activity structures, one can use activities as templates, i.e. cloning and adapting them. The ordering of activities are modeled explicitly using temporal and conditional relationships. We support several temporal and conditional relations between activity objects, which are typical for defining processes [33]. Currently, these are sequential, parallel, simultaneous, iteration, and alternative. In addition, we support temporal and conditional relations that are common in interactive systems, such as selectable and optional [9].
Figure 1: Extract from the Shared Hypermedia Data Model
Every hypermedia object is also a shared object. A shared object is potentially accessible from all participants. Concurrency control mechanisms take care of consistency. In an object-oriented environment a shared object typically has a unique identifier and shared attributes. Figure 1 makes use of UML-G [22] in order to model independently from any concrete architecture. The observable tag expresses that notifications about changes on instances of HMObject need to be supported in order to support synchronous cooperation. The shared hypermedia objects are modeled as persistent since asynchronous cooperation requires persistent data; otherwise different people at different points in time can't continue work. Moreover, it must be possible to continue synchronous work later. Finally, persistence is required to support transitions between asynchronous and synchronous cooperation.
Our cooperative editor, which supports the creation and manipulation of shared hypermedia objects, visualizes maps of the hypermedia structure, in form of a directed graph. Thus, links are displayed explicitly. Composite objects have an opened and a closed view whereas base node objects just have a closed view. Composite nodes can be opened in their original bounds to unfold their internal structures in their original context. Users can zoom in to see the details of the structure. This is a kind of fisheye plus focus visualization technique. Figure 2 shows two users, Alice and Bob, working with XCHIPS' cooperative hypermedia editor. Telecursors provide awareness about who is currently touching which object. User names on the bottom of a composite object indicate that these user(s) are currently working on it. Special annotation nodes provide visual artifacts for annotation and explanation purposes. For these nodes spatial proximity is used, rather than explicit links (see section 3.2). Annotation nodes are shared among the participants, too.
Figure 2: XCHIPS' Cooperative Hypermedia Editor Showing a Simple Workflow Structure
Our approach supports the participation of all stakeholders (or representatives of participating roles) in the definition and execution of cooperative activities (see R1). Only with active participation of all participants or at least their representatives potential conflicts in the work plan can be resolved. This is a kind of participatory design, an approach, in which end users of a system play a critical role in designing it [24]. Its fundamental principles are mutual reciprocal learning and design by doing. Our map-based hypermedia editor provides a shared space, where the different participants can model cooperative activities, assign responsibilities, annotate and discuss (by chat or audio support) the model. Modeling experts can participate, too, if they are needed. Furthermore, system designers can participate in case they are asked to implement support for specific activities. Thus, they learn from each other, agree on activities and assignments, and work together with system designers. Additional simulation support provides empirical hands-on practice (see section 3.3.2).
In our approach, it is important to distinguish between roles and actors. In use case modeling [3] these types are put together. There, actors are roles, but can also be e.g. human users. In that case it is a role played by a user. In Workflow modeling and in our approach roles and actors are separate modeling elements. An actor is an instance participating in performing an activity, e.g. a person, an organization, or a machine-based resource. Actors usually take roles when participating in an activity. From the cooperation point of view it is important to know the actor and to know the role the actor takes. On the other side it is important for our approach to allow incomplete workflow definitions and support interactive enactment, i.e. users can complete the workflow definition, and take decisions during run-time (see R3 and section 3.3.1). For this reason we allow to model roles participating in activities. Actors fill roles (but the workflow modeling environment does not enforce to model this). If the roles are not yet known actors can also directly participate in activities. Figure 3 gives an overview about the main explicit link types of our modeling language. The Process relation relationship is used there as a generic term for the different temporal and conditional relationships. These link types are visualized as explicit links in the map-based editor. Role and Actor are additional special node types.
Figure 3: Main Explicit Link Types
From our point of view use case modeling needs to incorporate the separation of actor and role in order to support cooperative activities more appropriate as activity diagrams are used to represent the flow of events in use cases [3].
Information objects are resources relevant in the context of a specific activity. The hypermedia-based workflow structure can reference any kind of information object by using special hypermedia wrappers that can point to classical documents as well as shared artifacts [21] (see R3). Here, we are using referential containment (with the characteristics of multiple containment, single membership, unordered, containment relationship on container [32]) since the same information object can be relevant in the context of more than one activity. By opening a wrapper object either the application registered for that type of document or the cooperative tool, such as a shared whiteboard, bound to the referenced shared object is invoked (dependent on the referenced object type). Folders as containers for information objects can be used to structure the objects relevant for one activity. In addition, freely labeled links can be used between information objects in order to express dependencies.
The Web focuses on navigational hypertext. We combine navigational hypertext for navigating through the activity space with map-based, spatial [17], and cooperative hypertext. Cooperative hypertext enables cooperative definition of collaborative workflow structures (see section 3.1). For creating and manipulating the workflow structure cooperatively, a map-based visualization is used that shows the structure explicitly, which is relevant for a specific activity, in order to provide the necessary overview. Sub-activities can be opened within the same view so that the whole hierarchy can be visualized in one map. In addition, a specific hierarchical view can be invoked that focuses on composite relationships and hides the explicit links. When using maps at the user interface, proximity becomes important. We are using spatial proximity and visual artifacts for annotation and explanation purposes (see R2). In contrast to the more formal-oriented activity-based structure these visual artifacts can be used to express ambiguity and to annotate incomplete models. Furthermore, it can be used to explain parts of the model or decisions taken. Thus, our approach complements Web-based workflow systems, such as Workware [4], [12] and WWWorkflow [2] with support for synchronous access to and manipulation of the activity-based structure and shared information objects. Moreover, flexible means for cooperative annotations and explanations are provided.
From the structural computing point of view [19], [20] our approach combines different structural abstractions - the classical navigational structure, spatial hypertext, and activity-based structure. The structural computing philosophy points out that systems need an open set of behaviors, computations over structure. The way collaborative workflow structures need to be executed differs from use case to use case. In addition, activities of one use case evolve over time and different execution support is needed. To support emerging behavior our approach proposes interactive execution (see section 3.3).
Interactive execution includes cooperation between the execution engine and the user, which is provided by several flexible workflow systems. In addition, it addresses cooperation between the users. The latter is usually missing in existing approaches and thus an important contribution of our approach.
For our approach, it is important to support incomplete workflow definitions, i.e. workflows can be executed at any time and users can interact with the collaborative workflow engine in order to take a decision or complete the definition (see R3). Users can manually activate, suspend, and complete activities. In addition, they can adapt the running workflow, i.e. perform modeling activities as a part of the execution. Flexible workflow systems, such as [6] [12], usually provide this kind of execution support. However, they lack the support for synchronous cooperation in workflow definition and execution as well as explicit communication channels for team members to "meet" and talk, as to coordinate their joint interaction with the tasks, documents, and the workflow structure itself. They do not have a graphical workflow editor for team members to visualize the task dependencies, navigate in the underlying workflow structure, and to modify the workflow structure through direct cooperative manipulation in a distributed virtual meeting setting. This gap is addressed in our approach by supporting the interaction between participants.
In our approach, interactive execution does not just focus on the interaction with the collaborative workflow engine, but also on the interaction between the participants (see R4). During execution of a collaborative workflow participants can work cooperatively on specific activities. They can meet online in order to resolve conflicts, e.g. by performing joint resource reallocation. Thus, they can adapt the running workflow. They can even extend it by adding details of activities, such as sub tasks.
In addition, we provide special execution support for group work. Activities can be simulated before execution so that participants can validate possible execution sequences. In addition, an activity can be linked to a shared artifact, which is manipulated by performing the activity. Different participate links can specify a specific cooperative tool that the assigned role or actor has to use to participate in the activity. And constraints can be expressed based on the shared artifact. In order to attach these additional elements to the model, a modeling expert can participate in the modeling session. Even system designers can participate in case they are asked to implement support for specific activities. When executing such an enhanced workflow definition the system performs the following steps for each activity that gets activated (according to the temporal and conditional relations and the status of the execution):
Thus, following a temporal or conditional link invokes specified cooperative tools on specified shared artifacts. Whether decisions need to be taken depends on the links.
This provides empirical hands-on practice and integrates group work. It goes beyond the classical document flow and invocation of single-user applications, which is usually provided by classical workflow engines.
The current prototype is implemented by the integration of the Web-based workflow system Workware [4], [12] and an extended version of the cooperative hypermedia system XCHIPS [21], [28]. Figure 4 shows a UML deployment diagram [23] related to this integration. There we can see the different components of server and client, the dependencies between these components, and how server and client are connected.
Figure 4: Components of the Prototype Implementation
The communication between clients and server is based on HTTP (Hypertext Transfer Protocol) in order to overcome potential firewall problems. The Workware servlets are running within Tomcat - a Web server and servlet container from Apache that is being developed in the context of the Apache Jakarta Project. Tomcat includes built-in support for WebDAV - an extension of HTTP for remote authoring of websites [31]. We are using WebDAV for the XML-based data exchange between XCHIPS and Workware, i.e. we are using a special XML-based format for representing workflow structure. In addition, Tomcat is serving XCHIPS, i.e. in order to start an XCHIPS server or an XCHIPS client we are using Java Web Start, which supports the automatic update and invocation of Java-based applications from a Web browser or the Java Web Start application manager by accessing the archives on a Web server. This enables a "one-click"-installation and update of an XCHIPS server as well as the invocation of an XCHIPS client from a Web browser. The client and server archives use one shared core component of the XCHIPS system. On the client side we are using Java Web Start rather than applets in order to benefit from the full potential of applications, such as for managing local documents and integrating A/V conferencing [29]. The disadvantage of not using applets is that the user interfaces of XCHIPS and Workware cannot be integrated within one browser window. The XCHIPS server uses an object database in order to store shared artifacts that can be manipulated or viewed cooperatively by a cooperative tool. Both - XCHIPS and Workware - have a URL-based API. The Workware servlets dynamically generate the user-dependent XCHIPS-URLs for each activity. These can be used in order to start or join cooperative XCHIPS sessions on these activities. When such a session is running on a specific activity this activity cannot be manipulated within Workware, but it can be browsed in Workware. When a cooperative session is finished the changes to the underlying activity are written to WebDAV and Workware is notified about the changes by invoking a referring HTTP request. The implementation of XCHIPS is based on the framework DyCE [25] that supports transactional access to and modification of shared data. DyCE supports HTTP-tunneling and client-side polling, i.e. clients ask for transactions rather then run a service that is used by the server to send them. In this way synchronous cooperation can run through firewalls.
In the following, we firstly present a cooperative planning and execution scenario utilizing the approach described in previous sections and implemented through the integration of Workware and XCHIPS. Then we report some usage experiences we gained in the use case.
In the EXTERNAL project, we have used the integrated system described in the previous section to support team members to create action lists cooperatively as part of their usual virtual meeting, and to export these task lists to the Web-based work support environment, where they are enacted. In the following, a detailed scenario description (in italic) is given to show (from a user's point of view) how this is done.
Alice, a software engineer working for the tool development package of the project, accesses the EXTERNAL work environment through a standard Web browser to check for ongoing tasks, and to conduct a virtual meeting with the work package manager. In the virtual meeting, the participants discuss problems and further work, and jointly create action items to address the issues. These actions automatically become part of the work plan performed in the work execution environment.
Firstly, Alice accesses the EXTERNAL environment through her Web browser. After providing the web address, she identifies herself to the system. She then proceeds to her current project by selecting the EXTERNAL project from the project list. Her first job is to check for the status of the actions presented as task lists. Thus, she selects the action list entry on the left side menu in the portal.
The EXTERNAL environment for action lists displays an overview of all tasks in a project. Figure 5 shows the EXTERNAL portal (which is based on the portal technology of Computas AS [5], Norway), the Workware explorer presenting activity lists generated for Alice, and the description of a selected task.
In the upper right part of the task description there are several buttons for invoking XCHIPS' services on the selected activity, such as the cooperative hypermedia editor, a simple chat, or a collaborative swimlane view.
Alice is now checking for her tasks. She notices the "Meeting task", which reminds her of the weekly meeting with her work package manager. Since they reside at different sites, they usually meet virtually in the EXTERNAL environment. By pressing the "chat button" in the task description window, Alice uses the EXTERNAL environment to invite the tool development WP manager, Bob, into a chat session.
By pressing the "invite" button she can invite any available worker for participating in the chat. As Bob accepts the invitation, he is presented with a synchronized chat tool. Bob and Alice now discuss the meeting agenda using the chat. Optionally, they could also use an audio conference.
Alice is now using the XCHIPS button in the task description window to open a shared workspace on the meeting task. As Bob accepts the invitation, he is presented with a synchronized copy of Alice's XCHIPS window. This is indicated by his name appearing in the user list in the upper left part of the session window (see Figure 2). Bob and Alice are now using the chat and the shared browser to conduct the meeting.
Figure 2 shows XCHIPS' cooperative hypermedia editor providing a shared workspace for the meeting task. We can see that Alice and Bob are cooperating on a simple workflow structure, which serves as the agenda.
Together, they discuss some issues in the order proposed by the agenda and using the specified cooperative tools, such as a shared mind mapping one. They agree to record their decisions on next actions as action items in the shared workspace. For this, Alice is now opening the cooperative hypermedia editor on the task, to which the new actions belong to. They use the shared browser to get an overview of the activity and to identify several missing actions within the overall context. Bob is adding an action as a new task object. Alice is adding more actions. Alice and Bob are now using the shared browser to define responsibilities and time constraints for the new actions. After they agree, the result is a set of fully defined actions ready for execution.
All what remains to be done now is to publish the changed work plan back to the Workware work execution environment. This is done via a simple button click (for XML export to the WebDAV repository).
Alice and Bob are now saying "Goodbye". Alice is returning to the EXTERNAL work environment to continue her work. Watching the action list again shows her that the new tasks are now present, and work can continue.
Having used the shared Web-based hypermedia workspace portal integrating Workware and XCHIPS, users have got the following benefits:
Approximately 15 users used the system in the EXTERNAL project. Early observations and feedback indicate that the users like the ease of moving from collaborative action list definition to collaborative execution. Furthermore, the collaborative definition of workflows seems to increase the acceptance of action assignments within the team.
WFMS, such as WWWorkflow [2] or the one in [13] built on KMS [1], focus on support for automatic enactment of asynchronous cooperative work, where the flow of work is either strictly predefined or may emerge during run-time. The latter requires the support of flexible WFMS, such as Freeflow [6] and Workware [12]. Flexible WFMS usually support some kind of interactive execution, i.e. users participate in interpreting the model and resolve ambiguities. However, WFMS usually don't support teams in negotiating joint work processes, in facilitating synchronous access to shared information resources, and in providing immediate interactive feedback and awareness. Thus, they don't support the interaction between participants while executing the workflow model. The interaction framework for flexible workflow modeling, presented in [12], does not consider the interaction between participants, which we think should be added.
Cooperation-aware groupware systems usually aim at synchronous cooperative work, where cooperators work on shared objects and organize their cooperation themselves. However, they lack coordination support provided by WFMS.
Existing approaches to integrate workflow and groupware functionalities, such as [18], don't address the smooth integration of synchronous cooperation as we do, e.g. through automating synchronous sessions. Endeavors [14] integrates communication tools, but does not support synchronous cooperation on the workflow structure and automating cooperation sessions for execution. Our previous work on CHIPS [27] and XCHIPS [28] lacks the automation of sessions and the integration with a flexible WFMS, such as Workware [12].
Other approaches to enhancing the WWW with cooperation support, such as sTeam [11], focus on document management, rather than modeling and executing workflows.
The approach in [15] supports the composition of information management services for processing dynamic Web content. IBM's Web Services Flow Language [16] is an XML-based language for composing Web services so that business processes are supported. Approaches like these use a workflow-based structure for coordinating services. However, there is no focus on cooperative activities and thus no specific support for collaborative definition and interactive execution of cooperative activities.
Activities are also relevant in the context of use case modeling as they are modeled to represent the flow of events in use cases [3]. However, CASE (Computer Aided Software Engineering) tools supporting flexible collaborative modeling and in particular collaborative interactive execution of the activity-models are usually not supported.
The method Groupware Task Analysis [26] provides a conceptual framework that enables the integrated description of different aspects of the situation in which end users perform their tasks. These aspects include aspects of the physical and social environment of the system. This approach focuses on an overall task world ontology for groupware, but does not support joint definition of emerging activity breakdown structures and their flexible collaborative interactive execution.
Existing Web-based workflow systems have made task list handlers widely accessible and provide good support for asynchronous cooperation. However, such systems are weak in synchronous cooperation support for either the activities to be performed by multiple people or for the collaborative adaptation of collaborative workflow. To address this problem, we propose an approach that integrates a Web-based workflow approach with a cooperative hypermedia-based process support approach. By taking the advantage of a Web-based approach, such an integrated system allows users to access task lists, their underlying workflow structure and related documents from anywhere using a standard Web browser. By exploiting the advantages of a cooperative hypermedia-based approach, such a system allows users to perform the cooperative activities, to refine their underlying workflow structure, and to deal with emerging problems cooperatively in a virtual meeting setting during run-time of the workflow. Comparing with the state of the art, the contribution of this work includes:
This bridges the gaps between workflow definition and execution as well as asynchronous and synchronous cooperation in a single shared workspace on the WWW.
To validate the approach, a use case and some usage experiences of the system were presented. This use case and the usage experiences indicate that such an integrated system can support project teams to conduct virtual meetings and to record action items in remote meetings. It supports team members to reach an agreement on action assignments within the meeting. The enactment of the confirmed actions is supported in a Web-based execution environment. Flexible collaborative interactive execution is provided in the shared workspace. Later access to the context of the creation of action items is supported by the Web- and cooperative hypermedia-based shared workspace. In summary, this approach makes the joint definition of action lists in virtual meetings simple, and facilitates the later execution of the accepted action lists. This makes project work more effective.
We would like to thank our EXTERNAL partners for fruitful cooperation, i.e. Computas AS, DNV, and SINTEF Telecom and Informatics from Norway, and Zeus E.E.I.G. from Greece. Special thanks go to Håvard Jørgensen and Svein Johnsen from SINTEF for taking care of the Workware integration.
[1] : KMS: a distributed hypermedia system for managing knowledge in organizations, In: Communications of the ACM 31,7, 1988, pp. 820-835.
[2] : A Web Based Enterprise Workflow System, In: Proceedings of GROUP'97, ACM Press, 1997.
[3] : Advanced Use Case Modeling: Software Systems, Addison-Wesley, 2001.
[4] : Emergent Workflow: The AIS Workware Demonstrator, In: CSCW-98 Workshop: Towards Adaptive Workflow Systems, 1998.
[6] : Freeflow: Mediating Between Representation and Action in Workflow Systems, In: Proceedings of CSCW '96, ACM Press, 1996.
[7] http://www.external-ist.org/, 2000-2002.
[8] : Enhancing Workflows by Web Technology, In: Proceedings of GROUP'97, ACM Press, 1997.
[9] : Teallach: A Model-Based User Interface Development Environment for Object Databases, In: Proceedings of UIDIS'99, IEEE Press, 1999, pp. 86-96.
[10] : The Dexter hypertext reference model, In: Communications of the ACM 37, 2, 1994, pp. 30-39.
[11] : sTeam - Designing an Integrative Infrastructure for Web-based Computer-Supported Cooperative Learning, In: Proceedings of WWW10, ACM Press, 2001, pp. 76-85.
[12] : Interaction as a Framework for Flexible Workflow Modelling, In: Proceedings of GROUP'01, ACM Press, 2001, pp. 32-41.
[13] : Providing workflow services using a programmable hypermedia environment, In: Information and Software Technology, Elsevier 40, 1998, pp. 381-396.
[14] : Supporting Distributed Workflow Using HTTP, In: Proceedings of 5th International Conference on Software Process, 1998.
[15] : Dynamic Coordination of Information Management Services for Processing Dynamic Web Content, In: Proceedings of WWW 2002, ACM Press, 2002.
[16] : Web Services Flow Language (WSFL 1.0), IBM Software Group, available at: http://www-3.ibm.com/software/solutions/webservices/pdf/WSFL.pdf , 2001.
[17] : Searching for the Missing Link: Discovering Implicit Structure in Spatial Hypertext, In: Proceedings of Hypertext'93, ACM Press, 1993, pp. 217-230.
[18] : Integrating Workflow and Groupware Functionalities for Co-operating Small and Medium Sized Enterprises: a Case Study, In: Proceedings of CRIWG'01, IEEE Press, 2001, pp. 38-43.
[19] : As We Should Have Thought, In: Proceedings of Hypertext'97, ACM Press, 1997, pp. 96-101.
[20] : Structural Computing and its Relationships to Other Fields, In: 3rd International Workshop on Structural Computing, Springer, 2001.
[21] : Organizing Shared Enterprise Workspaces Using Component-Based Cooperative Hypermedia, In: Proceedings of Hypertext'01, ACM Press, 2001, pp. 73-82.
[22] : Towards UML-G: A UML Profile for Modeling Groupware, In: Proceedings of CRIWG'02, Springer, 2002, pp. 93-113.
[23] : The Unified Modeling Language Reference Manual, Addison-Wesley, 1999.
[24] : Participatory Design: Principles and Practices, Lawrence Erlbaum Associates, 1993.
[25] : A Framework for Developing Component-based Co-operative Applications, GMD Research Series No. 7/2001, 2001.
[26] : Task Based Groupware Design: putting theory into practice, In: Proceedings of DIS 2000, 2000.
[27] : Flexible Coordination with Cooperative Hypermedia, In: Proceedings of Hypertext'98, ACM Press, 1998, pp. 245-255.
[28] : Hypermedia-Based Support for Cooperative Learning of Process Knowledge, In: Journal of Network and Computer Applications, Academic Press 23, 2000, pp. 357-379.
[29] : A Cooperative Visual Hypermedia Approach to Planning and Conducting Virtual Meetings, In: Proceedings of CRIWG'02, Springer, 2002, pp. 70-89.
[30] : Group Formation in Computer-Supported Collaborative Learning, In: Proceedings of GROUP'01, ACM Press, 24-31, 2001.
[31] : WebDAV and DeltaV: Collaborative Authoring, Versioning, and Configuration Management for the Web, In: Proceedings of Hypertext'01, ACM Press, 2001, pp. 259-260.
[32] : Uniform Comparison of Data Models Using Containment Modeling, In: Proceedings of Hypertext'02, ACM Press, 2002, pp. 182-191.
[33] : The Workflow Management Coalition Specification, available at: http://www.wfmc.org/.
![The EXTERNAL Portal [5] and Workware [4], [12]](./p563-rubart-5.gif)