Title:

Platform Independent
Download of
Applications in
Data Broadcast
Environments

Student:
Antonio Barletta

Supervisors:
Rudolf Bittner Markus Zunkeller Gil Müller
To all my Friends
Contents

Chapter 1 Introduction

1.1 What is DAB ?....................................................................................2

1.2 A Software Platform for Downloading Applications using the DAB
System.................................................................................................5
1.3 Examples of DAB Applications..........................................................6
1.4 A Brief Description of the Contents of this Thesis.............................8

Chapter 2 Mobile Code

2.1 A Brief Introduction on Communication Mechanisms.......................13
2.2 Distributed Computing Paradigms......................................................14
Client/Server Architecture
 3-tier Architecture
Remote Evaluation & Execution
Code on Demand
Mobile Agent

2.3 Classification of Mobile Code Mechanisms......................................20

2.4 Programming Languages Concepts for Mobile Code.........................24
Language Level
Abstract Machine Level
Library Level

2.5 Security & Safety of Mobile Code Technologies...............................28

Chapter 3 Technologies

Virtual Machine / OSes

3.1 JAVA...................................................................................................32
3.2 Inferno/Limbo.....................................................................................37
3.3 OSes as Virtual Machines ?................................................................40

Architecture for Object Components

3.4 CORBA...............................................................................................41
3.5 ActiveX/DCOM..................................................................................42
3.6 Java BEANS.......................................................................................44
3.7 Obliq...................................................................................................45
3.8 Objective Caml (O'Caml)...................................................................46

Mobile Agent
3.9 AGLETS.............................................................................................48
3.10 Telescript.............................................................................................50

Scripting Languages
3.11 Tcl/Tk..................................................................................................52
3.12 Internet Scripting: JavaScript, Jscript, VBScript................................53

3.13 Comparisons & Comments.................................................................53

3.14 A Technology for the DAB System....................................................58
Chapter 4 Java
4.1 Java Architecture.................................................................................64
4.2 Virtual Machine..................................................................................65
4.3 The Class File Format.........................................................................67
4.4 Loader: How Code Born !..................................................................70
4.5 Garbage Collector...............................................................................73
4.6 Java Language: A Deep Sight.............................................................73
Exceptions
Concurrency
Serialization
RMI
Java Family: JRE, SDK, Personal Java, Embedded Java, Java Card

4.7 Java API..............................................................................................76

4.8 Web Integration: Applet......................................................................78
4.9 Native Interface...................................................................................80
4.10 Does only one Java exist ? Microsoft Way: DCOM/Java, J/Direct, RNI
......................................................................................................................82
4.11 Java Extension Framework: How to Expand the Java API.................84
4.12 Java vs. Other technologies.................................................................84
4.13 Java Implementation: Window Platform............................................85
4.14 java.net.*: a Case of Study........................................................87
4.15 Future Development: a Faster and Secure Architecture.....................90

Chapter 5 Download of DAB Applications using Java

5.1 DAB Architecture...............................................................................
5.2 Concepts for Application Download in DAB ....................................
5.3 Request of an Extension of the Eureka 147 Specification..................
5.4 Proposal for a Security Model: Java/DAB Security...........................

Chapter 6 Simulation
6.1 Overview of the Simulation................................................................
6.2 Integration of the Java Virtual Machine: MS COM............................
6.3 Software Implementation: the Main Java Component........................
Chapter 7 J-DAB Package: A Complete Java Solution
7.1 JDAB: Java DAB API.........................................................................
7.2 JDAB: A Conceptual Framework.......................................................

Conclusion

References
Chapter 1 Introduction

“The quest to know the unknown

and see the unseen is inherent in human nature.
It is this restlessness that has propelled mankind
to over higher pinnacles and ever deeper depths.
This insatiable desire led to the discovery of light
as being electromagnetic,
paving the way to the discovery of the radio."

(Saleh Faruque - Cellular Mobile Systems Engineering)

Nowadays the technologies of the three major industries, entertainment, computing and
telecommunication are converging. In the new era of digital communication, many different systems are
being integrated.
During the last years Internet applications and services have been the leading technologies for new
advanced digital communication infrastructures. Many fields related to telecommunication are today
thinking about the integration with the "mother of all networks" - the Internet.
DAB, Digital Audio Broadcasting, is the advanced successor of FM broadcast radio systems. This new
system gives listeners interference-free reception of high quality sound, easy to use radios, reliable
mobile reception and overall the potential of a pure digital channel to receive all kind of data (MPEG
audio, videos, images, text data and code).
 Digital data opens to a wide area of broadcast applications because it is the base language used in the
computing environment and it can be used as a link to the world of the computer and telecom services
(Internet, database services, multimedia applications, telephony, GSM) with the world of broadcast radio
and video communication (GPS, Video On Demand).
Otherwise broadcast radio systems are well suitable and more flexible for large scale distributed data and
for general data services communication systems: weather forecast, traffic information, news, etc.
Today in the market different broadcast system for digital radio transmission are also available: DSR
(Digital Satellite Radio) and ADR (Astra Digital Radio); they are not so flexible and smarter as we will
see than DAB.

Video
on
Demand

Entertainment
Music
Multimedia
Mpeg 2
Broadcast Encoding
Database
Distributed Systems

Telecommunication Computing
Internet
GPS GSM Mobile Code
Single
Frequency Virtual Machine
Network

Figure 1: Converging fields in DAB System

1.1What is DAB ?
Digital Audio Broadcasting - DAB - is the most fundamental advance in radio technology since the
introduction of FM stereo radio. In the new era of digital communication, another step toward the global
integration of all networks is done. Broadcast radio systems, until now relegated to a peripheral role in
the multimedia and digital datacommunication applications, now are ready to compete and to integrate
with other distributed multimedia computing technologies.
♣♣♣

We can summarized the main capabilities of traditional radio broadcast systems in the following list:

* unidirectional
* scalable
* ubiquitous
* low capacity data channel - FM-RDS

Unidirectional and scalability are the main characteristics of broadcast systems: signals are broadcast by
a single source and are received by a large number of users and the amount of traffic (occupied
bandwidth) is independent from the number of possible users: these aspects make the radio system
suitable for low cost large scale data broadcasting.
Ubiquitous computing is related to the physical medium used to transmit the radio signals. Whenever a
wire is unavailable or unnecessary, wherever mobility is a big constraint radio systems are the best
solutions: boats, cars, small cabins, historical buildings, mobile stations, PDA, Walkman, etc.
Besides all this positive aspects of traditional broadcast radio systems, AM and FM radio miss some
issues and there are some big disadvantages: noise interference, multipath propagation on mobile
systems, interfrequency interference, low quality audio (with respect to CD or DAT audio quality), a poor
number of extra services (FM-RDS), etc.

What are the new features of the DAB system and what kind of services can be developed ?

The DAB transmission signal (see chapter 5 for details) carries a multiplex of several digital services
simultaneously; it uses advanced digital audio compression algorithm to achieve a spectrum efficiency
equivalent to or higher than that of conventional FM radio. Its overall bandwidth is 1.536 MHz,
providing a useful bit-rate capacity of approximately 1.5 Mbit/s in a complete "ensemble". Each service
is independently error protected with a coding overhead ranging from about 33% to 300% (200% for
sound), the amount of which depends on the requirements of the broadcasters (coverage, reception
quality, number of services).
The ensemble contains audio programmes, data related to audio programmes, and independent data
services. Usually the receiver will decode several of this services in parallel.
A specific part of the multiplex contains information on how the multiplex is actually configured, so that
the receiver can decode the signal correctly.
DAB system is the best gateway to move digital data towards mobile devices and it is suitable for
providing integration with other communication architectures (Internet, GSM, satellite networks).
Actually there are other digital system to broadcast information: DSR (Digital Satellite Radio) and ADR
(Astra Digital Radio) are two services provided by the use of satellite channels. They both provide CD-
quality radio (with none or some kind of compression mechanisms) using large bandwidth and they both
lack good performance for mobile devices and they are not suitable for local radio services.

DAB, in brief, is characterized by the following attributes:

* high quality audio

* high bitrate downlink channel
* optionally low bitrate uplink channel (GSM, Telephone lines)
* ubiquitous of the target users;
* small quantity of information that interests a large number of users;
* access time is independent from the number of users (scalable)
* designed for mobile reception (car, wireless device as radio, Walkman)
* one system standard for the whole European market
* unidirectional, scalable, data delivering communication;
* economicity of the medium
 * electrosmog

Some attributes are similar to traditional broadcast system, but new one are added in DAB. High quality
audio and design for mobile reception are one of the fundamental introduction of DAB system: the use
of special coding techniques permits to optimize the reception from mobile device (car radio, boat radio)
and the use of some special compression technique permits the transmission of CD-quality audio. DAB is
also a cheaper way respect to the FM system to transmit radio signal: transmitter are less powered than
traditional high frequencies transmitter. For the same reasons we have a reduction of electromagnetic
fields emission (electrosmog).
DAB has been under development since 1981 at the Institut für Rundfunktechnic (IRT): broadcasters,
research institutes, network providers/operators and consumer electronics firms are contributing. The
DAB system is a European standard (ETS 300401, February 1995) adopted by the European
Telecommunications Standards Institute (ETSI). Services or pilot projects are running in many countries,
including Australia, Belgium, Canada, Finland, France, Germany, Italy, Norway, Sweden and
Switzerland [8a].

DAB active services

DAB sperimental services
interested countries
information not available

Figure 2: DAB in Europe (see [8b] )

1.2A Software Platform for Downloading

Applications using the DAB System
At the present two different DAB applications have been developed: Broadcast Web Site and
SlidesShow. In both case we use some static data, HTML pages and GIF images, to implement new DAB
services.
From different parts, both from content providers (BBC, Swedish Radio) and receivers manufacturer
(Sony, Mitsubishi, Bosch), there is the need to have more flexible DAB application. Dynamic contents
are the base of download application: download a complete application can allow user to receive
dynamic services and to offer a large number of modern services (in competition with Internet or Mobile
phones).
 DAB opens new opportunities to service providers and new facilities to the users. This sophisticated
platform permits the introduction of new data services on the radio channel. Telematics, the integration of
communication and computer science, finds a new fertile field for creating new services in DAB.

The research of new software solutions for the DAB system is the leading topic of this thesis: virtual
machine architecture, dynamic applications, distributed computing, mobile code, software components,
Internet services are new word in the context of the broadcast services. Internet is a big laboratory for
new solutions in the field of network, software engineering and multimedia: for that reasons we will refer
continuously to Internet technologies applications.
For example virtual machines are important components of a modern portable computing environment
(as the Internet) because they provide an architecture-independent representation of executable code.
Their performance is critical to the success of such environments and for the development of general
purpose services; but they are difficult to design because they are subject to conflicting goals. On one
hand, they offer a way to hide differences between hardware devices and they give a standardized
software layer for programmers; on the other hand, they must be implemented efficiently on a variety of
different machines.
Since radio receivers are becoming increasingly complex and microprocessors cheaper and cheaper, in
the near future we think that receivers will became more like computers, and computers will incorporate
receivers [9]. Some of the leading software companies have been introducing in these months complete
OS for the market of the embedded devices (car radio, settop box, hand held computers): Windows CE
from Microsoft and Java OS from Sun, but also Linux RTOS, Inferno from Lucent, are only a few
examples of the big interests involved in this direction.

Before building a distributed computing platform, we have to investigate what are the different possible
approaches that we can use and what are the right technologies to implement them; then we have to
follow the basic requirements that our specific platform needs and to develop appropriate solutions.

1.3Examples of DAB Applications

Digital information opens to a wide range of new applications not available in the traditional FM/AM
Broadcast system. Also the advent of digital data can open a huge number of integration processes with
other kind of communication networks: computer networks, GSM network, home network, etc. Both
traditional (like audio programmes) and modern (like downloaded applications) services can exist
together in DAB.

We list a number of possible applications.

High Quality Audio. The advanced digital compression techniques (MPEG 1 e 2) used in the DAB
system allow the broadcast of high quality radio services. A flexible audio bit rate (from 32 kbit/sec to
384 kbit/sec) allow the multiplex DAB signal to provide from 20 restricted quality mono programmes up
to 6 high quality stereo audio programmes. Also DAB radio services are identified not with the frequency
range but with some additional information as the name, the type of programme: DAB receivers are
smarter than ordinary FM receivers and users can interface with different services in a modern way. For
example, some broadcasters transmit extra data along with the radio programme which identifies what
sort of programme is, Classical Music or News, and users can search all the DAB radio services that
match some special requirements. In DAB are also available some extra features to provide pay radio or
data services: broadcasters might offer special services (both audio or data information) available only on
payment, which users would subscribe to on an individual or long term basis.

Dynamic Label. DAB provides a flexible way to associate and synchronize a data information
channel with audio programmes. This additional data has a variable capacity from a minimum of 667
bit/sec up to 65 kbit/sec. This additional information can be used to implement different new services:
dynamic label messages, Karaoke-like transmission of lyrics, multilanguages information transmission.

Travel/Traffic Information. All information for traveling can be retrieved from a DAB service.
Using text, images, maps and applications we can coordinate and inform car driver about all kind of
information (from hotel prices to traffic situations) needed for a good and secure trip. The DAB system is
a perfect medium to communicate this kind of information.

Broadcast Web Site. Once we have build a new communication medium, we can develop a Web
Browser application to receive HTML pages, Java DABApplet, Images like a normal network link. DAB
is a high bitrate downlink medium for providing a selected number of Internet services: traffic
information, weather forecast, sport news, emergency messages, entertainment, etc.

Commercial Applications and Data Download. For a large company that has to
exchange common information (price reports, software patches, internal communication) to a large
numbers of branches customers, DAB offers low cost and secure services. For example a car company
has to inform thousands of car shops around a large area like Europe about new price lists or new offers;
then each single shop can use some feedback channels (Internet, phone, mail) to order specific items. A
software company can offer software uploads for their customers. To realize these kind of closed user
group services means to control access to potentially confidential data are required: conditional access
systems and cryptography.

DAB
Booked !!

Downlink path
Train/ Flight Timetable
Information UPlink path

Internet

I want to reserve a ticket ..

Figure 3: Example of DAB/Internet integration

Entertainment. The combination between sound transmission and application contents can be used
for creating a new way of broadcast radio entertainment. For example the Slides Show: in this case
broadcaster can transmit additional data that may include comprehensive information about a piece of
music being played, such as the song title, composer, singer, album name, album picture, video frames
and so on.
 Brokering Information & Stock Quote Systems. Information about sport results or
stock prices can be delivered using DAB and be presented by Java application. A brokering agency can
deliver information to users using a ubiquitous medium like DAB.

Polling & Surveying. Agencies that collect information can create a polling service upon the DAB
channel, asking general information and can receive the feedback from the users by the means of GSM
mail service, Internet mail, etc.

Multimedia Home Network. The DAB receivers will be just a node inside a home multimedia
network together with HIFI systems, digital TVs, digital cameras, Settop boxes, etc: Java would be the
glue for all these different platforms.

What do you think about

the italian newparliament ?

DAB
?!!@:-(

GSM

Internet
???!!!!@:-(

Figure 4: Another example of a possible DAB application

Web/DAB Integration. Once we have created a software bridge between Java and DAB services,
the computer can be an hardware bridge to the Internet: we can think about a global network in which we
can move and optimize data exchanges. We can use the characteristic of the DAB channel to reduce
traffic congestion on the Internet networks for some special kind of information.

Games. Using download application means the possibility to move also games. User can receive
games in their DAB car radio: the runtime environment with graphical output provides all the facilities to
create this services.

1.4A Brief Description of the Contents of this

Thesis
The goals of this work is to give a theoretical and practical introduction to the problems related to
distributed programming environment, in general, and to give the basic requirements for a downloading
 application service using the DAB system, in particular. Understanding the Java platform is another
central topic of this thesis: Java up to now is a platform useful for network applications; we analyze in
detail the potentiality of this platform for a DAB system.
At the end we have applied some of the Java mechanisms to investigate in details some particular
mechanisms of Java and to simulated a simple download application (Applets) service for seeing the
behavior of some Internet-like services (CodeOnDemand, teledatacommunication) using a DAB system
simulation.

All the information used in this thesis comes from specification papers, academic articles1, and free
available documentation on the Web [8].

Here is a brief description of the chapters contained in this thesis.

Chapter 1Introduction
This chapter wants to introduce the reader to the new aspects and future
developments related to the DAB systems. We point out the new
kind of services available and the need of building a complete
computing environment for the future challenges for the DAB
service. We also focus our attention on the differences and the
likeness of the DAB system and the Internet world. At the end we
give a brief overview of the possible future applications using DAB.

Chapter 2Mobile Code

This chapter is a theoretical introduction to the paradigm of distributed
computing: the material is a collection of general concepts to give
a complete working framework to understand all the problems
related to the distributed computing. The goal of this chapter is to
create a background and to collect a series of theoretical tools to
analyze all the contents of the following chapters. We have
pointed out some issues related to distributed computing
paradigms, security mechanisms, abstract machine and
programming languages principles.

Chapter 3Technologies
This chapter is a brief description of the main distributed computing
technologies now available on the market. The chapter is not
exhaustive, but we have tried to mention the majority of the
products now available both from the market and from the
academic world. Inferno from Lucent, Java from Sun,
ActiveX/DCOM from Microsoft, Obliq from DEC are only few
examples of complete programming environment for distributed
applications. At the end of this chapter we make a comparison
between all this technologies and we try to choose the right
platform for application download in DAB. These first chapters are
the base for the developing platform for this project: the Java
technology.

Chapter 4Java
Java is the winning technology for developing a download application service
in the DAB system. We describe here the Java technology moving
from the abstract machine implementation to the API library. We
describe also some of the main characteristics of this developing
1
See references for a detailed list of documents
 platform: abstract machine architecture, programming language
features, security mechanism, Java API, native interface, Applet
model, etc.

[ Due to company confidentiality it is not possible to publish the contents of the

following chapters]

Chapter 5Download of DAB Applications using Java

This chapter explains in details the DAB architecture principles and services.
We introduce some security concepts related to the problems of
application download using the Java technology in the DAB system
and the need of some extensions to the DAB architecture to make
the system more flexible for the Java integration.

Chapter 6Simulation
In the project we have integrated inside a C++ application the VM: we have
tried to understand the inner mechanisms to integrate the Java
VM. In this chapter we describe in details the simulation and the
used software components: we have integrated the MS Java VM
inside an MFC project that simulates the DAB Navigator.

Chapter 7J-DAB Package: A Complete Java Solution

In this chapter we sketch the basic steps for a complete Java
solution for the DAB system: this is a conceptual framework for
future development using Java platform. The contents are also the
basis for a discussion on the possibility to use Java as a DAB
platform.
Chapter 2 Mobile Code

“Independence of the design paradigm

from the underlying technology
is a major point
in general software engineering practice”

“Designing Distributed applications with Mobile Code Paradigms”

(A.Carzaniga, G.P. Picco, G.Vigna)

Telecommunication networks are evolving at a fast pace and this evolution proceeds along several lines.
The size of networks is increasing rapidly and this phenomenon is not confined just to the Internet,
whose tremendous growth rate is well-known, but also in many different fields of applications related to
advanced telecommunication systems: from mobile phones to PDAs, from satellite systems to mobile
computers.
The DAB system is a new way to transfer digital information using advanced technique on the radio
channels. It is a new opportunity that opens to researchers a wide area for developing new services for
the radio market.
Before starting our investigation on the possibility to implement a download application on the DAB
channel, we need to retrieve some theoretical and technical concepts about the distributed computing
systems. The Internet world has been a exsperimental platform for lots of new distributed technology: we
want to use all these experience for start the development of new solution for the radio services using the
DAB system.

♣♣♣

In an heterogeneous computing environment we need new approaches to develop efficient applications

and we can not use classical paradigms or technologies used for stand alone machines: that's why we
analyze at the beginning of this thesis the new features of the Distributed Computing Environment and
the new methods of the mobile code technology.
A global network links together many different systems, so we need new approaches to create new ways
for exchanging information: solutions to the new problems arrive both from the academic world and from
the industrial research centers. We decide to start with a brief general introduction and a classification of
mobile code architectures to have some theoretical tools in order to compare the different
implementations nowadays available on the market: a more complete survey is available in [1], [2].

The expression "mobile code" is used with various different meanings in the technical literature; for our
purpose we define mobile code

"as software that travels on a heterogeneous network, crossing protection domains and is automatically
executed upon arrival at the destination"[1].

For protection domains we intend both wide area networks and small embedded systems (DAB radio
receiver, Personal Digital Assistant, Smart Card, etc.), the only requirements is that all nodes are linked
via a specific network medium that permits to move digital information.

♣♣♣

"Code Mobility" is not a recent discovery: we have already some examples. (For an introduction on the
mobile code see reference [1].)

* PostScript Language is used to send a series of commands describing the pages to be printed and
sending these "programs" to the printer; printer have a complete special purpose computing environment
to evaluate the commands that clients send;
* SQL Script Language is an efficient way to balance the database processing load on the server
machine where the data resides; in this case the specific language is suitable for database queries, updates
or data manipulations;
* Web Browser Application: to have a dynamic behavior on the HTML pages many proprietary
solutions have produced some special mechanism to transmitted executable contents on the network (the
well known Java Applet mechanism of Sun Microsystems, ActiveX controls of Microsoft, embedded
multimedia contents of the Netscape Browser); the code is automatically fetch from network sites and is
executed in the client machine where it uses all or partial resources (memory, Microprocessor, Hard
Disks, etc.);
* Software Distribution and Installation problem: this specific application has produced many
proprietary solution as Inferno of Lucent Tech., a mobile code enabled network operating system for
media providers and telecommunication systems; the management of the software installation is a typical
application where code mobility can give a better solution than the old strategies for its particular
features: scalability, customizability, etc.

These are only few example of the possible applications of mobile code, but as you can see they try to
solve some specific constraints to built efficient systems in terms of scalability, network traffic reduction,
security, minimal overhead and performance. Mobile code technology is not a new approach, but until
now it was relegated to very specific applications: these new model start to be investigate in a deep
manner and different University Centers have started a formalization process of the new paradigms.
 In order to evaluate the different mobile code technologies available on the market or for future
development, a set of criteria and theoretical tools need to be established. The following are important
issues for a complete comprehension of the complex and dynamic world of mobile code applications.

2.1A Brief Introduction on Communication

Mechanisms
Without enter in a detailed description, it is good to introduce some mechanisms used to implement some
communications tasks: these are basic concepts that are used in the proceeding of these work during the
analysis of the mobile code technologies. The goal of this chapter is to give a basic theoretical
understanding of distributed architecture and a set of concepts to compare different mechanism. We are
going to talk about the principles of distributed computing architecture and it is good to introduce some
of the used technique to exchange information.
Always from an abstract point of view, we can distinguish different communication mechanisms. We can
summarize them the following scheme:

C o m m u n ic a t o n m e c h a n is m s

P o in t - t o - P o in t

M e s s a g e s

R P C

S tre a m

P o in t - to - M u lti- p o in t

E v e n ts

G ro u p C o m m u n ic a t io n

S h a re d M e m o ry

T u p le S p a c e s

M u lt ic a s t in g / B ro a d c a s t in g

Basically we can distinguish the number of the objects that interact and the mechanism of the
interactions. For the first we have components communicating inside the same machine (processes,
threads inside a process) or remotely (different machine in the network); the second is a group of
mechanisms used to exchange information between these components: anonymous notifier events, packet
exchanged on stream connection oriented channel (sockets), messages posted on specific site, etc.

Point-to-Point. It refers to the communication between two Execution Unit both locally and
remotely. The more primitive and simple mechanism is message passing used in the client/server
paradigm (HTTP, XWindow); Remote Procedure Call is a more advanced but always based on
client/server mechanisms (UNIX, Win); streams are channel used to transfer data from two entities in a
continuos way (pipes in UNIX, TCP socket connections).

Point-to-Multipoint. Shared memory is the mechanism most frequently used to achieve

multipoint intraprocess communication inside a single Operating System. Event-based mechanisms
define an event bus constituting the logical channel through which events are dispatched: a suppliers-
 consumers architecture is used to give the possibilities to send events and to subscribe for receiving
events we are interested in: for examples the Java event implementation. In this case we distinguish a set
of specific type of information (events) and we use them to communicate anonymous event: the goal is to
know what is the message (type of service), not knowing who sent the message.
With the tuple space technique, each execution unit communicates by either inserting the tuple
containing the information to be communicated into shared tuple space, or by searching it for a tuple
using some form of pattern matching.
Among the point-to-multipoint communication mechanisms, the notion of group communication is
essential for development of cooperative software both in distributed or autonomous system. These
concepts can be important in a broadcast environment, in which the group communication is intrinsic in
the topology of the architecture.

2.2Distributed Computing Paradigms

In traditional applications the computing environment was closed inside a single machine (singletask
OSes). As computer and network capabilities grew bigger, the next step was to developed some
communication mechanisms to interface applications in the same machine (multitask OSes) or in other
connected machine (network and distributed OSes). Some examples are related to the UNIX systems
(pipes, signal, sockets), to the Windows system (event mechanism, WinSocket, queue, shared files or
variables) or the Inferno OS (chain mechanism).
With these techniques all applications were built based on the simple Client/Server or Peer-to-Peer
paradigm in which a single entity (single-thread-processes or threads in a multithread-application) calls
some specific services on another entity (located locally in the same machine, or remotely in other
machine on the network); in general the exchanged information was only formatted data following
specific rules (variables, constants, data files, etc.). This mechanism determines the basic behavior of the
majority of the classical distributed applications: FTP, HTTP, RPC; nowadays some object oriented
mechanisms have been introduced to the Client/Server paradigm (CORBA, RMI), but essentially the
paradigm remains the same. The positive features of a simple Client/Server mechanism is related to its
simplicity, especially in small and homogeneous networks. But in an increasing world where a large
number of heterogeneous machine are linked together that is not enough to create efficient, scalable,
secure, customizable applications. The numbers of the interactions between clients and servers, the
delays introduced in WAN networks, the lack of flexibility in a non homogeneous network are few
examples of the problems of the client/server approach.

Today new distributed paradigms have been introduced to implement modern distributed system and to
increase performance in a complex and heterogeneous environment: a conceptual framework is needed to
partially understand the mobile code scenario.

We consider some basic components of a distributed computing environment. We distinguish three

architectural concepts: components, interactions and sites. A complete work about the subject can be
found on [2],[3] e [5].
Components are the constituents of a software architecture and are divided in code, resources and
computational components. The first encapsulates the know-how to perform a particular task (in
traditional system this component was running always in the single machine where the code was stored);
the second are elements used during computation (shared files or variables, hard disk, video resources
from a software point of view); and the third are active executor capable to carry out a computation
(OSes, interpreters, virtual machines).
Interactions are exchanged data that are used to communicate between one or more components (for
example a message between two process in the UNIX system, an event thrown by a window application,
a message between a client and a server machine through the network in a Xwindow system).
Sites are the physical location of this components on a specific network. We distinguish also the services,
that is the results of the computation.
 Computation Interaction
Component
(CPU,memory,VM)

Service Code Component

Resources Component

Figure 5: Traditional not distributed system: all components reside in a single machine

By using this abstractions we can introduce the main design paradigm used for implementing distributed
applications (in the pictures used in this chapter we use for simplicity computer-like entities, but these
system can refer to any possible network architecture).
We distinguish:

* Client/Server architecture (pure) - already mentioned -

* 3 tier architecture (N tier architecture)
* Remote Evaluation
* Code on Demand
* Mobile Agents

For analyzing these different paradigms we should consider some parameters to point out the main
advantages related to a particular approach. In brief these parameters could be:

* Number of interactions (generated network traffic)

* CPU costs in terms of calculation
* Security
* Performance & Simplicity of the implementation
* Scalability
* Latency Optimization
* Push and Pull capabilities

Client/Server Architecture.
This is the classical implementation of traditional distributed applications. The mechanisms used to
exchange information are very simple and only data information is exchanged between two machines
connected with a network. All management and security mechanisms are centered in a high performance
server machine that provides a "a priori fixed set of services accessible through a statically defined
interface" [2]; the server can communicate with a number of low-capabilities clients (mainframe
architecture) or with a group of medium powered machines (LAN architecture). This architecture has
encountered many problems of scalability, especially today that network applications spread from LAN
to WAN in an heterogeneous environment and the number of users is growing up. A few examples of this
kind of implementation can be reported: X-Window systems, POP, FTP and HTTP protocols, Remote
Procedural Call, etc. New implementation for distributed computing as CORBA, DCOM, RMI try to use
this architecture paradigm (RPC) together with an object oriented programming, in which clients and
servers are "object entity" distributed in the network. There is a big difference between the latter
mentioned computing models and mobile code paradigms: in the mobile code paradigm we explicitly
model the concept of a separate execution environment and how computations are moved between these
 environments, while in the object oriented distributed application, the computational environment is an
abstraction layer that hides all the network system.

Client/Server (pure)

message data

data
Service
Client Server
Computation
Es: RPC, HTTP, FTP, Xwindow Environment
Code
(CPU,memory,VM)

Figure 6: Client/Server (pure) Architecture

In C/S systems the generated traffic is large and it can be a problem the latency of the medium and the
number of the interactions: clients and servers exchange a large number of messages for coordination,
control, and executing specific tasks.
That's why this architecture is in general used only for small networks with high band capabilities
(LAN). A lot of Internet application use this paradigm for its simplicity, but the produced overhead of
information and the lower reliability of the large networks decrease the performance of this system.
Security policy is centralized on the server: the gain on security is paid with a loss on flexibility (static
set of controlled services) and a decrease on performance (high overhead).

3-tier Architecture.
This architecture design is the natural evolution of the C/S model. For balancing the load of computing
between different computers with the same high-medium capabilities, especially in commercial web-
based application, it has been introduced a multi-layer chained layout; each stage deals with a particular
aspect of the distributed application. For example we can separate the presentation tasks from the
processing tasks and from data access: in this way we reduce the overload of the exchanged information
in the network and we increase the performance of the entire system. The layering process can be done
both at an hardware level (different machines implement different tasks) and at a software level (inside
the same machine we can have many processes that communicate with each other).
 3 tier architecture
presentation processing data access

message
message

Service
Server
Service
Computation
Client Environment
Server/Client (CPU,memory,VM)
code
Es: HTTP/CGI Computation code
Environment
(CPU,memory,VM)

Figure 7: 3 tier Architecture

Remote Evaluation & Execution.

A client machine has all the know-how (code) and sends it to a server machine for running it: in this case
we transfer code through the network link. The result of the computation can come back to the client,
evaluation (for example a SQL query), or not, execution (a PostScript transmission to a printer, a remote
script shell in UNIX). This solution applies well in that case in which the exchanged information or the
complexity of the computing should saturate the bandwidth of the links.
The server offers a service that is programmable with a complete computation language and the client
can customize its own service.
In this case the server receives and interprets commands: it is the first basic step toward sending code
through the network.

Remote Evaluation & Execution

message code

message

Client Service Server

Computation
Environment
Es: Remote Unix shell (rsh),Scripting, SQL, (CPU,memory,VM)
PostScript

Figure 8: Remote Evaluation & Execution

Code on Demand.
Many upcoming Internet applications are based on this paradigm. In this case a client has already all
necessary components to execute some service, but it does not have the know-how; the provider machine
gives the necessary know-how "on demand", that is in replay to a request of the client machine (in
general this is automatically controlled by applications); the client machine must have capabilities to
download, link, run the code automatically.
 Each client has a complete computing engine; for the portability of the distributed code, all machines that
interact with the server must have the same computational capabilities: for that reason for implementing
this kind of paradigm we need a complete virtual machine (a machine with the same computational
characteristics in spite of different platforms). Among the many existing proposals, the most well known
is the Java Applets technology of Sun Microsystem; other technologies are ActiveX from MicroSoft,
Obliq from DEC Lab, etc.
We can see that the code is fetched from a source in the network and once it is in the host is executed.

Code on Demand
Es: ActiveX/IE4.0, Applet, Web services

message

code

Client Server
Service Computation
Environment
(CPU,memory,VM)

Figure 9: Code on Demand

Mobile Agents.
This is the most advanced distributed computing paradigm and today many research centers and
academia are trying to design the more efficient implementation for implementing mobile agent
applications.
Mobile Agents are computer programs which may migrate from one computer to another on the network
[10 pag.3]. They are said to be intelligent, because they can perform autonomous actions in the network
depending on the external conditions: in each host the agent application can exchange some information
(through events, local variables, etc.) and can choose how to continue its travel.
The advantage of this kind approach is clear: hosts interactions are reduced to the minimum, high
flexibility and scalability, new solutions for unsolved problems (for example in the network
management); the disadvantage is the need of a complex computing environment.
The executed process is moved among the nodes of the network autonomously. This intelligent agent
seems to be the best way for intelligent network and seems to resolve problems related to efficiency,
customization, management: mobile agent has become a huge industry buzzword, especially in the
business applications!
A complete process (an application running) can be moved from one site to the other with its execution
data (variables) or completely with its execution state (stack image, register values). This approach is
more complex than the others and it needs a complete framework environment that manages the
migration.
 Mobile Agent
Es: Aglet,Obliq

code code

Service Service Service

Computation Computation Computation

Environment Environment Environment
(CPU,memory,VM) (CPU,memory,VM) (CPU,memory,VM)

Figure 10: Mobile Agent Architecture

Let me explain some advantage of this technology with a simple example: if a client applications need to
communicate to a client machine with a high number of interaction, a mobile agent can perform the same
service, but it reduces the number of interaction on the network: it migrates from the client machine into
the server machine; it executes all the interactions locally inside the servers in a fast way and then it can
come back to the client with the result of the service.

♦♦♦♦

2.3Classification of Mobile Code Mechanisms

At this point we need some reference abstractions to classify the different mechanism that allow
applications to move code and state across a network: the reader interested in more detailed analysis can
refer to [2],[3],[5] e [6].
Traditional Network Computing Systems use a software layer to offer to programmer an homogeneous
programming environment: each programmers don't care about the presence of a underlying network.
CORBA and DCOM are a few modern examples of this kind of implementations.
Technologies supporting code mobility take a different perspective. The structure of the underlying
computer network is not hidden from the programmer, rather it is made manifest. In the first case the
programmers interface is called True Distributed System, while in the second Computational
Environment CE (see the Fig. 7).
 Network Apps Components Network Apps Components

True Distributed System CE CE CE

NOS NOS NOS NOS NOS NOS

COS COS COS COS COS COS

Hardware

Hardware
Host Host Host Host Host Host

COS Core Operating System COS Core Operating System

NOS Network Operating System NOS Network Operating System
CE Computational Environment
Figure 11: Traditional System Architecture vs. Mobile Code Architecture

Let's go further. In the mobile code architecture we distinguish the components hosted by the CE in
Execution units (EUs) and resources. Execution Units represent sequential flows of computation. Typical
examples of EUs are single-threaded processes or individual threads of a multi-threaded process.
Resources represent entities that can be shared among multiple EUs, such as file in the file system, on
object shared by threads in a multi-threaded object-oriented language, or an operating system variable.
In a conventional system, each EU is bound to a single CE for its entire lifetime and binding between the
EU and its code segment is generally static. On the contrary, in Mobile Computing Systems the code
segment, the execution state, and data space of EU can be relocated to a different CE and in principle
each of these EU constituents might move independently.

code

stack/registers

data space
Execution Units

Computational Environment

Figure 12: Computational Environment Components

These new concepts give us the possibility to classify two main forms of mobility: Strong Mobility and
Weak Mobility. Strong Mobility is the ability to allow migration of both the code and the execution state
of an EU to a different CE. Weak Mobility is the ability to allow code move across different CEs; code
may be accompanied by some initialization data or some state-data, but no migration of execution state is
involved. Let me do some examples to explain these concepts: in the case of a strong mobility the
execution of the application is frosen and the host engine takes care to remove all the information inside
the CPU registers and all the bound resources, and move all in another machine; in the case of weak
mobility only the code and the data are moved: programmers can use special flag and variables to save
the state of the execution, but at the application level.
Strong mobility is supported by two mechanisms: migration and cloning. The migration mechanism
suspends an EU, moves it to the destination CE, and then resumes it. The remote cloning mechanism
creates a copy of an EU at a remote CE. Remote cloning differs from the migration mechanism because
the original EU is not detached from its current CE.
Mechanism supporting weak mobility provide the capabilities to transfer code across CEs and either link
it dynamically to a running EU or use it as the code segment for a new EU. Such mechanism can be
classified according to the direction of code transfer, the nature of the code being moved, the
synchronization involved, and the time when code is actually executed at the destination site. An EU can
either fetch the code dynamically linked and/or executed, or ship such code to another CE. The code
migrates either as a stand-alone code or as a code fragment: the first is a self-contained piece of code and
will be used to instantiate a new EU on the destination sites (Java Applet); conversely a code fragment
must be linked in the context of already running code and eventually executed (Safe-Tcl).
The mechanism supporting weak mobility can be either synchronous or asynchronous, depending on
either the EU requesting the transfer suspends or not until the code executed.
We can compare the previous section contents about network paradigm and the last concepts about code
mobility n the next figure.

data mobility code mobility

code
data code +
+ + data
only data code data state +
exec state

Remote
Execution
Client/Server Code
on
Demand
Weak Migration Strong Migration

Figure 13: A complete view of mobility in a Distribuited Computing System

The previous concepts can be considered as a base framework to start an analysis and a comparison of
the technologies in the distributed computing systems. The choice of a paradigm for the design of a
distributed application is a critical decision. Much of the success of the development process may depend
on it; but there is no paradigm that is better than others in absolute terms. The choice of the paradigm
must be performed on a case-by-case basis, according to the type an application and the characteristic of
the physical systems: a management application on a computer network, an information retrieval system
on a radio broadcast environment, a smart card solution for Automatic Teller Machine, etc.
From [6] we see that paradigms and technologies are not completely orthogonal. Although it is possible
to use a single technology to implement many kind of computing paradigms, there are some technologies
more suitable to implement particular design. Technologies sometimes are too powerful or too limited to
implement a particular architecture: in the first case the use of resources is inefficient; in the second
programmers have to code all mechanisms, to use extra structures, to implement special policies that
technology does not provide.
In the following section we will go into more details about the technology attributes that characterize the
computational infrastructure of a mobile code system.
2.4Programming Languages Concepts for Mobile
Code
From a less abstract point of view, we now try to emphasize what are the technical concerns on the
implementation of code mobility. In the last section we have seen the basic paradigm for implementing a
distributed system; here we want to introduce some technical concepts related to the development of a
distributed system.
Mobile code technologies include specific new programming languages (or special capabilities added to
the old ones) and a corresponding run-time support.
For the sake of clarity, we introduce three conceptual levels to understand the major constraints of a
mobile architecture and the implementation of some specific technologies [1]. We distinguish:

* Language Level

* Abstract Machine Level

* Library Level

This distinction is valid in general, but sometimes specific problems of the distributed system are not
limited to a single level: for example security and safety are global properties, so a security model must
take into account all aspects of the system support and the execution of the code.

Graphics support
Network
Library Level Encry ption
Hierarchical Class Suppor t

Interpreted or Compi led

Languages Level Strongly Typed or Ty peles s
Programming Paradigm

Concurrency
Security Model
Memory Management
Abstract Machine Level Memory Architecture
Platform Archi tecture
Mobility Mechanism
Shippi ng or Fetching

Figure 14: Security conceptual layer

Language Level.
Interpreted or Compiled.
The language level is the first step and the main resources toward code mobility. The first characteristic is
the nature of the produced code: interpreted or compiled.
Compiled languages (C, C++, Pascal) translate code directly in the hardware language of the execution
machine (Assembler); they have big performance and are more efficient, but they lack portability and we
have to compiled the code each time we want to move the code in other platforms.
Interpreted languages (Visual Basic, JavaScript, Jscript) instead are based on special execution engines,
called interpreters (in general developed for each platform), and they are interpreted directly from the
source code to the code of the particular executing machine: this middle software level produce worse
performance, but it is a complete portable architecture ("write once, run everywhere").
Some new languages support a third way: they compile the source code in a platform independent format
for an abstract machine architecture and they execute it with some interpreter engine or sometimes with
a so-called Just-In-Time compiler (Java of MicroSoft Browser, Limbo of Lucent Tech., etc.): this
solution is a compromise between performance and portability.

Strongly Typed versus Typeless.

Languages can be defined to be typeless or strongly typed. In the first case all data belong to an untyped
universe. All values are interpreted when manipulated by different operators; there are no restrictions on
how data can be manipulated (more flexibility), but there is the problem of nonsensical or erroneous
manipulations: this can be a great disadvantage for security policy and maintainability of the code
(reduction of readability and maintenability). Examples of typeless languages is the C language.
In the latter case, programmers can use only a secure set of typed variables and each manipulation of
variables can be controlled at compile-time; to increase efficiency the control can be performed at run-
time. Examples: Java, Tcl
In a mobile code system strong typing can be practically impossible to achieve for two main reasons:
first, code can be downloaded and linked at run-time from remote host; second, resources may be bound
to a program as it is executing.
Between these two extreme many technologies have tried to find the right balance (Java, Limbo).

Programming Paradigm.
The majority of modern languages use the Object Oriented Programming paradigm (OOP) for its basic
characteristic (reusability, inheritance, encapsulation, security mechanism) (Java, Obliq, Telescript);
others use different paradigm and less complex instruments, but in general they give some form of code
modularity and security issues.. Some versions are based on the more traditional imperative (or
procedural) and functional languages, but they have some specific additional security features (Limbo,
Objective Caml).

Mobility.
At Language Level, the mobility mechanism are some time implemented in a transparent and automatic
way directly in the Abstract Machine Level, or sometimes there are explicit mechanisms for triggering
the migration in the network. Some implementation use only some specific network mechanisms (TCP,
UDP, HTTP connections on computer networks), while others give some loading mechanisms for general
purpose code mobility.

Abstract Machine Level.

Platform and Memory Architecture.
Fundamentally the Abstract Virtual Machine is a concrete computer architecture implemented in a
software way: that is we have all the physical components (registers, Memory, devices) of a hardware
machine, but are all virtually built using software components (stack, variables, handles, etc.). The
characteristic of this machine depend on what are the goals of developers: the Java VM looks like the
Intel 4004 processor (used for embedded applications) and need few hardware resources, while the VM
of Lucent tech., Inferno-Dis, is a RISC-like implementation with good configuration from high end
system to embedded phone machine.
From a programming point of view nothing change, but if we are looking for specific performance or we
want to have a flexible architecture we have to consider the nature of the implementation design.
Also the Memory Architecture follows some hardware specific requirements, but all implemented via
software: stack base design, memory-to-memory design, etc.; in these case we have to consider the
possibility to implement the design "idea" with the underneath hardware platform (virtual memory
mechanism, security features, etc.). We have to be carefully on the memory protection mechanisms: some
memory protection mechanism are implemented directly in hardware in a platform dependent way, while
in some abstract machine implementation all protection mechanism are implemented via software.
We can see again that the goal in the platform design, is either having a general purpose portable design
or getting some specific efficient features for embedded systems.
In general, in the memory design, it is implemented an automatic memory control, the so called Garbage
Collector mechanism. This is done for many reasons:

• it is not efficient nor simple to control memory allocation in a distributed computing system when
some object can reside on remote systems;
• it is better for security reason and for automatic binding of resources that the VM can control
completely the memory access; otherwise memory dominates the costs of small systems, so the VMs
should be designed to keep memory usage as small as possible;
• memory bugs are difficult to control, so an automatic memory management can help to built safe
applications.

All Virtual Machines for mobile code follow in some way this rules.

Security mechanisms.
General protection of the running process is performed in general by hardware memory mechanism,
confining the code in separate memory spaces; but sometimes this could be a solution too expensive for
small devices; some security features are implemented at the Abstract Machine Level in order to control
the executed code. During the loading and the linking process we can verify the contents of the code
itself and control it before the execution; a sort of Security Monitor can be implemented to control the
access to some resources or to manage trusted and untrusted references (Security Manager in Java).
(A more complete study on security mechanisms is reported in the next section)

Concurrency.
In this case we point out the capacity of the Virtual Machine to manage two or more applications (single
thread process or threads on a multi-threads process) at the same time in order to improve the use of the
CPUs resources.
In general a thread is an independent execution resource managed and scheduled by the operating
system; the OS associates the CPU, a set of instructions and a stack context (including local variables) to
a thread. The first Operating System responsibility is to manage computing resources. One of the ways
the OS manages is by scheduling access to the CPU to the various programs that are executed
contemporarily. Programs then can be made up of multiple threads. Threads became a fundamental part
of the operating system and nowadays they are spreadly used.
In general we use a collections of threads ruled by a preemptive or an cooperative scheduling. The first
is better for a strong thread control because the CPU gives to each thread a fixed time slice to execute its
code: the second is better for multimedia or real-time applications, in which it is the programmers that
manage the CPU resources depending on the need of the application. Some Abstract Machine give the
possibility to use embedded concurrency techniques in spite of the underlying platform (Java on Win
3.1), others use the specific instrument of the platform in which they are running).

Mobility: Shipping or Fetching code ?

We have talked about moving the code: but who is moving the code ? In some cases clients ask to
directly a server to download the necessary code (fetching), while in others the server move the code
towards different clients (shipping), and sometimes the code can move alone (mobile agents). The first
two mechanisms seem to be exactly the same (it is just a problem of symmetry), but they hide different
mechanism for loading, linking, resolving and running applications; the third is a more sophisticated way
to move around the network and need a more complete framework environment.
And what about the structure of the code itself ? In general we encounter two basic ways to move code:
a single block and an applet-like way. In the first case we have a single block of code that is run
completely from the beginning to the end (PostScript file, UNIX remote shell Script). In the second case
 it is applied a more object oriented solution: you can use a set of method to control and trigger in a
dynamic way the behavior of your applications (init(), start(), .., stop() for the Applet, OnDispatch(),
OnCloning(),.., OnArrival() for the IBM-Aglets, Objective Caml applet from INRIA).

Linking Mechanism.
One of the main characteristics of the modern operating system is the possibility to call functions
libraries or external code at runtime and linking this code directly on the calling process: these techniques
allow programmers to produce modular, flexible and smaller applications. Some example are: the DLL
mechanism in the Windows environment, class loading and linking techniques in Java, modules loading
in the Inferno system, etc.

Library Level.
Since it is important to built secure systems, the control on the implementation of external libraries is of
fundamental importance. In general there are set of libraries ready-to-use and tested in order to control
the behavior of the entire programming environment. Some particular implementation include inside the
libraries some extra features related to control access to critical resources. For example inside the Java
libraries each time we use some critical method a security check is done for control the permission of the
calling applications.

Graphics.
The existence of a complete set or packages to develop a graphical user interface is a strong advantage on
choosing a platform for mobile code: an easy and ready to use library, can allow from one side
developers to focus their attention on mobility skills and from the other have an integrated, secure and
stable graphics interface. Java and Inferno/Limbo, for example, provide these features.

Security instruments.
Some complex mechanisms to built some specific implementation of security are enclosed in ready to
use library: security interfaces for authentication and certification, security algorithms, etc.

2.5Security & Safety of Mobile Code Technologies.

Code mobility paradigms may be implemented only with the help of a complex framework: basically a
programming language, an abstract machine (interpreter or just in time compiler) and sometimes a
complete library. One of the major issues in a distributed environment is the security of the system. In an
open network security became a big constraints; the increase of systems complexity is a big concern also
related to the security. More complex is the system, more weak is ! We need special attention to how we
can build a secure and safe system, and where implement the controls.
In general the degree of security is related to the weakest "ring of the chain":

" You can build a 100 billion dollar secure system to prevent access to private password in your
system, but are you sure that your system manager will not give this information for less ? "
(A.Lioy - Security and Distributed Programming Professor at the Politecnico of Turin)

Another aspects is related to the nature of code mobility. As the mobile code is crossing protections
domains, special care must be taken in order to protect it against external computing environment and
special care must be taken by computing environment against malicious mobile code. A good
introduction on these issues could be found in [1].

We distinguish four security properties:

* Confidentiality (or Secrecy)
* Integrity (or Accuracy)
* Availability
* Authenticity
Confidentiality concerns the absence of leakage of private information (which often occurs through a
covert channel). Integrity of the data means that data should not be modifiable by unauthorized parties.
Availability, the negation of which is known as denial of service: the attackers denies normal use of
shared resources preventing users to use the resources. Authenticity permits that identity of
communication partner can be trusted.
We can divide a global mobile code computing system in four subsystems, or levels, to focus on in
details some specific aspects:

* Communication Level
* Operating System Level
* Abstract Machine Level
* Programming Language Level

Communication Level
At this level the network is a collection of computer connected with hardware networking technology:
the requirements at this level in general are concerning the robustness and efficiency of the protocol. But
how the information are protected by eavesdropping or how the confidential of exchanged information is
controlled ? Only in these years new secure features have been introduced at network layer (IPv6);
HTTPSecure and SSL (Secure Socket Layer) are some implementation that are located just on the HTTP
and Socket mechanisms. This new protocol based on cryptography techniques controls and manages
confidentiality, integrity and authentication, but they seldom lack availability: lots of examples are
related to the problems of deny of services in Internet.

Operating System Level

Safety and security at the communication level is not sufficient in general. Handling safety and security
is also a primary concern at the operating system level.
Historically, memory protection and privilege levels have been implemented in hardware: memory
protection via base/limit registers, segments, or pages; and privilege levels via user/kernel mode bits or
rings. The recent mobile code systems, however, rely on software rather than hardware for protection.
From a more general point of view, network hosts can be represented both by high-end machine and by
smaller embedded system with no hardware memory mechanisms.
The switch to software mechanism is being driven by two technological trends: portability and
performance. The first one permits to have a platform independent security mechanism; the second is
reached because software protection offer significantly cheaper cross domain calls.

Confidentiality and integrity can be achieved by controlling process access to information and
communication channel; to control availability we can limit the access to all needed resources (disk
space, memory usage, number of process, graphic access). Authentication is usually established through
an initial identification of the user and maintained by some protected OS structures.

Abstract Machine Level

Safety can be obtained also at Abstract machine level: the virtual machine can implement some specific
features, that in general are implemented by OS. In fact using a language independent abstract machine
retains all the language independence of the operating system solution, but does not have portability
problems.
At the Abstract Machine level you can control access to resources through the use of a set of secure API:
you can enforce protection of internal structures of VM.
Programming Language Level.
At this level we pay each secure mechanism with the flexibility of the programming language: the
majority of modern programming languages have some controls against low-level errors through
mechanism like typing, restricted pointers, automatic memory management, and array bound checking. It
is possible to go even further and use the language scope and access rules to protect the interface of
resources.
As an optimization, the high level program can be compiled and type checked before being shipped as
mobile code, but can we be sure that the object code is really a non tampered output of a correct compiler
?
Three techniques have been proposed [2]:

• using cryptographic signatures to reduce the problem to one of trusting the author (ActiveX)
• using cryptographic signatures to trust compilers, in this case we use only a small number of
trusted sites for compilation and certification (Inferno/Limbo)
• compiling to an intermediate language which can be checked to verify the same constraints that
are imposed on the source language (Java)

These techniques are not exclusive. You can use some combination of these techniques to improve your
security wall. For example you can combine the use of cryptographic signatures and trust compilers: it
seems easily feasible as they require much of the same technology and infrastructure [1].

As we have seen "Security is a global property, so a security model must take into account all aspects of
the system supporting the execution of the code. This includes in particular the hardware, operating
system, the abstract machine, the modules libraries, the security manager, and the browser (in this case it
means the container of the mobile code). A security weakness in just one of these endangers the security
of the whole system [1]".

“Consider the past and you shall know the future.”

(Chinese Proverb)
Chapter 3 Technologies

"Strong typing is for people with weak memories"

(Toman Vleck)

A number of mobile code solutions have been developed in the last years by the main software
Companies (Sun, Microsoft, IBM, Lucent, DEC) and by a number of academic research centers
(Berkeley, Stuttgart, Zurich).
As we have seen, mobile code applications can follow different implementations approach in spite of the
specific goals of the designers and follow different mechanisms to exchange information. Our purpose, in
this chapter, is to provide the readers an overview on the basic characteristics of the products now
available on the market, following the architectural frameworks (paradigms, techniques and instruments)
explained in the last chapter.
Using the theoretical tools of the previous chapter we also want to identify the differences and the
similarities of the distributed computing technologies and find the best suitable solution for our particular
domain (see next chapters).
 Talking about technologies means to investigate the basic practical tools used for implementing a certain
kind of engineering solution: that is talk about the architecture, the software components and tools, the
qualitative performances, etc.
A starting point for a complete overview of mobile code technologies can be found in [1].
In these subsections we will classify the different technologies in 4 main groups:

• Virtual Machine/OS
• Architecture for Object Components
• Mobile Agents
• Scripting Languages
The first group is a complete programming environment to create mobile code solutions: Java from Sun
and Inferno from Lucent Technologies are some good example to explain the main concepts of Operating
System and Virtual Machine for mobile code.
The second group is more general object oriented approach to the mobile technology; in the last chapter
we have discussed about true distributed system and here we make some example of this solutions.
CORBA, DCOM, Obliq, Java Beans are just some examples of this approach to distributed system: some
are only specification, other are ready-to-use tools to implement object components systems.
Mobile Agent are the more advanced architecture for building a distributed system: some solutions are
nowadays available on the market, but a lot of work has still to be done in this direction.
Finally. Scripting languages are a collection of very simple and efficient solutions for implementing
distributed system: they lack lots of the flexibility of other more sophisticated technologies, but they are
productive, cross-platform, and specialized tools.

Virtual Machine / OSes

3.1Java
Java was originally called Oak and was proposed by Sun as a language for embedded non-computer
devices - mostly consumer devices. When the Web became explosively popular, it was a natural fit to
apply this technology to the Web environment, and now this product is the leading technology for
implementing distributed mobile code applications in Internet.
Today there are two main version available on the market, SDK 1.x and SDK 1.1.x 2; it is going to be
shipped between few months JDK 1.2. All the information inside this section refers to [2], [3], and [5].

What is Java under the hood ?

Java, first of all, is a class-based, cross-platform, network-based, object oriented language created by Sun
Microsystems, with an emphasis on portability and security. Java is a complete programming
environment: it is not only a programming language, but a complete virtual machine specification and a
set of general purpose libraries that forms the API of the Java system.
Today Java is the most dynamic technology for Internet applications and for distributed computing:
initially it lacked performance and efficiency, but nowadays all the advantages of this platform are clear
and touchable. Portability is one of the main advantage, but also flexibility (loading mechanism, security
policy, API extensibility, specification).

2
In this chapter we refer to the JDK 1.1 implementation of Sun Microsystems and the JDK 2.0 of Microsoft, both developed for
the Win32 platform.
It is hard to make a brief overview of the Java family; in this section we will provide some basic concepts
and practical implementation to see both the advantages and the disadvantages of this architecture
following the theoretical framework built in section 2.5.
The most known applications of the Java technology are the Applets: a secure, easy to develop, portable,
object oriented application for embedding dynamic application inside HTML pages, the Web basic mean
to communicate over Internet. Applets are Java classes that are loaded automatically from the net and
executed inside a secure "sand box" following the code on demand paradigm. Applets have transformed
the way you can think of Internet and HTML pages: code is moved towards every point of the net
whatever are the OSes or the hardware platforms.
bytecode

Java Application
Java API

java.io java.net java.awt java.math

C / bytecode

OS API Java class

Graphic native
I/O TCP/IP Peer
class Math

Class Linker thread

Loader mgmt. Java VM
assembler / C

HD API Native Operating System

Interrupt Device
Management Memory Graphics

Figure 15: Java Architecture

Language Level. The Java programming language is based on a simplified variant of C++ (the
developing language most used on the market and in the academic world) with all unsafe and most
complicated language features removed: unsafe operations, like pointer arithmetic, unrestricted casts,
unions, and features leading to unmantainability programs like the C preprocessor, unstructured goto,
operator overloading, and multiple inheritance.
In computer science terms, Java is strongly typed and late bound with dynamic linking
programming language. It supports encapsulation, which reduces complexity; it is strongly object
oriented, where inheritance, polymorphism and delegation help to reuse the code; array and string types
are built-in with range checks for all accesses. Exception handling has also been added, in order to permit
the creation of robust programs.
Concurrency is provided at the language level with thread and serialized methods, using mutex-locking
technique on the corresponding object.
Java includes a novel notion of interface types. Interfaces define a collection of abstract methods and
attribute variables with their associated types. A class can be declared to implement an interface, in which
case it must implement all the methods of the interface. Whenever a value of an interface type is
expected, a value of a class implementing this interface is used. Interfaces are useful for a number of
purposes: they can be used to hide the implementation of a class and to group classes with a common
functionality without forcing them into a class hierarchy.
Java also uses the notion of package. A package groups a number of class and interface definitions. A
class can be defined final (disallowing subclasses of itself to be derived), abstract (disallowing instances
to be created), and private (limiting the scope of the class declaration to the containing package).
Attributes have four levels of visibility: private, default, protected, and public. Private attributes are
only visible from within the object itself; default visibility extends visibility to the package in which it is
defined; protected attributes further extend the visibility to subclasses of defining class, potentially
defined in another package; finally, public attributes are visible everywhere.
As we can see Java is more than a traditional programming language: it is a instrument built to help
programmers to develop object oriented applications skills and to create a secure platform to manage
code in a distributed computing environment. All these aspects make Java a complete operating system
language, as C++.

Abstract Machine Level. Basically the virtual machine of Java is a virtual hardware platform.
Today processors have high computing capabilities and they can simulate by software a complete
hardware platform for building a software layer between different specific platform and user
applications.
From an architectural point of view, the Java VM is like the Intel 4004 processor, with a minimum
number of registers (4) and a stack base memory architecture; this requirements allow to implement the
VM on almost all hardware platform, from embedded systems to high power computers. The VM have
its own machine language, the so called bytecode, that is used unchanged for each VM: it has both
efficiency of a compiled code and portability of a interpreted code.
The VM is not a monolithic piece of code. Since it is designed with portability and scalability in mind, it
heavily uses separate subsystems for threading, memory management (Garbage Collector), native
method interfacing, native system calls, loading, verifying and linking code, etc.. Each block can be used
and configured for specific purposes and can be added or removed to adapt to specific software and
hardware requirements. For example some embedded implementations of the JVM don't need the GC
module or the verifier module, because memory management is done manually and Java classes are
embedded inside the ROM memory.

Automatic memory management (Garbage Collector) has been added, protecting execution from
memory allocation/deallocation and pointer errors due to manual memory management; as we have seen,
automatic memory management is a key-point in distributed systems both to control and manage
resources and for security reasons.
The most interesting part of the VM is the execution engine itself, which comes in two different flavors:
interpreter and "just in time" compiler. The first is just a translator of the bytecode commands, while
the second is a more efficient way to execute Java code in a platform dependent way using caching
technique for the frequently used blocks of code.
The second solution is surely the more efficient but it lacks portability, because the VM implementation
is strictly dependent on the specific machine.
A JVM is available for a huge number of different hardware platform and OSes: from RISC based
processor to Intel Pentium, from embedded system to PDA, from MS Windows platform to Sun's Solaris,
etc.

Library Level. From the beginning of its life, Java has been shipped with a set of libraries (JAPI)
that have given programmers a complete and secure class based environment.
System classes are a complete set of pieces of reusable (using inheritance technique) code for permitting
to programmers to focus on their specific tasks, without worrying about all parts of the system. The Java
Development Kit (JDK) from Sun range from GUI interface to HTTP communication libraries, from
complex Math calculations to remote procedure calls.
The importance of the Java class libraries is in its role for built a secure system: Java class
libraries are written in such a way that all sensitive operations call into a centralized object, the security
manager, to check whether the caller is allowed to invoke this operation. Programmers can built their
own security manager to trigger the security of their environment.
Initially JDK was the only Java Technology available for application development, because Java was
positioned for the Internet market. Sun nowadays is looking seriously to other specific market segments.
You can adapt your Java system for different platforms: Personal Java for Network computers, smart
phones, handheld PDA; Embedded Java for embedded systems and Java Card for smart card
technologies. They all are designed to be upwardly compatible, so you can run your applications on the
upper API implementations.

Figure 16: Applet executed in Internet Explorer and in Netscape Navigator: not all is the same !!

Applications. Java is an environment to implement complex distributed applications. From its birth
Java has collected a huge number of different applications: from commercial oriented application to
agent based platform, from embedded device management to software component. A complete OS,
JavaOS, has been built. JDBC is a package for database interfacing using ODBC standard. Java Beans is
a component architecture for Java enabling re-usable software components. Java 3D, a set of libraries for
3D imaging. JavaChips, an hardware implementations of Java VM for embedded applications and
JavaCard, a complete set of API for building smart card apps.
The flexibility of the package structure of Java has allowed programmers to develop all kind of mobile
code applications: RMI packages permit to create traditional distributed client/server, object oriented
systems; Aglets, Voyager, Odyssey are some specific implementations that use some features of the Java
languages (RMI, serializable, networking, multithreaded) or use some additional technique to create
weak mobile code applications.

Java is a promising language with a tremendous market acceptance. Much of this popularity stems from
Java's unique combination of characteristics: close to C++, safe, portable, easy and concurrent, as well as
supplying a rich base library. There is yet much work to do especially in the secure architecture and the
efficiency of the execution engine; Java misses some characteristic for real time applications, where
performance of the executing applications have to be predictable.
Many other technologies are converging towards Java: Tcl/Tk is thought to be the scripting twin of Java;
DCOM interfacing with Java is a goal of Microsoft JVM; the Inferno OS developer from Lucent are
thinking of the possibility to embedded JVM inside their system; etc.

♣♣♣

Java is used as a base technology to implement different kind of mobile code architectures and
paradigms. Java and applets have revolutionized the Web, and executable contents has become a
common term in the Web and network glossary. We have seen that Applets are essentially a set of
program codes that can be downloaded (code on demand paradigm), instantiated, and executed in Web
Browser.
 Recently, this concepts has been matched by the introduction of servlet: the servlet is moved from the
client in the opposite way to the applet; that is, it allows the client program to upload additional program
code into server; the servlet's code is then instantiated and executed in the server (remote execution
paradigm).

