1

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

2
 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
 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

4
 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

5
6
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

7
 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.1 What 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

8
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 bandwindth) 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.

9
 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
optimise the reception from mobile device (car radio, boat radio) and the use of some
special compression tecnique permits the trasmission of CD-quality audio. DAB is also a
cheaper way respect to the FM system to trasmit 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 contribuiting. 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].

10
 DAB active services
DAB sperimental services
interested countries
information not available

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

1.2 A 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

11
 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.3 Examples 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 trasmit 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.

12
 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 Tim etable
Information UPlink path

Internet

Iwant 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

13
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 new parliam ent ?

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.

14
1.4 A 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 1 Introduction
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 2 Mobile 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 3 Technologies
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 4 Java
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 platform: abstract machine architecture,

1
See references for a detailed list of documents

15
 programming language features, security mechanism, Java API, native interface,
Applet model, etc.

Chapter 5 Download 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 6 Simulation
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 7 J-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.

16
17
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.

18
 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.);

19
 * 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.1 A 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:

Communicaton mechanisms

Point-to-Point

Messages

RPC

Stream

Point-to-Multi-point

Events

Group Communication

Shared Memory

Tuple Spaces

Multicasting/Broadcasting

20
 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.2 Distributed 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

21
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 -

22
 * 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.

23
 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).

24
 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

25
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.

26
 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.3 Classification 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).

27
 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

28
 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.

29
 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.

30
2.4 Programming 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.

a Graphics support
a Network
Library Level a Encryption
a Hierarchical Class Support

a Interpreted or Compiled
Languages Level a Strongly Typed or Typeless
a Programming Paradigm

Abstract Machine Level
a Concurrency
a Security Model
a Memory Management
a Memory Architecture
a Platform Architecture
a Mobility Mechanism
a Shipping 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,

31
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

32
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.

33
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

34
 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.5 Security & 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

35
* 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.

36
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)

37
38
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.

39
 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.1 Java
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].

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.

40
 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).

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

41
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

42
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.

43
 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.

♣♣♣

44
 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.2 Inferno/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;

45
 * 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.

46
 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.

47
Table 1: Inferno vs. Java - a Comparison -

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

3.3 OSes 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.

48
 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.4 CORBA
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

49
 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.5 ActiveX & 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).

50
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

51
 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.6 JAVA 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 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;

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.

52
 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.7 Obliq
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:

53
 • 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.8 Objective 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.

54
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.

55
 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.9 AGLETS
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).

56
 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.

57
 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.10 Telescript
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.

58
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.

59
 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.11 Tcl/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.

60
 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.12 Internet 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 e xecution 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.13 Comparisons & 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

61
 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.

62
 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

63
 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

Model code
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 private not applicable not applicable not applicable
same package
No outside update protected

64
No aliases NA NA protected NA
Mutual exclusion serialize
Attributes protections
No restriction public NA NA NA NA
Visible only in the protected NA NA NA NA
same package or in
subclass
Visible in subclasses default NA private NA
Visible only in private private NA default
defining 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.

65
3.14 A 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.

4
ITU stands for International Telecommunication Union; ETSI stands for European Telecommunication Standards
Institute

66
 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 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,

67
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.

68
 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.

69
 "… every new beginning
comes from some other new beginning end …"
(Pop Songs)

70
71
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)

72
 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.1 Java 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:

n an Internet instrument for a distributed and safe computing;

n 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;

73
 • 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.2 Virtual 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

74
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.

75
 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.3 The 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.

76
 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.

77
 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.

78
 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.4 Loader: 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

79
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.

80
 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.

81
 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 ..

Java Virtual Machine run the “main” static method

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.5 Garbage 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.

82
 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 class es 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.6 Java 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

83
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
Catchregionregion
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

84
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.

85
 • Desktop PC
• Enterprise Servers
• Mainframe
• RTOS
• Set-top boxes
• PDAs/ScreenPhones
• Internet TV
• Car Navigation
• 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 JavaCard

Java
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.7 Java 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);

86
 • 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).

87
 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.8 Web 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.

88
 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.

89
 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.9 Native 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:

