Un empuje a REST

Hace ya algunos meses desde que escribí por última vez acerca de conveniencia de utilizar REST dentro de las aplicaciones empresariales Sobre REST como alternativa válida a SOAP para la invocación de servicios mediante HTTP . En el post ponía especial relevancia en la carencia de estándares de seguridad para los servicios web expuestos según el paradigma de REST comparándolas con los servicios web más tradicionales que utilizan SOAP como protocolo de comunicación y WS-Security como estándar de seguridad. Hoy he leído un artículo que me ha llamado la atención, más que nada porque está escrito por un arquitecto de Oracle que, tras la adquisición de BEA, se ha convertido en el mayor referente en el middleware de integración. Este es el artículo en cuestión Building a RESTful Enterprise Integration... En éste detalla el cómo realizar implementaciones e invocaciones de servicios REST utilizando productos de la familia Oracle/BEA, lo que no deja de ser un guiño a este tipo de tecnología.

He vuelto a buscar información sobre los avances que se han hecho sobre los “servicios REST” en lo que a seguridad se refiere y he visto que se ha avanzado muchísimo al respecto. Amazon apuesta por el estándar HMAC tal y como se refleja en estos links: HMAC-SHA1 Signature, Authenticating REST Requests.

Esto da qué pensar. Como todo en la industria del Software, si hay empuje comercial (y económico) para impulsar una nueva tecnología, ésta tiene todas las garantías de triunfar. Si Amazon, todo un referente en el mundo del Cloud Computing y SAAS, con lo que de integración conlleva, apuesta por REST… Oracle/BEA se muestran dispuestos a trabajarla y, cuando menos a tenerla en cuenta… ¿Saldrá REST alguna vez del mundo "OpenSource"/académico más marginal del que proviene?¿Estaremos ante el nacimiento de una alternativa seria a los estándares WS* para las aplicaciones empresariales?

¿Buenas plataformas o buenos servicios?

Los que tenemos dentro de nuestros quehaceres diarios tareas más asociadas con la tecnología, nos preocupamos siempre por intentar tener para nosotros mismos (y poder proporcionar a los demás) las mejores herramientas y plataformas que permitan construir servicios mejores y de mayor calidad. No obstante, nuestro trabajo termina siendo frustrante en muchas ocasiones porque los servicios finales que se realizan utilizando estas herramientas son muy pobres y parece que el esfuerzo en elaborarlas ha sido en vano. Con el tiempo, se terminan utilizando de mejor modo pero, para cuando esto ocurre, la tecnología ha dado un giro y las nuevas plataformas y herramientas son mejores quedando las que ahora estábamos utilizando obsoletas.

Cuando cambiamos de interlocutores y preguntamos a los “desarrolladores del negocio” su opinión sobre las herramientas con las que cuentan, muchos de ellos responden que éstas son muy pobres. Con unas herramientas mejores serían capaces de proporcionar al cliente/usuario servicios más potentes y de mayor calidad. La visión cambia, condicionando la calidad de los servicios ofrecidos a las herramientas con las que se cuenta.

Nadie está conforme y tiende a culpar a la otra "sección" del mal resultado de su trabajo. Los técnicos no ven lucido el suyo por la pobre y/o mala utilización de las plataformas que han desarrollado y los "de negocio" aducen una mala plataforma a la mala y pobre calidad de los servicios que pueden ofrecer. Cierto es que con una navaja, un buen artesano es capaz de construir cualquier utensilio. Pero, por otra parte, teniendo las herramientas adecuadas no es necesario ser un artesano de 10 para conseguirlo y los de 5 también son capaces de obtener algo más o menos aceptable.

¿Cuál de los dos mundos tiene más razón? Yo creo que ninguno de ellos tiene la verdad absoluta. Son verdades complementarias.

Los técnicos muchas veces no hablamos lo suficiente con los que deben desarrollar el negocio y a la inversa. No es que hablemos en lenguajes diferentes, sino que nos obcecamos en seguir viéndonos desde la distancia cuando lo natural sería estar codo con codo trabajando. Los primeros para proporcionar las herramientas que sirvan a los segundos a conseguir sus propósitos.

