Home > vSphere API > How to Extend vSphere Java API?

How to Extend vSphere Java API?

I got a request a while back for extending the vSphere Java API. The idea is that the API itself is pretty basic and not high level enough for some applications. For example, if you want to add a virtual NIC to a virtual machine, there is no explicit method for doing this. Fair enough.

Now, how to achieve this?

Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.

Three possible approaches

  1. Change the structure of the API. For every managed object type, we have two types: one with implementation, and the other inheriting the first one but really empty. The user can replace the first second one with extra methods as extensions. This approach is smart, but will cause confusion in the future. For instance, we will have many different implementations for the sample types.
  2. Use composition. You can create a new type that contains an instance of a managed object. How to expose the methods of the managed object? You can either manually add them to the containing type, or expose the instance of the managed object so that others can call its methods.
  3. Use inheritance. You can create a new type that inherits a managed object type. Once you get an instance of a normal managed object, you can pass into the constructor of extended managed object type. You can use the extended type anywhere a normal type is expected. Let’s pick VirtualMachine as an example,
class VirtualMachineEx extends VirtualMachine
{
  public VirtualmachineEx(VirtualMachine vm)
  {
    //copy over two attributes
  }

  public AdditionalMethod1()
  {
   ...
  }

  public AdditionalMethod2()
  {
   ...
  }
}

Which approach should you go with?

The first approach involves too much work and will confuse the community with different implementations under same types. It is therefore not a good one.

The second approach follows a basic OO principle: composition over inheritance. Given the way to expose the existing methods, it means some tedious work or a little odd code. Also, you cannot pass in the containing type where the contained type is expected; instead you have to get the contained object. Works but may look a little awkward.

The third approach seems to be the best, therefore is my recommendation if you want to extend vSphere Java API.

After talking to many users, I think it makes sense to have an additional package of these extended types for better user experience and higher productivity. This additional package will be shipped as a separate bundle along with the core API. So you can just ignore it if you don’t need it.

I will collect more requirements. If you have such requirement and/0r existing code to contribute, please feel free to let me know.

Categories: vSphere API Tags: ,
  1. Tos2k
    March 7th, 2011 at 13:43 | #1

    Hi Steve!
    Thanks for pointing me here 😉 But I am still a little confused about extending vijava, as the code, as advised, gives me compilation errors. Is what you ment:


    public class JobVM extends com.vmware.vim25.mo.ManagedObject {
    public JobVM(VirtualMachine vm)
    {}
    }

    ?

    Tos2k

  2. March 7th, 2011 at 15:37 | #2

    Hi Tos2k,

    What approach do you want to take? What errors did you get? Thanks!

    -Steve

  3. Tos2k
    March 8th, 2011 at 04:38 | #3

    Hi,
    can you confirm that:
    class VirtualMachineEx extends VirtualMachine
    is correctly?

    Java complains about a missing constructor doing that…

    Can you confirm that (your) code shown is what you mean?
    VirtualMachine instead of ManagedObject – in the text you write ManagedObject, not VirtualMachine.

    TIA,
    Tos2k

  4. March 8th, 2011 at 12:53 | #4

    Do you want to post your code and let’s go from there.

    -Steve

  5. __geo__
    March 9th, 2011 at 23:28 | #5

    probably missing super:

    class VirtualMachineEx extends VirtualMachine
    {
    public VirtualmachineEx(VirtualMachine vm)
    {
    super(vm.getServerConnection(), vm.getMOR());
    //copy over two attributes
    }

    public AdditionalMethod1()
    {
    ...
    }

    public AdditionalMethod2()
    {
    ...
    }
    }

  6. March 12th, 2011 at 19:00 | #6

    I noticed your constructor name (m is lowercase) does not match the class name VirtualMachineEx.

    Steve

  7. Tamir
    February 10th, 2015 at 07:53 | #7

    Hi Steve,
    We are using vijava5.5, this is a very helpful project by you.
    Wondering if you are attending to extend it for vijava6 API’s as well, and if so – when?

    Thanks!

  1. No trackbacks yet.