Posts tagged: REST

vCloud API Spec 0.9: What’s New?

By Steve Jin, May 4, 2010

Some of you may have noticed that VMware released vCloud API Spec version 0.9 last week. The 9 page document describes all the functions and corresponding REST syntax of version 0.9. Better than I had expected, it highlighted changes from version 0.8. So if you have read previous version, you can just scan for the changes with keywords: CHANGED, NEW, REMOVED.

The vCloud API includes the following categories of functions.

Basic functions

  1. Inventory Listing: lists the entities like org, vDC, vApp, etc., in the inventory.
  2. Catalog Management:  retrieve, add, remove catalog items.
  3. Upload, Download, and Provisioning: quite some new features related to template management.
  4. vApp Configuration: mostly new with much finer control over configuration.
  5. vApp Operations: power on, off, ect.
  6. Miscellaneous Operations: login, version, task management.

Administrative Extensions

  1. Cloud Administration
  2. Org Administration
  3. vDC Administration
  4. Catalog Administration
  5. User Administration
  6. Group Administration
  7. Role Administration

In most categories, you will find so called CRUD ( Create, Read, Update, Delete) operations. In fact, it’s easier to understand the API if you think of the REST API in the SQL way: the resouce is a table, the CRUD operations are like INSERT, SELECT, UPDATE, DELETE statements.

The API spec itself is not enough for you to get started with programming. You want to read the vCloud API Programming Guide v0.9. The schema files of version 0.9 are however not there yet.

If you have read my blog from the beginning, you may still remember a blog I wrote to make the REST into Object Oriented. In so doing, we can easily map the REST like APIs and programming interfaces in a mechanical way.

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to RSS or Email, and follow on Twitter.

4 Ways to WIN $2,500 Prize With vSphere Java API

By Steve Jin, February 4, 2010

You may have read blogs from my colleagues Mike DiPetrillo, Duncan Epping about the VMware Script-O-Mania contest. The prizes are $2,500 (1st), $1,000 (2nd), and $500(3rd) respectively. The contest ends in March 15, 2010. So act quickly!

“Wait, how can I WIN the prizes?”

Well, first of all, you want to read carefully the criteria. Note that your script is for System Administrators with ESXi. So it could be for initial server set up, health monitoring, trouble shooting, reporting auditing, or anything else that is cool and creative. I suggest you talk to system administrators what REAL PAINS they have, and how they would like to fix the problems.

When you are clear what problems to solve, then let’s move on.

If you are already familiar with PowerCLI and RCLI, you should probably stick with them. You can get helps from VMware Developer Community.

If not, open source VI Java API can help you!

Here are 4 ways the API can do for you to win the $2,500: Read more »

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to RSS or Email, and follow on Twitter.

Introducing A Tiny Yet Powerful API to Manage and Automate vSphere

By Steve Jin, February 3, 2010

In yesterday’s blog, I talked about a little known secret of vSphere MOB – the invisible embedded XML in the HTML pages. To take advantage of the secret, I created a client side REST API which was shipped in VI Java API 2.0.

Note that I call it a Client side REST, because it is different from conventional REST API whose boundary is on the wire. With the Client side REST, the boundary is on the client side over the Java API. It implies that you cannot use a Web browser to “GET” information as would you with most conventional REST API. Anyway, the difference is not big enough for you to think twice because even if you use conventional REST API, most likely you will use a wrapper layer instead of tweaking XML data directly.

The API is very powerful and easy to use, and can do almost everything the SOAP APIs can do. There are a few developers tried it and fell in love with it, but most people don’t know much about it.

When Would You Want to Use It?

