Note: Descriptions are shown in the official language in which they were submitted.
CA 02267549 1999-03-30
LOADING AND UNLOADING OF APPLICATION COMPONENTS
Field of the Invention
This application is directed to a lightweight and reusable software component
architecture ideally
suited for building resource-constrained embedded products, such as products
which will be
connected to back-end server systems using a wireless or other relatively low-
speed network.
However, the invention is not limited to use in resource - constrained
environments.
Background of the Invention
The field of embedded, wireless products, particularly in the communications
arena, emphasize
device size/portability and cost. Thus, devices such as cellular telephones,
pagers and automotive
navigational systems are designed to be built with the least number and lowest
cost of hardware
components. This means that the smallest memory footprint and slowest
processor possible to meet
the performance requirements of the device are often used.
An embedded, wireless communications device is usually a member of a family of
similar devices,
addressing different points on price performance curves. This technology is
rapidly evolving into
an industry offering multiple functions in a single device. A good example is
the recent introduction
of "Personal Communication Services" (PCS). Through the use of the increased
bandwidth in
digital transmission, PCS wireless handsets or cellular telephones provide
additional services not
found on traditional analog cellular telephones, such as security, call
display, voice mail and
calendaring. Other personal wireless communications devices currently offer
email/messaging and
Internet access. The technology is converging, and soon, all these services
and more can be made
available for a single hardware platform.
However, due to constraints on memory capacity common to embedded devices, a
selection of
applications providing different services and/or service levels will have to
be made available for such
devices. Also, not every customer will want (or want to pay for) the same
service set as others - the
services required by a journalist may not be the same as those required by a
lawyer or plumber. This
CA9-99-004
CA 02267549 1999-03-30
degree of personalization adds complexity to the provision of applications and
services in the new
technology of personal wireless communication devices.
The manufacturer would ideally like to eliminate hardware/software
interdependencies in order to
separate the software and hardware selection processes so that a single
hardware offering can be used
to offer a range of software services on a vertical pricing structure.
However, to do this, a number
of hurdles must be overcome. These include application creation, application
deployment and
product maintenance.
First, because the technology and customer requirements are evolving so
rapidly, application
creation must be easy and fast. Second, installing and removing applications
onto the target device
must be done in the field, often over a connection to the server that is slow
and expensive. Finally,
software maintenance must be done without returning the product to the factory
or service centre,
ideally in the field, either by the user or as a background task.
In addition, the software supplier does not want to maintain separate
databases containing
downloadable applications for each model of device or version of software
currently on the market.
Summary of the Invention
It was the desire to address issues such as resource constraint and remote
downloading of new
applications that resulted in the present invention.
Although the invention is ideally suited for these types of environments, it
will be obvious to the
person skilled in the art that the use of the invention is not limited to such
environments. It is an
obj ect of the present invention to provide a framework with default
implementations for developing
and deploying applications over a wireless or a low speed network medium which
permits the
efficient loading, updating and operation particularly of resource constrained
embedded devices.
It is also a object of the present invention to provide a means to
differentiate customer requirements
CA9-99-004
CA 02267549 1999-03-30
so that software can be stored economically in a single database or file
system on a server, and
distributed on demand.
According to these and other objects, the present invention provides a
framework for upgrading
software in a target computing device having non-volatile memory and volatile
memory. The
framework includes means for identifying non-volatile memory requirement,
volatile memory
requirement, and pre-requisite software requirements for downloading and
running a desired
application in the target computing device, and comparator means to determine
whether the target
currently has available the memory and pre-requisite software requirements
prior to commencing
a download of the desired application.
The invention also provides a method for downloading a desired software
application from a server
to a target computing device. One receiving a request for the desired software
application, a set of
the software component required to run the desired software application is
obtained. This is
subsetted to a list of the software components required to be downloaded to
the target computing
device. The memory requirements for the subset list is compared with the free
memory available
in the target computing device.
Where there is insufficient free memory, software can be unloaded from the
target computing device.
The methods for performing the invention can be embodied in software encoded
on computer media
or m computer memory.
Brief Description of the Drawings
Embodiments of the invention will now be described in detail in association
with accompanying
drawings, in which:
Figure 1 is schematic diagram showing the remote networking environment of a
preferred
embodiment of the present invention;
Figure 2 is a schematic diagram of the system layout of a target device
according to the
CA9-99-004 3
CA 02267549 1999-03-30
invention;
Figure 3 is a flow diagram of the steps in the server/device for deciding to
download a
particular application component and its prerequisites according to a
preferred embodiment
of the invention;
S Figure 4 is a flow diagram of application component loading and
initialization, according to
the invention; and
Figure 5 is a flow diagram showing application component unloading, according
to the
preferred embodiment of the invention.
Detailed Description of the Preferred Embodiments
Figure 1 schematically illustrates a networking environment in which multiple
remote clients 2 are
in sporadic communication, over a wireless transmission medium 4 (e.g., a
radio bandwidth), with
a local network 6. The network 6 connects a plurality of specialized servers
8, such as application
servers, content servers, user data servers, billing systems, proxy servers
and user administration,
which provide these services directly or indirectly to the clients 2. The
network 6 may also have a
gateway 10 to an external network 12, such as the Internet.
The software architecture of the present invention is based on virtual machine
("VM") technologies
which are implemented in interpreted programming language environments such as
Smalltalk and
JavaTM' . These technologies have been used in embedded systems experimentally
for over a decade.
With increasing complexity and the changing requirements of connected embedded
products, VM
technologies are now cost-effective and competitive.
As shown schematically in Figure 2, the system in a target device consists of
several layers of
software, collectively designated as 22, on top of the hardware base 20. The
device's hardware base
20 includes a microprocessor, non-volatile memory (generally reffered to as
read only memory or
ROM) and volatile memory (generally referred to as random access memory or
RAM). The software
' Java is a trademark of Sun Microsystems, Inc.
CA9-99-004 4
CA 02267549 1999-03-30
22 contained in the layers above the hardware includes startup code, device
drivers, operating
systems and application level code.
The lowest layer of software 26 is the operating system and its associated
device drivers, including
the memory manager and the graphics driver. This layer is ported to the
specific hardware platform,
and it requires detailed knowledge of the hardware and its usage. In small
devices, a real time
operating system is often selected for reasons of size and performance. In
some smaller devices, an
operating system is not required and can be replaced with some form of device
interface code
containing only the drivers.
The second software layer 28 is the virtual machine (VM), which is ported to
the hardware platform
and the selected operating system. Typically, the VM layer 28 is linked
directly with the operating
system layer 26 together into a single executable and stored in flash memory
(which is non-volatile,
erasable memory) or other type of ROM. This single executable can then be
placed or copied into
RAM for execution at runtime.
The VM is the program that provides the execution environment on a single
machine. It maps data
and logic to the executing machine architecture, isolating the development
code from the architecture
of the machine. The VM initializes its own data structures and reserves a
predetermined amount of
memory for the image. The VM manages a preallocated RAM segment for image
memory (new and
old spaces) as well as preallocated flash memory segments where the
application components are
stored.
At the highest level is the image 24 which consists of the class definitions,
method byte codes and
the objects that define the applications and supporting code. The VM 28
isolates this layer from the
actual machine making this layer portable and reusable. An image can be
packaged into and
delivered/managed as one or more application components. This aspect is
discussed in detail below.
The image 24 is not a monolith, but has its own layers. These layers provide
organization and
CA9-99-004
CA 02267549 1999-03-30
partitioning opportunities to allow system engineers to integrate
functionality from multiple sources.
The bottom layer of the image 24 is called the base system 30. This layer
contains the base classes
used by the VM below and the subsystems and applications above. It provides
the basic
functionality, to all the dependent applications, such as the run time
environment, the common data
types and the other language implementation support classes.
Part of the base system 30 are the core subsystems that define the
characteristics of the products.
These include the user interface, the network interface, the local persistence
system, the application
management frameworks and various platform-specific subsystems. These
subsystems are typically
built and linked directly with the core system.
On top of the base system 30 is usually the application layer. Applications 34
use the service
provided by the base AC and core subsystems in the base system 30 to provide
the functionality to
be delivered to the end user. Optionally applications can use shared
application components 32.
These can act as common code libraries or services used by more than one
application component
34. Shared application components 36 that are required by an application
component 34 to function
are prerequisite image components and have to be loaded before the application
component 34 can
be loaded. There is technically no limit on the number of layers of shared
application components
32, but most system will limit it to one layer to reduce the complexity of
managing the application
components on the server and in the device.
According to the preferred embodiment of the invention, the image may be
packaged as multiple
application components, with some application components acting as
prerequisites (shared
application components) for others. An application component ("AC") is a file
of one or more
classes used to construct the layers of the image in a operating device. The
application layers for a
target platform can be packaged as application components which are
downloadable, reusable and
unloadable.
CA9-99-004 6
CA 02267549 1999-03-30
The building of application (or image) components is discussed in a
concurrently filed application
titled "Packaging Memory Image Files" (IBM docket no. CA9-99-005), which is
commonly
assigned. For the purposes of the present invention, it is important to
understand that an application
component includes memory segment descriptors with sufficient information
about the application
component requirements to permit it to be downloaded on the fly from a
database on a remote server
to an embedded device and run on the device.
These requirements include:
1. The application component's own identity;
2. A list of prerequisite application components required for this application
component to
run; and
3. The size requirements, both for loading the application component in ROM
and for
running it in RAM.
In the preferred embodiment, the application component's own identity is
provided by a marker
identifying the component as an image and by a pair of time stamps. One time
stamp is a version
time stamp used to indicate with which version the application component is
compatible; the other
is a unique time stamp indicating the unique build date for the particular
application component.
Each application component requires a base application component and some
random number of
other application components, providing user interface, network and other
basic support, that it
requires to run. In the preferred embodiment, this information is provided by
a list identifying the
prerequisite application components by name and a list of pointers (addresses)
to memory segments
inside the prerequisite application components.
Application components must know how much ROM (flash memory) and RAM
(including runtime
requirements) they need. Runtime requirements are identified at build time.
These size
requirements are included in the application component.
CA9-99-004 7
CA 02267549 1999-03-30
This information is loaded in the header of the application component from
which it can be extracted
and stored by the server to respond to download requirements.
For example, a base AC can access a library on the server and present its
version time stamp to
demand that the loader transmit all application components that are compatible
with it.
Following internal prechecking, the loader would present a list of application
components meeting
the compatibility requirement, and from this list, the user would select which
applications to
download.
Thus, the server manages the loading of application components on devices
according to:
1. Availability: which application components the server can provide;
2. Compatibility: whether the application component can run on this target;
and
3. Accessability: whether the application component is permitted to be loaded
onto this
target.
Figure 3 illustrates the management of loading an application component and
its prerequisites on a
target device. The process illustrated in Figure 3 is from the vantage of the
target device which
queries the server (and its own system) for the information it requires to
determine whether to
perform the download on a demand ("pull") basis.
However, the process could also be implemented as a "push" from the server,
with the server itself
querying the target device and determining from its own records whether a
download should be
started.
The process begins when the target device receives a request for an
application components (block
50). The request could originate with the user of the target device who
requests new or upgraded
service (for example, adding "calendaring" to a cellular telephone) or the
request could come from
the server awaiting a connection by the target device in order to
upgrade/update the user's service.
CA9-99-004 g
CA 02267549 1999-03-30
The target device first examines its own memory logs to determine whether the
application
component (corresponding to the requested service) is already loaded (block
52). If the application
is already loaded, then of course, the process terminates.
If the AC is not already loaded on the device, the device's manager adds the
application component
to a list of application components to download (block 54) and obtains a list
of the prerequisites for
the application component from the application component server (block 56). In
the preferred
embodiment, the list of prerequisites provided by the server is sorted by
dependency with the lowest
layer last.
Also, it should be noted that each of the prerequisites may have its own list
of prerequisites, and all
of these would be included in the list of prerequisites for the originally-
requested application
component provided by the server.
If there are any prerequisites listed for the requested application component
(block 58), the device's
manager determines, for each prerequisite on the list:
whether it is already loaded on the device (block 60); and
if it is already loaded, whether the loaded version of the prerequisite is
compatible with the
version of the requested application component (block 62). In the preferred
embodiment,
compatibility is determined by comparing the version time stamp of the loaded
pre-requisite with
the version time stamp of the requested AC. If the prerequisites time stamp is
the same or a later
version than the requested AC, then the prerequisite component is compatible
with the requested AC.
If the prerequisite is either not loaded or not compatible, then it is added
to the beginning of the
device's download list.
Once the downlist list is populated with the requested application component
and all prerequisite
application components needed to be downloaded to run the requested one, the
target device obtains
CA9-99-004 9
This information is loaded
CA 02267549 1999-03-30
the memory requirements for all of the application components on its download
list from the server
(block 66).
The target device determines whether it has enough memory to download all of
the application
components in the download list (block 68). If it does, it proceeds to
download each application
component (block 70), for example, using the process illustrated in Figure 4
and described below.
If the device does not have sufficient memory, it creates a "not enough
memory" exception (block
72) and ends the process. The requestor of the download could then implement
strategies to decide
how to free up memory by unloading other application components (least used,
most expensive,
largest or whatever method). If it were possible to free enough memory, the
download process
(block 68) could proceed.
An application component loader provides a mechanism for incrementally filling
in the contents of
an application component with image data so that the download of the
application component can
be done with using the least amount of RAM possible.
In the preferred embodiment, the application component loader is implemented
in a class called AC
Loader, which is part of the base system 30 in Figure 2.
The operation of the AC Loader is illustrated in Figure 4, and proceeds as
follows.
A new loader is created (block 100) which allocates the required memory
segments as described in
the application component information from the available free contiguous
memory block in ROM
(block 102). The loader then prepares that application component to receive
the image data (block
104).
A method called incrementallyLoad is called repeatedly (blocks 106,110) with
blocks of image data,
which are appended to the ROM segment of the image (block 108).
CA9-99-004 10
CA 02267549 1999-03-30
If the load must be aborted for any reason, for example, because the
connection to the server was
interrupted (block 112), the cancelIncrementalLoad method is called (block
114) to ensure that all
internal state is flushed (block 116).
If the load is successful, the finishIncrementalLoad method is called (block
118) to make the new
image data available to the running virtual machine and the garbage collector
as objects (block 120).
Until the application component data is completely loaded, the virtual machine
will not recognize
the obj ects contained in it. After the application component is loaded into
ROM, the RAM segments
are prepared and the mutable objects of the application component are copied
into RAM, in contrast
to static objects that cannot change their state (e.g. byte-code, strings,
bitmaps, etc.), which remain
in ROM.
Once loaded into a device, application components need a protocol for their
management to preform
activities such as startup, shutdown, unloading, warm start, restart, etc.. In
the preferred
embodiment, the application component manager residing in the target device
has the overall
responsibility for managing the application components. It is responsible for
all aspects of the life
cycle of application components, including loading, initializing, running (any
contained active
objects), deinitializing and unloading the application component.
The application programmer has the option to implement application component
specific behavior
for any of the life-cycle functions. These calls by the application component
manager can optionally
be monitored to complete in a certain time frame. If the call would result in
an endless loop for
example, the application component could be terminated and even be unloaded
again depending on
the application component manager's policy object (see below).
The first message after an application component has been successfully loaded
is 'install' (block
122). The application programmer can implement whatever initialization is
required when the
application component is loaded into a running system for the first time. The
default implementation
is to do nothing.
CA9-99-004 11
CA 02267549 1999-03-30
After that the application component's controller receives 'startup (block
124). This message is also
send after system start if the application component had already been loaded.
The default
implementation is to do nothing.
S Then it receives the 'run' call (block 126). For active application
components the application
provider would put the start code. The default implementation (to do nothing)
would make sense
for shared application components that are used as common libraries only.
These life-cycle method names are subject to change, the current names are
representations of life-
cycle functions. For example 'startup' could be renamed to 'initialize', 'run'
to 'start', 'shutDown' to
'stop', etc. There is also the possibility of adding (for example 'update') or
removing life-cycle
functions (combining 'startup' and 'run').
The application component manager has the following primary tasks;
1. It keeps a list of application components loaded on the target device;
2. It requests a list of available application components for loading from
either remote server
or local storage;
3. It calculates or negotiates with the server to arrive at a list of
prerequisite application
components for the image requested;
4. It loads application components;
5. It starts and stops application components by sending messages to the
application
component's controller; and
6. It unloads application components.
The application component manager may be customized to a specific device or
platform through
policy support in the form of a plugable object which is product specific and
implements the product
design decisions associated with loading and managing of application
components. This object can
act as a bridge between the applications already loaded and the available
applications on the server.
Therefore, the policy object would determine;
CA9-99-004 12
CA 02267549 1999-03-30
1. Whether to allow loading and unloading of application components;
2. The source of application components for loading;
3. The list of the available application components for download;
4. Whether to automatically load prerequisite application components;
5. A course of action if not enough space is available to load a desired
application
component (for example, to determine which application components can be
unloaded and what
resources would be released when they are unloaded);
6. Whether to unload a shared application component if all its dependents have
been
unloaded;
7. Whether to unload an application component when it has been terminated;
9. What to do if the application component causes an error (such as during
unload, restart,
etc.); and
10. The maximum number of threads an application component's application can
create.
In the preferred embodiment, an AC Loader object provides a mechanism for
incrementally filling
in the contents of an application component with image data.
According to the preferred embodiment, a facility is provided to unload
application components to
reclaim the resources they are using. The operation of this facility is
illustrated in Figure 5.
First, the application component manager sends the shutDown and uninstall
methods to the
controller of the application component which is about to be removed (block
130). This will give
the applications) in that application component the opportunity to send data
to its server, delete
persistent data, close resources or do other clean up work.
After that, all connections to objects inside that application component from
other application
components are broken. For each class defined in that application component
(block 132), all
references to the class and any instances of the class are located (block 134)
and replaced with null
(block 136). Also, all objects which reside in the memory space of that
application component but
CA9-99-004 13
CA 02267549 1999-03-30
that are instances of classes residing outside that application component and
are referenced from
other application components (block 138) are moved into the memory space of
the receiver class,
the object's own class or to the base application component (block 140). This
is performed
iteratively until complete.
If an application component cannot be removed cleanly (block 142), the
application component
manager will initiate a system restart without this application component
(block 148). This can
happen if there is no space available to move the referenced objects or if
there are invalid references
in places not under the control of an element of the application component
manager.
If the application component can be removed cleanly (block 142), the memory
segments are
physically released (block 144).
In either case, the application component manager will call the compact method
(block 146) in order
to eliminate "holes" in the RAM and the ROM segments, so that the largest
possible memory
segments can be allocated.
A preferred embodiment of the compact method is described in our concurrently
filed application
titled "Reclaiming Memory from Deleted Applications" (IBM docket no. CA9-99-
003), which is
commonly assigned.
The loading and unloading of application components of the present invention
is not restricted to
resource constrained devices, although due to the efficiencies achieved, it is
an appropriate
environment, as discussed. Thus, while embodiments of the invention have been
described in detail,
modifications, such as for use on other platforms, that would be obvious to
the person skilled in the
art are intended to be covered by the appended claims.
CA9-99-004 14
