ANSTO E-Science workshop

1. ANSTO E-Science workshop Romain Quilici University of Sydney • CIMA • Instrument Remote Control • Integration with GridSphere

2. CIMA: Project goals • Integrate instruments and sensors (e.g. real-time data sources) into a grid computing environment with Web Services interfaces • Abstract instrument capabilities and functions to reduce data acquisition and analysis applications’ dependence on specialized knowledge about particular instruments • Move production of metadata as close to instruments as possible and facilitate the automatic production of metadata • Develop a standard, reusable methodology for “grid enabling” instruments • Collaborate with scientists in academia and industry in a broad range of disciplines who either develop instruments or whose work depends on the details of using them.

3. CIMA Components • Service architecture • Instrument representative (IR) code (device independent) • Drivers (Plug-ins, device dependent) / Software (BIS) • Service life cycle, high level protocol, communications, self description, discovery, security • Communications protocol • Standards based • Support for synchronous and asynchronous interactions between client and IR • Instrument and sensor description • Ontology-based with static and dynamic information • Clients should be able to build functional model from description

4. Register Notify Locate Events/Streaming Request/Response Instrument Semantics, Metadata Registry and directory server Web Services interface Data Acquisition Code(s) Analysis Codes Storage Storage

5. CIMA instrument service User application (1) Session Request Service main (2) Session token … User app mainprogram Channel(Sink) Web Services Interface (3) Request Channel(Source) (6) Response with Data Plug-inModule #1 Plug-inModule #2, etc. WS Interface (7) Streaming Data Sensor Actuator (4) Session request Parcel with credentials Session token returned to client Request Parcel from client: describe, get, set, register, etc. plus session token Channel calls appropriate plug-in for request type and data source Plug-in retrieves data or runs actuator Response Parcel is returned to client (dataor result code) If Client registers for event or streaming data Service calls client periodically or when data is available (timer or event-driven from plug-in) Session request Parcel with credentials (5) Sensor Data Actuatorcommand Session token returned to client Request Parcel from client: describe, get, set, register, etc. plus session token Channel calls appropriate plug-in for request type and data source Plug-in retrieves data or runs actuator Response Parcel is returned to client (dataor result code) If Client registers for event or streaming data Service calls client periodically or when data is available (timer or event-driven from plug-in)

6. Plugin Configuration • XML based • Java Reflection API to load plugins at runtime

7. Instrument control • Must support several types of commands • Void command: Set variables • Synchronous command: Get • Asynchronous command • New parcel types: • Get • Command

8. Instrument control • Strong Security needed • Several levels required. Authentication Authorization, Encryption… • Log mechanism • Might be achieved with certificate (GSI/MyProxy) or with Shibboleth/XACML • Need for operations synchronization: • Concurrent access: Queues, Priorities, locks • Wait mechanism: • wait for parameters in order to build a command the instrument/drivers/software can understand. • Dependency between plugins • Parcels containing a sequence of commands • Instrument Constraints description • Self description • Defines rules for the instrument: collision map,… • Loaded dynamically by clients

9. Implementation Status • One C++ version • Used by several sites • Difficult to extend • 2 Java versions • Indiana • University of Sydney  Need to merge the 2 versions • On going projects • Instruments Ontology • Registry

10. CIMA-GridSphere • Provides Instrument monitoring and control • Technologies: Tomcat, WS (axis/XFire), Pushlets, AJAX, JavaScript, CIMA • Portal contains CIMA Sink (clients) • Plugin architecture • XML based configuration • JAVA Reflection API • Instantiated and Registered when the portlets container is loaded • Container Lifecycle • Unregistered when the container is destroyed

11. WebServices Container Data Manager SRB Dynamic content pushed: Pushlets-Ajax User Container A Monitor Portlets Container Several simultaneous users. Only one Administrator Data cache Monitor User Control CIMA component Data Retrieval Admin 1) Requests: XML Parcels SOAP SOAP Pushed Data: XML Parcels 2) Responses: XML Parcels WebServices Container CIMA component SOAP Pushed Data: XML Parcels Container B Instruments

12. WebServices Container Data Manager SRB Dynamic content pushed: Pushlets-Ajax User Container A Monitor Portlets Container Several simultaneous users. Only one Administrator Data cache Monitor User Control CIMA component Data Retrieval Admin 1) Requests: XML Parcels SOAP SOAP Pushed Data: XML Parcels 2) Responses: XML Parcels WebServices Container CIMA component SOAP Pushed Data: XML Parcels Container B Instruments

13. CIMA-GridSphere • Status: • Instruments • Labjacks (monitoring) • Diffractometer (monitoring and control) • Cameras • Security • Username/password authentication • No authentication in container B • Future work • Ensure only one operator (control) at a time, or must be synchronize at CIMA level • Rely on a safe/standard security infrastructure • Portal level • Instrument level • Delegation between both entities • Provides a list of instruments with their descriptions • Obtained from a registry • Dynamic registration, involves registration/user management • Dynamic Graphical Interface: portlet view built from the Instrument description • Use PGL to interface with SRB