Title:

Platform Independent Download of

Applications in Data Broadcast Environments

Student: Antonio Barletta

Supervisors: Rudolf Bittner Markus Zunkeller Gil Müller

To all my Friends

Contents

Chapter 1 Introduction

1.1 What is DAB ? ....................................................................................2 1.2 A Software Platform for Downloading Applications using the DAB

System.................................................................................................5 1.3 Examples of DAB Applications..........................................................6 1.4 A Brief Description of the Contents of this Thesis.............................8

Chapter 2 Mobile Code

2.1 A Brief Introduction on Communication Mechanisms.......................13 2.2 Distributed Computing Paradigms......................................................14

Client/Server Architecture

3-tier Architecture Remote Evaluation & Execution Code on Demand Mobile Agent

2.3 Classification of Mobile Code Mechanisms ......................................20 2.4 Programming Languages Concepts for Mobile Code.........................24

Language Level Abstract Machine Level Library Level

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

Chapter 3 Technologies

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

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

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

Scripting Languages 3.11 Tcl/Tk..................................................................................................52 3.12 Internet Scripting: JavaScript, Jscript, VBScript ................................53 3.13 Comparisons & Comments .................................................................53 3.14 A Technology for the DAB System....................................................58

Chapter 4 Java

4.1 Java Architecture ................................................................................64 4.2 Virtual Machine ..................................................................................65 4.3 The Class File Format .........................................................................67 4.4 Loader: How Code Born !...................................................................70 4.5 Garbage Collector ...............................................................................73 4.6 Java Language: A Deep Sight.............................................................73

Exceptions Concurrency Serialization RMI Java Family: JRE, SDK, Personal Java, Embedded Java, Java Card

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

Chapter 5 Download of DAB Applications using Java

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

Chapter 6 Simulation

6.1 Overview of the Simulation ................................................................ 6.2 Integration of the Java Virtual Machine: MS COM ........................... 6.3 Software Implementation: the Main Java Component........................

Chapter 7 J-DAB Package: A Complete Java Solution

7.1 JDAB: Java DAB API ........................................................................ 7.2 JDAB: A Conceptual Framework .......................................................

Conclusion

References

Chapter 1 Introduction

“The quest to know the unknown and see the unseen is inherent in human nature.

It is this restlessness that has propelled mankind to over higher pinnacles and ever deeper depths. This insatiable desire led to the discovery of light

as being electromagnetic, paving the way to the discovery of the radio."

(Saleh Faruque - Cellular Mobile Systems Engineering)

Nowadays the technologies of the three major industries, entertainment, computing and telecommunication are converging. In the new era of digital communication, many different systems are being integrated. During the last years Internet applications and services have been the leading technologies for new advanced digital communication infrastructures. Many fields related to telecommunication are today thinking about the integration with the "mother of all networks" - the Internet. DAB, Digital Audio Broadcasting, is the advanced successor of FM broadcast radio systems. This new system gives listeners interference-free reception of high quality sound, easy to use radios, reliable mobile reception and overall the potential of a pure digital channel to receive all kind of data (MPEG audio, videos, images, text data and code).

Digital data opens to a wide area of broadcast applications because it is the base language used in the computing environment and it can be used as a link to the world of the computer and tele com 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.

Entertainment

Telecommunication Computing

Database

InternetMobile Code

Virtual Machine

Distributed Systems

Videoon

Demand

MultimediaMusic

GPS

Broadcast

GSMSingle FrequencyNetwork

Mpeg 2 Encoding

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 digital datacommunication applications, now are ready to compete and to integrate with other distributed multimedia computing technologies.

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

* scalable

* ubiquitous

* low capacity data channel - FM-RDS

Unidirectional and scalability are the main characteristics of broadcast systems: signals are broadcast by a single source and are received by a large number of users and the amount of traffic (occupied bandwidth) is independent from the number of possible users: these aspects make the radio system suitable for low cost large scale data broadcasting. Ubiquitous computing is related to the physical medium used to transmit the radio signals. Whenever a wire is unavailable or unnecessary, wherever mobility is a big constraint radio systems are the best solutions: boats, cars, small cabins, historical buildings, mobile stations, PDA, Walkman, etc. Besides all this positive aspects of traditional broadcast radio systems, AM and FM radio miss some issues and there are some big disadvantages: noise interference, multipath propagation on mobile systems, interfrequency interference, low quality audio (with respect to CD or DAT audio quality), a poor number of extra services (FM-RDS), etc. What are the new features of the DAB system and what kind of services can be developed ? The DAB transmission signal (see chapter 5 for details) carries a multiplex of several digital services simultaneously; it uses advanced digital audio compression algorithm to achieve a spectrum efficiency equivalent to or higher than that of conventional FM radio. Its overall bandwidth is 1.536 MHz, providing a useful bit-rate capacity of approximately 1.5 Mbit/s in a complete "ensemble". Each service is independently error protected with a coding overhead ranging from about 33% to 300% (200% for sound), the amount of which depends on the requirements of the broadcasters (coverage, reception quality, number of services). The ensemble contains audio programmes, data related to audio programmes, and independent data services. Usually the receiver will decode several of this services in parallel. A specific part of the multiplex contains information on how the multiplex is actually configured, so that the receiver can decode the signal correctly. DAB system is the best gateway to move digital data towards mobile devices and it is suitable for providing integration with other communication architectures (Internet, GSM, satellite networks). Actually there are other digital system to broadcast information: DSR (Digital Satellite Radio) and ADR (Astra Digital Radio) are two services provided by the use of satellite channels. They both provide CD-quality radio (with none or some kind of compression mechanisms) using large bandwidth and they both lack good performance for mobile devices and they are not suitable for local radio services. DAB, in brief, is characterized by the following attributes: * high quality audio

* high bitrate downlink channel

* optionally low bitrate uplink channel (GSM, Telephone lines)

* ubiquitous of the target users;

* small quantity of information that interests a large number of users;

* access time is independent from the number of users (scalable)

* designed for mobile reception (car, wireless device as radio, Walkman)

* one system standard for the whole European market

* unidirectional, scalable, data delivering communication;

* economicity of the medium

* electrosmog

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

DAB active services

DAB sperimental services

interested countries

information not available

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

1.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 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 a nd 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 so lutions.

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 transmit extra data along with the radio programme which identifies what sort of programme is, Classical Music or News, and users can search all the DAB radio services that match some special requirements. In DAB are also available some extra features to provide pay radio or data services: broadcasters might offer special services (both audio or data information) available only on payment, which users would subscribe to on an individual or long term basis. Dynamic Label. DAB provides a flexible way to associate and synchronize a data information channel with audio programmes. This additional data has a variable capacity from a minimum of 667 bit/sec up to

65 kbit/sec. This additional information can be used to implement different new services: dynamic label messages, Karaoke-like transmission of lyrics, multilanguages information transmission. Travel/Traffic Information. All information for traveling can be retrieved from a DAB service. Using text, images, maps and applications we can coordinate and inform car driver about all kind of information (from hotel prices to traffic situations) needed for a good and secure trip. The DAB system is a perfect medium to communicate this kind of information. Broadcast Web Site. Once we have build a new communication medium, we can develop a Web Browser application to receive HTML pages, Java DABApplet, Images like a normal network link. DAB is a high bitrate downlink medium for providing a selected number of Internet services: traffic information, weather forecast, sport news, emergency messages, entertainment, etc. Commercial Applications and Data Download. For a large company that has to exchange common information (price reports, software patches, internal communication) to a large numbers of branches customers, DAB offers low cost and secure services. For example a car company has to inform thousands of car shops around a large area like Europe about new price lists or new offers; then each single shop can use some feedback channels (Internet, phone, mail) to order specific items. A software company can offer software uploads for their customers. To realize these kind of closed user group services means to control access to potentially confidential data are required: conditional access systems and cryptography.

DABDABDownlink path

UPlink pathTrain/Flight Timetable

Information

I want to reserve a ticket ..

Booked !!

Internet

Figure 3: Example of DAB/Internet integration

Entertainment. The combination between sound transmission and application contents can be used for creating a new way of broadcast radio entertainment. For example the Slides Show: in this case broadcaster can transmit additional data that may include comprehensive information about a piece of music being played, such as the song title, composer, singer, album name, album picture, video frames and so on.

Brokering Information & Stock Quote Systems. Information about sport results or stock prices can be delivered using DAB and be presented by Java application. A brokering agency can deliver information to users using a ubiquitous medium like DAB. Polling & Surveying. Agencies that collect information can create a polling service upon the DAB channel, asking general information and can receive the feedback from the users by the means of GSM mail service, Internet mail, etc. Multimedia Home Network. The DAB receivers will be just a node inside a home multimedia network together with HIFI systems, digital TVs, digital cameras, Settop boxes, etc: Java would be the glue for all these different platforms.

DABDAB

Internet

GSM

What do you think aboutthe italian new parliament ?

