Web Programming Environments: Towards a Virtual API

I.J.Palmer¹, N.Chilton² & R.A.Earnshaw²

(I.J.Palmer@comp.bradford.ac.uk, N.Chilton@bradford.ac.uk, R.A.Earnshaw@bradford.ac.uk)

Abstract

There has been an increased level of interest in programming applications specifically for the Web recently. The number of APIs for such applications is growing almost daily. Most of these APIs are targeted at particular problem domains (such as 3D graphics) or are very low-level (such as the Java environment). In this document, we perform a comparison of some Web programming environments that we have evaluated whilst searching for the most suitable API for our domain of interest, computer graphics (more specifically animation, visualization and virtual reality). What has emerged is that there is no single API that can satisfy all our needs at present, and we believe this stiuation will continue in the forseeable future.

We propose a `virtual' API that can be used to exploit specific features of lower-level APIs and bring together support for various specific features. This implies the definition and development of various generic features that the VAPI must support, and we have produced a simple example of how such features could be bound to different lower-level APIs.


1. Introduction

This document studies some existing programming environments for the World-Wide Web and makes some recommendations for future directions. It is a selective study, and brings together environments that the we have had some experience with, many of which have been considered for use for various applications. Our main interests can be grouped under the catch-all term `computer graphics', with more specific areas being visualization, animation and virtual reality. These interests have led to a bias towards programming environments that offer more extensive support to such activities (such as VRML 2.0 in its many proposed guises).

Our study attempts to put quantitative values on the features of different programming environments. This is an attempt to provide a comparison between different products to allow a reasoned choice to be made for different applications. Some of these ratings are based on preliminary readings of documentation, and so are somewhat arbitrary and open to debate and revision.

2. The programming environments studied

