On the use of Java to make Software Tools Accessible on ... - CiteSeerX

On the use of Java to make Software Tools Accessible on the Web Antonio Pulia to1, Orazio Tomarchio1, Kishor S. Trivedi2 , Lorenzo Vita1 1

Istituto di Informatica e Telecomunicazioni, Universita di Catania Viale A. Doria 6, 95025 Catania - Italy E-mail:fap, tomarchio, [email protected] 2

Department of Electrical Engineering, Duke University Durham, NC 27708-0291 - USA E-mail: [email protected]

Abstract Although the Web makes a large amount of information easy to access for a great number of users, it does not oer simple mechanisms to facilitate the use of a computation-oriented application on the Internet. The Java language developed by Sun Microsystems makes the development of such applications easier. In this paper we show how this technology can be used for creating a network computing platform for the Web sharing of applications which were not speci cally devised for network use. The platform developed is also equipped with adequate security mechanisms which provide authentication services and, if required, encryption. The approach proposed has been applied to porting the Sharpe software package for performance, dependability and performability analysis of computer and communication systems onto the Web. A similar approach has been adopted in developing the tool WebSPN for the analysis of non-Markovian Stochastic Petri Nets. Keywords:

Network Computing, Java, Web, Security

1 Introduction The increasing development of distributed computing, along with the growing computational power of desktop systems, has led to the adoption of distributed computing models based on a number of computers interconnected in a network. Consequently, the client/server model has become widespread: powerful servers, when applied to by clients with limited calculating power, carry out complex processing operations. The recent development of the Internet has partly altered this computational model, not least due to the relative simplicity with which connections can be set up with remote geographical 1

locations to access data and information in any part of the world [15]. In the last few years there has been a real boom in the Internet phenomenon: its rapid spread has provided a large number of users, many of whom are not exactly experts in using new computing tools, with access to this world-wide communications network (commonly known as the Web [3]). Although the Web has made a large amount of information easy to access for a great number of users, it does not oer any simple mechanisms to facilitate the use of a compute-intensive application on the Internet. Currently either remote connections are used (telnet), which require character interfaces as well as the need for access to the server, or there are proprietary solutions which, although ecient, preclude the use of heterogeneous architectures, thus wasting previous economic investments. Aware of such limitations, the IETF Web Distributed Authoring and Versioning working group (WebDAV) recently started to identify a set of functionalities to support distributed authoring and versioning on the Web. WebDAV is expected to specify a set of extensions to the existing HTTP standard for remote loading, editing, saving of dierent media types on the Web [11]. Java, a new language developed by Sun Microsystems, has features that make it ideal for the development of network applications [1, 6]. With Java, we can write applications (applets) that can be directly inserted onto Web pages and can be sent to the user's browser simply by a click of the mouse and then executed using local computing resources. This speci c feature of Java has not only made possible to create Web pages containing animation and sound and other features which were previously impossible, thus making the world of the Web more pleasant; its potential goes far beyond such simple use [12]. In this paper we show how it is possible to use this technology to create a network computing platform for the Web sharing of applications which were not speci cally devised for network use. The aim is to allow access to an application from any node connected with the Internet as long as it possesses a Java-enabled Web browser. To regulate the use of applications inserted into the network, making them available only to authorized users, the platform is also equipped with adequate security mechanisms based on public and private key algorithms, which provide authentication services. In this way only users with appropriate rights can access and use the applications in question. As a speci c case, the approach proposed was used to port the Sharpe tool (Symbolic Hierarchical Automated Reliability/Performance Evaluator) onto the Web [10]. Sharpe is a well-known tool for the speci cation and evaluation of models of dependability, performance and performability originally endowed with a purely textual interface and devised for use on stand-alone machines. Using the mechanisms provided by the platform developed, it has been possible to make Sharpe accessible on the Internet by means of a Java-enabled Web browser. The new application, called GISharpe [8] (Graphical Interface Sharpe), has been provided with a graphical interface which considerably simpli es the model speci cation phase. We also show how the same approach has been followed to develop WebSPN from scratch; this is a new tool for the analytical evaluation of non-Markovian Stochastic Petri Nets [2]. The rest of the paper is organized as follows: in Section 2 we describe how the proposed architecture works, including the security mechanisms; we also list a series of possible applications in which the platform would be particularly useful. In Section 3 we will describe the approach followed in the development of GISharpe and WebSPN; we present some implementation notes, also 2

