Highlighted
Expert
Expert

No AXIS any more -- introducing high performance web service engine, faster, smaller, more flexible

I am very pleased to announce the VI Java API 2.0 Beta. It comes with many feastures and improvements as follows:

  • High performance Web Service Engine to replace AXIS. It's about 15 times faster in loading the library, and 4+ faster in serialization/deserialization than AXIS.

  • Much smaller size of libraries, 1/5 of what is required using AXIS.

  • POJO Data Objects and Java Enum Types.

  • REST Client API. It's a super light weighted library.

  • Updateed samples using the APIs.

  • Multiple version support with same library.

  • Easy access the SOAP response, allowing further performance optimization for demanding applications.

To download the binary and source code, click here Given the increased size, the binary (.zip) and source (.jar) are packaged separately for the first time.The binary also include the dom4j 1.6.1 binary. That is the only 3rd party you will need. No AXIS anymore!

The VI Java API interfaces do not change, so the applications still work. Since Java enum type is used for XML enumeration types, the related code to access these types may need to be updated. Check out the samples to find more.

Steve JIN, VMware Engineering

Creator of VI Java API:

Steve JIN Author of VMware VI and vSphere SDK; Creator of open source VI Java API (http://vijava.sf.net); Blogger at http://www.doublecloud.org
0 Kudos
14 Replies
Highlighted
Expert
Expert

A big company emailed me Friday. It says,

"Thanks for sending the note on the updated VIJAVA 2.0b1. We put that into our project this morning and it's a HUGE speed improvement for us. Great work!"

Steve JIN, VMware Engineering

Creator of VI Java API:

Steve JIN Author of VMware VI and vSphere SDK; Creator of open source VI Java API (http://vijava.sf.net); Blogger at http://www.doublecloud.org
0 Kudos
Highlighted
Expert
Expert

Another feedback I got from a leading storage company:

"2.0 is absolutely fabulous. Previously, the API calls were taking about 90 seconds, now with 2.0 they are taking 25-30 seconds. You have done a fantastic job, thanks!"

Given the time spent on the server side, the serialization/deserializtion is more than 4 times faster than AXIS.

Steve JIN, VMware Engineering

Creator of VI Java API:

Steve JIN Author of VMware VI and vSphere SDK; Creator of open source VI Java API (http://vijava.sf.net); Blogger at http://www.doublecloud.org
0 Kudos
Highlighted
Expert
Expert

The support for next version SDK is ready. VMware runs a private beta, so I cannot release it before SDK GAs. If you are a beta customer, you can talk to your alliance manager for it.

Steve JIN, VMware Engineering

Creator of VI Java API: http://vijava.sf.net

Steve JIN Author of VMware VI and vSphere SDK; Creator of open source VI Java API (http://vijava.sf.net); Blogger at http://www.doublecloud.org
0 Kudos
Highlighted
Expert
Expert

The samples can be browsed @

Steve JIN, VMware Engineering

VI Java API 2.0: 4+ faster than AXIS with 1/4 of the size. Check out @

Steve JIN Author of VMware VI and vSphere SDK; Creator of open source VI Java API (http://vijava.sf.net); Blogger at http://www.doublecloud.org
0 Kudos
Highlighted
Expert
Expert

An update to beta 1 was released on Feb 14 to address two bugs.

Steve JIN, VMware Engineering

Creator of VMware Infrastructure Java API: http://vijava.sf.net

VI Java API 2.0 --- 15 times faster than AXIS in loading, 4+ faster in deserialization; only 1/4 of the size required by AXIS. More importantly freedom to redistribute your applications.

Download, Samples, DocWiki, RSS Feed

Steve JIN Author of VMware VI and vSphere SDK; Creator of open source VI Java API (http://vijava.sf.net); Blogger at http://www.doublecloud.org
0 Kudos
Highlighted
Expert
Expert

A new update (No. 2) to the beta was just released. It includes two bug fixes. Check it out

Steve JIN, VMware Engineering

Creator of VMware Infrastructure Java API:

VI Java API 2.0 --- 15 times faster than AXIS in loading, 4+ faster in deserialization; only 1/4 of the size required by AXIS. More importantly freedom to redistribute your applications.

Download, Samples, DocWiki, RSS Feed

Steve JIN Author of VMware VI and vSphere SDK; Creator of open source VI Java API (http://vijava.sf.net); Blogger at http://www.doublecloud.org
0 Kudos
Highlighted
Contributor
Contributor

Steve,

I'm new to vi java api and new to this forum. I'm finding that your 2.0 API is significantly faster than the Axis based API. Before I fully adopt this API, can you answer a few questions?

Questions:

1. I can't tell via your release notes, readme, or license file, but will this API eventually replace the one distributed with the VI SDK 2.5? A few replies back, you hinted at it making into the next SDK GA?

2. If and when it makes it to the next SDK, will VMware provide support for it? VMware tech support tells me that they don't provide support for the VI SDK - they tell me I have to use this forum.

3. Is there a projected release date for the next SDK release? Aside from bug fixes, do you anticipate major changes (ex. architectural, method prototype) that would require me to re-code when the next SDK is released?

Question 1 is critical for me - if you can answer it, I can move forward with development.

Thanks in advance.

0 Kudos
Highlighted
Expert
Expert

1. I can't tell via your release notes, readme, or license file, but will this API eventually replace the one distributed with the VI SDK 2.5? A few replies back, you hinted at it making into the next SDK GA?

> This API is an open source project. Although sponsored by VMware, it's not a VMware product. The support for next release of SDK is ready but I cannot release it because VMware runs a private beta program.

2. If and when it makes it to the next SDK, will VMware provide support for it? VMware tech support tells me that they don't provide support for the VI SDK - they tell me I have to use this forum.

> VMware will not support this API, but the community will. I am pretty active in the forum to help developers.

3. Is there a projected release date for the next SDK release? Aside from bug fixes, do you anticipate major changes (ex. architectural, method prototype) that would require me to re-code when the next SDK is released?

> I plan to release the API with support for the next SDK release on the same day of the next SDK release. I don't anticipate big changes other than more additions of managed objects, interfaces.

Question 1 is critical for me - if you can answer it, I can move forward with development.

Steve JIN, VMware Engineering

Creator of VMware Infrastructure Java API. VI Java API 2.0 --- 15 times faster than AXIS in loading, 4+ faster in deserialization; only 1/4 of the size required by AXIS. More importantly, the freedom to redistribute your applications. (Download, Samples, DocWiki, RSS Feed)

Get Connected with Other Developers in the Community?

Steve JIN Author of VMware VI and vSphere SDK; Creator of open source VI Java API (http://vijava.sf.net); Blogger at http://www.doublecloud.org
0 Kudos
Highlighted
Contributor
Contributor

Thank you so much for your quick reply.

Can you help me with a problem I'm having with the Peformance Manager. I get the following exception for the source code at the bottom. When debugging the code, I'm getting back the vm just fine and the performance counter exists. The exception occurs on the call to queryPerf():

Exception in thread "main" java.rmi.RemoteException: Exception in WSClient.invoke:; nested exception is: 
	java.lang.NoSuchFieldException: sampleInfo
	at com.vmware.vim25.ws.WSClient.invoke(WSClient.java:158)
	at com.vmware.vim25.ws.VimStub.queryPerf(VimStub.java:1051)
	at com.vmware.vim25.mo.PerformanceManager.queryPerf(PerformanceManager.java:88)
	at com.vmware.vim25.mo.samples.PerformanceStats.main(PerformanceStats.java:70)
Caused by: java.lang.NoSuchFieldException: sampleInfo
	at java.lang.Class.getField(Class.java:1520)
	at com.vmware.vim25.ws.XmlGen.fromXML(XmlGen.java:158)
	at com.vmware.vim25.ws.XmlGen.fromXML(XmlGen.java:115)
	at com.vmware.vim25.ws.WSClient.invoke(WSClient.java:154)
	... 3 more

<QueryPerfResponse xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:vim25"><returnval xsi:type="PerfEntityMetric"><entity type="VirtualMachine">vm-764</entity><sampleInfo><timestamp>2009-03-04T19:53:08Z</timestamp><interval>20</interval></sampleInfo><value xsi:type="PerfMetricIntSeries"><id><counterId>105</counterId><instance>4000</instance></id><value>0</value></value></returnval></QueryPerfResponse>

Digging deeper, it seems XMLGen.fromXML() is reconstituting a soap response (above) for type "PerfEntityMetricBase" and 'sampleInfo' node element but is unable to find the sampleInfo data member via reflection for PerfEntityMetricBase - which is accurate since the sampleInfo is a member of PerfEntityMetric. Looking at the xml response above and the code below, it seems that XMLGen.froXML() needs to return a PerfEntityMetric that contains a PerfEntityMetricSeries that contains the performance values and the PerfEntityMetric returned has to be cast as a PerfEntityMetricBase. I hope what I wrote was clear and useful to you.

CODE:

	    CommandLineParser clp = new CommandLineParser(new OptionSpec[]{}, args);
	   	String urlStr = clp.get_option("url");
  	    String username = clp.get_option("username");
	    String password = clp.get_option("password");

		ServiceInstance si = new ServiceInstance(new URL(urlStr), username, password, true);
		Folder rootFolder = si.getRootFolder();
		ManagedEntity mes = new InventoryNavigator(rootFolder).searchManagedEntity("VirtualMachine", "FSDALVM-DEV03 (10.0.2.33)");
		
		VirtualMachine vm = (VirtualMachine) mes; 
				
		int counter = 105;   // net performance: kbps received
		
		PerformanceManager pmRef = si.getPerformanceManager();
		
		PerfMetricId[] aMetrics = pmRef.queryAvailablePerfMetric(vm, null, null,
				new Integer(20));
		ArrayList mMetrics = new ArrayList();
		if (aMetrics != null) {
			for (int index = 0; index < aMetrics.length; ++index) {
				if (counter == aMetrics[index].getCounterId()) {
					mMetrics.add(aMetrics[index]);
				}
			}
		}

		PerfMetricId[] metricIds = (PerfMetricId[]) mMetrics.toArray(new PerfMetricId[0]);
		PerfQuerySpec qSpec = new PerfQuerySpec();
		qSpec.setEntity(vm.getMOR());
		qSpec.setMaxSample(new Integer(1));
		qSpec.setMetricId(metricIds);
		qSpec.setIntervalId(new Integer(20));

		PerfQuerySpec[] qSpecs = new PerfQuerySpec[] { qSpec };

		PerfEntityMetricBase[] pValues = pmRef.queryPerf(qSpecs);
		Long result = null;
		if (pValues != null) {
			result = new Long(0);
			for (int i = 0; i < pValues.length; ++i) {
				PerfMetricSeries[] vals = ((PerfEntityMetric) pValues[i]).getValue();
				for (int vi = 0; vi < vals.length; ++vi) {
					if (vals[vi] instanceof PerfMetricIntSeries) {
						PerfMetricIntSeries val = (PerfMetricIntSeries) vals[vi];
						long[] longs = val.getValue();
						result += longs[0];
					}
				}
			}
		}
		System.out.println(vm.getName()+": "+result);

		si.getServerConnection().logout();

0 Kudos
Highlighted
Expert
Expert

Thanks for reporting the bug. I have filed a bug on this with project tracker for you:

https://sourceforge.net/tracker/index.php?func=detail&aid=2663642&group_id=228007&atid=1073396

The fix is also checked into SVN at

http://vijava.svn.sourceforge.net/viewvc/vijava/trunk/src/com/vmware/vim25/ws/XmlGen.java?revision=1...

Could you please give it a try and let me know if it works or not? You just need to replace single file of your existing one. If yes, I will cut another update - #3.

Thanks!

Steve JIN, VMware Engineering

Creator of VMware Infrastructure Java API. VI Java API 2.0 --- 15 times faster than AXIS in loading, 4+ faster in deserialization; only 1/4 of the size required by AXIS. More importantly, the freedom to redistribute your applications. (Download, Samples, DocWiki, RSS Feed)

Get Connected with Other Developers in the Community?

Steve JIN Author of VMware VI and vSphere SDK; Creator of open source VI Java API (http://vijava.sf.net); Blogger at http://www.doublecloud.org
0 Kudos
Highlighted
Contributor
Contributor

It works beautifully, and fast too.

Once again, thanks for the quick response. It helps restore order in the universe - I can tell because upper management isn't so reluctant to move forward now. Smiley Wink

0 Kudos
Highlighted
Expert
Expert

Thanks HiepFirescope!

The Beta U3 was just released! It includes the following fixes:

A new update to the VI Java API 2.0 beta was just released to fix the following bugs:

  • 2671806 Need a method to specify the namespace of a target

  • 2665725 createSnapshot_Task(...).waitForMe() throws RemoteException

  • 2663642 PerformanceManager.queryPerf fails with Exception

  • 2657981 Task.waitForMe should throw appropriate MethodFault

  • 2657952 HostSystem.reconnectHost does not follow "_task" convention

  • 2655705 WSClient.invoke attempts to instantiate enum

  • 2646499 Task.waitForMe prints stack trace output from MethodFault

  • 2639448 OptionManager.updateOptions() does not work

  • 2639433 The searchDatastore_Task() returns null

Many thanks to the folks who reported/filed bugs: David Kelly(NetApp), James Burke (NetApp), Steve Strassmann(VMware), Garvin Gray(VMware), Daniel Parrella (VMware), Ryan Stokes, HiepFirescope, Andrew Kutz (Hyper9).

To download, visit here

Steve JIN, VMware Engineering

Creator of VMware Infrastructure Java API. VI Java API 2.0 --- 15 times faster than AXIS in loading, 4+ faster in deserialization; only 1/4 of the size required by AXIS. More importantly, the freedom to redistribute your applications. (Download, Samples, DocWiki, RSS Feed)

Get Connected with Other Developers in the Community?

Steve JIN Author of VMware VI and vSphere SDK; Creator of open source VI Java API (http://vijava.sf.net); Blogger at http://www.doublecloud.org
0 Kudos
Highlighted
Expert
Expert

After the beta one and three updates therefore, we finally hit Beta 2

which includes all the fixes to the bugs the community has reported.

It's now stable than ever (0 open bug on the tracker). We're

on track to GA release synchronized with next major VI SDK release.

In addition, beta 2 has moderate performance improvement and fixed following bugs:

  • 2692371 OptionManager#getSetting() fails -- a typo in property name

  • 2692265 Update readme with latest information

  • 2690376 Incorrect serialization of Calendar if first level object

  • 2689088 Using streaming feature in parsing XML

  • 2688913 Typo in the VIM20 namespace

  • 2685661 si.invoke("currentTime") does not return valid result. Note: the client REST API behind this bug is experimental.

Many thanks to the folks who reported/filed the above bugs: Brian

McFeely (TripWire), Andrew Kutz (Hyper9), soyuppy, Kem, Trak Marba.

The big thing of this release is the optimization of the web service

engine, mainly leveraging the streaming feature of the XML parser. So

don't be surprised to notice the performance improvement.

Steve JIN, VMware Engineering

Creator of VMware Infrastructure Java API. VI Java API 2.0 --- 15 times faster than AXIS in loading, 4+ faster in deserialization; only 1/4 of the size required by AXIS. More importantly, the freedom to redistribute it with your applications. (Download, Samples, DocWiki, RSS Feed)

Get Connected with Other Developers in the Community?

Steve JIN Author of VMware VI and vSphere SDK; Creator of open source VI Java API (http://vijava.sf.net); Blogger at http://www.doublecloud.org
0 Kudos
Highlighted
Contributor
Contributor

Steve,

Thanks for your VIJava APIs. It works great for me.

I am working for a company which try to integrate our software into VCenter as a plugin.

Eventhough open source is working great for us, Company want to proceed with "VMWare supported" sdk. (older SDK with AXIS)

I am little confused. VIJava has been listed under vmware communities but still claim "no support" from VMWare.

Can you exactly tell me "What is this supporting all about?". Will VMware support "SDK with AXIS" in future?

Can you point me to some samples/documents which help me in "SDK with AXIS" coding?

I am blocked due to this decision. Waiting for your response.

Thanks,

Arun

0 Kudos