VOEvent session at IVOA Interop

[Rob Seaman]

  Roy Williams wrote:

> VOEvent session at IVOA Interop
> -------------------------------
> Beijing, 9am Thursday 5/17
>
> (2) Technical objective is making extension schemas (see summary  
> information below). If you would like to contribute to this in  
> Beijing, the discussion begins at the Registry session 10am Tuesday  
> 5/15. In any case, please contribute your thoughts by email to this  
> group.

Sounds like a good agenda - presumably Matthew will be talking about  
the results of this at the "Hotwired" workshop?

> One of the objectives for VOEvent at the Interop is to build ways  
> of registering Repositories and Publishers with the VO Registry.  
> The first way to do this is to fill in a registry form for a  
> *Project* or *Organization* that deals with VOEvents, explaining  
> everything in the description, or providing a URL that has the  
> explanation. The associated IVORN can then be used in the VOEvent  
> packets themselves, so that contact information does not have to be  
> repeated for each published event. Another way to get involved is  
> to fill in a form defining a *Dataset*, meaning a collection of  
> past events, with an implication that there will be more.

Ok.

> In the VOEvent definition, several roles are defined, including  
> Author, Publisher, Repository, and Subscriber. The Publisher  
> accepts publication of events and accepts subscriptions; whenever  
> an event is published, subscribers get it very quickly, if it  
> matches the subscription criteria (eg "I only want bright  
> supernovae in Virgo"). The publisher may support one or more  
> transport protocols to push events to subscribers. The Repository  
> stores events that may be aggregated from several publishers. It  
> can take an event identifier (IVORN) and return the corresponding  
> VOEvent packet. It can take queries about past events (eg. "give me  
> all events in Virgo from April 2004")

So far so good.

> ** A /*Publisher*/ takes packets from an Author, checks the  
> validity of a packet, and assigns a unique identifier to it; either  
> the author or the publisher makes the actual XML syntax of the  
> event, but the publisher is responsible for the XML-validity of  
> that syntax. Publishers are expected to register with the IVOA  
> registry as described below.
>
> Publisher Capability Extension Schema
>    Who is running it
>    What kinds of events are published
>    How to subscribe to a feed
>       criterion for which ones are wanted by push protocol
>    How to publish events
>       permissions and authentication requirements
>    Which push protocols are supported for publish and for subscribe
>       Jabber
>          server name
>          feed name
>          login name and password
>       TCP Vanilla
>          server name
>          port number
>          is there any authentication?
>       RSS
>          server URL
>          how to get different feeds
>          version of RSS

RSS is pull...

I just want to point out that registries are not only for humans.   
One topic for Hotwired is how brokers talk to each other  
autonomously.  Presumably this starts with a registry query, like  
"who is out there?", and may end with a completely self-organizing  
network of packet-passing brokers, à la the internet.  We're going to  
get awfully tired of manually configuring our packet streams, otherwise.

> ** A /*Repository*/ persists packets either permanently or  
> temporarily, and runs a service that allows clients to resolve  
> identifiers and apply complex queries to the set of events in the  
> repository. A repository must subscribe to one or more input  
> VOEvent streams. Repositories are expected to register with the  
> IVOA registry.

Somehow the VO always ends up back with federated archives :–)

> Repository Capability Extension Schema
>    List of publishers whose events are kept
>    Queries by humans with web forms
>    "SEAP" protocol endpoint to fetch events (SEAP not yet defined)
>    endpoint for service that resolves event IVORNs
>    Harvesting interface

The name SEAP may also represent the self-organizing communications  
between brokers.

>    Can a client subscribe to a Repository?

Not directly.  I've attached my SPIE slide on this.  Subscribers talk  
to entities representing the role of "relay" (or "filter").  These  
may well be packaged up in brokers with other roles such as publisher  
and repository, but a subscriber and a repository both represent O-O  
"nouns" - they need a verb in between.  One advantage of this is that  
a relay can serve as a front-end to either a publisher or a  
repository such that the nature of the source of the packets is  
hidden from the client subscriber.

Another way to look at it is that we are building a network of only  
three types of VOEvent components:  authors, packet brokers, and  
subscribers.  A given broker may emphasize the functionality of a  
publisher or repository or both, but always includes at least the  
simplest functionality of a relay (i.e., filtering is optional).   
Brokers are connected in some as-yet-to-be-defined way like  
tinkertoys.  Authors funnel information in - subscribers funnel  
information out of the VOEvent network.

Rob
------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VOE_robust.pdf
Type: application/pdf
Size: 630000 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20070504/f013ed11/attachment-0001.pdf>