Good to know, thanks! ----- Original Message -----

From: "Christopher Morrissey" <Christopher.Morrissey@netapp.com> To: "Keith Robertson" <kroberts@redhat.com>, "Libor Spevak" <lspevak@redhat.com> Cc: engine-devel@ovirt.org Sent: Tuesday, February 12, 2013 5:53:52 PM Subject: RE: [Engine-devel] REST API calls from the GUI

The UI plugin framework already makes a session ID available for REST API calls. Oved's blog gives a good description with some example code.

http://ovedou.blogspot.co.il/2012/12/ovirt-foreman-ui-plugin.html

-Chris

...

-----Original Message----- From: engine-devel-bounces@ovirt.org [mailto:engine-devel- bounces@ovirt.org] On Behalf Of Keith Robertson Sent: Tuesday, February 12, 2013 11:30 AM To: Libor Spevak Cc: engine-devel@ovirt.org Subject: Re: [Engine-devel] REST API calls from the GUI

Not sure if this is possible now but, I would like the front-end to expose an authenticated hook to the API so that plug-ins can call RESTful methods. It would enable plug-in writers to do all sorts of interesting things in their plug- ins with the RESTful API.

Cheers, Keith

On 02/12/2013 11:13 AM, Libor Spevak wrote:

...

Hi,

I would like to ask, if there have been discussions about an option to call REST API services directly from the Frontend (GWT layer)? GWT compiles Java frontend-side to Javascript, calls to backend services are performed "transparently" by the framework using AJAX support. But, there is still a need to have a special set of data objects and the server-side logic can duplicate.

Java REST API SDK enables to build "thick" client. The calls are realized using e.g. Apache HttClient and supported libraries. I think the requirements of GWT can be a little bit different, but something overlaps.

I found several links about REST API support from GWT, so there is something for inspiration...

- http://www.spiffyui.org/ - http://www.zackgrossbart.com/hackito/gwt-rest/ - http://code.google.com/p/gwt-rest/ - http://restygwt.fusesource.org/

But, do you think it would be useful and what drawbacks can occur (authentication, authorization, response times, need to support larger set of services, painful refactoring, ...)?

Regards, Libor

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

On 15/02/2013 20:11, Vojtech Szocs wrote:

Hi Libor,

...

I would like to ask, if there have been discussions about an option to call REST API services directly from the Frontend (GWT layer)? GWT compiles Java frontend-side to Javascript, calls to backend services are performed "transparently" by the framework using AJAX support. But, there is still a need to have a special set of data objects and the server-side logic can duplicate.

Indeed, for both WebAdmin and UserPortal, we're planning to move away from GWT RPC (a.k.a Generic API) and use Engine REST API and promote loose coupling between client and server.

As Chris mentioned, for WebAdmin UI plugins, there's already support for calling Engine REST API - session ID is obtained upon WebAdmin UI login and passed to all UI plugins. It's up to plugin authors to decide if the plugin itself (JavaScript) will communicate via REST API, or if the plugin passes the session ID to some other server so that the other server does REST API communication.

...

Java REST API SDK enables to build "thick" client. The calls are realized using e.g. Apache HttClient and supported libraries. I think the requirements of GWT can be a little bit different, but something overlaps.

Well, we can't really use Java REST API SDK directly due to restrictions imposed by GWT on client-side code, e.g. HttClient uses sockets which are (obviously) not supported in JavaScript and therefore related classes are rejected by GWT compiler.

What we're planning to do is to map REST API XML responses to generated "REST API Types" (based on api.xsd schema) and vice versa. This could be a bit of challenge, as most frameworks for GWT REST API support use JSON representation in favor of XML.

JSON is also more efficient than XML, but will take a bit of time until supported by the REST API.

Vojtech

----- Original Message ----- From: "Christopher Morrissey" <Christopher.Morrissey@netapp.com> To: "Keith Robertson" <kroberts@redhat.com>, "Libor Spevak" <lspevak@redhat.com> Cc: engine-devel@ovirt.org Sent: Tuesday, February 12, 2013 11:53:52 PM Subject: Re: [Engine-devel] REST API calls from the GUI

The UI plugin framework already makes a session ID available for REST API calls. Oved's blog gives a good description with some example code.

http://ovedou.blogspot.co.il/2012/12/ovirt-foreman-ui-plugin.html

-Chris

...

-----Original Message----- From: engine-devel-bounces@ovirt.org [mailto:engine-devel- bounces@ovirt.org] On Behalf Of Keith Robertson Sent: Tuesday, February 12, 2013 11:30 AM To: Libor Spevak Cc: engine-devel@ovirt.org Subject: Re: [Engine-devel] REST API calls from the GUI

Not sure if this is possible now but, I would like the front-end to expose an authenticated hook to the API so that plug-ins can call RESTful methods. It would enable plug-in writers to do all sorts of interesting things in their plug- ins with the RESTful API.

Cheers, Keith

On 02/12/2013 11:13 AM, Libor Spevak wrote:

...

Hi,

I would like to ask, if there have been discussions about an option to call REST API services directly from the Frontend (GWT layer)? GWT compiles Java frontend-side to Javascript, calls to backend services are performed "transparently" by the framework using AJAX support. But, there is still a need to have a special set of data objects and the server-side logic can duplicate.

Java REST API SDK enables to build "thick" client. The calls are realized using e.g. Apache HttClient and supported libraries. I think the requirements of GWT can be a little bit different, but something overlaps.

I found several links about REST API support from GWT, so there is something for inspiration...

- http://www.spiffyui.org/ - http://www.zackgrossbart.com/hackito/gwt-rest/ - http://code.google.com/p/gwt-rest/ - http://restygwt.fusesource.org/

But, do you think it would be useful and what drawbacks can occur (authentication, authorization, response times, need to support larger set of services, painful refactoring, ...)?

Regards, Libor

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

---

Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

On 02/14/2013 11:20 AM, Doron Fediuck wrote:

----- Original Message -----

...

From: "Michael Pasternak" <mpastern@redhat.com> To: "Libor Spevak" <lspevak@redhat.com> Cc: engine-devel@ovirt.org, arch@ovirt.org Sent: Wednesday, February 13, 2013 12:55:36 PM Subject: Re: [Engine-devel] REST API calls from the GUI

Hi Libor,

This issue came across in one of the conversations i had with UX folks, but since we didn't end up with any conclusion/road map (nor discussed it properly to hear other thoughts), this is a perfect place to start this discussion,

Intuitively REST is a way to go with GWT AJAX calls ---------------------------------------------------

pros ====

- api data objects can be reused by generating java classes (using jaxb) from the rest schema [1] - no backend logic will be duplicated as api abstracts the backend exposing RESTful collection/resources to operate on - development against api is "easy" as api describes itself in RSDL [2]

cons ====

- implementing transport layer (HTTP) under GWT - implementing own j2xml/json/yaml/... marshalling layer - implementing own error handling mechanism - implementing REST callback mechanism (in GWT) - constant maintenance of the data objects generated from the api - painful for Java developers

Java-SDK --------

pros ====

- abstracts transport layer (leaving developer in standard Java api) - typesafe code (no need to mess with XML bulks) - has own data objects to work with - abstracts authentication/authorization (kerberos/cookie/session/etc.) - since SDK is auto-generated, it can be easily extended with required features to support UI (such as callback infrastructure for instance)

cons ====

- has to be converted in to Javascript (not sure what the impacts are in terms of AJAX calls/etc.) - probably much more cons that we're not aware of and will have to figure out with POC

thoughts?

[1] http[s]://server[:port]/api?schema [2] http[s]://server[:port]/api?rsdl

Although started as a UI request, there are other needs who wish to use API calls with a different transport. For example a backend hook which gets a REST entry point it can use to fetch for additional data, or perform actions. In this case I'd expect an internal connection rather than creating additional connections. How would you resolve it generically enough in this context?

Doron, I believe your approach a bit different, UX folks seeking for a convenient way of communicating with ovirt public api, e.g closing api<->GUI gap, and theirs alternatives where native HTTP layer or Java-SDK based framework, while what you need is in-process channel to communicate with the engine itself, i understanding your will of using stable api for this (RESTapi), but not sure that doing this via JavaSDK is a good way to go simply because SDK is designed to operate in a client-space, while what you need is a server-space bridge for that.

...

On 02/12/2013 06:13 PM, Libor Spevak wrote:

...

Hi,

I would like to ask, if there have been discussions about an option to call REST API services directly from the Frontend (GWT layer)? GWT compiles Java frontend-side to Javascript, calls to backend services are performed "transparently" by the framework using AJAX support. But, there is still a need to have a special set of data objects and the server-side logic can duplicate.

Java REST API SDK enables to build "thick" client. The calls are realized using e.g. Apache HttClient and supported libraries. I think the requirements of GWT can be a little bit different, but something overlaps.

I found several links about REST API support from GWT, so there is something for inspiration...

- http://www.spiffyui.org/ - http://www.zackgrossbart.com/hackito/gwt-rest/ - http://code.google.com/p/gwt-rest/ - http://restygwt.fusesource.org/

But, do you think it would be useful and what drawbacks can occur (authentication, authorization, response times, need to support larger set of services, painful refactoring, ...)?

Regards, Libor

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

--

Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Arch mailing list Arch@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch

-- Michael Pasternak RedHat, ENG-Virtualization R&D

----- Original Message -----

From: "Doron Fediuck" <dfediuck@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: engine-devel@ovirt.org, arch@ovirt.org Sent: Thursday, February 21, 2013 6:54:59 PM Subject: Re: [Engine-devel] REST API calls from

----- Original Message -----

...

From: "Michael Pasternak" <mpastern@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: engine-devel@ovirt.org, arch@ovirt.org Sent: Wednesday, February 20, 2013 2:56:59 PM Subject: Re: [Engine-devel] REST API calls from

On 02/14/2013 11:20 AM, Doron Fediuck wrote:

