CoMex
– A Mechanism for Coordination
of Task Execution in Group Work
Hilda Tellio˘glu
Vienna University of Technology, A-1040 Vienna, Austria
Abstract. CoMex (Co ordination Mechanism) is a system to coordinate
the execution of tasks accessing coordinable entities. It uses coordination
rules to describe the temporal and logical order of tasks performed in a
co operative work setting. These rules coordinate semantic dependencies
b etween work activities carried out by different users. The coordina-
tion rules are implemented in a relational database. This makes CoMex
unique and easy to integrate into an existing application. By illustrating
a case from a real work setting we show how these rules can be created,
which methodology can be applied for their production and how CoMex
can be used in a web application. We also describe the implementation
of CoMex and its architecture.
1 Introduction
Collaboration within a workgroup can only be established when several commu-
nication, coordination and cooperation mechanisms are provided by the system
in use. No matter whether computerized or paper-based, these mechanisms have
a great impact on work processes and must therefore be designed carefully.
Efficiency in the collaboration of workgroup activities requires coordination
mechanisms to ensure that dependencies occuring because of contextual, tempo-
ral or organizational reasons are considered accordingly. Some researchers tried
to identify and classify coordination processes [9]. Others tried to describe coordi-
nation problems within complex work processes. To them this is the precondition
to provide solutions to these problems. Etcheverry et al. defined a topology of
coordination problems and tried to solve them by means of well-known coordi-
nation forms [10]. They provided a catalogue of coordination patterns by taking
the coordination situations identified by Malone and Crowston [14].
There are also several coordination models and languages which are mostly
categorized by distinguishing b etween data-driven (like Linda [4], Sonia [7],
Laura [19], Ariadne [12] etc.) and process-oriented coordination models (like
IWIM [1], MANIFOLD [2] [3]) [17, p.35ff]. The focus of these approaches is to
overcome the complexity of providing coordination mechanisms on a technical
level. Most of them do not consider how the cooperative work is in fact carried
out.
Tellio
˘
glu H. (2004).
CoMex – A Mechanism for Coordination of Task Execution in Group Work.
In Proceedings of the 1st International Workshop on Computer Supported Activity Coordination, pages 13-20
DOI: 10.5220/0002670200130020
Copyright
c
 SciTePress

In this paper we will present the coordination mechanism called CoMex and
show the methodology we applied to design the coordination setting for a work
environment. CoMex is a mechanism to coordinate the execution of tasks access-
ing coordinable entities. It uses coordination rules to describe the temporal and
logical order of tasks performed in a cooperative work setting by several actors
and to coordinate semantic dependencies between work activities.
We take a real work domain as an example to illustrate our methodologi-
cal approach. Our case is about an international insurance company that uses
a management information system (MIS) with workflow functionality. Some re-
quirements are management of information packet requests and enrollment forms
clients send, or management of policies they offer and maintain. The system is
a web-based application. Some of the artifacts are inquiry requests, enrollment
forms, policies, contacts, dependents, outstanding items etc. Figure 1 illustrates
the basic activities carried out after receiving an enrollment form.
1
Fig. 1.
The next section shows how we carried out the systems design in our case.
This is the methodology that we found very effective and useful if one has to
introduce a coordination mechanism into a work environment. Section 3 presents
the coordination mechanism CoMex. In the same section its implementation is
presented in detail before concluding the paper.
1
14

