Design and Implementation of Scenario-based Collaborative Framework: XCREAM

Kyungeun Park, Jekuk Yun, Yanggon Kim Department of Computer & Information Science

Towson University Towson, U.S.A.

{kpark3, jyun4, ykim}@towson.edu

Juno Chang Div. of Media Technology

Sangmyung University Seoul, Republic of Korea

jchang@smu.ac.kr

Abstract—The XCREAM (XLogic Collaborative RFID/USN-Enabled Adaptive Middleware), as a mediator between smart physical objects and collaborative cyber services, gathers massive events from a variety of event origins and distributes them to the appropriate service parties depending on the predefined business scenarios. Demand for collaboration among numerous business applications draws attention to this kind of middleware platform especially in the highly networked environment. The XCREAM platform, the scenario-based collaborative framework, integrates various kinds of RFID/USN-enabled application services and provides more advanced collaborative services than the individual services. The goal of this research is to construct well-organized systematic RFID/USN prototyping framework, to which physical RFID readers or sensor devices are interfaced through their own middlewares. Additionally, tag data and sensor signals from the devices are propagated to the associated services registered to the framework. The study encourages us to develop the XCREAM platform and build prototyping environment for presenting further comprehensive services. This approach makes it possible to integrate many heterogeneous services and to present collaborative service framework.

Keywords-XCREAM (XLogic Collaborative RFID/USN-Enabled Adaptive Middleware); RFID (Radio Frequency Identification); USN (Universal Sensor Network); Collaboration

I. INTRODUCTION

Rapid progress in wireless network communication technologies and demand for application of the technologies in the real life accelerate the development of ubiquitous computing environment with various application services. Moreover, interests in making organic connections or integration of each individual application services have been increasing greatly.

In order to provide complex services of interconnected applications in RFID/USN environment, a seamlessly orchestrating framework which collects a large amount of sensor data from many data sources and delivers real-time data according to a predefined scenario for each service is necessary. As a solution for this requirement, a scenario-based collaborative framework is considered among heterogeneous service systems in RFID/USN environment and implemented with the basic philosophy of providing fast and easy adoption of a variable pervasive computing power.

To satisfy the growing needs, a robust and reliable infrastructure is required to handle a huge amount of tag and sensor data, and propagate the data to the appropriate services according to predefined scenarios. This requirement encourages us to develop a scenario-based collaborative framework, the XCREAM (XLogic Collaborative RFID/USN-Enabled Adaptive Middleware) framework, which seamlessly integrates highly sophisticated services, plays an organizing role in ultimate ubiquitous computing environment, and maximizes the collaboration between the services [18], [19].

For example, various services such as emergency rescue system, facility management system, and supply chain management system can not only provide their own services, but also perform more advanced collaborative services by combining them with the other applications based on the XCREAM framework.

The XCREAM is placed between RFID/USN middlewares, generally composed of RFID or sensor middlewares, and application services as in Fig. 1. The XCREAM framework collects the ECReports from RFID/USN middlewares [25] and interprets and delivers them to the corresponding user-defined business application services in order to establish an integrated cooperative working environment.

Figure 1. The XCREAM Framework Configuration

978-1-4244-5943-8/10/$26.00 ©2010 IEEE

The highly sophisticated services, which are triggered by a specific event from a variety of sensors or other services according to a pre-defined scenario, result from the seamless integration between many service systems. The framework introduced XML infrastructure language, called the “XLogic (eXtensible Logic)”, which makes the applications communicate with the XCREAM by registering XLogic scripts. The XLogic script contains specific service scenario depending on the events of automatic identification or remote measurement data from the separate RFID/USN middlewares.