...

----- Original Message -----

...

From: "Michael Pasternak" <mpastern@redhat.com> To: "Libor Spevak" <lspevak@redhat.com> Cc: engine-devel@ovirt.org, arch@ovirt.org Sent: Wednesday, February 13, 2013 12:55:36 PM Subject: Re: [Engine-devel] REST API calls from the GUI

Hi Libor,

This issue came across in one of the conversations i had with UX folks, but since we didn't end up with any conclusion/road map (nor discussed it properly to hear other thoughts), this is a perfect place to start this discussion,

Intuitively REST is a way to go with GWT AJAX calls ---------------------------------------------------

pros ====

- api data objects can be reused by generating java classes (using jaxb) from the rest schema [1] - no backend logic will be duplicated as api abstracts the backend exposing RESTful collection/resources to operate on - development against api is "easy" as api describes itself in RSDL [2]

cons ====

- implementing transport layer (HTTP) under GWT - implementing own j2xml/json/yaml/... marshalling layer - implementing own error handling mechanism - implementing REST callback mechanism (in GWT) - constant maintenance of the data objects generated from the api - painful for Java developers

Java-SDK --------

pros ====

- abstracts transport layer (leaving developer in standard Java api) - typesafe code (no need to mess with XML bulks) - has own data objects to work with - abstracts authentication/authorization (kerberos/cookie/session/etc.) - since SDK is auto-generated, it can be easily extended with required features to support UI (such as callback infrastructure for instance)

cons ====

- has to be converted in to Javascript (not sure what the impacts are in terms of AJAX calls/etc.) - probably much more cons that we're not aware of and will have to figure out with POC

thoughts?

[1] http[s]://server[:port]/api?schema [2] http[s]://server[:port]/api?rsdl

Although started as a UI request, there are other needs who wish to use API calls with a different transport. For example a backend hook which gets a REST entry point it can use to fetch for additional data, or perform actions. In this case I'd expect an internal connection rather than creating additional connections. How would you resolve it generically enough in this context?

Doron,

I believe your approach a bit different, UX folks seeking for a convenient way of communicating with ovirt public api, e.g closing api<->GUI gap, and theirs alternatives where native HTTP layer or Java-SDK based framework, while what you need is in-process channel to communicate with the engine itself,

i understanding your will of using stable api for this (RESTapi), but not sure that doing this via JavaSDK is a good way to go simply because SDK is designed to operate in a client-space, while what you need is a server-space bridge for that.

Michael, true but... Thinking about it differently both UI and hooks needs a client. The underlying protocols should be abstracted. This is something which will serve other functions as well.

I'm not sure we would need a new abstraction here. Both UI plugins and engine plugins need some API to do basic operations, and have access to different properties in the engine. In the UI plguins implementation, we gave this API, and in addition created a REST session to be used in order to do more sophisticated operations. I think we should probably do the same for engine plugins, giving the basic API, and giving a REST session for more advanced operations. The engine plugin may also have another 3rd party application it interacts with, and it would be able to share this session with it, allowing it to perform different operations on the engine. It would obviously be easy to do that using the Java SDK in the engine side, without creating a new layer of abstraction. I assume the 3rd party application will use either the Java SDK, or another one, according the platform it is built upon, and in the "worst case", will interact directly with the API.

...

...

...

On 02/12/2013 06:13 PM, Libor Spevak wrote:

...

Hi,

I would like to ask, if there have been discussions about an option to call REST API services directly from the Frontend (GWT layer)? GWT compiles Java frontend-side to Javascript, calls to backend services are performed "transparently" by the framework using AJAX support. But, there is still a need to have a special set of data objects and the server-side logic can duplicate.

Java REST API SDK enables to build "thick" client. The calls are realized using e.g. Apache HttClient and supported libraries. I think the requirements of GWT can be a little bit different, but something overlaps.

I found several links about REST API support from GWT, so there is something for inspiration...

- http://www.spiffyui.org/ - http://www.zackgrossbart.com/hackito/gwt-rest/ - http://code.google.com/p/gwt-rest/ - http://restygwt.fusesource.org/

But, do you think it would be useful and what drawbacks can occur (authentication, authorization, response times, need to support larger set of services, painful refactoring, ...)?

Regards, Libor

---

Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

----- Original Message -----

From: "Michael Pasternak" <mpastern@redhat.com> To: "Oved Ourfalli" <ovedo@redhat.com> Cc: engine-devel@ovirt.org, arch@ovirt.org Sent: Sunday, February 24, 2013 9:47:28 AM Subject: Re: [Engine-devel] REST API calls from

On 02/24/2013 09:05 AM, Oved Ourfalli wrote:

...

----- Original Message -----

...

From: "Doron Fediuck" <dfediuck@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: engine-devel@ovirt.org, arch@ovirt.org Sent: Thursday, February 21, 2013 6:54:59 PM Subject: Re: [Engine-devel] REST API calls from

----- Original Message -----

...

From: "Michael Pasternak" <mpastern@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: engine-devel@ovirt.org, arch@ovirt.org Sent: Wednesday, February 20, 2013 2:56:59 PM Subject: Re: [Engine-devel] REST API calls from

On 02/14/2013 11:20 AM, Doron Fediuck wrote:

...

----- Original Message -----

...

From: "Michael Pasternak" <mpastern@redhat.com> To: "Libor Spevak" <lspevak@redhat.com> Cc: engine-devel@ovirt.org, arch@ovirt.org Sent: Wednesday, February 13, 2013 12:55:36 PM Subject: Re: [Engine-devel] REST API calls from the GUI

Hi Libor,

This issue came across in one of the conversations i had with UX folks, but since we didn't end up with any conclusion/road map (nor discussed it properly to hear other thoughts), this is a perfect place to start this discussion,

Intuitively REST is a way to go with GWT AJAX calls ---------------------------------------------------

pros ====

- api data objects can be reused by generating java classes (using jaxb) from the rest schema [1] - no backend logic will be duplicated as api abstracts the backend exposing RESTful collection/resources to operate on - development against api is "easy" as api describes itself in RSDL [2]

cons ====

- implementing transport layer (HTTP) under GWT - implementing own j2xml/json/yaml/... marshalling layer - implementing own error handling mechanism - implementing REST callback mechanism (in GWT) - constant maintenance of the data objects generated from the api - painful for Java developers

Java-SDK --------

pros ====

- abstracts transport layer (leaving developer in standard Java api) - typesafe code (no need to mess with XML bulks) - has own data objects to work with - abstracts authentication/authorization (kerberos/cookie/session/etc.) - since SDK is auto-generated, it can be easily extended with required features to support UI (such as callback infrastructure for instance)

cons ====

- has to be converted in to Javascript (not sure what the impacts are in terms of AJAX calls/etc.) - probably much more cons that we're not aware of and will have to figure out with POC

thoughts?

[1] http[s]://server[:port]/api?schema [2] http[s]://server[:port]/api?rsdl

Although started as a UI request, there are other needs who wish to use API calls with a different transport. For example a backend hook which gets a REST entry point it can use to fetch for additional data, or perform actions. In this case I'd expect an internal connection rather than creating additional connections. How would you resolve it generically enough in this context?

Doron,

I believe your approach a bit different, UX folks seeking for a convenient way of communicating with ovirt public api, e.g closing api<->GUI gap, and theirs alternatives where native HTTP layer or Java-SDK based framework, while what you need is in-process channel to communicate with the engine itself,

i understanding your will of using stable api for this (RESTapi), but not sure that doing this via JavaSDK is a good way to go simply because SDK is designed to operate in a client-space, while what you need is a server-space bridge for that.

Michael, true but... Thinking about it differently both UI and hooks needs a client. The underlying protocols should be abstracted. This is something which will serve other functions as well.

I'm not sure we would need a new abstraction here. Both UI plugins and engine plugins need some API to do basic operations, and have access to different properties in the engine.

+1, that's exactly what i've suggested to begin with.

The only issue is that UI plugins and engine plugins shave different expectations from performance point of view. If UI is willing to wait for a refresh that may take too long for engine plugins, which would prefer to get the information as soon as possible without going into various communication layers which are not always needed. So again- a simple solution which enables transports layers to be replaced may serve more than one functionality in a better way.

...

In the UI plguins implementation, we gave this API, and in addition created a REST session to be used in order to do more sophisticated operations. I think we should probably do the same for engine plugins, giving the basic API, and giving a REST session for more advanced operations. The engine plugin may also have another 3rd party application it interacts with, and it would be able to share this session with it, allowing it to perform different operations on the engine. It would obviously be easy to do that using the Java SDK in the engine side, without creating a new layer of abstraction.

true, but the thing is that java-sdk designed to work with rest-api, and what Doron is trying to do is saving round-trip of engine->sdk->api->engine by enabling extra layer in sdk that will work not via HTTP, but natively with RESTeasy (REST framework we using in api), the disadvantages of such design are:

1. working with java-sdk via JNI (walking out from container to client application - sdk) 2. hacking RESTeasy by: 2.1 working with underlying (not public/backward compatible) interfaces & using JNI as well 2.2 most likely maintaining code working with RESTeasy on every new (RESTeasy) release by reverse engineering new changes/behaviour of this framework 2.3 making assumptions on code invocations to emulate GET/POST/PUT/DELETE HTTP calls 2.4 still having round-trip engine->sdk->RESTeasy->engine

therefore i think that having own private API in engine for that is a much better solution.

...

I assume the 3rd party application will use either the Java SDK, or another one, according the platform it is built upon, and in the "worst case", will interact directly with the API.

...

...

...

...

