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.

This entry was posted in vSphere API and tagged , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

7 Comments

  1. Tos2k
    Posted March 7, 2011 at 1:43 pm | Permalink

    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. Posted March 7, 2011 at 3:37 pm | Permalink

    Hi Tos2k,

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

    -Steve

  3. Tos2k
    Posted March 8, 2011 at 4:38 am | Permalink

    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. Posted March 8, 2011 at 12:53 pm | Permalink

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

    -Steve

  5. __geo__
    Posted March 9, 2011 at 11:28 pm | Permalink

    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. Posted March 12, 2011 at 7:00 pm | Permalink

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

    Steve

  7. Tamir
    Posted February 10, 2015 at 7:53 am | Permalink

    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!

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  • NEED HELP?


    My company has created products like vSearch ("Super vCenter"), vijavaNG APIs, EAM APIs, ICE tool. We also help clients with virtualization and cloud computing on customized development, training. Should you, or someone you know, need these products and services, please feel free to contact me: steve __AT__ doublecloud.org.

    Me: Steve Jin, VMware vExpert who authored the VMware VI and vSphere SDK by Prentice Hall, and created the de factor open source vSphere Java API while working at VMware engineering. Companies like Cisco, EMC, NetApp, HP, Dell, VMware, are among the users of the API and other tools I developed for their products, internal IT orchestration, and test automation.