90
 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){
jclass mcls,cls;
2 if(env.ExceptionOccurred()){
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\”;

6
...
err = JNI_CreateJavaVM(&jvm, &env, &vm_args);
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

91
 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.10 Does 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.

92
 .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.

93
4.11 The 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.12 Java 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

94
 (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.13 Java 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.

95
 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.

96
 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.14 java.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.

97
 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;

98
• 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

99
 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.15 Future 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.

100
 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 !!!

101
“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)

102
103
Chapter 5 Download of DAB
Applications using Java

"Words differently arranged have a different meaning and

meanings differently arranged have a different effect."

- Pascal, Blaise (1623-1662) -

DAB architecture is a sophisticated system that allow providers to offer new

flexible digital services on radio channel. In this chapter we start from a technical
overview about the basic layers of the communication architecture of the DAB system;
we continue to explain the already existent DAB applications and we finish giving some
basic security concepts about the use of the Java platform.

104
 This is an introduction to the possible future implementations and a framework
to understand the simulation that we will describe in details in the next chapter.

5.1 DAB Architecture

DAB is a new European standard for transmitting audio data using the radio
broadcasting systems. In this section we will see some of the principal concepts of the
DAB architecture; for more details see the specification provided by European
Telecommunications Standards Institute ETSI ([2] e [3]).

Radio channel. The DAB signal, at the physical layer, carries simultaneously a
multiplex of several digital services, called ensemble, using some advanced modulation
technique (Orthogonal Frequency Division Multiplexing - OFDM) for increasing the
performance for mobile communication.
The bandwidth of the signal is 1.536 MHz with a useful bit rate capacity of
approximately 1.5 Mbit/s. In figure 1 you can see the physical layout of the data
transmitted on air using the DAB system. In figures 2 and 3 there are the logical scheme of
a DAB receiver and transmitter.
The ensemble contains several audio and data services decoded in parallel using
a time interleaving technique: that means that each receiver receives the information of
all the services in parallel and can select one of these.

NULL Symbol
TFPR Time Frequency Phase Reference

0
1 2 3 4 5 6 7 8 9 10 …. 74 75 76

1.3 ms FIC Fast Information Channel

1.25 ms 6*512 bit with RAVE = 1/3

DATA Field - 72 symbol

1536 carriers

Guard
Interval
Useful Symbol ….

246 µs 1000 µs
256 1792

Time Domain Frequency Domain

Figure 38: DAB radio - The signal on the air

The services multiplexed on a single ensemble can be of two different types:

audio services and data services.
The audio data is transmitted using different compression tecnique (MPEG 1
Audio Layer II, MPEG 2 Audio Layer II). DAB allows 4 audio modes:

• Single Channel,

105
 • Dual Channel,
• Stereo and
• Joint Stereo.

In the case of stereo and joint stereo channel the receiver will automatically reproduce the
audio signal as a two channel stereo comprising a left and right channel. In the case of
dual channel we can diffuse mono bilingual transmission.
Independently from the audio mode, the complete audio signal is encoded in one
DAB audio bit stream and can be accessed by the receiver as one integral Service
component (see next section for details about service components).
Using different combination of the previous technique we can have a
transmitting rate for the audio ranging from 32 kbit/s to 384 kbit/s: the DAB audio
system can provide typically 6 high quality stereo audio programmes or up to about 20
restricted quality mono programme.
DAB provides also three different ways to carry data services. A PDA channel
(Programme Associated Data) incorporated at the end of the DAB/ISO audio frame that
provides a data rate from 667 bit/s up to 65 kbit/s. Independent data services: general
data may be transmitted as a separate service; this may be either in the form of
continuous stream segmented into 24 ms logical frames (with data rate of n x 8 kbit/s) or
in a packet mode. A third way is to carry data as a part of FIC (Fast Information
Channel): a unique data channel to transport information about the configuration of the
ensemble, that sometimes is used to transmit extra data.
In the next two figure you can see the scheme of a DAB Transmitter and a DAB
receiver.

Service & Multiplex FIC

Information
Transmission
Multiplexer

OFDM Transmitter
Audio Audio Channel
Services Encoder Coder
Multiplexer

Radio Frequency
MSC

Data
Packet Channel
Services
Mux Coder

Main Service Channel

Figure 39: DAB Transmitter scheme.

106
 Tuner OFDM Channel Audio
Demodulator DeCoder Coder Audio Service

FIC Packet Independent

DemMux Data
Service

controller User Interface

Figure 40: DAB Receiver scheme

Architecture. DAB architecture is a sophisticated system. DAB is a multilayered stack

protocol system that permits the transmission of high quality audio and management
and general purpose data. We have already described some basic concepts related to the
physical medium of a DAB channel; also we have pointed out some of the innovative
services available on the DAB system.
Here we want to add some additional information about the general structure of the
DAB multiplexing technique.
Basically we distinguish two way to transmit information: FIC Fast Information Channel
and MSC Main Service Channel. The first one is used primarily to transmit information
about the configuration of the MSC; the second one is used to transport different services
(audio and data) using special time interleaving technique (see fig. 4).

synchronization Fast Information Main Service Channel

channel Channel

Figure 41: Three main channel in the DAB system

The DAB system permits two mode of transmission: stream and packet. Information
inside the MSC channel is time interleaved: this permits to transmit "contemporarily"
different services. Using some additional fragmentation blocks of the MSC we can divide
the whole MSC channel in different subchannel, each carrying a different service
component (audio stream data, stream and packet data).

Services & Service Components. Inside an ensemble are available different services and each
service can contain one or more service components. A service component can be an
audio component or a data service component (see fig. 5).

107
 EnsembleID DAB ensemble X

ServiceID BBC Radio RAI Radio …………

Traffic
Service Audio Message
Service
Information Audio
Component Channel

MCI SI

SubCh SubCh SubCh

FIDC a b c
... ...

Fast Information Channel Main Service Channel

Figure 42: An Example of DAB structure

All the information about the configuration of the ensemble are inside the MCI (Multiple
Configuration Information) in the FIC channel. The programmer can select different
service and different service components using a set of identifiers. The service
organization defines the relationship between the services and the service components
(see fig 5) carried in the ensemble. Each service can be identified by a Service Identifier
which, when used in conjunction with an Extended Country Code, is unique worldwide.
Service components can be carried in a stream or in the packet mode: in the last case we
need some additional signaling of the subchannel and the packet address.
For the management of multimedia objects (image files, HTML pages, Java class), it has
been introduced an additional software layer, the MOT protocol.

MOT (Multimedia Object Transfer) Protocol. For the transmission of multimedia information
the DAB system makes use of the MOT protocol. The MOT is a data transport protocol
specified to provide a framework for the transportation of multimedia objects. Basically
an MOT object is an ordered collection of three parts:

• header core
• header extension
• body
The header core contains information about the size and the contents of the object, so
that the receiver can determine whether it has system resources to decode and present
the object or not. The header extension includes information that supports the handling
of the object and provides additional information that can support an application. The
body carries any kind of data, where structure and content of the data is describe in the
header core and header extension.

108
 For transportation the object split into several (at least two) segments. The header is
separated from the body during transportation in order to have the possibility to repeat
the header several times, to send the header in advance and to send the header
unscrambled with the body scrambled.

header core header extension object body

Figure 43: The MOT structure

In MOT protocol are defined different kind of contents: MIME/HTTP, ASCII, ISO 646,
HTML for text; GIF, JFIF, BMB for images, MPEG family for audio; and Java for code.
Today some extension are required for implementing new services and for integrating
new multimedia objects.

5.2 Concepts for Application Download in DAB

We have seen that the DAB system is a new way to transfer digital data by
means of radio channels. In the previous sections we have seen part of the layer of the
protocols stack of the DAB channel from the physical layer up to the MOT protocol.
Apart from the traditional audio services available (enhanced by the use of MPEG
compression tecniques), the DAB system can offer also a series of general purpose
services for the transport of digital information.
In this sections we will analyse two already developed applications: a Broadcast
WebSite and a Slides Show [4]. In these two applications the data services provided by a
DAB channel is similar to the Video teletext service available on the majority of the TV
channels. Teletext is a point-to-multipoint data dissemination system that provides an
effective and low cost means of distributing online information. Basically the teletext
service is a continuos flow of repetitive text pages on the air: these pages are transmitted
serially along with the television composite video signal; when the complete service has
been transmitted, the cycle is repeated. Each time a user wants to select a single page, the
receiver waits for the single page is received (so called access time) and shows the
contents on the TV monitor. The mechanism is enhanced using different ordering
algorithm (out-of-sequence for example) on the transmitting side and caching technique
on the receiver-side.
In the DAB system we have a similar behavior: on a single data service of the
DAB ensemble there could be different data object (MOT objects) periodically
transmitted.

109
 DAB Browser DAB Navigator

on air

DAB carosel

DAB local repository

html file Controller
c:\dab\cache
gif images

Figure 44: DAB Broadcasting Web Site architecture

In general we have a main application, called DAB Navigator in which we select

and shown all the DAB services available for a tuned station. Inside this application there
are integrated a DAB HTML Browser and a DAB Slide Show.
For the DAB Browser (see fig 4) we transmit a all the HTML/GIF files required
for a hierarchical HTML service: each file is an MOT object and all the files are sent in a
sort of carousel (teletext). When we select a service the main HTML page is download
from the DAB channel and it is shown: for each successive request the DAB driver is
called for retrieving the information available on the selected service.
In the Slides Show application a set of images are repetitively shown on the
screen: they can be sent using the PDA channel associated to an audio service or in a
separate data service.

The basic mechanism that we have used for the integration/simulation of the
Java VM and the DAB channel is based fundamentally on these two applications. In the
case of download Java application we need a more sophisticated framework to manage
the loaded code (see details in the next chapter).
In the DAB navigator we have embed the Java VM as a COM component. Each
time a Java service is required, we load the needed libraries and we initialize the VM. We
have seen that in general we have to pass as argument the name of the starting class; in
the simulation we use a specific class Loader as loader and the file system as the class
repository. In the future, using special native method to control the DAB driver, we can
fetch the data directly from the DAB system. In the next figure we can see the basic
architecture used in the simulation.

110
 DAB/MFC
app DABViewer dab.class

DAB.class
JVM
DAB.class

on air DAB DAB.class

DABViewer.class

c:\dab\java

html file DAB.class

java class file on air c:\dab\html

java class file permanently stored on disk

Figure 45: Integration of the Java VM inside the DAB Navigator (simulator scheme)

5.3 Request of an Extension of the Eureka 147 Specification

The standardization of parts of the DAB system is today a work in progress.
Additional extensions are needed for developing new services and for integrating new
multimedia components (Java for example).
We focus our attention on three main aspects related to the DAB architecture:
DAB API, the entries of the DAB FIC and the extensions of the MOT content type.
The first aspect, the DAB API, is the basic step to create a DAB platform for
future projects for the DAB system. At low level there is a protocol used for
communicating directly to the receiver: DCRS (DAB Commands Sets for Receiver). The
status of this protocol is currently under standardization. But nowadays the high level
communication with DAB receivers is done with proprietary solutions and sometimes it
is suitable only for a specific application (PDA, Audio, etc). Independently from the
future OS platform, today the DAB programmers need a specific set of common DAB
services functions; we can summarize:

• tuning (ensemble selection)

• services available on air
• select/start/stop services
• handle data (audio streams)
• MOT objects selection

111
 From the point of view of service providers these functions have to be a high
level API and they have to delegate all specific controls and data management inside the
particular implementation.
Some additional extensions are required in the DAB entries inside the FIC block.
The main parameters, which characterize the DAB applications, are the AppID and the
ProfileID. The first one is a reference of the kind of application inside a DAB data
service: up to now there are two AppID, one for the Broadcasting Web site and the other
for the Slides Show application. For adding the Java services we need a specific AppID
that refers to the Java VM.

EnsembleID DAB ensemble X

ServiceID BBC Radio RAI Radio …………

Traffic
Service Audio Message
Service
Information Audio Java
Component Channel VM

MCI SI

SubCh SubCh SubCh

FIDC ... ...
a b c

Fast Information Channel Main Service Channel

Figure 46: New services could be available with the Java VM integration

The ProfileID is a parameter used to specify a particular configuration needed for

the execution of the requested services. The ProfileID refers to the hardware resources
required for executing a particular service (Embedded terminal or PC terminal, display
size, memory requirements), the software resources (versions), the security access
(different levels of accessibility to DAB resources).
Also the MOT protocol needs some additional extensions. The identification of
an multimedia object is done using the content type/subtype fields inside the MOT
packet header. Java Applets are sent through the network in different way: in a single
class file or in a multiple archive (jar file is the Java standard way to move a set of class
and resources in a single compressed zip file; Microsoft uses its proprietary cab file for
the same purpose).

5.4 Proposal for a Security Model: Java/DAB Security

As we have seen in the last chapter, Security in Java is implemented at different
levels. In this sections we discuss the controls implemented at the application level to
protect and manage critical access to the DAB resources using the framework offered by
Java architecture.
We recall briefly some aspects already discussed. Java has a centralized Security
model at the application level. Java [JDK 1.x and JDK 1.1] distinguishes two different

112
 Java classes: trusted and untrusted code. The first one is referred to Java classes of the
core APIs (java.lang.*, java.io.*) loaded by the system class loader (sometime
called primordial class loader): no checks are performed on these classes because are
considered trusted. [It is up to the user to manage the CLASSPATH variables]. The
second are all the classes loaded by a subclass of the classLoader class: for example
Applet loaded by the URLClassLoader used by Browsers or the DABClassLoader
used in our project (see next chapter for details).

In JDK 1.1 a digital signed/certification mechanism has been introduced for load trusted
code, but at the moment we don't consider this particular case.

Each time an untrusted class attemps to access a critical resources, inside the API
methods there is an explicit call to the securityManager and a check is performed
calling a specific checkXXX() method. For example when an Applet try to access the file
system reading or writing a file, inside the read() and write() methods there is a call
to the corresponding checkRead()/checkWrite() methods of the
securityManager; it is up to the securityManager implementation performs all the
checks and in case throw a securityAccess Exception (see chapter 4 for more details).
Although Java is a general purpose distributed platform, most of the default
protection mechanisms are implemented for a specific computer-based, network
machine: it follows a list of all the critical resources checked by the securityManager.

Table 7: Critical resources controlled by the securityManager

Critical Resources securityManager check [JDK 1.1] Comments

File System checkDelete() The file system is considered the main
checkWrite() system repository
checkRead()
Network checkAccept() Network is the base means for
checkConnect() communication inside the Java VM: the
checkListen() majority of communication mechanism are
checkMulticast() based on TCP or UDP over IP.
Process control checkAccess() Process control is difficult to implement at
checkPackageAccess() application level: memory resources can be
checkSecurityAccess() controlled at start up of the VM.
User environment checkAWTEventQueueAccess() Video, KB, Mouse are the basic user
• Video checkTopLevelWindow() input/output channel.
• Keyboard checkSystemClipboardAccess()
checkPrintJobAccess()
• Speaker
• etc
System Calls checkExit() Native OS system calls.
checkLink()
checkExec()

Developers can extend the set of checkXXX methods to perform some specific
controls. This is the basic approach that we will follow for our DAB Security policy.

We distinguish conceptually three basic critical access to the DAB system:

Protection Level Critical resource Example

Level 1 Accessing MOT object getObject()

Level 2 Selecting & Starting services selectService()

113
 Level 3 Changing the DAB tune()
ensemble

We need now some information about the requirements of the selected services
(information taken from the DAB FIC data) and the local security configuration data that
users are supposed to provide for each kind of selected services.
From DAB channel we can retrieve for example three fields in the FIC block:
ServiceID (relative to the service provider), ApplicationID (relative to the kind of service)
and ProfileID (relative to source or security requirements).
For example: provider X (ServiceID) broadcasts a data service that needs a
certain level of accessibility (ProfileID) for executing the contents of MOT java objects
(AppID). User A can choose to configure the security permission or accessibility locally
to its DAB receiver depending of the kind of services or AppID (Slides Show, HTML
Browsing, Java Applets) or the kind of provider or ServiceID (Sony, BBC, CNN, HP).
At start up the information from FIC block and from local configuration is
compared and only the services that match the requirements are shown. At runtime each
critical access is checked by the securityManager to control if the application follow the
local security constraints.
The securityManager have to implement some extra checkXXX() methods (for
example checkGetObject()) in which we can implement our controls; for each critical
methods we have to call the securityManager checkXXX(). This is compliant to some
aspects related to our simulation: in fact we use for example for accessing a native
method service a special class inside our DAB package. The Applet will use our class, but
inside we implement our control.

DAB at start up show

show only services
that match the
Local User
ServiceID requirements Configuration
ApplicationID
ProfileID (ACL)

at run time the SM controls

each critical access

Applet
DAB Audio services
carosel
Applet MOT
Applet
securityManager

Figure 47: Proposal for a Security Model for a DAB/Java System

114
115
116
Chapter 6 Simulation

"C makes it easy to shoot yourself in the foot;

C++ makes it harder, but
when you do it blows your whole leg off."
- Bjarne Stroustrop, inventor of the C++ programming language

In this chapter we will describe the particularities of the simulation developped

to test our dowload application architecture. We will analyse the main components used
inside our project.
We want to outline that the purpose of this simulation is to test the possibilities
offered by the Java platform and the ways to integrate this platform inside the DAB
system. Up to now there are lots of open problems in the DAB standardisation process (a
standard high level DAB API, a standard software platform): we have developed for that
reasons a minimum set of components and we have made them very simple.

117
 This simulation can be seen as the future framework for a complete integration
between DAB/Java (see next chapter).

6.1 Overview of the Simulation

For implementing our simulator we have built a Main Dialog Box in which we
list the service available. After the selections we execute two different frame, one for a
simple HTML Browser and the other for the AppletViewer: the frame for the
AppletViewer is created inside the Java VM.
The application can be divided in two parts: the first one is a simple MFC
application used to show a list of services, to embed some data for simulating the
information from the FIC channel, to load the Java/COM object and to show the HTML
Browser; the second one is a set of very simple Java classes (see next sections) to show the
basic mechanism of downloading, security manager control, native access and Applet
management.
[In the next chapter we go in details on the Java componets we need for a comp lete Java DAB
integration].

We proceed step by step to the description of the behavior of the simulator.

Step 1. At start up we execute a simple dialog base frame in which we list all the
service available. All these information in the simulation are embedded in the
code, but in the real application are retrieved from the FIC block of the DAB
system.
Step 2. The user select a service. If it is a HTML service we use the AciveX Web
Browser control in a separate frame for showing the contents of some pages. If
we select the Java service the following service follow:
Step 3. We instantiate the C++ JView class. This class is only a wrapper class to load
the msjava.dll library (using the COM mechanism) in the process memory
space.
Step 4. We start the execution of the VM calling a special Invocation API (see next
sections for details) function and passing as arguments the name of the
DABFrameViewer and the location information of the Applet (name and
position). These information in the simulator are just the name of the Applet
class and the directory location; in real application we can pass all the needed
information to localize and control the Applet.
Step 5. The Java DABFrameViewer class is started and a new Frame appears in the
video; we instantiate the DABSecurityManager and the DABClassLoader;
the arguments passed to the DABFrameViewer are used by the
DABClassLoader to localise the Applet.
Step 6. The Applet is loaded by the DABClassLoader, it is instantiated and shown
inside the Panel of the main Frame of the DABFrameViewer.
Step 7. User can start manually the Applet using a START button.

118
 1 Ex:

sony c:\sony

dab c:\sony\dab

resources c:\sony\dab\resources

2 html java
…\java
…\html

img …\html\img
service1 serviceN …\java\service1

service2

3
pJV = new CJView(argc,argv);
c:\sony\dab\java
..
pJV->Initialize();
DABApplet.class

4
C++
servicesAvailable[0].appID = JAVA_APP;
servicesAvailable[0].fileName = "TicTacToe";
servicesAvailable[0].resourcePath = "service3";
... pJV->ExecuteClass(..)

5 7

JAVA
6

DABClassLoader

DABSecurityManager

Figure 48: Step by Step the behavior of the Simulator

6.2 Integration of the Java Virtual Machine: MS COM

We have described the implementation of the Java VM inside the WIN32
platform in the previous chapter. We have seen that the JVM is implemented as a set of
function inside a set of libraries. Inside these libraries fundamentally there are all the
necessary mechanism to start up the VM, instanziated the JVM objects and control the
excution of their methods.
Basically the roughly steps to follow for loading the JVM inside a preexistent
application are:
1. located the JVM libraries;
2. load the libraries inside the process memory space (in the case we use
dynamic linking at run time; otherwise we link statically at compiled time);

3. call a set of functions (Invocation APIs) to inizialise and start up the JVM;
4. pass the name of the first Java application (normally loaded from file
system).

We have chosen to use the implementation from Microsoft because there is a

C++ class (Jview.cpp) that wraps a series of COM calls to the Java VM. Microsoft
register the Java library as a COM object inside the registry file: for load the object as an
in-process object we use some COM API functions.
The Invocation API from Microsoft are a set of functions and data structures for
manage the initialisation and the start up of the Java VM.

119
 DECLARE_INTERFACE_(IJavaExecute, IUnknown)
{
/* IUnknown methods */
STDMETHOD(QueryInterface)(THIS_ REFIID riid, LPVOID *ppvObj) PURE;
STDMETHOD_(ULONG, AddRef)(THIS) PURE;
STDMETHOD_(ULONG, Release)(THIS) PURE;
/* IJavaExecute methods */
STDMETHOD(GetDefaultClassPath)(THIS_ LPOLESTR *ppszClassPath) PURE;
STDMETHOD(Execute)(THIS_ LPJAVAEXECUTEINFO pjei, LPERRORINFO *pperrorinfo) PURE;
};
DECLARE_INTERFACE_(IJavaExecute2, IJavaExecute)
{
/* IUnknown methods */
STDMETHOD(QueryInterface)(THIS_ REFIID riid, LPVOID *ppvObj) PURE;
STDMETHOD_(ULONG, AddRef)(THIS) PURE;
STDMETHOD_(ULONG, Release)(THIS) PURE;
/* IJavaExecute methods */
STDMETHOD(GetDefaultClassPath)(THIS_ LPOLESTR *ppszClassPath) PURE;
STDMETHOD(Execute)(THIS_ LPJAVAEXECUTEINFO pjei, LPERRORINFO *pperrorinfo) PURE;
/* IJavaExecute2 methods */
STDMETHOD(SetSystemProperties)(THIS_ LPENUMJAVAPROPERTY penumProperties) PURE;
STDMETHOD(SetClassSource)(THIS_ DWORD dwType, LPVOID pData, DWORD dwLen) PURE;
};
// {3EFB1800-C2A1-11cf-960C-0080C7C2BA87}
DEFINE_GUID(CLSID_JavaExecute,0x3efb1800, 0xc2a1, 0x11cf, 0x96, 0xc, 0x0, 0x80, 0xc7, 0xc2, 0xba, 0x87);
// {3EFB1803-C2A1-11cf-960C-0080C7C2BA87}
DEFINE_GUID(IID_IJavaExecute,0x3efb1803, 0xc2a1, 0x11cf, 0x96, 0xc, 0x0, 0x80, 0xc7, 0xc2, 0xba, 0x87);
// {D7658820-01DD-11d0-9746-00AA00342BD8}
DEFINE_GUID(IID_IJavaExecute2,0xd7658820, 0x1dd, 0x11d0, 0x97, 0x46, 0x0, 0xaa, 0x0, 0x34, 0x2b, 0xd8);

Figure 49: Interface of the Java/COM object developed by Microsoft

6.3 Software Implementation: the Main Java Component

For the implementation of the Java service we have used some special java
components: the DABFrameViewer, the DABApplet, the DABClassLoader, the
DABSecurityManager and the DABNative.
We describe in details the main properties of these components and the
relationships that occur between them.

DABFrameViewer. It is the first application executed by the VM. In our simulation it is a

very simple Applet viewer that subclass from Frame class [normally the applet viewer
implement the AppletContext and AppletStub interface, but in this case we have preferred to focus
on particular aspects].
Inside the DABFrameViewer we instantiate the DABClassLoader and we set our
particular DABSecurityManager.
The arguments passed in the main method are information used by the
DABClassLoader to localise the code of the Applet class.

DABClassLoader. It is the more important components of our project. Using the flexibility
of this component we can implement our specific loading process through different
channels: in this case it is a search inside a particular hierarchy directory; in the future we
will implement a particular access to the DAB channel using native methods.

DABSecurityManager. This is the central control for every critical access to the resources of
the DAB terminal. Before starting the implementation of the securityManager we have to
gather all the critical methods we want to control: for example the access to the file
system, the access to some DAB services (accessing MOT files, tuning, etc). Then inside
these methods we have to call explicitly the securityManager to control and filter the
access.

120
DABApplet. For the simulation we have used two very simple Applets. Applet are a good
model for moving application in a network: flexibility, security and easiness. Although
Applets are a good example, they are implemented for being execute inside a Web
Browser: the methods they use are suitable for managing the behavior inside a Web Page,
the special interface is suitable for linking to the particular framework of the Web
context, etc.
An alternative solution could be a new Applet design: new methods, new attributes, new
context. In these case we lose all compatibility to the Internet applications, but we can
develop a more flexible solutions for the DAB system.
These alternatives are linked to the requirements of the DAB download applications: in
the case Java would be a possible platform for DAB applications, the DAB community
have to open a discussion also on these aspects related to the DAB design.

DABNative. These component has been introduced for testing the call to a native function.
This class is stored in the package that have to be provided locally (trusted code - see
chapter 4 for details). There are different possible implementation. One is to use the
DABNative as a normal system classes (for example as the Socket.class or the
System.class); in this case the Applet can use directly a DABNative object and call the
special methods. The second solution is to use static methods: in this case we don't need
to instantiate any object, but we can directly call the required methods. At the moment
we have chosen the first solution.
The native library is implemented using the RNI provided by Microsoft (see fig.
50). Inside the DABNative.class we load the external library (TrafficMS.dll) and
we implement the native mathod.

#include <varargs.h>
#include <native.h>
#include <stdio.h>

#include "DABNativeInterface.h"

__declspec(dllexport)
DWORD __cdecl RNIGetCompatibleVersion()
{
return RNIVER;
}
__declspec(dllexport)
struct Hjava_lang_String *
__cdecl DABNativeInterface_getTrafficMS (struct HTrafficAppletMS *phThis)
{
return makeJavaString("Hello from native code !!!!", 27);
}

Figure 51: Simple implementation of a native library using RNI

The native method in Java class is

getTrafficMS()

and in the C library is

struct Hjava_lang_String * __cdecl DABNativeInterface_getTrafficMS

(
struct HTrafficAppletMS *phThis
)

121
 This component is the basic skeleton for the implementation of native methods to
access the DAB devices.

122
123
Chapter 7 Java DAB Package: a
Complete Java Solution.

"The reasonable man adapts himself to the world;

the unreasonable one persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man."
(George Bernard Shaw)

In the last chapter we have developed a simulation to integrate a JVM inside a

preexistent MFC Web Browser application testing the possibility to integrate the JVM at
the application level. In this chapter we want to follow a different approach and sketch
the main steps to build an application using only Java: we want to expand the Java API to
create a DAB platform for different DAB services. The model that we present here is a
reference model for possible future DAB implementation.
The Java VM is a complete platform to develop different user-end, distributed
and secure applications (Web Browsing, Slides Show, Traffic Information, Weather
Information, Network management, etc.), because the basic Java API offers all the
graphical, security and management tools to create multiplatform application; but it lacks

124
 all the necessary functionality to access specific platform dependent resources, for
example the DAB system.
Some parts of the DAB system are not still standardized (the DAB API at the
application levels, the OS platform for DAB receivers, the contents types for MOT
objects), but we can give some basic steps to use as a starting point for the DAB/Java
integration.
Java is a ″open″ technology and Java developers have thought about a way to
expand the Java VM both at the API level (packages) and at the OS level (Java Native
Interface) (see chapter 4 for details); also Java could be a suitable platform for the DAB
system (see chapter 3).
Using the standard way to expand the JVM and following the different examples
of native extension of JVM core packages (AWT, Serial Communication, JDBC) we tried
to give some basic principles for building a complete DAB package in order to apply
completely the ″Java paradigm″.
The Java platform will be a useful platform to develop both download
applications, but also to develop application inside the DAB system. Java provide 4
different implementation of the Java VM related to different hardware profile: Full Java,
Personal Java, Embedded Java and Java Card. Using the flexible platform, API, and the
extension mechanism we can fit Java in the DAB system.
Usually the native applications are pre-installed in the receiver by the
manufacturers. Personal Java, for example, provides some interesting features for
creating native application in a very dynamic way; we can divide the applications in two
separate portion: one is the core code for the main services, and the second is an
additional part that can be update for adding more features.

7.1 JDAB: Java DAB API

A Java DAB extension API is composed mainly in two parts:

* a native library to initialize, control and access the DAB system (we can call
Jdab.dll)
* a new extension to the Java API (a new package javax.sony.dab)
* possible embedded Java DAB applications

The first part is a complete set of functions written in native code (C or C++) that access
the DAB services at high level through a particular interface (RS232, FireWire link or
specific card). All the interface mechanisms for managing the DAB system should be
implemented at this level: setup of the connection, MOT rebuilding, selection of services,
tuning, access to the native API (WIN32), etc.

125
 New extension
Java DAB
javax.sony.dab.Applet.class
java.lang.*
java.io.* Java core javax.sony.dab.Viewer.class
java.awt.*
API API javax.sony.dab.ClassLoader
…..
…..

javai.dll Native Library

winawt .dll
io.dll
Java Native API DAB DAB.dll

JdbcOdbc.dll
…..

Win32 Basic API

gdi32.dll kernel32.dll user32.dll wsocket.dll ….

Figure 52: The basic component to expand the core API

The implementation of the library is platform dependent. We have to careful and

we have to balance two opposite constraints: from one side we want to maintain the
performance of our system and from the other we want to reduce the platform
dependent pieces of our extension. These library have to be developed for each different
platform in which we want to use the Java DAB API or we have to embed inside the
JavaOS.

The second part is an additional package that create a complete set of Java classes
to control and manage a DAB system in the Java platform. This package will be the DAB
API for all applications written upon the Java VM (see the figure 3) and it will the platform
independent API for all possible JDAB applications.

The third part refers to the possibility of implementing some special application
using the JDAB. In general it not secure (but possible) to load Java applications from the
external environment (from the network, but also from the DAB channel). Applications
are developed and stored locally in the system (or embedded inside the davice): for
example an HTML Browser, a Slides Show Viewer, but also a DAB System Manager, etc.
Traditionally the Broadcast receivers are not accessible as a network computer, but
sometimes there is the need to develop sophisticated applications.
The security of the applications in this case is assured partially by the DAB manufactories
(Sony, Mitsubishi, Grundig) and by the physical storage inside the DAB receiver (ROM).

2.1 JDAB: A Conceptual Framework

Why do we need an additional packages for the DAB system ?

126
Basically we need an extension package to implement the DAB access from the Java
system because the Java API is developed to be portable. The DAB system is a new
medium for the Java platform for receiving information and it is not a standard device
implemented inside the core Java API as a file or a socket network access.
Another reason to add some extra facilities to the JAVA API platform is that the
DAB system need some special management mechanism and some special data objects to
receive information: events management, special control, calling services, security
architecture.
We can summarize in some specific sections the needed extra classes for the DAB
package:

* Security Management
* Resources Loading Process
* Special Data Classes
* General Management of a DAB System
* DABApplets
* DAB Controls
* DAB Event Management: Asynchronous Events

Security Management. To implement a secure environment we need some special classes. A

new SecurityManager have to control the accessibility of the local resources and
manages the local user policy, especially the local access to the DAB receiver. Some extra
check methods or some additional permission classes (see chapter 4 for details on security
mechanism) ought to be added for implementing some specific control for the access to
the DAB resources. We have to be careful during the development of the new methods
that access the DAB resources to control the permission of the downloaded application:
each time a critical access is performed we have to control the permission of the calling
application (see chapter 5 "A Proposal for a Security ..").
In this case we have to develop some special Java classes to personalize our environment
and follow the security constraints. For examples adding new Exceptions form managing
the possible errors; in the new Java security model [JDK 1.2] we have to add some special
permissions; etc.

Resources Loading. The Java environment gives the necessary class to implement a
particular loading mechanism: the ClassLoader class.
We have to implement a new mechanism to load the Java application from the DAB
channel: in these case we can use some special native methods to load the data from
special buffers or we can implement a callback mechanism to receive the needed code
from the file system. Also we have to manage the loading of resources from the DAB
channel: Java application (single or jar files), but also images, text, mail, etc.
We have to decide where load the system classes (including the DAB package): from a
file system, from a ROM memory.
Java is suited for embed inside ROM memory all the necessary code, both the interpreter
and the basic API: today there are some example of Java embedded inside small devices
as phones, TV set-tops, hand held devices, cell phones, pagers, watches, etc.
(http://www.javasoft.com/features/1997/oct/Personal.Embedded.html)

127
Special Data Classes. We have seen that the DAB system use a special protocol to code
multimedia information, the MOT; but also we have seen that on the DAB channel there
are a collection of information related to specific services. We have to create some special
objects (in Java all is an object) to wrap the information received through the DAB
services. A class for MOT objects, for FIC data (configuration information), for Service
Label associated to audio services, etc.

General Management. To manage the DAB application environment we need some extra
classes like new event classes, new exception classes, etc.
All these additional classes are used to exchange specific information related to the DAB
environment and are used to control and manage information between each single part
of the DAB Framework. We need also a container for the loaded application
(DABApplet), that manages in a dynamic way the interaction with the downloaded code.
We need to manage the runtime environment to limit the access to resources (video,
memory, CPU, etc.).
Also we need to define the interaction with the user to implement a new model for
interacting with the DAB applications.
Normally in the Applets framework there is a set of interfaces that create all the
necessary connections for managing the interactions between different objects: for
example the AppletContext and the AppletStub interfaces; developers are in that
way free to implement in a flexible way their computing environment, but they use the
same architecture.

Java DAB javax.sony.dab.*

API
• Exceptions • Interface
• Errors • Hooks to Runtime
• Events • Permission
• Synchronization • Certification
• DABViewer mechanism

Security Loading Special Management DAB Applet

Management classes

• Security Manager • MOT objects

• Permissions & • FIC structure
check • Services
• loading path • Runtime env
• local policy
• DAB class loader DAB Control
implementation
• cache repository
• access to local
resources
• Native access & methods
• DAB controls
• Communication
• Data Transfer
• Initialisation
• Calls for data

Figure 53: DAB API packages - a logical overview -

DABApplet. This is the base mobile object to move code through the DAB channel. We can
define a subclass of the Applet class and specialized the DAB Applet or we can build a
completely new object component for adapting to the DAB requirements.

128
We have to think of the internal behavior of the loaded application (a well define set of
methods) and all the possible hooks to the runtime environment or the DAB controller.
Also in this case we need to define the interaction of the user with the DABApplet.

DAB Control. This is the most critical section of the entire package. We have to study all the
details about the accessibility to the DAB device. The majority of the methods to
implement here are native, because they access the native environment ! These set of
classes are the bridge to the native library implemented in a platform dependent
languages.
Some of the services to implement are: initialization of the DAB device, communication,
exchange information, request/replay/notify mechanisms, data caching, etc.
For implementing these particular class (or set of classes) a standard DAB API is a must:
developer need specific interface for reducing time for porting in different DAB platform.

DAB Event Management. In the DAB system, some interactions are asynchronous. Some
notification mechanism are implemented used some specific callback mechanism. In Java
we can implement that mechanism using the approach followed in the AWT Event
architecture. In this case we have to define some Event dispatcher thread, some new
events and some new Event listener.
A simple implementation could be: a dispatcher thread polls an event queues and using a
native call retrieve some event object; for each particular object a source object is bound
to the event; if a listener object is defined and set for that particular source, the
corresponding callback method is called.

D A B Weather
B r o w s e r Broadcast
DAB package
Java DAB Apps
Multimedia GPS Slide
Show NavigationSystem Show
Java VM
Java API Java DAB sony.dab.Applet.class,

API
java.lang.*, java.awt.*,java.net.*, sony.dab.Viewer.class,
java.io.*, java.applet.*, etc sony.dab.ClassLoader

Java Win32 Int.

msjava.dll (MS), javai.dll (Sun), Java Native API DAB DAB.dll (?)
winawt.dll, net.dll, JdbcOdbc.dll

Win32 platform
Win Basic API
GDI32.dll, KERNEL32.dll,
USER32.dll, ADVAPI32.dll,
etc

Figure 54: DAB extension of the Java API - a complete overview

129
 " Not high tech, not low tech, just the right tech."
(Mark W. McBride on Scandinavian PC Systems)

130
Conclusions

Distributed computing, DAB, Java: these three words are the main topics in this
work.
Distributed computing is a revolutionary paradigm in computer industry; DAB
is a revolution in the Broadcast systems; Java is a revolution in the programming
languages. In this thesis we have tried to find an integration for these three technology
for implementing modern services and for adding a new step toward the concepts of
ubiquitous computing.
We have used the typical approach of industry researchers: we started from
theoretical aspects of mobile code models, we passed through the available technologies
present in the market and finally we have developed a new sperimental application to
test the possibility offered by a specific tools, Java.

131
 We know that there is no a optimal technology to solve every problem: software
engineering is a branch of engineering that tries to find out for each particular system the
best solution.
Our investigation proved first that a mobile code approach extends the
capabilities of the DAB terminal environment; it prepares the DAB system to the
challenge of the future competition for providing data services between different
communication technologies: GSM, GPS, Internet, etc.
In this context Java can be a good choice from different point of view. From the
manufacturer point of view Java is a common solution for most of the present and future
embedded system; it is a de facto standard platform and a standadisation process is
running for a de iure acceptance. From the content provider point of view Java is a very
flexible and complete platform to integrate different computing fields: data manipulation
, multimedia, network access, etc. Finally from the developer point of view Java is an
easy programming language for fast development.

Now it is time to start a dialogue between different parts in the DAB community
for exchanging the sperimental results and think about the next steps.

132
133
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. Pricipal 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

134
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 - J.A.Bank - MIT Report
11. Java Security Architecture -(JDK 1.2) Li Gong
(www.javasoft.com/products/jdk/1.2/docs/)
12. Java for Embedded System: a tutorial (D.Mulchandani) IEEE Internet Computing [
May-June 1998]

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
1. Java Native Interface Specification - Release 1.1 - Sun Microsystems (May 1997)
2. Web sites (http://):
a)premium.microsoft.com/msdn/library/ - MSDN Library

135
 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

Chapter 7
1. Web sites (http://):
a)
b)
c)

2.

136
137