Dynamic Collaborative Business Processes within ... - CiteSeerX

2 downloads 0 Views 328KB Size Report
Oct 10, 2004 - WD : Sign this! oid : 234. CWorkflow … .... Silberschatz, M. Stonebraker, R. Snodgrass, J. Ullman, G. Weikum,. Widom, and J. Stan Zdonik, "The ...
Dynamic Collaborative Business Processes within Documents Thomas B. Hodel

Harald Gall

Klaus R. Dittrich

University of Zurich Department of Informatics CH-8057 Zurich, Switzerland +41 1 635 45 76

University of Zurich Department of Informatics CH-8057 Zurich, Switzerland +41 1 635 43 35

University of Zurich Department of Informatics CH-8057 Zurich, Switzerland +41 1 635 43 12

[email protected]

[email protected]

[email protected]

ABSTRACT

and long-term business process operations require a certain kind of collaborative workflow management system [12].

Effective collaborate business process support is essential in today’s business. In this paper, we address this aspect within documents. Often, such text documents are stored unsystematically in a rather confusing file structure with an inscrutable hierarchy and little access control. Business data, on the other hand, are stored in a systematic way in databases allowing multi-user, multi-site, user-/role-specific controlled access. We store text documents in databases and exploit these database capabilities: colloborative business processes then can be defined per document or any part of a document. In this paper, we present this dynamic collaborative business process concept and the prototype within documents for our database-based collaborative editor. We evaluate the potential of such business processes for the quality of communication and documentation.

A significant gap lies between the handling of business data (customer, product, finance, etc.) and text data (documents). Documents are not treated as a product even though a lot of companies’ knowledge is stored within this structure. For a largescale document management environment, local copies of remote data sources are often made. However, it is often difficult to monitor the sources in order to check for changes and to download changed data items to the copies. In many cases, text documents are stored somewhere within a confusing file structure with an inscrutable hierarchy and low security. On the other hand, data, which from an organization’s point of view can be classed as crucial, are stored in databases. Here, the infrastructure and the data are highly secure, multi-user capable and available to several other tools for compiling reports, content and knowledge. Collaborative business processes can be defined and applied to such data. Our idea is to make use of such a philosophy for texts. We therefore strive for the storage of texts in a database in a native way, which would enable functions within and for documents such as editing, awareness, fine-grained security, sophisticated document management, versioning, business processes, text structure, data lineage, metadata mining, multichannel publishing and web-services, all within a collaborative, real-time and multi-user environment.

Categories and Subject Descriptors H.2.4 Systems [Database Management]: Systems, Systems, Textual databases

Information

General Terms Management, Measurement, Human Factors.

Documentation,

Economics,

Keywords

Based on the described collaborative platform, dynamic collaborative business processes can be defined per document, or for any part of a document. They are called dynamic, because the processes can always be changed, if the rights and flows allow it. They are collaborative for two reasons: first of all, all processes can be executed and defined in a parallel fashion, based on the TeNDaX architecture which allows editing at the same time within the same document, and secondly, the processes are not limited to one document as a whole. Within a document, elementary processes can be applied. On top of these elementary processes, collaborative business processes, including several documents and/or other processes, can be defined. In addition, decisions and conditional flows can be defined. These processes can point directly to a certain text-region, to one or a flow of elementary processes. Conditions can be related to a certain textregion and therefore be automatically or manually decided. Within these collaborative business processes, the same rules apply as within the elementary processes: everything is

Document business process technologies, native text database, computer supported cooperative work (CSCW), collaborative document processing.

1. INTRODUCTION In today’s world, doing business without the possibility of creating collaborative business processes, characterized by data storing and communication, is unthinkable. Day to day, ad hoc Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SIGDOC’04, October 10–13, 2004, Memphis, Tennessee, USA. Copyright 2004 ACM 1-58113-809-1/04/0010...$5.00.

97

transaction’ we mean that editing text (e.g., writing a character/word, setting the font for a paragraph, or pasting a section of text) invokes one or several database transactions so that everything which is typed appears within the editor as soon as these objects are stored persistently. Instead of creating files and storing them in a file system, the content of documents is stored in a special way in the database, which enables very fast real-time transactions for all editing processes [5].

