<%BANNER%>

Transnational information sharing and event notification

University of Florida Institutional Repository

PAGE 1

TRANSNATIONAL INFORMATION SHARING AND EVENT NOTIFICATION By THRITY R. KASAD A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLOR IDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2003

PAGE 2

Copyright 2003 by Thrity R. Kasad

PAGE 3

I dedicate this to my parents

PAGE 4

ACKNOWLEDGMENTS This research was supported by grant EIA-0131886 from the National Science Foundation. I would like to express my sincere gratitude to Dr. Stanley Y. W. Su, chairman of my supervisory committee, for providing me with such an interesting thesis topic and for his valuable guidance and support in this research effort. I would also like to express my gratitude to Dr. Herman Lam, my supervisory committee member, for his feedback and guidance during the design and implementation phases of my research work. I would like to thank Dr. Joachim Hammer for serving on my supervisory committee. I take this opportunity to thank Ms. Sharon Grant, the secretary of the Database Systems Research and Development Center, for all the time and effort she spends in making the Center a pleasant place to work. I would like to extend my sincere thanks to Ms. Long Yu, Ph.D. student, for her contribution in the design of the example scenarios and the overall mechanism to demonstrate the use of the ETR technology in the Transnational Digital Government Framework. I am also grateful to Lakshmi Chakarapani, Prasad Menon, and my friends from the C.I.S.E Department for their help during the implementation of the prototype system. On a more personal note, Id like to thank my beloved parents, and my sisters and their families. Without their love, support and constant encouragement, none of this would have been possible. iv

PAGE 5

TABLE OF CONTENTS Page ACKNOWLEDGMENTS.................................................................................................iv LIST OF TABLES............................................................................................................vii LIST OF FIGURES.........................................................................................................viii ABSTRACT.........................................................................................................................x CHAPTER 1 INTRODUCTION........................................................................................................1 1.1 Background and Motivation...................................................................................1 1.2 Challenges and Proposed Solutions........................................................................4 1.3 Thesis Organization................................................................................................7 2 SURVEY OF ENABLING TECHNIQUES AND TECHNOLOGIES........................9 2.1 Distributed Query Processing.................................................................................9 2.1.1 Overview......................................................................................................9 2.1.2 Query Processing for Heterogeneous Database Systems...........................11 2.2 Event-Trigger-Rule (ETR) Technology...............................................................13 2.2.1 Events.........................................................................................................13 2.2.2 Rules...........................................................................................................14 2.2.3 Triggers.......................................................................................................16 2.2.4 Event Manager............................................................................................16 2.2.5 ETR Server.................................................................................................17 2.2.6 Knowledge Profile Manager.......................................................................17 2.2.7 Persistent Object Manager..........................................................................18 2.2.8 Metadata Manager......................................................................................18 2.3 Java Related Technologies...................................................................................18 2.3.1 Java Servlets...............................................................................................18 2.3.2 Java Server Pages.......................................................................................19 2.3.3 Tomcat Servlet Engine...............................................................................19 2.4 Extensible Markup Language...............................................................................20 2.5 Extended Stylesheet Language Transformations..................................................20 2.6 Web Services Technology....................................................................................21 2.7 Simple Object Access Protocol............................................................................22 2.8 Axis Toolkit..........................................................................................................23 v

PAGE 6

3 SYSTEM ARCHITECTURE.....................................................................................25 3.1 Overview...............................................................................................................25 3.2 Distributed Query Processor.................................................................................28 3.3 Publishing and Subscribing to Events..................................................................29 3.4 Posting and Notification of Events.......................................................................31 4 DISTRIBUTED QUERY PROCESSOR...................................................................32 4.1 Global Query Processing Component..................................................................33 4.2 Local Query Processing Component (LQPC)......................................................37 4.2.1 LQPC as a Web Service.............................................................................38 4.2.2 Wrapper Architecture of the LQPC............................................................39 5 EXAMPLE SCENARIOS TO DEMONSTRATE THE ROLE PLAYED BY THE ETR TECHNOLOGY................................................................................................42 5.1 Security Rule for Distributed Query Processor....................................................42 5.2 Police Arrest Record Scenario..............................................................................44 5.3 Person in the Watch List Scenario........................................................................44 6 IMPLEMENTATION DETAILS...............................................................................46 6.1 Distributed Query Processor.................................................................................46 6.1.1 Global Query Processing Component........................................................46 6.1.2 Local Query Processing Component..........................................................52 6.2 Registration, Subscription and Posting of Events.................................................58 6.2.1 Registering an Event...................................................................................59 6.2.2 Subscribing to an Event..............................................................................60 6.2.3 Posting an Event.........................................................................................62 7 CONCLUSION AND FUTURE WORK...................................................................65 LIST OF REFERENCES...................................................................................................68 BIOGRAPHICAL SKETCH.............................................................................................70 vi

PAGE 7

LIST OF TABLES Table page 4-1 Role list based on information access privileges.....................................................35 6-1 Configuration files for global query processing component....................................48 6-2 Description of objects and attributes stored in POM...............................................55 6-3 Attributes of restrictqaccess: return object for security rule of the distributed query processor...................................................................................................................58 vii

PAGE 8

LIST OF FIGURES Figure page 1-1 Transnational collaboration grids...............................................................................2 2-1 Generic layering scheme for distributed query processing......................................10 2-2 Web service architecture model...............................................................................21 2-3 XML messaging using SOAP..................................................................................23 3-1 Overall architecture of the proposed system............................................................25 4-1 Belize entry/exit forms.............................................................................................32 4-2 Dominican Republic entry/exit form........................................................................33 4-3 Architecture of the distributed query processor.......................................................34 4-4 Architecture of the LQPC........................................................................................38 5-1 Flow chart depicting access control mechanism......................................................43 6-1 Registered users and their roles from tomcat-users.xml..........................................47 6-2 Global query form....................................................................................................48 6-3 Global schema..........................................................................................................49 6-4 SOAP request sent to LQPC....................................................................................51 6-5 Query results for a super user...................................................................................51 6-6 Query results for a role D user (no access to departure information)......................52 6-7 WSDD file to deploy Dominican Republic LQPC web service..............................53 6-8 WSDD file to undeploy Dominican Republic LQPC web service..........................53 6-9 SOAP response from Dominican Republic LQPC web service...............................54 6-10 Sample configuration file for the MEM database....................................................56 viii

PAGE 9

6-11 Event registration page at OAS site.........................................................................60 6-12 Event subscription page for police arrest record scenario........................................61 6-13 Arrest.htm to post Arrest event................................................................................62 6-14 Watch list related immigration scenario...................................................................63 6-15 Immigration form at port of entry in the Dominican Republic................................63 ix

PAGE 10

Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science TRANSNATIONAL INFORMATION SHARING AND EVENT NOTIFICATION By Thrity R. Kasad August 2003 Chair: Stanley Y. W. Su Major Department: Computer and Information Science and Engineering In todays world, the emergence of digital government is creating a new paradigm for collaboration among governments and agencies empowered with cutting-edge computational tools. A successful transnational digital government program would need to address several issues to achieve the desired goal of international collaboration. These issues can be briefly outlined as the ability to share information and resources across heterogeneous platforms without compromising government policies on data security and privacy; and the mechanism to achieve close communication and coordination among people and organizations in a timely manner. This thesis describes the design and implementation of a distributed query processor to show the querying of heterogeneous, immigration-related data of participating countries. This query processor applies and demonstrates the techniques of data mediation and conversion, distributed query processing, and security policy enforcement. A uniform standard-based infrastructure, the Web Services infrastructure, is used to enable the invocation and communication among replicated system components. x

PAGE 11

This thesis also describes the concept and architecture of virtual transnational collaboration grids and the integration of the distributed query processor with an Event-Trigger-Rule (ETR) Server to enable the sharing of information resources, the timely notification of events, and the enforcement of government regulations and constraints to achieve close international coordination among governments and agencies. We demonstrate the use of events, triggers and rules in three scenarios: the use of a role-based access control mechanism to restrict data access in distributed query processing; the enforcement of privacy rules to filter out sensitive data in police arrest cases; and the alerting of relevant people and agencies when a person who is on the watch list enters a country. We also describe how our system can be integrated with other subsystems (such as the language translation system and the conversational user interface) being developed by other research groups in the transnational digital government project funded by the National Science Foundation. xi

PAGE 12

CHAPTER 1 INTRODUCTION 1.1 Background and Motivation Governments increasingly need to collaborate and share information with each other to solve many global problems such as illicit drug trafficking, border control, disease control, global education and terrorism. Transnational digital government can be defined as applying information technology to develop more responsive, efficient and accountable intergovernmental operations. Information systems, which support transnational digital government procedures, require countries to voluntarily participate in the collection, processing, exchange, and integration of information. These systems face many challenges such as, how to Protect, control access to, filter, summarize, correlate and share information across agencies and organizations without compromising the security, laws, autonomy, and culture of the countries Interoperate transparently across countries whose heterogeneous information networks differ in design, reliability, performance, and technological age. Gather, represent, share, translate, and retrieve multilingual information. At present, agencies in different countries independently collect data varying in accuracy, completeness, promptness, and compliance with international agreements. Under the support of a grant from the National Science Foundation of the United States, researchers at five universities (Carnegie Mellon University, University of Belize, University of Colorado, University of Florida, University of Massachusetts, and Ponticia Universidad Catolica Madrey Maestra); and experts from agencies in three countries (the 1

PAGE 13

2 Organization of American States (OAS) of the United States, the National Drug Abuse Control Council of Belizes Ministry of Health, and the National Drug Council of the Dominican Republic) are developing information technologies to enable resource sharing and collaboration and coordination among agencies of the collaborating countries. The developed technologies will enable the establishment of collaboration grids over the Internet (Figure 1-1). Figure 1-1. Transnational collaboration grids In each collaboration grid, participating countries can seamlessly integrate transnational activities and policies into their national government processes, so that each countrys public service agencies can have controlled access and use of data and application resources of the agencies of another country. The agencies of each country can participate in the activities of multiple collaboration grids to share information and

PAGE 14

3 application resources needed to solve different transnational problems. The participating agencies in each collaboration grid may have their own interagency policies on when, how, and what resources can be shared. The information technologies being developed by the members of the NSF project include conversational interface, language translation, collaborative information management, Internet portals and services, and network support for collaboration grids. The work presented in this thesis is part of the R&D effort in collaborative information management. To develop and test the technologies to enable collaborative information management, we must identify an application area that can provide real data for the testing. After several meetings with project members and agencies in both Belize and the Dominican Republic, it was decided that immigration and border control is the common problem faced by both countries. Both countries want to have a way of tracking the movement of people coming in and going out of the airports, seaports, and land-ports; and to be able to share the information. They want to have a way of informing relevant agencies when suspicious people, who may be involved in activities associated with illicit drug trafficking or other crimes, attempt to enter or exit the countries. To meet both countries urgent needs, the project members decided to develop a distributed information prototype system to test and demonstrate the application of the general technologies being developed by project members. The system can later be extended and used to solve similar transnational problems. At the Database Systems R&D Center of the University of Florida, we have developed a web-based prototype information system that will be replicated and installed at two hosting sites in the collaborating countries (initially Belize and the Dominican

PAGE 15

4 Republic). The purpose of this system is to provide an effective tool for government agencies in each country to identify and share information about individuals who may present a potential or imminent threat to society. This system is a stepping stone toward achieving the overall goal, coordinating the interorganizational activities of the participating nations. It will enable the agencies of participating countries, to access distributed data; and automatically notify relevant people and agencies about the occurrences of important events (e.g., a suspicious person attempting to enter the country, the arrest of a person who has entered the country) and to suggest the actions that should be taken by the informed people and agencies. The distributed and heterogeneous data would provide a source for analyzing trends and identifying behavior patterns related to illegal activities. 1.2 Challenges and Proposed Solutions Several challenges exist in building such a web-based information system. We shall discuss them and briefly mention our approach to meet these challenges. One challenge is that the data gathered by ports of entry in both Belize and the Dominican Republic are stored in different formats, structures, schemas, and natural languages (Belize uses English and the Dominican Republic uses Spanish). These heterogeneities prevent users from accessing data gathered by agencies of both countries simultaneously. In this work, we design and implement a distributed query processor that uses techniques for data mediation, conversion, and language translation. The users of this system use a single web-based interface to query databases of one or more participating nations using varied search criteria. The query processor forms subqueries that are then sent to the countries whose databases are being queried. Wrappers are pieces of code specifically tailored for accessing the particular countries databases. When a query is issued by the distributed

PAGE 16

5 query processor, these pieces of code deployed at the local sites are invoked and they convert the subqueries sent by the distributed query processor to the corresponding queries to be processed by the local database systems. The data retrieved from local databases are assembled and returned to the user. Secondly, close coordination and communication among people/organizations in a timely manner is crucial to the process of transnational collaboration. For example, if police authorities need to know about suspicious individuals entering the country, they would request for this data. This process might result in delayed and inaccurate data delivery. The agencies, which are doing the pulling of data, need to know what to pull and when to pull. Another problem with this pull model is that it only works with one-to-one interaction. This results in wasted processing power and bandwidth since there might be several users of the system pulling for the same data at the same time. Also different countries and different organizations within the same country may have their own policies, regulations and constraints regarding what, when, and how resources can be accessed by others. For instance, while querying for visitor entry/exit information, there might be some users such as officials of the tourism department of a particular country who have access to the data related to tourism (which is provided in the entry form) but do not have access to immigration-related information in the same form. In this work, we use the Knowledge Web Server developed at the Database Systems Research and Development Center, University of Florida, which combines the features of the push and pull model of information access and delivery and provides advanced event filtering and rule processing capabilities. The Knowledge Web Server is comprised of an Event Server, an Event-Trigger-Rule (ETR) Server and other associated

PAGE 17

6 components [1-3]. It provides a tool for defining events, triggers and rules. Any thing of interest (a real-world event, a database state, the enactment of a process, etc.) can be modeled as an event. Events trigger the processing of rules. These rules define the conditions to be verified and the actions or alternative actions that need to be performed when certain events occur (e.g., sending out notification to concerned agencies, enforcing transnational policies, constraints and enforcing data security and privacy rules.). Thirdly, application systems are implemented in different programming languages and run on different operating systems and computing platforms. A uniform standard based infrastructure to enable software resource sharing and interoperation of heterogeneous application systems is required. Our system is based on the web services model wherein any self-contained, modular application can be described, published, located, and invoked over the Internet via HTTP. Simple Object Access Protocol (SOAP) [4] is the protocol used to publish and invoke the web services. To achieve transnational sharing and notification of information, the system needs to provide a mechanism to allow agencies in different countries to publish events that are of interest to collaborating agencies. Also, the users of the system should be able to browse and identify events published by other agencies in order to subscribe to them. In this work, we establish a central registry at the Organization of American States (OAS) web site. This registry provides a mechanism for event registration and subscription. At this site, a user can browse and select the event of his/her interest and fill out a form (i.e., an event filter template) to define an event filter and provide his/her subscription information, which is sent and installed in the Event Server of the site where the event may occur. Upon the occurrence of the event, all the users who subscribed to the event

PAGE 18

7 and whose event filter conditions are satisfied will be notified by either email or cellular phone. In this work, we have developed a distributed query processor and its associated web interface for querying immigration-related data for the two participating countries. We also integrate it with the Knowledge Web Server and its associated GUI tools to demonstrate the enforcement of three general types of events and rules: the enforcement of role-based access control when a user queries for distributed data, the detection and notification of suspicious people entering a country, and the notification of a police arrest. We also provide an architectural overview of an integrated system, which would integrate the work reported in this thesis with those component systems being developed by other members of this project. 1.3 Thesis Organization This thesis is organized as follows. In Chapter 2, we describe the various technologies, techniques and protocols being used to implement the distributed information system to achieve transnational sharing of information. In Chapter 3, we propose the overall architecture of the distributed system. We explain how the various components available in the participating countries and being developed by other project members can be integrated. In Chapter 4, we define the internal architecture of the distributed query processor and its various components. In Chapter 5, we describe the integration of the query processor with the Knowledge Web Server to demonstrate the implementation of security rules for access control. This chapter also describes two scenarios designed and implemented to demonstrate the process of event notification, filtering and information delivery. Chapter 6 includes implementation details of the

PAGE 19

8 system. Finally, in Chapter 7, we conclude our results and propose areas for further research.

PAGE 20

CHAPTER 2 SURVEY OF ENABLING TECHNIQUES AND TECHNOLOGIES In this chapter, we provide a survey of the techniques and technologies used to implement the active distributed query processor and the ETR-based system to enable transnational notification and sharing. Section 2.1 describes the basics of the distributed query processing technique in the context of heterogeneous databases. In Section 2.2, we provide an overview of the ETR technology that is the primary technology used to perform event, trigger and rule processing and management. In Section 2.3, we describe the Java related technologies; Java Servlets, Java Server Pages and the Tomcat servlet engine, which have been used to implement our system. Section 2.4 gives a brief description of the Extended Markup Language (XML) that has been used as the language to specify the queries sent to the local sites and the query results sent back from them. Section 2.5 describes XSLT (Extended Style Sheet Language Transformations), which is used to transform the XML based documents to HTML documents. Section 2.6 describes the web services technology used to implement interapplication communication over the Internet. Section 2.7 describes SOAP and its use as an XML-based protocol for the exchange of information in a distributed environment. An overview of the Apache Axis toolkit to implement web services is provided in Section 2.8. 2.1 Distributed Query Processing 2.1.1 Overview The objective of query processing in a distributed context is to transform a high-level query on a distributed database, which is seen as a single database by the 9

PAGE 21

10 users, into an efficient execution strategy expressed in a low-level query language used for manipulating local databases [5]. Query on Global Schema QUERY DECOMPOSITION Global Schema Algebraic Query on Global Schema CONTROL SITE DATA LOCALIZATION Fragment Schema Fragment Query GLOBAL OPTIMIZATION Statistics on Fragments Optimized Fragment Query with Communication Operations LOCAL LOCAL OPTIMIZATION Local Schema SITES Query on Global Schema Figure 2-1. Generic layering scheme for distributed query processing [5] The four main layers perform functions of query decomposition, data localization, global query optimization and local query optimization.

PAGE 22

11 Query decomposition. The high level query is decomposed into an algebraic query on global relations. The information needed for this transformation is found in the global conceptual schema. Four successive steps involved in this process are Normalize the query Semantically analyze the query to detect and reject incorrect queries Simplify the query to eliminate redundant predicates Restructure the query as an algebraic query. Data localization. This layer determines which fragments are involved in the query and transforms the distributed query into a fragment query. A distributed relation is reconstructed by applying certain fragmentation rules and using the information stored in the fragment schema. Global query optimization. This layer determines an optimal execution strategy for the query processor. This strategy takes into account the cost of executing all operations, including communication costs. Local query optimization. This layer is executed by the local sites. The local query is optimized using the local schema information at the sites. In this thesis, optimization of the query in terms of minimization of the total cost is not a critical part of the design. This is due to the fact that all the component databases have distinct information that is specific to the nations. Hence, there is no replication of data across local sites. Therefore, there would be one and only one query execution plan for a given search criteria. 2.1.2 Query Processing for Heterogeneous Database Systems In a heterogeneous database system, the component databases have different capabilities to store data.

PAGE 23

12 The two main challenges in querying heterogeneous databases are To find query plans that can be executed on all the component databases in the best possible way. To deal with system and data heterogeneities. In our distributed query processor, we are assuming that the component databases being queried are all standard SQL databases. Also, in our work, as mentioned earlier, the existence of a single query execution plan ensures that meeting the first challenge is trivial for our system. System heterogeneities arise due to differences in hardware/software platforms. These can be resolved by the use of a common communication infrastructure such as TCP/IP and RPC. Data heterogeneities [6, 7] can be classified into the following two types: Schematic heterogeneity: Owing to different ways of naming and structuring data Semantic heterogeneity: Owing to different meanings associated with data. These heterogeneities can be dealt by two basic approaches. They are Defining a global integrated schema that reconciles all the schematic conflicts and unifies the semantic differences. Using certain mediation rules or specifications to resolve data conflicts among component systems at run time. In our work, we use an approach that is based on both the global schema and mediation-based approach. We define a global/integrated schema, which is the union of the local schemas of the component databases. This schema is meant to provide a uniform interface to the users of the system to query the various component databases simultaneously. However, in order to eliminate the data heterogeneities, the system employs a wrapper-based architecture [8]. Wrappers (or adaptors) encapsulate the details of component databases they are associated with. The wrapper translates the query based

PAGE 24

13 on the global schema to a request that is understood by the component databases API. The wrapper also translates the results returned by the component database so that the results are compliant with the global schema of the heterogeneous system. The wrapper implements the mediation logic/code that is required to eliminate schematic and semantic heterogeneities. 2.2 Event-Trigger-Rule (ETR) Technology The Event-Trigger-Rule (ETR) technology serves to extend the Internet from a data network to a knowledge network. It also extends the existing Web Server into a Knowledge Web Server. The knowledge network allows consumers and providers of data to express their knowledge in the form of events, rules and triggers that are associated with the data and data processing. The contributed knowledge is incorporated into the current data network. This knowledge network employs the push model instead of the pull model of information dissemination .The push approach is highly scalable as a large number of subscribers can simultaneously be provided information. The ETR technology is based on an Active Object Model (AOM). In this framework, all things of interest are modeled as objects. As in the traditional object model, these objects can have attributes and methods. In addition, the AOM allows for inclusion of events, triggers and rules in an object class definition. The specification of these events, triggers and rules transforms distributed objects to active distributed objects. The ETR-enabled knowledge network provides a framework to publish events, subscribe to events and define rules on subscribed events. 2.2.1 Events Any item of interest can be modeled as an event. For instance, a police officials arrest of an individual can be an item of interest and thus can be defined as an event. An

PAGE 25

14 actual arrest signals an occurrence of the event (i.e., an event instance). Events can be broadly categorized into method associated events, explicitly posted events and timer events. Method associated events are tied to the execution of certain methods. The time when the event is posted such as before, after or on commit of a method defines the coupling modes. These are synchronous coupling modes. In such a coupling mode, the execution of the method is suspended till a response is returned from the rule processor. Instead of and decoupled are two other coupling modes. In the instead of mode, the rule body is executed in place of the method if a certain condition evaluates to true. The decoupled mode allows an event to be posted asynchronously. An explicitly posted event is raised independent of any method. The event can be raised in the body of any method by a PostSynchEvent or PostAsynchEvent call using the event instance as a parameter in the call. An explicitly posted event can be used to signal a database state, a program status, an exception condition, etc. A timer event is explicitly related to some time of interest, which is when it is posted. It is asynchronous in nature. For example, a timer can be set to post an event every second, every hour, or any other prespecified time interval. In our system, we define events that are posted explicitly and in the synchronous mode. 2.2.2 Rules A rule is a high level declarative specification of a granule of executable code that is related to an event or events. A rule is composed of condition, action and alternative action clauses. When an event is posted, the condition clause of the associated rule is checked and, if it evaluates to true, the action clause of the rule is executed. Otherwise,