On 02/12/2013 06:13 PM, Libor Spevak wrote: > Hi, > > I would like to ask, if there have been discussions about an > option > to call REST API services directly from the Frontend (GWT > layer)? > GWT compiles Java frontend-side to > Javascript, calls to backend services are performed > "transparently" > by the framework using AJAX support. But, there is still a > need > to > have a special set of data objects > and the server-side logic can duplicate. > > Java REST API SDK enables to build "thick" client. The calls > are > realized using e.g. Apache HttClient and supported libraries. > I > think the requirements of GWT can be a > little bit different, but something overlaps. > > I found several links about REST API support from GWT, so > there > is > something for inspiration... > > - http://www.spiffyui.org/ > - http://www.zackgrossbart.com/hackito/gwt-rest/ > - http://code.google.com/p/gwt-rest/ > - http://restygwt.fusesource.org/ > > But, do you think it would be useful and what drawbacks can > occur > (authentication, authorization, response times, need to > support > larger set of services, painful > refactoring, ...)? > > Regards, > Libor >

---

Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

--

Michael Pasternak RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

----- Original Message -----

From: "Oved Ourfalli" <ovedo@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: engine-devel@ovirt.org, arch@ovirt.org Sent: Sunday, February 24, 2013 3:01:19 PM Subject: Re: [Engine-devel] REST API calls from

----- Original Message -----

...

From: "Doron Fediuck" <dfediuck@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: "Oved Ourfalli" <ovedo@redhat.com>, engine-devel@ovirt.org, arch@ovirt.org Sent: Sunday, February 24, 2013 1:20:12 PM Subject: Re: [Engine-devel] REST API calls from

----- Original Message -----

...

From: "Michael Pasternak" <mpastern@redhat.com> To: "Oved Ourfalli" <ovedo@redhat.com> Cc: engine-devel@ovirt.org, arch@ovirt.org Sent: Sunday, February 24, 2013 9:47:28 AM Subject: Re: [Engine-devel] REST API calls from

On 02/24/2013 09:05 AM, Oved Ourfalli wrote:

...

----- Original Message -----

...

From: "Doron Fediuck" <dfediuck@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: engine-devel@ovirt.org, arch@ovirt.org Sent: Thursday, February 21, 2013 6:54:59 PM Subject: Re: [Engine-devel] REST API calls from

----- Original Message -----

...

From: "Michael Pasternak" <mpastern@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: engine-devel@ovirt.org, arch@ovirt.org Sent: Wednesday, February 20, 2013 2:56:59 PM Subject: Re: [Engine-devel] REST API calls from

On 02/14/2013 11:20 AM, Doron Fediuck wrote: > > > ----- Original Message ----- >> From: "Michael Pasternak" <mpastern@redhat.com> >> To: "Libor Spevak" <lspevak@redhat.com> >> Cc: engine-devel@ovirt.org, arch@ovirt.org >> Sent: Wednesday, February 13, 2013 12:55:36 PM >> Subject: Re: [Engine-devel] REST API calls from the GUI >> >> >> Hi Libor, >> >> This issue came across in one of the conversations i had >> with >> UX >> folks, but since we didn't end >> up with any conclusion/road map (nor discussed it properly >> to >> hear >> other thoughts), this is a perfect >> place to start this discussion, >> >> Intuitively REST is a way to go with GWT AJAX calls >> --------------------------------------------------- >> >> pros >> ==== >> >> - api data objects can be reused by generating java classes >> (using >> jaxb) from the rest schema [1] >> - no backend logic will be duplicated as api abstracts the >> backend >> exposing RESTful collection/resources to operate on >> - development against api is "easy" as api describes itself >> in >> RSDL >> [2] >> >> cons >> ==== >> >> - implementing transport layer (HTTP) under GWT >> - implementing own j2xml/json/yaml/... marshalling layer >> - implementing own error handling mechanism >> - implementing REST callback mechanism (in GWT) >> - constant maintenance of the data objects generated from >> the >> api >> - painful for Java developers >> >> Java-SDK >> -------- >> >> pros >> ==== >> >> - abstracts transport layer (leaving developer in standard >> Java >> api) >> - typesafe code (no need to mess with XML bulks) >> - has own data objects to work with >> - abstracts authentication/authorization >> (kerberos/cookie/session/etc.) >> - since SDK is auto-generated, it can be easily extended >> with >> required >> features to support UI (such as callback infrastructure >> for >> instance) >> >> cons >> ==== >> >> - has to be converted in to Javascript (not sure what the >> impacts >> are >> in terms of AJAX calls/etc.) >> - probably much more cons that we're not aware of and will >> have >> to >> figure out with POC >> >> >> thoughts? >> >> [1] http[s]://server[:port]/api?schema >> [2] http[s]://server[:port]/api?rsdl >> > > Although started as a UI request, there are other needs who > wish > to use API calls with a different transport. For example a > backend > hook which gets a REST entry point it can use to fetch for > additional > data, or perform actions. In this case I'd expect an > internal > connection > rather than creating additional connections. > How would you resolve it generically enough in this context?

Doron,

I believe your approach a bit different, UX folks seeking for a convenient way of communicating with ovirt public api, e.g closing api<->GUI gap, and theirs alternatives where native HTTP layer or Java-SDK based framework, while what you need is in-process channel to communicate with the engine itself,

i understanding your will of using stable api for this (RESTapi), but not sure that doing this via JavaSDK is a good way to go simply because SDK is designed to operate in a client-space, while what you need is a server-space bridge for that.

Michael, true but... Thinking about it differently both UI and hooks needs a client. The underlying protocols should be abstracted. This is something which will serve other functions as well.

I'm not sure we would need a new abstraction here. Both UI plugins and engine plugins need some API to do basic operations, and have access to different properties in the engine.

+1, that's exactly what i've suggested to begin with.

The only issue is that UI plugins and engine plugins shave different expectations from performance point of view. If UI is willing to wait for a refresh that may take too long for engine plugins, which would prefer to get the information as soon as possible without going into various communication layers which are not always needed. So again- a simple solution which enables transports layers to be replaced may serve more than one functionality in a better way.

Let's start with the simple solution. We don't know yet who will the plugins, how would they be used, and whether using the SDK will be a bottleneck of any kind. If the proposed solution is to support different transport layers while still using the SDK, then it is an extension we can always do in the future, if we find it of high benefit. (btw, regardless of that, the API/SDK is now faster than in the past, as we support REST sessions, which removes the need to re-authenticate upon each API request).

Oved, we have pretty good idea on how it will be used and what will create performance hits. Otherwise we wouldn't have had this thread.

...

...

...

In the UI plguins implementation, we gave this API, and in addition created a REST session to be used in order to do more sophisticated operations. I think we should probably do the same for engine plugins, giving the basic API, and giving a REST session for more advanced operations. The engine plugin may also have another 3rd party application it interacts with, and it would be able to share this session with it, allowing it to perform different operations on the engine. It would obviously be easy to do that using the Java SDK in the engine side, without creating a new layer of abstraction.

true, but the thing is that java-sdk designed to work with rest-api, and what Doron is trying to do is saving round-trip of engine->sdk->api->engine by enabling extra layer in sdk that will work not via HTTP, but natively with RESTeasy (REST framework we using in api), the disadvantages of such design are:

1. working with java-sdk via JNI (walking out from container to client application - sdk) 2. hacking RESTeasy by: 2.1 working with underlying (not public/backward compatible) interfaces & using JNI as well 2.2 most likely maintaining code working with RESTeasy on every new (RESTeasy) release by reverse engineering new changes/behaviour of this framework 2.3 making assumptions on code invocations to emulate GET/POST/PUT/DELETE HTTP calls 2.4 still having round-trip engine->sdk->RESTeasy->engine

therefore i think that having own private API in engine for that is a much better solution.

...

I assume the 3rd party application will use either the Java SDK, or another one, according the platform it is built upon, and in the "worst case", will interact directly with the API.

...

...

> >> On 02/12/2013 06:13 PM, Libor Spevak wrote: >>> Hi, >>> >>> I would like to ask, if there have been discussions about >>> an >>> option >>> to call REST API services directly from the Frontend (GWT >>> layer)? >>> GWT compiles Java frontend-side to >>> Javascript, calls to backend services are performed >>> "transparently" >>> by the framework using AJAX support. But, there is still a >>> need >>> to >>> have a special set of data objects >>> and the server-side logic can duplicate. >>> >>> Java REST API SDK enables to build "thick" client. The >>> calls >>> are >>> realized using e.g. Apache HttClient and supported >>> libraries. >>> I >>> think the requirements of GWT can be a >>> little bit different, but something overlaps. >>> >>> I found several links about REST API support from GWT, so >>> there >>> is >>> something for inspiration... >>> >>> - http://www.spiffyui.org/ >>> - http://www.zackgrossbart.com/hackito/gwt-rest/ >>> - http://code.google.com/p/gwt-rest/ >>> - http://restygwt.fusesource.org/ >>> >>> But, do you think it would be useful and what drawbacks >>> can >>> occur >>> (authentication, authorization, response times, need to >>> support >>> larger set of services, painful >>> refactoring, ...)? >>> >>> Regards, >>> Libor >>>

----- Original Message -----

From: "Oved Ourfalli" <ovedo@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: engine-devel@ovirt.org, arch@ovirt.org Sent: Sunday, February 24, 2013 11:56:49 PM Subject: Re: [Engine-devel] REST API calls from

----- Original Message -----

...

From: "Doron Fediuck" <dfediuck@redhat.com> To: "Oved Ourfalli" <ovedo@redhat.com> Cc: engine-devel@ovirt.org, arch@ovirt.org Sent: Sunday, February 24, 2013 3:55:28 PM Subject: Re: [Engine-devel] REST API calls from

----- Original Message -----

...

From: "Oved Ourfalli" <ovedo@redhat.com> To: "Doron Fediuck" <dfediuck@redhat.com> Cc: engine-devel@ovirt.org, arch@ovirt.org Sent: Sunday, February 24, 2013 3:01:19 PM Subject: Re: [Engine-devel] REST API calls from

----- Original Message -----

...