In the next sections we will analyze some additional implementation using the Java technology: a mobile
agent architecture, Aglets, and an object components, Java Beans. These implementation are Java
solution but they have particular aspects that they have to be considered separately.

3.2Inferno/Limbo
The same folks that brought us UNIX an C are promising something even better for network
communication: Inferno OS and Limbo language.
Inferno by Lucent Technologies (Bell Labs Innovations) is a network operating system designed to suit
the constraints and needs of this environment; Limbo is the operating system programming language
used to build the majority of the OS and all applications. All information about Inferno is available on the
Lucent Web site and in some paper available also from Lucent [7].
Inferno is a commercial product intended to be flexible enough to be employed on devices as diverse as
intelligent telephones, hand-held computers, personal digital assistants, television set-top boxes, home
video game consoles, and inexpensive network computers; it can also be used on servers such as Internet
servers, financial servers, and video-on-demand servers. It is portable across processors (Intel, Sparc,
MIPS, ARM, HP-PA, AMD 29K) and across platforms (WinNT, Win95, UNIX: Irix, Solaris, Linux, AIX,
HP/UX).
The design of Inferno is based largely on Plan9 OS, a network operating system from Lucent, but
emphasizes portability, versatility, and economical implementation. Economic here refers to the
computing resources required; Inferno can run within little memory and does not require virtual memory
hardware. The portability has two dimension in Inferno. The operating system itself can run on a bare
hardware directly on the CPU (native mode), or on top of an existing operating system like UNIX,
WinNT or Plan9 as a VM (emulation environment). In the latter case, the services provided by Inferno
are mapped to the native services of the underlying operating system. The second dimension is the
portability of Inferno applications. Applications (as we have already mentioned) are written in Limbo, an
integral part of Inferno, and they are compiled to a binary format that is portable between all Inferno
implementations.
The Inferno system is based on the application of three basic principles:
* resources as files: system resources are represented as files in a hierarchical file system;
* namespaces: the application view of the network is a single, coherent namespace that appears as a
hierarchical file system but may represent physically separated resources;
* standard communication protocol: a standard communication protocol, called Styx, is used to access
all resources, both remote and local.
In the figure 5 we can see an overview of the architecture of the Inferno/Limbo system.
 Java ?
