An Overview of the Operating System Architecture

The JavaOS^TM for Business operating system is a Java-centric operating system with a feature set and architecture designed to provide a complete Java environment for a wide range of products, including network computers. JavaOS for Business software eliminates the need for a host operating system to run Java technology-based applications.

Network computers offer low-cost computing platforms with powerful server-side system administration. JavaOS for Business software provides this environment with integrated networking support, eliminating the need for client administration such as data backups and new software updates. This significantly reduces the total cost of ownership (TCO) for enterprise users.

The JavaOS for Business operating system was built using a layered architecture. Each layer is designed to be removable and updated independently, meaning that the operating system can be divided into components arranged in combinations that provide for the unique needs of a product. The layered architecture consists of:

• Stand-alone JDK^TM Runtime environment
• Device drivers
• JavaOS Platform Interface
• Microkernel and memory architecture

JavaOS for Business software also provides support for the full Java application programmers interface (API)

The layered architecture is divided into platform-specific and platform-independent code.

The platform-specific code is compiled to native code and contains the:

• Microkernel
• Java^TM Virtual Machine (JVM)

The Microkernel supports the following:

• booting
• interrupt handling
• multiple threads
• traps and DMA handling

enabling users to run multiple applets at the same time or download information while running a Java application.

The Java Virtual Machine (JVM) supports the Java:

• bytecode interpreter loop
• execution handling
• memory management
• threads
• class loading
• bytecode verifier

JavaOS for Business software extends the memory model to optimize for systems with limited memory.

The platform-independent portion of the system contains the:

• JavaOS Device Drivers
• JavaOS Network Classes
• JavaOS Window and Graphics systems

The JavaOS Device Drivers are written in Java and are portable and extensible.

The JavaOS Network Classes include industry standard networking protocols such as TCP/IP, UDP and ICMP for basic transport and routing. Both DNS and INS are used for looking up host names and supplying user names and passwords during log-in.

JavaOS for Business software supports both Reverse ARP and DHCP for discovering network addresses and eliminating client administration. System clients can access files on an NFS server and be managed using SNMP.

The JavaOS Window system controls all drawing to the screen, implements user interface components such as buttons, menus and scrollbars and handles management of overlapping windows.

The JavaOS Graphics system supports all common graphics calls, including draw, fill, lines, arcs and polygons and font rendering. Both the graphics and window subsystems support the Java Abstract Windowing Toolkit (AWT) in a memory-efficient way.

The remainder of this overview introduces the key components, services, and interfaces associated with the JavaOS for Business operating system:

• Client-Side OS
• Client-Server Model
• JDK and JDK^TM Runtime Layer
• JavaOS Device Interface (JDI)
• JavaOS Platform Interface (JPI)
• Microkernel
• JavaOS Boot Interface (JBI)

Client-Side OS

As shown in Figure 1, the JavaOS Platform Interface (JPI) presents a Device Driver Kit (DDK) for developing loadable drivers in Java (JDI).

Since Java limits access to memory, the JavaOS Platform Interface provides secure memory via a Platform Manager framework for writing Device Drivers in Java.

The Java OS Platform Interface (JPI) of the system provides the following:

• JavaOS System Database (JSD), manages configuration information that describes what devices are present, what system software services are installed, what user and group attributes have been selected, and any application-specific information required.



• JavaOS System Loader (JSL), a stand-alone service loading mechanism



• JavaOS Event System to provide the framework necessary to identify, map and manage device drivers, network protocols, and file systems to be loaded into the client platform



• JavaOS Configuration Tool (JCT), manages the hardware platform configuration

JavaOS Platform Services (JSD, JSL, and Event System) can be configured as a stand-alone system on a separate machine for client services and heavy access balancing. The JavaOS Platform Services include the server component with configuration management and client facilities.

The JSD supports a client/server model that facilitates the implementation of a thin client accessing configuration information, services, applications, and user data from one or more servers on the network. One server may provide the client the executable and loadable services required to boot the client. Another may authenticate user login and provide user-specific configuration information to the client. Still others may be sources of application and user data.

In addition, the system provides a JavaOS Device Driver development Kit (JDDK) and a Java Application Development Kit (JADK) to allow licensees and vendors to develop portable device drivers and applications through the JavaOS Device Driver Interface (JDI).

FIGURE 1.   JavaOS for Business software Client-network computers Server Overview

Client-Server Model