regarding the strength and the weakness of using Java. Section 4 shows the advantages achieved by using the tools both from inside and outside our Faculty. Finally we present our conclusions in Section 5.

2 Network computing on the Web using Java When the attempt is made to use the client/server model, which is commonly used at a local level, on the Internet it is necessary to take into account the dierent features of the environment and the varying user requirements. The Internet oers practically world-wide coverage, but does not have any mechanism for bandwidth sharing which can ensure users of a predetermined quality of service. The throughput oered, the delays and transmission errors vary considerably and are mostly unpredictable. In addition, in such a vast environment there is a wide range of hardware and software platforms, unlike a local environment where equipment is usually uniform. Users, however, want to be able to fully exploit the services oered by communication networks. Besides the immediate wish to communicate with each other, they want to access the data they need wherever it is and whatever format it is in. Also increasingly evident is the need for simple, safe use of the applications present on the Internet without having to possess speci c hardware and software architectures. This requirement renders calculating system open, i.e., capable of operating along with other systems, thus protecting previous nancial investments. As far as the last point is concerned, the aim of this paper is to de ne certain mechanisms which will allow a generic user connected to the Internet to use the services of an application present on a server, however distant it is, regardless of the type of architecture the client has. If we consider the current applications available on the Internet today, we can see that the only real multiplatform application is the Web. But with the Web, as mentioned previously, it is not possible to execute applications at a distance; it is a means for the retrieval and viewing of information held on the various Internet servers. The introduction of CGI [9] (Common Gateway Interface) and HTML forms has extended this use. In fact, when a Web server receives the content of an HTML form, it invokes the program indicated in the URL, using the CGI protocols to pass it the user parameters. In this mechanism, the Web server acts transparently between the Web client and the back-end program which performs the actual computations. But the applications which this approach can be applied to, are limited to the ones with no graphical interfaces. Input parameters can only be textual ones, because the only mechanism to provide them is through a HTML form. Due to this fact, remote databases access has been the eld in which CGI interaction has gained more success. The Java language [1] however, has greatly changed the basically static way of using the Web. Its capabilities have paved the way to new distributed and interactive application accessible through the Web [6, 12] . We used the Java technology to develop a network computing platform which is based on the following points: 

granting a generic user to access possibly complex compute-oriented applications through the Web; 3



making applications not originally devised for network use easy to use in a distributed environment, and endowing them with a simple graphic interface;



regulating access to the applications by appropriate security mechanisms;



elimination of problems relating to the installation, con guration and maintenance of software.

The approach taken can be seen as an extension of the client/server programming paradigm. The client, in fact, (1) processes locally the request to send to the server, who (2) executes it at a dierent time, at the end of which (3) it noti es the client of the results of the calculation. Unlike the classical approach, however, the client does not need to possess any speci c software; through a simple Web interface it loads the software using the mechanisms provided by Java. The immediate advantage is thus the simplicity of access to the application and the total absence of a preliminary phase to distribute and install the software interface. During the connection with the server the client loads the software required for the graphic interface, as well as the modules necessary for future communication sessions. The application provider can then update the application, modifying the interface as he likes, without having to provide potential clients with updated versions of the software. The user, in turn, has the certainty of being able to use the latest version of the software he is interested in, and can also count on optimal installation and an execution speed that is not always possible with his own computing resources. This aspect is not insigni cant, since it is often one of the limiting factors in the spread of complex applications which require sophisticated hardware that the end user does not always possess. As the proposed approach entrusts the server with execution of the application, the task of correctly sizing it belongs to the service provider. Appropriate security mechanisms therefore have to be developed to regulate access and allow only licensed users to use the applications. Lastly, the immediate retrievability on the Web ensures the complete availability of applications that otherwise would probably remain known only to a limited number of potential users. In this sense, an immediate use for the platform proposed would be in teaching, to allow students easy, economic access to applications which can support normal lessons. Server

Client Web browser

Web server

Application

Java Virtual Machine

User Interface (Java applet)

Java-enabled

Communication and server management

Figure 1: Software modules needed on the client and server Fig. 1 illustrates the software modules needed on the client and server for the network computing platform proposed to function correctly. As we can seen, the only requirement for the client is a Java-enabled Web browser. The server, on the other hand, needs the following software modules: 

Web server; 4



Java Virtual Machine;