From: "Doron Fediuck" <dfediuck@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: "Oved Ourfalli" <ovedo@redhat.com>, engine-devel@ovirt.org, arch@ovirt.org Sent: Sunday, February 24, 2013 1:20:12 PM Subject: Re: [Engine-devel] REST API calls from

----- Original Message -----

...

From: "Michael Pasternak" <mpastern@redhat.com> To: "Oved Ourfalli" <ovedo@redhat.com> Cc: engine-devel@ovirt.org, arch@ovirt.org Sent: Sunday, February 24, 2013 9:47:28 AM Subject: Re: [Engine-devel] REST API calls from

On 02/24/2013 09:05 AM, Oved Ourfalli wrote:

...

----- Original Message ----- > From: "Doron Fediuck" <dfediuck@redhat.com> > To: "Michael Pasternak" <mpastern@redhat.com> > Cc: engine-devel@ovirt.org, arch@ovirt.org > Sent: Thursday, February 21, 2013 6:54:59 PM > Subject: Re: [Engine-devel] REST API calls from > > > > ----- Original Message ----- >> From: "Michael Pasternak" <mpastern@redhat.com> >> To: "Doron Fediuck" <dfediuck@redhat.com> >> Cc: engine-devel@ovirt.org, arch@ovirt.org >> Sent: Wednesday, February 20, 2013 2:56:59 PM >> Subject: Re: [Engine-devel] REST API calls from >> >> On 02/14/2013 11:20 AM, Doron Fediuck wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Michael Pasternak" <mpastern@redhat.com> >>>> To: "Libor Spevak" <lspevak@redhat.com> >>>> Cc: engine-devel@ovirt.org, arch@ovirt.org >>>> Sent: Wednesday, February 13, 2013 12:55:36 PM >>>> Subject: Re: [Engine-devel] REST API calls from the GUI >>>> >>>> >>>> Hi Libor, >>>> >>>> This issue came across in one of the conversations i >>>> had >>>> with >>>> UX >>>> folks, but since we didn't end >>>> up with any conclusion/road map (nor discussed it >>>> properly >>>> to >>>> hear >>>> other thoughts), this is a perfect >>>> place to start this discussion, >>>> >>>> Intuitively REST is a way to go with GWT AJAX calls >>>> --------------------------------------------------- >>>> >>>> pros >>>> ==== >>>> >>>> - api data objects can be reused by generating java >>>> classes >>>> (using >>>> jaxb) from the rest schema [1] >>>> - no backend logic will be duplicated as api abstracts >>>> the >>>> backend >>>> exposing RESTful collection/resources to operate on >>>> - development against api is "easy" as api describes >>>> itself >>>> in >>>> RSDL >>>> [2] >>>> >>>> cons >>>> ==== >>>> >>>> - implementing transport layer (HTTP) under GWT >>>> - implementing own j2xml/json/yaml/... marshalling >>>> layer >>>> - implementing own error handling mechanism >>>> - implementing REST callback mechanism (in GWT) >>>> - constant maintenance of the data objects generated >>>> from >>>> the >>>> api >>>> - painful for Java developers >>>> >>>> Java-SDK >>>> -------- >>>> >>>> pros >>>> ==== >>>> >>>> - abstracts transport layer (leaving developer in >>>> standard >>>> Java >>>> api) >>>> - typesafe code (no need to mess with XML bulks) >>>> - has own data objects to work with >>>> - abstracts authentication/authorization >>>> (kerberos/cookie/session/etc.) >>>> - since SDK is auto-generated, it can be easily >>>> extended >>>> with >>>> required >>>> features to support UI (such as callback >>>> infrastructure >>>> for >>>> instance) >>>> >>>> cons >>>> ==== >>>> >>>> - has to be converted in to Javascript (not sure what >>>> the >>>> impacts >>>> are >>>> in terms of AJAX calls/etc.) >>>> - probably much more cons that we're not aware of and >>>> will >>>> have >>>> to >>>> figure out with POC >>>> >>>> >>>> thoughts? >>>> >>>> [1] http[s]://server[:port]/api?schema >>>> [2] http[s]://server[:port]/api?rsdl >>>> >>> >>> Although started as a UI request, there are other needs >>> who >>> wish >>> to use API calls with a different transport. For example >>> a >>> backend >>> hook which gets a REST entry point it can use to fetch >>> for >>> additional >>> data, or perform actions. In this case I'd expect an >>> internal >>> connection >>> rather than creating additional connections. >>> How would you resolve it generically enough in this >>> context? >> >> Doron, >> >> I believe your approach a bit different, UX folks seeking >> for >> a >> convenient >> way of communicating with ovirt public api, e.g closing >> api<->GUI >> gap, and >> theirs alternatives where native HTTP layer or Java-SDK >> based >> framework, >> while what you need is in-process channel to communicate >> with >> the >> engine itself, >> >> i understanding your will of using stable api for this >> (RESTapi), >> but >> not >> sure that doing this via JavaSDK is a good way to go >> simply >> because >> SDK is >> designed to operate in a client-space, while what you >> need >> is >> a >> server-space >> bridge for that. >> > > Michael, true but... > Thinking about it differently both UI and hooks needs a > client. > The underlying protocols should be abstracted. This is > something > which will serve other functions as well. >

I'm not sure we would need a new abstraction here. Both UI plugins and engine plugins need some API to do basic operations, and have access to different properties in the engine.

+1, that's exactly what i've suggested to begin with.

The only issue is that UI plugins and engine plugins shave different expectations from performance point of view. If UI is willing to wait for a refresh that may take too long for engine plugins, which would prefer to get the information as soon as possible without going into various communication layers which are not always needed. So again- a simple solution which enables transports layers to be replaced may serve more than one functionality in a better way.

Let's start with the simple solution. We don't know yet who will the plugins, how would they be used, and whether using the SDK will be a bottleneck of any kind. If the proposed solution is to support different transport layers while still using the SDK, then it is an extension we can always do in the future, if we find it of high benefit. (btw, regardless of that, the API/SDK is now faster than in the past, as we support REST sessions, which removes the need to re-authenticate upon each API request).

Oved, we have pretty good idea on how it will be used and what will create performance hits. Otherwise we wouldn't have had this thread.

If so, it would be nice if you share this information on the thread as well... some use-cases, some statistics you may have on the current performance, and on the performance requirements, and etc. I'm not saying that you're wrong... just saying I wasn't convinced it is really necessary.

Thank you, Oved

Think of intensive calls to an external scheduling 'hook'. We had a few threads about it in the past, and there's a wiki (being reworked now). Since you can never anticipate the information that hook will need, we should allow it to use REST API to fetch the information it needs from the backend. As Michael already answered opening a client in that hook will not be the optimal solution if it needs to open TCP connections.

...

...

...

...

...

In the UI plguins implementation, we gave this API, and in addition created a REST session to be used in order to do more sophisticated operations. I think we should probably do the same for engine plugins, giving the basic API, and giving a REST session for more advanced operations. The engine plugin may also have another 3rd party application it interacts with, and it would be able to share this session with it, allowing it to perform different operations on the engine. It would obviously be easy to do that using the Java SDK in the engine side, without creating a new layer of abstraction.

true, but the thing is that java-sdk designed to work with rest-api, and what Doron is trying to do is saving round-trip of engine->sdk->api->engine by enabling extra layer in sdk that will work not via HTTP, but natively with RESTeasy (REST framework we using in api), the disadvantages of such design are:

1. working with java-sdk via JNI (walking out from container to client application - sdk) 2. hacking RESTeasy by: 2.1 working with underlying (not public/backward compatible) interfaces & using JNI as well 2.2 most likely maintaining code working with RESTeasy on every new (RESTeasy) release by reverse engineering new changes/behaviour of this framework 2.3 making assumptions on code invocations to emulate GET/POST/PUT/DELETE HTTP calls 2.4 still having round-trip engine->sdk->RESTeasy->engine

therefore i think that having own private API in engine for that is a much better solution.

...

I assume the 3rd party application will use either the Java SDK, or another one, according the platform it is built upon, and in the "worst case", will interact directly with the API.

>>> >>>> On 02/12/2013 06:13 PM, Libor Spevak wrote: >>>>> Hi, >>>>> >>>>> I would like to ask, if there have been discussions >>>>> about >>>>> an >>>>> option >>>>> to call REST API services directly from the Frontend >>>>> (GWT >>>>> layer)? >>>>> GWT compiles Java frontend-side to >>>>> Javascript, calls to backend services are performed >>>>> "transparently" >>>>> by the framework using AJAX support. But, there is >>>>> still >>>>> a >>>>> need >>>>> to >>>>> have a special set of data objects >>>>> and the server-side logic can duplicate. >>>>> >>>>> Java REST API SDK enables to build "thick" client. The >>>>> calls >>>>> are >>>>> realized using e.g. Apache HttClient and supported >>>>> libraries. >>>>> I >>>>> think the requirements of GWT can be a >>>>> little bit different, but something overlaps. >>>>> >>>>> I found several links about REST API support from GWT, >>>>> so >>>>> there >>>>> is >>>>> something for inspiration... >>>>> >>>>> - http://www.spiffyui.org/ >>>>> - http://www.zackgrossbart.com/hackito/gwt-rest/ >>>>> - http://code.google.com/p/gwt-rest/ >>>>> - http://restygwt.fusesource.org/ >>>>> >>>>> But, do you think it would be useful and what >>>>> drawbacks >>>>> can >>>>> occur >>>>> (authentication, authorization, response times, need >>>>> to >>>>> support >>>>> larger set of services, painful >>>>> refactoring, ...)? >>>>> >>>>> Regards, >>>>> Libor >>>>>

---

Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

----- Original Message -----

From: "Michael Pasternak" <mpastern@redhat.com> To: "Oved Ourfalli" <ovedo@redhat.com> Cc: engine-devel@ovirt.org, arch@ovirt.org Sent: Monday, February 25, 2013 12:33:01 PM Subject: Re: [Engine-devel] REST API calls from