The main goal of the client-server computing model is to divide tasks. The user interface is concentrated on the client side and the data management is performed on the server side. Figure 2 illustrates the Client-Server model.

Network computers are inexpensive client devices that interact with more powerful, centrally-located server computers. Java applets and applications run on these network computers and execute inside a single Java container application like the HotJava^TM browser. These applets communicate through a network with applications running on a server.

The system is flexible enough to be ported to different hardware platforms. The system includes sample implementations that act as a guide to developing JavaOS for Business software-based products. This includes the x86-based PC platform.

FIGURE 2.   JavaOS for Business client-server model

Some system features include:

• File system is server-side. Network computers do not have a local file system. The advantage of this is simplicity and lower cost. Without a local file system to back up, there is less risk of data loss.



• Single programming language. Other operating systems support many different programming languages. JavaOS for Business software was designed to execute Java bytecode in a Java Virtual Machine.



• No system calls. Legacy operating systems provide access to operating system functionality through special interfaces. This programming style conflicts with the goals of 100% Pure Java^TM because it creates software that is limited to specific environments.

Conventional PC's require a system administrator to be physically present for many support tasks. Since resources like fonts and system files are stored locally, the system administrator must be present to support each machine.

JavaOS for Business software was designed to simplify this support model so that both the resources and the tasks to support those resources are concentrated on a server. This increases the productivity of a system administrator and lowers the cost of maintenance per seat.

The JavaOS for Business operating system is optimized to run Java applications in a network computing environment. It eliminates the need of a host operating system for running Java applications.

The system provides the following features:

• Stand-alone JDK^TM Runtime environment
• Device driver architecture
• Portable device driver architecture
• Microkernel
• Configuration management

The device driver architecture leverages a collection of JPI components including the:

• Configuration database, the JavaOS System Database (JSD)
• Service loader, the JavaOS System Loader (JSL) capable of loading device drivers and other OS/JDK components
• Event Management system

Figure 3 presents an overview of the architecture layers containing the following components and interfaces:

• Client Application
• JavaOS Development Kit (JDK)
• Java Virtual Machine (JVM)
• Hosting Classes
• JavaOS Device Interface (JDI)
• JavaOS Platform Interface (JPI)
• Microkernel
• JavaOS Boot Interface (JBI)

FIGURE 3.   JavaOS for Business Layered Architecture

JDK and JDK Runtime Layer

As illustrated in Figure 4 the JDK and JDK Runtime Layer matches or maps to the JavaOS for Business software. This section includes the following components:

• Java Development Kit (JDK)
• Java JDK Runtime layer including:
• Java Virtual Machine (JVM)
• JDK Hosting Classes
• JavaOS Device Interface (JDI)
• JavaOS Platform Interface (JPI)

FIGURE 4.   JDK and JDK Runtime Layers

Java Development Kit (JDK) Layer

The Java Development Kit (JDK) layer provides the means and the support for system layers and components through the use of the following classes:

• Language
• Security
• AWT
• I/O
• Network

Obtaining the name of a class or creating a new instance of a class requires that the developer derive an instance of class Class representing the current class. In turn, this requires that the developer know the name of the class or already have an instance of the class.

The Java platform includes a special class, the Class class, allowing the program to inspect Java data types at JDK Runtime. Each instance of class Class represents a different class or interface type loaded into the current Java Virtual Machine.

Using JDK, the developer queries a Class instance including the name of the class, class loader, superclass, interfaces, class fields, methods and constructors. JDK also allows the developer to create a new instance of the class and to access class objects directly from a class Class field.

For Events, JDK carries information about the event sources, the event type, when and where the event occurred, the state of the keyboard for the event, and the state of the component affected by the event.

JDK Runtime Layer

The layers above the Microkernel begin the platform-independent portion of the operating system and are collectively called the JavaOS for Business software JDK Runtime layer. JDK Runtime components include:

• Java Virtual Machine (JVM)
• Code to support AWT
• Networking classes
• File-related I/O classes

JDK Runtime also includes the JDI or JavaOS Device Interface, which supports the device drivers written in Java. These drivers are an important client of the JavaOS Platform Interface or JPI.

The JDK Runtime contains support for AWT and I/O, as well for a modern device driver architecture. The AWT and I/O support modules use the JDI to perform I/O with a variety of devices.

In the JavaOS for Business software, the AWT is layered upon a window system occupying space in the JDK Runtime layer. See Figure 5.

FIGURE 5.   JDK Runtime Layer Middleware