PAGE 26

15 the alternate action clause is executed. A rule has parameters, the actual values of which are provided by the event at run time. Rule syntax can be defined as follows: RULE rule_name (parameter list) [RETURNS return_type] [DESCRIPTION description_text] [TYPE DYNAMIC/STATIC] [STATE ACTIVE/SUSPENDED] [RULEVAR rule variable declarations] [CONDITION guarded expression] [ACTION operation block] [ALTACTION operation block] [EXCEPTION exception & exception handler block] A rule has a name and a parameter list. The values of the parameter list are specified at run time by the event that triggers the rule. The return value of the rule is specified by the RETURNS clause. A textual description of the purpose of the rule is provided by the DESCRIPTION clause. The TYPE clause indicates whether a rule will be modified or not after the initial definition. Static rules are less likely to change; whereas, a dynamic rule may change at run time. The STATE clause defines if the rule is active or suspended. A suspended rule needs to be activated before it can be triggered. The RULEVAR declares the rule variables used in the rule body. The CONDITION clause specifies a guarded expression. A guarded expression has two parts; a guard part and an expression part. If the sequence of operations in the guard part evaluates to true, then the expression is evaluated. Thus the guard part screens out cases where the rule must be skipped. The ACTION clause specifies the code that needs to be executed if the CONDITION clause evaluates to true else the code specified by the ALTACTION clause is executed. If an exception occurs during rule evaluation, then it is handled by the EXCEPTION clause that ties an exception type to an exception handler.

PAGE 27

16 2.2.3 Triggers Events are associated with rules by means of triggers. Triggers map event attributes to rule parameters. A trigger is capable of specifying parallel rule executions. The trigger definition syntax is defined below: TRIGGER triggername (trigger parameters) TRIGGEREVENT events connected by OR [EVENTHISTORY event expression] RULESTRUC structure of rules [RETURNS return_type:rule is rule_in_rulestruct] Optional clauses are surrounded by braces. The TRIGGER clause defines the name of the trigger and the trigger parameters which are used optionally to bridge between event attributes and rule parameters. The TRIGGEREVENT clause specifies the event/events whose posting shall trigger the execution of the structure of rules specified by the RULESTRUCT clause. If more than one event is defined in the TRIGGEREVENT clause, they are logically Ored, meaning the occurrence of any of these events can trigger the evaluation of the EVENTHISTORY clause. This clause specifies a complex event expression, which makes some reference to events that have already occurred. If the EVENTHISTORY expression evaluates to true, then the rule structure specified in the RULESTRUC clause is executed. Optionally, a trigger can return a value specified by the RETURNS clause in the case of a synchronous event that triggers the structure of rules. 2.2.4 Event Manager The Event Manager handles the incoming and outgoing events from the web server. When a new event is defined, its meta-data is given to the Event Manager in order to enable it to recognize and handle the event. The Event Manager and the ETR Server are replicated and installed in multiple websites. Event Managers can communicate with each other for the purpose of sending and receiving events. The Event Manager is also

PAGE 28

17 responsible for performing event filtering before it sends out events to the subscribers in order to support a selective subscription of events. It also includes the event registration capability for remote clients to register their interest in subscribing to certain events provided by the Knowledge Web Server. Also, when the Event Manager receives an event from a remote web server, it passes it to the local ETR Server to initiate the processing of triggers and rules. 2.2.5 ETR Server The ETR Server processes the triggers and rules defined in the Knowledge Web Server. Trigger and rule definitions, which are input through the Knowledge Profile Manager (a component of the Knowledge Web Server), are provided to the ETR server and are transformed into internal data structures used. The ETR server receives events from the local Event Manager and performs the trigger and rule processing. On receiving an event, the ETR Server can immediately identify the trigger related to the event, efficiently process the event history, and schedule the rules specified in the trigger for processing. The ETR Server is also responsible for executing the rules. These rules are composed of method calls, which may execute local or remote applications, or invoke methods of distributed objects. The rule can also generate an event to trigger other rules. 2.2.6 Knowledge Profile Manager The Knowledge Profile Manager (KPM) [9] is responsible for maintaining the knowledge profile of the Event Provider and Subscriber sites. The knowledge profile contains the events, triggers and rules that are published/subscribed by the event providers/subscribers. The KPM provides a GUI for defining and editing events, triggers and rules.

PAGE 29

18 2.2.7 Persistent Object Manager The Persistent Object Manager (POM) [10] consists of two main components. Object-Relational mapping engine. XML-Relational mapping engine. The Object-Relational mapping engine provides a persistent storage facility for storing information related to the system. It also provides a high-level interface in the form of APIs for programs to store, retrieve, update, and delete objects without having to know the internal data structures of the objects. The XML-Relational mapping engine provides the persistence capability and a filtering mechanism to the Event Server at every site. It includes a parser that maps the filter definitions of the events stored in XML files to their relational representations. POM is implemented on top of an Object-Relational database system called Cloudscape. 2.2.8 Metadata Manager Once events, triggers and rules are created using the GUI provided by KPM, they are stored and maintained by the Meta Data Manager at the respective sites. Thus, the Meta Data Manager module within the KPM provides persistence for storing the user knowledge profiles. 2.3 Java Related Technologies 2.3.1 Java Servlets Servlets [11] are the Java platform technology of choice for extending and enhancing web servers. Servlets provide a component-based, platform independent method for building web-based applications, without the performance limitations of CGI programs. Unlike the proprietary server extension mechanisms (such as the Netscape Server API or Apache modules), servlets are server and platform independent.

PAGE 30

19 Servlets have access to the entire family of Java APIs, including the JDBC API to access enterprise databases. Servlets can also access a library of HTTP-specific calls and receive all the benefits of the mature Java language, including portability, performance, reusability, and crash protection. 2.3.2 Java Server Pages Java Server Pages (JSP) technology [11] is an extension of the Java Servlet Technology. Java Server Pages technology allows web developers and designers to rapidly develop and easily maintain, information-rich, dynamic web pages that leverage existing business systems. As part of the Java family, JSP technology enables rapid development of web-based applications that are platform independent. Java Server Pages technology separates the user interface from content generation enabling designers to change the overall page layout without altering the underlying dynamic content. Java Server Pages technology uses tags that encapsulate the logic that generates the content for the page. Additionally, the application logic can reside in server-based resources that the page accesses with these tags. Any and all formatting (HTML or XML) tags are passed directly back to the response page. By separating the page logic from its design and display and supporting a reusable component-based design, JSP technology makes it faster and easier than ever to build web-based applications. 2.3.3 Tomcat Servlet Engine Tomcat [12] is the servlet container that is used in the official Reference Implementation for the Java Servlet and Java Server pages technologies. The Java Servlet and Java Server Pages specifications are developed by Sun under the Java Community Process. Servlet container is a runtime shell that manages and invokes servlets on behalf of users. Tomcat will operate under any Java Development Kit (JDK) environment that

PAGE 31

20 provides a JDK 1.1 or JDK 1.2 compatible platform. The JDK is required so that servlets, other classes, and JSP pages can be compiled. 2.4 Extensible Markup Language Extensible Markup Language (XML) [13] is a simple, very flexible text format-based language derived from SGML (ISO 8879). It is a cross-platform, software and hardware independent tool for transmitting information. Originally designed to meet the challenges of large-scale electronic publishing, XML is also playing an increasingly important role in the exchange of a wide variety of data on the web and elsewhere. XML allows the author to define his/her own tags and his/her own document structure. XML can also be used to store data in files or in databases. Applications can be written to store and retrieve information from the store, and generic applications can be used to display the data. 2.5 Extended Stylesheet Language Transformations In most cases, it is required to transform information marked up in XML from one vocabulary to another. EXtended Style sheet Language Transformations (XSLT) [14] provides a powerful implementation of a tree-oriented transformation language for transmuting instances of XML using one vocabulary into an XML, HTML, plain text or any other text-based document. XSLT documents require an XSLT processor. Example: Microsoft IE 5 and Apache's XALAN. In an XSL transformation, two trees of nodes exist. The first node tree is the source tree. The nodes in this tree correspond to the original XML document to which the transformation is applied. The second node tree is the result tree. This tree contains all the nodes produced by the XSL transformation.

PAGE 32

21 2.6 Web Services Technology The web services technology is a platform that supports distributed computing over the web. The web services model defines a Service as a collection of operations that carry out some tasks. A web service is an interface that describes a collection of operations that are network accessible through standardized XML messaging. Figure 2-2. Web service architecture model [15] As described by Gottschalk [15], a web service is described using a standard, formal XML notation called its service description. It specifies all the details necessary to interact with the service, including message formats, transport protocols and location. The interface hides the implementation details of the service, allowing it to be used independently of the hardware and software platform on which it is implemented and also independently of the programming language in which it is written. This allows web services-based applications to be loosely coupled, component-oriented and cross technology implementations.

PAGE 33

22 2.7 Simple Object Access Protocol Simple Object Access Protocol (SOAP) is a simple, lightweight, XML based protocol that uses HTTP for exchange of information in a distributed environment. It defines formats for messages exchanged between distributed applications. SOAP is language and platform independent because it is based on XML. It provides a means for different applications running on different operating systems, with different technologies and programming languages to communicate with each other. In SOAP, everything that goes across the wire is expressed in terms of HTTP or SMTP headers, MIME encoding and special XML grammar, as defined by the SOAP specification. A SOAP message has the following three parts: A SOAP envelope that defines the content of the message An optional SOAP header that contains the header information A SOAP body that contains call and response information. The SOAP envelope declaration is the outermost XML tag that delineates the boundaries of the SOAP document. The SOAP header has information intended for the underlying infrastructure, such as transaction ID, where transaction ID is not part of the method signature. It is intended for the SOAP processor that receives the message. This processor may be a J2EE server with a transaction manager. The SOAP body is intended for the actual data, or message payload, to be consumed and processed by the ultimate receiver. XML messaging and network protocols form the basis of the web services architecture (Figure 2-3). XML messaging using SOAP is a four step process: 1. Client side application at the service requestor side makes the service invocation request. The SOAP engine generates the SOAP message for this request and the network protocol takes care of converting this message to the appropriate format and routes it to the web service provider.

PAGE 34

23 2. At the web service provider side, the SOAP engine identifies the service request and invokes the appropriate method in the server side application. 3. The server side application returns the results of the invocation to the SOAP engine and the results are routed back to the client in the form of a web service response. 4. The results of service invocation are returned to the client side application. Figure 2-3. XML messaging using SOAP [16] 2.8 Axis Toolkit Axis is a web services toolkit developed by Apache. It is a SOAP engine that provides a framework for constructing SOAP processors, such as clients, servers and gateways. The existing version of Axis is written using Java. Axis can be plugged into a servlet engine like Tomcat. It also provides a tool for monitoring TCP/IP packets that allow us to view the structure of SOAP messages exchanged between applications. Axis has features that allow for deployment of web services in a flexible way. One simple way of doing this is to save your service class in java as a .jws file. All jws files get automatically deployed as web services as their invocations actually invoke the Axis

PAGE 35

24 servlet. No further configuration is required on the part of the service deployer. Another more common way of deploying a web service involves making use of a Web Service Deployment Descriptor (WSDD). The Axis API, org.apache.axis.client.AdminClient is used to deploy a web service. A deployment descriptor contains the details that the Axis engine needs to know to deploy a Java class as a web service. It contains details such as the Java class name for a given service, mapping of QName (qualified name) information to Java classes for the purpose of serialization and deserialization. Axis also provides the API, org.apache.axis.client.Call that is used to invoke a web service operation. The API encapsulates generation and decoding of SOAP messages and provides a high level interface to invoke the web services operations. The Axis Users guide [17] describes how to use the toolkit.

PAGE 36

CHAPTER 3 SYSTEM ARCHITECTURE In this chapter, we provide a detailed explanation of the architecture of the system that has been designed and is being implemented. Section 3.1 gives an overview of the architecture. Section 3.2 describes the distributed query processor. Section 3.3 describes the components that help achieve publishing of events and subscribing to events. In Section 3.4, we describe the posting and notification of events. 3.1 Overview The overall system architecture for the proposed system is shown in Figure 3-1. Figure 3-1. Overall architecture of the proposed system 25

PAGE 37

26 It involves three sites: OAS Belize Dominican Republic. The Organization of American States (OAS) is the central site based in the United States. A collaboration portal will be installed at this site. The portal will act as a repository for all the global information, which is required to integrate the functioning of the system across different participating nations. The other two sites are in the countries of Belize and the Dominican Republic where the initial system will be deployed. Currently, we have two participating nations; however, the design of the overall system is such that it could be easily extended to add nations to the transnational digital government grid in the future. All these three sites are interconnected through the Internet (Figure 3-1). All exchanges of information shall be through the Internet. The users of the system (individuals/applications that will be using the system to share information) fall into three broad categories: Port of Entry Station (with Conversational Interface) personnel Personnel of various government agencies Authorized individuals in both countries. All the participating nations (two in the initial system) are assumed to have local databases that store immigration and other government process-related data. These databases have their own local Database Management Systems (DBMS) already installed. In our initial system, we assume that the databases are standard SQL databases. The software components installed at each of the participating nations sites are described below.

PAGE 38

27 Event Server. The Event Server is responsible for accepting event registrations and delivering the events to the subscribers. During event registrations, the users provide their event filters by selecting or providing values to attributes that are provided in the predefined event filter templates. These filters allow subscribers to have selective subscription to the events of their choice. On the one hand, the Event Server listens to events from the Event Servers of other sites and, on the other hand, it communicates with the ETR server to activate rules triggered by those events. ETR Server. The ETR server is responsible for the installation and processing of rules at each site. The KPM provides the ETR server with trigger and rule definitions, which the former translates to internal data structures. Whenever the ETR Server receives an event notification from the Event Server, it identifies the proper triggers and rules to be executed. As mentioned in the description of the ETR technology, three components interact with the Event Server and the ETR Server to ensure their proper functioning. They are Knowledge Profile Manager (KPM) Persistent Object Manager (POM) Meta Data Manager. The purpose and description of these components has been provided in Chapter 2 of this thesis. Translator. This component is crucial to the design of our system since the participating nations use different languages. Thus, any form of data transfer may require a translation from one language to another. In the current scenario, Belize uses English and the Dominican Republic uses Spanish as its national language. Thus, both the ETR server and the Distributed Query Processor would need to invoke the translator to

PAGE 39

28 translate words/text from English to Spanish and vice versa. This component of the system is being developed at the Carnegie Mellon University, and currently we are in the process of finalizing the API for invoking the translator module. In the present implementation of the system, we simulate the translator by creating a static table that has English-Spanish word mapping. Short Message Service Center. When a subscriber subscribes to an event, he/she has an option of getting notified via either email or cell phone. The latter requires routing the event notification message through the Short Message Service Center. During event notification, the Event Server looks up the cell phone number and the network of the subscriber, and then sends the message with SMTP to phone@messaging.cell-network.com The SMSC routes this message to the users cell phone as an SMS message. Distributed Query Processor. One of the major capabilities of the proposed system is to allow the user to query immigration related heterogeneous data stored in the databases of all the participating nations. 3.2 Distributed Query Processor The distributed query processor has two components: The global query processing component and the local query processing component. The global query processing component has a Global Search Form based on the integrated global schema. This component is replicated at both the Belize and Dominican Republic sites. Based on the local schema information provided by the distributed data dictionary, the global query processing component partitions the query to sub queries and sends them across to the local sites whose databases are being queried. The global query processing component plays the role of a web service client that invokes the local query processing component

PAGE 40

29 web service deployed at the local sites. As per the web services model, the query issued is wrapped as a SOAP message and sent using HTTP over the Internet. The local query processing component is made accessible over the Internet as a web service. This service is invoked by passing an XML query string as an argument to it. The local query processing component at each site has a unique wrapper which communicates with the local database and the Event Server, the ETR Server and the Translator which are also installed at the local site. The wrapper, after performing the global to local attribute mapping and language translation, if required, to eliminate all the data heterogeneities, issues the subquery to the local database. The local query results are mapped to global attribute names, translated if required, and sent back to the global query processing component as a response to the web service invocation. 3.3 Publishing and Subscribing to Events In this subsection, we describe a mechanism by which means a user of the system can publish an event so that other users can subscribe to it. Users of the system are distributed across all the participating nations. The OAS site serves as the portal where a user can publish his/her event along with a suitable event description. A user of the system will browse this site and be able to subscribe to an event of his/her interest by providing suitable event filter parameters and notification information. Publishing an Event to the OAS site. The event publisher is assumed to have already defined the event, event filter template, triggers and rules (if required) using the KPM GUI at his/her local site. While publishing an event to the OAS site, the publisher has to provide the event name, event filter template location, event publishers country and a brief description of the event through an HTML form. This form is posted to a servlet which reads the event filter template XML file, appends tags to represent

PAGE 41

30 placeholders for subscriber information, and uses this information to invoke a web service at the OAS site itself. This web service is deployed as a Java Web Service File and has the following functions: Reads the event filter template xml file from its given location. Based on the country name provided by the event publisher, the web service stores the corresponding event filter template XML file, in a separate subdirectory at the OAS site. This filter template is also translated into the languages supported by the other countries and stored in their respective subdirectories. The web service also uses the SAX-based XSLT processor to transform the XML file to a corresponding HTML file and stores it along with the XML file in the same subdirectory. It also appends the event name and event description to Java Server Pages, which have a listing for all published events at the OAS site in the various supported languages. This concludes the event publishing process for an event by an event publisher at the OAS site. Subscribing to an Event from the OAS site. A user who is interested in subscribing to any event visits the OAS web site page that is in his/her language and browses through a list of all published events. Based on the event descriptions provided, s/he makes a selection of the event that s/he wishes to subscribe to. Clicking on the URL associated with the event selected, the user is directed to the HTML form generated from the corresponding event filter template. The user fills out event filter template parameters and his notification information. Posting this form invokes a web service method deployed at the event publishing site. The forms parameters are wrapped into a SOAP message and transferred using HTTP to the site whose web service method is being invoked. This web service method takes the filter template parameter values and the

PAGE 42

31 notification information passed to it and invokes the local Event Server to append the new subscribers information into the POM. This marks the end of the event subscription process for a user. 3.4 Posting and Notification of Events An event can be posted in several ways, as explained in Chapter 2. When the event publisher posts an event to the local Event Server, the event server does three things upon receiving the event: Identifies subscribers to the event. Subscribers specify certain event filter attributes (i.e., specific values for certain event attributes) at the time of subscription. When an event is posted, the Event Server identifies all such subscribers of the event for whom the filter parameters match the corresponding attributes of the event posted. Passes the event onto the local ETR server to process the triggering of associated rules, if any. Notifies the subscribers of the event about the latters occurrence. This notification is done based on the subscribers preferred method of notification provided at the time of event subscription.

PAGE 43

CHAPTER 4 DISTRIBUTED QUERY PROCESSOR This chapter describes the distributed query processor to achieve transnational sharing of information. This distributed query processor has the capability to query immigration related entry-exit information of the two participating nations through a common web-based interface. Figure 4-1 and Figure 4-2 show the entry/exit forms of Belize and the Dominican Republic. Entering the completed forms into the respective databases is part of the duties of the countrys local application system. Our distributed query processor queries the data stored in the participating nations databases. Figure 4-1. Belize entry/exit forms 32

PAGE 44

33 Figure 4-2. Dominican Republic entry/exit form The architecture, the actual design of the components and the functional capabilities of the Distributed Query Processor are explained in this chapter. 4.1 Global Query Processing Component This component of the query processor is replicated at both query issuing sites. It is comprised of the Global Query Form, the Global Query Processor, Global Schema and the Data Distribution Directory. The data being queried through this system is actually based on the entry/exit forms that immigrants or visitors fill out upon arrival to or departure from a country. Therefore, the schema for the tables may have certain fields that are similar and certain fields that are dissimilar. A global schema file is constructed

PAGE 45

34 based on the schematic information of the immigration data stored across both countries. This global schema is essentially a UNION of the individual local schemas of the two nations. This global schema file is created using the KPM GUI tool to define schemas. Thus it is stored as a .met file with the Meta Data Manager. Figure 4-3. Architecture of the distributed query processor

PAGE 46

35 Apart from the schemas, the other meta-data required for the accurate functioning of the global query processing component are: Form Fields Information. This includes information about every attribute in the global schema, the country it is derived from and its corresponding display property on the global query form; (e.g., information like the passport number is derived from the schemas of both Belize and the Dominican Republic and would require a text box on the global query form). Country Information. This includes information about the web service (URL of the web service) and the method to be invoked to access the individual local query processing components. The global query form, a Java Server Page served by Tomcat 4.1, is constructed based on the global schema and the Form Fields Information. The global query processing component is deployed as a web application under Tomcat 4.1 at two query issuing sites. The global query form is thus accessible through the web. All the users privileged to use this system have associated user profiles comprising of username, password, nationality, and a set of roles from a predefined role set. This user profile information is stored using the role based authentication system provided by Tomcat. A users role determines the privilege of his/her information access. For example in our implementation, we have identified the roles described in Table 4-1. Table 4-1. Role list based on information access privileges Role User group Access information A Super ALL B Police Arrest information C Immigration Immigration information D User 1 Arrival-related immigration information E User2 Departure-related immigration information F Tourism Tourism information

PAGE 47

36 This set of roles has been created to demonstrate the capability of the system to achieve a centralized role based access mechanism [18]. The actual role set in the system to be deployed would be based on the access levels that the participating countries agree to have on the various fields in their database. The users country information stored as part of his/her profile is required to determine the language in which the global query form and the query results would be displayed to the user. Thus the global query form is available in all supported languages, but which form is actually displayed depends on the users country of citizenship information stored in his/her user profile. The specified roles determine the access category that the user falls under. For instance, Role A, the super user has access to immigration, police and tourism, all classes of information; whereas, the other roles define a more restricted scope of access. The global query form has a format in which a list of the global attribute names is displayed along with place holders for the user to specify the attributes he/she wishes to have displayed in the final result, and the values for the condition attributes in the query. The layout of the form is such that the query generated is in disjunctive normal form and can contain up to three ORed expressions. Each of these OR expressions are internally a conjunction of the query parameters provided in the form. The values that the user fills in determine the search criteria on which to query the system. The global query form allows the user the option of selecting the countries from which he/she wishes to query information. The system is designed to query for records matching the given criteria and to display the records and/or the count of the number of records matching the given search criteria. The information being queried by the system right now does not contain any numeric fields. If there were any such fields, the system