collaborative, and can always be changed. Static process definitions can also be realized based on rights settings. In this paper, we focus on the business process problem within documents. For documents, innumerable workflow systems exist such as [9,10,11]. Within documents, there is no accurate workflow system available. According to our knowledge no word processing application is providing this functionality. Under a workflow system within documents we mean the possibility to define a workflow within (and/or for) a document. More precisely, it should be possible to set up the user or role (i.e. the person in charge) allowed to write, edit, sign, make a decision, or review any part of a text and the way (concerning time, serialized or parallelized) in which this can be done.

The database schema and the above-mentioned transactions are created in such a way that everything can be done within a multiuser environment, as approved by database technology. As a consequence, many of the achievements (with respect to data organization and querying, recovery, integrity and security enforcement, multi-user operation, distribution management, uniform tool access, etc.) are now, by means of this approach, also available for word processing.

Realizing such functionalities involves several aspects. First of all, the business process module has to be designed in such a way that it is collaborative. This means, at the same time several people can define, add, delete and change processes for and within the same document and see actions from other persons immediately. Second, the defined business process, or part of it, should by dynamically changeable, as long as a certain person has the permission, and the consistency of the whole business process is guaranteed. Finally the work off has to be collaborative, if this is requested and useful.

TeNDaX proposes a radically different approach, centered on natively representing text in fully-fledged databases, and incorporating all necessary collaboration support. Under collaboration support we understand functionality such as editing, awareness, fine-grained security, sophisticated document management, versioning, business processes, text structure, data lineage, metadata mining, and multi-channel publishing—all within a collaborative, real-time and multi-user environment.

This paper presents the dynamic collaborative business process concept and prototype within documents for our database-based collaborative editor. Further the consequences are evaluated of these collaborative processes, which can be applied on the lowest level (e.g., a character or any number of characters), for the quality of communication and documentation.

TeNDaX creates an extension of DBMS to manage text. This addition is carried out ‘cleanly’ and the responding data type represents a ‘first-class citizen’ [1] of a DBMS (e.g., integers, character strings, etc.).

2. APPROACH

1.1 Problem Description

Based on the described collaborative platform, dynamic collaborative business processes can be defined per document, or for any part of a document. They are called dynamic, because the processes can always be changed, if the rights and flows allow it. They are collaborative for two reasons: first of all, all processes can be executed and defined in a parallel fashion, based on the TeNDaX architecture which allows editing at the same time within the same document, and secondly, the processes are not limited to one document as a whole. Within a document, elementary processes can be applied. We structured these processes with the help of categories and category types. It makes sense, to class content, format, structure and process decision (see Fig. 1.) as categories, and category types may encompass edit, verification, comment, translate, and sign. Within this framework, all elementary processes, such as verify spelling, edit, add, shorten, write, write summary, change, illustrate, review, and complete text, can be registered.

Numerous word processing systems exist for documents, but no accurate dynamic business process system is available (and no database-based text editor). According to our knowledge no standard word processing application provides this functionality. Implementing such functionalities involves several aspects. The system has to be designed in such a way that it is collaborative, i.e. that several people can define, add, delete and change processes simultaneously within the same document, and can immediately see actions carried out by other people. The defined business processes should be dynamically changeable, as long as only a certain person has the permission to apply modifications to it, and the consistency of the whole process can be guaranteed.

1.2 Underlying Concepts The concept of dynamic, collaborative business processes requires an appropriate architectural foundation. The lowest level is a collaborative editing / document management system. Our concept and implementation is based on the TeNDaX [4] collaborative editing system, which we briefly introduce.

Apart from the aforementioned information, data such as process name and description, create date, author, processors (based on users and roles), due date, time and condition, specific notes, and access rights settings, are stored for each elementary process. On all elementary processes, work can be carried out simultaneously. If requested, a serial processing can be enforced (see Fig. 2.). As already mentioned, the process definitions can always be changed, if the state and user rights allow it. An elementary process can have the following states: inactive, skipped (inactive), active, overdue (active) or completed.

TeNDaX is a Text Native Database eXtension and makes use of such a philosophy for texts. It enables the storage of text in databases in a native form so that editing text is finally represented as real-time transactions. Under the term ‘text editing’ we understand the following: writing and deleting text (characters), copying & pasting text, defining text layout & structure, inserting tables, pictures, and so on; i.e. all the actions regularly carried out by word processing users. With ‘real-time

98

