Personalized database views and triggers

Theoretical and Applied Informatics ISSN 1896-5334 Vol. 19 (2007), no. 1 pp. 3 - 18

Personalized database views and triggers JAROGNIEW RYKOWSKI a a

Department of Information Technology The Poznan University of Economics 60-854 Poznan, Mansfelda 4

Received 16 April 2007, Revised 15 May 2007, Accepted 1 June 2007

Abstract: In this paper an architecture is presented of a universal agent-based approach to the personalization of database access. Within the approach it is possible to adjust the personalization process to both individual user requirements, and some limitations provoked by hardware, software, and communication method used at the moment. The implementation is based on Agent Computing Environment ACE system and extensions of JDBC database drivers/libraries. Potential application areas are the following: advanced and individual controlling of database access, personal database monitoring, asynchronous notification for changes, mobile and handicapped access to databases, etc. Keywords: personalization, database views and triggers, software agents

1. Introduction The databases are nowadays a core of many information systems. Increasing number of different data-base users provokes increasing demand for personalized access to the information stored. Such personalization is related with a need of adjusting the information (or the way it is to be accessed) to the requirements and capabilities of a computer system or a human interested in getting this information. The system-related case is widely investigated, to mention very promising Web Services [22] with some extensions [3, 5, 23]. However, the hu-man-related personalization still waits for a global and efficient solution, especially in the scope of mass access to the information by plenty of different users. It is not trivial to combine economical and technical limitations, on one side, and different, sometimes conflicting users’ requirements, on the other side, par-ticularly if taking into account system efficiency and security. Moreover, recently we observe a boom of new methods of access, communication channels, and end-user devices – e.g., mobile telecommunication, wireless networks, palmtops, etc. Such methods and devices, especially used in a mobile environment, create a number of additional limitations: small keyboard and display, restricted battery time, limited bandwidth, etc. Thus, the classical defi-

4

nition of the personalization is extended to cover an adjustment of both: contents – to individual user requirements, and format – to technical possibilities of the device/channel currently used. In general, two approaches are possible to achieve personalization of database access: allowing per-sonalization at the server-side, or leaving all the personalization tasks to the user, to be achieved at the client side. In general, it is better to perform the personalization as close to the information source as possible, i.e., at the database management level. However, such personalization has not been a crucial requirement for a typical database management system so far. Only some already existing mechanisms and approaches were adopted, originally proposed to solve other problems – e.g., database views and triggers, and active, multiversion, and objectoriented databases. Such adaptations are quite limited, mainly due to centralized, uniform data management (c.f. Section 2 for details). Thus, a need arises to find a global, dynamic solution, being aimed at executing personalization actions at any place, in any situation, and for any user, communication channel and end-user device. In this paper, we propose to use software agents for the personalization of database access. We de-scribe an architecture of a universal agent-based framework for the personalization of database access. The framework makes it possible to adjust the personalization process to both individual user require-ments, and some limitations provoked by hardware, software, and communication method used at the moment. The remainder of the paper is organized as follows. In Section 2, current approaches to personalization of database access are presented, mainly based on views and triggers. In Section 3, software agent tech-nology is presented, together with some basic features of the agent environment used. In Section 4, basic ways of using user-defined software agents for database personalization are presented, followed in Sec-tion 5 by a presentation of overall system architecture and some important implementation issues. Section 6 provides final conclusions and points out some trends for future work. 2. Current approaches to personal database access As mentioned in Section 1, two general approaches are possible to achieve personalization of a database access: allowing personalization at server-side, or leaving all the personalization tasks to the user, to be achieved at the client side. Server-side personalization is usually achieved in an external manner, in so called n-tier architecture, and by adaptation of some internal database mechanisms, mainly views, triggers and versions in relational (post-relational) databases, and objects (multiversion objects) in object-oriented databases. In the n-tier architecture several software layers are distinguished, responsible for storing, accessing, supplying, formatting, and presenting the information. The database is usually used as the lowest layer – to store the information. Subsequent layers are responsible for further processing of the information, and finally presenting it to

5

