330 likes | 503 Views
ICTP Workshop Trieste April 23-28 2007. Remote Instrument Adventures with Web Services in a Land Down-Under. Extensions to the Common Instrument Middleware Architecture (CIMA) Model for Web Services Based Collaborative Remote Instrument Control. - and Monitoring.
E N D
ICTP Workshop Trieste April 23-28 2007 Remote Instrument Adventures with Web Services in a Land Down-Under Extensions to the Common Instrument Middleware Architecture (CIMA) Model for Web Services Based Collaborative Remote Instrument Control - and Monitoring Ian Atkinson, Douglas du Boulay, Clinton Chee, Ken Chiu, Rick McMullen, Romain Quilici, Peter Turner, Mathew Wyatt. Part of a collaboration between Adelaide University, Indiana University, James Cook University, State University of New York (SUNY) at Binghamton, and the University of Sydney.
ICTP Workshop Trieste April 23-28 2007 • Summary of USyd CIMA extensions and portlet enhancements: • Extension of architecture to support instrument control • New plug-in types (e.g. instrument instruction module) • Enhancements to plug-in capability • New XML (SOAP) parcel types for instrument command and control; • - GET e.g. GET status information • - COMMMAND e.g. drive a goniometer axis motor • Hybrid push-pull model for managing data delivery inc option for • URL reference to data location and user selection of transfer protocol • Use of AJAX and Pushlets to improve Web browser functionality • X3D based virtual model for state representation and simulation
ICTP Workshop Trieste April 23-28 2007
ICTP Workshop Trieste April 23-28 2007
ICTP Workshop Trieste April 23-28 2007
ICTP Workshop Trieste April 23-28 2007
ICTP Workshop Trieste April 23-28 2007 SSRL-MMSN Remote Access Workshop February 9 2006 Melbourne University Learning Laboratory
ICTP Workshop Trieste April 23-28 2007 Remote Access via Remote Desktop Console Display eg NX NoMachine, VNC etc Server Computer for the Remote Instrument Users laptop Is this remote access via the Grid?
ICTP Workshop Trieste April 23-28 2007 A remote Unix Desktop is used for remotely accessing experimental and computational resources at SSRL. The user is able to run all command line and X-Window based applications available on the server at the remote macromolecular crystallography beam line. The server side runs on a SSRL computer and performs the bulk of the computation work. The client requires minimal CPU and memory resources on the client computer. Only 20 kbps of network bandwidth is required for excellent performance.
ICTP Workshop Trieste April 23-28 2007 • Remote Desktop Advantages: • Quick and easy to setup, using commercial software such as VNC enterprise, Citrix or NX NoMachine. • No requirement for development of additional software. Same desk-top based GUI used locally and remotely - no user learning curve. • Authentication and encryption provided with commercial/enterprise versions. Public domain version of VNC can be secured by SSH tunnel. • Support for different platforms, e.g. a Windows client can view a Linux server and vice-versa.
ICTP Workshop Trieste April 23-28 2007 • Remote Desktop Disadvantages: • (1) Limited functionality – restricted to the functionality provided by the remote desktop and facility policy. • (2) Instrument essentially an isolated resource - not integrated into the Web or Grid. • (3) Requires creation of user accounts on host server (password vulnerability, administration of user accounts). • (4) Difficult or impossible to limit desktop actions of user. • (5) Difficult to send data from the remote client to the host server. Inability to pass data or parameters to other applications outside the remote-desktop session • (6) Not a true service orientated architecture (SOA). Scalability issues; not suitable to support large numbers of (synchronous) users i.e. collaborative remote access
ICTP Workshop Trieste April 23-28 2007 Three software approaches to providing remote access: (a) Remote desk-top approach – user logs onto remote a facility server and the remote instrument computer console (desktop) display is tunnelled to users client machine. (b) Stand alone application with a purpose built interface providing connection to a remote instrument server. (c) Web browser driven portal based remote instrument/data services. All have strengths and weaknesses eg (a) easy but restricted to desktop functionality; (b) and (c) much harder to implement ( and possible replication of vendor code) but better security and flexibility, and can utilise Web services.
ICTP Workshop Trieste April 23-28 2007 • Web services(WS)provide a platform, language and location independent means of exchanging information between distributed resources. So can enable an instrument as a Web/Grid resource. • The specification of a Web service includes the nature of the application interface and the nature of message passed between the applications and resources. • WS typically exchange information or messages with Simple Object Access Protocol (SOAP).A SOAPmessage is an XML eXtensible Markup Language) parcel that typically runs over HTTP (HyperText Transfer Protocol). • The nature of the Web service (resource or application) and its interface is identified in an associated XML based Web Services Definition Language (WSDL: www.w3.org/TR/wsdl) message that enables interoperability. • Applications (legacy or otherwise) written in differing programming languages and running across heterogeneous platforms can use Web services to exchange data over the internet
ICTP Workshop Trieste April 23-28 2007 • Advantages of Web services: • Location, computer platform and computer language independent. Facilitates legacy code re-use. • Facilitates integration of the instrument into the Web (and Grid; can build a Grid using Web services) and its distributed resources. • Robust security model (WS-Security supports security tokens and certificates). • Use of HTTP as the underlying Web transport protocol facilitates firewall passage (through port 80). • Supports Service Orientated Architectures (SOAs). Can integrate remote services (stand-alone client applications, Web applications, command line tools, portal services, Grid resources and services) into project/user specific interfaces. • Facilitates the linkage of multiple users and resources for collaborative interactions across the Web.
ICTP Workshop Trieste April 23-28 2007 Web services can be used by stand-alone applications and interfaces – e.g. ANSTO’s GUMTree user interface could drive applications using Web services.
ICTP Workshop Trieste April 23-28 2007 • Web services are ideally suited to supporting and enabling Web portal based services, with the user interface then being provided byportlets embedded in a Web browser. The Web browser is pretty much everywhere! • So called Web 2.0technology is enabling the Web as an applications platform, and is changing the role of the ubiquitous Web browser. For instance; • AJAX(Asynchronous Javascript And XML) introduces a capability for a browser to function in a similar manner to a stand-alone GUI. In particular portlet specific dynamic ‘refresh’ of browser content, • Pushlets allow information/data to be continuously pushed to a browser – in effect over-turning the original browser get ‘paradigm’.
ICTP Workshop Trieste April 23-28 2007 We’ve been developing GridSphere (JSR 168 compliant portal-portlets) based portal tools using AJAX and Pushlets for Web services driven - Remote instrument control – facilitated by AJAX and Pushlets. Pushlets provide a mechanism for (pseudo-) real time responses Remote instrument monitoring – enhanced by AJAX and Pushlets Collaborative tool for data viewing, analysis and sharing – facilitated and enhanced by Pushlets and AJAX
ICTP Workshop Trieste April 23-28 2007 To provide the Web services infrastructure, we’ve adopted and extended the CIMA (Common Instrument Middleware Architecture). CIMA offers (at least in its vision and elegant design principles): A general and re-usable Web services framework for instrument access and management. Re-use through abstraction of instrument character and function. Flexible and extensible with modular use of plug-ins. Adaptable to different instrument settings. Publish-subscribe or registration model for services. Basis for a standardised implementation and deployment system, a standard programmable interface Grid enablement of instruments made accessible with Web service protocols.
Sensor Sensor Actuator Actuator Interface Interface Sensor Sensor Actuator Actuator ICTP Workshop Trieste April 23-28 2007 Instrument 1 Channel 1 Consumer A Channel 2 Channel 3 Consumers (clients) register for CIMA instrument services Channel 4 Instrument 2 Communication is via Web services channels Consumer B
ICTP Workshop Trieste April 23-28 2007 Web services communication over the CIMA channels uses SOAP encapsulating XML parcels: <Parcel> <Type>Sensor Double Data</Type> <Location>inline</Location> <Encoding>XML</Encoding> <Descriptor> <XMLParser>libxml</XMLParser> </Descriptor> <Body> <SensorName>...</SensorName> <TimeStamp>...</TimeStamp> <DoubleData>...</DoubleData> </Body> </Parcel> Tag Contents Type: Specifies the content type of the parcel body SensorName: Name of the sensor providing the data TimeStamp: Date and time in UTC as “YYYY-mm-dd HH:MM:SSZ” DoubleData: ASCII numerical value to be stored as a double
ICTP Workshop Trieste April 23-28 2007 New types of parcels for instrument control: • Void command: Set variables • Synchronous command: Get variables • Asynchronous command: Queued command • Examples of the new parcel types: • Get • Command (consistent with other instrument domains)
User application (1) Registration - credentials (2) Session token User app mainprogram Channel(Sink) (3) Request or command (6) Response with Data WS Interface (7) Pushed Data CIMA instrument service Service Component (4) … Web Services Interface Channel(Source) Plug-inModule #1 Plug-inModule #2, etc. (5) Sensor Data Actuatorcommand Register Parcel with credentials Session token returned to client Request Parcel from client: eg get, set, etc. Channel calls appropriate plug-in for request type and data source Plug-in retrieves data or runs actuator (motor) Response Parcel is returned to client (dataor result code) If Client registers for periodic event updates or streaming data, a Pushlet channel is established (time or event-driven from plug-in) Sensor Actuator
ICTP Workshop Trieste April 23-28 2007 Sensor Actuator Interface Sensor Actuator Instrument Instrument Representative Consumer Plug-in Modules Data Data Inst. Monitor Command Channels Command Inst. Command Response Response Actuator Register Web Services Container Web Services Container Sensor Actuator Portal & Portlets Plug-in modules Utility Sensor Channels Source Sink
ICTP Workshop Trieste April 23-28 2007 Java Reflection API to load plugins at runtime XML Based Plug-in Specification and Configuration:
Data Manager SRB Dynamic Content Pushed: Pushlets & AJAX Container A Collaborator Monitor Portlets Container Several simultaneous users. Only one administrator. Data cache Monitor Collaborator Control Web Services Container CIMA Component Operator 1) Requests: XML Parcels SOAP SOAP Pushed Data: XML Parcels 2) Responses: XML Parcels Web Services Container CIMA Component SOAP Pushed Data: XML Parcels Container B Instruments
Dynamic Content Pushed: Pushlets & AJAX Data Manager SRB Collaborator Container A Monitor Portlets Container Several simultaneous users. Only one Administrator Data cache Monitor Collaborator Control Web Services Container CIMA Component Operator 1) Requests: XML Parcels SOAP SOAP Pushed Data: XML Parcels 2) Responses: XML Parcels Web Services Container CIMA Component SOAP Pushed Data: XML Parcels Container B Instruments
ICTP Workshop Trieste April 23-28 2007 Acknowledgements: Sydney UniJCUIndiana and SUNY Douglas du BoulayIan M. Atkinson Rick McMullen Clinton CheeTristan King Ken Chiu Richard Leow Nigel G.D. Sim Romain QuiliciMathew Wyatt Australian Research Council:e-Research Seed Funding Programme and the Research Networks Programme (MMSN: Molecular and Materials Structure Network). Department of Education Science and Training:Dataset Acquisition, Accessibility, and Annotation e-Research Technologies (DART) project GrangeNet: The Integration of Scientific Instruments into the Grid
ICTP Workshop Trieste April 23-28 2007