7.2 Programming Model | ITV Handbook: Technologies and Standards

According to the iTV Java programming model, the receiver is assumed to have a layered architecture that includes (see Figure 7.2) a Real-Time Operating System (RTOS) layer, a JVM layer, a Java-based implementation of the application manager, PersonalJava (pJava), JavaTV, and JMF [JMF]. The Java class file format plays the role of MPEG tables in the transmission of audio and video content, as class files are delivered via (MPEG or IP) transports to be decoded executed by the iTV receiver's JVM. On reception of the class files, an application management middleware component manages the application life cycle which includes loading the application's code and data, allocating resources for the benefit of the application, granting the application security permissions, instantiating the application's entry-point object, executing the application, terminating the application, and disposing of the memory it used.

Figure 7.2. The AWT Component Class and Interface Hierarchy.

7.2.1 Applications versus Xlets

In the same way that the term applet refers to a Java application running within a Web-browser on a PC, within the context of iTV in general and within this chapter in particular, the term application is used interchangeably with the term JavaTV Xlet or simply Xlet . The details of the distinctions are made clear in Section 7.6 which describes JavaTV Xlets in detail.

7.2.2 JVM

The JVM is the underlying enabling technology for Sun's Java programming model. It enables Java's cross-platform delivery and execution, allows using small code sizes providing transport efficiency, and serves as the firewall between users and malicious programs.

The JVM is an abstract computing machine. It has an instruction set and uses its own private memory areas. The first prototype implementation of the JVM at Sun Microsystems, Inc., emulated its instruction set in software on a handheld device that resembled a contemporary PDA. Current releases are available for Windows, MacOS, Solaris, and a number of embedded system platforms.

The JVM concept does not assume any particular implementation technology or host platform. It is not inherently interpreted, and it may just as well be implemented by compiling its instruction set to that of a real CPU, as for a conventional programming language. It may also be implemented in microcode , or directly in silicon.

The JVM relies only on the class file format and is therefore independent of the source code (need not be Java) programming language. A class file contains JVM instructions (or byte codes) and a symbol table, as well as other ancillary information. For the sake of security, the JVM imposes strong format and structural constraints on the code in a class file. Note that any language with functionality that can be expressed in terms of a valid class file (e.g., C++), can be hosted by the JVM.

7.2.3 Personal Java

The PersonalJava Application Environment (PJAE) and library specification, collectively referred to as the Personal Java platform, is specifically designed for small-scale and network connectable consumer products [PJAVA]. Beyond iTV set-top boxes, examples of such products includes hand-held computers, smart phones, automotive navigation equipment, information appliances, and game consoles. It was designed to improve on state-of-the-art embedded system development as follows :

For the content provider, having the PersonalJava application environment on a large variety of end user devices such as cellular phones, set-top boxes, and mobile handheld units means that the content need only be provided in one format. The content provider can focus on the development of compelling content rather than using resources to repackage the content for use on a multitude of different platforms.
For the device manufacturer, implementing the PersonalJava application environment means faster time-to-market . With PersonalJava, the time spent porting, debugging, and supporting multiple proprietary code bases is eliminated. Code can be leveraged across an entire product line of devices that may utilize different underlying CPU and RTOS combinations. The PersonalJava interface remains invariant even when a product line needs to be upgraded and the device manufacturer decides to switch to a cheaper or faster processor, or to a different operating system.

7.2.4 JavaTV

The JavaTV API was designed to provide access to the functionality unique to iTV receivers. Similar to PersonalJava, the JavaTV technology is a collection of libraries. The JavaTV APIs provide a standard interface between the downloaded application and the environment supporting the following key functionality:

Audio and video streaming and media synchronization using on-screen graphics and JMF
EPG through access to in-band and out-of- band service information data
Conditional access partly relying on the Java security framework

The software environment consists of the Java platform and the JavaTV API. In addition, the software environment typically includes an RTOS. An application developed for a television receiver can use the JavaTV API and the Java class libraries in the Java platform. These libraries enable television content developers to offer consumers interactive television content such as the scenarios presented in Chapter 2.

Content streaming is supported through integration with the JMF, the JavaTV API. Applications typically refer to data service components using JavaTV locators that have internal and external forms. The latter is used to locate the data stream, whether audio or video. Once the stream is located, a DataSource object is constructed that is used to obtain access to the stream. The JavaTV API makes no guarantees concerning buffering or availability of the data obtained through PushSourceStream2 .