the user. From a point of view of a typical user, there is one serious drawback of this approach: the server-side software tiers are common for all the users, at most parameterized by some basic user characteristics (e.g., a profile, personal data, current localization, etc.). Such parameterization is usually limited, due to both technical (one cannot predict all the possible application areas) and economical reasons. Thus, n-tier architecture vitally restricts personalization. The second mentioned mechanism – built-in database triggers – is usually implemented as a set of procedures auto-executed by the database management system once a given event occurs. Triggers are widely used as an efficient mechanism for on-line verification of the database integrity [13]. Triggers may be used as a personalization mechanism; however, as they were not designed to this goal, such personalization is restricted, for several reasons. First, triggers are common for all the database users. As such, triggers are usually designed by system designers, and one cannot easily personalize them. Second, triggers are connected with a given table (relation) rather than a user/query. This drawback cannot be fully eliminated by extending trigger code, due to growing code complexity and processing time. Third, the triggers cannot modify query results. Fourth, in a case of an error, all the query results are lost – even if partial results were correct so far. Fifth, current trigger implementations are limited to “modify” commands only – usage of triggers for read-only queries is not possible. Active databases [4, 1], and more recently, active XML databases [2] are, in some sense, an extension of the trigger mechanism (in a sense of a concept, and not as a time- or historical successor). In these databases, an automatic system reaction is programmed by a set of mutually connected event-condition-action ECA rules. The idea of active databases [14], intensively elaborated in middle 90-ties (such systems as ARIEL, early Postgres, Sentinel, TriGS, etc.), looks now to be abandoned, mainly due to impossibility of development of efficient methods for database management (both information and active rules). Active databases never reached a commercial status; however, some interesting innovations (as modern triggering for example) were successfully adapted for commercial database systems. From a point of view of a personalization process, active databases are characterized by exactly the same drawbacks as the triggers. Only the fifth drawback may be tempered (however, usually it is not for implementation reasons). Similarly, object-oriented databases [9], joining merits of object-oriented approach and object-oriented programming languages with classical database management [12], could not find significant commercial application areas (with some rare examples, as O2, Gemstone, Versant, Ontos, etc., however, with marginal market share). From a point of view of a personalization process, objects and classes from an objectoriented database seems to be a good base. However, high hardware requirements (disk space, CPU time) and complex management make this approach practically useless in a mass environment, with millions of potential (and different) users. While taking into account the limitations of n-tier architecture, database triggers, and active and object-oriented databases, a possibility of running independent, userdefined personalization programs at server-side seems to be quite attractive solution.

6

However, from a local administrator point of view, several restrictions and limitations must be applied to such programs, thus protecting the system from (intentional or accidental) damages due to incorrect behavior of the alien code. Note that a psychological aspect is usually more important than all the technological ones: administrators, having limited control over user-defined code, usually decide to allow only execution of programs developed by trusted users, blocking a possibility of execution of all unchecked (thus potentially dangerous) programs (cf. Section 3.3). As a consequence, most of the ordinary users have limited possibilities of running their own software at the server-side. Thus, such users usually decide to execute their programs at client-side, in a private environment. Such approach is, however, limited by at least three serious drawbacks. First, the information is taken from the database in an uncontrolled and unlimited manner, to be further processed somewhere and somehow. Thus, database managers may feel anxious for freely providing this information outside. Second, usually a lot of information must be transferred between the database and a client in order to fulfill even a simple request. However, most of the information is filtered out at the client-side, thus somehow significant part of the data transfer is useless. Third, transferring and further processing the information at client side requires high-bandwidth communication links and efficient client hardware, which may be costly or even impossible to achieve, especially for a mobile environment. To solve the problem of unlimited, both client- and server-side personalization of database access, we propose to use software agents. We adapted a framework of userdefined, imperative software agents called Agent Computing Environment ACE, already developed and implemented by us for the personalization of network data sources and systems [15]. In the next sections, we present some basic features of the ACE framework, and an adaptation of this technology to provide efficient and powerful personalization of database access. 3. Agent Technology In our approach, we define software agents in classical way, as presented in [8, 24]. A software agent is a program, executed at a given place, characterized by: (1) autonomy – agents process their work independently without the need for human management, (2) communication – agents are able to communicate with one another, as well as with humans, and (3) learning – agents are able to learn as they react with their environment and other agents or humans. An agent may be programmed by its owner, thus allowing a personalization of its behavior [17]. Agents may be executed in different places [10], according to owners’ needs and possibilities of the end-user hardware [19]. Agents may create and use other agents, for example for continuous monitoring of a given data source and informing about data changes. As a basic agent-based environment, we propose to use the ACE agent-based framework described in [16]. The framework is based on a set of distributed Agent