???!!!!@:-(

?!!@:-(

Figure 4: Another example of a possible DAB application

Web/DAB Integration. Once we have created a software bridge between Java and DAB services, the computer can be an hardware bridge to the Internet: we can think about a global network in which we can move and optimize data exchanges. We can use the characteristic of the DAB channel to reduce traffic congestion on the Internet networks for some special kind of information. Games. Using download application means the possibility to move also games. User can receive games in their DAB car radio: the runtime environment with graphical output provides all the facilities to create this services.

1.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 articles 1, 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, programming language features, security mechanism, Java API, native interface, Applet model, etc.

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

Chapter 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

1 See references for a detailed list of documents

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.

Chapter 2 Mobile Code

“Independence of the design paradigm from the underlying technology

is a major point in general software engineering practice”

“Designing Distributed applications with Mobile Code Paradigms”

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

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

systems. The Internet world has been a exsperimental platform for lots of new distributed technology: we want to use all these experience for start the development of new solution for the radio services using the DAB system.

♣♣♣ In an heterogeneous computing environment we need new approaches to develop efficient applications and we can not use classical paradigms or technologies used for stand alone machines: that's why we analyze at the beginning of this thesis the new features of the Distributed Computing Environment and the new methods of the mobile code technology. A global network links together many different systems, so we need new approaches to create new ways for exchanging information: solutions to the new problems arrive both from the academic world and from the industrial research centers. We decide to start with a brief general introduction and a classification of mobile code architectures to have some theoretical tools in order to compare the different implementations nowadays available on the market: a more complete survey is available in [1], [2]. The expression "mobile code" is used with various different meanings in the technical literature; for our purpose we define mobile code "as software that travels on a heterogeneous network, crossing protection domains and is automatically executed upon arrival at the destination"[1]. For protection domains we intend both wide area networks and small embedded systems (DAB radio receiver, Personal Digital Assistant, Smart Card, etc.), the only requirements is that all nodes are linked via a specific network medium that permits to move digital information.

♣♣♣ "Code Mobility" is not a recent discovery: we have already some examples. (For an introduction on the mobile code see reference [1].) * PostScript Language is used to send a series of commands describing the pages to be printed and sending these "programs" to the printer; printer have a complete special purpose computing environment to evaluate the commands that clients send; * SQL Script Language is an efficient way to balance the database processing load on the server machine where the data resides; in this case the specific language is suitable for database queries, updates or data manipulations; * Web Browser Application: to have a dynamic behavior on the HTML pages many proprietary solutions have produced some special mechanism to transmitted executable contents on the network (the well known Java Applet mechanism of Sun Microsystems, ActiveX controls of Microsoft, embedded multimedia contents of the Netscape Browser); the code is automatically fetch from network sites and is executed in the client machine where it uses all or partial resources (memory, Microprocessor, Hard Disks, etc.); * Software Distribution and Installation problem: this specific application has produced many proprietary solution as Inferno of Lucent Tech., a mobile code enabled network operating system for media providers and telecommunication systems; the management of the software installation is a typical application where code mobility can give a better solution than the old strategies for its particular features: scalability, customizability, etc. These are only few example of the possible applications of mobile code, but as you can see they try to solve some specific constraints to built efficient systems in terms of scalability, network traffic reduction, security, minimal overhead and performance. Mobile code technology is not a new approach, but until now it was relegated to very specific applications: these new model start to be investig ate 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 theoret ical 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:

Messages

RPC

Stream

Point-to-Point

Events

Group Communication

Shared Memory

Tuple Spaces

Multicasting/Broadcasting

Point-to-Multi-point

Communicaton mechanisms

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

Code Component

Resources Component

Service

Computation Component

(CPU,memory,VM)

Interaction

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

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

We distinguish:

* Client/Server architecture (pure) - already mentioned - * 3 tier architecture (N tier architecture) * Remote Evaluation * Code on Demand * Mobile Agents For analyzing these different paradigms we should consider some parameters to point out the main advantages related to a particular approach. In brief these parameters could be: * Number of interactions (generated network traffic) * CPU costs in terms of calculation * Security * Performance & Simplicity of the implementation * Scalability * Latency Optimization * Push and Pull capabilities

Client/Server Architecture.

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

between these environments, while in the object oriented distributed application, the computational environment is an abstraction layer that hides all the network system.

Client/Server (pure)

Service

Computation Environment

(CPU,memory,VM)

message

Client Server

Es: RPC, HTTP, FTP, Xwindow

data

data

Code

Figure 6: Client/Server (pure) Architecture

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

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

3 tier architecture

Service

Computation Environment

(CPU,memory,VM)

message

Client

Server

Es: HTTP/CGI code

Server/ClientComputation Environment

(CPU,memory,VM) code

Service

message

presentation processing data access

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

Service

Computation Environment

(CPU,memory,VM)

message

Client Server

Es: Remote Unix shell (rsh),Scripting, SQL,PostScript

code

message

Figure 8: Remote Evaluation & Execution

Code on Demand.

Many upcoming Internet applications are based on this paradigm. In this case a client has already all necessary components to execute some service, but it does not have the know-how; the provider machine gives the necessary know-how "on demand", that is in replay to a request of the client machine (in general this is automatically controlled by applications); the client machine must have capabilities to download, link, run the code automatically.

Each client has a complete computing engine; for the portability of the distributed code, all machines that interact with the server must have the same computational capabilities: for that reason for implementing this kind of paradigm we need a complete virtual machine (a machine with the same computational characteristics in spite of different platforms). Among the many existing proposals, the most well known is the Java Applets technology of Sun Microsystem; other technologies are ActiveX from MicroSoft, Obliq from DEC Lab, etc. We can see that the code is fetched from a source in the network and once it is in the host is executed.

Code on Demand

Service Computation Environment

(CPU,memory,VM)

message

Client Server

Es: ActiveX/IE4.0, Applet, Web services

code

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 autonomous ly. This intelligent agent seems to be the best way for intelligent network and seems to resolve problems related to efficiency, customization, management: mobile agent has become a huge industry buzzword, especially in the business applications! A complete process (an application running) can be moved from one site to the other with its execution data (variables) or completely with its execution state (stack image, register values). This approach is more complex than the others and it needs a complete framework environment that manages the migration.

Mobile Agent

Service

code code

Service Service

Computation Environment

(CPU,memory,VM)

Computation Environment

(CPU,memory,VM)

Computation Environment

(CPU,memory,VM)

Es: Aglet,Obliq

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

COS COS COS

COS Core Operating System

HostHostHost

True Distributed System

Network Apps Components

COS COS COS

COS Core Operating System

HostHostHost

CE Computational Environment

CE CE CE

Network Apps Components

NOS Network Operating System NOS Network Operating System

NOS NOS NOS NOS NOS NOS

Hardw

are

Hardw

are

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.

Computational Environment

Execution Units

code

stack/registers

data space

Figure 12: Computational Environment Components

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

code mobilitydata mobility

data+codeonly datacode + data state

code+data+exec state

Remote Execution

Codeon

Demand

Weak Migration Strong Migration

Client/Server

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

The previous concepts can be considered as a base framework to start an analysis and a comparison of the technologies in the distributed computing systems. The choice of a paradigm for the design of a distributed application is a critical decision. Much of the success of the development process may depend on it; but there is no paradigm that is better than others in absolute terms. The choice of the paradigm must be performed on a case-by-case basis, according to the type an application and the characteristic of

the physical systems: a management application on a computer network, an information retrieval system on a radio broadcast environment, a smart card solution for Automatic Teller Machine, etc. From [6] we see that paradigms and technologies are not completely orthogonal. Although it is possible to use a single technology to implement many kind of computing paradigms, there are some technologies more suitable to implement particular design. Technologies sometimes are too powerful or too limited to implement a particular architecture: in the first case the use of resources is inefficient; in the second programmers have to code all mechanisms, to use extra structures, to implement special policies that technology does not provide. In the following section we will go into more details about the technology attributes that characterize the computational infrastructure of a mobile code system.

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

Languages Level

Abstract Machine Level

Library Levela Graphics supporta Networka Encryptiona Hierarchical Class Support

a Interpreted or Compileda Strongly Typed or Typelessa Programming Paradigm

a Concurrencya Security Modela Memory Managementa Memory Architecturea Platform Architecturea Mobility Mechanisma 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, but they lack portability and we have to compiled the code each time we want to move the code in other platforms. Interpreted languages (Visual Basic, JavaScript, Jscript) instead are based on special execution engines, called interpreters (in general developed for each platform), and they are interpreted directly from the source code to the code of the particular executing machine: this middle software level produce worse performance, but it is a complete portable architecture ("write once, run everywhere").

Some new languages support a third way: they compile the source code in a platform independent format for an abstract machine architecture and they execute it with some interpreter engine or sometimes with a so-called Just-In-Time compiler (Java of MicroSoft Browser, Limbo of Lucent Tech., etc.): this solution is a compromise between performance and portability. Strongly Typed versus Typeless. Languages can be defined to be typeless or strongly typed. In the first case all data belong to an untyped universe. All values are interpreted when manipulated by different operators; there are no restrictions on how data can be manipulated (more flexibility), but there is the problem of nonsensical or erroneous manipulations: this can be a great disadvantage for security policy and maintainability of the code (reduction of readability and maintenability). Examples of typeless languages is the C language. In the latter case, programmers can use only a secure set of typed variables and each manipulation of variables can be controlled at compile-time; to increase efficiency the control can be performed at run-time. Examples: Java, Tcl In a mobile code system strong typing can be practically impossible to achieve for two main reasons: first, code can be downloaded and linked at run-time from remote host; second, resources may be bound to a program as it is executing. Between these two extreme many technologies have tried to find the right balance (Java, Limbo). Programming Paradigm. The majority of modern languages use the Object Oriented Programming paradigm (OOP) for its basic characteristic (reusability, inheritance, encapsulation, security mechanism) (Java, Obliq, Telescript); others use different paradigm and less complex instruments, but in general they give some form of code modularity and security issues.. Some versions are based on the more traditional imperative (or procedural) and functional languages, but they have some specific additional security features (Limbo, Objective Caml). Mobility. At Language Level, the mobility mechanism are some time implemented in a transparent and automatic way directly in the Abstract Machine Level, or sometimes there are explicit mechanisms for triggering the migration in the network. Some implementation use only some specific network mechanisms (TCP, UDP, HTTP connections on computer networks), while others give some loading mechanisms for general purpose code mobility. Abstract Machine Level. Platform and Memory Architecture. Fundamentally the Abstract Virtual Machine is a concrete computer architecture implemented in a software way: that is we have all the physical components (registers, Memory, devices) of a hardware machine, but are all virtually built using software components (stack, variables, handles, etc.). The characteristic of this machine depend on what are the goals of developers: the Java VM looks like the Intel 4004 processor (used for embedded applications) and need few hardware resources, while the VM of Lucent tech., Inferno-Dis, is a RISC-like implementation with good configuration from high end system to embedded phone machine. From a programming point of view nothing change, but if we are looking for specific performance or we want to have a flexible architecture we have to consider the nature of the implementation design. Also the Memory Architecture follows some hardware specific requirements, but all implemented via software: stack base design, memory-to-memory design, etc.; in these case we have to consider the possibility to implement the design "idea" with the underneath hardware platform (virtual memory mechanism, security features, etc.). We have to be carefully on the memory protection mechanisms: some memory protection mechanism are implemented directly in hardware in a platform dependent way, while in some abstract machine implementation all protection mechanism are implemented via software. We can see again that the goal in the platform design, is either having a general purpose portable design or getting some specific efficient features for embedded systems. In general, in the memory design, it is implemented an automatic memory control, the so called Garbage Collector mechanism. This is done for many reasons:

• it is not efficient nor simple to control memory allocation in a distributed computing system when

some object can reside on remote systems;

• it is better for security reason and for automatic binding of resources that the VM can control

completely the memory access; otherwise memory dominates the costs of small systems, so the VMs

should be designed to keep memory usage as small as possible;

• memory bugs are difficult to control, so an automatic memory management can help to built safe

applications.

All Virtual Machines for mobile code follow in some way this rules. Security mechanisms. General protection of the running process is performed in general by hardware memory mechanism, confining the code in separate memory spaces; but sometimes this could be a solution too expensive for small devices; some security features are implemented at the Abstract Machine Level in order to control the executed code. During the loading and the linking process we can verify the contents of the code itself and control it before the execution; a sort of Security Monitor can be implemented to control the access to some resources or to manage trusted and untrusted references (Security Manager in Java). (A more complete study on security mechanisms is reported in the next section ) Concurrency. In this case we point out the capacity of the Virtual Machine to manage two or more applications (single thread process or threads on a multi-threads process) at the same time in order to improve the use of the CPUs resources. In general a thread is an independent execution resource managed and scheduled by the opera ting system; the OS associates the CPU, a set of instructions and a stack context (including local variables) to a thread. The first Operating System responsibility is to manage computing resources. One of the ways the OS manages is by scheduling access to the CPU to the various programs that are executed contemporarily. Programs then can be made up of multiple threads. Threads became a fundamental part of the operating system and nowadays they are spreadly used. In general we use a collections of threads ruled by a preemptive or an cooperative scheduling. The first is better for a strong thread control because the CPU gives to each thread a fixed time slice to execute its code: the second is better for multimedia or real-time applications, in which it is the programmers that manage the CPU resources depending on the need of the application. Some Abstract Machine give the possibility to use embedded concurrency techniques in spite of the underlying platform (Java on Win 3.1), others use the specific instrument of the platform in which they are running). Mobility: Shipping or Fetching code ? We have talked about moving the code: but who is moving the code ? In some cases clients ask to directly a server to download the necessary code (fetching), while in others the server move the code towards different clients (shipping), and sometimes the code can move alone (mobile agents). The first two mechanisms seem to be exactly the same (it is just a problem of symmetry), but they hide different mechanism for loading, linking, resolving and running applications; the third is a more sophisticated way to move around the network and need a more complete framework environment. And what about the structure of the code itself ? In general we encounter two basic ways to move code: a single block and an applet-like way. In the first case we have a single block of code that is run completely from the beginning to the end (PostScript file, UNIX remote shell Script). In the second case it is applied a more object oriented solution: you can use a set of method to control and trigger in a dynamic way the behavior of your applications ( init(), start(), .., stop() for the Applet, OnDispatch(), OnCloning(),.., OnArrival() for the IBM-Aglets, Objective Caml applet from INRIA). Linking Mechanism.

One of the main characteristics of the modern operating system is the possibility to call functions libraries or external code at runtime and linking this code directly on the calling process: these techniques allow programmers to produce modular, flexible and smaller applications. Some example are: the DLL mechanism in the Windows environment, class loading and linking techniques in Java, modules loading in the Inferno system, etc. Library Level. Since it is important to built secure systems, the control on the implementation of external libraries is of fundamental importance. In general there are set of libraries ready-to-use and tested in order to control the behavior of the entire programming environment. Some particular implementation include inside the libraries some extra features related to control access to critical resources. For example inside the Java libraries each time we use some critical method a security check is done for control the permission of the calling applications. Graphics. The existence of a complete set or packages to develop a graphical user interface is a strong advantage on choosing a platform for mobile code: an easy and ready to use library, can allow from one side developers to focus their attention on mobility skills and from the other have an integrated, secure and stable graphics interface. Java and Inferno/Limbo, for example, provide these features. Security instruments. Some complex mechanisms to built some specific implementation of security are enclosed in ready to use library: security interfaces for authentication and certification, security algorithms, etc.

2.5 Security & Safety of Mobile Code Technologies. Code mobility paradigms may be implemented only with the help of a complex framework: basi cally a programming language, an abstract machine (interpreter or just in time compiler) and sometimes a complete library. One of the major issues in a distributed environment is the security of the system. In an open network security became a big constraints; the increase of systems complexity is a big concern also related to the security. More complex is the system, more weak is ! We need special attention to how we can build a secure and safe system, and where implement the controls. In general the degree of security is related to the weakest "ring of the chain": " You can build a 100 billion dollar secure system to prevent access to private password in your system, but are you sure that your system manager will not give this information for less ? " (A.Lioy - Security and Distributed Programming Professor at the Politecnico of Turin) Another aspects is related to the nature of code mobility. As the mobile code is crossing protections domains, special care must be taken in order to protect it against external computing environment and special care must be taken by computing environment against malicious mobile code. A good introduction on these issues could be found in [1]. We distinguish four security properties:

* Confidentiality (or Secrecy)

* Integrity (or Accuracy)

* Availability

* Authenticity

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

* Communication Level

* Operating System Level

* Abstract Machine Level

* Programming Language Level

Communication Level At this level the network is a collection of computer connected with hardware networking technology: the requirements at this level in general are concerning the robustness and efficiency of the protocol. But how the information are protected by eavesdropping or how the confidential of exchanged information is controlled ? Only in these years new secure features have been introduced at network layer (IPv6); HTTPSecure and SSL (Secure Socket Layer) are some implementation that are located just on the HTTP and Socket mechanisms. This new protocol based on cryptography techniques controls and manages confidentiality, integrity and authentication, but they seldom lack availability: lots of examples are related to the problems of deny of services in Internet. Operating System Level Safety and security at the communication level is not sufficient in general. Handling safety and security is also a primary concern at the operating system level. Historically, memory protection and privilege levels have been implemented in hardware: memory protection via base/limit registers, segments, or pages; and privilege levels via user/kernel mode bits or rings. The recent mobile code systems, however, rely on software rather than hardware for protection. From a more general point of view, network hosts can be represented both by high-end machine and by smaller embedded system with no hardware memory mechanisms. The switch to software mechanism is being driven by two technological trends: portability and performance. The first one permits to have a platform independent security mechanism; the second is reached because software protection offer significantly cheaper cross domain calls. Confidentiality and integrity can be achieved by controlling process access to information and communication channel; to control availability we can limit the access to all needed resources (disk space, memory usage, number of process, graphic access). Authentication is usually established through an initial identification of the user and maintained by some protected OS structures. Abstract Machine Level Safety can be obtained also at Abstract machine level: the virtual machine can implement some specific features, that in general are implemented by OS. In fact using a language independent abstract machine retains all the language independence of the operating system solution, but does not have portability problems. At the Abstract Machine level you can control access to resources through the use of a set of secure API: you can enforce protection of internal structures of VM. Programming Language Level. At this level we pay each secure mechanism with the flexibility of the programming language: the majority of modern programming languages have some controls against low-level errors through mechanism like typing, restricted pointers, automatic memory management, and array bound checking. It

is possible to go even further and use the language scope and access rules to protect the interface of resources. As an optimization, the high level program can be compiled and type checked before being shipped as mobile code, but can we be sure that the object code is really a non tampered output of a correct compiler ? Three techniques have been proposed [2]: • using cryptographic signatures to reduce the problem to one of trusting the author (ActiveX) • using cryptographic signatures to trust compilers, in this case we use only a small number of

trusted sites for compilation and certification (Inferno/Limbo) • compiling to an intermediate language which can be checked to verify the same constraints that

are imposed on the source language (Java) These techniques are not exclusive. You can use some combination of these techniques to improve your security wall. For example you can combine the use of cryptographic signatures and trust compilers: it seems easily feasible as they require much of the same technology and infrastructure [1]. As we have seen "Security is a global property, so a security model must take into account all aspects of the system supporting the execution of the code. This includes in particular the hardware, operating system, the abstract machine, the modules libraries, the security manager, and the browser (in this case it means the container of the mobile code). A security weakness in just one of these endangers the security of the whole system [1]".

“Consider the past and you shall know the future.” (Chinese Proverb)

Chapter 3 Technologies

"Strong typing is for people with weak memories" (Toman Vleck)

A number of mobile code solutions have been developed in the last years by the main software Companies (Sun, Microsoft, IBM, Lucent, DEC) and by a number of academic research centers (Berkeley, Stuttgart, Zurich). As we have seen, mobile code applications can follow different implementations approach in spite of the specific goals of the designers and follow different mechanisms to exchange information. Our purpose, in this chapter, is to provide the readers an overview on the basic characteristics of the products now available on the market, following the architectural frameworks (paradigms, techniques and instruments) explained in the last chapter. Using the theoretical tools of the previous chapter we also want to identify the differences and the similarities of the distributed computing technologies and find the best suitable solution for our particular domain (see next chapters).

Talking about technologies means to investigate the basic practical tools used for implementing a certain kind of engineering solution: that is talk about the architecture, the software components and tools, the qualitative performances, etc. A starting point for a complete overview of mobile code technologies can be found in [1]. In these subsections we will classify the different technologies in 4 main groups:

• Virtual Machine/OS

• Architecture for Object Components

• Mobile Agents

• Scripting Languages

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

Virtual Machine / OSes

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

2 In this chapter we refer to the JDK 1.1 implementation of Sun Microsystems and the JDK 2.0 of Microsoft, both developed for the Win32 platform.

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

Interrupt

Java Application

DeviceManagement Memory Graphics

Native Operating System

Java class

java.awtjava.netjava.io java.math

I/O TCP/IPnativeMath

GraphicPeerclass

Java VMClass

LoaderLinker thread

mgmt.

Java API

OS API

HD API

byte

code

C /

byte

code

asse

mbl

er /

C

Figure 15: Java Architecture

Language Level. The Java programming language is based on a simplified variant of C++ (the developing language most used on the market and in the academic world) with all unsafe and most complicated language features removed: unsafe operations, like pointer arithmetic, unrestricted casts, unions, and features leading to unmantainability programs like the C preprocessor, unstructured goto, operator overloading, and multiple inheritance. In computer science terms, Java is strongly typed and late bound with dynamic linking programming language. It supports encapsulation, which reduces complexity; it is strongly object oriented, where inheritance, polymorphism and delegation help to reuse the code; array and string types are built-in with range checks for all accesses. Exception handling has also been added, in order to permit the creation of robust programs. Concurrency is provided at the language level with thread and serialized methods, using mutex-locking technique on the corresponding object. Java includes a novel notion of interface types. Interfaces define a collection of abstract methods and attribute variables with their associated types. A class can be declared to implement an interface, in which case it must implement all the methods of the interface. Whenever a value of an interface type is expected, a value of a class implementing this interface is used. Interfaces are useful for a number of purposes: they can be used to hide the implementation of a class and to group classes with a common functionality without forcing them into a class hierarchy. Java also uses the notion of package. A package groups a number of class and interface definitions. A class can be defined final (disallowing subclasses of itself to be derived), abstract (disallowing instances to be created), and private (limiting the scope of the class declaration to the containing package).

Attributes have four levels of visibility: private, default, protected, and public. Private attributes are only visible from within the object itself; default visibility extends visibility to the package in which it is defined; protected attributes further extend the visibility to subclasses of defining class, potentially defined in another package; finally, public attributes are visible everywhere. As we can see Java is more than a traditional programming language: it is a instrument built to help programmers to develop object oriented applications skills and to create a secure platform to manage code in a distributed computing environment. All these aspects make Java a complete operating system language, as C++. Abstract Machine Level. Basically the virtual machine of Java is a virtual hardware platform. Today processors have high computing capabilities and they can simulate by software a complete hardware platform for building a software layer between different specific platform and user applications. From an architectural point of view, the Java VM is like the Intel 4004 processor, with a minimum number of registers (4) and a stack base memory architecture; this requirements allow to implement the VM on almost all hardware platform, from embedded systems to high power computers. The VM have its own machine language, the so called bytecode, that is used unchanged for each VM: it has both efficiency of a compiled code and portability of a interpreted code. The VM is not a monolithic piece of code. Since it is designed with portability and scalability in mind, it heavily uses separate subsystems for threading, memory management (Garbage Collector), native method interfacing, native system calls, loading, verifying and linking code, etc.. Each block can be used and configured for specific purposes and can be added or removed to adapt to specific software and hardware requirements. For example some embedded implementations of the JVM don't need the GC module or the verifier module, because memory management is done manually and Java classes are embedded inside the ROM memory. Automatic memory management (Garbage Collector) has been added, protecting execution from memory allocation/deallocation and pointer errors due to manual memory management; as we have seen, automatic memory management is a key-point in distributed systems both to control and manage resources and for security reasons. The most interesting part of the VM is the execution engine itself, which comes in two different flavors: interpreter and "just in time" compiler. The first is just a translator of the bytecode commands, while the second is a more efficient way to execute Java code in a platform dependent way using caching technique for the frequently used blocks of code. The second solution is surely the more efficient but it lacks portability, because the VM implementation is strictly dependent on the specific machine. A JVM is available for a huge number of different hardware platform and OSes: from RISC based processor to Intel Pentium, from embedded system to PDA, from MS Windows platform to Sun's Solaris, etc. Library Level. From the beginning of its life, Java has been shipped with a set of libraries (JAPI) that have given programmers a complete and secure class based environment. System classes are a complete set of pieces of reusable (using inhe ritance technique) code for permitting to programmers to focus on their specific tasks, without worrying about all parts of the system. The Java Development Kit (JDK) from Sun range from GUI interface to HTTP communication libraries, from complex Math calculations to remote procedure calls. The importance of the Java class libraries is in its role for built a secure system: Java class libraries are written in such a way that all sensitive operations call into a centralized object, the security manager, to check whether the caller is allowed to invoke this operation. Programmers can built their own security manager to trigger the security of their environment. Initially JDK was the only Java Technology available for application development, because Java was positioned for the Internet market. Sun nowadays is looking seriously to other specific market segments. You can adapt your Java system for different platforms: Personal Java for Network computers, smart phones, handheld PDA; Embedded Java for embedded systems and Java Card for smart card technologies. They all are designed to be upwardly compatible, so you can run your applications on the upper API implementations.

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

Applications. Java is an environment to implement complex distributed applications. From its birth Java has collected a huge number of different applications: from commercial oriented application to agent based platform, from embedded device management to software component. A complete OS, JavaOS, has been built. JDBC is a package for database interfacing using ODBC standard. Java Beans is a component architecture for Java enabling re-usable software components. Java 3D, a set of libraries for 3D imaging. JavaChips, an hardware implementations of Java VM for embedded applications and JavaCard, a complete set of API for building smart card apps. The flexibility of the package structure of Java has allowed programmers to develop all kind of mobile code applications: RMI packages permit to create traditional distributed client/server, object oriented systems; Aglets, Voyager, Odyssey are some specific implementations that use some features of the Java languages (RMI, serializable, networking, multithreaded) or use some additional technique to create weak mobile code applications. Java is a promising language with a tremendous market acceptance. Much of this popularity stems from Java's unique combination of characteristics: close to C++, safe, portable, easy and concurrent, as well as supplying a rich base library. There is yet much work to do especially in the secure architecture and the efficiency of the execution engine; Java misses some characteristic for real time applications, where performance of the executing applications have to be predictable. Many other technologies are converging towards Java: Tcl/Tk is thought to be the scripting twin of Java; DCOM interfacing with Java is a goal of Microsoft JVM; the Inferno OS developer from Lucent are thinking of the possibility to embedded JVM inside their system; etc.

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

code into server; the servlet's code is then instantiated and executed in the server (remote execution paradigm). In the next sections we will analyze some additional implementation using the Java technology: a mobile agent architecture, Aglets, and an object components, Java Beans. These implementation are Java solution but they have particular aspects that they have to be considered separately.

3.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; * 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.

Application Layer

Kernel Layer

Hardware LayerStyx communication

HostOS

Device drivers network

Secu

rity

Nam

espa

ces

Proc

ess

Man

agem

ent

Mem

ory

Man

agem

ent

Gra

phic

s lib

rary

Dis Virtual Machine

Applications

Assembler C language

Limbo

Java ?

Figure 17: Inferno/Limbo Architecture

Language Level. A Technology for the DAB System Limbo is a safe imperative language. It's main inspiration is C, but it includes in addition declarations as in Pascal, abstract data types (ADT), first class modules, first class channels, automatic memory management, and preemptive scheduled threads. It excludes pointer arithmetic and casts. The declaration of a module identifies the types of exported functions and contains the exported declarations of ADT's, simple type declarations, and constants. In order to use a module, it must be instantiated by loading an implementation of the module (at runtime). The loading is done with the built-in function load that takes a module type and a path to the module implementation and return the instantiated module (or null if unsuccessful). This allows the programs to choose among several implementations at run-time. The channels of Limbo allow the communication of any value of its declared type. A channel can be connected directly to another process or, through a library call, to a named destination. Channel are the only built-in primitive for interprocess communication, but more complicated mechanism can be built upon them. Memory is managed automatically by a garbage collector mechanism. Abstract Machine Level. Limbo programs are compiled to a RISC-like abstract machine called Dis. Dis is designed for just-in-time compilation to efficient native code by Limbo run-time system. The machine is memory-to-memory architecture, not a stack machine, that translates easily to native instructions sets. The Inferno kernel provides preemptive scheduling of processes (with a very low overload) that are responsible for managing and servicing protocol stack, media copies, alarms, interrupts, and the like.. The kernel schedules processes with multiple priority run queues (8 levels) using round-robin mechanism. Scheduling is on a fixed time slice, or quantum, basis with each quantum being set by the local system clock. Inferno has two-level memory allocation mechanism: the lower level maintains control of large block of contiguous memory. The higher level divides memory into pools to allow applications to control the behavior of the system when the resources become scarce. Memory is stored as block in an unbalanced B-tree with the leaves sorted by size. The interface to all devices is via the Inferno file system interface (as it is partially done in UNIX) and each device driver is a kernel resident file system.

Figure 18: Inferno Emulator on WinNT platform

Library level. A rich set of standard modules are provided, including modules for network communication, secure and encrypted communication, and graphics. Two user interface libraries are available: one based on Tk is intended for traditional window based user interface; the other is a ready made interface components for typical embedded applications, such interactive TV. The specialized design allows for a minimal memory requirements. Security. Safety is achieved through a safe language with restricted pointers and automatic memory management: this safety is not enforced by the abstract machine (as in Java). Inferno relies on applications being signed by trusted authorities who control their validity and behavior: this is a big constraint for the diffusion of that environment for Internet applications, where a huge number of programmers live on. Applications. The applications domain for Inferno is focused toward applications for service providers. Inferno has been compared to Java by many in the press. The lack of an object oriented structure in Limbo is one of the reason for which Inferno developer are thinking of an integration of Java inside Inferno [4]. The two platform are briefly compared in the following table.

Table 1: Inferno vs. Java - a Comparison -

Inferno/Limbo JavaOS/Java Security Built in authentication and

encryption at OS level, not automatic machine protection security

Machine protection security is built-in. Encryption has been added.

Resources access One file system access everything from data to network

File system access local data: network data must be accessed through the server

Minimum size machine to run applications

512 KB of RAM 512 KB of ROM

128 of RAM 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 Microsof t, JavaOS from Sun, Inferno from Lucent, but also all UNIX flavors and real time OSes. The problem of portability for these systems is big and from many directions they are trying to include in the platform some tools to open the platform to a wide environment: Inferno programmers are developing a way to include Java VM inside their system; some real time OSes are thinking about Java as an additional module to include in their systems; etc.

Architecture for Object Components Modern programming languages employ the object paradigm to structure computation within a single operating system. The next logical step is to distributed a computation over multiple processes on one single or even on different machines. Because object orientation has proven to be adequate means for developing and maintaining large scale applications, it seems reasonable to apply the object paradigm to distributed computation as well. Object are distributed over the machines within a networked environment and communicate with each other [9]. As a fact of life the computers within a networked environment differ in hardware architecture, operating system software, and the programming languages used to implement the objects. That is what we call a heterogeneous distributed environment. To allow communication between components in such environment one needs a rather complex piece of software called a middleware platform.

3.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 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 del ivering "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 dist ributed 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 meth od without knowing the internal structure of the component) and that can be called from wherever application is both remotely and locally. At the moment the only platform that uses DCOM is the Windows platform (WinNT, Win95, Win98, etc.). As we can see from the introduction these technology is suitable for distributed object oriented programming applications. It is interesting the use of this mechanism inside the Internet Explorer Web Browser: in that case it implements a code on demand paradigm, because during the loading mechanism of HTML pages we can automatically download, register and run application object (ActiveX component). Language Level. DCOM architecture is not related to a particular language. The only needed features is the possibility to deference and create virtual function table, to create the necessary framework for create components and communicating each other. General purpose object oriented languages like C++, Java, Delphi could use this technology, but today only a restrict number of languages (all belonging to Microsoft Company) are the concrete instruments for this technology: Visual C++, Visual J++ and Visual Basic, the first two more suitable for operating system programming, the third is a more efficient and faster developing instrument for simple front-end user friendly applications. Software components are objects that implement a specific standard interface for each particular kind of applications (all interface inherits from a single interface called IUnknown): ActiveX control, ActiveX documents, ActiveX container, etc. Abstract Machine Level. The complete framework needed to built a DCOM system is given by the Microsoft OSes: each components when instanced it is registered inside the registry database (a central, efficient database for collect all software and hardware configuration information of a machine); this registering mechanism can be implemented also for remote objects.

ActiveX Controls can reside locally on a client machine or they can be downloaded from the Intern et. 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.

Example of an ActiveX inserted in a HTML page

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

3.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 dynamic 3 localization of object components. Java Beans is a very simple solution for static object component in the Java platform.

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.

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

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;

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:

• 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. Concurrency is obtained through the use of threads and mutex, while class-based orientation through an extension of the typing discipline. O'Caml supports a small number of visibility modifiers for classes and object attributes: a class can be declared virtual, disallowing any instances to be created, and closed disallowing any subclass to be derived. Attributes can be declared private, making them inaccessible outside the methods of the defining class. MMM Applets are only allowed to use safe variants of the standard libraries: a safe library imports everything exported from the unsafe original, but it only re-exports a selected subset. The advantage of O'Caml is a rich language with support for several programming paradigms: functional, imperative, and object oriented.

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

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

Aglet AgletMessage

AgletProxy

AgletProxy

core

Methods

variablesitinerary

identifier

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.

Aglet

Context A

Aglet

Context B

Class secondarystorage

Retract()

Dispatch()

Create()

Dispose()

Deactivate() Activate()

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. Object attributes can be private or public. Private objects can only be accessed from the class itself and its subclass, while public attributes are unrestricted. The operator protected turns object references into protected references. The access to objects is also done through unmoved, uncopied, copyrighted and protected attributes. Agents itself are processes with a number of properties (telename, owner, sponsor, client, permit, age, priority) that are used to implement a strictly access authentication and control. When an agent wants to move in the Telesphere (a network of Telescript engines) invokes the go operation. The ticket is sent to the remote hosts. If the destination accepts the agent's authority and gives access, the agent is moved with all its code and execution is resumed in the new place. Abstract Machine Level. The network is composed of hosts on which a Telescript engine runs; this is a sort of computing environment that listens and controls access to the site and manage the execution of the agents. Mobile processes are run in a separate domain and can only interact directly with the engine in which they run. All interprocess access is mediated by the engine. Telescript employs an intermediate, portable language called Low Telescript, which is the representation actually transmitted among engines. Library Level. Each place (Telescript name for computing engine) has a collection of built-in classes. Telescript applications consist of Telescript agents operating within a "world" or cyberspace of places, engines, clouds or regions. All of this are objects. For example, a place is an instance of some class within the engine whose definition inherits operations which can be called in that place. The top class in the Telescript's object hierarchy is the "process". A Telescript engine is itself a multitasking interpreter which can run multiple processes and switches preemptively between them. Agent processes, unlike place processes, are objects which cannot contain other processes, but they can go from place to place.

Scripting Languages In these brief overview on distributed programming environments, we want to introduce a particular group of computing languages: scripting languages. Although these groups is not suitable to build a complete distributed or mobile code application, some scripting languages are used to developed some very specific Internet application. Both the power and the weakness of scripting languages is their simplicity and their specialization.

3.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. 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 execution environment in general is provided as a collection of libraries that is loaded automatically each time we need by the process of Web Browser application. Scripting code is transmitted on the net either as separate ASCII file or enclosed inside the HTML pages. The fame of this languages is related to the success of the browser that embeds them (JavaScript for Netscape, Jscript and VBScript for Microsoft) and to their easiness. Usually the time required to learn and use this kind of languages is much less than other system languages. Future development are focusing on the mix of one operating system language to design high efficient server application and a simple, user friendly, object oriented scripting language. This is the way followed by Microsoft with Visual C++/Visual Basic/ VBScript and this is the way Sun wants to do with Java/Tcl-Tk.

3.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 different paradigm using the same technology. Once we have chosen a model for our application, we can use some generic developing platform (like JavaOS, Inferno) or use some specific software solution (Aglets, Telescript, ActiveX, etc.). In general the choice is related to the goals of the application: time to market, developing tools, flexibility. In the following table we try to classify some of the studied technologies [10].

Table 2: Mobile Systems classified depending on type of mobility

Type of Mobility Systems Remote Execution Java servlets (push) Remote Evaluation Tacoma

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

Resources We have to care about the local and remote resources available for computing: these are physical requirements depending on the target system. For example in a desktop system, resources like CPU,

memory, or storage devices are not a big constraint, while in embedded systems these resources can be limited. Also the nature of the network can provide different kind of services: available bandwidth, one way (Radio, TV Teletext) or two way (Internet/Telecom networks) communication, naming services (SNMP for Internet), etc. For these reasons we have to be careful and avoid complex architecture for simple systems. DCOM, ActiveX, CORBA applications are technologies sophisticated, that require a lot of physical (processing unit, networks) and extra coordination resources; some flavor of Java (Embedded Java, Personal Java) and some implementation of Inferno are well suited for embedded systems. Flexibility In this context, the flexibility of a system is the capability to adapt to some requirements and to personalize the behavior of a mobile code solution. For example some internal mechanisms are sometimes hidden to the programmers: the loading of execution code, the security policy, the communication channels, the event management, the memory management, etc. Some mobile code solutions are too Internet oriented and they provide specific services using infrastructure available only in the computer network system or in specific Operating System. ActiveX relies mainly on Windows systems; Telescript is a network oriented solution for UNIX platforms; some Java solutions are also network oriented, as Mole; interpreted languages as Jscript and JavaScript are related to specific application systems (Browsers). Security Security is one of the major constraints for distributed system. From the user's point of view, we need to control the access to local resources and we want to implement a personal security policy; while from the provider's point of view we need a flexible mechanism to offer different services and to access all the capabilities of the local systems. Today different security mechanisms are available embedded inside the programming platform: from secure programming languages to digitally signed techniques. Also in these cases we need a flexible security mechanism, not strictly related to a network system and open enough to include different scenario. Some technologies rely on some specific security mechanism and lack flexibility (Active X); 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 languages

Company Availability

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

Perl Cormell (USA), Tromso, Norway free

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 Model

Trust in the object 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 methods

closed

No instances abstract virtual protected abstract Visible only in the same package

private not applicable not applicable not applicable

No outside update protected No aliases NA NA protected NA Mutual exclusion serialize

Attributes protections No restriction public NA NA NA NA Visible only in the same package or in subclass

protected NA NA NA NA

Visible in subclasses default NA private NA Visible only in defining class

private private NA default

Runtime protected reference

protect

Mutual exclusion synchronized Efficiency Here for efficiency of a technology we refer to the measure of how the developed solution is suitable for our purpose, using the right amount of resources: you can measure efficiency in term of execution speed, cost of the used resources, quality of the service you want to deliver, maintenability of your application.

3.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 d eveloping platform is supposed to have. Follow immediately for each items the relationship with the Java technology. Standardization. The DAB system is a new technology for radio communication. Although this network can be seen as an extension of the Internet network, there are some fundamental differences between the two systems. The nature of the broadcast channel and the characteristics of the radio services are not so dynamic as computer network technologies. The systems and the tools used in the radio system are supposed to be available for a long period and overall they are supposed to stable. Standardization for radio systems is a must. The choice of a new platform to develop digital radio services must be the result of an agreement between different parts: standardization agencies (ITU, ETSI - EUREKA 1474), producer companies (Sony, Panasonic, Hitachi, Grundig, Borsh) and service providers (BBC, SWR, SWEDISH Radio). The broadcasting nature of radio (one signal for all) imposes fundamentally some requirements about the independence of developing environment. We also can derive some constraints about the complete availability of the needed documentation, the stability (in terms of versioning and maturity - see also the subsection about Maturity) of the developing tools and general acceptance by all the DAB community. Java, in this scenario, is becoming a standard de facto for distributed application in the computer industry: the number of users, software companies, research centers that work in this new platform is enormous. Sun is willing to follow the ISO/IEC patent policy or extend the terms of its current patent policy to cover implementors of the International Standard ( see http://www.javasoft.com/aboutJava/standardization/); they realize the added value to the marketplace that de jure standardization can represent. For example, some countries and companies still restrict the public procurement of goods and services in the information technology

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

sector to products based on de jure standards. These aspects can be a good issue for the choice of a technology in the DAB community. Security. In a distributed programming environment security is one of the building blocks. For the DAB system we can list the following security requirements: authenticity, availability, safety, runtime control, scalability, terminal protection, user policy. It is very important to have the possibility to control the access to the terminal resources: from the provider-side it is important to access how many resources are possible; the user has to be guaranteed a complete personal configuration of his own terminal. These security mechanism can be set both at start up of the services and during execution (runtime control). A very robust mechanism is also necessary to avoid hardware crashes at the application level: it is not allowed that an application could crash the receiver device. Java has a very flexible security mechanism. You can control your application at different levels (from the verification of the bycode to the security manger runtime control), both statically before executing Java application and dynamically at run time. The Java API includes different packages to use different security mechanism (authentication, certification, encryption).Java relies on a Garbage Collector manager to make safe the memory management, the basic requirements for every modern distributed technology. The model is robust and it can be adapted to different medium. Acceptance. There are many issues related to the general acceptance of a technology for the DAB system. First of all the chosen technology ought to be accepted by the whole DAB community as a common platform to develop DAB services. In this context we have to consider some aspect related to the market pressure. As market pressure we can consider all the interests involved in the DAB services: producer companies, standardization agencies, but also user acceptance, service providers, integration with other media. It is very important that the choice is accepted as a general solution by all interested parties. Java is collecting a large consensus: in the computer industry (Sun, IBM, HP, ORACLE, MS), inside the academia centers and inside research centers (Sony, Mitsubishi). Programmers are using Java for develop different kind of distributed applications for network system, but also for embedded devices. Java is a buzz word in the computer world. Why Java is so diffuse ? Fundamentally because it is an easy, a flexible and a powerful language. Its abstract machine is really platform independent and there are implementations for almost all platforms: HP-UX, UNIX, Solaris, SunOS 4.1.3, WinNT, Win95, Win3.1, AIX, Digital UNIX, Inferno for OSes; Intel, Sparc, ARM, JavaChip for CPUs. An increasing number of software vendors are including Java, or Java-based components, as a strategic part of their systems. For example, the leading browser vendors (Microsoft, Netscape, and Sun) support Java applets. The leading database vendors (Oracle, IBM, Tandem, Informix, etc.) are collaborating on standards for embedding SQL in Java and Java within the database engine. A leading smart card vendor (Schlumberger) offers a subset of the Java operating environment on their smart card so that smart card application developers can develop applications using standard Java development tools. Numerous other vendors in more non-traditional computing environments (e.g., embedded devices or real -time operating systems) are in the process of supporting the Java environment. These large number of Companies are investing in Java technologies and overall Java seems to be the flexible network platform want to be ! Multimedia & Distributed Computing. The DAB platform is supposed to give all necessary tools to create a distributed system, but also to give all possible instruments to integrate different media. In the first case, we consider the traditional way to build a distributed system (client/server), but overall the possibility to create advanced code on demand or agent solutions; we need a complete framework to bind dynamically resources both locally and remotely.

The second case is more related to the revolutionary introduction of the DAB system: the new digital channel opens great possibility for the integration of all the media: DVD systems, Internet services , home computer network, telecom services. The developing platform is supposed to have all the means to integrate a wide range of multimedia applications.

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

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

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

Implementation Aspects. Basically the chosen technology have to be flexible: but what does flexible mean? We have yet outlined that the DAB system is not a traditional network: researchers and programmers need a developing platform in which they can control completely the loading mechanism, the security policy both at runtime, the execution environment, the resources binding, the communication mechanism. Some platforms hide these aspects, while some other completely miss. In the case of abstract machine implementation (Java, Inferno) there is a need of a standardized interface to the native operating system. The extensibility of the system API is also another requirement: a new system needs new capabilities. Some technologies offer a standard way to add new functionality to the core API and to the system itself. Java is a complete portable platform and flexible for implementing different network applications. The Java API provides a series of objects to control the behavior of the whole system: securityManager, classLoader, Thread, etc. Some critics about the Java platform are on the overall performance; we mention some of the problems:

• the Java VM is a stack based machine, specifically optimised for small devices; • the interpreter engine lacks performance; just in time compilers seem to be a solution, but

the memory requirements increase;

• garbage collector management is a big constraints for small embedded devices; • non real time capabilities are a problem for the usage of Java in critical mission and

advanced multimedia applications;

♣ ♣ ♣

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

"… every new beginning

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

Chapter 4 Java

“The Future of Computing depends on Operating Systems

with integrated Browser"

“BYTE Editorial - July 1998” (Mark Schlack)

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

◊ the Java programming language ◊ the Java Virtual Machine (OS) ◊ and the Java library (API)

We have already discussed some features about the programming language in the last chapter, but for more details about these issues see [1], [2] e [3].

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

4.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;

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

4 GB

Stack

Method Area

Heap

program counter

optop register

frame register

varsregister

local variables

execution env.

operand stack

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. Java chips are dedicated Java processors, that is processors that run directly bytecode.

General CPU Java chip

Byte Code

Interpreter

Native OS Native OS

JIT compiler

binary code

Byte Code

Java OS

Byte Code

• Slow• Medium Memory

FootPrint• Compatiblity

• Compiler fast• Large Memory

FootPrint• VM Optimize for

specific platform

• Fastest• Small Memory

FootPrint

General CPU

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 d irectory set with the

CLASSPATH variable; the second is the implemented ClassLoader class used by programmers (see next section for details). In an embedded solution some VMs implement different loading mechanism: for example in the network computer classes are loaded from the network; in embedded devices classes could be loaded from ROM memories. The virtual machine loads the code of the first class, verifies the contents before preceding, resolves all the internal classes used and loads all the necessary classes. This load-verify-link process mechanism is executed dynamically at loading time and whenever it is necessary during execution time. For improve performance the verification mechanism could be suspended for internal system classes (from CLASSPATH). In the UNIX and Windows platform the start up process is started loading the execution environment (a set of dynamic C libraries that contains the Java VM implementation), setting all the needed information (CLASSPATH, Java version, runtime parameters as stack depth, etc.) and initializing the runtime resources (descriptor, stack, etc.): the name of the first class is passed and the loading mechanism is executed. The Java VM is a multithreaded process. At start up the following threads are executed: * the garbage collector,

* the thread to execute finalizers,

* an idle thread to fall back on when no other work need to be done,

* the thread that interprets the bytecode and

* the main method thread of the loaded class

* for each new thread object create in the main class it create a separate thread.

The JVM distinguishes between deamon and non-deamon threads [4]. At start up all the thread are deamon threads, except the thread that executes the main method; when the AWT toolkit is initialized, a non deamon thread is started that dispatches events and calls into call-back code provided by the application. If all the remaining threads turn out to be deamon threads the JVM exits.

VM Applicationstarts

VM Applicationstops

Deamon Threads Non Deamon Threads

Gar

bag

e Col

lect

or

Clo

ck H

andle

r

Idle

Thre

ad

Fina

lizer

main

met

hod

new

Thread

cla

ss

spawns

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 group cannot, for example, use native code; and also all critical accesses (to the network, to the file system, to the runtime environment) are controlled by the SecurityManager. In fact with the help of a securityManager you can control a set of actions to access some particular resources (network, file system, instanziation of particular classes, the classLoader itself, the SecurityManager). Normally, the Java VM loads all system classes from the local file system in a platform dependent manner. For example, on a UNIX system, the VM loads classes from the directory defined by the CLASSPATH environment variable; but in some embedded JVM implementation classes can be loaded from ROM memory. We can think of a class loader as a door-keeper that controls every class we need to execute a Java application. During the class loading it resolve the needed class name (control the identity), it loads it (let it enter in the building) and registers it (if someone else need it again) on an hash table (guests books - so called namespaces). When we use a class loader to load a class, all the internal needed classes are loaded by the same class loader. A Java application can use two types of classLoaders: a primordial class loader, embedded in the basic Java API that use native method, and a subclass of the classLoader object. We analyze in detail what are the main steps to implement a custom class loader (see fig 3). A class loader is a subclass of java.lang.ClassLoader. The only abstract method that must be implemented is loadClass(). The flow of loadClass() is as follows:

1. Verify class name

2. Check to see if the class requested has already been loaded.

3. Check to see if the class is a "system" class.

4. Attempt to fetch the class from this class loader's repository.

5. Define the class for the VM.

6. Resolve the class.

7. Return the class to the caller

These basic steps can be used to perform custom control upon class name, class code, class sources. Moreover we can see how you can manage and enter in the security architecture of the Java VM; we will see that this mechanism is basically what we use to load applet from Web Browser.

import java.util.Hashtable;...private Hashtable classes = new Hashtable();public Class loadClass(String className) throws ClassNotFoundException { ...

return (loadClass(className, true)); }public synchronized Class loadClass(String className, boolean resolveIt) throws ClassNotFoundException { Class result; byte classData[];

result = (Class)classes.get(className); if (result != null) {

return result; }

try { result = super.findSystemClass(className);

return result; } catch (ClassNotFoundException e) {

} classData = CustomFunction(className); if (classData == null) { throw new ClassNotFoundException(); } result = defineClass(classData, 0, classData.length); if (result == null) { throw new ClassFormatError(); } if (resolveIt) { resolveClass(result); } classes.put(className, result);

return result; }}

Hash table to control NamespaceHash table to control NamespaceName of className of class

1) Verify the class NameWe can control the class name string

