Copyright © 2010 Open Geospatial Consortium, Inc.
3
1.4 Future work
This report represents the continuation and refinement of the work that was performed in OWS-6 with respect to developing the OGC Event Architecture. Significant progress has
been made in OWS-7. At the same time, many work items were identified to be addressed in the future:
Investigate additional PublishSubscribe Technologies
– WS-Notification was the only technology that could be investigated in detail as to its applicability to
realize the general publish subscribe requirements defined during the testbed. Additional technologies like Atom AtomPub as well as WS-Eventing need to be
investigated in detail as well to enable a decision which technology the OGC should recommend for realizing publish subscribe functionality per service
binding KVP, POX, WS-, RESTful. Keep in mind that if no recommendation is made for one technology per binding, interoperability of systems using and
offering publish subscribe functionality is going to be hard to achieve. This work may also lead to a refinement of the requirements model established in OWS-7
and thus also to a refinement of the publish subscribe behavior model.
Detailed Testing of Event Channels
– The OWS-7 Aviation and SFE threads did not make use of dedicated event channels. Subscriptions targeted the whole set of
events available at an Event Service instead of connecting to channels that pre- filter the events. The FDF-Geosynchronization thread used some specific event
channels and also tested ad hoc channel functionality to a certain extent. Significant performance benefits can be achieved by defining and applying event
channels, which is described in this report. Further work should concentrate on defining the concept of event channels in more detail and actually test it. This
work should be a cross thread activity to prevent duplicate efforts across future testbed threads. Tools could be developed to simplify the interactions required to
create event channels and to manage them.
Notification Delivery Mechanisms
– In the testbed, notifications were pushed or pulled from event sources and thus delivered to subscription consumers.
Sometimes single events were sent when they occurred, other times they were retrieved in regular intervals. Sometimes a notification contained only one event,
sometimes multiple events were delivered in one notification. These different ways to deliver events should be investigated in more detail and clearly
documented. Batch transmission of multiple events and in pre-defined intervals could significantly reduce the communication overhead of sending single events.
Policies could be defined to be used by subscribers to define how exactly events
should be delivered to a subscription’s consumer. This could also incorporate transformation of a given event into another encoding,
for example placing the event into an EDXL-DE or CAP message to be delivered via emergency messaging middleware. In that respect, the Web Notification
Service could be enhanced to easily send emergency messages to such messaging systems.
4
Copyright © 2010 Open Geospatial Consortium, Inc.
Improve Event Filtering
– Various aspects of event filtering are described in this report. Issues but also ideas to significantly improve filtering of events have been
documented. Especially spatial filtering using dynamic filter properties event processing functionality could benefit the filtering results. In addition, well-
defined structures and mechanisms to enable automatic conversion transformation of the reference systems used by filter operands and filtered
properties would be a valuable feature. Further work on these aspects could considerably improve the filtering
functionality available at OGC services, especially when event filtering is concerned. Performed as a cross thread activity, this work would benefit multiple
domains and avoid duplicate work.
Event Security
– Initial work has been performed to identify security threats that apply specifically to an Event Architecture. Measures to mitigate these threats
have briefly been described as well. Further work on Event Architecture in general and especially Event Service developments should always take into
account relevant security aspects. Work on event security should continuously be improved and actually be tested to achieve the building blocks to deploy an
enterprise ready Event-Driven SDI.
Specification Guidelines
– Work that was started in OWS-6 to support users implementers and standards architects of the Event Architecture was continued
in OWS-7. Tutorials how to use Event Architecture components as well as guidelines that define which information is needed in standards that want to
include Eventing Architecture functionality publish subscribe interfaces, event channels etc form one important building block of the OGC Event Architecture.
Further work on aspects of the Event Architecture should always include the continued development and refinement of tutorials and guidelines for using and
deploying the architecture.
Event Discovery o Event information acquisition
– In OWS-7 the TopicSet data type from OASIS WS-Notification was used to provide eventing information for an
Event Service. We need to determine how best to acquire a TopicSet document from an Event Service. One option is to make use of WS-
Notification accessor methods to get a services TopicSet . Another possible way to obtain the TopicSet eventing information would be to put
it into a services Capabilities document like the SWE 2.0 services intend to do it. Depending on which publish subscribe interface is going to be
used in a given OWS binding, the event information may also be provided in a different way. These approaches have yet to be tested and thus are
potential areas for follow-on investigation.
o Event channel scheme
– Consider whether discovery is better served by introduction of a classification scheme to identify all event channels. This
may be useful if a set of channels is not large and fairly stable. Use of a scheme would make them more accessible to client software and offers
Kategori