1. The rise of the robots… Alasdair Allan School of Physics, University of Exeter Alasdair Allan School of Physics, University of Exeter

2. VOTech DSRP, Sorrento, 6 - 9th March 1 eSTAR in a nutshell

3. VOTech DSRP, Sorrento, 6 - 9th March 2 The eSTAR network © Nik Szymanek User Agents Embedded Agent The VO Gateway Service Embedded Agents OGLE III Alert Agent GCN Alert Agent Broker

4. VOTech DSRP, Sorrento, 6 - 9th March 3 What does VOEvent have to do with the VO? –event messages from DBs –event messages from workflow –data mining for added semantic content –testbed for agent architectures in the VO Why should I be interested? –major drivers for the adoption of the VO VOEvent and VOTech?

5. VOTech DSRP, Sorrento, 6 - 9th March 4 What we’ve done so far? Convenience layer and parser (Perl & C++) –building common cases (including GCN) –different parser methodologies –http://voevent.sourceforge.net/ Prototype event network live and on sky Limited (hard-wired logic) brokering Archiving and persistent storage RSS test feed(s) –programmatic, or human readable?

6. VOTech DSRP, Sorrento, 6 - 9th March 5 Where are we going? Event brokering (aggregators) –time critical –non-time critical (data mining?) Event archiving and persistent storage –REST interface –persistence of data products Search service –REST interface Event Feeds –pull, or push?

7. VOTech DSRP, Sorrento, 6 - 9th March 6 Unanswered questions Protocol standard(s?) –How the documents are passed… Transport standard(s?) –How the documents are carried…

8. VOTech DSRP, Sorrento, 6 - 9th March 7 Protocol work The recent work on interoperability between eSTAR and RAPTOR/TALONS has show the importance of, “ack” messages “iamalive” messages Gateway Service eSTAR Broker

9. VOTech DSRP, Sorrento, 6 - 9th March 8 Mini-interoperability meeting Tentative agreement on a protocol standard –“ack” and “iamalive” message types Tentative agreement on transport standards –pull via RSS feeds –push via vanilla TCP/IP TALONSCaltecheSTAR

10. VOTech DSRP, Sorrento, 6 - 9th March 9 Should we mandate transport? Why? Nobody thought about RFC 1149 when IP datagram packets were standardised… See http://www.blug.linux.no/rfc1149/http://www.blug.linux.no/rfc1149/

11. VOTech DSRP, Sorrento, 6 - 9th March 10 An architecture diagram showing; publishers, subscribers, relays and repositories, along with the more complicated aggregators and brokers. “Atomic” services Publisher Subscriber Relay Repository Author

12. VOTech DSRP, Sorrento, 6 - 9th March 11 UML diagram CREDIT: Philip Warner, NOAO

13. VOTech DSRP, Sorrento, 6 - 9th March 12 Event feeds There are two ways to feed events to consumers, Pull model (feeds) –polling –e.g. RSS feed Push model (forwarding) –via REST, SOAP or vanilla TCP

14. VOTech DSRP, Sorrento, 6 - 9th March 13 Pull model Advantage –under client control Disadvantage –as slow as the polling interval A pull model, e.g. RSS, is never going to work for rapid response cases like GRB or transient follow-up.

15. VOTech DSRP, Sorrento, 6 - 9th March 14 Push model Advantage –theoretically faster, depending on architecture Disadvantage –administrative nightmare for publisher A push model, e.g. GCN, is the only way to do rapid response work. However it isn’t really optimal, so we’ll probably be stuck using both approaches. Shouldn’t optimise our standard for distribution via RSS model.

16. VOTech DSRP, Sorrento, 6 - 9th March 15 Aggregators Why should we aggregate event feeds? Consolidation –Do we need to support multiple publishers? Removal of duplicate events Added semantic content Trust issues