Application to be made available on the network;



Java applet of the user interface;



Software module to run the communication session with the client.

The last module, entirely developed in Java, actually comprises two submodules. One of these in particular is transferred onto the client when the latter forwards a request for access to the server and provides the client with the mechanisms needed to run the communication sessions just started. The second submodule, on the other hand, is always in execution on the server and deals with accepting requests from various clients, robustly managing the various connections with clients, and sending clients the results put out by the server. It also keeps a memory of the correspondence between clients and the applications they use. To describe the functioning of the technique proposed in greater detail, we refer to Fig. 2, which is a scheme of the various phases of interaction between client and server. CLIENT

SERVER http request

Web browser html page

Web server

Web browser applet request

click on applet link the applet begins its execution

applet bytecode

Web server

the user works with the interface calculus request Java wrapper

the application executes

Java wrapper

results the user gets the results

Figure 2: Interaction between client and server Through his Web browser, the client loads the Java applet to view and run the graphic interface with which to formulate the request to be sent to the server. The user can thus specify his request using his own computing resources. When this phase ends, the request is transmitted to the server, possibly after conversion into a format accepted by the speci c software, which is then executed on the data provided by the user. The entire request for computing is now shifted to the server, while 5

the client waits for the processing results. At the end of this phase the server sends the client the processed data. The presence of security mechanisms, if any, involves an extension of the rst phase of the communication protocol to check the real identity of the user. Further details of how to implement a security service will be given in the following section. At this point we should point out some dierences between the technique described above and the normal use of Java applets. In our architecture the classical approach of Java applets is in a sense turned upside down. An applet is, in fact, an application written in Java which can be executed through Web locally on a client provided with a Java enabled browser. Once it is transferred to a client, applet execution is entirely local without any interaction with the server. Conversely, in our case the applet is only the interface with a much more complex and computationally onerous application which is executed on a remote machine. In addition, the computational part of the application is not written in Java (in the most general cases); on the contrary, to oer better performance it often greatly depends on the machine on which it is executed. The CGI approach is not helpful in our case, because we need a complex graphical interface on the client side which HTML forms cannot provide. With regards of communication mechanisms, we decide to implement our own communication protocol using plain Java sockets. Since the communication between the client part and the server is quite simple, we didn't use other higher-level mechanisms of communication. RMI [14], for example, is a powerful mechanism to create distributed applications in Java, hiding many tedious aspects of network programming. However, RMI was designed to transparently call methods belonging to remote Java objects located anywhere in the network. In our case, the application which we want provide Internet access, is not composed of a set of distributed objects, and it is implemented in a dierent language than Java. Besides, using plain sockets we don't add any overhead to the communication process.

2.1 Security and Access Control The development of a platform for network sharing of applications requires the design of suitable security mechanisms. Two kind of problems should be solved on client and server side. On the client side, the user wants a reliable way to check where a piece of software is really coming from, who has created it and whether it has been changed through the network by some intruder. The user wants to know the kind of actions that the code he downloaded from the network will execute on his machine, in order to evaluate the risk level associated with its execution. On the server side we want to control users' accesses in such a way to deny access to unknown or not authorized users and to monitor users which are using the tool (for statistical or accounting purposes). Security techniques based on public and private keys can be applied to solve this kind of problems [13]. The rst versions of Java did not include such authentication mechanisms. The security model in JDK 1.0.2 version follows the so called sandbox model [5]: untrusted code received from the network (such as applets) runs in a restricted environment and it has not full access to 6

