FEATURE
.
Java can be used to create a
INCREASING APPLICATION ACCESSIBILITY THROUGH JAVA
network computing platform that lets users share applications not specifically devised for the Web. The authors used one such platform to port an existing tool and develop a new application.
70
JULY • AUGUST 1998
http://computer.org/internet/
A NTONIO P ULIAFITO , O RAZIO T OMARCHIO , AND L ORENZO V ITA University of Catania K ISHOR S. T RIVEDI Duke University
A
lthough the Web has made a variety of information easy to access for many users, it still does not offer any simple way to use standalone applications, particularly those that are computationally intensive. Remote connections, such as in a telnet, require character interfaces as well as access to the server. Proprietary solutions, while efficient, are costly because developers cannot use heterogeneous architectures. These limitations have prompted the IETF Web Distributed Authoring and Versioning working group to identify a set of functions to support distributed authoring and versioning on the Web. The goal of this group, called WebDAV, is to specify extensions to the existing HTTP standard for remotely loading, editing, and saving different media types on the Web.1 HTML forms and the Common Gateway Interface protocols have made it easier to retrieve and view information on Internet servers. 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 on user parameters. In this mechanism, the Web server acts transparently between the Web client and the backend program that performs the actual computations. This approach has a major limitation, however. It is suitable only for applications with no graphical interfaces. Input parameters must be textual because the only way to provide them is through an HTML form. Because of this limitation, CGI interaction has gained more success in remote database access. Java has begun to open up new possibilities for accessing applications on the Web. With Java, developers can write applications as applets and insert them into Web pages. The user can then retrieve and execute them with local computing resources. This feature has made it possible, for
1089 -7801/ 9 8 /$10.00 ©1998 IEEE
IEEE INTERNET COMPUTING
.
I
N
C
R
E
A
S
I
N
G
A
C
C
E
S
S
I
B
I
L
I
T
Y
example, to add aniClient Server mation and sound Web server Application to Web pages. We Java-enabled believe, however, Web browser Communication and server manager that the true potenUser interface Java Virtual Machine (Java applet) tial of this Java feature lies beyond its current simple use.2 In this article, we show how devel- Figure 1. Software modules needed on the client and server. The client, which represents the user opers can use this requesting the application, needs only a Java-enabled Web browser. The burden of maintaining the feature to create a application rests solely on the application developer (server). network computing platform that lets Web users share applications not specifically devised the local machine. As the figure shows, the only for network use, including those that are computa- requirement for the client is a Java-enabled Web tionally intensive. At present, these applications typ- browser. The server, on the other hand, needs five ically have no user-friendly interface. Users must software modules: prepare a script with the operations to be performed, which they then send to the application in ■ The Web server is a standard HTTP server that a batch mode, via an interactive session (which is replies to the requests issued by the clients; frequently slow because the network is congested), ■ The Java virtual machine is the Java execution and log on to the remote machine. With our environment, which provides the language approach, the network is not involved as long as the interpreter and the runtime environment; user executes operations on the graphical interface, ■ The application is the code to be made available which is executed locally on the client. Only when on the network; users require some computational response from the ■ The Java applet implements the user interface; server do they need to access it. Access is straightand forward; authorized users can access the application ■ The communication and server manager runs the from any node connected with the Internet as long communication session with the client. as they have a Java-enabled Web browser. We have used one such platform in two appli- The fifth module, developed entirely in Java, comcations. The first is a port of Sharpe (Symbolic Hier- prises two submodules. Submodule 1, which is archical Automated Reliability/Performance Evalu- transferred to the client when it forwards a request ator),3,4 a well-known tool for specifying and for server access, provides the mechanisms needed evaluating dependability and performance models. to run the communication sessions. Submodule 2, Sharpe was designed with a purely textual interface which is always executing on the server, deals with and used only on stand-alone machines. With accepting requests from various clients, robustly GISharpe (Graphical Interface Sharpe),5 users work managing the various connections, and sending with a graphical representation of the model during clients the results from the server. Submodule 2 also model specification, which simplifies their task. keeps a memory of the correspondence between When they have finished specifying the model, they clients and the applications they use. access Sharpe via the Internet using a Java-enabled Web browser. In the second application, we used Client-Server Interaction the platform to develop WebSPN (Web-based Sto- Figure 2 shows the interaction between client and chastic Petri Net tool), a tool for analytically evalu- server. Because the client loads the software ating non-Markovian stochastic Petri nets.6 required for the graphical interface, as well as the modules necessary for future communication sesPLATFORM ELEMENTS sions, the application providers are free to update Figure 1 shows the modules needed for the client the application and modify the interface however and server in our platform. We essentially use the they like without providing updates to potential classic client-server paradigm, except that the client clients. Users, in turn, know that they are downdoes not need to install any specific software on loading the latest version of the software and can
IEEE INTERNET COMPUTING
http://computer.org/internet/
JULY • AUGUST 1998
71
.
F
E
A
T
U
R
E
count on an optimal installation and execution process that is not always possible with their own computing resources. This advantage is significant because complex applications have typically required that users have sophisticated hardware, which they didn’t always have. Furthermore, because applications can be retrieved immediately on the Web, more users are likely to try them. Differences from Traditional Java Use As Figure 2 shows, our approach in a sense is the converse of how Java applets are traditionally used. In the accepted use, an applet is an application written in Java that can be executed through the Web locally on a client with a Java-enabled browser. Once the applet transfers to a client, it is executed entirely locally without server interaction. In our approach, the applet is only the interface to a much more com-
Client
Server
Web browser a
Web server
b
Web server
Web browser Click on applet link Applet begins its execution User works with the interface c Java wrapper Application executes
User gets results
d
Java wrapper
Figure 2. Interaction between the client and server. (a) The user accesses the Web page of the application. (b) Through a Web browser, the user (client) loads the Java applet to view and run the graphical interface. Users can execute the interface using their own computing resources. (c) The request is transmitted to the server, possibly after conversion into a format accepted by the specific software, which then executes on the data the user provides. The entire request for computing now shifts to the server while the client waits for the results. (d) The server sends the client the processed data.
72
JULY • AUGUST 1998
http://computer.org/internet/
plex and computationally onerous application whose computational part is not written in Java in most cases. Indeed, to offer better performance, application developers can write the computational part in any language to improve the execution speed. The traditional CGI approach is not helpful here because the client side needs a complex graphical interface— something the HTML forms cannot provide. Our communication mechanisms also depart from tradition. Rather than using higher level mechanisms like RMI,7 we implemented our own communication protocol using plain Java sockets, since the communication between the client and server is quite simple. RMI was designed to transparently call methods that belong to remote Java objects located anywhere in the network. In our case, however, the application we want to provide Internet access to does not constitute a set of distributed objects, nor is it implemented in Java. Also, by using plain sockets, we don’t add any overhead to the communication process. Security and Access Control Of course, for the platform to be practical, there must be some degree of access control. This requires solving two problems. On the client side, the user must be able to check where a piece of software is really coming from, who has created it, and whether some intruder has changed it. Users also want to know how the code they download will execute on their machine so that they can evaluate the associated risks (if any) to the machine. On the server side, the application developer must be able to deny access to unauthorized users and to monitor authorized users for, say, statistical or accounting reasons. Security techniques based on public and private keys can solve both problems.8 In JDK 1.1, a security feature, applet signing,9 lets developers digitally sign the applet using their private key. Users viewing and executing the applet can verify the signature using the public key of the applet author. They can then decide whether to accept the applet as trusted. Once an applet is trusted, it can run with full execution rights, as if it were local code. Using this model, users can selectively give trust to some applets and deny trust to others. They can also detect if the applet has been modified or damaged through the network. JDK 1.1 contained all the necessary tools and the API for code signing—support for digital signatures, message digesting, and certificate manipulation—for us to satisfy all security needs on the client side. To solve the server-side problem, we
IEEE INTERNET COMPUTING
.
I
needed additional work. Unfortunately, the JDK 1.1 security tools and the API are supported only by the JDK 1.1 applet viewer. Common Web browsers such as Netscape Communicator or Microsoft’s Internet Explorer support different kinds of security APIs. Consequently, we had to set up a Web server with SSL10 functionalities to keep some information confidential. In our solution, the server asks users to register through a form on the Web site. The server assigns each user a digital ID and sends it to them. Because this registration phase is managed through an SSL connection to the Web server, the registration data flowing through the network is encrypted. Each time a user launches the interface applet’s execution, they must present the digital ID to the server to access the application’s full capabilities. In the GISharpe and WebSPN applications, this lets us give execution rights to regularly registered users, and monitor users who are running the application. We don’t ask users to pay for our services, but a private organization could use these mechanisms to ensure that users compensate for the services they use. An unregistered user can thus download the applet and execute it, but cannot access the computational part of the application. In fact, users have no rights to execute anything on the server without explicit authorization. However, they can fully employ the graphical interface to evaluate the application’s capabilities.
GISHARPE Sharpe provides a specification language and a variety of efficient algorithms for analyzing dependability, performance, and performability models. It supports design in that it aids modelers in selecting among tunable algorithms and provides a way to combine modeling techniques. Sharpe users can specify and analyze 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.4 Although the models lend themselves well to graphical representation, Sharpe requires the user to specify the system model in a text file containing the type of model used, the topology, the properties of each component, the links between the various components, and so on. When the user inputs the file, which also specifies the user’s measures of interest, Sharpe solves the model and outputs the results in another text file. Users can experiment with different combinations of solutions,
IEEE INTERNET COMPUTING
N
C
R
E
A
S
I
N
G
A
C
C
E
S
S
I
B
I
L
I
T
Y
which is particularly beneficial for complex or poorly defined models. This kind of application clearly falls into the category of applications that could be accessed over the Web using our platform. To create the model, the user need not interact with the program that makes the calculations. User interaction is required only twice: when the file containing the model description is sent and at the end when Sharpe returns the results. Our goals in creating GISharpe were to make Sharpe easily accessible through the Web and give it a graphical interface that the user could execute locally as a Java applet.
Sharpe provides efficient algorithms for analyzing models. GISharpe makes them accessible through the Web.
The interface we constructed lets the user specify the system graphically by combining graphical elements according to the model to be used. GISharpe then translates this representation into a text format that follows the specification syntax used in Sharpe. The main GISharpe display has four zones: ■
■
■
■
Menu panel. The user can choose from submenus File, Edit, and Models. Once the user selects a model, GISharpe displays another menu from which the user selects the graphical elements to be used in specification. The user can also click on a series of buttons for more immediate use of the menu’s graphical functions. Control panel. The user can activate a series of functions to create, load, and save a model, as well as select among the classical cut, copy, and paste functions. There are also functions to start solving a model and to manage hierarchical models. Design area. The user provides a description of the model in graphical terms, specifying the links that connect model parts. GISharpe enables significant graphical symbols and associated dialog boxes for each model. Status panel. Through this panel, GISharpe gives the interface’s runtime status, signaling the occurrence of any event the user may find interesting.
http://computer.org/internet/
JULY • AUGUST 1998
73
.
F
E
A
T
U
R
E
solve a wide range of stochastic Petri nets with different memory policies and concurrently enabled, generally distributed transitions.11 Unlike GISharpe, in which we worked around an existing tool, we designed WebSPN completely from scratch. Because of performance problems, we used C to implement the part of WebSPN that solves models. In fact, we found that using Java for computationally intensive applications is a great disadvantage. Java is an interpreted language; that is, it is transformed into executable code at runtime. Conversely, in a comFigure 3. GISharpe interface during model specification and analysis. In the leftmost piled language such as C, the window, the user specifies model elements, which are graphically represented (not source code is transformed into shown). In the top right window, the user has entered the analysis phase and is spec- executable code before the proifying the evaluation indices desired. Finally, in the bottom right window, GISharpe gram is launched. Even though displays the processing results the server has transmitted. using JIT (Just In Time) compiler technologies has considerably improved the application’s execution speed, Java is still inadequate for computaFigure 3 shows the GISharpe interface during tionally intense applications. For this application model specification and analysis. In the leftmost class, typical compiled languages, such as C, can window, the user specifies the properties of model fully exploit the hardware’s potential. elements using appropriate dialog boxes. In this We did, however, use many of JDK 1.1’s features case, the user is specifying the failure CDF (cumuin building the graphical interface for WebSPN lative distribution function) as an input to Block (shown in Figure 4). Because several functions of C. As the screen shows, the user can select among WebSPN were similar to those in GISharpe, we were nine CDF types. Once users specify the model, able to reuse the code that implements the graphical they begin model analysis by pressing the Analyze key in the main GISharpe display. This opens a dia- interface. This gave us insight into how object prolog box (top right window) for users to specify the gramming supported by Java can help in code reuse. desired evaluation indices. In the example, the user has specified the evaluation of the CDF of the IMPLEMENTATION ISSUES model “example.” GISharpe converts the graphical During the development of both GISharpe and representation to a text format in Sharpe specifica- WebSPN, we had to overcome several challenges in tion syntax when the user clicks on OK (leftmost adopting Java, primarily in adjusting to the change screen). GISharpe then sends the specification to from JDK 1.0.2 to JDK 1.1. We have also observed the server, where the management module (sup- important benefits from both internal use at the plied by the platform) begins executing a new university and access from non university users Sharpe instance. Once the processing is complet- through the Internet. ed, the server transmits the results to the client and displays them in a dialog box (bottom right win- Challenges Overcome dow). After viewing the results, the user can decide The only Java version available when we began to continue to analyze the system by modifying cer- GISharpe development was JDK 1.0.2. Although tain parameters or redefining the model. it was the first rather stable JDK version, Java as a language was still somewhat immature and did not WEBSPN port as easily as the JDK designers led us to believe. WebSPN is a tool for analytically solving non-Mar- We had to test the graphical interface on various kovian stochastic Petri nets. Its algorithms let users machines to assure a consistent appearance. We also
74
JULY • AUGUST 1998
http://computer.org/internet/
IEEE INTERNET COMPUTING
.
I
had no sophisticated tool for software development, and the AWT (Abstract Window Toolkit graphical library) had very poor graphical primitives. JDK 1.1 has since made it easier to develop integrated Java programming environments and build graphical interfaces.12 There are also more varied visual programming environments, and the graphics’ appearance in different environments has improved considerably. We used JDK 1.1 in the development of WebSPN, but it required some adjustments. The AWT event model radically changed from version 1.0.2, and although Sun still supports the old model, they encourage using the new one because of its improved performance and better object-oriented design. Indeed, the performance of the WebSPN graphical interface is better than that of the GISharpe interface, for which we maintained the version 1.0.2 event model. But even with JDK 1.1, we needed additional support. Because the main Web browser still did not fully support the 1.1 API, users would have had to use Sun’s applet viewer to run WebSPN. The introduction of advanced and sophisticated classes for graphics management (such as Sun’s JFC or Microsoft’s AFC) has made the development of complex applications in Java much easier. The disadvantage in using such classes, however, is the growth in code size. Since this code (if we structure the application as an applet) is transferred through the net each time a user uses the application, this approach may become impossible for use on the Internet, even if it remains a good solution in an intranet. We opted not to use any of these graphical libraries in either GISharpe or WebSPN. Consequently, the Jar file of WebSPN, which contains the entire applet code, is within 400 Kbytes—a size comparable to an ordinary Web page with some images. Our last challenge was to implement our security mechanisms. As we described earlier, we had to integrate the different technologies of JDK 1.1 and SSL to authenticate the applet on the client and regulate access on the server, respectively. Benefits Observed We have used GISharpe and WebSPN internally at the University of Catania and have made it available to nonuniversity users via the Internet. For students, the tools have been particularly beneficial in resolving the incompatibility between the laboratory environment—which is equipped with PCs running Microsoft Windows—and the environ-
IEEE INTERNET COMPUTING
N
C
R
E
A
S
I
N
G
A
C
C
E
S
S
I
B
I
L
I
T
Y
ment needed to solve the models analytically, which required Unix-like operating systems. Because we needed to give each student an account to use in accessing the tools, this incompatibility would have caused problems. On the other hand, we also wanted the applications to have adequate graphical interfaces. If we developed the graphical interfaces in a Unix environment, we could use tools through the X Windows protocol, but X Windows graphical programming would not have suited our needs and we would not have been able to distribute the load among clients. In fact, managing various X Windows connections on one server might have been prohibitively expensive. The load generated by the Internet would have certainly been higher, and users would not have been able to use the tools as effectively through the Internet. Our platform has provided several direct benefits. We can access applications from any type of machine, needing only a Java interpreter. Sun’s release of JRE (Java Runtime Environment) has let us install only parts of JDK on our machines. Each user can simply register online as described earlier, instead of needing an account in the Unix server, where the calculations are being done. As the popular Web browsers begin to support version 1.1’s API, we will be able to use them to access our applications, reducing software installation on the client even further. We also believe more users have accessed the tools than would have done so through traditional software distribution channels. The feedback we have received
Figure 4. WebSPN graphical interface.
http://computer.org/internet/
JULY • AUGUST 1998
75
.
F
E
A
T
U
R
E
has allowed us to constantly update and improve the application. Another benefit is that maintenance is much simpler; because there is only one software installation, users are guaranteed the latest version. We have also been sensitive to the time required to download the applet. We realized that frequent users would not be happy with an unpredictable delay, which could also be costly for those who access the Internet through a pay-as-you-go provider. To address this, after registration, we offer
We believe more users have accessed the tools than would have done so through traditional software distribution channels.
the user the opportunity to store the applet code locally. With a local store, users need not access the Internet at any time during model construction and specification (phases that require considerable time). They connect to our server only when they are ready to solve the model.
CONCLUSIONS In addition to the application areas we have described, we see several uses for our platform. The most suitable applications are those in which user interaction occurs in limited, concentrated periods. This means that the application developer can decouple work performed on the client from the calculations made on the server. Thus, the network will not be involved as long as the user executes operations on the graphical interface. In general, computationally intensive applications fit this profile—many of which were not conceived with network use in mind. Intranets are one possible application area. Our approach could reduce client hardware, software, and maintenance costs because clients (users) could retain their familiar computing environments, regardless of how the software on the server changed. The requirements for running a Java appliURLs for this article GISharpe • sun195.iit.unict.it/~gisharpe/ WebSPN • sun195.iit.unict.it/~webspn/webspn2/
76
JULY • AUGUST 1998
http://computer.org/internet/
cation are now within reach of most desktops. The main economic advantage, however, is that organizations with geographically distributed branches can continue to use the same working model. Another possibility is software distribution and maintenance. Suppose a user wants to purchase an application but first 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 can deny access to the server functions until the user purchases the software license. However, the user will be able to test the product in a meaningful way. When the application is purchased, the distributor simply grants the rights to use server functions to make the application fully usable. Distance learning would also benefit from our approach. Students who want to work at home are not usually able to use the same computational tools available on the workstations in the university laboratories. Applications developed using our platform would give students easy, relatively inexpensive access to a range of applications that support the main lessons. ■ REFERENCES 1. J. Slein et al., “RFC 2291, Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web,” 1998; http://www.isi.edu/rfc-editor/rfc.html. 2. K. Srinivas et al., “Java and Beyond: Executable Content,” Computer, Vol. 30, No. 6, June 1997, pp. 49-52. 3. R. Sahner and K. Trivedi, “SHARPE: Symbolic Hierarchical Automated Reliability and Performance Evaluator, Introduction and Guide for Users,” tech. report, Duke University, Durham, N.C., 1992. 4. R. Sahner, K. Trivedi, and A. Puliafito, Performance and Reliability Analysis of Computer Systems, Kluwer Academic Publishers, New York, 1996. 5. A. Puliafito, O. Tomarchio, and L. Vita, “Porting Sharpe on the Web: Design and Implementation of a Network Computing Platform Using Java,” Proc. Tool 97, Lecture Notes in Computer Science, No. 1245, Springer-Verlag, Berlin, 1997, pp. 32-43. 6. A. Bobbio et al., “WebSPN: A WEB-Accessible Petri Net Tool, Int’l Conf. Web-Based Modeling and Simulation, The Society for Computer Simulation International, San Diego, CA. 1998, pp. 137-142. 7. A. Wollrath, J. Waldo, and R. Riggs, “Java-Centric Distributed Computing,” IEEE Micro, Vol. 17, No. 3, MayJune 1997, pp. 44-53. 8. W. Stalling, Network and Internetwork Security Principles and Practice, Prentice Hall, Englewood Cliffs, N.J., 1995. 9. L. Gong, “Java Security: Present and Near Future,” IEEE Micro, Vol. 17, No. 3, May-June 1997, pp. 14-19.
IEEE INTERNET COMPUTING
.
GET CONNECTED 10. A. Freier, P. Karlton, and P. Kocher, “The SSL Protocol— Version 3.0,” Netscape Comm. Corp., 1995; http://www.netscape.com/newsref/std/SSL.html. 11. A. Horvath et al., “A Discrete-Time Approach to the Analysis of Non-Markovian Petri Nets,” Tech Report CS-12, University of Catania, Catania, Italy,1998. 12. M. Hamilton, “Java and the Shift to Net-centric Computing,” Computer, Vol. 29, No. 8, Aug. 1996, pp. 31-39.
with IEEE Internet Computing
Bimonthly magazine from the IEEE Computer Society focused on Internet-based applications and enabling technologies.
Antonio Puliafito is an associate professor of computer engineering at Catania University’s Institute of Computer Science and Telecommunications. His research interests include performance and reliability modeling of parallel and distributed systems, networking, and multimedia. He received an EE from the University of Catania and a PhD in computer engineering, from the University of Palermo.
http://computer.org/internet/ Orazio Tomarchio is a PhD candidate in computer engineering at the University of Palermo. He received an MS in computer engineering from the University of Catania. His research interests include distributed systems, network computing, mobile agents, distributed object-oriented programming, and network management. Kishor S. Trivedi is a professor of electrical and computer engineering at Duke University. He also holds a joint appointment in the Department of Computer Science at Duke and is the Duke-Site Director of an NSF Industry-University Cooperative Research Center between N.C. State University and Duke University for carrying out applied research in computing and communications. His research interests are the reliability and performance assessment of computer and communication systems. Trivedi received a BTech in computer engineering from the Indian Institute of Technology, and an MS and a PhD in computer science from the University of Illinois, Urbana-Champaign. He is a codesigner of the Harp, Save, Sharpe, and SPNP modeling packages. He is a fellow of the IEEE and a Golden Core member of the IEEE Computer Society. Lorenzo Vita is a professor of computer engineering at Catania University’s Institute of Computer Science and Telecommunications. His research interests include parallel processing, distributed and parallel systems and network management. He received an EE from the University of Catania and is a member of the IEEE Computer Society.
Features
❖ Peer-reviewed research articles report the latest developments in Internet-based applications and enabling technologies ❖ Essays, interviews, and industry reports address the Internet’s impact on engineering practice and society. ❖ Columnists provide tutorials and commentary on a range of topics. ❖ A companion webzine, IC Online, supports Webunique content and links to other sites.
Subscription information
❖ Subscriptions are available in paper or electronic formats or both. ❖ Send check, money order, or credit card number to IEEE Computer Society, 10662 Los Vaqueros Circle, PO Box 3014, Los Alamitos, CA 90720-1314. ❖ $29 for full-year paper subscription ❖ $23 for full-year electronic subscription ❖ $38 for full-year paper and electronic subscription
❖ Rates apply to members of IEEE Computer Society and IEEE Communications Society. (Membership number:_______________________________) _________________________________________________ Name
_________________________________________________ Company Name
_________________________________________________ Address
Readers can contact Puliafito, Tomarchio, and Vita at University of Catania, Institute of Computer Science and Telecommunications, Viale A. Doria 6 95025 Catania Italy; {ap, tomarchio, lvita}@iit.unict.it; and Trivedi at Duke University, EE Dept., Durham, NC 27708-0291;
[email protected].
IEEE INTERNET COMPUTING
_________________________________________________ City
State
Zip Code
__________________________________________________ Country
http://computer.org/internet/
JULY • AUGUST 1998
77
