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

any new data is available = polling). EDA had many forms during the years when it
was used in local networks and now it is often discussed in relation to SOA and
how these two can interact. This can be a very interesting feature when used in a
World-Wide-Web environment for many uses and especially for sensor data pub-
lication and monitoring problems. Theoretical discipline (without practical appli-
cation) which tries to combine these architectures is called SOA 2.0 (SOA
2.0 = SOA + EDA). Only local area network (LAN) monitoring and alerting
systems are widely used today. One type of their output is sending SMS/e-mail
messages to the speci

ed group of users (e.g. crisis team) if some threshold is
exceeded. This system is good for crisis team disaster early warning and is built
with reliability in mind. Such systems are not available to the public today. For the
public, another OGC Sensor Web Enablement standard was proposed and named
Sensor Alert Service (and a very new Sensor Event Service). These SOA web
service speci re-

wall unfriendly (XMPP protocol for SAS) or requires the consumer to have a public
endpoint address (SES). As we know, IPv4 is still the leading speci

cations have some disadvantages in transport binding which is

cation and not
many users own such an address. From a global public monitoring and alerting
perspective, these solutions are still weak for the task (and as a result they are not
well-known).
The motivation for our work was dealing with performance issues of web ser-
vices at first. After we built an API and experimental GIS-based system, new
opportunities and topology enhancements were discovered. In the

first part of the
text we introduce some fundamentals of the proposed style to understand the
concept and contribute with a comparison of the new concept with the style used
today. Next we will describe the experimental system and publish the results of
performance analysis. We would like to create another experimental system in
future which should show a reduction in the time needed to load WMS tiles from
the GIS server by pipelining enhancements of developed API (but that is not topic
of this paper). This will show us how pipelining the capabilities of our architecture
style can improve the performance of such a very common use. Finally we will
describe topology and event processing enhancements which are interesting espe-
cially for use-cases and can be used for building a publicly

available alerting solution (deployable to the cloud SaaS environment). The
resulting description will be transformed to the draft speci

“ GIS on the web ”

cation and API after

more tests on the experimental system.

2 Changing Architecture Style

The Weda architectural style is a hybrid architectural style that we have derived
from other network-based standards, such as web services [ 5 ] and HTML5 web-
sockets [ 6 ] to get a practical real-time SOA 2.0 [ 7 ] solution for WWW. It provides a
uniform connector interface to the client and server implementers allowing them to
extend their existing web services (SOAP 1.2, REST, POX) with a new type of