Active Documents and their Applicability in Distributed Environments Martin Fredriksson University College of Karlskrona/Ronneby Department of Computer Science and Business Administration S-372 38 Ronneby email: [email protected] $EVWUDFW$FWLYH'RFXPHQWVLVDWHFKQLTXHIRUDXWRPDWLQJWKHKDQGOLQJDQGFRQWURORIGRFXPHQWVE\ PDNLQJWKHPDFRPELQDWLRQRIVHUYLFHSURYLGHUV PRELOHDJHQWV DQGUHVRXUFHV FRPSRXQGGRFX PHQWV LQWKHIRUPRIDXWRQRPRXVDJHQWV7KHPDLQIRFXVRIWKLVVROXWLRQLVWRSURYLGHDQHQFDSVXOD WLRQ RI GRFXPHQWV LQFOXGLQJ WKHLU GDWD VWUXFWXUHV DQG UHODWHG IXQFWLRQDOLW\ EXW DOVR WR HQDEOH GRFXPHQWV WR UHIOHFW XSRQ WKHPVHOYHV LQ UHVSHFW RI WKHLU FRPSXWDWLRQDO HQYLURQPHQW DQG WDNH DFWLRQVDFFRUGLQJO\ .H\ZRUGV$FWLYH'RFXPHQWV6HUYLFH2ULHQWHG$UFKLWHFWXUHV&RPSRXQG'RFXPHQWVDQG0RELOH 6RIWZDUH$JHQWV &RQWHQWV 1 Introduction 1 1.1 Problem Description 1 The Evolution of Digital Documents 1 Limited Architectures 3 Limited Component Property Support 3 Fundamental Domain Issues 5 1.2 Approach to Problem Solution 6 Software Agents 6 The Thesis 7 1.3 Outline of the Thesis 7 1.4 Acknowledgements 8 2 Supporting Concepts and Technologies 9 2.1 Abstraction and Representation 9 Data Abstraction 10 Data Representation 11 2.2 Components, Documents, and Compound Documents 12 Components 12 Documents 13 Compound Documents 13 2.3 Software Agents 15 Active Objects 16 Mobile Objects 16 Conceptual Adherence 17 Communication Language 17 Behavior and Knowledge 18 Service-Oriented Architectures 18 2.4 Discussion 19 Implications of Abstractions 19 Requirements Implied by the Abstraction 20 3 Active Documents 22 3.1 Service-Oriented Architectures 22 Facilitators 22 Handlers 23 Services 24 3.2 Software Agents and Related Issues 25 Footprint 25 Mobility 25 Activation and Scheduling 26 Communication and Cooperation 26 3.3 Active Documents 27 Type Hierarchy 27 Entity Associations 28 3.4 Active Document Handling 29 Creating an Active Document 29 Storing an Active Document 29 Accessing an Active Document 29 &RQWHQWV LL 3.5 Discussion 30 4 Delving Into Active Documents 31 4.1 Business Workflow Processes 31 Case Study 31 4.2 A Different Point of View 33 Decision Styles 34 Markup Languages and Context 34 Combining Information Structure, Context, and Active Documents 35 4.3 Personal Assistants 37 Control Agents 37 4.4 Discussion 37 5 Summary and Conclusions 39 5.1 The Problem 39 5.2 Active Documents and Applicability in Distributed Environments 40 Conformance to the Problem Domain 40 Implications of the Active Document Approach 40 Applicability in Distributed Environments 41 5.3 Future Work 41 Appendix A - Architecture Design 42 References 43 ,QWURGXFWLRQ For centuries, documents have served as a way to record and share events of the past and present. Therefore, we can say that documents are a mechanism of knowledge sharing. In general, a docu- ment seems mostly concerned with the layout of text and/or images to be printed on paper of appro- priate quality. This view of a document is complemented with the notion of a digital document, and is more focused on the way information is most appropriately structured and handled for updating and access. The main difference between these two concepts is the new ways of information interac- tion and knowledge sharing that digital documents offer us. Thus, an area of applicability for digital documents is business workflow processes [4][6]. Nowadays documents have become vitally important components in workflow processes. Every organization with some self respect is trying to get in control of how digital information (mostly doc- uments of different types) in the organization is passed from one person to another and interacted with. One of the main concerns, when it comes to workflow processes, is therefore how we repre- sent, interact, and share information participating in the processes. In the general case, we tend to conceptualize information as computerized versions of physical documents. However, such an approach has one major drawback: workflow processes by nature involve activity, and computerized documents of today do not. In order to achieve the necessary activity in the workflow processes we have to make use of applications as a complement to the inactive data structures. The problem with this approach is threefold: it is difficult to combine the services offered by different applications with each other, most applications make use of non-compatible native storage formats, and it is difficult to model processes and activity using a static set of functionality offered by the applications. In combi- nation with each other, these three problems put us in a somewhat awkward position: we cannot cre- ate and/or control our workflow processes in a satisfying manner, due to the basic architecture we have chosen to model the relationship between activity (functionality) and information (document data). The questions are: (1) what are the fundamental issues of interest for both the document domain and business workflow area of research? (2) can we find an architecture/model that addresses these fun- damental issues in a more appropriate manner than current ones? 3UREOHP'HVFULSWLRQ In the following section a number of issues will be discussed, namely, an identification of where we are standing today concerning digital documents (digital document evolution), and the identification of problem issues related to digital documents with focus on business workflow processes and the modeling of activity. 7KH(YROXWLRQRI'LJLWDO'RFXPHQWVIn order to show what a digital document today really is, a brief outline of document evolution and historical background will be given below: • 3KDVH6XSSRUWIRU0XOWLSOH'RFXPHQW'DWD7\SHV- The main difference between the docu- ments used in the early days of computerized business and the ones we use today is that they only contained one type of data, and this data was stored according to some native application’s spe- cific storage format. Furthermore, the document applications could not handle any other data structures than their own native storage formats. Therefore, in order to create a document of mul- tiple types of data, the user had to generate output from a set of applications, and then integrate these outputs by hand. In other words, it was a so called cut and paste approach. Then, if a docu- 3UREOHP'HVFULSWLRQ ment contained any errors, the user would have to start the process all over again. Obviously, the approach of creating documents by hand was very cumbersome. However, a new approach in document handling was developed, the tool-centric integration approach. The main reason for developers to take the next step in document evolution (tool-centric integration), was a direct result of computer environments where document applications were running and documents were stored. Meaning, computer systems were developed that could support a network of output from multiple applications. This enabled the users to create documents containing multiple data struc- tures of different media types. However, the applications were only able to change specific parts of a document that were represented in the native format of that application. All other structures contained in the applications’ documents still had to be changed in their corresponding applica- tion, and reimported. As applications started to enable users to import different types of data structures, the applications became more complex. • 3KDVH6XSSRUWIRU$SSOLFDWLRQ,QGHSHQGHQW3DUW+DQGOHUV- There have been attempts to solve the problem of complexity versus functionality, by extracting the interaction with document parts (data structures of different types) from the applications, and putting functionality into separate objects that all applications can share. This approach is often denoted as a so called compound document approach1. By applying such an approach the applications can support documents con- taining a multitude of data-types, without increasing the complexity of the specific application, and still offer the users all the functionality they might want. The compound document approach is characterized by the extensive use of specialized components2, encapsulating the various data structures, that form the structure of a compound document. • 3KDVH6XSSRUWIRU6LWXDWHG$FWLRQV- Since documents nowadays are becoming more and more important as means for knowledge sharing and information interaction it is important that the documents support situated actions. The reason to this is the fact that it enables the documents to perform different actions depending on the current situation at hand, no matter if the action is related to visualization or something completely different. This requirement is for example of major interest in compound document systems, focusing on visualization aspects of document data. In such systems each document part is responsible for its own visualization, instead of rely- ing on external applications. Depending on part type and current situation, different visualizations can be applied by a document part. This feature is also of utmost importance in workflow pro- cesses, since it would enable us to get in control of the information flow processes and possibly also to automate parts of them. It is obvious that a digital document today no longer conforms to the definition and properties of a physical document. During their evolution, digital documents has adopted new technological advancements, but maybe most notably, new requirements have been imposed on the documents by the systems that handle them and by their users and new areas