Towards a Solution for the Public Web-Based GIS Monitoring and Alerting System - Geoinformatics for Intelligent Transportation - page 119

sensors systems. SWE is technology to enable the implementation of Sensor Webs.
Wild res, river basins, tsunami alerts, and environmental risk management are just

some of the uses of OGC

s interoperability framework for web-based access and
control of sensors and sensor data. One of the SWE standard

'

s services, the rela-
tively new Sensor Observation Service (SOS, 2008), provides an API (application
programming interface) that allows web servers to collect data from subscribed
sensors and public to explore their nearly real-time data. The goal of OGC Sensor
Web Enablement SOS is to provide access to observations from plug and play
sensors and sensor systems in a standard way that is consistent for all sensor
systems including remote, in situ,

'

fixed and mobile sensors. SOS standard is based
on the REST (SOS 1.0) or SOAP (SOS 2.0) protocols. SOAP/REST protocols are
the implementation of web services (and web services are a well-known application
of SOA

— service oriented architecture). Messages are exchanged using a

request reply pattern and interaction is synchronously initiated by client. The

question is if the standards are prepared today to be as interactive and intercon-
nected to be usable from a global perspective. Many sensor systems are built at a
local level and their read-only data is published on the web. There is a large space
for linking these autonomous systems to the big sensor web and evaluating different
event types with some higher automated logic or with preferences de ned by each
user. As with other SOAP web services, performance may also become an issue
and can negatively impact the user experience. Each request uses a shared HTTP
persistent connection over a single TCP connection (in the best case) and waits for
its response before another request can proceed. Web browsers open a memory-
reasonable number of connections (for example 6 for Chrome) to partly overcome
such limitations and developers use AJAX that prevents UI blockage (browser
communicates synchronously). But the performance problem and other web service
limitations still remains. At the time of writing, SOS standard are becoming known
in web mapping software and

-

first implementations exist (for example OpenLayers
javascript library provides a very limited functionality for requesting the SOS
service). So as we can see, for Sensor Observation Service, the mechanism is
publicly available and open, which can overcome its other disadvantages. As for
other OpenGIS standards, we think that this speci

cation will become broadly
popular in future. However, because of technology limitations, this web service
stack cannot be used for real-time monitoring and alerting in particular. In the next
few chapters we want to describe our approach to overcome these limitations and
also to present a version of an experimental system that we use to measure its
performance parameters and to tune the specification draft.
In 2003, Gartner introduced [ 2 ] a new terminology to describe a design para-
digm based on events: Event-Driven Architecture (EDA). EDA [ 3 , 4 ]de nes a

methodology for designing and implementing applications and systems in which
events are transmitted between decoupled software components and services. Event
objects are sent from an event source to the event consumer in asynchronous
messages at times determined by the event source. Pushing event objects proac-
tively reduces latency (the time required to respond to an event), compared to
waiting for consumers to pull event objects (for example, by repeatedly asking if