Figure 1. Define elementary process. Figure 2. Flow of elementary processes. The graphical view of elementary processes for one document (see Fig. 2.) depends on the active roles and their rights; therefore, each user could have a personalized view on a process.

2.2 Structuring of Text A text document’s main purpose is to represent text. To increase the benefits and the readability of text documents, one can structure them in multiple dimensions. Most obviously, the text can be split into sentences, paragraphs, pages, chapters and so on. In addition to that, the readability can be further enhanced by using different styles to display the letters, e.g., bold, italic, underlined, different fonts and font sizes, and so forth.

On top of these elementary processes, collaborative business processes, including several documents and/or other processes, can be defined. In addition, decisions and conditional flows can be defined. These processes can point directly to a certain textregion, to one or a flow of elementary processes. Form fields, realized by access rights mechanisms, can be addressed within this approach, too. Conditions can be related to a certain textregion and, therefore, be automatically or manually decided. Within these collaborative business processes, the same rules apply as within the elementary processes: everything is collaborative, and can always be changed. Static process definitions can also be realized, based on rights settings.

When working together on a text document, other features have proven to be very useful too, such as having a possibility to add comments to a certain section in the text, to limit the read-write access on text, or to specify tasks that someone has to do with a certain part of the text. All of these applications depend on the fact that one can define a number of consequent characters as an entity or element in the text and can link such an element with the data defining its properties. Such a TextBlockElement could then define a logical block of the text (line, paragraph, chapter or book) or contain any data assigned to that section of text, as for example a comment or security information on it. In this way, a text document can be structured in multiple dimensions.

2.1 Definitions To use the following terminology: Whenever the term ‘text document’ is used here, it refers to the digital representation of a text, either in memory or, on storage. A ‘TextBlockElement’ is a logical entity that represents a section of a text document between a start and an end point in a document. Both, the start and the end point of such a TextBlockElement will be called ‘borders’ of a TextBlockElement. An arbitrary number of visible or invisible characters, paragraph and page properties together define a ‘process element’ with a process element name. Such a process can be applied to a TextBlockElement. One or more processes together build a so-called ‘business process’ that can be assigned to a text document.

As the process elements of a text is one of the most complicated dimensions of such a structured text, the rest of the paper will mainly be focused on issues concerning the storage and handling of process information in a collaborative database-driven application. All of the conclusions drawn from that can equally be applied to any of the other dimensions (see Fig. 3.)

99

characters which are embedded into the text. As in TeNDaX, the characters are stored as objects that can have multiple properties. It would even be possible to use only one single character object to represent such a start- or end-tag.

Büntzli : Translate this to swiss-german Workflow

BigBoss : Verify this.

Either way, there are still serious limitations to that technique. The Client and Database need to be equipped with mechanisms to efficiently insert, find, edit and delete the tags. Furthermore, multidimensional structuring of text becomes very complicated if tags are used, which are inserted into the text.

owner = rw ; group = r ; others = -

Security

What does multidimensional mean?

Notes

Is this comprehensive ?

Template

Layout

the Text

Marked word

Marked word

2.3.3 As an Alternate Data Structur

Marked word

The third option is to create an additional data structure representing the structure(s) of the document and only linking its elements to the chain of character objects.

Sentence

Bold

Italic

Underline

In the TeNDaX Java client the java classes from the package javax.swing.text can be used to implement this functionality (see Fig. 4.). The HTMLDocument (javax.swing.text.html.HTMLDocument) stores the text internally in an array of characters, and the SGML - Tree that represents the layout of the HTML document which is being stored as a tree consisting of BlockElements and RunElements. Each instance of BlockElement represents a subsection of the text which can in turn be divided into subsections. The leaf of such a branch is then represented by a RunElement which has a pointer to the beginning and to the end of the section in the text.

Normal

This is an Example of multidimensional structuring of text.

Figure 3. Example for multidimensional structuring of text.

2.3 Storing of TextBlockElements in TeNDaX

RootElement

Instances of the class BlockElement

Instances of the class RunElement

HEAD

data

parent

2.3.1 As attributes of Each Character

root children

children HTML

data

parent

When every character is stored as a character object, the most "simple" way of storing process information on text might appear to be storing it as additional attributes on every character. This sounds very straight forward but brings considerable disadvantages with it. First, there's a serious performance issue, both when it comes to the used memory and to necessary operations on changes. The space issue can be solved by using pointers to additional objects storing all the process data for one or more sections of identically formatted text.