2 The Methodology
The conceptualization of a work domain is the first step to understand its ob-
jects and relations between its actors. The entities that may exist in that domain
and the relationships among those can be named and described by means of a
domain conceptualization. This provides a vocabulary for representing and com-
municating knowledge about that domain [11, p.2]. In [18] the notion of ontology
is used to model artifacts, create hierarchies and layers as a conceptual model
that is processable by computers. [15] had developed an approach to identify
elements to be coordinated (static coordination) and how these entities may be
coordinated (dynamic coordination). We have an object-oriented approach to
conceptualize the artifacts of the work domain. We create use case diagrams
with UML to understand and show what users want to do with the system en-
tities, how they carry out their work when they deal with their artifacts, what
their requirements are. In our example, users want to receive, modify, send out,
submit an enrollment form, receive an inquiry request and send an information
packet to the client, be informed when a new enrollment form or inquiry request
is received, calculate the effective date of the policy, contact the corresponding
persons like clients, agents, representatives etc.
Next, we create a data dictionary that describes concepts used in the sys-
tem and their relations to each other. After identifying classes, their attributes
and relations we produce a domain model that we may modify several times.
Next step is to define the constraints that the system has to fulfill. Relations,
associations and hierarchies between entities include restrictions and norms. We
consider these in the design process. We use the concept of rules that derive
from the relations defined in the domain model. Rules express the (hidden) de-
pendencies between entities. They describe what needs to be guaranteed by the
system in order to achieve consistency and correctness in the domain model.
Rules emerge when users talk about dependencies between their artifacts and
activities. Rules need to be refined and communicated between users and sys-
tems designers until all are convinced of the necessity, correctness and usefulness
of them.
Rules can in a first step be presented in a natural language. This makes their
exchange between users and designers easy. For instance, some of the rules for
enrollments are
2
:
R
1
:
R
2
:
R
3
:
Finally, we create activity diagrams to show the tasks to be performed and their
temporal and logical order (see Figure 1). This way we design the specific task
execution and define the work order.
2
1
15

3 CoMex – The Coordination Mechanism
The coordination theory applied in CoMex is based on processes that consist of
resources, activities and dependencies [14]. A dependency is a relation among
activities. There are three types of dependencies: flow, sharing and fit. A flow
dependency occurs when one activity’s output is a resource that is used by an-
other activity. When multiple activities use the same resource we talk about a
sharing dependency. A fit dependency happens when multiple activities together
produce a single resource. “Using these three basic types, any process can be de-
composed into a structure of activities and dependencies.” [13, p.2]. Coordination
is “managing dependencies between activities” [14, p.90]. Dependencies can be
described by using temporal relations between tasks. Allen defined seven prim-
itive relations between pairs of tasks [5]. These descriptive, mutually exclusive
relations can be applied over time intervals T
1
and T
2
:
– T
1
equals T
2
when they start and end at the same time.
– T
1
starts T
2
when both start at the same time, T
1
ends before T
2
.
– T
1
finishes T
2
when T
1
starts after T
2
and b oth end at the same time.
– T
1
meets T
2
when T
2
starts when T
1
ends.
– T
1
overlaps T
2
when T
1
starts before T
2
ends and T
1
ends before T
2
.
– T
1
is during T
2
when T
1
starts after and ends before T
2
.
– T
1
is before T
2
when T
1
ends before T
2
starts.
Allen also used a set of axioms to create a temporal logic based on these relations
[6]. Raposo and Fuks extended Allen’s seven primitives by introducing active,
passive, blocking and resource management interdependencies. They created a
model by proposing Petri-Net-based coordination mechanisms to deal with these
task interdependencies [16].
The coordination mechanism that is shown in this paper is based on task
interdependencies. The passive interpretation of these dependencies [16] are not
used because they do not support active handling in the task coordination.
By analyzing the activity diagrams we can define coordination rules. These
are rules that are derived by analyzing the temporal and logical order of tasks
that must be performed in order to implement a use case in an application. In
our example we can define the following coordination rules (CR
i
):
3
CR
1
: receiveEnrollment meets checkItemsOfEnrollment
CR
2
: receiveEnrollment meets notifyAdministrator
CR
3
: receiveEnrollment meets modifyTodoListOfAdministrator
CoMex uses a relational database to store the coordination rules. Figure 2 shows the
tables and relations in the CoMex database. Coordination rules (table CR) are coordina-
tion laws [17] that determine how active entities are coordinated using the coordination
media. They specify the semantics of the model’s framework.
Before the coordination rules can be entered into the database, CoMex needs to
know about the entities managed in the system. Entities can be saved in the domain’s
3
A simple notation is used here.
16

