Web Applications for Experimental Control at CLSDong Liu, Dylan Maxwell, and Elder Matias

Canadian Light SourceUniversity of Saskatchewan

Saskatoon, Canada

Abstract—The advantages of web applications have alreadygot attention in major physical research facilities like CanadianLight Source (CLS). It is the accessability of web applicationsthat makes them preferred to native desktop application insome experimental control scenarios. This short paper presentstwo web applications that were mainly developed at CLS —Science Studio for remote access and collaboration of instrumentsand computation resources, and Logit for beamline experimentinformation management. These two applications representstwo typical web applications. Science Studio is heavy-weightand provides a large spectrum of functionalities and has beendeveloped by distributed teams for years. Logit is light-weight,and provides very limited set of features and was delivered in avery short time. The architectural designs are discussed for bothsides, and the lessons learned from them are discussed.

I. INTRODUCTION

Web technologies might seem not suited for experimentalcontrol tasks in accelerator research facilities like CanadianLight Source (CLS) because the latency of web applicationscompared to native real-time control applications. On the otherside, web technologies do show strengths that cannot be foundin native real-time applications such as:

• An application can be developed once, and then be easilydeployed and updated on various operating systems forthe sake of the ubiquitousness of web browsers.

• HTTP enables an application to work across networkboundaries with firewall protection.

These advantages make web applications the top designoption for the following scenarios:

• remote monitoring and control of physical instrumentsacross network boundaries for a large number of userswith different roles,

• near-real-time sharing of fresh data and on-demand uti-lization of computation resources, and

• easy access of experimental information on differentplatforms including mobile devices.

The web application solutions for such scenarios havebeen made even simpler with continuous development of webtechnologies like server push, HTML/CSS and numerous highquality open-source JavaScript libraries. However, this doesnot mean that a web application can be definitely successfulin a research facility environment. We want to discuss andshare the lessons we have learned from two web applicationprojects within CLS.

II. SCIENCE STUDIO

Science Studio is a joint software project by Canadian LightSource (CLS), University of West Ontario (UWO) and IBM

funded by CANARIE under the NEP program [1], [2]. Theproject delivered web applications for secure and role-basedaccess to distributed experimental instruments and data. Aswell, Science Studio provides on-demand access to remotecomputing resources that are able to perform high performanceprocessing of large data sets transfered on high-speed network.Science Studio has been used by scientists at CLS, UWO,Advanced Light Source (ALS) and Brazilian SynchrotronLight Laboratory (LNLS) [3]. The first phase of the ScienceStudio project, Remote Beamline Access (RBA) started in2006 [4], and the third phase, Active Network Interchange forScientific Experimentation (ANISE) [5], was officially closedin early 2012.

Science Studio was first targeted to support remote accessof instruments on a couple of beamlines within CLS in the firstphase. Support was added for access to experimental data andon-line collaboration in the second phase, as well as supportfor more diverse instruments running on different platforms. Inthe third phase, it supported remote computational resourcesfor high performance processing of experimental data, andwas able to exchange experimental meta information acrossmultiple deployments across networks. Changing requirementshave been common for the project from the beginning, whichresulted in a continuously evolving architecture and implemen-tation. When Science Studio had just one application for a setof instruments, the change was not difficult. However, at theend of the project, any changes touching the core data modelsor libraries caused pains for the distributed developing teams.

The architecture of Science Studio is shown in Figure 1.The components on the bottom of the diagram including AD,NFS, Jetty service, DB, EPICS and ActiveMQ are within theprotection of an intranet. Science Studio is a typical Java-basedmultitire web application. Besides the frequent changes ofdata model, other significant changes during the developmentinclude:

• to replace direct AD/LDAP authentication with CAS(Centralized Authentication Service), and

• to provide RESTful interfaces to manipulate SS experi-ment meta-data across multiple SS deployments.

The first change was made to support SSO (single sign on)for the applications deployed on multiple SS deployments.The second change was made to decouple the dependency ofa common data model among multiple SS deployment. TheRESTful interface make it possible for a single SS deploy-ment to update its data model, and allow other unchanged

978-1-4673-4466-1/12/$31.00 ©2012 IEEE

ActiveMQ

AD DBmySQLNFS

CAS Tomcat

Spring MVC

SS controllerServletSpring

security

ORM iBATIS

JSP

Service Jetty

LDA

P

JDB

C

File

HTT

P

HTTPS

HTTPS

EPICS

