One of the key new features in vSphere 5.1 is the Single Sign On. Because it’s new and also complicated, I’ve heard it’s not easy to get it right the first time. Experts recommend that you should play with it in a test or staging environment before upgrading your production environment.
I got an interesting question on how to find out WSDL files are used by vSphere Web Services at the VI Java API forum. After some clarification, it turns out the questioner just wanted to know what methods are called, so that the proxy between client and vCenter server can decide whether it should be allowed to go through.
Although a rare use case, but it’s a valid and sophisticated one. In general, you can use vSphere built in feature for security, for example,
If you have paid close attention to the SOAP messages recorded by Oynx, you may have noticed that there is an extra attribute called “serverGuid” in a ManagedObjectReference. The following is copied from my previous posting “Moving Virtual Machine to Distributed Virtual Switch”.
<_this xsi:type=”ManagedObjectReference” type=”VirtualMachine” serverGuid=”BA9CE658-75F7-4A99-ACE6-99EB1376B94A”>vm-134</_this>
Note that this SOAP request message is from a vSphere Client. In VIJava API or other language binding, there is no such an attribute. You may wonder,
As a software professional, you may have heard about the source compatibility and binary compatibility. With the Web Services, a new type of compatibility came up. This is what I call wire compatibility. It’s not related to the programming but the XML messages passed on the wire. Since we don’t use XML directly but programming APIs, the wire compatibility surfaces and affects the source and binary compatibility.
Too abstract? You bet. Let’s pick up an example here. Because VMware vSphere API is defined in WSDL, I will use it in the following discussion.
In vSphere 4.1, the method PowerOnMultiVM_Task() gets an additional parameter called option typed as OptionValue array. The following are related parts in the WSDL:
<operation name="PowerOnMultiVM_Task"> <input message="vim25:PowerOnMultiVM_TaskRequestMsg" /> <output message="vim25:PowerOnMultiVM_TaskResponseMsg" /> <fault name="RuntimeFault" message="vim25:RuntimeFaultFaultMsg"/> </operation> <complexType name="PowerOnMultiVMRequestType"> <sequence> <element name="_this" type="vim25:ManagedObjectReference" /> <element name="vm" type="vim25:ManagedObjectReference" maxOccurs="unbounded" /> <element name="option" type="vim25:OptionValue" minOccurs="0" maxOccurs="unbounded" /> </sequence> </complexType>
As you can see, the minOccurs of the option element is zero, meaning it’s optional. If you have an application built with 4.0 (no option parameter by then), the SOAP request still works. So it’s compatible on the wire.
To your surprises, there are two types of sessions involved in vSphere SDK:
- HTTP Session. It’s used to identify a client and tracked by the cookie in HTTP header. Once you login the server, all the successive requests have to carry the cookie header similar as follows
- User Session. It’s used to identify a login session of a particular user. You can use SessionManager to find out more the details of the current user and other login users from the UserSession data object. The key in the UserSession is in the same format as the HTTP session, but you should never confuse them, or use them interchangeably.
As mentioned in previous blog, REST is a style than a systematic way defining distributed interfaces. Given how it’s used today, there is a big gap between how it’s used and sophisticated software system development.
The gap between REST and OO
REST or SOAP?
REST is acronym for Representational state transfer (REST). It is a software architecture style for distributed computing system such as Web.
For whatever reason, it got so popular today that many people equals the future of Web Services to REST. It’s true that REST based API is easy to understand with simple HTTP request/response messages in XML format. You can get some work done using text editor plus web browser.