PAGE 48

37 could easily be extended to support other arithmetic group functions such as AVERAGE, MAX and MIN. Another selection, which the system user makes, is for the attributes he/she wishes to be displayed in the final output of the query processor. When the user submits the global search form, the global query processing component is invoked. This component is responsible for the following tasks: Identify the roles associated with the user. Identify the countries whose local query processing components are being invoked; (i.e., the countries whose databases are being queried). Identify the nature of the display format; records and/or count of records. Partition the query parameters and the selected output attributes based on the country information associated with each attribute in the Form Fields Information. Wrap the role information and the partitioned query into an XML document with a predefined Document Type Definition (DTD). Invoke the web service method of the countries whose databases are being queried by passing an XML string representing the query. A SOAP engine installed at the Query Issuing site provides the API, which has the methods that are required to invoke a web service with a specific URL and method name. Thus, the Global Query Processing Component is a web service client that invokes the Local Query Processing Component, which is deployed as a web service. Accepts the query results returned by the web service methods of countries being queried and applies suitable Extensible Style Sheet Transformation (XSLT) using the SAXON processor to convert the query results from XML to HTML format and display them in the web browser. The style sheet applied to the query results to generate the final display page is also available in all supported languages. The style sheet to be applied is determined by the users country of citizenship information stored as part of his/her profile in the web servers configuration. 4.2 Local Query Processing Component (LQPC) The second component of the Query Processor is the Local Query Processing Component. This component is meant to receive the subquery from the global query processing component of the query issuing site and to modify it to a query that can be

PAGE 49

38 issued to the local database. On the one hand, it connects to the local DBMS and, on the other hand, it also connects to the Event Server and the Translator installed at the local site. Section 4.2.1 describes the web service interface of the Local Query Processing Component. Section 4.2.2 describes the architecture of the Wrapper component of the LQPC and its interaction with the Event Server, the Translator, and the local DBMS. Figure 4-4. Architecture of the LQPC 4.2.1 LQPC as a Web Service The local query processing component is deployed as a web service using the Apache Axis toolkit (Axis 1.0) and saving all the Java class files for its deployment under Tomcat servlet engines webapps directory. Thus, the entire local query processing component is accessible on the Internet as a web service, which can be accessed just like

PAGE 50

39 a local application through SOAP. The local query processing components web service has an associated deployment descriptor, which contains deployment information for the web service. WSDD (Web Service Deployment Descriptor) is an XML format specific to Axis. With a WSDD, we specify which classes are to be deployed as a service, which particular methods are exposed to the web service clients and we select the scope of the service, implement handlers, etc. The Axis API, org.apache.axis.client.AdminClient, is used to deploy and undeploy a web service. Once this service is deployed, another site can simply invoke the web service by making an HTTP connection using the web service URL. Axis provides the API, org.apache.axis.client.Call that is used to invoke a web service operation. The API encapsulates the generation and decoding of SOAP messages and provides a high level interface to invoke the web services operations. The web service method takes a single string argument representing the subquery issued by the global query processing component in XML format. After the LQPC has queried the database, the query results in XML format are returned by the web service method as a string. 4.2.2 Wrapper Architecture of the LQPC The invoked web service method of the Local Query Processing Component passes the query in XML format to the wrapper. We define a unique wrapper, set of Java classes and mapping files, for each nations local database. This wrapper (Figure 4-4) integrates with the deployed web service class on the one hand and on the local DBMS on the other hand. This section describes each of these components and their role in the functioning of the LQPC. Extractor. This subcomponent receives the string subquery in XML format from the web service class and extracts the query and role information from it. This is achieved

PAGE 51

40 by parsing the XML document using a DOM-based parser. The Extractor returns five vectors and passes them onto the next subcomponent. These five vectors are Role vector: A vector of the roles associated with the query issuing user. Select Attribute Vector: A vector of all global attribute names requested by the query issuer in his/her query. Condition Attribute Vectors I, II and III: These three vectors contain lists of the global attribute names in each of the three OR expressions in the global query, respectively. The elements of each of these vectors will be ANDed together internally to form the query to be issued to the local database. Additionally, the extractor is also responsible for wrapping the query results into an XML document and sending the document back to the web service class to return it as a string to the web service invoking client: the global query processing component. Access Controller. The five vectors returned by the Extractor are input to the Access Controller. This subcomponent is responsible for connecting to the local Event Server to post a synchronous event (qaccess) that triggers a rule to check the access rights of the querying user on the attributes being accessed in the query. The role played by this component is explained in detail in Chapter 5. Translator. This subcomponent deals with the issue of data heterogeneities across local databases. The global attribute names in the query are mapped to the corresponding local attributes names in the database. This mapping is implemented as hash tables in Java. Due to the difference in the language in which data is stored in the local databases of the participating countries, sometimes it becomes necessary to translate the query attribute values in order to query the local database. For example: If a user wishes to issue a query that retrieves information about all individuals traveling in and out of the country for whom the immigration official had added a comment that had the word

PAGE 52

41 Intoxicated in the comment field. To query for such information from the Dominican Republic database, the system would be required to translate the word Intoxicated to Spanish and then issue the query. This translation would be done by invoking the Translator (also a component in the local system). Additionally, after the local database has been queried, the local query attribute names in the query result are mapped back to the global query attribute names by the translator. Sometimes, the level of semantic heterogeneity, which the LQPC has to deal with, might be too complex to be handled by a simple hashing table. A good example of this is the Ports of Embarkation and Ports of Disembarkation airports information. The Dominican Republic stores this information as three letter airport codes like JFK for the John F. Kennedy Airport, New York City, USA. In Belize, this same information is stored as a pair: airport city name + airport country name; in this case, New York + USA. The mapping for Ports of Embarkation and Ports of Disembarkation airports information is also stored in the POM, and the wrappers translator subcomponent uses the POMs API retrieve airport-related information during query processing. Query Processor. The Query Processor connects to the local database and issues the translated query to it. The query results are sent back to the translator that maps the local attribute names to global attribute names, passes the query results to the extractor which wraps them into an XML document, and sends the document back to the web service class, which sends back the query results as a SOAP message to the client that invoked the LQPC web service.

PAGE 53

CHAPTER 5 EXAMPLE SCENARIOS TO DEMONSTRATE THE ROLE PLAYED BY THE ETR TECHNOLOGY In this chapter we shall describe the use of the ETR technology to define events, triggers and rules to show how this technology can be used in our project to enforce data privacy and security rules and to demonstrate automatic event notification, event filtering and information delivery. 5.1 Security Rule for Distributed Query Processor Our system assigns roles to users, which determine the access privileges of users who issue queries through the Distributed Query Processor. This role based access control mechanism is achieved by defining a rule with the ETR server that checks the access right of a user having a particular role for local attributes being queried. This security rule (qaccessrule) is invoked by a separate subcomponent, the Access Controller of the wrapper of the Local Query Processing Component. The five vectors produced by the Extractor subcomponent of the LQPC wrapper are mapped to three by adding all three condition attribute vectors to one. These three vectors form the event attributes of the qaccess event. This is a synchronous event, which triggers the processing of qaccessrule security rule. These parameters are mapped to three rule input parameters. The rule returns an object of the restrictqaccess class that has the following attributes: Status Flag: A Boolean variable, which is set to true if the user (based on his/her role) has access to all attributes of the Condition Attribute Vector, else it is set to false. 42

PAGE 54

43 Vector rbattr: A vector of integers {0, 1} corresponding to every attribute in the Select Attribute Vector. A indicates that the user does not have access to this attribute and a indicates that he/she has access to this attribute. The process associated with the Access Control Mechanism is depicted in Figure 5-1. Figure 5-1. Flow chart depicting access control mechanism The rule action code accesses the local POM to query the roleAccess table. The roleAccess table is a role based access matrix, which stores the accessibility mapping of every user role to every attribute defined in the local schema. The rule action code uses the POMs API to query this table to return an object of the restrictqaccess. If the status flag of the restrictqaccess object is set to false, the LQPC sends back an XML string to

PAGE 55

44 the web service class indicating that the user does not have the access privilege to query the system based on the criteria provided. If the status flag is set to true, the restrictqaccess object is passed along with the five query vectors to the next subcomponent of the system, the Translator. Next we describe two scenarios, implemented to demonstrate event notification, filtering and data privacy rules in our system. 5.2 Police Arrest Record Scenario We define the occurrence of an arrest by the police authority of a country as an event (Arrest). This event is posted by the officials by entering the arrest record information: defendants information, witness information and victims information. Subscribers to the arrest event shall provide event filter attribute values that specify the nature of the crime and the defendants nationality that they would be interested in. We also define a rule hideVicWitInfo. This rule enforces data privacy in the notification to the subscribers by suppressing the victim and witness information associated with the arrest. Posting of the Arrest event to the local Event Server causes the event server to look for all subscribers of the event whose event filter attribute values match those of the posted event. The event is then used to trigger the hideVicWitInfo rule stored with the local ETR server. Thus, the data, which would violate the privacy of the victim and the witness, is filtered out in the notification sent to the subscribers. 5.3 Person in the Watch List Scenario When a visitor enters a country and the immigration official fills out a port of entry application form, the program posts the Arrival event to the ETR Server which invokes the WatchListCheckRule to check if the visitor entering the country is on the Global

PAGE 56

45 Watch List of persons whose movements should be monitored. If not, the record is inserted into the local database table. If yes, the official is notified that the person is on the watch list, the record is inserted into the database, and an event (PEntry) is posted to the local Event Server. At the time of registration to the event, subscribers to this event shall provide event filter attribute values that specify the last name, first name and nationality of a person on the watch list. The posting of the event causes the Event Server to determine the subscribers who need to be notified about the individuals entry into the country. This notification is then sent out using the preferred notification mechanism of the event subscribers.

PAGE 57

CHAPTER 6 IMPLEMENTATION DETAILS Our system has been implemented using JDK 1.4, on a Windows NT platform. The Web Server used is Tomcat 4.1.18. Axis 1.0 toolkit is used to define, deploy and invoke the web services. The component databases have been implemented using Oracle 9i. In this chapter, we describe certain essential implementation details of our system. Section 6.1 describes the implementation details of the Distributed Query Processor. Implementation details regarding the registration of events, subscription to events and posting of events in our system are explained in Sections 6.2, 6.3 and 6.4, respectively. 6.1 Distributed Query Processor The distributed query processor has two components. The implementation of the two components: the global query processor and the local query processor are described here. 6.1.1 Global Query Processing Component A registered user of the system is assigned a set of roles and these roles along with the username, password and country of citizenship information form the users profile and are stored in the tomcat-users.xml file (Figure 6-1). There are two JSP files, which implement the Global Query Processing Component, are: Formcreation.jsp. This file reads the three configuration files (Table 6-1) and displays the global query form (Figure 6-2) based on the users country of citizenship information stored in the user profile. The users role is determined when the user logs 46

PAGE 58

47 into the system. A similar JSP file (Formcreationsp.jsp) displays the global search form in Spanish. This is based on the Spanish global schema file. The global schema is stored in parserARRIVAL-DEPARTURE.met (Figure 6-3). Figure 6-1. Registered users and their roles from tomcat-users.xml Query.jsp. This file uses the three configuration files and the form parameters from formcreation.jsp to generate the subqueries to be sent to the nations whose databases are being queried. A query sent to a local site shall contain only those global attributes that are present in its local schema. This JSP file acts as an Axis client and connects to the LQPC web service running at the queried sites. Figure 6-4 shows the SOAP message sent across to the LQPC web service, when the user is issuing a query to

PAGE 59

48 retrieve the last name, first name, ports of embarkation and disembarkation information of all visitors entering/exiting the Dominican Republic. Figure 6-2. Global query form Table 6-1. Configuration files for global query processing component. File name Description Fields parserARRIVAL-DEPARTURE.met This file defines the global schema, which is the UNION of the local schemas of all participating countries Attribute name, attribute data type. Country_info.txt This file contains information about all participating countries Country name, symbol, URL of its LQPC web service, web service method to be invoked. Form_info.txt This file contains form field information Global schema attribute, corresponding form entity, number of associated items, country symbols of countries having this attribute in their local schema.

PAGE 60

49 --This file defines the global schema which happens to be the union of all the schemas of the participating nations. ARRIVAL-DEPARTURE Individual ENTITY passportno REQUIRED PrimitiveType String dateofissue REQUIRED PrimitiveType String placeofissue-state REQUIRED PrimitiveType String placeofissue-country REQUIRED PrimitiveType String idno REQUIRED PrimitiveType String lastname REQUIRED PrimitiveType String firstname REQUIRED PrimitiveType String mi REQUIRED PrimitiveType String sex REQUIRED PrimitiveType String male REQUIRED PrimitiveType String female REQUIRED PrimitiveType String dateofentry REQUIRED PrimitiveType Date port-of-embarkation-code REQUIRED PrimitiveType String port-of-embarkation-city REQUIRED PrimitiveType String port-of-embarkation-country REQUIRED PrimitiveType String dateofdeparture REQUIRED PrimitiveType Date port-of-disembarkation-code REQUIRED PrimitiveType String port-of-disembarkation-city REQUIRED PrimitiveType String port-of-disembarkation-country REQUIRED PrimitiveType String dateofbirth REQUIRED PrimitiveType Date placeofbirth REQUIRED PrimitiveType String nationality REQUIRED PrimitiveType String occupation REQUIRED PrimitiveType String maritalstatus REQUIRED PrimitiveType String single REQUIRED PrimitiveType String married REQUIRED PrimitiveType String permanentaddress-street REQUIRED PrimitiveType String permanentaddress-number REQUIRED PrimitiveType String permanentaddress-city REQUIRED PrimitiveType String permanentaddress-state REQUIRED PrimitiveType String permanentaddress-country REQUIRED PrimitiveType String permanentaddress-zip REQUIRED PrimitiveType String airline-vehicle-vesselno REQUIRED PrimitiveType String intendedaddress-street REQUIRED PrimitiveType String intendedaddress-number REQUIRED PrimitiveType String intendedaddress-city REQUIRED PrimitiveType String intendedaddress-state REQUIRED PrimitiveType String intended-length-of-stay REQUIRED PrimitiveType String Figure 6-3. Global schema

PAGE 61

50 purpose-of-trip REQUIRED PrimitiveType String business REQUIRED PrimitiveType String pleasure REQUIRED PrimitiveType String conference REQUIRED PrimitiveType String official REQUIRED PrimitiveType String family/friends REQUIRED PrimitiveType String transit REQUIRED PrimitiveType String other REQUIRED PrimitiveType String visitedbefore REQUIRED PrimitiveType String yes REQUIRED PrimitiveType String no REQUIRED PrimitiveType String intended-accomodation REQUIRED PrimitiveType String hotel REQUIRED PrimitiveType String guesthouse REQUIRED PrimitiveType String boat REQUIRED PrimitiveType String private REQUIRED PrimitiveType String resort REQUIRED PrimitiveType String other REQUIRED PrimitiveType String special-interests REQUIRED PrimitiveType String nature REQUIRED PrimitiveType String diving/snorkeling REQUIRED PrimitiveType String fishing REQUIRED PrimitiveType String archaeology REQUIRED PrimitiveType String beaches REQUIRED PrimitiveType String other REQUIRED PrimitiveType String comments REQUIRED PrimitiveType String Figure 6-3. Continued The LQPC returns the query results as an XML string. Query.jsp applies an XSLT style sheet to this document to convert the XML document representing the query results to an HTML document. Figure 6-5 shows query results for a role-A super user who has access to all information being queried. The issued query requests for the last name, first name, ports of embarkation and disembarkation information of all visitors entering/exiting Belize and the Dominican Republic. Figure 6-6 shows the query results for the same query for a role D user who does not have access to disembarkation information. The query being considered is the same as the previous one.

PAGE 62

51 Figure 6-4. SOAP request sent to LQPC Figure 6-5. Query results for a super user

PAGE 63

52 Figure 6-6. Query results for a role D user (no access to departure information) 6.1.2 Local Query Processing Component The LQPC is deployed as a web service. With a Web Service Deployment Descriptor (WSDD), we specify which classes are to be deployed as a service, which particular methods are exposed to web service clients, select the scope of the service, implement handlers, etc. The Axis API, org.apache.axis.client.AdminClient, is used to deploy and undeploy a web service. Once this service is deployed, another site can simply invoke the web service by making an HTTP connection using the web service URL. Axis provides the API, org.apache.axis.client.Call, which is used to invoke a web service operation. The API encapsulates generation and decoding of SOAP messages and provides a high level interface to invoke the web services operations.

PAGE 64

53 The WSDD file to deploy the Dominican Republic LQPC web service is shown in Figure 6-7. Figure 6-8 shows the WSDD to undeploy the web service. The local query processing component web services are deployed as RPC services. This is the default style of service in Axis 1.0. Figure 6-9 shows the SOAP message representing the query results sent back from the Dominican Republic. This output has been obtained by running the tcpmon utility available with Axis toolkit. Figure 6-7. WSDD file to deploy Dominican Republic LQPC web service Figure 6-8. WSDD file to undeploy Dominican Republic LQPC web service We shall now describe the classes used to implement the LQPC. A point to be noted here is that, though the overall functioning of these classes is the same for all local query processing components, the data and language heterogeneities cause the actual files to be different for different nations. In this section, we describe the classes in the context of the Dominican Republic web service. DRServer. This class provides the DRInterface method which is the method used to invoke the DominicanR web service. This class also invokes the specxml class methods by instantiating a specxml object using the query XML string passed to the web

PAGE 65

54 service. The specxml class returns the query results to the DRServer class which returns the XML string to the axis client (the global query processor). Figure 6-9. SOAP response from Dominican Republic LQPC web service

PAGE 66

55 specxml. This class contains methods to implement the Extractor, the Translator, the Access Controller, and the Query Processor of the wrapper of the Local Query Processing Component. mapAttr. This file creates hash tables for the mapping of the global v/s local attribute names by reading in the text file containing the global local attribute name pairs. QueryAirportInfo. This class provides methods to connect to the POM and query it for airport related information. Our system uses the Object-Relational Mapping Engine of the Persistent Object Manager to perform database operations. Therefore, it is necessary to have objects corresponding to the relational tables that we require. We have developed two objects, each of which corresponds to a relational table in our database. The data members in these objects and a brief description of their purposes are shown in Table 6-2. Table 6-2. Description of objects and attributes stored in POM Object/Table Description of object Data members Type Description Airport This object/table contains the airport related information associated with the ports of embarkation and disembarkation Airportcode airportcity airportcountry String String String Three letter airport code Airport city name Airport country name roleAccess This object/table describes the role based access matrix for all the attributes in the local database Tbname Attribname roleA_super roleB_police String String Int Int Table Name Attribute name 0 or 1 depending on whether a super user has access to the particular attribute 0 or 1 depending on whether a user in police role has access to the particular attribute

PAGE 67

56 Table 6-2. Continued Object/Table Description of Object Data Members Type Description roleAccess roleC_immig roleD_user1 roleE_user2 roleF_tour Int Int Int Int 0 or 1 depending on whether a user in immigration role has access to the particular attribute 0 or 1 depending on whether a user in immigration role 1(arrival information) has access to the particular attribute 0 or 1 depending on whether a user in immigration role 2 (departure information) has access to the particular attribute 0 or 1 depending on whether a user in tourist role has access to the particular attribute To utilize the POM for persistent storage, a configuration file must be created and stored in the directory of the program that invokes the APIs of the POM. The database in which we store our systems tables is MemDB. The sample configuration file is shown in Figure 6-10. Figure 6-10. Sample configuration file for the MEM database The first parameter specified is the host on which the database is located. In our distributed query processor, all database operations are performed by the local query

PAGE 68

57 processing component. Hence, the value of the host parameter is localhost since the LQPC is a local application for a particular site. This parameter can also be a machine name or an IP address of a remote server. The second parameter is the connection port number. POM uses this port number for connection. No other program is allowed to use this port number. In our system, we have chosen 9099 as the port number. The final parameter specified is the name of the database. The database is created in the default path specified in the Persistent Object Managers settings. Now we shall describe the implementation of the access control mechanism for the Local Query Processing Component. We define the following: Event qaccess: We define an event qaccess using the KPM GUI tool. This event is posted by the Access Controller subcomponent of the LQPC. This event takes the role vector, select attribute vector, and condition attribute vector and passes them to the qaccessrule rule to implement access control. Rule qaccessrule: This rule is described below RULE qaccessrule(Vector selattr, Vector whereattr, Vector roleattr) RETURNS restrictqaccess DESCRIPTION This rules takes in 3 vectors as input parameters (selattr, whereattr, roleattr), checks them against the role access information stored in POM to either reject the query or accept it and return a 0/1 access vector for all attributes in the select attribute vector. RULEVAR Temporary Object ra; CONDITION true ACTION restrictqaccess ra=new restrictqaccess(); ra.restrictmethod(roleattr,selattr,whereattr);return ra; ALTACTION EXCEPTION The restrictqaccess class has two attributes (Table 6-3).

PAGE 69

58 Table 6-3. Attributes of restrictqaccess: return object for security rule of the distributed query processor Name Type Description Flag Boolean False: query rejected True: query accepted Rbattr Vector A vector of 0s and 1s corresponding to whether a user has access to a particular select attribute in the Select Attribute Vector or not. The only method in restrictqaccess is the restrictmethod(), which connects to the POM and queries the roleAccess table to determine if the user has access to the particular set of attributes. If the user does not have access to even a single element in the Condition Attribute Vector, flag is set to false else it is set to true. restrictmethod() also sets the elements of the rbattr vector to 1 or 0 based on whether the user (associated with a sequence of roles) has or does not have access to the elements of the Select Attribute Vector. 6.2 Registration, Subscription and Posting of Events We have defined the following two scenarios to demonstrate our system. Police Arrest Record Scenario: Event-Arrest: This event is posted when a police official enters the arrest record information: defendants information, witness information, and victims information pertaining to a particular arrest. Event FilterArrestFilter: If the arrest is related to a particular crime and the associated person is from a particular country. RulehideVicWitInfo: Suppress the victim and witness information in the message sent out to the subscribers.

