Abstract:
In a heterogeneous environment of virtual machines, an agent can migrate between virtual machines of different types. During migration, classes of the mobile agent may need to be instantiated on the new virtual machine. To support classes across all virtual machine types, a resource server is provided that can provide virtual machine type specific instances of the classfile. The resource server receives a resource request from a resource loader of a virtual machine. The resource request specifies the resource and the virtual machine type, thereby enabling the resource server to retrieve the correct instance of the classfile to return to the resource loader.

Description:
FIELD OF THE INVENTION 
       [0001]    This disclosure relates to virtual machines and in particular to migrating agents across virtual machines of different types. 
       BACKGROUND OF THE INVENTION 
       [0002]    In a Virtual Machine (VM) environment (e.g. Java, .NET etc) dynamic needs often require loading a new type, e.g. a new class in Java. Bringing a new class into the VM is handled by a resource loader that is responsible for finding the correct classfile for the new class and loading that classfile into the VM. Typically, the resource loaders are configured to load classfiles from VM specific resource servers. That is, there is a different resource server for each VM type. This can create problems in a heterogeneous environment because there is no single source for handling dynamic classfile needs, e.g. such as when a new mobile agent arrives at a VM. 
         [0003]    What is required is an improved system and method for providing resources to virtual machines. 
       SUMMARY OF THE INVENTION 
       [0004]    In one aspect of the disclosure, there is provided a method for obtaining a resource for use in a virtual machine. The method comprises determining at least one resource requirement in the virtual machine, providing a connection to a resource server, identifying a virtual machine type to the resource server, identifying the at least one resource requirement to the resource server, and receiving at least one resource corresponding to the virtual machine type from the resource server. 
         [0005]    In one aspect of the disclosure, there is provided a resource server configured to communicate with a plurality of virtual machines of a plurality of virtual machine types, and provide virtual machine type specific resources to the plurality of virtual machines. 
         [0006]    In one aspect of the disclosure, there is provided a computer-readable medium comprising computer-executable instructions for execution by at least one processor, that, when executed, cause the at least one processor to execute a virtual machine, receive a serialized stream comprising one or more classes, deserialize the serialized stream, obtain a resource server address from the serialized stream, generate a class request for at least one of the one or more classes, the class request indicating a type of the virtual machine, and cause the class request to be transmitted to a resource server at the resource server address. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0007]    Reference will now be made, by way of example only, to specific embodiments and to the accompanying drawings in which: 
           [0008]      FIG. 1  illustrates a system of virtual machines; 
           [0009]      FIG. 2  illustrates a method for obtaining resources for a virtual machine; 
           [0010]      FIG. 3  illustrates a process of a resource loader; 
           [0011]      FIG. 4  illustrates migration of a mobile agent between virtual machines of different types; 
           [0012]      FIG. 5  illustrates migration of a mobile agent which includes a resource server address; 
           [0013]      FIG. 6  illustrates a process for instantiating the mobile agent of  FIG. 5 ; 
           [0014]      FIG. 7  illustrates a process for processing a remote resource server queue in the resource loader; 
           [0015]      FIG. 8  illustrates a processor and memory of a virtual machine; 
           [0016]      FIG. 9  illustrates an instruction set executable on the processor of  FIG. 8 ; and 
           [0017]      FIG. 10  illustrates the processor and memory of the virtual machine in communication with a processor of a resource request handler. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0018]    In  FIG. 1 , there is shown a system  10  that includes a number of virtual machines  12 , shown as VM A, VM B and VM C. The VMs  12  represent different types of VMs, i.e. VMs that operate on different bytecode such as, without limitation, Java4, Java6, .NET CLR 2.0, Android Dalvik, etc. Each VM  12  includes a resource requestor  14  and resource loader  16 . 
         [0019]    Provided in the system  10  is a resource server  20 . The resource server includes a resource request handler  21  and data storage for storing resource files for VM type A  22 , VM type B  23  and VM type C  24 . Data storage for other VM types may also be provided. The data storage may be amalgamated into a single data storage or may be provided in some distributed form. The resource server  20  may itself run in a virtual machine of the same type as any of VM A, VM B or VM C or in any other VM type. The resource server may also run in a non-VM environment. In one embodiment, one or more of the data storages  22 ,  23 ,  24  may be offsite data storage that the resource request handler accesses through an appropriate network. The resource request handler includes an addressing system that identifies where the resource files for different types of virtual machines can be found. 
         [0020]    The resource files stored in the storages  22 ,  23 ,  24  may be VM-specific because they hold byte code that is VM-specific (e.g. Java class files for Java virtual machines). A resource can be a single item (e.g. a file containing a class) or a collection of items which may be an archive containing several files (e.g. a jar file, an OSGi bundle, a .NET assembly). 
         [0021]    A communication protocol is defined for communications between the virtual machines  12  and the resource server  20  that specifies how resources are to be requested. Specifically, a resource request  17  from a virtual machine  12  will identify a requested resource as well as the type of the virtual machine that is making the request. The resource request handler  21  is thus able to process the resource request  17  and retrieve the requested resource from the resource file storage of the appropriate type. The resource request handler  21  responds to the resource loader with a response  18  including the requested resource. In one embodiment, communication from the virtual machines  12  to the resource server  20  will typically be a serialized binary stream however any suitable protocol may be used, of which HTTP, RMI, SOAP/XML, Binary XML are some examples. 
         [0022]    A method for loading resources into the virtual machine is shown in the flowchart  100  of  FIG. 2 . At step  101 , the virtual machine  12  determines a resource requirement. At step  102 , the virtual machine makes a connection to a resource server  20  and identifies the virtual machine type and the resource requirement to the resource server  20  (step  103 ). The virtual machine then receives the requested resource corresponding to the virtual machine type from the resource server (step  104 ).  FIG. 1  shows a request for VM A resource, e.g., a Java resource, identified as Class X  17 . The resource request handler  21  retrieves the requested class from the storage  22  which stores VM A (Java) classfiles and returns Class X  18  to the resource loader  16 . Resources may be returned as stand alone files, archives, or in any appropriate form that can be processed by the resource loader. 
         [0023]    A method of operation of the resource loader is illustrated in the flowchart  200  of  FIG. 3  with specific reference to loading Java classes. It will be understood that non-Java resources may be used with the same method. At step  201 , the resource loader  16  receives a class request from the class requestor  14 . For example, the class request may arise as a result of deserialization of a received serialized object stream. If the resource loader  16  determines at step  202  that the class is available locally, e.g. from cache  13 , then the class is returned to the class requestor  14  at step  207 . Otherwise, if the resource loader is not configured with a remote resource loader, as determined at step  203 , then the resource loader  16  returns a Fail Return Error (step  208 ). If the resource loader  16  is configured with a remote resource server  20 , then the resource loader  16  proceeds to construct a resource request  17  to the resource server  20  (step  204 ). In the present example, the class request is for “Class X” from a type A virtual machine (e.g. Java VM). The request  17  is sent at step  205 . If the resource loader  16  receives the requested resource in the response message  18  from the resource server  20 , received at step  206 , then the class is returned to the class requestor at step  207 . Otherwise, a Fail Return Error is returned to the class requester  208 . 
         [0024]    In one embodiment illustrated in  FIG. 4 , the class requestor  14  may be considered to be a deserializer  19 . For example, a mobile agent  34  executing on VM B  32  may be serialized and migrate to VM A  12  across a network. In this example, the deserializer  19  of VM A  12  needs Class X for instantiating the incoming mobile agent  34  and so requests the Class X classfile from the resource loader  16 . The resource loader  16  generates a resource request that requests the Class X classfile for a type A virtual machine. 
         [0025]    In  FIG. 5  there is shown a modified system in which a serialized stream  34  from virtual machine B  32  includes the serialized class instances  35  that form mobile agent  34 . In this example, the mobile agent includes class instances ClassX, ClassY and ClassZ. In addition to the serialized mobile agent  35 , the serialized stream  34  includes a resource server URL  36  “URL 1 ” that provides an indicator to the resource server  20  from which the class instances can be retrieved. 
         [0026]    The process for instantiating the mobile agent  34  may be as illustrated in the flowchart  300  of  FIG. 6 . At step  301 , the serialized stream  34  is received into the deserializer of VM A  12 . Deserializing of the stream  34  commences by getting a first field of the stream  34  (step  302 ). A determination step  303  determines if the field is a Resource Context field. If the field is not a Resource Context field, the field is processed normally (step  308 ) and the process returns to step  302  where the next field is processed. If the field is determined to be a Resource Context field  36  at step  303 , then the deserializer  19  demarshalls the value of the resource loader URL, e.g. “URL 1 ”. The deserializer  19  then registers the Resource Loader URL with the Resource Loader  16 . The Resource Loader  16  may register the URL by receiving the URL from the deserializer  19  and adding the URL to a remote resource server queue  15 . As an optional step  306 , the URL may be added to a local list of all URLs registered with the resource loader. 
         [0027]    Normal processing as shown at step  308  includes instantiation of classes, for example by Class.forName( ) calls to the resource loader.  FIG. 7  shows a process  400  performed when the resource loader  16  receives such requests from the deserializer  19 . The request for a class is received at step  401 . The resource loader will typically cache remotely retrieved class files and so if the class is available locally, as determined at step  402 , then the class is returned to the deserializer at step  406 . Otherwise, the resource loader processes the remote resource server queue  15  to retrieve the requested class remotely. Because the most likely candidate to successfully supply the requested class is the last registered URL, the queue  15  may be a last-in-first-out (LIFO) queue though other systems for storing the potential URLs will be apparent to the skilled addressee. The resource loader  16  processes the queue  15  by selecting a first or next Resource Server URL from the queue (step  403 ). If no connection from the resource loader  16  to the server identified by the selected URL exists, then a connection is established at step  404 . The resource request  17  identifying the requested resource and the virtual machine type is sent to the selected server  20 . If the requested resource is not successfully returned, then the queue processing returns to step  403  where a next URL is selected from the queue  15 . If the requested resource is successfully supplied by the server, then the resource loader  16  returns the class to the deserializer  19  at step  406 . 
         [0028]    Using a stateful connection between the resource loader  16  and the resource server  20 , as opposed to a stateless approach, the “VM_type:” field and value may be sent in the connect message rather than in the resource request message. 
         [0029]    Once the mobile agent has been properly instantiated on the virtual machine to which the agent has migrated, any URLs required to instantiate the mobile agent, e.g. URL 1 , may optionally be deregistered from the remote resource server queue  15 . 
         [0030]    The components of the system  10  may be embodied in hardware, software, firmware or a combination of hardware, software and/or firmware. In a hardware embodiment, the virtual machine  12  may be executed on a processor  61  operatively associated with a memory  62  as shown in  FIG. 8 . The memory  62  may store instructions that are executable on the processor  61 . An instruction set  500  that may be executed on the processor  61  is depicted in the flowchart of  FIG. 8 . Specifically, when executed, the instruction set  500  allows the processor  61  to receive a serialized stream (step  501 ) comprising one or more classes and to deserialize the stream (step  502 ). The processor  61  obtains a resource server address from the serialized stream (step  503 ). If any of the classes from the stream require instantiating in the virtual machine, the processor  61  generates a class request (step  504 ) that includes an identity of the virtual machine type. The processor then causes the class request to be transmitted to a resource server at the resource server address (step  505 ). 
         [0031]    As shown in  FIG. 10 , the processor  61  may communicate through a suitable communications link  65  with further processors, such as a processor  71  of a resource request handler  21  with associated memory  72 . Through the communications link  65 , the processor  61  may provide the class requests. At the resource request handler end, the processor  71  may receive a class request and determine the virtual machine type of the requestor. The processor  71  may then look up the memory  72  to determine a location at which the requested class is stored for the particular virtual machine type. 
         [0032]    Although embodiments of the present invention have been illustrated in the accompanied drawings and described in the foregoing description, it will be understood that the invention is not limited to the embodiments disclosed, but is capable of numerous rearrangements, modifications, and substitutions without departing from the spirit of the invention as set forth and defined by the following claims. For example, the capabilities of the invention can be performed fully and/or partially by one or more of the blocks, modules, processors or memories. Also, these capabilities may be performed in the current manner or in a distributed manner and on, or via, any device able to provide and/or receive information. Further, although depicted in a particular manner, various modules or blocks may be repositioned without departing from the scope of the current invention. Still further, although depicted in a particular manner, a greater or lesser number of modules and connections can be utilized with the present invention in order to accomplish the present invention, to provide additional known features to the present invention, and/or to make the present invention more efficient. Also, the information sent between various modules can be sent between the modules via at least one of a data network, the Internet, an Internet Protocol network, a wireless source, and a wired source and via plurality of protocols.