17. VOTech DSRP, Sorrento, 6 - 9th March 16 Storage Why should we permanently store event messages? The data itself will be replicated elsewhere in the VO. Why do we care about the original message? If we want to search, we have to store. However, to me, the best use case for persistent storage is actually event feeds…

18. VOTech DSRP, Sorrento, 6 - 9th March 17 Its an optional sub-element of the RSS tag that allows the feed publisher to include a link to a file. It has three required attributes. The url=“ ” attribute says where the enclosure is located, length=“ ” says how big it is in bytes, and type=“ ” says what its type is, a standard MIME type. e.g, This is how podcasting works..

19. VOTech DSRP, Sorrento, 6 - 9th March 18 RSS feed VOEvent GCN Notices en RSS feed for GCN notices http://voeventnet.caltech.edu/GCN.html MILAGRO_Source trigger 886-1 Possible GRB The event time is 2005-12-01T16:24:15 UT. Location RA 232.1248 Dec 62.9797 (J2000) Fri, 02 Dec 2005 16:09:52 PST http://voeventnet.caltech.edu/Notices/ivo_GCN_MILAGRO_58_886-1_2005-12-01T16:24:15.xml Scott Barthelmy GCN scott@milkyway.gsfc.nasa.gov http://gcn.gsfc.nasa.gov/gcn3_archive.html.

20. VOTech DSRP, Sorrento, 6 - 9th March 19 RSS feed VOEvent GCN Notices en RSS feed for GCN notices http://voeventnet.caltech.edu/GCN.html MILAGRO_Source trigger 886-1 Possible GRB The event time is 2005-12-01T16:24:15 UT. Location RA 232.1248 Dec 62.9797 (J2000) Fri, 02 Dec 2005 16:09:52 PST http://voeventnet.caltech.edu/Notices/ivo_GCN_MILAGRO_58_886-1_2005-12-01T16:24:15.xml Scott Barthelmy GCN scott@milkyway.gsfc.nasa.gov http://gcn.gsfc.nasa.gov/gcn3_archive.html.

21. VOTech DSRP, Sorrento, 6 - 9th March 20 Infrastructure changes for VOEvent Main change needed is to the registry, need to be able to register the “atomic” VOEvent services –author, publisher, relay, repository, subscriber Also need to handle services which do more than one atomic operation, –aggregator (relay + repository) –broker (relay + repository + publisher)

22. VOTech DSRP, Sorrento, 6 - 9th March 21 Infrastructure changes for agents Again the main (only?) change needed is to the registry, need to be able to register the agents. New types of services, –agents at telescopes –agents doing science –brokers for data mining

23. VOTech DSRP, Sorrento, 6 - 9th March 22 Things I’m going to promise you… Deliverables –agents deliverables –VOEvent standards & prototypes –integration into the VO

24. VOTech DSRP, Sorrento, 6 - 9th March 23 VOEvent deliverables Prototype “first cut” infrastructure VOEvent parsers (Perl & Java) Library to co-ordinate with Registry –convenience layer to hide registries Standards work, input into standards documents VOEvent prototype network –message handling & forwarding –storage & archiving –search services

25. VOTech DSRP, Sorrento, 6 - 9th March 24 Agent deliverables Event Broker (Agent) –aggregation of messages –data-mining for added semantic content –publishing its own event feed Query Broker (Agent) –marshalling asynchronous queries –encapsulation queries, hides low level interfaces Neural networks –more intelligent, intelligent agents –enhanced decision making for the VO

26. VOTech DSRP, Sorrento, 6 - 9th March 25 Integration with the VO? Emitting VOEvent messages from Workflow Wrapping ACR and Workflow inside agents Distributed storage of event messages in VOSpace

27. VOTech DSRP, Sorrento, 6 - 9th March 26 Conclusions Two different groups of people working on VOEvent Conflict between these groups now (mostly) resolved Standards moving forward, a lot of prototypes now being written at Exeter, Caltech and Los Alamos A good testbed for the intelligent agent work