Applications
Application Layer
Dis Virtual Machine

Process Management

Memory Management

Graphics library
Namespaces

Security
Limbo Kernel Layer

Styx communication

Assembler Host Device Hardware Layer

C language OS drivers network

Figure 17: Inferno/Limbo Architecture

Language Level. A Technology for the DAB System Limbo is a safe imperative language. It's main
inspiration is C, but it includes in addition declarations as in Pascal, abstract data types (ADT), first class
modules, first class channels, automatic memory management, and preemptive scheduled threads. It
excludes pointer arithmetic and casts.
The declaration of a module identifies the types of exported functions and contains the exported
declarations of ADT's, simple type declarations, and constants. In order to use a module, it must be
instantiated by loading an implementation of the module (at runtime). The loading is done with the built-
in function load that takes a module type and a path to the module implementation and return the
instantiated module (or null if unsuccessful). This allows the programs to choose among several
implementations at run-time.
The channels of Limbo allow the communication of any value of its declared type. A channel can be
connected directly to another process or, through a library call, to a named destination. Channel are the
only built-in primitive for interprocess communication, but more complicated mechanism can be built
upon them.
Memory is managed automatically by a garbage collector mechanism.

Abstract Machine Level. Limbo programs are compiled to a RISC-like abstract machine called
Dis. Dis is designed for just-in-time compilation to efficient native code by Limbo run-time system. The
machine is memory-to-memory architecture, not a stack machine, that translates easily to native
instructions sets.
The Inferno kernel provides preemptive scheduling of processes (with a very low overload) that are
responsible for managing and servicing protocol stack, media copies, alarms, interrupts, and the like..
The kernel schedules processes with multiple priority run queues (8 levels) using round-robin
mechanism. Scheduling is on a fixed time slice, or quantum, basis with each quantum being set by the
local system clock.
Inferno has two-level memory allocation mechanism: the lower level maintains control of large block of
contiguous memory. The higher level divides memory into pools to allow applications to control the
behavior of the system when the resources become scarce. Memory is stored as block in an unbalanced
B-tree with the leaves sorted by size.
The interface to all devices is via the Inferno file system interface (as it is partially done in UNIX) and
each device driver is a kernel resident file system.
 Figure 18: Inferno Emulator on WinNT platform