PAGE 70

59 Person in the Watch List Scenario: EventArrival: This event is posted from a port of entry application form when an individual enters the country. Its purpose is to trigger the WatchListCheckRule. RuleWatchListCheckRule: Checks if the person entering the country is on the watch list. If yes, a warning message is displayed on the screen and the PEntry event is posted. If the person entering the country is not on the watch list or if the suspicious person is allowed to enter the country, a port of entry record for that individual is inserted into the local countrys database. EventPEntry: This event is posted by the WatchListCheckRule when the person entering the country is on the global watch list. Event FilterPEntryFilter: If the individual entering the country has a particular last name, first name, and nationality. Notification is sent out to all subscribers whose filter attribute values match the corresponding values in the event posted. 6.2.1 Registering an Event To register an event at the OAS site, the user pulls up the Event Registration form (Figure 6-11), which asks for the Event Name, the users country name and the URI for the event filter template. This form is posted to RegisEvent servlet. In our current implementation, we assume that the event filter template XML file can be stored on any machine but has to be accessible via the web. Thus the servlet would read the event filter template file from its location. This event filter template XML file along with the event name, description and event publishers country, are used to invoke the EventRegister web service deployed at the OAS site. This web service is deployed simply by creating a

PAGE 71

60 Java Web Service (.jws) file for the web service class and placing this file under Tomcats webapps axis directory. Figure 6-11. Event registration page at OAS site EvntRegister.jws: This web service does the following: Writes the XML string representing the event filter template into the corresponding countrys subdirectory at the OAS site. Translates the XML string to all other supported languages and stores them in the respective subdirectories of the other countries. Converts the XML document to the corresponding HTML form that displays the event filter template with placeholders for subscribers to enter their notification information. Appends the new event information to the web pages containing the list of all published events in the various supported languages at the OAS site. 6.2.2 Subscribing to an Event When the user selects an event he/she wishes to subscribe to (from the web page displaying the list of published events), he/she is directed to the HTML event

PAGE 72

61 subscription page generated by the EvntRegister web service. The Event Subscription page generated for the Police Arrest Record Scenario is shown in Figure 6-12. After filling out the required information, the form gets posted to the subscribe servlet. This servlet wraps the subscription information in an XML string and invokes the WSETR web service at the event publishers site. This web service (WSETR.jws) performs the following functions: Parses the XML document passed to it using a DOM parser and extracts the subscribers information. Invokes the subscribe method of the Event Manager using the parsed subscription information. This method subscribes the user to the event of his/her choice and stores the subscription information in the local POM. Figure 6-12. Event subscription page for police arrest record scenario

PAGE 73

62 6.2.3 Posting an Event To post an event, an application needs to invoke the post method of the Distributor class of the Event Manager with the event name as a parameter. Police Arrest Record Scenario. On submitting the Arrest.htm form (Figure 6-13), the PostArrestFormEvent servlet is invoked. This servlet posts the Arrest event (using parameters provided by the HTML form) to the local Event Server. Figure 6-13. Arrest.htm to post Arrest event Person in the Watch List Scenario. Figure 6-14 depicts the overall implementation to demonstrate the posting of an event when a visitor enters a country and he/she is present in the global watch list of persons being monitored.

PAGE 74

63 Figure 6-14. Watch list related immigration scenario Figure 6-15. Immigration form at port of entry in the Dominican Republic

PAGE 75

64 The steps depicted in Figure 6-14 are described here. 1. Post an event to the ETR Server using field values from the Arrival Form submitted by port of entry official. 2. Check if the person is on the watch list. 3. If the person is on the watch list, 3a. Display a warning message. 3b. Post an Event to the Event Manager. 3c. Send email/cell phone notification to the subscribers of the event based on their subscription profiles. 4. If person is not on the watch list or suspicious person is allowed into the country, insert a port of entry record for that individual into the local countrys database. On submitting the Arrival form (Figure 6-15), the application posts the Arrival event to the local ETR server (step 1).This event triggers the WatchListCheckRule. This rule queries the watch list table in the local database to check if the visitor is on the watch list (step 2). If yes(step 3), an alert displaying a warning message pops up on the screen of the immigration official (step 3a) and the PEntry event is posted to the local Event Manager(step 3b) Once the event is posted to the Event Manager, the Event Manager identifies the subscribers of the event and sends them notification (step 3c).If the person is not on the watch list or a suspicious person is allowed to enter the country, a port of entry arrival record is inserted for this individual, into the countrys database.

PAGE 76

CHAPTER 7 CONCLUSION AND FUTURE WORK In this work, we have described the design and implementation of a distributed query processor and its integration with the Event-Trigger-Rule based system to achieve transnational information sharing and event notification. This system has the capability to query heterogeneous immigration-related data from the component databases of different nations. This is the first step towards meeting the end goal of the Transnational Digital Government Project: to develop advanced information technology for transnational resource sharing and intergovernmental and interorganizational coordination/collaboration over virtual collaboration grids. Our proposed transnational collaboration grid is comprised of network nodes installed in the participating countries. Each node at a participating nation consists of a distributed query processor, a Translator, a Web server, an Event Server, an ETR server, a Knowledge Profile Manager, a Persistent Object Manager, and a Meta Data Manager. The distributed query processor allows users of participating nations to access data across national boundaries. It also deals with the issues of mediating data heterogeneities across various databases. Furthermore, it makes use of the ETR server to implement a role based access control mechanism to enforce data security and privacy policies and rules. We have described the overall process of registering events with the OAS site in order to make them (events) accessible for subscription by users. This is followed by a description of how a user should subscribe to events of his/her interest from the OAS and the general mechanism for automatic event notification, event filtering, and information delivery. By 65

PAGE 77

66 defining and storing rules in the local ETR servers, the system achieves the capability of automatic information filtering and dissemination, enforcement of interorganizational policies, regulations and constraints, and security and privacy rules. This entire architecture helps achieve a push-based information sharing and notification mechanism across the transnational collaboration grids. We have also described two scenarios: the arrest record scenario and the person in the watch list scenario to demonstrate the use of the ETR technology in the context of the transnational digital government framework to demonstrate event notification, filtering, information delivery and rule processing. Our system is integrated with the web service technology to achieve a uniform standard-based infrastructure for interoperation of the heterogeneous application systems. In spite of the desirable features that the implemented system provides, several issues need to be further investigated. First, the language translator being developed at the Carnegie Melon University needs to be integrated with the distributed query processor and the event registration, filtering and notification mechanisms. Second, if the port of entry data is to be gathered by using the conversational interface system or the spoken dialog system contributed by the researchers at the University of Colorado, the integration of our system with theirs will have to be carried out. Third, when a user subscribes to an event, his/her subscription profile is sent to the event publishers knowledge web server even though the subscriber may be from a country different from the event publishers. Thus, when an event is posted, the Event Server of the provider would send notifications to all the subscribers. This can be very time-consuming if the number of subscribers is large and the notification is done by unicasting. A more efficient

PAGE 78

67 way is to distribute the subscription information of the subscribers in a country to the knowledge web server of that country. When an event occurs at the event provider side, the Event Server at that site can send a notification to the Event Servers of all other sites that contain subscription information of that event. These Event Servers can then process the event filters and send notifications to the subscribers in their respective countries. These and several other deployment-related issues are being resolved by interactions with research groups at the five universities and the government officials of the participating nations. Also, we need to identify other transnational digital government problems that can be solved by using the general information technologies introduced by the various research groups. The system prototype described in this thesis is meant to be a starting point for the intended distributed system. Once a stable system has been developed, research needs to be carried out to understand the practical realities of deploying, maintaining and using the system at the actual sites.

PAGE 79

LIST OF REFERENCES 1. Lee, M., Event and Rule Services for Achieving a Web-based Knowledge Network, PhD Dissertation, Department of Computer and Information Science and Engineering, University of Florida, Gainesville, Florida, 2000. 2. Lee, M., Su, S. Y. W., and Lam, H., Event and Rule Services for Achieving a Web-based Knowledge Network, Proceedings of the First Asia-Pacific Conference on Web Intelligence (WI-2001), Maebashi City, Japan, Oct 23-26, 2001. 3. Su, S. Y. W. and Lam, H., IKnet: Scalable Infrastructure for Achieving Internet-based Knowledge Network, Proceedings of the International Conference on Advances in Infrastructure for Electronic Business, Science, and Education on the Internet, lAquila, Rome, Italy, July 31-August 6, 2000. 4. Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielson, H., Thatte, S., Winer, D., Simple Object Access Protocol (SOAP) 1.1, May 2000. Available from URL: http://www.w3.org/TR/SOAP/ Accessed on: 04/2003. 5. Ozsu, T. and Valduriez, P., Principles of Distributed Database Systems, Second Edition, Prentice Hall, Englewood Cliffs, NJ, 1999. 6. Yu, T-F., Information Modeling and Mediation Languages and Techniques for Information Sharing among Heterogeneous Information Systems, PhD Dissertation, Department of Computer and Information Science and Engineering, University of Florida, Gainesville, Florida, 1997. 7. Su, S. Y. W. and Yu, T-F., Distributed Information Mediation and Query Processing in a CORBA Environment, International Symposium on Digital Media Information Base (DMIB ), Nara, Japan, November 26-28, 1997, pp 120-131. 8. Kossman, D., The State of the Art in Distributed Query Processing, ACM Computing Surveys, vol. 32, no. 4, December 2000, pp. 422-469. 9. Parui, U., Knowledge Profile Manager for Supporting Event-trigger-rule Services on the Internet, Masters Thesis, Department of Computer and Information Science and Engineering, University of Florida, Gainesville, Florida, 1999. 10. Shenoy, A., A Persistent Object Manager for Java Applications, Masters Thesis, Department of Computer and Information Science and Engineering, University of Florida, Gainesville, Florida, 2001. 68

PAGE 80

69 11. Hall, M., Core Servlets and JavaServer Pages (JSP), Prentice Hall PTR, 1 edition, 2000. 12. The Tomcat 4 Servlet/JSP Container, Available from URL: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/index.html Accessed on: 02/2003. 13. Deitel, H., Deitel, P., Nieto T., Lin, T. and Sadhu, P., XML How to Program, Prentice-Hall Inc., Upper Saddle River, New Jersey, 2001. 14. Holzner, S., Inside XSLT, New Riders Publishing, Indianapolis, Indiana, 2002. 15. Gottschalk, K., Web Services Architecture Overview The next stage of evolution for e-business, September 2000. Available from URL: http://www-106.ibm.com/developerworks/web/library/w-ovr Accessed on: 04/2003 16. Nagarajan, K., Integration of Business Events and Rules Management with the Web Services Model, Masters Thesis, Department of Computer and Information Science and Engineering, University of Florida, Gainesville, Florida, 2003, Figure 2-3, page 10. 17. Axis User Guide, Available from URL: http://docs.pushtotest.com/axisdocs/user-guide.html Accessed on: 04/2003. 18. Sandhu, R., Coyne, E., Feinstein, H. and Youman, C., Role Based Access Control Models, IEEE Computer, vol. 29, no. 2, February 1996, pp. 38-47.

PAGE 81

BIOGRAPHICAL SKETCH Thrity Kasad was born on May 22 nd 1979, in Navsari, Gujarat, India. She received a bachelors degree in computer engineering, securing first class with honors from the Maharaja Sayajirao University of Baroda, Baroda, India, in May 2001. In August 2001, she joined the University of Florida to pursue a masters degree in computer science and engineering. She has been a Teaching Assistant and a Research Assistant during her studies at the University of Florida. Her research interests include distributed query processing, active databases and object-oriented databases. 70


Permanent Link: http://ufdc.ufl.edu/UFE0001207/00001

Material Information

Title: Transnational information sharing and event notification
Physical Description: Mixed Material
Language: English
Creator: Kasad, Thrity R. ( Dissertant )
Su, Stanley Y. W. ( Thesis advisor )
Lam, Herman ( Reviewer )
Hammer, Joachim ( Reviewer )
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2003
Copyright Date: 2003

Subjects

Subjects / Keywords: Communication, International   ( lcsh )
Computer and Information Science and Engineering thesis, M.S
Rule based programming   ( lcsh )
Dissertations, Academic -- UF -- Computer and Information Science and Engineering

Notes

Abstract: In today's world, the emergence of digital government is creating a new paradigm for collaboration among governments and agencies empowered with cutting edge computational tools. A successful transnational digital government program would need to address several issues to achieve the desired goal of international collaboration. These issues can be briefly outlined as the ability to share information and resources across heterogeneous platforms without compromising government policies on data security and privacy; and the mechanism to achieve close communication and coordination among people and organizations in a timely manner. This thesis describes the design and implementation of a distributed query processor to show the querying of heterogeneous, immigration related data of participating countries. This query processor applies and demonstrates the techniques of data mediation and conversion, distributed query processing, and security policy enforcement. A uniform standard based infrastructure, the Web Services infrastructure, is used to enable the invocation and communication among replicated system components. This thesis also describes the concept and architecture of virtual transnational collaboration grids and the integration of the distributed query processor with an Event Trigger Rule (ETR) Server to enable the sharing of information resources, the timely notification of events, and the enforcement of government regulations and constraints to achieve close international coordination among governments and agencies. We demonstrate the use of events, triggers and rules in three scenarios: the use of a role based access control mechanism to restrict data access in distributed query processing; the enforcement of privacy rules to filter out sensitive data in police arrest cases; and the alerting of relevant people and agencies when a person who is on the watch list enters a country. We also describe how our system can be integrated with other subsystems (such as the language translation system and the conversational user interface) being developed by other research groups in the transnational digital government project funded by the National Science Foundation.
General Note: Title from title page of source document.
General Note: Includes vita.
Thesis: Thesis (M.S.)--University of Florida, 2003.
Bibliography: Includes bibliographical references.
General Note: Text (Electronic thesis) in PDF format.

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0001207:00001

Permanent Link: http://ufdc.ufl.edu/UFE0001207/00001

Material Information

Title: Transnational information sharing and event notification
Physical Description: Mixed Material
Language: English
Creator: Kasad, Thrity R. ( Dissertant )
Su, Stanley Y. W. ( Thesis advisor )
Lam, Herman ( Reviewer )
Hammer, Joachim ( Reviewer )
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2003
Copyright Date: 2003

Subjects

Subjects / Keywords: Communication, International   ( lcsh )
Computer and Information Science and Engineering thesis, M.S
Rule based programming   ( lcsh )
Dissertations, Academic -- UF -- Computer and Information Science and Engineering

Notes

Abstract: In today's world, the emergence of digital government is creating a new paradigm for collaboration among governments and agencies empowered with cutting edge computational tools. A successful transnational digital government program would need to address several issues to achieve the desired goal of international collaboration. These issues can be briefly outlined as the ability to share information and resources across heterogeneous platforms without compromising government policies on data security and privacy; and the mechanism to achieve close communication and coordination among people and organizations in a timely manner. This thesis describes the design and implementation of a distributed query processor to show the querying of heterogeneous, immigration related data of participating countries. This query processor applies and demonstrates the techniques of data mediation and conversion, distributed query processing, and security policy enforcement. A uniform standard based infrastructure, the Web Services infrastructure, is used to enable the invocation and communication among replicated system components. This thesis also describes the concept and architecture of virtual transnational collaboration grids and the integration of the distributed query processor with an Event Trigger Rule (ETR) Server to enable the sharing of information resources, the timely notification of events, and the enforcement of government regulations and constraints to achieve close international coordination among governments and agencies. We demonstrate the use of events, triggers and rules in three scenarios: the use of a role based access control mechanism to restrict data access in distributed query processing; the enforcement of privacy rules to filter out sensitive data in police arrest cases; and the alerting of relevant people and agencies when a person who is on the watch list enters a country. We also describe how our system can be integrated with other subsystems (such as the language translation system and the conversational user interface) being developed by other research groups in the transnational digital government project funded by the National Science Foundation.
General Note: Title from title page of source document.
General Note: Includes vita.
Thesis: Thesis (M.S.)--University of Florida, 2003.
Bibliography: Includes bibliographical references.
General Note: Text (Electronic thesis) in PDF format.

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0001207:00001


This item has the following downloads:


Full Text












TRANSNATIONAL INFORMATION SHARING AND EVENT NOTIFICATION


By

THRITY R. KASAD













A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2003

































Copyright 2003

by

Thrity R. Kasad

































I dedicate this to my parents















ACKNOWLEDGMENTS

This research was supported by grant EIA-0131886 from the National Science

Foundation. I would like to express my sincere gratitude to Dr. Stanley Y. W. Su,

chairman of my supervisory committee, for providing me with such an interesting thesis

topic and for his valuable guidance and support in this research effort. I would also like to

express my gratitude to Dr. Herman Lam, my supervisory committee member, for his

feedback and guidance during the design and implementation phases of my research

work. I would like to thank Dr. Joachim Hammer for serving on my supervisory

committee.

I take this opportunity to thank Ms. Sharon Grant, the secretary of the Database

Systems Research and Development Center, for all the time and effort she spends in

making the Center a pleasant place to work. I would like to extend my sincere thanks to

Ms. Long Yu, Ph.D. student, for her contribution in the design of the example scenarios

and the overall mechanism to demonstrate the use of the ETR technology in the

Transnational Digital Government Framework. I am also grateful to Lakshmi

Chakarapani, Prasad Menon, and my friends from the C.I.S.E Department for their help

during the implementation of the prototype system.

On a more personal note, I'd like to thank my beloved parents, and my sisters and

their families. Without their love, support and constant encouragement, none of this

would have been possible.
















TABLE OF CONTENTS
Page

A C K N O W L E D G M E N T S ................................................................................................. iv

L IST O F T A B L E S ................................................................................ ..... vii

LIST OF FIGURES ................................................. ........ ........... viii

A B ST R A C T .......... ..... ...................................................................................... x

CHAPTER

1 IN TR OD U CTION ............................................... .. ......................... ..

1.1 B background and M motivation ............................................................................. .. 1
1.2 Challenges and Proposed Solutions.............................................. .................. 4
1.3 Thesis Organization .................. ........................... ....... .................

2 SURVEY OF ENABLING TECHNIQUES AND TECHNOLOGIES........................9

2 .1 D distributed Q uery P processing ................................................................................9
2.1.1 Overview .............................................................9
2.1.2 Query Processing for Heterogeneous Database Systems...........................11
2.2 Event-Trigger-Rule (ETR) Technology .................................... ............... 13
2.2.1 Events ................................. ............................... ....... 13
2 .2 .2 R u le s ................................14.............................
2.2.3 Triggers ............... .......... .............. 16
2.2.4 Event Manager ............................ ................. ...............16
2 .2 .5 E T R S e rv er ........................................................................................... 17
2.2.6 Knowledge Profile Manager ............. ......................... ......... 17
2.2.7 Persistent Object M manager .............................................................. 18
2 .2 .8 M etadata M manager ................................................................................ 18
2.3 Java Related Technologies ................. .................................18
2.3.1 Java Servlets .................................................................................... .... ......18
2.3.2 Java Server Pages ............................................................ ............ 19
2.3.3 Tom cat Servlet E ngine ....................................................... 19
2.4 Extensible M arkup Language ................... ................................. ....................20
2.5 Extended Stylesheet Language Transformations...................... ...............20
2.6 W eb Services Technology ............................................................................21
2.7 Sim ple Object A access Protocol .........................................................................22
2 .8 A x is T oolkit ........................................................................................ .......2 3


v









3 SYSTEM ARCHITECTURE ......................................................... ............. 25

3.1 O overview .................................................................................................... ......25
3.2 D distributed Q uery Processor........................................... .......................... 28
3.3 Publishing and Subscribing to Events ...................................... ............... 29
3.4 Posting and N otification of Events.................................................................... 31

4 DISTRIBUTED QUERY PROCESSOR ....................................... ............... 32

4.1 Global Query Processing Component ...................................... ............... 33
4.2 Local Query Processing Component (LQPC) ............................................... 37
4.2.1 LQPC as a W eb Service ........................................ ........................ 38
4.2.2 Wrapper Architecture of the LQPC.....................................................39

5 EXAMPLE SCENARIOS TO DEMONSTRATE THE ROLE PLAYED BY THE
E TR T E C H N O L O G Y ........................................................................ ..................42

5.1 Security Rule for Distributed Query Processor .......................................... 42
5.2 Police A rrest R record Scenario........................................ .......................... 44
5.3 Person in the W atch List Scenario.................................... ........................ 44

6 IMPLEMENTATION DETAILS.................................................................. 46

6.1 Distributed Query Processor............... .............................. 46
6.1.1 Global Query Processing Component ................................. ............... 46
6.1.2 Local Query Processing Component...................................................52
6.2 Registration, Subscription and Posting of Events...................... .. ............. 58
6.2.1 R egistering an E vent........................................................ ............... 59
6.2.2 Subscribing to an Event .......... .. ................................. ..... .......... 60
6.2.3 Posting an Event .................. ............................ .... .... ................. 62

7 CONCLUSION AND FUTURE WORK ....................................... ............... 65

L IST O F R E F E R E N C E S ............................. ...................................................................68

B IO G R A PH IC A L SK E TCH ..................................................................... ..................70
















LIST OF TABLES

Table p

4-1 Role list based on information access privileges .............................................. 35

6-1 Configuration files for global query processing component..................................48

6-2 Description of objects and attributes stored in POM .............................................55

6-3 Attributes of restrictqaccess: return object for security rule of the distributed query
processor ............................................................................ ........ ....... 58
















LIST OF FIGURES

Figure p

1-1 Transnational collaboration grids............... ................. ...... ......... 2

2-1 Generic layering scheme for distributed query processing ................................ 10

2-2 W eb service architecture m odel ........................................ .......................... 21

2-3 XM L m essaging using SOAP ............................................................................ 23

3-1 Overall architecture of the proposed system .......... ............................................25

4-1 B elize entry/exit form s ......... ..................... ......... .................................... 32

4-2 Dom inican Republic entry/exit form .................................... ........................ 33

4-3 Architecture of the distributed query processor .................. ...............34

4-4 Architecture of the LQPC ..... ........................................... ............................ 38

5-1 Flow chart depicting access control mechanism ............................................... 43

6-1 Registered users and their roles from tomcat-users.xml .......................................47

6-2 G global query form ....................... .. .......................... .. ....... ............... 48

6-3 G global scheme a ............. .... ............................. ............ ............49