7

Servers, each of them capable of storing and executing software agents. The agents may be moved among Agent Servers. Agent Servers may be located in both stationary (multi-user, multi-agent, mass-usage servers) and mobile devices. In the latter case, characterized by limited hardware and software possibilities and high communication costs, personal light-weight Agent Servers may be used. ACE agents communicate among themselves by the use of the XML text-based messages. Agents may also contact local and remote software, both stationary and mobile. To this end, specialized agents-brokers are used called gateways (for contacting remote software systems) and drivers (for contacting local software and hardware). Gateways and drivers are usually prepared by system designers and designed for public, parallel, mass usage. In most cases, in addition to their basic functions, they act as information-cache and synchronization-points. ACE agents differ by state and behavior. Agent’s state is represented by current values of agent’s internal variables. These values are permanent, i.e., they are conserved while the agent is not activated and restored just before its activation. Agent’s behavior is programmed in agent code. To this end, two basic languages are preferred: an XML dialect for imperative shell-like programming, and Java. The XML-based programming improves overall system safety, due to continuous code inspection and impossibility of inserting malicious code. However, as the XML-based agent code is interpreted, the efficiency is limited. On the contrary, Java agents are compiled and thus efficiently executed, however, with some reduction of overall system security. As mentioned above, ACE agents are created and executed on behalf of their owners. An owner of an agent may be a human, or another agent. An agent is controlled by its owner, i.e., the code is defined by the owner, and the internal agent variables are defined and accessible for the owner only. If needed, agent behavior may be adjusted to the hardware/software possibilities of the environment the agent executes in [21]. There are two basic classes of ACE agents of the proposed system: public Service Agents, and Private Agents. Public Service Agents SAs are agents created by trusted users (usually system designers), to be used in a mass manner by many users. SAs are treated as trustful system elements. Their efficiency is of primary concern. Thus, SAs are programmed in Java. Java was chosen for its universality, portability, efficiency, big support for using with different Internet services and standards, and openness for linking with other software. Standard Java security checking is applied. If needed, some additional security mechanisms may be manually added by programmers, including user account, password checking, token verification, ciphering, etc. A way of usage of a given SA cannot be changed by an ordinary user; however, it may be parameterized during the invocation. SAs are used in all the situations where there is a need for mass access by many users to given information, providing this information in a standardized form and with optimum effort (from the system point of view). The most frequently used SAs are the following: communication wrappers, cache utilities, synchronizers, etc. The Private Agents PAs are created and controlled by their owners. Unless directly ordered by its owner, the agent cannot be accessed by any other agent and service. For

8

a trade-off between overall system efficiency and agent privacy, a specialized language is proposed to program agent behavior, based on XML and imperative programming. The language is equipped with several non-standard mechanisms to improve efficiency and security [16]. Several PAs belonging to the same owner and SAs may be used to compose a complex agent CPA. For each CPA, there are two basic programming levels: private level, under user personal control, and public level, under system (and in part external) control. The private layer is an equivalent for a shell layer of a typical operating system. This layer is composed of PAs, to be run under individual user control. Agents belonging to that layer may be used for CPA composition (links among other agents used and external services, data flow), service personalization (data presentation, user preferences, etc.), and some advanced tasks (monitoring of changes, data comparison, wrapping, caching, etc.) [20]. Agents belonging to the private layer may be activated either at request, or in an asynchronous manner. In the first case, CPA owner initiates the service activation. Once the execution of all service activities is over, a service response is generated and sent to the owner. The CPA becomes inactive until the next request. In the second case, the CPA initiates the activation, usually after detecting an information change in one of the observed SAs and services. Once a change is detected of any interest to the CPA owner, an appropriate message is generated and sent. Thus, the private layer may be used for continuous monitoring of changes of information from the database. The public layer is composed of different SAs (possibly connected with some external software), to be used in a public manner. Public agents and services cannot be modified by the CPA owner, however, they may be accessed, and the information taken may be used by the agents of the private layer. Basic tasks of the public layer are related with mass information access, massive and multi-user computing, access standardization, data caching, mass synchronization of parallel access to common data, etc. On the contrary to the private layer, functionality of the public layer is determined in advance. The SAs are prepared by system designers, and thus such agents are known in advance for the CPA owner. The SAs may be parameterized, with the behavior adjusted to the current CPA state. Although in theory users have full control over the behavior of their agents, in the reality they are not obliged to set up all their agents individually. There are four predefined classes of users, taking into account users’ ability to program agents’ behavior. The non-advanced users use predefined, standard, fixed CPAs. The advanced users use standard CPAs as well, however, with higher parameterization level. These users are allowed to manually change some agents’ internal variables. The experts are advanced users with an ability to change the links among agents composing the CPA agents as well as the parameters used. The programmers are experts with a possibility of defining their own PA agents for developing individual information flow [21].