Character Array

TITLE parent children

Instances of the class StickyPosition

In TeNDaX no text files are used to represent the text, but on the server side a chain of CChar objects is stored in the database, and on the client side there is an array of character objects. The reasons why this structure is the best choice and offers a high level of performance are described in [2,3]. To add structuring information like the SGML-Structure of an HTML document to a file stored in TeNDaX, many different methods are available. In the following section some of these are presented and discussed.

META parent children

children

data

data BODY

P

parent

parent

parent

startPosition

children

children

endPosition

data

data

data

P

parent

parent

startPosition

children

endPosition

The tree structure displayed here represents a simple HTMLDocument with some Header information (Title & Meta) and three paragraphs (P)

However that still leaves us with the transactional performance issue. For every change in the process, each of the concerned character objects has to be altered; in the worst case scenario, this would mean that if someone wanted to change the font size of an entire document, then every single character of the document would first have to be altered, both in the client and in the database.

data

data

P

parent

parent

startPosition

children

endPosition

data

data

Figure 4. SGML tree structure in Java. On the database side there is no need to follow the suggestions made by the Java implementation, which is why a simpler but similarly efficient implementation is possible. The question which we had to ask ourselves was: is it really necessary to store the required information in the form of a tree structure, or would a collection of TextBlockElement objects be sufficient? It turned out that a non-hierarchically ordered collection of TextBlockElements on the database side is sufficient for reconstructing the complete tree structure on the client side, as long as certain precautions are taken when synchronizing the client and database.

2.3.2 As Tags of One or Multiple Characters As shown above, defining structural information on every single character is far too expensive. To decrease these costs the text could be split up into sections and the process information could be assigned to that section instead of to every single character inside the section. Such sections are also used in HTML, XML or any other SGML, and are defined with so-called tags. The idea is to mark the beginning and the end of a section with a tag. In HTML and XML this is done with a series of predefined

100

accordingly to the first character object appearing after the end of the TextBlockElement. A simple example is shown in Fig. 5.

In the following section of this paper, the newly constructed data structure on the database side will be explained, together with its advantages and disadvantages.

With this data structure it is not only possible to structure a text in one dimension, but rather in multiple dimensions, merely by using a different value for the BlockType attribute in the TextBlockElements in the database and a separate RootElement for the tree structure in the Java client.

3. EVALUATION Corresponding to the RunElements in Java, CTextBlockElements in the database represent a selection of text and contain data that applies to that section. To keep the position and the size of such a section efficiently up-to-date and synchronous with the clients, the start and end borders of the section must somehow be marked in the text. In Java, this is accomplished with instances of the class StickyPosition. A StickyPosition represents the offset of a character in the text and moves together with the character whenever text is inserted or deleted before the StickyPosition. This is done by increasing and decreasing a counter every time text is inserted, depending on the position of the insertion. In the database, with potentially thousands of positions in thousands of documents, this solution would not be efficient enough. A far more efficient way is to add a pointer from the character object after the desired position of the border to the TextBlockElement that starts or ends there. When text is then inserted or deleted before, inside or after the section, the borders are still always before the same character. It’s only when deleting the character which actually links the pointer to a border, that care must be taken that the pointer is moved to the next character on the right.

3.1 Loading and Synchronization As stated earlier, it is not necessary to store the complete SGML tree in the database in order to restore it in or to synchronize it with the clients. As line breaks are already embedded into the chain of character objects in the database, the system doesn't have to take care of splitting other TextBlockElements when a line break is inserted into the text. All other changes in the TextBlockElement tree of the client are directly coupled to the business process actions taken by the user.

3.1.1 Document When a document is loaded from the database, first the complete set of characters, including all the line breaks, is loaded into the client. Then all the TextBlockElements of the document are loaded, and depending on the type of TextBlockElement used, an action is taken. For process TextBlockElements this action would be to apply the properties defined in the TextBlockElement object to the section of text it represents. Since all the TextBlockElements have a unique object identifier and since it is always true that a TextBlockElement A, with an identifier higher than TextBlockElement B, is younger than TextBlockElement A, the TextBlockElements of a document can be loaded in a chronological order. This again makes it possible for the Java class that manages the tree structure (javax.swing.text.DefaultStyledDocument.ElementBuffer) in the client to reconstruct the tree, so that it then looks identical to any other instance in any other client that currently has the same document open.