6-4 SOAP request sent to LQPC .............................................................................. 51

6-5 Query results for a super user.......... ......... .......... ................. 51

6-6 Query results for a role D user (no access to departure information) ....................52

6-7 WSDD file to deploy Dominican Republic LQPC web service ...........................53

6-8 WSDD file to undeploy Dominican Republic LQPC web service ........................53

6-9 SOAP response from Dominican Republic LQPC web service............................54

6-10 Sample configuration file for the MEM database .......................................... 56









6-11 Event registration page at OA S site .............................................. ............... 60

6-12 Event subscription page for police arrest record scenario............... .......... 61

6-13 A rrest.htm to post A rrest event ........................................ .......................... 62

6-14 W watch list related immigration scenario........................................ ............... 63

6-15 Immigration form at port of entry in the Dominican Republic.............................63















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

TRANSNATIONAL INFORMATION SHARING AND EVENT NOTIFICATION

By

Thrity R. Kasad

August 2003

Chair: Stanley Y. W. Su
Major Department: Computer and Information Science and Engineering

In today's world, the emergence of digital government is creating a new paradigm

for collaboration among governments and agencies empowered with cutting-edge

computational tools. A successful transnational digital government program would need

to address several issues to achieve the desired goal of international collaboration. These

issues can be briefly outlined as the ability to share information and resources across

heterogeneous platforms without compromising government policies on data security and

privacy; and the mechanism to achieve close communication and coordination among

people and organizations in a timely manner.

This thesis describes the design and implementation of a distributed query

processor to show the querying of heterogeneous, immigration-related data of

participating countries. This query processor applies and demonstrates the techniques of

data mediation and conversion, distributed query processing, and security policy

enforcement. A uniform standard-based infrastructure, the Web Services infrastructure, is

used to enable the invocation and communication among replicated system components.









This thesis also describes the concept and architecture of virtual transnational

collaboration grids and the integration of the distributed query processor with an

Event-Trigger-Rule (ETR) Server to enable the sharing of information resources, the

timely notification of events, and the enforcement of government regulations and

constraints to achieve close international coordination among governments and agencies.

We demonstrate the use of events, triggers and rules in three scenarios: the use of a

role-based access control mechanism to restrict data access in distributed query

processing; the enforcement of privacy rules to filter out sensitive data in police arrest

cases; and the alerting of relevant people and agencies when a person who is on the watch

list enters a country. We also describe how our system can be integrated with other

subsystems (such as the language translation system and the conversational user

interface) being developed by other research groups in the transnational digital

government project funded by the National Science Foundation.














CHAPTER 1
INTRODUCTION

1.1 Background and Motivation

Governments increasingly need to collaborate and share information with each

other to solve many global problems such as illicit drug trafficking, border control,

disease control, global education and terrorism. Transnational digital government can be

defined as applying information technology to develop more responsive, efficient and

accountable intergovernmental operations.

Information systems, which support transnational digital government procedures,

require countries to voluntarily participate in the collection, processing, exchange, and

integration of information. These systems face many challenges such as, how to

* Protect, control access to, filter, summarize, correlate and share information across
agencies and organizations without compromising the security, laws, autonomy,
and culture of the countries

* Interoperate transparently across countries whose heterogeneous information
networks differ in design, reliability, performance, and technological age.

* Gather, represent, share, translate, and retrieve multilingual information.

At present, agencies in different countries independently collect data varying in

accuracy, completeness, promptness, and compliance with international agreements.

Under the support of a grant from the National Science Foundation of the United

States, researchers at five universities (Carnegie Mellon University, University of Belize,

University of Colorado, University of Florida, University of Massachusetts, and Ponticia

Universidad Catolica Madrey Maestra); and experts from agencies in three countries (the








Organization of American States (OAS) of the United States, the National Drug Abuse

Control Council of Belize's Ministry of Health, and the National Drug Council of the

Dominican Republic) are developing information technologies to enable resource sharing

and collaboration and coordination among agencies of the collaborating countries. The

developed technologies will enable the establishment of collaboration grids over the

Internet (Figure 1-1).



Country X

--- _d i.-. q' mi s"
-,,. a ro ,


Dominican
Republic


Figure 1-1. Transnational collaboration grids


In each collaboration grid, participating countries can seamlessly integrate

transnational activities and policies into their national government processes, so that each

country's public service agencies can have controlled access and use of data and

application resources of the agencies of another country. The agencies of each country

can participate in the activities of multiple collaboration grids to share information and









application resources needed to solve different transnational problems. The participating

agencies in each collaboration grid may have their own interagency policies on when,

how, and what resources can be shared. The information technologies being developed by

the members of the NSF project include conversational interface, language translation,

collaborative information management, Internet portals and services, and network

support for collaboration grids. The work presented in this thesis is part of the R&D

effort in collaborative information management.

To develop and test the technologies to enable collaborative information

management, we must identify an application area that can provide real data for the

testing. After several meetings with project members and agencies in both Belize and the

Dominican Republic, it was decided that immigration and border control is the common

problem faced by both countries. Both countries want to have a way of tracking the

movement of people coming in and going out of the airports, seaports, and land-ports;

and to be able to share the information. They want to have a way of informing relevant

agencies when suspicious people, who may be involved in activities associated with illicit

drug trafficking or other crimes, attempt to enter or exit the countries. To meet both

countries' urgent needs, the project members decided to develop a distributed information

prototype system to test and demonstrate the application of the general technologies

being developed by project members. The system can later be extended and used to solve

similar transnational problems.

At the Database Systems R&D Center of the University of Florida, we have

developed a web-based prototype information system that will be replicated and installed

at two hosting sites in the collaborating countries (initially Belize and the Dominican









Republic). The purpose of this system is to provide an effective tool for government

agencies in each country to identify and share information about individuals who may

present a potential or imminent threat to society. This system is a stepping stone toward

achieving the overall goal, coordinating the interorganizational activities of the

participating nations. It will enable the agencies of participating countries, to access

distributed data; and automatically notify relevant people and agencies about the

occurrences of important events (e.g., a suspicious person attempting to enter the country,

the arrest of a person who has entered the country) and to suggest the actions that should

be taken by the informed people and agencies. The distributed and heterogeneous data

would provide a source for analyzing trends and identifying behavior patterns related to

illegal activities.

1.2 Challenges and Proposed Solutions

Several challenges exist in building such a web-based information system. We shall

discuss them and briefly mention our approach to meet these challenges. One challenge is

that the data gathered by ports of entry in both Belize and the Dominican Republic are

stored in different formats, structures, schemas, and natural languages (Belize uses

English and the Dominican Republic uses Spanish). These heterogeneities prevent users

from accessing data gathered by agencies of both countries simultaneously. In this work,

we design and implement a distributed query processor that uses techniques for data

mediation, conversion, and language translation. The users of this system use a single

web-based interface to query databases of one or more participating nations using varied

search criteria. The query processor forms subqueries that are then sent to the countries

whose databases are being queried. Wrappers are pieces of code specifically tailored for

accessing the particular countries' databases. When a query is issued by the distributed









query processor, these pieces of code deployed at the local sites are invoked and they

convert the subqueries sent by the distributed query processor to the corresponding

queries to be processed by the local database systems. The data retrieved from local

databases are assembled and returned to the user.

Secondly, close coordination and communication among people/organizations in a

timely manner is crucial to the process of transnational collaboration. For example, if

police authorities need to know about suspicious individuals entering the country, they

would "request for" this data. This process might result in delayed and inaccurate data

delivery. The agencies, which are doing the pulling of data, need to know what to pull

and when to pull. Another problem with this pull model is that it only works with

one-to-one interaction. This results in wasted processing power and bandwidth since

there might be several users of the system pulling for the same data at the same time.

Also different countries and different organizations within the same country may have

their own policies, regulations and constraints regarding what, when, and how resources

can be accessed by others. For instance, while querying for visitor entry/exit information,

there might be some users such as officials of the tourism department of a particular

country who have access to the data related to tourism (which is provided in the entry

form) but do not have access to immigration-related information in the same form.

In this work, we use the Knowledge Web Server developed at the Database

Systems Research and Development Center, University of Florida, which combines the

features of the push and pull model of information access and delivery and provides

advanced event filtering and rule processing capabilities. The Knowledge Web Server is

comprised of an Event Server, an Event-Trigger-Rule (ETR) Server and other associated









components [1-3]. It provides a tool for defining events, triggers and rules. Any thing of

interest (a real-world event, a database state, the enactment of a process, etc.) can be

modeled as an event. Events trigger the processing of rules. These rules define the

conditions to be verified and the actions or alternative actions that need to be performed

when certain events occur (e.g., sending out notification to concerned agencies, enforcing

transnational policies, constraints and enforcing data security and privacy rules.).

Thirdly, application systems are implemented in different programming languages

and run on different operating systems and computing platforms. A uniform standard

based infrastructure to enable software resource sharing and interoperation of

heterogeneous application systems is required. Our system is based on the web services

model wherein any self-contained, modular application can be described, published,

located, and invoked over the Internet via HTTP. Simple Object Access Protocol (SOAP)

[4] is the protocol used to publish and invoke the web services.

To achieve transnational sharing and notification of information, the system needs

to provide a mechanism to allow agencies in different countries to publish events that are

of interest to collaborating agencies. Also, the users of the system should be able to

browse and identify events published by other agencies in order to subscribe to them. In

this work, we establish a central registry at the Organization of American States (OAS)

web site. This registry provides a mechanism for event registration and subscription. At

this site, a user can browse and select the event of his/her interest and fill out a form (i.e.,

an event filter template) to define an event filter and provide his/her subscription

information, which is sent and installed in the Event Server of the site where the event

may occur. Upon the occurrence of the event, all the users who subscribed to the event









and whose event filter conditions are satisfied will be notified by either email or cellular

phone.

In this work, we have developed a distributed query processor and its associated

web interface for querying immigration-related data for the two participating countries.

We also integrate it with the Knowledge Web Server and its associated GUI tools to

demonstrate the enforcement of three general types of events and rules: the enforcement

of role-based access control when a user queries for distributed data, the detection and

notification of suspicious people entering a country, and the notification of a police

arrest. We also provide an architectural overview of an integrated system, which would

integrate the work reported in this thesis with those component systems being developed

by other members of this project.

1.3 Thesis Organization

This thesis is organized as follows. In Chapter 2, we describe the various

technologies, techniques and protocols being used to implement the distributed

information system to achieve transnational sharing of information. In Chapter 3, we

propose the overall architecture of the distributed system. We explain how the various

components available in the participating countries and being developed by other project

members can be integrated. In Chapter 4, we define the internal architecture of the

distributed query processor and its various components. In Chapter 5, we describe the

integration of the query processor with the Knowledge Web Server to demonstrate the

implementation of security rules for access control. This chapter also describes two

scenarios designed and implemented to demonstrate the process of event notification,

filtering and information delivery. Chapter 6 includes implementation details of the







8


system. Finally, in Chapter 7, we conclude our results and propose areas for further

research.














CHAPTER 2
SURVEY OF ENABLING TECHNIQUES AND TECHNOLOGIES

In this chapter, we provide a survey of the techniques and technologies used to

implement the active distributed query processor and the ETR-based system to enable

transnational notification and sharing. Section 2.1 describes the basics of the distributed

query processing technique in the context of heterogeneous databases. In Section 2.2, we

provide an overview of the ETR technology that is the primary technology used to

perform event, trigger and rule processing and management. In Section 2.3, we describe

the Java related technologies; Java Servlets, Java Server Pages and the Tomcat servlet

engine, which have been used to implement our system. Section 2.4 gives a brief

description of the Extended Markup Language (XML) that has been used as the language

to specify the queries sent to the local sites and the query results sent back from them.

Section 2.5 describes XSLT (Extended Style Sheet Language Transformations), which is

used to transform the XML based documents to HTML documents. Section 2.6 describes

the web services technology used to implement interapplication communication over the

Internet. Section 2.7 describes SOAP and its use as an XML-based protocol for the

exchange of information in a distributed environment. An overview of the Apache Axis

toolkit to implement web services is provided in Section 2.8.

2.1 Distributed Query Processing

2.1.1 Overview

The objective of query processing in a distributed context is to transform a

high-level query on a distributed database, which is seen as a single database by the









users, into an efficient execution strategy expressed in a low-level query language used

for manipulating local databases [5].


Query on Global
Schema
I


CONTROL
SITE


Fragment Query


Optimized Fragment Query with
Communication Operations


LOCAL
SITES


Figure 2-1. Generic layering scheme for distributed query processing [5]


The four main layers perform functions of query decomposition, data localization,

global query optimization and local query optimization.









Query decomposition. The high level query is decomposed into an algebraic query

on global relations. The information needed for this transformation is found in the global

conceptual schema.

Four successive steps involved in this process are

* Normalize the query
* Semantically analyze the query to detect and reject incorrect queries
* Simplify the query to eliminate redundant predicates
* Restructure the query as an algebraic query.

Data localization. This layer determines which fragments are involved in the query

and transforms the distributed query into a fragment query. A distributed relation is

reconstructed by applying certain fragmentation rules and using the information stored in

the fragment schema.

Global query optimization. This layer determines an optimal execution strategy

for the query processor. This strategy takes into account the cost of executing all

operations, including communication costs.

Local query optimization. This layer is executed by the local sites. The local

query is optimized using the local schema information at the sites.

In this thesis, optimization of the query in terms of minimization of the total cost is

not a critical part of the design. This is due to the fact that all the component databases

have distinct information that is specific to the nations. Hence, there is no replication of

data across local sites. Therefore, there would be one and only one query execution plan

for a given search criteria.

2.1.2 Query Processing for Heterogeneous Database Systems

In a heterogeneous database system, the component databases have different

capabilities to store data.









The two main challenges in querying heterogeneous databases are

* To find query plans that can be executed on all the component databases in the best
possible way.

* To deal with system and data heterogeneities.

In our distributed query processor, we are assuming that the component databases

being queried are all standard SQL databases. Also, in our work, as mentioned earlier, the

existence of a single query execution plan ensures that meeting the first challenge is

trivial for our system.

System heterogeneities arise due to differences in hardware/software platforms.

These can be resolved by the use of a common communication infrastructure such as

TCP/IP and RPC. Data heterogeneities [6, 7] can be classified into the following two

types:

* Schematic heterogeneity: Owing to different ways of naming and structuring data
* Semantic heterogeneity: Owing to different meanings associated with data.

These heterogeneities can be dealt by two basic approaches. They are

* Defining a global integrated schema that reconciles all the schematic conflicts and
unifies the semantic differences.

* Using certain mediation rules or specifications to resolve data conflicts among
component systems at run time.

In our work, we use an approach that is based on both the global schema and

mediation-based approach. We define a global/integrated schema, which is the union of

the local schemas of the component databases. This schema is meant to provide a

uniform interface to the users of the system to query the various component databases

simultaneously. However, in order to eliminate the data heterogeneities, the system

employs a wrapper-based architecture [8]. Wrappers (or adaptors) encapsulate the details

of component databases they are associated with. The wrapper translates the query based









on the global schema to a request that is understood by the component database's API.

The wrapper also translates the results returned by the component database so that the

results are compliant with the global schema of the heterogeneous system. The wrapper

implements the mediation logic/code that is required to eliminate schematic and semantic

heterogeneities.

2.2 Event-Trigger-Rule (ETR) Technology

The Event-Trigger-Rule (ETR) technology serves to extend the Internet from a data

network to a knowledge network. It also extends the existing Web Server into a

Knowledge Web Server. The knowledge network allows consumers and providers of data

to express their knowledge in the form of events, rules and triggers that are associated

with the data and data processing. The contributed knowledge is incorporated into the

current data network. This knowledge network employs the push model instead of the

pull model of information dissemination .The push approach is highly scalable as a large

number of subscribers can simultaneously be provided information.

The ETR technology is based on an Active Object Model (AOM). In this

framework, all things of interest are modeled as objects. As in the traditional object

model, these objects can have attributes and methods. In addition, the AOM allows for

inclusion of events, triggers and rules in an object class definition. The specification of

these events, triggers and rules transforms distributed objects to active distributed objects.

The ETR-enabled knowledge network provides a framework to publish events,

subscribe to events and define rules on subscribed events.

2.2.1 Events

Any item of interest can be modeled as an event. For instance, a police official's

arrest of an individual can be an item of interest and thus can be defined as an event. An









actual arrest signals an occurrence of the event (i.e., an event instance). Events can be

broadly categorized into method associated events, explicitly posted events and timer

events.

Method associated events are tied to the execution of certain methods. The time

when the event is posted such as before, after or on commit of a method defines the

coupling modes. These are synchronous coupling modes. In such a coupling mode, the

execution of the method is suspended till a response is returned from the rule processor.

Instead of and decoupled are two other coupling modes. In the instead of mode, the rule

body is executed in place of the method if a certain condition evaluates to true. The

decoupled mode allows an event to be posted asynchronously.

An explicitly posted event is raised independent of any method. The event can be

raised in the body of any method by a PostSynchEvent or PostAsynchEvent call using the

event instance as a parameter in the call. An explicitly posted event can be used to signal

a database state, a program status, an exception condition, etc.

A timer event is explicitly related to some time of interest, which is when it is

posted. It is asynchronous in nature. For example, a timer can be set to post an event

every second, every hour, or any other prespecified time interval. In our system, we

define events that are posted explicitly and in the synchronous mode.

2.2.2 Rules

A rule is a high level declarative specification of a granule of executable code that

is related to an event or events. A rule is composed of condition, action and alternative

action clauses. When an event is posted, the condition clause of the associated rule is

checked and, if it evaluates to true, the action clause of the rule is executed. Otherwise,









the alternate action clause is executed. A rule has parameters, the actual values of which

are provided by the event at run time. Rule syntax can be defined as follows:

RULE rulename (parameter list)
[RETURNS return_type]
[DESCRIPTION description text]
[TYPE DYNAMIC/STATIC]
[STATE ACTIVE/SUSPENDED]
[RULEVAR rule variable declarations]
[CONDITION guarded expression]
[ACTION operation block]
[ALTACTION operation block]
[EXCEPTION exception & exception handler block]


A rule has a name and a parameter list. The values of the parameter list are

specified at run time by the event that triggers the rule. The return value of the rule is

specified by the RETURNS clause. A textual description of the purpose of the rule is

provided by the DESCRIPTION clause. The TYPE clause indicates whether a rule will

be modified or not after the initial definition. Static rules are less likely to change;

whereas, a dynamic rule may change at run time. The STATE clause defines if the rule is

active or suspended. A suspended rule needs to be activated before it can be triggered.

The RULEVAR declares the rule variables used in the rule body. The CONDITION

clause specifies a guarded expression. A guarded expression has two parts; a guard part

and an expression part. If the sequence of operations in the guard part evaluates to true,

then the expression is evaluated. Thus the guard part screens out cases where the rule

must be skipped. The ACTION clause specifies the code that needs to be executed if the

CONDITION clause evaluates to true else the code specified by the ALTACTION clause

is executed. If an exception occurs during rule evaluation, then it is handled by the

EXCEPTION clause that ties an exception type to an exception handler.









2.2.3 Triggers

Events are associated with rules by means of triggers. Triggers map event attributes

to rule parameters. A trigger is capable of specifying parallel rule executions. The trigger

definition syntax is defined below:

TRIGGER triggername (trigger parameters)
TRIGGEREVENT events connected by OR
[EVENTHISTORY event expression]
RULESTRUC structure of rules
[RETURNS returntype:rule is rule inrulestruct]

Optional clauses are surrounded by braces. The TRIGGER clause defines the name

of the trigger and the trigger parameters which are used optionally to bridge between

event attributes and rule parameters. The TRIGGEREVENT clause specifies the

event/events whose posting shall trigger the execution of the structure of rules specified

by the RULESTRUCT clause. If more than one event is defined in the TRIGGEREVENT

clause, they are logically Ored, meaning the occurrence of any of these events can trigger

the evaluation of the EVENTHISTORY clause. This clause specifies a complex event

expression, which makes some reference to events that have already occurred. If the

EVENTHISTORY expression evaluates to true, then the rule structure specified in the

RULESTRUC clause is executed. Optionally, a trigger can return a value specified by the

RETURNS clause in the case of a synchronous event that triggers the structure of rules.

2.2.4 Event Manager

The Event Manager handles the incoming and outgoing events from the web server.

When a new event is defined, its meta-data is given to the Event Manager in order to

enable it to recognize and handle the event. The Event Manager and the ETR Server are

replicated and installed in multiple websites. Event Managers can communicate with each

other for the purpose of sending and receiving events. The Event Manager is also









responsible for performing event filtering before it sends out events to the subscribers in

order to support a selective subscription of events. It also includes the event registration

capability for remote clients to register their interest in subscribing to certain events

provided by the Knowledge Web Server. Also, when the Event Manager receives an

event from a remote web server, it passes it to the local ETR Server to initiate the

processing of triggers and rules.

2.2.5 ETR Server

The ETR Server processes the triggers and rules defined in the Knowledge Web

Server. Trigger and rule definitions, which are input through the Knowledge Profile

Manager (a component of the Knowledge Web Server), are provided to the ETR server

and are transformed into internal data structures used. The ETR server receives events

from the local Event Manager and performs the trigger and rule processing. On receiving

an event, the ETR Server can immediately identify the trigger related to the event,

efficiently process the event history, and schedule the rules specified in the trigger for

processing. The ETR Server is also responsible for executing the rules. These rules are

composed of method calls, which may execute local or remote applications, or invoke

methods of distributed objects. The rule can also generate an event to trigger other rules.

2.2.6 Knowledge Profile Manager

The Knowledge Profile Manager (KPM) [9] is responsible for maintaining the

knowledge profile of the Event Provider and Subscriber sites. The knowledge profile

contains the events, triggers and rules that are published/subscribed by the event

providers/subscribers.

The KPM provides a GUI for defining and editing events, triggers and rules.









2.2.7 Persistent Object Manager

The Persistent Object Manager (POM) [10] consists of two main components.

* Object-Relational mapping engine.
* XML-Relational mapping engine.

The Object-Relational mapping engine provides a persistent storage facility for

storing information related to the system. It also provides a high-level interface in the

form of APIs for programs to store, retrieve, update, and delete objects without having to

know the internal data structures of the objects. The XML-Relational mapping engine

provides the persistence capability and a filtering mechanism to the Event Server at every

site. It includes a parser that maps the filter definitions of the events stored in XML files

to their relational representations. POM is implemented on top of an Object-Relational