1) Verify the class NameWe can control the class name string

2) already been loaded ?If it is inside the Hash table

2) already been loaded ?If it is inside the Hash table

3) System class ?We use the primordial class loaderthat in genral load classes from CLASSPATH

3) System class ?We use the primordial class loaderthat in genral load classes from CLASSPATH

4) Custom way ...We load the class in a custom way

5) Define thaclass for the VMWe transform byte streamin a class object

5) Define thaclass for the VMWe transform byte streamin a class object

6) Return a class object the Caller6) Return a class object the Caller

public class Example {public static void main(String args[]) {CustomClassLoader sc = new CustomClassLoader();Object o;Class c;String tst = "ClassName";try {c = sc.loadClass(tst);o = (c).newInstance();((‘ClassInterface’) o).’ClassMethod’("none");} catch (Exception e) { }}

public class Example {public static void main(String args[]) {CustomClassLoader sc = new CustomClassLoader();Object o;Class c;String tst = "ClassName";try {c = sc.loadClass(tst);o = (c).newInstance();((‘ClassInterface’) o).’ClassMethod’("none");} catch (Exception e) { }}

Figure 23: Basic class loading mechanism

In example of figure 3 we see that the loadclass() method has two implementation: one for the user interface, to which we pass as argument only the class name and the second, that is called from the first, to set the resolve flag. The security Manager is a class in which we can specify the security constraints related to the use of the physical resources: access to hard disk, open network connections, use of native libraries. You can create your own Security Manager inheriting from the class java.lang.SecurityManager and set it using System.setSecurityManager(YourSecurityManager s); Using this technique you can trigger the loading process of your Java application. We can define our own securityManager just once in the main java application: each successive attempt to set the securityManager will throw an exception. Basically the Java VM takes as input the name of the main class file and the directory where it can find the system classes (we will see in more details in the next sections); then it starts running the code from static public void main(String s[]) If you want to configure the loading process you can load an intermediate class in which you use the mentioned special classes (class loader, Security Manager, etc.), but also you can use some special tools classes to load a jar file (zipped Java files), object images stored on HD, or code from the network.

Java Virtual Machine run the “main” static methodand receive a String array forarguments

Java file Java Applet Jar file DAB Java ?

AppletViewer

JarReader

...

java.class arg1 arg2 .. argn Applet.class par1 par2 .. parn

AppletViewer.class Applet.class par1 par2 ..

jarfile.jar

JarReader.class jarfile.jar

Example of Java Loading Mechanisms

DAB Loader

& Viewer

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. The Java runtime system relies on garbage collection to automatically identify and reclaim object no longer in use. Garbage collection doesn't alter the behavior of an application written in Java, with the exception of classes that declare a finalizer method. Finalizers are executed right before objects found to be garbage are discarded, giving you a chance to explicitly release non memory resources the class uses. Tricky finalizers may resuscitate an object by installing a new reference to it, but finalizers are execute only once. This garantees that objects may be brought back to life only once. Beginning with JDK 1.1,

data belonging to classes is also garbage collected, allowing unused classes to be automatically discarded (this happens whenever their class loader gets recycled). System classes are never garbage collected. The initial set of roots of a Java run time are * the live thread objects, * system classes (i.e. java.lang.String), * local variables and operands on the JVM stack, * the reference from the JNI, * pending exceptions and * the reference of the native stack. The garbage collection code is executed in a separate thread when the system runs out of memory or when System.gc() is explicitly invoked. The collector may also run asynchronously when it detects that the system is idle, but this may require some support from the native thread package. In any case, the execution of the garbage collector halts all other application threads and scans the entire heap: this is a big problem for Java embedded system, because the GC can introduce too long delays.

4.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 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].

try {...}catch (Exception e) {...}catch (Exception e) {...}...finally{...}

try {...}catch (Exception e) {...}catch (Exception e) {...}...finally{...}

Critical regionWe use some particular method that throws exceptions in case of unexpected conditions

Critical regionWe use some particular method that throws exceptions in case of unexpected conditions

Catch regionWe trigger all the thrown error exceptions

Catch regionWe trigger all the thrown error exceptions

Finally regionIn case the exception is sent to super classes,before leaving the critical region, we can do something !

Finally regionIn case the exception is sent to super classes,before leaving the critical region, we can do something !

try {File f = new File(‘someFile’);}catch (IOException e) {System.err.println(..);}finally{f.close();}

try {File f = new File(‘someFile’);}catch (IOException e) {System.err.println(..);}finally{f.close();}

Figure 25: Exception sections tecnique.

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

Java Personal Java

Embedded Java

Java Card

• Desktop PC• Enterprise Servers• Mainframe • RTOS

• Set-top boxes• PDAs/ScreenPhones• Internet TV• Car Navigation

• Industrial controllers• Pagers• Automotive

• Smart Card• Java Ring

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

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

Table 6: Resources requirements for different Java environment (only Java system requirements)

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

4.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); • 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.*

