In Chapter I seven distinct areas of work were identified as being parts of the task of creating a Web-based interface to a remote robot: the Web user interface design, how to accept robot service requests, data storage, communication with the robot, scheduling, feedback from the robot and displaying the results. The success of the division of work into these seven areas is now examined.
The division of the work into individual parts could be evaluated as a success if each module could be examined on its own and developed almost completely separately from the others. The interfaces between the modules would be the exception – some coordination between the development of modules which communicate with each other is necessary in order to agree on the format of that communication. Six of the seven areas of work did fit this description and were designed and implemented mostly separately from the others. These were web interface design, data storage, communication with the robot, scheduling, feedback and displaying the results. The other area – accepting robot service requests strongly depended on two others – Web user interface design and data storage – and required special attention.
1.1 Dependencies Of Accepting Robot Service Requests
The problem with the area of accepting service requests is that the implementation of the dialogue between the system and user for defining a service request is highly dependant on the capabilities of the Web user interface. In 2002, before facilities such as AJAX (Paulson 2005) were widely used, the available options for creating a dialogue
with the user in order to construct a complex request were limited to a page based question and answer session, unless a Java or Flash applet was developed for it. However, doing so was not feasible, since the availability of Java or Flash interpreters in the user's browser could not be guaranteed, and even if available, compatibility issues between versions would need to be addressed.
The second challenge for accepting a service request from the user was how to structure the data in such a way that it could be processed, transmitted to the robot and executed. This issue strays into the area of data storage, since as much as it should not, the data storage method eventually affects what format data can be in. The data format used was the table model – one row of data in a table to represent one real object to the system, such as a single request. This imposes limits, for example: Using the table model, each row of data in the table must have the same number of fields, since the set of columns for the whole table is defined once for that table. This and other methods of operation set out by the RDBMS guided the request and job format towards the current design. This is not necessarily a negative point – the design worked well and generated a flexible and capable system, however, other radically different and interesting possibilities for the design of the request and job objects might exist if the straitjacket of a RDBMS were removed.
1.2 Independent Areas Of Work
The other six areas of work did not depend as strongly on each other and different solutions could have been produced for each while maintaining working interfaces between the modules.
The design of the Web user interface is influenced by the capabilities of the server hardware, Web server software, HTTP protocol, server-side Web scripting language and HTML. Whilst obviously having to serve content appropriate for a robotic telescope
interface, and provide the necessary functions to use the robot, the design of the Web user interface is otherwise not influenced or restricted by any of the other areas of work. A content management system could have been used, a fully Flash or Java implementation could have been created. The solution chosen in this case was a bespoke Web application implemented using the PHP language. While any of these solutions could have been chosen, this thesis argues that a bespoke Web application – although creating more programmer work initially – allows for the most flexible and capable resulting system, not bounded by the limitations of a pre-existing framework solution or CMS.
The solution chosen for the storage of data is a clearly defined separate component of the system, as a relational database was used. RDBMS servers are designed to be stand- alone software components which handle the implementation of exactly how data is managed, stored, indexed, searched and accessed entirely internally. As RDBMS servers are stand-alone processes, any access to the data stored passes through an API layer. It is in the database's vendor or provider's best interests to make the API available to as many client languages as possible in order to grow the customer or user base – this results in the ability to make use of relational databases from many programming languages. This is highly useful and desirable for a project such as the interface to a telescope robot since it enables different software systems to access the same dynamic data set in similar ways. The Web application, maintenance scripts, scheduler simulator and image processing programs all have equal access to any of the stored data. Without this cross- language access to the same data ability, integration of the C++ compiled scheduler simulator results into the Web application would not be possible. It is hoped that the data storage implementation is somewhat future-proofed because of the clearly defined separation between application and data storage. Even if new Web languages or
techniques became available and were implemented, provided that a database API for those systems existed, they would also be able to access the dynamic data set in the same way.
The design adopted for the telescope Web interface included the rule that the Web application itself would not directly communicate with the robot because it cannot be guaranteed that the communications link with the robot will work at all times. It is unacceptable from a user interaction perspective for users to wait for page loads that may never execute correctly due to an outage in the robot communications link. As such, all Web application to robot communication was implemented using background software programs. This was made possible by the use of a RDBMS – any updates to the dynamic data set made by users through the Web interface are stored in the RDBMS. Background software programs independent of the Web application can regularly check the data set for updates requiring communication with the robot, and then perform that communication. The freedom to implement the communications system as a background process created many possibilities for implementation solutions which did not depend on any more components in the system. Any programming language which could interact with the relational database and use network communication could have been used to implement the robot communication system. This in turn meant that any framework based on any language capable of these requirements could also have been used.
In a similar way as the communication system can be considered a separate module, robot scheduling can be viewed as an individual problem. One of the requirements of the robot control software was that if there were eligible jobs waiting for service, one of those jobs should be ready to be given to the robot at any time with no processing delay, i.e. the scheduler should know which is the next job before the robot requires it. How
the scheduler made this possible was a matter internal to the scheduler. It was decided that the scheduler would run periodically, regardless of the state of the rest of the robot control software. This could have been implemented as an integrated part of the robot control software or as an external program. Since all job data at the robot is stored in a relational database just as with the Web application, any programming language and software capable of communicating with a relational database could have been used to perform the scheduling task. In this case the scheduler was integrated with the robot control software, but still as an independent module within that software.
Considering the robot feedback system as an individual system is not as straight forward. The data collection is dependent on where the data is generated, and how it can be extracted from various software systems. Displaying the collected data on the Web site is dependent on the Web technologies available. However, a large part of the work involved with moving real-time data from the robot to viewing users is done in-between these end-points; storage and transmission of the data is internal to the module. Although the real-time data system depends on particular methods of capture and display of information, it can still be considered a separate area of work, since bespoke systems were designed and implemented which aimed to perfectly match the systems they depended on. Apart from the most minimal of extra programming code to expose various data to the real-time data system, the rest of the robot control software was unmodified.
Again, apart from depending on Web technologies, displaying the results from the robot can be considered an individual module in the system. The robot communication system ensured that the image files were transferred to the Web interface computer well before any user would normally want to view them. Any sufficiently capable Web technology could have been used to allow users to inspect their results.