database system called Cloudscape.

2.2.8 Metadata Manager

Once events, triggers and rules are created using the GUI provided by KPM, they

are stored and maintained by the Meta Data Manager at the respective sites. Thus, the

Meta Data Manager module within the KPM provides persistence for storing the user

knowledge profiles.

2.3 Java Related Technologies

2.3.1 Java Servlets

Servlets [11] are the Java platform technology of choice for extending and

enhancing web servers. Servlets provide a component-based, platform independent

method for building web-based applications, without the performance limitations of CGI

programs. Unlike the proprietary server extension mechanisms (such as the Netscape

Server API or Apache modules), servlets are server and platform independent.









Servlets have access to the entire family of Java APIs, including the JDBC API to

access enterprise databases. Servlets can also access a library of HTTP-specific calls and

receive all the benefits of the mature Java language, including portability, performance,

reusability, and crash protection.

2.3.2 Java Server Pages

Java Server Pages (JSP) technology [11] is an extension of the Java Servlet

Technology. Java Server Pages technology allows web developers and designers to

rapidly develop and easily maintain, information-rich, dynamic web pages that leverage

existing business systems. As part of the Java family, JSP technology enables rapid

development of web-based applications that are platform independent. Java Server Pages

technology separates the user interface from content generation enabling designers to

change the overall page layout without altering the underlying dynamic content.

Java Server Pages technology uses tags that encapsulate the logic that generates the

content for the page. Additionally, the application logic can reside in server-based

resources that the page accesses with these tags. Any and all formatting (HTML or XML)

tags are passed directly back to the response page. By separating the page logic from its

design and display and supporting a reusable component-based design, JSP technology

makes it faster and easier than ever to build web-based applications.

2.3.3 Tomcat Servlet Engine

Tomcat [12] is the servlet container that is used in the official Reference

Implementation for the Java Servlet and Java Server pages technologies. The Java Servlet

and Java Server Pages specifications are developed by Sun under the Java Community

Process. Servlet container is a runtime shell that manages and invokes servlets on behalf

of users. Tomcat will operate under any Java Development Kit (JDK) environment that









provides a JDK 1.1 or JDK 1.2 compatible platform. The JDK is required so that servlets,

other classes, and JSP pages can be compiled.

2.4 Extensible Markup Language

Extensible Markup Language (XML) [13] is a simple, very flexible text

format-based language derived from SGML (ISO 8879). It is a cross-platform, software

and hardware independent tool for transmitting information. Originally designed to meet

the challenges of large-scale electronic publishing, XML is also playing an increasingly

important role in the exchange of a wide variety of data on the web and elsewhere.

XML allows the author to define his/her own tags and his/her own document

structure. XML can also be used to store data in files or in databases. Applications can be

written to store and retrieve information from the store, and generic applications can be

used to display the data.

2.5 Extended Stylesheet Language Transformations

In most cases, it is required to transform information marked up in XML from one

vocabulary to another. EXtended Style sheet Language Transformations (XSLT) [14]

provides a powerful implementation of a tree-oriented transformation language for

transmuting instances of XML using one vocabulary into an XML, HTML, plain text or

any other text-based document. XSLT documents require an XSLT processor. Example:

Microsoft IE 5 and Apache's XALAN.

In an XSL transformation, two trees of nodes exist. The first node tree is the source

tree. The nodes in this tree correspond to the original XML document to which the

transformation is applied. The second node tree is the result tree. This tree contains all the

nodes produced by the XSL transformation.










2.6 Web Services Technology

The web services technology is a platform that supports distributed computing over

the web. The web services model defines a "Service" as a collection of operations that

carry out some tasks. A web service is an interface that describes a collection of

operations that are network accessible through standardized XML messaging.




Service Requestor





TRANSPORT
MEDIUM




Service Provider Service Directory
PUBLISH





Figure 2-2. Web service architecture model [15]


As described by Gottschalk [15], a web service is described using a standard,

formal XML notation called its service description. It specifies all the details necessary to

interact with the service, including message formats, transport protocols and location.

The interface hides the implementation details of the service, allowing it to be used

independently of the hardware and software platform on which it is implemented and also

independently of the programming language in which it is written. This allows web

services-based applications to be loosely coupled, component-oriented and cross

technology implementations.









2.7 Simple Object Access Protocol

Simple Object Access Protocol (SOAP) is a simple, lightweight, XML based

protocol that uses HTTP for exchange of information in a distributed environment. It

defines formats for messages exchanged between distributed applications. SOAP is

language and platform independent because it is based on XML. It provides a means for

different applications running on different operating systems, with different technologies

and programming languages to communicate with each other. In SOAP, everything that

goes across the wire is expressed in terms of HTTP or SMTP headers, MIME encoding

and special XML grammar, as defined by the SOAP specification.

A SOAP message has the following three parts:

* A SOAP envelope that defines the content of the message
* An optional SOAP header that contains the header information
* A SOAP body that contains call and response information.

The SOAP envelope declaration is the outermost XML tag that delineates the

boundaries of the SOAP document. The SOAP header has information intended for the

underlying infrastructure, such as transaction ID, where transaction ID is not part of the

method signature. It is intended for the SOAP processor that receives the message. This

processor may be a J2EE server with a transaction manager. The SOAP body is intended

for the actual data, or message payload, to be consumed and processed by the ultimate

receiver.

XML messaging and network protocols form the basis of the web services

architecture (Figure 2-3). XML messaging using SOAP is a four step process:

1. Client side application at the service requestor side makes the service invocation
request. The SOAP engine generates the SOAP message for this request and the
network protocol takes care of converting this message to the appropriate format
and routes it to the web service provider.









2. At the web service provider side, the SOAP engine identifies the service request
and invokes the appropriate method in the server side application.

3. The server side application returns the results of the invocation to the SOAP engine
and the results are routed back to the client in the form of a web service response.

4. The results of service invocation are returned to the client side application.


Swkni ICvqUwClr Ncknirt Prrm 'kr












jiil2.8 Axis Toolkit Fl
Axis is a web services toolkit developed by Apache. It is a SOAP engine that












allow us to view the structure of SOAP messages exchanged between applications.









Axis has features that allow for deployment of web services in a flexible way. One

simple way of doing this is to save your service class in java as a .jws fle. All jws fles

get automatically deployed as web services as their invocations actually invoke the Axis
get automatically deployed as web services as their invocations actually invoke the Axis









servlet. No further configuration is required on the part of the service deployer. Another

more common way of deploying a web service involves making use of a Web Service

Deployment Descriptor (WSDD). The Axis API, org.apache.axis.client.AdminClient is

used to deploy a web service. A deployment descriptor contains the details that the Axis

engine needs to know to deploy a Java class as a web service. It contains details such as

the Java class name for a given service, mapping of QName (qualified name) information

to Java classes for the purpose of serialization and deserialization. Axis also provides the

API, org.apache.axis.client.Call that is used to invoke a web service operation. The API

encapsulates generation and decoding of SOAP messages and provides a high level

interface to invoke the web services operations. The Axis User's guide [17] describes

how to use the toolkit.















CHAPTER 3
SYSTEM ARCHITECTURE

In this chapter, we provide a detailed explanation of the architecture of the system

that has been designed and is being implemented. Section 3.1 gives an overview of the

architecture. Section 3.2 describes the distributed query processor. Section 3.3 describes

the components that help achieve publishing of events and subscribing to events. In

Section 3.4, we describe the posting and notification of events.

3.1 Overview

The overall system architecture for the proposed system is shown in Figure 3-1.


US *SMSC: Short message service center


Figure 3-1. Overall architecture of the proposed system









It involves three sites:

* OAS
* Belize
* Dominican Republic.

The Organization of American States (OAS) is the central site based in the United

States. A collaboration portal will be installed at this site. The portal will act as a

repository for all the global information, which is required to integrate the functioning of

the system across different participating nations.

The other two sites are in the countries of Belize and the Dominican Republic

where the initial system will be deployed. Currently, we have two participating nations;

however, the design of the overall system is such that it could be easily extended to add

nations to the transnational digital government grid in the future. All these three sites are

interconnected through the Internet (Figure 3-1). All exchanges of information shall be

through the Internet.

The users of the system (individuals/applications that will be using the system to

share information) fall into three broad categories:

* Port of Entry Station (with Conversational Interface) personnel
* Personnel of various government agencies
* Authorized individuals in both countries.

All the participating nations (two in the initial system) are assumed to have local

databases that store immigration and other government process-related data. These

databases have their own local Database Management Systems (DBMS) already

installed. In our initial system, we assume that the databases are standard SQL databases.

The software components installed at each of the participating nations' sites are

described below.









Event Server. The Event Server is responsible for accepting event registrations

and delivering the events to the subscribers. During event registrations, the users provide

their event filters by selecting or providing values to attributes that are provided in the

predefined event filter templates. These filters allow subscribers to have selective

subscription to the events of their choice. On the one hand, the Event Server listens to

events from the Event Servers of other sites and, on the other hand, it communicates with

the ETR server to activate rules triggered by those events.

ETR Server. The ETR server is responsible for the installation and processing of

rules at each site. The KPM provides the ETR server with trigger and rule definitions,

which the former translates to internal data structures. Whenever the ETR Server receives

an event notification from the Event Server, it identifies the proper triggers and rules to

be executed.

As mentioned in the description of the ETR technology, three components interact

with the Event Server and the ETR Server to ensure their proper functioning. They are

* Knowledge Profile Manager (KPM)
* Persistent Object Manager (POM)
* Meta Data Manager.

The purpose and description of these components has been provided in Chapter 2

of this thesis.

Translator. This component is crucial to the design of our system since the

participating nations use different languages. Thus, any form of data transfer may require

a translation from one language to another. In the current scenario, Belize uses English

and the Dominican Republic uses Spanish as its national language. Thus, both the ETR

server and the Distributed Query Processor would need to invoke the translator to









translate words/text from English to Spanish and vice versa. This component of the

system is being developed at the Carnegie Mellon University, and currently we are in the

process of finalizing the API for invoking the translator module. In the present

implementation of the system, we simulate the translator by creating a static table that has

English-Spanish word mapping.

Short Message Service Center. When a subscriber subscribes to an event, he/she

has an option of getting notified via either email or cell phone. The latter requires routing

the event notification message through the Short Message Service Center. During event

notification, the Event Server looks up the cell phone number and the network of the

subscriber, and then sends the message with SMTP to

phone@messaging.cell-network.com. The SMSC routes this message to the user's cell

phone as an SMS message.

Distributed Query Processor. One of the major capabilities of the proposed

system is to allow the user to query immigration related heterogeneous data stored in the

databases of all the participating nations.

3.2 Distributed Query Processor

The distributed query processor has two components: The global query processing

component and the local query processing component. The global query processing

component has a Global Search Form based on the integrated global schema. This

component is replicated at both the Belize and Dominican Republic sites. Based on the

local schema information provided by the distributed data dictionary, the global query

processing component partitions the query to sub queries and sends them across to the

local sites whose databases are being queried. The global query processing component

plays the role of a web service client that invokes the local query processing component









web service deployed at the local sites. As per the web services model, the query issued is

wrapped as a SOAP message and sent using HTTP over the Internet. The local query

processing component is made accessible over the Internet as a web service. This service

is invoked by passing an XML query string as an argument to it. The local query

processing component at each site has a unique wrapper which communicates with the

local database and the Event Server, the ETR Server and the Translator which are also

installed at the local site. The wrapper, after performing the global to local attribute

mapping and language translation, if required, to eliminate all the data heterogeneities,

issues the subquery to the local database. The local query results are mapped to global

attribute names, translated if required, and sent back to the global query processing

component as a response to the web service invocation.

3.3 Publishing and Subscribing to Events

In this subsection, we describe a mechanism by which means a user of the system

can publish an event so that other users can subscribe to it. Users of the system are

distributed across all the participating nations. The OAS site serves as the portal where a

user can publish his/her event along with a suitable event description. A user of the

system will browse this site and be able to subscribe to an event of his/her interest by

providing suitable event filter parameters and notification information.

Publishing an Event to the OAS site. The event publisher is assumed to have

already defined the event, event filter template, triggers and rules (if required) using the

KPM GUI at his/her local site. While publishing an event to the OAS site, the publisher

has to provide the event name, event filter template location, event publisher's country

and a brief description of the event through an HTML form. This form is posted to a

servlet which reads the event filter template XML file, appends tags to represent









placeholders for subscriber information, and uses this information to invoke a web

service at the OAS site itself. This web service is deployed as a Java Web Service File

and has the following functions:

* Reads the event filter template xml file from its given location.

* Based on the country name provided by the event publisher, the web service stores
the corresponding event filter template XML file, in a separate subdirectory at the
OAS site.

* This filter template is also translated into the languages supported by the other
countries and stored in their respective subdirectories.

* The web service also uses the SAX-based XSLT processor to transform the XML
file to a corresponding HTML file and stores it along with the XML file in the
same subdirectory.

* It also appends the event name and event description to Java Server Pages, which
have a listing for all published events at the OAS site in the various supported
languages.

This concludes the event publishing process for an event by an event publisher at

the OAS site.

Subscribing to an Event from the OAS site. A user who is interested in

subscribing to any event visits the OAS web site page that is in his/her language and

browses through a list of all published events. Based on the event descriptions provided,

s/he makes a selection of the event that s/he wishes to subscribe to. Clicking on the URL

associated with the event selected, the user is directed to the HTML form generated from

the corresponding event filter template. The user fills out event filter template parameters

and his notification information. Posting this form invokes a web service method

deployed at the event publishing site. The form's parameters are wrapped into a SOAP

message and transferred using HTTP to the site whose web service method is being

invoked. This web service method takes the filter template parameter values and the









notification information passed to it and invokes the local Event Server to append the

new subscriber's information into the POM. This marks the end of the event subscription

process for a user.

3.4 Posting and Notification of Events

An event can be posted in several ways, as explained in Chapter 2. When the event

publisher posts an event to the local Event Server, the event server does three things upon

receiving the event:

* Identifies subscribers to the event. Subscribers specify certain event filter attributes
(i.e., specific values for certain event attributes) at the time of subscription. When
an event is posted, the Event Server identifies all such subscribers of the event for
whom the filter parameters match the corresponding attributes of the event posted.

* Passes the event onto the local ETR server to process the triggering of associated
rules, if any.

* Notifies the subscribers of the event about the latter's occurrence. This notification
is done based on the subscriber's preferred method of notification provided at the
time of event subscription.























CHAPTER 4

DISTRIBUTED QUERY PROCESSOR


This chapter describes the distributed query processor to achieve transnational



sharing of information. This distributed query processor has the capability to query



immigration related entry-exit information of the two participating nations through a



common web-based interface. Figure 4-1 and Figure 4-2 show the entry/exit forms of



Belize and the Dominican Republic. Entering the completed forms into the respective



databases is part of the duties of the country's local application system. Our distributed



query processor queries the data stored in the participating nations' databases.






Belize Arrival/Departure Forms


WELCOME TO BELIZE
raRKvA.I. HKncrulf









*Ht' fl cthr

L r, N*'f i' L) -i *Th ____________<____flN____3_____
BI 1'I~l p rL^'ini e ...............










7 bL. NxJy.-zA..
SL. hitarii i -rain 11 inMtir a~insrti VhiiLINnl pV i-e Ms _________
I i. L'ria-i QZntn urtd r lrmo. ---------------------------


iIe- c.^~oldlr;~.. ..




__m wt-rrkrffll
^1 ll vlu yau. *J*ii ritii EI& iXH hnaB e l) -I K



_______________________ ci lurj-r m llll Cll 'raif ____________


n)LPAHTVRL RECORD
I? FtI NaI N :
I.Ser: iL e(I./i .l ... N. II. oll.i____________
20. i.L HFdi.: l l ZL Counltey ofBinh:_____
U1. Psupn Nurbe.r ___________________________________
Ia)- orF Iuc:


I'.' rII ._________________________ __
:J LINE 14"C1 i|.h',



CuiJn a a r a.. ._ ^ _____/
i~ ~ ~ ____ _____ a ^ _____ Srllfliure oIP^mier


Figure 4-1. Belize entry/exit forms












Dominican Republic Arrival/Departure Form

I TARLETA INTERNAL ONAI E EBIi- A I._ nFL i_ L. i L r C J, .J I
INTE RNAIONAE. M6 BA* B A T ON o M r I Pi- e d r, Trh- tr 7 1N r-1

,- -'''"/^ T ^-'^ '^^^^,.. .. *''' -,,.

^ *^**; S .. .......................... .. -f ', J .... ; ,Jn ^ ', J









--
> i. .^ .. ..... .. ..
----------










Figure 4-2. Dominican Republic entry/exit form



The architecture, the actual design of the components and the functional

capabilities of the Distributed Query Processor are explained in this chapter.

4.1 Global Query Processing Component

This component of the query processor is replicated at both query issuing sites. It is

comprised of the Global Query Form, the Global Query Processor, Global Schema and

the Data Distribution Directory. The data being queried through this system is actually

based on the entry/exit forms that immigrants or visitors fill out upon arrival to or

departure from a country. Therefore, the schema for the tables may have certain fields

that are similar and certain fields that are dissimilar. A global schema file is constructed









based on the schematic information of the immigration data stored across both countries.

This global schema is essentially a UNION of the individual local schemas of the two

nations. This global schema file is created using the KPM GUI tool to define schemas.

Thus it is stored as a .met file with the Meta Data Manager.


Figure 4-3. Architecture of the distributed query processor









Apart from the schemas, the other meta-data required for the accurate functioning

of the global query processing component are:

Form Fields Information. This includes information about every attribute in the global

schema, the country it is derived from and its corresponding display property on the

global query form; (e.g., information like the passport number is derived from the

schemas of both Belize and the Dominican Republic and would require a text box on the

global query form).

Country Information. This includes information about the web service (URL of the web

service) and the method to be invoked to access the individual local query processing

components.

The global query form, a Java Server Page served by Tomcat 4.1, is constructed

based on the global schema and the Form Fields Information. The global query

processing component is deployed as a web application under Tomcat 4.1 at two query

issuing sites. The global query form is thus accessible through the web.

All the users privileged to use this system have associated user profiles comprising

of username, password, nationality, and a set of roles from a predefined role set. This

user profile information is stored using the role based authentication system provided by

Tomcat. A user's role determines the privilege of his/her information access. For example

in our implementation, we have identified the roles described in Table 4-1.

Table 4-1. Role list based on information access privileges
Role User group Access information
A Super ALL
B Police Arrest information
C Immigration Immigration information
D User 1 Arrival-related immigration information
E User2 Departure-related immigration information
F Tourism Tourism information









This set of roles has been created to demonstrate the capability of the system to

achieve a centralized role based access mechanism [18]. The actual role set in the system

to be deployed would be based on the access levels that the participating countries agree

to have on the various fields in their database. The user's country information stored as

part of his/her profile is required to determine the language in which the global query

form and the query results would be displayed to the user. Thus the global query form is

available in all supported languages, but which form is actually displayed depends on the

user's country of citizenship information stored in his/her user profile.

The specified roles determine the access category that the user falls under. For

instance, Role A, the super user has access to immigration, police and tourism, all classes

of information; whereas, the other roles define a more restricted scope of access.

The global query form has a format in which a list of the global attribute names is

displayed along with place holders for the user to specify the attributes he/she wishes to

have displayed in the final result, and the values for the condition attributes in the query.

The layout of the form is such that the query generated is in disjunctive normal form and

can contain up to three ORed expressions. Each of these OR expressions are internally a

conjunction of the query parameters provided in the form. The values that the user fills in

determine the search criteria on which to query the system.

The global query form allows the user the option of selecting the countries from

which he/she wishes to query information. The system is designed to query for records

matching the given criteria and to display the records and/or the count of the number of

records matching the given search criteria. The information being queried by the system

right now does not contain any numeric fields. If there were any such fields, the system









could easily be extended to support other arithmetic group functions such as AVERAGE,

MAX and MIN.

Another selection, which the system user makes, is for the attributes he/she wishes

to be displayed in the final output of the query processor. When the user submits the

global search form, the global query processing component is invoked. This component is

responsible for the following tasks:

* Identify the roles associated with the user.

* Identify the countries whose local query processing components are being invoked;
(i.e., the countries whose databases are being queried).

* Identify the nature of the display format; records and/or count of records.

* Partition the query parameters and the selected output attributes based on the
country information associated with each attribute in the Form Fields Information.

* Wrap the role information and the partitioned query into an XML document with a
predefined Document Type Definition (DTD).

* Invoke the web service method of the countries whose databases are being queried
by passing an XML string representing the query. A SOAP engine installed at the
Query Issuing site provides the API, which has the methods that are required to
invoke a web service with a specific URL and method name. Thus, the Global
Query Processing Component is a web service client that invokes the Local Query
Processing Component, which is deployed as a web service.

* Accepts the query results returned by the web service methods of countries being
queried and applies suitable Extensible Style Sheet Transformation (XSLT) using
the SAXON processor to convert the query results from XML to HTML format and
display them in the web browser. The style sheet applied to the query results to
generate the final display page is also available in all supported languages. The
style sheet to be applied is determined by the user's country of citizenship
information stored as part of his/her profile in the web server's configuration.

4.2 Local Query Processing Component (LQPC)

The second component of the Query Processor is the Local Query Processing

Component. This component is meant to receive the subquery from the global query

processing component of the query issuing site and to modify it to a query that can be










issued to the local database. On the one hand, it connects to the local DBMS and, on the

other hand, it also connects to the Event Server and the Translator installed at the local

site. Section 4.2.1 describes the web service interface of the Local Query Processing

Component. Section 4.2.2 describes the architecture of the Wrapper component of the

LQPC and its interaction with the Event Server, the Translator, and the local DBMS.


From query issuing
site..


Global Query Query Results

Web service interface to
LQP


Evert Server Extractor

Access Controller
ETR Server
Translator
Translator
QueryProcessor





DBMS



DB




Figure 4-4. Architecture of the LQPC


4.2.1 LQPC as a Web Service

The local query processing component is deployed as a web service using the

Apache Axis toolkit (Axis 1.0) and saving all the Java class files for its deployment under

Tomcat servlet engine's webapps directory. Thus, the entire local query processing

component is accessible on the Internet as a web service, which can be accessed just like









a local application through SOAP. The local query processing component's web service

has an associated deployment descriptor, which contains deployment information for the

web service. WSDD (Web Service Deployment Descriptor) is an XML format specific to

Axis. With a WSDD, we specify which classes are to be deployed as a service, which

