Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of kelven.yang@citrix.com
 designates 66.165.176.89 as permitted sender)
From: Kelven Yang <kelven.yang@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Date: Tue, 31 Jul 2012 11:26:05 -0700
Subject: Re: vijava - some additional thoughts
Thread-Topic: vijava - some additional thoughts
Thread-Index: Ac1vSfOJ94NKmvkeQViXDLnsyUWMHA==
Message-ID: <CC3D6EFF.4DD4%kelven.yang@citrix.com>
In-Reply-To: 
 <CA+96GG4Qdu8GAQKMBOEHPGE+bwJatCnv4r1=1n2z1OPnRcRTPg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.2.3.120616
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

I'd like to share some background information related to choice of Vmware
SDK.

Before I started Vmware integration project, both vi java and Vmware SDK
were black
boxes to me, but one thing for sure is that Vmware SDK should not have any
blockers that could mask off raw vSphere functionality. Vi java is a until
library that wraps on top of Vmware web service interface and it may not
cover 100% of full Vmware functionality
at that time. To be safe and get us quickly started, I made the choice of
using
Vmware SDK directly.

Both vi java and Vmware SDK are very thin wrapper layers on top of vSphere
web service WSDL interface, vi java does more high-level abstractions to
help application developers, but I'm not sure how much those abstractions
that we can take advantage of as we already built a similar library
(vmware-base) to serve the needs from CloudStack.

To get rid of Vmware SDK license problem, we actually have another option,
which is to  generate our java bindings directly from vSphere WSDL and
make Vmware-base library built on top of it, since vmware-base library is
at similar position of VI java, it is more natural to bind it to raw WSDL
generated files instead of on yet another abstraction layer.

The question is whether or not we have license issue of Vmware web service
WSDL?

Kelven


On 7/31/12 5:50 AM, "Chip Childers" <chip.childers@sungard.com> wrote:

>On Mon, Jul 30, 2012 at 10:59 PM, Adrian Cole <adrian.f.cole@gmail.com>
>wrote:
>> (snip) despite lack of unit tests and sensible
>> logging.  (snip)
>
>Well there are those issues... :-(
>
>As you say, there really isn't another alternative out there though.
>Beyond rolling our own (which I'm not in favor of), this is the best
>option.
>
>-chip