Archive

Posts Tagged ‘sdk’

Azure Service Management APIs: The Old APIs That Works

March 14th, 2016 3 comments

After the initial bad experience with the new Azure Resource Management APIs, I took a different approach – try the old Service Management APIs. While transitioning from old system to new system, the old one may still be the best for an unexpected long period of time. Like VMware vSphere Client, VMware has declared end of life many times, but it’s still the favorite for most customers, while the future Web Client remains “future” since 2011.

What I Learned about Microsoft Azure and its Resource Management APIs

March 9th, 2016 No comments

It was my plan to go over the popular cloud services on their management APIs. After familiarizing myself with Amazon AWS Java SDK with a few samples, I started with Azure and it turned out to a painful process.

In the following I will walk you through what I had experienced, and what works and not. Hope my experience will help you save some time with Azure.

Amazon Web Service Java SDK Tutorial: List All Networks

March 8th, 2016 1 comment

In my previous posts, I showed samples on virtual machine creation, virtual machine instances listing, storage volume listing. This sample shows how to list all the networks that you have.

With the information about your networks, you can get all the private and public IP addresses.

To run the following sample, you can check out the previous post for the pom.xml file and how to get AWS credentials from AWS console.

621274bd4fadac35b5a9c8e99b0f688c005

Amazon Web Service Java SDK Tutorial: List All Volumes

March 7th, 2016 3 comments

In my previous posts, I showed samples on how to create a new virtual machine instance, and how to list all the virtual machine instances you own. This sample shows how to list all the disk volumes that you have.

To run the following sample, you can check out the previous posts for the pom.xml file and how to get AWS credentials from AWS console.

package org.doublecloud.awssample;
 
import com.amazonaws.auth.AWSCredentials;
import com.amazonaws.auth.PropertiesCredentials;
import com.amazonaws.services.ec2.AmazonEC2;
import com.amazonaws.services.ec2.AmazonEC2Client;
import com.amazonaws.services.ec2.model.DescribeVolumesResult;
import com.amazonaws.services.ec2.model.Volume;
 
public class AwsEc2ListVolumes
{
  public static void main(String[] args) throws Exception
  {
    AWSCredentials credentials = new PropertiesCredentials(AwsEc2ListVolumes.class.getResourceAsStream("/AwsCredentials.properties"));
    AmazonEC2 ec2 = new AmazonEC2Client(credentials);
 
    DescribeVolumesResult volReq = ec2.describeVolumes();
 
    int count = 1;
    for (Volume vol : volReq.getVolumes())
    {
      System.out.println("Volume " + count   + "\n Details: " + vol);
      count++;
    }
  }
}

The output will be something as follows:

Amazon Web Service Java SDK Tutorial: Create New Virtual Machine

March 2nd, 2016 No comments

In my previous post, I showed a sample on how to list virtual machine instances. While that is helpful, maybe even more so is to create a new virtual machine. Here comes another sample that creates new virtual machine instance using the Amazon Java SDK.

Amazon Web Service Java SDK Tutorial: Simplest Hello World

February 17th, 2016 2 comments

I looked at Amazon Web Services SDK a while back and started to work with it recently. While searching it the Internet, I got all the results on the first two pages on Google pointing back to Amazon, which is great. After reading these documents, however, I got headaches. Why? For one thing, they are pretty long and sometimes run over different Web pages. Do you want to read for an hour to get your first program running? Or you are like me who would like to get my first program like Hello World to run in 5 minutes or even shorter. We should then read more if we don’t understand some parts. If you have gone through the Amazon documents, you’d know it’s impossible.

Cisco UCS Director REST APIs: Step By Step Tutorial

March 10th, 2014 7 comments

As I introduced in last article, there are two sets of APIs in UCS Director: north bound APIs, and south bound APIs. The north bound APIs are REST styled, allowing other applications to invoke UCS Director functionalities, or simply retrieve information from UCS Director. We’ll go through the REST APIs in details so that you can quickly get started with it.

Preparation

Setting Up vSphere Web Client SDK: A Few Mistakes to Avoid

December 10th, 2013 5 comments

With the vSphere Web Client, VMware has really made the system complicated and slower. The extension mechanism is more flexible, but forces developers to use more libraries/frameworks/languages, therefore represents a much deeper learning curve than before with the Web based plugins. Installing and configuring the development environment itself could be intimidating for some developers. That is why I wanted to avoid it as long as possible, until I got a consulting project that may involve developing plugin for the Web Client.

vSphere SDK Compatibility

February 21st, 2011 No comments

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

What Makes A Platform Stick?

February 23rd, 2010 No comments

Inspired by the book Made to Stick – Why do some ideas thrive while others die? by Heath brothers, I would like to give it a try on software platforms rather than the ideas covered in the book. Although the computer industry is still relatively young compared with other industries, it’s quite dynamic and we’ve seen some platforms came and died while others came and thrive. So, what are the general characteristics for such sticky platforms?

The authors of the book summarized the 6 principals to make ideas stick, meaning the ideas change either the thoughts or/and behaviors of the receivers. These principals are Simplicity, Unexpectedness, Credibility, Concreteness, Emotions, and Stories. They are shortened to SUCCESs for easy memory.

Most of these principals don’t apply on software platforms. Unexpectedness, for example, may be the last thing you would like to see of a software platform. For software platform, we definitely need predictability, among other qualities.

After thinking the problem over, I summarized 4 basic principles for a software platform to stick: Simplicity, Extensibility, Ecosystem, and Developers, in short SEED.

Automatically Generate Your Java Code With Onyx?

February 6th, 2010 2 comments

During last Friday VMware beer bash, I bumped into Carter Shanklin. He told me he’s ready show off how his Onyx project can help Java developers using VI Java API at Partner Exchange next week in Las Vegas. If you will be there, be sure to attend his session TEXIBP1007 – also known as “Getting Stoned with ‘Project Onyx’” on Thursday at 11:30.

Common Mistakes Using VMware VI and vSphere SDK

January 31st, 2010 2 comments

I posted two blogs on the top 10 best practices of using the vSphere SDK (part 1, part 2) two days ago. Here is a list of several common mistakes developers make during their development. It’s based on the stats from our SDK support team.

  1. Defining wrong interval information in PerfQuerySpec
  2. Using same unit number for each device attached to a controller
  3. Mistakes in defining the TraversalSpec
  4. Using case sensitive DNS names or IP address