respect to software engineering, mobile computing paradigm has introduced the ...... decision of aborting transaction to each non-returned clone or to dispatch ...
XVII Simpósio Brasileiro de Banco de Dados
AMDB: An Approach for Sharing Mobile Databases in Dynamically Configurable Environments Angelo Brayner
José Aguiar M. Filho
University of Fortaleza - UNIFOR {brayner, jaguiar}@unifor.br
Abstract We define a Mobile Database Community (MDBC) as a dynamic collection of autonomous mobile databases in which each database user can access databases in the community through a wireless communication infrastructure. New participants may join to an MDBC as they move within communication range of one or more hosts which are members of the MDBC. On other hand, MDBC participants may transiently disconnect from the network due to communication disruptions or to save power. For that reason, an MDBC can be characterized as a dynamically configurable environment. This paper describes an agent-based architecture, called AMDB (Accessing Mobile Databases), which enables such communities to be formed opportunistically over mobile database hosts in ad hoc configurable environments. The AMDB architecture is fully distributed and exploits physical mobility of hosts and logical mobility of database queries and their results across mobile hosts. A prototype of the proposed architecture is currently being developed based on the IBM agent system, called AGLETS.
1. Introduction Advances in portable information devices and wireless network technology have led to the development of a new computing paradigm, called mobile computing. According to this paradigm, users carrying portable devices have access to information services provided through a wireless communication infrastructure, regardless of their physical location or movement patterns. Mobile computing paradigm has affected traditional models and concepts of many computer science areas. For example, in the network area, networks need to be ubiquitous, since they must guarantee user connectivity independently of the physical user location. Communication networks with such as property are called ad hoc networks [12]. With respect to software engineering, mobile computing paradigm has introduced the notion of mobile code. Informally, code mobility refers to the capability of dynamically changing the bindings between code fragments and the location where they are executed. In addition, mobile codes need to be “aware” about the computational environment on which they are running. Based on this knowledge, they can take decisions and perform actions [10]. Database technology has been impacted by the mobile computing paradigm as well. From a database technology perspective, the mobile computing paradigm provides the necessary support for the following scenario: several mobile computers (also called mobile units or hosts) can be interconnected through a wireless communication infrastructure, on each of which resides a database system, denoted mobile database. In such a context, the notion of any-where and any-time data access is introduced. Thus, any mobile computer user can access any database residing on a mobile computer. Such a database is denoted mobile database, since it resides on a mobile unit.
12
XVII Simpósio Brasileiro de Banco de Dados
We call mobile database community (MDBC) a dynamic collection of autonomous mobile databases, interconnected through a wireless communication infrastructure. It is important to note that databases in an MDBC can be mobile, autonomous, distributed and heterogeneous. Accordingly, conventional concepts and techniques, used in areas, such as query processing, transaction management and data distribution, must be revisited in order to introduce the concept of mobility into the database technology. In order to illustrate this fact, consider a mobile database community M. Databases belonging to M are heterogeneous and reside in mobile computers interconnected through an ad hoc network. Now, suppose that a database DB residing on a mobile computer C is a member of the MDBC M. The database DB should be shared with each other community member. In other words, the computer C should behave as a database server belonging to M. Additionally, a user on the mobile host C may wish to query objects stored at other databases which are members of M. Of course, the heterogeneous, distributed, autonomous and mobile databases have to be integrated. Since the databases are mobile, they can leave the community at anytime, even though the required query is still running. Moreover, the query submitted by a user on the mobile host C can represent a distributed transaction. In this case, a protocol to guarantee the atomicity of the commit operation1 is required. Therefore, in such a scenario, it is necessary to address the following problems in order to make feasible the access to mobile databases in an MDBC: (i) heterogeneous databases integration; (ii) query processing over a variable number of mobile databases and; (iii) mobile transaction management (i.e., concurrency control and recovery for mobile and distributed transactions). In this paper we propose an architecture, denoted Accessing Mobile Database (AMBD), for supporting database sharing in mobile database communities. The gist of the proposed architecture is to provide access to heterogeneous, autonomous and mobile databases. The AMDB architecture is based on the concept of mobile agents and is fully distributed. Furthermore, it provides the support to form MDBCs opportunistically over mobile databases hosts. Since AMDB is an agent-based architecture, it does not require changes to the core of underlying databases systems. For that reason, we classify the AMDB approach as nonintrusive [6]. This property enables commercial DBMSs for participating in a mobile database community through AMDB architecture. In order to make a DBMS member of an AMDB, it is only necessary to install the AMDB agents in the mobile computer, which is the host of the DBMS. It is important to note that that many approaches to support mobility can be classified as intrusive in that they require new capabilities to be added to the underlying database [5,7]. This paper is structured as follows. In section 2, a mobile computing environment is characterized. In section 3, the concept of mobile databases community is defined. Section 4 presents the AMDB architecture. The components of the architecture are described and analyzed. Section 5 focuses on query processing and optimization opportunities in the AMDB context. Transaction processing issues in the proposed architecture are addressed in Section 6. Finally, section 7 concludes the paper.
1
Such a protocol is necessary to enforce that a distributed transaction presents the same state in every mobile host, in which the transaction is executed. An example for such a protocol is the 2PC protocol.
13
XVII Simpósio Brasileiro de Banco de Dados
2. Mobile Computing Environment An abstract model for a mobile computing environment can be defined as follows. Mobile computers are grouped into components called cells. Each cell represents a geographical region covered by a wireless communication infrastructure. Such cells can represent a Wireless Local Area Network (WLAN), an ad hoc network, an geographical area covered by a cell phone network (called cell as well) or a combination of those communication technologies (for example, an ad hoc network inside cell of a cellular phone network). Mobile support stations (or base stations) are components of a mobile computing platform which have a wireless interface in order to enable communication between mobile units located at different cells. Thus, each cell must be associated with one mobile support station. Communication between two base stations is made through a fixed network. In fact, mobile support stations represent fixed hosts interconnect through a high-speed wired network. From a database technology standpoint, there are two classes of database systems in a mobile computing environment: (i) a class consisting of database systems which reside on fixed hosts, and; (ii) a class of database systems which reside on mobile computers. Database systems residing on mobile hosts are denoted mobile databases It is worthwhile to note that, when a cell in a mobile computing environment represents a WLAN or an ad hoc network, mobile computers inside the cell can communicate with each other directly. On the other hand, when a cell represents an area covered by a cell phone network, mobile units need should use the cell’s base station to communicate with each other. A mobile computer can use different communication technologies. We call vertical handoff the fact of a mobile computer migrating from a given communication technology to another. For example a mobile computer A can use a WLAN to communicate with other mobile computer inside the same cell, and it can use a cellular phone network to communicate with mobile computers located at another cell. From a database technology perspective, we can categorize mobility in two different types: x Physical Mobility: this type of mobility cope with spatial mobility of database clients and database servers through different space regions; x Logical Mobility: this type of mobility is related to code migration among several mobile clients and database servers. In order to provide logical mobility, mobile computers should be able to generate database access codes (SQL queries, stored procedures or methods), which can migrate autonomously to several databases servers. When such a code arrives at a database server, it should be locally executed. After that, it should return (with the access result) to home (the host which originates the access code). As we will see in section 4, the AMDB architecture provides support to both of the mobility types described above. 3. Mobile Database Community In our approach, a database system is characterized as a mobile database, if the database system resides on a mobile unit. Next, we describe what we call mobile database community. A Mobile Database Community (MDBC) represents a dynamic collection of autonomous mobile databases, interconnected through a wireless communication infrastructure. Thus, an MDBC models the notion of a federation of databases, where those databases may reside on mobile units. At a given moment, a varying number of mobile computers can participate in an MDBC. In this case, MDBC members share databases available in the MDBC. An MDBC 14
XVII Simpósio Brasileiro de Banco de Dados
member can behave as a database server or as a client in the community. Therefore, we have two types of members in an MDBC: database server or database client. By database server, we mean that a mobile computer, which is the host of a database system (DBS). Each database system encompasses a database (DB) and a database management system (DBMS). A database represents a collection of object representing real world entities. A DBMS is the software component of the DBS. In that case, the database (or part of it) stored in a database server can be accessed by any other member of the community. The second class of MDBC members is composed by mobile hosts which participate in an MDBC as database clients. Such members can only access object stored in databases available in the MDBC. That means, either they do not have or they do not want to share an own database with the members of the community. New participants may join to an MDBC as they move within communication range of one or more hosts which are members of the MDBC. On other hand, MDBC participants may transiently disconnect from the network due to communication disruptions or to save power. For that reason, an MDBC can be characterized as a dynamically configurable environment. A mobile computer needs to declare to the participants of an MDBC its intention to become a member of the community. If the mobile computer is the host of a database system, it should declare that its database will be available to the members of the community. In that case, the mobile computer has to publish its database schema to the community. It is highly likely that databases in an MDBC are heterogeneous. For example, they might be relational, native XML, oriented-object databases or any other data source (e.g., HTML pages). Thus, schemas of databases belonging to an MDBC should be represented in a common model. Since XML has been consolidated as a standard for data interchanging, we have decided to use XML as the common model for data interchanging in an MDBC. For that reason, mobile databases in an MDBC have to publish their schemas (or part of them) through XML Schema [23], a schema definition language for XML data. Mobile users interact with mobile databases in an MDBC by means of transactions. A transaction models a sequence of operations on database objects that is executed atomically. Typically, such operations are expressed in a database query language such as SQL. There are two types of transactions in an MDBC environment: local transactions and global transactions. A local transaction is submitted directly to a mobile database DB by an application running on the same host on which DB resides. A global transaction encompasses database operations which should be executed on different hosts belonging to an MDBC. Observe that the notion global transaction in an MDBC generalizes the concept of distributed transaction, since a global transaction captures the mobility property, besides being distributed. Therefore, a protocol should enforce commit atomicity of global transactions. An example for such a protocol is the two-phase commit (2PC) protocol [1]. The correctness criterion for the execution of concurrent transactions is serializability. We assume that each mobile database in an MDBC guarantees serializability by the two-phase locking (2PL) protocol. This is a quite reasonable assumption, since all existing database systems implements the 2PL to guarantee serializability. 4. Sharing Databases in Mobile Database Communities The key goal of the proposed architecture is to enable MDBCs to be formed opportunistically over mobile database residing on mobile hosts in environments with a wireless communication infrastructure (for example, an ad hoc network). The proposed architecture is fully distributed (i.e. no centralized control structure is needed) and relies on existing mobile agent technology to allow transient sharing of databases. In addition, to support disconnected operations, the architecture exploits logical mobility of both database queries and their
15
XVII Simpósio Brasileiro de Banco de Dados
results. For the sake of clarity, we assume that mobile computers are interconnected through an ad hoc network infrastructure. 4.1 AMDB Architecture As already mentioned, the AMDB architecture is based on the concept of software agent. The proposed architecture has two classes of agents: stationary agents and mobile agents. The stationary-agent class is compound by two types of agents: manager agents and wrapper agents. Manager agents are responsible for managing local computational resources of a mobile computer. These resources can be used to perform tasks of mobile agents. Wrapper agents provide an interface between mobile unit users and the AMDB platform. For that reason, Wrapper agents have the following functionalities. First, they should create the execution context for mobile agents. Thus, wrapper agents behave like a middleware between a mobile agent and a database participating of an MDBC. Second, wrapper agents provide a common data representation of the stored local data at mobile computers. As already said, XML will be used as a common data representation. Additionally, a wrapper agent running on a given mobile unit is also responsible for temporarily transferring one or more services to another mobile computer of the community to improve performance or whenever a critical situation occurs (for example, temporary service unavailability such as insufficient local memory for processing a query) at its mobile computer. In this case, any mobile agent visiting the mobile unit of the wrapper agent should be redirected to the unit where the service is being provided. Obviously, the mobile-agent class is compound by mobile agents. Mobile agents are responsible for implementing the logical mobility property in the AMDB architecture. Consequently, they should be able to transport itself from one MDBC member to another. In the proposed architecture, the basic feature of mobile agents is to carry database access code and access results, while migrating between MDBC members. In the AMDB architecture, there are three types of mobile agents: Runner, Loader and Broker agents. Runner agents are directly responsible for performing tasks required by mobile unit users in remote mobile databases belonging to an MDBC. Such tasks can represent data queries, data updates or schema evolution of the mobile databases. Loader agents have the functionality of carrying a database query result back to the mobile unit that has required the query. Broker agents should gather schemas of mobile databases of an MDBC, when a mobile unit joins to an MDBC. Moreover, a broker agent can define a mobile unit as temporary storage for storing partial query results when it is necessary.
Mobile Unit MUL
Manager
Client Apicação Apicação Application Cliente Cliente
Wrapper
DBMS
Broker
Runner
Loader
DB
Client Apicação Apicação Application Cliente Cliente
Wrapper
DBMS
DB
Figure 1: Abstract Model of AMDB architecture 16
Mobile Unit MUM
Manager
XVII Simpósio Brasileiro de Banco de Dados
Figure 1 depicts an abstract model of the AMDB architecture. In order to describe how the proposed architecture works, suppose that a mobile unit MUM wants to form an MDBC. For that, it declares itself as initial coordinator of the new community to its wrapper agent. After that, the wrapper agent of MUM sends information about the new community to all computers inside the area covered by the wireless communication network in which MUM is connected. When news members begin to join the new MDBC, the central coordinator role is not necessary anymore. This coordinator function will be performed local and collaboratively by the wrapper agents at each mobile unit which is member of the community. Now, suppose that a mobile unit MUL wants to join to the MDBC, which was initially created by MUM. First of all, it is necessary an explicit declaration of MUL in order to see the schemas of all databases which are member of the community. This functionality is executed by the local wrapper agent, which, in turn, creates a broker (mobile) agent and gives to it the task of querying local database schema at all mobile units, which are hosts of database systems. The broker agent will roam unit by unit and will collect the local schemas. Local database schemas will be provided by local wrapper agents. Recall that local schemas visible to the members of an MDBC are represented in XML Schema [23]. When the broker agent of MUL returns to MUL, it brings the schemas of the participating databases and passes them away to wrapper agent of MUL. With the database schemas of each database of the MDBC, users or application programs at MUL can see data stored at those databases. To enable the access to such databases, the wrapper agent provides an interface to users and application programs. Therefore, users or application programs submit queries to the local wrapper agent. Such queries should be specified in XQuery [24], a query language for XML data. A global query denotes a query, which should be executed over several databases of an MDBC. When the wrapper agent of MUL receives a global query, it creates a runner (mobile) agent at MUL and passes to the runner agent the XQuery expression corresponding to the submitted query. After that, the runner agent begins to process the query. The query execution plan should be generated considering optimization opportunities and the hosts (MDBC’s participants), where the query will be actually executed. It is important to observe that an MDBC is characterized as a distributed environment. Therefore, most queries in such an environment are distributed. In section 5, query processing performed by runner agents will be detailed. The scenario described above is illustrated in Figure 1. The wrapper agent of MUL creates a runner agent, which has to migrate to MUM, considering that MUM encompasses the target DBMS for processing the query submitted initially at MUL. When the runner agent arrives at MUM, it sends the XQuery expression to the local wrapper agent. The wrapper agent of MUM, in turn, maps the XQuery expression to the native query language of the local database and submits it for execution as a common user. When the result is available, the local wrapper agent passes it back to runner agent. If the result is too huge and the runner agent has still to migrate to others units, the runner agent can create a loader agent and transfers to it the result of the query execution on MUM. The loader agent begins a trip back to the runner-agent home unit. It is important to note that once the loader agent creation has finished, the runner agent can resume migrating to other units. Asynchronously, the loader agent takes the partial query result data back to MUL. When the runner agent returns home, it communicates to the wrapper agent of MUL that its task has finished. The wrapper agent unit shows the result to the user or sends the results to application program. Next agent functionalities will be described and analyzed.
17
XVII Simpósio Brasileiro de Banco de Dados
4.2 Stationary-Agent Class Agents belonging to this class must be installed at each mobile computer which participates in an MDBC. The primary function of this class of agents is to provide support to the execution of mobile agents and to manage local resources of each mobile computer of an MDBC. As already said, this class is compound by the manager and wrapper agents. Next, functionalities of both of them will be detailed. 4.2.1 Manager Agent The Manager agent is responsible for providing local support functions to all other agents (stationary or mobile). Its functionalities are described below. Management of local computational resources. This is the key function performed by a manager agent. In mobile units, the manager agent can control battery status or memory use for accepting or not service requests (for example, queries or updates). Providing Services Lists and Services Parameters Definition. A manager agent is responsible for making available a list of supported services by the mobile computer. When a mobile unit joins to a community, the service list supported by the mobile unit should be published. The Service list of a mobile unit can be changed dynamically. A list of services may include: x Identification of the unit behavior in the MDBC: This service indicates the behavior of the mobile unit inside the community. It can be either a database client or a database server (in this case, the mobile unit has a database system, which is available to the community); x 2PC Protocol Support: Here it is indicated if the local database system implements the 2PC protocol; x Backup for a 2PC Coordinator: This type of service indicates whether or not the unit can or be selected as a backup for the coordinator process of the 2PC protocol. Such a service is important to cope with coordinator failures (see section 6). O course, this service is only supported by units which support the 2PC protocol as well; x Temporary Storage: it indicates whether or not the unit can be selected to play a temporary storage role for partial results of other units; x Identification of Non-Supported Operations: This service indicates natively nonsupported operations by local database at mobile unit (see section 5). Temporary Transfer of Services. In scenarios with peak of demand or lack of resources, manager agents can decide to transfer one or more services from its unit to another unit in the MDBC. In this case, the manager agent asks the wrapper agent to redirect running mobile agents to another unit. Making disconnections. A manager agent is responsible for subscribing/unsubscribing the mobile host where it is running to/from an existing mobile database community. This can occur upon explicitly user request or upon temporary disconnection (for example, saving mobile unit battery).
18
XVII Simpósio Brasileiro de Banco de Dados
4.2.2 Wrapper agent A wrapper agent behaves like a middleware between the mobile unit and the MDBC. The functions executed by a wrapper agent are described bellow. Providing a common local data representation. As already said, XML will be used as common data model. This strategy relies on fact that XML is becoming a standard for data interchanging. Therefore, a wrapper agent should make available an XML schema to all members of an MDBC. The XML schema describes part of the local database schema in XML format. By doing this, we guarantee the necessary support to execute queries over distributed, heterogeneous and mobile databases. Performing mobile agent requests. When a mobile agent arrives at an MDBC’s member, it tries to perform its task. To do that, the mobile agent has to interact with the local wrapper agent. In fact, the mobile agent sends XQuery expressions to the local wrapper agent. The wrapper agent, in turn, translates XQuery expression to local database native query language expressions (for example, SQL or OQL). The wrapper agent submits the query to the local database system. After receiving the query result, the wrapper agent passes the results back to the mobile agent. Redirecting mobile agents. A wrapper agent of a mobile unit MU which belongs to an MDBC M has the property of transferring the execution of a local service to other member of M. This may occur when such a service can not be executed by MU at a given moment. In that case, the wrapper agent should inform to any visitor mobile agent requesting that service that it has been transferred to another community member. It will give the unit network address to the mobile agent. By doing this, it is redirecting mobile agents. Performing services of others members of the database community. A wrapper agent can accept the request of executing services which should not be executed by another member of the community. For example, consider that a mobile computer MUi is processing a query, which requires a large amount of memory in order to store temporary data. Suppose that there is not enough available memory in MUi to store such temporary data. In this case, MUi can ask another mobile computer MUk to provide temporary data storage. The wrapper agent of MUk can accept such a service and start to store temporary data at MUk. Thus, MUk stores data that is not its own neither requested by a local user. Providing local user Interface. Wrapper agents are responsible for providing local user interface at the mobile unit they are running. Therefore, wrapper agents should receive user requests, thereafter they should submit user requests to several database systems of an MDBC as mobile agents and, finally, they have to present the request result to the users. It is worthwhile to mention once more that stationary agents are mandatory at each mobile unit which wants to participate in an MDBC through the AMDB architecture. 4.3 Mobile-Agent Class This class of agents encompasses agents that roam units in an MDBC in order to perform user tasks. This class is compound by the following agents: (i) Runner agents, which carry database access codes; (ii) Loader agents, which bring back query partial results whenever necessary, and; (iii) Broker agents, which provide the necessary support to stationary and mobile agents for performing their functions.
19
XVII Simpósio Brasileiro de Banco de Dados
4.3.1 Runner Agent When a user wants to access (query or update) any database, which is participating in an MDBC, it is created a runner agent with the functionality of making viable that access. As already mentioned, the local wrapper agent creates the runner agent with such a responsibility. Once created, the runner agent migrates to mobile units in the MDBC, in which the data to be accessed are stored. When its task is completed, the runner returns to the unit it has been created, that is, its home. While Runner agent is executing its task, the user can request a varying number of tasks. A runner agent has also the functionality of being a 2PC protocol Coordinator [16,20]. In section 6, we present a discussion about distribute transaction processing in the AMDB architecture. 4.3.2 Loader Agent Loader agents have the functionality of carrying partial query results back to runner agent’s home. This represents an interesting property, since the result of a database access can be too huge with respect to the returned data. Runner agents have the capability of creating loader agents, whenever they recognize that such an action is necessary. 4.3.3 Broker Agent A broker agent is responsible for: (i) reading databases schemas of databases participating in a given MDBC; (ii) seeking and choosing a participant unit to serve as temporary data storage; (iii) seeking and choosing a participant unit to serve as a backup for the 2PC coordinator (in case of distributed transactions), and; (iv) publishing unit service list when a unit joins to an MDBC. When a mobile unit user wants to see the schemas of MDBC-participant databases, the local wrapper agent creates a broker agent which roam unit by unit in order to gather information about such schemas. The broker agent has to interact with each wrapper agent of the mobile units it is visiting, since local schemas are provided by the local wrapper agent. Figure 1 illustrates a broker agent activity. It is important to observe, that when the broker agent returns home, it delivers the schemas it has gathered to the unit’s wrapper agent. The second function of broker agents is to seek and to choose a participant unit to work as temporary data storage. This is necessary when the broker’s origin unit does not have enough storage capacity. In this case, before starting query processing, the runner agent creates a broker agent and delegates to it the task of seeking and choosing another participant unit, which can temporarily store partial results of the query. The broker agent migrates to each network unit and will negotiate with each local wrapper agent. If one of units accepts to play the role of temporary storage unit, the broker agent return to the runner’s unit and passes to the runner the address of the choose unit. The broker agent will finish its task and it will dispose itself. From that point on, the runner agent will send partial results to the selected unit. The third function is executed when distributed transactions have to be processed. In this case, the runner agent creates a broker agent and delegates to it the task for seeking and choosing a unit amongst the MDBC participants which is able to behave as a backup of the 2PC coordinator (backup coordinator). Recall that the runner agent has the functionality of being the 2PC coordinator, when a distributed transaction has to be executed. After the broker agent has been created, it migrates to each mobile unit and negotiates with each local wrapper agent. If one of the units accepts to play the role of backup coordinator, the broker
20
XVII Simpósio Brasileiro de Banco de Dados
agent returns to the runner’s unit and gives to the runner the address of the choose unit. The broker agent finishes its task. Finally, the fourth function of broker agents is performed when a unit joins to an MDBC. When a unit wants to join to an MDBC, its manager agent should make available its services list to all members of the community. The manager agent sends the service list to the local wrapper agent. The wrapper agent, in turn, creates a broker agent and delegates to it the task of sending the unit service list to each MDBC participant. While visiting MDBC members, the broker agent can get the list of each participant. 5. Query Processing In section 4, we have seen that the wrapper agent is responsible for providing local database schema to all MDBC members. In existing database systems, such schemas consist of metadata and statistical data about the database such as, for example, tables’ cardinality, tables’ blocking factor and the height of index structures [20]. Such information is needed for query processing. For that reason, if a mobile unit wishes to participate in an MDBC, it has to send its broker agent to each mobile unit providing its local schema. The broker agent can also gather the local schemas of the visited units. Once the broker agent has returned home, the mobile unit has the necessary information for submitting queries over participant databases. A query can be local or distributed. A local query only involves operations over local database objects. In this case, the local wrapper agent translates the fragment into the native query language of the local DMBS. After that, the query is submitted to the local DBMS by the wrapper agent through the DBMS user interface. A distributed query may involve several mobile databases of an MDBC. Mobile computer users submit distribute queries to the local wrapper agent. The local wrapper agent, detecting a distributed query, creates a runner agent and delegates to it the query processing task. The runner agent receives the query in XQuery format. Therefore, the runner agent implements an XQuery query processor for processing and optimizing queries in the AMDB architecture. The runner agent makes a query optimization based on local database schemas, the number of hosts in which the query should be executed, volume of data at each database and known integrity constraints. It is important to note that query optimization is a global process and the query processing activity is adaptive and dynamic. A distributed query in the AMDB platform is processed in six distinct phases. Initially, the runner-agent’s query processor, after receiving the query in XQuery format, generates a query execution plan (QEP). The generated QEP is represented by an operator tree [2,8], whose nodes represent XML formal semantics algebraic operators (formerly XML query algebra) or data sources. The root represents the final query result. An intermediate node indicates the application of the corresponding operator on the results generated by its children. The edges of a tree represent the data flow from bottom to top, i.e., from the leaves to the root of the operator tree. The nodes have also attributes like data locality, selectivity factor and name of data source. This phase is called Pre-Processing. After the Pre-Processing phase, the runner-agent’s query processor starts performing the Decomposing phase. In this phase, a query is divided into fragments. Each fragment can represent recursively a sub-tree whose locality attribute refers to a mobile unit (in which the query fragment has to be executed). Thus, query-partitioning criterion is based on the data locality principle. After the Decomposing phase, the Context Recognition phase is processed. During this phase, the runner agent’s query processor verifies, for each fragment, whether or not the local DBMS has resources to execute the fragment. If the DBMS does not have support to
21
XVII Simpósio Brasileiro de Banco de Dados
execute the operation, the operation should be executed by the runner agent itself. This execution may be carried out either on the origin unit or on the mobile unit selected as temporary storage unit. In this case, it is necessary a QEP reordering for bringing to highlevel nodes (nodes close to the root) of the QEP the operations, which should be executed by the runner agent. Once Context Recognition phase has been finished, the Clone Generation phase is started. In this phase, the runner agent creates clones (cloning is supported by several agents platforms such as IBM AGLETS). A clone for each query fragment (generated during the Decomposing phase) is created, where each clone is responsible for executing the corresponding fragment. After clones creation, each clone is dispatched (carrying a query fragment) to a mobile unit in order to execute the query fragment. Clone dispatching can be carried out in a parallel fashion and asynchronously. Therefore, at a given moment, more than one clone can be running at a particular mobile unit. The Fragment Execution phase is initiated when a runner agent clone migrates to a mobile unit in which a query fragment should be executed. On arriving at mobile unit, the clone sends to the local wrapper agent with its fragment in XQuery format. The wrapper agent, in turn, translates the fragment into the native query language of the local DMBS. After that, it submits the query to the local DBMS and returns the results back to the clone. Obviously, local DBMSs can optimize the processing of the query fragment it is executing. The last phase is the Post-Processing. This phase is initiated when the clones begin to arrive at the mobile unit, on which they were created. During this phase, the clones give to the runner agent the results of the query fragments. The runner agent, in turn, will start the execution of operations that could not be executed by local DBMSs. In this case, the runner agent performs operations corresponding to the high-level nodes of the operator tree. Once the execution has finished, Runner agent will project the final result to user at origin unit. We want to emphasize the dynamic and adaptive features of the query processing in the AMDB architecture. First of all, it is important to observe the parallel and asynchronous execution of query fragments by mobile agents (runner agent and its clones) in the proposed architecture. Second, higher-level operations in the QEP are executed without the obligation of waiting for the results of all query fragments. This feature reduces the initial (or first-tuple) delay, when executing joins, for example. Third, a generated QEP can be updated on-the-fly, whenever it is necessary. 6. Transaction Processing As already said, mobile users interact with DBS by invoking transactions. There are two types of transactions in an MDBC environment: local transactions and global transactions. A local transaction is submitted directly to a mobile database DB by an application running on the same host on which DB resides. A global transaction consists of database operations which should be executed on different hosts belonging to an MDBC. In our approach, the correctness criterion for the execution of concurrent transactions is serializability. We assume that each mobile database in an MDBC guarantees serializability by the two-phase locking (2PL) protocol. In the AMDB architecture, runner agents are responsible for managing the execution of global transactions. In order to process mobile transactions, the conventional centralized and linear versions of the 2PC protocol [1] were extended. The idea is to consider the mobility property, when processing distributed transactions over several mobile databases. The extension of the centralized 2PC is triggered when a runner agent cloning happens. On the other hand, the extension of the linear 2PC should be used when there is no cloning process.
22
XVII Simpósio Brasileiro de Banco de Dados
Next, we describe how the centralized 2PC has been extended. Consider that a database system DBSi resides on a mobile unit MU, which belongs to an MDBC. Suppose that a MU´s user submits a query Q over several databases of the MDBC. A runner agent R should be created (by the wrapper agent of MU) in order to execute Q. Suppose that the execution of Q is modeled by the distributed transaction T. Thus, the runner agent is responsible for executing T (a distributed transaction). Before starting the execution of T, the runner agent creates an agent whose functionality is to play the role of a backup for the 2PC coordinator process. This is necessary because the runner agent R may visit a mobile unit which can disconnect from the wireless communication infrastructure or exit the mobile database community. In this case, a backup process should assume the coordination of the extended 2PC protocol. The backup for the 2PC coordinator process is created as follows. Before starting the execution of a global transaction, the runner agent creates a broker agent and dispatches it to the MDBC members. The broker should select one of the visited mobile units to be the host of the agent, which has functionality of behaving as a backup for the 2PC coordinator. When the broker agent returns home, it passes the network address of the selected unit to the runner agent. The runner agent creates a clone, passes to it the list of units in which the operations of the global transaction have to be executed, and dispatches the clone to the select unit. This clone will behave as the backup of the 2PC coordinator process. It is important to observe that the creation of that backup reduces the frequency of executing a termination protocol [1]. In the AMDB architecture, the termination protocol has to be triggered, if and only if the 2PC coordinator and its backup are unreachable. After creating the backup for the coordinator process, the runner agent creates n–1 clones. It is important to note that each clone has the network address of the mobile unit which is the host of the backup coordinator. The clones migrate to the hosts on operations of the global transaction should be executed. The runner agent migrates to a mobile unit as well. When the clones return home, they bring the votes corresponding to the second step of the conventional 2PC protocol. They send the votes to the runner agent (the coordinator), if it has already come back. When a ‘no’ vote is detected, the runner agent sends a message to the backup coordinator with the final decision for aborting transaction. After that, the runner agent can use two different strategies concerning to the final decision: to send a message with the final decision of aborting transaction to each non-returned clone or to dispatch once more the clones to each unit already visited with the final decision of aborting transaction. If all of votes were ‘yes’, the runner agent sends a message to the backup coordinator with the final decision for committing the transaction. The clones are dispatched again to the MDBC units with the final decision for committing the transaction. If the runner agent is unreachable (all clones have already returned and have reached their timeout), the backup coordinator assumes the coordination process. In this case the new coordinator decides to abort the transaction. It sends a message to the clones and dispatches them to the transaction-involved units with the decision for aborting transaction. When the runner agent produces no clones, it has to migrate itself to MDBC participants in order to execute the operations of the global transaction. After the runner agent has visited the last unit, it already has the vote of all participants, which have executed operations of the global transaction. If all votes were ‘yes’, it will trip back to the mobile units which have executed operations of the global transaction (on a unit-by-unit basis) with the final decision for committing transaction. If at least one vote was ‘no’, the runner agent stops its trip and comes back to each unit (unit-by-unit basis) it has visited with the final decision for aborting transaction.
23
XVII Simpósio Brasileiro de Banco de Dados
In an MDBC, each mobile unit can exit from community at anytime. Since the 2PC coordinator is mobile (the runner agent), there are two situations, which can induce transaction failure. In the first case, when the runner agent arrives on the last unit it has to visit, the unit may disconnect from network. In this case, the agent is not able to return. Thus, no participant could know the final decision. In the second case, disconnection could happen to any unit during the return path (in which the participants are informed about the final decision) of the runner agent. In this case, some of the participants might know the final decision and others not. In both of cases, the termination protocol should be executed. However, in the first case, we may have the problem of blocked participants [1]. Furthermore, triggering termination protocol induces as side-effect a high network overhead, which undesirable in ad hoc network contexts. To overcome this problem, we propose the use of the mechanism of backup coordinator. The process of defining a backup coordinator for the extension of the linear version of the 2PC protocol is the same as process defined for extension of the centralized version, described above. Next, we describe how the backup coordinator works. At each visited unit, after executing the local part of task and before moving to next one, the runner agent sends the vote to backup coordinator through a message. When the runner agent reaches the last unit, it is able to reach the final decision. Before returning back to the visited units, the runner agent sends the vote and the final decision to the backup coordinator. The propose extension to the Linear 2PC guarantees a network overhead decreasing, while limiting the side-effects, when the coordinator unreachable. 7. Conclusions In this paper, we define the notion of dynamically configurable database communities in mobile computing environments. In order to provide a platform to enables such communities to be formed opportunistically over mobile database hosts in ad hoc configurable environments, an agent-based architecture, denoted Accessing Mobile Databases (AMDB), is proposed. The AMDB architecture is fully distributed and exploits physical mobility of hosts and logical mobility of database queries and their results across mobile hosts. The architecture has interesting properties for coping with database mobility. In particular, x it does not require changes to the underlying database systems, consequently preserving database autonomy; x it keeps global schema information in a distributed manner, and; x it supports opportunistic creation of database communities over a varying number of mobile and autonomous database hosts. For query processing in mobile database communities, the proposed architecture implements a query optimizer that adapts the query plan to the execution scenario of a given query. With respect to transaction processing, the 2PC protocol was extended to take into account the mobility property. However, we are investigating other transaction models less restrictive than serializability-based model [1], as proposed in [3] e [4]. A prototype implementation of this architecture is currently being developed based on IBM AGLETS.
24
XVII Simpósio Brasileiro de Banco de Dados
References [1] P. Bernstein., V. Hadzilacos, and N. Goodman, N. Concurrency Control and Recovery in Database Systems, Addison-Wesley, 1987. [2] L. Bouganim, F. Fabret, C. Mohan and P. Valduriez. “A Dynamic Query Processing Architecture for Data Integration Systems”. IEEE Data Engineering Bulletin. Vol. 23 No. 2. June-2000. [3] A. Brayner, T. Härder and N. Ritter. “Semantic Serializability: A Correctness Criterion for Processing Transactions in Advanced Database Applications”. DATA & KNOWLEDGE ENGINEERING, 31, 1999. [4] A. Brayner and T. Härder. “Global Semantic Serializability: An Approach to Increase Concurrency in Multidatabase Systems”. Cooperative Information Systems - Lecture Notes in Computer Science. 301-315. Springer-Verlag, 2001. [5] M. H. Dunham and V. Kumar. “Impact of Mobility on Transaction Management”. In Proceedings of the International Workshop on Data Engineering for Wireless and Mobile Access, August 1999. pp. 14-21. [6] W. Emerich, C. Mascolo and A. Finkelstein. “Implementing Incremental Code Migration with XML”. Proceedings of the 22nd International Conference on Software Engineering. Limerick, Ireland. 2000. pp. 397-406. [7] J. Holliday, D. Agrawal and A. E. Abbadi. “Planned Disconnections for Mobile Databases”. In Proceedings of the 11th IEEE International Workshop on Database and Expert Systems, 2001. [8] Z. Ives, D. Florescu, M. Friedman, A Levy and D. S. Weld. “An Adaptative Query Execution System for Data Integration”. In Proceedings of ACM SIGMOD International Conference on Management of Data, Philadelphia, USA. 1999. pp. 299-310. [9] A. Kemper and C. Wiesner. “HyperQueries: Dynamic Distributed Query Processing on the Internet”. In Proceedings of 27TH International Conference on Very Large Databases, Roma, Italy. 2001. pp-551-560. [10] D. B. Lange and M. Oshima. “Programming and Deploying Java Mobile Agents with Aglets”. Addison-Wesley. Massachusets, USA. 1998. [11] J. Jing, A. Helal and A. Elmagarmid. “Client-Server Computing in Mobile Environments”, ACM Computing Surveys, Vol. 31, No. 2, pp- 117-157. June 1999. [12] J. P. Macker and M. S. Corson. “Mobile Ad Hoc Networks and the IETF”, Internet Engineering Task Force, MANET Working Group. http://www.ietf.org/html.charter/manet-charter.html. [13] I. Manolescu, D. Florescu, D. Kossman. “Answering XML Queries over Heterogeneous Data Sources”. In Proceedings of 27TH International Conference on Very Large Databases, Roma, Italy. 2001. pp. 241-250. [14] N. C. Mendonça, A. Brayner and J. M. Monteiro. “Mobile Database Communities: An approach for Sharing Autonomous Mobile Database in Ad Hoc Networks”. Submitted for publication. [15] A. L. Murphy, G. P. Pico and G.-C. Roman. “Lime: A Middleware for Physical and Logical Mobility”. Proceedings of the 21st International Conference on Distributed Computing Systems. April 2001. pp. 524-533. [16] M. T. Özsu and P. Valduriez. “Principles of Distributed Database Systems”. Prentice Hall, 1999. 2nd Edition. [17] J. M. Patel. “Query Processing in Mobile Environments”. NFS Wokshop on Context Aware Mobile Database Management (CAMM). January 24-25, 2002, Providence, Rhode Island, USA. http://www.sice.umkc.edu/nsfmobile/wshop.html/JigneshMPatel.pdf.
25
XVII Simpósio Brasileiro de Banco de Dados
[18] S. H. Phatak, and B. R. Badrinath. “An Architecture for Mobile Databases”. Technical Report #DCS-TR-351. Rutgers University, Department of Computer Science. ftp://www.cs.rutgers.edu/pub/technical-reports/dcs-tr-351.ps.Z. [19] G.-C. Roman, G. P. Pico and A. L. Murphy. “Software Engineering for Mobility: A Roadmap”. In A. C. W. Finkelstein, editor, Future of Software Engineering. ACM Press, 2000. [20] A. Silberschatz, H. F. Korth and S. Sudarshan. “Database System Concepts”. McGraw Hill, 1998. 3rd Edition. ISBN 0070310866. [21] M. Singhal. “Techniques for Building Large Relational Databases on Mobile Computing Systems”. NFS Wokshop on Context Aware Mobile Database Management (CAMM). January 24-25, 2002. Providence, Rhode Island, USA. http://www.sice.umkc.edu/nsfmobile/wshop.html/MukeshSinghal.pdf . [22] R. Vlach, J. Lána, J. Marek and D. Navarra. “MDBAS – A Prototype of a Multidatabase Management System Based on Mobile Agents”. Proceedings of the 27th Annual Conference on Current Trends in Theory and Practice of Informatics (SOFSEM), Springer-Verlag, Nov. 25 - Dec. 2, 2000. Milovy, Czech Republic. [23] XML Schema. http://www.w3.org/XML/Schema. [24] XQuery 1.0 Formal Semantics. http://www.w3.org/TR/query-semantics/ .
26