local system resources (e.g. the le system). This way, Java designers wanted to provide the users with a certain level of safety in execution of remote applets. But, in some cases, this mechanism was too restrictive; the impossibility of reading and writing les was the greatest limitation from our point of view. Common Web browser in fact, adopted a simple security policy: they deny any reading or writing operation from local le system, preventing any possible dangerous action on the client. Using the appletviewer instead, the user could set some properties to give to applets rights of reading and writing in a prede ned directory of local le system; we found this possibility not reliable on all platform, and potentially dangerous because the user cannot assign dierent rights to distinct applets. Some new security features were added in JDK 1.1 to solve this kind of problems: applet signing [5]. Software developers can digitally sign the applet using their private key. Users viewing and executing the applet can verify the signature on it, using the public key of the applet author: then he can decide to accept the applet as trusted. Once an applet is trusted, it can run with full rights of execution, as it was local code. Using this model, users can selectively give trust to some applet and deny to some others. Besides, users can be sure of the applet integrity: in fact, they can detect if it has been modi ed or damaged through the network. The JDK contains the necessary tools and API for code signing, including support for digital signatures, message digest and certi cate manipulation. This enabled us to satisfy all security needs on the client side. Unfortunately the security APIs so far described are available only using the appletviewer provided with the Sun JDK : common Web browsers such as Netscape Communicator or MS Internet Explorer support dierent kinds of security API. Due to this incompatibility among dierent security model, we had to integrate some dierent technologies to satisfy the requirements on the server side. In particular, we set up a Web server with SSL [4] functionalities in order to keep con dential some informations owing on the net. To use the solution engine of our tools (which run on the server), a user is asked to register through a registration form on the Web site. The server associates to the user a digital ID which will send to him. This registration phase is managed through a SSL connection to the Web server; data owing in the network are crypted, so that nobody else can read them. Successively, when the user launch the applet execution, it has to present this digital ID to our server in order to access to full capabilities of the application. This way, on the server we are able to give rights of execution on our server to regularly registered users, monitoring at the same time users who are currently running the application. As an educational institution, we don't ask users to pay for using our services; however, a private organization could use these mechanisms in order to make users pay according to the use of the service. A user who has not registered, can obviously download the applet and execute it, but he cannot use the computational part of the application. In fact, he has no rights to execute anything on the server without explicit authorization. However, he can fully use the graphical interface in order to evaluate the capabilities of the application.

7

2.2 Fields of Application The range of applications to which the technique described can be applied is rather large; the greatest advantages, as far as performance is concerned, are, however, obtained with applications in which interaction is for some limited, concentrated periods of time. In such applications (without user-friendly interfaces) we often need to prepare a script with the operations to be performed, which are then sent to the application in a batch mode. Today, for using an application of this kind on a network, we need to start up an interactive session (e.g. telnet), which frequently causes a slowingdown due to network congestion, and of course the user has to possess a login to access the remote machine. With the approach proposed here we can detach the work performed on the client from the calculations made by the server. This way the network will not be involved as long as the user executes operations on the graphical interface, which is executed locally on the client. The range of application on which this approach could obtain best performance does not, however, constitute a limitation, as many compute-oriented applications possess this feature. These applications, some of which were not originally conceived of for network use, can now be eciently used with an access mode familiar to most users working with Web on the Internet, irrespective of the dierent hw/sw architectures they use. An immediate application proposed consists of simplifying access to applications in what is commonly called the Intranet, i.e. a subnetwork belonging to an organization. In this environment some applications frequently have to be used by dierent users; the technique described thus allows client costs to be reduced in terms of both hw/sw material and maintenance costs. The requirements for running a Java application, in fact, are now accessible to any desktop and, following the proposed approach, we can eliminate all the problems connected with keeping dierent con gurations and version for each user, just updating the software on the server. The main advantage of adopting this technique, however, lies in the fact that an organization with geographically distributed branches can continue to use the same working model, with the consequent economic advantages. Another eld of application for the technique proposed is linked to software distribution and maintenance. Let us assume that a user wants to purchase an application but rst wants to test its functionality. If the application is organized according to our model, with the graphical interface running on a generic client, the software distributor may deny access to the server functionalities until the user purchases the software license. However, the user will really be able to test the product, evaluating the capabilities of the application in exam. When he decides to purchase the application, he doesn't have to make other complex installation procedure; he simply obtains the rights to use server functionalities which fully enable him to use the application. The end user does not have any problems of managing and optimizing the software involved. He may not be aware, and probably does not need to be, of whether the machine with the role of server is a pool of processors or several machines connected together to make the service more reliable. These problems are taken into consideration and solved by the Java application on the server which converses with the applet on the client. Another eld in which the technique may be useful is distance learning. In an university, students who want to work at home do not usually have the opportunity to use the same computational 8

tools as they are available on the workstations in the university laboratories. Exploiting the services made available by the platform described, we could provide students with Internet access to a whole range of applications to support normal teaching. In section 4 we will show how we use the implemented tools in our Faculty.

