¿Cuál es la mejor manera de diseñar un servidor GWT "independiente de la plataforma"?

Question

¿Cuál es la mejor manera de diseñar una arquitectura de servidor Java que interactúa con una aplicación GWT del lado del cliente, pero también responde correctamente a varias otras solicitudes de clientes de otras plataformas? Específicamente, me gustaría usar la misma capa de servlet para responder no solo a mi aplicación GWT, sino a las aplicaciones iOS y Android correspondientes.

El primer enfoque que pensé sería implementar la capa de cliente GWT utilizando "RequestBuilder" en lugar de las interfaces de servicio de método RPC habituales. Usando este enfoque, pude codificar los servlets genéricos que responden a las solicitudes HTTP de manera RESTful mediante el procesamiento de variables codificadas en algo como JSON o XML. Aunque esto funcionaría, sería un poco laborioso tener que codificar y decodificar mis objetos/parámetros en JSON tanto en el cliente como en el servidor, especialmente cuando RPC proporcionaba una solución tan elegante.

El otro enfoque (que creo que es mejor), sería encontrar la especificación que Google utiliza para serializar y deserializar sus llamadas al método RPC e implementar algún tipo de biblioteca que haga lo mismo para iOS (en Objective-C) y Android. El problema es que no he podido encontrar buena documentación sobre este estándar de codificación, ni he encontrado bibliotecas que lo implementen para iOS o Android (aunque encontré algo así para PHP en www.gwtphp.com).

¿Alguien podría dirigirme hacia una especificación de cómo GWT serializa/deserializa sus objetos o, mejor aún, bibliotecas para iOS y/o Android que implementan interfaces RPC?

Answer 1

Crea una capa de "servicio", es decir, un conjunto de clases de negocios que devuelven POJO.

Luego puede hacer que GWT-RPC y REST llamen fácilmente a la capa de servicio.

Esto es bastante fácil y directo. Su problema será cómo crear una capa empresarial que solo devuelva POJO. Pero esa es otra historia.

Answer 2

Si realmente está tratando de tener un servidor independiente de la plataforma con el que los clientes puedan interactuar, entonces la mejor opción será usar un enfoque de "mínimo común denominador", que a menudo es pasar datos simples y manejar superficies para varias acciones para ocurrir.

Para ello, una interfaz RESTful, probablemente con JSON o XML para codificar los datos, será su apuesta más compatible.

La principal ventaja de ir de esta manera es que ya hay mucha de las bibliotecas que tienen que ver con la serialización/deserialización JSON y XML, y que están manteniendo su servicio lo más flexible posible, lo que significa que no está limitando su base de clientes al exigirles que hagan mucho más que tratar con el texto y realizar solicitudes web (en el nivel más básico).

Se hace poner un poco más de trabajo en hacer que el lado del servidor de la conexión haga lo que quiera, pero esa es la disyuntiva entre la flexibilidad de RESTO bastante genérico que cualquier cliente puede tratar y mucho más servicio de RPC de destino que, si bien hace algunas implementaciones de más fáciles, hace limita los clientes a aquellos que pueden tratar con la implementación de RPC específica.

Answer 3

GWT-RPC es realmente una mala opción cuando no controla la implementación de los clientes, porque los clientes deben actualizarse cada vez que realice un cambio en sus clases. Esta es una de las razones que llevó a que se desarrollara RequestFactory. Y funcionará como está en Android.

Dicho esto, estoy de acuerdo con Peter Knego: compilar API públicas específicas del protocolo sobre una única capa de servicio.

Además, puede utilizar GSON, Jackson y/o GWT AutoBeans para serializar objetos a JSON.