WebClass: Software to web-enable MATLAB for collaborative use

WebClass: Software to web-enable MATLAB for collaborative use

Advances in Engineering Software 36 (2005) 497–503 www.elsevier.com/locate/advengsoft WebClass: Software to web-enable MATLAB for collaborative use L...

338KB Sizes 1 Downloads 66 Views

Advances in Engineering Software 36 (2005) 497–503 www.elsevier.com/locate/advengsoft

WebClass: Software to web-enable MATLAB for collaborative use L. Petropoulakis*, B. Stephen Department of Electronic and Electrical Engineering, University of Strathclyde, 50 George Street, Glasgow G1 1QE, Scotland, UK Received 5 August 2004; accepted 17 February 2005 Available online 21 April 2005

Abstract The paper describes the work carried out in Strathclyde University to web-enable MATLAB, a commonly used package in engineering applications, for Internet-based distance co-working and collaboration with full sharing functionality by all users and at all times. The software was developed with platform-independence in mind and has undergone several updates. Additional software to enhance functionality is still being developed and integrated into the original system. The paper provides an overview of the development known as WebClass. q 2005 Elsevier Ltd. All rights reserved. Keywords: Collaboration; Engineering software; MATLAB; Distance co-working

1. Introduction The work described here is part of a larger project1 to develop a series of software to assist collaborative engineering working and distance learning studies. The work undertaken within the context of WebClass is directed towards MATLAB,2 since this is an industry standard package for engineering simulations. Early inspiration for the project was from efforts to use the Internet for distance tele-operation as described in [3]. The original intention was to use WebClass for training purposes and for collaborative use over Internet connections so as to enable users to share MATLAB through web browsers. However, WebClass is a forerunner to a more general suite of software, currently under development, which will web-enable practically all software applications. It is perhaps interesting to note at this point that although MATLAB’s own web server permits Internet access to * Corresponding author. Tel.: C44 141 548 2935; fax: C44 141 548 4203. E-mail address: [email protected] (L. Petropoulakis). 1 WebClass was developed as part of the WebEng project (www.webeng. org) and funded by the Scottish Higher Educational Funding Council (SHEFC). 2 A simulation package produced by MathWorks, Inc. (www.mathworks. com).

0965-9978/$ - see front matter q 2005 Elsevier Ltd. All rights reserved. doi:10.1016/j.advengsoft.2005.02.006

users, this is only available on a single-user basis. This is totally unsuitable for collaboration, training or supervised distance learning. The intention of the WebClass development was to address these issues. This entailed that consideration had to be given to the following challenges: (a) Creating an environment where the same copy of MATLAB could be shared simultaneously by several users over Internet connections in a consistent and easy to use way. (b) Ensuring that the user–MATLAB interface remained unchanged so as to eliminate the need for learning a new interface. (c) Minimising the latency arising due to Internet congestion or due to low bandwidth connections. (d) Providing total platform-independence for the development since MATLAB is available on several computer platforms. This would also allow for cross-platform use of MATLAB without extra cost. (e) Providing a Simulink-type interface over network connections compatible with MATLAB.3 The most important challenge was the need to allow multiple sharing sessions and multiple application-sharing 3 The interface is also compatible with Octave [10], a freely distributed GNU product resembling early MATLAB versions, available for Unix, Linux and Windows. It does not support a Simulink-type GUI and graphics’ support is poor.

498

L. Petropoulakis, B. Stephen / Advances in Engineering Software 36 (2005) 497–503

for each user. The motivation for this feature came from our experience that, in certain cases, it is desirable to be able to monitor several simultaneous and independent MATLAB sessions and be able to switch between them at any time. For example when several users are being instructed by a single instructor, it is desirable for the instructor to be able to share each user’s MATLAB session and be able to take control of it so as to provide guidance. This implies that the instructor must have the ability to observe all running sessions and actively participate in any of them independently from the others. The WebClass software was designed to meet these requirements, thus providing a useful tool for distance tutoring, for classroom teaching and project coordination.