The system is built from a combination of native code, some of which is platform-dependent, and Java byte-code, which is completely independent of the platform. The platform-independent portion of the operating system is the JDK Runtime, replacing the functions that reside within a host operating system supporting Java.

The JDK Runtime is also designed to run on a very hardware-limited platform. For example, the JDK Runtime does not require a Memory Management Unit (MMU) to map virtual addresses to physical memory addresses, or memory protection.

JDK Runtime allows developers to determine whether the underlying Microkernel should use an MMU or enforce memory protection. For example, the Microkernel bundled in the system uses an MMU to make several noncontiguous memory regions appear contiguous to that version of JDK Runtime.

The features implemented in this version of the system by the underlying Microkernel are shaped by the product under construction. For instance, an implementation destined for a phone needs a small, simple kernel. However, a network computer may require a more complex kernel implementation.

The JDK Runtime also lets the Microkernel designer decide how to manage multiple CPUs: symmetrically using SMP or asymmetrically with ASMP. The JDK Runtime is fully re-entrant. Each JDK Runtime critical section is protected by Java language synchronization primitives, and is therefore fully capable of running on a multiple processing platform.

From the Microkernel's point of view, the JavaOS for Business software is a process residing in a single JavaOS address space. The JavaOS address space may or may not resemble the physical memory map in size or layout.

Any differences between virtual and physical memory are managed by the Microkernel. JDK Runtime never assumes the physical characteristics of memory; JPI service calls gather all knowledge of JavaOS address space.

Some of the sublayers within the JDK Runtime include required and optional components for given product and/or platform combinations.

Required components for all products on all platforms include the following:

• Configuration Manager (CM): the first class of Java code to be executed by the JVM. The JVM regards the CM as its main application, invoking the CM main method with the standard Java application start-up parameters.



• The CM:
• parses start-up arguments
• starts up the platform manager component by passing argument strings
• starts up the list of required services and the list of option services described by the start-up parameters.
• The Java prototype for CM's main method is:




public static void main(String ags[]) {}



• Platform Manager: the component responsible for initialization of platform-specific devices and other hardware resources. The Platform Manager is the CPU host-bus manager.



• Service Manager: a utility package of Java code that can locate, load, and start JDK Runtime services.



• Device Manager: the central logic for the JDI driver architecture.



• Virtual Machine: JVM is an abstract computing machine with an instruction set that uses various memory areas. Common practice is that a virtual machine implements a programming language and the Java Programming Language uses JVM as the implementing method.



• JDK Classes specific to JOSD



• JPI Classes: insulate JDI device drivers and JDI support code from platform specific issues regarding time, memory, and interrupt management.

Optional components depend on the following factors:

• JDK configuration including B-JDK (Business), E-JDK (Embedded), or P-JDK (Personal)
• The set of devices requiring drivers (e.g., Framebuffer, ethernet, mouse, keyboard, serial, etc.)
• Debugging support needed.

For instance, Figure 6 illustrates the components in a JDK Runtime for a network computer:

FIGURE 6.   JavaStation^TM network computer JDK Runtime Components

Components required for specific platforms and/or products:

• Platform-independent device drivers: A key component of the JDK Runtime. All device drivers managing access to a platform resource of device use the JPI, making the system a platform-independent device driver model.
  
  However, platform independence doesn't mean bus independence. Each device driver is written to operate in the context of one or more expansion or I/O buses. Each driver uses the JPI to access platform resources such as memory and interrupts, but is also paired with a bus manager that allocates bus resources.
  
  Figure 7 shows that the model lets third-party expansion card vendors maintain a single copy of driver source code for each device and bus combination offered, resulting in substantial savings for the vendor.
  
  Each vendor must also use a JPI-compliant Microkernel, certified with a series of tests made available to each JavaOS for Business software licensee.





FIGURE 7.   Device and Bus Management



• Platform-tuned device drivers: While the JPI insulates drivers from platform dependencies, it doesn't prevent a driver from gathering platform-specific information that can optimize performance.



• A JavaOS for Business device driver can, if necessary, be written to be platform specific, since each component of the JPI publishes methods that return platform-specific information.

Java Virtual Machine (JVM)

The heart of the Java programming language is the Java Virtual Machine, (JVM), which is responsible for Java's:

• cross-platform delivery
• small footprint compiled code
• security capabilities

