DOCUMENT MANAGEMENT API FOR MANAGING SOFTWARE ...
174
DOCUMENT MANAGEMENT API FOR MANAGING SOFTWARE ARTIFACTS WONG CHI CHONG (WGCY 01004) FACULTY OF COMPUTER SCIENCE AND INFORMATION TECHNOLOGY UNIVERSITY OF MALAYA KUALA LUMPUR 2006
-
Upload
khangminh22 -
Category
Documents
-
view
3 -
download
0
Transcript of DOCUMENT MANAGEMENT API FOR MANAGING SOFTWARE ...
DOCUMENT MANAGEMENT API FOR MANAGING
SOFTWARE ARTIFACTS
WONG CHI CHONG
(WGCY 01004)
FACULTY OF COMPUTER SCIENCE AND
INFORMATION TECHNOLOGY
UNIVERSITY OF MALAYA KUALA LUMPUR
2006
ii
DOCUMENT MANAGEMENT API FOR MANAGING
SOFTWARE ARTIFACTS
WONG CHI CHONG
(WGCY 01004)
DISSERTATION SUBMITTED IN FULFILLMENT OF THE REQUIREMENTS
FOR THE DEGREE OF MASTER OF SOFTWARE ENGINEERING
FACULTY OF COMPUTER SCIENCE AND
INFORMATION TECHNOLOGY
UNIVERSITY OF MALAYA KUALA LUMPUR
2006
iii
ABSTRACT
This project is about the development of a Document Management Application
Programming Interface (DMAPI) interface for dealing with capturing and preserving
software artifacts using a document-oriented approach. The proposed software development
life cycle is based on object-oriented methodology using Unified Modelling Language (UML).
This project proposes a basic framework for preserving formal knowledge from knowledge
workers. It is essential to implement a document repository in such a way that is accessible
via any web-based infrastructure and providing a more convenience way for document
accessing. Moreover, the details of an artifact stored are being preserved as documents in its
native formats. A document handler is proposed to act like a container or hierarchy of
various versions of modification and annotation that attached to the document. These
documents can be accessed by referring to the root reference of the document tree via path.
The documents ontology, file extensions or any other alternative difference that are generally
unpopular will be implemented via the proposed Application Programming Interfaces
(APIs), which will be able to differentiate the likely fine components of the document types.
Finally, yet importantly, with this proposed DMAPI in place, software developers can further
enhance and extend related business domains using this extensible framework in the near
future.
iv
DECLARATION
I certify that this dissertation submitted for the degree of Master of Software Engineering is
the result of my own research, except where otherwise acknowledged, and that this
dissertation or any part of it has not been submitted in support of an application for higher
degree or qualification to any other university or institution.
________________
Wong Chi Chong
v
ACKNOWLEDGMENTS
I wish to thank my parents and Katarina for their moral support and love. Moreover, I would
also like to extend my greatest appreciation and special thanks to my supervisor, Associate
Professor Dr. Lee Sai Peck, who has continually given me guidance and constructive
suggestions during the progression of my dissertation. Finally, I would like to thank all my
friends and colleagues for their support.
vi
TABLE OF CONTENTS
Chapter 1 Introduction ...................................................................................................................... 13 1.1 Problem Statement ................................................................................................................ 14 1.2 Objectives ............................................................................................................................... 17 1.3 Dissertation Organisation ..................................................................................................... 18
Chapter 2 Literature Review .............................................................................................................. 20 2.1 Document Imaging and Document Management (DMS) ................................................ 20 2.2 Source Version Control (SVC) ............................................................................................. 22 2.3 Content Management System (CMS) .................................................................................. 26 2.4 Portal ....................................................................................................................................... 29 2.5 Application Products Reviews.............................................................................................. 31
2.5.1 System Requirements................................................................................................... 33 2.5.2 Security .......................................................................................................................... 36
2.5.3 Product Supports ......................................................................................................... 40 2.5.4 Ease of use .................................................................................................................... 43 2.5.5 Performance ................................................................................................................. 44 2.5.6 Management ................................................................................................................. 46 2.5.7 Interoperability ............................................................................................................. 49 2.5.8 Flexibility ....................................................................................................................... 50 2.5.9 Built-In Components ................................................................................................... 51
2.6 System Limitation .................................................................................................................. 53
2.7 Conclusions ............................................................................................................................ 53 Chapter 3 Methodology ..................................................................................................................... 56
3.1 Quantitative Analysis ............................................................................................................. 56 3.2 Layered Architecture ............................................................................................................. 59
3.2.1 Application Systems ..................................................................................................... 61 3.2.2 Business Specific Layer ................................................................................................ 61 3.2.3 Middleware ................................................................................................................... 62 3.2.4 System Software ........................................................................................................... 62
3.3 XML Persistence Framework ............................................................................................... 62 3.4 Object-Oriented Software Engineering .............................................................................. 63 3.5 Object Analysis ...................................................................................................................... 64 3.6 Object Models ........................................................................................................................ 66 3.7 Object-oriented Programming (OOP) ................................................................................ 67 3.8 Summary ................................................................................................................................. 69
Chapter 4 Domain Analysis and Design .......................................................................................... 71 4.1 System Layered Architecture ................................................................................................ 71
4.2 Domain Analysis and Design for DMAPI ......................................................................... 74 4.3 DMAPI Use Case Model ...................................................................................................... 76
4.3.1 DMAPI Administrator’s Use Case Model ................................................................ 77 4.3.2 DMAPI User’s Use Case Model ................................................................................ 79
4.4 DMAPI Analysis Model ........................................................................................................ 80 4.4.1 Login Collaboration Diagram ..................................................................................... 82 4.4.2 Check Permission Base Facade Collaboration Diagram ......................................... 84 4.4.3 Check In/Out Files Collaboration Diagram ............................................................. 85
4.4.4 Retrieve Previous Version Collaboration Diagram .................................................. 86 4.4.5 Rollback Previous Version Collaboration Diagram ................................................. 87 4.4.6 Define Access Control List (ACL) Collaboration Diagram .................................... 88
vii
4.5 DMAPI Design Model .......................................................................................................... 89 4.5.1 Login Sequence Diagram ............................................................................................ 90 4.5.2 Check Permission Base Facade Sequence Diagram ................................................. 91 4.5.3 Check In/Out Files Sequence Diagram .................................................................... 92
4.6 DMAPI Class Diagrams ....................................................................................................... 94 4.7 DMAPI Security Design ....................................................................................................... 94
4.8 File System Design................................................................................................................. 98 4.9 Sample of Component Facade Packages for Extender Applications ............................ 100 4.10 Conclusion .......................................................................................................................... 103
Chapter 5 System Implementation and Testing ............................................................................ 105 5.1 Application Development Environment .......................................................................... 105 5.2 Layered Architecture Implementation............................................................................... 106 5.3 The Web Service Interface.................................................................................................. 110
5.3.1 Login Implementation ............................................................................................... 111
5.3.2 Check In Files Implementation ................................................................................ 114 5.3.3 Check Out Files Implementation ............................................................................. 116 5.3.4 DMAPI Security Implementation ............................................................................ 118
5.4 Using the XML Persistence Framework ........................................................................... 121 5.5 Document Storage Strategies.............................................................................................. 123 5.6 Client Graphical User Interface (GUI).............................................................................. 124
5.6.1 Items Listing ............................................................................................................... 125 5.6.2 Define Work Folder .................................................................................................. 125
5.6.3 Check Out Items ........................................................................................................ 126 5.6.4 Check In Items ........................................................................................................... 127 5.6.5 Version Control for Document................................................................................ 129 5.6.6 Version Control for DMAPI .................................................................................... 129 5.6.7 Document Information and Security Interface ...................................................... 129 5.6.8 User Manager.............................................................................................................. 130
5.7 DMAPI Testing Strategies .................................................................................................. 132 5.8 Features Comparison........................................................................................................... 135
5.9 System Limitation ................................................................................................................ 139 5.10 Conclusion .......................................................................................................................... 140
Chapter 6 conclusion ........................................................................................................................ 142 6.1 Significance of Proposed Research .................................................................................... 142 6.2 Limitations ............................................................................................................................ 146 6.3 Future Work ......................................................................................................................... 147 6.4 Conclusion ............................................................................................................................ 148 Appendix A – DMS Applications Reviewed .......................................................................... 149
Appendix B – XML Serialization Classes ................................................................................ 153 Appendix C – WSDL Document for File Manager ............................................................... 155 Appendix D – Starting Guide ................................................................................................... 162 Appendix E – Sample Application........................................................................................... 165
SUPPLEMENT ................................................................................................................................ 173
viii
LIST OF FIGURES
Figure 1-1 Document Management Classes .................................................................................... 16 Figure 2-1 Source Version Control Collaboration Process ............................................................ 24 Figure 2-2 Relationship between Portals and CMS (Browning P., 2003) ..................................... 28 Figure 2-3 Portal Vendor (Kounadis T., 2000)................................................................................ 31
Figure 2-4 Application/Web Server Review .................................................................................... 34 Figure 2-5 Databases Review............................................................................................................. 34 Figure 2-6 Operating Systems Reviews ............................................................................................ 35 Figure 2-7 Audit Trail Reviews .......................................................................................................... 36 Figure 2-8 Granular Privileges Reviews ........................................................................................... 36 Figure 2-9 Kerberos Authentication Reviews.................................................................................. 38 Figure 2-10 LDAP Authentication Reviews .................................................................................... 38 Figure 2-11 NTLM Authentication Reviews ................................................................................... 38
Figure 2-12 SMB Authentication Reviews ....................................................................................... 38 Figure 2-13 Session Management Reviews ...................................................................................... 39 Figure 2-14 SSL Compatible Reviews .............................................................................................. 40 Figure 2-15 Online Help Reviews ..................................................................................................... 43 Figure 2-16 Pluggable API Reviews.................................................................................................. 43 Figure 2-17 Drag-n-drop Content Reviews ..................................................................................... 44 Figure 2-18 Undo Reviews ................................................................................................................ 44 Figure 2-19 Page Caching Reviews ................................................................................................... 45
Figure 2-20 Advanced Caching Reviews .......................................................................................... 45 Figure 2-21 Database Replication Reviews ...................................................................................... 46 Figure 2-22 Load Balancing Reviews ................................................................................................ 46 Figure 2-23 Online Administration Reviews ................................................................................... 47 Figure 2-24 Web-based Style/Template Management Reviews .................................................... 47 Figure 2-25 Workflow Engine Reviews ........................................................................................... 48 Figure 2-26 Content Syndication Reviews ....................................................................................... 50 Figure 2-27 FTP Support Reviews .................................................................................................... 50
Figure 2-28 WebDAV Support Reviews .......................................................................................... 50 Figure 2-29 XHTML Compliant Reviews ....................................................................................... 50 Figure 2-30 Extensible User Profiles Reviews ................................................................................. 51 Figure 2-31 Interface Localization Reviews ..................................................................................... 51 Figure 2-32 Document Management Reviews ................................................................................ 52 Figure 2-33 HTTP Proxy Reviews .................................................................................................... 52 Figure 2-34 Web Services Reviews ................................................................................................... 52 Figure 2-35 Search Engine Reviews.................................................................................................. 52
Figure 3-1 Raw Data in MS Access .................................................................................................. 57 Figure 3-2 SQL Statement for “Operating System” View/Query ................................................ 58 Figure 3-3 A Typical Layered Architecture ...................................................................................... 60 Figure 4-1 Layered Architecture ........................................................................................................ 72 Figure 4-2 DMAPI System Administrator’s Use Case Model ....................................................... 78 Figure 4-3 DMAPI User’s Use Case Model .................................................................................... 80 Figure 4-4 Login Collaboration Diagram ......................................................................................... 84 Figure 4-5 Check Permission Base Facade Collaboration Diagram ............................................. 85
Figure 4-6 Check In/Out Files Collaboration Diagram ................................................................. 86 Figure 4-7 Retrieve Previous Version Collaboration Diagram ...................................................... 87 Figure 4-8 Rollback to Previous Version Collaboration Diagram ................................................ 88
ix
Figure 4-9 Define ACL Collaboration Diagram.............................................................................. 89 Figure 4-10 Login Sequence Diagram .............................................................................................. 91 Figure 4-11 Check Permission Base Facade Sequence Diagram ................................................... 92 Figure 4-12 Check In/Out Files Sequence Diagram ...................................................................... 93 Figure 4-13 Access Control List (ACL) Class Diagram.................................................................. 96 Figure 4-14 Principal Base Class ....................................................................................................... 97
Figure 4-15 File System Object (FSO) Class Diagram ................................................................... 99 Figure 4-16 SCV and Portal Use Case Diagrams .......................................................................... 101 Figure 4-17 Sample of Extender Applications’ Framework ........................................................ 102 Figure 5-1 Application Development Environment..................................................................... 106 Figure 5-2 Core Class Declaration .................................................................................................. 109 Figure 5-3 Referring Figure 4-4 Implementation Highlight ......................................................... 111 Figure 5-4 Login Screen ................................................................................................................... 111 Figure 5-5 Client Logon Code Snippet........................................................................................... 111
Figure 5-6 Referring Figure 4-4 State Explanation ....................................................................... 112 Figure 5-7 Referring Figure 4-11 State Explanation ..................................................................... 112 Figure 5-8 Logon Server Side Code Snippet.................................................................................. 113 Figure 5-9 Session Verification Façade Code Snippet .................................................................. 113 Figure 5-10 Referring Figure 4-5 Implementation Highlight ....................................................... 114 Figure 5-11 Check In Code Snippet ............................................................................................... 115 Figure 5-12 WebStreamer Class Hierarchy .................................................................................... 115 Figure 5-13 Check Out Code Snippet ............................................................................................ 118
Figure 5-14 Add Access Control List Entry Code Snippet .......................................................... 120 Figure 5-15 Remove Access Control List Entry Code Snippet ................................................... 121 Figure 5-16 XML Serialization Sample ........................................................................................... 122 Figure 5-17 XML Serialization Output ......................................................................................... 122 Figure 5-18 Hierarchy Representation of Document Container ................................................. 123 Figure 5-19 Detailed File Listing ..................................................................................................... 125 Figure 5-20 Icons File Listing .......................................................................................................... 125 Figure 5-21 Set Local Folder ........................................................................................................... 126
Figure 5-22 Folder Selection Dialog ............................................................................................... 126 Figure 5-23 Check Out Items .......................................................................................................... 127 Figure 5-24 Document Check Out Status...................................................................................... 127 Figure 5-25 Check In Items ............................................................................................................. 128 Figure 5-26 Document Check In Status ......................................................................................... 128 Figure 5-27 Document Properties .................................................................................................. 130 Figure 5-28 Document Security Properties.................................................................................... 130 Figure 5-29 User Manager – User ................................................................................................... 131
Figure 5-30 User Manager – Role ................................................................................................... 132 Figure 5-31 NUnit Test Script ......................................................................................................... 134 Figure 5-32 NUnit Testing ............................................................................................................... 135 Figure 5-33 Hardware Architecture for Clustering ....................................................................... 139 Figure 6-1 Developer Reference Guide (HTML Format) ........................................................... 143 Figure 6-2 Developer Reference Guide (Compiled HTML Help File) ...................................... 143
x
LIST OF TABLES
Table 2-1 Various Authentications Methods ................................................................................... 37 Table 2-2 Implementation Guide Lines ........................................................................................... 41 Table 2-3 Protocol and Standard Descriptions and Review Percentages ..................................... 49 Table 2-4 Security Elements .............................................................................................................. 54
Table 2-5 Performance Factors ......................................................................................................... 55 Table 3-1 Subset of the Collected Data ............................................................................................ 57 Table 3-2 Result for the Distinctness of Operating Systems ......................................................... 58 Table 3-3 Summarized for the Distinctness of Operating Systems .............................................. 59 Table 5-1 Main Classes Features ..................................................................................................... 107 Table 5-2 Features Comparison ...................................................................................................... 136 Table 6-1 Products & Imperfect Features ..................................................................................... 144
xi
GLOSSARY
ANNOTATIONS – Changes or additions made to a document using sticky notes, a highlighter, or other electronic tools
API – Application Programming Interface
ASCII – American Standard Computer Information Interchange
ASP – Active Server Pages
BITMAP/BITMAPPED – See Raster/Rasterized
BMP – A native file format of Windows for storing images called “bitmaps”
B2B – Business to Business
B2C – Business to Customer
CAD – Computer Aided Design
COM – Component Object Model
C2C – Customer to Customer
DOCUMENT IMAGING – Software is used to store, manage, retrieve and distribute scanned documents quickly and easily
FAT – File Allocation Table
FSO – File System Object
GIF – Graphics Interchange Format
GIS – Geographic Information System
HTTP – HyperText Transfer Protocol
JAAS – Java Authentication and Authorization Service
JPEG – Joint Picture Experts Group (JPEG or JPG)
JSP – Java Server Pages
KM – Knowledge Management
xii
LDAP – Lightweight Directory Access Protocol
NTLM – A challenge/response authentication protocol in Windows NT version 4.0 and earlier.
OIL – Ontology Interface Layer
RASTER/RASTERIZED (RASTER or BITMAP DRAWING) – Method that represents an image with a grid (or “map”) of dots or pixels
SMB – Server Message Block
SQL – Structured Query Language
SOAP – Simple Object Access Protocol
TCP/IP – Transmission Control Protocol/Internet Protocol
TIFF – Tagged Image File Format
WORKFLOW – Series of automated steps that route documents to various users on a multi-user document system
WYSIWYG – What You See Is What You Get
W3C – World Wide Web Consortium
13
CHAPTER 1 INTRODUCTION
A decade ago, as a result of hardware and software innovation, new data intensive
applications emerged, for which traditional software artifacts management (or document
management system, DMS referred in this dissertation), based on the single document
format model, was inadequate. All kind of software artefacts include specification, design,
code, etc which can be store in a single document or multiple composite documents.
Document formats for Word, Lotus123, Excel, databases, CAD or CAM, geographic
information system (GIS) and multimedia system become more and more common
resulting from their impressive market penetration. A repository is crucial in document
management because it is used to store and share software artifacts that can be classified in
different document types. These applications have requirements and characteristics, such
as highly structured and unstructured data, multimedia or multi-files data and non-
standard, application-specific operations that are different from those typical of a
traditional document management system. The first and most important document
management application was used in massive hardcopy to softcopy conversion, typically
for a digital library to reduce the information flooding throughout the physical storage
spaces, and to overcome the inconvenient use of microfilm in certain areas such as medical
imaging.
“A financial services company in the midst of constructing a new building was shocked to
learn that 30 percent of its space would be used to store papers.” (Yockelson, 2000)
This issue influenced thousands of organisations around the world to use hardcopy
oriented document management (electronic paper filing document imaging) every day
14
instead of paper filing systems. The reasons for using a DMS are simple and are listed
below:
• Prevent loss of documents
• Manage documents easily
• Find documents quickly
• Make documents centrally available
• Save storage space by eliminating the need for a physical storage space
On the other hand, organisations began to realize that there was an internal growing need
to organize, rationalize and digitalize documentation such as word files, spreadsheets, and
PowerPoint presentations. This need resulted in the creation of such powerful software
called Document Management Systems (DMS) to manage the whole process.
This project introduces a way of capturing and organizing various software artifacts into a
well-organised and shared repository in order to meet requirements imposed by those
applications. Its purposed design should inherit the benefits of a DMS, source and version
control system (SCV) and contents publishing system. Other growing commercial
application domains are not in the scope of this project. However, an extendable, pluggable
and adaptable interface is being presented in this dissertation to allow further application
extensions development in the near future.
1.1 Problem Statement
At present, there is no perfect document management system that covers every aspect of
all applications or business domains knowledge. Situation happens to be worst if little or
no such standardized API to permit software developers to integrate their needs into the
15
system. Most systems allow loosely integration via configuration. For example, users may
be allowed to configure to open a text document (*.txt) with a specified editor besides
Notepad by default, or to define a new document class with specified permissions.
However, non-proprietary integration is still lacking. For example, there are standards such
as SQL89 and SQL92 to define the necessary Data Definition Language (DDL) and Data
Manipulation Language (DML) to ease the interoperatebility among different database, but
no such standard defined for document management system.
A document management system with web access integration extends its usage to most
remote sites of user or department unit. Thus, a programmable web service (self-contained,
modular, distributed, dynamic applications that can be described, published, located, or
invoked over the network to create products, processes, and supply chains) will allow
customization of the remote sites in no time. For instance, caching certain types of
document locally from the remote repository is easier to be implemented by having the
programmable web.
In order to allow wider share of information and documents, it is wiser to have the most
popular information exchange standard such as XML as the medium to store the
document tags and pass around to the requester for processing. The tags should be easily
read, manipulated and extended to have additional fields of information. This is inline with
the object-oriented terminology where the functions or methods should be attached with
fields of data.
Most software application systems are built upon several underlying subsystems.
16
Document Management
File System RDBMS
Document Imaging and Document Managemet SCV Content Management
Web Portal
Figure 1-1 Document Management Classes
Referring to Figure 1-1, three main popular subtypes of DMS are Source Control and
Versioning (SCV), Document Imaging and Document Management, as well as Content
Management System (CMS), which can be extended into a web portal service. Extensible
object model is the key architecture to patch up the deficiency offered by the majority of
DMS applications.
In addition, all basic DMSs provide a file sharing storage repository either in a database
and/or in flat file system. A value-added document management system is able to
incorporate more business processes and capabilities throughout the document life cycle.
Some general milestones in this life cycle include:
• Workflow process for procurement (Kenneth & Sunil, 1994)
• Document attachment for business communication
• Document annotation and commenting
17
• Document ID or digital signature, notarisation and time-stamping for document
approval and integrity preserving (Baldwin et al, 2001)
Focusing on the value adding flexibility rather than the offered functions increases the
usability of a DMAPI. Nevertheless, DMAPI products offered plug-ins extensions to the
original package resolve this issue partially. Value added service provided by software
developers is the key to improve the situation.
1.2 Objectives
Commercial Document Management products appeared more than a decade ago. Since
then, Document Management was improving significantly from their earliest releases and
many changes have occurred in computer science. For example, the emergence and quick
increase in the use of the Internet and the World Wide Web (WWW) have significantly
changed the way documents are published, shared and served.
In this study, a complete design of the document management will be described. However,
it is good to clarify the following point that the DMAPI framework and its several core
components will be implemented in the proposed prototype in order to be extended by
future commercial applications or business-oriented developers, instead of a particular
implementation for a certain business domain. Besides the proposed prototype
implementation, several objectives and milestones also need to be achieved, they are listed
below:
• To study and analyse the common functionalities and requirements of existing
document management systems. In addition, review the pros and cons of existing
commercial document management system products.
18
• To study core document management systems’ APIs that currently exist as
research prototypes or commercial components.
• To develop a prototype of a document management framework that is persistent
and extensible where it is able to promote future potential expansion of document
management types using web services programming technologies such as
Microsoft .NET technology as the web service client and server. This
implementation of web services can promote cross platform integration among
server-side applications.
1.3 Dissertation Organisation
This dissertation is organised into six main chapters. The first chapter is concerned about
the overall introduction of this dissertation. This chapter describes the common problems
of generic document imaging and document management system, and objectives of the
dissertation.
Chapter 2 covers the literature review of document imaging and document management
systems. This review provides some brief explanation on several commercial document
management systems and the choice of technologies used.
Chapter 3 explains the methodology used in implementing this proposed system. Here, it
covers the systematic and organised methods taken to implement the proposed system
from the start of its software development lifecycle until the end of its development. For
example, these phases include system requirements, system design and analysis,
implementation, testing and reviews, and finally potential future enhancement. This
19
chapter will elaborate how these sequential phases will be carried out conceptually before
proceeding to the next chapter for further implementation.
Chapter 4 is about the analysis and design details of the proposed system. In this chapter, it
describes the proposed application’s analysis and design phases, which will include the
overall analysis process and system architecture design in more detail. Subsequently, it
further defines and models the conceptual results from analysis and design phases into
systematic models using UML diagrams, such as use case diagram, class diagram and
sequence diagrams.
Chapter 5 describes the overall implementation, testing and review of the proposed
prototype. In this chapter, it explains the implementation details via well-defined UML
diagrams, such as sequence diagrams and class diagrams. After the final implementation
phase, the proposed working prototype will be tested and reviewed thoroughly using well-
planned and organised testing processes. The testing procedures will cover the application
performance benchmark, fine-turning result and the APIs usage descriptions.
Lastly, Chapter 6 is the last and concluding chapter of this dissertation. This chapter
discusses the potential future enhancement of the proposed DMAPI framework and the
conclusion remarks of the dissertation research. Besides that, the strengths and limitations
of the proposed DMAPI framework are also discussed.
20
CHAPTER 2 LITERATURE REVIEW
In this chapter, some literature reviews are carried out on document imaging and
document management systems. In the first part, these reviews describe briefly the
different types of document imaging and document management system. Then the reviews
continue to concentrate on the comparison of various commercial document management
applications on the market. Besides reviewing these existing applications, these reviews also
discuss the programming techniques and the server technologies that are used in these
applications.
2.1 Document Imaging and Document Management (DMS)
The conversion of paper documents into (single or multi page) electronic images is referred
to as document imaging (Wigging, 1994, quoted by Roman et al, 2002). However, in the
context of document management, a document is essentially a file, which is electronically
or digitally containing information. A system of document imaging and document
management provides tools for the users to create, manage, control, store, retrieve and
distribute electronic documents with secure repositories and project workspaces. Basically,
the document imaging and document management system consist of five main elements:
• Scanning – Documents are scanned, converted and saved into the temporary
storage (Koulopoulus et al, 1995 quoted by Roman et al, 2002).
• Storage – Saved document that is uploaded to the document imaging and
document management repository (Koulopoulus et al, 1995 quoted by Roman et
al, 2002).
21
• Index – Indexes are created during the document upload process to improve the
speed of document retrieval storage (Koulopoulus et al, 1995 quoted by Roman et
al, 2002).
• Security – Ownership and access rights of the documents are recorded together
with the indexed documents.
• Retrieval – This is the situation where the user is able to retrieve electronic
document storage from the repository using the document imaging and document
management’s client viewer such as Microsoft Internet Explorer, IE (Koulopoulus
et al, 1995 quoted by Roman et al, 2002).
There are two main types of DMS, they are client and server-based. In general, for a
server-based DMS, it will use Local Area Network (LAN), or web-based environment,
whereas the client-based DMS will use a stand-alone application or web browser to access
documents. To study several document imaging and document management systems such
as Laser Fiche, Hummingbird Cyberdoc and 80-20 Document Manager, their generalised
features are listed below:
• Able to retrieve and search documents from large datasets and multiple databases
with (Borghoff et al, 1997) or without agent.
• Offers user friendly features because it is able to gather all levels of user’s skills
from records manager to MIS manager.
• Provides multiple levels of document access rights, system function rights and
audit trails control at the folders (Eklund & Cole, 2002) and documents for
different groups and individuals to prevent and detect unauthorised creation,
addition, alteration or deletion of documents.
22
• Provides email or fax facilities to distribute files from word processors,
spreadsheets and graphics programs.
• Provides online access services in order to share documents electronically among
other users, departments, offices, clients or the public over the network or through
the Web.
• Supports various format presentations and conversions such as emails and
attachments, documents, Web pages, XML files, rich media, and so on.
• Supports multiple versions of documents.
• Offers marks-up and annotations that can provide additional information about a
document or its status without actually changing the original image.
• Adapt to the business domain without changing the business operation.
• Publishes and archives information to an unalterable format, such as CD or DVD,
WORM (Write One Read Many) medium and Tape to reduce the risk of loss or
damage to the manual system.
• Supports disaster recovery and workflow (Kenneth & Sunil, 1994) facilities.
In short, DMS is a way for users to organise data, distribute documents and manage the
flow of information among users or across organisations. Besides, it also defines who has
the access to specific information, and determines how these data can be viewed.
2.2 Source Version Control (SVC)
Although both SVC and document imaging and document management are derived from
the same base class, however, there are major differences among them. Apparently, it
causes major confusion between these two unrelated purposes, which are record keeping
and collaboration that are closely connected.
23
“Provide a mechanism where developers can maintain independent development
environments, … The environment should represent a snapshot of all the software being
developed in a system, not just the code the developer is modifying. Try to ensure that the
private development area is not used as a crutch though.” (Berczuk, 1996)
From the quoted paragraph above, one can know that record keeping provides a
comparison between the program states with the history deployment. The comparison
includes the features delivered, bug fixed and software upgrades or patches released.
Perhaps, it increases the ease of source code access and revision process among software
developers.
On the other hand, collaboration among a large team of software developers may be a
critical problem especially in file locking situation (Laakso et al, 1996). Essentially, a SVC
system with the facility of lock-modify-unlock development model or copy-modify-merge
model helps software developers to make changes to the same file concurrently and merge
back to the repository later, rather than requiring that developers to coordinate with each
other to avoid conflicts. Figure 2-1 shows the major activities of SVC in a collaboration
diagram.
24
Check Outfor modify
Local copy
Check Outfor compilation
Local copy
Master Copy
Get Latest Version
Developers Team
Release
New features
Bug fix
Check In
Local copy
Merge
Figure 2-1 Source Version Control Collaboration Process
Below is an example of sequential states that might happen in a collaboration process
among developers during software development:
• Developer A requests or checkouts a working copy of source code, where it can be
a directory tree containing the files that make up the project, from SCV (Fogel,
2002).
• While Developer A edits his or her local working copy, at the same time, another
developer may edit on his or her local working copy too (Fogel, 2002).
• Developer A finishes the changes and commits them into SCV, at the same time, it
will merge into the master copy (Fogel, 2002).
• Meanwhile, other developers can retrieve and merge into the SCV as well without
knowing the changes produced by the previous developer (Fogel, 2002).
25
As a result, it is less security rigid than the document management where all SCV users or
software developers on a same project are of equal rights of updating policy.
“Developers should be provided with a mechanism for check pointing changes at a
granularity that they are comfortable with. This can be provided for by a local revision
control area, only stable code sets are checked into the team version control repository.”
(Berczuk, 1996)
Generally, one must understand that updating the source code before commencing on
major changes and committing changes after fully tested are those common strategies for
software projects. In fact, the master copy in the repository should always be in an available
and executable mode.
“Provide a mechanism to allow developers to build all the current software periodically.
Developers should be discouraged from maintaining long intervals between "check-ins."
Developers should also be able to build against any of the Named Stable Bases, or the
newest checked in software, at will.” (Berczuk, 1996)
The common features of SVC after analysing several existing products in the market such
as Code Version System (CVS), Visual SourceSafe (VSS), and PreForce are listed below
(Fogel, 2002):
• Provides binary and ASCII files handling
• Provides locking, renaming and moving
• Offers delta changes (Burns et al, 1997)
• Supports user-defined properties and execute permissions
26
• Supports features such as annotate or label or tag, which is a named list of user-
specified revisions of files
• Displays graphical user interface that can provide shell-level integration with
Windows Explorer to give users bidirectional drag-and-drop interaction with SVC
server
• Supports version branching
• Provides work request such as a bug report or enhancement request
Furthermore, some of the common terminologies used in SVC are (Fogel, 2002):
• Add or check in – Place the files into a depot or repository
• Edit or check out – Copy the file to local disk and open it for editing
• Revert or undo check out – Discard any changes for the checked out files
• Merge – Reconcile and combine the differences and conflicts between two
revisions into a single file
• Synchronised or get latest version – Copy files from the repository to the current
working directory
• Depot or repository – Central storage for source codes and related files.
Client workspace or working directory - Directory structure on the local computer where
the users work with local copies of files that are under source control.
2.3 Content Management System (CMS)
Nowadays, with the rapid development of Web technologies, software vendors are moving
away from stand-alone document management platforms to tools that can manage the full
27
array of digital content. In fact, content management extends the document management
system by providing rich sets of features to store, index, search, retrieve and organise a
collection of disparate contents efficiently and effectively (Lindvall, 2002). Generally, a
document may contain one or more units of digital information, thus a document is in
essence comprised of content. Apparently, these contents may be any type of files, such as
Word document, Spreadsheet or multimedia etc. Primarily, a CMS would cover the
following components or features:
• Web-based publishing – Contains page templates, wizards, and other software
tools that help to deliver the contents to the audiences
• Viewer – Provides a set of DLLs or cross-platform web-enabled type viewer such
as Internet Browser, PDF reader, picture or raster viewer and multimedia viewer
• Editor – WYSIWYG facilitates stand-alone desktop applications or browser-based
editor so that users can create, edit, manage and publish the contents
• Format management – Conversion of the source documents such as legacy
electronic documents, or scanned paper documents data into common formats
that are suitable for web publishing such as HTML or PDF
• Links – Provides ease of assigning related contents to a meaningful name
• Indexing, search, and retrieval - Documents are parsed using keywords, headings,
graphics, XML description, and other elements for increasing the search
performance
• Categories – Organise, package as well as publish different sections of a content
publicly
• Location transparent – Location of the contents should be transparent of where it
created, retrieved, and managed around the web developer
28
• Workflow – Ensures a coherent and validated layout appearance (Kenneth & Sunil,
1994)
• Security – Inherits from DMS plus the mechanism to support out-of-the-box use
for authentication against an LDAP directory including Active Directory or
Microsoft NT Domain
• SVC – Please refer to Section 2.2 for further details
Combining these rules, processes, workflows and framework requirements in such a way
that will allow non-technical personnel to add, edit, manage and publish all the contents of
a particular business domain. Before going further, one has to understand how are a DMS
and a CMS related to each other? The answer is simple. Prior to 1990s, the CMS is DMS,
and only lately CMS is becoming Information or Web Portal. Figure 2-2 illustrates the
complicated relationship between portals and CMS.
Figure 2-2 Relationship between Portals and CMS (Browning P., 2003)
Generally, a DMS is concerned about a document entirely and less emphasized in what the
document contains. In contrast, a CMS emphasizes in managing information at the micro
29
level, i.e. the content rather than the higher level, i.e. the document that makes up a
document or web page. In essence, the main differentiation between a DMS and a CMS is
that the CMS offers more granularity of management of the digital information over the
DMS.
2.4 Portal
A portal generally allows the audiences to access critical business information located inside
and outside of an organisation through personalised, consistent and single point of access
via web browser. Besides using a desktop web browser to access a portal, instead, other
web-enabled devices such as PDA or mobile phones may also be used and are referred to
as Web top. Moreover, the portal can gather and deliver information from multiple servers
around the globe. In fact, there are over 100 portal vendors with different business
domains and features. Below are the common features of these portals:
• All in one interface – Integrates features from DMS, CMS and SVC, and also
capable to launch other common office applications, such as word processing,
spreadsheets, e-mail, and so on
• Knowledge management (KM) – Aggregates contents from disparate sources and
collaborate with experts and peers on specific issues, and access competitive
information and database (Preece et al, 2001)
• B2B, B2C and C2C capabilities – Provides communication among different
enterprises, partners, suppliers, investors, and customers via e-business strategies
• Personalise and user friendly – Offers users with ease-of-use features, such as to
select preferred content for his or her personal portal page
• Role-based and functional-based portal – Allows for some degree of
personalisation such as personal tab pages for box scores, links to favourite Web
30
sites, and other non-work-related information without relegating the importance of
the business workspace
• Harvesting engine - Collects information using a spider engine and data mining
from a variety of sources such as http servers, Lotus Domino server and Microsoft
Exchange server
• Flexible, extendable and modular framework – For example, it allows developers to
make customisation, creates new modules or new integration requirements using
standard APIs from JavaScript, Java, .Net, COM, Active Server Pages (ASP), or
Java Server Pages (JSP). Most vendors provide support for some subsets of these
languages and APIs. For further details on portal frameworks, please refer to
Appendix A
• Collaboration – Provides peer-to-peer communication using chat tools or
collaboration clients such as Microsoft NetMeeting
Besides DMS and CMS, many other information systems can be upgraded to a portal,
regardless of its shapes, sizes, and specialties. According to Delphi Group company, “The
market space for portal applications is exploding, with compound annual growth in excess
of 100 percent through 2001 to US$740 million.” Referring to Figure 2-3, it shows that the
portal players can come from a wide variety of technology disciplines. This figure is taken
from The Delphi Group, the market researcher and consulting firm
(http://www.delphigroup.com).
31
Figure 2-3 Portal Vendor (Kounadis T., 2000)
2.5 Application Products Reviews
Conducting a research with raw data gathering may be time consuming and too bias
toward specified groups of users. Therefore, collecting raw data from a well-known public
internet site embraces the following advantages:
• The data is collected via non-profit organization without bias.
• The collected data is matured and continuous in stream.
• The data is being updated by global users, which represents the majority.
A web site, CMS matrix (http://www.cmsmatrix.org) that consolidated most of the DMS,
CMS and SCV products, features, reviews and reports has been evaluated and analyzed.
The following sections describe the analyzed results using methodologies that will be
discussed in session 3.1.
32
CMS matrix web site has conducted 206 applications products reviews from various
vendors and different business domains. Applications products such as e-publish, Ektron
CMS300, OmniUpdate, OpenPortal CMF, Oracle Portals, Sharepoint Portal Server,
SiteBuilder, and Websphere EIP are just a few among the full list.
On the other hand, there are total of 123 application features recorded for comparisons.
These items are divided into nine main categories namely system requirements, security,
support, ease of use, performance, management, interoperability, flexibility as well as built-
in components. However, only important items shown in the categories listed below are
counted into the analysis processes.
• System Requirements – Application/Web server, database, operating system.
• Security – Audit trail, Granular Privileges, Kerberos authentication, LDAP
authentication, NTLM authentication (i.e., A challenge/response authentication
protocol), SMB (Server Message Block) authentication, Session management, and
SSL compatible.
• Supports – Online help and pluggable API.
• Ease of use – Drag and Drop content and undo.
• Performance – Advanced caching, page caching, database replication, and load
balancing.
• Management – Online administration, web-based style/template management and
workflow engine.
• Interoperability – Content syndication (RSS), FTP support, WebDAV support, and
XHTML compliant.
• Flexibility – Extensible user profiles and interface localization.
33
• Build-in component – Document management, HTTP proxy, search engine, and
web service front end.
2.5.1 System Requirements
There are three items, application environment/web server, database and operating system
included in the system requirements review. As illustrated in Figure 2-4, PHP and IIS with
ASP.NET cover almost 50% of the application environment/web server markets
(according to CMS Matrix website http://www.cmsmatrix.org/, some sample of raw data
is provided in Table 3-1). Although PHP and PERL are only scripting languages but they
rely heavily on its own proprietary session management, caching management and server
objects (request and response). Like Java, which is a programming language that rely on it
pure Java container as an application platform or web server. In other word, DMS that
uses Java means it uses Java application environment or Java web server but not PHP
application environment although it only a programming language. In facts, J2EE, PERL
and Apache are among other famous application environment/web server. Please note
that, not all DMS applications requires application environment/web server, it may be
optional or built into the DMS application itself. There are 4% among 227 DMS
applications support four or more application environment/web servers.
34
Figure 2-4 Application/Web Server Review
For databases, MySQL, Microsoft SQL server and Oracle penetrate half of the DMS
applications market. A freeware version of database, MySQL is the main choice for DMS
Database
38%
23%
18%
8%
5%
2%
2%
1%
1%
1%
1%
0%
MySQL
Any
MSSQL
Oracle
PostgreSQL
built-in (none required)
Access
Flat file
XML
DB2
Java Content Repository
(JCR)
hierarchical object DB
Figure 2-5 Databases Review
Application Environment/Web Server
28%
20%
12%
9%
7%
6%
4%
4%
3%
3%
3%
1%
PHP 4.1.2+
IIS + ASP.NET
J2EE
Other
Apache
None
Hosted CMS
4 or more
PERL
built-in (none required)
Coldfusion
(optional)
35
vendors to integrate their products. By referring Figure 2-5, one knows that there are
vendors who implement their DMS applications using flat file, XML, Java content
repository (JCR) as well as hierarchical object database for the DMS data storage. It may be
a new concept that customers or users may lack of confidence on these new technology or
techniques which its stability and robustness are questionable.
To maintain a product market competitive, DMS applications vendors have consider their
product available on any operating systems or platforms. Half of the DMS applications can
run on any platforms, 24% are on Windows family platforms, which include Windows
Server 2003, Windows Server/Professional 2000, Windows XP, Windows
Server/Workstation NT as well as some Windows 98/ME. By now, the market share for
UNIX and Linux on DMS applications market are same with 12% for each of them. These
indicate that Linux is catching up UNIX for its server dominant platforms recently.
Operating System
50%
24%
12%
12%
1%
1%
Any
Window s
Unix
Linux
Other
J2SE Compatible
Figure 2-6 Operating Systems Reviews
36
Some DMS applications vendors claim that their products will run on any J2SE compatible
platforms, which includes Java OS and virtually any OSes because of its platform
independent capability.
2.5.2 Security
Audit trail and granular privileges are two important features required for a DMS
application. As illustrated in Figure 2-7 and Figure 2-8, more than two third of DMS
applications have built in audit trail and granular privileges. In brief, audit trail is a
chronological record of system activities that is sufficient to enable the reconstruction,
reviewing, and examination of the sequence of environments and activities surrounding or
leading to an operation, a procedure, or an event in a transaction from its inception to final
results (Slade, 2004). Whereas granular privileges allow read and write privileges on a per
page, per content or per resource basis, as well as separate privileges for other system
functions. In other words, audit trail and granular privileges are a must features for a DMS
application.
Audit Trail
67%
8%
1%
1%
23% Yes
No
Limited
Free Add On
Costs Extra
Figure 2-7 Audit Trail Reviews
Granular Privileges
82%
11%
7%
0%
0%
Yes
No
Limited
Free Add On
Costs Extra
Figure 2-8 Granular Privileges Reviews
37
On the DMS authentications method, there is no clear guideline for universal
authentication implementations. Table 2-1 describes the characteristics of each type of
authentications.
Table 2-1 Various Authentications Methods
Authentications Method
Descriptions
Kerberos
Kerberos is network authentication protocol, software that will add to the ability of operating systems (Windows, Mac, etc.) to authenticate users and servers, and manage session-level security and encryption. It is IP-based service. It uses secret-key cryptography to provide strong authentication for client/server applications. (Hitmill, 2004)
LDAP
Lightweight Directory Access Protocol. It is a protocol for accessing information directories such as organizations, individuals, phone numbers, and addresses. It is based on the X.500 directory protocols, but it is simpler, and unlike X.500, it supports TCP/IP for Internet usage. The standards are specified in RFC 1777. (Howe, 2000)
NTLM
A challenge/response authentication protocol. The NTLM authentication protocol was the default for network authentication in Windows NT version 4.0 and earlier. The protocol continues to be supported in Windows 2000 but no longer is the default. (Microsoft, 2002)
SMB
Server Message Block. A protocol for sharing files, printers, serial ports, and communications abstractions such as named pipes and mail slots between computers.
Share level – Protection is applied at the share level on a server. Each share can have a password, and a client only needs that password to access all files under that share.
User Level – Protection is applied to individual files in each share and is based on user access rights. Each user (client) must log in to the server and be authenticated by the server.
(Sharpe, 2002)
By referring Figure 2-9, Figure 2-10, Figure 2-11 and Figure 2-12, the vendors of the DMS
applications selectively integrate some or all four authentications methods, which include
38
Kerberos authentication, LDAP authentication, NTLM authentication and SMB
authentication. It may be difficult to implement all authentications methods. Fortunately,
33% of the DMS applications vendors include LDAP authentication into their products.
Kerberos Authentication
82%
5%
2%
1%
10%
No
Yes
Costs Extra
Limited
Free Add On
Figure 2-9 Kerberos Authentication Reviews
LDAP Authentication
8%
4%
2%
53%
33%
No
Yes
Costs Extra
Free Add On
Limited
Figure 2-10 LDAP Authentication Reviews
NTLM Authentication
77%
5%
3%
13%
2%
No
Yes
Costs Extra
Limited
Free Add On
Figure 2-11 NTLM Authentication Reviews
SMB Authentication
82%
4%
2%
2%
10% No
Yes
Costs Extra
Limited
Free Add On
Figure 2-12 SMB Authentication Reviews
A session is used to store the users’ information during their visit and operations request to
the DMS server. This feature is useful to reduce the amount of round trips between the
DMS server and the DMS client since the security information is kept in the DMS server.
39
Session Management
43%
42%
12%3%
Yes
No
Limited
Costs Extra
Figure 2-13 Session Management Reviews
Referring Figure 2-13, 43% of the DMS applications support session management
although some features of session management is limited or demanding extra costs.
Nevertheless, session management is built-in with all famous web servers. This is an
advantages if DMS application is built on top of from web server.
Similarly, SSL (Secure Socket Layer) is come with most web servers. It encrypts the
transmitted data over the HTTP channel using tunnelling technique. From the Figure 2-14,
80% of the DMS applications comply with the SSL standard. Interestingly, even though
both session management and SSL have built into the web servers, only 43% of the DMS
applications have integrate session management into their products. Some study shows that
maintaining the sessions consume server resources; therefore, it is not wise to implement
the session management into the DMS applications.
40
SSL Compatible
80%
18%
1%
1%
Yes
No
Costs Extra
Limited
Figure 2-14 SSL Compatible Reviews
The SSL feature is important to ensure that the communication between the DMS server
and client is not intruded by the hackers.
2.5.3 Product Supports
Product supports is a key feature to sustain a product lifetime. Most users will not employ a
new piece of software application without the formal supports from the DMS applications
vendors. There are 13 items includes in the CMS matrix web site under supports
categories, certification program, commercial manuals, commercial support, commercial
training, developer community, online help, pluggable API, professional hosting,
professional services, public forum, public mailing list, third-party developers, and users
conference. Table 2-2 analyzed the steps of implementations for each category.
41
Table 2-2 Implementation Guide Lines
Category Steps of implementations
Certification Program
Setting up professional panel/board for the procedures
1. Defines and drafts the certificate standard 2. Accepts comments from the communities via RFC or by other
means. 3. Evaluates and finalizes the certificate requirement. 4. Accepts certificate application from the developers or software
engineers
E.g. There are Sun Certified Programmer, Sun Certified Developer and Sun Certified Enterprise Architect for Java platform; MCP (Microsoft Certified Professional), MCSD (Microsoft Certified Solution Developer) and MCSE (Microsoft Certified Systems Engineer) are most popular certificates from Microsoft. For DMAPI, the appropriate certificate level should be DMAPI Solution Integrator, DMAPI Solution Architect and DMAPI Solution Provider.
Commercial Manuals
The commercial manuals cover set of books or CDs that come with the box or package of DMAPI.
These books or CDs of PDF (Portable Document Format) may include the following topic:
1. Beginner guide for DMAPI 2. Program the DMAPI 3. DMAPI Extensibility 4. DMAPI References Guide 5. DMAPI Administration and Configuration 6. DMAPI Case Study and Real Life Example
The example of most complete user manuals include MSDN (Microsoft Developer Network) library package.
Commercial Support, Professional Services
The support can be purchased from a commercial organization together with the following items:
1. Conducted by trained staff member. 2. 7 x 24 technical support. 3. Phone support. 4. Chat or Messenger Support (MSN, Yahoo Messenger or IRC) 5. Maintenance Agreement 6. Product warranty.
By the way, DMAPI should employ technical staffs to provide administrative services or customize needs from customers.
42
Commercial Training
DMAPI should retail the training package from dedicated training staff commercially to cover:
1. Onsite or offside training. 2. Training Manual 3. Training Certificate 4. Professional Trainer Employment
Developer Community, Public Forum and Public Mailing
1. DMAPI needs to invite the application developer to join the developer community.
2. A public forum or message board is installed to allow developer community to communicate effectively.
3. Product changes or updates are broadcasted to the developer community via mailing list.
Professional hosting
Setup a hosting environment (application service provider) which tuned professionally or signup a certified hosting partner program to provide.
1. 99.9% service uptime. 2. High bandwidth availability. 3. Hosting package:
a. By hard disk space b. By monthly bandwidth
Third- Party Developers
Provide incentive to encourage other vendors to develop third-party plug-ins such as workflow management system and web portal integration. These developers usually build value added plug-ins to support the DMAPI framework.
For instance, Crystal Report and ComponentOne are the great tools to support .Net framework.
Users Conference
If possible and financially allowed, there will be a user conference organized every year for DMAPI user group and third party developer to get together to discuss ideas and get training.
43
Although there are many items in product support category, however, only online help and
pluggable API are usable for the purpose of this dissertation since the prototype is an API
and academic product.
Online Help
72%
21%
6%
1%
0%
Yes
No
Limited
Free Add On
Costs Extra
Figure 2-15 Online Help Reviews
Pluggable API
66%
25%
7%
2%
Yes
No
Limited
Costs Extra
Figure 2-16 Pluggable API Reviews
Figure 2-15 and Figure 2-16 indicate that the reviews of the percentage of DMS that are
providing the popular features required by the users. Hence, from these reviews, the users
emphasize the popular features such as online help and applications customizable when
they are choosing a DMS product. In other words, DMS vendors do not invest in those
features that are less demanding if there are no market value with it. As a result, two thirds
of DMS applications provide excellent online documentation and programmable API.
2.5.4 Ease of use
Another important factor besides product supports is ease of use. Ease of use is a very
subjective issue to be discussed. CMS matrix web site includes drag-n-drop content, email
to discussion, friendly URLs, macro language, server page language, spell checker,
subscriptions, template language, user interface levels, undo and WYSIWYG (what you see
44
is what you get) editor as the ease of use factors. However, factors other than drag-n-drop
and undo are not applicable in this dissertation. Furthermore, drag-n-drop feature reduces
user needs for remembering the commands for each operation. Undo tolerates users’
mistakes by allowing rollback of the fault operations or steps.
Figure 2-17 and Figure 2-18 illustrated the percentage of vendors that implement drag-n-
drop and undo features into their DMS applications products.
Drag-N-Drop Content
39%54%
7%
No
Yes
Limited
Figure 2-17 Drag-n-drop Content Reviews
Undo
48%
40%
12%
Yes
No
Limited
Figure 2-18 Undo Reviews
2.5.5 Performance
There are two main factors concerning the performance issue, the response time or speed
and system scalability. The response time and speed depend heavily on how the DMS
server caches and serves the resources. These resources are preloaded into system memory
so that if it is requested again it can skip most of the work to create the page. Some
advanced caching technique may include page navigation, template and content object as
well. Figure 2-19 and Figure 2-20 show both percentages of the caching techniques. A
45
good reason to explain why most DMS applications support caching is that caching is built
into the web servers.
Page Caching
75%
22%
2%
1%
Yes
No
Limited
Free Add On
Figure 2-19 Page Caching Reviews
Advanced Caching
58%
41%
1%
Yes
No
Costs Extra
Figure 2-20 Advanced Caching Reviews
Database replication and load balancing allow a single DMS application runs on several
machines. The former distributes the database workloads such as queries and indices
across multiple servers, whereas the later shares the hardware resources such as processor
power, memory and hard disk spaces among the load balancers. Either case, sophisticated
configurations and planning must be done before setting up the implementation.
Referring Figure 2-21 and Figure 2-22, only 32% of the DMS applications support
database replication and 42% support load balancing. In addition, both scalability factors
are classified as enterprise features. The DMS applications vendors who support these
features are beneficial for their market advantages. Moreover, the cost to configure and
maintain the system is known to be very high.
46
Database Replication
32%
2%
2%
1%
63%
No
Yes
Limited
Costs Extra
Free Add On
Figure 2-21 Database Replication Reviews
Load Balancing
42%
4%
3%
0%
51%
No
Yes
Costs Extra
Limited
Free Add Onc
Figure 2-22 Load Balancing Reviews
2.5.6 Management
CMS matrix web site includes online administration, web-based style/template
management, workflow engine, etc as the management factors for their DMS application
review. An online administration allows the DMS system administrator to configure and
maintain the system via a web browser. Since the system is configurable via web browser,
the DMS can be contacted at any places and any time without physical boundary. The
aspect further increases the uptime of the DMS system. For the same reason, there are only
7% of the DMS applications do not support online administration. On the other hand, the
online administration comes together with security burden. Without detailed security
constitution, the hackers may take advantage through the system.
47
Online Administration
91%
7%2%
Yes
No
Limited
Figure 2-23 Online Administration Reviews
With the help of web-based style/template management, the user interface can be changed
dramatically without much programming efforts.
Web-based Style/Template Management
70%
20%
8% 2%
Yes
No
Limited
Costs Extra
Figure 2-24 Web-based Style/Template Management Reviews
Figure 2-24 shows that more than two thirds of the DMS applications support this feature.
48
Most web content providers do not have a built-in workflow engine. Referring to Figure
2-25, only one third of the DMS applications incorporate a workflow engine.
Workflow Engine
46%
38%
8%
6% 2%
No
Yes
Limited
Costs Extra
Free Add On
Figure 2-25 Workflow Engine Reviews
49
2.5.7 Interoperability
Besides operating systems, some standard protocols are required to be complied in order
to ensure a DMAPI is interoperable. A client developed by one vendor is capable to
request and process the DMAPI services developed by the other vendor. Table 2-3
explains some basic protocols, usages and its review percentages (from Figure 2-26, Figure
2-27, Figure 2-28 and Figure 2-29).
Table 2-3 Protocol and Standard Descriptions and Review Percentages
Protocol or Standard
Descriptions Percentages
RSS
Really Simple Syndication or Rich Site Summary for syndicating news and the content of news-like sites.
Yes – 57%
No – 29%
FTP
File Transfer Protocol - A way of transferring files over the TCP/IP protocol from one computer to another.
Yes – 40%
No – 53%
WebDAV
Standard used to save data to web. The IETF Web Distributed Authoring and Versioning working group is responsible for a set of WebDAV standards.
Yes – 17%
No – 77%
XHTML
Extensible Hypertext Markup Language
A reformulation of HTML 4.0 in XML 1.0. XHTML is a new language for building web pages that has recently been proposed as a W3C Recommendation.
Yes – 54%
No – 38%
50
.
Content Syndication (RSS)
57%29%
6%
5%
3%
Yes
No
Limited
Costs Extra
Free Add On
Figure 2-26 Content Syndication Reviews
FTP Support
53%40%
4%
2%
1%
No
Yes
Limited
Costs Extra
Free Add On
Figure 2-27 FTP Support Reviews
WebDAV Support
77%
17%
3%
2%
1%
No
Yes
Limited
Costs Extra
Free Add On
Figure 2-28 WebDAV Support Reviews
XHTML Compliant
54%38%
7% 1%
Yes
No
Limited
Costs Extra
Figure 2-29 XHTML Compliant Reviews
2.5.8 Flexibility
Flexibility factors include extensible user profiles and interface localization. Extensible user
profiles provide a user profiling that can be extended with new profile properties through
an administrative interface. Furthermore, the system can be translated into other languages
51
and take locale preferences like date/time preferences into account through localization or
internationalization support. Fortunately, half of the DMS applications support extensible
user profiles and internationalization (from Figure 2-30 and Figure 2-31).
Extensible User Prof iles
53%36%
6%
4%
1%
Yes
No
Limited
Costs Extra
Free Add On
Figure 2-30 Extensible User Profiles Reviews
Interface Localization
59%
35%
4%
2%
0%
Yes
No
Limited
Costs Extra
Free Add On
Figure 2-31 Interface Localization Reviews
2.5.9 Built-In Components
Some DMS applications vendors may include or bundle additional components into their
products to enhance its market competitive. Components such as document management
attracts 26% among all DMS applications vendors to have it integrate into their products.
Only 22% of the DMS applications vendors incorporate HTTP proxy into their products
(from Figure 2-32 and Figure 2-33). The provided or built-in components are not always
beneficial. In fact, some users complain that it brings extract cost into their project
implementation.
52
Document Management
57%26%
8%
7%
2%
No
Yes
Costs Extra
Limited
Free Add On
Figure 2-32 Document Management Reviews
HTTP Proxy
72%
22%
3%
3%
0%
No
Yes
Limited
Costs Extra
Free Add On
Figure 2-33 HTTP Proxy Reviews
With the same explanation, only 15% DMAPI use web services implementation (Figure
2-34). Referring to Figure 2-35, there are 72% among all DMAPIs are built-in with search
contents engine.
Web Services
70%
15%
8%
4%
3%
No
Yes
Limited
Costs Extra
Free Add On
Figure 2-34 Web Services Reviews
Search Engine
72%
17%
6%
3%
2%
Yes
No
Costs Extra
Free Add On
Limited
Figure 2-35 Search Engine Reviews
.
53
2.6 System Limitation
There are total 123 products features, however only 35 features are being reviewed or
compared. The omitted features may become general limitation of DMAPI since there are
not taken into account although some of them are irrelevant as listed in Table 2-2. Several
factors determine the limitation of DMAPI or similar product. There are OS (Operating
System) or platform independent, open source, market share, and user friendliness. The
reviews should be conducted against fully platform independent compliance, since some of
feature like NTLM is native to Microsoft Windows.
Currently there is no pure API for DMS like the proposed DMAPI. It is very difficult to
justify the limitation of API product. For example, the decision to support OS/platform
independent with expensive development cost or to support OS that having more market
share, without complying one of them does not mean product limitation. Rich features like
Microsoft .Net Framework versus open source Java, both have their advantages and
disadvantages. However, the key is ‘API Product’, which allows features or framework
extension.
2.7 Conclusions
The reviewing process in this chapter leads to the decision of the DMAPI’s design and
implementation. Several critical remarks are derived from the reviewing process. Referring
all the charts depicted in the previous sections, some of the remarks are closely due to the
nature of the web-based architecture offered by most DMAPI. Half of the application
features are web-based, e.g. web server, online help, advanced caching, page caching, online
administration, etc. These features are heavily depends on the defined HTTP protocol
performance and security implementations. For the performance issue, the pure HTTP
54
implementation of file transfer technique is suggested to be improved due to HTTP PUT
and POST method does not support resume broken download and upload. The proposed
DMAPI should support these features since it is built using web service that allows more
control over communication channel.
On the other hand, the security implementation of DMAPI must cover the items listed in
Table 2-4.
Table 2-4 Security Elements
Element Description
Confidentiality The data is hidden to the entities listening to the conversation
Integrity Ability to detect changes to the SOAP or other HTTP messages.
Authentication Ability to know who is the caller. Authorization Identify the caller’s rights to access the web
methods or services. Non-repudiation
Prevent the client from fraudulently reneging on a transaction.
The transmitting data must be configured to support public key infrastructure (PKI) to
ensure that no data is being intercepted during the communications. During the application
development, the information in an HTTP-based SOAP message should be kept
confidential and be exchanged over the SSL channel. This keeps the data in the Web
service hidden from any entity looking at data transmission over the connection.
Performance and scalability issues play an important role in web-based DMAPI features.
These issues can adversely affect the performance and scalability of the proposed DMAPI.
Table 2-5 below shows the summary of the performance factors.
55
Table 2-5 Performance Factors
Performance Factor
Description
Resource affinity
Prevent from adding more servers, CPUs, memories, or other resources that is caused by the written codes requiring a specific thread, CPU, component instance, or server.
Excessive allocations
Allocation of memory excessively on during a client request.
Managing expensive resources
Closing or disposing resources permits the resources to be reused more efficiently. Failing to release expensive resources, such as database connections, may lead to resource shortages.
Blocking operations
Calls to long-running stored procedures and remote objects may block a thread for a significant amount of time in servicing additional user requests while the thread is waiting for a downstream call to return.
Misusing threads
Creating threads for each request incurs thread initialization costs. However, multiple requests in the queue slow performance and create scalability issues.
Large responses
The more data sent over the network, the more bandwidth consumed. Highly consumed bandwidth creates application bottleneck.
Data caching Catching too little static data or too much infrequently used data may limit the system's performance and scalability.
Lastly, the features that the majority of vendors agreed will be built into the proposed
DMAPI core engine. These features include audit trail, granular privileges, SSL compatible,
online help and pluggable API that have the most demand. Features that are having the
least demand are unlikely to be implemented since the reviews are based on public domain
and interests. However, additional features that are not covered in the DMAPI are possible
to be implemented using the inheritance feature of OOP.
56
CHAPTER 3 METHODOLOGY
Having a methodology to guide the implementation of this proposed DMAPI framework
is a critical element for any application that can be derived from it. Different extension of
DMAPI has different needs and cultures and this is the reason why DMAPI
implementation needs to be designed carefully and tailored to the target extended business
domain. In this chapter, the methodology of the proposed DMAPI is hoped to address
this issue and helps in the understanding and setting up of a DMAPI framework for any
interested organisation. There are also domain experts who know the culture and problems
best and can help avoid obstacles and aim at solving the true problems. In general, the
methodology described here will consist of research methodology, an object-oriented
approach to software development lifecycle and a set of object-oriented techniques and
notations using Unified Modelling Language (UML) that support the approach (Bennett et
al., 2002). Furthermore, it also consists of an incremental lifecycle model to structure the
development process and a unifying set of procedures and approaches. The following
sections will describe the methodology to be taken in more detail to assist in defining
systematic and orderly methods and procedures, approaches, and tools that define the
overall framework of the DMAPI software development life cycle (SDLC).
3.1 Quantitative Analysis
The research is conducted using quantitative analysis technique whereby it uses data-driven
analytical method against a range of DMAPI features. A large volume of raw data from
the public domain is collected, organized, arranged and sorted into analyzable tables to
form the charts that represent the proportional DMAPI features on the market. A subset
57
of the collected data is shown in Table 3-1, in which a total of 226 rows and 123 columns
are included in the actual table. This table of data is recorded in the spreadsheet.
Table 3-1 Subset of the Collected Data
Product Application Server
Approximate Cost Database License
Operating System
Programming Language
Root Access
Absolut Engine 1.69 Free MySQL GNU GPL Any PHP
ADXSTUDIO 2004
IIS + ASP.NET 3999
Microsoft SQL Server 2000 per server
2003, 2000, XP-Pro ASP.NET Yes
Affino LX
Any J2EE 1.4 compatible AS 10000 PostgreSQL
Commercial, subscription model or single-purchase
Microsoft Window, RedHat Linux ColdFusion Yes
AGPCMS PHP 4.2.1+ € 1300,00 MySQL 3.23.5+
Commercial per installation Unix, Linux
PHP 4.2.2 or later No
Apache Lenya 1.2 4 or more Any
Apache-style Any
Java/XML/XSLT/Javascript/JSP
AquiferCMS 3.0 ASP
Call 877-806-1274
MSSQL, MSDE
Per Server or ASP Monthly Windows ASP No
Ariadne 2.4rc2 mod_php
PostgreSQL, MySQL, Oracle GNU GPL
Windows, Unix PHP
Arp.Site Free 2.0 Tomcat 0
MySQL, Oracle, MSSQL
Apache Licence 2.0 Any Java 5.0 No
Artiloo Velocity PHP 4.3.0+
MySQL 4.23.xx or later GNU GPL Any
PHP 4.2.2 or later Yes
AssetNow NX Coldfusion
US$1495 - $2495
mySQL, Microsoft SQL Server and Microsoft Access Commercial
Microsoft Window, RedHat Linux ColdFusion No
This spreadsheet is imported into MS Access database for further analysis (Figure 3-1).
Figure 3-1 Raw Data in MS Access
58
A view or query for every column (representing a category) is built to analyze the
distinctness of each value. An example of these queries is shown in Figure 3-2.
SELECT CMS2.[Operating System], Count(CMS2.[Operating System]) AS
[CountOfOperating System]
FROM CMS2
GROUP BY CMS2.[Operating System];
Figure 3-2 SQL Statement for “Operating System” View/Query
The result of the SQL statement in Figure 3-2 is shown in Table 3-2.
Table 3-2 Result for the Distinctness of Operating Systems
Operating System Operating System CountOfOperating
System Any 83
Windows 24
Linux, Solaris, Windows 14
Unix, Linux 12
2003, 2000, XP-Pro 11
Unix, Linux, FreeBSD & All BSD's, HP-UX, Windows 2000, 2003, XP, Solaris, AIX
11
UNIX (Linux, MacOS X...), Windows 2000/2003/XP 7
Windows, Macintosh, Linux, Unix 6
Windows, Unix 5
Windows Server 2003 5
Java 1.4 4
Most OS 4
OS independent 4
Linux 4
Unix (Linux, Mac OSX, Solaris, etc); beta available for Windows servers
3
Windows XP/2000/2003 3
UNIX, Linux, FreeBSD, OS X, Windows 3
Linux, FreeBSD, Microsoft Windows NT/2000 2
Microsoft Window, RedHat Linux 2
J2SE Compatible 2
Unix (Linux, BSD, AIX, HPUX, Mac OS X, etc.) 2
Win 2000 server 2
OS Independent 1
Windows/IE 6 for authoring 1
Unix, Windows, MAC 1
Java 1.3 compatible 1
Windows, AIX, Solaris 1
59
FreeBSD UNIX 1
Windows, Mac Classic, Mac OS X 1
Windows, MacOS 9/X, Linux, IBM AIX, IBM z/OS, IBM OS/400, Sun Solaris
1
OSX Panther 1
The result in Table 3-2 is further summarized into main streams of OS, which is illustrated
in Table 3-3. The summarized result can be plotted into a pie chart.
Table 3-3 Summarized for the Distinctness of Operating Systems
Operating System CountOfOperating System
Any 139
Windows 66
Unix 34
Linux 32
Other 4
J2SE Compatible 7
All other features related to the categorises can be plotted into charts after sorted according
to the percentages using the similar method in spreadsheet application.
Quantitative analysis method is suitable to determine which features are importance to the
market place. It directly influences the components that going to be built into the DMAPI
prototype.
3.2 Layered Architecture
The proposed DMAPI will be implemented using systematic layered architecture design
with the application systems built on the top and its respective component systems built
underneath it as shown in Figure 3-3. Generally, a layered architecture defines the static
organization of software into several different subsystems, which consists of system
structure, interfaces, and interaction patterns at a significant level and how nodes executing
those software subsystems interact with each other. Furthermore, a layered architecture is
60
applied in order to simplify the system evolution and enables extensive reuse of its
components. This type of layered architecture is much preferred by most software
communities as it organises the software system according to different layers where each
layer is built on top of another more general layer.
A well-designed layer architecture is crucial to maintain system integrity and to manage the
complexity of software systems because it is able to isolate the functionality of the
application interfaces from the business specific functionality. With this layered
architectural design in each development, it can lead to a more effectively and predictable
system so that any changing components will depend upon the stable parts but not vice
versa. The separation of components of the subsystem that change frequently from the
stable components in a layered manner will allow the component and application systems
to be reused and to evolve gracefully over time.
Application Systems Layer
Business-Specific Layer
Middleware Layer
System Software Layer
Figure 3-3 A Typical Layered Architecture
61
3.2.1 Application Systems
In this layer, a proposed user interface application connects the user operations to the
DMAPI logic. Throughout this layer, the user is provided with a communication channel
to some of the services or objects provided by an operation system in one of the lower
layers. The top-most layer, usually known as application systems layer, contains application
systems offering a coherent set of use cases to its end users. Some application systems such
as SCV may possess more than one version (or variant) of application systems. This kind
of layered architecture is selected in this project implementation because it is able to
produce significant levels of software reusability in the architecture and design of the
software systems. In fact, this method is able to provide a clearer implementation boundary
across different business domains.
3.2.2 Business Specific Layer
In the business-specific layer, it contains a number of component systems that are specific
to the nature of business, i.e. specific to a problem domain or something concrete and
significant in the business. Such component systems include use cases and object
components. In short, a business component is a representation of a thing active in the
business domain, including at least its business name and definition, attributes, behaviour,
relationship, rules, policies and constraints. Traditionally, these domain specific operations
are located in this layer. Referring to Figure 3-3, this layer is an extension of middleware
layer in Section 3.2.3. Additional functions of a DMAPI such as Document and Imaging
Management System, SCV, CMS and portal can be added in this layer.
62
3.2.3 Middleware
The core of this project implementation provides utility classes to manipulate specific
DMAPI operations. These functions include basic object persistency, object relational
mapping and object-database interface adapter. The serializable middleware can capture
data and hold onto it until it has been updated appropriately by all the applications or
databases that required the information. Moreover, this middleware layer can be extended
further to other applications such as CMS and portal.
3.2.4 System Software
System software means a platform specific software infrastructure that contains basic
operations to interface with specific hardware or software drivers. Usually components in
this layer are hardware or rather platform dependent, such as JAVA platform or Microsoft
.NET framework can be used to access the platform services offered by the operating
system. In addition, this system software also provides popular communication protocols
such as SOAP (Simple Object Access Protocol) and TCP/IP.
3.3 XML Persistence Framework
XML Persistence framework is a framework approach that provides persistence support
for object models. In this case, the proposed DMAPI will use this framework to map its
objects and relationships between objects to the information stored in XML documents.
Storing these objects in semi object-oriented XML documents require knowledge on XML
schema extension and solid understanding of SOAP implementation. Ideally, a single
integrated model that describes both approaches and relationships should be implemented.
Fortunately, both object modelling and XML modelling are actually tremendously
63
compatible. This is because objects encapsulate code and data into a logical element, while
XML are more data centric with tree structure providing features such as elements and
attributes to store object data efficiently.
Traditional persistence framework defines a set of interfaces and abstract classes that are
used to store application objects persistently. Newest approaches include interfaces and
methods mark-up or decorating. With those implementations methods, the software
developers are freed from concerns of database architectural design, data storage, and
object management. The outcome is that the upgrades of the existing business or domain
can be developed faster, easier to maintain and enhance, and can run faster and more stable
without any compromise with the strong capabilities of object-oriented programming such
as polymorphism or inheritance. As a proof of concept, persistence framework has been
moved away from the object persistence and object management, and move towards the
core logic as a fundamental component of an object-oriented workflow management
system (Vossen et al., 1999).
3.4 Object-Oriented Software Engineering
As mentioned above, this proposed DMAPI will adopt object-oriented software
engineering methodology. Since the introduction of object-oriented software engineering
(OOSE) to software industries decades ago, it has been widely accepted as the de facto
standard for software development methodologies. It is an important approach for
software analysis and design process using object-oriented approach to analyse, design and
develop software solutions via object-oriented modelling notations such as Unified
Modelling Language (UML). One should know that by using object-oriented software
engineering approach, the final software solution developed will be more extensible,
64
reusable, modular, robustness and easily maintainable. Software systems that are designed
using this approach are composed of objects, and each of them has unique attributes and
behaviours. Apart from that, they also have features such as encapsulation, inheritance,
polymorphism, messages passing and so on, which will be elaborated in more detail in
Section 3.7. Moreover, object-oriented approach provides a more modular and extensive
methods of analysing and modelling the real problem domains via objects and classes.
This, in turn, will translate into clearer, reusable and easily understandable designs and
ultimately leads to better implementation and easily maintainable software solutions that
enable lower development time and maintenance costs.
In short, the benefits of using object-oriented software engineering approach is best
suitable in today rapidly changing software development world as it can accommodate the
dynamic changes of user requirements and technologies updates. This is especially true
because in today rapidly evolving knowledge industry whereby DMAPI solutions have
been greatly customised and designed to suit the complex demands of the knowledge
workers and advancing web technologies. Subsequently, this approach focuses on
identifying the core objects in the real problem domain, then analyse, design and model
these objects using UML notations before implementing them using an object-oriented
programming language. The following sections will elaborate how object-oriented
approach is implemented to perform the required analysis and design process of this
proposed DMAPI framework.
3.5 Object Analysis
The development of this proposed DMAPI prototype uses object-oriented software
development approach, which is incremental and iterative in nature. It is recommended for
65
providing best basis for object-oriented analysis and design. The first step in object analysis
is to produce characterisation of the business domain and definition of current business
processes and existing knowledge. Here, the distinctions between software artifacts that are
structured and unstructured are made. This characterization helps us to understand what
external knowledge factors are not covered, how existing software artifacts fit into the
layered architecture, and how it can be reused. Object analysis is a method of object-
oriented analysis that examines requirements from the perspective of the classes and
objects found in the vocabulary of the problem domain.
After the characterization of the layered organization, the roles for the DMAPI actors,
business domain objects and implementers are defined and use cases are developed based
on the general domain knowledge, processes and user roles. Actors are defined based on
the culture of DMAPI and the different types of roles that will be performed by different
organizations. Examples of actor roles are checking in, such as creating or add an existing
or a new document into the DMAPI repository; checking out to retrieve a document for
viewing or editing, and merge when a person who is responsible for maintenance of the
experience base.
Besides that, user roles can be refined for each main facet in an iteratively cycle. This rapid
prototyping of DMAPI is a highly iterative development life cycle that will help in reducing
any development risk and bug. Thus, this process uses an incremental and iterative life
cycle, which will be refined until all of its requirements are met. An example of this
refinement is an actor, i.e. the software developer, derived from a DMAPI user who is able
to access the basic functionality in DMAPI. Subsequently, use cases are defined based on
the characterization of the business domain, the application processes that are relevant to
66
DMAPI and the user roles. Usually, these use cases cover procedures that are already in
place and add new ones as required.
The next step is to define a data model, or classification, which is suitable for the system.
This data model will employ a XML persistence framework to serialize and classify the
software artifacts that will be included in DMAPI in order to make it easier for users to
retrieve and store the document. During this step, different types of artifacts will be
identified and classified. Finally yet importantly, testing procedures are also done in parallel
with the implementation of the defined classes in order to conform to the specified
requirements which otherwise will be fed back into the cycle for any re-analysis and re-
design process.
3.6 Object Models
The object-oriented software development approach encompasses five main models to
design and develop a concrete, reusable and robust DMAPI. Each of these models is
manipulated by different people that have specific interests and roles. The proposed object
models are as follows:
• Requirement Model – Responsible to capture abstract and high-level views of
functional requirements through use case model.
• Analysis Model – Responsible to build a reusable, robust and extensible object
structure. It does not deal with any low-level details of the implementation.
• Design Model – Responsible to build a more concrete and low-level details, which
express how the proposed system is to be implemented by transforming high-level
models, such as use case and analysis models into more detailed and low-level
model.
67
• Implementation Model – Responsible to build the implementation mechanisms
and detailed coding designs by implementing the detailed design in some
programming language to produce the working system.
• Testing Model – Responsible to describe how the final system will be tested and
conform the validity of other defined models by verifying all the system’s
requirements.
Most importantly, these five different models and the elements defined in above respective
models can be seamlessly connected with one another so that software developers are able
to track down changes from the requirements to these different models. Subsequently, this
will help in analysing the impact of any changes that need to be done. On the other hand,
this process also enables the software developers to take full advantage of these ready and
reusable models. All these models for the proposed DMAPI will be explained and drawn
in more detail in Chapter 4.
3.7 Object-oriented Programming (OOP)
This section describes the type of programming approach that will be used to develop the
proposed DMAPI and the main features of the selected programming language. Popular
OOP such as Microsoft .Net C# programming language has been selected to develop the
DMAPI prototype. By definition, object-oriented programming is a method of
implementation in which programs are organised as cooperative collections of objects,
each of which represents an instance of some class, and whose classes are all members of a
hierarchy of classes united via inheritance relationships (Booch, 1991). OOP is a new way
of thinking about the process of decomposing problems and developing programming
solutions (Budd, 1991). Specifically, any programming language without inheritance
68
support is distinctly not considered as object-oriented, but known as programming with
abstract data types. Generally, OOP has the following three important elements:
• Objects as its fundamental logical building blocks
• Each object is an instance of some class and classes
• Classes are related to one another via inheritance relationships
The mentioned OOP concept is applied in this proposed prototype implementation.
Hence, by implementing OOP in the proposed prototype, software representations of real-
world entities like developers or actors and document artifacts are modelled using objects.
Objects are characterized by its unique structure, such as its attributes or data, and
behaviour, such as a set of methods with signatures attached, which can be performed on
this data. Another feature of objects is that they communicate with each other via message
passing. Once an object receives a message, it will determine whether the respective
method is available or not, if in the case the method is available, it will be invoked and the
return values are sent back to the calling object. However, if there is no such method, then
the system will raise an exception error.
This object-oriented problem solving approach, in general, can be divided into four basic
steps. They are as follows:
• Identify the domain problem
• Identify the objects needed for the solution
• Identify messages to be sent to the objects, and
• Create a sequence of messages to the objects that solve the problem.
69
For this reason and others, OOP applied with persistence framework and layered
architecture does provide many great benefits to software development communities
today, such as reusability, robustness, maintainability, and so on. Besides, there are many
proven design patterns for object-oriented solutions, which can be referenced and applied
in this DMAPI framework. One of the most important features of object-oriented
programming is the ability to alter any existing solution to solve new domain problems. For
example, in a case where if a particular kind of problem has been solved using an OOP
approach, then a similar but slightly different problem can usually be solved by making
some changes in the existing object-message protocol. However, most of the time, by
changing this it would require adding some new messages or adding new objects and new
messages to those responding objects.
The following chapter will elaborate in more detail on three major features in OOP, which
will be implemented throughout the related classes of the proposed DMAPI in this
dissertation. Nevertheless, there are also many great benefits that can obtain from the well-
designed use of OOP in software development.
3.8 Summary
In conclusion, this chapter describes the selected methodology, techniques ands tools to be
used in this proposed DMAPI framework implementation. As we know that software is
naturally complex and the complexity of software systems often exceeds our human
intellectual capacity. Thus, we need to have systematic methodologies to lead us to design
and implement a better DMAPI. Some of the methodologies are described earlier and need
to be satisfied at every phase of the software development life cycle in order to address this
issue. For example, to apply OOP for object-oriented programming approach, layered
70
architecture for the system architectural design, XML persistence framework for
framework architecture and design pattern for the DMAPI framework design is to follow a
proven solution pattern in the same context. Therefore, these are guidelines on how this
dissertation implementation is based upon and will be implemented consecutively in each
phase of SDLC. .
Here, the overall programming approach used is object-oriented programming. Generally,
the object-oriented problem solving approach is very similar to the way human solve their
daily problems. To start, it consists of identifying the domain objects in the context and
how to use these objects according to the correct sequence in order to solve the problem
domain. In other words, object-oriented problem solving can consist of designing objects
whose behaviour can solve a specific problem. For example, a message to an object causes
it to perform its operations and solve its part of the problem.
Finally yet importantly, object-oriented programming is fundamentally different from
traditional functional programming because if we apply the approach correctly, it will lead
to development of very robust, easily expandable and maintainable code. One must always
remember that objects are everywhere around us, while the class they belong to is not
always obvious to capture.
71
CHAPTER 4 DOMAIN ANALYSIS AND DESIGN
In this chapter, the main objective is to discuss the overall domain analysis and design for
the proposed system in more detail according to object-oriented methodology. In order to
model this domain analysis and design objects in a well-planned object-oriented system
framework, a recommended language has been introduced, it is known as the Unified
Modeling Language (UML). As a matter of fact, UML can provide better methods of
analyzing and designing of object-oriented software requirements. A well-planned system
framework begins with the system development lifecycle that requires thorough analysis
and design phases before proceeding into implementation and testing phases.
These dissertation is aim to produce a working deliverable which is a prototype
implementation of the proposed DMAPI base classes without any business extension such
as SCV or portal. Moreover, there are great distinct in design goals between the
implementation of DMAPI bases classes and its implementation of the business extension.
Business extension is known as systems that involved in extending the basic functionality
of a system with additional domain-specific operations.
4.1 System Layered Architecture
As explained earlier, a layered architecture organises software component systems
according to generality. For example, at the top layer, an application system can be
composed from components, whereas these components can be composed from other
components in the lower layers. The Document Management System requires detailed
components classification and separation. This layered architecture is used to organize the
various components into manageable package according to its functionality, complexity,
72
domain classification and degree of generality. In most cases, the layered architecture also
varies according to the development environment used such as Microsoft .Net Framework.
According to the layered architecture model, the system architecture is the overall
organisation of the system into components known as subsystems, where the lower-level
subsystems and design classes are grouped together. This model is made up of the analysis
types and subsystems, which also includes their relationships. Figure 4-1 shows the layered
architecture for the proposed DMAPI. This layered architecture consists of layers of
different packages that interact with each other to perform their assigned tasks, where each
layer is built on top of another more general layer that resides below it. Hence, the lower
layer provides the basis for the implementation of the higher layer, however it has no
knowledge of the layer above it.
Figure 4-1 Layered Architecture
Package that included in DMAPI
Package that to be implemented by the Domain Specific Application
73
The topmost layer shows the application system layer for the proposed DMAPI, which is
the DMAPI Web Service Client. This layer provides the presentation tier whereby the
actors can interact with the application systems. Here, the DMAPI client can invoke its
exposed DMAPI web methods via the popular SOAP over HTTP. On the other hand, the
application system layer can be extended to provide alternative presentation tier to the
actors. This is shown through the two dotted packages in Figure 4-1, i.e. Web Pages which
are optional component in the DMAPI implementation. In the Web Pages package, the
actors can use any available browser to access the DMAPI services via HTTP. Then again,
in a traditional client-server environment, the actors can access the DMAPI service via the
Windows Form Application package.
Below this application system layer is the business specific layer, which consists of one
main component system known as DMAPI Web Service. This business related layer
provides the basis implementation of the business logic and rules for the application
system layer above it, whereas the middleware layer is a layer below it. One important point
of designing any software framework is to design a generic business logic skeleton
incorporated into this layer in every software project. Its business component provides the
components required by the application system via the façade of the component system.
Moreover, the business component designed to be able to reuse and extend by any
developer via their available objects and classes. There are three dotted packages shown in
Figure 4-1 in this layer, they are SCV, CMS and portal. These dotted packages are separate
extender domain applications, which will not be covered and implemented in this
dissertation.
The middleware layer consists of component systems or packages that offer the core
infrastructure and base classes needed to execute the proposed DMAPI. These packages
74
include the XML Persistence Framework, SOAP API and Security. XML Persistence
Framework package provides the methods mark-up facility to specify which class attributes
to be serialized. Hence, this XML persistence framework is vital to provide the core engine
for DMAPI to run, and all the packages and component systems are built on top of this
engine. In this case, SOAP package is used to offer web services in order to expose its
public business methods to Internet users’ usage via HTTP. Hence, web service APIs can
provide web services functionality and generation of WSDL (Web Service Definition
Language) to enable DMAPI to offer web services to its end-users. Besides being able to
provide client-server application purpose, the proposed DMAPI is more agile to Internet
technology upgrade and changes because web service technology is the current popular
technology in the business world. In fact, most of the existing DMS solutions in the market
are currently client-server based applications, though now more and more DMS vendors
are aware of this technology update and are moving towards web service technology.
Security package offers security APIs to the proposed DMAPI. This is important because
every system has to be guaranteed of its security, such as to protect the confidentiality and
integrity of the information stored in the repository.
The bottom layer, which is the system software layer, contains .Net Framework package.
This package can offer platform services and database connectivity services to the layer
above it.
4.2 Domain Analysis and Design for DMAPI
Generally, domain analysis and design process involves the process of engineering the
business domain itself instead of its detailed software component or package. A well-
designed business domain will not only increase the manageability of an application but
75
also the reusability of a business domain. Domain analysis can be used as an efficient
technique to better understand the target business and its needs for information system
supports. In fact, domain analysis is the identification and exploitation of commonality
across related systems. Moreover, it is an activity known for determining the common
requirements within a domain with the purpose of identifying reuse opportunities among
the systems in the domain. It builds a domain architectural model representing the
commonalities and differences in requirements within the domain (Laforme et al., 1995).
Here, the DMAPI domain has activities such as to login, check-in or checkout files,
retrieve the latest version of a document and so on. These activities are some of the
common activities occur across those related systems and hence can be implemented as
framework components.
One of the objectives of this dissertation emphasizes the reusability of object-oriented
methodology. In this case, the DMAPI domain application framework consists of several
subsystems that interact with each other because of communication requirement to
perform any transactions. Hence, only selected common abstraction of analysis and design
details should be taken into consideration to develop reusable component systems.
Ultimately, all these reusable components are designed to provide a generic and extensible
framework for potential extended systems in the problem domain for future reuse. An
extensive and robust framework will enable the reuse of analysis objects, design patterns,
software components and code. In addition, the proposed DMAPI framework consists of
several commonly used domain components and classes with association relationships
between the domain classes in the DMAPI subsystems. For example, the generic Login
package and Check-in and Checkout package can be reusable software components for
both DMAPI User and DMAPI Admin because both are using the same DMAPI services.
As a result, domain analysis and design processes are vital to produce reusable object-
76
oriented software components that will help to produce rapid software solutions and
eventually lower or cut development cost.
In domain software engineering process, developing software models are an excellent
starting point to define software architectures, find reusable components and develop
application systems that can provide value-added features for the domain extender. Thus,
in this case, the domain analysis and design process is modelled using Use Case Driven
approach as explained in the following section. This process is modelled using UML
standard.
4.3 DMAPI Use Case Model
In general, the main goal of the use case modelling is to capture the complete system
functionalities and reusable requirements of DMAPI in order for the system to satisfy
users’ requirements. A use case model is vital to use in the effective communication
between domain experts and system analysts or developers. This is because most of the
time, the domain experts and end-users might not be knowledgeable in software
architecture and design. As a result, a use case model is used to define what a system
should offer to its users and how the users can use the system. This modelling technique is
simple yet convenient and easily understood by any level of users without being
overwhelmed with too many technical details. From a business perspective, a business use
case is a series of work steps performed in a business system that produces a result of perceived and
measurable value to an individual actor of the business (Jacobson et al, 1999). Most importantly, use
case modelling is the first step in UML methodology to take when starting any software
development project.
77
In this case, the use case driven approach is adopted to build the required user requirement
models for the proposed DMAPI’s analysis phase. Here, DMAPI begins with two high-
level use case models as shown in Figure 4-2 and Figure 4-3 to describe the interactions
between the actors and the overall functionalities of the system. The actors of the system
include DMAPI system administrator, who is responsible to manage and administer the
overall DMAPI whereas the DMAPI users who are the actual actors using the system.
These use case models describe the kind of services provided by the proposed system to its
users by specifying how these responsibilities are allocated to the respective actors and their
interactions roles via the instances of the use case diagrams.
These roles include valid DMAPI system administrators, registered DMAPI users or
application developers. For example, the actors of this proposed system are typically
application developers, who can make use of the proposed DMAPI implementations to
extend more value-added services in their applications. On the other hand, DMAPI system
administrators are actors who can interact with DMAPI to manage the system and whose
security attributes are kept as important system state data during the use case behaviour
activities. The overall behaviour of DMAPI are defined as use case diagrams in use case
model based on the users’ requirements, such as login, check-in, check-out, retrieve latest
version and so on.
4.3.1 DMAPI Administrator’s Use Case Model
Generally, Figure 4-2 depicts the overall interactions between the DMAPI system
administrators’ roles and the underlying proposed DMAPI. Each of these use case
instances in the model reflects an important system requirement for the DMAPI system
administrator’s (admin) responsibility, which has been defined during the capturing of
78
requirements with the customers. However, in this case, we will not be covering in detail
for this use case model, as we will do so for the DMAPI users’ use case model. This is
because the scope of this dissertation emphasises how the generic yet extensive DMAPI
framework offers its many services to its users, and not much emphasis on the
administrators’ roles. This use case model consists of a set of use case diagrams that
describes what the system administrators can do with the system. For example, the admin
can login to the system, define root store, define user and role, assign public and private
store, assign quota and finally manage the users or roles profiles.
User
Login
Define Root Store
Define User & Role
Assign Public &
Private Store
Assign Quote
Manage User/Roles
Profiles
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
Figure 4-2 DMAPI System Administrator’s Use Case Model
79
4.3.2 DMAPI User’s Use Case Model
Figure 4-3 shows the main use case model of DMAPI that reflects the overall core
transactions, which are carried out based on the requirements of DMAPI users’ roles.
DMAPI end-users are allowed to perform the following operations or responsibilities, such
as login, create or check in new or existing files and folders, check out files for
modification, retrieve the latest version of the files and retrieve history version of the files
from the data repository. Besides that, they can also rollback the previous version of the
files if there is any break down during the transaction and is able to define Access Control
List (ACL) for their files’ security level attributes. All these defined use case behaviours are
core responsibilities of the proposed DMAPI. Hence, this is the area that we will be
focusing in detail to deliver a working prototype of DMAPI based on these use case
behaviours.
80
Figure 4-3 DMAPI User’s Use Case Model
4.4 DMAPI Analysis Model
The next stage of this proposed DMAPI development life cycle is to focus in-depth on the
system design details. This stage is done in an iterative and incremental cycle until the full
architecture of DMAPI becomes clearer. During the analysis model process, we will
identify the core objects that will collaborate to carry out DMAPI’s use case behaviours.
Subsequently, an UML collaboration diagrams is developed to describe a high-level view
on what tasks DMAPI performs but not how it performs them. Hence, this analysis model
81
will consist of participating analysis objects or classes that are responsible to perform the
use cases’ behaviours and will be elaborated from the use case instances drawn in Figure
4-3. Based on the layered architecture mentioned, these objects are originated from the
component that represent the business specific layer. Thus, a use case can be spanned
across different layers of the system architecture whereby it can represent business
components from the business specific layer and application components from the user
presentation layer in the application systems layer. The detailed design of these component
systems or use case instances can be illustrated using three kinds of analysis objects or
classes from the collaboration diagrams, they are boundary, control and entity objects.
Each of the use case instances illustrated in Figure 4-3 can be mapped to their own
collaboration diagrams, which will be shown in the section 4.4.1 and onwards.
Furthermore, each of these collaboration diagrams will elaborate on how the analysis
objects interact and participate together to perform its respective use case behaviours.
Subsequently, these diagrams also illustrate the relationships between the participating
analysis objects during their interactions. With this, we can trace from this high-level
analysis model to its respective high-level design model later on. As a result, in this analysis
model, all use cases drawn in Figure 4-3 should be analysed and detailed out with defined
boundaries, interfaces, and controls objects using collaboration diagrams. Having these
three distinct analysis objects of boundary, control and entity will help to design DMAPI
when identifying and specifying the objects in collaboration diagrams. There are six use
cases identified from Figure 4-3, namely the Login, Check Permission Base Facade, Check
In/Out files, Retrieve Previous Version, Rollback Previous Version, and lastly Define
ACL. Among these diagrams, most of them have demonstrated the DMAPI’s abilities and
objectives, which are reusability and extensibility, whereby each of them is able to import
and reuse packages between them in order to extend their use case behaviours.
82
4.4.1 Login Collaboration Diagram
Referring to Figure 4-4, this collaboration diagram is traced from its respective use case
instance, i.e. Login shown from Figure 4-3. This diagram depicts that an interested DMAPI
User who wishes to login to DMAPI before he or she can start using the system. Any
users, regardless of DMAPI Users or DMAPI System Administrators, who wish to access
the DMAPI, have to perform the Login function before entering the system. Here, the
actor stereotype, i.e. <<actor>>, represents the DMAPI User. On the other hand, a
boundary object known as Login Interface represents the login user interface. In addition,
there is another boundary object known as Inform User Interface, which is responsible to
send the confirmation message across to the DMAPI User to inform the user of the login
result. These boundary objects separate the user interface from its business components.
From Figure 4-4, Match User Name and Accept & Store User Token are the control
objects that depict the back-end login mechanism. The following list shows the control
objects that are responsible to perform the Login user case scenario.
1. The first control object is in charge to match the user name and password with the
user list that represents an entity object, i.e. Access Control List (ACL).
2. Consequently, once the matching process has completed successfully, then the
Accept & Store User Token control object will accept and return a valid user token
(Object ID).
3. Then it will store the valid token as session data and assign a predefined expiry
time for this token and it is transformed into a Session Store entity object.
83
4. Session Store entity object persist the user token data to a data storage as long as
the user is still accessing DMAPI because it is needed every time the user access
any resource in DMAPI to validate the user’s security credential.
5. This security check is vital in order to prevent any unauthorised user to access the
system.
6. Finally, the Inform User boundary object represents the interface that displays the
login result back to the user.
7. If an unauthorised user were to try to login to the system or a wrong password is
entered to the system, then the Login function would reject the user and display a
message back to the respective user.
8. On the contrary, if an authorised user were to login to DMAPI, then the system
would display a successful login message via the Inform User interface. Therefore,
this security feature of checking users’ permissions will be elaborated further in
Figure 4-5.
84
Login
DMS User
Login
Interface
Match
User
Name
ACL
Accept &
Store User
Token
Session
Store
Inform
User
Figure 4-4 Login Collaboration Diagram
4.4.2 Check Permission Base Facade Collaboration Diagram
Figure 4-5 depicts that the internal check permission base facade collaboration diagram
imports Login package from the Login use case scenario shown earlier. Here, this diagram
has illustrated more in depth and extended the Login collaboration diagram in order for
DMAPI to perform further verification of user’s permission credentials after the login
process. One of the vital reasons for this security verification is to allow the system to
check for user’s permission every time when the user accesses the resources from DMAPI
to verify whether he or she has a valid access to the requested resources from DMAPI.
Through this base facade, the system checks for the user’s permission once the user has
login successfully to the system via the Login package. Here, the Verify User control object
will perform verification of the user’s identity, and then the control execution will pass to
Verify Session control object to verify the user’s session data with the user’s role or
85
permission. Once the latter control object has completed its processing, it will return a
message back to the User via a boundary object. In this case, there are two possible
decision making flows where if the user has the valid permission, then the control will
display an accept message via the Accept boundary object. User or developer can then
execute or issues other operations via the DMAPI without verifying the valid user again
since the session is stored. However, if the user does not have the authorised permission or
a valid session to access the system, then the control will reject his or her request and
display a message back to the user via the Reject boundary object. Any further operations
attempted to execute on the server is blocked.
Checking Permission Base Facade
User/Developer
Verify
User
Verify
Session
Accept Reject
Session
Store
Custom
API
Figure 4-5 Check Permission Base Facade Collaboration Diagram
4.4.3 Check In/Out Files Collaboration Diagram
Figure 4-6 illustrates the check in and check out collaboration diagram, which can be
mapped from the Check In use case and Check Out use case of Figure 4-3. Similarly, this
figure uses and extends the Check Permission Base Facade collaboration diagram as shown
in Figure 4-5. As mentioned from the start, DMAPI is designed to be a reusable and
extensible framework, therefore we can import and extend from its base use case
behaviour and transform into another use case behaviour. In this case, this diagram
86
illustrates that when a user wants to check in or check out any software artefacts or files, he
or she has to go through the DMAPI Check Permission Facade package to verify his or
her authorised permission before allowing them to check in or check out the requested file
to or from the system. When the system has identified his or her permission, then the
Check In/Out control object will assign the check in or check out attributes to the
resource and subsequently passes to File Store control object to stream in or out the
requested file via the Stream In/Out boundary object back to the user.
Check in/out files
User
Check In/Out
Stream In/Out
File Store
-UserSession
1..1
Verify Session
-File Info1..*
1..*
-File Info
1..*
-File
1..*
1..*
-File Stream
1..*
Figure 4-6 Check In/Out Files Collaboration Diagram
4.4.4 Retrieve Previous Version Collaboration Diagram
Figure 4-7 uses the Check Permission Base Facade shown in Figure 4-5 to import the
Check Permission Base Facade package into this collaboration diagram. Here, when a user
wants retrieve his or her previous file version from DMAPI, again the system will check
for his or her permission before allowing him or her to retrieve the requested previous file
version. Similarly, after the Check Permission Base Facade package, the process is passed
to Retrieve Previous Version control object to assign and retrieve the previous file’s
attributes from the system. Following that, the File Store control object will perform the
87
task to stream out the requested previous file version via the Stream Out boundary object
back to the user.
Figure 4-7 Retrieve Previous Version Collaboration Diagram
4.4.5 Rollback Previous Version Collaboration Diagram
Likewise, Figure 4-8 imports the Retrieve Previous Version package from Figure 4-7 into
this collaboration diagram. This diagram illustrates that when a user wants to rollback the
previous version of the file after he or she has retrieved the requested file from DMAPI.
This scenario happens in the case when the user has retrieved the requested file but due to
some circumstances, the user might want to rollback the action and restore back to its
previous unchanged state. Therefore, the Destroy From That Version Onwards control
object will destroy and rollback all the data from the previous done action, which has gone
through some update, and finally restore them back to their original data state before the
retrieval.
88
Figure 4-8 Rollback to Previous Version Collaboration Diagram
4.4.6 Define Access Control List (ACL) Collaboration Diagram
With reference to Figure 4-9, again here it imports the Check Permission Base Facade
package shown in Figure 4-5 into this collaboration diagram. This use case behaviour is
important as it allows the DMAPI user to define their file’s access control list attributes in
order to enforce the file’s security feature, so that the DMAPI user can manage any user
who has access, such as read and write access, to the respective file. Therefore, this diagram
illustrates that the user can define a new access control list for a file if there is no existing
entry for the file. Firstly, before the user can define an ACL entry for a file, the system will
check for the user’s permissions via the Check Permission Base package. Following that,
the user will interact via the Select File System Object(s) boundary object to define the file’s
ACL attributes. However, before allowing the user to define an ACL entry, the system will
check for any other existing ACL entry for that respective file via the Check Existing Entry
control object. If there is no ACL entry for the file, the system will add a new principal by
adding new user’s roles with permissions via the Add New Principal control object to
define a new ACL entry for the file.
89
Define ACL
Check
Existing
Entry
Select File
System
Object(s)
Add new
principle
Verify
Session
Custom
APIPermission
Store
User/Developer
Figure 4-9 Define ACL Collaboration Diagram
4.5 DMAPI Design Model
In an object-oriented design model, design diagrams are drawn to illustrate the life cycle of
design decisions on how to solve and implement the DMAPI’s architecture. To solve any
design domain problems, it is a life cycle of iteration and increment stages from the top-
levels towards the detailed low-levels. During the transition phase from object-oriented
analysis to object-oriented design phase, more details related to the implementation phase
are revealed and implemented in the design model. On the contrary, the analysis model
revealed more of the high-level details. Sequence diagrams belong to the design model that
holds the design diagrams. Consequently, the design model is structured into several
sequence diagrams, which are obviously traceable and map from the use case models and
collaboration diagrams drawn previously. Hence, this shows that they can be derived from
their analysis models to their respective design models. Generally, UML interaction
diagrams can capture the behaviour of a use case and demonstrate the sequence of
information flows between the interacting objects by describing how these objects
collaborate to perform their tasks. Therefore, sequence diagrams are one of the interaction
diagrams used to model the dynamic behaviour of the use case instances. These use cases
90
can be traced from collaboration diagrams to sequence diagrams. Nonetheless, the use case
instances drawn in the use case model earlier are mapped to illustrate the details of
information flow and operations using sequence diagrams.
In this section, we will depict further the information flows among the component systems
identified in the earlier sections via sequence diagrams. A sequence diagram is vital to show
detailed messages or data flow and operation details during the design phase before the
actual implementation takes place. Moreover, these diagrams are able to reflect the
behaviour of the objects and their respective activities occurred during their interactions
with other related objects. Normally, UML sequence diagrams are used to guide developers
where to put the classes’ operations based on the methods assigned to objects on the
sequence diagrams.
4.5.1 Login Sequence Diagram
Figure 4-10 shows the login sequence diagram that can be mapped from its collaboration
diagram in Figure 4-4. In order to login to DMAPI, the first step is that a user needs to key
in his or her own username and password, then the system will validate and check the
entered username and password with the system’s ACL. If the system can match the
entered username and password with the define system’s ACL, then the system will accept
the login and store the user session data to the Session Store object for as long as the user
still login to the system. Conversely, if the user entered an invalid username and password,
the system will not be able to match any entry in the system’s ACL with this username and
password. Subsequently, the system will fail and reject the login by sending back a reject
message to the user.
91
DMS Clien User Manager Session Store
Key in Username & Password
ACL
Check Username & Password with ACL
FailPass/Fail
Accept & Store SessionPass: Return Session Token
Fail: Reject user
User/Developer
Login
Login Status
Figure 4-10 Login Sequence Diagram
4.5.2 Check Permission Base Facade Sequence Diagram
Figure 4-11 depicts the process flow for Check Permission Base Facade sequence diagram.
As mentioned earlier in its collaboration diagram in Figure 4-5, it has imported the Login
package into its respective collaboration diagram. Hence, its corresponding sequence
diagram, which can be mapped from its collaboration diagram, also extends the above
Login sequence diagram. Firstly, after a user has login to DMAPI, the system will check for
the user’s permissions by verifying the user’s roles against with the user permission entries
in the system. Moreover, at the same time, the system verifies the user’s session data with
the session data store. Based on the user’s permission verification result, the system will
accept or reject the user’s permission to access the system resources. Lastly, the system
displays accept or reject message to inform the user about the results.
92
Figure 4-11 Check Permission Base Facade Sequence Diagram
4.5.3 Check In/Out Files Sequence Diagram
Figure 4-12 illustrates the sequence of processes occurred when the user performs any
check in/out of file(s) from DMAPI. This figure simultaneously shows the two sequence
diagrams side-by-side for check in files and checkout files. The diagram on the left-hand
side (a) depicts the check in process, whereas the right-hand side (b) depicts the check out
process. In the case of checking in a file happens when a user decides to check in or store
the file through DMAPI in a repository, then the user must first initialise the permission
facade with the system, which will then cause the system to check and verify for the user’s
permissions with the ACL. After the system has successfully checked the user’s
permissions, the user must prepare the file stream to create a copy of the file before
sending or uploading the respective file to the DMAPI repository. Once DMAPI receives
the file, it will acknowledge the user by sending back the acknowledgement to the user, and
finally store the respective file into the system repository. There are not possible for users
uploading the same file since the file is locked once the access request is performed.
93
Similarly, when a user wants to perform some update or just to read the file stored in the
system repository, the user has to check out a file from the DMAPI repository. Firstly, a
user needs to initialise the permission facade with the system, so that the system will
perform the permission checking process against the user’s permission with the ACL.
Secondly, the user will send a request to the system to invoke the system to prepare the file
stream for that respective file. Once it has completed the file stream, the system will send
the file via the file stream object and download to the client’s side by creating a local copy
of the file on the client’s local file system. By having the copy of the file at the client’s side,
the client can read or simply modify the file content locally before checking in the file to
the DMAPI repository for storage without affecting the copy of the same file at the
system’s side.
DMS Client WebStream
Initialize permission facade
Prepare local file stream
Return check in stream
Request check in stream
Upload file(s)
Acknowledgement Acknowledge
System.IO.FileInfo
Open/Create File
File Handler
Commit/Store the file(s)
User/Developer
New/Existing File
Operation Status
(a)
(b) Figure 4-12 Check In/Out Files Sequence Diagram
94
4.6 DMAPI Class Diagrams
After using the sequence diagrams to show the message flows between the underlying
interacting objects, we will proceed to develop the design classes and the relationships
between the objects using UML class diagrams. Here, the objects discovered during the
previous analysis phase can serve as the framework for the design phase in order to design
the classes. Additionally, when designing from analysis classes to design classes, we can
reveal and discover more details that are related closely to the implementation phase.
Object-oriented analysis and design involves the process of identifying and designing of
objects, and representing them using class diagrams. In general, class diagrams are the
backbone of almost every object-oriented methods including UML. By having a class
diagram, we are able to describe the static structure of any software system. According to
Object Management Group, UML class diagrams are the mainstay of object-oriented
analysis and design. Hence, UML class diagrams are able to show the classes of the system,
their inter-relationships (including inheritance, aggregation, and association), and the
operations and attributes of the classes. On the other hand, class diagrams can be used for
a wide variety of purposes, including during both conceptual or domain modelling and
detailed design modelling. A design class can represent a class with more detailed and
high-level view from the system’s implementation. However, when designing and refining
the design classes, new classes can be added, deleted, spitted or even joined in an iterative
and continuous cycle.
4.7 DMAPI Security Design
The following section elaborates the design class’s structure for DMAPI security features.
In any application system, security features should be implemented into the system to
95
protect confidential and privacy of the system repository from any unauthorised access and
hacking. Therefore, many efforts were carried out during the design phase to design and
enforce security features into DMAPI. The DMAPI’s security is designed to allow other
extender applications to integrate its underlying security authentication technique into the
extender applications without developing from scratch.
The logic behind it allows a user to access a file from DMAPI repository, the system has to
check for the user’s permissions or roles against the access control list that defined the
user-based authorization for each resource in the system. Before a user can access to any
resource from the system repository, DMAPI has to authorise the user’s access to the
resource. To do this, it has to first authenticate the source of the request, then the session
token is returned to the requester for further operation. The user can use the session token
to request other resource information such as the owner of the resource, access control list,
date last modified and etc. Transaction of each operation is kept as well.
Figure 4-13 shows the design class diagram for Access Control List (ACL) class, ACLEntry
class and the ISupportACL Interface that needs to be implemented by any object or
artifact to control its user access management, for example in this case is the Document
class. Referring to Figure 4-13, in any system repository, an object or rather resource
should have access control properties to control the resource access, which will be defined
in an ACL class.
96
ISupportACL
+ACL()
+Add(in value : ACLEntry) : int
+Add(in value : object) : int
+Contains(in item : ACLEntry) : bool
+Contains(in principal : Principal) : bool
+Contains(in item : object) : bool
+Remove(in obj : ACLEntry)
+Remove(in guid : Guid)
+Remove(in obj : object)
+Remove(in principal : Principal)
+this(in index : int) : ACLEntry
+this(in principal : Guid) : ACLEntry
-guids : Hashtable = new System.Collections.Hashtable()
ACL
+ACLEntry()
+ACLEntry(in principal : Guid, in permission : Permission)
+Principal() : Guid
+Permission() : Permission
+PrincipalName() : string
+ToString() : string
-ToPrincipal() : Principal
-principal : Guid
-permission : Permission
-name : string
ACLEntry
+Owner() : Guid
+ACL() : ACL
+Document()
+Document(in path : string)
+Path() : string
+Exists() : bool
+CreationTime() : DateTime
+LastAccessTime() : DateTime
+LastWriteTime() : DateTime
+Length() : long
+Name() : string
+GUID() : Guid
+Operation() : Operation
+ReadStream() : Stream
-path : FileInfo
-guid : Guid = System.Guid.NewGuid()
-operation : Operation
-acls : ACL = new ACL()
-root : string
-owner : Guid
Document
1 0..*
Figure 4-13 Access Control List (ACL) Class Diagram
DMAPI will then use this information to perform the authentication and access control
transactions when there is a user requesting the resource from the repository. As a result,
the users benefit from certain security services provided by the DMAPI security
framework, such as automatic authentication, access control list, automatic permission
checking, artifact lifecycle management, and so on.
The primary purpose of the ACL features is to control and provide security services for the
objects or artifacts it contains. When it needs to use some underlying functionality, such as
checking permission on behalf of a user, it uses the facilities of the underlying DMAPI
security framework. DMAPI security framework is the base set of services on top of which
the ACL runs. In order for an object to support the permission attributes, it must
implement the ISupportACL interface as shown in Figure 4-13. This interface contains
attributes such as Owner token and ACL. Besides that, by having the Owner attribute,
97
ISupportACL interface allows any form of owners such as role or user that can extend the
Principal base class. Moreover, this class allows the objects to include lists of access control
entries. For example, an object can grant user A with permission Read and Write but grant
user B with permission Read only.
Figure 4-14 Principal Base Class
In this domain context, a Principal means a user and/or owner of a resource in the system
repository. It is an implementation class borrowed from Java 2 technology. As shown in
Figure 4-14, principal serves as the base class for the Manipulator objects. These Manipulator
objects include group, role, user, and owner, which have extended the model. Although
these classes extend the same base class, they are different in nature. In class diagram, the
objects such as User or Owner might have user name and password however, Group or
Role might not have it. A group is an entity that consists of several users which having the
same role. For example, Wong and Lee are users that belong to a group which having the
same Admin role or rights. In addition, a user can have two different roles. One of its
98
popular extender applications in this case is X.509 Certificate, which provides a standard
way to access all the attributes of an X.509 Certificate.
4.8 File System Design
The term File System Object is most popular known as FSO in short among software
developers, especially those familiar with Microsoft Visual Basic or .Net programming, to
access files from the system. The FSO model provides an object-based framework for
working with folders and files that reside in the computer systems, which is in line with the
objectives of this dissertation. This is because it permits developers to use the familiar
object method syntax that comes with a rich set of properties, methods, and events to
process folders and files. Moreover, for Visual Basic developers, they can utilize the
traditional Visual Basic statements and commands when using FSO. By implementing the
FSO model here, it gives DMAPI the ability to create, alter, move, and delete folders.
Alternatively, it even can determine if and where a particular folder exist in the system. It
also enables the developers to retrieve the information about the folders, for example, their
names and the date they were created or last modified. The FSO model makes processing
files and folders much easier than last time. When processing files, our primary goal is to
store data in an efficient, easy-to-access format. This is because users need to be able to
create files, insert and change the data, and output or read the data. Although we can store
data in a database, doing so adds a significant amount of overhead to the application. We
may not want to have such overhead, or DMAPI data access requirements may not call for
the extra functionality associated with a full-featured database. In this case, storing data in a
text file or binary file is the most efficient solution. Like our physical file system in
computers, FSO acts as the file system entry or file allocation table (FAT) entry in this
99
DMAPI context. It can be a file or a directory that the user checks in and checks out from
the system repository. In the case of DMAPI here, the entry can allow only directory.
FSOFolder
FSOEntries
FSOEntryFileVersioned File
ISupportACL
Owner : IPermission
ACL : ACL
(from ACL)
Figure 4-15 File System Object (FSO) Class Diagram
Referring to Figure 4-15, these high-level FSO design classes depict that a file allows any
number of attachments or versions to be included together into the File class, which is
defined under the directory behaviour attribute. From the diagram, the most common class
relationship that occurs between these FSO classes are actually inheritance relationships.
To illustrate the inheritance relationships here, we can start to take the FSO base class as
the starting point for the inheritance relationships because it is the parent class for all its
child classes below it. For example, a FSO base class can be inherited by a Folder class that
is packaged with FSOEntries as one of its attributes. Subsequently, FSOEntry class inherit
the Folder class. At the same time, a File class can inherit from a Folder class and
FSOEntry class. As we go down to the most low-level details of FSO structure is the
Versioned File class, which it inherits the File class, which then inherits the Folder class at
the top. In short, FSO base class is the top-most base class that all of its child classes
100
should be inherited. As discussed earlier, FSO will host all the permission attributes via the
ISupportPermission interface, shown using ISupportACL class in the class diagram. As a
result, the security requirements of checking of resource access authorization are done via
this interface.
4.9 Sample of Component Facade Packages for Extender Applications
Since the primary objective of this dissertation is to design an extensible DMAPI
framework, some of the base classes are designed in such a way that can be packaged into
facade for further reuse purposes in potential extender applications. In this section, we are
going to explain briefly some of the potential extender applications, which can reuse and
extend DMAPI’s robust and extensible component facade packages. Nevertheless, we will
not be implementing these extender applications but to demonstrate the ability of DMAPI
framework to be able to extend to build another application on top of its base classes. For
instance, some of the reusable classes are the ACL classes shown in Figure 4-13 and FSO
classes shown in Figure 4-15.
So far, we have explained in the earlier chapters that SCV and portal are some of the
potential extender applications of this DMAPI framework. For example, SCV can extend
both ACL and FSO packages to provide code versioning services to store and manage
codes more efficiently. Moreover, additional functions such as add, delete, rename, and
move files or folders, are originated from the basic file system operation (FSO) package
(Eklund & Cole, 2002). In fact, the Retrieve Latest Version and Get History Version use
case instances shown in Figure 4-3 are extended facades from the FSO package. However,
the details of this package will be discussed further in the next chapter. Although SCV and
Portal are some of the samples of the potential extender applications, where there are
101
capable of extending the DMAPI base framework and build new application context on
top of these extender applications.
Nevertheless, SCV and Portal implementations will not be covered in this dissertation’s
scope, but Figure 4-16 will briefly outlines the design expansion of using DMAPI use case
packages to create SCV and Portal use case packages for developer and public user
respectively. To illustrate the SCV package that resides on the left-hand side from a use
case view, it simply depicts that a developer can merge any two or more files or software
artitfacts using the exposed APIs of the FSO classes in their applications. While the Portal
package at the right-hand side shows from a use case view that a public user with efficient
read access permission can read the contents retrieved from the Portal repository because
Portal package can extend and import the ACL classes from DMAPI class packages.
SCV
(from Use Case View)
Merge
DMS
(from Use Case View)
Developer
Portal
(from Use Case View)
DMS
(from Use Case View)
Read ContentsPubl ic User
Figure 4-16 SCV and Portal Use Case Diagrams
In other words, because DMAPI contains reusable classes such as File and ACL classes,
we can also model the above view using some high-level class packages to form different
perspective view. Referring to Figure 4-17, it depicts how DMAPI class facade package can
be extended to create simple SCV class package demonstrating using only the FSO classes
and ACL classes. Referring to the diagram, the high-level File class from FSO in the
102
DMAPI facade package is designed to be an extender into source code file via the File class
down to the Code class. For instance, the check in and check out methods in File class of
the DMAPI’s FSO package can be overridden in the extended File class of the SCV
package to provide some special functionalities to handle application source code and
versioning features. On the other hand, the ACL class from ACL package can use to
enhance further the security requirements of an application for advanced developer. For
example, the Document Author class can be served as facade for the developers via the
ACL class. Moreover, the ACL class is designed to provide security services for its users,
such as the document authors or owners, in order to control and manage their software
artifacts in the DMAPI repository.
SCV
DMS
DMS
(from DMS)
<<Facade>>
ACL(f rom ACL)
ACL'(f rom SCV)
File(f rom FSO)
File'(f rom SCV)
Code(f rom SCV)
Figure 4-17 Sample of Extender Applications’ Framework
103
4.10 Conclusion
In conclusion, the overall of this chapter describes how to use domain analysis and design
methodologies using object-oriented techniques and UML standards to design and draw
the use case model, analysis model and design model domain for this dissertation. Besides
that, it also covers how to apply the layered architecture design into separating the different
packages and component into their specific layers according to their specific
responsibilities. As explained in Chapter 3, these methodologies are essential to apply here
in this dissertation because they are recognised object-oriented software development
standards that are used to develop good quality software design and architecture, which will
be able to deliver reusable, extensible, and maintainable software components. The study
of UML use case driven approach is applied to capture DMAPI users’ requirements and
develop the use cases for DMAPI, which formed the fundamental use case model for
analysis, design and implementation models to be built.
There are several different models drawn in the previous sections, which include use case
model, analysis model and design model. Use case model consists of use case instances for
DMAPI system administrators and DMAPI users to capture the requirements of what the
system has to offer to its actors and what the actors can do with the system. While the
analysis model contains several collaboration diagrams that can be traced from their
respective use cases in the use case model. Developing these diagrams illustrates what the
DMAPI use cases’ behaviours do rather than how these use cases do it. Following that, the
designing process proceeded to develop design model that contains UML sequence
diagrams and class diagrams. Sequence diagrams are interaction diagrams, which can be
traced from their corresponding collaboration diagrams, to model the DMAPI use cases’
behaviours and the information flows between the objects. To facilitate the creation and
104
discovery of design classes in class diagram, sequence diagrams can use to discover the
design classes together with their attributes, methods, and relationships such as
associations, inheritance and so on. Nonetheless, these design classes still depict high-level
view to give an overview picture of the class structure. Using object-oriented techniques,
these high-level design classes shall be refined and detailed out the class structure iteratively
until they fully resemble the actual working software architecture during the
implementation stage. During the implementation stage, these classes provide clearer
pictures as they will be developed into full-blown class diagrams packaged with details of
class attributes, methods and relationships between the interacting classes in the next
chapter. Lastly, this chapter also briefly discussed on the conceptual design of the potential
extender applications such as Portal and SCV, which can be extend and derive from the
DMAPI base framework by importing the reusable component facade packages from it.
105
CHAPTER 5 SYSTEM IMPLEMENTATION AND TESTING
The implementation of DMAPI is organised according to layered architecture as described
in Section 4.1. The functional logic for each layer is categorised into packages or
namespaces. Subsequently, several tools are chosen to draft, build and test out the idea.
During these processes, various programming and testing techniques are being used. The
final step of the implementation involves the integration between the web service client
and web service server. In this step, numerous performance tests are conducted to identify
the bottleneck of the implementation. The results of these tests as well as future
improvements are concluded in Chapter 6.
5.1 Application Development Environment
The development of DMAPI is carried out using several hardware and OS platforms.
There are three server machines used in this development environment; one server
machine is used for development purpose and two machines are used as testing servers.
Whereas the completed DMAPI web service client is deployed onto another workstation
machine. Basically, web service server and web service client are deployed on separate
machines during the testing stage. As for the OS platforms, there are Windows 2000
Processional, Windows 2000 Advanced Server, Windows XP Professional and lastly
RedHat Linux 9.0, which requires Mono .Net runtime to execute DMAPI. Figure 5-1
shows the hardware and software specifications used in the DMAPI implementation.
106
Figure 5-1 Application Development Environment
DMAPI Development
Server
DMAPI Testing Server
1
DMAPI Testing Server 2
DMAPI Client Workstation
Operating System
Window 2000 Professional
Window 2000 Advanced Server
RedHat Linux 9.0
Window XP Professional
Processor Speed
Pentium III 800Mhz
Pentium IV 1600Mhz
Pentium IV 1600Mhz
Pentium III 800Mhz
RAM 512 MB 1024 MB 1024 MB 512 MB System Layer Software
.Net Framework .Net Framework
Mono .Net Framework
The first step of the development process involves selecting the appropriate tools for
drafting the system. Rational Rose 2000 and Visio 2003 Enterprise Architecture had been
used to design the system. Rational Rose 2000 is used to generate the initial classes and
interfaces. However, using these tools during the development and coding processes have
caused some difficulties in arranging and formatting the code, therefore some diagrams are
drawn after the development process via reverse engineering option. For documentation,
NDoc is used to generate the system documentation instead of using Rational Rose to do
the task. Finally, the classes and interfaces generated with Rational Rose will be ported into
Visual Studio .Net for further coding development. In this dissertation, Visual Studio .Net
2002, 2003 as well as 2005 Beta are used.
5.2 Layered Architecture Implementation
As explained in Chapter 4, Figure 4-1, layered architecture organises software component
systems according to generality. At the top layer, there is DMAPI client package which
consists of the presentation tier of user interface. In this layer, all user interactions and
requests are captured before being sent to the DMAPI web service package for processing.
107
The DMAPI Client package depends heavily on the DMAPI web service package which is
located directly below it. There are four main classes in the web service package to provide
operations for all the DMAPI clients’ requests. These classes are FileManager,
UserManager, WebService and WebStream. Table 5-1 describing the features for each class
together with the correspondence class diagram attached with additional private helper
methods.
Table 5-1 Main Classes Features
Class Features
FileManager
+FileManager()
+GetRoot() : Folder
+GetFiles(in folder : Folder) : File[]
+GetFolders(in folder : Folder) : Folder[]
-ToRootName(in path : string) : string
-ToAbsoluteName(in path : string) : string
-ToUNCName(in path : string) : string
-ToFiles(in parent : Folder, in files : FileInfo[]) : File[]
-ToFolders(in parent : Folder, in dirs : DirectoryInfo[]) : Folder[]
+GetDocumentInfo(in uncPath : File) : Document
+ChangeOwner(in token : Guid, in uncPath : string)
+AddACL(in token : Guid, in uncPath : string, in principal : Guid, in type : Permission)
-ToPermission(in principal : Guid) : Principal
+RemoveACL(in token : Guid, in uncPath : string, in principal : Guid)
DMS::FileManager
All functions are used with valid session token and owner rights.
• Get the root folder from the DMAPI system.
• Get all files from a given folder.
• Get all subfolders from a given folder.
• Get document/file information.
• Change the owner of the document.
• Add access control list (ACL) entry to the document.
• Remove ACL entry from the document.
UserManager
All functions are used with valid session token and administrator rights.
• Login to the DMAPI.
• Logout from the DMAPI.
• Get users information.
• Add user
• Remove user
• Get roles information.
• Add role
• Remove role
108
• Get user role
• Add user role
• Remove user role
WebService
All functions are used with valid session token.
• Start the DMAPI service.
• Stop the DMAPI service.
• Check in document.
• Check out document.
• Define local/work folder.
• Remove defined local/work folder information.
WebStream
All functions are used with valid file token.
• Gets a value indicating whether the current stream supports seeking.
• Gets a value indicating whether the current stream supports writing.
• Closes the file and releases any resources associated with the current file stream.
• Clears all buffers for this stream and causes any buffered data to be written to the physical file system
• Gets or sets the length in bytes of the stream.
• Gets or sets the current position of this stream.
109
• Reads a block of bytes from the stream and writes the data in a given buffer.
• Writes a block of bytes to this stream using data from a buffer.
The classes defined in Table 5-1 are the core logic implementation of DMAPI. Its depend
heavily on other entity classes such Document (Figure 4-13), ACL package (Figure 4-14),
and FSO package (Figure 4-15).
These classes handle all domain requirements as well as document management concept to
translate the requests from the clients to results. Figure 5-2 below shows the instance
declaration for classes described above.
public class Explorer : System.Windows.Forms.Form
{
...
private FileManager.FileManager fm;
private WebService.WebService ws;
private WebStream.WebStream wstream;
private UserManager um;
private SessionToken token;
...
}
Figure 5-2 Core Class Declaration
Conversely, three dependent classes are written in the middleware layer to provide key
communication bridge between the bottom layer and DMAPI. The bottom layer consists
of several significant specifications implementation such as XML, (Web Service Definition
110
Language) WSDL and SOAP. All the packages are designed to work together to facilitate a
basic workable solution for DMAPI.
5.3 The Web Service Interface
All client and server communications rely heavily on Web Service Protocol, services or
components that can be used on the Internet to provide new value-added services by
combining various Web services without the need for manual input. Web service uses
XML-related technologies such as SOAP as the communication protocol, WSDL as the
interface description language, and UDDI for registering and searching services.
Table 5-1 in Section 5.2 contains five major classes in DMAPI server application. Four of
them are implemented using Web Service technique. In other words, those features belong
to these classes are implemented with web method too. To implement a web method,
WebMethod attribute is added to a method within an XML Web service. This makes the
method callable from remote web clients.
Since the client and the server are interacting via this web method, some kind of contract
must be defined in order to ensure this interaction was not disrupted. The Web Services
Description Language (WSDL) is an XML format for describing the network services
offered by the server. WSDL is used to identify the services provided by the server and the
set of operations within each service that the server supports. For each of the operations,
the WSDL file also describes the format that the client must follow in requesting an
operation. The server agrees to provide certain services only if the client sends a properly
formatted SOAP request. A WSDL of FileManager is listed in Appendix C.
111
5.3.1 Login Implementation
Inline with the login design illustrated in Figure 4-4 and Figure 4-10, Figure 5-5 shows the
code snippet after the user clicks on “Connect” button as in Figure 5-4.
Login
DMS User
Login
Interface
Match
User
Name
ACL
Accept &
Store User
Token
Session
Store
Inform
User
Figure 5-3 Referring Figure 4-4 Implementation Highlight
Figure 5-4 Login Screen
UserManager instance is created after the dialog box in Figure 5-4 is dismissed. The
UserManager is a web service class that should be assigned with web service provider URL
and the user session token is return once the user name and password combination is
validated. The user session token must be kept in the client environment in order to make
other request to DMAPI server.
um = new UserManager();
um.Url = "http://" + server + ":80/" + share + "/UserManager.asmx";
token = um.Logon(username, password);
Figure 5-5 Client Logon Code Snippet
During the client logging into the server, a web method “Login” is called. The web method
has to perform the steps illustrated in code snippet shown in Figure 5-8 before returning a
valid token to the user. Meanwhile, Figure 4-4 and Figure 4-11 have been redrawn in
112
Figure 5-6 and Figure 5-7 below to exhibit the actual implementation corresponding to the
system design.
Figure 5-6 Referring Figure 4-4 State Explanation
Figure 5-7 Referring Figure 4-11 State Explanation
• A, B – Checks the existence of the user and verifying the password.
• C – Creating the session token based on the user name, concurrent login with the
same user name is possible but with a different session token.
• D – Store the newly created user session token to the memory repository.
• E – Returning the session token if login is successful. Otherwise,
“InvalidPasswordException” or “UserNotFoundException” is thrown.
Alphabets A to E are marked in code snippet shown in Figure 5-8 to reveal some of the
actual code written.
[WebMethod()]
public SessionToken Logon(string username, string password)
{
Users users = base.DMSServer.Environment.Users;
(A,B) if (users.Contains(username))
if (((User)users[username]).Password == password)
113
{
(C) SessionToken st = new SessionToken(username);
(D) Sessions.Add(st);
(E) return st;
}
else
(E) throw new InvalidPasswordException(username);
else
(E) throw new UserNotFoundException(username);
}
Figure 5-8 Logon Server Side Code Snippet
The façade implementation in Figure 5-9 indicating that the “IsValid” method can be
overridden by the derived class with its own implementation to provide additional security
measurement. In this implementation, the “IsValid” method only verifies whether the user
session token has expired.
public virtual bool IsValid(System.Guid token)
{
SessionToken sessionToken = (SessionToken)this[token];
if (sessionToken.Expired)
throw new SessionExpireException(sessionToken.UserName);
return this.ContainsKey(token);
}
Figure 5-9 Session Verification Façade Code Snippet
Figure 5-10 highlights the control entity corresponding to the code snippet shown in
Figure 5-9.
114
Figure 5-10 Referring Figure 4-5 Implementation Highlight
5.3.2 Check In Files Implementation
Prior to the check in/out process, several procedures have been done; for example,
ensuring that the document is checked out by the requesting user or the document does
not exist at all for a newly check in document, besides detecting the authenticate fault.
Figure 5-11 illustrates the check-in method with all lines except the last line on the
checking procedure described above.
public WebStreamToken CheckIn(string uncPath, string username)
{
Document d = this.GetDocumentInfo(uncPath);
//is ok for new file check in
if (d == null)
if (this.Exists(uncPath))
throw new NotCheckOutException(...);
User u = this.env.Users[username];
//is ok for new file check in
if (d != null)
if (d.Operation != null)
115
if (!d.Operation.UserID.Equals(u.GUID))
{
if (Users.Contains(d.Operation.UserID))
throw new
CheckedOutByOtherUserException(...);
else
throw new
CheckedOutByOtherUserException(...);
}
return new TempCheckInWebStreamer(...).Token;
}
Figure 5-11 Check In Code Snippet
TempCheckInWebStreamer class is used to maintain an asynchronous web streaming
process between the client and the server. There are in total three variations in this
hierarchy of classes. These variations are shown in Figure 5-12.
Figure 5-12 WebStreamer Class Hierarchy
116
WebStreamer is the base class of all asynchronous streaming process. When a client needs
a file resource at the server, the resource is opened and WebStreamer class will make sure
that its handler will be released after 2 minutes of idle time. In other words, all file handlers
must be closed by the user or else it will be inaccessible and the process done previously
may need to be repeated. SessionExpired event handler is used to inform the event
subscriber including the derived class about the occurrence happened. In contrast, if the
file process is terminated normally, the FileClose event is raised.
In case of file check in, a temporary file will be created to let the client upload the file.
When the file is fully uploaded, the FileClosed event raised by the base class will trigger out
the file replacement function. This function backup the previous file and stores the version
information ahead of substituting the old version with the new version.
5.3.3 Check Out Files Implementation
In view of check in files, check out file is much more complicated in terms of its pre-return
processes but easier for the output streaming process. To keep a complex process simple,
the following steps must be done in advance:
• A – Verify that the requested file exists.
• B – Substantiate the user session token.
• C – Get the document’s information and ensure that it was not checked out by any
user other than the requested user.
• D – Verify the document security and accessibility
• E – Update the check out information thus it can be checked in later.
• F – Save the document information.
117
• G – Return the document stream.
Figure 5-13 illustrates the actual code implementation for the pseudo-step above. The
“GetLatestVersion” method is almost the same as CheckOut method without sections B,
C, E, F and G.
public WebStreamToken CheckOut(string uncPath, string username)
{
(A) if (!uncPath.Substring(0, uncroot.FullName.Length).ToUpper()
.Equals(uncroot.FullName.ToUpper()))
throw new SoapException(...);
string resource = GetResource(uncPath);
string absolute = ToAbsolutePath(uncPath);
FileInfo dinfo = new FileInfo(ToInfoPath(uncPath));
Document d;
//user check
(B) User u= (User)Environment.CurrentEnvironment.Users[username];
if (u == null)
throw new SoapException(...);
//existing document info check
(C) d = this.GetDocumentInfo(uncPath);
//for new file also
if (d != null)
if (d.Operation != null)
{
if (Users.Contains(d.Operation.UserID))
throw new CheckedOutException(...);
else
throw new CheckedOutException(...);
}
118
//document check
d = new Document(absolute);
if (!d.Exists)
throw new SoapException(...);
(D) //verify document security and accessibility
...
//set operation
(E) d.Operation = new Operation(u.GUID, CheckOut, DateTime.Now);
Directory.CreateDirectory(dinfo.Directory.FullName);
(F) XML.Save(d, typeof(Document), dinfo.FullName);
(G) WebStreamer ws = new WebStreamer(d.ReadStream());
return ws.Token;
}
Figure 5-13 Check Out Code Snippet
The returned WebStream class, which is the base class of all other streams, is more than
enough to handle the functionalities of checking out as well as “GetLatestVersion” feature.
Hence, the “GetLatestVersion” will not be explained in this document.
5.3.4 DMAPI Security Implementation
DMAPI Security is implemented using the well-known role-based architecture. Role-based
security is an elegant way to provide user authorisation and user access checks for DMAPI.
Referring to Figure 4-13 and Figure 4-14, a role is a set of users sharing the same security
privileges. A user belonging to a particular role can access resources for which permissions
119
are granted for the role. Code snippet in Figure 5-14 demonstrates the processes involved
in granting permissions to access resources using roles as well as users.
public void AddACL(string uncPath, User user, Principal principal,
Permission type)
{
(A) if (!(Users.Contains(principal.GUID) ||
Roles.Contains(principal.GUID)))
throw new SoapException(...);
Document ed = GetDocumentInfo(uncPath);
(B) if (ed.Owner == Guid.Empty)
ed.Owner = Users["admin"].GUID;
Principal everyone = Roles["everyone"];
//is everyone role enable?
(C) if (!(ed.ACL.Contains(everyone) &&
(ed.ACL[everyone.GUID].Permission & Security) ==
Security))
if (!ed.Owner.Equals(user.GUID))
throw new SoapException(...);
//change acl
(D) if (ed.ACL.Contains(principal))
ed.ACL[principal.GUID].Permission = type;
else
120
ed.ACL.Add(new ACLEntry(principal.GUID, type));
(E) XML.Save(ed, typeof(Document), ToInfoPath(uncPath));
}
Figure 5-14 Add Access Control List Entry Code Snippet
• A – Verify that the derived class of principal exists in users or roles collection.
• B – Set the document owner to default, “admin” if it owner is not found.
• C – The user must have permission to update the document security information
or the document contains ACL entry for “everyone” with “security” item. If the
condition fails, the process will not continue further.
• D – Add or change the ACL entry
• E – Save the document information.
In step C, for example, suppose an application grants permission to access a particular
feature to ten users. DMAPI only needs to declare that the users belonging to a particular
role can access a feature.
Similarly, only step D is needed to be redefined for removing ACL entry. Since a document
can contain only one unique principal among an ACL, therefore no iteration is needed
during removing ACL entry.
public void RemoveACL(string uncPath, User user, Principal principal)
{
(A,B,C)
...
//change acl
(D) if (ed.ACL.Contains(principal))
121
ed.ACL.Remove(principal);
(E) ...
}
Figure 5-15 Remove Access Control List Entry Code Snippet
Although some of the code appearing inefficiently and heavily repeated especially code
snippets in Figure 5-14 and Figure 5-15, however it is exhibiting the major workflow in the
functions without disregard simplicity and maintainability.
5.4 Using the XML Persistence Framework
The XML persistence framework packages contained in the System.XML namespace
provide series of serialization attributes that can be used to decorate the classes. These
attributes allows programmers to invent new kinds of declarative information, attach this
declarative information to various classes entities, and retrieve this declarative information
at run-time. For example, to indicate that a given class supports XML serialization,
System.Xml.Serialization.XmlType is used.
[System.Xml.Serialization.XmlRoot("User")]
public class User : Principal
{
...
[System.Xml.Serialization.XmlElement("Name")]
public string Name
{
get{...}
set{...}
}
122
System.Xml.Serialization.XmlElement("Password")]
public string Password
{
get{...}
set{...}
}
[XMLIgnore]
...
}
Figure 5-16 XML Serialization Sample
Figure 5-16 is an example of a XML serialized class. XMLType attribute indicates that User
is a serializable class, it controls how the XmlSerializer serializes or deserializes an object.
To indicate that a particular attribute should not be serialized in a class,
System.Xml.Serialization.XmlIgnore is used.
Figure 5-17 illustrates the sample output from the class decorated with serialization
attributes.
<?xml version="1.0" ?>
<User xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<GUID>f6c1d1c5-fab7-4821-8ffb-781566cb0e05</GUID>
<Name>admin</Name>
<Password>xxx</Password>
</User>
Figure 5-17 XML Serialization Output
123
In addition to the usage of XMLElement, XMLRoot and XMLIgnore, there are other
XML serialization attributes which are listed in Appendix B.
5.5 Document Storage Strategies
The document is proposed to act like a container to store it own various version of
modification and annotation using XML persistence method discussed in section 5.4.
Figure 5-18 Hierarchy Representation of Document Container
Figure 5-18 illustrate the file or document container of AssemblyInfo.cs. There are total 11
version of the same file which can be accessed via their path and version number. The
annotation of each version is stored in “.version” file extension in which the contents is
formatted using XML persistence method discussed in section 5.4.
124
5.6 Client Graphical User Interface (GUI)
Client user interface provides an important medium for human-computer interaction. This
user interface emphasizes the ease of use of the DMS application without the need of
highly computer knowledge. Users generally can perform all functions using mouse-
clicking technique and all process activities are performed behind the user scene. The
following sections illustrate some GUIs developed in DMAPI.
The DMAPI client needs the users to authenticate themselves before continuing any
operations. A windows explorer-like interface will show and list the contents of the shared
repository after a successfully user login. The shared repository can be viewed in various
forms similar to a windows explorer. Figure 5-19 and Figure 5-20 are two popular formats
among others where Figure 5-19 denotes a detailed view and Figure 5-20 denotes an icon
view. Unlike the detailed view, the icon view conceals all file information such as last
written date, file size, check in/out status, and its status date.
125
5.6.1 Items Listing
Figure 5-19 Detailed File Listing
The icon view in Figure 5-20 is very useful for those users who dislike too much
information presenting on the screen. On the other hand, Figure 5-19 are design for those
who need detailed information.
Figure 5-20 Icons File Listing
5.6.2 Define Work Folder
Before any check in/out operations, users must first set the work folder to place the
documents locally. These documents can be used for viewing, editing and later update back
126
to the DMAPI repository. Figure 5-21 illustrates the context menu that should be clicked
on to launch the common folder selection dialog (Figure 5-22).
Figure 5-21 Set Local Folder
Figure 5-22 Folder Selection Dialog
Once the local folder is defined, the location path will be stated at the status bar as shown
in Figure 5-19.
5.6.3 Check Out Items
To check out document(s) or folder(s), the user has to right click on the targeted item and
select “Check Out” from the context menu as shown in Figure 5-23.
127
Figure 5-23 Check Out Items
During the check out process, all the operations events are logged under the log window
shown in Figure 5-24. These events include “Check out successful”, “Check in successful”
and some error events to name just a few. By the way, if the document is checked out
successfully, the document status and the date will be shown in the detailed listing as
illustrated in Figure 5-24.
Figure 5-24 Document Check Out Status
5.6.4 Check In Items
Similarly, right click on the targeted item and select “Check In” from the context menu as
shown in Figure 5-25 to check in file(s) or folder(s).
128
Figure 5-25 Check In Items
The events status provoked from the check in process are shown in the log window as
illustrated in Figure 5-26.
Figure 5-26 Document Check In Status
The documents are store in native format without any conversion. After check out, it can
be opened with native application which installed locally.
129
5.6.5 Version Control for Document
All files are stored in file system without using database. Total number version of
document or depth are depends on the size of file system or hard disk space. A periodic
schedule of backup and archive process is suggested to improve the DMAPI storage by
storing outdated or obsolete version of document into CDs or tapes. For example, all
version of document that older than a year will be archived into tapes.
5.6.6 Version Control for DMAPI
DMAPI version control can be done by marking the API’s functions or methods with
deprecated flag (in Java) or obsolete attribute (in .Net framework). When a developer
intends to use these obsolete functions or methods, warning will be given and the newer
implementation or replacement will be suggested. The future version of the DMAPI
deployment will not cause any conflicts.
5.6.7 Document Information and Security Interface
Figure 5-27 and Figure 5-28 illustrate the properties for a particular document. The
document properties such as file type, file location in the DMAPI server, file size, date
created, date modified, date accessed and owner of the document are located in the
“General” tab (Figure 5-27), whereas the permissions and accessibilities of the document
are located on the “Security” tab (Figure 5-28).
130
Figure 5-27 Document Properties
Figure 5-28 Document Security Properties
Both dialogs in Figure 5-27 and Figure 5-28 are used to define ACL for a document.
Meanwhile, the following session describes the details on adding users and roles to the
DMAPI system.
5.6.8 User Manager
There are two dialog windows, Figure 5-29 and Figure 5-30 to maintain users and roles
information. The early dialog window is used to manage the user information such as:
• Add new user.
• Remove existing user.
• Add role to existing user, and
• Remove role from existing user.
131
Figure 5-29 User Manager – User
Multiple roles can be assigned to users concurrently by selecting several users from the left
panel and roles from the right panel, then click on “Add Role” button.
Role management in Figure 5-30 is implemented analogous to user management window;
it provides the following functions:
• Add new role.
• Remove existing role.
• Add user to existing role, and
• Remove user from existing role.
132
Figure 5-30 User Manager – Role
Likewise, multiple users can be assigned to roles concurrently by selecting several roles
from the left panel and users from the right panel, then click on “Add User” button.
5.7 DMAPI Testing Strategies
It is a good practice to write the testing code during the code writing process. A well-tested
code works better and helps to shorten time in debugging. It increases the program
building efficiency and reduces the testing cycles at the end of the project.
In this dissertation, NUnit, an open source .NET testing framework is used for application
testing. This downloadable framework from nunit.sourceforge.net is capable of using the
“attribute” feature of .NET to identify tests. Test fixtures are identified by the attribute
[TestFixture] and individual tests by [Test]. During test-time, NUnit finds those methods
marked with these attributes and run the tests before generating reports on the tests.
133
Figure 5-31 denotes the subset of the test script used to test DMAPI. The test result will be
explained following this figure.
[TestFixture]
public class DMSTest
{
...
[SetUp]
[Test]
public void Connect()
{
explorer = new Explorer();
Assert.IsTrue(
explorer.Connect("localhost", "share",
"chichong", "chichong"), ...);
}
[Test]
public void InvalidPasswordConnect()
{
Assert.IsTrue(explorer.Connect("localhost", "share",
"chichong", "xxx"), ...);
}
[Test]
public void CheckInFile()
{
Assert.IsTrue(explorer.CheckIn(
@"\\...\Project a\Service.cs",
134
@"D:\Development\dms\work\Service.cs", false,
NullableBool.Null));
}
[Test]
public void CheckInFolder()
{
Assert.IsTrue(explorer.CheckIn(
@"\\CHICHONG\share\root\Projects\Project a",
@"D:\Development\dms\work\", true,
NullableBool.Null));
}
[Test]
public void CheckOutFile()
{
Assert.IsTrue(explorer.CheckOutFile(
@"\\...\Project a\Service.cs",
@"D:\Development\dms\work\Service.cs"));
}
...
}
Figure 5-31 NUnit Test Script
NUnit supports two versions of testing mode, one that needs to run at the command
prompt, and another uses a GUI application to run. Sample screenshot of GUI version is
shown in Figure 5-32.
135
Figure 5-32 NUnit Testing
The total tested methods has been reduced in order to simplify the testing approach. When
pressing the Run button, NUnit looks at the program, finds all the tests, and runs them. If
the tests all run correctly, NUnit displays a green bar. If any of the tests fails, the bar is
highlighted in red. The test processes will be repeated for each release of the application or
defined milestone until it reached a certain degree of stability.
The above tests have been restructured into a loop of 500, 1000 and 2000 concurrent
iteration with random file size and check in and out operations. The larger number of
concurrency and the bigger size in file being checked in or out has caused the system’s
response time slower.
5.8 Features Comparison
One might wonder the question, i.e. “Is there any database implementation for this
prototype?” Yes, the main difference between DMAPI with other major commercial
document management products is that there is no database or SQL involved in this
136
DMAPI implementation. All records are stored in XML format. Each XML document
represents an object, the persistence support will save and load the object’s attributes from
the XML document. In this case, DMAPI does not require any third party databases to
support the DMAPI data store or repository, the physical hard disk space is more than
enough. This advantage helps to reduce overall implementation cost.
Due to the nature of DMAPI system implementation, there is no direct means of features
or performance comparison among other products. Table 5-2 shows a list of implemented
features for the DMAPI prototype in this dissertation.
Table 5-2 Features Comparison
Features DMAPI Other Products Application/Web Server IIS IIS, J2EE, Apache, and etc (Figure
2-4)
Database N/A MySQL, MSSQL, Oracle, PostgreSQL, and etc.(Figure 2-5)
Operating System Windows and Linux
Windows, Unix, Linux and etc. (Figure 2-6)
Audit Trail Yes Yes – 67% (Figure 2-7) No – 23%
Granular Privileges Yes Yes – 82% (Figure 2-8) No – 11%
Kerberos Authentication Yes * Yes – 10% (Figure 2-9) No – 82%
LDAP authentication Yes * Yes – 33% (Figure 2-10) No – 53%
NTLM authentication
Yes * Yes – 13% (Figure 2-11) No – 77%
SMB Authentication
Yes * Yes – 10% (Figure 2-12) No – 82%
Session Management
Yes Yes – 43% (Figure 2-13) No – 42%
SSL Compatible Yes * Yes – 80% (Figure 2-14) No – 18%
Online Help Yes Yes – 72% (Figure 2-15) No – 21%
Pluggable API Yes Yes – 66% (Figure 2-16) No – 25%
Drag and Drop Content Yes Yes – 39% (Figure 2-17) No – 54%
Undo No Yes – 48% (Figure 2-18)
137
No – 40%
Advanced caching N/A Yes – 58% (Figure 2-20) No – 42%
Page Caching N/A Yes – 75% (Figure 2-19) No – 22%
Database Replication N/A Yes – 32% (Figure 2-21) No – 63%
Load Balancing Yes ** Yes – 42% (Figure 2-22) No – 51%
Online Administration Yes Yes – 91% (Figure 2-23) No – 7%
Web-based Style/ Template Management
No Yes – 70% (Figure 2-24) No – 20%
Workflow Engine No Yes – 38% (Figure 2-25) No – 46%
Content Syndication (RSS) N/A Yes – 57% (Figure 2-26) No – 29%
FTP Support Yes * Yes – 40% (Figure 2-27) No – 53%
WebDAV Support Yes * Yes – 17% (Figure 2-28) No – 77%
XHTML Compliant N/A Yes – 54% (Figure 2-29) No – 38%
Extensible User Profiles Yes Yes – 53% (Figure 2-30) No – 36%
Interface Localization No Yes – 59% (Figure 2-31) No – 35%
Document Management Yes Yes – 26% (Figure 2-32) No – 57%
HTTP Proxy Yes ** Yes – 22% (Figure 2-33) No – 72%
Search Engine Yes ** Yes – 72% (Figure 2-35) No – 17%
Web Service Yes Yes – 15% (Figure 2-34) No – 70%
* Features come with IIS. ** Features come with OS.
In terms of performance issue, a database uses some kind of indexing schema to enhance
the records fetching process; however, DMAPI in this dissertation relies on the native file
allocation table (FAT) to provide the index algorithm. Both methods are not comparable
and highly dependant on the vendor implementation. However, the document
management system mimics closer to file system storage, thus the design and
implementation of DMAPI will be much simpler. For example, to add an additional hard
138
disk to the DMAPI data store, the user may just need to plug in the hard disk and mount
the folder into the data store without any other configuration. For instance, merging two
DMAPI data stores requires re-indexing the database table for database implementation,
whereas for file system implementation, one needs to copy only the XML files to the
DMAPI data store and letting the operating system to do the job.
Another major difference between DMAPI and the ordinary document management
system is that the DMAPI server is implemented on top of web service protocol. Because
of this, DMAPI application is more visible and accessible to the DMAPI client. It uses
standard HTTP port 80 for all the operations and most firewalls open it. This is important
for WAN deployment of DMAPI clients behind firewall.
For the same reason, DMAPI bounds to be more extensible and scalable. Dynamic
clustering and load balancing is made possible by just loading in a DNS multiplexer. Figure
5-33 shows a simple and possible hardware architecture to handle the increased number of
DMAPI clients in the future.
139
Figure 5-33 Hardware Architecture for Clustering
Referring to Figure 5-33, if a DMAPI service is configured to handle 2000 clients, the
additional 10 clients will be relocated to a different web service server by DNS multiplexer
to handle their requests. For the testing purposes, the multiplexer is configured with three
clients for each server to test with server load.
5.9 System Limitation
Referring to Table 5-2, there are four features not being implemented in DMAPI. These
features include undo, web-based style template management, workflow engine and
interface localization. More development resources should be allocated to build and
incorporate these features into DMAPI to increase the usability of the system. The
implementation plan is suggested to be executed near future as soon as the development
140
resources are allocated. Additional time resource should be allocated to stabilize the
existing features as well.
For those features that are Web Server or OS dependent, additional steps needed to be
performed during the platform migration. This required additional cost in order to make
other platform run smoothly.
The platform dependent features include:
• Web Server - Kerberos Authentication, LDAP authentication, NTLM
authentication, SMB Authentication, SSL Compatible, FTP Support, WebDAV
Support, HTTP Proxy, Search Engine
• OS - Load Balancing
To resolve this issue, DMAPI can incorporate some other third party components or
services into it.
5.10 Conclusion
This chapter covers implementation details for DMAPI. Application development
environment, development and design tools have been discussed early in this chapter. The
implementation of layered architecture was discussed in Chapter 4. Classes, packages or
namespaces organization have been introduced to serve as the backbone of the
implementation. Various protocols presented in the previous chapters have been applied to
make sure DMAPI is portable, extensible and scalable to any other platforms.
141
Numerous code snippets have been checked for explaining its corresponding design. These
code snippets are highly associated to the correlation diagrams and sequential diagrams. All
stages in the code are mapped to diagrams. In additions, the SOAP protocol uses XML as
a medium to ensure that the serialized documents are portable and transportable on HTTP
protocol over port 80.
For the client graphic user interface, every operation is handled by the mouse point and
click facilities. The steps of the processes are also listed in this chapter together with some
snapshot of the user interface. The testing strategies have been discussed right after the
GUI section. Finally, the comparison of application features has also been discussed.
142
CHAPTER 6 CONCLUSION
This chapter concludes the overall research and development of this dissertation. The
strengths and limitations of the implementation are highlighted in this section followed by
some possible future enhancements.
6.1 Significance of Proposed Research
As stated early, this dissertation does not require any database to store the documents.
Thus, it reduces the total cost of implementation and simplifies the system development
and integration during the implementation process. However, using XML document as
data storage does not suggest that it inherits all those disadvantages of XML databases such
as XML element fragmentation and XML query performance. By using the tree structure
storage that mimics the file system, every document object in DMAPI can be accessed by
specifying its address or path without using any SQL statement. However, contents search
requires a different set of knowledge that includes the understanding of internal format or
structure of every document, for example, Microsoft Word (.doc), compressed files (.zip),
etc. This topic is not in the scope of this dissertation.
By implementing DMAPI using the web service technique, all the published services will
be available to the other developers who intend to integrate their front-end application into
DMAPI. The developed DMAPI is supplied with a set of developer reference guide to
ease the development process. The developer reference guide is prepared using NDoc in
both HTML format shown in Figure 6-1 and compiled HTML help file (.chm) shown in
Figure 6-2.
143
Figure 6-1 Developer Reference Guide (HTML Format)
Figure 6-2 Developer Reference Guide (Compiled HTML Help File)
A sample front-end application is provided to help the developers comprehend the object
model during their development process (Refer to Appendix E). This application
144
demonstrates ease-of-use of the graphical user interface for users to manipulate the
documents. Users do not require to memorize all the instructions set but making use of the
drag and drop features. In addition, the DMAPI setup steps is listed in Appendix D.
By referring to Table 5-2, 15% of all the DMS features are yet to be implemented in the
DMAPI prototype. Subsequent performing a ‘cross tab’ analysis, there are 26 out of 266
DMS products in the market having the least ‘number of imperfect features’. All the 226
DMS products are listed in Table 6-1.
Table 6-1 Products & Imperfect Features
No.
Product
No of imperfect
features No.
Product
No of imperfect
features No.
Product
No of imperfect
features
1 Estrada Web Technology 3.6 0 77
Tiki CMS/Groupware 1.8.4 10 153 Webbler 2.5.9 16
2 ECMSuite 3.5 0 78 Arp.Site Free 2.0 12 154 AutoWebBuilder 1.2 17
3 Smartsite CMS Release 5 0 79
CMS Encore Pro 1.0 11 155 Ciamos RC1 17
4 Interwoven TeamSite 6.1 1 80 conrad:// 11 156
Dynasite - Universal CMS 6.5 17
5 Polopoly 8.5 1 81 ContentX 1.3 12 157 NetPotential CMS 17
6 SiteRefresh 5.0 1 82 Contribute 1.0 11 158 SPIP 1.7.2 17
7 WAXTRAPP 3.0.1 1 83 Conviveon SiteConnect 6.0 12 159 CMS Master 1.0 19
8 ContentXML 3.0 RC 1 1 84 CPG-Nuke 8.2b 12 160
Esselbach Storyteller CMS 1.7.2 19
9 Eplica 1.4.5 1 85 dbCanvas 2.0 12 161 FLUiD CMS 4.5 18
10 Quantum Art Q-Publishing QP7 1 86
E-Commerce SIBOX CMS 3.6 12 162
HardCore WCM 5.3 19
11 Sitecore 4.3.2 1 87 EasyConsole CMS 2.4 11 163 MetaDot 6.0.6 18
12 eZ publish 3.x 2 88 EPiServer 4 Professional 11 164 NetManager 1.4 18
13 Livelink WCM Server 9.2 2 89 i-Web Suite Enterprise 11 165 Revize 4.3 18
14 Merge Portal 4.0 2 90 IceWEB CMS 3.0 11 166 SuiteWise 1.5 18
15 NPS 5.5 2 91 mmprove for websites 12 167 Sytadel 4 18
16 Websphere EIP 8.1 2 92 Movable Type 3.0 12 168 Web Manager 1.5 18
17 Nuxeo CPS 3.1.4 3 93 NPDS 5.0 12 169 webEdition 3.1 18
18 Roxen CMS 4.0 3 94 OpenACS 5.1.2 11 170 Cofax 2.0 19
19 Powerslave ECMS 5.4 3 95 OpenPHPNuke 2.1.2 12 171 finalsite CF 19
20 Sharepoint Portal Server 2001 3 96 Text-e 1.6.4 11 172 GiiCorp CMS 19
21 SelbstdenkerFrameworks 5.x 4 97 Tonic 2.0 11 173
Jetbox CMS 2.0.8 19
22 EGOCMS 3.5 4 98 Axinom Enterprise CMS 4.2 12 174
Near-Time Flow 1.1 19
145
23 Immediacy CMS 4.8 4 99 Drupal 4.5.0 13 175 openEngine 1.5 20
24 WebPal 1.5.1 4 100 eNetwizard Matrix Server v0.0.1 13 176
OpenPortal CMF 2.8 19
25 WORKSsitebuilder 2.0 4 101 EPIX 3.0 12 177 pMachine Pro 2.3 20
26 xBx Site Manager 4 102 ICMv2 2.2.0 12 178 Site Wizard 3 20
27 contentXXL - ASP.NET CMS 2.54 4 103 icogs icogs Beta 12 179 Artiloo Velocity 20
28 WebEngine v6 6.2.04 Rev. 019 4 104
liveSTORYBOARD CMS 5 12 180 AssetNow NX 20
29 DMAPI 4 105 Moodle 1.4 13 181 Big Medium 1.3.4 21
30 MARQUI 5.6 5 106 Netdoc 1.02 13 182 DEV WMS 1.5 20
31 WebGUI 6.2 5 107 OmniUpdate 12 183
Ektron CMS400.net CMS400.net v4.7 20
32 WebHare A.P. 2.10 5 108 PostNuke 0.75 Gold 13 184 Etomite 0.6 21
33 PLS Manage-It!/YourWeb 3.0 5 109 SiteSapiens 2.0 13 185
Komplete CMS 2.5.0 20
34 mmprove for publications 6 110 Xoops 2.06 12 186 SiteBuilder 2.0 21
35 RedDot CMS 6.0 6 111 Ariadne 2.4rc2 13 187 WordPress 1.2.2 20
36 CommonSpot Content Server 4.0 6 112 e107 6.17 13 188 WYMSY 1.0 20
37 DotNetNuke 2.0.4 6 113 eContent 3.0 13 189 Dynamicweb Portal 21
38 Jahia 4.0.4 6 114 Enonic Vertical Site 3.1 13 190 e-publish 2 21
39 Cont'N'Shop 4.2 7 115 Harmonise 13 191 Geeklog 1.3.9 21
40 Plone 2.0.4 7 116 lemoon® 2.0 14 192 SuperCharged CMS 4.1 21
41 ADXSTUDIO 2004 7 117 Rainbow 1.0 13 193 TCMS 1.0 21
42 BeYourOwn.net 1.5 7 118 XCMS 14 194 zeta producer 6 21
43 edeptive™ R3.0 7 119 AWF 1.11 14 195 Direct News 4.7 22
44 imCMS 1.10.x 7 120 Composite CMS Enterprise 14 196 GYO 0.3 22
45 SiteSage CMS 5.0 7 121 ContentServ 3.1 14 197 MKDoc 1.6 22
46 Back-End CMS 0.7.1.3 8 122 Zonus Engine 2.0 14 198 SabreTooth 4.0.5.1 22
47 Isens Evolution 5.9 8 123 Ektron CMS300 4.5 15 199
SpinPike Commerce 3.3.5 22
48 Manila 9.0.1 8 124 ExpressionEngine 1.2 15 200
Tikipro 2.0 -BONNIE- 22
49 Absolut Engine 1.69 8 125 Mambo 4.5.1 14 201
XHP - eXpandable Home Pag 0.3 22
50 Apache Lenya 1.2 8 126 Scoop 1 14 202 Axyl 2.1.4 24
51 AquiferCMS 3.0 8 127 Site Unit CMS 2.5 14 203
Dozing Dogs ASP.NET CMS 2.0 23
52 ISIPortal 2.9.1 8 128 Synkron.web 3.6 14 204 MeshCMS 1.0 RC2 23
53 MMBase 1.6 8 129 Tangora CMS 4.0 14 205 Nucleus CMS 3.15 23
54 Open CMS 5.0 8 130 TWiki Cairo 15 206 Opus 2.24 23
55 Libertas Enterprise CMS 3 9 131
Web Content Manager 3 15 207
phpWebSite 0.9.3-4 23
56 Bitrix Site Manager 3.3 9 132 Xitex WebContent M1 PE 1.8 14 208 Poseidon 0.6.1 24
57 BolinOS 4.4.0 9 133 Xitex WebContent M1 SE 1.8 14 209 AGPCMS 24
58 openshare 2.2 9 134 Bricolage 1.8.1 15 210
BLOG:CMS BLOG:CMS 3.5.1 25
59 PHP Nuke 6 9 135 Caravel 2.0 15 211 CathDesign CMS V1.0 24
146
60 TYPO3 3.7 9 136 Kentico CMS for ASP.NET 1.3 15 212 Exponent 0.95 24
61 Xaraya 0.9.9 8 137 MD-Pro 1.0.7 15 213 gee! Web Tools v3.0 24
62 Affino LX 9 138 multineo neOS 0.9 16 214 Honeycomb Archive 3.0 24
63 autowebcms 1.0 9 139 Saurus CMS 3.3 15 215 MammonBase 2 24
64 Easy Publisher 1.6 9 140 Silva 1.1 15 216 My Web Pro 2.0 24
65 eTouch CMS 1.3 9 141 Simplicis 2 15 217 OPENi-CMS 1.0 24
66 Freestyler 4.6 10 142 SiteKreator 1.0 15 218 REDAXO 2.7 24
67 GeoDocs 7.0 9 143 Taggon 15 219 WebDB 1.1 24
68 Jalios JCMS 5.0 9 144 XPort Version two 15 220 lucidCMS 1.0.10 25
69 Oracle Portals 10g (9.0.4.1) 9 145 Contenido 4.4.4 16 221 Daisy 1.1 26
70 phpSlash 0.72 10 146 Explid 1.0 16 222 fipsCMS XL 3.8 26
71 ContentM 2.0 11 147 Krang 1.026 17 223 Miraserver 1.0 26
72 ENID 1.7.2 10 148 Land Down Under 700 16 224
SiteWorks Professional 5.0.0 27
73 Komodo CMS v1.0 10 149 Magnolia 2.0 16 225
Tools for Organizations 4.0 26
74 Pathos 0.90 10 150 Manifest 2 16 226
fly CMS somewhere between 1.5 and 2.0 27
75 Site & Content Manager v1.0 Neptune 586 10 151 phpwcms 1.1 RC4 16 227 Slashcode 2.2.6 29
76 Sitellite CMS 4 10 152 PHPX 3.5.3 16
However, the DMAPI development will not stop here. Several potential features that have
been identified are outlined in Section 6.3 for further application enhancement.
6.2 Limitations
DMAPI is built on top of web service technology, which is an extension of HTTP. It
inherits the good and the bad of the HTTP protocol. For example, the maximum
connections per server for a client is two as defined in HTTP 1.1 protocol. DMAPI client
which built on top of HTTP 1.1 protocol cannot perform more than two operations on
the same server simultaneously. The transmission of the documents is deemed to be slow.
Although a sample of DMAPI client that uses DMAPI is provided, it is not incorporated
into the developer reference. It is always a good practice to include the code sample
147
snippets into the developer reference to ease the developers’ task. This issue can be easily
resolved given more time.
Every off-the-shelf-software applications must have conducted extensive testing. These
test procedures are important to ensure the application robustness and to prevent data loss
due to application crash. However, the core application API is only tested during the
application development environment but not in a production environment. Thus, the
reliability of the application is not fully tested yet.
The issues above can be overcome by enlarging the user group and setup developers’
forum where all problems and solutions should be found.
6.3 Future Work
One of the potential future enhancement works is to integrate workflow management into
DMAPI. As the result of this value-added feature, users can authorize, certify and verify
the documents inside DMAPI. In addition, it allows the flow of work between individuals
and/or departments to be defined and tracked. Workflow helps to automate a range of
business tasks, and electronically route the right information to the right people at the right
time. Users are notified of pending work, and managers can observe status and route
approvals through the system quickly. At the moment, this is a low priority work because
only 38% products on the market having this feature integrated.
In case of graphical user interface, there are three enhancements that need to be done such
as changeable interface template or skin in modern windows form application, undo
feature and localization capability. Each of them has been implemented respectively by
70%, 48% and 59% of the vendors. It seems important because research shows that, most
148
users judge the usefulness of a software by its user interface (Preece, 1994). These are high
priority works needed to be done in the near future.
A powerful search engine becomes handy if it is able to integrate with DMAPI. However,
it is an optional work because of the issues discussed in Section 6.1. Furthermore, some
popular third-party search engines such as Google is allowed to be integrated into DMAPI
easily. For instance, a search result set from a self hosted document server will be returned
with the following search string “search site:mydocument.com”.
6.4 Conclusion
In conclusion, DMAPI embraces a wide range of interests ranked from basic file storage to
advance documents manipulation. To recap, the various document types and formats have
been described in Chapter 1, followed by the classification of DMS application in Chapter
2. There are four major branches of DMS applications namely document imaging and
document management, source version control, content management system and portal.
Some popular and feasible features for the DMS application are also reviewed in this
chapter. These features are characterized into nine categories; system requirement, security,
product supports, eases of use, performance, management, interoperability, flexibility and
built-in components. Each of them is charted with a figure and brief explanation.
The design of DMAPI is carried out using a set of reviewed theories and methodologies,
which include layered architecture XML persistence framework, object-oriented software
engineering, object analysis, object modelling, and object-oriented programming. After
that, the implementation plans are drawn according to the reviewed theories in Chapter 4.
A detailed layered architecture diagram and various specified UML diagrams such as use
149
case model diagrams, collaboration diagrams, sequence diagrams and class diagrams have
also been applied in the application design phase.
Generally, the objectives of the dissertation have been achieved. The common
functionalities and requirements of document management systems are described in
Chapter 2. The pros and cons of commercial document management system products are
compared by its provided features. There are 35 selected features have been developed into
DMAPI framework using web services programming technologies.
Finally, the actual prototype implementation and testing have been enlightened in Chapter
5. The class interface and implementation are mapped from the design diagrams
accordingly together with the actual implementation code snippets. Application testing and
documentation have been done lastly according to the SDLC workflow steps.
Appendix A – DMS Applications Reviewed
1. ASP.NET 2. MammonBase 2 3. Absolut Engine 1.69 4. Manifest 2
5. ADXSTUDIO 2004 6. Manila 9.0.1
7. Affino LX 8. MARQUI 5.6 9. AGPCMS 10. MD-Pro 1.0.7
11. Apache Lenya 1.2 12. MediaApps NetPortal
13. AquiferCMS 3.0 14. Merge Portal 4.0
15. Ariadne 2.4rc2 16. MeshCMS 1.0 RC2
17. Arp.Site Free 2.0 18. MetaDot 6.0.6
19. Artiloo Velocity 20. Microsoft Exchange 2000 21. AssetNow NX 22. Miraserver 1.0
23. AutoWebBuilder 1.2 24. MKDoc 1.6
25. autowebcms 1.0 26. MMBase 1.6 27. AWF 1.11 28. mmprove for publications
29. Axinom Enterprise CMS 4.2 30. mmprove for websites 31. Axyl 2.1.4 32. Moodle 1.4
33. Back-End CMS 0.7.1.3 34. Movable Type 3.0
150
35. BeYourOwn.net 1.5 36. multineo neOS 0.9
37. Big Medium 1.3.4 38. MyLibrary 39. Bitrix Site Manager 3.3 40. My Web Pro 2.0
41. Blackboard Community Portal System
42. Near-Time Flow 1.1
43. BLOG:CMS BLOG:CMS 3.5.1 44. Netdoc 1.02 45. BolinOS 4.4.0 46. NetManager 1.4
47. Bricolage 1.8.1 48. NetPotential CMS
49. Caravel 2.0 50. Novell Portal Services 51. CathDesign CMS V1.0 52. NPDS 5.0
53. Ciamos RC1 54. NPS 5.5 55. CleverPath 56. Nucleus CMS 3.15
57. CMIS ePortal 58. Nuxeo CPS 3.1.4 59. CMS Encore Pro 1.0 60. OmniUpdate
61. CMS Master 1.0 62. Open CMS 5.0
63. Cofax 2.0 64. OpenACS 5.1.2 65. Cold Fusion 66. openEngine 1.5
67. CommonSpot Content Server 4.0 68. OPENi-CMS 1.0
69. Composite CMS Enterprise 70. OpenPHPNuke 2.1.2
71. conrad:// 72. OpenPortal CMF 2.8
73. Cont'N'Shop 4.2 74. openshare 2.2
75. Contenido 4.4.4 76. Opus 2.24 77. ContentM 2.0 78. Oracle Portals 10g (9.0.4.1)
79. ContentServ 3.1 80. Pathos 0.90
81. ContentX 1.3 82. PHP Nuke 6 83. ContentXML 3.0 RC 1 84. PHPortal
85. contentXXL - ASP.NET CMS 2.54
86. phpSlash 0.72
87. Contribute 1.0 88. phpwcms 1.1 RC4
89. Conviveon SiteConnect 6.0 90. phpWebSite 0.9.3-4
91. CPG-Nuke 8.2b 92. PHPX 3.5.3
93. Daisy 1.1 94. Plone 2.0.4
95. dbCanvas 2.0 96. PLS Manage-It!/YourWeb 3.0 97. DEV WMS 1.5 98. pMachine Pro 2.3
99. Direct News 4.7 100. Polopoly 8.5
101. DotNetNuke 2.0.4 102. Poseidon 0.6.1 103. Dozing Dogs ASP.NET CMS 2.0 104. PostNuke 0.75 Gold
105. Drupal 4.5.0 106. Powerslave ECMS 5.4 107. Dynamicweb Portal 108. Quantum Art Q-Publishing QP7
109. Dynasite - Universal CMS 6.5 110. Rainbow 1.0 111. E-Commerce SIBOX CMS 3.6 112. REDAXO 2.7
113. e-publish 2 114. RedDot CMS 6.0
115. e107 6.17 116. Revize 4.3 117. Easy Publisher 1.6 118. Roxen CMS 4.0
119. EasyConsole CMS 2.4 120. SabreTooth 4.0.5.1
121. ECMSuite 3.5 122. Saurus CMS 3.3
123. eContent 3.0 124. Scoop 1
125. edeptive™ R3.0 126. SelbstdenkerFrameworks 5.x
127. EGOCMS 3.5 128. Sharepoint Portal Server 2001
151
129. Ektron CMS300 4.5 130. Silva 1.1
131. Ektron CMS400.net CMS400.net v4.7
132. Simplicis 2
133. eNetwizard Matrix Server v0.0.1 134. Site & Content Manager v1.0 Neptune 586
135. ENID 1.7.2 136. Site Unit CMS 2.5 137. Enonic Vertical Site 3.1 138. Site Wizard 3
139. EPiServer 4 Professional 140. SiteBuilder 2.0 141. EPIX 3.0 142. Sitecore 4.3.2
143. Eplica 1.4.5 144. SiteKreator 1.0
145. Esselbach Storyteller CMS 1.7.2 146. Sitellite CMS 4 147. Estrada Web Technology 3.6 148. SiteRefresh 5.0
149. Etomite 0.6 150. SiteSage CMS 5.0
151. eTouch CMS 1.3 152. SiteSapiens 2.0
153. Explid 1.0 154. SiteWorks Professional 5.0.0
155. Exponent 0.95 156. Slashcode 2.2.6
157. ExpressionEngine 1.2 158. Smartsite CMS Release 5 159. eZ publish 3.x 160. SpinPike Commerce 3.3.5
161. finalsite CF 162. SPIP 1.7.2
163. fipsCMS XL 3.8 164. SuiteWise 1.5 165. FLUiD CMS 4.5 166. SuperCharged CMS 4.1
167. fly CMS somewhere between 1.5 and 2.0
168. Synkron.web 3.6
169. Freestyler 4.6 170. Sytadel 4
171. gee! Web Tools v3.0 172. Taggon
173. Geeklog 1.3.9 174. Tangora CMS 4.0
175. GeoDocs 7.0 176. TCMS 1.0
177. GiiCorp CMS 178. Text-e 1.6.4 179. GYO 0.3 180. Tiki CMS/Groupware 1.8.4
181. HardCore WCM 5.3 182. Tikipro 2.0 -BONNIE- 183. Harmonise 184. Tonic 2.0
185. Honeycomb Archive 3.0 186. Tools for Organizations 4.0 187. i-Web Suite Enterprise 188. TWiki Cairo
189. IceWEB CMS 3.0 190. TYPO3 3.7
191. ICMv2 2.2.0 192. WAXTRAPP 3.0.1
193. icogs icogs Beta 194. Web Content Manager 3
195. imCMS 1.10.x 196. Web Manager 1.5
197. Immediacy CMS 4.8 198. Webbler 2.5.9 199. Interwoven TeamSite 6.1 200. WebCT Vista
201. Isens Evolution 5.9 202. WebDB 1.1
203. iPlanet Portal Server 204. webEdition 3.1 205. ISIPortal 2.9.1 206. WebEngine v6 6.2.04 Rev. 019
207. Jahia 4.0.4 208. WebGUI 6.2 209. Jalios JCMS 5.0 210. WebHare A.P. 2.10
211. Jetbox CMS 2.0.8 212. WebPal 1.5.1 213. Jetspeed 214. Websphere EIP 8.1 215. Kentico CMS for ASP.NET 1.3 216. WordPress 1.2.2
217. Komodo CMS v1.0 218. WORKSsitebuilder 2.0
152
219. Komplete CMS 2.5.0 220. WYMSY 1.0
221. Krang 1.026 222. Xaraya 0.9.9 223. Land Down Under 700 224. xBx Site Manager
225. lemoon® 2.0 226. XCMS
227. Libertas Enterprise CMS 3 228. XHP - eXpandable Home Pag 0.3 229. Livelink WCM Server 9.2 230. Xitex WebContent M1 PE 1.8
231. liveSTORYBOARD CMS 5 232. Xitex WebContent M1 SE 1.8
233. Lotus Notes/Domino 234. Xoops 2.06
235. lucidCMS 1.0.10 236. XPort Version two
237. Magnolia 2.0 238. zeta producer 6
239. Mambo 4.5.1 240. Zonus Engine 2.0
153
Appendix B – XML Serialization Classes
• XmlAnyAttribute – Specifies that the member (a field that returns an array of
XmlAttribute objects) can contain any XML attributes.
• XmlAnyElement – Specifies that the member (a field that returns an array of
XmlElement or XmlNode objects) can contain objects that represent any XML
element that has no corresponding member in the object being serialized or
deserialized.
• XmlArray – Specifies that the XmlSerializer should serialize a particular class
member as an array of XML elements.
• XmlArrayItem – Specifies the derived types that the XmlSerializer can place in a
serialized array.
• XmlArrayItem – Represents a collection of XmlArrayItemAttribute objects.
• XmlAttribute – Specifies that the XmlSerializer should serialize the class member
as an XML attribute.
• XmlAttributeEventArgs – Provides data for the UnknownAttribute event.
• XmlAttributeOverrides – Allows you to override property, field, and class
attributes when you use the XmlSerializer to serialize or deserialize an object.
• XmlAttributes – Represents a collection of attribute objects that control how the
XmlSerializer serializes and deserializes an object.
• XmlChoiceIdentifier – Specifies that the member can be further disambiguated by
using an enumeration.
• XmlElement – Indicates that a public field or property represents an XML element
when the XmlSerializer serializes or deserializes the containing object.
154
• XmlElementAttributes – Represents a collection of XmlElementAttribute, which
the XmlSerializer uses to override the default way it serializes a class.
• XmlElementEventArgs – Provides data for the UnknownElement event.
• XmlEnum – Controls how the XmlSerializer serializes an enumeration member.
• XmlIgnore – Instructs the Serialize method of the XmlSerializer not to serialize the
public field or public read/write property value.
• XmlInclude – Allows the XmlSerializer to recognize a type when it serializes or
deserializes an object.
• XmlNamespaceDeclarations – Specifies that the target property, parameter, return
value or class member contains prefixes associated with namespaces that are used
within an XML document.
• XmlNodeEventArgs – Provides data for the UnknownNode event.
• XmlRoot – Controls XML serialization of the attribute target as an XML root
element.
• XmlSerializer – Serializes and deserializes objects into and from XML documents.
The XmlSerializer enables you to control how objects are encoded into XML.
• XmlSerializerNamespaces – Contains the XML namespaces and prefixes that the
XmlSerializer uses to generate qualified names in an XML-document instance.
• XmlText – Indicates to the XmlSerializer that the member should be treated as
XML text when the containing class is serialized or deserialized.
• XmlType – Controls the XML schema generated when the attribute target is
serialized by the XmlSerializer.
• XmlTypeMapping – Contains a mapping of one type to another.
155
Appendix C – WSDL Document for File Manager
<?xml version="1.0" encoding="utf-8" ?>
<wsdl:definitions xmlns:s1="http://microsoft.com/wsdl/types/"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns="http://tempuri.org/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="http://tempuri.org/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
<s:schema elementFormDefault="qualified" targetNamespace="http://tempuri.org/">
<s:import namespace="http://microsoft.com/wsdl/types/" />
<s:element name="GetRoot">
<s:complexType />
</s:element>
<s:element name="GetRootResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="GetRootResult" type="tns:Folder" />
</s:sequence> </s:complexType>
</s:element>
<s:complexType name="Folder">
<s:complexContent mixed="false">
<s:extension base="tns:FileSystem">
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="HasChild" type="s:boolean" />
</s:sequence> </s:extension> </s:complexContent>
</s:complexType>
<s:complexType name="FileSystem" abstract="true">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="Name" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="Path" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="ACLEntry" type="tns:ArrayOfGuid" />
</s:sequence> </s:complexType>
<s:complexType name="ArrayOfGuid">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded" name="guid" type="s1:guid" />
</s:sequence> </s:complexType>
<s:element name="GetFiles">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="folder" type="tns:Folder" />
</s:sequence> </s:complexType>
</s:element>
<s:element name="GetFilesResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="GetFilesResult" type="tns:ArrayOfFile" />
</s:sequence> </s:complexType>
156
</s:element>
<s:complexType name="ArrayOfFile"> <s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded" name="File" nillable="true" type="tns:File" />
</s:sequence> </s:complexType>
<s:complexType name="File"> <s:complexContent mixed="false">
<s:extension base="tns:FileSystem" />
</s:complexContent>
</s:complexType>
<s:element name="GetFolders">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="folder" type="tns:Folder" />
</s:sequence> </s:complexType>
</s:element>
<s:element name="GetFoldersResponse"> <s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="GetFoldersResult" type="tns:ArrayOfFolder" />
</s:sequence> </s:complexType>
</s:element>
<s:complexType name="ArrayOfFolder"> <s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded" name="Folder" nillable="true" type="tns:Folder"
/>
</s:sequence> </s:complexType>
<s:element name="GetDocumentInfo">
<s:complexType> <s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="uncPath" type="tns:File" />
</s:sequence> </s:complexType>
</s:element>
<s:element name="GetDocumentInfoResponse">
<s:complexType> <s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="GetDocumentInfoResult" type="tns:Document" />
</s:sequence> </s:complexType>
</s:element>
<s:complexType name="Document">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="Path" type="s:string" />
<s:element minOccurs="1" maxOccurs="1" name="CreationTime" type="s:dateTime" />
<s:element minOccurs="1" maxOccurs="1" name="LastAccessTime" type="s:dateTime" />
<s:element minOccurs="1" maxOccurs="1" name="LastWriteTime" type="s:dateTime" />
<s:element minOccurs="1" maxOccurs="1" name="Length" type="s:long" />
<s:element minOccurs="0" maxOccurs="1" name="Name" type="s:string" />
<s:element minOccurs="1" maxOccurs="1" name="GUID" type="s1:guid" />
<s:element minOccurs="1" maxOccurs="1" name="Owner" type="s1:guid" />
<s:element minOccurs="0" maxOccurs="1" name="Operation" type="tns:Operation" />
<s:element minOccurs="0" maxOccurs="unbounded" name="ACL" type="tns:ACLEntry" />
157
</s:sequence> </s:complexType>
<s:complexType name="Operation">
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="UserID" type="s1:guid" />
<s:element minOccurs="1" maxOccurs="1" name="Type" type="tns:OperationType" />
<s:element minOccurs="1" maxOccurs="1" name="Date" type="s:dateTime" />
</s:sequence> </s:complexType>
<s:simpleType name="OperationType">
<s:restriction base="s:string">
<s:enumeration value="CheckIn" />
<s:enumeration value="CheckOut" />
<s:enumeration value="Read" />
</s:restriction> </s:simpleType>
<s:complexType name="ACLEntry">
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="Principal" type="s1:guid" />
<s:element minOccurs="1" maxOccurs="1" name="Permission" type="tns:Permission" />
<s:element minOccurs="0" maxOccurs="1" name="PrincipalName" type="s:string" />
</s:sequence> </s:complexType>
<s:simpleType name="Permission"> <s:list>
<s:simpleType> <s:restriction base="s:string">
<s:enumeration value="FullControl" />
<s:enumeration value="Modify" />
<s:enumeration value="Read" />
<s:enumeration value="Write" />
<s:enumeration value="Security" />
</s:restriction> </s:simpleType>
</s:list> </s:simpleType>
<s:element name="ChangeOwner">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="token" type="s1:guid" />
<s:element minOccurs="0" maxOccurs="1" name="uncPath" type="s:string" />
</s:sequence> </s:complexType>
</s:element>
<s:element name="ChangeOwnerResponse">
<s:complexType />
</s:element>
<s:element name="AddACL">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="token" type="s1:guid" />
<s:element minOccurs="0" maxOccurs="1" name="uncPath" type="s:string" />
<s:element minOccurs="1" maxOccurs="1" name="principal" type="s1:guid" />
<s:element minOccurs="1" maxOccurs="1" name="type" type="tns:Permission" />
</s:sequence> </s:complexType>
158
</s:element>
<s:element name="AddACLResponse">
<s:complexType />
</s:element>
<s:element name="RemoveACL">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="token" type="s1:guid" />
<s:element minOccurs="0" maxOccurs="1" name="uncPath" type="s:string" />
<s:element minOccurs="1" maxOccurs="1" name="principal" type="s1:guid" />
</s:sequence> </s:complexType>
</s:element>
<s:element name="RemoveACLResponse">
<s:complexType />
</s:element>
</s:schema>
<s:schema elementFormDefault="qualified" targetNamespace="http://microsoft.com/wsdl/types/">
<s:simpleType name="guid"> <s:restriction base="s:string">
<s:pattern value="[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-
F]{12}"/>
</s:restriction> </s:simpleType>
</s:schema>
</wsdl:types> <wsdl:message name="GetRootSoapIn">
<wsdl:part name="parameters" element="tns:GetRoot" />
</wsdl:message>
<wsdl:message name="GetRootSoapOut">
<wsdl:part name="parameters" element="tns:GetRootResponse" />
</wsdl:message>
<wsdl:message name="GetFilesSoapIn">
<wsdl:part name="parameters" element="tns:GetFiles" />
</wsdl:message>
<wsdl:message name="GetFilesSoapOut">
<wsdl:part name="parameters" element="tns:GetFilesResponse" />
</wsdl:message>
<wsdl:message name="GetFoldersSoapIn">
<wsdl:part name="parameters" element="tns:GetFolders" />
</wsdl:message>
<wsdl:message name="GetFoldersSoapOut">
<wsdl:part name="parameters" element="tns:GetFoldersResponse" />
</wsdl:message>
<wsdl:message name="GetDocumentInfoSoapIn">
<wsdl:part name="parameters" element="tns:GetDocumentInfo" />
</wsdl:message>
<wsdl:message name="GetDocumentInfoSoapOut">
<wsdl:part name="parameters" element="tns:GetDocumentInfoResponse" />
</wsdl:message>
<wsdl:message name="ChangeOwnerSoapIn">
<wsdl:part name="parameters" element="tns:ChangeOwner" />
</wsdl:message>
<wsdl:message name="ChangeOwnerSoapOut">
<wsdl:part name="parameters" element="tns:ChangeOwnerResponse" />
</wsdl:message>
<wsdl:message name="AddACLSoapIn">
159
<wsdl:part name="parameters" element="tns:AddACL" />
</wsdl:message>
<wsdl:message name="AddACLSoapOut">
<wsdl:part name="parameters" element="tns:AddACLResponse" />
</wsdl:message>
<wsdl:message name="RemoveACLSoapIn">
<wsdl:part name="parameters" element="tns:RemoveACL" />
</wsdl:message>
<wsdl:message name="RemoveACLSoapOut">
<wsdl:part name="parameters" element="tns:RemoveACLResponse" />
</wsdl:message>
<wsdl:portType name="FileManagerSoap">
<wsdl:operation name="GetRoot">
<wsdl:input message="tns:GetRootSoapIn" />
<wsdl:output message="tns:GetRootSoapOut" />
</wsdl:operation> <wsdl:operation name="GetFiles">
<wsdl:input message="tns:GetFilesSoapIn" />
<wsdl:output message="tns:GetFilesSoapOut" />
</wsdl:operation> <wsdl:operation name="GetFolders">
<wsdl:input message="tns:GetFoldersSoapIn" />
<wsdl:output message="tns:GetFoldersSoapOut" />
</wsdl:operation> <wsdl:operation name="GetDocumentInfo">
<wsdl:input message="tns:GetDocumentInfoSoapIn" />
<wsdl:output message="tns:GetDocumentInfoSoapOut" />
</wsdl:operation> <wsdl:operation name="ChangeOwner">
<wsdl:input message="tns:ChangeOwnerSoapIn" />
<wsdl:output message="tns:ChangeOwnerSoapOut" />
</wsdl:operation> <wsdl:operation name="AddACL">
<wsdl:input message="tns:AddACLSoapIn" />
<wsdl:output message="tns:AddACLSoapOut" />
</wsdl:operation> <wsdl:operation name="RemoveACL">
<wsdl:input message="tns:RemoveACLSoapIn" />
<wsdl:output message="tns:RemoveACLSoapOut" />
</wsdl:operation> </wsdl:portType>
<wsdl:binding name="FileManagerSoap" type="tns:FileManagerSoap">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" /> <wsdl:operation name="GetRoot">
<soap:operation soapAction="http://tempuri.org/GetRoot" style="document" /> <wsdl:input>
<soap:body use="literal" /> </wsdl:input>
<wsdl:output>
<soap:body use="literal" /> </wsdl:output> </wsdl:operation>
<wsdl:operation name="GetFiles">
<soap:operation soapAction="http://tempuri.org/GetFiles" style="document" /> <wsdl:input>
<soap:body use="literal" />
160
</wsdl:input> <wsdl:output>
<soap:body use="literal" /> </wsdl:output> </wsdl:operation>
<wsdl:operation name="GetFolders">
<soap:operation soapAction="http://tempuri.org/GetFolders" style="document" /> <wsdl:input>
<soap:body use="literal" /> </wsdl:input>
<wsdl:output>
<soap:body use="literal" /> </wsdl:output> </wsdl:operation>
<wsdl:operation name="GetDocumentInfo">
<soap:operation soapAction="http://tempuri.org/GetDocumentInfo" style="document" /> <wsdl:input>
<soap:body use="literal" /> </wsdl:input>
<wsdl:output>
<soap:body use="literal" /> </wsdl:output> </wsdl:operation>
<wsdl:operation name="ChangeOwner">
<soap:operation soapAction="http://tempuri.org/ChangeOwner" style="document" /> <wsdl:input>
<soap:body use="literal" /> </wsdl:input>
<wsdl:output>
<soap:body use="literal" /> </wsdl:output> </wsdl:operation>
<wsdl:operation name="AddACL">
<soap:operation soapAction="http://tempuri.org/AddACL" style="document" /> <wsdl:input>
<soap:body use="literal" /> </wsdl:input>
<wsdl:output>
<soap:body use="literal" /> </wsdl:output> </wsdl:operation>
<wsdl:operation name="RemoveACL">
<soap:operation soapAction="http://tempuri.org/RemoveACL" style="document" /> <wsdl:input>
<soap:body use="literal" /> </wsdl:input>
<wsdl:output>
<soap:body use="literal" /> </wsdl:output> </wsdl:operation> </wsdl:binding>
<wsdl:service name="FileManager">
<documentation xmlns="http://schemas.xmlsoap.org/wsdl/" />
<wsdl:port name="FileManagerSoap" binding="tns:FileManagerSoap">
<soap:address location="http://localhost/share/FileManager.asmx" /> </wsdl:port>
161
</wsdl:service> </wsdl:definitions>
162
Appendix D – Starting Guide
9. This is a simple guide to install and develop using DMAPI framework.
10. Copy all files with extensions .asax, .asmx, .config and .dll into the inetpub folder in
the IIS folder (normally in C:\Inetpub\wwwroot\) with its respective application
root folder name (“share” is the name for this dissertation).
11. All .dll must be located in the “bin” folder under the application root folder.
12. In Internet Information Services console, right click on the application root folder
“share” and choose properties from the context menu. Click on the “Create”
button to configure this folder as an application in IIS.
163
13. Create a data store (in any physical hard disk/folder) with the following folder
structure.
14. Modify the root entry, UNCRoot and server name in Web.Config with the
correspondent data store location, UNC share path and the name of the respective
computer.
15. Make sure the ASP.Net runtime have full permission on the applications folder.
164
16. Test the following URL; http://localhost/share/FileManager.asmx,
http://localhost/share/UserManager.asmx,
http://localhost/share/WebService.asmx, and
http://localhost/share/WebStream.asmx.
165
Appendix E – Sample Application
1. The solution projects consists of three sub projects, DMS.Client, DMS.Object and
DMS.Service. DMS.Object containing the share classes which are used by both
DMS.Client and DMS.Service.
2. The following steps are used to setup the sample DMS client project.
3. Copy three projects into local development machine.
166
4. Open the solution project located in <local>\DMS.Service\DMS.sln.
5. Configure the DMS.Service project property web address if necessary (by pointing
to DMS.Service project in the project group).
6. Explore the code sample by opening the program entry class.
167
7. Press F7 to open the code window.
8. Please configure the solution using “Multiple Startup Projects” in order to debug
both web service and web service client.
168
9. Compile and run the project by pressing F5.
169
REFERENCES
Ageenko E. I., Franti P. (1997). Storage system for document imaging application. Department of Mechanics and Mathematics, State university of Uljanovsk, Russian.
Borghoff U. M., Hilf E. R., Pareschi R., Severiens T., Stamerjohanns H., Willamowski J. (1997). Agent-Based Document Retrieval for the European Physicists: A Project Overview. In: Proc. 2nd Int’l. Conf. on the Practical Application of Intelligent Agents and Multi-Agent Technology (PAAM ‘97), April 21-23, 1997, London, U. K., pp. 271-285.
Baldwin A., Beres Y., Casassa M. M., Shiu S. (2001). Trust Services: A Trust Infrastructure for E-Commerce. Trusted E-Services Laboratory, HP Laboratories Bristol.
Becker, P. & Eklund, P. (2001). Prospects for Document Retrieval using Formal Concept Analysis. Knowledge, Visualization and Ordering Laboratory (KVO) Distributed Systems Technology Centre (DSTC), Griffith University.
Bennett, Simon et al. (2002). Object-Oriented Systems Analysis and Design Using UML, 2nd Edition. U.K: McGraw Hill Companies, pp. 45-82, pp. 231-250.
Berczuk S. (1996). Configuration Management Patterns. Optimax Systems Corporation.
Berry C.A., Carnell J., Juric M. B., Kunnumpurath M. M., Nashi N., Romanosky S. (2002). J2EE Design Patterns Applied. Wrox Press, UK
Booch, Grady (1991). Object-oriented Design with Applications. The Benjamin/Cummings Publishing Company, Inc., pp. 36-74.
Borghoff U. M., Hilf E. R., Pareschi R., Severiens T., Stamerjohanns H., Willamowski J. (1997). Agent-Based Document Retrieval for the European Physicists: A Project Overview. In: Proc. 2nd Int’l. Conf. on the Practical Application of Intelligent Agents and Multi-Agent Technology (PAAM ‘97), April 21-23, 1997, London, U. K., pp. 271-285.
Browning P. (2003). Portals and Portal Frameworks. http://www.bris.ac.uk/is/projects/portal/portalbytes. University of Bristol.
170
Budd, Timothy (1991). An Introduction to Object-oriented Programming. Addison-Wesley Publishing Company, Inc., pp. 1-17, pp. 185-200.
Burns R. C., Long D. D. E. (1997). A Linear Time, Constant Space Differencing Algorithm. Department of Computer Science, University of California Santa Cruz. Santa Cruz, California.
Chi Chong, Wong and Sai Peck, Lee. Document Management Application
Programming Interface Framework. Proceedings of the Seventh International
Conference on Information Integration and Web Based Applications &
Services (iiWAS2005). Kuala Lumpur, Malaysia. 19-21 September, 2005.
Connolly D. (2002). Web Ontology (WebONT) Working Group Charter. W3C.
Cooper J. W. (2003). C# Design Patterns: A Tutorial. Addison Wesley. USA.
Eklund, P. (2001). A Structured Ontology and Information Retrieval Engine for Email Search and Discovery. Knowledge, Visualisation and Ordering Laboratory School of Information Technology, Griffith University.
Eklund, P. & Cole, R. (2002). Structured Ontology and Information Retrieval for Email Search and Discovery. School of Information Technology and Electrical Engineering, University of Queensland.
Fogel K. (2002). Open Source Development with CVS. http://cvsbook.red-bean.com/cvsbook.html.
Ghandeharizadeh S., Sommers F., Joisher K., Alwagait E. (2002). A Document as a Web Service: Two Complementary Frameworks. Department of Computer Science, University of Southern California, USA.
Ivar Jacobson, Grady Booch, James Rumbaugh (1999). The Unified Software Development Process, Addison Wesley
Jenny Preece (1994), Human-Computer Interaction. Pearson Education Limited.
Kenneth R. A., Sunil K. S. (1994). Experiences with Workflow Management: Issues for the Next Generation. ACM 0-89791 -689-1/94/001 0, CSCW 84- 10/94 Chapel Hill, NC, USA.
Kuropka, D. (1998) Specification and Implementation of a CORBA-Based Persistent Workflow Engine. Diplomhausarbeit. Institute for Information Systems, University at Munster, German.
171
Koulopoulus, T.M. and Frappaolo C. (1995). Electronic Management Systems, A Portable Consultant. McGraw Hill, New York.
Kounadis T. (2000). How to Pick the Best Portal. E-Business Advisor Magazine.
Laakso, S. A., Laakso K. P., Vartiainen, P., Saura, A. (1996). Problems with Save. Department of Computer Science, University of Helsinki.
Laforme D., Stropky Maria E. (1995). An Automated Mechanism for Effectively Applying Domain Engineering in Reuse Activities. Proceedings of the Annual International Conference on TRI-Ada 1995: Ada’s Role in Global Markets: Solutions for a Changing Complex World. Anaheim, California, United States. pp. 332-340.
Li Z. H., Francis Day Y., Fahmi H., Ghafoor A. (1997). A Multimedia Document Management System Using Temporal, Spatial and Content Based Indexing. Distributed Multimedia Systems Laboratory, School of Electrical and Computer Engineering.
Lindvall M., Rus I., Sinha S. S. (2002). Technology Support for Knowledge Management. Fraunhofer Center for Experimental Software Engineering, College Park, USA.
Microsoft (2002), Windows 2000 Resource Kit. Microsoft Press, Redmond, WA
Preece A., Flett A., Sleeman D., Curry D., Meany N., Perry P. (2001). Better Knowledge Management Through Knowledge Engineering: A Case Study in Drilling Optimisation. Department of Computing Science, University of Aberdeen.
Richard Sharpe (2002), Just what is SMB?. http://samba.anu.edu.au/cifs/docs/what-is-smb.html
Rob Slade (2004). Glossary of Communications, Computer, Data, and Information Security Terms. Victoria TelecommunityNet and Northern Illinois University.
Román H. L., Aburas H. M., M.S., Armacost J. P. (2002). Admission Application Processing: An Application in Computer Simulation. Office of Operational Excellence and Assessment Support and Department of Industrial Engineering & Management Systems, University of Central Florida.
Vossen, G., Weske, M. (1999). The WASA2 Object-Oriented Workflow Management System. Proc. ACM SIGMOD Conference on Management of Data, pp. 587–589. New York.
Walt Howe (2000). Glossary of Internet Terms.
172
Weske M., Kuropka D. (2001). Flexible Persistence Framework for Object-Oriented Middleware. Hasso Plattner Institute for Software Systems Engineering, Am Luftschiffhafen, Potsdam, Germany.
Wigging, B. (1994). Document Imaging, A Management Guide. Meckler Publishing, Westport, CT.
173
SUPPLEMENT
The following paper has been accepted and simultaneously published in:
1. Proceedings of the Seventh International Conference on Information Integration
and Web Based Applications & Services (iiWAS2005). Kuala Lumpur, Malaysia.
19-21 September, 2005.
Title of the paper: Document Management Application Programming Interface
Framework
Name of the Authors: Wong Chi Chong and Sai Peck Lee
Abstract: This project is about the development of a Document Management
Application Programming Interface (DMAPI) for dealing with capturing and
preserving software artifacts using a document-oriented approach. The project
proposes a basic framework for preserving formal knowledge from knowledge
workers. It is essential to implement a document repository in such a way that is
accessible via any web-based infrastructure and providing a more convenient way for
document accessing. Moreover, the details of an artifact stored are being preserved as
documents in their native formats. The documents ontology, file extensions or any
other alternative difference that are generally unpopular will be implemented via the
proposed Application Programming Interfaces (APIs), which will be able to
differentiate the likely fine components of the document types. Instead of representing
these documents as rigid static files, a document representation should act as a
container of a wide variety of information, or at least pointers to related information
174
that are dynamically assembled as they are retrieved. Finally, yet importantly, with
this proposed DMAPI in place, software developers can further enhance and extend
related business domains using this extensible framework in the near future.
