Active Web Alert Service for Rule Based Alerting in Sensor Web An Event Based Approach
Anish Joshi March, 2005 Active Web Alert Service for Rule Based Alerting in Sensor Web An Event Based Approach
by
Anish Joshi
Thesis submitted to the International Institute for Geo-information Science and Earth Observation in partial fulfilment of the requirements for the degree in Master of Science in Geoinformatics.
Degree Assessment Board
Thesis advisor Dr. Andreas Wytzisk Drs. Barend J. Kobben¨ Thesis examiners Chairman: Prof. Dr. Menno Jan Kraak External examiner: Ingo Simonis Supervisor: Dr. Andreas Wytzisk Second supervisor: Drs. Barend J. Kobben¨
INTERNATIONALINSTITUTEFORGEO-INFORMATIONSCIENCEANDEARTHOBSERVATION
ENSCHEDE, THENETHERLANDS Disclaimer
This document describes work undertaken as part of a programme of study at the International Institute for Geo-information Science and Earth Observation (ITC). All views and opinions expressed therein remain the sole responsibility of the author, and do not necessarily represent those of the institute. Abstract
The recent developments in sensor, computing, communication and soft- ware technologies have brought about a new concept: the Sensor Web.A Sensor Web is a macro-instrument consisting of a heterogeneous, intelli- gent, spatially distributed sensors deployed to monitor and explore the envi- ronment. Open Geospatial Consortium’s (OGC) Sensor Web Enablement (SWE) initiative provides an infrastructural framework to integrate au- tonomous sensor webs into Spatial Data Infrastructure (SDI). The integra- tion of sensor web-based real/near real time information into SDI would culminate in a new level of spatio-temporal decision support for critical application scenarios for climate, natural resources, environment, disas- ter management, critical infrastructure protection, homeland security and emergency response issues.
This new level of decision support is achieved by the formalized knowledge of the facts and circumstances of the environment. However, there lacks a system in current SWE architecture that incorporates the rule based facts of the real world scenarios. This research work is an effort to conceptual- ize and develop an alerting geo-service that is capable of incorporating real world environmental, spatial and temporal rules that will help to get an in-depth insight of the real world phenomena for better decision making.
Based on the use case scenario of flood early warning, a service is envisioned and designed that allows definition of spatio-temporal and observational rules pertaining to a flood event. The service communicates with underlying Sensor Collection Services (SCS) for sensor observation data and validates the data against predefined threshold rules. The service dispatches alert notifications to the subscribers based on the fulfillment of these threshold rules. Such an alerting service is realized through an Active Web Alert Ser- vice (AWAS). The AWAS extends current SWE components by incorporating a new service for alert notification as envisioned by Open Web Service 2 (OWS 2).
The AWAS is built on top of event based communication model, a new com- munication paradigm for distributed GI-Services. The event based commu- nication model enables proactive communication pattern between the AWAS and SCS(s), enabling active dispatch of sensor observation data when the rules are satisfied. The event based model enables anonymous and asyn- chronous communication between SCS(s) and the AWAS. SCS(s) publishes its observations as events to the event service and the AWAS subscribes to the events defined by rules with the event service. A notification is sent to the subscriber AWAS when the published and subscribed events are matched.
i Abstract
This research work is an effort to conceptualize and design AWAS based on event based communication model as well as to investigate on enhance- ments required on current SWE components to support incorporation of the AWAS in SWE framework.
Keywords Sensor Web, Rule Based Alerting, Active Web Alert Service, Event Based Communication, Emergency Warning
ii Contents
Abstract i
List of Figures vii
List of Tables ix
Acknowledgements xi
1 Introduction 1 1.1 Background ...... 1 1.2 Research Scenario ...... 3 1.3 Problem Statement ...... 3 1.4 Research Objective ...... 4 1.5 Research Question ...... 4 1.6 Research Scope ...... 5 1.7 Thesis Structure ...... 5
2 Interoperability Framework for Sensor Web 7 2.1 Integrating Sensor Web into SDI ...... 7 2.2 Interoperability Framework ...... 8 2.2.1 Service Oriented Architecture ...... 9 2.2.2 Web Service ...... 10 2.2.3 Open Geospatial Consortium ...... 11 2.2.4 OGC Specification ...... 12 2.3 OGC Web Service Architecture ...... 16 2.3.1 OWS Framework ...... 16 2.4 Sensor Web Enablement ...... 18 2.4.1 SensorML ...... 18 2.4.2 Observations & Measurements ...... 20 2.4.3 Sensor Collection Service ...... 25 2.4.4 Sensor Planning Service ...... 27 2.4.5 Web Notification Service ...... 29 2.5 Synopsis ...... 31
3 Sensor Web for Spatio-Temporal Decision Support 33 3.1 Sensor Web in Emergency Management ...... 34 3.2 Use Case Scenario–Flood Management & Early Warning .... 35
iii Contents
3.2.1 Role of Sensor Web ...... 37 3.3 Rule Based Alerting Service for Sensor Web ...... 37 3.3.1 General Concept ...... 39 3.4 Requirements ...... 40 3.4.1 Rule Registration ...... 40 3.4.2 Communication Model ...... 42 3.4.3 Encodings of Alert Messages ...... 43 3.4.4 Extension of SWE components ...... 46 3.5 Open Issues ...... 47 3.6 Synopsis ...... 48
4 Event Based Communication Model 51 4.1 Event Based Communication ...... 51 4.1.1 Participants of Event Based Communication ...... 51 4.1.2 Characteristics of Event Based Communication ..... 51 4.1.3 Event ...... 53 4.1.4 Event Notification ...... 54 4.1.5 Filter ...... 54 4.1.6 Pattern ...... 55 4.1.7 Event Service ...... 56 4.1.8 Advertise/Publish/Subscribe ...... 57 4.1.9 Event Notification Schemes ...... 57 4.1.10 Interaction Pattern ...... 58 4.2 Synthesis: AWAS and Event Based Communication Model ... 60 4.2.1 AWAS Object Model ...... 60 4.2.2 AWAS Event Model ...... 60 4.2.3 Event Generation Schemes ...... 61 4.3 Open Issues ...... 63 4.4 Synopsis ...... 64
5 Active Web Alert Service - Architecture 65 5.1 Architectural Concept ...... 65 5.1.1 Layered View ...... 65 5.1.2 Structural View ...... 66 5.1.3 Interface Operations ...... 68 5.1.4 Behavioral View ...... 71 5.2 Functional Design Components ...... 73 5.2.1 Event ...... 73 5.2.2 Event Filter/Pattern ...... 75 5.2.3 Event Publish/Subscribe ...... 75 5.2.4 Event Notification ...... 75 5.2.5 Event Handling and Parsing ...... 76 5.3 Non-Functional Design Components ...... 76 5.3.1 Quality of Service ...... 76 5.3.2 Temporal Synchronization of Events ...... 77 5.4 Deployment Concept ...... 77 5.4.1 Process View ...... 77 iv Contents
5.4.2 Deployment View ...... 79 5.5 Open Issues ...... 80 5.6 Synopsis ...... 81
6 Proof of Concept 83 6.1 Implementation Framework ...... 83 6.2 Implementation Technology ...... 84 6.2.1 Java ...... 84 6.2.2 Servlet ...... 85 6.2.3 JDBC ...... 85 6.2.4 XForm ...... 85 6.2.5 XML Parser ...... 86 6.3 Prototype ...... 86 6.3.1 Siena Event Service ...... 86 6.3.2 Implementation ...... 88 6.3.3 Result ...... 90 6.4 Synopsis ...... 91
7 Conclusion and Recommendation 93 7.1 Conclusion ...... 93 7.2 Recommendation for Future Work ...... 98
A 101 A.1 User rules expressed in Filter Encodings ...... 101 A.2 Common Alerting Protocol(CAP)Document Object Model .... 102 A.3 Example of user form for rule registration ...... 103
B 105 B.1 Results of prototype ...... 105 B.1.1 Event Publishing ...... 105 B.1.2 Event Subscription ...... 106
Bibliography 107
Glossary 117
v Contents
vi List of Figures
2.1 Publish-Find-Bind Pattern [11] ...... 10 2.2 Web Service interoperability stack ...... 11 2.3 UML Class diagram of OpenGIS Geodata Model adopted from [6] 14 2.4 UML Class diagram of Abstract and Implementation Service Spec- ifications adopted from Percivall [53] ...... 15 2.5 The OWS Service Framework [11] ...... 17 2.6 SWE Sequence diagram adopted from [97] ...... 19 2.7 UML Class diagram representing sensor in SensorML adopted from [94] ...... 21 2.8 UML Class diagram representing the Observation Feature in O&M [24] ...... 23 2.9 UML Class diagram representing Observation Collection & Cov- erage in O&M [24] ...... 24 2.10 UML Class diagram showing Scalar Value & Composite Value for aggregate model in O&M [24] ...... 25 2.11 UML Class diagram showing Derived Phenomena & Composite Phenomena [24] ...... 26 2.12 UML Sequence diagram showing the interactions of SPS opera- tions. Adopted from [61] ...... 28 2.13 UML Sequence diagram showing One-Way-Notification [84] .. 30 2.14 UML Sequence diagram showing Two-Way-Notification [84] .. 31
3.1 Flood Warning Process [72] ...... 36 3.2 Flood Warning Process based on threshold rules ...... 37 3.3 Conceptual Model of Alert Notification Service in UML use case diagram ...... 40 3.4 Extension required in SCS ...... 47
4.1 Client/Server Vs Event Based Communication Model ...... 52 4.2 Example of notification. Adapted from [18] ...... 54 4.3 Example of filter adopted from [18] ...... 55 4.4 Example of pattern filter adopted from [18] ...... 55 4.5 Distributed event notification service [18] ...... 56 4.6 Advertise/Subscribe of events. Adopted from [69] ...... 59 4.7 Active Web Alert Service (AWAS) Object Model ...... 60 4.8 Example of pattern filter for river gauge level and precipitation 61 4.9 Event generation Scheme 1 ...... 61
vii List of Figures
4.10 Event generation Scheme 2 ...... 62 4.11 Event generation Scheme 3 ...... 63
5.1 Layered view of system architecture ...... 66 5.2 System Architecture in UML notation ...... 67 5.3 AWAS components in UML notation ...... 68 5.4 System Interaction in UML notation ...... 72 5.5 O&M fragment of river gauge observation ...... 74 5.6 Example of O&M observation parsed event tuples and correspond- ing event function call ...... 74 5.7 Example of published event and subscribed event filter ..... 75 5.8 System Components in UML notation ...... 78 5.9 AWAS Deployment in UML notation ...... 79
6.1 AWAS Components/Deployment in Unified Modeling Language (UML) notation ...... 84 6.2 Siena Event Service in UML notation ...... 87 6.3 AWAS Prototype classes in UML notation ...... 88 6.4 AWAS Prototype deployment in UML notation ...... 90
A.1 Example of user rule encoded in Filter Encoding ...... 101 A.2 Common Alerting Protocol (CAP) Document Object Model [8] . 102 A.3 Flood rule registration HyperText Markup Language (HTML) form sample ...... 103
B.1 Screen shot of events published by Sensor Collection Service (SCS) emulator ...... 105 B.2 Screen shot of event filter subscribed by AWAS event subscriber class ...... 106
viii List of Tables
3.1 Elements (mandatory) of CAP [8] ...... 45
5.1 Service operations of AWAS ...... 69 5.2 Parameters of GetCapabilities operation ...... 69 5.3 Parameters of SubscribeUser operation ...... 70 5.4 Parameters of RegisterRule operation ...... 70
6.1 Interface of Siena [18] ...... 87 6.2 Filter subscription ...... 89 6.3 Event publication ...... 89
ix List of Tables
x Acknowledgements
Wernher Von Braun once said “Basic research is what I am doing when I don’t know what I am doing”. This has certainly been a case in many occasions when I didn’t know what I was doing and what I had to do. I would like to take this opportunity to extend my sincere gratitude to individuals who showed me the path what I had to do.
I extend most sincere gratitude to Dr. Andreas Wytzisk who encouraged me to pursue my research on this topic. His continuous support, guidance, constructive comments and suggestions have been invaluable for this work to take its present shape. It was a privilege to have him as my supervisor.
I am also grateful to Drs. Barend J. Kobben¨ for his enthusiastic support, suggestions and personal encouragements that helped me find the path for the completion of this work.
I would also like to thank Alexander Walkowski and Ingo Simonis from the Institute of Geoinformatics University of Munster¨ for providing me excellent resources and ref- erences for my work.
I am grateful to the Government of the Netherlands for granting me an opportunity to pursue my MSc course at ITC. I also thank all the faculty members of GFM, the stu- dent affairs and the hotel staffs for their support to complete my studies and a pleasant stay here in Enschede.
Last but not least, I would like to thank all my MSc colleagues, friends at ITC and in Enschede for all those wonderful memories we had over the last 18 months.
xi Acknowledgements
xii Acronyms
API Application Programming Interface
AWAS Active Web Alert Service
ASCS Active Sensor Collection Service
CAP Common Alerting Protocol
CORBA Common Object Request Broker Architecture
CPS Coverage Portrayal Service
CQL Common Query Language
CRS Coordinate Reference System
DCE Distributed Computing Environment
DCP Distributed Computing Platform
EOSE Extended Open Systems Environment
GIS Geographic Information System
GML Geography Markup Language
GPS Global Positioning System
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
ICT Information Communication Technology
ISO International Organization for Standardization
ISO/TC International Organization for Standardization/Technical Committee
JDBC Java Database Connectivity
JVM Java Virtual Machine
OGC Open Geospatial Consortium
OGM Open Geodata Model
xiii Acknowledgements
OLE/COM Object Linking and Embedding/Common Object Mode
O&M Observations and Measurements
OSF OWS Service Framework
OWS OGC Web Services
QoS Quality of Service
RDF Resource Description Framework
RM-ODP Reference Model for Open Distributed Processing
SCS Sensor Collection Service
SDI Spatial Data Infrastructure
SDSS Spatial Decision Support System
SensorML Sensor Markup Language
SLD Styled Layer Description
SMS Short Message Service
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
SPS Sensor Planning Service
SQL Structured Query Language
SWE Sensor Web Enablement
TIN Triangulated Irregular Network
UDDI Universal Description Discovery and Integration
UML Unified Modeling Language
URI Universal Resource Identifier
URL Uniform Resource Locator
W3C World Wide Web Consortium
WAS Web Alert Service
WMS Web Map Service
WNS Web Notification Service xiv Acknowledgements
WRS Web Registry Service
WSDL Web Services Description Language
WSFL Web Service Flow Language
WWW World Wide Web
XML eXtensible Markup Language
xv Acknowledgements
xvi Chapter 1
Introduction
1.1 Background
The Sensor Web is a novel approach toward integrated earth sensing and provides a new level of decision support for making critical decisions on cli- mate, natural resources, sustainable development, environment, disaster man- agement, critical infrastructure protection, homeland security and emergency response issues.
Sensor Web as first proposed by NASA Sensor Web Applied Research Plan- ning Group in 2001 is defined as “A Sensor Web is a system of intra communi- cating spatially distributed sensor pods that can be deployed to monitor and ex- plore new environments” [29]. This definition by NASA limits the sensor web in a small scope focusing on a specific instrument the sensor pod. A more compre- hensive definition is given by Tao et al [89] as “The Sensor Web is a web-centric, open, interconnected, intelligent and dynamic network of sensors that presents a new vision for how we deploy sensors, collect data and use and distribute information” [82]. Such sensors are deployed for flood gauge measurement, air-pollution monitors, stress gauges on structures, mobile heart monitors, we- bcams and satellite born earth imaging devices etc. [89].
Open Geospatial Consortium’s1 Sensor Web Enablement (SWE) Initiative plays a prominent role in defining a common reference architecture and common in- formation model, which provides an interoperability framework for accessing and utilizing sensors and sensors systems in space-time context via web proto- cols. The SWE consists of five loosely coupled processing components, which are still under specification, development and testing process. These components are namely Sensor Markup Language (SensorML),Observations & Measure- ments (O&M), Sensor Collection Service (SCS), Sensor Planning Service (SPS) and Web Notification Service (WNS)[10]. SensorML is an information model and XML encodings for describing Web-resident sensors [9]. O&M is an in- formation model and XML encodings for observations and measurements [24].
1Formerly OpenGIS Consortium
1 1.1. Background
SCS provides an interface to fetch observations from a sensor or constella- tion of sensors. This is the intermediary between a client and an observation repository or near real-time sensor channel [67]. SPS is a service to assist in ‘collection feasibility plans’ and to process collection requests for a sensor or sensor constellation. This is the intermediary between a client and a sensor collection management environment [61]. WNS executes and manages mes- sage dialogue between a client and web services for long duration asynchronous processes [84].
The SWE provides a framework to integrate real/near real time data into Spatial Data Infrastructure (SDI). The incorporation and open distribution of spatio-temporal data through the Spatial Data Infrastructure (SDI) services helps to provide in-depth insight on environmental and/or human induced phe- nomena for a new level of decision support related to the environment, disaster management, critical infrastructure protection, homeland security and emer- gency response. Such a decision support system would require simple as well as complex rule evaluation functionalities that can distinctly identify the oc- currences of one or more natural and/or human induced phenomena occurring within a certain spatial extent and timespan.
An alerting service is envisioned to incorporate observational and spatio- temporal rules that forms the basis for detecting a critical event (natural or human induced) occurring in the environment and send subsequent alerts of ensuing disaster event. Such an alerting service would communicate with the underlying SCS(s) as well as other conventional information resources like Web Mapping Service (WMS), Web Feature Service (WFS) or Web Coverage Service (WCS); evaluate the responses from these resources and respond with alert no- tification upon the validation of the rule(s) [85]. The SWE, however, at the current stage of development does not have such a service framework that sup- ports the aforementioned rule subscription, evaluation and subsequent alert notification.
The Open Geospatial Consortium (OGC) is envisaging for such an alerting service for upcoming OGC Web Services (OWS) 3.0 initiative. Simonis et al [85] conceives a Web Alert Service (WAS) that allows incorporation of user rule, evaluates the observations against the rule and actively notifies the user upon the fulfillment of the rule. Such an active alerting service is based on a new net- work communication paradigm for the ‘push mechanism’ of data transfer: the ‘event based communication’. However, no actual work has been done to build such a service. This research work investigates the possibility to incorporate a rule based alerting service into the SWE architecture and build a conceptual model of such a service. This service is built on top of event based communi- cation model and collaborates with other SWE services to actively send alert notifications and is named as an Active Web Alert Service (AWAS). The con- ceptual model will be based on a use case driven approach, which will help to generalize the contents as well as provide a possibility for future extension.
2 Chapter 1. Introduction
High degree of interoperability with the current SWE components, flexibility to accommodate complex observational and spatio-temporal rules, extensibility and built upon the current and emerging technologies will be the prerequisites of such an alerting service.
1.2 Research Scenario
Temporal dynamic spatial information is crucial to support decision mak- ing processes in emergency scenarios related to natural hazards such as flood, earthquake, tsunami, hurricane etc and human induced hazards such as toxic plume, nuclear and chemical hazard etc. The temporal dynamic nature of the information requires real/near real time data acquisition and active data dis- semination to support decision making and alerting in emergency scenarios.
To build up a scenario, the following use case is considered: a web of het- erogeneous meteorological and hydrological sensors that provide data for pre- cipitation, river gauge level and other parameters to support the detection of flood within a spatial extent. The prerequisites for such a scenario would be that the user registers with an underlying service, providing the service with user profile, communication address, flood rules (e.g. certain threshold water level, threshold precipitation etc.), spatio-temporal conditions (e.g. within cer- tain area and on certain day(s) and/or time). An early warning of an ensuing flood event detected based on these complex rules enables emergency decision makers to take critical decisions for disaster management.
Framing the above scenario into the SWE context, SWE has to be extended by a novel service, which provides an interface to register for risk related rules and send alert notifications to the clients when the rules are satisfied. These rules are the constraints on threshold values of hydrological and meteorological parameters that clearly identifies a flood event when exceeded.
1.3 Problem Statement
Although the OWS advocates for an alerting service on its future specifica- tion and few conceptions have been drawn, true implementation of these con- cepts haven’t been realized as yet. Another impeding factor for realizing such an alerting service is the current SWE framework based on request/response model implementing a pull mechanism for data transfer. In this context, the SCS must be periodically requested by the alerting service for the sensor data and consecutively the received data must be verified against the given criteria. This method of request/response and publishing of sensor data consequently in- creases the volume of transmitted data and consumes unnecessary bandwidth as well as increases the workload of SCS and the alerting service. Consequently, the network traffic and simultaneous multiple requests might delay or even fail to deliver the data to the user.
3 1.4. Research Objective
The other issue pertaining to the limitations of current SCS specification is that it lacks functionality to accommodate the user defined rules, which pro- vides the user to define the constraints for the observations. This specific prob- lem has been addressed in Active Sensor Collection Service (ASCS)[94], which extends the interface of the conventional SCS by implementing a push model that can automatically dispatch data. However, there still remains a bottleneck in the case of complex rule evaluation involving more than one SCSs in combi- nation with spatio-temporal constrains. Another important issue is the adap- tation of WNS to operate with the proposed AWAS to send alert notifications. Integration of these types of complex rule and communicating and responding to them under current SWE specifications does not seem fully viable.
To summarize, the outline of the problem statement can be drawn as:
• Inability of currently implemented SCS to accommodate registration and evaluation of complex threshold rules.
• Lack of efficient data transfer model for pro-active data dissemination.
• Lack of standardized/well specified interface to register and evaluate com- plex spatio-temporal and observational rules.
• Insufficiency of WNS to send emergency alert notifications.
1.4 Research Objective
The main objective of this research work is:
• To conceptually design an event based alerting service based on use case scenario in support of autonomous sensor web systems that will logically extend and is consistent with the current SWE specifications and is coher- ent with the broad OGC framework.
1.5 Research Question
The following questions are outlined to address the above objective:
• What are the typical rules (including spatio-temporal and observational) AWAS should handle for alert notification in emergency scenarios?
• What are the limitations of Sensor Collection Service (SCS) and Web No- tification Service (WNS) to support Active Web Alert Service (AWAS)?
• How does AWAS communicate with the SCS(s)?
• How to implement event based communication model between SCS(s) and proposed AWAS?
• How to evaluate the conceptual model?
4 Chapter 1. Introduction
1.6 Research Scope
This research investigates on a novel service for emergency alert warnings under SWE framework. The main focus of the research is to build a conceptual model of a rule based alerting service - Active Web Alert Service (AWAS) based on event based communication model. The research work is limited to the in- vestigation of current SWE components to support the proposed AWAS and to conceptually design the service based on event based communication model. A simplified prototypical implementation is carried out to prove the concept.
1.7 Thesis Structure
This thesis is organized in following chapters:
• Chapter 2 gives the overview of OGC and its stance on sensor web tech- nology. The chapter discusses the SWE initiative and its components SensorML, O&M, SCS, SPS and WNS. The chapter provides overview of interoperability framework to integrate proposed AWAS in current SWE framework.
• Chapter 3 describes the concept behind the AWAS considering emergency management use case scenario of flood detection and early warning, and analyzes the requirements for AWAS.
• Chapter 4 gives a detailed insight of event based communication para- digm and models AWAS into the event based communication model.
• Chapter 5 builds the architecture of AWAS based on software design ar- chitecture technique.
• Chapter 6 gives the validation of the developed architectural model by demonstrating a simplified prototype.
• Chapter 7 provides a critical discussion on the conclusions drawn and gives recommendation on future development of the service as a new com- ponent for SWE.
5 1.7. Thesis Structure
6 Chapter 2
Interoperability Framework for Sensor Web
2.1 Integrating Sensor Web into SDI
Groot and McLaughlin [43] defines Spatial Data Infrastructure (SDI) as
“The relevant collection of technologies, policies and institutional arrange- ments that facilitate the availability of and access to spatial data...”
The technological framework of SDI allows access to distributed geospatial data and geoprocessing capabilities. The technical services in SDI consists of in- teroperable and modular software entities that provide users with an access to distributed geoprocessing functionalities and geospatial information resources through a standardized and open interface[98]. GIS applications based on dis- tributed geoprocessing services prompt the concept of GI-Service Infrastruc- ture, which comprises disparate services that can be combined with each other and with other specialized services1. GI-Services are subset of web services that enable the discovery, retrieval, processing, manipulation, analysis and vi- sualization of spatial data from multiple resources via communication networks [53].
The evolutionary, dynamic, complex and heterogeneous nature of user types, user requirements and application domains have further broaden the definition and functionality of conventional SDI. In this context, the functionality and re- sources of SDI have also undergone significant technological development and maturation to incorporate user needs. Over the years, the user demand for spatio-temporal information for various application domains have significantly increased. The incorporation of spatio-temporal information offered by sensor web networks into SDI would enable SDIs to be suitable backbones for decision support processes in temporal critical application areas [98] ranging from emer- gency management, climate, natural resources, sustainable development, en- vironment, disaster management, critical infrastructure protection, homeland
1Specialized services include sensors, simulation tools etc
7 2.2. Interoperability Framework
security etc. The seamless integration and accessibility of real and near real- time spatio-temporal information into SDI framework would transform spatial data infrastructure to spatial knowledge infrastructure [75], a new knowledge base.
2.2 Interoperability Framework
Distributed Computing Environment (DCE) has made it possible for the tran- sition of GIS technology from centralized GIS Systems to distributed GI-Services. The distributed environment refers to a distributed collection of users, data, softwares and hardware whose purpose is to meet some predefined objectives [7]. The term distributed GI-Service refers to distributed GIS, built upon dis- tributed component technology, which connects to and interact with multiple and heterogeneous systems and platforms and without the constraints of tradi- tional client/server relationships [73]. The cross platform integration, interac- tion and availability of heterogeneous interoperable software components over the network makes the DCE a base for interoperability framework.
Open Geospatial Consortium (OGC) and the Technical Committee tasked by the ISO (ISO/TC 211) are the major organizations that set industry standards for distributed GI-Services [12]. The OGC specification defines a comprehen- sive software framework for integration and distributed access to geodata and geoprocessing resources through the information infrastructure. ISO/TC 211 emphasize on a service-oriented view of geoprocessing technology and a bal- anced concern for information, applications and systems [60].
The interoperability framework provided by open distributed computing is based on ISO/IEC RM-ODP. The RM-ODP defines standard concepts and ter- minology for open distributed processing and contains five standard viewpoints that focus on the different aspects of the system to enable the separation of concern and allow designers to concentrate on facets of the design that are of interest [11]. The enterprise viewpoint captures the purpose, scope and policies for the system being designed. The information viewpoint specifies the infor- mation the system holds and the processing it carries out. The computational viewpoint addresses distribution through functional decomposition of the sys- tem into objects which interact at interfaces. The engineering and technology viewpoints focus on the mechanisms, functions and technology choices to real- ize a distributed system. Each viewpoint is the abstraction that specifies the whole system from its individual perspective, but is not independent of other viewpoints [32].
Focusing on the computational viewpoint which defines the interoperabil- ity between the interfaces and services, the following section 2.2.1 describes the Service Oriented Architecture (SOA) pattern to represent the interactions among OGC services (web services), which play central role within the OGC approach to achieve an interoperable system.
8 Chapter 2. Interoperability Framework for Sensor Web
2.2.1 Service Oriented Architecture Service Oriented Architecture (SOA) is an architecture that is made up of components and interconnections that stress interoperability and location trans- parency [87]. SOA provides an approach for building systems that deliver ap- plication functionality as services to the end user applications or other services [34].
SOA contains components, services and processes. Components are binaries that do specific tasks and these binaries each have defined interface and usu- ally execute one job. A service is a grouping of components and these services are joined together by the processes to form a business process. This concept basically has three components namely service provider, service broker, service requester and three operations namely publish, find and bind. The descriptions of these components and the operations are mentioned as following:
• Service Provider: It is a network-addressable entity that publishes its ser- vices and interface contract to the service registry so that the service con- sumer can discover and access the service.
• Service Registry/Broker: It enables the discovery of the service. It con- tains a repository of available services and allows for the lookup of service provider interfaces to interested service consumers.
• Service Consumer/Requester: It is an application, a software module or another service that requires a service. It inquiries the service registry for the service, binds to the service over a transport protocol and executes the service function according to the interface contract provided by the service provider.
These entities in SOA are bound together by three operations described as follows:
• Publish: It is used to advertise data and services to a broker. A service provider publishes its service description metadata describing its capabil- ities and network address, so that it can be discovered and invoked by a service consumer.
• Find: A service requester locates a service by querying the service registry that meets its criteria. A service registry then responds by delivering the results that match the query.
• Bind: A service requester retrieves the service description of requested service to bind with the service provider and proceeds to invoke the service according to the information in service description.
These components and operations bound together with SOA collaborations, which is based on publish-find-bind paradigm. According to this pattern, a ser- vice provider gives a description of the service it wants to publish to the service
9 2.2. Interoperability Framework
registry. This description includes a description of the interface at which the service instance is available. A service consumer performs a dynamic service location by querying the service registry for a service that matches its criteria. If the queried service exist, the registry provides the consumer with the inter- face contract and the endpoint address for the service. The following fig. 2.1 illustrates the publish-find-bind pattern.
Service Registry
Find Publish
Service Service Consumer Provider Bind
Figure 2.1: Publish-Find-Bind Pattern [11]
2.2.2 Web Service IBM [59] defines web service as “A Web service is an interface that describes a collection of operations that are network accessible through standardized XML messaging. A Web service is described using a standard, formal eXtensible Markup Language (XML) notion, called its service description. It covers all the details necessary to interact with the service, including message formats (that detail the operations), transport protocols and location. The interface hides the implementation details of the service, allowing it to be used independently of the hardware or software platform on which it is implemented and also inde- pendently of the programming language in which it is written. This allows and encourages Web Services-based applications to be loosely coupled, component- oriented, cross-technology implementations. Web Services fulfill a specific task or a set of tasks. They can be used alone or with other Web Services to carry out a complex aggregation or a business transaction”. A short and programmatic definition is given by Stencil Group [86] as “Loosely coupled, reusable software components that semantically encapsulate discrete functionality and are dis- tributed and programmatically accessible over standard Internet protocols”.
The web service concept represents a next generation architecture that pro- vides high level of interoperability between software components based on soft-
10 Chapter 2. Interoperability Framework for Sensor Web ware industry standards [85]. Web services are built on top of existing and emerging standards such as HTTP, XML, SOAP, WSDL and UDDI. Web ser- vice allows applications to be integrated more easily based on transactions of XML messages, which focuses on more service semantics rather than network protocol semantics, thus enabling loose coupling of business processes. The web service architecture is based upon publish-find-bind paradigm defined by SOA pattern.
Web service architecture represents a collection of several related technolo- gies logically layered in a virtual stack. The lowest level of the stack contains network which enables the connectivity of the software components by enabling them to bind, send and receive messages. Because of ubiquity, HTTP is a de facto standard network protocol for Internet based web service [59]. The XML based messaging layer uses SOAP as a medium to wrap XML messages in an envelope over HTTP. The service description layer defines the interface and the mechanism of service interaction through WSDL. WSDL describes the func- tion, location and method of invocation of web services. A service provider uses Web Services Description Language (WSDL) document to publish web services, find the publish services and to bind to service dynamically [11]. The publish and discovery layer uses UDDI to publish the service, which can subsequently be discovered by the user by the means of interaction with the UDDI interface. The UDDI describes a standard way of setting up registries of web services and the methods to query such registries. The topmost layer, service flow describes the flow of communications and collaborations between the services via WSFL. Figure 2.2 illustrates the interoperability stack of web service.
WSFL Service Flow
Service Publication/ Quality of Service
UDDI Management Discovery Security Security
WSDL Service Description
SOAP XML-Based Messaging
HTTP, FTP, E-mail Network MQ, IOOP etc
Figure 2.2: Web Service interoperability stack
2.2.3 Open Geospatial Consortium
OGC is an international industry consortium with 266 members which in- cludes companies, government agencies and universities participating in a col- laborative, consensus process to enhance and enable interoperability for tech-
11
2.2. Interoperability Framework
nologies involving spatial information. OGC was founded in 1994 with a vision of full integration of geospatial data and geoprocessing resources into main- stream computing and widespread use of interoperable, commercial geoprocess- ing software throughout the global information infrastructure [12]. The OGC was initiated with a mission to deliver spatial interface and encoding speci- fications that are openly and publicly available for global use [11]. Such an open interface specifications enable content providers, application developers and integrators to deliver more capable products and services to consumers in optimum time and cost and with more flexibility.
The OpenGIS Specifications define a comprehensive software framework for distributed access to geodata and geoprocessing resources. The OpenGIS Spec- ifications provide a framework for software developers to create software that enables their users to access and process geodata from variety of sources across a generic computing interface within an open information technology founda- tion [12]. The OpenGIS Specifications contains abstract specification and imple- mentation specifications. The contents of both these specifications are based on three conceptual models namely Open Geodata Model (OGM), OpenGIS Service and Information Communities Model which are described later in the section 2.2.4.
The OpenGIS Abstract Specification provides the conceptual foundation and presents a high level abstraction defining characteristics for designing data model and services. Open interfaces and protocols are built and referenced against the Abstract Specification thus enabling interoperability between dif- ferent kinds of spatial processing systems. The Abstract Specification is based on essential model for geographic information and processing [12]. The essen- tial model contains the abstraction of the real world facts and their mathemat- ical and symbolic representation. The mathematical and symbolic representa- tions are implemented in software through DCP specific OpenGIS Implemen- tation Specifications.
OpenGIS Implementation Specifications address software specifications which are adopted on the basis of conceptual model in OpenGIS Abstract Specifica- tion. Application developers and software programmers are the primary users of the OpenGIS Implementation Specification, which defines explicit APIs or languages for accessing geodata and geoprocessing functions [12]. Implemen- tation specifications are created by software vendors based on specific Distrib- uted Computing Platform (DCP) like OLE/COM, CORBA, Java or SQL and lan- guages like XML.
2.2.4 OGC Specification OpenGIS Specifications can be included in three conceptual models – the Open Geodata Model (OGM), the OpenGIS Services Architecture and the In- formation Communities Model. These three models are described in brief in the following sections.
12 Chapter 2. Interoperability Framework for Sensor Web
Open Geodata Model OpenGIS Specifications represent real earth phenomena in two fundamental geographic types – features and coverages. Both features and coverages can be used to map real-world elements or phenomena to an OpenGIS specifications representation, which ultimately provides a common way to deliver these ele- ments in software design [12]. Basic class of all geographic object is Feature, which is defined as a representation of real world element or the abstraction of the real world. Features are the basic elements of geospatial information and include geometry, semantic properties and metadata [12]. Features are usually managed in groups [73] FeatureCollection and are associated with FeatureType, which describes the category of feature. The semantic prop- erties of feature is described by FeatureProperties. Geometry is a special type of FeatureProperties, which defines the shape as well as includes space reference represented by SpatialReferenceSystem.
Coverage represents spatially continuously phenomena such as tempera- ture distribution, terrain model, imagery, soil maps, population distribution etc. Coverage is a specialized Feature and is a subtype of Feature [12]. In a coverage, every location has associated data values related to a phenomenon. Coverages are associated to the CoverageFunction, which represents the re- lationship between local points and the range of values of the coverage. The CoverageFunction, for example represent lattice of TIN or a quantity of a Theissen Polygon representing a continuous geographical phenomena [6]. The following fig. 2.3 adopted from [6] represents the Open Geodata Model in UML notation.
OpenGIS Service Architecture The OpenGIS Services Architecture defines a set of services to access and process geographic types (features and coverages) defined in OGM as well as provide capabilities to share geodata within user communities who use common set of geographic features definition and translate between different communi- ties of users that use different sets of geographic feature definitions [12]. The OpenGIS Services Architecture is based on ISO RM-ODP and extends Extended Open Systems Environment (EOSE) model for geographic services defined in ISO 19101. The EOSE defines six classes of information technology services based on the semantic type of computation that they provide [53]. These classes are the basis for geographic service taxonomy [53] and are used to categorized the types of GI-Services.
• Geographic Human Interaction Services are services for management of user interfaces, visualization and presentation of of geodata for different purposes.
• Geographic Model/Information Management are services for management, access as well as administration of conceptual schemas, geodata and cor- responding metadata.
13 Visual Paradigm for UML Community Edition [not for commercial use] 2.2. Interoperability Framework
FeatureType
Feature FeatureProperty
1..*
0..*
Coverage FeatureCollection Geometry
CoverageFunction SpatialReferenceSystem
Figure 2.3: UML Class diagram of OpenGIS Geodata Model adopted from [6]
• Geographic Workflow/Task Service are services that support use of re- sources and development of products involving a sequence of activities or steps conducted by different individuals and/or services. For e.g. service chaining of several GI-Services.
• Geographic Processing Service are services that perform computations of geodata like coordinate transformation, geocoding etc.
• Geographic Communication service encode and exchange geodata across communication networks such as exchange data between different GI- Services.
• Geographic System Management Service are services for the management of system components, applications and networks. For e.g. management of user privileges and user access.
Service specifications are defined in various levels of abstraction. Platform- neutral service specifications defines services without reference to a particular type of specification or to its implementation. These platform-neutral service specifications form the basis to define the implementation of a specific type of service for a specific DCP. There may be multiple platform-specific specifica- tions for a single platform-neutral specification. These multiple platform speci-
14 Chapter 2. Interoperability Framework for Sensor Web
ficationsVisual Paradigm are meant for UML for Community supporting Edition variety [not offorDCP commercials. The use]UML diagram in fig.2.4 below shows the relation between different types of service specifications.
ServiceSpecification
abstSpec 1
typeSpec 1 PlatformNeutralServiceSpecification
typeSpec 1
implSpec 1 1..* Service PlatformSpecificServiceSpecification specification 0..* implementation
Figure 2.4: UML Class diagram of Abstract and Implementation Service Specifications adopted from Percivall [53]
Information Communities Model
Information Communities Model enables sharing of information between dis- parate geospatial databases with inconsistent definitions and help communi- cate between communities that describe geographic features in different ways [12]. An information community is a collection of different user communities affiliated to different disciplines, who share common geospatial resources and common spatial feature definitions. For an instance, a soil scientist and a civil engineer might have different perspective and interpretation of soil information from a common soil data. Such case presents a common spatial feature defini- tion but totally different semantics. Information communities model facilitates automated translation between different geographic feature domains and es- tablishes communications among different communities of geodata producers and users [73]. Information communities model addresses this intercommunity sharing of geodata through software semantics translators, which will contain all of the information it needs to find and translate feature collections from the source to the target semantics [12].
The OpenGIS Information Communities Model has not been fully developed and approved by OGC Technical Committee [12]. Hence, further elaboration of this model is not done here.
15 2.3. OGC Web Service Architecture
2.3 OGC Web Service Architecture
OGC Web Services (OWS) are an evolutionary, standards-based framework that enables seamless integration of a variety of online geoprocessing and loca- tion services across the web using familiar technologies and protocols such as XML and HTTP [30]. OWS provides a vendor-neutral, interoperable framework for web based discovery, access, integration, analysis, exploitation and visual- ization of multiple online geodata sources, sensor derived information and geo- processing capabilities [30]. OGC Web Services architecture is based on SOA pattern and follows the Reference Model for Open Distributed Processing (RM- ODP).
OGC Web Services can be be grouped in three basic categories – data ser- vices, processing services and registry services. The components of these ser- vices share capabilities and characteristics and provides many features to sup- port distributed geoprocessing. OWS structure is based on service model ar- chitecture, in which individual services have interfaces of known types. These interface types are described in service metadata. Service metadata is that information that describes a given service and follows a existing metadata standards particularly International Organization for Standardization (ISO) 211 and OGC standards. These services metadata is then made available to the users/clients via a Get Capability request. These service metadata are queryable through services provided by Catalogs/Service Registries.
2.3.1 OWS Framework The OWS Service Framework (OSF) identifies services, interfaces and ex- change protocols that can be utilized by any application [11]. The OSF provides a common set of interfaces and encodings that span the functional parts of the enterprise to provide enterprise-wide interoperability [62]. OSF framework al- lows to build applications to common interfaces without a-priori or run-time de- pendencies on other applications or services. These applications can be added, modified or replaced without affecting other applications. Further, operational workflows can be changed or modified allowing rapid response to the critical situation. This loosely coupled, standards based approach results in a system that can be flexibly adapted to any change in requirements and technologies [11].
The OSF categorizes services into five categories, which corresponds to the OGC services taxonomy2. These categories are: application services, registry services, processing services, portrayal services and data services. These ser- vices are described in brief as follows:
• Application Services: Application services run in client terminal and en- ables user to interact and access to registry, portrayal, processing and data services. Examples of application services include discovery services,
2Geographic Service Taxonomy described in section 2.2.4
16 Chapter 2. Interoperability Framework for Sensor Web
map-viewer services, value-add services, imagery exploitation services, sensor web application services, location organizer services and mobile location services. • Registry Services: It provides a common mechanism to classify, register, describe, search, maintain and access information about data and ser- vices. For example Web Registry Service (WRS). • Processing Services: These services are the application-building-blocks services that operate on geospatial data and metadata of other services providing value-added service. Examples are coordinate transform ser- vices, geocoder services, gazetteer services, Sensor Planning Service, Web Notification Service etc. • Portrayal Services: These services provide visualization of geospatial in- formation. Portrayal Services produce rendered outputs such as carto- graphically portrayed maps, perspective views of terrain, annotated im- ages, views of dynamically changing features in space and time etc. Por- trayal Services include Web Map Service (WMS), Coverage Portrayal Service (CPS) etc. • Data Services: These services provide access to collections of data in repos- itories and databases. Data services include Web Feature Service (WFS), Sensor Collection Service (SCS), Web Coverage Service (WCS) etc.
ThereOGC are 03-040 various standard encoding formats describedOGC Reference by the ModelOGC to facil- itate interaction between these services. Geography Markup Language (GML) is an XML encoding for storage and transfer of geometric as well as feature data andBy isbuilding used applications by WFS to. com Styledmon interfaces, Layer each Description application can (beSLD built) without is XML a-priorischema or that run-time dependencies on other applications or services. Applications and services can be added, transformsmodified,GML or replaceddata without to georeferenced impacting other applications. data withIn addition, user-defined operational workflows styling. Sen- sorML describescan be changed the on-the-fly, sensor allowing and rapid its platformresponse to tim toe-criticalSCS. situations. The overview This loosely of OSF is coupled, standards-based approach to development results in very agile systems—systems that illustratedcan be in flexibly fig. adapted2.5 as toshown. changing requirements and technologies
Mobile Imagery Location Map Viewer Value-Add Sensor Web Location Discovery Exploitation Organizer Bind Service Application Services Find
GML XIMA SLD
Service Obs Data SensorML Service Device Style Metadata &Meas Registry Registry Registry Registry Image *XLS LOF Registry Services Metadata Encodings Publish
Coord. FAS CAS SCS MPS CPS Chaining Transf. Geocoder
*Directory *Gateway IAS *Mobile TPS *Route *Reverse Gazetteer Present. Determin. Geocoder Data Services Portrayal Services Processing Services
= OpenGIS Service Interface * = OpenLS Service/Encoding FigureFigure 2.5: 18 - The OWS OWS Service Service Framew Frameworkork (OSF) [ 11]
The OSF is designed to meet the following purposes: • Provide a framework for coordinated development of new and extended services • Enable interoperable services through standard interfaces and encodings • Support publishing, discovery and binding of services through service metadata 17 • Allow separation of data instances from service instances • Enable use of a provider’s service on another provider’s data • Define a framework that can be implemented in multiple ways
The OSF is a profile of the OGC services taxonomy (See Section 4.3.1.1). The OSF categorizes services into five categories that correspond to the OGC services taxonomy top-level domains as shown in Table 3.
34 © OGC 2003– All rights reserved
2.4. Sensor Web Enablement
2.4 Sensor Web Enablement
Sensor Web Enablement (SWE) is an OGC initiative to provide information infrastructure containing interoperability interfaces and metadata encodings that enable real time integration of distributed, heterogeneous and dynamic sensor webs based on web service architecture. SWE is an open platform for discovering, accessing, and controlling of all types of web-resident sensors, in- struments, imaging devices and repositories of sensor data [10]. SWE was initiated under OWS 1.1 initiative in 2001 and development continued under OWS 1.2 focusing on defining and prototyping the foundational building blocks namely Sensor Markup Language (SensorML), Observation & Measurement O&M, Sensor Collection Service (SCS), Sensor Planning Service (SPS) and Web Notification Service (WNS). Further expansion on SWE capabilities to build autonomous and robust sensor web capabilities is going on under OWS 2.0.
The aforementioned components of SWE were initially designed to fulfill the following needs [85]:
• describe sensors and platforms in a standardized way
• building a framework and encoding for measurement and observation
• standardize the access to the observation data
• standardize the process of sensor planning which consists of planning, scheduling, tasking, collection and processing
The SensorML describes the characteristics of sensors as well as the mount- ing platforms in a standardized way. The measurement and observation is en- coded in XML grammar O&M. The SCS provides a standardized interface to access the observation data. The SPS provides a standard interface to plan the collection of observations. Further, a new standard was developed for a notification service which transmits asynchronous messages. The WNS sends asynchronous messages to the user indicating whether the requested observa- tion operation was successful, delayed, canceled or failed. These components are described in detail in the following sections. The interaction sequence of SWE components is represented in the following figure: 2.6.
2.4.1 SensorML SensorML provides a model and XML schema encoding for defining the geo- metric, dynamic and observational characteristics of a sensor. SensorML pro- vides a functional model for sensors but not a detailed hardware specification. SensorML supports wide range of sensors including in-situ and remote sensors as well as both dynamic and stationary sensor platforms. The purpose of Sen- sorML is to [9]:
• provide general sensor information in support of data discovery
18 Chapter 2. Interoperability Framework for Sensor Web
Figure 2.6: SWE Sequence diagram adopted from [97]
• support processing and analysis of the sensor measurement
• support the geolocation of the measured data
• provide performance characteristics like accuracy, threshold etc.
• archive fundamental properties and assumptions regarding sensor
The root element of all SensorML document is a sensor or sensor group and is represented by a unique identifier which allows to link to sensor’s description and use its properties. The core components of sensor description are described in the following paragraph.
Basic sensor identification properties such as a unique id, name and sensor type is provided by the identifiedAs property. The constraints on sensor document instance are listed in documentConstrainedBy property. The con- straints include time of observation of sensor description, legal constraints and
19 2.4. Sensor Web Enablement
level of security of the document. The measurement characteristics of of an ob- servable are described by the measures property which takes Measurand as its value. The Measurand describes the observed phenomenon as well as provides the information required to process, analyze and geolocate observations. These three properties (identifiedAS, documentConstrainedBy and measures) are required properties. The others described here after are optional and a sensor description need only contain properties that are relevant to particular sensor type or purpose [9]. The platform of the sensor to which it is mounted on is pointed by attachedTo property. The hasCRS property links to or defines sensor’s local coordinate reference system. This property either links3 to an ex- ternal GML schema or defines an EngineeringCRS as its value. The location of a sensor or a platform is provided by locatedUsing property. Besides the location, this property also provide the state of the sensor (orientation, veloc- ity, acceleration and rotational acceleration). The operatedBy property gives information regarding the party or parties responsible for operating the sensor and managing the data. This property also provides a service URI to a SPS for this sensor. The describedBy property provides general metadata including manufacturer, responsible party, model, identification, deploying agency as well as reference document. The design of sensor description and the history of the document are recorded in the documentedBy property.
Platform schema defines a means of defining a coordinate reference system which assists in determining the geographic and orientation of the sensor as well as the geolocation of observation. Platform has several properties identi- cal to Sensor schema as well as further contains links or definition to Sensor or other platform instance. A collection of sensors is defined by SensorGroup type and includes SensorArray and SensorPackage. The SensorArray is a set of sensors of the same type at different locations and produces an array of like measurement. The SensorPackage provides derived measurement based on the collection of multiple heterogeneous sensor measurements. The Figure 2.7 below illustrates a sensor as an aggregation of aforementioned properties.
2.4.2 Observations & Measurements Observations & Measurements (O&M) Engineering Specification [24] describes a conceptual model to represent sensor observations and measurements in XML based encodings. O&M was initially originated under OWS 1.1 initiative and has undergone significant enhancements under OWS 1.2. The current ver- sion under OWS 1.2 is fully harmonized with GML 3.0 and its observations are based on GML observation encodings as well as contains quality measures associated with them [24].
Some terminologies associated with O&M are described here:
• Observable: A phenomena that can be observed and to which values are assigned such as temperature, pressure, chemical concentration, number
3Links through xlink:href
20 Chapter 2. Interoperability Framework for Sensor Web
Visual Paradigm for UML Community Edition [not for commercial use]
Identifier Measurand CoordinateReferenceSystem AssestDescription
1 1..* 0..1 identifiedAs measures hasCRS 0..* describedBy AttachedPlatform
carries DocumentMetaData 0..1 Sensor 0..1 attachedto documentedBy 0..1 Platform 1..* Constraints 1..* documentConstrainedBy carries member 1..*
0..* 0..* operatedBy ResponsibleParty locatedUsing LocationModel SensorGroup
SensorModel SPS Responsibility SensorArray SensorPackage
Figure 2.7: UML Class diagram representing sensor in SensorML adopted from [94]
of individuals etc.
• Observation: An instance of a procedure which contains number or other symbols/figures related to the phenomena such that the number or symbol represent the attributes of the phenomena being observed.
• Value: Value is an element of the value space belonging to a datatype. It may be represented in one of the scales including nominal, ordinal, ratio and interval, spatial and temporal. Primitive data types may be combined to form aggregate datatypes with aggregate values.
• Observed Value: An estimate of value describing a phenomena which is characterized by its observable and may include other properties like qual- ity measures. The term is used regardless whether the value is measured by an instrument, derived by theoretical model, subjective assignment or some other method.
The O&M contains three conceptual models related to the observation, ob- served value and the observable. The observation model describes the structure of observations and observation collections. The results of these observations are represented by the values defined in value model. The phenomena model defines the structure of phenomena that are the subject of the observations. These models are described in brief in the following sections:
21 2.4. Sensor Web Enablement
Observation Model An Observation is modeled as a basic Feature type4, in which one of its properties is resultOf whose value is a ValueObject5 describing some phe- nomena. An Observation has a timeStamp since the observation feature describes an observation event. An Observation has a using property, which describes the Procedure such as instrument or observer. A model of functional description of instrument (sensors) is given in SensorML. An Observation is semantically represented using an Observable property, which defines the Phenomenon being observed.
The association of an Observation with other Features such as observa- tion collection, previous observation, previous observation which is the basis for new observation, reference point etc is modeled using relatedFeature asso- ciation class with a role attribute. A common related feature such as a station or a specimen is a subject of observation, so such common related features have fixed role target. The quality indicators of an Observation associated with it is represented by QualityDescriptor. The Observation also contains the metadataProperty and location properties.
Composite observations may be aggregated into a collection using an Obser- vationCollection, which can be treated as Observation. The Observa- tionCollection uses the relatedFeature, timeStamp and target proper- ties to accommodate common items in the collection. Ordered, homogeneously typed observations in ObservationCollection is an ObservationArray, which may carry observable property inherited by all its members. An Obser- vationArray is a representation of a DiscreteObservationCoverage, in which the values of the set of location and timeStamp properties define the domain set of the coverage.
Value Model As described earlier, value refers to the magnitude of a quantity expressed in ordinal, nominal, ratio or interval scales. Values my also combine to form an aggregate value. The value model refers all of these as ValueObjects. The primitive or scalar values occurring in different aforementioned scales are modeled as a small number of generic data types Category, Quality, Count and Boolean, which are derived from an abstract super class ScalarValue. The list or ordered set of values using the same scale is modeled using Ca- tegoryList, QuantityList, CountList and BooleanList on the basis of equivalent scalar values mentioned above. Certain values like spatial position and time instant are special forms of ordinates in interval scale (e.g. coordinate system). Such special datatypes are modeled using special components. To accommodate the appearance of spatial and temporal objects within the same context of scalar values, the components are grouped into a generalized class
4Feature type as described in section 2.2.4, Open Geodata Model (OGM) 5Structure of ValueObject is described in the following section
22 Chapter 2. Interoperability Framework for Sensor Web
Figure 2.8: UML Class diagram representing the Observation Feature in O&M [24]
Value and a union class ValueObject as shown in fig. 2.10.A Null object is provided to support the values which are absent.
Aggregate values are the values with complex structure composed of mul- tiple components. The component of these aggregate values may be related and will be simultaneously changed by any transformation. These components may be scalar values or other aggregates. These aggregate values are modeled using CompositeValue and represents Value in the case of aggregate val- ues. Such CompositeValue has a tree structure and has nodes each bearing Value, ValueList, Geometry and TimeObject. ValueArray is an ordered collection in which each member is of the same type and is formed by arrays of CompositeValue.
Value has a special attribute axis, which associates the Value (including ScalerValue, CompositeValue and ValueArray with the phenomena being observed. The mapping of the semantics of the phenomena is done using the TypedValue. One or more quality descriptions may be associated with the
23 2.4. Sensor Web Enablement Visual Paradigm for UML Community Edition [not for commercial use]
<
<
0..1 0..1 ObseevationArray Procedure using Target target {TimeSeries: count(Procedure)=1} timeStamp DiscreteObservationCoverage SensorCollection TimePrimitive 0..1
SensorArray {SpatailCoverage: Procedure=SensorArray}
Figure 2.9: UML Class diagram representing Observation Collection & Coverage in O&M [24]
observed Value. The QualityDescriptor may contains five specific methods namely Description, Rank, Error, Bounds and Errors.
Phenomena Model The value of the observable can only be evaluated with reference to the ob- served phenomenon. Thus the phenomena provides the conceptual definition of the observation and its results. A phenomenon may have description on various scales or reference systems. Conversely, different phenomena can be represented using the same scale. Considering this pattern, there seems to be an association between the scale of measurement and the phenomena. How- ever, the correspondence is not one-to-one. Both the scale and the phenomena are the part of the description of an observed value. Therefore, the phenomena is defined separately from the scale or reference system and needs semantic definition. O&M Phenomena Model assumes that an appropriate definition of each of basic phenomena is available and represented using URI. The primitive phenomena maybe refined or combined in systematic way to form parameter- ized or composite phenomena provided that the definition of scalar or primitive phenomena are available.
A ParameterizedPhenomenon is based on base Phenomenon and applies one or more constraints in TypedValue defining an axis and a value. The resulting paramaterised phenomena is derived from a set of more primitive phenomena indicated by the base phenomenon and the value of the axis in each of the constraints. A CompositePhenomenon is constructed from com-
24 Chapter 2. Interoperability Framework for Sensor Web
Figure 2.10: UML Class diagram showing Scalar Value & Composite Value for aggregate model in O&M [24] ponentPhenomena using composite pattern. Alternatively, it can also be con- structed using base phenomenon and applying one or more constraintsSets. This set may be expressed explicitly as a TypedValue set which follows the valueArray pattern described earlier.
2.4.3 Sensor Collection Service Sensor Collection Service (SCS)[67] is an interoperable web-based interface that provides standardized access to sensors or sensor data archives. Develop- ment of SCS was initiated during OWS1.1 and has continued through OWS1.2 with objectives to
• support access to variety of sensor and observation types
• support heterogeneous sensor collection
• process observation requests to get real/near real time, forecasted and/or archived observation from one or more distributed sensors
• support capabilities to discover
• support SPS
A SCS can be considered as domain specific specialization of WFS, which supports time variant data [97]. However, in contrast to WFS specification, which support information encoded in GML only, the SCS specification supports
25 2.4. Sensor Web Enablement Visual Paradigm for UML Community Edition [not for commercial use]
Phenomenon 0..* compositePhenomena description : text basePhenomena id : identifier 0..1 name : char
basePhenomena
ParameterisedPhenomenon CompositePhenomena Either ComponentPhenomenon(s) or (basePhenomenon + constraintSet(s)
constraintSet 0..* constraint 1..* <
Figure 2.11: UML Class diagram showing Derived Phenomena & Composite Phenomena [24]
information in accordance with O&M. This information being the observation, which is a specialized form of geographic feature as described earlier in section 2.4.2.
SCS uses similar operations as WFS and WCS to describe service capabili- ties, station types and individual stations. GetCapabilities operation pro- vides SCS metadata in machine and human form containing description of the service information content and acceptable parameter values. Describe oper- ations viz. DescribeSensor and DescribeSensorPlatform describes the characteristics of the sensor and the platform. These describe operations return XML instance documents encoded in SensorML.A DescribeSensorPlatform operation can be queried for a list of sensors, which can be used to define the DescribeSensor operation. A DescribeSensor operation, in turn, pro- vides a list of observables that support the request of observation data for GetObservation operation. A GetObservation operation retrieves obser- vations from a SCS.A GetObservation request is processed by a SCS and re- turned with the resulting observation(s) in O&M encodings. A GetObservation operation has several parameters, which provide a distinct identification of an observation with respect to spatial and temporal extent as well as platform and sensor. Further these parameters support for querying specific observation(s). These parameters and their brief descriptions are presented as follows. • BoundingBox: It defines certain spatial extent for which observation(s) is requested. The value of BoundingBox is given by a set of coordinates in a form of minx, miny, maxx, maxy. It helps to define and query observations of certain SCS(s) within the area of interest. • Time: It defines time instance and/or time interval of the observation. This allows SCS to support temporal data description and request, mak-
26 Chapter 2. Interoperability Framework for Sensor Web
ing it possible to query for observations occurring at certain instance or period of time.
• SensorID: It defines the identification of a sensor or a collection of sensors, which allows observation request from a specific sensor or collection of sensors.
• PlatformId: Identifies the platform of the sensor(s). Identification of plat- form makes it possible to query for required specific platform only.
• Query: Defines a set of restrictions on the basis of above mentioned para- meters to request for observation(s) from SCSs.
2.4.4 Sensor Planning Service Sensor Planning Service (SPS)[61] provides a standard interface to manage sensor assets and the support system that surrounds them. SPS is designed to handle different kinds of request processing systems, which may or may not provide access to the different stages of planning, scheduling, tasking, collec- tion, processing, archiving and distribution of observation data. The collection request, execution of measurement and the delivery of observation take certain time period. Such long term transaction often involve more than one OGC oper- ation and services as well as non-OGC legacy support system for management. Such asynchronous transaction may involve feasibility request and response, collection planning, collection execution, observation notification and observa- tion delivery. Further, these operations may require the client to be able to track the progress, update the request as well as cancel it. SPS supports these operations with the help of other service WNS.
The SPS has two kinds of operations - information and functional operations. The information operations GetFeasibility and GetStatus provide neces- sary information to the users, whereas the DescribeCollectionRequest op- eration provides information to the assets management system. The functional operations GetFeasibility, SubmitRequest, UpdateRequest and Cancel- Request operations provides functionalities to the user.
The GetCapabilities operation describes the capabilities of the SPS, which includes the sensor encased by it, support for request tracking, support for as- sets planning, support for collection request as well as support for access to supporting tools. The DescribeCollectionRequest operation provides SPS client with necessary information in order to allow the user to prepare a collec- tion request on selected assets supported by the SPS. The information includes the exact syntax, possibilities of parameterization and contentwise constraints, which enables client application handling the assets to execute the observa- tion [97]. The GetFeasibility operation provides feedback to a user about the feasibility of a collection request. This operation enables to examine the validity of the contents of the collection request as well as availability of nec- essary resources. The SubmitRequest operation formulates and submits the
27 2.4. Sensor Web Enablement
request for the collection in accordance with the information provided by the DescribeCollectionRequest operation. In certain cases, previously submit- ted collection request has to be updated as for instance adjustment of boundary conditions and/or adjustment in interval of collection. The UpdateRequest op- eration allows such updates on previously submitted collection request. The CancelRequest operation aborts the collection procedure as well as termi- nates it. The GetStatus operation gives the status of the assigned collec- tion procedure. It enables the user to monitor the progress of the collection procedure as well as indicates if the requested collection is awaiting for execu- tion or is aborted/terminated. The status of collection procedure provided by GetStatus operation allows the user to update the collection request accord- ingly if required.
The aforementioned operations of the SPS and their interactions are illus- trated in a UML sequence diagram in fig.2.12
Figure 2.12: UML Sequence diagram showing the interactions of SPS operations. Adopted from [61]
28 Chapter 2. Interoperability Framework for Sensor Web
2.4.5 Web Notification Service The Web Notification Service (WNS)[84] specification defines interfaces that provides functionalities for the notification to the users/services. The WNS in- terfaces provides means to request information describing its capabilities, al- lows user registration, allows submission of simple synchronous user notifica- tion as well as for asynchronous user-service or service-service communication. The collection request involving SPS, that requires feasibility planning, control and management activities and intermediate and/or subsequent user notifica- tions of the status of the requested job needs an asynchronous communication support provided by the WNS
The WNS can send its messages through one of the channels described in its capabilities. These communication channels may include e-mail, HTTP Post, Short Message Service (SMS), instant message, phone call, fax or letter. The user/service registers for a service with the WNS, providing registration infor- mation about the user identification and channel of communication. Upon the confirmation of the registration, the WNS provides a registration identification, which is used as a reference to the user/service.
The WNS communicates with the user/service in two ways. The one-way- communication, simply provides the user/service with a notification message. Whereas, the two-way-communication provides the user/service with a message which requires recipient to acknowledge with some asynchronous response. The details of these communication patterns are described in the following para- graphs.
One-way-notification It is the simplest form of WNS notification. It facilitates the registration of client/user through registerUser operation and sends notification messages to the client/user through doNotification operation. The following UML diagram illustrates the one-way-notification pattern.
The doNotification request results with status report stating whether the notification was sent successfully, notification sent unsuccessfully or notifica- tion timed out.
29 2.4. Sensor Web Enablement
Figure 2.13: UML Sequence diagram showing One-Way-Notification [84]
Two-way-notification The two-way-notification is an enhanced WNS and has capabilities of one- way-notification and additionally provides the interface to receive responses by the user. The two-way-notification realizes a dialogue between the user and WNS through doCommunication operation. The user/client replies to the WNS through its call-back interface doReply. This reply from the user is then passed over by the WNS to the initiating service. However, at present, the call-back interface getReply is not entirely supported under OWS 1.2. This implies that the calling OGC service should be able to receive user response di- rectly without the aid of WNS. The two-way-notification pattern is illustrated by the following UML diagram.
30 Chapter 2. Interoperability Framework for Sensor Web
Figure 2.14: UML Sequence diagram showing Two-Way-Notification [84]
2.5 Synopsis
The SDI has evolved from a static concept addressing organizational need for homogeneity in data and systems that support data dissemination to dynamic and heterogeneous nature that addresses incorporation and interoperability be- tween disparate systems and components to form a business process. This evo- lution has enabled seamless integration of novel services such as sensor web into its technological framework. The technical base provided by distributed GI-Services embedded into SDI framework enables interoperable and modular software components to provide users with an access to distributed geoprocess- ing functionalities and spatial information resources through an open and stan- dardized interfaces.
ISO/TC 211 and OGC are forerunners in spatial information domain to in- stigate industry standards for distributed GI-services to achieve openness and interoperability. The standardization of distributed GI-Service domain provides a high level service framework to integrate novel services such as sensor web into an existing SDI infrastructure. The integration of sensor web into SDI will bring about a new dimension in spatio-temporal information dissemination. The up-to-date availability of temporal information provided by sensor web via open services and integration of this information with existing GI-services will
31 2.5. Synopsis
culminate in a new level of Spatial Decision Support System (SDSS).
OGC’s Sensor Web Enablement (SWE) initiative is a step towards achieving interoperability between disparate GI-Services and sensor web resources. OGC has developed mature specifications to address sensors and supporting plat- form as well as encoding for observation in a formalized manner. SensorML and O&M specifications addresses characterization of sensor/platform and ob- servation encodings respectively. Other supporting standardizations to support access to observations, planning for observations and notification of observa- tions respectively through SCS, SPS and WNS are currently under develop- ment and public discussion. The integration and collaboration of these services with existing GI-Services will result in a dynamic knowledge base for SDSS for temporal critical application domains.
32 Chapter 3
Sensor Web for Spatio-Temporal Decision Support
Malczewski [63] defines Spatial Decision Support System (SDSS) as
“An interactive, computer-based system designed to support a user or group of users in achieving a higher effectiveness of decision making while solving a spatial decision problem.”
The concept of SDSS, has over the years emerged as the leading paradigm for addressing complex spatial problems offering a higher effectiveness in decision making by incorporating the decision maker’s judgment and computer-based programs into the decision making process. The computer-based system helps the user to explore the decision problem in an interactive and recursive fashion in all phases of decision making process. Utilization of SDSS for complex spatial decision making involves incorporation of appropriate spatial data into decision making process: a double sided process requiring access to spatial data, as well as access to the supported decision process by decision makers [38].
The first process of access to spatial data concerns the issues of data discovery and cataloging, maintenance, quality, metadata, exchange standards, scale and dissemination [38]. The technological as well as institutional and legislative framework in SDI provides a firm platform for data discovery and dissemina- tion, keeping in the view the aspects of distributed access, quality and stan- dards for cross-system and cross-institutional connectivity with a high degree of interoperability. The second process, access to the decision support system relates to open access and utilization of decision support tools. Traditional GIS applications are often utilize to support decision making process and are con- sidered as SDSS tools [98]. However, upon closer examination, spatial decision support requires specialized analytical functions, which typically exceeds the functional range of common GIS applications [78]. The functionality of GIS based SDSS can be extended by incorporating the analysis, optimization and
33 3.1. Sensor Web in Emergency Management
evaluation capabilities of SDSS into the SDI framework. This would require improved and up-to-date availability of spatio-temporal information acquired either through measurement or simulation [98].
Many of decision support application domains related to the environment depends on the availability of high resolution temporal information. For in- stances, temporal critical decisions for environmental disasters like flood, land- slide, earthquake, forest fire, chemical and toxic spill etc needs high volume of up-to-date spatio-temporal data to monitor and predict the dynamics of such phenomena. Sensors mobilized in strategic locations help monitor and collect data related to such phenomena and the network connecting these sensors pro- vides real/near real time access to the collected information. In this context, the sensor web provides vital spatio-temporal data required for such a saptio- temporal decision support.
This chapter builds up a basis for this research work illustrating a use case scenario of emergency management in flood situation. Extending on the concept of early warning system for flood management described in section 1.2, this chapter further elaborates the scenario and investigates on the requirements of such a service.
3.1 Sensor Web in Emergency Management
Emergency management is a prescribed system how societies respond to dis- asters [26]. It consists of a cycle of activities beginning with the mitigation of the vulnerability and negative impacts of disaster, preparedness in response to operation, response and providing relief in emergency situations and aiding in recovery, which can include physical reconstruction and ability to return quality of life to a community after a disaster [77]. The recent advances in GI Science and ICT has enabled the utilization of GIS, remote sensing, GPS and related technologies in emergency management, which has considerably improved dis- aster management through facilitating data capture, integration and analysis. The integration of these technologies with each other and with other technolo- gies such as SDSS, World Wide Web (WWW) and simulators has created more effective disaster management [77].
The methods, models, processing and visualization techniques provided by the aforementioned technologies have proven to be extremely valuable tools in pre-disaster planning, crisis management and post disaster recovery. However, on the other hand, the issue of necessary and timely data required for such tools still remain a bottleneck. According to Radke et al. [76], data acquisition and integration is the single largest contribution area needed for emergency preparedness and response. The dynamic nature of disasters and emergency situations require highly dynamic temporal data for accurate modelling of such phenomena and effective planning and management. There is a critical need for real-time data and information, a temporal requirement that often cannot
34 Chapter 3. Sensor Web for Spatio-Temporal Decision Support be met in the field [26]. The disaster phenomena undergo spatial and natural conditions change from moment to moment, which increases the level of uncer- tainty in its analysis. For instance, using un-updated data in flood forecasting would lead to the faulty conclusion. This temporal uncertainty in emergency management of disasters demand high resolution temporal data.
In this context, spatially enabled sensor web network provides a framework for collecting high temporal resolution data and dynamic dissemination of col- lected information. This enables decision makers, emergency managers and others to make effective decisions in temporal critical application domain as emergency management, thus reducing the loss of lives and properties.
3.2 Use Case Scenario–Flood Management & Early Warning
Recent flood events in Europe, including the 1993 and 1995 events in the Rhine and Meuse basins, the summer floods of 1997 and 2002 in the Oder, Elbe and Danube basins and the UK floods of 2000/2001 have raised interest in the provision of flood warning in an effort to reduce losses of property and lives [79]. In recent years, various flood forecasting methods and systems based on data collected by meteorological and hydrological stations, weather radars as well as satellites have been developed and implemented. These flood forecasting systems typically use hydrological models to predict short term flood evolution due to a combination of recent and forecasted precipitation with the objective of increasing the lead time with which warnings can be delivered [96]. Lead time, in the context used here is the time gap, in which reliable warning can be given of imminent flooding.
The most widespread flood warning system is an operational flood warning systems and there are many different approaches for its implementation [96]. Operational flood warning and other traditional systems are typically embed- ded within or integrated with flood prediction and forecasting systems. Further, these prediction and forecasting systems are based on statistical and probabilis- tic approaches. As such forecasting models employ complex hydrological and meteorological models/methods, the warning system also gets complex. In one hand, such complex methods lead to more accurate forecasting and subsequent warning enabling greater lead times. On the other hand, such fluvial fore- cast and warning relies more and more on prediction of future rainfall rather than downstream propagation of water already in drainage system [96]. The main characteristic of an operational flood warning is that rather than target warning at the public, pre-warnings are targeted at operational staff of the established flood forecasting system, which makes the use of traditional fore- casting systems easier and effective as these staffs are assumed to have good understanding of flood prediction [96]. However, a foreseeable drawback is that such pre-warnings are not directed to the emergency management personnel or
35 3.2. Use Case Scenario–Flood Management & Early Warning
emergency decision makers, who presumably don’t have any technical knowl- edge of forecasting that would help to provide emergency support.
Despite the apparent variety of approaches, the process of flood warning ba- sically consists of four important steps [72] as shown in figure 3.1.
Detection Warning Response
Forecasting
Figure 3.1: Flood Warning Process [72] > threshold value
• Detection Detectionstage consists of monitoringWarning of real-timeResponse data that could gen- erate a flood event. Monitoring includes hydrological and meteorological data collected through ground based stations, climate stations, weather radar, satellite imagery etc.
• Forecasting stage uses the data and information gathered in detection stage to predict level of flow as well as the time of occurrence of an en- suing flood event. Generally, forecasting involves the use of hydrological and meteorological models based on real-time data gathered in detection stage and forecasted meteorological conditions such as rainfall and tem- perature [96].
• Warning stage utilizes the information derived from the detection and forecasting stages and issue a warning to appropriate authorities and/or property at risk. The warning must be an unambiguous message on the imminent flood potential [96].
• Response to the flood warning includes flood damage control measures such as flood control reservoir, stock piling emergency supplies, evacua- tion of people and mobilising emergency services.
Flood forecasting is a prominent stage in these four stages and warning and response depends on it. However, the most basic forecasting systems do not include an explicit forecasting step and issue flood warnings on the basis of observations such as gauged rainfall and flows [21]. Such a basic system is typically based on exceedance of certain threshold value of hydrological and/or meteorological parameter. In this case, a warning is triggered when one or more parameters are exceeded. This enables technical as well as non-technical decision makers to better understand the flood situation.
In recent years GIS based hydrological models using radar-rainfall as input to produce flood depth forecasting and issue site-specific warning have widely been used [56]. GIS provide tools for collection, archival and processing spatial
36 Chapter 3. Sensor Web for Spatio-Temporal Decision Support data on watershed drainage systems, soil and landuse, location of facilities at risk as well as delineation of hazard zone due to flooding. Examples of GIS applications used in flood warning are PoldEvac, DISMA, the dyke informa- tion system North-Rhine/Westphalia and he GIS Zurich [99]. These GIS based warning tools, however, are legacy system based and does not support integra- tion of real/near real time data, which is crucial for effective flood forecasting and subsequent warning.
3.2.1 Role of Sensor Web Spatially enabled web of in-situ sensors distributed over a river basin col- lecting real/near real-time data and transmitting the data through network in- frastructure will provide extremely up-to-date data needed for flood prediction and issuing warnings. The benefit of sensor web architecture is that the mea- sured data is processed and interpreted collocated with the instrument so that real-time decision can be made based on the data the sensor is receiving [1].
Framing the aforementioned use case scenario of flood management and early warning in sensor web framework, a novel service capable of triggering an alert notification basedDetection on user thresholdWarning rules is needed.Response This service accepts user threshold rules for flood situation and triggers a warning when the threshold value defined in the rule is breached, thus eliminating the need of complex forecasting phase as shownForecasting in figure 3.2.
> threshold value
Detection Warning Response
Figure 3.2: Flood Warning Process based on threshold rules
3.3 Rule Based Alerting Service for Sensor Web
A new web service is designed within OGC’s OWS framework to dispatch alert notifications to the clients when given alert conditions are met. The de- signed service extends the current SWE specification and is based on OWS 2 testbed’s Web Alert Service (WAS) vision. The rule based approach allows to filter observed data and process only those which are relevant. This eliminates superfluous processing of data, which otherwise consumes unnecessary over- head in sensor resources, supporting services and network. This is more signif- icant in real world scenarios like flood management and early warning, where delay or failure in delivery of data may prove critical.
Rule based approach expresses the domain knowledge by means of rules [83]. The term “rules” in this context is used as constraint conditions in physical,
37 3.3. Rule Based Alerting Service for Sensor Web
spatial as well as temporal parameters. For aforementioned use case scenario, the constraints in physical parameters such as river gauge level, precipitation, moisture etc, which have direct influence in flooding in river. Spatial constraint might be the extent of the river basin under consideration, the location of river level gauge or /and precipitation sensors. Similarly, the temporal constraint might be the duration of precipitation which influences the rise in water level in the river. Based on these kinds of constraint rules, a rule based approach can be used to identify flood situation and dispatch alert notifications. For our scenario, a simplified rule based approach based on threshold value exceedance can be applied as illustrated in examples below: • Example 1: if river gauge level exceeds threshold value of 3.5 m in certain reach of the river, send alert message. • Example 2: if precipitation in certain area exceeds 50 mm in 24 hours and river gauge level exceeds 3.5 m, send alert message. • Example 3 if the average of river gauge levels distributed over certain area exceeds 4 m, send alert message
In our use case scenario, the threshold values in the rules are kept open as a specific river basin or a river is not considered. In the case of a particular river basin, the threshold value for river level varies at different location of observa- tions along the river reach. River gauge level is also influenced by amount of precipitation in the basin, its duration and time taken by surface runoff and sub-surface runoff to reach the main river course, where the observation is taken. In the case of specific river and associated SCSs, it is advisable to include the minimum and maximum threshold values of the observation para- meter such as river gauge level, in the service’s GetCapabilities operation. This enables user/client to evaluate flood scenario and define threshold rules more specifically.
Typical emergency use case scenarios as flood early warning, requires a proac- tive and efficient data transfer mechanism for effective operation. However, cur- rently implemented OGC ’s web service architecture based on pull/poll mecha- nism does not support such a proactive transfer mechanism. The service trad- ing architecture based on data pulling shows significant shortcomings if an ac- tive dispatch is required, in the case if the measurement value has to be imme- diately distributed if it exceeds a predefined threshold [85].
A proactive web service is designed, which is capable of actively pushing data or alert notification upon validation of the threshold rule. To achieve loose cou- pling and heterogeneity between disparate components and services, a syner- getic approach is considered, which extends the traditional service-trading ar- chitecture by event based patterns to support push based data transfer mech- anism [85]1. This proactive service capable of dispatching an alert notification
1Push data mechanism and event based communication pattern is described in subsequent sections
38 Chapter 3. Sensor Web for Spatio-Temporal Decision Support upon the fulfilment of user defined flood scenario rules is named as Active Web Alert Service (AWAS).
3.3.1 General Concept
AWAS is designed based on web service standards on top of event based com- munication model. It assumes the role of user interface to the alerting service scenario. A user/client subscribes to the service by registering the user profile providing with communication address and preferred communication channel (email, SMS, telephone etc). This subscription acts as a contract between the service and the user. Upon successful user subscription, the service returns the user with a unique UserID as user identification. This enables the user to pro- ceed to the second step of registering flood threshold rules. The registered rule is then passed as event filters 2 to underlying event service. Relevant SCS(s) collecting observation data for flood scenario (i.e. river level gauge sensors, pre- cipitation sensors etc) publish their data as event notifications3 to the event service. An event service4 acts as a black box and is responsible for the com- munication between the AWAS and related SCS(s). This communication occurs indirectly and anonymously through the transaction of event notifications. It is the responsibility of event service middleware to match the event published by SCS(s) to the event subscribed by the AWAS. The published event repre- sents the observed data by SCS(s) and the subscribed event represents the user registered rule in AWAS.
A successful reception of event notification by the AWAS represents that the user rule has been satisfied, that is, flood threshold values has been breached. In this case, the AWAS parses the event notification to translate the received event notification to a meaningful alert message. The alert message gener- ated is then sent to the user via WNS. The fundamental concept of the service is illustrated in UML notation as shown in figure 3.3. The figure shows the conceptual view of AWAS, incorporating event notification service and SCS(s), other incorporating services viz. SCS and WNS are not shown at in the figure for simplicity.
In a case of unsuccessful user subscription or rule registration due to unavail- ability of SCS(s) event publication or the desired phenomenon is not supported or any other errors, the user must be informed with a failure notice. The service should also have possibility to update rules as well as to unsubscribe from the service if the user is no longer interested in receiving the alert notifications.
2Described in section 4.1.5 3Described in section 4.1.4 4Described in section 4.1.7
39 3.4. Requirements
Figure 3.3: Conceptual Model of Alert Notification Service in UML use case diagram
3.4 Requirements
Based on the above concept, the requirements are drawn for the following issues.
3.4.1 Rule Registration The rules pertaining to the flood scenario are registered in the service by the user. These rules are then parsed are to form event filters to be subscribed with an underlying event service. Representation of these rules require proper structuring and formalization as well as proper encoding to achieve a degree of semantic interoperability.
Formalization of Rules The integration of knowledge bases into a web service require functionality on different stages of the exploitation process [83]. To add meaning and metadata that are human and machine usable, it is required to represent the knowledge domain in a standardized formal machine-readable manner. Ontology, a for- mal explicit specification of a shared conceptualisation fulfills this requirement [54]. Ontologies represent semantics of a particular domain in a network via properties of concepts and relationships among these domain specific concepts [57]. The ontology specifies relevant domain concepts, properties of those con- cepts -including, where appropriate, value ranges or explicit sets of values and possible relationships among concepts and properties [54].
40 Chapter 3. Sensor Web for Spatio-Temporal Decision Support
Flood management and early warning depends on effective use of task spe- cific knowledge. Semantic representation of online data/information related to flood management domain knowledge in an intuitive non-logical description language will support the location and retrieval of such task-specific knowl- edge through intelligent agents/services, which allows to perform context aware queries [57]. The definition of system ontology by a controlled, hierarchical vo- cabulary for describing domain knowledge [66] will enable the service and end users to use a common language to represent the knowledge, thus eliminating the semantic ambiguity.
Various researches and works have been undertaken to represent flood man- agement domain. Among them, Kampf¨ et. al [57] have implemented an on- tology into an intelligent agent system to support flood-risk management. An- other successful implementation of ontology based definition of flood manage- ment knowledge domain is by Mazzetti et. al [65, 66]. The later work defines a taxonomy that is the vocabulary of basic terms defining the decision maker’s view about the flash flood emergency early warning. The ontology in this work is the collection of the information about the relationship between basic terms in the domain. It distinguishes between the ontologies of the basin realm, the rainfall event realm, the rainfall map and the rain gauge network domain.
In our case of rule based alerting, the ontologies of the knowledge domain require further extension to incorporate user rules in the domain parameters. Standardization and formalization of rules will enable to integrate various data sources5 and the rules pertaining to the parameters related to these data sources. The formal representation of the flood management knowledge domain based on the integration with OWS components is yet to be realized.
Encoding of Rules
The user defined rules pertaining to the threshold conditions can be encoded in XML in conformance to the OGC Common Query Language (CQL) as a sys- tem neutral representation of the rules in Structured Query Language (SQL) query like predicate. A filter expression can be used to constraint the property values of an object type to identify a subset of object instances to be operated upon in some manner [93]. A value corresponding to the threshold rule is a sub- set of property values of an object observation. This subset corresponding to the threshold rule can be encoded in OGC’s Filter Encoding [93] as similar to defining a query constraints in GetFeature operation of a WFS. Filter En- coding expresses predicates in XML on the basis of CQL specified in OGC’s Catalogue Interface Implementation Specification [93]. The encoding of user rules in Filter Encoding enables to pass the rules to other OGC services and make query or request for data.
5SCS(s), WMS, WFS, simulators etc
41 3.4. Requirements
Filter Encoding [93] contains
The spatial operator tests whether the value of geometric property satisfies the spatial relationship implied by the operator [93]. The geometric property is referenced using the property name and geometric literal value expressed in GML. In spatial operator,
The example given in section 3.3 can be expressed in XML Filter Encoding as illustrated in Appendix A.1
3.4.2 Communication Model An efficient communication pattern is necessary between the data sources6 and the alerting service. OGC services based on pull data model doesn’t support proactive dispatching of data as in the case required in emergency warning scenarios, where data must be dispatched when certain event occurs. A push model overcomes the synchronous request/response pattern between the client and service by allowing asynchronous data dissemination [49]. Push model corresponds to a event-based7 system, with which the components communicate over the asynchronous exchange of events.
Pull / Push Model In the traditional OGC service model, data is synchronously provided by a service upon request [85]. Following this model, SCS provides sensor observa- tion data upon GetObservation request by the user/client. Considering the
6 SCS(s), WMS, WFS etc 7Described in chapter 4
42 Chapter 3. Sensor Web for Spatio-Temporal Decision Support current SCS architecture model, the client AWAS has to query the relevant SCS (s) through GetObservation request in our use case scenario. In this context, the AWAS has to periodically request the SCS for the observation. The data pull model implemented here requires the AWAS to issue observation re- quest periodically in certain time interval (e.g. every 30 minutes interval). This method of request/response consequently increases the volume of transmitted data and consumes unnecessary network bandwidth as well as increases the workload of underlying SCS(s) and AWAS. The network traffic and simulta- neous multiple requests results in data latency or even failure to deliver data [94], which might prove critical in case of flood early warning. Other significant shortcoming of pull data model is failure to transmit the data instantaneously when certain event occurs. For example, a service pulling data in every thirty minutes interval fails to recognize a significant fluctuation of data between this time interval. In case of flood scenario, a SCS will fail to transmit data if a sudden rise in river gauge level occurs in the 25th minute of 30 minute request interval. This failure to transmit the data may prove critical in flood warning process.
A push data model, on the other hand, proactively transmits data only when certain event or condition occurs. In the flood scenario use case, when certain threshold value of flood parameter exceeds, a push enabled SCS proactively dispatches the observation data to the client. A proactive SCS -Active Sensor Collection Service (ASCS)[94] extends the current SCS to dispatch observation data actively.
3.4.3 Encodings of Alert Messages
The alert message generated after parsing event notifications must be en- coded in a generic format for exchanging all hazard emergency alerts and pub- lic warnings over all kinds of networks. Such encodings must be done in an open, non-proprietary standard data interchange format that can be used to collect all types of hazard warnings. Common Alerting Protocol (CAP) is an XML based messaging framework for emergency alert notifications that can be used to encode parsed event notifications into a meaningful alert messages.
Common Alerting Protocol (CAP)
The Common Alerting Protocol (CAP) [8] provides an open, non-proprietary digital messaging format for all types of alerts and notifications. The CAP for- mat is compatible with web service framework and can be converted to and from the native formats of all kinds of sensor and alerting technologies [8]. This makes it ideal for translating AWAS event notifications to alert messages based on its standard templates.
Basically each CAP alert message consists of an
43 3.4. Requirements
more area segments [8]8. A brief descriptions of the segments of CAP and their mandatory elements is given as follows
•
•
•
• - The segment describes a geographical area for which the
The mandatory elements of aforementioned segments and their brief descrip- tions are give in the table 3.1. Optional element and sub-elements are illus- trated in CAP document object model diagram in annex A.2
8Refer CAP document object model diagram in annex A.2
44 Chapter 3. Sensor Web for Spatio-Temporal Decision Support
Table 3.1: Elements (mandatory) of CAP [8]
45 3.4. Requirements
3.4.4 Extension of SWE components
Minor enhancements in the current SWE components are necessary to in- tegrate them with AWAS architecture. The enhancement in SCS is required to make it pro-actively generate events based on observations. The extensions in WNS is required to make it capable of communicating with AWAS. The extensions and enhancements required in SCS and WNS is underlined in the following sections.
SCS
SCS assumes the role of event producer and is responsible for generating events and publishing them to the underlying event service. For this function, the current SCS needs minor upgrade to include an operation that actively generates events and sends to the underlying event service. The events are generated by parsing observation, spatial and temporal elements of an O&M observation document.
The publishing of such events is done by invoking publish() operation of underlying event service. The SCS should also be able to announce the events it intends to publish as well as denounce them when publication is no longer done. The announcing and denouncing is done by invoking event server’s advertise() and unadvertised() operations respectively. Events are pub- lished to a centralized event service server or a server node in a distributed event service environment. The SCS should be configured to address URI ad- dress of event server considering the protocol of communication the event ser- vice implements. The distributed event servers communicate with client ser- vices on top of either IP Unicast or IP Multicast or HTTP or SMTP protocol.
In this context, a SCS capable of actively dispatching data has already been developed under the name Active Sensor Collection Service (ASCS)[94]. The ASCS extends the interface of the conventional OGC’s SCS by implementing a push data model for proactive data dissemination [94]. Figure 3.4 illustrates the current SCS and extensions required in order to integrate with AWAS. In the use case diagram, white use cases represent the current SCS operations9 and grey use cases denote operations that need to be extended.
WNS
In order to use WNS as messaging service to deliver alert messages to the user, its doNotification
9Adopted from [94]
46 Chapter 3. Sensor Web for Spatio-Temporal Decision Support
Figure 3.4: Extension required in SCS
Further, the current WNS does not provide Quality of Service (QoS) guaran- tees relating to the deliver of the messages. The QoS relates to the reliability, priority and durability of message handling and dispatching. WNS should be able to check if the notification message has been delivered, fulfilling the re- quirements for reliable dispatching. Prioritization of message to be delivered is another QoS issue. However, in the case of emergency alert messaging, mes- sages are delivered synchronously as soon as they are received from the AWAS, so prioritization is not significant. The durability refers to the ability of WNS to retain the messages until they are sent. Similarly, durability is not significant as the notification messages are sent synchronously.
To address the reliability of delivery, WNS has to be extended to include an operation that checks for the delivery of notification messages, whether they are sent or pending.
3.5 Open Issues
As the current SWE framework and its implementation are still in the stage of infancy, development and integration of a new service into SWE framework requires consideration of its future enhancements. There are still open issues and compatibility problems in OWS framework to integrate heterogeneous ser- vices and components to work together as a system. The development of AWAS also faces such problems in integrating different services. The major problem arises in the interaction between static and dynamic components. These issues are outlined as follows and needs to be addressed in future work.
47 3.6. Synopsis
• User rules encoded in filter encodings have to be parsed to events com- plying to the format required by the underlying event service. Different event service may have different requirements, therefore a generic event model accepted by any event service needs further investigation.
• Event notifications can be parsed to be represented in CAP alert mes- sages. However, classification of flood phase to represent its uncertainty level, severity level and probability level as required by CAP notification structure, can’t be done unless formalization of scenario rules in context of these information parameters is done. For e.g. severity level is high if and only if [river gauge > 4 AND rain > 50].
• WNS can be used for user registry as it already has the interface for user registry and communication medium. Further, WNS can be integrated with AWAS to form one service, which performs the function of both the services. In contrary, WNS may not be required altogether if messaging infrastructure is built itself in AWAS.
3.6 Synopsis
Spatial Decision Support System (SDSS) for temporal critical application do- mains such as emergency warning requires highly dynamic temporal data. Spa- tially enabled sensor network provides a framework for collecting high tempo- ral resolution data and dynamic dissemination of collected information. This enables decision makers to make effective decisions in emergency situations, reducing the loss of lives and properties.
A system consisting of web of in-situ sensors spatially distributed over a river basin collecting real/near real time data and transmitting the data through network infrastructure can provide extremely up to date data needed for an emergency use case of flood prediction and early warning. A novel service is de- signed within OWS framework, capable of triggering an alert notification when certain threshold value in flood parameters such as river level or precipitation is exceeded. This service is capable of incorporating such physical threshold values as rules defined by the user. This rule based approach allows to filter observed data and process only those which are relevant, thus eliminating su- perfluous processing of data and unnecessary consumption of sensor resources, supporting services and network. A proactive web service -Active Web Alert Service (AWAS) is designed on top of event based communication model, which extends the current request/response service architecture by actively dispatch- ing the data whenever the rules are matched.
AWAS enables the user to register rules as threshold values pertaining to flood scenario. These rules are subscribed as event filters to an underlying event service. Correspondingly, the observations are published as events by SCS(s) to the same event service asynchronously. The underlying event service matches the subscribed and published events and sends notifications to the AWAS if
48 Chapter 3. Sensor Web for Spatio-Temporal Decision Support a match is made. The notification represents that the user defined threshold rules have been satisfied, that is flood threshold values have been breached.
The major requirement for AWAS is integration with the current SWE com- ponents and adoption of currently available standards for rule encodings and alert messaging to achieve a certain degree of interoperability. For this pur- pose, the user registered rules are encoded in OGC’s Filter Encodings and the alert messages are encoded in Common Alerting Protocol (CAP) alert messages. In order to incorporate AWAS with current SWE components (SCS and WNS), enhancements are required in these services. SCS has to be extended with a functionality to pro-actively send observations as events to an underlying event service. Where as, WNS should be able to incorporate CAP alert messages in its notification framework as well as should be able to receive user and commu- nication profiles registered in AWAS.
49 3.6. Synopsis
50 Chapter 4
Event Based Communication Model
4.1 Event Based Communication
Event based communication is a widely used architectural style for, distrib- uted, loosely-coupled, heterogeneous software components based on event gen- eration, observation and notification [80, 17, 68, 25]. The event based com- munication model support decoupled one to one or many to many communica- tion patterns [74, 68] that allow application components to notice the change in the state of another application component. This change in the state is noti- fied through event notifications. Event based communication provides scalable, efficient, decoupled and asynchronous communication through event notifica- tion and hold promise of supporting a flexible and effective interaction between highly reconfigurable heterogeneous distributed software components [25].
4.1.1 Participants of Event Based Communication The software/application components are objects that support a set of oper- ations, each of which can be invoked by some other objects. The object whose operation is invoked is referred as an object of interest, the object invoking the operation as the invoker and the object that receive notifications about the invo- cation as the recipient [80]. Framing this scenario in publish/subscribe interac- tion paradigm, the object of interest is the producer of events and the recipient is the consumer. The producers publish events on a connector service and the consumers subscribe to the event they want to receive from that connector ser- vice. The connector service is called an event service or an event notification service or an event dispatcher [14] and is responsible for providing storage and management for event subscription and efficient deliver of events.
4.1.2 Characteristics of Event Based Communication In the traditional publish-find-bind paradigm, the application components behave as service provider and service consumer based on client/server archi- tecture; the service provider being the server and the service consumer the
51 4.1. Event Based Communication
Recipient (consumer)
subscribe C2 Server C1 C3 notify
Request B
Response B
Event Service
Request A
Response A
Client A Client B P1 P2 publish advertise
Object of interest (producer)
Figure 4.1: Client/Server Vs Event Based Communication Model
client. A client/server relationship is established between two application com- ponents when a client initiates a service request to a server that is capable of responding to the service request. The request/response interaction between the clients and the server residing on separate physical machines occurs via a network connection. This model essentially provides synchronous, one-to- one communication between client and server and requires the knowledge of each others location and name for both the client and server for communica- tion to occur [69]. In contrast, the model based on event based communication requires less tightly coupled communication pattern between the components acting as event producer or consumer, allowing them to interact in an asyn- chronous, anonymous, one-to-many and many-to-many manner [69].The event based paradigm support a flexible and effective interaction among highly recon- figurable distributed software components [25] based on these characteristics.
• Asynchronous Communication - Event producers disseminate events to event consumers asynchronously. Asynchronous communication prevents slow, temporarily unavailability or blocked application components from delaying interactions between components [69]. Dedicated servers are re- sponsible to withhold the event notifications from producer until a con- sumer shows interest to it. Producers are not required to wait for re- sponses from consumers before proceeding to propagate subsequent event notifications [69].
• Anonymity - Event based communication allows the components to inter- act anonymously without having knowledge of each other’s location and number. A middleware connector called event service manages the con- nection between producer and consumer transparently [69]. This enables producers to disseminate event notifications to consumers without target-
52 Chapter 4. Event Based Communication Model
ing a specific destination and the consumers to retrieve event notifications without direct communication with the producer. A consumer is indiffer- ent to which particular producer supplies the event that it is interested in and a producer does not need to know about the set of consumer that will receive the event [74]. This enables certain level of decoupling between the event producer and consumer, which means a component can oper- ate in the system without being aware of existence of other components and any number of components can plug in and out of the architecture without affecting other components [14]. Decoupling the production and consumption of information increases scalability by removing all explicit dependencies between the interacting participants [37].
• Heterogeneity - Event based communication offers high degree of interop- erability by enabling loose coupling between distributed application com- ponents. Disparate components interact by disseminating event notifi- cations by producer and recognizing the event notification of interest by consumer by providing an interface for dispatching and receiving respec- tively [69]. This makes communication via event notification ideal for dis- tributed components in a heterogeneous systems that were not inherently designed to interoperate.
• One-to-Many and Many-to-Many Communication - A producer can initiate event based communication by propagating event notification to a group of consumers in one-to-many (1-M) fashion. Similarly, a collaborative group of producers can participate in many-to-many (M-M) communication with a group of consumers. The one-to-many and many-to-many communica- tion patterns are generally based on multicast protocols [44]. Figure 4.1 illustrates 1-M and M-M communication pattern in event based commu- nication.
• Scalability - Event based communication is scalable in as sense that the architecture can accommodate growing number distributed components [14]. Certain degree of scalability is achieved by building the event service itself as distributed components called the event servers. Different net- work server topologies (such as hierarchical server topology, acyclic peer- to-peer server topology, generic peer-to-peer server topology) and routing techniques [13, 18, 16] are adopted for efficiency and high degree of scala- bility.
4.1.3 Event An event is a message generated due to the instantaneous effect of the termi- nation of an invocation of an operation of an object [80]. The event is uniquely characterized by the identity of the object of interest, the identity of the op- eration, the identity of the invoker and the time of occurrence of the event. This characterization for a unique identification depends on the naming model employed. The two prevalent naming models classes are structure-based and property-based models [80]. In structure-based model, entities are named on
53 4.1. Event Based Communication
the basis of hierarchical naming scheme that corresponds to the hierarchical organization of the entities of interest. Property-based naming model employs declarative naming model with a description of some property of the entity or some predicate they satisfy [80].
4.1.4 Event Notification Event notification or simply notification can be termed as physical represen- tation of event. Event notification can be generic or typed. Generic event no- tification is represented by a data blob without an explicit structure where as typed event notification provides a well defined, explicit and expressive data structure into which a wide variety of event cane be mapped [69]. Event notifi- cation is defined by a type describing its structure and followed by an instance describing the specific values of its attributes. Carzaniga et al. [18, 16] de- fines an event notification as a set of typed attributes in which each attribute contains a type, a name and a value. The attributes are uniquely identified by their names, types are predefined set of primitives with fixed set of operators commonly used in programming languages. An example of structured event notification is illustrated in figure 4.2.
string event = stock time date = Mar 4 11:40:00 MST 1999 string exchange = DAX float prior = 210.25 float earn = 5.04
Figure 4.2: Example of notification. Adapted from [18]
The structure of typed events ranges from simple to complex and from sin- gle string to programming language specific object with an associated set of attributes and methods [69]. The structure associated with typed event notifi- cations is essential for applying event filters. The granularity [25] of structure influences its expressiveness hence enabling explicit filtering.
4.1.5 Filter An event filter provides a means to control the propagation of events [69]. A consumer may only be interested in a subset of a large number of events produced by potentially large number of producers in an event system. Filters enable a particular consumer to specify the exact set of events in which it is interested [68]. Event filtering prevents the delivery of unwanted events to the consumers consequently reducing the computing and computation resources.
An event filter is defined by specifying a set of attributes and constraints on the values of those attributes [18]. A filter attribute contains name, type, value
54 Chapter 4. Event Based Communication Model
string event = stock time date = Mar 4 11:40:00 MST 1999 string exchange = DAX float change < 0
Figure 4.3: Example of filter adopted from [18] and binary predicate operator that set constraint rule in the attribute values. For example, figure 4.3 illustrates a filter for event notification illustrated in figure 4.2
An event notification with an attribute α = (typeα, nameα, valueα) matches filter with attribute constraints φ = (typeφ, nameφ, operatorφ, valueφ) if and only if typeα = typeφ ∧ nameα = nameφ ∧ operatorφ(valueα, valueφ)[18]. This in- fers that the event published by the producer satisfies the event subscribed by the consumer such that α ≺ φ [18]. A filter may also contain multiple constraints for the same attribute and must be matched with the event no- tification. Such multiple constraints are interpreted as a conjunction and all such conjunctions must be matched [18] such that typeα = typeφ ∧ nameα = nameφ ∧ operator1φ(value1α, value1φ) ∧ operator2φ(value2α, value2φ). In short, a notification N matches a filter f i.e. N ≺ f if and only if [18]
N ≺ f ⇔ ∀φ ∈ f : ∃α ∈ N : α ≺ φ
4.1.6 Pattern A pattern of filter is a combination of a set of event filters [13, 18]. A filter pattern can be considered as a composite filter made up of filter primitives. A filter selects one event notification at a time, where as a pattern can select sev- eral notifications that together match an algebraic combination of filters [13]. Intuitively, a subscription to a pattern is a set of separate subscription to all the filter primitives of that pattern plus the combinator that assembles filter primitives in the pattern. An illustration of pattern filter is shown in figure 4.4
string event = stock time date = Mar 4 11:40:00 MST 1999 string exchange = DAX float change < 0 ∧ string event = stock time date = Mar 4 11:40:00 MST 1999 string exchange = NYSE float change > 0
Figure 4.4: Example of pattern filter adopted from [18]
55 4.1. Event Based Communication
A pattern of notification is delivered to the consumer only if all the elemen- tary filter primitives forming the pattern are matched by the event service. Logically, if N is a set of notifications n1, n2...... nn and p is a pattern made up of 1 filters f1, f2...... fn then N matches p i.e. N ≺ p if and only if
N ≺ p ⇔ ∀φ ∈ f1 : ∃α ∈ n1 ∧ ∀φ ∈ f2 : ∃α ∈ n2 ∧ ...... ∀φ ∈ fn : ∃α ∈ nn : α ≺ φ
4.1.7 Event Service
An event service is a middleware platform underlying event based communi- cation paradigm. This middleware platforms run on top of heterogeneous oper- ating systems and provide a homogeneous, abstract view of the entire distrib- uted system [74]. An event service is a general purpose facility responsible for managing and dispatching of event notifications. Event service acts as an ob- server, where producers of events publish their events and the consumers sub- mit their subscription requests. Numerous technologies that realize an event service have been developed and effectively used [16]. Intuitively, these event services vary in their architecture framework as well as capabilities, functions, routing techniques, filtering algorithms and data transfer topologies. Despite of differences, event services basically provide APIs for advertising, publishing and subscribing event notifications and contain algorithm for event matching and dispatching the matched events. Traditional middleware services such as QoS, security, reliability etc are implemented in the form of modules on top of event services [74] enabling efficient and secure delivery of event notifications.
Event services themselves contain interconnected servers called event servers2 as illustrated in figure 4.5. An event producer component contacts the event service via one event server know as its access point or node [16].
object of interest advertise subscribe
publish notify
interested party
event servers event service
Figure 4.5: Distributed event notification service [18]
1Adopted from [18] 2Also referred as event broker, event dispatcher, event notifier etc
56 Chapter 4. Event Based Communication Model
4.1.8 Advertise/Publish/Subscribe
In analogy to publish/subscribe paradigm for distributed application compo- nents, event based communication is also based on advertisement, publication and subscription. The only dissimilarity is that service (description) is adver- tised, published and subscribed in publish/subscribe framework for web ser- vices. Where as, in event based paradigm, it’s the events generated by the producer, which is advertised, published and subscribed by the consumer.
Advertisement
Producers announce their intention to generate events using advertisements. The usage of advertisements is to inform the event notification service about which kind of notifications will be generated by which object of interest, so that it can best direct the propagation of subscriptions [18]. A producer can unan- nounce the events in case it seizes to generate [69]. In general, advertisement is an optional event model feature [69] and is not explicitly required for event dispatching.
Publish
An object of interest or the producer publishes its event notifications to the event service subsequently after advertising the event. The published event no- tifications contain a unique event identification along with the attribute tuples defining the event.
Subscribe
The recipients or event consumers subscribe to the instances of the events to which they are interested [69] with event service. After the subscription, the consumers receive subsequently disseminated events notifications until they unsubscribe. Consumers may subscribe to an event specifying a filter or filter pattern, showing interest on specific set of events only.
4.1.9 Event Notification Schemes
The events of interest can be specified in various ways, which has led to several publish/subscribe schemes. These schemes have different semantics describing underlying mechanism for sending events to the subscribers. The choice of schemes depends in the requirement of the application implement- ing event based architecture. Some applications may have stronger reliability requirements related to specific order for dispatching events, where as others may require some timeliness constraints [69] for real-time applications. The following sections describes various schemes applied in event based model and their characteristics in brief.
57 4.1. Event Based Communication
Channel based Publish/Subscribe In channel based publish/subscribe, interested parties listen to a channel by subscribing to it. An object of interest publishes its event notification to a spe- cific channel, which is consequently delivered to only those parties listening to that channel [16]. All the recipients connected to a channel receive all the noti- fications published by object of interest on that channel, which makes channel based scheme unable to filter event notifications. Common Object Request Bro- ker Architecture (CORBA) Event Service [36, 4] is an example of channel based middleware.
Subject based Publish/Subscribe Subject based scheme extends the concept of channel by addressing the sub- ject or the topic of an event. In this scheme, each event is classified based on a set of subject also known as a topic [69]. Producers propagate their events with subject labels, which are then sent to the consumers subscribed to a spe- cific subject. A subscriber subsequently receives all events labelled with that specific subject. The main difference with respect to channel is that subscribers can express interest in more than one subject (potentially infinite) by specifying some form of expression to match a subject [16]. The subject of an event is repre- sented by its name and the events of the same subject have identical structure. Hence, the subject of an event allows consumers to subscribe to a specific group of events and identifies their type [69]. Significantly, subject-based event mod- els allow for an efficient approach to matching events against a large number of subscriptions. TIBCO Rendezvous [91] and Smartsockets [92] adopt subject based publish/subscribe mechanism.
Content based Publish/Subscribe The content-based publish/subscribe schemes is based on the actual content of the events. In other terms, events are not classified according to some pre- defined external criterion (e.g. topic name), but according to the properties of events themselves [37]. In content based scheme, the whole structured con- tent of notifications is visible to subscriptions, which gives more expressiveness in defining the filter [16]. Consumers subscribe to events by defining a filter predicate that may test arbitrary parameters of an event [69]. A subscriber subsequently receives all events whose parameters match the subscriber’s filter predicate. Event services implementing content based publish/subscribe mech- anism are Siena [18], Elvin [81], Jedi [71] or meta-data associated to events, as in the Java Message Service [46].
4.1.10 Interaction Pattern The publish/subscribe interaction pattern in event based paradigm provides consumers with the ability to express their interest in an event or a pattern of events, in order to be notified subsequently of any event, generated by a pro- ducers, that matches their registered interest [37]. The basic system model for
58 Chapter 4. Event Based Communication Model publish/ subscribe interaction pattern (shown in figure 4.6) relies on an event notification service providing storage and management for subscriptions and efficient delivery of events. Such an event service represents a neutral media- tor between publishers, acting as producers of events, and subscribers, acting as consumers of events.
Subscribers register their interest in events by typically invoking a sub- scribe() operation on the event service. This subscription information re- mains stored in the event service and is not forwarded to publishers. The op- eration unsubscribe() terminates a subscription. To generate an event, a publisher typically calls a publish() operation. The event service propagates the event to all relevant subscribers acting as a proxy for the subscribers. In some cases, the failure might prevent subscribers from receiving some events. Publishers may also have the ability to announce the nature of event using advertise() operation. The provided information can be useful for the event service to adjust itself to the expected flows of events as well as for the sub- scribers to learn when a new type of information becomes available [37].The event service matches the pattern of published event notification and subscribed event filter/pattern. Once the pattern is matched, event notification is sent to the consumer using notify() operation.
advertise unadvertise Producer
t0 t1 t2 t3 t4 t5 t6 Publish e0 e1 e2 e3 e4 e5 e6 Consumer subscribe unsubscribe
Time
Figure 4.6: Advertise/Subscribe of events. Adopted from [69]
The interaction pattern is shown in figure 4.6, which illustrates the adver- tise/publish/subscribe pattern in event based paradigm. The figure shows an event producer advertising the events it intends to generate. The producer subsequently generates events (e0 . . . e6) in time (t0 . . . t6) and eventually unad- vertisement them. No events are published either before the advertisement or after the unadvertisement. A consumer registers for interest in these events for a period of time when it subscribes to the time when it unsubscribes. The con- sumer receives the notifications generated within this time period while it has subscribed i.e. the events e2, e3 and e4 are delivered, while prior and subsequent
59 4.2. Synthesis: AWAS and Event Based Communication Model
events are ignored.
4.2 Synthesis: AWAS and Event Based Communica- tion Model
Based on general concept of AWAS and event based communication model, a synthesis of these two concepts is drawn to design an Active Web Alert Service on top of event based communication model.
4.2.1 AWAS Object Model The object model of the system shows its components, which encapsulates the functionalities. An object supports a set of operations, each of which can be invoked by some other objects [80]. The object whose operation is invoked is an object of interest and the object invoking the operation is an invoker. An oper- ation may be invoked through some hardware component associated with the object or it may be invoked indirectly as a result of executing some command or application of the object [80]. The termination of the invocation of an operation results in an event. The object that receive the notification of this event is called a recipient. In this context, SCS is an object of interest, the sensor that invokes its operation to transmit the data is an invoker and AWAS, which receives the event notification is a recipient. The object, which monitors the generation and transmit of event is an observer. In this case, an event service which acts as a proxy between SCS and AWAS is an observer. Figure 4.7 illustrates the object model of the system.
Invoker Invocation of operation subscribe data publish SCS AWAS advertise notify Sensor Event Service Object of Interest Receipient
Observer
Figure 4.7: AWAS Object Model
4.2.2 AWAS Event Model An event model for the rule based approach requires high expressiveness in terms of expressing the rule predicates. Referring to the example given in section 3.3, the rule set is as shown
As shown in the example, the contents of the event filter/pattern defines the rule the user has registered. The expressiveness of the rule is only achievable
60 Chapter 4. Event Based Communication Model
string event = gauge time start = 2004-01-15T12:00:00.00 time end = 2004-01-16T12:00:00.00 float value > 3.2 ∧ string event = rain time start = 2004-01-15T12:00:00.00 time end = 2004-01-16T12:00:00.00 float value > 50
Figure 4.8: Example of pattern filter for river gauge level and precipitation when its contents are transparent to the filtering mechanism. For this reason, the content based publish/subscribe of the events is only able to define the rules specifically in the event publication and subscription.
4.2.3 Event Generation Schemes On synthesis of AWAS architecture into event based model, three different schemes of event generation can be drawn. The choice and suitability of these schemes explicitly depends on the optimum usage of sensor, network and soft- ware component resources. A brief description of each scheme is presented as follows:
Scheme 1 In the first scheme, a sensor sends it data to the corresponding SCS. That is, sensor invokes an operation of the SCS wrapping around it [85]. The op- eration may be getData or updateData operation. Upon the termination of this operation, an event notification is generated. This generated event is then published to an underlying event service. The recipient AWAS subscribes to an event filter or pattern with the event service. The published event and the sub- scribed event filter is matched by the event service. Upon matching, the event service sends the event notification to the subscriber AWAS.
SWE Framework data SCS AWAS
Sensor Event subscribe notify
publish Event Service
Figure 4.9: Event generation Scheme 1
61 4.2. Synthesis: AWAS and Event Based Communication Model
The architecture holds valid for multiple SCSs as well. In this case, SCSs publish their events to an underlying event service, where the AWAS also sub- scribes for an event. When the published and subscribed events are matched, notification is sent for each match. The aggregation of sent event notifications is done by the AWAS.
Theoretically, each SCS can publish its events with individual event servers in the distributed event service hierarchy. However, the major drawback is that each SCS should know the address of its event server and similarly, the AWAS should also know the specific address of event server where its interested events are published. This problem is partly solved by advertising events by SCS in the event service. However, this is only helpful, when the events are advertise in one particular distributed event service. This issue needs to be investigated further and is not discussed in this work.
Scheme 2
In the second scheme, a sensor sends its data to the corresponding SCS. The AWAS acts as a client service and forwards user defined rule to the correspond- ing SCS. The rule is then validated against the observed data. If the rule satisfies with the observed data, an event is generated and subsequently for- warded to the AWAS. Aggregation of events received from different SCSs is done as similar to the scheme 1.
SWE Framework data SCS pass rule AWAS Sensor Source Filtering notify Event
Figure 4.10: Event generation Scheme 2
The drawback of this scheme is that, the source filtering of data in the SCS against the user rule increases the computational resources of SCS and this requires major enhancements in current SCS architecture and functions. In addition, both participating AWAS and SCS(s) requires to know each others service address, which may cause severe restrictions in case when there are number of participating SCSs and AWASs involved.
Scheme 3
In the third scenario, an active sensor (smart sensor) itself sends its data to the client showing the interest on the data. The client being the AWAS
62 Chapter 4. Event Based Communication Model and the data itself is an event. In this architecture scheme, the communica- tion between the object of interest (sensor) and the recipient (AWAS) occurs via a specialized communication protocol called content based networking pro- tocol [19, 45, 15]. Content based networking protocol implements event based communication model’s publish/subscribe architecture at network level (within routers). The mechanism is similar to the content based event notification scheme described in section 4.1.9 but the publish/subscribe, filter and dispatch- ing notification occurs in the network infrastructure itself. Data driven network infrastructure such as distance vector/dynamic receiver partitioning DV/DRP [45] and directed diffusion [51, 52] already exist, which are specifically designed for wireless sensor networks.
(event) subscribe data Content Based Networking AWAS notify Sensor (Smart Sensor)
Figure 4.11: Event generation Scheme 3
On overviewing aforementioned schemes for AWAS, scheme 1 seems to be most suitable at current development stage of SWE framework. For implemen- tation of this scheme, major enhancement on SCS is not required as well as the system remains open to any number of heterogeneous components (SCS and AWAS) to join or leave the system, increasing its scalability and making the system flexible.
The architecture of AWAS presented in chapter 5 is based on scheme 1 of event publication and subscription.
4.3 Open Issues
Event based communication acts as a proxy between publisher SCS and sub- scriber AWAS. However, there are still issues of data exchange format, formal definitions, communication protocols and others. These open issues are sum- marized in the following points. The investigations on the solutions of these issues are beyond the scope of the research work.
• Interaction with event service needs specific definition of event server’s address, which is generally based on TCP/IP or UDP routing address3. The requirement of specific definition of event server address makes the system rigid.
3Based on investigated event services
63 4.4. Synopsis
• Event services do not publish their service definitions and capabilities to a registry service, therefore client services must specifically know their addresses and capabilities.
4.4 Synopsis
Event based communication paradigm is a new communication model that extends traditional request/response communication model between distributed components by enabling active push data transfer mechanisms. Event based communication model have been implemented in various application domains ranging from distributed service components to mobile computing [68] and sen- sor networks [45]. Event based communication enables distributed, heteroge- neous software components to communication with each other based on event generation, observation and notification.
The components that participate in event based communications are called objects of interest and recipients. Objects of interest are those objects which produces the events and publish them to an event service. Recipients are those who consumes the events by subscribing to specific events to an event service and receiving the notifications about the occurrence of those events. An event service is middleware platform underlying event based communication para- digm and acts as a proxy between objects of interest and recipients.
Synthesizing AWAS into event based communication model, SCS acts as an object of interest and publishes its observations as events to an underlying event service. AWAS represents the recipient and subscribes for specific event described by user rules with the same event service. The event service matches the published events and subscribed event filter and sends event notifications to the subscriber AWAS if a match if made.
In this manner, event based communication model enables space, time and synchronization decoupling[37] between two heterogeneous components - the AWAS and the SCS.
64 Chapter 5
Active Web Alert Service - Architecture
Bass et. al [5] gives the definition of software architecture as
“The software architecture of a program or computing system is the structure or structures of the system, which comprise software ele- ments, the externally visible properties of those elements, and the re- lationships among them.”
Architecture is an abstraction of a system represented by the elements and their behavior with other elements of the system relating to how they use, are used by, relate to, or interact. This chapter gives the abstraction view of the AWAS by defining its logical and execution architectural views based on con- ceptual view presented in section 3.3.1. The chapter also presents the compo- sition of event model for the AWAS architecture and discusses functional and non-functional design components related to the event composition and man- agement.
5.1 Architectural Concept
The architectural concept extends the general concept presented in section 3.3.1 and gives the logical architecture view of system components and their interface specifications. The following sections present layered, static and dy- namic views of the system and describe the service operations.
5.1.1 Layered View
The AWAS is built on top of two different distributed platform paradigms: OWS framework and event based communication model. These platforms are based on web service architecture and event driven architecture respectively and needs close correlation among their components. The web service archi- tecture framework is responsible for information request and response where
65 5.1. Architectural Concept
as the event driven architecture is responsible for information delivery and ac- tions. A virtual stack of integration of these two architectures is illustrated in figure 5.1.
OGC Compliant Client
SWE
WNS TCP/IP HTTP SCS Event Service AWAS
Open Web Service (OWS)
Figure 5.1: Layered view of system architecture
The AWAS is built on top of OWS framework as a SWE component. It is available to an OGC compliment client via HTTP protocol by querying to the registry service, where the AWAS publishes its capabilities. Communication between the AWAS and SCS occurs anonymously via TCP/IP communication protocol with the event service.
5.1.2 Structural View
The AWAS architecture is based on SWE architectural framework and func- tions in collaboration with event based communication model. The AWAS should be built to interact with underlying event service’s interface. The UML class di- agram in figure 5.2 represents the static view of the system showing the visible interfaces of components and their interrelationships with other components, which implement the interfaces.
Class Description
• An abstract class SWE Service is inherited by all the SWE component classes in the system. This class implements Capabilities interface containing getCapabilities() method.
• An abstract class Sensor implements getData() method to send obser- vation data to the SCS class.
66 Chapter 5. Active Web Alert Service - Architecture
Figure 5.2: System Architecture in UML notation
• An abstract class SCS is inherited by its implementation classes for river gauge level and precipitation (e.g. SCS RiverGauge and SCS Preci- pitation). This class instantiates Publish interface implemented by Event Service class to publish and advertise/unadvertise events.
• An abstract class WNS inherits SWE Service abstract class and imple- ments Notification interface. This interface contains doNotification method which is invoked by AWAS class to send notifications.
• The Event Service abstract class implements Publish and Subscribe interfaces. Publish interface contains advertiseEvent(), unadver- tiseEvent() and publishEvent() methods. Subscribe interface con- tains subscribeEvent() and unsubscribeEvent() methods.
• The AWAS class extends SWE Service abstract class. It contains re- gisterUser(), returnUserID(), registerRule(), updateRule(), parseRule(), parseEvent() and unregisterUser() methods. The AWAS class subscribes event with Event Service’s Subscribe interface implementation and notifies the alert messages to Notification inter- face of WNS class.
Method Description • registerUser() method registers user with user profile and communi- cation protocol and address.
• returnUserID() method returns a unique userID after user registra- tion.
• registerRule() method registers user defined rules.
67 5.1. Architectural Concept
• updateRule() method updates on previously defined rule. • parseRule() method parses user defined rule to event filter/pattern. • parseEvent() method parses received event notifications to alert mes- sages. • unregisterUser() method terminates the user subscription from the service consequently voiding the defined rules.
The functional decomposition of AWAS is shown in UML notation in figure 5.3.
Figure 5.3: AWAS components in UML notation
5.1.3 Interface Operations Based on the function of AWAS, the service interface is defined. All its in- terface operations are called upon by HTTP Post method. Table 5.1 gives the overview of the service operations and are described subsequently.
All the operations have two common parameters: SERVICE and VERSION. The SERVICE operation indicates the type of service for which the operation is requested. This allows the same interface to offer several different services over the same Uniform Resource Locator (URL) prefix [27]. The VERSION pa- rameter is optional and it allows the user to receive a particular version of the service operation. Both these parameters follow the naming and numbering conventions of the Basic Service Model [27].
68 Chapter 5. Active Web Alert Service - Architecture
Table 5.1: Service operations of AWAS
Operation Required/Optional Description GetCapabilities R Self description of the service SubscribeUser R Subscription of user profile and communication media and address UnsubscribeUser R Unsubscription from the service RegisterRule R Registration of user defined rules UpdateRule O Updating of previously defined rule
GetCapabilities
The GetCapabilities operation provides clients with a self description of the service instances. The description includes general information about the service, what operations that service supports, and what content it offers. The GetCapabilities operation complies with the Basic Service Model specifica- tion [27] and has parameters as shown in the table 5.2.
Table 5.2: Parameters of GetCapabilities operation
Request Parameter Required/Optional Description REQUEST = GetCapabilities R Request name SERVICE = AWAS R Service name VERSION = version O Request Version
The response to the GetCapabilities operation is capabilities document encoded in XML or OGC service exception for the failure or response.
SubscribeUser
The SubscribeUser operation allows users to register in the service and make subscription for alert notification messages. The user has to provide user name and profile and preferred communication protocol (e-mail, SMS, tele- phone, fax, HTTP) along with address. The AWAS should have capability to manage user database and generate unique individual identity of the user. The user and communication profile registered needs to be passed to the messaging WNS.
The response of SubscribeUser operation is a unique userID.
RegisterRule
The RegisterRule operation allows user to register threshold rules pertain- ing to the flood scenario. The rules are encoded in OGC filter encodings [93],
69 5.1. Architectural Concept
Table 5.3: Parameters of SubscribeUser operation
Request Parameter Required/Optional Description REQUEST R Request name (subscribeUser) NAME R User name COMMUNICATIONPROTOCOL R Preferred communication medium (e-mail, SMS, telephone, fax, HTTP) COMMUNICATIONADDRESS R Communication address of chosen protocol
which offers comparison, logical and spatial operators to define a set of obser- vational rules with spatial as well as temporal constraints 1. The AWAS should provide web based electronic form (e.g. HTTP form, java applet etc) as user front end in which user fills out the threshold rule. The form is linked with a binding template, which binds the values of parameters specified in the form with filter encoding elements. In this context, XForms [31] seems more suit- able as it offers skeleton of collection request in filter encoding structure with empty elements to be filled with user input values. The main idea is to fill an electronic form and bind the values with filter encoding elements. An example of web based user interface to register rules is illustrated in Appendix A.3
The parameters of RegisterRule operation is given in the table 5.4.
Table 5.4: Parameters of RegisterRule operation
Request Parameter Required/Optional Description REQUEST R Request name ( registerRule) USERID R User identification number re- turned by the service after user registration (userID) RULE R Threshold rule defined by the user
The AWAS should be able to send user, the confirmation of rule registration upon successful registration or send exception in case of failure.
UnsubscribeUser
The UnscubscribeUser operation allows the user to unsubscribe from the service, thus unsubscribing from the alert notification customer list.
1Example of threshold rules encoded in filter encodings is given in Appendix A.1
70 Chapter 5. Active Web Alert Service - Architecture
UpdateRule The UpdateRule operation enables a user to update on previously registered rule.
5.1.4 Behavioral View SCSs wrapped around two different in-situ sensors for river-gauge level and precipitation get observation measurement data. That is, sensors perform mea- surements and invoke an operation (update or new data operation) of the cor- responding SCSs. The SCS, after getting a data generates an event, which is simply a structured message with a unique identification containing a set of attributes. The attributes basically contain identity of corresponding sensor, its location, time stamp of measurement collected and the collected measurement.
The event is then published to the underlying event service by invoking event service’s publishEvent() operation. Prior to this, the SCS can advertise its event by invoking the event service’s advertiseEvent() operation. The event advertisement basically contains the fragments of SCS’s getCapabilities re- sponse including the type of event generated. The SCS can invoke event ser- vice’s unadvertisedEvent() operation when it no longer intends to publish its events.
User/client subscribes with the AWAS registering user profile, preferred com- munication medium and communication address. In return, the AWAS returns the user with a unique userID. The user and communication profile is sent to a WNS, which later uses this information to send alert messages to the cor- responding user. This leads to the rule registration process, where user/client registers threshold rules pertaining to the flood scenario. For a flood scenario in a particular river basin, the user is assumed to have pre-knowledge of thresh- old value range for different hydrological and meteorological parameters. The registered rule is then parsed as event filter and pattern for complex rule and passed to the underlying event service by invoking its subscribeEvent() op- eration.
The event service matches the pattern of published and subscribed events. Once the pattern is matched, it sends event notifications to the subscriber AWAS. The AWAS, at this point retains the event notification messages until all the subscribed events matching to the user defined rule are obtained. The received event notifications are tested against the user defined rule to check if the event pattern is fulfilled. After receiving the event notifications matching to the subscription, the AWAS parses to translate the events into a meaningful alert notifications based on CAP alert messaging framework.
The AWAS then invokes WNS’s doNotification() interface operation to send the alert notification, which is finally sent to the user as alert messages by the WNS.
71 5.1. Architectural Concept
The AWAS also provides operations to update rule definition (updateRule) as well as unsubscribe from the service (unsubscribeUser). The updating of rule again invokes event service’s subscribeEvent() interface operation and the unsubscription of the user invokes unsubscribeEvent() interface operation.
The dynamic view of the system architecture is represented by showing the interactions between the system’s components in UML sequence diagram as illustrated in figure 5.4
Figure 5.4: System Interaction in UML notation
72 Chapter 5. Active Web Alert Service - Architecture
5.2 Functional Design Components
The functional components described in subsequent sections describe the ar- chitecture and features of even model components that build the system.
5.2.1 Event Events generated by SCS are typed events with well-defined, explicit, and ex- pressive data structure into which a wide variety of event data can be mapped. These typed events are generated from a fragment of O&M document. The named elements of O&M document containing the data corresponding to the observation are parsed to event objects with an associated set of attributes and values. This event object is specific to the programming language being used and its semantics should correspond to that of underlying event service plat- form’s event type.
Some of the event services implement parser APIs that accept XML docu- ment and is parsed to typed events. SIENA-XML [35] and YANCEES [39, 40] are examples of such parser APIs built on top of existing event services. In general, these parser APIs convert hierarchical events in XML document to non-hierarchical namespaces. However, these event service parser APIs are only developed as research prototypes and does not seem suitable for AWAS system at the implementation level. The reason being that the namespaces of the events parsed from O&M fragments does not match with the namespaces of the event filters subscribed, the event filters being the fragments of filter encod- ings as conceived in this work. In this case, the event service will fail to match the published events with the subscribed event filters even though they match, the failure attributed to the difference in attribute namespaces.
The possible solution for this implementation issue would be to incorporate such a parsing mechanism in the SCS itself. This parsing mechanism will parse a fragment of O&M containing the observation value, observable ID, SCS ID, time stamp of observation etc. to a generic event object acceptable by the un- derlaying event service. An example of O&M fragment and the event parsed from it is illustrated as shown in figures 5.5 and 5.6 respectively.
73 ANHANG
B.3.2 SubscribeObservationResponse
B.3.3 UnsubscribeObservationResponse
B.3.4 GetObservationResponse
Figure 5.5: O&M fragment of river gauge observation
Event tuples string Phenomenon = GAUGE HEIGHT string Station = GA356 string pos = 40.73768 54.854607 time timePosition = 2004-08-20T10:00:00 float TypedQuantity = 3.523
Event publish function call 81 publish(‘‘Phenomenon’’,‘‘GAUGE HEIGHT’’); publish(‘‘Station’’,‘‘GA356’’); publish(‘‘pos’’,‘‘40.73768 54.854607’’); publish(‘‘timePosition’’,2004-08-20T10:00:00); publish(‘‘TypedQuantity’’,3.523);
Figure 5.6: Example of O&M observation parsed event tuples and corresponding event func- tion call
74 Chapter 5. Active Web Alert Service - Architecture
5.2.2 Event Filter/Pattern Event filter in the AWAS is generated from user defined rules. User defined rules pertaining to the flood scenario is parsed to form event filters. If the rules are encoded in filter encoding as conceived in section 3.4.1, the filter encoding XML document needs to be parsed to generate event filter tuples as similar to parsing O&M document for events in the SCS.
5.2.3 Event Publish/Subscribe If the published events and subscribed events filters are modeled as men- tioned in sections 5.2.1 and 5.2.2 respectively, the semantics of events and the event filters must be the same. That is, the event attribute name and type must be the same. Representing the event and event filter attributes with generic names and value types corresponding to spatial, temporal and observational tuples solves the semantic differences in published and subscribed events. A subscriber AWAS can know the semantics of the published events from the event type advertised by the publisher SCS.
The most common attributes for flood scenario are sensorID, its position, ob- served phenomena, observed time and observed value. If these generic event attributes are mapped with common names and value types both in the pub- lisher SCS and subscriber AWAS, the issue of semantics will be resolved. An example of published event and subscribed event filter parsed from O&M/GML elements mapped in common names is illustrated in figure 5.7.
Published Event string Phenomenon = gauge height string sensorID = GA564 string pos = 40.73768 54.85464 time timePosition = 2004-08-20T10:00:00.00 float TypedQuantity = 3.8
Subscribed Event Filter string Phenomenon = gauge height string sensorID = GA564 string pos = 40.73768 54.85464 time timePosition = 2004-08-20T10:00:00.00 float TypedQuantity > 3.0
Figure 5.7: Example of published event and subscribed event filter
5.2.4 Event Notification Event notifications sent to the AWAS by the event service are structured set of attributes with unique attribute names, attributes types and corresponding
75 5.3. Non-Functional Design Components
attribute values. These attribute value types are predefined set of primitives recognized by commonly used programming languages. The most commonly used primitive types are string, integer, float, boolean and date. The typed attribute sets enables to store the event notifications in a persistent storage for manipulation and is recognizable to the implementing programming language.
5.2.5 Event Handling and Parsing A received event notification should be retained in a persistent database un- til all the events sequence in a rule is received by the AWAS. The events in the database expires as soon as the event sequence is fulfilled. This event se- quence is then parsed to generate alert messages based on CAP messages. The description of message types and semantics of rules are referred from a formal- ized description in a RDF document.
5.3 Non-Functional Design Components
Non-functional components address the constraints on the functions of the system such as timing constraints, reliability constraints, constraints in devel- opment process, standards etc. Non-functional issues such as reliability, re- sponse time and memory management are addressed by QoS.
The major non-functional design issues in the development of AWAS are re- lated to the QoS, temporal synchronization of heterogeneous data and selection of event service middleware. Other issues such as inventory of events for back- tracking of their occurrences and monitoring of the state of events are also sig- nificant for emergency warning application domain. These issues are addressed in brief in the following sections.
5.3.1 Quality of Service QoS is related to the reliability, response time and memory management of the service. AWAS as an alert messaging web service, should inherit the QoS characteristics of both web services as well as message notification ser- vice. QoSs pertaining to web service architecture are availability, accessibility, integrity, performance, reliability, regulatory and security [64]. These QoS are related to usability, utility and quality of the service. QoS related to the mes- sage notification services are discard policy, earliest delivery time, expiration time, maximum messages per consumer, order policy, priority and reliability [4]. Most of these QoSs for messaging service are already implemented in un- derlying event notification service, as event notification service itself being a messaging service. However, the AWAS being a specialized message notification service for real-time messaging, the QoS should also have parameters related to temporal constraints. The major issue related to the temporal constraints in QoS is the temporal synchronization of events and pacing interval2.
2maximum amount of time events in a sequence will be collected before being delivered to a consumer [4]
76 Chapter 5. Active Web Alert Service - Architecture
5.3.2 Temporal Synchronization of Events Physical parameters related to the natural phenomenon do not always occur concurrently. For instance, for flood scenario, exceedance of threshold values in river gauge level and precipitation do not occur concurrently even though these phenomena are related. Consequently, the generation of event notifications due to exceedance of certain threshold values of these parameters do not occur synchronously. In such a case, the AWAS should be able to queue the events until the corresponding event occurs to fulfill the user rule. Messages (events) can be stored in the queuing server either in memory, which does not guaran- tee against system failure or in some persistent store such as a database [42]. However, the issue of event queuing time and expiration time for such events is critical for real-time messaging and needs further investigation. A solution can be sought in collaborative sensor network constituting of reconfigurable smart sensor nodes [1], in which sensor units can actuate other units when certain event occurs. In the flood scenario, smart sensors collecting precipitation data can actuate river gauge sensor when precipitation reaches certain threshold and consequently notify the user via the AWAS. In this case, the user has to register rule only for principle event, the precipitation. Elaboration of this sce- nario needs further investigation and is not done in this work.
5.4 Deployment Concept
The deployment concept presents the execution architecture of the system. The execution architecture presents the mapping of functionalities via software building blocks on hardware resources [70]. This section present the process view and deployment view of the system architecture of AWAS and describes its components. The process view shows the components and their interactions with other components and interfaces. The deployment view shows the map- ping of (physical) components in the executing system onto the nodes of the physical system.
5.4.1 Process View Figure 5.8 shows the process view of system architecture in UML component diagram. The descriptions of components are given in the subsequent section.
Component Description • User Registry - This component is the front end of the system and provides a HTML form in a web browser for user subscription. The user provides with name, communication protocol and address in the registry form. This component implements UserProfile and Communication interfaces of Registry Handler component to pass the entered user profile and com- munication parameters respectively to the AWAS.
• Registry Handler - This component handles the registration of user and maintains user database. This component is responsible for returning the
77 5.4. Deployment Concept
Figure 5.8: System Components in UML notation
user with a unique UserID upon successful registration. This component is connected to user database by implementing DB API interface.
• User DB - This component is a relational database, used for storing of user profile data.It supports database application programming interface DB API.
• Rule Registry - This component provides user interface for registration of flood scenario rules in XForm document mapped in filter encoding XML document. The user rules are parsed and passed to Event Filter com- ponent by implementing ParseRule interface.
• Event Filter - This component sends event filter and pattern to underly- ing event service by invoking event service’s SubscribeEvent interface operation.
• Observation - The Observation is component of SCS object that collects data from sensor and generates event by implementing Event interface of Event Generator component. The Event interface parses the obser- vation encoded in O&M to event object to be published.
• Event Generator - This component advertise/unadvertise and publishes events to the event service.
• Advertise - This event service object component implements Advertise- Event interface operation to allow SCS to advertise its events.
78 Chapter 5. Active Web Alert Service - Architecture
• Publish - This component implements PublishEvent interface operation to allow SCS to publish its events.
• Subscribe - This component implements SubscribeEvent interface oper- ation to allow AWAS to subscribe for event notifications.
• Event Match - This component is responsible for matching published and subscribed events in the event service.
• Notify - This component notifies the subscriber AWAS with event notifica- tion when the matching of published and subscribed events occur.
• Event Management - This component is responsible for managing the event notifications received. The management involves queuing and storing the event notifications until all the events in a sequence is collected before being parsed to translate into alert messages.
• Event DB - This component backups Event Management component by storing the event notifications.
• Event Parse - This component parses the event notifications to translate into alert messages (CAP messages).
• Notification - The Notification is WNS component responsible for noti- fying the user with alert notification messages. The Event Parse compo- nent of AWAS invokes doNotification interface operation to dispatch the alert messages to the WNS.
5.4.2 Deployment View The deployment view in figure 5.9 presents the deployment of the system showing the relation of AWAS application module with external modules and the communication links between the modules.
Figure 5.9: AWAS Deployment in UML notation
79 5.5. Open Issues
Module Description • AWAS Server - The core application is deployed in AWAS Server node. It implements HTTP protocol to allow clients to send requests. It imple- ments TCP/IP protocol3 to interact with Event Server and HTTP Post protocol to interact with messaging client WNS Server. • DB Server - Databases are deployed in DB Server node. Databases User DB and Event DB are used for persistence of user information and event notifications respectively. The databases are connected via a database Application Programming Interface (API) connector (JDBC). • Client - Users of the service who connect the AWAS from remote hosts using a web browser.This node represents the client hosts (user machines) which connect to the system to request service. • SCS Server - It is the data source node for the system. It provides observa- tion data as events, which is sent to Event Server node by implementing TCP/IP protocol. • Event Server - This node is responsible for handling events and event fil- ters/patterns, match them and send event notifications to the AWAS Server node. It implements TCP/IP protocol to communicate with its clients AWAS Server node and SCS Server node. • WNS Server - This is messaging node and handles alerts messages sent by AWAS Server node. It sends these messages to the client via HTTP Post protocol.
5.5 Open Issues
• Integration of SCS with event based model requires it to actively gener- ate events compatible to underlaying event service’s event model. This event model is not generic and depends on event service’s event matching algorithm. • Active sensors (autonomous sensor pods) can generate events by them- selves. In such case, sensors can send events directly to the event service without requiring SCS. In this scenario, the AWAS subscribes for the noti- fication with the event service and the active sensors publishes its events to the event service. • Rule registration operation can be extended to enable automatic regis- tration for events that occur when the observation value returns back to normal value after exceeding the threshold. For an instance, user should be informed about river gauge level when it returns back to the normal readings after exceeding the threshold. This enables the AWAS to inform the user that the flood level has receded and there is no imminent danger.
3The communication protocol with event service can be TCP/IP or UDP depending on the implementation of the event service
80 Chapter 5. Active Web Alert Service - Architecture
5.6 Synopsis
The architecture of the AWAS is built on the basis of OWS framework on top of event model. The AWAS communicates with other SWE services and OGC compliant clients via Hypertext Transfer Protocol (HTTP) protocol. The communication with the underlying event service depends on the protocol im- plemented by the event service (TCP/IP or UDP or HTTP or SMTP).
The architecture of the AWAS is presented based on software engineering model driven approach. The structural view presents the static classes of the system, the interfaces instantiated by the AWAS and the methods in the AWAS. The AWAS invokes Subscribe interface implementation of the underlying event service to subscribe for event filter/patterns. The SCS invokes Publish interface implementation of the event service to publish its events. WNS’s Notification interface is invoked by the AWAS to send its alert notifications. The AWAS has GetCapabilities(), SubscribeUser(), RegisterRule(), UnsubscribeUser() and UpdateRule() interface operations.
The events generated in SCS are set of typed event attributes parsed from O&M elements representing the observation value, time of observation, loca- tion of sensor and the sensor ID. These events are published to an underlying event service by invoking event service’s publish interface. The event filters subscribed by the subscriber AWAS is a set of typed attributes similar to the published events but in addition it contains a binary operator that set con- straints on the observation value. The publisher SCS can advertise their event types with the event service so that the AWAS can know the type of event to subscribe.
81 5.6. Synopsis
82 Chapter 6
Proof of Concept
This chapter provides evidence that demonstrate Active Web Alert Service (AWAS) concept presented in chapter 3 and its architecture presented in chap- ter 5 is feasible. However, the full implementation of the presented concept and architecture requires several key issues to be addressed and resolved. Among the key issues, the extension of current SCS and WNS to enable integration of AWAS into SWE architecture is the major. Other issues are related to a formal definition of flood ontology for rule based alerting, reliability and QoS issues of event service for real time data dissemination and availability of per- tinent event service suitable for data exchange between the OWS components. Moreover, the full implementation requires formal specification of the presented AWAS architecture, which is sought as the next step for its development. This chapter briefly describes the implementation framework for the proof of concept and software technologies which can be implemented. The implementa- tion framework outlines how AWAS can be realized as a web service in distrib- uted environment based on SWE standards. A simplified prototype is built to demonstrate the feasibility of event based communication between AWAS and an active SCS and is presented in this chapter.
6.1 Implementation Framework
AWAS can be built as SWE service based on existing web service standards. Servlet is one of the common web service component technology based on Java platform. Servlet runs on top of web container or servlet container such as J2EE [88] and Apache Tomcat [2] platforms. The AWAS servlet provides HTML form in client’s web browser to fill up with user profile and preferred communication medium with address. The AWAS returns the user with a unique UserID. An XForm [31] document mapped in filter encoding [93] enables the user to register flood rules. These rules encoded in filter encoding is parsed by an XML parser tool (e.g.JAXP [95], JDOM [55] etc.) to event filters. These event filters are subscribed with an underlying event service.
The SCS parses its O&M observation document to events using XML parser tools and publishes these events to the event service. Event service sends event
83 6.2. Implementation Technology
notifications to the AWAS, which is then parsed to CAP alert messages based on Resource Description Framework (RDF) document, which contains rules for alert types. The CAP alert message is then sent to the user via WNS.
Figure 6.1 illustrates the components for AWAS implementation.
Figure 6.1: AWAS Components/Deployment in UML notation
6.2 Implementation Technology
This section gives a brief overview of software technologies that can be im- plemented in order to build and deploy AWAS in implementation level. The technologies discussed are based on the Java Platform and XML data transfer standards as compliance to the OWS standards. However, the descriptions are non-exhaustive and implementation can be done on top of any OWS compliant development platform.
6.2.1 Java The Java programming language is a general-purpose, concurrent, class based, object oriented language [41]. Java offers a platform independent software en- vironment that reside on top of any underlaying operating system for delivering and running highly interactive, dynamic and secure applications on networked computer systems [58]. This high degree of platform independency is achieved
84 Chapter 6. Proof of Concept by compiling program byte codes, which are not specific to any physical machine but are machine instructions for a virtual machine. This virtual machine is the core of the Java Platform and is called the Java Virtual Machine (JVM).
The Java Virtual Machine (JVM) is a “soft” computer that can be imple- mented in software or hardware [58]. Different platforms have their own JVM implementations but there is only one virtual machine specification, which pro- vide a standard, uniform programming interface to applets and applications on any system. The Java Platform is designed to provide “Write Once, Run Any- where” capability ideal for the Internet, where a program should be capable of running on any computer in the world [58].
6.2.2 Servlet A servlet is a Java technology based Web component, managed by a con- tainer that generates dynamic content [23]. It is a Java programming language API class that enables a protable way to provide dynamic, user oriented con- tent in the web. Like other Java technology-based components, servlets are platform-independent Java classes that are compiled to platform-neutral byte code that can be loaded dynamically into and run by a Java technology-enabled Web server [23]. Although servlets can respond to any type of request, they are generally used to extend the applications hosted by Web servers via HTTP interface [3].
Servlets are run on top of a servlet container also called as servlet engine. Servlet engines are web server extensions that provide servlet functionality to interact with web clients via a request/response paradigm[23]. The container is a compiled, executable program that acts as an intermediary between the web server and the servlets in the container. The container enables loading, initializing and execution of servlets.
6.2.3 JDBC The Java Database Connectivity (JDBC) is a Java API that provides program- matic access to relational data from the Java programming language [33]. The applications written in the Java programming language can execute SQL state- ments, receive results and propagate changes back to the underlying data base via the JDBC API. The JDBC also allows distributed application components to access multiple data sources in a distributed, heterogeneous environment.
6.2.4 XForm XForm is W3C’s new generation of Web forms that provides a new platform- independent markup language for online interaction between a client/user and a remote agent. XForms are the successor to HTML forms, but differs from the later as it is able to distinguish contents from the presentation of the form [31]. XForm is a server-side Java package that dynamically generates and validates
85 6.3. Prototype
interactive web forms [31]. The data collected in XForm is expressed as XML instance data and its model describes the structure of the instance data.
6.2.5 XML Parser XML parser enables processing of XML documents within the application development environment. Programs that need to read, process and write XML documents rely on XML parsers. The parser is a software library (in Java its a class) that reads the XML document and checks it for well-formedness [47]. Client applications use method calls defined in the parser API to receive or request information the parser retrieves from the XML document [47].
The Java development platform implements two major standard APIs for processing XML documents, the Simple API for XML (SAX) and Document Ob- ject Model (DOM). Both of these parser API standards are bundled together in Java API for XML Processing (JAXP), which leverages these standards to parse the XML data as a stream of events or to build an object representation of it [3]. JDOM is another XML parser standard, which provides an open source API designed to represent XML and its contents [50, 48].
6.3 Prototype
This sections describes the simplified prototypical implementation of the AWAS. The prototypical implementation characterizes the fundamental of ar- chitecture presented in previous chapter, i.e. dissemination of sensor observa- tion data as event notifications. The section also describes in brief the under- lying event service: the Siena Event Service [20, 13, 18] implemented for the prototype.
6.3.1 Siena Event Service Siena (Scalable Internet Event Notification Architectures) is a content-based generic publish/subscribe event notification service [20]. Its design offers maxi- mum expressiveness of the contents and scalability on Internet scale. Siena ex- tends the publish/subscribe protocol with an additional interface function called advertise(), which an object of interest can use to advertise the notifications it publishes [18]. Siena also offers unadvertise() and unsubscribe() func- tions to cancel the subscription and the advertisement respectively. Table 6.1 shows the interface functions of Siena.
An event notification (event) is a set of typed attribute published by the object of interest (publisher) to the Siena event service. Each attribute in an event notification has a type, name and a value [18]. An event filter in Siena is a set of attributes and constraints on the values of those attributes. Each attribute is a tuple specifying a type, a name, a binary predicate operator and a value for the attribute [18]. A pattern is a sequence of filters that is matched by temporally ordered sequence of notifications, each one matching the corresponding filter.
86 Chapter 6. Proof of Concept
Table 6.1: Interface of Siena [18] publish(notification n)
subscribe(string identity, pattern expression) unsubscribe(string identity, pattern expression)
advertise(string identity, filter expression) unadvertise(string identity, filter expression)
Siena event service offers scalable topology, where the event servers them- selves communicate in order to cooperatively distribute the selection and de- livery tasks of event across wide-area-network [18]. In Siena architecture, the distributed event servers communicate with each other in three basic architec- tures: hierarchical client/server, acyclic peer-to-peer and general peer-to-peer [18]. Besides these, it also offers the option of centralized architecture, where single centralized event server handles incoming events and outgoing notifica- tions. However, this client/server topology does not offer high degree of scala- bility.
Detailed description of Siena and its implementation API is beyond the scope of this work. A UML notation is presented in 6.2 showing the architecture of Siena and its major components.
Figure 6.2: Siena Event Service in UML notation
87 6.3. Prototype
6.3.2 Implementation
A simplified prototype is built in Java on top of event based communication platform to demonstrate the dissemination of sensor observation data as event notifications.
A Subscriber class representing AWAS subscribes for the events relating to river gauge level and rainfall data with Siena event server running on remote system. A Publisher class emulates two SCSs and publishes events relating to river gauge and rainfall observations to the same Siena server. The Siena event service matches the subscribed and published events and notifies to the subscriber AWAS if the match is made. The description of prototypic implemen- tation is given in detail in the following section.
Figure 6.3: AWAS Prototype classes in UML notation
Class Description
• An abstract class Siena Event Service has Siena and Notifiable interfaces implementations.
• Siena interface provides methods for publishing, subscribing, advertis- ing, unsubscribing and unadvertising the events and event filters/pat- terns. This interface class is associated to Notifiable interface, whose notify() method is called to send notifications to the client AWAS.
• Notifiable interface sends Notification to the subscriber AWAS client. Notification is a set of named attributes and its values. It has methods notify(Notification) and notify(Notification[]), which are im-
88 Chapter 6. Proof of Concept
plemented by the client to receive a notification or a sequence of notifica- tions respectively. • Class ThinClient inherits Siena interface class and provides thin client publish/subscribe environment to the publisher and the subscriber clients. It offers methods to control the server and requires server’s Universal Resource Identifier (URI) address and port to be defined. • Class AWAS Prototype implements ThinClient class to subscribe for event Filter or Pattern. AWAS Prototype also implements Notifi- able interface to receive notifications if the events are matched. • Filter class contains filter attributes defined by attribute name attrib- ute, binary operator Op and attribute value value. A filter/pattern is defined by using addConstraint(string, Op, value) method. For example, threshold values for river gauge level and rainfall is subscribed as:
Table 6.2: Filter subscription Filter f = new Filter(); f.addConstraint("GaugeID","GA234"); f.addConstraint("RiverThreshold", Op.GT, 3.6); f.addConstraint("RainID","RA678"); f.addConstraint("RainThreshold",Op.LT, 50.0); siena.subscribe(f,subscribe);
• SCS Implementation class emulates river gauge level and rainfall ob- servations and publishes them as events to the Siena thin client server. The events contain attributes with names and attribute values. Events are published using putAttribute(string, value) method as shown
Table 6.3: Event publication Notification e = new Notification(); e.putAttribute("GaugeID", "GA234"); e.putAttribute("RiverThreshold",4.9); e.putAttribute("RainID","RA678");); e.putAttribute("RainThreshold",45); siena.publish(e);
The prototype is deployed as Java modules on different systems acting as servers for subscriber AWAS and publisher SCS. The Siena event service is run on a system as an event server and is addressed by the publisher SCS and subscriber AWAS by its URI and service port . All three servers are within the institute’s intranet. An overview of prototype deployment is illustrated in UML notation in figure 6.4.
89 6.3. Prototype
Figure 6.4: AWAS Prototype deployment in UML notation
First testing of the prototype is done as a single instance of AWAS and SCS, in which these services subscribe and publish events to a centralized event server. Second testing is done for multiple instances of AWASs and SCSs in multiple servers. Both these testings showed successful generation of event notifications when the subscribed events by the AWAS matches to the published events by SCS(s).
6.3.3 Result
Testing of above mentioned simplified prototypic implementation successfully showed that the events representing SCS observations can be pro-actively dis- tributed to the clients, who demand for the observations defined by rules. The results of the testings were displayed in the client’s (AWAS server) command terminal user interface as notification attributes with name and value followed by an arbitrary alert message1“Threshold value breached. Flood risk HIGH!”. Enhancements can be made by incorporating GUI to subscribe for event filter and display event notifications.
This prototypical implementation can easily be extended to work on distrib- uted web service environment and its functionalities extended to allow user de-
1Screen captures of result is presented in Appendix B.1
90 Chapter 6. Proof of Concept
finition of event filters in a web form as well as send alert messages to various communication mediums.
6.4 Synopsis
The core concept of the architecture i.e. communication between SCS and designed AWAS on top of event based communication model is validated by simplified prototypical implementation. The full implementation of AWAS is technically feasible with the available software technologies. However, there are key issues to be resolved on upgrading the functionalities of current SCS and WNS in order to integrate the AWAS with them to function as a collabora- tive system of services for emergency alert warning.
91 6.4. Synopsis
92 Chapter 7
Conclusion and Recommendation
As the demand for highly temporal dynamic sensor data increases for vari- ous application domains, there is a need for OGC’s sensor web infrastructure to extend its capabilities to actively disseminate the observation data. Active Web Alert Service (AWAS) is an effort to develop a pro-active geo-service un- der OGC’s Sensor Web Enablement (SWE) umbrella to disseminate real time sensor observation data. The AWAS will enable decision makers, emergency managers as well as general public to receive emergency alert warnings and related information of ensuing natural/man made hazards such as flood, land- slide, earthquake, tsunami, chemical and toxic spills, nuclear accidents etc.
This pro-active data dissemination is enabled by a new information commu- nication paradigm for distributed environment - the event based communica- tion. The AWAS is built on top of event based communication model and inter- acts with corresponding SCS(s) by exchanging event messages. This model of communication breaks the boundary of traditional pull based request/response model by following active push data model, in which data is automatically dis- patched when the rules related to a certain event are fulfilled.
This chapter concludes the thesis by presenting the main outcomes of this research study and outlines some recommendations and directions for future work. The answers to the questions posed in section 1.5 are specifically outlined and discussed.
7.1 Conclusion
The following points outline general conclusions of this research study and an- swers to the questions posed in section 1.5.
• Spatially enabled sensor web networks provide high temporal resolution data and dynamic dissemination of collected information to support spa- tial decision making process for temporal critical application domains such
93 7.1. Conclusion
as emergency warning. Open Geospatial Consortium (OGC)’s Sensor Web Enablement (SWE) initiative provides a standardized information infra- structure to integrate distributed, heterogeneous and dynamic sensor net- works based on web service architecture enabling on-line discovery, access and control of web resident sensors and their data. However, the current SWE initiative does not have a service that is capable of sending alert notifications to the user/client when certain phenomena occurs in envi- ronment.
• Phenomena that occurs in environment can be identified and distinguished from the others by various physical parameters associated with the phe- nomena. Constraints on physical parameters of such phenomena enable to identify certain specific events. For e.g. constraint on physical para- meter defined as a threshold value for river gauge level enables to detect certain rise in river water level when the threshold value is breached.
• Based on this concept, a constraint rule based geo-service Active Web Alert Service (AWAS) is designed considering an emergency management use case of flood early warning system. The designed AWAS incorporates user defined threshold rules pertaining to a flood scenario and detects a flood event based on the threshold value exceedance.
• Research question 1: What are the typical rules AWAS should handle for alert notification in emergency scenarios?
– The constraint rules are generic rules related to the location, time and threshold value, which define the spatial location of sensor(s), the time of observation and the observed value respectively. These rule parameters can clearly identify occurrence of any phenomena in the environment. The location of sensors observing the phenomena identifies the location of occurrence, the time indicates the time of occurrence and the threshold value indicates occurrence of an anom- alous event. These generic rules are applicable to almost all kinds of emergency warning scenarios for natural and human induced haz- ards and can be extended and combined to form complex rules. – A formal definition of the taxonomy of rules and their parameters related to flood domain is required. This enables to specifically de- fine the properties of the flood, explicit sets of parameter values for threshold conditions and possible relationships among concepts and properties. – These rules are encoded in filter encodings to make them interoper- able within the OGC framework. This also makes it possible to pass the rules to any other OGC services and make query or request for data.
• There is a major limitation in data communication model to realize such a pro-active alerting service and integrate with current SWE services. The constraint being the currently implemented request/response data model
94 Chapter 7. Conclusion and Recommendation
based on pull data mechanism in which a client requests for data and the service dispatches it. This method of data transfer significantly increases bandwidth consumption as well as overhead in processing of correspond- ing services resulting in data latency and even failure in data delivery. This limitation of request/response method can be resolved by implement- ing a push mechanism of data transfer in which the data is actively dis- patched by the service as per the demand of client. Event based communi- cation model enables active push data dispatch based on event messages transactions between the participating service components.
• The alert messages sent by the AWAS requires to be encoded in an open, non-proprietary standard data interchange format that is generic and be used for all kinds of hazard warnings. Common Alerting Protocol (CAP) provides a messaging framework for emergency alert notifications and public warnings over all kinds of networks.
• Research question 2a: What are the limitations of SCS to support AWAS?
– The AWAS needs to communicate with SCS(s) to get observation data. The AWAS requires active reception of data from the corre- sponding SCS(s), which requires participating SCS(s) to dispatch the observational data pro-actively. However, the current SCS implemen- tation does not support such active data dissemination. For an active dispatch of observation data based on event based communication model, the functions of SCS must be extended to enable it to produce event messages and send to consumer AWAS.
• Research question 2b: What are the limitations of WNS to support AWAS?
– The AWAS uses WNS as communication service to send alert mes- sages to the client. However, the current implementation of WNS does not support incorporation of alert messages such as CAP mes- sage in its NotificationMessageType element. This should be ex- tended to include at least the mandatory message elements in the CAP messaging framework. As the AWAS itself provides user reg- istry interface, the registered user and communication profile must be passed to the WNS, eventually to send alert messages to the user. This requires extension of WNS interface so that the AWAS can send user and communication profile to it. However, WNS can be used as the user registry interface as it already has necessary infrastructure and functionalities to handle user and communication profile. This eliminates the need to build user registry and handling functionali- ties in the AWAS but requires functionalities in both the AWAS and WNS to be able to communicate with each other.
• Active data dissemination can be achieved by implementing event based communication model between the data producer and consumer service components. Event based communication model extends the traditional
95 7.1. Conclusion
data request/response model by enabling distributed, heterogeneous soft- ware components to communicate with each other based on event genera- tion, observation and notification. These events are simple messages that are generated when certain operation on an object terminates. The objects that generate events in event based communication are called objects of interest and those that consumes these events are called recipients. A me- diator service acts as proxy between the objects of interest and recipients and is called an event based middleware or an event service or an event dispatcher and plays a role of an observer.
• Research question 3: How does AWAS communicate with the SCS(s)?
– The AWAS is built on top of event based communication model, in which it communicates with SCS(s) on the basis of event transac- tions. The communication occurs anonymously and asynchronously with the aid of proxy event service. Any number of heterogeneous SCS(s) can take part as data provider as well as any number of data consumer AWAS can request for data, thus enabling a high degree of scalability and interoperability. – In AWAS framework, object of interest SCS(s) produce events and publishes to an underlying event service. The recipient AWAS sub- scribes for certain events via an event filter/pattern with the event service. The mediator event service is responsible for matching the published and subscribed events and sends event notifications to the subscriber when the subscribed event filter matches with the pub- lished event. – The events generated by SCS is a generic set of typed attributes with name and corresponding values. Basically, the attribute set contains attributes for the name of corresponding SCS and/or sensor, location of the sensor, time stamp of the observation and the observed value and is derived/parsed from corresponding elements of an O&M docu- ment containing the sensor observations. – An event filter subscribed by the AWAS is the same in structure of the attributes as the published events but in addition, it contains a binary predicate operator that set a constraint rule in the attribute value. An event pattern is a set of composite filters made up of filters combined by a logical operator. The attributes and the constraint operator in an event filter/pattern are derived from the user defined threshold rule registered in the AWAS.
• Research question 4: How to implement event based communication model between SCS(s) and proposed AWAS?
– The AWAS can be modelled into three different schemes of event gen- eration. In the first scheme, the AWAS subscribes for an event and SCS(s) publish their events asynchronously with the event service. Consequently event notifications are sent to the subscriber AWAS
96 Chapter 7. Conclusion and Recommendation
when the events are matched. The second scheme differs from the first scheme as it does not require a middleware event service. In this scheme, user defined threshold rules are checked against observed data in SCS itself. If the observed data and threshold rules match, an event is sent to the client AWAS. In the third scheme, events are published and subscribed with a specialized network called content based network in contrary to the first scheme where the events are handled by an event service component. This service eliminates the need of SCS altogether as the AWAS communicates directly with ac- tive sensors capable of sending events themselves via a content based network infrastructure. – The first scheme provides maximum flexibility and scalability in the system allowing any number of SCSs and AWASs to participate anony- mously and does not require major enhancements in participating SCSs. Where as, in the second scheme, the participating SCSs and AWAS must know each others service addresses, which might cause severe limitations if there are number of participating services. Be- sides this issue of scalability, the SCS would require major enhance- ments to incorporate functionalities to accept threshold rules from the AWAS, validate these rules against its observed data and send events to the AWAS if the rules are validated. The third scheme provides more advanced architecture than the previous two and is technically feasible with available smart sensor hardwares and sup- porting network infrastructure. – The AWAS architecture is designed based on aforementioned first scheme. The presented architecture is based on layered architecture design concept for software engineering and is decomposed into three levels of abstractions - the general concept, architectural concept and deployment concept representing conceptual, logical and execution architectures respectively.
• The AWAS is built on web service architecture on top of event based com- munication model. The web service architecture framework is responsible for information request and response where as the event based communi- cation model is responsible for information delivery. • Research question 5: How to evaluate the conceptual model? – A simplified prototype is built to prove the core concept of the system i.e. event based communication between participating AWASs and SCSs. Implementation of SCS is done by building a sensor emulator, which generates sensor observations at specified interval and pub- lish the observations as events to an underlying Siena event server. A subscriber class is built to implement AWAS’s subscribe method for subscribing event filter with the Siena event server. The successful testing of the prototype on distributed single and multiple instances of services proves that the concept AWAS based on event based com- munication model is feasible. However, to implement the concept in
97 7.2. Recommendation for Future Work
SWE environment based on OWS framework, minor enhancements on supporting services is needed as well as efficient and compatible event service is to be identified.
• The coalition of web service framework and event driven framework archi- tecture offers a new service architecture for pro-active services in distrib- uted environment. The AWAS is the first effort to design a pro-active alert notification service implementing OGC Web Services (OWS) and event based communication framework. This research is an attempt to study the viability of integrating these two disparate paradigms and design an architectural framework for its actual implementation as a new SWE ser- vice for emergency alert messaging. The result obtained from a simplified prototypical implementation clearly demonstrates that the AWAS concept is viable. However, there remains few implementation issues that needs to be resolved for its formal specification based on OWS standards and eventual implementation as a new SWE service.
7.2 Recommendation for Future Work
The work presented in this thesis represents the conceptualization of an alerting service based on OWS and event based model architectural frame- works. The fusion of these two paradigms is itself a new concept in many aspects and there are still many issues ranging from semantics to implementa- tion to be resolved before such an alerting service can be realized based on the architecture presented in this research thesis. The main impending issues are outlined in respective chapters under the heading “Open Issues”. Some direc- tions and recommendations related to these open issues that requires further investigations are described in the following points. These points only discuss issues related to the SWE aspects that requires further study in order to inte- grate event based alerting service.
• A formal definition of flood domain ontology and rules related to it is nec- essary to realize a rule based alerting service. Several researches [57][66] have been undertaken related to the definition of ontology for flood man- agement. However, these works do not contain definition of threshold rules pertaining to flood.
• This study is based on the assumption that there exists Sensor Collection Services that can generate events and actively send them to an underlying event service. However, the current SCS architecture does not support such functionalities and requires to be upgraded in order to actively send observations to the clients. Other issue related to the enhancement of SCS is whether to build an integrated service that can itself do the source filtering of events i.e. SCS can itself manage, match and dispatch the events without the use of middleware event service tier.
• Similarly, Web Notification Service also needs to be enhanced in order to incorporate CAP alert messages on its notification scheme. Furthermore,
98 Chapter 7. Conclusion and Recommendation
WNS as a messaging service needs to include QoS guarantees related to reliable delivery of messages, message queuing and message prioritiza- tion. On the other hand, an integrated alert notification service can be build, which incorporates the capabilities of WNS to handle user regis- trations and messaging and the capabilities of AWAS to generate alert notifications based on event model.
• This architecture presented in this study basic set of rule containing spatio- temporal and observational parameters. Event model needs to be ex- tended to include more observational parameters from the O&M docu- ment.
99 7.2. Recommendation for Future Work
100 Appendix A
A.1 User rules expressed in Filter Encodings Page 1 of 1