Library level. A rich set of standard modules are provided, including modules for network
communication, secure and encrypted communication, and graphics. Two user interface libraries are
available: one based on Tk is intended for traditional window based user interface; the other is a ready
made interface components for typical embedded applications, such interactive TV. The specialized
design allows for a minimal memory requirements.

Security. Safety is achieved through a safe language with restricted pointers and automatic memory
management: this safety is not enforced by the abstract machine (as in Java). Inferno relies on
applications being signed by trusted authorities who control their validity and behavior: this is a big
constraint for the diffusion of that environment for Internet applications, where a huge number of
programmers live on.

Applications. The applications domain for Inferno is focused toward applications for service
providers.
Inferno has been compared to Java by many in the press. The lack of an object oriented structure in
Limbo is one of the reason for which Inferno developer are thinking of an integration of Java inside
Inferno [4]. The two platform are briefly compared in the following table.
Table 1: Inferno vs. Java - a Comparison -

Inferno/Limbo JavaOS/Java
Security Built in authentication and Machine protection security is built-
encryption at OS level, not in. Encryption has been added.
automatic machine protection
security
Resources access One file system access everything File system access local data:
from data to network network data must be accessed
through the server
Minimum size machine to 512 KB of RAM 128 of RAM
run applications 512 KB of ROM 512 of ROM
Object Oriented No Yes
Virtual Machine DIS Java Virtual Machine

3.3OSes as Virtual Machines ?

Special hardware devices need OSes built directly upon them. For some specific purpose architecture we
can not implement an abstract virtual machine upon the main OS. Big constraints on hardware resources
as memory, CPU, special communications protocol or special video devices, give us the only choice to
develop only a very thin software layer and use that as the only platform.
There are some advantages to use a platform dependent environment:
• fast performance and efficient code
• direct access to the hardware resources
• a complete and optimized set of developing instruments
• a well defined API
• real time capabilities
Nowadays there are a few number of platform for distributed applications that follow this way. Apart for
some peculiar characteristics, they can be included in this group of OSes: Windows CE from Microsoft,
JavaOS from Sun, Inferno from Lucent, but also all UNIX flavors and real time OSes.
The problem of portability for these systems is big and from many directions they are trying to include in
the platform some tools to open the platform to a wide environment: Inferno programmers are developing
a way to include Java VM inside their system; some real time OSes are thinking about Java as an
additional module to include in their systems; etc.
 Architecture for Object Components
Modern programming languages employ the object paradigm to structure computation within a single
operating system. The next logical step is to distributed a computation over multiple processes on one
single or even on different machines. Because object orientation has proven to be adequate means for
developing and maintaining large scale applications, it seems reasonable to apply the object paradigm to
distributed computation as well. Object are distributed over the machines within a networked
environment and communicate with each other [9].
As a fact of life the computers within a networked environment differ in hardware architecture, operating
system software, and the programming languages used to implement the objects. That is what we call a
heterogeneous distributed environment. To allow communication between components in such
environment one needs a rather complex piece of software called a middleware platform.

3.4CORBA
Currently there are two major approaches to distributed-object technology, namely Microsoft's
OLE/ActiveX technologies and the Object Management Group's (OMG) CORBA Architecture
specification.
CORBA stands for Common Object Request Broker Architecture. Let's imagine the internal hardware
architecture of a PC. Inside we have different blocks that implement different mechanisms: one o more
CPU, hard disks, floppy controller, video controller, audio card. All we need to coordinate all these
separate block is a common "bus" that coordinate and ruled the exchanging information. CORBA
provides the software solution, a "bus" specification to connect different software components from
different platforms.
CORBA addresses the following issues:

* object orientation
* distribution transparency
* hardware, operating system and language independence
* vendor independence.
CORBA is an open standard in the sense that anybody can obtain the specification and implement it;
besides its technical features this is considered one of the CORBA's main advantages over other
proprietary solutions.
For resume CORBA is a standard specification to built a multiplatform distributed computing
environment using a object oriented paradigm. Other proprietary solutions are now available on the
market (DCOM from MS), but CORBA is becoming the standard and the reference model for large
distributed applications. The biggest Software Company use CORBA as a reference model for their
applications (IBM, HP, ORACLE) and a lot of other company are building a bridge to this specification
(Java/CORBA, DCOM/CORBA).