9

4. Using ACE agents for personal database access To solve the problem of unlimited, both client- and server-side personalization of database access, we propose to use ACE agents. In Fig. 1, a logical architecture of serving a single database access by a typical personalization agent is proposed. This architecture may be a starting point for further individualization by users. Processing result set, tuple by tuple Applying changes no Are all tuples egzamined?

Reception of result set

yes Command executing/sending

Command standardization

Results standardization

Channel standardization

Channel adjustment

application SMS/MMS, voice, e-mail

Fig. 1. Logical architecture of serving a single command by a typical personalization agent

The agent is contacted by its owner by the use of one of the communication channels, arbitrary chosen at the moment. The command composed by the agent owner is normalized, taking into account channel properties and individual user parameters. For example, an SMS message composed in a semi-natural language may be used to choose a sample database query, via user-defined keyword extraction and analysis [18]. The normalized command is sent to the database management system, by a specialized gateway. The database response (in a form of a classical result set, i.e., as a set of tuples), colleted by the gateway, is sent back to the personalization agent. All the result tuples are fetched by the agent and processed, tuple by tuple. As a result of this process, a new tuple (a set of tuples) may be generated by the agent, replacing the original tuple under analysis. Finally, the newly obtained result set is normalized, according to channel specification (and, indirectly, to the possibilities of the end-user device) and individual user formatting algorithms. Such normalized result is sent to the agent owner as a response to his/her original command (e.g., as a natural-language SMS message). With the above logical architecture, it is possible to program an individual reaction for: (1) the command sent by the agent owner/application (including both its format

10

and meaning), (2) database response (including all the obtained result tuples, each of them analyzed individually), and (3) some specific parts of the process, both dynamic – as for example geographical location, date and time, and static, such as end-user hardware and software. Note that although the above architecture is quite general, in the reality all the above agent actions are programmed individually for each user, thus allowing personalization of the database access to the maximum extent. The basic technical question related with the above logical agent architecture is how to register/identify the agents to be executed for given database queries, users, timings, places, etc. Thus, four basic subtypes of ACE agents are provided1: (1) agents directly and statically bonded with their human owners, (2) agents bonded with some additional parameters of a query, (3) agents dynamically bonded with query results, (4) agents directly bonded with the database, an environment, a communication, etc. An agent statically bonded with its owner is a broker between this owner and the database, processing all the owner’s commands and obtained results. Such agent is responsible for standardizing the owner’s command (as required by the database management system and communication links), transferring the command to the database host, collecting the database response, and finally formatting the results according to owner’s requirements and current end-user software and hardware. The agent processes all the commands in the same manner (however, as notified above, individually programmed for each agent by its owner). Such agent is a counterpart of a personalized trigger or a personalized tier of an n-tier architecture. However, the agent is related with all the commands of a given owner, rather than all the modification commands related with a given database table (as for triggers) submitted by all the users (both triggers and n-tier architecture). In addition, the agent is able to process (and edit) the result obtained from the database, to add some results (e.g., some statistical data), to format the result (e.g., to change the result from a set of tuples to a flat text), to check some additional conditions, etc. Note that such additional functionality cannot be achieved by means of standard triggering mechanism. Moreover, such functionality is not common even for complex n-tier architecture due to high costs of the server-side personalization (cf. Section 2). An agent dynamically bonded with some additional query parameters is able to detect and use such user-defined parameters, such as: user name/password, individual access rights, environmental parameters (e.g., a geographical locations, date & time, nationality, etc.). Similar to the previous agent type, this agent processes all the commands in the same way. What is different is the agent identifier and invocation parameters may vary for different database accesses.

