DoubleCloud.org

If you’ve had a chance to use vSphere Web Service SDK, you must know the PropertyCollector is very hard to use. It takes a newcomer quite some time to learn how to use it, and even more time to learn to use it effectively. Luckily, you no longer have to if you use the open source vSphere Java API (a.k.a. vijava) because it has encapsulated the PropertyCollector behind these newly added getter methods of the managed object types.

Still, a question has lingered in my mind for a while: “Why was the PropertyCollector designed to be hard?” If you have a similar question, this article is for you. Note that this is just my own thoughts. Hope it offers a good explanation, and more importantly you can learn from it for your future designs.

Although vCenter and ESX/ESXi have implemented the same API interfaces, the vSphere API is mainly for vCenter and heavily influenced by vCenter. Functionality wise, vCenter supports almost all the APIs, while ESX/ESXi does part of them. It’s not strictly superset/subset relationship but pretty close.

As you know, the vCenter is built on top of relational databases, either Oracle or Microsoft SQL Server. With the vFabric Data Director and vPostgress, we can expect Postgress to be used. Why? According to Paul Maritz, you got to eat your own dog food.

So vCenter is a database centric application in server form. What does it really mean? At a high level, the managed object types are mapped to tables in the database; managed object instances to records; properties to fields. The ManagedObjectReference includes both type (table) and value (primary key). Secondly, different threads in vCenter share information via database.

With that in mind, the PropertyCollector is really an interface to the database retrieving different tables (managed object types) and their fields (properties). It’s very natural to design something like PropertyCollector, a single type that is responsible for getting all properties of all managed objects. Also with SOAP Web Services, it does not make much sense (check out the data transfer object design pattern) to provide numerous getters, each of which corresponds to a property.

While the single type making sense, the interface design can be improved however. The most common use case of PropertyCollector is to retrieve a property from a managed object. With the existing interfaces, you got to work with several data objects to specify what you want. It of course works but isn’t easy to use. Ideally it should have included a simple interface as follows:

Object getProperty(ManagedObjectReference obj, String propName)

This simple property retrieval is, however, not the most common usage of PropertyCollector in vSphere Client which has been the first and still the most important application built on top of vSphere API. This is yet another reason why the PropertyCollector is hard to use – its major application vSphere Client has different requirements that have been satisfied, therefore there hasn’t been enough incentives to improve the design.

Now, how to bridge the gap? I think the open source vSphere Java API has demonstrated a good approach. Should you be interested in how, you can check out the code. The architecture is designed so that other distributed system can leverage it as well. So you may still find it useful even if you are not using VMware vSphere.