As said, the Client REST API provides similar functionality as SOAP based API. The key advantages of the API are

  • Super fast loading time compared with VI SDK. Already impressed by the VI Java API SOAP implementation, this API is about 20 times faster than that in loading time.
  • Super simple and light-weighted. Only 4 Java classes involved and zero dependency on any third party library other than J2SE.
  • XML centric so that you can easily apply XPATH, XSLT, XQuery on the data returned from the API.
  • Version Neutral. It works with 2.0, 2.5, and 4.0 without any change in your code.
  • Can be easily ported to other languages. I actually did a Python version and then handled it over to my colleagues. Consider the amount of code involved, it’s not a big project.

Once you are clear with these benefits, you can decide how it fits your projects. Before you make the final decision, please read on to the discussion part.

Architecture Overview

As you can see from the following figure, there are two layers: REST API layer and the managed object wrapper/cache layer. The later is built on top of the former. You can build your applications on either or both of these two layers.

The REST API layer talks to the vCenter/ESX(i) as a MOB client. It takes REST-like URL from the callers and makes HTTP calls to the server. When the responses come back, it converts them back to XML and returns to the caller.

The managed object wrapper/cache layer provides a bit higher level services, so you can speak in terms like managed object, properties, data object, etc. The caching is a little interesting here. It basically provides a caching around a wrapper. The cache holds the whole property XML so that you can retrieve multiple properties without going to the server twice.

The following diagram shows the object models. RestClient is the REST API layer. The RestManagedObject and CachedManagedObject are Managed Object wrapper/cache layer.

The ResultConverter is a helper class that you don’t even need to know, but it does the heavy lifting in the back. The challenge for the ResultConvert is that the responses of method calls do NOT have any XML embedded, therefore the code has to parse the HTML tables to XML. It can be tricky when you have tables embedded in tables for several layers.

 
 

As a long time software professional, I know how important the samples are to learn a new APIs. Let’s move onto the HelloWorld like sample.

A Sample Using Both API Layers

This is a sample included with the VI Java API that shows how you can use the API. It has two methods that demo the usage of the REST level API and managed object level API. I believe it is clear enough for me not to add any additional explanation. Click here to check out the full code from the code repository.

public class RestAppDemo
{
  public static void main(String[] args) throws Exception
  {
    RestClient rc = new RestClient("https://8.8.8.8", "root", "pass");
    runRestLevel(rc);
    runMOLevel(rc);
  }

  public static void runMOLevel(RestClient rc) throws Exception
  {

    RestManagedObject si = new RestManagedObject(rc, "ServiceInstance");

    System.out.println("name:" + si.getPropertyAsString("content.about.fullName"));
    System.out.println(si.invoke("currentTime"));
    System.out.println(si.invoke("retrieveContent"));

    String allXml = si.getAllProperties();
    System.out.println(allXml);
    CachedManagedObject csi = new CachedManagedObject(allXml);
    System.out.println("name:" + csi.getProperty("content.about.fullName"));
    System.out.println("root:" + csi.getProperty("content.rootFolder"));
    System.out.println("cap:" + si.getPropertyAsString("capability.multiHostSupported"));

    String em_id = si.getPropertyAsString("content.eventManager");
    RestManagedObject eventMgr = new RestManagedObject(rc, em_id);
    System.out.println("latest evt:" + eventMgr.getPropertyAsString("latest.fullFormattedMessage"));

    RestManagedObject vm = new RestManagedObject(rc, "48");
    System.out.println("reload:" + vm.invoke("reload"));
    CachedManagedObject cvm = new CachedManagedObject(vm.getAllProperties());
    System.out.println("Roles:" + cvm.getProperty("effectiveRole"));
  }

