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?
Three possible approaches
- 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.
- 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.
- 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.
Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to Email or RSS, and follow on Twitter.