particular methods are exposed to the web service clients and we select the scope of the

service, implement handlers, etc. The Axis API, org.apache.axis.client.AdminClient, is

used to deploy and undeploy a web service. Once this service is deployed, another site

can simply invoke the web service by making an HTTP connection using the web service

URL. Axis provides the API, org.apache.axis.client.Call that is used to invoke a web

service operation. The API encapsulates the generation and decoding of SOAP messages

and provides a high level interface to invoke the web services operations.

The web service method takes a single string argument representing the subquery

issued by the global query processing component in XML format. After the LQPC has

queried the database, the query results in XML format are returned by the web service

method as a string.

4.2.2 Wrapper Architecture of the LQPC

The invoked web service method of the Local Query Processing Component passes

the query in XML format to the wrapper. We define a unique wrapper, set of Java classes

and mapping files, for each nation's local database. This wrapper (Figure 4-4) integrates

with the deployed web service class on the one hand and on the local DBMS on the other

hand. This section describes each of these components and their role in the functioning of

the LQPC.

Extractor. This subcomponent receives the string subquery in XML format from

the web service class and extracts the query and role information from it. This is achieved









by parsing the XML document using a DOM-based parser. The Extractor returns five

vectors and passes them onto the next subcomponent. These five vectors are

* Role vector: A vector of the roles associated with the query issuing user.

* Select Attribute Vector: A vector of all global attribute names requested by the
query issuer in his/her query.

* Condition Attribute Vectors I, II and III: These three vectors contain lists of the
global attribute names in each of the three OR expressions in the global query,
respectively. The elements of each of these vectors will be ANDed together
internally to form the query to be issued to the local database.

Additionally, the extractor is also responsible for wrapping the query results into an

XML document and sending the document back to the web service class to return it as a

string to the web service invoking client: the global query processing component.

Access Controller. The five vectors returned by the Extractor are input to the

Access Controller. This subcomponent is responsible for connecting to the local Event

Server to post a synchronous event accesss) that triggers a rule to check the access rights

of the querying user on the attributes being accessed in the query. The role played by this

component is explained in detail in Chapter 5.

Translator. This subcomponent deals with the issue of data heterogeneities across

local databases. The global attribute names in the query are mapped to the corresponding

local attributes names in the database. This mapping is implemented as hash tables in

Java.

Due to the difference in the language in which data is stored in the local databases

of the participating countries, sometimes it becomes necessary to translate the query

attribute values in order to query the local database. For example: If a user wishes to

issue a query that retrieves information about all individuals traveling in and out of the

country for whom the immigration official had added a comment that had the word









'Intoxicated' in the comment field. To query for such information from the Dominican

Republic database, the system would be required to translate the word 'Intoxicated' to

Spanish and then issue the query. This translation would be done by invoking the

Translator (also a component in the local system). Additionally, after the local database

has been queried, the local query attribute names in the query result are mapped back to

the global query attribute names by the translator.

Sometimes, the level of semantic heterogeneity, which the LQPC has to deal with,

might be too complex to be handled by a simple hashing table. A good example of this is

the Ports of Embarkation and Ports of Disembarkation airports information. The

Dominican Republic stores this information as three letter airport codes like JFK for the

John F. Kennedy Airport, New York City, USA. In Belize, this same information is

stored as a pair: airport city name + airport country name; in this case, New York + USA.

The mapping for Ports of Embarkation and Ports of Disembarkation airports

information is also stored in the POM, and the wrapper's translator subcomponent uses

the POM's API retrieve airport-related information during query processing.

Query Processor. The Query Processor connects to the local database and issues

the translated query to it. The query results are sent back to the translator that maps the

local attribute names to global attribute names, passes the query results to the extractor

which wraps them into an XML document, and sends the document back to the web

service class, which sends back the query results as a SOAP message to the client that

invoked the LQPC web service.














CHAPTER 5
EXAMPLE SCENARIOS TO DEMONSTRATE THE ROLE PLAYED BY THE ETR
TECHNOLOGY

In this chapter we shall describe the use of the ETR technology to define events,

triggers and rules to show how this technology can be used in our project to enforce data

privacy and security rules and to demonstrate automatic event notification, event filtering

and information delivery.

5.1 Security Rule for Distributed Query Processor

Our system assigns roles to users, which determine the access privileges of users

who issue queries through the Distributed Query Processor. This role based access

control mechanism is achieved by defining a rule with the ETR server that checks the

access right of a user having a particular role for local attributes being queried. This

security rule (qaccessrule) is invoked by a separate subcomponent, the Access Controller

of the wrapper of the Local Query Processing Component.

The five vectors produced by the Extractor subcomponent of the LQPC wrapper are

mapped to three by adding all three condition attribute vectors to one. These three vectors

form the event attributes of the access event. This is a synchronous event, which triggers

the processing of qaccessrule security rule. These parameters are mapped to three rule

input parameters. The rule returns an object of the restrictqaccess class that has the

following attributes:

Status Flag: A Boolean variable, which is set to true if the user (based on his/her role)

has access to all attributes of the Condition Attribute Vector, else it is set to false.










Vector rbattr: A vector of integers e {0, 1} corresponding to every attribute in the Select

Attribute Vector. A '0' indicates that the user does not have access to this attribute and a

'1' indicates that he/she has access to this attribute. The process associated with the

Access Control Mechanism is depicted in Figure 5-1.



From Extractor

Query Attribute
Names+ User Roles
--- \ --


Posts access event with Event
Server


Triggers qaccessrde with ETR
server


-Status flag: 0-Query
Rej ected, 1 -Query
Accepted /
-Query attribute name /
access information /

To Translator
component



Figure 5-1. Flow chart depicting access control mechanism


The rule action code accesses the local POM to query the roleAccess table. The

roleAccess table is a role based access matrix, which stores the accessibility mapping of

every user role to every attribute defined in the local schema. The rule action code uses

the POM's API to query this table to return an object of the restrictqaccess. If the status

flag of the restrictqaccess object is set to false, the LQPC sends back an XML string to









the web service class indicating that the user does not have the access privilege to query

the system based on the criteria provided. If the status flag is set to true, the

restrictqaccess object is passed along with the five query vectors to the next

subcomponent of the system, the Translator.

Next we describe two scenarios, implemented to demonstrate event notification,

filtering and data privacy rules in our system.

5.2 Police Arrest Record Scenario

We define the occurrence of an arrest by the police authority of a country as an

event (Arrest). This event is posted by the officials by entering the arrest record

information: defendant's information, witness information and victim's information.

Subscribers to the arrest event shall provide event filter attribute values that specify the

nature of the crime and the defendant's nationality that they would be interested in. We

also define a rule hideVicWitInfo. This rule enforces data privacy in the notification to

the subscribers by suppressing the victim and witness information associated with the

arrest.

Posting of the Arrest event to the local Event Server causes the event server to look

for all subscribers of the event whose event filter attribute values match those of the

posted event. The event is then used to trigger the hideVicWitInfo rule stored with the

local ETR server. Thus, the data, which would violate the privacy of the victim and the

witness, is filtered out in the notification sent to the subscribers.

5.3 Person in the Watch List Scenario

When a visitor enters a country and the immigration official fills out a port of entry

application form, the program posts the Arrival event to the ETR Server which invokes

the WatchListCheckRule to check if the visitor entering the country is on the Global









Watch List of persons whose movements should be monitored. If not, the record is

inserted into the local database table. If yes, the official is notified that the person is on

the watch list, the record is inserted into the database, and an event (PEntry) is posted to

the local Event Server. At the time of registration to the event, subscribers to this event

shall provide event filter attribute values that specify the last name, first name and

nationality of a person on the watch list. The posting of the event causes the Event Server

to determine the subscribers who need to be notified about the individual's entry into the

country. This notification is then sent out using the preferred notification mechanism of

the event subscribers.














CHAPTER 6
IMPLEMENTATION DETAILS

Our system has been implemented using JDK 1.4, on a Windows NT platform. The

Web Server used is Tomcat 4.1.18. Axis 1.0 toolkit is used to define, deploy and invoke

the web services. The component databases have been implemented using Oracle 9i. In

this chapter, we describe certain essential implementation details of our system. Section

6.1 describes the implementation details of the Distributed Query Processor.

Implementation details regarding the registration of events, subscription to events and

posting of events in our system are explained in Sections 6.2, 6.3 and 6.4, respectively.

6.1 Distributed Query Processor

The distributed query processor has two components. The implementation of the

two components: the global query processor and the local query processor are described

here.

6.1.1 Global Query Processing Component

A registered user of the system is assigned a set of roles and these roles along with

the username, password and country of citizenship information form the user's profile

and are stored in the tomcat-users.xml file (Figure 6-1).

There are two JSP files, which implement the Global Query Processing

Component, are:

Formcreation.jsp. This file reads the three configuration files (Table 6-1) and

displays the global query form (Figure 6-2) based on the user's country of citizenship

information stored in the user profile. The user's role is determined when the user logs







47


into the system. A similar JSP file (Formcreationsp.jsp) displays the global search form


in Spanish. This is based on the Spanish global schema file. The global schema is stored


in parserARRIVAL-DEPARTURE.met (Figure 6-3).




cOrmL verucfn-'..aC ,nwding-'utf-S" >
1;rt l m lca e-uer "user
-rcole raoenrrnmeroe Asupser /

-CrolE FraIEnamrne'um.r f>

-crole releanema'rolnB lporllcr /'
r
-crole rDlkSeame-'rbMlfFpau or' /


-tr ole Wr lMbal're-maglElr1" /.
-srle r e. lma -'pr li,,, r" -. -,

-iJuser usnermme-'ue" Pbsword-uZ roles"i'DamI ro beplrleA_ uper" /

-ueir u s rname-'aper pamsswrd"s~upcr" mles -'"dllem,rQalm saupr"/
-cuqjr uractfme-tarnged r password-torM e ar rtolesItorntat' /0
cisesr usrsierfme-nlmegl passwor4"lnmlmio roles-"BellIeolrClinsC nlm"w/
-Fgu r Registme"d u se rs ard"u tei" roles from tmcp,aroltusersl"
Quer uerjsp. This fle usetwrd's the three configratit flesh and te fm prs
datas ues aremeing querie rd. queryl rslet t a lioc,ralstesll cnn n
cnctsr usto the LQ websetilt' web serve rnnin at the erliediter Fire e 6-4 s s
-cuer uslrncrm"me'u32 piassword'u3"" rolesra"Bellae,usr 0/>
-qser uaarfemem&admml paiswaordfadmin" roltefsadrminnim flafger- 1

Atomcfslt-asars




Figure 6-1. Registered users and their roles from tomcat-users.xml

Query.jsp. This file uses the three configuration files and the form parameters

from formcreation.jsp to generate the subqueries to be sent to the nations whose


databases are being queried. A query sent to a local site shall contain only those global


attributes that are present in its local schema. This JSP file acts as an Axis client and


connects to the LQPC web service running at the queried sites. Figure 6-4 shows the


SOAP message sent across to the LQPC web service, when the user is issuing a query to







48


retrieve the last name, first name, ports of embarkation and disembarkation information


of all visitors entering/exiting the Dominican Republic.


I 3 ~ S~b:


- ,- :,: I ,


3jF| t.: J5. .,. -.- _J V r


GLOBAL SEARCH FORM

ARRIVAL/DEPARTURE INFORMATION


CECK COWTRIES YOU WISH TO QUERY
F Eiic (b)


DiFpby Reolt FP Cl .t

MNTR PARAMEIfRS FOR QIURYING AMRRVAL/DEPARTURE RtCORD IfOUMATION
Chlak ikberfe f ifyou l tle fil i hbe mtrieed in ithe fialn r
Fiel. inashgle agm imL ANDedaptieerx; istc aa third columns ilhwi leOIReiin It acRiea


I1 I I OR i



TII II y
contryeofiwue-ouity | j I i I J
-i-1- ift .l.t..-


Figure 6-2. Global query form


Table 6-1. Configuration files for global query processing component.
File name Description Fields
parserARRIVAL-DEPARTURE.met This file defines the Attribute
global schema, which is data typ
the UNION of the local
schemas of all
participating countries
Countryinfo.txt This file contains Country
information about all URL of
participating countries service,


Form info.txt


This file contains form
field information


name, attribute
e.


name, symbol,
its LQPC web
web service


method to be invoked.
Global schema attribute,
corresponding form
entity, number of
associated items, country
symbols of countries
having this attribute in
their local schema.


