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.
Kategori