The XCREAM adopts the service-oriented architecture (SOA) as an interface scheme to RFID/USN-enabled application services, not only to guarantee independence of individual services, but also to gain flexibility when extending the framework infrastructure by enabling new collaborative services to work with the XCREAM or other application services. The SOA makes it possible to increase the reusability of the business services. Easily applicable service functionalities through the SOA also provide the foundation for stable provision of composite services. The additional advantage of using the SOA consists in retaining loose coupling of the service building blocks across the whole service framework. The other important reason why the XCREAM adopts the SOA technology is that it allows a business application to request any services, which are exposed to others with SOA interfaces, regardless of the service platform environment. Moreover, the SOA has been focused as a flexible integration technology in parallel with the demands for the fast development of RFID/USN-enabled system as well as the sharp increase of the numerous device-oriented services [5]–[7].

The XCREAM is based on the event-driven architecture (EDA), which is completely decoupled from the conventional RFID/USN middlewares. This scheme enables the XCREAM to work independently with a specific RFID/USN middleware and execute scenarios only when the relevant events from the RFID/USN middleware are recognized. Based on the SOA scheme, the XCREAM exposes customized web services as the method of establishing connections with heterogeneous external systems. The XCREAM is written in Java programming language.

This paper is composed of 6 chapters in total. Chapters 1 and 2 present the introduction and the related research. Chapter 3 describes the overall architecture and the internal execution mechanism of the XCREAM framework in detail. In chapter 4, the prototype system based on the XCREAM framework, the Sports Complex Management System (SCMS) is presented. The results of the performance tests are summarized in chapter 5. The Chapter 6 discusses the application areas, and chapter 7 concludes with the future research direction.

II. RELATED RESEARCH

There have been many researches related to the proposed system: RFID-enabled auto-identification technology for the data collection and recognition of the front-end component of the framework; continuous event and query processing technology for the massive events stream; and USN

middleware technology, which many similar systems adopted in the fields [6], [7].

In conjunction with handling RFID tag data, a lot of research efforts have been made during the past decade to define the RFID tag specification. Research has also been made to formalize the protocols required for seamless communication between related components and to enhance the performance and correctness of the system itself.

Initially, RFID-enabled network infrastructure was proposed by the Auto-ID Center [20]. Their research goal is to realize ubiquitous automated identification technologies based on the networked physical world [6]. They have developed an open architecture system which is composed of the EPC, EPC tags and readers, local networking technology, and RFID middleware [24], [25]. Local networking technology allows readers and sensors to be connected via local databases. RFID middleware collects and filters massive tag data, aggregates and processes them into meaningful information, and delivers them to the pertinent applications. The middleware may use the Object Name Service (ONS) similar to the Domain Name Service (DNS) in the Internet for location lookups of specific items [5].

A variety of automatic identification devices under highly-networked environment generate a huge amount of events streams. This means that a new querying scheme is required to recognize the arrival of the corresponding events and to evaluate the corresponding queries. In order to do so, users need to issue a continuous query (CQ) which is invoked once and run continuously over the events streams and database, and notified whenever the data matches the query [21]. The continuous query processing system must be capable of monitoring the incoming events that occur during certain predefined time intervals and generate new results when they become available [3], [4]. Moreover, the event queries are distinguished from the traditional queries that carry over the relations by many researchers who analyze the events and the nature of the event queries [1], [2], [14], [16], [23]. The XCREAM interprets the XLogic script, which contains a query request, into a Java runnable object, transforming the written script to the executable form. The runnable objects are activated by a specific event as in the event driven systems.

Many data stream management systems (DSMS), such as TelegraphCQ [3]; NiagaraCQ [4]; STREAM [27] and OpenCQ [12], have been developed as solutions to handle multiple continuous, high-volume, and possible time-varying data streams. The TelegraphCQ adopts an adaptive query engine to process queries efficiently in volatile and unpredictable environments. The NiagaraCQ keeps scalability by grouping CQs. The STREAM maintains adaptive and dynamic central scheduler of query operators over shared stream queue which holds high-volume and bursty traffic of data. The OpenCQ focuses on a query processing algorithm based on the incremental view maintenance [2].

These systems are primarily focusing on CQ optimization by allowing traditional DBMS, or their own data stream management system, to support CQs over data streams and conventional relations. The XCREAM supports CQs over time-varying RFID tags or sensor data in trigger mode and