On 02/24/2013 03:01 PM, Oved Ourfalli wrote:

...

...

...

From: "Doron Fediuck" <dfediuck@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: "Oved Ourfalli" <ovedo@redhat.com>, engine-devel@ovirt.org, arch@ovirt.org Sent: Sunday, February 24, 2013 1:20:12 PM Subject: Re: [Engine-devel] REST API calls from

----- Original Message -----

...

...

From: "Michael Pasternak" <mpastern@redhat.com> To: "Oved Ourfalli" <ovedo@redhat.com> Cc: engine-devel@ovirt.org, arch@ovirt.org Sent: Sunday, February 24, 2013 9:47:28 AM Subject: Re: [Engine-devel] REST API calls from

On 02/24/2013 09:05 AM, Oved Ourfalli wrote: > > > > > > ----- Original Message ----- > > >> From: "Doron Fediuck" <dfediuck@redhat.com> > > >> To: "Michael Pasternak" <mpastern@redhat.com> > > >> Cc: engine-devel@ovirt.org, arch@ovirt.org > > >> Sent: Thursday, February 21, 2013 6:54:59 PM > > >> Subject: Re: [Engine-devel] REST API calls from > > >> > > >> > > >> > > >> ----- Original Message ----- > > > >>> From: "Michael Pasternak" <mpastern@redhat.com> > > > >>> To: "Doron Fediuck" <dfediuck@redhat.com> > > > >>> Cc: engine-devel@ovirt.org, arch@ovirt.org > > > >>> Sent: Wednesday, February 20, 2013 2:56:59 PM > > > >>> Subject: Re: [Engine-devel] REST API calls from > > > >>> > > > >>> On 02/14/2013 11:20 AM, Doron Fediuck wrote: >> > > >>>> >> > > >>>> >> > > >>>> ----- Original Message ----- >>> > > >>>>> From: "Michael Pasternak" <mpastern@redhat.com> >>> > > >>>>> To: "Libor Spevak" <lspevak@redhat.com> >>> > > >>>>> Cc: engine-devel@ovirt.org, arch@ovirt.org >>> > > >>>>> Sent: Wednesday, February 13, 2013 12:55:36 PM >>> > > >>>>> Subject: Re: [Engine-devel] REST API calls from >>> > > >>>>> the GUI >>> > > >>>>> >>> > > >>>>> >>> > > >>>>> Hi Libor, >>> > > >>>>> >>> > > >>>>> This issue came across in one of the conversations >>> > > >>>>> i had with >>> > > >>>>> UX >>> > > >>>>> folks, but since we didn't end >>> > > >>>>> up with any conclusion/road map (nor discussed it >>> > > >>>>> properly to >>> > > >>>>> hear >>> > > >>>>> other thoughts), this is a perfect >>> > > >>>>> place to start this discussion, >>> > > >>>>> >>> > > >>>>> Intuitively REST is a way to go with GWT AJAX >>> > > >>>>> calls >>> > > >>>>> --------------------------------------------------- >>> > > >>>>> >>> > > >>>>> pros >>> > > >>>>> ==== >>> > > >>>>> >>> > > >>>>> - api data objects can be reused by generating >>> > > >>>>> java classes >>> > > >>>>> (using >>> > > >>>>> jaxb) from the rest schema [1] >>> > > >>>>> - no backend logic will be duplicated as api >>> > > >>>>> abstracts the >>> > > >>>>> backend >>> > > >>>>> exposing RESTful collection/resources to operate >>> > > >>>>> on >>> > > >>>>> - development against api is "easy" as api >>> > > >>>>> describes itself >>> > > >>>>> in >>> > > >>>>> RSDL >>> > > >>>>> [2] >>> > > >>>>> >>> > > >>>>> cons >>> > > >>>>> ==== >>> > > >>>>> >>> > > >>>>> - implementing transport layer (HTTP) under GWT >>> > > >>>>> - implementing own j2xml/json/yaml/... marshalling >>> > > >>>>> layer >>> > > >>>>> - implementing own error handling mechanism >>> > > >>>>> - implementing REST callback mechanism (in GWT) >>> > > >>>>> - constant maintenance of the data objects >>> > > >>>>> generated from the >>> > > >>>>> api >>> > > >>>>> - painful for Java developers >>> > > >>>>> >>> > > >>>>> Java-SDK >>> > > >>>>> -------- >>> > > >>>>> >>> > > >>>>> pros >>> > > >>>>> ==== >>> > > >>>>> >>> > > >>>>> - abstracts transport layer (leaving developer in >>> > > >>>>> standard >>> > > >>>>> Java >>> > > >>>>> api) >>> > > >>>>> - typesafe code (no need to mess with XML bulks) >>> > > >>>>> - has own data objects to work with >>> > > >>>>> - abstracts authentication/authorization >>> > > >>>>> (kerberos/cookie/session/etc.) >>> > > >>>>> - since SDK is auto-generated, it can be easily >>> > > >>>>> extended with >>> > > >>>>> required >>> > > >>>>> features to support UI (such as callback >>> > > >>>>> infrastructure for >>> > > >>>>> instance) >>> > > >>>>> >>> > > >>>>> cons >>> > > >>>>> ==== >>> > > >>>>> >>> > > >>>>> - has to be converted in to Javascript (not sure >>> > > >>>>> what the >>> > > >>>>> impacts >>> > > >>>>> are >>> > > >>>>> in terms of AJAX calls/etc.) >>> > > >>>>> - probably much more cons that we're not aware of >>> > > >>>>> and will >>> > > >>>>> have >>> > > >>>>> to >>> > > >>>>> figure out with POC >>> > > >>>>> >>> > > >>>>> >>> > > >>>>> thoughts? >>> > > >>>>> >>> > > >>>>> [1] http[s]://server[:port]/api?schema >>> > > >>>>> [2] http[s]://server[:port]/api?rsdl >>> > > >>>>> >> > > >>>> >> > > >>>> Although started as a UI request, there are other >> > > >>>> needs who >> > > >>>> wish >> > > >>>> to use API calls with a different transport. For >> > > >>>> example a >> > > >>>> backend >> > > >>>> hook which gets a REST entry point it can use to >> > > >>>> fetch for >> > > >>>> additional >> > > >>>> data, or perform actions. In this case I'd expect an >> > > >>>> internal >> > > >>>> connection >> > > >>>> rather than creating additional connections. >> > > >>>> How would you resolve it generically enough in this >> > > >>>> context? > > > >>> > > > >>> Doron, > > > >>> > > > >>> I believe your approach a bit different, UX folks > > > >>> seeking for a > > > >>> convenient > > > >>> way of communicating with ovirt public api, e.g > > > >>> closing > > > >>> api<->GUI > > > >>> gap, and > > > >>> theirs alternatives where native HTTP layer or > > > >>> Java-SDK based > > > >>> framework, > > > >>> while what you need is in-process channel to > > > >>> communicate with > > > >>> the > > > >>> engine itself, > > > >>> > > > >>> i understanding your will of using stable api for this > > > >>> (RESTapi), > > > >>> but > > > >>> not > > > >>> sure that doing this via JavaSDK is a good way to go > > > >>> simply > > > >>> because > > > >>> SDK is > > > >>> designed to operate in a client-space, while what you > > > >>> need is a > > > >>> server-space > > > >>> bridge for that. > > > >>> > > >> > > >> Michael, true but... > > >> Thinking about it differently both UI and hooks needs a > > >> client. > > >> The underlying protocols should be abstracted. This is > > >> something > > >> which will serve other functions as well. > > >> > > > > I'm not sure we would need a new abstraction here. > > Both UI plugins and engine plugins need some API to do > > basic > > operations, and have access to different properties in the > > engine.

+1, that's exactly what i've suggested to begin with.

The only issue is that UI plugins and engine plugins shave different expectations from performance point of view. If UI is willing to wait for a refresh that may take too long for engine plugins, which would prefer to get the information as soon as possible without going into various communication layers which are not always needed. So again- a simple solution which enables transports layers to be replaced may serve more than one functionality in a better way.

Let's start with the simple solution. We don't know yet who will

----- Original Message ----- the plugins, how would they be used, and whether using the SDK will be a bottleneck of any kind. If the proposed solution is to support different transport layers while still using the SDK, then it is an extension we can always do in the future, if we find it of high benefit. (btw, regardless of that, the API/SDK is now faster than in the past, as we support REST sessions, which removes the need to re-authenticate upon each API request).

true, but the real bottleneck is sending XML bulks over the wire + bi-directional marshalling X 2 (engine<->api + api<->xml).

Here we're in agreement.

Hi Daniel,

The first alternative can be implemented by using GWT RequestBuilder (for sending the HTTP requests) and GWT overlay types (that can be generated from java POJOs). Probably best performance-wise/less data type conversions/etc; However, basically means writing a JavaScript SDK.

Yes, we can use RequestBuilder for making AJAX HTTP requests, but using GWT overlay types is possible only if REST API fully supports JSON format. In case of XML format, we would have to use GWT XMLParser to map "restapi-types" entities/collections to/from XML strings, e.g. we could write GWT deferred binding generators to generate such mappers from current schema.

The benefit of the second alternative is currently rather vague since the Java SDK can't be converted to JavaScript as is (can't use apache.commons and javax packages in GWT client side). Need to check how easily they can be replaced with JRE libraries that GWT can emulate (for supporting both GWT web and debug mode).

Indeed, we can't use Java REST API SDK as it is with GWT: https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation This means we need to implement our own transport layer (RequestBuilder) and most likely also the marshalling layer (XMLParser vs. JSONParser vs. overlay types).

A third alternative could be simply maintaining the current GWT RPC mechanism we use. I.e. integrating the Java SDK into the GWT servlet, which means wrapping the API into GenericApiGWTService. The main drawback is an additional layer of data type conversion and round-trip: Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client).