1

We only mention here agents directly related with a personalized access to the database. One may imagine other useful agent types: statistical agents, managers, monitors, etc. However, a detailed description of such agents will not be included here, mainly due to limited space, as well as to (at least) potential rich agent functionality, that is in the majority user-defined or at least application-specific.

11

An identifier and activation parameters for the agent dynamically bonded with query results are extracted from the result returned by the database. The identifier and the parameters may be set up individually for each tuple of the result; however, the algorithm for the extraction is the same for all the tuples. The agent is an extension of the agent bonded with some additional query parameters, enabling individual treatment of each tuple returned as the database response. The agent enables filtering and altering tuples of certain value/domain, e.g., intentionally falsifying some results for users with no rights to access the real value, changing values of the “secret” attributes to “inaccessible”, etc. Note that the filtering/editing may be performed in a transparent (from the end-user point of view) manner, with hiding the information about the changes performed. This may improve a resistance of the database to some attacks, as the attacker is convicted that his/her attack was successful, while it was not. The functionality of the agent dynamically bonded with query results cannot be achieved using nowadays techniques, mainly due to dynamic linking of personalization parameters with the result returned by the database (cf. Sections 2 and 3). The agent statically bonded with the database, environment, communication channel, etc. is a counterpart of a single tier in an n-tier architecture. The agent processes all the commands of all the users in the same manner; however, the detailed behavior of the agent may be parameterized, for example by user access rights, date and time, etc. All the above-mentioned agent types may be used in parallel in a single system, for a single user, a group of users, and the whole user population. Moreover, several agents of different types may be executed for a single user command, and the final results of one agent may be treated as input results for the next one. In this way, a single user may be supported by several agents, some of them created by/for him, some of them working at the system level, in both transparent and apparent mode. The ACE agents fulfill, in a natural way, all the requirements for advanced brokerage between users and the database (cf. Section 1). ACE agents combine advantages of the above mentioned n-tier architecture and internal database triggers, with no disadvantages of these technologies (cf. Section 2). An agent may be individually programmed to access a given database in a specific manner (taking into consideration database instance, tables, tuples, users, incoming queries, etc.). Agent’s behavior may be programmed to fulfill all the requirements of its owner. At the same time, the information gathered by the agent may be automatically adjusted to the environment the agent is executed in, current time, place, communication link, etc. One may say that agents may be set up by users and, at the same time, self-adopt themselves to changes in the environment. An agent does not have to execute in the same host the database management system is running. Instead, another server may be chosen if necessary, including a specialized network server and private end-user device (a mobile phone, a personal computer, etc.). Agents may be moved to other locations once some conditions are changed. Regardless the place of an execution, an agent may adjust itself to the environment/situation, e.g., sending an immediate SMS notification to a mobile phone, and transferring at the same time full report to a home PC.

12

5. System architecture and implementation What we propose is to use the proposed ACE agents in a transparent manner as long as it is possible, with existing database management systems and existing applications. Only for the most advanced agent type – agents dynamically bonded with the query results – a user must be aware of using some additional parameters for agent identification and execution, and this fact must be included directly in the application code. For the remaining three basic agent types (cf. Section 4) it is possible to program and execute agents without a need for changing existing applications and supplying any additional query parameters at run-time. Certainly, for some advanced users, such parameterization would be quite useful and may be set up in an individual manner, at desired level of individualization (cf. Section 3). Moreover, a dedicated application fully taking advantage of the ACE technology may be proposed, i.e., using different communication channels (SMS, e-mail, WAP/WWW, etc.), auto-adjusting to end-user devices, and more (cf. Section 3). A – apparent access to agents T – transparent access to agents

ACE application A

MA – Management Application

M A

Standard application

T

T

JDBC-API ACE-related driver

Agent Server Agent Server Agent Server

Database „original” driver Database Management System

Fig 2. Access to the database via agent-extended JDBC library and RDBMS driver

