In my previous blog, I talked about the object model of the vSphere API. Many people like the UML diagram that illustrates how the managed objects are inherited from each other.
Following that blog, I will introduce the object model of the open source Java API that is built on top of the Web Services, as well as some key design decisions I made while designing the API.
Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.
The following UML diagram is extracted from the overall model but adds much more details with properties and methods. If you can understand this diagram, you can then easily understand all other managed object types.
The ManagedObject class is not part of vSphere API, but added to vSphere Java API. It holds two private properties:
- mor of type ManagedObjectReference — pointing to the ManagedObjectReference object that is used to represent a managed object in VI SDK.
- serverConnection of type ServerConnection — pointing to the ServerConnection object I will cover later.
Besides accessors, the class has getCurrentProperty() method defined to encapsulate the PropertyCollector. This method gets called in subclasses to get a property. For example, the getName() in ManagedEntity called it like (String) getCurrentProperty(“name”); In most of cases, you don’t need to use it at all, I already provide explicit getter methods like getName() in concrete subclasses.
The ServerConnection, not part of vSphere API, is used to represent a connection to the server under a specific login user. It holds information like URL to the server, the userSession with username etc., and vimService which is the JUMBO interfaces with 300+ methods. For convenience, ServerConnection also has a reference to a ServiceInstance object.
Now let us take a look at the ServiceInstance type. It’s a special managed object and the first managed object you will have in a typical application logic flow. You can create a new ServiceInstance object by providing url/username/password, or url/sessionID combination. The later is not used as much as the first constructor, but very helpful when you develop a VI client plugin in Java.
According to the API Reference, the ServiceInstance has a ServiceContent object as its property, which holds all the ManagedObjectReferences to various “manager” attached to it, and an AboutInfo data object. Unlike Web Service interface, you can get any of them with a single call in Java API. ServiceContent object is, therefore, no long needed.
At the right side of the diagram are the ExtensibleManagedObject and its subclass ManagedEnity. ExtensibleManagedObject doesn’t have methods defined at all, but three properties. Therefore it only has three corresponding getters. As you will find in the overall UML diagram, it has many other subclasses, but I only list the ManagedEntity here.
ManagedEntity is one of the most important managed object type given that VirtualMachine, HostSystem etc. are all inherited from it. To search the inventory, I also provide a utility like class InventoryNavigator to group all the search methods to retrieve items in the inventory tree from a specified node. For example, you can easily find all the Virtual in one single call.
The above UML diagram and the overall diagram in previous blog should give you a pretty good picture about the object model and how key types are related to each other. If you really need to know more details about the Java API, please give it a try as described in the Getting Started Tutorial. There are also about 50 samples for you to continue learning.