3 Applications: GISharpe and WebSPN The technique proposed has been applied to port Sharpe (Symbolic Hierarchical Automated Reliability/Performance Evaluator), a tool for the modelling and analytical evaluation of systems, onto the Web [10]. The Sharpe package provides a speci cation language and a wide variety of ecient algorithms for analyzing various kinds of dependability, performance and performability models. Sharpe is a modeler's design aid in that it provides alternative tunable algorithms and a exible mechanism for combining dierent modeling techniques. Using Sharpe, one can specify and analyze the following model types separately or in combination: fault trees, reliability block diagrams, reliability graphs, product-form queuing networks, series-parallel acyclic directed graphs, Markov and semi-Markov chains and generalized stochastic Petri nets. Users are allowed to deal with the problems caused by large and/or ill-conditioned models by choosing the best solution algorithm and by combining possibly heterogeneous models. Although the models that Sharpe can solve lend themselves well to graphic representation, there is no graphic tool to specify these models. A system model is speci ed in a text le containing the type of model used, the topology, the properties of each single component, the links between the various components, etc. The le also speci es the measures of interest. It is fed into Sharpe which, when the resolution is reached, puts out the desired results in another le. This kind of application clearly falls into the category mentioned previously, as during the creation of the model no interaction is necessary with the program making the calculations. The only interaction required is when the le containing the description of the model to be solved is sent, and then at the end when, having solved the model, Sharpe returns the results. The aim was therefore to adopt the network computing platform developed to make Sharpe easily accessible through the Web and endow it with a graphical interface which, structured as a Java applet, can be executed locally on the user machine. The graphical interface constructed allows the system to be speci ed graphically by combining graphic elements depending on the model to be used, and then this representation is translated into a text format which follows the speci cation syntax used in Sharpe. The main GISharpe display, shown in Fig. 3, has the following four zones: 1) a Menu panel, 2) a Control Panel, 3) a Design area, 4) a Status panel. The Menu oers the usual choices - besides the submenus File and Edit there is also Models, through which the user chooses the type of model he is interested in. Once the model has been selected, a further menu is displayed with items which allow the user to select the graphic elements to be used in the speci cation phase. More immediate use of the graphic functions is provided by a series of push buttons on the left hand side of the display which summarize the main graphic 9

Figure 3: Main display of GISharpe functions on the menu. The control panel can be used to activate a series of functions to create, load and save a model; there are also the classical cut, copy and paste functions and others to activate resolution of the model and manage hierarchical models. The design area is where the user provides a description of the model in graphic terms and connecting links between them. Signi cant graphic symbols and the associated dialogue boxes are enabled for each model. Finally, the status panel gives run-time indications regarding the status of the interface, signalling the occurrence of any event that may be of interest to the user. During the model speci cation phase, a user can specify the properties of model elements using appropriate dialog box (Fig. 4a). Once the model speci cation phase is completed, the user passes to the analysis stage simply by pressing the Analyze key which opens a dialogue box in which the user speci es the evaluation indices he wants (Fig. 4b). Pressing the Ok button the graphic representation is converted into text format using the Sharpe speci cation syntax, and a request is made on the server where the management module supplied by the platform begins execution of a new Sharpe instance. Once the processing is completed, the results are transmitted to the client and displayed in a dialogue box like the one shown in Fig. 4c. This is the end of a typical session using the tool; having viewed the results, the user can decide to continue to analyze the system by modifying certain parameters or rede ning the model. GISharpe can be accessed at the following Web address: http://sun195.iit.unict.it/gisharpe/ The approach followed in GISharpe has been used also for the creation of WebSPN [2], a tool for the analytical solution of non-Markovian Stochastic Petri Nets. WebSPN implements some algorithms that allow us to solve a wider range of SPNs, with dierent memory policies and concurrently enabled generally distributed transitions. For a detailed description of the theoretical 10

b

c

a

Figure 4: a) Editing block properties, b) Evaluation indices, c) Results. fundamentals of the algorithms for the analytical solution of the models of Petri nets supported by WebSPN, see [7]. Unlike GISharpe, in which the models were solved using an existing tool, WebSPN has been completely designed, exploiting the experience made with GISharpe. Due to problems of performance, the part regarding the solution of the models has been implemented in C. In fact, the use of Java for compute-intensive applications is a great disadvantage, due to its process of interpretation. Even if the development in JIT (Just In Time compiler) technologies has considerably improved the speed of execution of applications, Java is still inadequate for computation-oriented applications in which the typical compiled languages such as C can instead fully exploit the potentialities of the hardware. Conversely, while creating the graphical interface, we have exploited the new features of version 1.1 of Java. Thanks to the fact that several functionalities of the two tools are similar, we could use again (with little eort) various parts of code that implement the graphical interface. This has allowed us to evaluate how the object programming supported by Java can help us for re-using the code. WebSPN can be accessed at the following Web address: http://sun195.iit.unict.it/webspn/webspn2/