attempts to enhance the performance by caching the runnable objects of the XLogic scripts correspondent to them.

The requirements of the early USN middleware were comparatively simple due to the direct connection to a specific application service. As various kinds of ubiquitous computing applications, such as u-Healthcare, u-Transportation, u-911, and u-Eco, are rapidly introduced to our day to day life, it is expected that the increase of the information sharing from variable RFID/USN data sources will stimulate the development of the composite services [8]–[10]. Several middleware researches are having conducted on the following examples: MiLAN middleware [7], developed to guarantee QoS (Quality of Service) as its top priority; event-based DSWare middleware [11] , which sends desired data to USN application systems by setting events on continuous stream of sensor data obtained, similar to RFID middleware; Impala middleware [11], [13], which can dynamically change functions of sensor node middleware according to changes in USN application services and changes in the surrounding environment of sensor networks through wireless communication; TinyDB middleware [15] and Cougar middleware [22], which carries out requirements of USN application system using distributed processing by considering sensor data from the sensor network as distributed data of distributed database.

In COSMOS (COmmon System for Middleware Of Sensor network), developed by ETRI, key functions of middleware, jointly needed for various types of USN application services, were extracted, and technology development and standardization to provide these in a standardized way were carried out. The main functions of COSMOS are as follows: query support (temporary, permanent, and event); support for simultaneous processing of a large amount of queries for large-capacity sensor network environments; and support for abstraction of heterogeneous sensor networks [17].

Oracle Complex Event Processing (Oracle CEP) combined with distributed caching publishes output events to a replicated, distributed cache thereby making the results of its computation highly available. Distributed caching technology can also

Figure 2. The XCREAM Framework Interface Layer

increase the performance and scalability of Oracle CEP applications [26]. The XCREAM supports caching mechanism of the runnable objects of the XLogic Scripts. And incoming events are transmitted to the Proxy Agent enforcing the runnable object of the associated scenario to be executed.

III. THE XCREAM FRAMEWORK

The XCREAM provides a scenario-based adaptive service framework, which seamlessly integrates various application services in the RFID/USN environment. Within the XCREAM, the Agent Manager plays a bridge role between the various application services and the individual RFID/USN middlewares. The Agent Manager maintains the runnable objects of the XLogic scripts, which invoke the corresponding web services of the application services. Upper-level application services are to collaborate with each other, through the Agent Manager, which allows pre-registered scripts to be executed depending on the event data collected by the RFID/USN middlewares. The XLogic scripts describe specific service scenarios and interact with the XCREAM framework. Each agent may exchange event data, under the supervision of the XCREAM Enterprise Manager of the Agent Manager. Their associated relationships are shown in Fig 2.

A. The XCREAM Framework Components The XCREAM framework is composed of the following

agents such as the Subscriber Agent, the Proxy Agent, the Instance Managing Agent, and the Was Agent as well as the Agent Manager as in Fig.3.

• The Agent Manager

The Agent Manager is in charge of managing the remaining four agents and delivering every event received from each agent to the appropriate parties. Internal events just pass through the Agent Manager. The Agent Manager propagates events to the whole agents registered to it, and the other agents accept only events that are of interest for further processing and ignore the other events.

Figure 3. The XCREAM Components

Application Services based on Web ServiceApplication Services based on Web ServiceApplication Services based on Web Service

RFID/USN MiddlewaresRFID/USN RFID/USN MiddlewaresMiddlewares

XLogicXLogicScriptsScripts

RepositoryRepository

XCREAM Enterprise ManagerXCREAM Enterprise ManagerXCREAM Enterprise Manager

XLogicXLogicScenario 1Scenario 1

XCREAM Agent ManagerXCREAM Agent Manager

XLogicXLogicScenario 2Scenario 2

XLogicXLogicScenario 3Scenario 3

App. Service 1App. Service 1 App. Service 2App. Service 2 App. Service 3App. Service 3 App. Service 4App. Service 4

RFID/USNRFID/USNMiddleware 1 Middleware 1

RFID/USNRFID/USNMiddleware 2Middleware 2