This is interesting, generic API could be used to transfer "restapi-types", along with extra information to emulate proper HTTP request, without any marshalling involved. Vojtech ----- Original Message ----- From: "Daniel Erez" <derez@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: engine-devel@ovirt.org, "Einav Cohen" <ecohen@redhat.com>, arch@ovirt.org, "Libor Spevak" <lspevak@redhat.com>, "Vojtech Szocs" <vszocs@redhat.com> Sent: Friday, February 15, 2013 7:17:43 PM Subject: Re: [Engine-devel] REST API calls from the GUI ----- Original Message -----

From: "Michael Pasternak" <mpastern@redhat.com> To: "Libor Spevak" <lspevak@redhat.com> Cc: engine-devel@ovirt.org, "Daniel Erez" <derez@redhat.com>, "Gilad Chaplik" <gchaplik@redhat.com>, "Einav Cohen" <ecohen@redhat.com>, arch@ovirt.org Sent: Wednesday, February 13, 2013 12:55:36 PM Subject: Re: [Engine-devel] REST API calls from the GUI

Hi Libor,

This issue came across in one of the conversations i had with UX folks, but since we didn't end up with any conclusion/road map (nor discussed it properly to hear other thoughts), this is a perfect place to start this discussion,

Intuitively REST is a way to go with GWT AJAX calls ---------------------------------------------------

pros ====

- api data objects can be reused by generating java classes (using jaxb) from the rest schema [1] - no backend logic will be duplicated as api abstracts the backend exposing RESTful collection/resources to operate on - development against api is "easy" as api describes itself in RSDL [2]

cons ====

- implementing transport layer (HTTP) under GWT - implementing own j2xml/json/yaml/... marshalling layer - implementing own error handling mechanism - implementing REST callback mechanism (in GWT) - constant maintenance of the data objects generated from the api - painful for Java developers

Java-SDK --------

pros ====

- abstracts transport layer (leaving developer in standard Java api) - typesafe code (no need to mess with XML bulks) - has own data objects to work with - abstracts authentication/authorization (kerberos/cookie/session/etc.) - since SDK is auto-generated, it can be easily extended with required features to support UI (such as callback infrastructure for instance)

cons ====

- has to be converted in to Javascript (not sure what the impacts are in terms of AJAX calls/etc.) - probably much more cons that we're not aware of and will have to figure out with POC

thoughts?

The first alternative can be implemented by using GWT RequestBuilder (for sending the HTTP requests) and GWT overlay types (that can be generated from java POJOs). Probably best performance-wise/less data type conversions/etc; However, basically means writing a JavaScript SDK. The benefit of the second alternative is currently rather vague since the Java SDK can't be converted to JavaScript as is (can't use apache.commons and javax packages in GWT client side). Need to check how easily they can be replaced with JRE libraries that GWT can emulate (for supporting both GWT web and debug mode). A third alternative could be simply maintaining the current GWT RPC mechanism we use. I.e. integrating the Java SDK into the GWT servlet, which means wrapping the API into GenericApiGWTService. The main drawback is an additional layer of data type conversion and round-trip: Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client).

[1] http[s]://server[:port]/api?schema [2] http[s]://server[:port]/api?rsdl

On 02/12/2013 06:13 PM, Libor Spevak wrote:

...

Hi,

I would like to ask, if there have been discussions about an option to call REST API services directly from the Frontend (GWT layer)? GWT compiles Java frontend-side to Javascript, calls to backend services are performed "transparently" by the framework using AJAX support. But, there is still a need to have a special set of data objects and the server-side logic can duplicate.

Java REST API SDK enables to build "thick" client. The calls are realized using e.g. Apache HttClient and supported libraries. I think the requirements of GWT can be a little bit different, but something overlaps.

I found several links about REST API support from GWT, so there is something for inspiration...

- http://www.spiffyui.org/ - http://www.zackgrossbart.com/hackito/gwt-rest/ - http://code.google.com/p/gwt-rest/ - http://restygwt.fusesource.org/

But, do you think it would be useful and what drawbacks can occur (authentication, authorization, response times, need to support larger set of services, painful refactoring, ...)?

Regards, Libor

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

--

Michael Pasternak RedHat, ENG-Virtualization R&D

----- Original Message -----

From: "Vojtech Szocs" <vszocs@redhat.com> To: "Daniel Erez" <derez@redhat.com> Cc: arch@ovirt.org, engine-devel@ovirt.org Sent: Saturday, February 16, 2013 1:07:56 AM Subject: Re: [Engine-devel] REST API calls from the GUI

Hi Daniel,

...

The first alternative can be implemented by using GWT RequestBuilder (for sending the HTTP requests) and GWT overlay types (that can be generated from java POJOs). Probably best performance-wise/less data type conversions/etc; However, basically means writing a JavaScript SDK.

Yes, we can use RequestBuilder for making AJAX HTTP requests, but using GWT overlay types is possible only if REST API fully supports JSON format. In case of XML format, we would have to use GWT XMLParser to map "restapi-types" entities/collections to/from XML strings, e.g. we could write GWT deferred binding generators to generate such mappers from current schema.

AutoBean(http://code.google.com/p/google-web-toolkit/wiki/AutoBean) could be useful instead of generating/writing overlay types. AutoBeans will be converted overlay types internally by GWT automatically.

...

The benefit of the second alternative is currently rather vague since the Java SDK can't be converted to JavaScript as is (can't use apache.commons and javax packages in GWT client side). Need to check how easily they can be replaced with JRE libraries that GWT can emulate (for supporting both GWT web and debug mode).

Indeed, we can't use Java REST API SDK as it is with GWT: https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation

This means we need to implement our own transport layer (RequestBuilder) and most likely also the marshalling layer (XMLParser vs. JSONParser vs. overlay types).

It would be better if We can come up with a "GWT REST API SDK", which is analogous Java SDK.

...

A third alternative could be simply maintaining the current GWT RPC mechanism we use. I.e. integrating the Java SDK into the GWT servlet, which means wrapping the API into GenericApiGWTService. The main drawback is an additional layer of data type conversion and round-trip: Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client).

This is interesting, generic API could be used to transfer "restapi-types", along with extra information to emulate proper HTTP request, without any marshalling involved.

We can't directly use the restapi models in the client side, as they have lot of xml and annotations stuff involved which will not be compatible with GWT.

Vojtech

----- Original Message ----- From: "Daniel Erez" <derez@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: engine-devel@ovirt.org, "Einav Cohen" <ecohen@redhat.com>, arch@ovirt.org, "Libor Spevak" <lspevak@redhat.com>, "Vojtech Szocs" <vszocs@redhat.com> Sent: Friday, February 15, 2013 7:17:43 PM Subject: Re: [Engine-devel] REST API calls from the GUI

----- Original Message -----

...

From: "Michael Pasternak" <mpastern@redhat.com> To: "Libor Spevak" <lspevak@redhat.com> Cc: engine-devel@ovirt.org, "Daniel Erez" <derez@redhat.com>, "Gilad Chaplik" <gchaplik@redhat.com>, "Einav Cohen" <ecohen@redhat.com>, arch@ovirt.org Sent: Wednesday, February 13, 2013 12:55:36 PM Subject: Re: [Engine-devel] REST API calls from the GUI

Hi Libor,

This issue came across in one of the conversations i had with UX folks, but since we didn't end up with any conclusion/road map (nor discussed it properly to hear other thoughts), this is a perfect place to start this discussion,

Intuitively REST is a way to go with GWT AJAX calls ---------------------------------------------------

pros ====

- api data objects can be reused by generating java classes (using jaxb) from the rest schema [1] - no backend logic will be duplicated as api abstracts the backend exposing RESTful collection/resources to operate on - development against api is "easy" as api describes itself in RSDL [2]

cons ====

- implementing transport layer (HTTP) under GWT - implementing own j2xml/json/yaml/... marshalling layer - implementing own error handling mechanism - implementing REST callback mechanism (in GWT) - constant maintenance of the data objects generated from the api - painful for Java developers

Java-SDK --------

pros ====

- abstracts transport layer (leaving developer in standard Java api) - typesafe code (no need to mess with XML bulks) - has own data objects to work with - abstracts authentication/authorization (kerberos/cookie/session/etc.) - since SDK is auto-generated, it can be easily extended with required features to support UI (such as callback infrastructure for instance)

cons ====

- has to be converted in to Javascript (not sure what the impacts are in terms of AJAX calls/etc.) - probably much more cons that we're not aware of and will have to figure out with POC

thoughts?

The first alternative can be implemented by using GWT RequestBuilder (for sending the HTTP requests) and GWT overlay types (that can be generated from java POJOs). Probably best performance-wise/less data type conversions/etc; However, basically means writing a JavaScript SDK.

The benefit of the second alternative is currently rather vague since the Java SDK can't be converted to JavaScript as is (can't use apache.commons and javax packages in GWT client side). Need to check how easily they can be replaced with JRE libraries that GWT can emulate (for supporting both GWT web and debug mode).

A third alternative could be simply maintaining the current GWT RPC mechanism we use. I.e. integrating the Java SDK into the GWT servlet, which means wrapping the API into GenericApiGWTService. The main drawback is an additional layer of data type conversion and round-trip: Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client).

...

[1] http[s]://server[:port]/api?schema [2] http[s]://server[:port]/api?rsdl

On 02/12/2013 06:13 PM, Libor Spevak wrote:

...

Hi,

I would like to ask, if there have been discussions about an option to call REST API services directly from the Frontend (GWT layer)? GWT compiles Java frontend-side to Javascript, calls to backend services are performed "transparently" by the framework using AJAX support. But, there is still a need to have a special set of data objects and the server-side logic can duplicate.

Java REST API SDK enables to build "thick" client. The calls are realized using e.g. Apache HttClient and supported libraries. I think the requirements of GWT can be a little bit different, but something overlaps.