¿Hasta cuándo seguiremos trabajando de este modo apartheid que, aun no siendo estéril, no dista tanto de serlo en muchas ocasiones? ¿Es que nadie derribará nunca esa barrera artificial que separa los dos mundos?

Elección de un "Java Persistence Framework"

La gran parte de los desarrollo que hoy se realizan en J2EE tienen como objetivo final el tratamiento de datos, estándo éstos almacenados habitualmente en una Base de Datos relacional. La transición desde el mundo relacional hasta el de la Orientación a Objetos es un viaje que no tiene por qué ser sencillo. Normalmente, partiendo de un modelo de datos normalizado, se tiende a generar un objeto contenedor de datos que se encarga de la persistencia y mapeo de datos contra el Modelo de Datos. Estas "reglas no escritas" suelen servir para la gran parte de los desarrollos y lo que suele realizarse es definir el típico DAO que contiene la información de select, update y delete contra la/s tabla/s de BBDD que tienen asociados.

Hasta aquí todo suele funcionar, sobre todo cuando los objetos son simples que no guardan relación unos con otros. Pero existen casos en los que la generación de un DAO puede traer problemas:

- La generación del DAO es manual, lo que implica que la posibilidad de fallo es elevada a en la programación. Además, las "utilidades" de programación que ayuden a la generación de DAOs es más bien escasa.

- El control transaccional de las instrucciones con la BBDD tiene que estar controlado en un nivel superior en el caso de que exista relaciones entre objetos.

- Para muchos, programar es un arte, y hay artistas que la simple construcción de un DAO pueden hacerla lo suficientemente compleja como para que el mantenimiento de la aplicación se complique sobremanera.

- El mecanismo manual no tiene per se funcionalidades de cacheo, clustering, etc... Si se quieren hay que hacerlo.

Es por las razones anteriores por las que es interesante la adopción de un Java Persistence Framework que, con tareas muy simples de configuración o desarrollo permitan al desarrollador aislarse del mundo relacional y centrarse en el de objetos. De hecho, existe multitud de artefactos que permiten la generación de las configuraciones y objetos necesarios para el mapeo objeto-bbdd. Este artículo Adopting a Java Persistence Framework: Which, When, and What? creo que hace una comparativa bastante interesante de los 4 frameworks de este tipo más usados (incluyen JPA por ser el estándar de referencia, no por que se utilice ampliamente), aunque hecho en falta un análisis más profundo de Castor, Kodo e iBatis.

Mi recomendación a este respecto resume mucho lo anterior:
- Si quieres algo rápido, estándar y no quieres tener dependencia de estar desplegado en un servidor de aplicaciones de EJBs --> Hibernate es tu opción (sobre todo si utilizas Spring como framework de Desarrollo)
- Si tu problema no es el de los recursos y quieres delegar en el Servidor de Aplicaciones la gran parte de las operaciones --> utiliza los EJBs de entidad. Sobre todo en la versión 3, en la que se mejoran muchos aspectos, sobre todo la facilidad a la hora de programar.

De todos modos, no es oro todo lo que reluce y, en muchos casos, seguiremos teniendo que utilizar sentencias SQL mediante JDBC. Las señoritas, SELECT, UPDATE y DELETE están algo más maquilladas, pero siguen estando ahí. Aquellos que no les tenían simpatía podrán verlas menos a menudo, pero no les recomiendo tener una mala relación. Terminarán quedando para tomar un café antes de lo que imaginan.

Sobre REST como alternativa válida a SOAP para la invocación de servicios mediante HTTP