awt.*

beans.*

io.*

lang.* math.*

net.*

rmi.*

util.*

security.*

sql.*

text.*

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

The Java core API is composed schematically by a set of core packages divided following special rule and depending of the functionalities. Sun (but also MS and Netscape) provides a complete set of

application APIs to build a complete developing environment with secure and tested classes (see figure 7).

Application Programming Interface APIsby Sun

JFC Java Foundation Classes (core API)

Java Accessibility (core API)

Security (core API)

Java Beans (core API)

JDBC - Database (core API)

Java Interface Definition Language (core API)

J RMI (core API)

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

Java Mail

Java Help

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.

1

2 Browser3

4

5

6

7

8

HTML page

VM

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

SecurityManager

AppletViewer

HTTP

9

10

Figure 29: Applet loading mechanism

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

2 ... receives the HTML page.

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

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

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

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

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

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

Some information is exchanged between the AppletViewer and the applet to set the run time environment or to pass some extra data: this is done using an embedded mechanism inside the applet class (from whom all Applets inherit basic methods) or using some well know interfaces. The java.applet.* package is a minimum set of classes and interface to create the necessary framework. Inside the AppletViewer application we can implement a customized security policy instantiating our own SecurityManager implementation !!!

The Applet mechanism is a very simple solution to the problem of mobile code oriented to the Internet environment, but it can be expanded to other environments or can be used as a good example for other network architectures.