I found several links about REST API support from GWT, so there is something for inspiration...

- http://www.spiffyui.org/ - http://www.zackgrossbart.com/hackito/gwt-rest/ - http://code.google.com/p/gwt-rest/ - http://restygwt.fusesource.org/

But, do you think it would be useful and what drawbacks can occur (authentication, authorization, response times, need to support larger set of services, painful refactoring, ...)?

Regards, Libor

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

--

Michael Pasternak RedHat, ENG-Virtualization R&D

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

----- Original Message -----

From: "Michael Pasternak" <mpastern@redhat.com> To: "Kanagaraj Mayilsamy" <kmayilsa@redhat.com> Cc: "Vojtech Szocs" <vszocs@redhat.com>, engine-devel@ovirt.org, arch@ovirt.org Sent: Wednesday, February 20, 2013 5:55:50 PM Subject: Re: [Engine-devel] REST API calls from the GUI

On 02/18/2013 05:09 AM, Kanagaraj Mayilsamy wrote:

...

----- Original Message -----

...

From: "Vojtech Szocs" <vszocs@redhat.com> To: "Daniel Erez" <derez@redhat.com> Cc: arch@ovirt.org, engine-devel@ovirt.org Sent: Saturday, February 16, 2013 1:07:56 AM Subject: Re: [Engine-devel] REST API calls from the GUI

Hi Daniel,

...

The first alternative can be implemented by using GWT RequestBuilder (for sending the HTTP requests) and GWT overlay types (that can be generated from java POJOs). Probably best performance-wise/less data type conversions/etc; However, basically means writing a JavaScript SDK.

Yes, we can use RequestBuilder for making AJAX HTTP requests, but using GWT overlay types is possible only if REST API fully supports JSON format. In case of XML format, we would have to use GWT XMLParser to map "restapi-types" entities/collections to/from XML strings, e.g. we could write GWT deferred binding generators to generate such mappers from current schema.

AutoBean(http://code.google.com/p/google-web-toolkit/wiki/AutoBean) could be useful instead of generating/writing overlay types. AutoBeans will be converted overlay types internally by GWT automatically.

...

...

The benefit of the second alternative is currently rather vague since the Java SDK can't be converted to JavaScript as is (can't use apache.commons and javax packages in GWT client side). Need to check how easily they can be replaced with JRE libraries that GWT can emulate (for supporting both GWT web and debug mode).

Indeed, we can't use Java REST API SDK as it is with GWT: https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation

This means we need to implement our own transport layer (RequestBuilder) and most likely also the marshalling layer (XMLParser vs. JSONParser vs. overlay types).

It would be better if We can come up with a "GWT REST API SDK", which is analogous Java SDK.

...

...

A third alternative could be simply maintaining the current GWT RPC mechanism we use. I.e. integrating the Java SDK into the GWT servlet, which means wrapping the API into GenericApiGWTService. The main drawback is an additional layer of data type conversion and round-trip: Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client).

This is interesting, generic API could be used to transfer "restapi-types", along with extra information to emulate proper HTTP request, without any marshalling involved.

We can't directly use the restapi models in the client side, as they have lot of xml and annotations stuff involved which will not be compatible with GWT.

why? they only have jaxb annotations which are 'must' for serialization & talking with api.

We can't use jaxb, as GWT won't emulate the jaxb classes. https://developers.google.com/web-toolkit/doc/1.6/RefJreEmulation If at all we want use jaxb, we should include the source of jaxb to ui module, so that GWT can compile them to javascript equivalents. But this is less likely as jaxb relies heavily on reflection which not supported by GWT.

...

...

Vojtech

----- Original Message ----- From: "Daniel Erez" <derez@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: engine-devel@ovirt.org, "Einav Cohen" <ecohen@redhat.com>, arch@ovirt.org, "Libor Spevak" <lspevak@redhat.com>, "Vojtech Szocs" <vszocs@redhat.com> Sent: Friday, February 15, 2013 7:17:43 PM Subject: Re: [Engine-devel] REST API calls from the GUI

----- Original Message -----

...

From: "Michael Pasternak" <mpastern@redhat.com> To: "Libor Spevak" <lspevak@redhat.com> Cc: engine-devel@ovirt.org, "Daniel Erez" <derez@redhat.com>, "Gilad Chaplik" <gchaplik@redhat.com>, "Einav Cohen" <ecohen@redhat.com>, arch@ovirt.org Sent: Wednesday, February 13, 2013 12:55:36 PM Subject: Re: [Engine-devel] REST API calls from the GUI

Hi Libor,

This issue came across in one of the conversations i had with UX folks, but since we didn't end up with any conclusion/road map (nor discussed it properly to hear other thoughts), this is a perfect place to start this discussion,

Intuitively REST is a way to go with GWT AJAX calls ---------------------------------------------------

pros ====

- api data objects can be reused by generating java classes (using jaxb) from the rest schema [1] - no backend logic will be duplicated as api abstracts the backend exposing RESTful collection/resources to operate on - development against api is "easy" as api describes itself in RSDL [2]

cons ====

- implementing transport layer (HTTP) under GWT - implementing own j2xml/json/yaml/... marshalling layer - implementing own error handling mechanism - implementing REST callback mechanism (in GWT) - constant maintenance of the data objects generated from the api - painful for Java developers

Java-SDK --------

pros ====

- abstracts transport layer (leaving developer in standard Java api) - typesafe code (no need to mess with XML bulks) - has own data objects to work with - abstracts authentication/authorization (kerberos/cookie/session/etc.) - since SDK is auto-generated, it can be easily extended with required features to support UI (such as callback infrastructure for instance)

cons ====

- has to be converted in to Javascript (not sure what the impacts are in terms of AJAX calls/etc.) - probably much more cons that we're not aware of and will have to figure out with POC

thoughts?

The first alternative can be implemented by using GWT RequestBuilder (for sending the HTTP requests) and GWT overlay types (that can be generated from java POJOs). Probably best performance-wise/less data type conversions/etc; However, basically means writing a JavaScript SDK.

The benefit of the second alternative is currently rather vague since the Java SDK can't be converted to JavaScript as is (can't use apache.commons and javax packages in GWT client side). Need to check how easily they can be replaced with JRE libraries that GWT can emulate (for supporting both GWT web and debug mode).

A third alternative could be simply maintaining the current GWT RPC mechanism we use. I.e. integrating the Java SDK into the GWT servlet, which means wrapping the API into GenericApiGWTService. The main drawback is an additional layer of data type conversion and round-trip: Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client).

...

[1] http[s]://server[:port]/api?schema [2] http[s]://server[:port]/api?rsdl

On 02/12/2013 06:13 PM, Libor Spevak wrote:

...

Hi,

I would like to ask, if there have been discussions about an option to call REST API services directly from the Frontend (GWT layer)? GWT compiles Java frontend-side to Javascript, calls to backend services are performed "transparently" by the framework using AJAX support. But, there is still a need to have a special set of data objects and the server-side logic can duplicate.

Java REST API SDK enables to build "thick" client. The calls are realized using e.g. Apache HttClient and supported libraries. I think the requirements of GWT can be a little bit different, but something overlaps.

I found several links about REST API support from GWT, so there is something for inspiration...

- http://www.spiffyui.org/ - http://www.zackgrossbart.com/hackito/gwt-rest/ - http://code.google.com/p/gwt-rest/ - http://restygwt.fusesource.org/

But, do you think it would be useful and what drawbacks can occur (authentication, authorization, response times, need to support larger set of services, painful refactoring, ...)?

Regards, Libor

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

--

Michael Pasternak RedHat, ENG-Virtualization R&D

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

--

Michael Pasternak RedHat, ENG-Virtualization R&D

Hi guys,

...

...

...

...

We can't directly use the restapi models in the client side, as they have lot of xml and annotations stuff involved which will not be compatible with GWT.

why? they only have jaxb annotations which are 'must' for serialization & talking with api.

Actually, we *can* use JAXB-generated REST API Java types with GWT, since GWT compiler simply ignores annotations in Java sources during compilation to JavaScript. The only problem I see is REST API Java types using stuff like javax.xml.datatype.XMLGregorianCalendar - we'd have to emulate it in GWT (shouldn't be an issue). Other than that, I'd recommend using JAXB-generated REST API Java types, as they always match current REST API schema (api.xsd). As for the marshalling layer, we can't use JAXB (REST API Java SDK) with GWT, but we can still write deferred binding generator to generate mappers for XML <--> Rest API Java type conversion.

if you not using JAXB, you should make sure calling variables in the classes that will be marshalled to XML as they are defined in the api schema and not using Java naming convention (as XJC does),

Yeah, with XML representation we would have to do this ourselves. On the other hand, things would be much simpler if REST API supported JSON, which is something we should consider (wait for JSON support? work with XML?)

...

...

...

...

It would be better if We can come up with a "GWT REST API SDK", which is analogous Java SDK.

I'd rather have JavaScript REST API SDK which we could use with GWT, this would open up new possibilities for web clients. Vojtech ----- Original Message ----- From: "Michael Pasternak" <mpastern@redhat.com> To: "Kanagaraj Mayilsamy" <kmayilsa@redhat.com> Cc: "Vojtech Szocs" <vszocs@redhat.com>, engine-devel@ovirt.org, arch@ovirt.org Sent: Wednesday, February 20, 2013 2:07:15 PM Subject: Re: [Engine-devel] REST API calls from the GUI On 02/20/2013 02:45 PM, Kanagaraj Mayilsamy wrote:

----- Original Message -----

...

...

From: "Michael Pasternak" <mpastern@redhat.com> To: "Kanagaraj Mayilsamy" <kmayilsa@redhat.com> Cc: "Vojtech Szocs" <vszocs@redhat.com>, engine-devel@ovirt.org, arch@ovirt.org Sent: Wednesday, February 20, 2013 5:55:50 PM Subject: Re: [Engine-devel] REST API calls from the GUI

