Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F8/00—Arrangements for software engineering
  • G06F8/40—Transformation of program code
  • G06F8/54—Link editing before load time
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/44—Arrangements for executing specific programs
  • G06F9/445—Program loading or initiating

Definitions

• the present invention relates to a computer system and method for loading applications.
• the present invention relates to a computer system and method for application loading in an MHEG-6 environment.
• multimedia was only one of many elements of the World Wide Web. It was never meant as a support technology for the presentation of technical content or for interaction with the outside world.
• the advent of technologies such as Java (® Sun Microsystems Corporation) and ActiveX has increased the functionality of multimedia and, in turn, the World Wide Web but these have in turn made access to the World Wide Web a memory and CPU resource hungry activity.
• the MHEG (Multimedia and Hypermedia Experts Group) standard was developed to define a basic GUI (Graphical User Interface) and multimedia library for use in kiosk information systems, TV sets, or in video on demand servers for use in communicating with set-top boxes.
• MHEG level 5 defines a final form representation for applications such that the appearance of an application is common across all platform types. It allows GUI and multimedia applications to be simply created by defining its constituent components. It is the responsibility of the client terminal to have a run-time system that interprets MHEG commands, to present the application to the user and to handle local interaction with the user.
• MHEG level 5 is limited in that it does not cater for interaction with the outside world, for example data exchange or the use of client/server applications.
• MHEG level 6 is in extension to MHEG level 5 that defines a set of mechanisms allowing MHEG applications and Java applications to inter-operate.
• Java applications are not restricted to multimedia, GUI's and user interaction, offering communication with other computer hosts, applications etc.
• the inter-operation between Java and MHEG permit MHEG applications to communicate with the external environment.
• MHEG level 6 is mainly intended to support distribution of interactive retrieval (client/server) applications running on limited resource terminals.
• the Digital Audio-Visual Council (DAVIC) has adopted MHEG level 6 as the basis for the specification of set-top units for interactive Television.
• MHEG applications are delivered to the user as a series of MHEG objects which are interpreted on the user's terminal by an MHEG engine responsible for turning the MHEG objects to graphical and multimedia output at the terminal.
• Each MHEG level is built on the preceding level.
• An MHEG engine capable of running an MHEG level 6 application comprises an MHEG level 5 engine interfaced with a Java Virtual Machine. The interface between the Java virtual machine and the MHEG environment allows MHEG applications to run and interact with Java applications.
• Java applications are written in terms of a series of objects, each object defining a particular data structure or user interface element of the Java application.
• Each object is created from a predefined class which defines necessary data structures and functions for an object created from the class to be manipulated or interacted with. These functions are known as methods.
• a class is effectively a template which is referenced when initially creating an object to determine the structure of the object, the data structures the object may need to operate and also the methods the object can use.
• the classes of objects it uses are checked against those, if any, already held in memory. Any classes that are required but not held in memory are loaded into memory.
• For each class used to create objects by a Java application all the methods associated with the class are loaded by the Java virtual machine which runs the Java application. This approach, whilst ensuring that all required methods are loaded, is very wasteful in that many classes contain methods which are not used by the application but which are loaded anyway.
• a method for loading object-oriented applications comprising the steps of loading the application, determining the class type of each object required by the application, loading the class type(s), including a number of associated functions, required by the application, determining the associated functions loaded with each class, determining the associated functions to be used by the application and removing from memory the associated functions loaded but which are not required by the application.
• a computer system adapted for loading applications, comprising an application loader configured to load an application, to determine the class type of each object required by the application and to load the class type(s), including a number of associated functions, required by the application; and a class processor configured to determine the associated functions loaded with each class, determine the associated functions to be used by the application, and remove from memory the associated functions loaded but which are not required by the application.
• Figure 1 is a block diagram of a computer system adapted for implementing the present invention
• FIG. 2 is a flowchart of a method loading algorithm for use in the present invention.
• FIG. 3 is a flowchart of another method loading algorithm for use in the present invention.
• Figure 1 is a block diagram of a computer system adapted for implementing the method or system of the present invention.
• a computer system running MHEG level 6 applications comprises a server computer 10, a client terminal 20 (such as a television set top box) linked to the server by a data communications link 30 such as a computer network or telephone network.
• the client terminal 20 includes an MHEG engine (ENG) 21 , a Java Virtual Machine (VM) 22 and a core MHEG library (LIB) 23.
• ENG MHEG engine
• VM Java Virtual Machine
• LIB core MHEG library
• the MHEG engine 21 accesses the core MHEG library 23 and loads an MHEG user interface to enable a user to interact with the client terminal 20.
• the MHEG engine 21 also loads communication routines from the core MHEG library 23 enabling it to communicate with the Java VM 22 and the server computer 10.
• An MHEG application (such as an interactive television programme) accessed or requested by the user via the user interface is requested from the server computer 10 by the MHEG engine 21.
• the server computer 10 passes the MHEG application to the client terminal 20 as a series of MHEG objects. Once all the MHEG objects of the MHEG application are received by the client terminal 20, the MHEG engine 21 parses the objects and runs the application.
• the first time an MHEG application requires to run or interact with a Java application for example if the users interaction with the MHEG application results in a service in the form of a Java application such as video-on-demand being required from a remote server computer, the Java application is loaded as a series of class objects from the server computer 10 in the same manner as an MHEG application described above.
• FIG. 2 is a flowchart of a method loading algorithm for use in the present invention.
• the methods are cross-referenced with method calls from the Java application and the MHEG application to determine whether they are used and, if not, they are discarded instead of being loaded.
• step 40 a loaded class from which an object is to be created is parsed to determine the methods it includes. The name or an identifier of each method included in the class is recorded in a table in step 50.
• step 60 the method calls of the Java application and the MHEG application are cross-referenced with the table generated in step 50 to determine (at step 69) whether they are calling a method of the class and, if so, the entry in the table for that method is marked in step 70. Once all the method calls have been parsed (determined at step 71), the methods that are not marked in the table are deleted from memory in step 80.
• Figure 3 is a flowchart of another method loading algorithm for use in the present invention.
• Steps 40, 50, 60, 69, 70 and 71 are performed for the application to be loaded as has previously been discussed with reference to Figure 2.
• the steps are then also repeated for each further application using the class prior to step 80 to determine the methods they may require.
• the methods required by the already running application will already be in memory. However, methods not required will have been discarded previously and, if the new application requires any of the discarded methods, the whole class will be reloaded and the set of methods required by both applications is retained in memory.
• this process could be performed at the server so only the necessary code is transferred from the server to the client.
• the method and system for determining redundant methods according to the present invention could also be called at intervals during the running of the applications to determine methods that are no longer needed.
• Java code can be loaded in one 'chunk' using a JAR file to load the data (a JAR file is a collection of Java class files merged into a single file).