4.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: 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 li brary 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;JNIEnv* env;JavaVM* jvm;jclass mcls,cls;jmethodID mmid,mid;jstring jstr;jarray args;jint err;vmargs.version = 0x00010001;JNI_GetDefaultJavaVMInitArgs(&vm_args);...vmargs.classpath = “c:\jdk1.1\lib\class.zip;c:\dab\java\”;...err = JNI_CreateJavaVM(&jvm, &env, &vm_args);mcls = env.FindClass(exec); // class of the main java apphandleError();mmid = env.GetStaticMethodID(cls,”main”,”([Ljava/lang/String;)V”);handleError();

cls = env.FindClass(“java/lang/String”);handleError();args = env.NewObjectArray(argc,cls,0);handleError();for(int i = 0;I< argc; I++){

str = env.NewStringUTF(argv[I+1]);handleError();env.SetObjectArrayElement(args,I,str);handleError();

}env.CallStaticVoidMethod(mcls,mmid,args);handleError();jvm.DestroyJavaVM();

static void handleErrors(void){if(env.ExceptionOccurred()){

env.ExceptionDescribe();env.ExceptionClear();vm.DetachCurrentthread();}

}

NB: the Invocation API is writtenin C code, but some compileraccept the C++ notation; so:

(*env)->FindClass(env,exec);can be written as