JCA/CAJ

CA

File

SS model

SS model

JMS

UWO SS

Spring REST

HTTPS

HTT

PS

JSO

N

FirefoxCanvas

EXT JS

AJAX

HTTPS

Fig. 1. Science Studio architecture.

deployments to still exchange data with it.

III. LOGIT

Logit is an internal project delivered by the CLS CID groupfor the BioMedical Imaging and Therapy (BMIT) beamline.The major goal is to provide a web-based application thatcan capture diverse experimental information on the beamlineincluding instrument state and control parameters availableas EPICS PV’s, image acquisition information hidden inimage headers, and other information only available from thescientists and users on site by manual record. The applicationcan serve two scenarios: 1) to collect all the information foruser experiments for later reference and review, and 2) torecord the state of the machine and beamline related to faultsfor diagnosis.

The project was delivered with an effort of about 10developer-weeks. This time also includes initial testing andmodifying some features. The application was designed in aservice-oriented way such that the major functionalities aredeveloped as services. Because each service was independentfrom others, the developer was able to release a serviceand its web interface and let the scientists test it whiledeveloping other services. This also makes the later integrationof services quite straightforward. When the whole applicationwas released for testing, most issues had already been fixedduring the previous service testing cycles. The first release of

Logit supported the capture of more than 100 PV’s, parsing 5customized TIFF headers, and a form of more than 140 controlelements.

The architecture of Logit was shown in Figure 2. Logit wasa very light-weight web application with all services developedusing node.js1 and its modules. Naturally, all the objects andmessages are represented in JSON2. The developer originallywanted to use a no-SQL document-oriented database likeCouchDB or MongoDB. The choice of database was changedto MySQL because the beamline staff had more experiencewith the use of a traditional SQL database. The object-relationmapping (ORM) was done with the help of Sequelize3. Theimage metadata parser was based on imageMagick4. The loginservice was implemented by Passport5. The user interface wasdeveloped with jQuery6 and Bootstrap7.

IV. LESSONS FROM SCIENCE STUDIO AND LOGIT

Science Studio and Logit can represent two very differentweb applications in a scientific experimental facility settinglike CLS. Science Studio aimed to address almost every

1See http://nodejs.org/2See http://www.json.org/3See http://www.sequelizejs.com/4See http://www.imagemagick.org/5See http://passportjs.org/6See http://jquery.com/7See http://twitter.github.com/bootstrap/

browser Web server

DB

CLS AD PV snapshot service

Log record service

IOCchannel access

ldap

HTTP

image

html5/file

system boundary

Image meta info service

Login service

Fig. 2. Logit architecture.

aspects that a web application can do. It was designed to beheavy-weight. It had been developed for several years. Onthe other side, Logit was developed for just one beamline,though it can be very easily extended for other beamlines orfacilities. Its scope was small and the project spans only a shortperiod. It is difficult to tell which project or application is moresuccessful than the other. This paper aims to summarize thelessons that we learn from these two projects. These lessonsare common for web applications and cover both heavy-weightand light-weight varieties.

A. Browser compatibility

Browser support might be the most tricky aspect of webapplications. Even many mature commercial web applicationshave issues with browser compatibility. Science Studio re-moved the burden of browser compatibility by supporting onlyFirefox from the start of the project mainly because canvas wasnot supported by early versions of Internet Explorer (IE). Thatdecision has saved lots of effort for developers to tune the webpages and JavaScript. In fact, there were still requirements forScience Studio to support other popular browsers like IE andChrome.

When Logit was first developed, Firefox and Chrome are thebrowsers to be tested. However, the beamline staff indicatedthat IE should be supported because IE is the default browseron many Windows workstations on the beamline. Testing Logitagainst IE and making it IE-compatible used about 2 weeksof development time out of the total 10 weeks.

Browser compatibility will continue to be an issue for webapplications from now on with the development of HTML5,CSS3 and growth of mobile devices. A general rule to achievethe best browser compatibility is to use the most popular webfront-end frameworks and JavaScript libraries, and to avoidthe testing features such frameworks or libraries provide. Forexample, we found BootStrap was much better for browsercompatibility than jQuery UI components.

B. Version control

Source code version control is straightforward with so manymature tools’ support. The source version control tool used inScience Studio development was CVS at the beginning, andlater was changed to Git with repository hosting and issuetracking provided by SourceForge. The tool used in Logitwas Git. We also track production versions by MKS in CLSintranet.