3.1 Implementation Notes In the previous sections we have shown the main reasons for using Java technology in the development of our applications. However, during the development phase we had to face and solve some issues due to the adoption of the Java language. The Java version available at the time of the beginning of the GISharpe development was the 1.0.2. This was the rst rather stable version of JDK, but the language was in a quite immature 11

Figure 5: WebSPN graphical interface phase of its evolution. The portability of the language worked not so ne as stated by the language designers. Particularly the graphical interface had to be tested on various machines to assure a consistent appearance. The lack of evolute tool for software development together with the poorness of graphical primitives of the AWT were also some of the greatest drawbacks in this phase. Now, the greatest diusion of Java and the release of 1.1 version have favoured the development of integrated environments for programming in Java. There are dierent visual programming environments, which are very helpful to the programmer for building graphical interfaces. Also graphical appearance on dierent environments has been improved a lot. Evolving from 1.0.2 to 1.1 version has however caused some problems. The AWT event model has been radically changed; although the old model is still supported, use of the new one is highly encouraged for its improved performance and its better object-oriented design. So, in the WebSPN project we decided to adopt this new model; the graphical interface has better performance compared to GISharpe in which we maintained the old model. Yet, the use of JDK 1.1 has some drawbacks. For example, since the main Web browser still do not fully support the 1.1 API, users have to use the appletviewer provided by Sun to run WebSPN. The introduction of advanced and sophisticated classes for the management of graphics (such as JFC by Sun or AFC by Microsoft) has made the development in Java of complex applications much easier. The disadvantage for the use of such classes is the growth in the size of the code. Since this code (if we structure the application as an applet) is transferred through the net each time a user uses the application, the use of this approach may become impossible in the Internet, even if it remains a good solution in an Intranet. In our projects we have not used any of these graphical libraries; this way, the size of the Jar le of WebSPN (which contains the whole bytecode of the applet) remained within 400KBytes (this size may be easily reached by an ordinary Web page with some images). 12

For implementing the security mechanisms described before, we needed to integrate dierent technologies. As far as the authentication of the applet on the client is concerned, we have used the mechanisms present in JDK 1.1. Conversely, we have developed appropriate mechanisms on the server for regulating the access. At the time of registration, each user receives a digital ID that will be used for connecting to and accessing our applications. This ID ows through the net and is crypted, because at the time of the user's registration a SSL connection is used.

4 Using our tools in a Real Environment In this section we show the use of the tools presented, both at the University of Catania and by ordinary users connected to the Internet. The availability of the tools on the Web and the absence of software installations in local clients, has allowed the experimentation of such tools by a wide range of users, who could not have been reached through the traditional channels of distribution of the software. Nowadays the access to the applications is completely free, quite for allowing the widest diusion. The feedback we received from users allowed us a constant update and improvement of the features of the applications. With reference to the internal use of the tools, they have been tested and actively used by the students of some courses of the faculty of Engineering. Our solution has allowed us to solve some of the practical problems we faced when we made students use the modelling tools presented in the course. The main issue is the incompatibility between the working environments available to the students and the ones needed for running the applications for the analytical solution of the models. In fact, the engines for the analytical solution run in servers using Unix-like operating systems, while the laboratories available to the students are equipped with PCs whose operating system is MS Windows. For accessing the tools, we needed to give an account to each student, and this would have caused several problems. On the other hand, we wanted to provide the applications with adequate graphical interfaces. The development of graphical interfaces in Unix environment would have allowed the use of such tools through the X-Window protocol. However, as well as the issues linked to the graphical programming in X-Window, this protocol would not have allowed us to distribute the load on the various clients. In fact, managing various X-Window connections on one server might be too expensive. Besides, the load generated by the net would have certainly been higher than the one generated by the solution we carried out, and we could not have used the tools eectively through the Internet. The proposed solution has solved such problems, and has also given other bene ts. First of all, we can access the applications from any type of machine: only the presence of a Java interpreter (which today is available for any type of hw/sw architecture) is needed. The release of JRE (Java Runtime Environment) by Sun also allows us not to install the whole JDK in the various machines. Thus each user does not need to have an account in the Unix server where the solution engines of the models are running. The on-line registration procedure allows us to monitor the use of the tool. Besides, as soon as the main Web browsers fully support the API of version 1.1 of Java, we will be able to use them for accessing our applications, thus reducing software installation on the 13