2. Background and the basic collaboration concept The concept of sharing legacy applications such as MATLAB implies that the application executes on just one computer and several remotely located users can provide inputs to the application and view outputs from it in realtime. Usually only one copy of the software is required; it is thus shared by all users who, normally, take turns to control the application. Programs such as NetMeeting and Virtual Network Computing (VNC) are capable of providing this capability but with major drawbacks: (a) What is offered by these programs is not application sharing but screen sharing. To do so requires that the same program (e.g. NetMeeting) runs on all sharing computers and this may cause compatibility issues if cross-platform operation computers are used. Since MATLAB runs on several operating platforms, such programs do not usually provide optimal solutions. (b) Even if cross-platform compatibility issues could be resolved with such approaches, our aim was to minimise time-consuming graphic transmissions over Internet connections so as to guarantee a fast response at all times. Screen sharing systems default to screen dumps and therefore fail to satisfy this requirement. (c) Screen sharing programs owing to their design only allow one sharing connection per user. Thus, although there can be multiple connections (one per user) to a single shared session using programs like VNC, users cannot, in general, participate in multiple, independent concurrently running sharing sessions. Moreover, under Microsoft Windows operating systems screen sharing implies occasionally surrendering control of mouse and keyboard on the server to other connected users. Hence, the requirement for multiple independent sharing sessions by all users and at all times could not be satisfied through the use of screen sharing programs.

a browser interface, since this would minimise the need to learn yet another interface. As there are many different browsers available, browser-independence was also desirable. To meet these objectives a Java-based development was considered as the best solution. Minimising transmission of information through the Internet was also an important consideration which has influenced the overall design. The details of this part of the development are dealt with in Section 4. WebClass [6,8] is mostly written in Java4 and it is conceptually shown in Fig. 1. Users (restricted to two in Fig. 1 for clarity) are considered to be clients and must connect to the server, through standard TCP/IP connections to use and share the software. The process (with reference made to Fig. 1) is described next. A Java Server Application (JSA) runs continuously on the server (here a Sun workstation) ‘listening’ for connections. A user (User1) connects to the server by pointing a browser at the server web page containing the JSA. The ensuing execution produces a page—displayed on the browser of User1—and a login dialog (Fig. 2) requiring user name, password and status (e.g. Student/Tutor/Supervisor/Trainee, etc.). A selection of all available programs for sharing is also made at this time. After login, the designated application starts on the server. In Fig. 2, the user indicates that a new copy of MATLAB is to start. The first user starting an application (User1) usually has full control of the application as though the application was running on this user’s computer. ActiveUser and Administrator objects associated with User1 are created in the server as shown (Fig. 1). When User2 connects to the server to share with User1, a similar login process appears. User2 is able to view a list of all the applications available for sharing and also which applications are shared and who is the controlling user in each case. Several independent sharing sessions can co-exist—each instantiated by a different user. User2 needs to indicate the user with whom he/she wishes to share (here User1) by inserting the name in the relevant section of the login script. A connection is then created and users can share the application. The difference in this case is that a PassiveUser object handles the connection with User2. Unlike an ActiveUser, a PassiveUser does not ‘own’ a copy of the shared application. PassiveUsers receive information from ActiveUsers and the shared application, but cannot interact with the application in any way except to log out or to save graphs. The Administrator object (Fig. 1) contains a dynamic lookup table of all users ‘looking on’ to the session started by an ActiveUser. User names enable the server to propagate the commands issued and also the responses 4

In designing WebClass we considered that operation over Internet connections would be best served through

A version of an early system is available at www.webeng.org, by emailing us your request. (Attention must be paid to MATLAB’s licensing conditions if you intend to use our software with this application.)

L. Petropoulakis, B. Stephen / Advances in Engineering Software 36 (2005) 497–503

499

Browser Netscape Client 2

Administrator

Java Layer

Client 2

Native Layer

User-Client 2: PC running IRIX

Passive User

TCP/IP Connections

Browser I.E. Client 1

Active User Shared MATLAB

Java Applet

Java Applet

Java Layer

Client 1

Native Layer

SERVER

Server: Sun Solaris running Unix

User-Client 1: PC running Windows Fig. 1. The sharing concept.

obtained from MATLAB as a result of these commands. Any commands typed in the client browser are executed in the server and the results are returned to the browsers for viewing. It must be noted that graphics are not transmitted over Internet connections. Commands to create graphs are sent, together with all data, to clients. Graphs are built at the client as described in Section 4. As in Standard MATLAB the system can handle both console commands and batch files.

