Home > Articles > Operating Systems, Server

  • Print
  • + Share This
This chapter is from the book


The VI SDK exposes the features of the VMware Infrastructure. With the rapid changes of the VI, the VI SDK has evolved accordingly. As it stands today, there are three major versions of the VI SDK: 2.0, 2.5, and 4.0 (a.k.a vSphere SDK). The version 2.0 is not compatible with the other two.


As discussed earlier, the most important component in the SDK is the WSDL file from which the client stubs can be generated. The two versions' WSDLs use two different namespaces: VI SDK 2.0 uses urn:vim, and VI SDK 2.5 uses urn:vim25. Interestingly, the VI SDK 2.5 package also includes a previous version of WSDL. Therefore, you can use the VI SDK 2.5 package to develop applications with 2.0 interfaces.

When client-side stubs are generated, the package names are up to the developers. The pregenerated stubs use com.vmware.vim in SDK 2.0 and com.vmware.vim25 in SDK 2.5. If your application needs to work with two versions of platforms, you have two package names even though the class definitions are similar, if not the same.

Tying the version with a namespace complicates the application development. If you have to work with two versions of VI in your application, you must include two JARs. These JARs actually include many duplicated classes that are essentially the same, even though they end up in two package names. For example, there are two ManagedObjectReference types. When you enter the type name, the compiler cannot easily decide which one to use. To avoid the confusion, just include the full package name in your code.

The following code detects the version of the target. The basic idea is to get the vimService.wsdl file, as shown in Listing 18-2, with the following URL, and then parse the XML file for the version number.


When you want to discover the namespace of a target server, simply call the utility like the following. If the target supports SDK 2.5, the version is urn:vim25Service.

String version = VerUtil.getTargetNameSpace("");

Listing 18-2. VerUtil.java

package vim25.samples.mo.util;
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.net.HttpURLConnection;
import java.net.URL;
import java.security.KeyManagementException;
import java.security.NoSuchAlgorithmException;
import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;

import javax.net.ssl.HostnameVerifier;
import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSession;
import javax.net.ssl.TrustManager;
import javax.net.ssl.X509TrustManager;

public class VerUtil
   * Retrieve the target server's namespace
   * @param target, either IP or host name
   * @return the namespace, e.g. urn:vim25Service
  public static String getTargetNameSpace(String target)
    String version = "";
          new HostnameVerifier()
            public boolean verify(String urlHostName,
                SSLSession session)
              return true;

      String urlStr = "https://"+ target
          + "/sdk/vimService?wsdl";
      HttpURLConnection conn = (HttpURLConnection) new URL(
      BufferedReader in = new BufferedReader(
          new InputStreamReader(conn.getInputStream()));

      StringBuffer xmlWSDL = new StringBuffer();
      String line;
      while ((line=in.readLine())!= null)

      int start = xmlWSDL.indexOf("targetNamespace")
                    + "targetNamespace".length();
      start = xmlWSDL.indexOf("\"", start);
      int end = xmlWSDL.indexOf("\"", start+1);
      version = xmlWSDL.substring(start+1, end);
    catch (Exception e)
    return version;

  private static void trustAllHttpsCertificates()
    throws NoSuchAlgorithmException, KeyManagementException
    TrustManager[] trustAllCerts = new TrustManager[1];
    trustAllCerts[0] = new TrustAllManager();
    SSLContext sc = SSLContext.getInstance("SSL");
    sc.init(null, trustAllCerts, null);

  private static class TrustAllManager
    implements X509TrustManager
    public X509Certificate[] getAcceptedIssuers()
      return null;
    public void checkServerTrusted(X509Certificate[] certs,
        String authType)
      throws CertificateException
    public void checkClientTrusted(X509Certificate[] certs,
        String authType)
    throws CertificateException

  public static void main(String[] args)
    String ver = getTargetNameSpace("");
    System.out.println("ver:" + ver);


Can the applications developed with 2.0 still work with the newer VI product? Yes. The newer version of VI supports both the current and older versions of WSDL generated stubs.

Because the application still uses the old interfaces, they cannot, however, retrieve the new properties and call the newly added methods. So how can you access new properties and methods?

There could be two different solutions. First, rewrite the application to the newer version of SDK. Then the application no longer works with lower versions of VI platforms. For example, the application built on top of SDK 2.5 does not work with ESX 3.0 or VirtualCenter 2.0.

The second solution is to keep the old code as it is and choose to access new properties and new methods after detecting that the target is newer. Of course, the logic could be more complicated and the code could be less straightforward. But the gain would be application compatibility, which allows it to work with both older and newer versions of VI.

In the second solution, to access the newly defined properties or methods, you must convert the old ManagedObjectReference to the newer ManagedObjectReference. Because the definitions are the same except for the package name and name space, the conversion is straightforward. With the new MOR object, you can retrieve new properties and invoke new methods.

API Deprecation

With the evolution of the VI SDK, some of the interfaces are deprecated in favor of new ones. As a simple naming convention, the new interfaces normally have an Ex suffix in their names. For example, the old interface to create a cluster was createCluster(), and the new interface is createClusterEx().

These new interfaces normally come with new data objects with similar Ex suffixes. The createClusterEx() method, for example, has a new parameter type ClusterConfigSpecEx instead of ClusterConfigSpec for the old method.

Because of interface changes, some of the managed objects might have new properties of new types. For instance, the ComputeResource has a configrationEx property of ClusterConfigInfoEx.

Although for compatibility reasons the new interfaces are still supported, you should use the new interfaces especially for new development for better compatibility and more features.

Note that not all the deprecated methods have replacements. The destroyNetwork() method is such a case. When the network is no longer in use, the system removes it automatically like the garbage collection in Java, thereby making it unnecessary.

  • + Share This
  • 🔖 Save To Your Account