The environments considered during this study are mainly those with some kind of support for graphics and/or distributed processing as these are our primary interests. Some environments have been considered that do not fit our application requirements particularly well (such VisualBasic Script), and these are included merely due to the fact that they were considered as part of our initial investigation. Others that should be included (such as Obliq) absent due to our inexperience of these enviroments. The existing programming environments studied in this exercise are:
  1. Java (Sun's language plus the JDK libraries)
    Java is an object-oriented language, which together with the development libraries of the JDK provides a programming environment for Web applications.
  2. HoloWeb (Sun's proposal for VRML 2.0 that supports a simple API)
    This is a VRML proposal that uses Java as a control language for VRML 3D scenes that makes an initial attempt at distributed processing.
  3. Out of this world (Apple's VRML 2.0 proposal)
    This proposal supports multiple scripting languages to produce dynamic 3D environments and is based on Apple's QuickDraw3D graphics API.
  4. ActiveVRML (Microsoft's extension to VRML that supports functional programming)
    This (although not originally proposed as a VRML 2.0 specification) offers an extension to VRML that allows the use of functional programming techniques for controlling scenes.
  5. Moving Worlds (SGI and Sony's VRML 2.0 proposal)
    Like most VRML 2.0 proposals this aims to add multiple users and real-time interaction by extending the node set significantly. Also fields will be added to some existing nodes. Behaviours will be allowed through the use of a `script node' to incorporate Java or other scripting languages.
  6. Rve (IBM Japan's VRML 2.0 proposal)
    This is a proposal to allow multi-user realtime interaction through call backs and scheduling. The proposal relies on Java (and other scripting languages) for the ability to provide methods for describing actions.
  7. DynamicWorlds (GMD's VRML 2.0 proposal)
    This has much in common with other VRML 2.0 proposals and includes support for multiple scripting languages.
  8. W3A (An API for general Web `applets')
    This a C based system for allowing Web browsers, helper applications, servers, etc. to be developed and dynamically linked to each other on different platforms.
  9. W3C C libraries (C reference libraries for Web applications)
    This includes core functions such as binding to the local file systems, protocols, and callbacks, as well as more specific features such as a cache Management, proxy servers, logs, and utilities like dynamic memory management.
  10. CORBA (OMG's Common Object Request Broker Architecture for distributed programming)
    CORBA is a specification for using distributed objects over networks. It is not itself a programming environment, and in this study we are considering CORBA complient systems (such as Sun's Java implementation).
  11. VisualBasic Script (Microsoft's programming environment for the Web)
    This is Microsoft's port of their VisualBasic programming language to the Web environment. It is an interpreted system in which the source code is embedded in the Web page.
  12. ICE (DimensionX's 3D API extension to Java)
    This adds support for 3D primtives to the Java environment.
  13. LiquidReality (DimensionX's API extension to VRML and Java)
    This is a programming environment that uses Java to add behavourial characteristics to VRML scenes.

3. Analysis

The definition of what constitutes a programming environment is somewhat flexible. For the purpose of this study, we have taken it to apply to some kind of programming environment that supports one or more `languages' (itself a problematic term) and some kind of interface to provide services that can be used through the programming language. This means that Java itself would (naturally) be excluded, but Java plus its supporting JDK libraries and programs would qualify. At the moment there is no single programming environment that satisfies all the requirements of software development for the Web. This is because: We believe that this scenario will continue into the foreseeable future. Indeed, this may be a desirable, as it allows `communication' experts to develop API features that best suit their applications, `graphics' expert to develop their interests, and so on. High-level APIs are often developed for use in one or two specific application areas. Features are added to support these areas but other areas will rely on the low level API (e.g. Java) to support the general case.

The features that we considered in our study of each environment were as follows:

Platform independence
This gives an indication of simple it is to use code designed for one platform on a different platform
Distribution of data
How easy is it to use data held at different network locations?
Distribution of code
Can code located on different sites be used transparently?
Distribution of users
Does the environment support the access by remote users?
Distribution of processing
Does the environment provide support for distributed processing?
Extensibility
How easy is it to add further features and adapt the environment to a particular application?
Scalability
Does the environment allow easy development of both small-scale and large-scale applications?
Power
What is the expressive power of the environment?
Efficiency
How efficient is the code produced by the environment?
History
Does the environment allow code to perform operations that depend on previous executions?
Self-modifying
Can the environment be used to produce self-modifying code?
Native 3D graphics
Is there support for 3D graphics primitives and operations?
Multimedia
Is there support for multimedia features?
HCI/GUI facilities
How easy is it to build an effective user interface?
Level of programming
How abstract is the model of programming provided by the environment?
Security
How secure are applications developed using the environment?

Each environment was given a score of 0-10 for each feature, and the results are shown in Table 1 and the profiles in Figure 1. This score is an attempt to provide a quantitative comparison of a qualitative study, and the exact figures are not important.

Programming environment
Characteristic JavaHoloWebActive VRMLMoving WorldsIBM RveDynamic WorldsVRML2*W3AW3CW3**CORBAVBScrICELRAVG.
Platform independence108888108766.5101010109
Distribution of Data;101091010101010891010101010
Code; 10888888787.5101010109
Users; 4636455745.5102665
Processing 0000051000100001
Extensibility 9879778888102888
Scalability 33254541057.5100335
Power 7878687766.5107787
Efficiency 752746568755886
History 122452302171153
Self-modifying 122342300031132
Native 3D graphics 086979811100885
Multimedia 584847626400004
HCI/GUI facilities 7537355766.505455
Level of programming3434344433.554344
Security 8444444301.575554
Avg 56465655457456
Total 858970100819787797175107628493
* VRML2 has scores equal to the average of the proposals studied
** W3 has scores equal to the average of W3A and W3C
Scores:
0 to 3Difficult to exploit this feature, little of no native support
4 to 6Some support for the feature
7 to 10Full native support for this feature, easy to use

Table 1: Feature ratings of programming environments


Figure 1: Profile comparison of programming environment features

Our selective study has revealed that at present most of the programming environments (unsurprisingly) have good support for distribution of code, data and end-users. What is lacking from many at present is effective support for distributed processing. This is a major disadvantage at present, but this is likely to change with more widespread adoption of CORBA-like distributed object schemes. From our point of view, there is a general lack of effective support for 3D graphics and the ability to provide adaptive and persistent code. Some of these short-comings may be addressed by VRML 2.0, but the proposals for this lack the more `net-centric' features features for true distributed computing.

The `total' scores shown in Table 1 for each environment show that there is little to choose between the contenders overall, with CORBA showing strength by virtue of its extensive support for distributed, general purpose computing. The `average' scores for each feature in Table 1 give an indication of how well each feature is supported in general by the environments studied. This information is represented graphically in Figure 2.


Figure 2: Profile of the `average' programming environment

What is required for a general purpose API is that of flexibility and extensibility. It should be as abstract as possible to allow freedom to match the programmed solution to the problem domain. It should be possible therefore to present a simple, uniform interface API that supports many lower level APIs. In this way it would be possible to program under a single environment for multiple applications, and this is an extension of the Java philosophy of providing a virtual machine environment to provide platform independence. We propose a `virtual API', or VAPI, environment that supports many different lower level APIs. This means that we need to develop canonical models for API features, and to use these models in the VAPI.

4. The `Virtual API': VAPI

The API that we envisage to support the generic features necessary would be easiest to base upon an extension of the Java environment. Java itself is too low a level for rapid Web development of complex applications, but it does have the necessary network, mutltimedia (to a certain extent) and GUI support. What it lacks is support for the distribution of processing, history (or persistence) and 3D graphics. These are all available through different APIs that are built on Java, and so integration of these features will satisfy our requirements. We propose that the VAPI should support many lower levels APIs and utilise these if they exist on the target platform. VAPI allows integration of optimised code from different APIs to improve performance on various platforms (see Figure 3). The interface between `programs/applications' should be standardised so that applications can be swapped between platforms by only substituting the small platform dependent optimised API, since the VAPI should not need to know which platform it is on. It should also be able to simulate the features of APIs that are not present if this is necessary. This will mean that although the extra layer may effect efficiency during the actual development phase, the final application will use the most optimised API available and will not experience any overhead due to the VAPI.


Figure 3: Interaction of different levels of APIs

For example, consider support for 3D graphics. The VAPI should be able to support 3D modelling primitives such as polyhedra. If a lower level API such as ICE is available, then the features of this should be used. If there are no lower level APIs that support 3D graphics, then the necessary support must be generated. This implies that each function supported by a lower level API must be generalised. Extending the example of 3D graphics further, we would like an API to support:

These facilities are support by ICE, so calls to such features should make use of these facilties by providing a binding for each VAPI feature. Hence we may generate the following VAPI features and bindings:
VAPI ICE
Vector3D Vector3
Transformation3D Matrix4
Polyhedron3D Model
Camera3D Graphics3D
Material Material
Light3D Light
PointLight3D PointLight
SpotLight3D SpotLight

If the code development using the VAPI is being carried out on a machine that does not support ICE, then the application will first search for a lower level API that supports 3D graphics, such as VRML 2.0, as shown here:
VAPI VRML (1.0/2.0)
Vector3D Coordinate3
Transformation3D MatrixTransform
Polyhedron3D IndexedFaceSet
Camera3D PerspectiveCamera/
OrthographicCamera
Material Material
Light3D DirectionalLight
PointLight3D PointLight
SpotLight3D SpotLight
If it finds an API that supports 3D primitives, it will use the bindings for that API for the 3D graphics support. If it does not, then it will load additional code from the nearest VAPI repository for generic graphic libraries. This would typically be local to the development platform, since at the installation stage of the VAPI it would create any libraries necessary for development. We stress that this proposed scheme of working is not fully developed solution, but is at the conceptual stage. Many problems need to be solved, and the work complements other work at Bradford involving specification of object signatures for search-and-reuse of distributed code.

5. Conclusions and future work

We have performed a selective study of various programming environments for the Web, concentrating mainly on those that offer features that are requirements for our particular graphics applications. This has revealed that no single environment at present offers the features that we desire, and that a `mix-and-match' approach offers the most practical solution at the expense of usability.

Because of this (and the fact that this situation is likely to continue in the future), we propose a `virtual API' that allows integration of multiple APIs. In this way we hope to provide the features on many different programming environments at the expense of providing an extra layer on top of the current APIs. This layer will reduce the efficiency of the application development process (with the benefit of increased abstraction), but should have little effect on the speed at which the final application executes.

The next stage of this work is define the essential features of the VAPI and to specify bindings between the VAPI and the underlyng existing APIs. Once this has been completed, implementation of a full `virtual' programming environment can begin to provide an extendible, abstract development system that will combine the features of existing APIs.

References

  1. Java (http://java.sun.com)
  2. HoloWeb (http://www.sunlabs.com/research/tcm/holoweb/holoweb.html)
  3. Out of this world (http://product.info.apple.com/qd3d/VRML20/Out_Of_This_World.HTML)
  4. ActiveVRML (http://www.microsoft.com/INTDEV/avr/avrml.htm)
  5. Moving Worlds (http://webspace.sgi.com/moving-worlds)
  6. Rve (http://www.ibm.co.jp/trl/projects/rve/vrml2top.html)
  7. DynamicWorlds (http://wintermute.gmd.de:8000/vrml/)
  8. W3A (http://www.let.rug.nl/~bert/W3A/W3A.html)
  9. W3C C libraries (http://www.w3.org/pub/WWW/Library/)
  10. CORBA (http://ruby.omg.org/corba.htm)
  11. VisualBasic Script (http://www.microsoft.com/intdev/vbs/vbscript.htm)
  12. ICE (http://www.dimensionx.com/lr/documentation/javadoc-ice/ice.html)
  13. LiquidReality (http://www.dimensionx.com/lr/index.html)
  14. Obliq (http://www.research.digital.com/SRC/Obliq/Obliq.html)

¹Graphics & Image Processing Group
Department of Computing
University of Bradford
Bradford BD7 1DP
UK
²Electronic Imaging and Media Communications Unit
University of Bradford
Bradford BD7 1DP
UK
http://www.comp.brad.ac.uk/research/GIP/ http://www.brad.ac.uk/acad/eimc/