In 2001-2, we developed the Mobiscope service discovery system for mobile network resources. Mobiscope is a discovery service where clients submit long-running queries to continually find sets of moving network resources within a specified area. As in moving object databases (MODBMSs), moving resources advertise their positions as functions over time. When Mobiscope receives a query, it runs the query statically against advertisements (ads) that are currently cached by Mobiscope, and then continuously over ads that Mobiscope receives subsequently. For scalability, Mobiscope distributes the workload to multiple nodes by spatial coordinates. Application-level routing protocols based on geography ensure that all queries find all matching resources on any node without significant processing overhead. Simulation results indicate that Mobiscope scales well, even under workloads that stress Mobiscope's distribution model.
The current Mobiscope design only allows queries that find moving objects within a given region. We are currently extending our design to support temporal operators in the Mobiscope query language in order to support more complex queries.
1IBM T.J. Watson Research Center
2IBM T.J. Watson Research Center
TinyDB is a query processing system for extracting information from a network of TinyOS sensors. Unlike existing solutions for data processing in TinyOS, TinyDB does not require users to write embedded C code for sensors. Instead, TinyDB provides a simple SQL-like interface to specify the data you want to extract, along with additional parameters, such as the rate at which data should be refreshed--much as one would pose queries against a traditional database. Given a query specifying data interests, TinyDB collects that data from motes in the environment, filters it, aggregates it together, and routes it out to a PC. TinyDB does this via power-efficient in-network processing algorithms.
XML is emerging as the common wire format for data. As a result, there recently have been significant advances in XML filtering. To date, solutions have focused on identifying the queries that match incoming documents, and possibly identifying the specific matching elements within such documents. These solutions have not, however, addressed the additional processing required to support the customization of output needed in many emerging scenarios, such as application integration, web services, and personalized information delivery. This customization can significantly increase the complexity of the matching process.
We have developed a system that leverages an efficient, shared, path matching engine to extract the specific document components needed to generate customized output for large numbers of filtering queries. We compared three different ways of exploiting the shared path matching engine for this purpose. We also proposed techniques to optimize the processing of output from the engine, and to enable the sharing of such processing across all matched queries. The effectiveness of these techniques were evaluated through a detailed performance study of our implementation.