Hoy he estado leyendo información sobre REST (REpresentational State Transfer http://es.wikipedia.org/wiki/Representational_State_Transfer ) en su relación más directa con la invocación de servicios por el protocolo HTTP. Básicamente, se trata de la invocación de servicios simplemente a través de una invocación a una URL conocida enviándole los parámetros que se precisen.

En este post me gustaría exponer las conclusiones a las que he llegado en mi “muy-por-encima” aproximación a este nuevo estándar.

Exposición de funcionalidades a través de REST

Los servicios expuestos a través de REST no precisan de un descriptor como podría ser un WSDL para el caso de los Web Services. Esto es debido a que, desde su diseño, contemplan los siguientes principios básicos:

• Todos los “ítems” expuestos deber estar identificados, tener un ID único que los diferencie del resto. Un ID perfectamente válido podría ser una URI para cada uno de los “ítems de negocio” sobre los que se pueden invocar servicios. Ejemplos de esto podrían ser: peticiones, productos, clientes, etc.


• En el caso de “ítems” compuestos, los elementos componentes deberían a su vez ser presentados por su identificativos – URI (algo, según mi parecer, nefasto desde el punto de vista del rendimiento para la mayoría de los casos, porque imposibilita recoger toda la información necesaria en una única llamada para ciertos escenarios). Un ejemplo para este caso podría ser el siguiente:
  



• Hablando ya del mundo de la Orientación a Objetos, y relacionando los ítems como objetos, los métodos a implementar dentro de los mismos deberán ser estándares y corresponderse con los “verbs” del protocolo HTTP: GET, PUT, POST y DELETE. Esto se debe principalmente a la carencia de descriptores claros de las funcionalidades que se pueden llevar a cabo. Esto no obliga a implementarse estas funcionalidades para todos los objetos. Esto puede obligar, desde el diseño, a pensar sobre esta filosofía ya que esta restricción puede obligarnos a la creación de un mayor número de ítems/objetos de los que sería estrictamente necesarios en la programación OO. Este problema desaparecería con la utilización de Web Services con varios métodos que podrían actuar sobre uno o varios objetos.

• La comunicación con estos servicios debe ser sin estado. Stateless. Esta característica busca promover la escalabilidad de los sistemas. Un debate parecido podría surgir dentro del universo J2EE en la utilización de los dos tipos diferentes de Session EJBs: sin estado (stateless) o con estado (stateful).
  Para que esto sea posible, en el diseño de los servicios éstos han de definirse como “idempotentes” y, en muchos casos, esto no es trivial. Incluso me atrevería a decir que imposible.La carencia de estado conversacional, hace que, en aquellos casos en los que sea necesario, éste deberá ser gestionado en el cliente.

Recomendación

Creo que REST, en su vertiente más pura, es una alternativa válida para la invocación de servicios que no tienen especiales requerimientos de seguridad, transaccionalidad, etcétera. Alguno de estos ejemplos podrían ser la interacción con sindicadores de contenido RSS o el acceso y publicación de contenidos en un Blog. No obstante, hay algunas empresas referentes en lo que ha venido a denominarse como la Web 2.0. Son los casos de Amazon (http://www.amazon.com/AWS-home-page-Money/b?ie=UTF8&node=3435361 ), eBay (http://developer.ebay.com/developercenter/rest/ ) y Yahoo (http://developer.yahoo.com/ ).

Además, los principales frameworks de Web Services de Java, como es el caso de Axis 2, ya se declaran “REST compliant”. De hecho, aquellos que lo cumplen lo marcan como un elemento diferenciador del resto. Esto puede hacer pensar que, posiblemente, REST deje pronto de ser una tecnología marginal en cuanto al uso para pasar a ser una alternativa más seria al hoy por hoy todopoderoso SOAP.

No obstante, la posibilidad de exposición de funcionalidades por REST no hay que perderla de vista. Tiene ciertas ventajas que residen básicamente en la simplicidad de su uso. Por el contrario, existen ciertos aspectos ya resueltos por los diferentes estándares de los Web Services que son necesarios para multitud de escenarios de negocio. Para los casos en los que la interoperabilidad y los requerimientos transaccionales o de seguridad (amén del resto ya cubierto por los diferentes estándares WS*) no sean triviales, creo que SOAP hoy en día tiene la madurez y el apoyo de la industria necesario para ser la principal alternativa para la exposición de servicios.

WS-I* un poquito de por favor

Para aquellos de nosotros que estamos dando los primeros “pasitos” en la definición, composición y uso de servicios inter-operables, es de agradecer una pequeña luz en el bosque de las siglas de estándares. En mi caso, los requerimientos funcionales los teníamos claros pero no los estándares concretos que trataban de cubrirlos. Estos estándares nos servirían para una evaluación de los productos concretos en los que basarnos como plataforma de inter-operabilidad.

Este artículo nos sirvió como una buena introducción a los diferentes estándares existentes. Espero que a vosotros también os ayude.

Making Sense of all these Crazy Web Service Standards

Un saludo, navegantes.