On 02/18/2013 05:09 AM, Kanagaraj Mayilsamy wrote:

...

...

----- Original Message -----

...

> From: "Vojtech Szocs" <vszocs@redhat.com> > To: "Daniel Erez" <derez@redhat.com> > Cc: arch@ovirt.org, engine-devel@ovirt.org > Sent: Saturday, February 16, 2013 1:07:56 AM > Subject: Re: [Engine-devel] REST API calls from the GUI > > Hi Daniel, > >>> The first alternative can be implemented by using GWT >>> RequestBuilder (for sending the HTTP requests) >>> and GWT overlay types (that can be generated from java POJOs). >>> Probably best performance-wise/less data type conversions/etc; >>> However, basically means writing a JavaScript SDK. > > Yes, we can use RequestBuilder for making AJAX HTTP requests, but > using GWT overlay types is possible only if REST API fully > supports > JSON format. In case of XML format, we would have to use GWT > XMLParser to map "restapi-types" entities/collections to/from XML > strings, e.g. we could write GWT deferred binding generators to > generate such mappers from current schema.

AutoBean(http://code.google.com/p/google-web-toolkit/wiki/AutoBean) could be useful instead of generating/writing overlay types. AutoBeans will be converted overlay types internally by GWT automatically.

...

> >>> The benefit of the second alternative is currently rather vague >>> since the Java SDK can't be converted to JavaScript as is >>> (can't use apache.commons and javax packages in GWT client side). >>> Need to check how easily they can be replaced >>> with JRE libraries that GWT can emulate (for supporting both GWT >>> web and debug mode). > > Indeed, we can't use Java REST API SDK as it is with GWT: > https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation > > This means we need to implement our own transport layer > (RequestBuilder) and most likely also the marshalling layer > (XMLParser vs. JSONParser vs. overlay types).

It would be better if We can come up with a "GWT REST API SDK", which is analogous Java SDK.

...

> >>> A third alternative could be simply maintaining the current GWT >>> RPC >>> mechanism we use. >>> I.e. integrating the Java SDK into the GWT servlet, which means >>> wrapping the API into GenericApiGWTService. >>> The main drawback is an additional layer of data type conversion >>> and round-trip: >>> Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client). > > This is interesting, generic API could be used to transfer > "restapi-types", along with extra information to emulate proper > HTTP > request, without any marshalling involved. >

We can't directly use the restapi models in the client side, as they have lot of xml and annotations stuff involved which will not be compatible with GWT.

why? they only have jaxb annotations which are 'must' for serialization & talking with api.

We can't use jaxb, as GWT won't emulate the jaxb classes. https://developers.google.com/web-toolkit/doc/1.6/RefJreEmulation

If at all we want use jaxb, we should include the source of jaxb to ui module, so that GWT can compile them to javascript equivalents. But this is less likely as jaxb relies heavily on reflection which not supported by GWT.

if you not using JAXB, you should make sure calling variables in the classes that will be marshalled to XML as they are defined in the api schema and not using Java naming convention (as XJC does), if your schema->java converting tool support this, you're okay. -- Michael Pasternak RedHat, ENG-Virtualization R&D

It looks like there are several frameworks trying to support GWT and/or XML/JSon serialization, but still there is a lot of work to do + compatibility problems with the latest versions of GWT, etc. I investigated a little bit Restlet framework, which looked promising. The online documentation available is very limited. But good place to look is the book 'Restlet in Action'. Project examples: (size: 500M) git clone https://github.com/restlet/restlet-framework-java.git cd restlet-framework-java/modules/org.restlet.example.book.restlet.ch09.gwt Info from the book: "GWT and Restlet versions Restlet Framework version 2.0 supports version 2.0 and 2.1 of Google Web Toolkit, but not later, due to API breaking changes introduced in GWT 2.2. Restlet Framework version 2.1 supports GWT 2.3 and above, but not previous versions." but: "At the time of writing, the deferred binding support of Restlet only supports the special GWT object serialization format. In future versions, XML and JSON-based formats could be added by leveraging the Piriti library. This library provides JSON and XML mappers for GWT based on annotations and deferred binding. Further details are available on Google Code at http://code.google.com/p/piriti/." Just DomRepresentation object and "manual" parsing is probably possible now. Still waiting for a hope, now 'piriti'? :-) git clone https://github.com/hpehl/piriti Has anybody seen it in action? On 15.2.2013 20:37, Vojtech Szocs wrote:

Hi Daniel,

...

The first alternative can be implemented by using GWT RequestBuilder (for sending the HTTP requests) and GWT overlay types (that can be generated from java POJOs). Probably best performance-wise/less data type conversions/etc; However, basically means writing a JavaScript SDK. Yes, we can use RequestBuilder for making AJAX HTTP requests, but using GWT overlay types is possible only if REST API fully supports JSON format. In case of XML format, we would have to use GWT XMLParser to map "restapi-types" entities/collections to/from XML strings, e.g. we could write GWT deferred binding generators to generate such mappers from current schema.

...

The benefit of the second alternative is currently rather vague since the Java SDK can't be converted to JavaScript as is (can't use apache.commons and javax packages in GWT client side). Need to check how easily they can be replaced with JRE libraries that GWT can emulate (for supporting both GWT web and debug mode). Indeed, we can't use Java REST API SDK as it is with GWT: https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation

This means we need to implement our own transport layer (RequestBuilder) and most likely also the marshalling layer (XMLParser vs. JSONParser vs. overlay types).

...

A third alternative could be simply maintaining the current GWT RPC mechanism we use. I.e. integrating the Java SDK into the GWT servlet, which means wrapping the API into GenericApiGWTService. The main drawback is an additional layer of data type conversion and round-trip: Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client). This is interesting, generic API could be used to transfer "restapi-types", along with extra information to emulate proper HTTP request, without any marshalling involved.

Vojtech

----- Original Message ----- From: "Daniel Erez" <derez@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: engine-devel@ovirt.org, "Einav Cohen" <ecohen@redhat.com>, arch@ovirt.org, "Libor Spevak" <lspevak@redhat.com>, "Vojtech Szocs" <vszocs@redhat.com> Sent: Friday, February 15, 2013 7:17:43 PM Subject: Re: [Engine-devel] REST API calls from the GUI

----- Original Message -----

...

From: "Michael Pasternak" <mpastern@redhat.com> To: "Libor Spevak" <lspevak@redhat.com> Cc: engine-devel@ovirt.org, "Daniel Erez" <derez@redhat.com>, "Gilad Chaplik" <gchaplik@redhat.com>, "Einav Cohen" <ecohen@redhat.com>, arch@ovirt.org Sent: Wednesday, February 13, 2013 12:55:36 PM Subject: Re: [Engine-devel] REST API calls from the GUI

Hi Libor,

This issue came across in one of the conversations i had with UX folks, but since we didn't end up with any conclusion/road map (nor discussed it properly to hear other thoughts), this is a perfect place to start this discussion,

Intuitively REST is a way to go with GWT AJAX calls ---------------------------------------------------

pros ====

- api data objects can be reused by generating java classes (using jaxb) from the rest schema [1] - no backend logic will be duplicated as api abstracts the backend exposing RESTful collection/resources to operate on - development against api is "easy" as api describes itself in RSDL [2]

cons ====

- implementing transport layer (HTTP) under GWT - implementing own j2xml/json/yaml/... marshalling layer - implementing own error handling mechanism - implementing REST callback mechanism (in GWT) - constant maintenance of the data objects generated from the api - painful for Java developers

Java-SDK --------

pros ====

- abstracts transport layer (leaving developer in standard Java api) - typesafe code (no need to mess with XML bulks) - has own data objects to work with - abstracts authentication/authorization (kerberos/cookie/session/etc.) - since SDK is auto-generated, it can be easily extended with required features to support UI (such as callback infrastructure for instance)

cons ====

- has to be converted in to Javascript (not sure what the impacts are in terms of AJAX calls/etc.) - probably much more cons that we're not aware of and will have to figure out with POC

thoughts?

The first alternative can be implemented by using GWT RequestBuilder (for sending the HTTP requests) and GWT overlay types (that can be generated from java POJOs). Probably best performance-wise/less data type conversions/etc; However, basically means writing a JavaScript SDK.

The benefit of the second alternative is currently rather vague since the Java SDK can't be converted to JavaScript as is (can't use apache.commons and javax packages in GWT client side). Need to check how easily they can be replaced with JRE libraries that GWT can emulate (for supporting both GWT web and debug mode).

A third alternative could be simply maintaining the current GWT RPC mechanism we use. I.e. integrating the Java SDK into the GWT servlet, which means wrapping the API into GenericApiGWTService. The main drawback is an additional layer of data type conversion and round-trip: Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client).

...

[1] http[s]://server[:port]/api?schema [2] http[s]://server[:port]/api?rsdl

On 02/12/2013 06:13 PM, Libor Spevak wrote:

...

Hi,

I would like to ask, if there have been discussions about an option to call REST API services directly from the Frontend (GWT layer)? GWT compiles Java frontend-side to Javascript, calls to backend services are performed "transparently" by the framework using AJAX support. But, there is still a need to have a special set of data objects and the server-side logic can duplicate.

Java REST API SDK enables to build "thick" client. The calls are realized using e.g. Apache HttClient and supported libraries. I think the requirements of GWT can be a little bit different, but something overlaps.

I found several links about REST API support from GWT, so there is something for inspiration...

- http://www.spiffyui.org/ - http://www.zackgrossbart.com/hackito/gwt-rest/ - http://code.google.com/p/gwt-rest/ - http://restygwt.fusesource.org/

But, do you think it would be useful and what drawbacks can occur (authentication, authorization, response times, need to support larger set of services, painful refactoring, ...)?

Regards, Libor

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

--

Michael Pasternak RedHat, ENG-Virtualization R&D