This now enables the definition of sections of text which are unaffected by insert or delete actions. However if one would like to be able to have multiple sections start at the same position (for example, the sections "book 1", "chapter 1" and "paragraph 1" start at the same positions), another data structure is needed.

Instances of the class CChar

oid 7

oid

T

null

E

oid 12

oid

N

18

D

3.1.2 Propagating Changes

Instances of the class CTextBlockElement

Oid = 32

Oid = 455

BlockType = layout

BlockType = layout

BlockDataType = style

BlockDataType = style

BlockDataValue = Title 1

BlockDataValue = Title 2

StartBorder = 7

StartBorder = 12

EndBorder = 12

EndBorder = 18

...

...

Whenever a user now initiates a change in the clients TextBlockElement tree, only the action that initialized this change has to be stored and propagated accordingly to the database and to the other clients. The insertion or deletion of one or more characters in the client does not affect the TextBlockElement structure, neither in the client nor in the database. The only action that has to be taken when deleting a character object from the database, is to check whether or not it carries a pointer to a virtual TextBlockElementBorder A. If this is the case, the pointer to A has to be moved to the next character object on the right that is not being deleted. If this character object already carries a pointer to a virtual TextBlockElementBorder B, the pointer to A can be dismissed and all references to A within the TextBlockElements of this document have to be replaced with references to B.

Figure 5. TextBlockElements on virtual borders. Instead of having pointers which point directly from the character object to the TextBlockElement object, TextBlockElementBorder objects can be used as an intermediate to implement this 1:n relationship. To simplify things even more, these TextBlockElementBorders don't even need instantiated objects, but only virtual borders represented by a unique identifier. The first character object inside a TextBlockElement has a pointer to such a virtual TextBlockElementBorder, and the TextBlockElement object has as it’s start attribute a pointer to the same virtual TextBlockElementBorder. The same applies

Whenever the function is being called to locally create a TextBlockElement in the client, either the TextBlockElements OID is already known, which means that the same Element already exists on the database, or its OID is not yet known, which means that the action creating the TextBlockElement has been initiated in the local client and that the new element has to be

101

Splitting up the information contained in a TextBlockElement into three parts, makes it possible to structure a document in multiple dimensions, to assign simple data type - value pairs to a TextBlock or even to make references to complex database objects, as, for example, styles from a style sheet, simple tasks or complete workflows.

created in the database as well. The creation of the new TextBlockElement in the database will then be propagated to all but the initiating client. When the TextBlockElement has been created on the database, the returned OID from the database is assigned to the Element in the client. If the OID for the TextBlockElement to be created is already given, the Element has already been created in the database and the creation of the Element in the client is due to a propagation action from the database or from another client.

To speed up the searches for CTextBlockElements with a reference to a given virtual border, a two dimensional index is maintained on CTextBlockElement.FileId and CTextBlockElement.startBorder, and another one on CTextBlockElement.FileId and CTextBlockElement.endBorder. These indices are guaranteed to have almost linear performance no matter how many documents are stored in the database.

If a TextBlockElement with the specified OID already exists locally in the client, this means that an already existing Element has been altered in the database and therefore must also be altered in the client. To delete a TextBlockElement, the initiating client only has to call the according function in the database. If the deletion is successful, it is propagated to all clients whereupon they also locally delete the TextBlockElement.

3.3 Collaboration Conflicts Since TeNDaX was built to support multiple users editing the same text document simultaneously, it has to be possible not only to insert and delete characters, but also to define TextBlockElements at the same time. To define a TextBlockElement, a reference to the start and to the end of the TextBlock as well as the TextBlockElement data have to be available. As the data of a TextBlockElement is created in one client only and cannot be accessed by any other, no collaboration conflicts can be expected here. However in order to be able to create a TextBlockElement on the database and then propagate it to the clients, the references to the start and to the end of the TextBlockElement have to remain valid until the TextBlockElements creation has been completed.

3.2 Database

CFile

oid

oid

startBorderOid

StyleName

WorkflowDescr.

DefaultStyleSheet

endBorderOid

StyleSheetName

owner

….

blockType

FontName

...

blockDataType

FontSize

blockDataValue

