Dolphin Smalltalk Web Applets

The deployment of applications via the Internet to be executed within the confines of a web browser is becoming ever more popular. Sun's Java language and Microsoft's Active/X technology are both aimed at allowing small applications to be embedded within HTML pages and distributed over the Web. Such "applets" are capable of bringing static web pages to life, making them more interactive. Dolphin now brings this technology to the Smalltalk arena; giving you the choice of using this more flexible language for creating Web deployable applications.

Before we look at how Dolphin applets work, it may be useful to discuss how Java and Active/X achieve the same functionality. Otherwise you can go straight to find out how Dolphin meets the challenge.

Alternatively, you may just want to test out some sample applets in your web browser.

Java

Java is an architecture neutral and portable object-oriented language derived from C++. It can be used either to build applets for execution inside web browsers or applications capable of supporting themselves. Most of the excitement surrounding Java at the moment is aimed at the former ability.

Java applet classess are compiled to a compact bytecode format that is independent of any target machine and these class files are distributed across the Web alongside the HTML pages that include them. The bytecodes are then interpreted by a Java virtual machine (VM) that is (usually) built in to the client web browser. Sometimes the bytecodes are dynamically compiled at the client side to aid performance. The existence of the VM interpreter at the client side gives rise to two important features of Java:

• The VM implementation can be different for different client side hardware. This allows Java applets to execute on a wide range of target systems from Windows to Macs to Unix. It inevitably means, though, that Java applets cannot make use of useful operating system features that are not common across all target environments.
• Since all bytecode execution is in some way interpreted by the VM this allows for a secure situation in which rogue applets can be prevented from damaging the target machine. This so-called sand-box approach encourages end-user confidence in the distribution mechanism but it does significantly restrict the possibilities of what can legitimately be done by a Java applet.

Active/X

Microsoft's Active/X™ technology is not a language but a means of deploying small executable components that can be run within the confines of a client's web browser. It is derived from their OLE and COM strategy of the past few years. Usually these components are compiled from C++ source and distributed as a true executable. This gives rise to the following points:

• Because it contains target machine code the component is not portable and can only run on a client machine for which it has been built; for the moment this implies the client must be running Win32. Also, since machine code is inevitably larger than a bytecode format, this implies that download times of Active/X components may be longer.
• Active/X components are executed raw on the target machine without the safety buffer of a virtual machine to filter out rogue requests. This makes for a potential security risk but allows the applets to be much more powerful than their Java counterparts. Microsoft's answer to the security issue is to digitally sign each Active/X component so that it is possible for the client to verify that they have been received unmodified from a known and trusted supplier.
• The ability to execute Active/X components is built-in to the Microsoft Internet Explorer. Other browsers can install a plug-in to allow them to benefit from web pages with these embedded components.

Dolphin Smalltalk Applets

Dolphin Smalltalk applets are built in the standard Dolphin development environment. Indeed, with Dolphin, there is no difference between a full application and an applet. Any Presenter or View class can be taken deployed as an applet and embedded within an HTML page.

How does it work.

At the client side, a Dolphin virtual machine and base image must first be installed into the web browser as a plug-in before any pages that contain Smalltalk applets can be viewed. If the VM plug-in is not installed, it is possible to arrange for this to happen automatically when a page containing an applet is accessed.

The applet is built as normal in Dolphin. The new classes that comprise the applet (over and above the classes in the base image) are then isolated from the image and saved out in a compiled bytecode format similar to the .class files employed by Java. Each class is contained in its own bytecode file. These files are then copied to a suitable location on an HTTP web server.

To add an applet inside a web page you must use an EMBED tag like the following.

<EMBED
SRC=Applets/ScribblePresenter.stc
WIDTH=400
HEIGHT=200
>

This will embed the standard Scribble sample application in an area of 400x200 pixels in the chosen web page. The two classes (ScribblePresenter and ScribbleView) that make up the application will be downloaded automatically from the Applets directory in the web server and executed inside the plug-in VM and base image.

Note that only the classes above and beyond those installed in the base image need to be downloaded. Also, classes are only downloaded on an as required basis, so rarely used classes may not need to be accessed at all. This means that quite complex applications can be brought to life in short download times.

Issues

The Dolphin applet technology embodies advantages and disadvantages in common with Java and Active/X. For instance:

• We use a virtual machine to interpret bytecodes in much the same way as Java. This allows the files being downloaded to be kept small thus minimising download times. The base image contains around 300 useful classes that don't therefore need to be downloaded; these include the full implementation of our application framework.
• The virtual machine does not restrict the applet for security purposes in the way that Java's does. Thus, Dolphin applets can be very powerful; accessing local DLLs and files etc. Instead, we use code signing of the applet class files in the same way that Active/X components do, so that a client may verify trust in the supplier before the applet is started. On the whole, for Intranet use this security method is advantageous since the applications can be fully functional and trust in the supplier is not an issue. For general purpose Internet use it may be seen as inconvenient for everyday users to verify suppliers before viewing a web page.
• Our applets only support Win32 clients. In general this is a disadvantage compared with Java. We do, however, then have access to all the platform specific features of Windows 95 and NT.
• Dolphin applet classes are identical in every way to standard Dolphin applications. No code changes are necessary when the decision is made to deploy an application over the Web.

Intended Uses

We see the applet deployment technology being useful, in the first place, for developing Intranet solutions. In these environments, the power of a language like Smalltalk is essential, and the ability to execute unrestricted downloadable applications is a bonus for serious work. For most Intranets, the code signing and Win32 client limitations will not be an issue since the clients and providers are "known" to each other.

Use over the general Internet Web may be more restricted but as applets become more complex (rather than mere gizmos) we hope to see Dolphin being used in preference to the other two solutions; Active/X and Java.

Sample Applets

We have put together some sample applets to demonstrate this technology. You can check these out here.

More information

For more information see: Web Browser Plug-in.