env.FindClass(exec);

exec is the name of the mainclass file; depending ofthe implementation of thenative function FindClassyou can pass a C string orspecial string (es: Win32string)

1

2

3

45

6

8

9

10

11

7

Figure 30: Using JNI for Invocate the VM

JNI Invocation Interface JDK 1.11

Inside the jni.h header we define all the prototype of the Java Invocation interface; these functions aredefined inside a library implemented by the developer (Sun, MS, Netscape). Basically the JNI is a standardinterface 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 specialID for the class, the method implemented inside the class using a well define interface.

2

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

4 We call a JNI API function JNI_GetDefaultJavaVMInitArgs(&vm_args) to set the environmental variablesneeded 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 pointernecessar y to call the JNI API functions.

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

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

9 We build a string array and pass a series of arguments used by the java class main method: in this way wecould 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.

com.ms

.activeX

.awt .peer

.com

.fx

.service

.lang

.ui .resource

.util .cab

.vm

Invocation API

JVM as a COMobject

IJavaExecute::GetDefaultClassPath(..)IJavaExecute::Execute(..)

IJavaExecute2::SetSystemProperties(..)IJavaExecute2::SetClassSource(..)

Figure 32: Additional facilities of JVM from MS

RNI stands for Raw Native Interface. This is the MS specification to access native code (C, C++) from Java code or to call the JVM directly from native code. This specification is studied just for expert developer and to produce very efficient code. J/Direct is an extension of the MS compiler and interpreter for calling Win32 API functions in a direct manner from Java code: developers can access all capabilities of the dynamic library in the Win platform using the same name of the native code. Class ShowMsgBox { public static void main(String args[]){ MessageBox(0,"It worked !","…",0);

} //* @dll.import("USER32") */ private static native int MessageBox(int,String,String,int);

} Some special ready-to-use Java classes are added as a extended packages to wrap the main API functions: com.ms.win32.Kernel32.class, com.ms.win32.Gdi32.class, etc. import com.ms.win32.*; class MsgBox{ public static void main(String args[]){ MessageBox(0,"It worked !","…",0);

} } DCOM/Java is a high level interface to call Java as an COM object in your application.