To minimize changes at the database level and at the application level, we propose to extend a software library for database access, being a standard mediator between the database and the applications (Fig. 2). Such a library is usually devoted to particular database management system and given programming language. For the reason of popularity, for our prototype implementation we chose Java programming language and JDBC library. Our current implementation uses a standard driver to the ORACLE database management system (version 9.x). Our extension, however, may be easily

13

adapted to any JDBC-compliant database driver, as it uses only standard JDBC procedures, with no extensions specific for any particular database management system. In our proposal, two basic kinds of applications may be used: existing applications, and newly proposed ACE applications (Fig. 2). We propose to use existing applications with the ACE agents statically bonded with users, the database, the environment, etc. Such an application may be used without any change, except for changing the standard database driver to our ACE-related one. To manage ACE agents bonded with the standard applications, a dedicated management application MA is provided that is a kind of an ACE-application. With such an application, one may statically link ACE agents to applications/users/databases/timings/places etc., thus monitor and control the agents and the traffic among applications, agents and the database. Note that the management is performed outside the applications and thus may be provided in a transparent (from an end-user point of view) manner, for example by a system designer/administrator. However, some advanced users may be able to apparently use MA application to make more profits of the ACE technology. ACE-specific applications may be designed to better use the ACE technology. First of all, such applications may use ACE agents in both transparent (with the use of the above-mentioned management application) and apparent way, shifting some functionality of MA application to the application code. Next, ACE applications may use several benefits of the ACE agents not necessary strictly related with a personalized access to the database – different communication channels, advanced user-defined formatting, asynchronous monitoring and informing about interesting changes in the database data, autonomous work, etc. And last but not least – standard applications may be used and controlled by an ACE application, thus enriching existing applications’ functionality. From the technical point of view, in our prototype driver we overloaded2 a definition of two classes: a database connection and a database segment. For both, we used an instance of the “original” class as a private variable, redirecting all the invocations to this variable. Some of the invocations are monitored, and if needed, some ACE-specific code extensions are executed. The updated class definition contains some ACE-specific private variables, e.g., for keeping the ACE-related state of the connection/segment, storing identifiers of the ACE agents, etc. Basic method of using the instances of the updated classes is the following. An application asks the database driver to activate a new connection (a new segment). This call is passed to the updated driver. The driver creates an instance of a new connection (segment) and redirects the control to the constructor of the class. The constructor creates an instance of an “original” class and, via this instance, performs standard access to the 2

For current prototype implementation, we use different names (prefixes) for “new” and “original” Java classes, thus we had to adjust the code of sample applications using ACE agents. However, for the final implementation we plan to provide a database driver with the whole definition of the “original” class replaced by the ACE-related one, thus keeping the applications unchanged.

14

database. Once the access is completed, the constructor interprets all the ACErelated parameters (if any), registering/invoking appropriate ACE agents from given Agent Servers. During the execution of the ACE agents, the “original” result generated by the database may be updated, according to the agent class and invocation parameters (cf. Section 4). Final result (or error notification) of type compatible with the “original” type is sent back to the calling application. Note that, as mentioned above, the calling application does not have to be informed about the fact of using the updated database driver. However, if informed, the application may supply some additional parameters during the call to use full potential of the updated driver. Known limitations of our current prototype implementation are the following. • ACE agents do not use the transaction mechanism. However, this mechanisms (and in particular rollback() and commit() methods) is used “as it is” at the level of the “original” driver. In future implementations we plan to extend the transactions to the population of ACE agents, thus having a possibility to hide temporary results and rollback some actions performed by the agents since the last “safe point”. We do not think this utility would be very useful, as ACE agents are used by ordinary users mainly for monitoring and personalization of read-only access to the database. The latter conclusion is based on real-life experiences with users of ACE agents and ACE-related applications. • Full updating (i.e., replacing by the new one) of the database driver may be difficult due to huge number of versions of such drivers, even for a single DBMS. We plan to provide a possibility of automatic generation of the “updated” driver from an existing one; however, this task is not finished yet. So far, the installation must be performed manually, with careful inspection of all the updated classes and interfaces. 6. Conclusions and future work In this paper we presented our approach to personalization of a database access by the use of ACE agents. Our proposal is characterized by several advantages in comparison to current approaches, mainly based on database triggers and n-tier architecture. • Existing applications and databases may profit from using ACE agents as monitors and personalizers, in both transparent (from the user point of view) and apparent manner. Mobile ACE agents and ACE applications, apart from personalization of the database access, are able to take some benefits of modern communication channels, from standard WAP/WML and SMS, through advanced MMS and PTT (Push-To-Talk), to (semi-)natural-language voice access. • ACE agents may be executed in an autonomic manner, and it is possible to implement an asynchronous way of information access. In a typical, synchronous access, this is the user who asks for some information by sending a query. In this case, ACE agents are used as brokers, first adjusting user command to the possibilities of