  public static void runRestLevel(RestClient rc) throws Exception
  {
    String contentXml = rc.get("moid=ServiceInstance&doPath=content");
    System.out.println(contentXml);

    XPath xpath = XPathFactory.newInstance().newXPath();
    String emMOR = xpath.evaluate("//eventManager/text()", new InputSource(new StringReader(contentXml)));
    System.out.println("view:" + emMOR);
    String lastEventXml = rc.get("moid=" + emMOR + "&doPath=latestEvent");
    xpath.reset();
    String eMessage = xpath.evaluate("//fullFormattedMessage/text()", new InputSource(new StringReader(lastEventXml)));
    System.out.println("Latest Event: " + eMessage);

    System.out.println(rc.get(null));
    System.out.println(rc.get("?moid=ServiceInstance&doPath=content%2eabout"));
    long start = System.currentTimeMillis();
    System.out.println(rc.get("?moid=48"));
    long end = System.currentTimeMillis();
    System.out.println("time taken:" + (end-start));
    Map para = new Hashtable();
    para.put("newName", "Melody_SuSe");
    System.out.println(rc.post("moid=48&method=rename", para));
    Map para1 = new Hashtable();
    System.out.println(rc.post("http://10.20.143.205/mob/?moid=48&method=acquireMksTicket", para1));
  }
}

Discussion

Although the Client REST API works perfectly fine, it’s not supported by VMware but the open source community. The underlying MOB may change over the time. Without the secret XML, the whole stuff just doesn’t work unless much more efforts there to convert the property HTML to XML.

Having said that, it’s still a good choice for you to write small applications, especially small utilities, automation scripts, XML centric applications, etc.

Are you ready to give it a try? Visit the VI Java API project home. Everything is there.

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to RSS or Email, and follow on Twitter.

A Little Known Secret of vSphere Managed Object Browser

By Steve Jin, February 2, 2010

secretMost VI SDK developers know Managed Object Browser (MOB), and mostly have used it for better understanding of the SDK, or assisting programming and debugging. In my opinion, it’s a must-have  tool for every vSphere SDK developer.

It’s extremely helpful if you want to figure out the inventory path of certain managed entities. The vSphere Client shows you different paths which don’t work with the SearchIndex and others. Nothing wrong with vSphere Client – it just tries to display information in a way that is easier to understand by the system administrators.

To use the browser, you just enter the following URL to your server:

https://<ip_address|host_name>/mob/

After entering the user name and password, you see the home of the MOB. You can then click down to different managed objects, and even invoke methods. Check this document in vSphere Client Plug-ins community, in which I described how to use MOB to register a plug-in with “100% less line of code” (Carter’s joke, by the way). Because you have to change XML content, it could be quite error prone. Therefore you wouldn’t want to use it as a norm.

Everything till here is common knowledge. If you have ever closely read the HTML source of the MOB pages, you can find a section as follows:

<xml id="objData">
<object>
  <capability xsi:type="Capability">
    <provisioningSupported>false</provisioningSupported>
    <multiHostSupported>false</multiHostSupported>
    <userShellAccessSupported>true</userShellAccessSupported>
  </capability>
  <content xsi:type="ServiceContent">
    <rootFolder type="Folder">ha-folder-root</rootFolder>
    <propertyCollector type="PropertyCollector">ha-property-collector</propertyCollector>
    <viewManager type="ViewManager">ViewManager</viewManager>
    <about>
      <name>VMware ESX Server</name>
      <fullName>VMware ESX Server 3.5.0 build-62355</fullName>
      <vendor>VMware, Inc.</vendor>
      <version>3.5.0</version>
      <build>62355</build>
      <localeVersion>INTL</localeVersion>
      <localeBuild>000</localeBuild>
      <osType>vmnix-x86</osType>
      <productLineId>esx</productLineId>
      <apiType>HostAgent</apiType>
      <apiVersion>2.0.0</apiVersion>
    </about>
    <setting type="OptionManager">HostAgentSettings</setting>
    <userDirectory type="UserDirectory">ha-user-directory</userDirectory>
    <sessionManager type="SessionManager">ha-sessionmgr</sessionManager>
    <authorizationManager type="AuthorizationManager">ha-authmgr</authorizationManager>
    <perfManager type="PerformanceManager">ha-perfmgr</perfManager>
    <eventManager type="EventManager">ha-eventmgr</eventManager>
    <taskManager type="TaskManager">ha-taskmgr</taskManager>
    <accountManager type="HostLocalAccountManager">ha-localacctmgr</accountManager>
    <diagnosticManager type="DiagnosticManager">ha-diagnosticmgr</diagnosticManager>
    <licenseManager type="LicenseManager">ha-license-manager</licenseManager>
    <searchIndex type="SearchIndex">ha-searchindex</searchIndex>
    <fileManager type="FileManager">ha-nfc-file-manager</fileManager>
    <virtualDiskManager type="VirtualDiskManager">ha-vdiskmanager</virtualDiskManager>
  </content>
  <serverClock xsi:type="xsd:dateTime">2010-02-02T18:20:47.427266Z</serverClock>