3. Cross-session sharing and additional system modes The basic sharing features described in Section 2 permit a number of additional system modes such as supervisory and supervised modes as well as complex cross-platform and cross-session simultaneous sharing modes. These modes allow use of MATLAB for the purpose of active teaching, tutoring, project development, synergistic design or distance learning.

Fig. 2. A typical login process.

500

L. Petropoulakis, B. Stephen / Advances in Engineering Software 36 (2005) 497–503

Group A User 3 User 1

User 4

User 2

User 5

Matlab Server 2

Matlab Server 1

User 6

Group B

Instructor

Fig. 3. Sharing modes.

The key features to providing additional modes are: (a) The ability of the software to allow PassiveUsers to become ActiveUsers and vice-versa at any time without without loss of data or delays, and (b) The ability of the development to support simultaneous and independent sharing sessions for all users and at all times. Fig. 3 illustrates a series of possible scenarios which the software can support simultaneously. MATLAB Server_1 executes a single copy of MATLAB shared by a group of users (Group A). Within this group User_1 is an ActiveUser the other two users have passive roles. MATLAB Server_2 executes two entirely independent instances of MATLAB. One of these is shared by two users in Group B, the other is a single use of a MATLAB session by User_4. All of these sessions can be viewed by another user, in this case an Instructor user. The instructor can point a browser to any of these sessions and view and/or assume control of the session as explained in Section 2. Alternatively, the instructor may choose to use separate browser instances to maintain permanent and separate sharing connections to any of these

MATLAB sessions. Hence, an instructor may quietly observe activities of users, or groups of users, and has the ability to assume control of any process individually. Meanwhile, users within a group may control the shared process as illustrated in Section 2. The software also allows for more complex situations to occur. For example, it is entirely possible for any user in Fig. 3 to connect and share another MATLAB session at the same time. This can be done quite independently of other group users. The combinations are unlimited and restricted only by hardware limitations or licensing issues. History logs of user activity can be available and instructors have the capability to supervise large numbers of trainee users and attend to each one in turn. A typical case is presented in Fig. 4 where double-clicking the highlighted name on the list of names on the left-hand side of the window enables tutors to take control of the corresponding user session. In case of distant collaboration, the system allows one ActiveUser per MATLAB copy, but an infinite number of PassiveUsers. An ActiveUser can be alerted to the fact that a PassiveUser is seeking control of the software and he/she can surrender control when agreed. WebClass allows privileged users (e.g. tutors or supervisors) to participate in multiple sharing sessions and monitor

Fig. 4. Controlling several users.

L. Petropoulakis, B. Stephen / Advances in Engineering Software 36 (2005) 497–503

several users or groups. Switching between multiple sessions is merely a case of switching between browsers or pointing the browser to different connection points. WebClass is totally agent-based along the lines described in [7]. The meaning of an agent, as applied to this development, is described in [2,4]. To improve communications between agents we also introduced several extensions to KQML [1], but these are beyond the scope of this paper. 4. The WebClass graphic user interface (WGUI) MATLAB’s current solution of operating on Internet connections is to convert output to html and transmit the information to the clients. In the context of transmitting graphics over web connections, we feel that this is wasteful, inappropriate for low bandwidth connections and generally unnecessary. For this reason, and also in order to accommodate the Octave development whose graphics facilities were rather poor, we developed a plotting system which is client-based. In this way, graphs are plotted at the client side at a rate which the client can handle, whilst the commands and information of what needs to be plotted is transferred over the Internet in textual form. This is fast and efficient for distant communications, and allows for easy compression if required. It also ensures operation in lower bandwidth situations and frees bandwidth for other multimedia (e.g. sound). The graphic interface is compatible with MATLAB and Octave and an example of complex plot is shown in Fig. 5.

501