RFID/USNRFID/USNMiddleware 3Middleware 3

RFID/USNRFID/USNMiddleware 4Middleware 4

• The Subscriber Agent

Events originated from RFID/USN middlewares are collected by asking the XCREAM for the following queries: a snapshot query with which a RFID/USN middleware requests immediate real-time identification or sensor data and a continuous query that is kept in active state and used to continuously request the data during the specified period.

The Subscriber Agent is connected to various RFID/USN middlewares through multi-threaded socket connections on the pre-allocated port and is in charge of forwarding the identification or sensor data to the Agent Manager after converting them to the corresponding Java objects, called “ReportsArrivedEvent.”

• The Proxy Agent

The Proxy Agent is responsible for shortening the overall-event processing time. An XLogic script, which has been executed, is in memory as an executable Java object rather than the XML script itself saved in the repository. This buffering scheme remarkably reduces parsing time compared to the fetch-and-execution scheme from the repository and makes it possible to effectively manage the system resources throughout the whole lifetime of the XLogic script related with a specific service scenario.

The Proxy Agent usually extracts the unique identification information of “ReportsArrivedEvent,” which is forwarded by the Agent Manager. If the value equals to one of the XLogic script resident in memory, the XLogic is converted into “XLogicScriptExecuteRequestEvent” and sent back to the Agent Manager. If it is not found in memory, XLogic in the XML form is queried and then parsed to be placed in memory as an executable Java object. Accordingly, the event is delivered to the Agent Manager as the above.

• The Instance Managing Agent

The Instance Managing Agent not only executes the XLogic script but also keeps the statistics of the active XLogic such as the success and failure ratio, the last completion time, and the current status. This information is presented online in real-time through a web interface, the Enterprise Manager (hereafter known as the EM), and helps the user establish an execution strategy based on the acquired statistical data.

• The WAS Agent

The WAS Agent exposes the useful functions to the outside by providing users with web services, and acts as the web server of the EM.

B. XLogic Execution Modes Incoming events from data sources are processed in two

modes within the framework: a trigger mode in which a received event will activate a pre-registered XLogic script and an immediate mode in which an XLogic script is converted into a Java object and executed immediately as soon as the script has been registered to the XCREAM.

• Trigger Mode

An XLogic script, which is defined as trigger mode, is executed when the external event is collected by the XCREAM according to the flow of event depicted in Fig. 4.

When an event is collected from the Subscriber Agent, the “ReportsArrivedEvent” is sent to the Agent Manager. The Agent Manager forwards it to the every agent registered to it. The Proxy Agent that is responsible for processing the “ReportsArrivedEvent” adds statistical data and sends the ”XLogicScriptExecuteRequestEvent” back to the Agent Manager when it finds the related XLogic resident in memory. The Agent Manager sends the converted event to all the agents again, and finally, the Instance Managing Agent that is capable of processing the “XLogicScriptExecuteRequestEvent” executes the XLogic script.

• Immediate Mode

It refers to the mode in which an XLogic script written by a user is executed immediately. If a user writes and executes an XLogic in EM, it is sent to the Instance Managing Agent through the WAS Agent and then the XLogic script written in the XML form is transformed into a Java object and then the Java object is executed as shown in Fig. 5.

Figure 4. The XLogic Trigger Mode Execution

Figure 5. The XLogic Immediate Mode Execution

C. XLogic Script Language The initial motivation of the development of the XCREAM

was the construction of the collaboration framework for the various kinds of information systems used in many independent sites as well as the newly introduced RFID/USN-enabled application services. As the solution to a completely seamless interfacing scheme, the research team designed an XML based infrastructure interface scheme, the XLogic script language. The external systems just need to register XLogic scripts of the service scenarios to the repository, which correspond to the RFID identification or the USN sensor data through the Enterprise Manager of the XCREAM framework.

The XLogic script language follows the XML-based scheme and provides the application services with the following statements in the form of the XML tags:

• set statement

• wait statement

• print statement

• if statement

• while statement

• foreach statement

• invokeWebService statement

• break statement