<<table>>
EntityType
-entityTypeID[1] : int (11)
-entityTypeName[0..1] : varchar (128)
+entityTypeID( entityTypeID )
+PRIMARY( entityTypeID )
<<table>>
ActionType
-actionTypeID[1] : int (11)
-actionTypeName[0..1] : varchar (128)
+actionTypeID( actionTypeID )
+PRIMARY( actionTypeID )
<<table>>
CoorType
-coorTypeID[1] : int (11)
-coorTypeName[0..1] : varchar (128)
+coorTypeID( coorTypeID )
+PRIMARY( coorTypeID )
<<table>>
CR
-firstTaskID[1] : int (11)
-coorTypeID[1] : int (11)
-secondTaskID[1] : int (11)
+firstTaskID( firstTaskID )
+coorTypeID( coorTypeID )
+secondTaskID( secondTaskID )
+PRIMARY( coorTypeID )
<<table>>
Task
-taskID[1] : int (11)
-entityTypeID[1] : int (11)
-actionTypeID[1] : int (11)
-method[0..1] : varchar (255)
+taskID( taskID )
+actionTypeID( actionTypeID )
+entityTypeID( entityTypeID )
+PRIMARY( actionTypeID )
* equals
* starts
* finishes
* meets
* overlaps
* during
* before
1..*
0..*
Fig. 2. The database structure of CoMex.
own database, only their types must be entered into the CoMex database. Entities used
in this example are Enrollment, Info Packet Requests, Policy, Outstanding Item.
To associate entities with rules, tasks are introduced. Certain tasks are assigned
to certain entities. Figure 2 shows the relation between entity and action types, tasks
and coordination rules. Some action types in our case are receive, submit, modify
todo-list, notify, check items.
To create coordination rules tasks are needed. Tasks include actions to different
entity types and the name of the method that must be invoked in the application when
the task is carried out. For some tasks no methods are necessary and the value is set
to null. The entityTypeID of Enrollment is “1”. The actionTypeID of receive is
“11”. We need "insert into Task values (1,1,1,null);" for receiveEnrollment
and "insert into Task values (13,1,11,’checkItemsOfEnrollment’);" for
checkItemsOfEnrollment.
Co ordination rules consist of tasks and a coordination type. Coordination types
are equals, starts, finishes, meets, overlaps, during, before. In our case we try to
create coordination rules for the entity Enrollment. If an enrollment is received – which
happ ens by means of a HTML-form in the web application which on the one hand sends
an e-mail to the administrator and on the other hand stores the data entered into the
database – three tasks must be executed. We show here only the one which starts to
check all items that need to be attached if one of the questions in the enrollment form
is answered with “Yes” (CR
1
). The coorTypeID of meets is “4” and we need the entry
"insert into CR values (1,4,13);" in the database.
CoMex is implemented in Java (JDK 1.4). We used MySQL (Version 3.23.55) as
database, The Tomcat 4 Servlet/JSP Container (Version 4.1.24), The Apache Jakarta
Struts (Version 1.1) as an open source framework for building the web application. Fig-
ure 3 shows the architecture of CoMex and its interfaces to other systems. The client
tier provides an interface to interact with the application. The interaction includes
submitting a request and receiving a resp onse from the middle tier. Web container
with the web pages, servlets and b eans (computation part) and CoMex are lo cated in
the middle tier. CoMex is separated from the computation part, has its own database
17