client. Maintenance operations are much simpler, since there are no dierent software installations. In fact, the latest version of the software will always be present in the server. All this will be completely transparent to users. In fact, they will not need to take care of problems regarding the con guration or the installation of software. Besides, they will continue to work using environments they are familiar with. We realized that some delay can be experienced when downloading the applet. Frequent users may not be happy with this unpredictable delay. Furthermore, it would represent a cost for users (like students connecting from home) who access the Internet through a modem. This is why after the registration phase, the user is oered the opportunity to locally store the bytecode of the applet. During the whole phase of construction and speci cation of the model (this phase requires a considerable amount of time) he does not need to access the net. Only when he wants to solve the model, a connection to our server will be established. This way users are not limited by the lower amount of bandwidth available with telephone connections and modems and the overall access to the tool is much faster and more eective.

5 Conclusions In this paper we have presented a technique for access to remote applications through Web-based interfaces, adapting the classical client/server model to a heterogeneous geographical network environment like the Internet. To do so we used the Java development environment, with which a network computing platform has been implemented to enable use of applications which were not necessarily designed for use in a distributed environment. Great care has been taken to de ne authentication mechanisms, so as to reserve use of the applications to authorized users. The platform developed has been used to port Sharpe, a tool for system performance modelling and analysis, onto the Web. It has also been used to develop WebSPN, a new application for the analytical resolution of Petri nets. The implementation has shown the advantages of using Java in software development. The use of an object-oriented language facilitated modular design of the program and allowed parallel development in several modules. The libraries supplied for network communications also simpli ed the development in the modules relating to the management of connections between client and server. The bene ts of adopting this model of organizing an application have been evaluated, by showing the real use of the developed tools both at the University of Catania and by ordinary users connected to the Internet.

References [1] K. Arnold and J. Gosling. The Java Programming Language. Addison-Wesley, May 1996. [2] A. Bobbio, A. Pulia to, M. Scarpa, and M. Telek. WebSPN: A WEB-accessible Petri Net Tool. In 1998 Int. Conf. on Web-Based Modeling and Simulation, San Diego, CA, January 1998. 14

[3] T. Berners Lee et al. The World Wide Web. Communications of the ACM, 37(8), August 1994. [4] A.O. Freier, P. Karlton, and P.C. Kocher. The SSL Protocol - Version 3.0. Netscape Communications Corp., Internet Draft, December 1995. [5] Li Gong. Java Security: Present and Near Future. IEEE Micro, 17(3):14{19, May 1997. [6] M. A. Hamilton. Java and the shift to Net-centric Computing. IEEE Computer, 29(8):31{39, August 1996. [7] A. Horvath, A. Pulia to, M. Scarpa, and M. Telek. A discrete-time approach to the analysis of non-Markovian Petri nets. Technical report, University of Catania, 1998. [8] A. Pulia to, O. Tomarchio, and L. Vita. Porting Sharpe on the Web: Design and Implementation of a network computing platform using JAVA. In Proceedings of TOOL'97, Saint Malo, France, June 1997. [9] D.R.T. Robinson. The WWW Common Gateway Interface - version 1.1. IETF Internet Draft, February 1996. [10] R. A. Sahner, K. S. Trivedi, and A. Pulia to. Performance and Reliability Analysis of Computer Systems. Kluwer Academic Publishers, November 1995. [11] J. Slein, F. Vitali, E. Whitehead, U.C. Irvine, and D. Durand. Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web. RFC 2291, February 1998. [12] K. Srinivas, V. Jagannathan, Y.V.R. Reddy, and R. Karinthi. Java and Beyond: Executable Content. IEEE Computer, 30(6):49{52, June 1997. [13] W. Stalling. Network and Internetwork Security Principles and Practice. Prentice Hall, 1995. [14] A. Wollrath, J. Waldo, and R. Riggs. Java-Centric Distributed Computing. IEEE Micro, 17(3):44{53, June 1997. [15] E. Yourdon. Java, the Web, and Software Development. IEEE Computer, 29(8):25{30, August 1996.

15