• continue statement

The following is a sample XLogic script, which registers a service called “PlayerInfoService” with the final destination of the tag data to be sent to the specified URL.

<?xml version="1.0" encoding="UTF-8"?>

<xlogic:XLogicScriptxmlns:xlogic="urn:spoon:xlogic:script:xsd:1"xmlns:xsi=http://www.w3.org/2001/XMLSchema-instancexsi:schemaLocation="urn:spoon:xlogic:script:xsd:1">

<xlogic:set name="tags" select="//tag"> ${_REPORTS}</xlogic:set>

<xlogic:invokeWebServiceservice="TagPrintWebService"port="TagPrintWebServiceHttpPort"url="http://10.55.17.78:8000/gym/services/TagPrintWebService"name="result">

<tagPrintxmlns="http://tagprint.webservice.spoon.org">

<ArrayOfString><string>${reader}</string><xlogic:iterator name="tag"

source="tags"><string>${tag}</string></xlogic:iterator></ArrayOfString>

</tagPrint>

</xlogic:invokeWebService>

</xlogic:XLogicScript>

IV. THE SPORTS COMPLEX MANAGEMENT SYSTEM

As a prototype system based on the XCREAM, we have constructed the Sports Complex Management System (SCMS), which is composed of the Registration System (RS), the Restaurant Management System (RMS), the Gym Management System (GMS), and the Athlete Management System (AMS) as shown in Fig 6. Those applications not only operate independently, but they also collaborate with each other by sharing events through the XCREAM framework within RFID/USN environment.

The SCMS is to provide athletes with a convenient and efficient environment based on the RFID/USN technology. The individual services communicate with each other by receiving the athletes’ tag identification information from the XCREAM. For example, the GMS identifies an athlete’s SSN, name, height, dates when the athlete enters into a gym and calculates the calorie consumption of the athlete. In addition, the RMS notifies the cost of a meal to the related AMS. The history records of athletes are saved into a specific database so that the athletes can keep track of what they have done so far.

This prototype system shows that the XCREAM works as a collaboration framework across the individual application systems with the useful XLogic script language and the flexible interface scheme based on SOA.

Fig. 7 and Fig. 8 are the shortcut of the SCMS user interfaces, which shows the room availability when the athletes check in and the XCREAM Enterprise Manager manipulating the XLogic scripts.

Figure 6. The SCMS Configuration

AMS

RMS

RS

GMS

Figure 7. The SCMS User Interface of the RS

Figure 8. The XCREAM Framework Enterprise Manager

Figure 9. The XCREAM Performace Testbed

V. THE XCREAM PERFORMANCE TESTS

In order to measure the performance of the XCREAM framework, a performance testbed shown in Fig. 9 was built, which is composed of the reader-simulator, the XCREAM, and a performance monitor. The first performance test set measured the time to convert the XLogic scripts in XML form into a Java object in immediate mode. For this test, multiple set of XLogic scripts requesting numerous tag data are adopted.

The measurement has been accomplished by calculating the elapsed time between the start and end point of a parsing process. In order to obtain the average elapsed parsing time, each XLogic script has been parsed 20 times. The following table shows the results of the performance test, the average parsing time depending on the number of statements of the XLogic scripts.

The test result shows that the XCREAM framework spends linearly increasing time to parse the variable set of XLogic scripts depending on the number of statements contained in the scripts.

TABLE I. THE AVERAGE PARSING TIME DEPENDING ON THE NUMBER OF STATEMENTS OF THE XLOGIC SCRIPTS

No. of Statements of XLogic (lines)

Avg. Parsing Time (ms)

100 0.47 200 0.68 300 0.90 400 1.13 500 1.39 600 1.65 700 1.95 800 2.16 900 2.44

1,000 2.61

Figure 10. The Curve of the Average Parsing Time

XCREAM Framework Enterprise ManagerXCREAM Framework Enterprise Manager

The next simulation is to show the robustness of the system by taking time durations to process a number of events as shown in Table II. In the testbed, an XLogic script registered by a specific application service in trigger mode recognizes a RFID tag event and delivers it to the application service.

