[one-users] Alternative java bindings

[Tiago Batista]

Thanks,

This is my first JAXB experience, so looking at someone else's code
actually helped a lot on what I am doing...

I am mostly writing stylesheets for the rpc responses, so I am still
not at the point where I want to be, my current purpose with this is
to expose most or all of the functionality to a java experienced
programmer, removing as much of the opennebula specific parlance as
possible (notice that *Pool becomes a list() as an example).

As a test application, I am exposing the methods as a web service
(opennebula specific), something like a soap interface for the rpc...
If there is interest, I think I can release the full app (have to ask
my superiors)...

As for the rpc responses, I have found a few inconsistencies, mostly
between the *.info and the *pool.info methods that are slowing me down
a bit as I have to account for them... Is this expected behavior or a
bug?

As an example note the USERNAME:

    <xs:complexType name="vmType">
        <xs:sequence>
            <xs:element name="ID" type="xs:int" />
            <xs:element name="UID" type="xs:int" />
            <xs:element name="USERNAME" type="xs:string" minOccurs="0"
/> <!-- only on the pool -->
            <xs:element name="NAME" type="xs:string" />
            <xs:element name="LAST_POLL" type="xs:unsignedLong" />
            <xs:element name="STATE" type="xs:string" />
            <xs:element name="LCM_STATE" type="xs:string" />
            <xs:element name="STIME" type="xs:unsignedLong" />
            <xs:element name="ETIME" type="xs:unsignedLong" />
            <xs:element name="DEPLOY_ID" type="xs:string" />
            <xs:element name="MEMORY" type="xs:unsignedLong" />
            <xs:element name="CPU" type="xs:unsignedLong" />
            <xs:element name="NET_TX" type="xs:unsignedLong" />
            <xs:element name="NET_RX" type="xs:unsignedLong" />
            <xs:element name="LAST_SEQ" type="xs:unsignedLong" />

            <xs:element name="TEMPLATE" type="vmTemplateType" minOccurs="0"/>
            <xs:element name="HISTORY" type="vmHistoryType" minOccurs="0"/>
        </xs:sequence>
    </xs:complexType>


The username appears only in the pool method, but not on the info
method... The same is valid for vnet methods if I recall.

Again, thanks for your input!

Tiago

On Thu, Oct 7, 2010 at 11:46 PM,  <Carsten.Friedrich at csiro.au> wrote:
> Hi Tiago,
>
>
>
> I did something similar some time ago (attached for your perusal, you need
> to add the JAXB libraries yourself). The binding of returned templates is a
> bit patchy, but it works well enough for me here. It supports most 2.0
> features.
>
>
>
> Carsten
>
>
>
> From: users-bounces at lists.opennebula.org
> [mailto:users-bounces at lists.opennebula.org] On Behalf Of Tiago Batista
> Sent: Thursday, 7 October 2010 21:06
> To: Users at lists.opennebula.org
> Subject: [one-users] Alternative java bindings
>
>
>
> I am in the process of creating alternative java bindings for OpenNebula.
> (Dont ask and I wont tell why!)
>
> They are now at a very embrionary state, and I would like to expose them a
> little. There are some parts that are specific to my setup, and a lot of
> refactoring is required but most of the code is automatically generated.
>
> I use JAXB to bind the xmlrpc responses to POJOs, and I use a catchall class
> to perform the required operations on the server. A usage example:
>
> Client client = new Client("username", "password",
> "http://hostname:2633/RPC2");
> VMOperations vmOps = new VMOperations(client);
> VmType vm = vmOps.info(id);
>
> This way, adding features is as simple as editing the apropriate xsd. By the
> way, extensions to the existing xsd, or new xsd files are welcome! With a
> little refactoring I think I can wrap the VmType that is read only on a
> class that allows some operations to be performed over it...
>
> Also, this is better for environments where the data must be used across a
> network, as the classes (although not marked as such) should face no
> serialization problems. Even is none of the code seems useful, you should
> really consider replacing the standard Client class with a serializable one!
>
> What do you think of this?