Home

User Manual

1. For some labs the format is Alternative 2 username password starttime enadtime priority expID In the next release all labs will use the 2 format Parameters accessList List of accepted upcoming sessions Returns Returns OK or ERROR followed by an error description endSession Method that ends any active user session Returns OK or ERROR followed by an error description getCurrentUTC Method that returns current UTC as seen by the Provider Lab Server Returns the value represented as a String or ERROR Confidential 2003 06 21 Page 26 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 Method initiated by Cyberlab Description followed by an error description getExperimentid Gets the experiment ID the Lab ID from the Lab Server This ID is used internally by the Cyberlab communication sw Returns the experiment ID from the Lab represented as a String or ERROR followed by an error description getExperimentValue identifier Gets a boolean numerical or textual value as a String from the Lab The identifier is Provider specific Parameters identifier The identifier of the value to read e g variable name Returns the value represented as a String or ERROR followed by an error description setExperimentValue identifier
2. Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 3 The Cyberlab Communication Server CCS The Cyberlab Communication Server CCS is implemented as a stand alone Java application The CCS runs on the same PC as the Cyberlab Web Server and the DB Server The CCS communicates with the Cyberlab DB via a JDBC interface Today the CCS is running on a Linux based PC with Apache web server and mySQL DB BS Cyberlab Communication Server version 0 3 CYS EFL E se n Experiments connected V vindow Communication RMI and DB DummyLab1 23 Syberlab Communication Server version 0 3 Welcome RMI communication status RMI communication active Stop RMI communication ng up JDBC connection to the MySQL database on localhost successfully connected to the database mpting to start the RMI service Started the RMI communication Display information Database status getSupportedMethod Connected to database Udateacesstist Disconnect fom tates Getallversion EndSession Figure 9 Main window for Cyberlab Communication Server The Cyberlab Communication Server is running 24 7 and servers as the connection point for Lab Servers that connects to the Cyberlab Network Confidential 2003 06 21 Page 17 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0
3. stopConnection Stop CCS connection Confidential 2003 06 21 Page 63 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 12 Configuration files for the Provider 12 1 General The following configuration files must be set for the Lab Server to communicate with the Cyberlab Communication Server CLProvider ini CLProviderCallback ini policyForExperiment 12 2 CLProvider ini The CLProvider ini file holds the main settings for the TransportationAdapter The file should be located in the same directory as the directory where the Provider SW TransportationAdapter is started from A typical CLProvider ini file can look like this Transportation Adapter and Application Adapter properties Used for both Transportation Adapter application and Provider SW The last line must be empty Port definitions Used by both TA and AA TA_Port1 5678 TA_Port2 5688 Cyberlab server RMI connection used by TA 129 241 10 126 kybpc bb8 129 241 187 53 Cyberlab server linux CL_Server_RMI rmi localhost 1099 CyberlabRmiDispatcherInterface CL_Server_RMI rmi cyberlab org 1099 CyberlabRmiDispatcherInterface The syntax of the INI file is simple All lines starting with are comments All empty lines are ignored All other lines have a property name equals sign and the value of the property Note that the last line
4. strUserName nClientTyp nApisUserSessionID strUserName Genen Leg 2 strSessionInfo CyberlabInt ExperimentiIn REAG PEAS callback if cyberlab null amp amp login sessi callbac cyberlab loginResult callback getExperimentId on nApisUserSessionID Lat strRole mai K strSessionInfo ntTyp Uu cyberlab main getCyberlabCallObject n getExperimentCallObject DOLL A strUserName clientType else if cyberlab null do error repor callback null do error repor ting ale ting nClientType MEY TL identifier separating several Callback from Apis when a user session has ended param nApisUserSessionID Additiona D sessions for one user param nReason Reason for end of session Ka public void OnUserSessionEnded int nApisUserSessionID int nReason String logoutString OnUserSessionEnded nApisUserSessionID r E E DE Eieren t Wmkeasons Y ap ARSASON r UAVs String userName SsessionID tnApisUserSessionID CyberlabInterfac ExperimentInterfac callback if cyberlab null amp amp call cyberlab loginResult callback get else 1AE cyberlab null do error repor Caliiback snus do error repor ting LE ting cyberlab main getCyberlabCa
5. essssseeeesssesrerrrrnresssrrenne 25 Table 2 Cyberlabinterface Methods initiated by Lab Geer 28 Table 3 Experimentinterface summary of Methods eee eeeeeeee eee e rete eeeeeteeeeeeeee rete 31 Table 4 Legal values for the status field in getStatus 2 0 0 0 ieee ceeeeeee tere eeeeeetteeeeeeeeeeeeeee 32 Table 5 CyberlabInterface summary Of methodS cece eeeeeeeeee eee eeeeeeeneeeeeeeeeeeeees 45 Table 6 The socket package class files Overview srrrrrrrrrrrrrtrrrrrtttrrtttttrtrrrrrrnrrnna 56 Table 7 C version of the Java Experiment nterface cee eeeeeeeeeeeeeee eee eeeeenneeeeeeeeeeteeee 57 Table 8 C version of the Java Cvberlablntertace eee eeeeentieeeeeeeeeteees 57 Table 9 Program arguments for TransportationAdapter sssseeeeeeessseenerrnsrrssrrrrrrrnneesne 61 Table 10 Properties incCLProvideriinl cci csccedecaseeietidantectacheeeseadvccledeteee ees duetieceeaneeieas 64 Table 11 Properties in CL Provider allback mt 66 Figures Figure 1 Schematic view of the ESP business model 9 Figure 2 Cyberlab Portal with differentiated access levels c cceeeeeeeeeteeeetteeeeeeeees 11 Figure 3 A unified Lab poresentaton un 12 Figure 4 Provider Admin s online editing of Lab details cceeeceeeseeeeeeeeeeeeeeeeeneeeeeeees 12 Figure 5 Booking Opie EEN 13 Figure 6 The BOOKING PrOCeSS E 14 Figure 7 Running an Experiment on a Lab eebeebet Eens Seege 15 Figure 8 A simple techni
6. 4 The Middleware solution 4 1 Using a database as a component in the middleware solution If the Lab Server does not have a flexible Java interface this is probably the easiest and currently the most stable way to integrate a new Lab with the Cyberlab Network The solution is illustrated in the figure below Using this approach the Provider only has to implement some DB access methods and implement the business logic for responding to messages sent from Cyberlab and initiating requests to Cyberlab Cyberlab computer Cyberlab interface SW Provider computer Figure 10 Using a DB in the middleware solution Confidential 2003 06 21 Page 18 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 4 2 The standard Java RMI version The middleware solution based on Java RMI communication has been available for some time now and has proved both stable and robust This is the preferred solution if the Provider Lab Server is written in Java or if a flexible Java interface from the Lab Server already exists Provider Cyberlab Lab interface Server SW Provider computer Figure 11 Using the standard Java solution The main SW components using this solution is illustrated in the figure below assuming a Java based Lab Server Cyberlab Server Transportation Adapter Application Adapter Figure 12 A simplified diagram of the
7. COLE POLYTECHNIQUE the floor 7 aoe The Electrical Drive Optical Tracking System y control Optical tracking laboratoy Figure 2 Cyberlab Portal with differentiated access levels Confidential 2003 06 21 Page 11 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 The Inverted Pendulum Balance the inverted pendulum Dont let it hit the floor Experiments available on this laboratory apparatus Default experiment default Edit Delete Show Provider url Keywords e No keywords provided The inverted pendulum laboratory setup Bees More information from laboratory provider Desenpuon http iawww2 epfl ch Lab_IE html a H fi A a Remote experimentation of an inverted pendulum The lab can be run be Application and as an LabVIEW VI application Book lab time Login laboratory Laboratory status The lab is online Provider Contact person Denis Gillet show userinfo Du Institut d automatiqueSwiss Federal Institute of Technology in Lausanne EPFL Street address DGM EPFL Eclubens COLE POLYTECHNIQUE gt SC AER gege Zip Postal CH 1015 City Lausanne EPFL Country Switzerland Phone 4121 693 5168 Experiments available on this laboratory apparatus Figure 3 A unified Lab presentation General information Title Refrigeration process This lab offers several experiments in control eng
8. Legal values USER SYSTEM sessionId A session ID describing the user Returns A String describing the specific activity or ERROR followed by an error description checkUserAccess sessionld Method to check if a specific user has access to the lab NOW Parameters sessionId A session ID describing the user Format lt username gt lt password gt Returns A String describing the access rights or ERROR followed by an error description Confidential 2003 06 21 Page 29 of 70 Connecting Remotely Operable Labs to the Cyberlab Network Introduction Cyberlab Org UM 013 01 Revision 1 0 Method initiated by Lab Server getBookingData Description Method that gets the booking data Returns A String describing the booking data or ERROR followed by an error description Confidential 2003 06 21 Page 30 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 7 Experiment Interface Implementation details The Experiment Interface is part of the Cyberlab Communication Interface The Experiment Interface is defined via a Java Interface called Experimentinterface The Providers must provide an implementation of this Java interface These methods in the Experimentinterface are initiated by the Cyberlab Communication Server at the Cyberlab site and sent to the La
9. The Cyberlab system is based on a Business Model where the three different actors communicate with each other from separate computers via Internet as illustrated in Figure 1 below The three actors are e The Experiment Service Provider ESP This is represented by the organising company Cyberlab who provides all the necessary services and access to the laboratories in order to have the system in operation e The Providers This is the laboratory owners with their individual physical lab apparatus e The Customers This is individuals or organisations acting as customers an performing experimentation on the remotely operable laboratories Experiment Service Provider Independent operating company Ce d A N Customers Providers Network of providers of high quality physical experiments Traditional or open universities Continuing education institutions Industry Figure 1 Schematic view of the ESP business model Confidential 2003 06 21 Page 9 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 2 1 Main Cyberlab Network Services The main services offered via the Cyberlab Network can be summarised as e The Lab portal eCommerce and on line 24 7 services Web pages for Lab presentation promotion etc Quality assurance Lab availability regularity Booking invoicing reporting etc Access control usage supe
10. Who has the right to reset a laboratory and when Note It is strongly recommended that the Provider implements this method 7 2 3 4 Example code N A 7 2 4 connectionlsLost 7 2 4 1 The method public java lang String connectionlsLost java lang String reason Confidential 2003 06 21 Page 43 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 This method is optional and is called by the CCS Calling this method will send a signal to the Lab Server indicating that the communication with the Provider Lab Server is lost Parameters reason The reason for the lost connection Return value The Lab Server returns OK represented as a String or ERROR followed by an error description 7 2 4 2 CCS implementation details e This method is called by the CCS on request and based on some specified events e Only the Cyberlab Admin should be allowed to manually trigger this message 7 2 4 3 Lab Server implementation details e The business logic for the actions to be taken must be defined 7 2 4 4 Example code N A 7 3 Not used methods These methods are not described in any detail Confidential 2003 06 21 Page 44 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 8 Cyberlab Interface Implementation details The Cyberlab Interface is part of
11. a more complicated logic must be specified and implemented in order to deduct the actual status 7 1 1 4 Example code N A 7 1 2 getSupportedMethods 7 1 2 1 The method public java lang String getSupportedMethods This method is compulsory and is called by the Cyberlab Communication Server The Lab Server returns a list with the methods supported by the Lab Server The list should include the implementation status for all methods both for the CyberlabInterface and in the ExperimentlInterface and for both the compulsory and the optional methods Parameters no parameters Return value The Lab Server returns the supported methods in a String or ERROR followed by an error description The format of the supported methods String is lt interface_version gt lt method_ status 1 gt lt method status N gt where lt interface_version gt The Cyberlab Communication Interface version This is represented like this CCI version lt majorversion minorversion gt The current version is i e 0 5 The interface version is given by Cyberlab lt method_status i gt lt method gt lt version gt lt status gt lt method gt The name of the method getStatus getSupportedMethods etc Confidential 2003 06 21 Page 33 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 lt version gt Version number of implementation This is a version num
12. ecccceesseeeeeeeeeeeeeeeseneeeeeeeeeeeeeeeenneees 25 Le lee EE 25 6 2 General requirements sicvesigssdiclenakives ede ted sa shoves id ve teed EELER EENS ENER 25 6 3 Intertace El Le EE 25 6 3 1 Methods initiated by the Cyberlab Server sssssssessesssesesserrnrrrssererrrrnnnessee 25 6 3 2 Methods initiated by the Lab Server c cc ccceeeeeeeeeeteeeeeeeeeeeteeenneeeeeeeeeeteeee 28 7 Experiment Interface Implementation Cetails cccccccsseeesseeeeeeeeeeeeeeeeeeeeeeeeeeenneees 31 7 7 Compulsory Methods 2 i cte2e ease a shiva Hevea abies Heke elie Hake eee eke 32 7 1 1 geistat s ee Deeg 32 En SE AMC SIIOUIOO AAE EAEE le deletes E S E 32 7 1 1 2 eege e EE 33 7 1 1 3 Lab Server implementation details AE 33 TUNA Exampl E 33 7 1 2 GelSupporied Method ccs cceciveeehs eeceecetenweehs acer os taweuens heenons weve SEENEN 33 E E Sege EE 33 7 1 2 2 CCS implementation details 34 7 1 2 3 Lab Server implementation details AE 34 Fide E ere 34 7 1 3 GETV CISION EE 34 TMG THE met d E 34 7 1 3 2 CCS implementation details 35 7 1 3 3 Lab Server implementation details 2 ccceeeeeeeeeeeeeeceneneeeeeeeeetteeessnaeees 35 E Example code e E 35 7 1 4 WIPE AalGACCESSC ONO E 35 Confidential 2003 06 21 Page 2 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 en Ge The El E 35 7 1 4 2 CCS implementation details 36 7 1 4 3 Lab Server
13. initiated by CS Java RMI over the internet TransportationAdapter Details for TA is not Java shown here Local socket communication Communication initiated by Provider T Software SocketWrapper i avam by i Cyberlab C application C Method calls running on Providers l computer CyberlabCom L C Method calls T Provider Provider software a Figure 15 Overview of communication between the Provider and CCS using local sockets 10 1 2 Socket package class files The socket package consists of three classes on Windows and four classes on Linux The difference in numbers arise from how multithreading is handled Confidential 2003 06 21 Page 55 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 Table 6 The socket package class files overview Class files Description CyberlabCom cpp Main class in the socket package The provider makes an CyberlabCom h instance of this class All communication with CCS goes through this class via method calls SocketInterface cpp Cyberlab interface virtual class Defines all methods the SocketInterface h Provider must provide The same class that holds an instance of CyberlabCom in the Provider project must also implement this interface This interface allows CyberlabCom to call methods at the Provider SocketWrapper cpp Manages low level socket hand
14. 21 Page 15 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 2 6 Technical schematic A more detailed schematic of the overall architecture of the Cyberlab System is given in Figure 8 below As it can bee seen from this figure the communication between Cyberlab and the Provider is implemented using Java RMI Another alternative that is available today is a CORBA based solution Cyberlab x Se we Cyberlab Databases MySQL Web server Apache Database Interface JDBC Cyberlab Customer and Provider Communication Module Java Application Web pages booking etc HTTP HTTPS Customer Provider Communication Communication Interface Interface Status IP Socket Access Control and Status Java RMI Ee Provider s Cyberlab mrdanication Communication Interface Interface Cyberlab Provider Service Module Java Application Status Window Java Applet Lab Interface Java C C or other Provider specific software for Provider specific software Standard Web Control of lab Experiment Data for control of lab browser Browser Plugin LabVIEW APIS Java Applet or MatLab etc Standalone Application Provider Customer Figure 8 A simple technical schematic of the main SW components and interactions for a typical solution using Java RMI Confidential 2003 06 21 Page 16 of 70
15. 43 VAA D DEENEN 43 7 2 4 2 CCS implementation e E 44 7 2 4 3 Lab Server implementation details AAA 44 7244 ege EE 44 7 3 UINCHUSEGMOINOOS Lise Ee E EE tM EE 44 8 Cyberlab Interface Implementation Cetails cccccccesseeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeneees 45 8 1 Compulsory methods ate snc heen Sova ne Pte advent aad a a aN 45 8 1 1 ei 45 8 1 1 1 Rn E 45 8 1 1 2 eet 46 8 1 1 3 Lab Server implementation details 46 OTA ee 46 8 1 2 Keser EE 46 8 21 The method TE 46 8 1 2 2 CCS ee 47 8 1 2 3 Lab Server implementation details 47 GE EXAMPIC Cod Orre araeir eer a io R i a A R Ee ieat 47 Confidential 2003 06 21 Page 3 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 8 1 3 EE 48 Bota dy O ET E 48 8 1 3 2 CCS implementation details AAA 49 8 1 3 3 Lab Server implementation details AE 49 8 13 44 SEENEN eege ee 49 8 2 Tee Re EE 49 8 2 1 EE Ee EE EE 49 Bie Ved eme O e a a a e a a Ee A E SEE ETE 49 8 2 1 2 CCS implementation details AAA 50 8 2 1 3 Lab Server implementation details AAA 50 82 14 Eent G t E ENEE EEN 50 8 2 2 GISCONNGGE dE 50 8 2 2 1 Ree EE 50 8 2 2 2 CCS implementation details AAA 50 8 2 2 3 Lab Server implementation details AAA 50 B22 A ee 51 8 2 3 ee e a as E i deh dela na E a eel nq deena dak ee E dak E 51 E TE TIOU EE 51 8 2 3 2 CCS implementation details AAA 51 8 2 3 3 Lab Server implementation det
16. KEE EE EE RL 1 OO Onl Onl OK uk Seo ONE a writer newLine catch IOException e System out printlin write failed for FileName fi Close rile ecw A writer close catch IOException e System out printlin Can t close FileName 7 1 5 endSession 7 1 5 1 The method public java lang String endSession This method is compulsory and is called by the Cyberlab Communication Server The Lab Server should respond to this method by ending any active user session on the Lab Confidential 2003 06 21 Page 38 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 Parameters no parameters Return value The Lab Server returns OK in a String or ERROR followed by an error description 7 1 5 2 CCS implementation details e This method is only called by the Cyberlab Communication Server on request or based on a given event The method could be triggered as a response from a User that is not able to log into the Lab due to an existing session conflicting with a booked and accepted session 7 1 5 3 Lab Server implementation details Some implementation details for the business logic on the Provider Lab Server e The action of this method must be clarified for a couple of special cases Should it be possible to end a session if a alocal user is performing local operation of the Lab during a ti
17. OF CONTENTS Summary 7 1 Definitions 8 Eartt Zueketg GOM EMMER NEESS 9 2 General system overview of the Cyberlab System ccccsssessseeeeeeeeeeeeeeeeeeeeeeeeeeeeeneeees 9 2 1 Main Cyberlab Network Services 00 ceeeeeceeneee eter eee eeeeeeeeeeeeeeeeeeeeceaaeeeeeeeeeeteneeaaees 10 2 2 The Cyberlab POlals tac atest Sc neckties Oia nen aiten aut eereae sickens 11 225 BOOKING OP ONS sasra eane a ee a acess does aaea a ae E aaa aa EN E EAEAN E 13 274 the BOOKING proc SS inori e eae i dara E aa n e anenai 14 2 5 Running an experiment ssaciccceds yetenaoteseaehd Haedeyboreiaveheckediyonsiieveds tees ey bacicerdd seneeaeneanoe te 15 2 6 Technical SCNOMmatic ciicccsicce tas el enge ee 16 The Cyberlab Communication Server CCS 17 4 The Middleware SOIUtION ccccccsssseeeeeeeeeeeeeeeeeeeneeeeeeeeeeeseeeeeeeeeeeeeeeeeseneeeeneeeeeeeeenenees 18 4 1 Using a database as a component in the middleware solution 18 4 2 The standard Java RMI version 19 4 2 1 Calls initiated by the Lab Server ee 20 4 2 2 Calls initiated by the Cyberlab Communication Server ceeeeeeeeeeees 20 4 3 The ane Ee EE 21 5 Connecting a Lab to the Cyberlab Network eeeeceeeesseeeeeeeeeeeeeeeeeaeeeeeeeeeeeeeeeeaneees 23 Eat ele EE 23 5 2 General E tg 23 5 3 SW provided by Cyberla Dire EE 23 5 4 Other SW BEE 23 5 5 Connecting to Cyberlab Communication Germer 24 6 The Cyberlab Provider Interface Methods
18. called This method will try to re establish the connection a startTransportationAdapterDispatcher is called it starts transportationAdapter b startApplicationAdapter is called it starts applicationAdapter c If reConnect could not make a connection to CyberlabServer then it waits a specified minutes before trying again End recovery sequence Confidential 2003 06 21 Page 54 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 10 The C version of the Interface 10 1 1 Introduction A standalone Java application the Transportation Adapter is run on the Providers computer This application sets up the communication over the internet to CCS via Java RMI Providers connect to this Java application by either Java JNI or as will be described here by local sockets Socket communication is intended for providers using C projects The package presented here is C code working on both Windows and Linux There is no need for two packages By including the class files of this package in the Provider s project the socket communication to the Java application is handled The Provider implements an interface and instantiates an object of a specific class All communication to from the CCS is then done by method calls from the Provider s point of view Provider local socket communication tails f i Cyberlab Server e Geier ge Communication
19. directory the location of the ini files must be specified by the cyberlab inifile dir property The property can be set in the bat file starting the ProviderMain as follows java Dcyberlab inifile dir lt path_to_the_inifile gt classpath TransportationAdapter jar DummyProvider jar crypt jar com cyberlab dummyProvider ProviderMain Confidential 2003 06 21 Page 59 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 When the TA is started by the dummyProvider or whatever it is called the TA will get the cyberlab inifile dir property if it is set Unix Linux DummyProvider can be run by writing a command file sh or similar or by writing the following on the command line java classpath TransportationAdapter jar DummyProvider jar crypt jar com cyberlab dummyProvider ProviderMain Please note the separators used for Unix Linux and the separators for Windows If the ini files are not located in current directory the location of the ini files can be specified by the cyberlab inifile dir property as indicated in the example above for the Windows version The above assumes that Sun s JDK 1 3 or JRE 1 3 is installed and properly configured 11 6 The TransportationAdapter A Lab Server that shall communicate with the CCS must use a Java application made by Cyberlab TransportationAdapter TA to enab
20. log into the Lab directly via the Provider s web site The Provider will use Booking data received from Cyberlab during the Booking process in order to decide if the User should be granted access or not Some options and alternative solutions do however exist e The User will interact with the Lab using a Provider specific solution for the GUI of the lab This can be a downloaded application a pure web based solution or a mix This lab GUI solution is normally developed and maintained by the Provider e The main part of the communication will take place directly between the User and the Lab Server ref the meas control audio video label in the figure below e During an Experiment run some administrative data can be retrieved by Cyberlab from the Lab Server ref the Status amp control label Several options and alternatives can be configured for this logging of data e During a Lab session an optional status window Cyberlab Status Window can be used and configured by the Provider This applet will provide the User with some additional lab and booking information sent directly to the User from Cyberlab as illustrated with the Lab status label Ceci d Cyberlab Status Window http a SCH Lab S Provider dependent lab interaction meas Control audio video Java RMI Corba Status amp control Lab Client GUI Figure 7 Running an Experiment on a Lab Confidential 2003 06
21. must be blank or else the last property will not be read properly The properties available for use in CLProvider ini are shown in the table below Table 10 Properties in CLProvider ini Property name Description Example value TA Port The first port to listen for 5678 AA connection Used for communication between TA and AA TA_Port2 The second port to listen for 5688 AA connection Used for communication between TA and AA CL_Server_RMI Address to Cyberlab Server RMI rmi cyberlab org 1099 service CyberlabRmiDispatcherInterface rmi localhost 1099 CyberlabRmiDispat cherlnterface Confidential 2003 06 21 Page 64 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 If some of the properties are missing or the whole INI file is missing hard coded in the Java code default values will be used for the missing values 12 3 CLProviderCallback ini The CLProviderCallback ini file holds the main settings for the Provider Lab Server callback properties The file should be located in the same directory as the directory that the Provider Lab Server is started from A typical CLProviderCallback ini file can look like this Cyberlab Provider Lab Server Callback properties Comments start with The last line must be empty Th xperiment ID of this experiment It is sent
22. no parameters Return value The Cyberlab Communication Server returns a String with the current and most up to date version available of all the Cyberlab components in the system or ERROR followed by an error description The format of the version String is lt component_1 gt lt component_N gt where lt component_i gt lt component_id gt lt version gt lt component_id gt The short name of the SW component CCI Cyberlab Communication Interface CyberlabInterface and Confidential 2003 06 21 Page 49 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 Experimentlnterface CCS _ Cyberlab Communication Server TA Transportation Adapter AA Application Adapter lt version gt Version number of the SW component This is a version number defined by Cyberlab The version mumber follows the format lt majorversion gt lt minorversion gt 8 2 1 2 CCS implementation details N A 8 2 1 3 Lab Server implementation details e The name will probably be changed to getCyberlabVersion in the next release 8 2 1 4 Example code N A 8 2 2 disconnect 8 2 2 1 The method public java lang String disconnect java lang String offlineStatusDescription This method is optional and is called by the Lab Server The method that notifies the Cyberlab server that this experiment is about to disconnect and close the connection with the Cyberlab S
23. standard middleware solution and its components TCP IP socket Q S S z 5 T S Si e d Confidential 2003 06 21 Page 19 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 The two Java interfaces that the Provider must implement in his code are marked in the figure above as Experimentinterface and Cyberlabinterface In the following sections a simplified description is given on how the information flows when method calls are made from the Lab Server ProviderMain to the Cyberlab Communication Server called CyberlabServer in the figure above and vice versa 4 2 1 Calls initiated by the Lab Server Calls from ProviderMain to CyberlabServer A simplified description of the calls from ProviderMain to the CyberlabServer is given below ProviderMain 1 ProviderMain sends a call to ApplicationAdapter 2 ApplicationAdapter sends the call over TCP IP SocketCommunication to the TransportationAdapter TransportationAdapter 3 TransportationAdapter sends the call over Java RMI to the CyberlabServer CyberlabServer 4 CyberlabServer performs the necessary action based on the call updating the DB etc 5 CyberlabServer returns a return value over Java RMI to the TransportationAdapter TransportationAdapter 6 TransportatioAdapter returns the return value over the TCP IP Socket communication further to the ProviderMain s A
24. the Cyberlab Communication Interface The Cyberlab Interface is defined via a Java Interface called CyberlabInterface The Providers must provide an implementation of this Java interface These methods in the CyberlabInterface are initiated by the Lab Server and sent to the Cyberlab Communication Server CCS A summary of the methods is given in the table below Some implementation details and guidelines are given in the following sections Table 5 Cyberlabinterface summary of methods Method initiated by Lab Server connect loginResult labName session D result isAlive getVer Next release getCyberlabVersion disconnect offlineStatusDescription Strongly reccomended to implement this log type sessionld action Strongly reccomended to implement this checkUserAccess sessionld getBookingData Please refer to the example Java code ProviderMain java for examples of calling the CyberlabInterface methods from the Provider SW Important files for the Provider e The Cyberlabinterface filesForProvider com cyberlab Cyberlabinterface java e Example of a Provider implementation when calling the methods defined in the CyberlabInterface filesForProviders code com cyberlab dummyProvider ProviderMain java 8 1 Compulsory methods 8 1 1 connect 8 1 1 1 The method public java lang String connect Confidential 2003 06 21 Page 45 of 70 Connecting Rem
25. the CyberlabCom class and the SocketInterface interface The CyberlabCom class has all compulsory methods presented in the CyberlabInterface in previous sections Table 7 C version of the Java Experimentinterface Methods initiated by the CCS Socketinterface Virtual Class public virtual char getStatus public virtual char getSupportedMethods public virtual char getVersion char identifier public virtual char updateAccessControlList char accessList public virtual char endSession public virtual char getExperimentid public virtual char getExperimentValue char identifier public virtual char setExperimentValue char identifier char value public virtual char resetExperiment public virtual char connectionlsLost Note The compulsory method getCurrentUTC is currently not implemented Table 8 C version of the Java Cyberlabinterface Methods initiated by the Lab Server CyberlabCom Class public std string connect public std string loginResult std string laobName std string sessionlD std string result public std string isAlive public std string getCyberlabVersion public std string disconnect std string offlineStatusDescription public std string log std string type std string sessionID std string action Note The optional method checkUSerAccess is currently not implemented Confidential 2003 06 2
26. the received bookings mySQL has been used with success for this purpose by several Providers The Cyberlab Crypt package can be used for the encryption decryption of the passwords The type of encryption to be used must be agreed with Cyberlab 7 1 4 4 Example code Here is a very simple example of a Provider implementation of the updateAccessCotrolList method Method is the implementation of the updateAccessControlList of the Experiment Interface The method is the Lab Server respons when the method is called from the Cyberlab Communication Server This is the LabXYZ specific implementation of how to handle the session file Inte ACCESS CGomecel lige as Se eecl iim a Jeer VDI ain a te ee tere cl_session The filename is specified by the Filename entry in the configuration file CLProviderCallback ini The session file is located in a protected area The path needed by the Lab Server to the session file is specified by the registry key My computer HKEY_LOCAL_MACHINE SOFTWARE ServerXYZ SessionPath The Lab Server will use this information when using the OPC Security mechanism when clients are connecting to the lab via the remote application The Lab Server is using the following format for the session file username password starttime endtime aere Sloe username password starttime endtime Ge ee ape eye Mea ae eae Sra ed
27. without the need of any new software Dispatcher II RMI IIOP This is one of the dispatcher object in the extended version and it can be contacted over the IIOP protocol The object can be seen on as a RMI IIOP server that can communicate with both RMI IIOP and IDL Internet Definition Language clients RMI IIOP clients enable the same Java package as the server which means they must also be written in Java The IDL clients are language independent and can be written in any programming language that implements the Common Object Request Broker Architecture CORBA However there still exist some compatibility problems between some of the existing CORBA implementations and the RMI IOP technology CORBA Wrapper Server and Dispatcher III CORBA These two components are used to avoid the compatibility problems that can occur between some CORBA implementations and the RMI IIOP dispatcher object The CORBA Wrapper Server act as a RMI IIOP client towards the RMI IIOP dispatcher object and at the same time it acts as a CORBA server implemented in Java There are no compatibility problems between a RMI IIOP and IDL communication when both client and server are written in the Java API The communication between the dispatcher object in CORBA Java IDL and other CORBA implementations are handled without problems Transportation Adapter RMI and Application Adapter These blocks are intermediate communication adapters used to enable provider software im
28. 00 05 00 06 00 07 00 08 00 09 00 lt lt September gt gt 2001 SMT EE 4 2 Ke 16 00 17 00 18 00 19 00 20 00 21 00 22 00 23 00 Available time slot Occupied time slot Note Remember to store all s 10 00 RW fo i a E EEEn nE EEEE 11 00 First name Tor Ivar Street Kringsjaveien 334 Lastname Eikaas Zip N 7032 z City Trondheim Country Norway EES Lab Head box Time slot 60min Experiment Default experiment LabUser torivar Summary of selected bookings Customer Date Time torivar 2001 09 17 16 00 Start date Start time Type 00 torivar 2001 09 17 10 00 4 2001 Sep 17 16 control 2001 Sep 17 10 00 control Accept bookings and continue o Order confirmed The following bookings have been confirmed Figure 5 Booking options Confidential 2003 06 21 Page 13 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 2 4 The Booking process The figure below illustrates the main information flow during the Booking process i e when the user is making a reservation for running a lab available in the Cyberlab Network Some main characteristics of the information flow at this stage are At this stage all information regarding a lab is retrieved from the Cyberlab DB e All requests from the User are done via the Cyberlab Portal No communication is done directly between th
29. 1 Page 28 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 Method initiated by Lab Server Description getVer Gets the current and most up to date version numbers of the main components in the Cyberlab Next release system getCyberlabVersion This method is not a necessary function for the Cyberlab system but is used mainly for maintenance and debugging Returns The version numbers of the components in the system or ERROR followed by error description The main components CCI Cyberlab Communication Interface CyberlabInterface and Experimentinterface CCS Cyberlab Communication Server TA Transportation Adapter AA Application Adapter disconnect offlineStatusDescription Method that notifies the CCS that this experiment is about to disconnect and close the connection with the Cyberlab Server optional The Laboratory status will be set to OFFLINE One must specify the reason for the OFFLINE status Parameters offlineStatusDescription A String describing the OFFLFINE status Typical values are Maintenance SW upgrade etc Returns OK to signal that the message was received the last answer from Cyberlab or ERROR followed by an error description log type sessionld action Method that logs some specific activity on the Lab Server The activity can be initiated both by the user and by the system Parameters type Log type
30. 1 Page 57 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 11 A simple Java Lab Server 11 1 General The application DummyProvider has been implemented as a small stand alone example program to illustrate a simple Lab Server The dummyProvider use the ApplicationAdapter AA and belonging interfaces to communicate with the Cyberlab Communication Server CCS for testing purposes The most important issues of DummyProvider are e DummyProvider itself consist of only two classes ProviderMain and CallbackClass e ProviderMain creates a new object from CallbackClass and uses that object when creating a new AA Later the AA is used to send messages to the CCS e CallbackClass is the class that handles all messages from the CCS The package com cyberlab dummyProvider source code available for the Providers contains the two test classes for the CCS communication and is only provided for helping the Provider getting started It includes only a simple example of a Lab Server but a generic Lab Server written in Java or with a Java interface could easily use the same methods and principals to connect to the CCS 11 2 Summary of files Files to run DummyProvider e DummyProvider jar e CLProvider ini usually not needed for an Lab Server except for the TA e startDummyProvider bat Files to rebuild DummyProvider com cyberlab java com cyberlab applicationAdap
31. 9 2001 Cyberlab Org AS Figure 17 Cyberlab Information applet after a successful login and after a non successful one In Figure 17 the applet to the left shows the typical information after a successful login to the Lab The applet shows the remaining time of the booked timeslot s together with important status information from the lab This status information can be useful for the Lab User if the connection between the Lab User client application and the lab breaks down or if there are unforeseen problems with the Lab User client application The applet to the right shows the typical information after a non successful login attempt The applet will then show a list with the next few booked and registered timeslots for this user at this specific lab The applet will then be useful for the Lab User in order to know how to proceed Confidential 2003 06 21 Page 69 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 further One typical reason for a non successful login could be problems with the local timezone offset to UTC CY3cILdz Status info Tech support Questionaire Functionality of Cyberlab booking system Q01 203 04 O05 K6 Functionality of Remote Laboratory Q01 02 03 H4 05 6 Comments Suggested improvements twas a bit hard getting started The lab description should contain more examples CH Copy
32. Basic are also available It is assumed that the reader is comfortable with the Java programming language 5 2 General requirements e The existing or to be created Lab Server must be able to use Java This does not necessarily mean that the whole Lab Server must be implemented in Java but it must be able to communicate with a Java Application that can be an integrated part of the Lab Server e Other interfaces like C and VB are available on request Please contact Cyberlab for further details e Cyberlab must be notified about general information about the experiment name IP address description etc for use with the Cyberlab database and for use on authenticating an Lab Server s connection to the Cyberlab Communication Server 5 3 SW provided by Cyberlab The files needed for a Provider are ApplicationAdapter jar TransportationAdapter jar Crypt jar DummyProvider jar Source code for the interfaces CLProvider ini CLProviderCallback ini startTransportationAdapter bat manifestForDummyProvider policyForExperiment Relevant JavaDoc Provider example code Source code for dummyProvider DummyProvider jar startDummyProvider bat Relevant JavaDoc for dummyProvider All these files are available for the Providers from Cyberlab 5 4 Other SW needed It is required that the following software is installed e Java Development Kit preferably version 1 4 but earlie
33. CWSe7Ld3 Document Name Document Date Document Author s Document approved by Document type Deliverable Number Report number Version Status Classification Document Reference Number File User Manual Connecting Remotely Operable Labs to the Cyberlab Network Introduction 2003 06 21 Tor Ivar Eikaas User manual UM 013 1 0 Final Confidential UM 013 01 UM 013 ConnectingLabs Intro v1_0 doc The information contained in this report is subject to change without notice and should not be construed as a commitment by Cyberlab In the event of any software or algorithms being described in this report Cyberlab assumes no responsibility for the use or inability to use any of its software or algorithms The information is provided without any warranty of any kind and Cyberlab expressly disclaims all implied warranties including but not limited to the implied warranties of merchantability and fitness for a particular use COPYRIGHT 2000 2003 Cyberlab Org AS This document may not be copied reproduced or modified in whole or in part for any purpose without written permission from Cyberlab In addition to such written permission to copy acknowledgement of the authors of the document and all applicable portions of the copyright notice must be clearly referenced All rights reserved Connecting Remotely Operable Labs to the Cyberlab Network Introduction Cyberlab Org UM 013 01 Revision 1 0 TABLE
34. ERROR followed by an error description 6 3 2 Methods initiated by the Lab Server interface CyberlabInterface This Interface describes all possible calls from the Lab Server to the Cyberlab Communication Server CCS The methods are initiated by the Lab Server and sent to the CCS Table 2 Cyberlabinterface Methods initiated by Lab Server Method initiated by Lab Server Description connect Establish the connection with the CCS If successful the Laboratory status is set as ONLINE The Provider does not need to do any implementation work for this method Returns OK to signal that the message was received or ERROR followed by an error description loginResult labName session D result Method that returns the result from attempted login and the actual login time Parameters LabName The Cyberlab identifier for this lab sessionId A session ID describing the user result result from attempted login Returns A String describing the result from attempted login and actual login time or ERROR followed by an error description This method is also used when users log out of the system isAlive Cyberlab System method that checks the Cyberlab connection The Provider does not need to do any implementation work for this method Returns OK to signal that the message was received or ERROR followed by an error description Confidential 2003 06 2
35. Server and the Provider s Lab Server A special focus is on the methods SW and interfaces for the communication between the Cyberlab Communication Server and the Lab Server This document is not meant to be a complete reference and description of the SW used for the Cyberlab Portal and Cyberlab Communication Server but it is rather an overview giving the main functionality Further details and example code is available from Cyberlab Confidential 2003 06 21 Page 7 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org 1 Definitions Revision 1 0 AA CCI CCS Customer Cyberlab Admin Cyberlab DB Application Adapter Cyberlab Communication Interface See Cyberlab Communication Server A Cyberlab User registered and accepted by Cyberlab as a Customer A specific Cyberlab User from Cyberlab Org given Cyberlab Admin rights The Cyberlab database Located on a Cyberlab computer May be split in several physical databases Cyberlab Communication Server CCS ESP Experiment Experiment Server Guest GUI Lab Laboratory Lab User Lab Unit Lab Server Provider Provider Admin TA User Cyberlab User The SW running at the Cyberlab s site providing the necessary functionality for interfacing the Lab Server via the Cyberlab Provider Communication and the Cyberlab DB Previously called Cyberlab Server Experiment Service Provider Th
36. The Provider must only use the identifier provided by Cyberlab for the specific Laboratory as part of the agreement between Cyberlab and the Provider e The identifier is currently the defined in a string in the file CLProviderCallback ini that must be located in the same directory as where the Provider Server is started from Experiment_Id lt unique identifier gt e The variable name used for the identification will probably change in the next version of the Provider Interface SW A special note regarding the Java interface e It should normally be sufficient for the Provider just to return the EXPERIMENT_ID in the implementation of getExperimentld in CallbackClass java 7 1 7 4 Example code N A 7 2 Optional methods 7 2 1 getExperimentValue 7 2 1 1 The method public java lang String getExperimentValue java lang String identifier This method is optional and is called by the CCS The Lab Server returns the value for a specified identifier variable name The returned value can be a boolean numerical or textual value as a String from the Lab Parameters identifier The identifier of the value to read e g variable name tag Return value The Lab Server returns the value represented as a String or ERROR followed by an error description The format of the return String should follow the following syntax Confidential 2003 06 21 Page 41 of 70 Connecting Remotely Operable Labs to the Cyberlab Netw
37. able SW components Return value The Lab Server returns the version of all or the specified component in a String or ERROR followed by an error description The format of the version String is Components lt component_1 gt lt component_N gt Confidential 2003 06 21 Page 34 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 where lt component_i gt lt component_id gt lt version gt lt component_id gt The short name of the SW component TA AA ES All lt version gt Version number of the SW component This is a version number defined by Cyberlab for TA and AA and defined by the Provider for ES LS The version mumber follows the format lt majorversion gt lt minorversion gt 7 1 3 2 CCS implementation details e This method is normally called by the CCS on request only and not with a fixed frequency and is normally only used for debugging and statistical purposes 7 1 3 3 Lab Server implementation details e There should be no wm embedded in the text string e The version numbers are the ones defined by Cyberlab for TA and AA Both ES and LS is accepted as a short notation for the Lab Server e The version number for LS ES is defined by the Provider e Other return values may be specified by Cyberlab for Labs using other interfaces than the ones for Java Below is an example on how the returned String could
38. ails AAA 51 8 23 44 Example EE 51 8 2 4 lee 51 B24 THC Ee EE 51 8 2 4 2 CCS implementation details AAA 52 8 2 4 3 Lab Server implementation details 52 8 2 4 4 e 52 8 3 NODUSEG E e EE 52 9 The Java version Of the interface cccccccessseeeeeeeeeeeeeeeeeeeeeeneeeeeeeeeeseseeeeeeeeeeeeeeseeees 53 9 1 Example architecture using Java RMI ssssssssssssssrrrnesssssrrrrrnnrrssernnrrnnnsssrrrnnrrnnnesent 53 9 2 Error recovery at the Provider aide AAA 53 10 The C version of the Interface ccccssceseeeeeeeeeeeeseeeeeeeeeeeeeeeeeneeeeeneeeeeeeeesaseeneneeeeenees 55 10 114 WG OUCHON seers es iat atte thot ee ee ee eene eege Ee dee 55 10 1 2 Socket package class les 55 10 1 3 Detailed description dev eseteesk accede anceies daceels actescigecweieiaeeeiedaddeluakeieeacueass 56 10 1 4 C interface e 57 11 A simple Java Lab Server ic cisi ccssscsscecceccccessesnecectecesesarasnaescteceteseratnnnastececesesasaseantoceceteees 58 11 1 General 58 112 elen el 58 11 3 Generating DUMMYProvider jal cece ENEE 58 11 4Configure enee eege dee e ees 59 11 5 Running DummyProvider osiccscisiawrtsinceeracts teuckphorucends EENS EENS ENGEN 59 11 6 The TransportationAdapter E 60 11 6 1 Running the TransportationAdapter ssssseeeeeeeseeennrrrnersserrrnrrrnrrsserrrrrn n 60 11 7 Classes and Interfaces provided by Cyberlab s nssssssesesnrrnneesseeernrrnnnrssrrrerrnnersee 61 11 7 1 Interface com cyberlab Experimenti
39. ava Application that can be assembled as an integrated part of the Lab Server e The integration between the Lab Server and the Cyberlab System can be made even less tight using a SQL DB as a middle layer between the Lab Server and a communication module provided by Cyberlab e Cyberlab must be notified about general information about the lab name IP address description etc for use with the Cyberlab database and for use when authenticating a Lab Server s connection to the Cyberlab Server 6 3 Interface methods The following two sections describes the methods defined for the Cyberlab Communication Interface between the Cyberlab Communication Server and the Lab Servers The methods are categorized according the following criteria e compulsory All experiment servers have to implement these methods e optional These may or may not be implemented by the Provider in the experiment server e not used May have been used in a previous version Not expected that it is needed anymore Still kept in the interface in order to avoid unnecessary changes by the Provider 6 3 1 Methods initiated by the Cyberlab Server interface Experimentinterface This Interface describes all possible calls from the Cyberlab Communication Server CCS to the Lab Server The methods are initiated by the CCS and sent to the Lab Server Table 1 Experimentinterface Methods initiated by Cyberlab Method initiated by Cyberlab Description getStatus Get
40. b Server Experiment Server at the Provider site A summary of the methods is given in the table below Some implementation details and guidelines are also given in the following sections Table 3 Experimentinterface summary of methods Method initiated by Cyberlab getStatus getSupportedMethods getVersion identifier updateAccessControlList accessList endSession getCurrentUTC getExperimentld getExperimentValue identifier setExperimentValue identifier value resetExperiment Strongly reccomended to implement this connectionlsLost throwOutUser sessionld throwOutAllUsers Note 1 The Cyberlab Communication Server must support both the Compulsory and the Optional methods Note 2 The enclosed example file CallbackClass java implementing the Experimentinterface for a simple Provider Lab Server dummyProvider does not fully implement the specification of the return values described in the following sections Important files for the Provider e The Experimentinterface filesForProvider com cyberlab Experimentinterface java e Example of a Provider implementation of the Experimentinterface filesForProviders code com cyberlab dummyProvider CallbackClass java Confidential 2003 06 21 Page 31 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 7 1 Compulsor
41. ber provided by the Provider It is recommended to use the format lt majorversion gt lt minorversion gt lt status gt This Implementation status of the individual method This is a Provider defined text indicating the actual status of the implementation Typical values are full Full implementation draft A test version dummy Only a sceleton no Not implemented 7 1 2 2 CCS implementation details e This method is normally called by the CCS on request only and not with a fixed frequency and is normally only used for debugging and statistical purposes 7 1 2 3 Lab Server implementation details e There should be no wm embedded in the text string e Below is an example on how the list of supported methods included in a String could be returned from the Lab Server Only a part of the list is included CCI version 0 3 getStatus 1 0 full getSupportedMethod 0 9 draft getVersion 0 1 dummy lt stuff deleted gt log 1 0 full 7 1 2 4 Example code N A 7 1 3 getVersion 7 1 3 1 The method public java lang String getVersion java lang String identifier This method is compulsory and is called by the Cyberlab Communication Server The Lab Server returns a list with the version number of all or a specified component of the system Parameters identifier The identifier for the specified SW components TA Transportation Adapter AA Application Adapter LS ES Lab Server Experiment Server All All avail
42. berlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 Started TA manually is only recommended in special cases and is only recommended for experienced users If it is started manually it must be done before starting the AA via the Lab Server However manually starting TA will not influence the behaviour of the system The TA can be run by executing the file startTransportationAdapter bat or by writing the following on the command line java Djava secutiry manager Djava security policy policyForExperiment jar TransportationAdapter jar If the location of the ini files are not the current directory the location of the ini files may be specified in a similar way as when starting the dummyProvider in the previous section java Dcyberlab inifile dir lt path_to_the_inifile gt Djava secutiry manager Djava security policy policyForExperiment jar TransportationAdapter jar d The above also assumes that Sun s JDK 1 3 or JRE 1 3 is installed and properly configured TransportationAdapter can be given the following parameters which must be written at the very end of the line when starting TA Table9 Program arguments for TransportationAdapter Parameter Description d Print debug information to default out PXXXX Listen on porti XXXX when communicating with the experiment software default is 5678 or the value in CLProvider ini qXXXX Listen on port2 XXXX
43. blank or else the last property will not be read properly Confidential 2003 06 21 Page 65 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 The properties available for use in CLProviderCallback ini are shown in the table below Table 11 Properties in CLProviderCallback ini Property name Description Example value Experiment_ld Identifier of this lab Will be sent to DummyLab123 the Cyberlab system Refrigeration cycle process Head box The Inverted Pendulum The Electrical Drive Optical Tracking System Filename Name of the file used by the ProviderSessionFile txt Provider to store the updated access control list 12 4 Policy file policyForExperiment On some systems TransportationAdapter is not given the correct default security access rights Therefore the following policy file is used when starting the application AUTOMATICALLY GENERATED ON Wed Jan 10 11 32 07 GMT 01 00 2001 DO NOT EDIT grant codeBase file ermission java net SocketPermission localhost accept J connect listen resolve ermission java net SocketPermission 129 241 187 64 accept J connect listen resolve ermission java net SocketPermission cyberlab org accept J resolve ermission java io FilePermission lt lt ALL FILES gt gt read write D J permission java util PropertyPermission use
44. ble Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 9 The Java version of the interface 9 1 Example architecture using Java RMI This example illustrates an example solution using Java RMI for the communication part between the CCS and the Lab Server Java RMI is very flexibility and requires little resources to implement To get around the problem that Java RMI does not communicate very well with other languages than Java it has been chosen to make a middle layer This middle layer or glue is a Java application that translates Java RMI calls into something which can be read by any programming language TCP IP communication with an own protocol This means that the Provider must implement the defined Java interface and include this code segment in his own Lab Server SW running on Cyberlab Server Cyberlab computer Java RMI TransportationAdapter Communication Standalone Java Application module communication E TCP IP Socket ApplicationAdapter Glue made by Interface and Cyberlab belongning implementation The provider includes the Provider s experiment ApplicationAdapter software in the experiment software One program Can be Java C C etc Software running on experiment PC Figure 14 Example of the architecture for the communication mechanism between the Cyberlab Server and the Lab Server using Java and the sta
45. cal schematic of the main SW components and interactions for a typical solution using Java RMI iergert DuRe Eug ECH dE ge 16 Figure 9 Main window for Cyberlab Communication Server ssssssssessssseenerrnnereserrrrrrrn 17 Figure 10 Using a DB in the middleware solution ccceeeeeeeeeeeeeceeeeeeeeeeeeeeeneeeeeeeees 18 Figure 11 Using the standard Java solution 19 Figure 12 A simplified diagram of the standard middleware solution and its components19 Figure 13 The extended middleware solution un 21 Figure 14 Example of the architecture for the communication mechanism between the Cyberlab Server and the Lab Server using Java and the standard interface 53 Figure 15 Overview of communication between the Provider and CCS using local sockets 55 Figure 16 UML diagram of the socket package TestProvider represents a class in the Providers DOE reee nerne ara ea EE Ea EA A E EE Ra AEAEE 56 Figure 17 Cyberlab Information applet after a successful login and after a non successful one 69 Figure 18 Questionnaire and Tech support from the Cyberlab Information Applet 70 Confidential 2003 06 21 Page 6 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 Summary This document gives a brief introduction of the SW and methodology used for connecting remotely operable laboratories to the Cyberlab Network via the Cyberlab Communication
46. ccess to a limited set of values e The rules for when and by whom it should be possible to set individual values must be clarified Confidential 2003 06 21 Page 42 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 e The Provider must supply Cyberlab with a list of available identifiers tags together with a short description The list should also include a summary of the restrictions applied for the individual identifiers 7 2 2 4 Example code N A 7 2 3 resetExperiment 7 2 3 1 The method public java lang String resetExperiment This method is optional and is called by the Cyberlab Communication Server Calling this method will cause the Lab Server to reset the laboratory to a predefined ready and safe state Parameters no parameters Return value The Lab Server returns OK represented as a String or ERROR followed by an error description 7 2 3 2 CCS implementation details e This method is only called by the CCS on request or based on a specific event e Only the Cyberlab Admin should be allowed to manually trigger this message e This message can be used if the Customer Provider communication is lost during an experiment run e The message can also be used in order to prepare the Lab for new Users 7 2 3 3 Lab Server implementation details e The business logic for this method must be defined for each individual lab
47. d but definitely not outdated Java RMI solution will continue working without any modifications whatsoever The new addition to the middleware solution is currently under testing CYBERLAB SERVER CORBA WRAPPER SERVER DISPATCHER I RMI JRMP IIOP TRANSPORTATIO ADAPTER RMD soccer X APPLICATION APPLICATION ADAPTER ADAPTER PROVIDER II S Figure 13 The extended middleware solution The double lines marked JRMP Java Remote Method Protocol and IIOP Internet Inter ORB Protocol is the separation between server and provider software Everything below these lines is part of the provider software and hence situated on the provider computers Below are some notes regarding the various components in the extended middleware solution e Cyberlab Server The server can handle communication over different protocols such as JRMP and IIOP e Dispatcher RMI This represents a dispatcher object registered with the Cyberlab Server The object enables RMI Remote Method Invocation communication between software written in the Java programming language This dispatcher is part of the standard solution and is still is part of the Confidential 2003 06 21 Page 21 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 extended solution because of backward compatibility It enables existing Providers to communicate with the enhanced server
48. der to detect and possibly correct problems with incorrect time settings at the Provider computer e If the time is not set correctly the Lab Users will have problems accessing the Lab according the reservations that have been made e Some of the notations used Greenwich Mean Time GMT Coordinated Universal Time UTC Dayligth Savings Time DST Norway UTC 0200 with DST UTC 0100 no DST e More information about the time zones can be found on htto www cl cam ac uk mgk25 iso time html Overview of timezones etc http Awww twinsun com tz tz link htm Timezone conversion 7 1 6 4 Example code N A 7 1 7 getExperimentid 7 1 7 1 The method public java lang String getExperimentid This method is compulsory and is called by the Cyberlab Communication Server The Lab Server returns a String giving a unique identification of the Lab Parameters no parameters Return value The Lab Server returns a unique identification of the Lab in a String or ERROR followed by an error description The unique identifier will follow the following syntax Confidential 2003 06 21 Page 40 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 lt providerShortName gt lt labShortName gt Some typical identifiers are NTNUrefrig RUBoptiCon EPFLpendulum 7 1 7 2 CCS implementation details N A 7 1 7 3 Lab Server implementation details e
49. e User and the Lab Server e In order to make reservations for a lab run the User must be registered as a Cyberlab User and given the appropriate privileges The bookings are stored in the Cyberlab DB e Several booking modes exist as briefly described elsewhere in this note Several alternative solutions and options are available with respect to how the requested bookings are sent to the Lab Server er ren a ow eee O29 Ber res Bee e 28 A mg e me Ce d http Java RMI Corba Ke amp access data Booking amp customer y EA Your timezone CET 2 hours Current date 2001 09 17 Laboratory Head box ef Recommended number of timeslots for this experiment 1 Start CET Status Booking Start CET Status Booking __ 00 00 en mi 12 00 Ka 01 00 02 00 03 00 04 00 05 00 06 00 07 00 08 00 09 00 ep Occupied time slot 10 00 RW m imiu u mju mjm a 5 88888 ooo eet Set Ce te Note Remember to stor 11 00 Figure 6 The Booking process Confidential 2003 06 21 Page 14 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 2 5 Running an experiment When a User is running an Experiment on a Lab there are two main information channels and one optional These are illustrated in Figure 3 below Some main characteristics at this stage are e Normally the User will
50. e gare gas ys ae Mae Die ake See a ee ars Pitas cee m Currently only the alternative 1 format of the access list is supported session_i username password starttime endtime priority Confidential 2003 06 21 Page 37 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 5 and not the new format lt br gt SS session_i username password starttime endtime priority expId x The time format starttime and endtime is OOO SIMMS DD alial 3 imine ASI The time ig stored sim U fetaczs paramaccessList List of accepted upcoming sessions return the value represented as a String or ERROR followed by A an error description SCH public String updateAccessControlList String accessList AA erte Buitiiierecliicitec usel to welte co ELLS BufferedWriter writer null ey A writer new BufferedWriter new FileWriter FileName catch IOException e System out printlin Can t open FileName Stringlokenizer Eieren naw Stringroksnizerl accessslist ns while token hasMoreTokens String type token nextToken Ee A ff Wiemheess a lator to ks writer write type writer newLine catch IOException e System out println write failed for FileName Write some additional entries for Admin purposes Eeer A
51. e than X working days from will be accepted This in order to allow for manual local user registration at the Provider site For this first time user Cyberlab sends a user registration request by email to the Provider Admin informing about Username full name email The Provider registers the new user and The Provider sends an email to Cyberlab notifying the result of the registration Cyberlab will send the new user a notification email if the registration process at the Provider site failed for some reason Cyberlab registers the User as a confirmed user for the Labs from this specific Provider A confirmation email will automatically be sent from Cyberlab to the User including information about the booked timeslots instructions on how to change cancel bookings specific Provider login instructions the username to use for logging into the Lab Cyberlab username but no password The Provider sends an email with the password to the User This password is only valid for the Labs from this specific Provider The message updateAccessControlList containing upcoming lab sessions is sent from Cyberlab to the Provider The Provider stores the updated access control list in a protected DB or file on the Provider computer The User can log into the Lab from a Provider web page using the same username as for the Cyberlab site but with a Provider specific password A message oginResult is sent from the P
52. entinterface private static final String EXPERIMENT_ID DummyExperiment123 public CallbackClass doSomelnitializationlfNessesary public String getExperimentld return EXPERIMENT_ID public String getExperimentValue String identifier doSomething return someString public String setExperimentValue String identifier double value doSomething return someString public String resetExperiment doSomething return someString public String throwOutUser String sessionld doSomething return someString the rest of the methods are put here 11 7 2 Interface com cyberlab Cyberlabinterface This is the interface which defines all the method calls which a Lab Server can call on the Cyberlab Communication Sever See the JavaDoc for a more detailed description of the interface and its methods 11 7 3 Class com cyberlab applicationAdapter ApplicationAdapter The ApplicationAdapter AA is the class which automatically sets up communication to TransportationAdapter TA and thus the CCS The AA has a constructor which takes a object any class implementing Experimentinterface the CallbackClass as the only parameter That object is used when the AA receives calls from the CCS When creating a new instance of AA the following or similar code must therefore be used Connects to the Cyberlab Server Experimentinterface callback new CallbackClass try cyberlab
53. erver Note This method may become compulsory in the next release Parameters offlineStatusDescription A String describing the OFFLINE status Typical values are Maintenance SW upgrade etc Return value The Cyberlab Communication Server returns OK to signal that the message was received the last answer from Cyberlab or ERROR followed by an error description 8 2 2 2 CCS implementation details e The Lab status will be set to OFFLINE after this message has been received 8 2 2 3 Lab Server implementation details e The Providers are encouraged to implement this method even though it is not compulsory Confidential 2003 06 21 Page 50 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 The offlineStatusDescription should be accompanied with a string indicating when the Lab is expected online again 8 2 2 4 Example code N A 8 2 3 log 8 2 3 1 The method public java lang String log java lang String type java lang String sessionld java lang String action This method is optional and is called by the Lab Server The method logs some specific activity on the Lab Server The logged action can be initiated by both the user and the system Note The next release may include a timestamp from the Provider Lab Server as a parameter for this method Parameters type Log type Legal values USER SYSTEM sessionId A s
54. erver normally calls this method every 12hr All upcoming sessions for the specific lab for the next 24hrs are sent every time the method is invoked e The method is also invoked every time an existing booking for the specific lab has been modified new moved or deleted from the Cyberlab Portal Confidential 2003 06 21 Page 36 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 By default two or more consecutive sessions in the Cyberlab booking DB is transferred to the Provider Lab Server as one continuous session This in order to avoid the user to be thrown out after the end of the individual session s The criteria for concatenating consecutive bookings are a same labuser b the same lab and experiment ID The labs can be individually be configured so that the CCS do not concatenate the bookings before sending them to the Lab Server No spaces are allowed in the username The usage of priority must be configured for each individual lab The password can be sent to the Lab Server in clear text or using a built in encryption algorithm All start and stop times are stored and sent to the Provider in UTC The bookings are moved to a historical DB after endtime has been reached 7 1 4 3 Lab Server implementation details The actual implementation of this method is Lab specific Some Labs are using a local SQL DB for storing
55. ession ID describing the user action The action triggered by the SYSTEM or the USER Return value The Cyberlab Communication Server returns OK in a String or ERROR followed by an error description 8 2 3 2 CCS implementation details e The CCS stores historical data for the actions 8 2 3 3 Lab Server implementation details e The Provider must define and specify the actions to be stored 8 2 3 4 Example code N A 8 2 4 checkUserAccess 8 2 4 1 The method public java lang String checkUserAccess java lang String sessionld This method is optional and is called by the Lab Server The method is used by a lab to check if a user is allowed to access the lab Confidential 2003 06 21 Page 51 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 Parameters sessionId A session ID describing the user Format sessionld lt username gt lt password gt Return value A String describing the access rights or ERROR followed by an error description Note This method was in the Not used category in the previous release 8 2 4 2 CCS implementation details N A 8 2 4 3 Lab Server implementation details e Not all Labs will need this method 8 2 4 4 Example code N A 8 3 Not used methods These methods are not described in any detail Confidential 2003 06 21 Page 52 of 70 Connecting Remotely Opera
56. g the provided username and password The encrypted password is stored in a local Provider DB together with the username The User will logon to the Provider Lab using his Cyberlab Portal username and password The Provider will call a method VerifyUser username password returning true false 0 A message oginResult is sent from the Provider to the Cyberlab Server 1 If login is accepted the Lab application is started and operation is made available for the user and 12 the Cyberlab Status Window is launched on the User s computer oF Le ae eee Confidential 2003 06 21 Page 67 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 Cyberlab will require an agreement with the Provider concerning protection of the password 13 3 Provider with manual registration procedure 1 2 oro N 11 12 13 14 15 16 17 19 The user registers as a new user at the Cyberlab Portal site The user selects the username and password for the Cyberlab Portal However in some situations like bulk booking the Cyberlab System will automatically generate a username Cyberlab stores the username and password encrypted in the Cyberlab DB When the new user books a lab session on a lab from a specific Provider Cyberlab registers the User as a non confirmed user for Labs from the specific Provider In this case only bookings mor
57. has an encryption and a decryption method 13 1 1 Example of using the Crypto package The Crypto package can be tested using a simple test program CryTest e g by entering java classpath Crypt jar CryTest I want to encrypt this and see it decrypted again For the usage in the Cyberlab system the username and the password are encrypted in one single string by separating the username from the password by a f The encryption can be simply performed by calling String userlD crypter encryptString UserName Password This string can then be used for the user ID throughout the Cyberlab system The original information can be later extracted by String UserNameAndPassword crypter decryptString userID and then simply split into UserName and Password at the 13 2 User registration and User login at Provider Lab using the encryption scheme This is the normal procedure to be applied for the Labs 1 The user register as a Lab User at the Cyberlab Portal site and requests Customer status 2 The user may also have been registered by someone else via the Bulk booking scheme If so the user will receive the username and password via email from Cyberlab The user can change the password whenever he she wants The user makes bookings for a specific lab The bookings are sent to the Provider s Lab Server together with the username and password in encrypted form If needed the Provider will manually create a local user usin
58. he individual lab lt starttime gt The start time of the lab session The time is given in UTC using the following format YYYY MM DD hh mm lt endtime gt The end time of the lab session Same format as for the lt starttime gt lt priority gt The given priority for the actual session This is normally represented as an integer in the range 1 10 with 1 as the highest priority This parameter is optional and normally only used for labs with a priority based access control lt expID gt The experiment identifier for current session Interpreted as default experiment if lt expID gt is not specified lt NOTE gt The next release of the interface will only support alternative 2 above Currently each lab must be configured explicitly to support alternative 2 The default configuration is alternative 1 Contact Cyberlab in order to configure the lab to receive the booking data in the alternative 2 format lt NOTE gt The time starttime and endtime is sent to the individual labs in UTC Return value The Lab Server returns the update status as OK if the access list has been successfully updated or ERROR followed by an error description if the update has failed 7 1 4 2 CCS implementation details The following rules apply for the CCS implementation of the updateAccessControlList method e The booking data is collected from the Cyberlab booking database e The Cyberlab Communication S
59. he access 8 1 2 4 Example code Here is a very simple example of a Provider implementation of the loginResult method This example is from the NTNU lab using the Apis system It also shows how the loginResult method is used both when users log in and log off Callback from Apis when a new user session has started The method will be called both for successful and unsuccessful login EE Ka param nApisUserSessionID Additional identifier separating several S sessions for one user param nApisUserName Username for user logged in the same as in the a cl_session file param nCLientType The client type enum CT_NONE 0 CT_OPC_DA 1 S CT_OPC_AE 2 Only CT_OPC_DA is interesting for the a refrigeration process param strRole Not used To be used in a future release of Apis with Net D role based sequrity model param strSessionInfo Not relevant for the Refrig process To be used by zi Apis configuration tool providing more info about the session No ns EE DIE e OUD SmeEC Ka SS public void OnUserSessionStarted int nApisUserSessionID String strUserName int nClientType String strRole String strSessionInfo String loginString OnUserSessionStarted nApisUserSessionID Confidential 2003 06 21 Page 47 of 70 Connecting Remotely Operable Labs to the Cyberlab Network Introduction Cyberlab Org UM 013 01 Revision 1 0
60. implementation details AE 37 LATOR Example COO Cres soos ee 37 7 1 5 Gute KE EE 38 Ke SE AVC INOUIOO Hc avcetasceoeticces debs steed he ncvte cae E EAER 38 7 1 5 2 CCS implementation CCAS si sac sco2s ceded ccs adecs cates tedcoasact oes dadetdes awdees atest 39 7 1 5 3 Lab Server implementation details AAA 39 7 1 5 4 gt ie 39 FAG ei D EE 39 ZEOT Ne EE 39 7 1 6 2 CCS implementation details 40 7 1 6 3 Lab Server implementation details 2 cccsseeeceeeeeeeeeeneeeeeeeeeeeteeesnsaeees 40 FAA E EE 40 Ee Ge Ce A0 E Dee EE 40 7 1 7 2 CES implementation Cette ciciccccsciareceeecisgeteet ct ehanpatedelansatetatecdaeetvessts 41 7 1 7 3 Lab Server implementation details E 41 TNT EE 41 Fg ace lee Ee 41 7 2 1 GETEXDSNIMG MTV AUG ee ee Seen ead eaves Zeene Deeg Zeen 41 Petal reel EE 41 7 2 1 2 CCS implementation details 42 7 2 1 3 Lab Server implementation details AE 42 Fb TEX te 42 7 2 2 setExperimentValue osceck cong nnndia eege ebe eege Eege 42 Zet PAC IICTIOO E 42 7 2 2 2 CCS implementation details 42 7 2 2 3 Lab Server implementation details unn 42 7 2 2 4 Example GOO Cas etic EE 43 7 2 3 PESGIEXPOMINIGNT EE 43 728 1 fg 06 21 1 98 Em ene tir ett renee ON rare tener e a ore entre ere 43 7 2 3 2 CCS implementation OCIANS ccasstseic bed ne endseedtan bsdeeentesaaees tad cients eaeeseaeet 43 7 2 3 3 Lab Server implementation details unn 43 7 2 3 4 Example GOGO ee EE 43 7 2 4 connectionlsLost e ege ege eege
61. in time is represented in UTC Login time format should be YYYY MM DD HH MM Typical values for the error description are wrong password not a valid timeslot access refused by Provider lt NOTE gt This method is also used when a user logs off from the Lab Confidential 2003 06 21 Page 46 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 lt NOTE gt The timestamp is added automatically to the message sent to the CCS This is done in the TA level Return value The Cyberlab Communication Server returns OK in a String or ERROR followed by an error description 8 1 2 2 CCS implementation details The following rules apply for the CCS implementation of the oginResult method e The login result is stored in the Cyberlab DB together with a timestamp for the login e The timestamp is stored in UTC e Some providers may use the checkUserAccess method in connection with this method Other Labs use the locally stored accessControlList in order to verify the access 8 1 2 3 Lab Server implementation details e The logic for verifying the username and password against the ones in the database is defined elsewhere and may vary from Provider to Provider e Some providers may use the checkUserAccess method in connection with this method Other Labs use the locally stored accessControlList in order to verify t
62. inering The lab consists of an industrial refrigerator which can be controlled and fine tuned via the Internet This service provides live video and sound 3D Virtual Reality models simulators process diagrams and much more Description a Short description Industry style refrigeration cycle process lab lt br with control er Keywords Process control Controller tuning Instrumentation URL http www remotelab ntnunofrefrig 020000 Status online z Provider NTNU Cybernetics zl Image information Title The lab process Figure text Ps of the lab process and local computer with WinCC and Apis Figure 4 Provider Admin s online editing of Lab details Confidential 2003 06 21 Page 12 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 2 3 Booking options The main booking options that is available via the Portal are Timeslot based booking Priority based Recurring booking Bulk booking In addition the Provider Admins can easily configure the lab availability for external usage and own administrative bookings for their own labs Laboratory Head box Your timezone CET 2 hours Experiment Default experiment Current date 2001 09 17 Customer Tor Ivar Eikaas Recommended number of timeslots for this experiment 1 Start CET Status Booking Start CET Status Booking 00 00 12 00 01 00 13 00 02 00 14 00 03 00 15 00 04
63. interface AAA 61 11 7 2 Interface com cyberlab CyberlabIinterface AAA 62 11 7 3 Class com cyberlab applicationAdapter ApplicationAdapter ss0nseneeee 62 12 Configuration files for the Provider eeeeeeeeeeeeeeeeeeneeeeeeeeeeeeeeeeeeeeeeeeeeaeeeeneeeeeeneees 64 12 1General 64 12 2 GU e le LEE 64 E ge le E Ee EE 65 12 4 Policy file pohcvtortvperment AA 66 Confidential 2003 06 21 Page 4 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 13 Access Te anair seeder coe cacsneccnnctncadsaetncccnacescncuaetssccencssusdsantnicceactouscuawts tcckacesusesaetnece 67 13 1 Password encryption aloortthms cece tere rete tecneeeeeeee ee eteeecnaaeeeeeeeeeeneee 67 13 1 1 Example of using the Crvpiopackaue 67 13 2 User registration and User login at Provider Lab using the encryption scheme 67 13 3 Provider with manual registration procedure ssssseesssssetrrnretsstrrtrrnrrrssrrtrerrnneeseet 68 14 Run time information to Lab USers ccccseseeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeneees 69 14 1 General 69 14 2 Integrating the Cyberlab Information Window with the Provider GW 70 Confidential 2003 06 21 Page 5 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 Tables Table 1 Experimentinterface Methods initiated by Cyberlab
64. is is the organization in this case Cyberlab responsible for the services offered both to Customers and Providers A predefined exercise defined for performing some operation on a Laboratory See Lab Server A non registered person accessing the Cyberlab Web A Guest has only limited access to the site s functionality Graphical User Interface Often also called HCI The whole setup of the physical apparatus instrumentation and SW needed for a laboratory A Cyberlab User accepted for access to one or more of the Labs A Time Slot or a single access to a Lab This is the shortest possible duration when booking access to a Lab The SW running on the Providers site providing the necessary functionality for interfacing the Lab and the Cyberlab Server In addition the Lab Server may provide functionality for the communication with the Lab User Client SW when operating the Lab An organization owning a Lab A Cyberlab User from the Provider organization given Provider Admin rights Transportation Adapter A person registered as a Cyberlab User Username Identifies the person accessing the Cyberlab system independent of his role as Cyberlab Admin Lab User Provider Admin etc Confidential 2003 06 21 Page 8 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 Part System overview 2 General system overview of the Cyberlab System
65. istered on the server This is also used in order to gain some experience with the extended solution Provider These are the actual components of the Lab Servers that must be implemented by the lab providers The two provider boxes to the left must have an Application Adapter written in the same programming language while the rest are CORBA providers that need a CORBA implementation for the programming language in use Today there exist CORBA implementations for all the major programming languages Cyberlab has built test providers using the programming languages Java C and Visual Basic The solution seems to function properly The main advantages with the extended communication model are Better language independence when integrating new Providers The code on the client provider side should also be somewhat easier to implement It is also important that it works as an enhancement and not a logic change of the system meaning that the old functionality is preserved while new functionality is added Confidential 2003 06 21 Page 22 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 5 Connecting a Lab to the Cyberlab Network 5 1 Introduction This chapter describes how Providers can use software provided by Cyberlab to connect a Lab to the Cyberlab System This document focuses on the way it is done using Java Other interfaces like C and Visual
66. ive more information like under maintenance Expected to be online yyyy mm dd upgrading lab SW Expected to be online yyyy mm dd UNKNOWN It is not possible to determine the lab status The lt status description gt should give more information like Lab is not responding No socket communication with the Lab Server Unknown reason for break in the communication UNAVAILABLE The lab is currently not available for Cyberlab usage Lab is used locally Confidential 2003 06 21 Page 32 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 7 1 1 2 CCS implementation details e The method is run on all labs with a lab specific frequency e The method can also be triggered manually or based on some specific event e The update interval is specified individually for each lab The default is set to 10min e The system automatically checks the time deviation between the CCS and the Provider Lab Server If the difference is too large a notification is sent by email to the Provider admin 7 1 1 3 Lab Server implementation details All Lab servers must implement this method but the business logic needed for defining the actual status will vary between the individual labs For some Labs it will be possible to check only if some program is running and probably the current measurement of a few tags For other Labs
67. le the communication from the Lab Server computer to the CCS The name TransportationAdapter implies that the application adapts the messages sent between the Lab Server and the CCS The current version of TA use Java RMI communication towards the CCS It is therefore important that the Lab Server if put behind a firewall is made sure to be able to communicate on the default ports used by Java RMI A description of how to use RMI behind a firewall can be found on Sun s RMI web site at the FAQ http java sun com j2se 1 3 docs quide rmi fag html firewall No programming is needed for the Provider to use the TA but it is important that the Provider knows that TA shall be used when doing further programming of the Lab Server This is because the ApplicationAdapter AA described below requires a running TA in order to communicate with the CCS 11 6 1 Running the TransportationAdapter The TA can be started manually or it can be started automatically by the AA The default mode is to start the TA automatically The TA will need the configuration files CLProvider ini and CLProviderCallback ini in order to operate correctly on the Providers computer In order to locate the ini files the TA will use the property cyberlab inifile path if set Otherwise the TA will use the standard system property user dir as the path for the ini file Confidential 2003 06 21 Page 60 of 70 Connecting Remotely Operable Labs to the Cy
68. ling used by CyberlabCom SocketWrapper h ReadSocketThread cpp Used by Linux for multithreading An instance of this class is ReadSocketThread h listening on a socket for CCS calls y Com init by Provider Com init by CS F Communication by sockets SocketWrapper CyberlabCom 1 ReadPortThread Socketinterface TestProvider main Interface KH Ooo O Figure 16 UML diagram of the socket package TestProvider represents a class in the Providers project 10 1 3 Detailed description Providers using JNI need to run a standalone Java application consisting of the Transportation Adapter TA in conjunction with the ApplicationAdapter AA TA communicates with the CCS via RMI over the Internet TA and AA communicate via local sockets and Providers communicate with AA through JNI Providers using the socket package shortcut AA The socket package communicates with TA through the same sockets AA was using Providers using the socket package need to run TA as a standalone Java application It is important that TA is started and running before the Providers application is started This is to ensure correct socket creation The TA must have permissions to start RMI and socket communication This is done via a Java policy file The Providers projects must include the socket package A class in the Provider project must extend Socketlnterface and implement the virtual methods of Socketlnterface The same class must make an instance
69. llObject main getExperimentCallObject back ExperimentId awy A userName logoutString 8 1 3 isAlive 8 1 3 1 The method public java lang String isAlive This method is compulsory and is called by the Lab Server It is a Cyberlab System method used internally by the system for checking the connection between the Lab Server and the Cyberlab Communication Server Confidential 2003 06 21 Page 48 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 Parameters no parameters Return value The Cyberlab Communication Server returns OK to signal that the message was received or ERROR followed by an error description 8 1 3 2 CCS implementation details N A 8 1 3 3 Lab Server implementation details e The Provider does not need to do any implementation work for this method as such See details from the available example code for a simple Lab Server dummyProvider for details on how to implement the necessary logic around this method e Should be called once approx every 1 5min from the Provider SW 8 1 3 4 Example code N A 8 2 Optional methods 8 2 1 getVer 8 2 1 1 The method public java lang String getVer This method is optional and is called by the Lab Server The method will return the current and most up to date version numbers of the main components in the Cyberlab system Parameters
70. look like when returned from the Lab Server after requesting All TA 0 5 AA 0 5 ES 1 4 7 1 3 4 Example code N A 7 1 4 updateAccessControlList 7 1 4 1 The method public java lang String updateAccessControlList java lang String accessList This method is compulsory and is called by the Cyberlab Communication Server normally once every 12hr The Cyberlab Communication Server sends a list of all the accepted upcoming sessions bookings for the next 24hrs for the specific lab Parameters accessList List of accepted upcoming sessions The format of the accessList String is lt session_1 gt lt session N gt where Confidential 2003 06 21 Page 35 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 Alternative 1 lt session_i gt lt username gt lt password gt lt starttime gt lt endtime gt lt priority gt Alternative 2 lt session_i gt lt username gt lt password gt lt starttime gt lt endtime gt lt priority gt explD lt username gt The Cyberlab username identifying the user that has been booked for a lab session lt password gt The password to be used during login on the Laboratory Normally the password is encrypted but it can also be in clear text for some labs For some labs the password is not sent via this mechanism This parameter is optional depending on the solution used at t
71. meslot when a Cyberlab user has booked lab time b alocal user is performing local maintenance of the Lab c the session is performed by a Provider Admin d the session is outside a timeslot booked by a Cyberlab Customer e the Lab is not defined as ONLINE or RUNNING e The actual business logic for this method should be agreed with Cyberlab 7 1 5 4 Example code N A 7 1 6 getCurrentUTC 7 1 6 1 The method public java lang String getCurrentUTC This method is compulsory and is called by the Cyberlab Communication Server The Lab Server should respond to this method by sending the current UTC as seen by the Lab Server Parameters no parameters Return value The Lab Server returns current UTC in a String or ERROR followed by an error description The format of the current UTC String is lt currentUTC gt YYYY MM DD hh mm Confidential 2003 06 21 Page 39 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 7 1 6 2 CCS implementation details e The CCS calls this method with a specified frequency e The period can be configured individually for each Lab e The default request frequency is 24hrs e The offset error is computed by the CCS If the deviation the error is greater that a specified limit an email is automatically sent to the Provider Admin 7 1 6 3 Lab Server implementation details e This method is important in or
72. n order to run the DummyProvider some initialisation may be required 1 Configure CLProvider ini Set the correct IP address for the computer running the CCS Normally this will be CL_Server_RMl rmi 129 241 187 53 1099 CyberlabRmiDispatcherInterface During testing etc this may be set to another IP address according instructions from Cyberlab 2 Configure CLProviderCallback ini Set the correct identification for the lab using the Experiment_ d identifier Please note that you must use a valid identifier provided from Cyberlab Failing to use a unique and valid identifier will cause error messages trying to connect to the CCS Also note that the identifier must be a valid entry in the Cyberlab DB Please contact Cyberlab in case a new entry is needed 3 Configure policyForExperiment Set the correct IP address for the computer running the CCS This is the same IP address as for item 1 The entry will look like this permission java net SocketPermission 129 241 187 53 accept connect listen resolve Note that the policy file may have several entries 4 Start the dummyProvider 11 5 Running DummyProvider Windows DummyProvider can be run by executing the file startDummyProvider bat or by writing the following on the command line java classpath TransportationAdapter jar DummyProvider jar crypt jar com cyberlab dummyProvider ProviderMain If the ProviderMain starts the TA and the ini files are not located in current
73. ndard interface 9 2 Error recovery at the Provider side A lot of error recovery mechanisms are built into the system in order to make it as reliable as possible In this section the main principle of the recovery sequence at the Provider side is given Confidential 2003 06 21 Page 53 of 70 Connecting Remotely Operable Labs to the Cyberlab Network Introduction Cyberlab Org Before the ProviderMain calls method on the CyberlabServer it always checks the connection by running a test method on CyberlabServer If an error or communication problem occur then it will try to re establish the connection Situation An error or a communication problem occurs Action ProviderMain in Lab Server UM 013 01 Revision 1 0 Start recovery sequence 1 checkConnection is called a isAlive is called This method will check the connection with CCS b If an error or communication problem has occurred then isAlive returns a string that starts with error c stopConnection is called This method will stop the cyberlab connection i if TransportationAdapterDispatcher and ApplicationAdapter are running then stop it by calling 1 stopTAD which stop the TransportationAdapterDispatcher 2 stopApplicationAdapter which stop the ApplicationAdapter ii else if only the ApplicationAdapter is running then stop it by calling 1 stopApplicationAdapter which stop applicationadapter 2 reConnect is
74. new ApplicationAdapter callback catch UnknownHostException e System out printIn Error Can not find host n e nExiting System exit 1 catch IOException e Confidential 2003 06 21 Page 62 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 System out printIn Error 1O error n e nExiting System exit 1 The above example is taken from DummyProvider It assumes that the variable cyberlab is defined somewhere above the code shown After the variable cyberlab has been initialised as shown in the code above method calls can be sent to the CCS Some code examples are shown below See the example code in ProviderMain java for more examples Example 1 Get version if checkConnection false Check connection with CCS reConnect Re establish connection with CCS System out printin The version is cyberlab getVer else System out printin The version is cyberlab getVer Example 2 Disconnect from the CCS if checkConnection false reConnect System out printlin I say disconnect the answer is cyberlab disconnect Shutdown due to scheduled upgrade stopConnection Stop CCS connection else System out printin I say disconnect the answer is cyberlab disconnect Shutdown due to scheduled upgrade
75. of CyberlabCom CyberlabCom makes the necessary socket connections to TA using an instance of SocketWrapper CyberlabCom s constructor takes a pointer to the Confidential 2003 06 21 Page 56 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 Provider owner class which implements Socketinterface Calls from CCS to the Provider are sent through CyberlabCom which uses the methods in SocketInterface to invoke methods at the Provider Calls to CCS from the Provider go through methods in CyberlabCom The socket package is multithreaded The package uses two sockets for communication one which is a client socket for communication from the provider to CCS the other is a server socket for receiving calls from CCS Listening on the server socket requires a thread of its own because the thread hangs on the socket till something is written to it Thread handling is different on Windows and Linux On Windows CyberlabCom has a static method which runs in it s own thread On Linux the equivalent thread is defined in a class of it s own ReadSocketThread It is important that the Providers project supports multithreading and includes the necessary lib files for it Include Ws2_32 lib in Windows and libpthread so in Linux 10 1 4 C interface methods Presented here are the constructors and methods available in the socket package The Providers must take notice of
76. ork UM 013 01 Introduction Cyberlab Org Revision 1 0 lt identifier gt lt value gt 7 2 1 2 CCS implementation details e This method can for example be used for generating customised reports for documenting an experimental run 7 2 1 3 Lab Server implementation details e The names of the identifiers are Provider specific e The Provider may restrict the access to a limited set of values 7 2 1 4 Example code N A 7 2 2 setExperimentValue 7 2 2 1 The method public java lang String setExperimentValue java lang String identifier double value This method is optional and is called by the Cyberlab Communication Server A new value for a specified identifier is specified from the Cyberlab Communication Server and sent to the Lab Server The corresponding identifier at the lab is updated with the new value Parameters identifier The identifier of the value to read e g variable name tag value The new value to set to the variable Boolean is represented as 0 0 false and all other numbers true Return value The Lab Server returns OK represented as a String or ERROR followed by an error description 7 2 2 2 CCS implementation details A set of high level identifiers may be defined in the Cyberlab System 7 2 2 3 Lab Server implementation details e This method is important for Labs where customised reports are generated e The names of the identifiers are Provider specific e The Provider may restrict the a
77. otely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 This method is compulsory and is called by the Lab Server A call to this method will establish the connection with the CCS The CCS returns a String giving the result of the connection Parameters no parameters Return value The Cyberlab Communication Server returns OK in a String in order to signal that the connection was established otherwise ERROR followed by an error description 8 1 1 2 CCS implementation details N A 8 1 1 3 Lab Server implementation details The Provider does not need to do any implementation work for this method as such See details from the available example code for a simple Lab Server dummyProvider for details on how to implement the necessary logic around this method 8 1 1 4 Example code N A 8 1 2 loginResult 8 1 2 1 The method public java lang String loginResult String labName java lang String sessionID java lang String result This method is compulsory and is called by the Lab Server The method returns the result from attempted login both successful and non successful login attempts together with the actual login time Parameters labName The lab identifier defined by Cyberlab sessionID The identifier for the current user username result The result of the attempted login Legal values are OK lt login time gt ERROR lt login time gt lt error description gt Log
78. plemented in other languages than Java to communicate with the Cyberlab Server These adapters are part of the standard solution with RMI communication model to free the solution from the Java language dependency A provider using these adapters can still communicate with the extended version as long as the RMI dispatcher is registered with the server The Transportation Adapter is written in Java and act as a client towards the RMI dispatcher on the server side and at the same time it registers a Socket server within itself to talk with Application Adapters written in any language that support socket communication The drawback is that application adapters will have to be implemented in the different languages and this is not a straightforward operation Socket communication is low level programming compared with program packages such as RMI RMI IIOP and CORBA Today Cyberlab Org has implemented Application Adapters in Java and the C programming languages Transportation Adapter RMI IIOP This block represents a modified Transportation Adapter that will enable Application Adapters Providers using the standard solution to connect and communicate through the RMI IIOP dispatcher object By using this object the RMI dispatcher object at the server will be surplus to requirements but it also means that already existing providers must change to this new adapter before communication can take place In a transition state both communication dispatcher are reg
79. pplicationAdapter ProviderMain 7 ApplicationAdapter passes the return value further to the original caller ProviderMain 4 2 2 Calls initiated by the Cyberlab Communication Server Calls from CyberlabServer to ProviderMain A simplified description of the calls from the CyberlabServer to the ProviderMain is given below CyberlabServer 1 CyberlabServer sends a call to the TransportationAdapter over Java RMI TransportationAdapter 2 TransportationAdapter sends the call further over TCP IP Socket communication to the ProviderMain s CallbackClass ProviderMain 3 CallbackClass does the necessary action s according to the call 4 CallbackClass returns a return value over TCP IP Socket communication to the TransportationAdapter TransportationAdapter 5 TransportationAdapter passes the return value further over Java RMI to the CyberlabServer CyberlabServer 6 CyberlabServer receives the return value Confidential 2003 06 21 Page 20 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 4 3 The extended version In parallel Cyberlab has also developed an extension to the standard version This new solution opens up for easy integration of CORBA and RMI IIP solutions This will give greater flexibility for alternative solutions of the Lab Server SW In addition a very nice feature with this design is that all the existing Providers using the ol
80. r dir read ermission java util PropertyPermission cyberlab inifile dir read J y y write Important note e The policy file must include the IP address of the machine running the Transportation Adapter e The user dir is read by the Ta for locating the ini files e The cyberlab inifile dir property must have both read and write access This is used by the TA for the location of the ini files e On the Refirgeration Process at NTNU the policy file does only work if starting with grant instead of grant codeBase mie It is recommended that the policy file is only created or changed using the JDK tool policytool The tool can be started by writing policytool on the command line See Sun s web pages for a more detailed description Confidential 2003 06 21 Page 66 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 13 Access Control This section describes one of the possible access control schemes to be applied for Lab Users booking time slots and running the Labs connected to the Cyberlab System 13 1 Password encryption algorithms The SUN s Java crypter classes of the JCE package are only running up from Java 1 3 Some of the providers are using Java 1 1 and we will therefore use a small a small crypter package Crypto This package will also work for Java 1 0 The Crypto package
81. r versions are known to work properly e All software which is a part of the Provider s Lab Server Confidential 2003 06 21 Page 23 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 5 5 Connecting to Cyberlab Communication Server The Cyberlab Communication Server currently running at all times Please make an appointment with a Cyberlab Administrator in order to run some tests and verify the communication between your Lab Server and Cyberlab Please also refer to the following sections describing methods and configuration files needed when connection the Lab to www cyberlab org Confidential 2003 06 21 Page 24 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 6 The Cyberlab Provider Interface Methods 6 1 Introduction This chapter describes how Providers can use software provided by Cyberlab to connect a new Lab and Lab Server to the CCS at the Cyberlab System 6 2 General requirements e The Lab Server must be able to use Java or one of the other languages supported by the various interfaces Currently Java and C is supported for the standard middleware solition and Java C and VB for the extended middleware solution This does not necessarily mean that the whole Lab Server must be implemented in for example Java but it must be able to communicate with a J
82. right 1999 2001 Cyberlab Org AS Ce d Cyberlab Org AS E mail Tor Eikaas cyberlab org Telephone Mobile Test lab E Mail gislee itk ntnu no Telephone Mobile c Copyright 1999 2001 Cyberlab Org AS Figure 18 Questionnaire and Tech support from the Cyberlab Information Applet In case of problems the user can get some links to both administrative and technical help via the Tech support part of the applet This is shown to the right in Figure 18 The Lab Users are also encouraged to rate the lab and the Cyberlab System after they have run the lab This information is important feedback for both the ESP and the Lab owner In addition potential Customers can use statistics about the individual labs in order to select the best ones most reliable best functionality etc 14 2 Integrating the Cyberlab Information Window with the Provider SW Please contact Cyberlab in order to get details on how to integrate the Cyberlab Information Window with the Provider SW Confidential 2003 06 21 Page 70 of 70
83. rovider to the Cyberlab Server 18 If login is accepted the Lab application is started and operation is made available for the user and the Cyberlab Status Window is launched on the User s computer Confidential 2003 06 21 Page 68 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 14 Run time information to Lab Users 14 1 General When a Lab User is trying to log into a lab and when he is running some experimentation on a lab is sometimes a need for additional information to be displayed for the Lab User This can for example be general information about the current session he has booked status information from the Lab help information request for user feedback etc In order to improve the total quality of the system of both the Cyberlab Portal and the Lab application Cyberlab has developed a Cyberlab Information Applet that can be configured for each individual lab Typical information displayed in the prototype version of the applet is given in the two following figures below CY3e7LAz CYSEWLAZ Username Tor Ivar Eikaas Username Tor Ivar Eikaas Laboratory state Online Laboratory state Online y Lab available for experiments User logged in Booked starting time 14 00 AN Time remaining 00 56 EE EE Your next booking is at 2002 06 06 16 00 00 0 CH Copyright 1999 2001 Cyberlab Org AS CH Copyright 199
84. rvision Lab supervision Support services reporting etc Handling of disputes e Lab interface sw e Specifications and sw supporting a wide range of lab server sw solutions e Support and maintenance services for new and existing lab Providers Confidential 2003 06 21 Page 10 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 2 2 The Cyberlab Portal The Cyberlab Portal provides differentiated user access The main user categories are Visitors Users and Customers Provider Admins Cyberlab Admin Some main characteristics of the Portal are e The Portal can display live status data retrieved from the Lab Server via the Cyberlab Communication Server Information regarding the individual labs is provided via some unified Lab presentation pages e The Provider Admins can edit information regarding their labs via dedicated templates The Provider Admins do some online configuration regarding access modes and access restrictions for their own labs Address http www cyberlab org frames php Current labs Status Provider Description Head box laboratory experiment Refrigeration process Industry style refrigeration cycle process lab with control engineering experiments Head box gp D NTNU Cybernetics Lab Browsi ng The Inverted Pendulum Balance the inverted pendulum Dont let it hit
85. s the actual status information from the laboratory The status String MUST start with either RUNNING ONLINE OFFLINE UNKNOWN The status should be followed by a textual description e g OFFLINE Under Confidential 2003 06 21 Page 25 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 Method initiated by Cyberlab Description maintenance Returns Returns the status string followed by a description getSupportedMethods Method that returns the methods supported by the Lab Server Returns Returns the methods represented as a String or ERROR followed by an error description getVersion identifier Returns a description of the current SW version for the specified SW components at the Lab Server Arguments identifier TA Transportation Adapter AA Application Adapter ES Experiment Server All All available SW components Parameters identifier The identifier for the specified SW components Returns the SW version s represented as a String or ERROR followed by an error description updateAccessControlList accessList Method that updates the access control list the bookings from the Cyberlab DB Cyberlab Server sends a list of accepted upcoming sessions for the specific lab Format Alternative 1 default configuration username password starttime enadtime priority
86. ter java com cyberlab dummyProvider java com cyberlab socketCommunication java filenamesDummyProvider manifestForDummyProvider compileDummyProvider bat createJarForDummyProvider bat Files for JavaDoc e All java files specified above for a detailed list of all required files see the file filenamesDummyProvider com cyberlab package html com cyberlab applicationAdapter package html com cyberlab dummyProvider package html com cyberlab socketCommunication package html createJavaDocForAll bat Note Creates JavaDoc not only for DummyProvider but for all classes and packages 11 3 Generating DummyProvider jar DummyProvider jar is a JAR file which holds all classes and images needed to run DummyProvider Confidential 2003 06 21 Page 58 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 The file is generated using the script createJarForDummyProvider bat Note that e All necessary files must be compiled for example with compileDummyProvider bat before the JAR can be generated e all the file names of the classes needed for DummyProvider are listed in the file filenamesDummyProvider e the file manifestForDummyProvider is used to define the main class which should be executed in the JAR file See Sun s web pages for more information on how JAR files are created and used 11 4 Configure DummyProvider I
87. to Cyberlab when getExperimentId is called The ID is the same as the Laboratory name on the Cyberlab Web The syntax is Experiment_Id lt lab name gt The following IDs lt lab name gt should be used by the ReLAX partners riment_Id Refrigeration cycle process riment_Id Head box riment_Id The Inverted Pendulum riment_Id The Electrical Drive riment_Id Optical Tracking System Hea ee x Os TOO HO For testing the following IDs can be used riment_Id DummyLabRUB riment_Id DummyLabEPFL riment_Id DummyLabNTNU fe x OX IO IO TO dummy experiment To be replaced by the Provider Experiment_Id DummyLab123 Description of the current SW version for the specified SW components TA_VERSION TransportationAdapter Version AA_Version ApplicationAdapter Version ES_Version ExperimentServer Version Name of the file used by the Provider to store the upcomming sessions sent from the Cyberlab Communication Server Filename ProviderSessionFile txt The syntax of the INI file is simple All lines starting with are comments All empty lines are ignored All other lines have a property name equals sign and the value of the property Note that the last line must be
88. value Sets a numerical or boolean value for the Lab The identifier is Provider specific Parameters identifier The identifier of the value to read e g variable name value The new value to set to the variable Boolean is represented as 0 0 false and all other numbers true Returns the value that was set if successful or ERROR followed by an error description resetExperiment Resets the Lab by setting it to a predefined and ready safe Returns OK if successful or ERROR followed by an error description Note It is strongly reccomended to implement this method connectionlsLost Method that gets called when the connection to the Cyberlab Communication Server is lost Parameters reason The reason for the break in communication Returns OK or ERROR followed by an error description throwOutUser sessionld Throws out a user from controlling or observing the experiment not used Confidential 2003 06 21 Page 27 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 Method initiated by Cyberlab Description Parameters sessionId The session ID to identify the user to throw out Returns OK if successful or ERROR followed by an error description throwOutAllUsers Throws out all users from controlling or observing the Lab not used Returns OK if successful or
89. when communicating with the experiment software default is 5688 or the value in CLProvider ini Command line arguments override any settings in the INI file CLProvider ini 11 7 Classes and Interfaces provided by Cyberlab Cyberlab provides the TA the AA and the interfaces Experimentinterface and CyberlabIinterface for the Provider to use The source files can be found at filesForProviders com and precompiled versions can be found in filesForProviders ApplicationAdapter jar The files can be compile into the Lab Server or simply put in the classpath 11 7 1 Interface com cyberlab Experimentinterface This is the interface that defines all the method calls which the Cyberlab Server can call on an Lab Server See the JavaDoc for a more detailed description of the public interface Experimentinterface interface and its methods The Provider must create a class that implements ExperimentInterface The class must be instantiated before any communication with the Cyberlab Server is started and calls to the object are calls from the Cyberlab Server For example as done with DummyProvider a class named CallbackClass can be created like this package something import com cyberlab Experimentinterface Confidential 2003 06 21 Page 61 of 70 Connecting Remotely Operable Labs to the Cyberlab Network UM 013 01 Introduction Cyberlab Org Revision 1 0 public class CallbackClass implements Experim
90. y methods 7 1 1 getStatus 7 1 1 1 The method public java lang String getStatus This method is compulsory and is called by the Cyberlab Communication Server The Lab Server returns the actual status information about the laboratory Parameters no parameters Return value The Lab Server returns the status information in a String The format of the status information String is lt Status gt lt status description gt The legal values for lt status gt are defined in the table below The purpose of lt status description gt is to provide some additional information underpinning the lt status gt The content of lt status description gt is Provider and Lab dependent but some suggestions and guidelines are given below lt Note gt The lt status gt must be one of the legal ones defined in the table below Table 4 Legal values for the status field in getStatus lt status gt Description RUNNING This means that somebody has logged into the lab and is running the lab doing some experimentation on it The lt status description gt should give more information like remote Cyberlab usage local usage ONLINE The lab is available for remote access A person with a valid username and password can log into the lab The lt status description gt should give more information like Ready for remote access OFFLINE The lab is not available for remote access The lt status description gt should g

User Manual

Contents

Download Pdf Manuals

Related Search

Related Contents