On reviewing the test result, a single XCREAM executable handles 100 events per one second. This encourages us to deploy multiple volume of the XCREAM and makes it possible to achieve performance improvement in the real world, even for the massive events streams.

In addition, the research team is building convincing test models, which show the benefits of the collaboration across the autonomous RFID/USN-enabled services.

TABLE II. SCRIPT PROCESSING TIME ON VARYING EVENTS IN TRIGGER MODE

No. of Events from the RFID Simulator

Avg. Processing Time (ms)

100 903 200 2,224.9 300 3,679.8 400 5,242.2 500 7,406.5 600 9,393.7 700 10,865.5 800 12,523.7 900 14,238.9

1,000 15,567.4

Figure 11. The Curve of the Average Parsing Time

VI. APPLICATION AREAS

The introduction of the XCREAM based approach is expected to increase the user needs to attach a variety of innovative smart devices and the associated services to the existing service framework with elaborate collaborative scenarios.

Improved services with a variety of combination of individual services would remarkably change our day-to-day life a lot more comfortable and safer than before.

The wide adoption of the RFID/USN-enabled application services with the proposed framework accelerates rapid prototyping and deployment of the new services with the effective customization methods.

The developed XCREAM framework in this research can make a cooperative work possible among existing middleware systems and enable a variety of RFID/USN-enabled services to be combined within the flexible framework to provide composite and refined services.

Furthermore, as the XCREAM framework has not only focused on seamless integration of the external services, but also the autonomy of the individual services, this framework would be well suited to the complex RFID/USN-enabled command and control center solution for the “Smart City” as well as the customized application services.

VII. CONCLUSION AND FUTURE RESEARCH DIRECTION

This paper focuses on the implementation of the collaborative XCREAM framework with the specification and the execution process of the XLogic script language which is used to define either individual or collaborative service scenarios. The research team continues to test the required functionalities of the XCREAM framework itself and the performance of the framework by combining test services. Based on this framework, our research team will also provide many effective solutions with well-organized service scenarios.

In the near future, the benchmark test of the XCREAM framework by comparing it with other solutions as well as the application of the framework to the real world cases would be accomplished.

The research team is also building reasoning process to the XCREAM to help the framework recognize a special situation with the combination of the context, i.e. the current status of an environment.

REFERENCES

[1] A. Arasu, S. Badu, and J. Widom, “CQL: A Language for continuous queries over streams and relations”, DBPL, 2003.

[2] B. Babcock, S. Babu, M. Datar, R. Motwani, and J. Widom, “Models and Issues in Data Stream Systems”, ACM, 2002.

[3] S. Chandrasekaran, O. Cooper, A. Deshpande, M.J. Franklin, J.M. Hellerstein, W. Hong, S. Madden, V. Raman, F. Reiss, and M. Shah, “TelegraohCQ: Continuous dataflow processing for an uncertain world”, CIDR 2003, First Biennial Conf. on Innovative Data Systems Research, Asilomar, CA, USA, 2003.

[4] J. Chen, D.J. DeWitt, F. Tian, and Y. Wang, “NiagaraCQ: A Scalable Continuous Query System for Internet Databases”, Proc. ACM SIGMOD Intl. Conf. on Management of data, 2000, pp. 379-390.

[5] N.D. Evans, “Middleware is the key to RFID”, 2004, Available from: http://www.rfidjournal.com/article/view/858/ 1/82.

[6] C. Floerkemeie, M. Lampe, “RFID mddleware design – addressing application requirements and RFID constraints”, Joint sOc-EUSAI conference, 2005, pp. 219-224.

[7] W. Heinzelman, A. Murphy, H. Carvalho, and M. Perillo, “Middleware to Support Sensor Network Applications,” IEEE Network Magazine Special Issue Jan. 2004.

[8] G. J. Kim, S. J. Kim, N. S. Kim, C. S. Pyo, “USN Service and Market Trend”, Journal of KISS, Vol. 25, No. 12, Dec. 2007.