4.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 classe s; 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 (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.

native API

ntdll.dll

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

OS Kernel

Win32 API

Win32 App Win32 App

Win32 App

thirdy part modules

Figure 33: Basic WinNT software architecture

Through a well define set of APIs users can develop applications to access the hardware and software resources. Each specific VM implementation uses a different number of additional libraries; we can summarize the specific "core" functions in different families: * basic VM operation (Memory management, thread scheduling, interpreter, jit compiler, etc.); * JNI interface functions; * native methods implementation of the Java classes:

* graphics procedure * I/O

* network access * multimedia functions

* additional JVM capabilities (ActiveX, DCOM interface) [not available for all implementations]; * compiler functionality Some of these functions groups are collected in single DLL or they can be put in separate library file. The first group is a collection of functions that implement the basic VM operation and it is loaded each time the VM runs: for example javai.dll from Sun and msjava.dll from MS. Another group of functions is related to the native calling mechanism, so the specific set of functions for calling native methods or for loading and calling the Java VM: generally it resides in the main library. Many native functions used by the Java API are collected in different libraries depending on the particular task they do: Graphics native functions (winawt.dll, awt3240.dll), network communications (net.dll), mathematical functions (math.dll), special purpose functions (JdbcOdbc.dll). For those implementations that have a compiler, some additional libraries are included in the package. In general the core of the Java VM is all implemented in a single library: for Sun we have javai.dll and for MS msjava.dll. Inside there is a set of functions that are executed to start up the virtual machine or some internal function to control memory management or object layout. In general these libraries contain all the native interface calls and the basic native method implementation (for the core Java classes java.lang.*).

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

Win32 API

JDK 1.1.6

javai.dll

awt.dll symcjit.dll…

msjava.dll

ips.dll jscript.dll

…

IE 4.0 Browser

urlmon.dll msjvc.dll

winawt.dll mshtml.dll

jit3240.dll

awt3240.dllpr3240.dll…

Navigator 4.04

jsd3240.dll jrt3240.dll

jpeg3240.dll js3240.dll

net.dll math.dll

Netscape Microsoft Sun

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

Windows OS

platform dependentimplementation

Java platform dependentinterface

Java platform independentinterface

OS API

Java package

matching abstract classes

Java

byco

de

C c

od

e

Figure 35: Block diagram of Java interfacing Model

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

• at the lower level we have a platform dependent class that implements all the needed native calls. In

general it extends an abstract class that wraps the Java basic methods to access a specific service; • in the middle we have a set of matching classes that give to the upper packages a well defined

minimum interface to the services (a set of method calls); • at the Java API level we have all the rest of the package class that implement all the complex

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

class 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);}