15

the database, and then formatting the database response according to individual requirements and possibilities of the end-user hardware/software. In the second case, the agent informs its owner that something interesting just happened. What is “interesting” for a given user is programmed in the agent code. Thus, ACE agents are used as personal asynchronous triggers. • Four different levels of personalization make it possible to use ACE agents by ordinary and advanced users at the same time. More the user is advanced in using agent technology, more personalization level he/she is able to obtain. • The framework may be used in a mass environment, with practically unlimited number of users, applications, and databases, of different types, localizations, communication methods, etc. The framework is flexible and open for: new users, creating new and incorporating existing applications, new database management systems (and new database instances), new communication methods, etc. ACE agents may be executed in arbitrary chosen (by users) places, including stationary network servers and users’ private mobile devices. Moreover, an execution place of an ACE agent may be dynamically adjusted to current situation/localization/time etc. • Today’s personalization mechanisms may be either replaced, or incorporated by ACE agents, depending on individual user needs. ACE agents offer personalization support at the level at least comparable with exiting systems, including active and object-oriented databases, however with no burden related with centralized management (the main reason of abandoning the above database types). • An openness and universality of the ACE framework makes it possible to incorporate and use almost any existing software technology. In particular, ACE agents may serve as an efficient tool to implement personalized services (e.g., Web Services), they may support knowledge representation and interchange (e.g., using ontologies, UDDI catalogues, KQML, etc.), they may be used for personal assistance (like FIPA-agent [7], DARPA agents [6]), etc. • Using ACE agents as external brokers to database systems makes it possible to personalize behavior of such closed systems, as bank databases, company’s internal systems, etc. Moreover, such personalization may be performed in an invisible way (from the point of view of a database administrator). Potential application areas of the ACE framework are the following: advanced and individual controlling of database access, personal monitoring, asynchronous notification for changes, personalization of closed systems, mobile access to databases, enabling access for non-advanced and handicapped (by hardware and communication-link purposes) users, etc.

16

References [1] ACT-NET Consortium (1996), The Active Database Management System Manifesto: A Rulebase of ADBMS Features, ACM Sigmod Record 25-1996-3, pp. 40-49, [2] Abiteboul, S., Benjelloun, O., Milo, T. (2007), The Active XML project: an overview, PDF file from ftp://ftp.inria.fr/INRIA/Projects/gemo/gemo/GemoReport-331.pdf [3] Bonett, M. (2001), Personalization of Web Services: Opportunities and Challenges, Ariadne Issue 28, http://www.ariadne.ac.uk /issue28/personalization/intro.html [4] Ceri, S., Fraternali, P. (1997), Designing Database Applications with Objects and Rules. Addison-Wesley, ISBN 0-201-40369-2 [5] DAML Semantic Web Services (2006). From http://www.daml.org/services. [6] DARPA Agent Markup Language Homepage (2006), from http://www.daml.org/ [7] FIPA ersonal Assistant Specification (2006), http://www.fipa.org/specs/fipa00083/XC00083B.html [8] Franklin S., Graesser A. (1996). Is it an Agent, or just a Program? A Taxonomy for Autonomous Agents. Proceedings of the 3rd International Workshop on Agent Theories, Architectures, and Languages, Springer-Verlag [9] McFarland, G., Rudmik A., Lange D. (1999), Object-Oriented Database Management Systems Revisited, from http://www.dacs.dtic.mil/techs/oodbms2/ [10] Milojicic D. (1999), Trend Wars – mobile agent applications, IEEE Concurrency, pp. 80-90. [11] Nwana, H. (1996), Software Agents: an overview, Knowl. Eng. Review 11-1996-3, pp. 205-244 [12] OODBMS Facts (2001). Barry & Associates, http://www.odbmsfacts.com/ [13] Oracle Triggers (2007), from http://wwwrohan.sdsu.edu/doc/oracle/server803/A54643_01/ch15.htm [14] Paton N. (1999), (Ed.), Active Rules in Database Systems, Springer, ISBN 0-387-98529-8 [15] Rykowski, J. (2005). ACE Agents – Mass Personalized Software Assistance. Lecture Notes in Artificial Intelligence, 3690, pp. 587-591 [16] Rykowski, J. (2006). Management of information changes by the use of software agents. Cybernetics and Systems, vol. 37, no 2-3. Taylor & Francis Publishing, Philadelphia (US), ISSN 0196-9722, pp. 229-260