From the point of view of distributed paradigm, CORBA is an evolution of the client/server RPC model
used in many platforms (UNIX, Windows, Solaris): the revolutionary idea is to match the object oriented
paradigm and to give a specification separated from a particular technology: OSes, programming
languages, communication mechanisms.
In CORBA there is no mobile code: this technology is a coordinating framework to export object
communication from single address space process to a distributed environment (both locally and
remotely).
As other technology CORBA is Internet oriented, that is a complete specification to build a sophisticated
system for large high powered computers networks and for large scale applications. It can be considered
a reference model for building general distributed computing environments.
3.5ActiveX & DCOM
To explain the Microsoft technology, we have to do a brief historic excursus. All material regarding
COM technology can be found in the Microsoft Web site (http://www.microsoft.com/COM/).
Object Linking and Embedding OLE, which was introduced in 1991, began as a way to create compound
documents that would serve as containers for blocks of highly structured data--a spreadsheet, a clipart, a
document for example. These containers could embed a fragment of a spreadsheet in the middle of a
word processing document. But along the way, Microsoft added one function after another, placing them
all under that one well-known label. By continually expanding OLE's core capabilities, Microsoft
bloated OLE components and made them inefficient for delivering "active" content to bandwidth-choked
dial-in Internet clients. Contrasted with the monolithic OLE, ActiveX defines a family of interfaces, with
each member of that family meeting a more narrowly focused set of needs. The base of these
technologies is the Component Object Model (COM) and Distributed COM (DCOM) standards.
DCOM (the network side of COM), the base technology for ActiveX and OLE, is a way for software
components to communicate with each other both locally than remotely; this is the distributed extension
for moving data from inside the machine to the Internet world.
It is a binary and network standard that allows any two components to communicate regardless of what
machine they are running on (as long the machines are connected), what OS the machine are running (as
long it supports COM), and what language the components are written in (as long it support deference
and virtual function tables) . These technology was developed by Microsoft for its OS and recently, under
the impulse of CORBA technology, it have started a standardization process for exporting this technology
on other platform (UNIX, Solaris, etc.).
On the other side DCOM technology is the natural evolution of the well known DLL technique and COM
components: DLL are dynamic linked library that permit to Win developer to reuse piece of code inside
Win32 applications and to load it at run time (dynamically). DCOM component are piece of code that
have a standard interface, like the COM counterpart (so you can call some specific method without
knowing the internal structure of the component) and that can be called from wherever application is
both remotely and locally.
At the moment the only platform that uses DCOM is the Windows platform (WinNT, Win95, Win98,
etc.). As we can see from the introduction these technology is suitable for distributed object oriented
programming applications. It is interesting the use of this mechanism inside the Internet Explorer Web
Browser: in that case it implements a code on demand paradigm, because during the loading mechanism
of HTML pages we can automatically download, register and run application object (ActiveX
component).
Language Level. DCOM architecture is not related to a particular language. The only needed
features is the possibility to deference and create virtual function table, to create the necessary framework
for create components and communicating each other.
General purpose object oriented languages like C++, Java, Delphi could use this technology, but today
only a restrict number of languages (all belonging to Microsoft Company) are the concrete instruments
for this technology: Visual C++, Visual J++ and Visual Basic, the first two more suitable for operating
system programming, the third is a more efficient and faster developing instrument for simple front-end
user friendly applications.
Software components are objects that implement a specific standard interface for each particular kind of
applications (all interface inherits from a single interface called IUnknown): ActiveX control, ActiveX
documents, ActiveX container, etc.

Abstract Machine Level. The complete framework needed to built a DCOM system is given by
the Microsoft OSes: each components when instanced it is registered inside the registry database (a
central, efficient database for collect all software and hardware configuration information of a machine);
this registering mechanism can be implemented also for remote objects.
 ActiveX Controls can reside locally on a client machine or they can be downloaded from the Internet.
You can use ActiveX Controls to handle client-side interactions with the user or server side computation
(three tier architecture). An ActiveX Control may be as simple as a button or as complex as a reporting
tool. Since the same ActiveX Controls can also be used inside Visual Basic, you can expect to see a
proliferation of ActiveX Controls that you'll be able to use in your Web pages.

Usually in the Internet application ActiveX components are used to create dynamic behavior inside the
HTML pages: each time in a page there is a special tag (<OBJECT ..> see figure) that refers to an
ActiveX components (ActiveX documents, ActiveX Scripting, etc.), the code of this components is
fetched, registered on the system and run to exploit some particular tasks. Differently from Java Applets
loading mechanism, this fetched code don't need a VM, but it can run directly on windows OS because is
compiled only for this platform.

<OBJECT
ID="NewControl"
CLASSID="clsid:12345678-1234-1234-1234-123456789012"
CODEBASE="http://ourserver/somecontrol.ocx">
</OBJECT>

Example of an ActiveX inserted in a HTML page

At the moment only the tools of Microsoft allow the development of these applications; some
applications like Web Browsers of other company (Netscape) are developing some instruments for
compatibility or they exists some third part add-ons to use COM technology.
The solution COM/Java realized by MS is very interesting: MS developer have design a Java VM
component to embed the VM functionality in any applications using COM interface; moreover some
special tools permit to interface toward Java class as they are COM object and allow communication
between different technologies (ActiveX components, Applets, Java Beans, etc.).
Some security mechanisms (authentication, integrity) have been implemented, but nowadays there are
still some dark holes in the implementations. That is also emphasized by the complete access of the
ActiveX code to the system resources.
The disadvantage of being a single platform technology is an enormous advantage when we have to
develop application only in the windows environment: a complete set of tools is available to develop
efficient applications. Today some embedded system version of Windows OS (Windows CE) is ported to
a vast range of hardware machine (from Palm PC to WinTerminal).

3.6JAVA Beans
This section introduces one particular implementation of the distributed computing using Java:
components architecture programming.
The first two technologies that we have discussed about in the previous sections are a little bit different:
CORBA is a sophisticated platform independent specification and different implementations exist for the
UNIX OS; DCOM is specific for the Windows platform, but some steps for standardization are currently
running; both technologies provides a complex environment both for static and dynamic3 localization of
object components. Java Beans is a very simple solution for static object component in the Java platform.

Nowadays the time to market is one of the main constraint for developing distributed applications: the
solution to that problem is the component architecture, that is a new way to assembly applications using
3
Static and dynamic in this context mean that object are located at compile time or at run time; at the moment only CORBA and
DCOM provides the possibility to locate object dynamically.
 reusable software components. A component is fundamentally a block of reusable code (a button, a slide
bar, but also an editor, a Web Browser) that can be use to built and assembly very complex network
applications; a software component model is a specification for how to develop reusable software
components and how these components objects can communicate each other. Today there are different
component technologies available on the market: ActiveX and Visual Basic from MS, Delphi from
Borland, and Java Beans from Sun.
JavaBeans is a portable, platform-independent software component model written entirely in Java [2]; it
enables developers to write reusable components once and run them anywhere - benefiting from the
platform-independent power of the Java VM. Beans are Java classes that can be manipulated in a visual
builder tool and composed together into runtime applications containers (i.e. MS Word, Lotus Notes,
Browser, etc.). Any Java class that adheres to certain property and event interface conventions can be a
Bean.

We introduce some general aspects of component models before going into the description of Java Beans
[1].
In order for a component model to work, each software component must provide several features:
1. the component model must be able to describe itself: this means that a component must be
able to identify any properties that can be modified during its configuration and also the
events that it generates;
2. the component must allow graphical editing of its properties: the configuration of a software
component is done almost exclusively through control panels that expose accessible
properties;
3. the component must be directly customizable from a programming language (at least a
scripting language);
4. the component must generate events and must provide some other mechanism that lets
programmers semantically link components.
Java Beans supports autodescription through an introspection mechanism, graphical component editing
through a customization mechanism, and linking through an event model. In details Beans use some
characteristics of the Java environment:

• Reflection API and Introspector class, that is the capabilities to interrogate at run time a
Bean about its internal structure;
• Serialisation, that is the possibility to move the Beans inside a network;
• RMI (Remote Methods Invocation), that is the capabilities to call objects methods remotely;
• Java events model, that is Sources and Listerners, for receiving events from the external
environment.

Java Beans relies on Java for its security. The Security model includes intrinsic security mechanism that
protects the user from errors that can result from incorrect type casting or illegal memory access. Also a
SecurityManager provides resource level security that restricts a Java program's access to critical
resources (hard disks, network, video).
And also there are some additional packages provided by Sun or by third company to create a bridge
between Java Beans and other component models, ActiveX for example.

Java, as we can see from the Aglets and Java Beans applications, is not a programming language, but a
complete platform to implement different distributed programming technologies.

3.7Obliq
Obliq of DEC System Research Center, is a lexically scoped, dynamically typed, prototype based
language, designed for distributed object-oriented computations. Computations in Obliq are network
transparent, that is they depend neither on the allocation site or on the computation site, but the
distribution is managed explicitly at the language level.
 Language Level. Obliq has three main characteristics:
* network transparency: any value can be transmitted between hosts, including closures and
object references;
* embedded prototype based: there are no classes and object are created by copying (cloning)
existing objects (the prototypes); in embedded prototyping all methods valid on an object are
contained in the object itself, without using a list of super class methods;
* dynamically typed: type errors are caught cleanly and propagated to the original site.

There are four basic operations on objects:

• Selection/Invocation
• Updating/overriding
• Cloning: create a shallow copy of an object;
• Aliasing: attributes can be redirected to attributes in other object via the mechanism of
aliases.

Objects can be protected against modification, aliasing, and cloning from outside the object using the
protected keyword.
Concurrency is inherent in Obliq; processes can executed independently on distinct server and processes
can spawn new threads locally. To handle concurrent accesses, Obliq supports serializing objects; when
an object is serialized, at most one thread can access an object or run one of its methods at any given
time.
Object migration can be programmed: we use a combination of closure transmission, cloning, and
surrogates. Transmitted closures can use functions from the basic library, but do not otherwise gain
access to names from the receiving site. Names are explicitly exported by passing them as parameters to
the received closures.
Abstract Machine Level. An Obliq computation may involved multiple threads of control within an
address space, multiple address spaces on a machine, heterogeneous machine over a local network, and
multiple networks over the Internet. This is implemented using application server engines that create a
complete object oriented distributed system.
All applications made in Obliq are academic projects: user-interface toolkit, algorithm animation, 3D
graphics are some examples.

3.8Objective Caml (O'Caml)

Objective Caml (O'Caml) is a functional language originating from Caml, a language developed at Inria
(Institut National de Recherche en Informatique et en Automatique) that is widely used in education.
This languages is developed mainly for distributed object oriented application.
One interesting application of O'Caml is the development of a Web Browser, MMM, with the possibility
to dynamically linking and executing O'caml applets fetched from the net. MMM, as a computational
environment, gives to O'Caml code a number of hooks to dynamically interact with the external
environment (user menu access, content decoder, changing the handling of link activation and also
browser cache, browser navigation values).
Language Level. O'Caml includes imperative features (references, assignments) and class-based object
system, all integrated with a functional core.
The main characteristics of O'Caml language are:

• Strong, static polymorphic typing

• Modules system
• First Class (high order functions)
All type error are caught during compilation and primitives error are handled through an exception
mechanism; functions can be passed to other functions and returned as results.
Concurrency is obtained through the use of threads and mutex, while class-based orientation through an
extension of the typing discipline.
O'Caml supports a small number of visibility modifiers for classes and object attributes: a class can be
declared virtual, disallowing any instances to be created, and closed disallowing any subclass to be
derived. Attributes can be declared private, making them inaccessible outside the methods of the defining
class.

MMM Applets are only allowed to use safe variants of the standard libraries: a safe library imports
everything exported from the unsafe original, but it only re-exports a selected subset.

The advantage of O'Caml is a rich language with support for several programming paradigms: functional,
imperative, and object oriented.
 Mobile Agent

We introduce the group of the Mobile Agent using two technologies: Aglets and Telescript. The first one
is a solution using Java, while the second it is a solution provided by General Magic for UNIX
Environment.

3.9AGLETS
The Aglets are Agent Applets developed at the IBM Research Center in Tokio by D.B.Lange; you can
find a detailed explanation of the Aglet architecture in [6] or directly refers to the Aglet Web Page
(http://www.trl.ibm.jp/Aglets).
The Aglet represents the next leap forward in the evolution of executable contents on the Internet,
introducing program code that can be transported along with state information (we will see that the Aglet
mechanism is considered a weak mobile agent mechanism, see previous chapter).
Aglets are Java-based objects that can move from one host on the Internet to another. Aglets can execute
some specific methods on one host and can suddenly halt execution, dispatch to a remote host, and
resume execution there. When Aglets move, they bring with them their program code as well as their
state (data) - state in this case doesn't means the execution state data (program counter, stack, etc.), but a
series of data information variables - weak mobility.
Conceptually, the Aglet is a mobile agent because it supports the ideas of autonomous execution and
dynamic routing on its itinerary.
This mobile agent architecture is completely based on the Java features and uses all the mechanism
embedded inside Java platform to create a complete agents system: object oriented paradigm for hiding
information of the different communicating objects; Serialisation for moving code objects from one host
to the other; security policy using the embedded Java mechanism; Applet-like architecture for manage
the dynamic behavior of agents; network communication using sockets; threads architecture; etc.
The Aglets object model defines a set of abstractions and the behavior needed to leverage mobile code
technology in Internet-like open wide-area networks. The key abstractions found in these model are
Aglets, context, proxy, message, itinerary and identifier.
An Aglets is a mobile Java object that visits Aglets-enabled hosts in a computer network. It is
autonomous, since it runs in its own thread of execution after arriving at a host, and reactive, because of
its ability to respond to incoming messages. The behavior of the Aglets is controlled by a specific set of
interface-methods and the Aglets can react to some exchanged messages: the execution environment
leads the Aglets during all its life calling the specific method implemented by the Aglets. Behavior
supported in the Aglets object model includes creation, dispatching, retraction, deactivation, activation,
disposal and messaging (see figure).
 identifier core

Methods
itinerary
variables

Message
Aglet
Aglet Proxy Aglet Aglet
Proxy

Comunication
Aglet-AgletContext

Figure 19: Aglet Architecture

A Context is an Aglets's workplace. It is a stationary object that provides a means for maintaining and
managing running Aglets in a uniform execution environment, where host system is secured against
malicious Aglets. One node in a computer network may host multiple context with different policy
mechanism for accessing local resources.
A Proxy is a representative of an Aglets. It serves as a shield for the Aglets that protects itself from
direct access to its public methods. The proxy also provides location transparency for the Aglets, that is it
can hide the real location of the Aglets.
A Message is an object exchanged between Aglets and it allows for asynchronous and synchronous
message passing between the Aglets. Message passing can be used by Aglets to collaborate and
exchanged information in a loosely coupled fashion.
A MessageManager allows for concurrency control of incoming messages.
An Itinerary is an Aglet's travel plan: it provides a convenient abstraction for non-trivial travel patterns
and routing.
An Identifier is bound to each Aglets. This identifier is globally unique and immutable throughout the
lifetime of the Aglets.

Context A Context B

Dispatch()
Dispose()
Aglet Aglet
Retract()

Create() Deactivate() Activate()

Class secondary
storage
 Figure 20: Aglets Life

All the security policy of the Aglets framework is managed using the SecurityManager class: for each
host, local users can set the security permissions for the arriving Aglets and limited the access to local
resources; even the memory usage of the Aglets is controlled.
Aglets are suitable for a lot of software applications from business area to network control: accessing
remote database for queries, distributed meeting scheduling, network monitor, electronic commerce are
only few examples of their possible applications.
As we can see in the Aglets Architecture are mixed old and new concepts: interprocess communication
between objects, network transparency, code mobility, global object identifiers, security.
Java is a basic platform to glue all these mechanisms for building a flexible distributed architecture.

3.10Telescript
Telescript of General Magic is an object oriented class-based interpreted language for the development of
large distributed applications .
Telescript is not intended for general purpose programming, but only as a specialized language for
communication. Security has been one of the driving factors in the language design, together with a
focus on strong mobility.
Telescript interpreters (engines) run on each host in a network and accept incoming traveling agents,
which autonomously execute code on behalf of their owner.
Language level. The Telescript language itself is a class based and includes run-time typing. Classes can
inherit from a single superclass, any number of mix-ins and abstract classes which cannot be instantiated.
Classes have two attributes: sealed and abstract. The first one indicates that the class cannot be
specialized, and the second one that the class cannot be instantiated.
Object attributes can be private or public. Private objects can only be accessed from the class itself and
its subclass, while public attributes are unrestricted. The operator protected turns object references into
protected references. The access to objects is also done through unmoved, uncopied, copyrighted and
protected attributes.
Agents itself are processes with a number of properties (telename, owner, sponsor, client, permit, age,
priority) that are used to implement a strictly access authentication and control. When an agent wants to
move in the Telesphere (a network of Telescript engines) invokes the go operation. The ticket is sent to
the remote hosts. If the destination accepts the agent's authority and gives access, the agent is moved with
all its code and execution is resumed in the new place.
Abstract Machine Level. The network is composed of hosts on which a Telescript engine runs; this is a
sort of computing environment that listens and controls access to the site and manage the execution of the
agents. Mobile processes are run in a separate domain and can only interact directly with the engine in
which they run. All interprocess access is mediated by the engine.
Telescript employs an intermediate, portable language called Low Telescript, which is the representation
actually transmitted among engines.
Library Level. Each place (Telescript name for computing engine) has a collection of built-in classes.

Telescript applications consist of Telescript agents operating within a "world" or cyberspace of places,
engines, clouds or regions. All of this are objects. For example, a place is an instance of some class
within the engine whose definition inherits operations which can be called in that place. The top class in
the Telescript's object hierarchy is the "process". A Telescript engine is itself a multitasking interpreter
which can run multiple processes and switches preemptively between them. Agent processes, unlike
place processes, are objects which cannot contain other processes, but they can go from place to place.
 Scripting Languages

In these brief overview on distributed programming environments, we want to introduce a particular

group of computing languages: scripting languages. Although these groups is not suitable to build a
complete distributed or mobile code application, some scripting languages are used to developed some
very specific Internet application. Both the power and the weakness of scripting languages is their
simplicity and their specialization.

3.11Tcl/Tk
Tcl/Tk family is the most representative scripting language present on the market suitable for some
specific code mobility purposes [8]. Tcl (Tool command Language) and Tk (the graphic extension of Tcl)
are a set of C libraries developed for specific high level management computing skills. They are
interpreted languages and they have been implemented for many platforms (all flavors of UNIX,
Windows, McOS, Inferno).
One of the main characteristic is the possibility to embed the functionality of these two product both
inside Internet application (Browser) and inside other languages (C, Prolog, Lisp). Tcl/Tk is a string
based command language and it designed to be a glue that assembles software building blocks into
applications. The flexibility of this technology is related to its implementation: a set of command are
collected inside libraries or packages (Safe-Tcl, Socket-Tcl, Agent Tcl, etc.).
The new and more interesting application of these scripting languages are Tclets. Tclets are piece of code
written in Tcl/Tk loaded through Internet browser and run locally.
Another interesting aspects is that today there are a sort of symbiosis between Java and Tcl/Tk: both
languages claim to be suitable for transmitting executable content over the Internet, but they respond to
different kind of applications.
Sun developers want to create a twin of languages that are complementary for distributed computing
system. Sun developers aim to create a tight synergy between Tcl and Java. The idea is to create an
architecture where the developer can use the right tool for the right job. The architecture is a dual
language environment that is meant to support two very different communities of developers. Java should
be used for creating components, framework, and other core technology that required writing large
detailed systems. Tcl should be used as a glue code, a control language, or other smaller tasks that require
a good deal of dynamism or high level control.
At the moment (see [5]) current deliverable technologies include four items: Jacl is a Java
implementation of Tcl; Tcl Blend allow the (C based) Tcl interpreter to load and interact with the Java
VM and vice versa; the Java package, which is part of both Jacl and Tcl Blend, provides the
communication between Tcl and Java; finally a Tcl Beans for Java Studio.
C, C++ and Visual Basic are the most famous example of this kind of integration: from one side there is
a complete operating system language suitable for high back end application (database engine, Internet
server, etc.), and to the other side an easy-to-use, efficient, specific purpose interpreted scripting language
suitable for simple front end applications.
Other interesting implementations based on Tcl are Agent Tcl that provides a Tcl interpreter extended
with support for strong mobility and Safe-Tcl that is an extension of Tcl conceived to support active e-
mail.

3.12Internet Scripting: JavaScript (Netscape),

Jscript (MS), VBScript (MS), etc.
An overview on distributed computing instruments cannot lack a brief description on the scripting
languages used in the Internet browsers. This languages in general are simple, special purpose, object
 oriented scripting languages designed for developing light interface client and server Internet application
(Scriptlets).
Scripting languages borrow a lot of concepts from advanced programming languages, but because they
are simpler and have fewer features, they are easy enough for non-programmers to learn.
One of the main concern of HTML pages is their static contents; using scripting languages you can create
dynamic contents HTML pages that can be run both on user side and on server side.
They are implemented with external libraries or embedded inside the browser engine: during the parsing
process of the HTML page contents, each times we encounter some special tags, we interpret the code on
the fly. The execution environment in general is provided as a collection of libraries that is loaded
automatically each time we need by the process of Web Browser application.
Scripting code is transmitted on the net either as separate ASCII file or enclosed inside the HTML pages.
The fame of this languages is related to the success of the browser that embeds them (JavaScript for
Netscape, Jscript and VBScript for Microsoft) and to their easiness. Usually the time required to learn
and use this kind of languages is much less than other system languages.
Future development are focusing on the mix of one operating system language to design high efficient
server application and a simple, user friendly, object oriented scripting language. This is the way
followed by Microsoft with Visual C++/Visual Basic/ VBScript and this is the way Sun wants to do with
Java/Tcl-Tk.

3.13Comparisons & Comments

The choice of a development platform is one of the basic problems of the software engineer.
In this chapter we have seen some of the available solutions on the market to build a distributed
environment: some are specific solutions for specific problems (Telescript, Agent-Tcl, Aglets, etc.) others
are general purpose developing platforms for implementing a wide range of applications (Java, Inferno);
none is the best answer to all problems. In this section we want just to outline and compare all these
technologies; in the next chapter we analyze the requirements of the DAB system and we will discuss the
chosen technology for our project.

Paradigm.
As we have seen, some technologies are suitable for some specific mobile code applications. In general
paradigms and technologies are not related: you can implement different paradigm using the same
technology. Once we have chosen a model for our application, we can use some generic developing
platform (like JavaOS, Inferno) or use some specific software solution (Aglets, Telescript, ActiveX, etc.).
In general the choice is related to the goals of the application: time to market, developing tools,
flexibility.
In the following table we try to classify some of the studied technologies [10].

Table 2: Mobile Systems classified depending on type of mobility

Type of Mobility Systems

Remote Execution Java servlets (push) Remote Evaluation Tacoma
Code on Demand ActiveX Java Applets, Tclets Java Servlets (pull)
Weak Migration Aglets Mole Odyssey, Voyager
Strong Migration Agent Tcl Telescript
Distributed Objects DCOM CORBA Voyager, Obliq

Resources
We have to care about the local and remote resources available for computing: these are physical
requirements depending on the target system. For example in a desktop system, resources like CPU,
memory, or storage devices are not a big constraint, while in embedded systems these resources can be
limited.
Also the nature of the network can provide different kind of services: available bandwidth, one way
(Radio, TV Teletext) or two way (Internet/Telecom networks) communication, naming services (SNMP
for Internet), etc.
For these reasons we have to be careful and avoid complex architecture for simple systems.
DCOM, ActiveX, CORBA applications are technologies sophisticated, that require a lot of physical
(processing unit, networks) and extra coordination resources; some flavor of Java (Embedded Java,
Personal Java) and some implementation of Inferno are well suited for embedded systems.

Flexibility
In this context, the flexibility of a system is the capability to adapt to some requirements and to
personalize the behavior of a mobile code solution. For example some internal mechanisms are
sometimes hidden to the programmers: the loading of execution code, the security policy, the
communication channels, the event management, the memory management, etc.
Some mobile code solutions are too Internet oriented and they provide specific services using
infrastructure available only in the computer network system or in specific Operating System.
ActiveX relies mainly on Windows systems; Telescript is a network oriented solution for UNIX
platforms; some Java solutions are also network oriented, as Mole; interpreted languages as Jscript and
JavaScript are related to specific application systems (Browsers).

Security
Security is one of the major constraints for distributed system. From the user's point of view, we need to
control the access to local resources and we want to implement a personal security policy; while from the
provider's point of view we need a flexible mechanism to offer different services and to access all the
capabilities of the local systems.
Today different security mechanisms are available embedded inside the programming platform: from
secure programming languages to digitally signed techniques. Also in these cases we need a flexible
security mechanism, not strictly related to a network system and open enough to include different
scenario.
Some technologies rely on some specific security mechanism and lack flexibility (ActiveX); other have
sophisticated way to control the authenticity of the executed code (Inferno); other solutions give to the
user simple, but flexible ways to implement control (Java).

Target market
The kind of services we want to develop reaches a vast number of consumers. Each consumer is
supposed to have different platform so we have to develop specific target solution.
Portability is one of the main constraint for a final solution and it can be a big problem to implement;
some time designers prefer creating a specific product for a specific developing platform for optimizing
the performance.
ActiveX, OLE technologies are specific platform solutions for the Microsoft Window system; Java is a
general purpose, portable platform for different network system; Inferno is a proprietary product mainly
suitable for high performance network application, but it provides also some portability services (Limbo
language, Inferno abstract machine); etc.

Developing tools
Technical and human resources available on the market are important aspects related to the development.
Technical tools are normal developing instruments, but human resources are all the possible information
channel regarding a particular technology: from paper documentation to practical solutions, from current
ongoing project to future market trends.
Proprietary solutions sometimes don't give all this huge number of information (ActiveX, Inferno,
Telescript). For some other technologies (Java, ActiveX, etc) a vast number of "public" documentation
and overall a vast number of papers are available. These are good channels for testing the robustness of
the technology and see the impact on the market.
 In table 3 we can see for example different mobile code implementations and the relative used
technology [10].

Table 3: Main Mobile Agent Systems (Languages, platforms,etc)

Name of the System Supported Company Availability

languages
ActiveX C++, VB Microsoft
Agent Tcl Tcl Dartmounth College, USA free
Aglets* Java IBM, Japan binary only
ARA Tcl, C, Java University of Kaiserslautern (Germany) free
Concordia* Java Mitsubishi, USA binary only
CyberAgents* Java FTP Software, USA no longer
Facile ML language ECRC in Munich
ffMAIN Tcl, Perl, Java Univ. of Frankfurt (Germany) no
Inferno/Limbo Limbo Lucent tech. binary only
Java-2-go* Java Univ. of California at Berkeley, USA free
Kafka* Java Fujitsu, Japan binary only
Messangers M0 University of Zurich, Switzerland free
MOA* Java The Open Group, USA no
Mole* Java Univ. of Stuttgart, Germany free
MonJa* Java Mitsubishi, Japan binary only
Obliq Obliq DEC Research Center
Odyssey* Java General Magic, USA binary only
Safe-Tcl Tcl
Sumatra* Java Univ. of Maryland
Tacoma Tcl, C, Python, Cormell (USA), Tromso, Norway free
Perl
Telescript Telescript General Magic, USA binary only
Voyager* Java ObjectSpace, Inc., USA binary only

Practically, the choice of the programming language and the flexibility of this instruments is very
important. Time-to-market is a variable that we have to consider if we are thinking to a competitive
product.
The tables that follow are a series of comparison at the programming language level between the
mentioned technology.
In table 4 we can see a comparison between different platform and their general characteristic: object-
oriented paradigm, concurrency model, kind of mobile code implemented, the security architecture used
and the trusting mechanism of the moving code.

Table 4: Comparison between mobile code Technologies features (General View [11]).

Language OO Concurrency Mobility Safety Security Trust in the object code

Model
Java √ √ Fetch √ PL/OS Verified object code
O'Caml √ some Fetch √ PL Signed object code
Limbo √ Fetch √ OS Signed object code
Obliq √ √ Agent √ PL No provision
Telescript √ √ Agent √ PL Secure network
Safe-Tcl Fetch √ OS Not applicable
 In table 5 we go in details about the specific internal features of the programming languages used to
implement the object paradigm. These features are important to evaluate the flexibility of a programming
language.

Table 5: Class and attributes protection and the keyword used (Language features [11])

Protection Offered Java O'Caml Obliq Telescript Limbo

Class Protection
No subclass final protected sealed
Subclass cannot add closed
methods
No instances abstract virtual protected abstract
Visible only in the same private not applicable not applicable not applicable
package
No outside update protected
No aliases NA NA protected NA
Mutual exclusion serialize
Attributes protections
No restriction public NA NA NA NA
Visible only in the same protected NA NA NA NA
package or in subclass
Visible in subclasses default NA private NA
Visible only in defining private private NA default
class
Runtime protected protect
reference
Mutual exclusion synchronized

Efficiency
Here for efficiency of a technology we refer to the measure of how the developed solution is suitable for
our purpose, using the right amount of resources: you can measure efficiency in term of execution speed,
cost of the used resources, quality of the service you want to deliver, maintenability of your application.
3.14A Technology for the DAB System
The brief overview about the distributed computing technologies is the base for a more specific
discussion about the choice of a suitable technology for the DAB system.
In this section we try to list the requirements that the DAB system imposes for choosing a developing
platform. The main goal is to develop a mechanism to download application using DAB channel.
Java is the right platform mainly for its portability, flexibility and for the big consensus in the computer
industry: we will analyze in more details the reasons of our choice.

We have collected the basic requirements in a series of main topics:

♦ Standardization
♦ Security
♦ Acceptance
♦ Multimedia & Distributed Computing
♦ Maturity
♦ Implementation Aspects

for each items we will discuss in details the DAB requirements and the characteristics the developing
platform is supposed to have. Follow immediately for each items the relationship with the Java
technology.

Standardization. The DAB system is a new technology for radio communication. Although this
network can be seen as an extension of the Internet network, there are some fundamental differences
between the two systems. The nature of the broadcast channel and the characteristics of the radio services
are not so dynamic as computer network technologies. The systems and the tools used in the radio system
are supposed to be available for a long period and overall they are supposed to stable.
Standardization for radio systems is a must. The choice of a new platform to develop digital radio
services must be the result of an agreement between different parts: standardization agencies (ITU, ETSI
- EUREKA 1474), producer companies (Sony, Panasonic, Hitachi, Grundig, Borsh) and service providers
(BBC, SWR, SWEDISH Radio).
The broadcasting nature of radio (one signal for all) imposes fundamentally some requirements about the
independence of developing environment. We also can derive some constraints about the complete
availability of the needed documentation, the stability (in terms of versioning and maturity - see also
the subsection about Maturity) of the developing tools and general acceptance by all the DAB
community.

Java, in this scenario, is becoming a standard de facto for distributed application in the computer
industry: the number of users, software companies, research centers that work in this new platform is
enormous.
Sun is willing to follow the ISO/IEC patent policy or extend the terms of its current patent policy to cover
implementors of the International Standard ( see
http://www.javasoft.com/aboutJava/standardization/); they realize the added
value to the marketplace that de jure standardization can represent. For example, some countries and

4
ITU stands for International Telecommunication Union; ETSI stands for European Telecommunication Standards Institute
companies still restrict the public procurement of goods and services in the information technology
sector to products based on de jure standards. These aspects can be a good issue for the choice of a
technology in the DAB community.

Security. In a distributed programming environment security is one of the building blocks. For the
DAB system we can list the following security requirements: authenticity, availability, safety, runtime
control, scalability, terminal protection, user policy.
It is very important to have the possibility to control the access to the terminal resources: from the
provider-side it is important to access how many resources are possible; the user has to be guaranteed a
complete personal configuration of his own terminal. These security mechanism can be set both at start
up of the services and during execution (runtime control).
A very robust mechanism is also necessary to avoid hardware crashes at the application level: it is not
allowed that an application could crash the receiver device.

Java has a very flexible security mechanism. You can control your application at different levels (from
the verification of the bycode to the security manger runtime control), both statically before executing
Java application and dynamically at run time. The Java API includes different packages to use different
security mechanism (authentication, certification, encryption).Java relies on a Garbage Collector
manager to make safe the memory management, the basic requirements for every modern distributed
technology.
The model is robust and it can be adapted to different medium.

Acceptance. There are many issues related to the general acceptance of a technology for the DAB
system. First of all the chosen technology ought to be accepted by the whole DAB community as a
common platform to develop DAB services. In this context we have to consider some aspect related to
the market pressure. As market pressure we can consider all the interests involved in the DAB services:
producer companies, standardization agencies, but also user acceptance, service providers, integration
with other media.
It is very important that the choice is accepted as a general solution by all interested parties.

Java is collecting a large consensus: in the computer industry (Sun, IBM, HP, ORACLE, MS), inside the
academia centers and inside research centers (Sony, Mitsubishi). Programmers are using Java for
develop different kind of distributed applications for network system, but also for embedded devices.
Java is a buzz word in the computer world.
Why Java is so diffuse ? Fundamentally because it is an easy, a flexible and a powerful language. Its
abstract machine is really platform independent and there are implementations for almost all platforms:
HP-UX, UNIX, Solaris, SunOS 4.1.3, WinNT, Win95, Win3.1, AIX, Digital UNIX, Inferno for OSes; Intel,
Sparc, ARM, JavaChip for CPUs.
An increasing number of software vendors are including Java, or Java-based components, as a strategic
part of their systems. For example, the leading browser vendors (Microsoft, Netscape, and Sun) support
Java applets. The leading database vendors (Oracle, IBM, Tandem, Informix, etc.) are collaborating on
standards for embedding SQL in Java and Java within the database engine. A leading smart card vendor
(Schlumberger) offers a subset of the Java operating environment on their smart card so that smart card
application developers can develop applications using standard Java development tools. Numerous other
vendors in more non-traditional computing environments (e.g., embedded devices or real-time operating
systems) are in the process of supporting the Java environment.
These large number of Companies are investing in Java technologies and overall Java seems to be the
flexible network platform want to be !

Multimedia & Distributed Computing. The DAB platform is supposed to give all
necessary tools to create a distributed system, but also to give all possible instruments to integrate
different media.
In the first case, we consider the traditional way to build a distributed system (client/server), but overall
the possibility to create advanced code on demand or agent solutions; we need a complete framework to
bind dynamically resources both locally and remotely.
The second case is more related to the revolutionary introduction of the DAB system: the new digital
channel opens great possibility for the integration of all the media: DVD systems, Internet services, home
computer network, telecom services. The developing platform is supposed to have all the means to
integrate a wide range of multimedia applications.

Java is born as a network technology with a strong attitude for multimedia applications. Inside the Java
API there are all the functionality for manipulate multimedia objects: images, sound, speech, animation,
Internet protocols.
Java RMI API provides a rich set of libraries to create sophisticated network applications: agent
systems, software components, client/server. Java gives designer flexible and powerful mechanisms to
implement their own download mechanism (ClassLoader) for retrieving code and resources from any
medium.
At the moment there are a large number of applications developed in the Java platform: Hot Java,
Jeeves, Beans, Aglets, Mole, Voyager, Odissey, Kafka, Concordia.

Maturity. The maturity of a technology is related to a huge number of aspects. In primis the
developing framework is supposed to have reach a good stability in terms of the formal description of the
system (language, abstract machine, API, runtime system, protection mechanism), but also the maturity
of the product on the market in terms both of acceptance and the dominance.
It is very important to have a lot of documentation on the problems related to the developing platform:
the maturity of a technology also refers to the number of good solutions available on the market, the
number of the developed or developing projects in different areas: software companies, but also
universities and R&D laboratories.

Sun shipped Java around 1995. Java is one of the first technology to use the Internet world as a
development laboratory. In this short period in all areas of computer industry Java have found its
particular application.
The most interesting thing about Java maturity is the fact that not also Java is a market product, but
academia centers have a huge number of projects about the Java platform: Java is not the best platform,
but its implementation includes all the aspects of a modern programming environment: object oriented,
network based, flexible enough to be applied from embedded system to high end server, from smart card
to network computers.
Java provides developing tools, but also a complete specification documentation for the language and
for the abstract machine: this formalisation process has been started from the beginning and it is one of
the basic reason of the success of Java.

Implementation Aspects. Basically the chosen technology have to be flexible: but what does
flexible mean? We have yet outlined that the DAB system is not a traditional network: researchers and
programmers need a developing platform in which they can control completely the loading mechanism,
the security policy both at runtime, the execution environment, the resources binding, the communication
mechanism.
Some platforms hide these aspects, while some other completely miss. In the case of abstract machine
implementation (Java, Inferno) there is a need of a standardized interface to the native operating system.
The extensibility of the system API is also another requirement: a new system needs new capabilities.
Some technologies offer a standard way to add new functionality to the core API and to the system itself.

Java is a complete portable platform and flexible for implementing different network applications. The
Java API provides a series of objects to control the behavior of the whole system: securityManager,
classLoader, Thread, etc.

Some critics about the Java platform are on the overall performance; we mention some of the problems:
 • the Java VM is a stack based machine, specifically optimised for small devices;
• the interpreter engine lacks performance; just in time compilers seem to be a solution, but
the memory requirements increase;
• garbage collector management is a big constraints for small embedded devices;
• non real time capabilities are a problem for the usage of Java in critical mission and
advanced multimedia applications;

♣♣♣

Comparing mobile code technologies is a hard task. The world of distributed computing is today very
dynamic and heterogeneous. The right choice of a programming environment is a typical problem of
software engineer, but in this case we have to consider other branches as telecommunication, security and
multimedia.
As we have introduced in the first chapter, our problem is to find a new technology to implement the best
environment for the DAB radio system. Today and for the next years, the right platform seems the Java
platform.
 "… every new beginning
comes from some other new beginning end …"
(Pop Songs)
Chapter 4 Java

“The Future of Computing

depends on Operating Systems
with integrated Browser"

“BYTE Editorial - July 1998” (Mark Schlack)

Java is not only an object-oriented programming language. The "Java world" consists of three main
components:

◊ the Java programming language

◊ the Java Virtual Machine (OS)

◊ and the Java library (API)

We have already discussed some features about the programming language in the last chapter, but for
more details about these issues see [1], [2] e [3].
 Our focus will be on the last two components to point out what are the fundamental basis and the wide
capabilities of this new architecture; most of the aspects are related to our purpose of building a
download platform for a specific system (I will not mention yet the specific requirements for our project,
because this chapter should be available for general dissertation about Java technologies).
The documentation on Java VM is vast and we can not go in deep for all the aspects: we will focus our
attention on some specific tools that can be well suit for our comprehension and for our goals.
The majority of the material used in this chapter can be found in some books [1], [2], [3] in many papers
and articles [4], [5] ,[6], [7], [10] e [12]. In this chapter we always refer to the JDK 1.1 specification.

4.1Java Architecture
Java has been described as a revolution in computing world. This high-level programming language was
developed by Sun Microsystems and was designed for handheld devices and set-top boxes. Java was
originally called Oak. Because the Oak product never made it to the market, in 1995 Sun changed course
and went after the Internet, changing the product name to Java. At the beginning Java was developed
with two ideas in mind:

an Internet instrument for a distributed and safe computing;

a portable platform to compete against to the Microsoft windows OS.

Let's start from the first aspects. The explosion of the Internet world gave Sun developers the
opportunities to move their goals towards the network and browser applications. Internet is a new "arena"
and a new market for the most recent generation of software applications and sometimes is the testing
place where new solution are used and developed.
The second aspect is related to the commercial purpose of Java: not less important than the technology
aspects, Java is a product developed to fight in the distributed applications and in the OS software
market. Sun Microsystems is an Hardware and Software company oriented on high end network server
systems for business applications.
The market scenario for Internet applications is very complex: different OSes, a huge number of
development tools for each specific platform, wide range of open possibilities for Web integration of
embedded systems, a growing population of "different skills" Internet programmers, the explosion of
multimedia applications, etc.
Java is a well suitable technology for Internet applications that has all the characteristics of a modern
programming instruments:
• a modern dynamic object oriented language;
• safe and secure system;
• a virtual machine platform;
• multithreading architecture;
• a ready to use set of APIs for a wide range of applications (from office computing, to
embedded system requirements, to multimedia applications).

This are only few of the main aspects of the Java technology and every day new solutions exit from the
hat of the Sun developers. In the next sections we will go in details for each specific element of the Java
architecture.
4.2Virtual Machine
The Java virtual machine is the cornerstone of the Java programming language, it is the component of the
Java technology responsible for Java cross platform delivery, the small size of its compiled code, and the
Java ability to protect users from malicious programs.
The idea of a machine independent program representations is quite old and goes back to the year 1960
with the UNCOL language [8]. The design of the Java VM has been strongly influenced by P code, the
abstract machine used by many Pascal implementations. The VM is described in [2]: this publication is
an high-level description that can be implemented in different way depending on the underlying OSes
(Sun has provided also a complete JavaOS, an OS written completely in Java).
Basically the Java Virtual Machine, or JVM, is an abstract computer that uses assembler like source code
and runs compiled Java class file. The JVM is virtual because it is not only implemented as an abstract
software layer on top of a real hardware platform (x86, PowerPC, Mips, ARM) but it is a complete
operating systems (Win32, Solaris, UNIX, Linux) that provides a complete set of API for building
general purpose, graphical applications.
Glancing the internal architecture of Java VM, we start our description from the virtual basic
components.
The virtual hardware can be divided into four basic parts:

* the registers,

* the stack,

* the garbage collected heap, and

* the method area.

These parts are abstract and are implemented directly by software.

The JVM has a program counter and three registers that manage the stack. The stack-oriented design
helps keep the JVM's instruction set and implementation small: the number of instructions to move data
to and from registers and memory is less than other complex architecture, in which the high number of
hardware components need a higher number of instructions to manage and coordinate all moving data.
For example in high end computers, generally there are a set of instructions for moving data for specific
registers, for different memory access, for data manipulation.
This architecture is considered well suit for embedded systems, where the underlying hardware
architecture have often no enough physical resources. On the other side someone thinks that this is a
disadvantage, because on big and high system this architecture can not be implemented in an very
efficient way [8].
In details, the JVM uses a program counter to keep track of where in memory it is the currently
executing instruction. The other three registers - optop register, frame register, and vars register -
point to various parts of the stack frame of the currently executing method.
A JVM can support many threads of execution at once, therefore each thread has its own program
counter register. Therefore, at any point, each thread is executing the code of a single method. If that
method is not native (code of the underlying hardware machine, i.e. C, C++, Assembler), the PC register
contains the address of the Java VM instruction currently being executed; if the method is native, the
value of the JVM's PC register is undefined.
The Java stack is used to store parameters for and results of bytecode instructions, to pass parameters to
and return values from methods, and to keep the state of each method invocation. The state of a method
invocation is called its stack frame. There are three sections in a Java stack frame: the local variables, the
execution environment, and the operand stack. The local variables sections contains all the local
variables being used by the current method invocation: it is pointed to by the vars register.
The execution environment section is used to maintain the operations of the stack itself: it is pointed to
by the frame register. The operand stack is used as a work space by bytecode instructions; it is here that
 the parameters for bytecode instructions are placed, and the result of bytecode instructions are found: the
top of the operand stack is pointed to by the optop register.
The execution environment is usually sandwiched between the local variables and the operand stack. The
operand stack of the currently executing method is always the topmost stack section, and the optop
register therefore always points to the top of the entire Java stack.

The size of an address in the JVM is 32 bits. The JVM can, therefore, address up to 4 GBits of memory,
with each memory location containing one byte. Each register stores one 32-bit address. The stack, the
garbage-collected heap, and the method area reside somewhere within the 4 GBytes of addressable
memory (the exact location of these memory areas is a decision of the implementers of each particular
JVM). The method area, because it contains bytecode, is aligned on byte boundaries. The stack and the
garbage collected heap are aligned on words (32 bits).
The Heap is where the objects of a Java program live. Any time you allocate memory with the new
operator, the memory comes from the heap. The Heap is shared among all threads. The Java language
doesn't allow you to free allocated memory directly. Instead, the runtime environment keeps tracks of the
references to each object of the heap, and automatically frees the memory occupied by objects that are no
longer referenced (garbage collection process).
The Method Area is analogous to the storage area for compiled code of a conventional language, or the
text segment in a UNIX process: it is the place where the bytecode resides.

Stack

local variables

execution env.

program operand stack

counter

optop Method Area

register
frame
register 4 GB
vars
register

Heap

Figure 21: Java Virtual Machine Memory Architecture

4.3The Class File Format

The Java compiler, like any compiler, takes your program's source code and translates it into machine
code and binary symbolic information. In traditional systems, this data would be stored in a object
specific assembler format file for later use and execution on a specific platform; in Java's case, it is
placed into separate .class files for each class or interface in your source code and the code is related to
the JVM abstract architecture, so the same for all platforms.
Before going into a detailed analysis about the structure of the Class, it is necessary to introduce briefly
how are the ways to manage the bytecode.
Today for running Java Software are three alternatives are available:
 ◊ Java interpreters

◊ Just-in-time compiler

◊ Java chips

The first one, like a translator at the United Nations, translates Java bytecode into native instructions the
CPU understands. Interpreters converts bytecode on-the-fly and must process the same code over and
over again when you run the Java program. It usually runs slowly, sometimes at only 3-10 percent of the
speed of compiled C-code.
Just-in-time (JIT) compilers translate Java bytecode into native code like interpreters do, but they don't
have to translate the same code over and over again, because they cache the native code and they
optimize it. Some blocks of code are translated in native code and moved in a cache: each time we
execute these particular blocks, the JVM executes the native code. This can result in significant
performance improvements, but sometimes a JIT compiler takes an unacceptable amount of time and
memory to do this job.
Java chips are dedicated Java processors, that is processors that run directly bytecode.

Byte Code

Byte Code JIT compiler

binary code Byte Code

Interpreter

Native OS Native OS Java OS

General CPU General CPU Java chip

• Slow • Compiler fast • Fastest

• Medium Memory • Large Memory • Small Memory
FootPrint FootPrint FootPrint
• Compatiblity • VM Optimize for
specific platform

Figure 2: Three way to crunch Java bytecode

What is a class file ? Fundamentally a .class file contains bytecode to be executed and a large amount of
symbolic and typing information to manage dynamic loading and linking. Class files are based on a
linear, record based organization. They follow a rigid five-part format, yet allowing significant flexibility
in each section; this parts are:

Constant Pool,
Class Descriptor,
Fields,
Methods
and Attributes Areas.
Each class begins with a magic number and version information, followed by a constant pool, a class
descriptor header, fields, methods, and finally an extension area. This data informs the JVM about to
resolve internal and external class references, and also allows it to verify the security and integrity of
classes.

All multibyte data types are in big-endian byte order (most significant byte first). Information is
generally written to the class file with no space or padding between consecutive pieces of information;
everything is aligned on byte boundaries. This helps keeps class files small so they will be aerodynamic
as they fly across networks.
All classes are loaded and linked dynamically from two sources: the first is the primordial class loader
(the loader embedded inside the Java virtual machine) loads classes from a specific directory set with the
CLASSPATH variable; the second is the implemented ClassLoader class used by programmers (see
next section for details). In an embedded solution some VMs implement different loading mechanism:
for example in the network computer classes are loaded from the network; in embedded devices classes
could be loaded from ROM memories.
The virtual machine loads the code of the first class, verifies the contents before preceding, resolves all
the internal classes used and loads all the necessary classes. This load-verify-link process mechanism is
executed dynamically at loading time and whenever it is necessary during execution time. For improve
performance the verification mechanism could be suspended for internal system classes (from
CLASSPATH).
In the UNIX and Windows platform the start up process is started loading the execution environment (a
set of dynamic C libraries that contains the Java VM implementation), setting all the needed information
(CLASSPATH, Java version, runtime parameters as stack depth, etc.) and initializing the runtime
resources (descriptor, stack, etc.): the name of the first class is passed and the loading mechanism is
executed.
The Java VM is a multithreaded process. At start up the following threads are executed:
* the garbage collector,
* the thread to execute finalizers,
* an idle thread to fall back on when no other work need to be done,
* the thread that interprets the bytecode and
* the main method thread of the loaded class
* for each new thread object create in the main class it create a separate thread.
The JVM distinguishes between deamon and non-deamon threads [4]. At start up all the thread are
deamon threads, except the thread that executes the main method; when the AWT toolkit is initialized, a
non deamon thread is started that dispatches events and calls into call-back code provided by the
application. If all the remaining threads turn out to be deamon threads the JVM exits.
 VM Application Deamon Threads Non Deamon Threads

starts
spawns

main method
Garbage Collector

Clock Handler

Idle Thread

Finalizer

new Thread class

VM Application
stops

Figure 22: Threads in the VM

4.4Loader: How Code Born !

All these previous features are related to the skeleton of the Java VM: things that you ought to know, but
that you can touch !
One of the interesting things that we can touch is the loading mechanism of Java code: the class loader.
In general, a Loader is an OS utility that copies programs from a storage device (hard disk, floppy for a
computer, ROM for embedded devices) to the main memory (RAM), where they can be executed: in
these sense the loader defines the application's policy describing where and how to download executable
code. Most loaders inside OSes are invisible to user and sometimes to developers; you cannot directly
manipulate them, but OSes use them when necessary.
Java has special abstract classes, called ClassLoader and SecurityManager, in which it embeds
all the features related to the loading mechanism and security policy. Part of this classes are
implemented using native mechanism, but with the inheriting technique we can specialize its behavior to
control exactly part of the loading mechanism. The Java runtime has two distinct ways of loading a new
class: the default mechanism is to load a class from a file on the local host machine (CLASSPATH) and it
is embedded inside the JVM C-library; any other way of loading a class requires the ClassLoader.

In JDK 1.x and 1.1, basically to load an external class file we need at least its image in a byte buffer; we
don't care about the source of this data: from the network, from a optic disc, from a radio channel. All we
need is a Java byte array buffer in memory.
In Java 1.1.x we consider two groups of class code: trusted and untrusted. The former is composed of
all the classes that you can find in the CLASSPATH, while the latter are all the rest of the class you can
use (loaded from network, from a specific path inside the classLoader, etc.). Trusted classes are
allowed to do all (!!!!) while the other group cannot, for example, use native code; and also all critical
accesses (to the network, to the file system, to the runtime environment) are controlled by the
SecurityManager. In fact with the help of a securityManager you can control a set of actions
to access some particular resources (network, file system, instanziation of particular classes, the
classLoader itself, the SecurityManager).
Normally, the Java VM loads all system classes from the local file system in a platform dependent
manner. For example, on a UNIX system, the VM loads classes from the directory defined by the
CLASSPATH environment variable; but in some embedded JVM implementation classes can be loaded
from ROM memory.
We can think of a class loader as a door-keeper that controls every class we need to execute a Java
application. During the class loading it resolve the needed class name (control the identity), it loads it (let
it enter in the building) and registers it (if someone else need it again) on an hash table (guests books - so
called namespaces). When we use a class loader to load a class, all the internal needed classes are loaded
by the same class loader.
A Java application can use two types of classLoaders: a primordial class loader, embedded in the
basic Java API that use native method, and a subclass of the classLoader object.
We analyze in detail what are the main steps to implement a custom class loader (see fig 3).
A class loader is a subclass of java.lang.ClassLoader. The only abstract method that must be
implemented is loadClass(). The flow of loadClass() is as follows:

1. Verify class name

2. Check to see if the class requested has already been loaded.
3. Check to see if the class is a "system" class.
4. Attempt to fetch the class from this class loader's repository.
5. Define the class for the VM.
6. Resolve the class.
7. Return the class to the caller

These basic steps can be used to perform custom control upon class name, class code, class sources.
Moreover we can see how you can manage and enter in the security architecture of the Java VM; we will
see that this mechanism is basically what we use to load applet from Web Browser.
 import java.util.Hashtable; Name
Nameofofclass class
... Hash table to control Namespace
Hash table to control Namespace
private Hashtable classes = new Hashtable();
public Class loadClass(String className) throws ClassNotFoundException {
...
return (loadClass(className, true));
1)
1)Verify
Verifythe
theclass
className
Name
We can control the class name string
} We can control the class name string
public synchronized Class loadClass(String className, boolean resolveIt)
throws ClassNotFoundException {
Class result; 2)
2)already
alreadybeen
beenloaded
loaded??
byte classData[]; If it is inside the Hash table
If it is inside the Hash table
result = (Class)classes.get(className);
if (result != null) {
return result; 3)
3)System
Systemclass
class??
} We use the primordial class loader
We use the primordial class loader
try { that in genral load classes from CLASSPATH
that in genral load classes from CLASSPATH
result = super.findSystemClass(className);
return result;
} catch (ClassNotFoundException e) { 4) Custom way ...
} We load the class in a custom way
classData = CustomFunction(className);
if (classData == null) { public class Example {
throw new ClassNotFoundException(); public class Example {
public static void main(String args[]) {
} public static void main(String args[]) {
CustomClassLoader sc = new CustomClassLoader();
result = defineClass(classData, 0, classData.length); CustomClassLoader sc = new CustomClassLoader();
Object o;
if (result == null) { Object o;
Class c;
throw new ClassFormatError(); Class c;
String tst = "ClassName";
} String tst = "ClassName";
try {
try {
if (resolveIt) { 5)
5)Define
Definetha
tha c = sc.loadClass(tst);
c = sc.loadClass(tst);
resolveClass(result);
}
class
classfor
forthe
theVM
VM
o = (c).newInstance();
o = (c).newInstance();
We transform byte stream ((‘ClassInterface’) o).’ClassMethod’("none");
classes.put(className, result); We transform byte stream ((‘ClassInterface’) o).’ClassMethod’("none");
in a class object } catch (Exception e) {
return result; in a class object } catch (Exception e) {
}
} }
}
}
} 6)
6)Return
Returnaaclass
classobject
objectthe
theCaller
Caller