abstract public class SocketImpl{...abstract void bind(inetAddress address, int lport)throws IOException;...}

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

Figure 36: A Three Layer Approach: Java interfacing Model

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

Another example of the layered approach is the following figure.

Java Implentation: an example from KaffeRuntime.c

System.java

Runtime.java

public static void LoadLibrary(String libname){Runtime.getRuntime().loadLibrary(libname);}

public synchronized void loadLibrary(String libname){...loadInternal(buildLibName(path[path],libname);...}private boolean loadInternal(String filename){...return loadFileInternal(filename);}native private Boolean loadFileInternal(String filename);

jint java_lang_Runtime_loadFileInternal(struct Hjava_lang_Runtime* this,struct Hjava_lang_String* s1){int r;...r = loadNativeLibrary(lib); ...}

External.cint loadNativeLibrary(char* lib){...LOADLIBRARY(libHandle[i].name,lib)...}

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

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. Some of the new solution are introduced in the different releases of the JDK packages, while other try to expand the Java API using new packages. Java is the base platform for different kind of distributed computing environment: not only the Applet architecture (Code On Demand paradigm) or the traditional client/server architecture, but also some new agent technology is implemented in Java.

♣ ♣ ♣

New aspects are introduced in the JDK 1.2.x concerning the security mechanism and policy of the Java VM [11]. There is no built-in notion of "trusted code" and the securityManager has more advanced capabilities to control the security of the Java Environment [9]. In the previous version of the JVM you basically have two way to load Java classes: one embedded system dependent "trusted code" way to download classes from the CLASSPATH (system classes) and the other to use your classLoader and manage the security access with the securityManager (Applet download).] Java is born as a proprietary product but today is become a instrument of all Internet users !!!

“They love him, gentlemen, and they respect him, not only for himself, .but for his character, for his integrity and judgment and iron will;

but he was most loved for the enemies he made"

General Edward S. Bragg (speaking about Grover Cleveland, but it can be applied to the controversy between Sun Java and MS)

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

b) www.club-internet.fr/dabfrance/ 9. Principal Architecture of a DAB receiver - A Reference Model (www.worlddab.org/members/) 10. Languages for Mobile Agents (Thesis) S.Versteeg (25/8/1997) (www.cs.mu.oz.au/~scv/) Chapter 3 1. Java Beans and ActiveX go head to head - Merlyn Hughes [JavaWorld (March 1997)] 2. Java Beans Specification - Sun Papers 3. The Java language Specification - Java language Series 4. Using Inferno to Execute Java on Small devices - C.F.Yurkoski, L.R.Rau, B.K.Ellis - Bell Labs - 5. Tcl and Java Integration - Ray Johnson - Sun Microsystem Laboratories (February 3, 1998)

6. Java Aglet Application Programming Interface - D.B. Lange - White Paper - 7. Inferno Programmers Guide (http://www.lucent-inferno.com) 8. Choosing a Scripting Language - C.Laird K.Soraiz SunWorld - October 1997 9. Mico is CORBA by Kay Römer, Arno Puder 10. Mole - Concept of a Mobile Agent system [chapter 1 ref 3] 11. Programming Languages for Mobile Code - T.Thorne - INRIA n°3134 (Mars 1997) Chapter 4 1. Java Native Interface Specification - Release 1.1 - Sun Microsystem (May 1997) 2. The Java Virtual Machine Specification - T. Lindholm, F. Yellin 3. Thinking in Java - Bruce Eckel 4. Experience with Secure Multiprocessing in Java - Li Gong, D. Barfanz 5. Java Garbage Collection for Real Time System - A. Petit-Bianco - [DR.Dobbs october 1998] 6. Extensible Security Architecture for Java - D.Wallach, D.Balfanz, D.Dean, E.Felten [Department of Computer Science Princeton University] 7. Java Security - J.A.Bank - MIT Report 8. CACAO - A 64 bit Java VM Just-in-Time Compiler - A.Krall, R.Grafl - Institut für Computersprachen technische Universität ( Wien) 9. The Java Extension Framework (http://java.sun.com/products/jdk/1.2/docs/guide/extensions) 10. Java Security Architecture -(JDK 1.2) Li Gong (www.javasoft.com/products/jdk/1.2/docs/) Chapter 5 1. Window NT Internals 2. Radio broadcast system: DAB to mobile, portable and fixed receiver (Final draft ETS 300 401) November 1994 3. Specification of the Multimedia Object Transfer Protocol (MOT) - Eureka Projects 147 - 4. DAB Data Service - Overview of Current Technology - R.Bittner, R.Schäfer - 104th AES Convention Chapter 6 e 7 1. Java Native Interface Specification - Release 1.1 - Sun Microsystems (May 1997) 2. Web sites (http://): a)premium.microsoft.com/msdn/library/ - MSDN Library b)www.q-tek.com/scripting/JavaDocs/ - Microsoft SDK for Java 2.0 c)msdn.microsoft.com/developer/sdk/inetsdk/ 3. MSDN Library - January 1998 by Microsoft