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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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).
- 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.
- ICE
(DimensionX's 3D API extension to Java)
This adds support for
3D primtives to the Java environment.
- 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:
- low-level APIs like the Java language and its environment allow
most desired features to be implemented, but the level of abstraction
is very low;
- higher-level programming environments (such as LiquidReality)
generally rely on the lower level APIs for many of their features,
adding support for particular features as necessary. This means that
they are only generally `higher-level' in one or two key areas.
- higher-level APIs often implement some key elements using platform
dependent opitimsed code (e.g. for 3D rendering). This provides a
richer API at the expense of portability.
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 | Java | HoloWeb | Active VRML | Moving Worlds | IBM Rve | Dynamic Worlds | VRML2* | W3A | W3C | W3** | CORBA | VBScr | ICE | LR | AVG. |
Platform independence | 10 | 8 | 8 | 8 | 8 | 10 | 8 | 7 | 6 | 6.5 | 10 | 10 | 10 | 10 | 9 |
Distribution of Data; | 10 | 10 | 9 | 10 | 10 | 10 | 10 | 10 | 8 | 9 | 10 | 10 | 10 | 10 | 10 |
Code; | 10 | 8 | 8 | 8 | 8 | 8 | 8 | 7 | 8 | 7.5 | 10 | 10 | 10 | 10 | 9 |
Users; | 4 | 6 | 3 | 6 | 4 | 5 | 5 | 7 | 4 | 5.5 | 10 | 2 | 6 | 6 | 5 |
Processing | 0 | 0 | 0 | 0 | 0 | 5 | 1 | 0 | 0 | 0 | 10 | 0 | 0 | 0 | 1 |
Extensibility | 9 | 8 | 7 | 9 | 7 | 7 | 8 | 8 | 8 | 8 | 10 | 2 | 8 | 8 | 8 |
Scalability | 3 | 3 | 2 | 5 | 4 | 5 | 4 | 10 | 5 | 7.5 | 10 | 0 | 3 | 3 | 5 |
Power | 7 | 8 | 7 | 8 | 6 | 8 | 7 | 7 | 6 | 6.5 | 10 | 7 | 7 | 8 | 7 |
Efficiency | 7 | 5 | 2 | 7 | 4 | 6 | 5 | 6 | 8 | 7 | 5 | 5 | 8 | 8 | 6 |
History | 1 | 2 | 2 | 4 | 5 | 2 | 3 | 0 | 2 | 1 | 7 | 1 | 1 | 5 | 3 |
Self-modifying | 1 | 2 | 2 | 3 | 4 | 2 | 3 | 0 | 0 | 0 | 3 | 1 | 1 | 3 | 2 |
Native 3D graphics | 0 | 8 | 6 | 9 | 7 | 9 | 8 | 1 | 1 | 1 | 0 | 0 | 8 | 8 | 5 |
Multimedia | 5 | 8 | 4 | 8 | 4 | 7 | 6 | 2 | 6 | 4 | 0 | 0 | 0 | 0 | 4 |
HCI/GUI facilities | 7 | 5 | 3 | 7 | 3 | 5 | 5 | 7 | 6 | 6.5 | 0 | 5 | 4 | 5 | 5 |
Level of programming | 3 | 4 | 3 | 4 | 3 | 4 | 4 | 4 | 3 | 3.5 | 5 | 4 | 3 | 4 | 4 |
Security | 8 | 4 | 4 | 4 | 4 | 4 | 4 | 3 | 0 | 1.5 | 7 | 5 | 5 | 5 | 4 |
Avg | 5 | 6 | 4 | 6 | 5 | 6 | 5 | 5 | 4 | 5 | 7 | 4 | 5 | 6 |
Total | 85 | 89 | 70 | 100 | 81 | 97 | 87 | 79 | 71 | 75 | 107 | 62 | 84 | 93 |
* 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 3 | Difficult to exploit this feature, little of no native support |
4 to 6 | Some support for the feature |
7 to 10 | Full native support for this feature, easy to use |
Table 1: Feature ratings of programming environments
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.
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.
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:
- 3D geometries in the form libraries
- Projection and display facilities to produce on screen images of
3D objects
- Lighting primitives
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
- Java (http://java.sun.com)
- HoloWeb (http://www.sunlabs.com/research/tcm/holoweb/holoweb.html)
- Out of this world (http://product.info.apple.com/qd3d/VRML20/Out_Of_This_World.HTML)
- ActiveVRML (http://www.microsoft.com/INTDEV/avr/avrml.htm)
- Moving Worlds (http://webspace.sgi.com/moving-worlds)
- Rve (http://www.ibm.co.jp/trl/projects/rve/vrml2top.html)
- DynamicWorlds (http://wintermute.gmd.de:8000/vrml/)
- W3A (http://www.let.rug.nl/~bert/W3A/W3A.html)
- W3C C libraries (http://www.w3.org/pub/WWW/Library/)
- CORBA (http://ruby.omg.org/corba.htm)
- VisualBasic Script (http://www.microsoft.com/intdev/vbs/vbscript.htm)
- ICE (http://www.dimensionx.com/lr/documentation/javadoc-ice/ice.html)
- LiquidReality (http://www.dimensionx.com/lr/index.html)
- Obliq (http://www.research.digital.com/SRC/Obliq/Obliq.html)