</object></xml>

 If you are familiar with vSphere SDK, you know this XML holds all the property values of the ServiceInstance managed object. It’s not only for this starting managed object, but for every managed object along your clicking!

Remember, when your browser can get the information, you can write programs to do it as well. This actually led me to write the Client REST API, which released in VI Java 2.0. This is a very tiny yet powerful set of APIs which allow you to do everything, at least in theory, VI SDK can do for you.

It’s interesting to note that, when I talked to our engineer who wrote this great tool, he mentioned to me there was a secret in the MOB pages. By that time, I already shipped the API. There is little secret in IT today :-) .

I will blog on the Client REST API later. Stay tuned by subscribe the feed.

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to RSS or Email, and follow on Twitter.

My contribution mentioned in VMware news release

By Steve Jin, January 26, 2010

Last week VMware released a news “VMware Expands VMware vCloud Developer Ecosystem With Open-Source Java and Python SDKs for VMware vCloud API”. It says,

VMware has also made a number of open-source contributions to the Cloud Tools project, which powers the SpringSource Cloud Foundry service, enabling Java developers to deploy, test, and manage applications for VMware environments via VMware vSphere(TM) and the VMware vCloud API.

The contributions are the two adapters I developed for the CloudTools project to run on both vSphere and vCloud Express. I wrote the following news on VI Java API project home, which was then quoted in a SpringSource blog by Charles Lee.

DIY PaaS made possible with VI Java API and CloudTools
Nov 23, 2009

As mentioned earlier, VI Java API was leveraged at VMWorld 2009 Keynote demos. Now I got legal approval and contributed the related adapters to CloudTools code hosted at Google.

The CloudTools/CloudFoudry was originally designed for EC2. The CloudTools is open source; the CloudFoudry is not. With our contributed code, you can run CloudTools with vSphere for deploying your Java (Groovy) based web applications to your internal cloud. It offers both Maven and Grails plugins so you can do all the deployment with one line of command. Even better, you can integrate the plugin command with Spring Tools Suite (STS) and have a context menu in the Eclispe based IDE. This is what I call DIY PaaS (Do It Yourself Platform as a Service): vSphere + VI Java API + adapter + CloudTools.

The vCloud adapter was designed with Terremark vCloudExpress platform for the SpringOne 2GX keynote demo. The adapter does not use the VI Java API, but leverages the vCloud REST API. Besides the basic part, the Terremark vCloud API provides extensions for managing the network like public IP, InternetService, and node.

Although you see two different adapters, the user experiences are the same. Both adapters implement the required interfaces defined by CloudTools. Technically it’s not a big deal, but business wise, it is a big deal — you can seamlessly deploy to private (vSphere) cloud and public (service providers like Terremark) cloud, whatever best suits your needs.

DIY PaaS has many advantages overal typical PaaS especially ultimate flexibility and no vendor lock-in, which are critical for enterprises. I will detail more on the DIY PaaS concept, stategies and architecture in a later blog.

Author: Steve Jin is the author of VMware VI and vSphere SDK (Prentice Hall), creator of VMware vSphere Java API. For future articles, please subscribe to RSS or Email, and follow on Twitter.

Page 1 of 212

OfficeFolders theme by Themocracy