Landscapes

• Engineering & Computer Science (AREA)
• Software Systems (AREA)
• Theoretical Computer Science (AREA)
• General Engineering & Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Stored Programmes (AREA)
• Devices For Executing Special Programs (AREA)
• Multi Processors (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=10856100

Family Applications (1)

Country Status (9)

Families Citing this family (2)

Family Cites Families (1)

• 1999
  • 1999-06-26 GB GBGB9914927.0A patent/GB9914927D0/en not_active Ceased
• 2000
  • 2000-04-26 TW TW089107882A patent/TW463127B/zh not_active IP Right Cessation
  • 2000-06-22 WO PCT/EP2000/005769 patent/WO2001001292A2/en not_active Application Discontinuation
  • 2000-06-22 CN CNB008011737A patent/CN1175349C/zh not_active Expired - Fee Related
  • 2000-06-22 KR KR1020017002430A patent/KR20010072982A/ko not_active Application Discontinuation
  • 2000-06-22 EP EP00945803A patent/EP1135733A2/en not_active Withdrawn
  • 2000-06-22 BR BR0006857-8A patent/BR0006857A/pt not_active IP Right Cessation
  • 2000-06-22 JP JP2001507231A patent/JP2003503799A/ja not_active Withdrawn
  • 2000-06-22 PL PL00346280A patent/PL346280A1/xx not_active Application Discontinuation

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events