Browse Prior Art Database

Method for Permitting Several Version of a Module to Coexist within a Virtual Machine

IP.com Disclosure Number: IPCOM000013325D
Original Publication Date: 2001-Mar-01
Included in the Prior Art Database: 2003-Jun-18
Document File: 10 page(s) / 71K

Publishing Venue

IBM

Abstract

A method is proposed that permits to run several versions of a module within a virtual machine. This permits to have dynamic upgrades of a module without interrupting or disturbing in any manner services currently using the old version of the module. This proposal does not require the services to know that several versions of a module can be present simultaneously. This proposal also permits to select the version of the module to be used based on some external criteria like security rules or user profile.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 22% of the total text.

Page 1 of 10

  Method for Permitting Several Version of a Module to Coexist within a Virtual Machine

  A method is proposed that permits to run several versions of a
module within a virtual machine. This permits to have dynamic
upgrades of a module without interrupting or disturbing in any
manner services currently using the old version of the module. This
proposal does not require the services to know that several
versions of a module can be present simultaneously. This proposal
also permits to select the version of the module to be used based
on some external criteria like security rules or user profile.

Background

Virtual machines are becoming more and more popular.
SmallTalk and Java for example are two languages that permit
to create a program that will be executed within a virtual
machine. There are several reasons for this popularity.
Among others, a virtual machine is a secure environment in
which access to external resources like network interfaces
or disk or other processes can be severely controlled.
Another reason to mention is portability, the virtual
machine abstracts the underlying platform and therefore it
is possible to execute a program written for a specific
virtual machine on any platform that implements the virtual
machine specifications.

However these benefits can only be obtained because of some
restrictions on what a program can do in a virtual machine
and what a virtual machine shall provide to programs
executing inside of it. Especially, most virtual machines do
not allow to run different versions of the same code
simultaneously. The reason is that the virtual machine is
responsible in most cases for finding the code to be
executed and translating it in a format understood by the
underlying platform. Allowing several versions of the same
code in one virtual machine would be a very strong
requirement in the virtual machine specifications and could
lead to security problems, therefore most of the benefits of
a virtual machine would be lost.

Nevertheless it might be of the utmost importance for some
services to run continuously. In a telecommunication
network, for example, it is not acceptable that some
services are shutdown, even for a very short period of time.
In this case an additional mechanism has to be provided in
order to upgrade a module, without disturbing any of the
active services already using this module.

1

Page 2 of 10

Also when a service needs to access a given module, it
usually does not know how many versions of this modules are
present in the system, it may not be able to find the
correct version of a module, it is not its role to handle
this kind of problems, and it may lead to terrible
management problems if it has the responsibility of
resolving these issues. This is why it is not acceptable in
most cases to implement the version resolution algorithm in
the service.

This proposal provides a solution for solving the problems
described above in a manner which is transparent for both
the service and the module a service may need to access.

Problems

A...