You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by David Nalley <da...@gnsa.us> on 2012/07/31 04:04:10 UTC
vijava - some additional thoughts
Hi folks,
I know I keep beating this drum until it sounds absurd, but I
discovered this blog post [1] today which reinforces to me that vijava
might be a suitable alternative for the VMware SDK, and as a bonus
gets rid of the proprietary licensing that the VMware SDK brings along
with it. Obviously this would require some rework, and probably isn't
a good candidate for any imminent upcoming release, but, for a release
or two out, it might be reasonable.
--David
[1] http://www.doublecloud.org/2010/10/netapp-and-brocade-opt-for-vi-java-api/
Re: vijava - some additional thoughts
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday, July 31, 2012 03:02:50 PM David Nalley wrote:
> On Tue, Jul 31, 2012 at 2:26 PM, Kelven Yang <ke...@citrix.com>
wrote:
> > 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:
>
> https://issues.apache.org/jira/browse/LEGAL-137
>
> 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
WSDL's.
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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: vijava - some additional thoughts
Posted by David Nalley <da...@gnsa.us>.
On Tue, Jul 31, 2012 at 2:26 PM, Kelven Yang <ke...@citrix.com> wrote:
> 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:
https://issues.apache.org/jira/browse/LEGAL-137
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?
--David
Re: vijava - some additional thoughts
Posted by Kelven Yang <ke...@citrix.com>.
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" <ch...@sungard.com> wrote:
>On Mon, Jul 30, 2012 at 10:59 PM, Adrian Cole <ad...@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
Re: vijava - some additional thoughts
Posted by Chip Childers <ch...@sungard.com>.
On Mon, Jul 30, 2012 at 10:59 PM, Adrian Cole <ad...@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
Re: vijava - some additional thoughts
Posted by Adrian Cole <ad...@gmail.com>.
I've not found an alternate OSS java library for vsphere except vijava. It
definitely is in wide use, despite lack of unit tests and sensible
logging. Wins by default and also historically good support from Steve Jin.
-A
On Jul 30, 2012 7:29 PM, "Chip Childers" <ch...@sungard.com> wrote:
> David,
>
> I can vouch for vi java. It's a much more rational API for VMware
> integration than the native SDK, and we can always ask the author
> (Steve Jin) for support if we need it. He's a great guy, and really
> does a good job with that project. We use the library here at SunGard
> almost exclusively when coding VMware integrations.
>
> The license is BSD, so that should work for us. It does drag in the
> dom4j library as well, but that's BSD licensed too.
>
> I'd be happy to represent this project in any discussion with Steve...
> He and I know each other at least a little bit.
>
> -chip
>
> [1] - http://vijava.svn.sourceforge.net/viewvc/vijava/trunk/License.txt
>
> On Mon, Jul 30, 2012 at 10:04 PM, David Nalley <da...@gnsa.us> wrote:
> > Hi folks,
> >
> > I know I keep beating this drum until it sounds absurd, but I
> > discovered this blog post [1] today which reinforces to me that vijava
> > might be a suitable alternative for the VMware SDK, and as a bonus
> > gets rid of the proprietary licensing that the VMware SDK brings along
> > with it. Obviously this would require some rework, and probably isn't
> > a good candidate for any imminent upcoming release, but, for a release
> > or two out, it might be reasonable.
> >
> > --David
> >
> >
> > [1]
> http://www.doublecloud.org/2010/10/netapp-and-brocade-opt-for-vi-java-api/
> >
>
Re: vijava - some additional thoughts
Posted by Chip Childers <ch...@sungard.com>.
David,
I can vouch for vi java. It's a much more rational API for VMware
integration than the native SDK, and we can always ask the author
(Steve Jin) for support if we need it. He's a great guy, and really
does a good job with that project. We use the library here at SunGard
almost exclusively when coding VMware integrations.
The license is BSD, so that should work for us. It does drag in the
dom4j library as well, but that's BSD licensed too.
I'd be happy to represent this project in any discussion with Steve...
He and I know each other at least a little bit.
-chip
[1] - http://vijava.svn.sourceforge.net/viewvc/vijava/trunk/License.txt
On Mon, Jul 30, 2012 at 10:04 PM, David Nalley <da...@gnsa.us> wrote:
> Hi folks,
>
> I know I keep beating this drum until it sounds absurd, but I
> discovered this blog post [1] today which reinforces to me that vijava
> might be a suitable alternative for the VMware SDK, and as a bonus
> gets rid of the proprietary licensing that the VMware SDK brings along
> with it. Obviously this would require some rework, and probably isn't
> a good candidate for any imminent upcoming release, but, for a release
> or two out, it might be reasonable.
>
> --David
>
>
> [1] http://www.doublecloud.org/2010/10/netapp-and-brocade-opt-for-vi-java-api/
>