pabilities 1]. Current implementation of the 800 number service consists of a switching system, a database of the 800 number records, a network management ...
Network Services Database - A Distributed Active Real-Time y Database (DARTDB) Application Rajendran M. Sivasankaran, Bhaskar Purimetla, John A. Stankovic, & Krithi Ramamritham Department of Computer Science University of Massachusetts Amherst, MA 01003 1 Introduction
A methodical study of real-time database applications can help us identify the important research issues in real-time databases. In [4] a number of real-time database issues are discussed. In this paper, we discuss the data and transaction characteristics of a telephone network services database in an attempt to study realtime database issues in the context of an application and to identify new research issues. Network services databases are soft/ rm real-time systems and provide support for the service-providing intelligent network (IN). The IN provides services like dialed number services (800 service), personal mobility service, virtual business group service, and televoting. The data and the service logic1 in this system are distributed. We will also present a brief explanation of the distributed active real-time database simulator that we are building for the purpose of experimenting with issues that arise in applications such as the Network Services Database. 2 Network Services Database
The telecommunication industry plans to provide numerous services like the 800 number service and personal mobility service. They require a robust, evolvable Intelligent Network (IN) architecture to serve as the backbone of such services. The features for IN that they desire are service independent architecture, exible distribution of service logic and service supporting functions, user friendly and exible service creation functions, open architecture with a set of standard interfaces, compatibility with existing networks, selfThis work was supported in part by NSF under grants IRI-9114197 and IRI-9208920. y A report on the recent NATO Advanced Study Institute on Real-Time Computing identi ed an important missing ingredient in much of today's real-time research, i.e., we must take into account real needs of applications in developing appropriate solutions. This paper addresses this issue with respect to real-time databases. 1 Code to process the service.
awareness, and self-adapting and self-provisioning capabilities [1]. Current implementation of the 800 number service consists of a switching system, a database of the 800 number records, a network management and engineering system, and an interactive operations management system. The underlying network connecting these systems is the Common Channeling System (CCS) network that uses the Signaling System #7 (SS7) protocol. When an 800 number is dialed, the call is routed to a switch that launches a query via the CCS network which routes it to the database. The network management and engineering system is responsible for trac control, ecient routing of queries, and faulttolerance, and the operations management system is responsible for accounting and other operations support functions. In the future, service processing in the IN is expected to be more complicated and demanding than the 800 number call processing. When a request for service is sensed at a call processing node2 , depending on the request, the node could process the request locally, or transfer it to another node, or get the service processing logic from an appropriate node. Once a node starts to process a service it may have to read/write data from/to approporiate databases or transfer processing to another node to complete the service. After the completion of service the account information is updated. We need a exible distribution of service processing logic, service related data and accounts data. The network must be self-adapting and fault-tolerant. So, whenever a node queries a database, or transfers processing or routes a query it will have to look at the network request (or query) trac3 and con guration so that it can query the In the 800 service network, a call is rst processed at Service Switching Points (SSP) which are electronic switches that contain the service logic required to send queries to the centralized database. We will use the term node to indicate any entity on the service network that is involved in call processing. 3 When we mention trac and routing we do not mean 2
database that will take the least time to respond, or transfer processing or route the query to the node that will take the least time to respond. It should be noted that the trac and con guration data could reside in a database from where the nodes could obtain them.
2.1 Data Characteristics
The di erent data entities that are in the IN are service logic, customer service records, account records, operations support data and Network Trac Management (NTM) data. All these data are distributed and are subject to concurrent accesses. Data such as the service logic is mostly read-only and is subject to infrequent updates. There is read/write data like the customer record base and account information base. The most dynamic of all this data is the NTM data which provides the ability for real-time monitoring of the network contributing to the self-adapting and fault-tolerant requirements. NTM data has to be temporally consistent, i.e., there is a need to maintain consistency between the actual state of the network and the NTM data. The notions of absolute consistency and relative consistency [4] are applicable to NTM data. The sampled data of the real world (NTM data) should not lag behind the actual data of the real world (network trac) by more than a speci ed time. This speci ed time is the absolute validity interval (avi). The NTM data used to derive other data should not di er from each other by more than the relative validity interval (rvi). Any data item d is in a correct state if and only if it is logically consistent and temporally consistent (absolutely and relatively). The dynamic data that is used for real-time monitoring is temporal. Failure of a transaction that updates such data may not require conventional rollback and recovery protocols because the next transaction that updates this data will restore it to a consistent value. The best way to recover is to trigger a transaction to sense the value again in such a way that the logical and the temporal consistency of the data item is not violated. Non-dynamic data such as the service logic, customer records, and accounts information do not have temporal consistency requirements. It is possible in the case of account information to relax the isolation4 property of the accessing transactions, for instance, the network layer level packet trac and routing, but the service level query trac and routing. 4 Isolation of the Atomicity, Consistency, Isolation and Durability (ACID) properties of transactions.
using epsilon serializability5 to give approximate account information.
2.2 Transaction Characteristics
Transactions can be broadly classi ed as aperiodic or periodic; hard, soft or rm real-time depending on how critical they are; and, read-only, read-write and write-only on the basis of data access type. This application includes all of the above mentioned types of transactions except for hard real-time transactions. Examples of periodic transactions include the ones responsible for obtaining the trac data, and those responsible for generating bills. Let us brie y look at the transaction that obtains the NTM data for real-time surveillance. The avis of the NTM data require these transactions to be executed with a periodicity that will maintain the temporal consistency. These transactions have soft deadlines, because failure to meet the deadline will not be catastrophic and obtaining the trac data after expiration of deadline might be useful for later routing of requests. There are other transactions such as the monthly billing and accounting that are periodic and have soft deadlines. The transactions that are executed to process a service call are aperiodic in nature. All the transactions that are part of this larger call processing transaction are aperiodic. The call processing transactions have rm deadlines because they impart no value to the system once their deadlines expire. The transaction that queries the database about the loads which is a subtransaction of a call processing transaction is monotonic in nature. It is advantageous to know the load about as many nodes as possible for optimal routing of requests. The quality of the response increases with the fraction of the transaction completed. In such transactions we can relax the atomicity property. Partial completion of such transactions is not totally undesirable. The transactions that are part of a call processing transaction have soft deadlines. It might still be possible to complete a call after missing a deadline of one of the many queries processed as part of the call. It does not make sense to give up and respond with a failure message to a caller just because a query to obtain the service logic is delayed. There are other aperiodic transactions such as the ones executed to process a call for information on accounts. As mentioned earlier, in these transactions it is possible to relax the isolation property, if the customers are satis ed with approximate information. Even in 5 Epsilon Serializability is a weaker form of consistency criterion that allows transactions to view inconsistent data in a controlled way thus providing more concurrency.
transactions that query the trac data (part of call processing) approximate information might be sucient thus permitting the relaxation of their isolation property. There are di erent kinds of transactions with varying access patterns (read-only, read-write and writeonly). The transaction that reads the network con guration for ecient routing of service query is a read-only transaction. Report generating transactions are read-only. The transaction that does accounting is an example of a read-write transaction. It should be noted that the application is conducive to the usage of the Event-Condition-Action6 (ECA) paradigm from active databases [3]. We can set triggers to update routing data when the trac load reaches a minimum or a maximum value. A service request may be forwarded to di erent nodes depending on the time of the day. The physical address of the node to which a request is forwarded will change depending on the time of the day. We can set triggers to update the address translation database when the time of the day is a certain value. We can trigger transactions to do the billing when certain events occur. For instance, we can trigger transactions at the end of the month to calculate the monthly bill. 3 Research Issues In this section we outline the real-time database research issues that arises in application such as the Network Services Database application. There is also a brief explanation of the distributed active real-time database simulator that is being built.
3.1 Incorporation of Time in the Active Database Model
Derivation of Priority and Deadline of Triggered Actions: Numerous interesting questions arise when we try to assign deadlines and priorities to actions triggered by a transaction. For instance, when the trac reaches a particular level we can trigger actions to update the routing table. The problem of assigning priority and deadline to this transaction is nontrivial. The assignment strategy will have a signi cant impact on the performance of the system as the triggered actions will contend with ongoing transactions for both data as well as CPU and I/O resources. An action can be
The Semantics of the ECA rule is that if the speci ed event (E) occurs and if the condition (C) is true then execute the speci ed action (A). 6
a subtransaction or an independent transaction depending on the type of coupling mode chosen [3]. Hence we may have to consider the coupling mode in the assignment of priorities and deadlines of the actions. Moreover, rules can have deadlines speci ed for their actions when a constraint has to be restored within a certain time from the point where the constraint has been violated. This explicit deadline speci ed for the action has to be considered in the assignment. Preanalysis of Transaction for Triggers The actions triggered by a transaction makes its execution time unpredictable if immediate or deferred coupling modes are used. It may be possible to preanalyze a transaction to determine the potential rules it can trigger and if it can nish before the deadline and if it can, assign an appropriate priority so that it can nish by its deadline. Under normal circumstances, i.e., when the transaction doesn't trigger any rules, the transaction may nish before its deadline with a low priority. But due to increased execution time (because of rule triggering) it may be unable to nish before the deadline with a lower priority. We can design a transaction model where potential rules that are triggered can be speci ed. This information can be used to assign a transaction a higher priority than usual so that it can meet its deadline.
3.2 Recovery
Recovery is a complex, unexplored issue in the context of real-time databases and has great impact on the predictability of the system. For instance, in the undo/redo recovery model, undoing the e ects of a transaction consumes resources that can interfere with ongoing transactions. Hence RTDB recovery must consider resource availability to determine the most opportune time to do recovery. Moreover we can exploit data characteristics to simplify recovery and minimize overheads. Given an application, we might be able to classify its data depending on their recovery and their permanence properties and develop appropriate recovery protocols. For instance in the IN, data for real-time monitoring need not be permanent. An aborted transaction that updates this data can recover by just updating the value again. If a transaction that is updating the routing table fails and the updating is monotonic (i.e., accuracy of data increases with the fraction of update done), then we may not need to undo the e ects, but just use the data and let the next updating transaction update it to the correct value
or run a compensating transaction that reconciles the values later when there is less load on the system (opportune moment).
3.3 Semantic Concurrency Control Protocols Operation semantics such as commutativity and recoverability have been proposed to enhance concurrency. The notion of temporal consistency has not been considered in the design of semantics based concurrency control protocols. We should investigate if it is possible for concurrency control protocols to exploit the temporal semantics of data to achieve more concurrency.
3.4 New Execution Model for Transactions
Prerunning a transaction to determine its feasibility is a new execution model that improves the predictability of the system. We can evaluate whether the savings in recovery costs and execution time obtained by this model, by avoiding running infeasible transactions and later aborting them, balances the overhead of prerunning the transaction. If we prerun a transaction that queries an 800 number and determine that we might not be able to complete before the soft deadline we can execute alternate transactions that tell the user that there is too much load on the system.
3.5 Miscellaneous
There are various other research issues that have to be looked at such as the trading o quality of response for timeliness. We can compromise on the completeness of transactions, accuracy of results, consistency of the data and currency of the data to gain timeliness. Another issue of interest is the performance of time cognizant CPU scheduling and CC protocols in a distributed setting. Most of the studies until now have been done in single site systems.
3.6 DARTDB Simulator
We are building a distributed active real-time database simulator to aid us in studying these research issues. The data is modeled as having certain number of object classes and each object class having certain number of instances. We model the objects as multilevel objects, but for now restrict the number of levels to two. The simulator consists of ve modules. The transaction generator simulates the application or the environment in which the database operates. We can model the transaction characteristics of the application we want to study as closely as possible. The transaction manager schedules and executes the transactions by forwarding the requests to the object
manager. It informs the rule manager of the various transaction events like start, commit and abort. The object manager executes the methods of the objects in the system as requested. It handles concurrency control. It informs the rule manager of the various object events. The rule manager is responsible for detecting which rules are triggered when transaction, object or temporal events occur. It then requests the transaction manager for the condition and action execution if necessary. Three coupling modes, i.e, immediate, deferred and independent are supported between the external transaction and condition, and between the condition and the action. The resource manager simulates the CPUs and disks and main memory. Both the transaction manager and the object manager request the resource manager to ful ll their computation and data needs. 4 Conclusion In this paper we discussed the network services database, a soft/ rm real-time system that contains rich data and transaction semantics which can be exploited to design better protocols for concurrency control, recovery, and scheduling. We identi ed a number of research issues that have to be resolved to develop such a complex system and brie y described the distributed active real-time database simulator on which we intend to conduct our experiments. References
[1] AT&T Technical Journal, \Intelligent Networking: Network Systems," Volume 70, Summer 1991. [2] B. Purimetla, R. Sivasankaran, J. Stankovic, and K. Ramamritham, \A Study of Distributed Realtime Active Database Applications," Technical Report 93-10, Jan 93, Department of Computer Science, University of Massachusetts, Amherst. [3] U. Dayal et. al., \The HIPAC Project: Combining Active Databases and Timing Constraints," SIGMOD Record, 17, 1, March 1988. [4] K. Ramamritham, \Real-Time Databases," International Journal of Distributed and Parallel Databases, 1993.