Figure 23: Basic class loading mechanism

In example of figure 3 we see that the loadclass() method has two implementation: one for the user
interface, to which we pass as argument only the class name and the second, that is called from the first,
to set the resolve flag.
The security Manager is a class in which we can specify the security constraints related to the use of the
physical resources: access to hard disk, open network connections, use of native libraries. You can create
your own Security Manager inheriting from the class java.lang.SecurityManager and set it
using

System.setSecurityManager(YourSecurityManager s);

Using this technique you can trigger the loading process of your Java application. We can define our own
securityManager just once in the main java application: each successive attempt to set the
securityManager will throw an exception.
Basically the Java VM takes as input the name of the main class file and the directory where it can find
the system classes (we will see in more details in the next sections); then it starts running the code from

static public void main(String s[])

If you want to configure the loading process you can load an intermediate class in which you use the
mentioned special classes (class loader, Security Manager, etc.), but also you can use some special tools
classes to load a jar file (zipped Java files), object images stored on HD, or code from the network.
 java.class arg1 arg2 .. argn Applet.class par1 par2 .. parn jarfile.jar

Java file Java Applet Jar file DAB Java ?

Jar
Reader
DAB
Loader
Applet ... & Viewer
Viewer JarReader.class jarfile.jar

AppletViewer.class Applet.class par1 par2 ..

