|
An Overview of the Operating System ArchitectureJavaOS for Business 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. 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:
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:
The Microkernel supports the following:
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:
JavaOS for Business software extends the memory model to optimize for systems with limited memory. The platform-independent portion of the system contains the:
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 OSAs 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 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 ModelThe 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 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:
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:
The device driver architecture leverages a collection of JPI components including the:
Figure 3 presents an overview of the architecture layers containing the following components and interfaces:
FIGURE 3. - JavaOS for Business Layered Architecture
JDK and JDK Runtime LayerAs 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:
FIGURE 4. - JDK and JDK Runtime Layers
Java Development Kit (JDK) LayerThe Java Development Kit (JDK) layer provides the means and the support for system layers and components through the use of the following classes:
Obtaining the name of a class or creating a new instance of a class
requires that the developer derive an instance of class
The Java platform includes a special class, the
Using JDK, the developer queries a 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 LayerThe 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:
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:
Optional components depend on the following factors:
For instance, Figure 6 illustrates the components in a JDK Runtime for a network computer:
FIGURE 6. - JavaStation network computer JDK Runtime Components Components required for specific platforms and/or products:
Java Virtual Machine (JVM)The heart of the Java programming language is the Java Virtual Machine, (JVM), which is responsible for Java's:
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 The JVM components are as follows:
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 ClassesThe JDK Runtime layer includes Hosting Classes for:
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:
Figure 8 illustrates the JDI components:
FIGURE 8. - JDK Runtime Layer JDI Components
Event SystemJavaOS 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 ManagerJDI 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 DriversDevice 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 ManagerThe 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:
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.
MicrokernelThe 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 ManagementA 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 ManagementThe 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 ManagementThe 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 SupportA 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:
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.
Download JavaOS for Business SDK, 2.1 |
Readme |
Technical Summary |
Documentation |
Device Driver White Paper |
Product
and Marketing Information |
Java Point of Sale-Compliant
_______ | |||||
|
| ||||||||||||