The JVM contained in the JDK Runtime layer of the system is an abstract computing machine with an instruction set that uses various memory areas. Common practice is that a virtual machine implements a programming language and the Java Programming Language uses JVM as the implementing method.

The JVM knows nothing of the Java programming language, only of a particular file form, the class file format. A class file contains JVM instructions (or bytecodes) and a symbol table, as well as other information.

The JVM components are as follows:

• Garbage Collector
• Native Method Interface
• JIT
• Interpreter
• JVM System Function Library

The Java Virtual Machine (JVM) provided with the system has been optimized for the needs of network computers. This includes a just-in-time compiler (JIT), a memory management system optimized for limited memory environments and a Microkernel designed solely to support the needs of the JVM.

The development environment includes a tool for linking Java classes and generating multi-class files or preloaded sets of class files. These can be used to build application modules and more compact image files that can be stored in ROM.

Other Java JDK Runtime environments map abstract services (like Threads) required by the JVM onto services provided by the underlying native operating system (like native threads). The system provides these services directly.

Hosting Classes

The JDK Runtime layer includes Hosting Classes for:

• Graphics
• I/O
• Network

JavaOS Device Interface (JDI)

The JavaOS Device Interface (JDI) is a series of classes and interfaces providing appliance software access to locally connected I/O devices.

Clients of the JDI include applications, applets, JavaOS for Business system packages and JavaOS device drivers. Applets and various system packages use JDI to configure the I/O system and to initiate I/O requests. Drivers use the JDI to fulfill I/O requests.

The JDI functions as a device manager, managing a device through the first step in a device lifecycle called discovery. Device discovery is a platform, bus, and
device-specific task.

The JDI calls upon the booting sub-system to publish devices found during system boot. The Bus management software alerts the JDI post-boot to the existence of a new device. PCI expansion buses allow for complete plug-and-play device management.

Once a device is discovered, it is named by the entity (JBI-PROM, bus manager or JSD administrator) that found the device. The name then serves as a pointer to the device.

The JDI includes the following components:

• Event System
• Platform Manager
• JavaOS System Database (JSD)
• Device Drivers
• Bus Manager

Figure 8 illustrates the JDI components:

FIGURE 8.   JDK Runtime Layer JDI Components

Event System

JavaOS for Business software supports a local platform communication model based upon Events. An event is a typed piece of information.

The simplest event contains a single piece of information referencing the event source, known as the event producer.

The system event model supports multiple event receivers, called consumers.

Event, producer and consumer definition classes are provided a package of classes. This events package acts as the broker between event producers and consumers. The broker model of distribution serves to separate producers from consumers and lessen the burden on any one event producer.

Platform Manager

JDI Platform Management provides configuration naming services using these services to name devices and publish interfaces. JDI works with the JavaOS System Database (JSD).

JavaOS System Database (JSD)

JSD allows the storage and retrieval of Java System Configuration information through a unified repository on all Java platforms. The JSD lets operating system services, applications, JavaBeans, and JDK components store and retrieve complex configuration information about all Java platforms.

The database is populated dynamically during platform start-up using a flexible population interface. The population interface allows data to be obtained from files, the network, and the host OS. An interface to browse and navigate through the data hierarchy and contents is also provided.

The JSD can interact with other registries, like Windows NT, and the data can be populated from the Windows NT registry. An Event mechanism is provided to maintain data coherency after the initial population of the database.

The server side of the JSD is a stand-alone system that exists on a separate server machine other than the JavaOS for Business server to better optimize high client access load.

The JSD uses a distributed repository model with the IIOP protocol for client and server communication.

Device Drivers

Device families and stand-alone device drivers are the building blocks of the sytem's I/O system. It is the collective set of families, drivers, and their relationships that implement the many I/O interfaces exported to device clients.

JDI device drivers provide families with a consistent, powerful loading and matching package that does most of the work of matching a driver to a device.

Bus Manager

The JDI Bus Manager ensures the driver is matched to the device for each bus connected to a platform. The Bus Manager allocates memory and process interrupts on behalf of the drivers

JavaOS Platform Interface (JPI)

The JavaOS for Business operating system extends the Java platform with portable, platform-independent interfaces to memory, interrupt, and I/O support classes. The Java classes themselves rely on the underlying Microkernel but provide the facilities for the Java Virtual Machine (JVM) and JDI device drivers to use platform-independent interfaces (insulated from platform dependencies.)

The JPI provides services to the virtual machine for threads, paging, and native code libraries. The OS extensions can use services like platform timing, interrupt and memory architecture.