Once generated, graphs may be rotated or otherwise manipulated in 3D. Zooming facilities also exist and there is provision for animations and movies. Currently, the WebClass GUI (WGUI) system is available for Windows, Unix, Linux systems. Apart from the ability to plot graphics locally, WGUI also enables a Simulink-type GUI. Simulink sharing over Internet connections implies heavy transmission of graphics. Once again the MathWorks solution is unnecessary as it imposes a lot of work on the server and relies on fast Internet connections which cannot be guaranteed. Worse still, every time a new plot is needed a conversion of the whole graph from scratch into html must be carried out and sent through the Internet. Our solution, briefly described here, requires the use of our existing client-based WGUI and a Java-based Simulink-type workspace known as J-SIM. J-SIM operates on client-side, requiring that all clients have a copy installed in their computer as well as a copy of WGUI. Much like Simulink, J-SIM uses blocks, each containing a mathematical function, and through drag and drop actions creates simulations in a workspace. The blocks can be linked, as in Simulink, to provide complex simulations. As simulations are developed, the commands required to build the blocks are propagated as textual descriptions on all client machines and the graphs showing the process are built on each client. Hence, all participating users are able to view the progress. The ActiveUser has full control when to start, pause and stop this information propagation. During simulation, only the commands pertaining to the next stage of the development need be

Fig. 5. The WGUI plotting facilities.

502

L. Petropoulakis, B. Stephen / Advances in Engineering Software 36 (2005) 497–503

transmitted. In this way transmission of information over network connections is minimised, whilst a progressive approach can be used (useful when instructing users how to build and use simulations). Each block generated by J-SIM contains its own mathematical formula and uses MATLAB as its mathematical engine. MATLAB must therefore exist on a designated server (locally or remotely located). Mathematical functions are interpreted by MATLAB at each stage of the simulation and results are propagated to the next block until the simulation is completed. All J-SIM clients sharing a simulation receive the same information and view the same outputs and generated graphs. J-SIM enables users to switch their roles as active and passive users in much in the same way as described for WebClass. A typical illustration depicting a two-user sharing session is shown in Fig. 6. It should be noted that the ActiveUser has all the toolboxes available whilst the PassiveUser does not. If control of the application is switched, then the toolboxes will also switch. J-SIM is under development and it is only being mentioned here for completion. The WebClass and J-SIM software developments were influenced by concepts of distributed software design as described in [9] by ideas and experiences of software for engineering education outlined in [5]. 5. Technical differences, requirements and use of WebClass WebClass is not a screen sharing system such as NetMeeting, VNC, or Webex. These systems use a variety

of techniques to detect screen changes and transmit them to clients including Dynamic Link Library (DLL) hooks and polling (both used traditionally by VNC) or even mirror device drivers. Hooks can have unpredictable effects whilst polling consumes large CPU resources and decreases overall refresh rate. Mirror video drivers are more efficient and they operate by capturing the information sent to video displays and transmitting it to clients—VNC has also adopted this method in very recent releases using drivers donated by DemoForge (www.demoforge.com). Even video drivers, however, require considerable resources and traffic over connections is still substantial. Another drawback of screen sharing which particularly affects Microsoft Windows operating systems is surrendering mouse and keyboard control at the server to other connected users. Although in general this does not present a problem when participating in a sharing session, it implies that a server cannot be used to facilitate a sharing session for other connected users whilst still allowing the user at the server to do something else (such as sending an email). This, in our experience, can be useful in some student–tutor sharing sessions where students collaborate on a project using a tutor’s computer as a server, whilst the tutor is there to offer advice and supervise when needed. WebClass, not being a screen sharing system, has none of these drawbacks. To use WebClass a MATLAB installation is required at the server and Java-enabled web browsers at the clients together with the WGUI plotting facilities. By design WebClass can start several different instances of MATAB—all on the same server if necessary—each instance being shared by different sets of users (Fig. 3

Fig. 6. J-SIM platform and browser independent.

L. Petropoulakis, B. Stephen / Advances in Engineering Software 36 (2005) 497–503

illustrates such an environment). As already explained, the server–client information exchange is in textual mode and therefore very efficient requiring little server or client resources. There are no known limitations to WebClass’s ability to support any number of users at anyone time and therefore the system is deemed to be quite scalable. Some tests to verify this have been carried out but not to a scale sufficient to provide conclusive evidence. Communications with the server are through standard http ports and therefore not affected by soft firewalls. Even in extreme cases, in very security conscious environments, where only port 80 is available to facilitate external connections, WebClass is still operational. In this case, however, WebClass will have to compete with all other traffic through the port and this may cause substantial delays. WebClass was developed for use mostly within academic and related environments and therefore security issues are more relaxed than could otherwise have been. This is true both for the server–client communications and the way users login and use the system. In the former case additional encryption–decryption algorithms can be implemented but are not envisaged in the foreseeable future. In the latter case access to sharing is effected though a two-level stage: (a) users must have a valid account in the computer(s) using WebClass and (b) users must have registered with the WebClass Administrator process on the server before any connections can occur. At present, users can register as ‘tutors’, ‘supervisors’ or ‘users’ (their status can be verified with departmental records). Tutors and supervisors have privileged access and total control of all WebClass functions. Users with a ‘student’ status only have access to what privileged users make available to them. One important consideration when using WebClass with MATLAB is that users are required to have a MATLAB web license. This is because of the MATLAB licensing agreement which requires a web license whenever MATLAB is used over web connections. This restriction does not apply to Octave. Web Class is currently under review with a more advanced and elaborate system under development. For this reason all downloads and support has stopped from the WebClass website to enable the development team to focus solely on the current development. It is unclear as yet how the University intends to license and distribute WebClass in future. 6. Conclusions We have developed and tested a system which, through the use of simple browsers, allows users to access MATLAB applications via Internet connections for collaborative use. The system can be used in classroom environments and also for distance learning and co-working. This development operates across various computer platforms such as UNIX, Linux, Windows, etc.