(CoMexDB) and its own interfaces enabling configuration (CoMexAdmin) and monitoring
(CoMexMonitor). CoMexService is the main part of the mechanism in which co ordi-
nation rules are checked for a given task. The domain database and the CoMexDB are
lo cated in the enterprise information system (EIS) tier.
Middle Tier
CoMexWeb Container
Client Tier EIS Tier
CoMexService
(C)
ComexServiceImlementation
(C)
CoMexConfigure.xml
(M)
Struts framework
Web service peers
CoMexMonitor
(V)
CoMexAdmin
(V)
Web browser
JavaBeans
(M)
CoMexDB
Database
Servlet
(C)
Client
JSP
(V)
Fig. 3. System architecture. (M = Model, V = View, C = Controller)
If a client fills in the Enrollment Form in the web site and the data entered is val-
idated, CoMex is instantiated by the Action Servlet of the form Enrollment. The
metho d EnrollmentAction.execute() is called. It returns an ActionForward object
which is a wrapper around the physical resource specified in the configuration file.
4
EnrollmentAction.execute() sets all attributes of an Enrollment bean getting the
validated values from the EnrollmentWebForm given to the method by the parameter
ActionForm and stores the current Enrollment in the data store. We implemented
a service interface that Action classes use instead of interacting with the persistence
framework directly [8].
After successfully storing the Enrollment in the database, the EnrollmentAction.
execute() gets a CoMex service and starts the coordination process by invoking the
metho d ComexService.executeCR(). This has three parameters: the object which is
the instance of the entity for which coordination rules must be retrieved from the
database (in our case the enrollment), the type of this object and the action type.
What happens in the method ComexService.executeCR()? It connects to the
CoMex database, selects all coordination rules associated to the entity type given.
By each coordination rule (a selected row from the table CR) it looks for any method
declared in the corresponding tasks. Some of the tasks do not have any method de-
fined. That means it is not necessary to execute a sp ecific action by CoMex. But if
there is a method, its name is retrieved and saved in the string buffer methodStr.
Then ComexService.executeCR() searches for the full name of the method by using
Class.forName() of the Service Implementation which it reads from its configura-
tion file (CoMexConfigure.xml). The XML file is used to configure classes that are
relevant for CoMex.
5
Then it invokes the method by instantiating the appropriate
4
The ActionForward class represents a logical abstraction of a web resource which
can be a Java Server Page or a Java servlet.
5
For simplicity reasons dealing with the configuration file is not shown here.
18

class. In our example, to check the items needed for the enrollment form the method
checkItemsOfEnrollment() is invoked. It looks for documents on the server that had
to be uploaded by the client in case of a positive answer to any of the questions in the
enrollment form. If the document cannot be found the system sends an e-mail to the
client asking for the outstanding items.
4 Conclusions
In this paper we defined coordination rules which describe the temporal and logical
order of tasks performed in a cooperative work setting. These are used to coordinate
semantic dependencies between work activities carried out by different users. We also
showed – by illustrating a case from a real work setting – how these rules can be cre-
ated, which methodology can be applied and how this mechanism can be implemented
technically.
Co ordination problems are context-dependent. Etcheverry et al. had a general ap-
proach, without considering the context in which coordination takes place [10]. We
tried to introduce a methodology that enable user involvement in identifying context-
dep endent coordination situations. Users can specify dependencies between tasks they
carry out. The rules they define can easily be implemented in CoMex. CoMex is a safe,
cheap and easy way to control business pro cesses: Dependencies between activities are
co ordinated and tasks that must follow other tasks or must be executed at the same
time are invoked automatically. The system must guarantee that data is consistent,
necessary steps are taken and nothing is forgotten or missing. Additionally everything
must happen at the right time.
We argue that following issues are important in this context:
– It is not necessary to take care of any type of task dependency. Controlling and
co ordinating the share of common resources is the responsibility of the database
management system used. In fit dependencies we find activities running simulta-
neously or overlapping which are then synchronized to a given point of time. One
can easily map fit dependencies into flow dependencies using the seven relations
defined by Allen. The only dependency type that concerns any coordination mech-
anism is then the flow dependency. That is why we considered in CoMex only the
flow dependency.
– Is is important to apply UML in systems design, it enables better communication
b etween users and designers. But it is not necessary to produce too many diagrams
when these do not enhance the quality and efficiency of the process.
– It is still a problem to represent rules with UML. For this purpose, a formal lan-
guage is needed.
– To separate coordination from computation the transfer of domain specific data to
the coordination mechanism must be avoided. The interface between CoMex and
the application or other systems must dynamically create the necessary information
flow in the run time. In the current version of CoMex we still use a configuration
file that we want to eliminate in the future.
In this paper we presented a running version of CoMex. comex.jar can be used by
any object-oriented web application. However, the development of CoMex is not fin-
ished yet. CoMexAdmin and CoMexMonitor are just prototypes and must be refined and
completed.
19

