Last week an issue was reported with using vSphere SDK 4.1 to connect vSphere 4.0. The problem is related to the HTTP header called “SOAPAction” introduced in vSphere SDK 4.0. A recent KB article introduced this header, but with a minor error. I will talk about it in the end.
With vSphere SDK 4.1, the SOAPAction header has a value of “urn:vim25/4.1” while 4.0 has “urn:vim25/4.0”. For an older version of vSphere server, either vCenter or ESX/ESXi, it has no idea of the new value of SOAPAction, therefore refuse to serve. But the other way around works just fine because the newer version of vSphere knows about the older value but also support the older version of SDK directly. As a result, any application using older version of SDK works with newer version of vSphere. I am not saying your application can leverage new features. In fact, you cannot and must upgrade to do so.
From the SDK part, I found it’s a little disturbing when your newer SDK cannot work with older vSphere. We all expert newer SDK are better and back compatible. That is why Read more...
As a software professional, you may have heard about the source compatibility and binary compatibility. With the Web Services, a new type of compatibility came up. This is what I call wire compatibility. It’s not related to the programming but the XML messages passed on the wire. Since we don’t use XML directly but programming APIs, the wire compatibility surfaces and affects the source and binary compatibility.
Too abstract? You bet. Let’s pick up an example here. Because VMware vSphere API is defined in WSDL, I will use it in the following discussion.
In vSphere 4.1, the method PowerOnMultiVM_Task() gets an additional parameter called option typed as OptionValue array. The following are related parts in the WSDL:
<input message="vim25:PowerOnMultiVM_TaskRequestMsg" />
<output message="vim25:PowerOnMultiVM_TaskResponseMsg" />
<fault name="RuntimeFault" message="vim25:RuntimeFaultFaultMsg"/>
<element name="_this" type="vim25:ManagedObjectReference" />
<element name="vm" type="vim25:ManagedObjectReference" maxOccurs="unbounded" />
<element name="option" type="vim25:OptionValue" minOccurs="0" maxOccurs="unbounded" />
As you can see, the minOccurs of the option element is zero, meaning it’s optional. If you have an application built with 4.0 (no option parameter by then), the SOAP request still works. So it’s compatible on the wire. Read more...
Many of you already know there are some changes in the vSphere API from 2.5 to 4.0. The changes include 20+ new managed object types, additional properties (including sub-properties that embedded inside the first level properties), and several inheritance structure changes.
Several managed objects like Datastore became the subtype of ManagedEntity in vSphere 4, which is different from the hierarchy in 2.5 where it’s a subtype of ExtensibleManagedObject. The changes came for good reasons – we want permission control over these managed objects. Read more...
Among many well know improvements like huge performance boost, VI Java API 2.0 has a big feature that we don’t talk much. It’s the full compatibility: one library for all the existing version from 2.0, 2.0 to 4.0. Read more...