JPI includes the following components:

• JVM System Function Library Managers
• Memory Classes
• Language Classes
• DMA Classes

Figure 9 illustrates the JPI components:

FIGURE 9.   JPI Components

JPI clients are divided into two groups: native and Java. The primary native client is the Java Virtual Machine (JVM). The JVM views the platform interface as a set of C-based routines providing the raw platform services required by the virtual machine. This collection of services is called the JVM System Functions.

The Java-based clients include Java-based device drivers, and various system software components. A Java-based client views the platform interface as a set of support classes that are implemented as a combination of Java and native methods.

The JPI client composition is illustrated in Figure 10:

FIGURE 10.   Clients of the Java Platform Interface

From the Microkernel point of view, the kernel provides native, C-based handlers that execute on behalf of the native and Java clients. The C-based handlers are platform dependent. The client-invocation side of the interface is platform independent.

The JPI is an interface designed to provide more flexibility between the Microkernel and JDK Runtime. It allows separate teams and/or companies to work on the Microkernel and JDK Runtime components of the system in parallel.

From a product point of view, one kernel could be tuned for hard realtime environments, while another kernel could be designed for a network computer.

The Microkernel was designed with an network computer in mind. It implements the JVM system functions and provides just enough device-related native methods to support linked drivers. The JDI has been created in part to support a formal, portable device driver model.

Microkernel

The platform-dependent part of the operating system is known as the Microkernel, a small component of native code that provides services to the virtual machine and to the OS extensions. Compliance with the JPI specification is validated by a suite of tests designed to exercise Microkernel services.

Services required of a JPI-compliant Microkernel are memory management, process management, thread management, and I/O support.

Microkernel components are illustrated in Figure 11:

FIGURE 11.   JavaOS Microkernel Layer

A JPI-compliant Microkernel performs four kinds of services:

• memory management
• process management
• thread management
• I/O support.

Memory Management

A JPI-compliant Microkernel exports a set of memory management services that let the JDK Runtime allocate virtual address space. A page is the smallest unit of memory managed by the Microkernel on behalf of the JDK Runtime. The JVM requires pages of virtual address space to build object heaps, but device drivers require pages of memory for buffer space.

Named collections of one or more pages of memory are called areas. All areas reside in the single JavaOS for Business software address space, including space for the Microkernel itself. An area's name and type denote its purpose.

For example, an area of type RAM and named JVM object heap is used by the JDK Runtime to implement Java objects. Device drivers use an area of I/O space memory called Framebuffer to access I/O devices.

Figure 12 illustrates a sample virtual address space:

FIGURE 12.   Virtual Address Space

Process Management

The Garbage Collector (GC) accounts for memory allocation within an object heap. Some resources required by the JDK Runtime, however, cannot be accounted for by the GC. Therefore, a JavaOS for Business software process is considered the unit of Microkernel and JDK Runtime resource accounting. Processes are used by the JDK Runtime to track resources assigned to applications, JDK Runtime service modules, and device drivers.

Multiple processes share the JavaOS for Business software address space. Each process is assigned a set of threads and memory areas.

The Microkernel exports a set of process management services that encapsulate the lifecycle of a process.A process is created without any assigned resources, but over its lifetime is dynamically assigned threads and memory areas. Process resources are consumed by the Microkernel when the process is deleted.

Thread Management

The Microkernel exports a set of thread management services that let the virtual machine fulfill the semantics of Java threads. Each Java thread is layered upon a Microkernel thread.

The Microkernel thread model supports multiple threads within a single JavaOS for Business software process.

I/O Support

A JPI-compliant Microkernel exports a set of memory management services that let the JDK Runtime allocate virtual address space.

JavaOS Boot Interface (JBI)

Figure 13 illustrates the JBI and JavaOS Booter layers:

FIGURE 13.   JavaOS Boot Interface and JavaOS Booter for the x86-based PC

The booting layer includes:

• JavaOS Boot Interface (JBI)
• JavaOS Booter

The booting system loads the JavaOS for Business software into memory and begins execution of the Microkernel. The system can be booted from network, ROM, RAM, CD-ROM, floppy, and hard disk devices.

The JBI standardizes the boot operations available to the operating system. This interface is used both by the Microkernel and the JDK Runtime layers.

JBI defines the bi-directional interface that is also an OS execution environment. JBI gives product designers flexibility when making booting decisions.

Return to top