The DORII Middleware. Instrument Element (IE)

Overview

Traditional Grids are composed mainly of computing and storage resources. The Instrument Element (IE) component, as its name suggests, adds a possibility to include such devices as scientific instruments and sensors in the data elaboration process. In other words, the Instrument Element represents a virtualization of data sources in a Grid environment.

The main goal of the middleware is to provide users with a simple way of attaching their scientific instrumentation to gLite-based grids. The IE framework provides support for secure access control, concurrency control, simple Grid storage access and JMS publishing. It offers a common interface for accessing instrumentation. Instruments and sensors are interfaced via Instrument Managers that allow connections to physical devices or more precisely, their control systems. Instrument Managers consist mainly of the Java client code for the instrumentation and should run inside the IE installation.

Instrument Element runs as an Axis web service inside a Tomcat servlet container. A schematic overview of its architecture may be seen in the following picture.



Instrument Element presents a SOAP web service interface for client access. The interface contains methods for controlling the Instrument Managers and thus the devices behind them, as well as the authentication methods. The framework does not provide a client GUI.

User authentication is performed using the gLite/GSI security model based on user's proxy delegation, with a fine-grain authorization control through Virtual Organization Membership Service (VOMS) attributes. The VOMS roles are mapped to predefined Instrument Element roles and may be modified by the administrator during runtime. Multiple virtual organizations are supported. The framework provides a Grid-FTP based utility that allows Instrument Managers to save their outputs to Grid storage elements or load data and settings from there. Middleware hides the complexity of the Grid protocols from the developer of the instrument interface. Users are authenticated on the Grid by their delegated proxies.

IE assures multiple user support through concurrency control and locking. Instruments can be explicitly locked by a single user for a certain time period, e.g. to perform a set of operations on the device. Locking and unlocking of the instrument managers is triggered by user-issued commands. Instruments are locked automatically by the framework during the execution of commands that change the state of the instrument or its parameters and attributes.

IE offers the possibility to use Java Message Service (JMS) for asynchronous monitoring of instrument variables. Framework checks an instrument variable and if its value has changed, it propagates the new value via JMS to all the subscribed users (e.g. the Virtual Control Room). The way instrument variables are checked depends on the caching policy defined by its Instrument Manager. Another important use of the JMS in the IE framework is for signaling alarms and events to the users. Alarms and events are raised by the Instrument Manager code and propagated as JMS messages to all the clients subscribed to the given topic. Thus far, IE has been tested with the Narada Brokering, OpenJMS and the IBM's proprietary implementation, Reliable Multicast Messaging (RMM) and it should work with any provider conforming to the JMS standard.

Information System provides for an up-to-date view of the resources available on the Grid. The BDII (Berkley Database Information Index), based on LDAP servers, has been adopted in the gLite middleware as the Information System technology. Instrument Elements are made discoverable by the Information System when registered in the BDII as Glue services.

Instrument Managers can be grouped inside the Instrument Element in logical units called contexts, and contexts can be further grouped in other contexts creating a tree-like structure that improves visibility and organization. This structure may be modified at runtime by the administrator.


IE installation

Requirements:

• Linux (RH Enterprise based distribution preferably, e.g. Scientific Linux.)
• Host certificates must be installed on the machine that will run IE. Yum/apt system should be set to retrieve lcg-CA and glite-UI packages from the LCG repository.
• Java JDK SE 5 or 6.
• Apache Ant 1.7.*
• Apache Tomcat 5.5.* or 6.*
• JAVA_HOME, ANT_HOME, CATALINA_HOME environment variables must be correctly set.
• JMS server running and client libraries available (e.g. Narada)
• Apache Axis (included with the IE.)

The Instrument Element package contains an INSTALL text file containing detailed step by step instructions on how to install and configure the IE. The IE package contains a few sample Instrument Managers that may be used for installation testing before the application developers implement and deploy their own, application-specific IMs.

How to use it

See the IE User Guide for detailed instructions. A brief summary follows:

Instrument Manager (IM) is the code that connects the Instrument Element to the instrument's control system or when possible, to the instrument itself. Instrument Managers are not standalone clients, once created they must be deployed to an Instrument Element installation and run inside it. Instrument Managers may be viewed simply as the Java client code for a specific instrument. Complexity of the Instrument Manager depends upon the instrument's interface. In the best possible case, there is already a Java client available for the given instrument so the Instrument Manager is simply a wrapper around it.

Instrument Manager Parts

• The XML descriptor: It fully describes the Instrument Manager's state machine and lists the transitions, commands, attributes and parameters together with their types, range, default values, etc.
• Instrument Manager implementing classes. These classes must extend those provided by the Instrument Element framework. Classes may be reused, e.g. single attribute implementing class may be used by a number of attributes of the same type.
• Note that the classes and the XML descriptor are closely linked together!
• There must always be a main class for each Instrument Manager that extends the abstract class eu.dorii.ie.InstrumentManager. That class is passed by reference to all attribute, parameter and command implementing classes.
• There may be a “shared object” class containing code used by others e.g. the bridge code to communicate with the instrument API.

Instrument Manager Template

The fastest and the simplest way to build an Instrument Manager it to use the provided IM-DevGuide and the Eclipse IDE. The template is intended as a guide and a starting point for development of the custom Instrument Managers. Both the template and especially the example code contain detailed comments for better understanding of the IM parts. We strongly recommend the use of it.

Source code

Subversion repository:
https://svn.gforge.hlrs.de/svn2/dorii-jra/middleware/IE2/trunk/

Latest release:
https://svn.gforge.hlrs.de/svn2/dorii-jra/middleware/IE2/tags/InstrumentElement-2.4.2/

Subversion repository for the IM-DevGuide (template):
https://svn.gforge.hlrs.de/svn2/dorii-jra/middleware/IM-DevGuide/trunk/

Both the middleware and the IM template may be downloaded from the Elettra site:
http://ulisse.elettra.trieste.it/uos/index.php?option=com_docman&task=cat_view&gid=18&order=date

Documentation and manuals

Instrument Element package contains a detailed Instrument Element User Guide:
https://svn.gforge.hlrs.de/svn2/dorii-jra/middleware/IE2/trunk/IEmanual.pdf

User Guide may be downloaded from the Elettra site too:
http://ulisse.elettra.trieste.it/uos/index.php?option=com_docman&task=cat_view&gid=39&order=date