I 3-K [VAL; UtPAA I UK* KILURD&LOBAL QUI&Y FC*M. MMA JM-t IbpkI











--This file defines the global schema which happens to be the union
of all the schemas of the participating nations.
ARRIVAL-DEPARTURE

Individual ENTITY
























String


passportno REQUIRED PrimitiveType String
dateofissue REQUIRED PrimitiveType String
placeofissue-state REQUIRED PrimitiveType String
placeofissue-country REQUIRED PrimitiveType String
idno REQUIRED PrimitiveType String
lastname REQUIRED PrimitiveType String
firstname REQUIRED PrimitiveType String
mi REQUIRED PrimitiveType String

sex REQUIRED PrimitiveType String
male REQUIRED PrimitiveType String
female REQUIRED PrimitiveType String

dateofentry REQUIRED PrimitiveType Date
port-of-embarkation-code REQUIRED PrimitiveType String
port-of-embarkation-city REQUIRED PrimitiveType String
port-of-embarkation-country REQUIRED PrimitiveType String

dateofdeparture REQUIRED PrimitiveType Date
port-of-disembarkation-code REQUIRED PrimitiveType String
port-of-disembarkation-city REQUIRED PrimitiveType String
port-of-disembarkation-country REQUIRED PrimitiveType


dateofbirth REQUIRED PrimitiveType Date
placeofbirth REQUIRED PrimitiveType String

nationality REQUIRED PrimitiveType String
occupation REQUIRED PrimitiveType String














maritalstatus REQUIRED PrimitiveType String
single REQUIRED PrimitiveType String
married REQUIRED PrimitiveType String


permanentaddress-
permanentaddress-
permanentaddress-
permanentaddress-
permanentaddress-
permanentaddress-


-street REQUIRED PrimitiveType String
number REQUIRED PrimitiveType String
-city REQUIRED PrimitiveType String
-state REQUIRED PrimitiveType String
-country REQUIRED PrimitiveType String
-zip REQUIRED PrimitiveType String


airline-vehicle-vesselno REQUIRED PrimitiveType String









intendedaddress-
intendedaddress-
intendedaddress-
intendedaddress-
intended-length-


-street REQUIRED PrimitiveType String
-number REQUIRED PrimitiveType String
-city REQUIRED PrimitiveType String
-state REQUIRED PrimitiveType String
-of-stay REQUIRED PrimitiveType String


Figure 6-3. Global schema










































purpose-of-trip REQUIRED PrimitiveType String
business REQUIRED PrimitiveType String
pleasure REQUIRED PrimitiveType String
conference REQUIRED PrimitiveType String
official REQUIRED PrimitiveType String
family/friends REQUIRED PrimitiveType String
transit REQUIRED PrimitiveType String
other REQUIRED PrimitiveType String

visitedbefore REQUIRED PrimitiveType String
yes REQUIRED PrimitiveType String
no REQUIRED PrimitiveType String


intended-accomodation REQUIRED PrimitiveType String
hotel REQUIRED PrimitiveType String
guesthouse REQUIRED PrimitiveType String
boat REQUIRED PrimitiveType String
private REQUIRED PrimitiveType String
resort REQUIRED PrimitiveType String
other REQUIRED PrimitiveType String

special-interests REQUIRED PrimitiveType String
nature REQUIRED PrimitiveType String
diving/snorkeling REQUIRED PrimitiveType String
fishing REQUIRED PrimitiveType String
archaeology REQUIRED PrimitiveType String
beaches REQUIRED PrimitiveType String
other REQUIRED PrimitiveType String


comments REQUIRED PrimitiveType String


Figure 6-3. Continued



The LQPC returns the query results as an XML string. Query.jsp applies an XSLT


style sheet to this document to convert the XML document representing the query results


to an HTML document. Figure 6-5 shows query results for a role-A super user who has


access to all information being queried. The issued query requests for the last name, first


name, ports of embarkation and disembarkation information of all visitors


entering/exiting Belize and the Dominican Republic. Figure 6-6 shows the query results


for the same query for a role D user who does not have access to disembarkation


information. The query being considered is the same as the previous one.
















Listen Port: 8081
Target Host: localhost
Target Port: 8080
-=== Request ==
POST /axis/services/DominicanRService HTTP/1.0
Content-Type: text/xml: charset=utf-8
Accept: applicatlon/soap+xml, applicatlon/dime, multipart/related, text/*
User-Agent: Axis/1.0
Host: localhost
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: "
Content-Length: 1534


xmlns:xsd="http://www.w3.org/2001/XHLSchema" xmlns:xsl="http://www. 3.org/2001/XMLSchema-instance">


It; ?xml version =&apos:1.Oeapos;?>:
<'DOCTYPE QUERY [&1t;'ELEMENT QUERY (ROLE+, TABLENAHE, ATTRIBUTE+, OR*)>
&It;'ELEMENT ROLE (#PCDATA)> <'ELEMENT TABLENAME (#PCDATA)>
< ELEMENT ATTRIBUTE (#PCDATA) gt; ⁢'ELEMENT OR (AND+)>
<'ELEMENT AND (ATTRNAME, OPERATOR, ATTRVAL)> <'ELEMENT ATTRNAHE (#PCDATA)>
&It;'ELEMENT OPERATOR (#PCDATA)> &It;'ELEMENT ATTRVAL (#PCDATA)> ]>
<QUERY><ROLE>roleA super</ROLE>≪TABLENAME>Individual</TABLENAMErgt;
<ATTRIBUTE>passportno≪/ATTRIBUTE><ATTRIBUTEgt;lastname</ATTRIBUTE>
<ATTRIBUTE>firstnamelt;/ATTRIBUTE>: t;ATTRIBUTE>port-of-erbarkation-code</ATTRIBUTE>
<ATTRIBUTE>por-of-erbarkation-clty</ATTRIBUTE>
<ATTRIBUTE>port-of-embarkation-country</ATTRIBUTE>
<ATTRIBUTE>port-of-disembarkation-code</ATTRIBUTE>
<ATTRIBUTE>port-of-disembarkation-clty</ATTRIBUTE>
<ATTRIBUTE>port-of-disembarkation-country</ATTRIBUTE><ATTRIBUTE>COUNT(t) &t;/ATTRIBUTE>
<OR></OR><OR></OR><OR>lt;/OR>&It;/QUERY>









Figure 6-4. SOAP request sent to LQPC


_I-


I 1-0" | .J ; jfo "_Js "f 3, "* "l 4

Query Results!


Cont= 6
ssopor of Erataon P fEm of Emarkation o rkln P ofDiermbarkatin Po ofEenari
N.o t:rac Fn ao os 9E? DOE JOHN BOS BOSTON USA DW,ORD CHICAGO JUSA
8 KA THIT MDWOD CHICAGO USA WORD CHICAGO USA
0i10l AlESO SAAH LOAJPK INEWYORK USA BOSTON USA
133333 rl., I, t r jrI iI, .
SjOE5 CA iBoS BoSTON USA rJAJFK NEW YORK JSA
\77 JOHSO ISTE IBOS iBOSTON USA WORD CHICAGO |SA

Query Results!

DOMINCAN REPUBIC
Cont= 4
NPo ofEbarha P... of.Ema .. .o. .f Enbation I-". .. |orlofDs.. b.at.ion : ..*' .. ...

IAIl iiiH ASAD WiIT FJ HhYFK [ NEWY YORK
|A9W999 MIiH [MARY BOS FBSTON USA
1941 4485 6ATEISA IMA IJFK |WYOBK wSA
F3J323 232 OOIUEZJU JANNAiBZE BE UZECIT BEIZE S B BOSTON A









Wi 64 r F-F-m -


Figure 6-5. Query results for a super user


I. c ne- _-jr i ,m ,-











I,,PM: R V .f "... f t,( .UPI, L.[ A- ',



Query Resuts!
BVL1
Com 6
L -:1:. t. i ; For,-. E,- ii,.r i, ,:r :iE. rison P r : r, : II:-llirL bar.t I In F.. :1:*Itd- b&vI,






Query ResIlts!
D OMINICAN REFBUC

'a.. :N _. .... ....7 '.- r*C.. -( F A -: i kay)
"4T 7 .. I1 I Mi*. IiI -.w




Aill 1 KASAD rHATY LOAJFK IrEWORK [USA jHoOss |Nocesos |Nosccss






ar32525232 rfMO1,EZJUUANNA FBEE iBEUYECTy IBEZ |KooM [Noe|oooo










Figure 6-6. Query results for a role D user (no access to departure information)



6.1.2 Local Query Processing Component


The LQPC is deployed as a web service. With a Web Service Deployment

Descriptor (WSDD), we specify which classes are to be deployed as a service, which





implement handlers, etc. The Axis API, org.apache.axis.client.AdminClient, is used to


deploy and undeploy a web service. Once this service is deployed, another site can


simply invoke the web service by making an HTTP connection using the web service


URL. Axis provides the API, org.apache.axis.client.Call, which is used to invoke a web


service operation. The API encapsulates generation and decoding of SOAP messages and


provides a high level interface to invoke the web services operations.









The WSDD file to deploy the Dominican Republic LQPC web service is shown in

Figure 6-7. Figure 6-8 shows the WSDD to undeploy the web service. The local query

processing component web services are deployed as RPC services. This is the default

style of service in Axis 1.0. Figure 6-9 shows the SOAP message representing the query

results sent back from the Dominican Republic. This output has been obtained by running

the tcpmon utility available with Axis toolkit.


xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">






Figure 6-7. WSDD file to deploy Dominican Republic LQPC web service





Figure 6-8. WSDD file to undeploy Dominican Republic LQPC web service


We shall now describe the classes used to implement the LQPC. A point to be

noted here is that, though the overall functioning of these classes is the same for all local

query processing components, the data and language heterogeneities cause the actual files

to be different for different nations. In this section, we describe the classes in the context

of the Dominican Republic web service.

DRServer. This class provides the DRInterface method which is the method used

to invoke the DominicanR web service. This class also invokes the specxml class

methods by instantiating a specxml object using the query XML string passed to the web










54





service. The specxml class returns the query results to the DRServer class which returns



the XML string to the axis client (the global query processor).





=== Response ====
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Date: Tue, 27 Hay 2003 22:24:10 GMT
Server: Apache Coyote/1.0
Connection: close





&It;?xml version ='l.0'?>
&It;INDIVIDUAL DETAILS>
&It;COUNTRY>DOMINICAN REPUBLIC</COUNTRY>
&It;COUNT>4</COUNT>

&t; INDIVIDUAL DETAIL>
⁢passportno>Allll1&t;/passportno>
&It;lastname>KASAD</Iastname>
&It;firstnaimegt;THRITY&It;/firstname>
&It;port-of-embarkation-code gt;JFK</port-of-embarkatlon-code>
&It;port-of-emrbarkation-citysgt;NEW YORK</port-of-enbarkation-city>
&It;port-of-embarkation-country>USAk&t;/port-of-embarkation-country>
&It;port-of-diselnarkation-code>JFK&It;/port-of-disenbarkation-code>
&It;port-of-diselnarkation-city>NET YORK</port-of-disembarkation-city>
&It;port-of-disemtarkation-countrygt;USA</port-of-disemtarkation-country>&It;/INDIVIDUAL DETAIL>
It; INDIVIDUAL DETAIL>
<passportnogt;A999999999lt;/passportnogt;
&It;lastname>SMITH</lastnameigt;
&It;firstnaimegt;MARY</firstnalie>
&It;port-of-emrbarkation-codegt; BOS</port-of-emrbarkatlon-code>
&It;port-of-emrbarkation-citygt; BOSTON&It;/port-of-elnarkation-city>
&It;port-of-enwbarkation-country>T USkAt;/port-of-embarkation-countryEgt;
&It;port-of-diselntarkation-code>⁢/port-of-diselbarkation-code>
&It;port-of-diselbarkation-city>⁢/port-of-diselbarkation-city>
&It;port-of-disetlarkation-countryigt;&It;/port-of-disembarkation-country> </INDIVIDUAL DETAIL>
It; INDIVIDUAL DETAIL>
&It;nassportno⁢:94114485<:/assportno &ft;


<lastname>BATISTA</lastname>
⁢ frstname>MARIA</firstname>
<port-of-embarkatlon-code>JFK</port-of-embarkatlon-code>
<port-of-embarkation-city>NEW YORK</port-of-embarkation-city>
&It;port-of-embarkatlon-country>USA&ft;/port-of-embarkatlon-country>
<port-of-disembarkatlon-code></port-of-disembarkation-code>
<port-of-disembarkation-city>⁢/port-of-disembarkation-city>
<port-of-disenbarkatlon-country> ⁢/port-of-disembarkation-country> &t;/INDIVIDUAL DETAIL>
<INDIVIDUAL DETAIL>
<passportno>323232323</passportno>
<lastname>DOMINGUEZ</lastname>
<flrstname>JULIANNA</firstname>
<port-of-embarkatlon-code>B2E</port-of-embarkatlon-code>
<port-of-embarkatlon-clty>BELIZE CITY</port-of-erbarkatlon-city>
<port-of-embarkatlon-country>BELIZE</port-of-emebarkation-country>
<port-of-disenbarkation-code>BOS</port-of-disenbarkation-code>
<port-of-diseibarkatlon-clty>BOSTON</port-of-disenbarkation-city>
<port-of-disembarkation-country>USA</port-of-disemlarkation-country></INDIVIDUAL DETAIL>
</INDIVIDUAL DETAILS>









Figure 6-9. SOAP response from Dominican Republic LQPC web service









specxml. This class contains methods to implement the Extractor, the Translator,

the Access Controller, and the Query Processor of the wrapper of the Local Query

Processing Component.

mapAttr. This file creates hash tables for the mapping of the global v/s local

attribute names by reading in the text file containing the global local attribute name pairs.

QueryAirportInfo. This class provides methods to connect to the POM and query

it for airport related information.

Our system uses the Object-Relational Mapping Engine of the Persistent Object

Manager to perform database operations. Therefore, it is necessary to have objects

corresponding to the relational tables that we require. We have developed two objects,

each of which corresponds to a relational table in our database. The data members in

these objects and a brief description of their purposes are shown in Table 6-2.

Table 6-2. Description of objects and attributes stored in POM
Object/Table Data members Type Description
Description of object
Airport Airportcode String Three letter airport code
This object/table
contains the airport airportcity String Airport city name
related information
associated with the airportcountry String Airport country name
ports of embarkation
and disembarkation
roleAccess Tbname String Table Name
This object/table
describes the role Attribname String Attribute name
based access matrix
for all the attributes roleAsuper Int 0 or 1 depending on
in the local database whether a super user has
access to the particular
attribute

roleBpolice Int 0 or 1 depending on
whether a user in police
role has access to the
particular attribute










Table 6-2. Continued
Object/Table
Description of Object
roleAccess


Data Members

roleC immig


Type

Int


roleD userl






roleE user2






roleF tour


Description

0 or 1 depending on
whether a user in
immigration role has
access to the particular
attribute

0 or 1 depending on
whether a user in
immigration role
1(arrival information) has
access to the particular
attribute

0 or 1 depending on
whether a user in
immigration role 2
(departure information)
has access to the particular
attribute

0 or 1 depending on
whether a user in
tourist role has access to
the particular attribute


To utilize the POM for persistent storage, a configuration file must be created and stored

in the directory of the program that invokes the APIs of the POM. The database in which

we store our system's tables is MemDB. The sample configuration file is shown in Figure

6-10.


Host localhost
Port 9099
Database MemDB


Figure 6-10. Sample configuration file for the MEM database

The first parameter specified is the host on which the database is located. In our

distributed query processor, all database operations are performed by the local query









processing component. Hence, the value of the host parameter is "localhost" since the

LQPC is a local application for a particular site. This parameter can also be a machine

name or an IP address of a remote server.

The second parameter is the connection port number. POM uses this port number

for connection. No other program is allowed to use this port number. In our system, we

have chosen 9099 as the port number.

The final parameter specified is the name of the database. The database is created

in the default path specified in the Persistent Object Manager's settings.

Now we shall describe the implementation of the access control mechanism for the

Local Query Processing Component. We define the following:

Event access: We define an event access using the KPM GUI tool. This event is

posted by the Access Controller subcomponent of the LQPC. This event takes the role

vector, select attribute vector, and condition attribute vector and passes them to the

qaccessrule rule to implement access control.

Rule qaccessrule: This rule is described below

RULE qaccessrule(Vector selattr, Vector whereattr, Vector roleattr)
RETURNS restrictqaccess
DESCRIPTION This rules takes in 3 vectors as input parameters (selattr, whereattr,
roleattr), checks them against the role access information stored in
POM to either reject the query or accept it and return a 0/1 access
vector for all attributes in the select attribute vector.
RULEVAR Temporary Object ra;
CONDITION true
ACTION restrictqaccess ra=new restrictqaccess();
ra.restrictmethod(roleattr, selattr,whereattr);return ra;
ALTACTION
EXCEPTION


The restrictqaccess class has two attributes (Table 6-3).









Table 6-3. Attributes of restrictqaccess: return object for security rule of the distributed
query processor
Name Type Description
Flag Boolean False: query rejected
True: query accepted
Rbattr Vector A vector of 0's and 1's
corresponding to whether
a user has access to a
particular select attribute
in the Select Attribute
Vector or not.


The only method in restrictqaccess is the restrictmethodo, which connects to the

POM and queries the roleAccess table to determine if the user has access to the particular

set of attributes. If the user does not have access to even a single element in the Condition

Attribute Vector, flag is set to false else it is set to true. restrictmethod( also sets the

elements of the rbattr vector to 1 or 0 based on whether the user (associated with a

sequence of roles) has or does not have access to the elements of the Select Attribute

Vector.

6.2 Registration, Subscription and Posting of Events

We have defined the following two scenarios to demonstrate our system.

Police Arrest Record Scenario:

Event-Arrest: This event is posted when a police official enters the arrest record

information: defendant's information, witness information, and victim's information

pertaining to a particular arrest.

Event Filter- ArrestFilter: If the arrest is related to a particular crime and the

associated person is from a particular country.

Rule- hideVicWitInfo: Suppress the victim and witness information in the message

sent out to the subscribers.









Person in the Watch List Scenario:

Event- Arrival: This event is posted from a port of entry application form when an

individual enters the country. Its purpose is to trigger the WatchListCheckRule.

Rule- WatchListCheckRule: Checks if the person entering the country is on the

watch list. If yes, a warning message is displayed on the screen and the PEntry event is

posted. If the person entering the country is not on the watch list or if the suspicious

person is allowed to enter the country, a port of entry record for that individual is inserted

into the local country's database.

Event- PEntry: This event is posted by the WatchListCheckRule when the person

entering the country is on the global watch list.

Event Filter- PEntryFilter: If the individual entering the country has a particular last

name, first name, and nationality.

Notification is sent out to all subscribers whose filter attribute values match the

corresponding values in the event posted.

6.2.1 Registering an Event

To register an event at the OAS site, the user pulls up the Event Registration form

(Figure 6-11), which asks for the Event Name, the user's country name and the URI for

the event filter template. This form is posted to RegisEvent servlet. In our current

implementation, we assume that the event filter template XML file can be stored on any

machine but has to be accessible via the web. Thus the servlet would read the event filter

template file from its location. This event filter template XML file along with the event

name, description and event publisher's country, are used to invoke the EventRegister

web service deployed at the OAS site. This web service is deployed simply by creating a







60


Java Web Service (.jws) file for the web service class and placing this file under

Tomcat's webapps axis directory.


~J~J W


I .. I_ U .
I- I- I .. .. .


jS I '_.* r


REGISTER YOUR EVENTS HERE


EventName: |Arrest
EventDescription: Fh event s posted wh
Event registered by country: I||I Bee
|EventFilterTemplate(File Location): | |\,8\,kne\siel\Te mc
SFr P{;


Figure 6-11. Event registration page at OAS site

EvntRegister.jws: This web service does the following:

* Writes the XML string representing the event filter template into the corresponding
country's subdirectory at the OAS site.

* Translates the XML string to all other supported languages and stores them in the
respective subdirectories of the other countries.

* Converts the XML document to the corresponding HTML form that displays the
event filter template with placeholders for subscribers to enter their notification
information.

* Appends the new event information to the web pages containing the list of all
published events in the various supported languages at the OAS site.

6.2.2 Subscribing to an Event

When the user selects an event he/she wishes to subscribe to (from the web page

displaying the list of published events), he/she is directed to the HTML event


12 l-ft 1 t upl








61



subscription page generated by the EvntRegister web service. The Event Subscription


page generated for the Police Arrest Record Scenario is shown in Figure 6-12. After


filling out the required information, the form gets posted to the subscribe servlet. This


servlet wraps the subscription information in an XML string and invokes the WSETR


web service at the event publisher's site. This web service (WSETR.jws) performs the


following functions:


* Parses the XML document passed to it using a DOM parser and extracts the
subscriber's information.


* Invokes the subscribe method of the Event Manager using the parsed subscription
information. This method subscribes the user to the event of his/her choice and
stores the subscription information in the local POM.


AfiW~


I .. I ,' ,* ,'J .
I I

Subscribe to Event!
Abonese el acontecimiento
Eent Name:
Anest
Eent Descriprion:
This is a filter fo the arst record event
Please iput yourprefreence here:
DefClierl USA
DefAnestTypel Drug Trffi cki ng

Please input your contact information:
(Por favor entrada su information del contacto)
Namlnombre FThrlty
Emaiconeo electrom o Ithnty79@yahoo corn
Ce lNO elnumeo deteleft o lacelula 3522192631

Submi ResetI










1,'


Figure 6-12. Event subscription page for police arrest record scenario


13&\5\1-t\M I- Hi ft nt-tFIp- I








62



6.2.3 Posting an Event


To post an event, an application needs to invoke the post method of the Distributor


class of the Event Manager with the event name as a parameter.


Police Arrest Record Scenario. On submitting the Arrest.htm form (Figure 6-13),


the PostArrestFormEvent servlet is invoked. This servlet posts the Arrest event (using


parameters provided by the HTML form) to the local Event Server.




I''" ,.



Arrest Record Infor tion

guage IEngl sh j
DEFENDANT:
Name Andrez Gonzales
Street Address 951 Omega Drive
City Belize city
State Belize
Zp Code 45231
Phone# 4322134567
ColmtryofCltlzensup USA
Drug Trafficking
Arst Type

WITNESS:
\!'he IyVOI I

Name Amy Policard
Address 923 Omega Drive. Belize Cit Belize
Phone# 14321234581
VICTIM:
Name Shaun Shah
Address 900 Omega Drive Belize city Belize
Phoe# 43212321241
Submt| Reset |





Figure 6-13. Arrest.htm to post Arrest event




Person in the Watch List Scenario. Figure 6-14 depicts the overall


implementation to demonstrate the posting of an event when a visitor enters a country


and he/she is present in the global watch list of persons being monitored.







































Agets/Organizations


Figure 6-14. Watch list related immigration scenario


File Edit View Favorites Tools Help f


QBack J [. ^ Search 'Favorites e Media 0 7 L T D 4( -[
Address hj htp://28.227 176.39:80808/memorrm sp ,sp
Links C shortcut to 5olutlonHW2 Customize Links Free Hotmal 9 RealPlayer ] Windows 4 Windows Meda


ARRIVAL FORM


123456
iJul ana
10-JUN-1960
IS
IAl 23

I

Dominican nRepublic v
Sianto Domingo
|re re|
IDom ncan Republic
1-MAY-2000
1[mA>,00 1
i[


Apellidos
Nacionahdad


Ocupacion
ParidaNumeroVuelo
PuertoEmbarque
CmudadNacutrento
DocViajeNumero
No
CmudadParaje
ProvmciaEstado
ILugaraCrmento


Dominguez
Dominican Republic '"
IF
Business
8123
JFK
[Santo Domingo
A1111111
IAl
Santo Domingo


| SantDo Domngo

r

f


OK--i


Figure 6-15. Immigration form at port of entry in the Dominican Republic


NumeroCedula
Nombres
FechaNacimtento
EstadoCvlv[
NumeroVuelo
PuertoDesEmbarque
FechaFaratda
PaisNacrimento
Calle
MotovoViaje
Pais
FechaLlegada
C omentano General


v 1I Go









The steps depicted in Figure 6-14 are described here.


1. Post an event to the ETR Server using field values from the Arrival Form submitted
by port of entry official.

2. Check if the person is on the watch list.

3. If the person is on the watch list,
3a. Display a warning message.

3b. Post an Event to the Event Manager.

3c. Send email/cell phone notification to the subscribers of the event based on
their subscription profiles.

4. If person is not on the watch list or suspicious person is allowed into the country,
insert a port of entry record for that individual into the local country's database.


On submitting the Arrival form (Figure 6-15), the application posts the Arrival

event to the local ETR server (step 1).This event triggers the WatchListCheckRule. This

rule queries the watch list table in the local database to check if the visitor is on the watch

list (step 2). If yes(step 3), an alert displaying a warning message pops up on the screen

of the immigration official (step 3a) and the PEntry event is posted to the local Event

Manager(step 3b) Once the event is posted to the Event Manager, the Event Manager

identifies the subscribers of the event and sends them notification (step 3c).Ifthe person

is not on the watch list or a suspicious person is allowed to enter the country, a port of

entry arrival record is inserted for this individual, into the country's database.














CHAPTER 7
CONCLUSION AND FUTURE WORK

In this work, we have described the design and implementation of a distributed

query processor and its integration with the Event-Trigger-Rule based system to achieve

transnational information sharing and event notification. This system has the capability to

query heterogeneous immigration-related data from the component databases of different

nations. This is the first step towards meeting the end goal of the Transnational Digital

Government Project: to develop advanced information technology for transnational

resource sharing and intergovernmental and interorganizational

coordination/collaboration over virtual collaboration grids.

Our proposed transnational collaboration grid is comprised of network nodes

installed in the participating countries. Each node at a participating nation consists of a

distributed query processor, a Translator, a Web server, an Event Server, an ETR server,

a Knowledge Profile Manager, a Persistent Object Manager, and a Meta Data Manager.

The distributed query processor allows users of participating nations to access data across

national boundaries. It also deals with the issues of mediating data heterogeneities across

various databases. Furthermore, it makes use of the ETR server to implement a role based

access control mechanism to enforce data security and privacy policies and rules. We

have described the overall process of registering events with the OAS site in order to

make them (events) accessible for subscription by users. This is followed by a description

of how a user should subscribe to events of his/her interest from the OAS and the general

mechanism for automatic event notification, event filtering, and information delivery. By









defining and storing rules in the local ETR servers, the system achieves the capability of

automatic information filtering and dissemination, enforcement of interorganizational

policies, regulations and constraints, and security and privacy rules. This entire

architecture helps achieve a push-based information sharing and notification mechanism

across the transnational collaboration grids.

We have also described two scenarios: the arrest record scenario and the person in

the watch list scenario to demonstrate the use of the ETR technology in the context of the

transnational digital government framework to demonstrate event notification, filtering,

information delivery and rule processing. Our system is integrated with the web service

technology to achieve a uniform standard-based infrastructure for interoperation of the

heterogeneous application systems.

In spite of the desirable features that the implemented system provides, several

issues need to be further investigated. First, the language translator being developed at

the Carnegie Melon University needs to be integrated with the distributed query

processor and the event registration, filtering and notification mechanisms. Second, if the

port of entry data is to be gathered by using the conversational interface system or the

spoken dialog system contributed by the researchers at the University of Colorado, the

integration of our system with theirs will have to be carried out. Third, when a user

subscribes to an event, his/her subscription profile is sent to the event publisher's

knowledge web server even though the subscriber may be from a country different from

the event publisher's. Thus, when an event is posted, the Event Server of the provider

would send notifications to all the subscribers. This can be very time-consuming if the

number of subscribers is large and the notification is done by unicasting. A more efficient









way is to distribute the subscription information of the subscribers in a country to the

knowledge web server of that country. When an event occurs at the event provider side,

the Event Server at that site can send a notification to the Event Servers of all other sites

that contain subscription information of that event. These Event Servers can then process

the event filters and send notifications to the subscribers in their respective countries.

These and several other deployment-related issues are being resolved by

interactions with research groups at the five universities and the government officials of

the participating nations. Also, we need to identify other transnational digital government

problems that can be solved by using the general information technologies introduced by

the various research groups.

The system prototype described in this thesis is meant to be a starting point for the

intended distributed system. Once a stable system has been developed, research needs to

be carried out to understand the practical realities of deploying, maintaining and using the

system at the actual sites.















LIST OF REFERENCES


1. Lee, M., "Event and Rule Services for Achieving a Web-based Knowledge
Network," PhD Dissertation, Department of Computer and Information Science
and Engineering, University of Florida, Gainesville, Florida, 2000.

2. Lee, M., Su, S. Y. W., and Lam, H., "Event and Rule Services for Achieving a
Web-based Knowledge Network," Proceedings of the First Asia-Pacific
Conference on Web Intelligence (WI-2001), Maebashi City, Japan, Oct 23-26,
2001.

3. Su, S. Y. W. and Lam, H., "IKnet: Scalable Infrastructure for Achieving
Internet-based Knowledge Network," Proceedings of the International Conference
on Advances in Infrastructure for Electronic Business, Science, and Education on
the Internet, l'Aquila, Rome, Italy, July 31-August 6, 2000.

4. Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielson, H.,
Thatte, S., Winer, D., "Simple Object Access Protocol (SOAP) 1.1," May 2000.
Available from URL: http://www.w3.org/TR/SOAP/. Accessed on: 04/2003.

5. Ozsu, T. and Valduriez, P., "Principles of Distributed Database Systems", Second
Edition, Prentice Hall, Englewood Cliffs, NJ, 1999.

6. Yu, T-F., "Information Modeling and Mediation Languages and Techniques for
Information Sharing among Heterogeneous Information Systems," PhD
Dissertation, Department of Computer and Information Science and Engineering,
University of Florida, Gainesville, Florida, 1997.

7. Su, S. Y. W. and Yu, T-F., "Distributed Information Mediation and Query
Processing in a CORBA Environment," International Symposium on Digital Media
Information Base (DMIB '97), Nara, Japan, November 26-28, 1997, pp 120-131.

8. Kossman, D., "The State of the Art in Distributed Query Processing," ACM
Computing Surveys, vol. 32, no. 4, December 2000, pp. 422-469.

9. Parui, U., "Knowledge Profile Manager for Supporting Event-trigger-rule Services
on the Internet," Master's Thesis, Department of Computer and Information
Science and Engineering, University of Florida, Gainesville, Florida, 1999.

10. Shenoy, A., "A Persistent Object Manager for Java Applications," Master's Thesis,
Department of Computer and Information Science and Engineering, University of
Florida, Gainesville, Florida, 2001.









11. Hall, M., "Core Servlets and JavaServer Pages (JSP)," Prentice Hall PTR, 1
edition, 2000.

12. "The Tomcat 4 Servlet/JSP Container," Available from URL:
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/index.html. Accessed on: 02/2003.

13. Deitel, H., Deitel, P., Nieto T., Lin, T. and Sadhu, P., "XML How to Program,"
Prentice-Hall Inc., Upper Saddle River, New Jersey, 2001.

14. Holzner, S., "Inside XSLT," New Riders Publishing, Indianapolis, Indiana, 2002.

15. Gottschalk, K., "Web Services Architecture Overview The next stage of
evolution for e-business," September 2000. Available from URL:
http://www-106.ibm.com/developerworks/web/library/w-ovr. Accessed on:
04/2003

16. Nagarajan, K., "Integration of Business Events and Rules Management with the
Web Services Model", Master's Thesis, Department of Computer and Information
Science and Engineering, University of Florida, Gainesville, Florida, 2003, Figure
2-3, page 10.

17. "Axis User Guide," Available from URL:
http://docs.pushtotest.com/axisdocs/user-guide.html. Accessed on: 04/2003.

18. Sandhu, R., Coyne, E., Feinstein, H. and Youman, C., "Role Based Access Control
Models," IEEE Computer, vol. 29, no. 2, February 1996, pp. 38-47.















BIOGRAPHICAL SKETCH

Thrity Kasad was born on May 22nd, 1979, in Navsari, Gujarat, India. She received

a bachelor's degree in computer engineering, securing first class with honors from the

Maharaja Sayajirao University of Baroda, Baroda, India, in May 2001.

In August 2001, she joined the University of Florida to pursue a master's degree in

computer science and engineering. She has been a Teaching Assistant and a Research

Assistant during her studies at the University of Florida. Her research interests include

distributed query processing, active databases and object-oriented databases.