An Overview of the Operating System Architecture
JavaOSTM for Business is a Java-centric
operating system with a feature set and architecture designed to provide a
complete JavaTM 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. This means 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 JDKTM 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
- Java1 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:
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
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 HotJavaTM 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
JavaTM 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 JDKTM
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
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:
- 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. - JavaStationTM 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:
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
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.
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.
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
_______
1 As used on this web site, the terms
"Java virtual machine" or "JVM" mean a virtual machine for the Java platform.