503

Our development targets engineering applications and it aims to ease difficulties associated with the large requirements imposed on bandwidth use, the need for providing suitable explanations on difficult design issues, and the general lack of suitable software to provide convenient collaborative interactions. We believe that, when fully developed, this prototype will be of potential value in general collaborative engineering environments heavily involved in using MATLAB. From the technical viewpoint, WebClass still has not been tested rigorously. However, we remain confident that, transmitting textual information only provides a substantial improvement on MATLAB’s current approach of indiscriminate transmission of all data over Internet connections. Further we believe that, although general purpose screen sharing systems have started to become more sophisticated, the current requirement they have on computer resources and the inconvenience of ‘being locked’ into single sharing sessions make them unsuitable for general purpose educational activities such as tutoring, training and overseeing large numbers of users engaged in different collaborative projects. Acknowledgements The authors would like to acknowledge the contribution of the Scottish Educational Funding Council (SHEFC) for their support of this work. References [1] Finin T, Labrou Y, Mayfield J. KQML as an agent communication language. In: Bradshaw J, editor. Software agents. Cambridge: MIT Press; 1997. [2] Genesereth MR, Ketchpel SP. Software agents. Commun ACM 1994; 37(7):48–53. [3] Goldeberg K, Mascha M, Gentner S, Rothenberg N. Desktop teleoperation via the world wide web. Proceedings of IEEE international conference on robotics and automation, Nagoya, Aichi, Japan, 1995. p. 654–9. [4] Jennings N, Wooldridge M. Software agents. IEE Rev 1996;January: 17–20. [5] Paaso J. Telematics for high-tech engineering education: from computer based teaching to telematic learning in software engineering. Proceedings of the EAEEIE 96 conference, June 12–14, Oulu, Finland, 1996. p. 107–15,. [6] Petropoulakis L, Mc Arthur S, Mc Donald J. Agent-controlled Internet tools for computer-based distance training in industry and education. Int J Contin Eng Educ Life-Long Learn 2002;12:267–77. [7] Petropoulakis L, Stephen B. Sharing CAD and simulation applications over Internet connections. Proceedings of 4th international workshop on computer science and information techonology (CSIT), September 18–20, Rio, Patras, Greece, 2002. p. 326–37. [8] Petropoulakis L, Stephen B. Resource sharing software for distance learning in engineering education. Int J Eng Educ 2003;19(3):371–8. [9] Shuey RL, Spooner DL, Frider O. The architecture of distributed computer systems. Reading, MA: Addison Wesley; 1997, ISBN: 0201-55332-5. [10] Eaton J, Baier, T, Berry K. GNU Octave; 1988 (http://www.octave.org).