VOEvent

Aim: To demonstrate the generation, routing, signing, consumption and compilation of VOEvent packets using VO standards.

Team (in alphabetic order): Steve Allen, Avi Fhima, Jorge Garcia, Ashish Mahabal, Aaron Price, Rob Seaman

Implementation: This was put together in approximately two days and contains a fair number of hacks as packages and standards that are not fully threshed out are involved in places. One of the main intentions of the project was in fact to determine the obstacles in a proper implementation of such a system. Keep tuned for developments. We hope to keep the page updated with latest happenings. Some additional details can be found on the IVOA VOEvent page and the NVOSS talk.


As indicated in the schematic above, the project consisted of six different pieces:

A VOEvent generating form that conforms to the VOEvent standard is where the life of a packet announcing a VOEvent starts. It can be generated by a person by hand or by a program on behalf of a robotic instrument. It has two parts consisting of essential and non-essential sections.

A VOEvent needs to be authenticated before it can be believed by subscribers. The "seal" of the agency indicates to the downstream modules that the event comes from a known agency. Code from xmlsec was used to do the signing. The keys and X509 certificates used for the signing were created using the openssl libraries and tools.

The W3C main page for XML digital signatures has more details.

The W3C (and IETF) recommendation for XML digital signatures allows an XML element to wrap a signature, a signature to wrap an element, or the signature to be entirely disjoint.

The most immediate XML problem with the project demonstration was that the schema for VOEvent (and presumably for almost all other IVOA schemas) does not admit a <Signature> element.

For this simple case we created a new root element called VOEwrapper which had a VOEvent and a Signature as child nodes.

Ultimately the VO schema working groups will have to consider which of the VO schemas may have elements which need to be authenticated. Those schemas will have to admit <Signature> elements.

In the case of many simple VO schemas the typical usage will be that the entire content of the XML document will never be changed. In some cases (probably including VOEvent) if a change is needed then a new XML document would be created with a reference to the previous document, and the entire new document would be signed by a single authority. For schemas such as these it will be sufficient to admit zero or more <Signature> elements as part of the schema.

In the case of some more complex VO schemas it may be desirable to permit different child elements to be authenticated by different authorities. In these cases the VO schemas will need to admit <Signature> elements. It may also be desirable for the IVOA working groups to publish XPath transforms which select the elements of the XML document which are commonly signing by different authorities.

Elvin (also here) was used for content based routing. By supporting the definition of subscription rules, it allows broadcasting different kinds of packets as separate streams, e.g., "raw" events, "signed" events, "follow-up" events, and so on. Different subscribers can then listen to only the streams they are interested in - or rather, the router will only forward packets to clients who have previously subscribed to rules matching those packets. One could also choose to listen to events from a specific agency or a specific type of event, for example. Elvin claims support for XML marshalling and wide-area federation. The vendors say it is low latency and "massively" scalable.

As configured, the system was somewhat awkward to use due to its blindness to XML syntax and to differences in end-of-line characters between the Mac, Linux and Windows platforms. For simplicity, we also chose to rely on scripting the supplied producer and consumer clients. This required us to stop listening to the event stream to allow actual processing of messages to occur, for example to sign packets or call web services. This limitation is not intrinsic to Elvin, but note that the producer/consumer paradigm is not conceptually identical to the VOEvent publisher/subscriber pattern. In particular, the former is synchronous and the latter, asynchronous. Alternates to Elvin will be investigated, including Apache pubscribe, ICE and Jabber.

A router is only one piece of a fully functioning VOEvent publisher. It is likely that signing, certification and authentication duties will be co-located with at least some of the publisher nodes. Publishers are also responsible for archiving packets in support of future queries and asynchronous delivery of packets. A simple archive was realized as part of the summer school demo. Not all interested parties will be listening when an event occurs, but all want to be reliably informed as soon as possible. VOEvent publishers provide access to the wider community of VOEvent authors and some minimum author standards must be met for publishing to occur. Providing distributed support for these standards will require something similar to an internal VOEvent "registry" of known VOEvent resources.

A typical deployed VOEvent network might resemble:


This is where people can subscribe to various subsets of events. A fun schematic shows the different types:

A compilation of all VOEvents, including raw, signed, follow-ups etc. will be maintained here. RSS Parser (php code) was used to read and translate VOEvent packets into human readable form.
In the future there will be following additions:

This part involves parsing a VOEvent packet for its id, position and error ellipse and obtaining a list of possible VOEvent contaminants (e.g. known asteroids and known variable stars) in that area. In particular, the perl script takes the max. of the two error dimensions, ensures that it is between 60 and 1800 arcsec. and returns a list of objects in that region from

Actually, currently only links are written to the voeventable.html HTML page automagically updated when a new VOEvent arrives, but the hacked perl code does contain SOAP::Lite code to turn on the part that will directly call the webservice. Also, it is planned to convert the GCVS database in to webservices using a local mysql dump (provided by Aaron).

In the future the list of returned objects will be plotted as the Guide Stars are (next part).

When a certified event is automatically parsed in an Aladin script, a finding chart for the field of interest is computed and created. The resulting image, including a sky snapshot, with the best selected guide stars, detailing instrument configurations and field of view, plus VOtable with the selected stars are dynamically display on the default browser, keeping a safe copy on the archive area. On the client side (Observatory, telescope or instrument) a more specific solution is easy to implement, just using the correct filters for the right apertures, instrument setup, wave front sensors detectors or more specific catalogs.