Bold

fileId

...

CTextBlockElement

oid

...

If, for example, client A tries to create a TextBlockElement "E" starting at character object "2e49" and ending at character object "6a02", and, at exactly the same time client B deletes the character object "2e49" from its local character array and from the database, then by the time the TextBlockElement "E" should be created on the database, one of its borders no longer exists in the database, as it has been deleted just previously. As a consequence, the TextBlockElement cannot be created and the initiating user will receive an error message asking him/her to try again.

CTextBlockElement

oid : 71

oid : 76 CStyle

sBOid : 12

SN : Title 1

bT: layout

oid : 234

eBOid : 22

WD : Sign this!

bT : CWorkflow

SSN : Classic1

bDT : CStyle

O : theBoss

bDT : oid

...

bDV : 234

FN : Arial

bDV : Title 1

sBOid : 12

CWorkflow

oid : 1584

eBOid : 19

Example instances of the classes

CChar nextCChar

CWorkflow

oid

previousCChar

CStyle

oid

characterValue

CTextBlockElement

virtualBorderOid

Class definitions

In the following section of the paper, we describe the used data structure that implements the structures of a document on the database side, and later we move on to discuss the algorithms.

FS : 22

FID : 11

FID : 11

B : true

This is one of three possible collaboration conflicts. The start character object or the end character object, or even both the start and the end character object of the TextBlockElement have been deleted. Everything else that is initiated by two or more different users affecting the same area in a text document does not really represent a technical conflict, as things down in the database and thus also in the clients happen sequentially, but probably just too fast for a user to realize the time shift between the actions.

... CFile FID : 11 SSN : Classic1

CChars

….

oid 12

T

oid ...

null

E

oid ...

null

N

oid ...

19

D

oid ...

null

A

oid ...

22

X

...

Figure 6. Database schema and samples.

4. QUALITY DOCUMENTATION

To define a TextBlockElement in a document, a pointer to a virtual border has to be set on the first CChar inside and the first CChar after the TextBlock. Pointers to the same virtual border then have to be set in the new CTextBlockElement. Depending on the type of TextBlockElement, the data for the TextBlock must then be set accordingly. In Fig. 6, the example of a TextBlockElement is shown, that defines that the letters "TEN" have the style "Title 1", assigned from the style sheet with the name "Classic1", and a second TextBlockElement defines that the letters "TENDA" have the workflow task assigned to them that the user "theBoss" should complete the action "Sign this!".

Dynamic collaborative business processes that exploit database capabilities enable more effective and more qualitative documentation [8]. In the project MOTION [6,7], we have investigated several processes within a large telecommunications company: software configuration management, software release management, and conducting peer- review meetings for software designs. In the following, we briefly focus on the design review process and show its characteristics when realized as a dynamic collaborative business process. Among the different instances of design reviews across product development, we distilled common best practices in performing the process in a multi-site dimension.

102

database system working with the underlying TeNDaX architecture. This architecture enables different roles to collaboratively edit documents in a structured, reliable and realtime cooperation environment. Business cases such as the one described can be empowered by such a database-driven text document technology that enables a flexible and dynamically changeable definition of processes for every kind of role. The scenarios taken from our MOTION project have shown that quality documents can be produced by allowing synchronous and asynchronous collaboration on business-critical documents.

A design review process in the telecommunications company is defined in a separate handbook for mobile phone software development, its follows the SEI Software Process Definition Guide and uses the SPICE process model defined by ISO. The particular instance of a peer (design) review in that company is conducted when a work product has been created and checked to be ready for review. The design review team consists of three to six participants (usually from the same development team) each having one or more roles in the design review. The work product may be distributed to the reviewers in advance for their individual checking prior the actual meeting. During the (virtual) meeting the author(s) of the document present(s) the work product, walk(s) through it in detail and reviewers give their comments on defects, suggested changes and improvements. These findings are recorded and the work product is improved (by revision or refinement) by the responsible author(s) after the meeting. The reworked artefact is verified again. Measures and statistics are collected and stored for analyzing the review process.

Further steps will include an integration with the MOTION peerto-peer service platform that would work upon the proposed architecture and especially exploit loosely coupled and ad-hoc teams. Additionally, more case studies will be carried out to strengthen our results and fine-tune our technology.

REFERENCES