The deployment version control is not that easy as sourceversion control. Deployment of right versions of compiledlibraries and third-party libraries on development, testing, andproduction servers took lots of efforts during the developmentof Science Studio. It got even more difficult when there weremultiple SS deployments in various organizations.

The deployment version control was made much easier inLogit. Because the JavaScript source does not need to be com-piled before run by node.js virtual machine, the deploymentversion control was made exactly the same as source versioncontrol. The developer can easily update and roll back theversions in development, testing and production environmentswith Git. Even the version control of third-party libraries couldbe done the same with Node Packaged Modules (NPM)8. Theversions of dependent node.js modules are explicitly specifiedin a JSON configuration file that is also version controlled byGit.

C. Development methodology

In both Science Studio and Logit projects, we had formallycollected and documented requirements. However, sometimethe requirements did not cover all the potential users whenthe application would be used by a large community likeScience Studio. Such missing requirements resulted in missingfeatures or features that were not useful for the user group.When the development team learned the negative feedbacks,it was too late because the project deadline approached. This

8See https://npmjs.org/

problem can be avoided by making the development processagile and fast. It very naturally suggests to adapt feature-driven or service-oriented design. Tools like MKS can helptrack emerging requirements and corresponding source andconfiguration changes. CLS is moving towards using MKSfor an integrated management of development process fromrequirements to test cases.

The other common pitfall of Science Studio and Logitis the emphasis of data model. Because both applicationshave a database back-end, the development started with acomprehensive data model from the elicited requirements. Wealways assumed that the data model was designed so wellthat it would hardly be changed during the development.Lots of effort therefore had been spent on the discussion andrefinement of those models. However, it turned out some partof the model was either never implemented in the applicationand most part of the model had been revised continuously. Theuse of advanced ORM tools can save developers’ effort in suchcases, but it cannot help them to avoid designing models thatare not suitable for either business requirements or integrationrequirements.

A thorough solution might be test-driven development.For web applications, that means the web user interfaces orprogramming interfaces should be developed and tested beforethe model was implemented and finalized. The developmentof test cases, either prototype web forms or cURL9 scripts,can potentially help the developer to better understand the usecases, which will eventually bring better data model that canstay unchanged longer.

9See http://curl.haxx.se/

V. CONCLUSION

We presented the design of two web applications — ScienceStudio and Logit — in this paper. Although web applicationsare currently not the major players in experimental physicsfacilities, we expect that more attention will be drawn tosuch applications with the development of more powerfulweb technologies and increased access to mobile devices. Thelessons that we learned from the projects are discussed, andthey will help us to avoid these pitfalls in future projects andto deliver better web applications for the scientific researchcommunity.

ACKNOWLEDGMENT

The research work described in this paper was performed atthe Canadian Light Source, which is supported by CANARIE,NSERC, NRC, CIHR, and the University of Saskatchewan.

REFERENCES

[1] D. Liu, E. D. Matias, D. Maxwell, D. Medrano, M. Bauer, M. Fuller,N. S. McIntyre, Y. Yan, C. H. Armstrong, and J. Haley, “Science studio:A project status update,” in Proceedings of ICALEPCS2009, Kobe, Japan,2009.

[2] D. G. Maxwell, D. Liu, E. Matias, D. Medrano, M. Bauer, M. Fuller,S. McIntryre, and J. Qin, “Remote access to the vespers beamline usingscience studio,” in Proceedings of PCaPAC 2010, Oct. 2010, pp. 118–120,http://accelconf.web.cern.ch/AccelConf/pcapac2010.

[3] N. Sherry, J. Qin, M. S. Fuller, Y. Xie, O. Mola, M. Bauer, N. S. McIntyre,D. Maxwell, D. Liu, E. Matias, and C. Armstrong, “Remote internetaccess to advanced analytical facilities: A new approach with web-basedservices,” Analytical Chemistry, 2012.

[4] C. Armstrong, “Cls remote beamline access software requirementsdocument,” Canadian Light Source, Tech. Rep., 2006,http://www.lightsource.ca/operations/pdf/7.4.1.1.Rev.0-CLS RemoteBeamline Access Software Requirements Document-Armstrong.pdf.

[5] ——, “Active network interchange for scientific experimentation,”CANARIE, Tech. Rep., 2009, http://sciencestudio.lightsource.ca/sswiki/upload/2009/5/NEP2 ANISE SOW v.final-11130713.doc.