run the “main” static method

Java Virtual Machine and receive a String array for
arguments

Example of Java Loading Mechanisms

Figure 24: Java loading mechanisms

In the last release, Java 1.2 beta, something is changed in the delegation model of the ClassLoader and
some methods have been added: these changes are backward compatible.
The new delegation model provides a consistent and well defined search policy for loading classes and
resources. The basic idea is that every class loader has a parent class loader: when loading a class, a class
loader "first" delegates the search for the class to its parent class loader before attempting to find the
class itself; the default parent class loader is the system class loader.
The loadClass() method in ClassLoader performs these tasks, "in order", when called to load a class:
* if a class has already been loaded it returns it (hash table)
* otherwise it delegates the search for the new class to the parent class loader
* if the parent doesn't find the class, loadClass() calls the method findClass() to find and load
the class.
These mechanism is flexible, but at the same time is more secure of the implementation of Java 1.1; in
addition to the extension class loading it gives additional flexibility for expanding the Java API in a safe
way (see Expanding the Java API section).

4.5Garbage Collector
The Garbage collection technique has been introduced in the programming environment to reduce the
risk related to the dynamic management of memory. In a distributed environment this tool is a basic piece
for building safe applications: the code sometimes arrived from unknown site and it can cause big
damage voluntarily or involuntarily [5].
This protection mechanism has been introduced for the main programming languages as an additional
library (C++, C); in Java garbage collector is a fundamental piece and every Java implementation has to
offer this service.
The Java runtime system relies on garbage collection to automatically identify and reclaim object no
longer in use. Garbage collection doesn't alter the behavior of an application written in Java, with the
exception of classes that declare a finalizer method. Finalizers are executed right before objects found to
be garbage are discarded, giving you a chance to explicitly release non memory resources the class uses.
Tricky finalizers may resuscitate an object by installing a new reference to it, but finalizers are execute
only once. This garantees that objects may be brought back to life only once. Beginning with JDK 1.1,
 data belonging to classes is also garbage collected, allowing unused classes to be automatically discarded
(this happens whenever their class loader gets recycled). System classes are never garbage collected.
The initial set of roots of a Java run time are

* the live thread objects,

* system classes (i.e. java.lang.String),
* local variables and operands on the JVM stack,
* the reference from the JNI,
* pending exceptions and
* the reference of the native stack.

The garbage collection code is executed in a separate thread when the system runs out of memory or
when System.gc() is explicitly invoked. The collector may also run asynchronously when it detects
that the system is idle, but this may require some support from the native thread package. In any case,
the execution of the garbage collector halts all other application threads and scans the entire heap: this is
a big problem for Java embedded system, because the GC can introduce too long delays.

4.6Java language: a deep sight

We will focus on some of the big characteristics of the Java programming language.
Exception
Basically exceptions allow you to smoothly handle unexpected conditions that occur as your programs
run; embedded inside the Java execution architecture there is a flexible, object oriented exception
management implementation. There are errors that arise during normal computation caused by external
or internal malfunctionalities: for example an I/O access abort (both on network, but also on HD), an
array out of boundary access, a permission deny access, etc.; all possible exceptions in Java are collected
and managed by a robust exception mechanism and programmers can control, in a easy way, each
particular aspects of error handling.
Exception occur in Java either implicitly or explicitly. Typical implicit exceptions are references to the
null pointer, an array index out of bounds and division by zero. Exceptions also can be raised explicitly
with the throw instruction.
For example when we have to perform some special actions inside a critical method (for example I/O
access), we declare that the method can throw a particular exception

public void MyFunction(void) throws SomeKindOfException{…}

and we close each occurrence of this method inside a special section (see figure 5); if an exception is
thrown we can handle in a smoothly way inside the catch block; if no catch close handling an exception
can be found, then the current thread is terminated, but only after all finally clauses have been executed
and the method uncaughtException has been invoked for the ThreadGroup that is the parent of
the current thread [2].
 Critical
Criticalregion
region
try { We use some particular method
try { We use some particular method
... that throws exceptions in case of unexpected
... that throws exceptions in case of unexpected
} conditions
} conditions
catch (Exception e) { try {
catch (Exception e) { try {
... File f = new File(‘someFile’);
... File f = new File(‘someFile’);
} }
} }
catch (Exception e) {
catch (Exception e) { Catch
Catchregion
region
catch (IOException e) {
catch (IOException e) {
... We trigger all the thrown System.err.println(..);
... We trigger all the thrown System.err.println(..);
} error exceptions }
} error exceptions }
... finally{
... finally{
finally{ f.close();
finally{ f.close();
... }
}
... Finally
Finallyregion
region
}
} In case the exception is sent to super classes,
In case the exception is sent to super classes,
before leaving the critical region,
before leaving the critical region,
we can do something !
we can do something !

Figure 25: Exception sections tecnique.

Concurrency
Another requirement for a the modern platform is the possibility to develop applications using
multithreading techniques: that means the possibility to have main process applications and inside the
same memory space execute separate light weight and independent execution units. In general we
distinguish two different kind of multitasking: preemptive and cooperative. In a cooperative multitasking
scheme, the amount of time a task is allowed to run is determined by the task, whereas in a preemptive
scheme, the time is determined by the operating system.
Threads are integral part of the Java programming language. A thread implementation includes the
creation, execution, switching, killing and synchronization of threads. The JVM specification also states
clearly that each object has a mutex (a data structure to synchronize access to common resources)
associated with it.
Java threads can be implemented using threads provided by the host operating system, as user-level
libraries, or as a combination of the two and there is not a specification of the kind of multitasking
(preemptive or cooperative). For example Sun and MS implements two different policy of multitasking,
because they use different base implementation for the thread mechanism.
From the point of view of the users this means a more user friendly and dynamic interface, from the
hardware point of views means running independent execution units on every processor available in a
parallel-multiprocessor machine. Java resolves that problem in a very simple and safe way for
programmers.
The Java API offers a inheritable class java.lang.Thread and an interface, Runnable, to develop
easily a multithreaded environment.
Each thread in the Java programs corresponds to an instance of the java.lang.Thread class: for building a
separate thread, Java classes are supposed to inherit from java.lang.Thread or to implement the Runnable
interface; programmers have to implement the block of code in a run() method, and each time you want
to create a separate thread you have to call the start() method of your class. Additionally the Java
environment provides a set of methods to control the dynamic in a multithreaded program. These are
methods to change and to control the thread states and methods to notify information between different
threads.

Serialization
One of the main problems for distributed environments is the possibility to move data throughout
different memory spaces located on the same machine or to different machines in the network.
Serialization is a technique implemented for representing the state of Java objects in order to reconstruct
the object itself once it is moved to a remote machine. This mechanism is often called marshaling and
unmarshalling technique: in details it means that complex structure as array, C struct, C++ objects are
represented in a single process space using pointers to some memory location; when you have to move
this component towards other process spaces, we have to think of a way to rebuild all the structure (in
this sense we serialize because we create a stream of information that represent the object itself). Many
of the common Java classes implements already a serialisable interface (java.lang.*, 
java.util.*).
Most of the distributed programming applications written in Java use these capabilities: RMI is the most
well known mechanism, but also the Agent applications make wide use of this features.

RMI
Sockets communication is the common way to move data throughout the network for low level
communication. Java has a set of classes to open and manage stream (TPC) and datagram (UDP)
connections. Java has also a complete set of ready-to-use classes to implements more sophisticated
network services. RMI (Remote Method Invocation) is the object oriented implementation of the well
know RPC (Remote Procedure Call) technique used for client/server applications. Everyday new tools
are added to the Java architecture to implement different distributed computing applications (Agents,
Aglets) and they use basically or low level TCP connections or high level RMI classes.

Java Family: JRE, SDK, Personal Java, Embedded Java, Java card
Before going into a detailed description of Java libraries, we need a brief introduction on the Java
packages available for developers. We have mentioned that initially Java was a network technology
suitable for Internet applications; successively Sun developer have understand that not only the Internet
is a good platform for Java applications. For those reasons they reduced the set of components to fit the
needs of other applications targets. They build a series of subset APIs designed to be upwardly
compatible: JDK (the main and complete implementation), Personal Java, EmbeddedJava, and JavaCard.

• Desktop PC
• Enterprise Servers
• Mainframe
• RTOS
• Set-top boxes
• PDAs/ScreenPhones
• Internet TV
• Car Na vigation
• Industrial controllers
• Pagers
• Automotive

• Smart Card
• Java Ring

Java Personal Embedded Java

Java Java Card
Figure 26: The four Java Application Environment [see 11]

Java designer have not only reduced the number of core classes, but for each platform they have
implemented a specific version of the Java VM. This is possible because the Java VM is describe as a
specification not as an implementation. In fact for example it is possible to re-implement the data
structures and methods that form the internal implementation of the classes for reducing the memory
footprint and maximize the performance for each specific platform.
The following table gives an idea of the resources needed for each Java platform.
Table 6: Resources requirements for different Java environment (only Java system requirements)

Resources Java Personal Java Embedded Java JavaCard

ROM 4 -8 MB < 2 MB < 512 KB 16 KB
RAM > 4 MB 1 MB < 512 KB 512 KB
Processor 32 bit > 100 MHz 32 bit > 50 MHz 32 bit > 25 MHz 8 bit 300 KIPS

4.7Java APIs
The standard Java runtime environment comes with a variety of useful libraries, providing file system
access, network access, a window toolkit, and a variety of other tools. Initially, JDK 1.0.2 was the only
Java technology available for application development. Because Java was initially positioned for the
Internet market, JDK 1.0.2 was designed to support a broad set of application [12].
The correct specification of the libraries is of critical importance. The language itself provide the ability
to create secure libraries (see next sections).
The access restrictions of the libraries are based on three mechanisms:
• the Java language mechanism of providing access restrictions to object methods and variables
(already seen);
• using a specialized ClassLoader to load imported code (see "How Code Born!" section);
• using of explicit calls, inside the packages methods, to a global SecurityManager to check the
validity of certain specific operations.

The Java platform provides a set of ready-to-use component to develop a wide range of applications:
from GUI to encryption tools.
Developers can use directly these packages or inherits from these basic elements to specialize their own
components in a well defined framework. The Java API is supported by a well designed object oriented
architecture, in which every element to access JVM or external features is inside a Java class ordered in a
hierarchical tree, where all classes derive from a common root class, the object class, and are ordered
following the application area (network, basic access, graphic interface, etc.).

java.object
applet.* text.*

awt.* sql.*

io.* util.*

math.*
lang.*

net.* security.*

beans.* rmi.*
Figure 27: core API class hierarchical tree: Java is a complete Obiect Oriented platform.

The Java core API is composed schematically by a set of core packages divided following special rule
and depending of the functionalities. Sun (but also MS and Netscape) provides a complete set of
 application APIs to build a complete developing environment with secure and tested classes (see figure
7).

Application Programming Interface APIs

by Sun

JFC Java Foundation Classes (core API)

Java Accessibility (core API)

Security (core API)

Java Mail
Java Beans (core API)
Java Help
JDBC - Database (core API)

Java Interface Definition Language (core API)

J RMI (core API)

Java Communication: voice mail, fax, smart cards, RS232, IEEE1284

Java Media: 2D,3D, Advanced Imaging, Sound, Speech, Telephony

Figure 28: Application Programming APIs

Additional packages are added when they are considered fundamental, but there are also some expansion
mechanisms to add some specific functionalities, without touching the core API.

4.8Web Integration: Applet

The continuing growth and popularity of the Internet has led to a flurry of developments for the World
Wide Web. Many contents providers have expressed frustration with the inability to express their ideas in
HTML. Rather than further HTML extensions, the notion of downloading a program (called an applet)
which runs inside the Web browser has gained popularity.
One of the most important introductions of the Java world is this concept of Applet. An Applet is a well
defined Java class, with a well known interface to implement little application which can run inside the
Web Browser.
Around the Applets there are a series of Java classes to implement all the dynamic behavior, the security
policy, the loading process. Each developer can implement his own framework: AppletViewer, Java
Browser, etc.
When a HTML page is loaded into a Browser, it is parsed through in search of all special format tags (let
say special commands). When an <APPLET> tag is encountered the Browser loads the Java libraries and
executes the AppletViewer.class (different name are used by different proprietary solutions). The
Appletviewer receives the name and the URL of the loading applet and retrieves the code using a HTTP
connection. Once loaded, the applet is instantiated and the AppletViewer run specific methods of the
applet object.
 1

2
Browser
8 3
9

HTML page 4

AppletViewer
10 7
SecurityManager

HTTP

VM
5

6
“CLASSPATH” ...
sun.applet.AppletViewer.class

Figure 29: Applet loading mechanism

1 The Browser sends an HTTP request for loading a HTML page file ….

2 ... receives the HTML page.

3 The Browser parses the HTML page and formats the video output; if it found an <APPLET> tag ...

4 … it loads the Java libraries in its memory space and executes ...

5 6 .. the AppletViewer.class located in the classpath in the local repository !!!

7 The AppletViewer as in independent application loads the code of the Applet ...

8 9 … opening a HTTP connection (request & response) with a remote site.

10 The Applet runs under the control of the SecurityManager instantiated in the AppletViewer

Some information is exchanged between the AppletViewer and the applet to set the run time environment
or to pass some extra data: this is done using an embedded mechanism inside the applet class (from
whom all Applets inherit basic methods) or using some well know interfaces.
The java.applet.* package is a minimum set of classes and interface to create the necessary
framework.
Inside the AppletViewer application we can implement a customized security policy instantiating our
own SecurityManager implementation !!!
 The Applet mechanism is a very simple solution to the problem of mobile code oriented to the Internet
environment, but it can be expanded to other environments or can be used as a good example for other
network architectures.

4.9Native Interface
The goal of the JVM is to abstract the underlying hardware layer providing the programmers a complete
multiplatform environment. Sometimes, on the contrary, it is necessary to access the physical resources
both of the OSes and of the hardware upon which the JVM resides: for example optimizing the threads
management, running Java application directly from C, C++ code, accessing physical resources like
serial ports, accessing to the OS API, support for the platform dependent features, are only few examples
of the normal needs of a complete computing system. That's why Java designers have introduced some
standard mechanisms to interface the Java applications to external software system, the so called native
code interface.
The Java Native Interface (JNI) is a native programming interface specification and give all the rules for
enabling Java/Native code intercommunication.
Currently, VMs from different vendors offer different native method interfaces. These different interfaces
force programmers to produce, maintain, and distribute multiple versions of native method libraries on a
given platform. Only for the Win32 platform you have to deal with JNI from Sun, JRI (Java Runtime
Interface) from Netscape and RNI (Raw Native Interface), J/Direct, Java/COM, and many others from
Microsoft (see the section " Does exist only one Java ? Microsoft way : DCOM/Java, J/direct, RNI").
Fundamentally JNI (and basically RNI) gives a set of standard functions that triggers the communication
between Java code and native code: native code accesses the Java VM features calling JNI functions. JNI
functions are available through an interface pointer (a pointer to an array of pointers, one for each
function - a standard way to communicate between two objects methods interface, like a C++ virtual
function table or a COM interface). The advantage of using such a mechanism, rather than hard-wired
functions entries, is that the JNI name spaces becomes separate from the native code. A VM can easily
provide multiple version of JNI function tables.

In brief, currently, JNI is designed to interface with native methods written only in C and C++ and native
methods can:

* Create, inspect, and update Java objects (including arrays and strings);
* Call Java methods
* Catch and throw exceptions
* Load classes and obtain class information
* Perform runtime type checking
thus virtually everything you can do with classes and objects in ordinary Java you can also do in native
methods.
For example from Java applications, native methods are loaded with the System.loadLibrary 
method. The native method is declared as follow:

package pkg;
class AnyClass {
native double f(int I, String s);
static {
System.loadLibrary("Pkg_Cls");
}
}
The argument to System.loadLibrary is a library name chosen arbitrarily by the programmer. The
system uses a standard, but platform-specific, approach to convert the library name to a native library
name. For example, a Solaris system converts the name Pkg_Cls to libPkg_Cls.so, while a Win32
system converts the same Pkg_Cls name to Pkg_Cls.dll. Then you have to use some special tools
(javah file generator) to convert the native name of the functions inside the Java code, in an C header file,
implement the code of the native method and compile it in a dynamically linked library.

JNI Invocation Interface JDK 1.1