Given the above activities and roles for the design review process taken from the project MOTION, we elicited that several services can be supported well by the above presented database-based dynamic and collaborative editor: •

synchronous work on a (design) document enabling multiuser, multi-site real-time role-based access to the particular documents



asynchronous work on a (design) document allowing exact tracing of all kinds of changes for loosely coupled teams including dislocated experts from any branch of a company



seamless integration between collaborative working environmnents such as the one presented and synchronous communication means such as NetMeeting.

As a result, our technology allows effective ways of coordination between teams or team members for document collaboration. Further, the above real-world scenario showed the following aspects rather clearly: Besides the structured and systematic management of documents, business processes such as the collaborative working on a specification or documentation of a design including a well-structured design review phase can be supported in a highly efficient way. Roles such as reviewers, inspectors, editors, etc. and processes or sub processes such as collaboratively working on the document or reviewing and adding comments to parts of the document can be easily defined, access control mechanisms can be customized to the individual needs. All the basic mechanisms such as distribution of updates of document (parts) or process information is handled by the underlying database including synchronization, distribution, and systematic and controlled access (including role-based visibility of text). As a consequence, the collaborative and dynamic business process instantiation and customization can focus on the business aspects and fully rely on effective databased technology of TenDaX.

[1]

S. Abiteboul, R. Agrawal, P. Bernstein, M. Carey, S. Ceri, B. Croft, D. DeWitt, M. Franklin, H. G. Molina, D. Gawlick, J. Gray, L. Haas, A. Halevy, J. Hellerstein, Y. Ioannidis, M. Kersten, M. Pazzani, M. Lesk, D. Maier, J. Naughton, H. Schek, T. Sellis, A. Silberschatz, M. Stonebraker, R. Snodgrass, J. Ullman, G. Weikum, Widom, and J. Stan Zdonik, "The Lowell Database Research Self Assessment," Massachusetts 2003.

[2]

T. B. Hodel and K. R. Dittrich, "A collaborative, real-time insert transaction for a native text database system," presented at Information Resources Management Association (IRMA 2004), New Orleans (USA), 2004.

[3]

T. B. Hodel and K. R. Dittrich, "A native text database: What for?," presented at Information Resources Management Association (IRMA 2004), New Orleans (USA), 2004.

[4]

T. B. Hodel and K. R. Dittrich, "Concept and prototype of a collaborative business process environment for document processing," Data & Knowledge Engineering, vol. Special Issue: Collaborative Business Process Technologies, 2004.

[5]

T. B. Hodel, M. Dubacher, and K. R. Dittrich, "Using Database Management Systems for Collaborative Text Editing," presented at European Conference of Computer-supported Cooperative Work (ECSCW CEW 2003), Helsinki (Finnland), 2003.

[6]

Engin Kirda and Harald Gall. A Service Architecture for Mobile Teamwork. International Journal of Software Engineering and Knowledge Engineering, Vol. 13, No. 4, pp. 447-467, World Scientific Publishing Company, August, 2003.

[7]

Schahram Dustdar and Harald Gall. Architectural concerns in distributed and mobile collaborative systems. Journal of Systems Architecture, 49 (2003), pp. 457-473, Elsevier B.V., 2003.

[8]

Aniello Cimitile, Andrea De Lucia, and Harald Gall (eds.). Cooperative Methods and Tools for Distributed Software Processes. Franco Angeli Publishing, ISBN 88-464-4774-3, 2003.

[9]

C.A. Ellis and G. J. Nutt, “Office information systems and computer science,” Comput. Surv., vol. 12, no. 1, pp. 27-60, 1980.

[10]

C.A. Ellis, S.J.Gibbs, G.L. Rein “Groupware: some issues and experiences,” Communications of the ACM, 34, 1, 39-58, 1991.

[11] J. Puustjärvi, H. Laine “Supporting cooperative inter-organizational business transactions,” in Proc. DEXA 2001, Computer Science Lecture Notes, Springer Verlag, pp. 836-845, 2001.

5. CONCLUSION Business processes that can be changed dynamically and are collaborative in terms of parallel work on documents and work on documents in parallel have become business citical. In this paper, we have proposed such a dynamic and collaborative business process support environment that represents all documents in a

[12] C. Bussler “Enterprise-wide Workflow Manage-ment,” IEEE Concurrency, 7, 3, 32-43, 1999.

103