- Managing Global Settings with OptionManager
- Collecting Logs Using DiagnosticManager
- Sharing Sessions Among Different Applications
- Using Single Sign-On from the VI SDK to CIM
- Downloading and Uploading Files Using HTTP Access
- Multithreading with the VI SDK
- Versioning
- Following Best Practices for Performance and Scalability
- Considering Internationalization
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Versioning
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.
Namespace
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.
https://<server-name>/sdk/vimService?wsdl
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("192.168.143.209");
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 = "";
try
{
trustAllHttpsCertificates();
HttpsURLConnection.setDefaultHostnameVerifier(
new HostnameVerifier()
{
public boolean verify(String urlHostName,
SSLSession session)
{
return true;
}
});
String urlStr = "https://"+ target
+ "/sdk/vimService?wsdl";
HttpURLConnection conn = (HttpURLConnection) new URL(
urlStr).openConnection();
conn.connect();
BufferedReader in = new BufferedReader(
new InputStreamReader(conn.getInputStream()));
StringBuffer xmlWSDL = new StringBuffer();
String line;
while ((line=in.readLine())!= null)
{
xmlWSDL.append(line);
}
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)
{
e.printStackTrace();
}
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);
HttpsURLConnection.setDefaultSSLSocketFactory(
sc.getSocketFactory());
}
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("10.20.143.205");
System.out.println("ver:" + ver);
}
}
Compatibility
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.