17 [17] Rykowski, J. (2005), Personalization of monitoring of network data sources by the use of software agents, Pro Dialog International Journal, II-2005, (in Polish). [18] Rykowski, J. (2005). Using software agents to personalize natural-language access to Internet services in a chatterbot manner. In Proceedings of the 2nd International Conference Language And Technology L&T’05, Poznan, Poland, April 2005. [19] Rykowski, J. (2006), Who should take care of the personalization?, in IFIP International Federation for Information Processing, Volume 226, Project E-Society: Building Bricks, eds. Suomi, R., Cabral, R., Hampe, J., Felix, Heikilla, A., Jarvelainen, J., Koskivaara, E., Boston: Springer, pp. 176-188. [20] Rykowski J., Cellary W. (2004), Virtual Web Services - Application of Software Agents to Personalization of Web Services, 6th International Conference on Electronic Commerce ICEC 2004, Delft (The Netherlands), 2004 ; ACM Publishers; pp. 409-418. [21] Rykowski, J., Juszkiewicz (2003), A., Personalization of Information Delivery by the Use of Agents, IADIS Int. Conference WWW/Internet, Algarve, Portugal, pp. 1056-1059. [22] Web Services Activity home page (2002), from http://www.w3.org/2002/ws/ [23] Web Ontology Language OWL (2004), from http://www.w3.org/2004/OWL/ [24] Wooldridge, M. (2002), Introduction to MultiAgent Systems, ISBN 978-0-471-49691-5, Wiley &Sons.

18

Spersonalizowane perspektywy oraz wyzwalacze bazy danych

Streszczenie W artykule zaproponowano zastosowanie technologii agentów programowych do personalizacji dostępu do bazy danych, w szczególności do umożliwienia personalizacji widoków bazy danych oraz wyzwalaczy. Opisano zarówno architekturę systemu, jak i jego implementację w środowisku relacyjnej bazy danych, z wykorzystaniem języka programowania Java oraz biblioteki JDBC. Podejście umożliwia dopasowanie sposobu dostępu do bazy danych zarówno do indywidualnych wymagań użytkownika, jak i ograniczeń w dostępie nakładanych przez wykorzystywany sprzęt, oprogramowanie oraz łącze komunikacyjne. Podejście charakteryzuje się szeregiem zalet w stosunku do obecnie stosowanych metod personalizacji dostępu, w szczególności: (1) staje się możliwa personalizacja systemów zamkniętych, w których nie przewidziano możliwości zmian metod dostępowych dla poszczególnych użytkowników, (2) użytkownicy mogą wykorzystywać niestandardowe kanały komunikacyjne, takie jak wiadomości SMS/MMS, bramki głosowe, dostęp WAP itp., (3) agenty programowe mogą śledzić kluczowe dla użytkowników zmiany da-nych oraz powiadamiać swoich właścicieli o zajściu takich zmian, w wybranej przez użytkownika formie, miejscu i czasie, (4) podejście jest skalowalne i umożliwia personalizację systemu masowego, z potencjal-nym rozproszeniem funkcjonalności w sieci komputerowej oraz urządzeniach końcowych użytkowników. Przewidywane obszary zastosowań obejmują indywidualny monitoring danych rozproszonych, indywidu-alne łączenie i wspólne przetwarzanie informacji pochodzących z różnych źródeł, udostępnianie informa-cji użytkownikom za pośrednictwem kanałów mobilnych i standardowych łączy telekomunikacyjnych, itp.