cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: vijava - some additional thoughts
Date Tue, 31 Jul 2012 19:11:17 GMT
On Tuesday, July 31, 2012 03:02:50 PM David Nalley wrote:
> On Tue, Jul 31, 2012 at 2:26 PM, Kelven Yang <> 
> > 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
> So this question came up (or was decided) since we've been in the
> incubator. Namely:
> I don't personally take that as blanket permission, and it probably
> means asking legal@ (there were several caveats that Sam called out)
> might be a good idea. Any mentor want to weigh in on that?

I was just trying to do some research based on that exact JIRA.  This 
situation is a bit different though.  In that particular JIRA, the WSDL is 
machine generated output from the .NET framework whereas the VMWare WSDL's 
are not (I think).  Thus, there is more copyrightable material in the VMWare 

I haven't looked at the license for the VMWare SDK WSDL's so I don't know 
what is there.    My gut feeling is that we wouldn't be able to redistribute 
it and thus not allowed to be in the repo.   However, you may be able to run 
something like CXF's wsdl2java on it (or wsimport as part of JDK6+) and 
commit the generated code.   With the recent google ruling of the raw API 
names not being copyrightable, I don't think there would be any problems 
with copyright with just having the generated code in the repository.

Runtime could be an issue though.   The JAX-WS impl in the JDK requires a 
WSDL at runtime for the clients.   You may be able to point them at the 
running service with the ?wsdl and that  may be fine.   Not really sure.   
CXF doesn't require it so that could be another option as well.

Daniel Kulp -
Talend Community Coder -

View raw message