#include “jni.h”
JDK1_1InitArgs vm_args;
1
JNIEnv* env;
JavaVM* jvm; static void handleErrors(void){
if(env.ExceptionOccurred()){
jclass mcls,cls;
2
jmethodID mmid,mid; env.ExceptionDescribe();
jstring jstr; env.ExceptionClear();
jarray args; 3 vm.DetachCurrentthread();
jint err; }
vmargs.version = 0x00010001; }
JNI_GetDefaultJavaVMInitArgs(&vm_args); 4
...
5
vmargs.classpath = “c:\jdk1.1\lib\class.zip;c:\dab\java\”;
...
err = JNI_CreateJavaVM(&jvm, &env, &vm_args);
6
mcls = env.FindClass(exec); // class of the main java app 7
handleError(); exec is the name of the main
mmid = env.GetStaticMethodID(cls,”main”,”([Ljava/lang/String;)V”); class file; depending of
handleError(); the implementation of the
native function FindClass
cls = env.FindClass(“java/lang/String”);
8 you can pass a C string or
handleError();
special string (es: Win32
args = env.NewObjectArray(argc,cls,0); string)
handleError();
for(int i = 0;I< argc; I++){ 9 NB: the Invocation API is written
str = env.NewStringUTF(argv[I+1]); in C code, but some compiler
accept the C++ notation; so:
handleError();
(*env)->FindClass(env,exec);
env.SetObjectArrayElement(args,I,str);
can be written as
handleError();
} 10 env.FindClass(exec);
env.CallStaticVoidMethod(mcls,mmid,args);
handleError();
jvm.DestroyJavaVM(); 11

Figure 30: Using JNI for Invocate the VM

 JNI Invocation Interface JDK 1.1
Inside the jni.h header we define all the prototype of the Java Invocation interface; these functions are
1 defined inside a library implemented by the developer (Sun, MS, Netscape). Basically the JNI is a standard
interface to call all the facilities we need to control, instanziate and manage the JVM

Basic variables & structures used to call JVM environment and java objects. For java objects we call special
2 ID for the class, the method implemented inside the class using a well define interface.

3 We have to specify the version of the Java implementation we are using (very important).

We call a JNI API function JNI_GetDefaultJavaVMInitArgs(&vm_args) to set the environmental variables

4 needed by the VM to access external system class and libraries.

5 We can modify some external environmental variables, ex. the classpath (to include \dab\java\ ?)

6 This functions load the external library inside the process address space and return all the pointer
necessar y to call the JNI API functions.

The FindClass functions returns an ID to a specific class passed as an arguments; this function verifies,
7 loads, resolves & instanciates a Java class. As we can see we need only the name of the class: the
searching path is defined inside the JDK1_1InitArgs structure.

We look at a specific method inside the specified class; usually we call the “main” method, but we can
8 personalise this mechanism. Note the special tag used to identify the called method.

We build a string array and pass a series of arguments used by the java class main method: in this way we
9 could call a predefined java class and pass the main java class as an arguments: java Applet mechanism !!!

10 Finally we execute the method !!!!! JVM Running !

Figure 31: Step by step JNI interface

One of the big problems with the JNI interface is that you have to rebuild all your old libraries for
reusing them again in the Java applications: new libraries that wrap the old named native method. A
solution come out from Microsoft world and we will see in details in the next section.
For a detailed explanation see [1], [3].

4.10Does only one Java exist ? Microsoft Way :

DCOM/Java, J/Direct, RNI
The Java implementation produced by Microsoft has some additional capabilities created to increase the
integration between Java and the Windows platform. These additional capabilities are implemented on
the compiler side, on the JVM interpreter side and with additional Java classes packages. Java code that
uses this particular features is not yet platform independent and you cannot use it for developing
application for all platforms.
 .activeX IJavaExecute::GetDefaultClassPath(..)
IJavaExecute::Execute(..)
.awt .peer
IJavaExecute2::SetSystemProperties(..)
.com IJavaExecute2::SetClassSource(..)

.fx

com.ms .lang

.service

.ui .resource
JVM as a COM
.util .cab object

.vm

Invocation API
Figure 32: Additional facilities of JVM from MS

RNI stands for Raw Native Interface. This is the MS specification to access native code (C, C++) from
Java code or to call the JVM directly from native code. This specification is studied just for expert
developer and to produce very efficient code.
J/Direct is an extension of the MS compiler and interpreter for calling Win32 API functions in a direct
manner from Java code: developers can access all capabilities of the dynamic library in the Win platform
using the same name of the native code.

Class ShowMsgBox {
public static void main(String args[]){
MessageBox(0,"It worked !","…",0);
}
//* @dll.import("USER32") */
private static native int MessageBox(int,String,String,int);
}

Some special ready-to-use Java classes are added as a extended packages to wrap the main API
functions: com.ms.win32.Kernel32.class, com.ms.win32.Gdi32.class, etc.

import com.ms.win32.*;

class MsgBox{
public static void main(String args[]){
MessageBox(0,"It worked !","…",0);
}
}

DCOM/Java is a high level interface to call Java as an COM object in your application.
4.11The Java Extension Framework: How to
Expand the Java API
The core packages of the JVM are a set of classes to implement general purpose and network oriented
applications. Sometimes programmers need to create some additional facilities or just create some
specific application: a set of classes that control a proprietary database, a new editor, a new application
environment for developing new distributed paradigm. Java uses extensions as a standard way to add
new facilities to its own programming environment.
Extension are packages of Java classes (and any associated native library) that application developers can
use to extend the functionality of the core platform.
The Extension mechanism allows the Java VM to use the extension classes in much the same way as the
VM uses the system classes.
Adding new classes to the core API is different depending on the JDK version. Until the JDK 1.1 adding
new classes meant to create a new package and to add the installation directory to the CLASSPATH. The
need of a more dynamic and controlled way, and overall the need to download and to install
automatically new packages has introduced in the JDK 1.2 new standard mechanisms.
First of all, Extensions are embodied in JAR files (compressed ZIP files). Every Jar file is a potential
extension. A Jar file can be an extension package in two way:

* installed extension: put the JAR file inside the a special location ;
* downloaded extension: referenced inside a download JAR file;
When the VM is searching for a class of a particular name, it will first look among the system classes; if
it fails to find the desired class there, it will next look for the class among any installed extensions (in
general in JAVA\bin\ext for Java packages and JAVA\lib\ext for native libraries, where JAVA is the
installed directory of the JVM); if it doesn't find the class among either the system classes or the installed
extension, the VM will search among any download extension referenced by the application or applet.

Also the name of the packages have to follow some special rules, but not always there is a fixed
mechanism. From one version to the other of the JDK we had some different notation:
sun.*,netscape.*, then com.sun.*,com.ms.*, and at the end we will use some notation
similar to javax.sony.dab.*

4.12Java vs. other technologies

Although Java is often in antithesis to other distributed computing technologies (ActiveX, Obliq), some
independent computing designers (Inferno from Lucent, DCOM technology from Microsoft) have start a
process that we can call of Java friendship. They are converging from different directions towards Java
technology. This is another advantage for Java developer, because they have a growing market of
available platform and applications written for Java and in Java.
For example the Lucent technology developers are thinking about integrating Java VM in their Inferno
OS; Microsoft for many reason has chosen to integrate Java with its ActiveX technology inside the
Microsoft Java VM.
Java developer are integrating TCl/Tk scripting language (a common scripting language for UNIX
platform) directly inside the VM; some big software Company (Oracle, Adobe) are thinking to develop
their applications directly in Java code to reduce implementation costs for different platforms.
Java for many reason have collect consensus from the entire world of software producers and instead of
finding a way to fight against it, many developer are trying to find the way to converge towards Java.
4.13Java Implementation: Window Platform.
We have seen that Java is a Virtual Machine, so an abstract view of an operating system. It represents a
software layer between a specific platform (Win32, UNIX, Solaris, etc.) and the Java bytecode
applications.
In the Win32 platform (Win NT family, Win95, Win98, but also Windows CE) the Java VM is
implemented as a dynamic linked library (DLL) and extends the API functionality of the underlying
Win32 platform. All basic functionality are gathered by modules written in C, that access the underlying
OS throughout the Win32 API functions.
There are three main implementations of the VM in the Win32 environment (Win98, Win NT, etc.):

* JDK from Sun Microsystems

* MS JVM integrated in the Internet Explorer (Web Browser) from MS
* Netscape JVM integrated in the Netscape Navigator

The first two are a complete development environment (interpreter, development tools, compiler,
AppletViewer, class libraries); the last one is an implementation integrated specifically for the Web
Browser to use Applet, but also included extended network facilities to develop complex Web Server
applications.
Windows architecture is fundamentally a layered OS with a kernel that manages the basic functionality
(memory management, driver management, Thread scheduling, process management, etc.) and a series of
independent external modules to implement some specific tasks.

Win32 App

Win32 App Win32 App thirdy part

modules

Win32 API

kernel32.dll user32.dll gdi32.dll advapi32.dll ………….. winmm.dll

native API

ntdll.dll

OS Kernel

Figure 33: Basic WinNT software architecture

Through a well define set of APIs users can develop applications to access the hardware and software
resources.
Each specific VM implementation uses a different number of additional libraries; we can summarize the
specific "core" functions in different families:

* basic VM operation (Memory management, thread scheduling, interpreter, jit compiler, etc.);
* JNI interface functions;
* native methods implementation of the Java classes:
* graphics procedure
 * I/O
* network access
* multimedia functions
* additional JVM capabilities (ActiveX, DCOM interface)
[not available for all implementations];
* compiler functionality

Some of these functions groups are collected in single DLL or they can be put in separate library file.
The first group is a collection of functions that implement the basic VM operation and it is loaded each
time the VM runs: for example javai.dll from Sun and msjava.dll from MS.
Another group of functions is related to the native calling mechanism, so the specific set of functions for
calling native methods or for loading and calling the Java VM: generally it resides in the main library.
Many native functions used by the Java API are collected in different libraries depending on the
particular task they do: Graphics native functions (winawt.dll, awt3240.dll), network communications
(net.dll), mathematical functions (math.dll), special purpose functions (JdbcOdbc.dll).
For those implementations that have a compiler, some additional libraries are included in the package.

In general the core of the Java VM is all implemented in a single library: for Sun we have javai.dll and
for MS msjava.dll. Inside there is a set of functions that are executed to start up the virtual machine or
some internal function to control memory management or object layout. In general these libraries
contain all the native interface calls and the basic native method implementation (for the core Java
classes java.lang.*).

Netscape Microsoft Sun

Navigator 4.04 IE 4.0 Browser JDK 1.1.6

jit3240.dll msjava.dll javai.dll

… …
awt3240.dll
… pr3240.dll ips.dll jscript.dll awt.dll symcjit.dll

jsd3240.dll jrt3240.dll urlmon.dll msjvc.dll net.dll math.dll

jpeg3240.dll js3240.dll winawt.dll mshtml.dll

Win32 API

kernel32.dll user32.dll gdi32.dll advapi32.dll ………….. winmm.dll

Figure 34: Netscape/Microsoft/Sun: three way to implement Java

Then there are the libraries that gather all the native methods for special functions: graphic interface
(awt.dll or winawt.dll), I/O access, network access (net.dll), multimedia functions (mpeg.dll), etc. Each
of these libraries is loaded only when it is needed.

These main modules are loaded by special "Kick off program" applications (java.exe, javac.exe from
Sun; jview.exe, jvc.exe from MS; etc.) or by the Java classes using the loadLibrary() call.
 The calling applications load the necessary libraries and run special functions passing the name of the
class to execute and the searching path directories (classpath) where find all Java System classes.
Only Microsoft have developed some special DCOM wrapper interface to use the Java VM capabilities
at a higher level to integrate with its ActiveX/DCOM environment.

4.14java.net.* : A Case of Study.

It is interesting for the goals of this thesis to point out the inner mechanisms of integration followed in
the Java system on the windows platform. Using all the possible free information available on the
Internet, the work that follows is a reverse engineering process to outline the ways Java developers have
built the Java API platform.
The following information is derived from the source code of the Kaffe Implementation (a 100%
compatible free source version of the Java VM available on the net,
http://www.transvirtual.com/kaffe.html) and the compiled classes used in the JDK 1.1.6
provided by Sun; all considerations upon this subject derive from my personal work and are not related
to some document.
The java.net package is one of the smaller and less complex packages, but I think it contains all the
fundamental principles used in the other Java packages; also it is one of the core packages of the Java
platform and basically it is implemented by all Java platforms available on the market.
I will outline during the dissertation what are the points in which implementations differ.
A Java API block fundamentally is a set of classes that implement a specific OS facility available for
developers: for examples we have packages for the basic elements of Java OS (java.lang.*), for I/O
communication (java.io.*), for Graphic Management (java.awt.*), Thread mechanism, Applet
interface (java.applet.*), remote method invocation (java.rmi.*), etc.
All functionality of the Java runtime system are exposed following a well defined Object Oriented
paradigm, in which each service is wrapped inside a well defined class, which wraps all the method and
data needed by this service.
From an abstract point of view, we can distinguish different software layers between the higher Java API
classes to the lower OS API. In this case we need to balance different opposite aspects: Java object
oriented vs. the C procedural approach, platform dependent services of the Windows OS vs. the platform
independent API provided by Java, etc.

Java package Java platform independent

Java bycode

interface

matching abstract classes

Java platform dependent

interface

platform dependent
implementation
C code

Windows OS
OS API

Figure 35: Block diagram of Java interfacing Model

Following the logical block diagram we can distinguish 3 kind of classes inside a Java package:

• at the lower level we have a platform dependent class that implements all the needed native calls. In
general it extends an abstract class that wraps the Java basic methods to access a specific service;
• in the middle we have a set of matching classes that give to the upper packages a well defined
minimum interface to the services (a set of method calls);
• at the Java API level we have all the rest of the package class that implement all the complex
features related to a particular kind of service.

Look at the following figure (fig 14) to see an example of chain implementation.
As you can notice, this mechanism permits to have a well defined, efficient, standard way interface to the
specific services of a platform dependent OS (UNIX socket, WinSocket). Using the abstract classes we
can specify also the name and the set of minimal services that we need, in order to reduce the platform
dependent access, but at the same time to give a portable solution for all Java implementations. This 3-
step process not always is followed, but it is a good example of multiplatform approach of Java.

class Socket{
socketImpl impl;
Socket() {
impl = new PlainSocketImpl();
}
...
}

abstract public class SocketImpl{

...
abstract void bind(inetAddress address, int lport)
throws IOException;
...
}

class PlainSocketImpl extends SocketImpl{

static{
System.loadLibrary(“net”);
}
...
protected synchronized void bind(inetAddress address, int lport)
throws IOException{
...
socketBind(address,port);
}
...
native private socketBind(InetAddress addr, int port);
}

Figure 36: A Three Layer Approach: Java interfacing Model

From native method we call native function using the well define JNI specification and model.
In the underlying OS we need a wrapping DLL (in the case of dynamic library) to gather all the equal
purpose C functions (in our example the net.dll file); from this library, inside the single functions
implementation, we can call the native API and link to the native API library (in the case of Window
platform winsocket.dll, kernek32.dll, etc.).
While the JNI interface is a specification between the Java layer and the native code layer, the approach
followed inside the Java API implementation is a good example of well defined developing approach. In
the case of an external package, we suggest to follow this way to build a well defined Java package. The
JNI specification defines only the name of the wrapper native functions (C functions); internally each
single Java platform can use different implementation of the native services.
In brief we have seen that also in the Java platform we can distinguish a set of classes that are tightly
bound to the underlying platform and the specific configuration of the system: if it is possible we should
 create a set of abstract classes to implement a well defined set of platform independent API and then we
should implement separately for each classes a specific implementation.
Another example of the layered approach is the following figure.

Java Implentation: an example from Kaffe

Runtime.c
System.java jint java_lang_Runtime_loadFileInternal(
struct Hjava_lang_Runtime* this,
struct Hjava_lang_String* s1){
public static void LoadLibrary(String libname){
int r;...
Runtime.getRuntime().loadLibrary(libname);
r = loadNativeLibrary(lib); ...
}
}

Runtime.java
public synchronized void loadLibrary(String libname){ External.c
...
int loadNativeLibrary(char* lib){
loadInternal(buildLibName(path[path],libname);
...
...
LOADLIBRARY(libHandle[i].name,lib)
}
...
private boolean loadInternal(String filename){
}
...
return loadFileInternal(filename);
}
native private Boolean loadFileInternal(String filename);

slib.h
#if defined(__WIN32__)
#define LIBRARYINIT()
#define LIBRARYLOAD(HAND, LIB) HAND = LoadLibrary(LIB)

Win32 API
#endif

Figure 37: Another example of the Java interface with native OS

Some packages are separated from the specific implementation of the OS platform or from a special
proprietary solution provided by different Company. In these cases some special packages have part of
the name of the core Java implementation but they differ in the radix (java.util.*,
sun.util.*, netscape.util.*).

4.15Future Develpments: A Faster and More

Secure Architecture.
Java is not a perfect platform and is not the best VM implementation for all kind of distributed
applications. There are still a lot of things to do to adapt the Java technology to some special computing
area. Java has some unresolved problems in the Real Time Applications as Garbage collector
management and as real time multithreading; efficiency and speed of the code is not yet comparable to
the native implementation for some embedded solutions both for interpreter or JIT compiler.
In the Internet world both inside Academic centers and in Software companies there are a lot of new
projects that are trying to deal with all this particular aspects.
Some free source implementations are available in Internet from GNU association and are the base for
tens of experimental solutions.
Some of the new solution are introduced in the different releases of the JDK packages, while other try to
expand the Java API using new packages.
Java is the base platform for different kind of distributed computing environment: not only the Applet
architecture (Code On Demand paradigm) or the traditional client/server architecture, but also some new
agent technology is implemented in Java.
 ♣♣♣

New aspects are introduced in the JDK 1.2.x concerning the security mechanism and policy of the Java
VM [11].
There is no built-in notion of "trusted code" and the securityManager has more advanced
capabilities to control the security of the Java Environment [9].
In the previous version of the JVM you basically have two way to load Java classes: one embedded
system dependent "trusted code" way to download classes from the CLASSPATH (system classes) and
the other to use your classLoader and manage the security access with the securityManager
(Applet download).]
Java is born as a proprietary product but today is become a instrument of all Internet users !!!
“They love him, gentlemen, and they respect him, not only for himself,
.but for his character, for his integrity and judgment and iron will;
but he was most loved for the enemies he made"

General Edward S. Bragg (speaking about Grover Cleveland,

but it can be applied to the controversy between Sun Java and MS)
References
Chapter 1 and 2
Programming Languages for Mobile Code - T.Thorne - INRIA n°3134 (Mars 1997)
Understand Code Mobility - A.Fuggetta, G.Picco, G.Vigna - IEEE (1998)
Mole - Concept of a Mobile Agent system - J.Baumann, F.Hohl, K.Rothermel, M.Strasser -
Universität Stuttgart (August 1997)
A Note on Distributed Computing - J.Waldo, G.Wyant, A.Wollrath, S.Kendall - Sun Microsystem -
(November 1994)
Design Distributed Applications with Mobile Code Paradigm - A.Fuggetta, G.Picco, G.Vigna -
Politecnico di Torino/Milano (1997)
6. Mobile Code Paradigms and Technologies: A Case of Study - C.Ghezzi, G.Vigna - Dip. Di
Elettronica e Informazione, Politecnico di Milano
7. Comparison of Mobile Agent Toolkits for Java (Draft) - Steven Versteeg - June 19, 1998
8. WWW sites (http://):
a) www.worlddab.org
b) www.club-internet.fr/dabfrance/

9. Principal Architecture of a DAB receiver - A Reference Model

(www.worlddab.org/members/)
10. Languages for Mobile Agents (Thesis) S.Versteeg (25/8/1997) (www.cs.mu.oz.au/~scv/)

Chapter 3
1. Java Beans and ActiveX go head to head - Merlyn Hughes [JavaWorld (March 1997)]
2. Java Beans Specification - Sun Papers
3. The Java language Specification - Java language Series
4. Using Inferno to Execute Java on Small devices - C.F.Yurkoski, L.R.Rau, B.K.Ellis - Bell Labs -
5. Tcl and Java Integration - Ray Johnson - Sun Microsystem Laboratories (February 3, 1998)
6. Java Aglet Application Programming Interface - D.B. Lange - White Paper -
7. Inferno Programmers Guide (http://www.lucent-inferno.com)
8. Choosing a Scripting Language - C.Laird K.Soraiz SunWorld - October 1997
9. Mico is CORBA by Kay Römer, Arno Puder
10. Mole - Concept of a Mobile Agent system [chapter 1 ref 3]
11. Programming Languages for Mobile Code - T.Thorne - INRIA n°3134 (Mars 1997)

Chapter 4

1. Java Native Interface Specification - Release 1.1 - Sun Microsystem (May 1997)
2. The Java Virtual Machine Specification - T. Lindholm, F. Yellin
3. Thinking in Java - Bruce Eckel
4. Experience with Secure Multiprocessing in Java - Li Gong, D. Barfanz
5. Java Garbage Collection for Real Time System - A. Petit-Bianco - [DR.Dobbs october 1998]
6. Extensible Security Architecture for Java - D.Wallach, D.Balfanz, D.Dean, E.Felten [Department of
Computer Science Princeton University]
7. Java Security - J.A.Bank - MIT Report
8. CACAO - A 64 bit Java VM Just-in-Time Compiler - A.Krall, R.Grafl - Institut für
Computersprachen technische Universität ( Wien)
9. The Java Extension Framework (http://java.sun.com/products/jdk/1.2/docs/guide/extensions)
10. Java Security Architecture -(JDK 1.2) Li Gong
(www.javasoft.com/products/jdk/1.2/docs/)

Chapter 5
1. Window NT Internals
2. Radio broadcast system: DAB to mobile, portable and fixed receiver (Final draft ETS 300 401)
November 1994
3. Specification of the Multimedia Object Transfer Protocol (MOT) - Eureka Projects 147 -
4. DAB Data Service - Overview of Current Technology - R.Bittner, R.Schäfer - 104th AES
Convention

Chapter 6 e 7
1. Java Native Interface Specification - Release 1.1 - Sun Microsystems (May 1997)
2. Web sites (http://):
a)premium.microsoft.com/msdn/library/ - MSDN Library
b)www.q-tek.com/scripting/JavaDocs/ - Microsoft SDK for Java
2.0
c)msdn.microsoft.com/developer/sdk/inetsdk/
3. MSDN Library - January 1998 by Microsoft