References
1. Arbab, F.: The IWIM Model for Coordination of Concurrent Activities. First In-
ternational Conference on Coordination Models, Languages and Applications (Co-
ordination’96), 15-17 April, (1996) 34-56
2. Arbab, F., Blom, C. L., Burger, F. J., Everaars, C. T. H.: Reusable Coordinator
Mo dules for Massively Concurrent Applications. Europar’96, (1996) 664-677
3. Arbab, F., Herman, I., Spilling, P.: An overview of Manifold and its implementa-
tion. Concurrency: Practice and Experience 5(1) (1993) 23-70
4. Ahuja, S., Carriero, N., Gelernter, D.: Linda and Friends. IEEE Computer, August
(1986) 26-34
5. Allen, J. F.: Towards a General Theory of Action and Time. Artificial Intelligence
23 (1984) 123-154
6. Allen, J. F.: Maintaining Knowledge about Temporal Intervals. Communications
of the ACM 26(11) (1983) 832-843
7. Banville, M.: Sonia: an Adaptation of Linda for Coordination Activities in Orga-
nizations. First International Conference on Coordination Models, Languages and
Applications (Coordination’96), 15-17 April (1996) 57-74
8. Cavaness, C.: Programming Jakarta Struts. O’Reilly (2002)
9. Crowston, K.: A Taxonomy of Organizational Dependencies and Coordination
Mechanisms. http://ccs.mit.edu/CCSWP174.html Technical Report, 174, Mas-
sachusetts Institute of Technology, Center for Coordination Science (1994)
10. Etcheverry, P., Lopisteguy, P., Dagorret, P.: Pattern-Based Guidelines for Co or-
dination Engineering, DEXA 2001, LNAI 2113, eds. Mayr H. C. et al., Springer-
Verlag Berlin Heidelberg (2001) 155-164
11. Farquhar, A., Fikes, R., Pratt, W., Rice, J.: Collaborative Ontology Construction
for Information Integration. KSL 95-63, Technical Report, Knowledge Systems
Lab oratory, Stanford University (1995)
12. Florijn, G., Besamusca, T., Greefhorst, D.: Ariadne and HOPLa: Flexible Coordi-
nation of Collaborative Processes. First International Conference on Coordination
Mo dels, Languages and Applications (Coordination’96), 15-17 April (1996) 197-214
13. Hayashi, N., Herman, G.: A Coordination-Theory Approach to Ex-
ploring Process Alternatives for Designing Differentiated Products.
http://ccs.mit.edu/wpmenu.html Massachusetts Institute of Technology, Sloan
School of Management, Center for Coordination Science (2002)
14. Malone, T. W., Crowston, K.: The Interdisciplinary Study of Coordination. ACM
Computing Surveys 26(1) (1994) 87-119
15. Muccini, H., Mancinelli, F.: Eliciting Coordination Policies from Requirements.
SAC 2003 (2003)
16. Raposo, A. B., Fuks, H.: Defining Task Interdependencies and Coordination Mech-
anisms for Collaborative Systems. Coopertive Systems Design. A Challange of the
Mobility Age, eds. Blay-Fornarino, M. et al., IOS Press (2002) 88-103
17. Schumacher, M.: Coordination Models and Languages. Objective Coordination in
MAS Engineering, Springer-Verlag Berlin Heidelberg (2001) 33-49
18. Tellio˘glu, H.: A Coordination Mechanism Based on Ontologies: Methodology and
Implementation. VIP Scientific Forum of the International IPSI-2003 Conference,
5-10 October, Montenegro (2002)
19. Tolksdorf, R.: Coordinating Services in Open Distributed Systems with LAURA.
First International Conference on Coordination Models, Languages and Applica-
tions (Coordination’96), 15-17 April (1996) 386-402
20