[9] M. S. Kim, Y. J. Lee, J. H. Park, “USN Middleware Technology Trend” Journal of ETRI, Vol. 22, No. 3, Jun. 2007.

[10] Y. B. Kim, C. S. Kim, J. W. Lee, “A Middleware Platform Based on Multi-Agents for u-Healthcare Services with Sensor Networks” Symposium on Applied Computing Proceedings of the 2008 ACM symposium on Applied computing, 2008.

[11] S. Li, S. H. Son, and J. A. Stankovic, “Event Detection Services Using Data Service Middleware in Distributed Sensor Networks,” Information Proc. In Sensor Networks, Apr. 2003, LNCS 2634, pp.502-517.

[12] L. Liu, C. Pu, and W. Tang, “Continual Queries for Internet Scale Event-Driven Information Delivery”, IEEE Tran. Knowledge and Data Engineering, vol. 11, no. 4, 1999.

[13] T. Liu and M. Martonosi, “Impala: A Middleware System for Managing Autonomic,” Parallel Sensor Systems, Proc. ACM SIGPLAN Symp. Principles and Practice of Parallel Programming, 2003, pp. 107-118.

[14] D. Luckham, The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems, Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA, 2001.

[15] S.R. Madden, M.J. Franklin, and J.M. Hellerstein, “TinyDB: An Acquisitional Query Processing System for Sensor Networks.” ACM TODS, Vol.30, No.1, 2005, pp.122-173.

[16] I. Motakis, C. Zaniolo, “Temporal aggregation in active database rRules”, Proc. Intl. Conf. on Management of Data(SIGMOD), ACM Press, 1997.

[17] J. H. Paik, H. S. Kim, Y. H. Kim, S. I. Han, “New Techonology Trends on Indexing for Moving Objects”, Journal of KISS, Vol. 25, No. 1, Jan. 2007.

[18] K. Park, Y. Kim, J. Chang, D. Rhee, and J. Lee, “The Prototype of the Massive Events Streams Service Architecture and its Application”, Proc. Intl. Conf. on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing (SNPD 2008), Thailand, 2008.

[19] K. Park, Y. Kim, J. Lee, and J. Chang, “Integrated Design of Event Stream Service System Architecture (ESSSA)”, Proc. Intl. Conf. on E-business, Barcelona, Spain, 2007.

[20] S. Sarma, D.L. Brock, and K.Ashton, “The networked physical world – proposals for engineering the next generation of computing, commerce & automatic identification”, Technical Report MIT-AUTOID-WH-001, MIT Auto-ID Center, 2000, Available from: http://www.autoidlabs.org/uploads/media/MIT-AUTOID-WH-001.pdf.

[21] D. Terry, D. Goldberg, D. Nichols, and B. Oki, “Continuous Queries over Append-Only Databases”, Proc. of the ACM SIGMOD Intl. Conf. on Management of data, 1992, pp. 321-330.

[22] Yong Yao and J.E. Gehrke, “The Cougar Approach to In-Network Query Processing in Sensor Networks,” SIGMD RECORD. Vol.31, No.3, Sep. 2002.

[23] D. Zimmer, R. Unland, “On the semantics of complex events in active database management systems”, Proc. Intl. Conference on Data Engineering (ICDE), IEEE Computer Society Press, 1999, pp. 392-399.

[24] EPCglobal, “The EPCglobal Architecture Framework”, 2005, Avaiable from: http://www.epcglobalinc.org/standards/Final-epcglobal-arch-20050701.pdf.

[25] EPCglobal , “The Application Level Events (ALE) Specification”, ver. 1.0, 2005, Available from: http://www.epcglobalinc.org/standards/ale/ale_1_0-standard-20050915.pdf

[26] Oracle, “Oracle Complex Event Processing and Distributed Caching”, 2008, Available from: blogs.oracle.com/CEP/cep_coherence.doc

[27] The STREAM Group, “STREAM: The Stanford stream data manager”, IEEE Data Engineering Bulletin. vol. 26, no. 1, 2003.