Hace un par de días leí un interesante artículo sobre los paradigmas de programación web en el blog de Abhijit Nadgouda. Lo encontré bastante explicativo, así que me puse en contacto con el autor para saber si le importaría que intentase traducirlo al español. Una cosa es entender el artículo y otra ha sido tratar de traducirlo al español entero, es más complicado y he tenido varias dudas que supongo que serán típicas en las traducciones de literatura especializada (traducir o no traducir el nombre de determinada tecnología, las siglas que usar [inglés, castellano]), amén de varias expresiones inglesas que me han resultado un poco difíciles de traducir (y quizás el resultado sea un tanto artificioso).
De todas maneras, con el espíritu de traducir un artículo que puede resultar útil a quien se quiera informar sobre el tema, lo he intentado. El resultado es el siguiente, y las modificaciones o correciones que aportéis serán más que bienvenidas!
_________
La Web ha sido la cumbre de las redes, desde los puntos de vista del software y social. Las redes de software llevadas al extremo han convertido la Web en una plataforma de redes sociales, de colaboración, de publicación de contenido como en los medios de comunicación y en plataforma de programación. De todas formas, la Web fue originalmente diseñada para documentos, como una forma de compartir información. Para ser capaces de hacer lo que queramos con la Web, hemos de hacerla programable.
Programando la Web
La Web es programable hoy en día. Puede ser programada para varios propósitos, algunos de los cuales han sido mencionados en el comienzo del artículo. Esta programabilidad deriva de los maduros principios genéricos del software. Se necesita una arquitectura, un diseño y una implementación. El software genérico de programación ha pasado por muchos cambios, algunos de los cuales pueden ser calificados como mejoras. Desde los estilos de programación como la programación estructurada la atención se ha desplazado hacia la arquitectura y el diseño, produciendo técnicas como POO y las nuevas arquitecturas Ágil y «Model Driven«. En líneas similares, hoy en día la Web está llena de incipientes arquitecturas y aproximaciones. Reflexionemos sobre algunas de ellas.
Servicios
El concepto de servicio fue creado para tratar de hacer hincapié en las loose couplings y en las relaciones cliente-servidor. El software anterior a la Web estaba normalmente atado al hardware y asociado a plataformas. La Web, siendo tan abierta y ubicua, no puede permitirse hacer eso. La Web fue creada para compartir, sin tales restricciones. De ahí vino el concepto de servicio. Un servicio es una función con un objetivo, sirve a todos los clientes sin ninguna restricción en sus detalles de implementación.
Arquitectura Orientada a Servicios (AOS, SOA en inglés).
Tal colección de servicios llevó a que los clientes pudiesen aprovechar la denominada como Arquitectura Orientada a los Servicios. Estos servicios se comunicaban unos con los otros, algunos colaboraban y otros trabajaban autónomamente.
Para ser capaces de establecer una etapa de entendimiento, los clientes tenían que obedecer los protocolos mencionados en el servicio. Los más populares eran XML-RPC y SOAP. Se centraban en abstraer la Web para aplicaciones y dominios. Un acercamiento distinto fue lleado a cabo con REST, que se centraba en usar la Web tal y como es, siguiendo sus principios básicos.
La ventaja de la AOS era que ahora los negocios podían escoger entre distintos servicios sin ser entorpecidos por la tecnología o por límites organizacionales. Ni las definiciones ni las especificaciones de las AOS estaban limitadas por la Web o dependían de ella. La AOS podría permitir interesantes mezclas e integraciones. El Software como un Servicio (Sofware As A Service, SaaS está completamente basado en esto y ha sido capaz de introducir el concepto de «subcontratación análogica» (analogical outsourcing) a la empresa.
De todas maneras hay algunas desventajas clave en esta aproximación. La mayor está en el esfuerzo para ser una plataforma agnóstica y portable, hundiendo a las AOS bajo una capa de especificaciones. Incrementalmente se hace difícil y costoso el ser capaz de cumplir con los protocolos y hablar con un servicio. Otra desventaja, que no tiene por qué ser grave a veces, es que los servicios no son descubribles. El conocimiento de los servicios es necesario para poder usar el servicio que proporciona un directorio de servicios. Dado que la Web es ilimitada por naturaleza, es imposible mantener tal directorio. Esto hace los SOA menos accesibles.
Arquitectura Orientada a la Web
Para hacer la AOS más ligera y más popular llegó la AOW. Básicamente es un subconjunto de AOS que recomienda REST antes que homólogos más pesados como SOAP. La filosofía de REST es diferenciar entre la programación en red y la programación de escritorio, haciendo más simple su uso con lo anterior.
AOW es mas personalizable para la Web al incluir REST. Y especializándolo puede deshacerse de las pesadas abstracciones que lo hace incluir todo.
Arquitectura Orientada a Recursos (AOR)
Éste es un acercamiento radical, desde el punto de vista de la AOS. Alex Bunardzic introdujo la AOR. Mientras que la AOW es conceptualmente suave, la AOR es una rebelde con causa. Alex señala que el concepto de servicios no debería ser aplicado a la Web. Como se menciona antes, los servicios no pueden ser descubiertos y es imposible mantener un catálogo. Aquí es donde va en contra de la Web, la AOR cree que la Web es explorativa por naturaleza.
Por la unicidad de la Web como medio, la única abstracción que le hace justicia es el recurso. La Web es una colección de recursos. Estos recursos son astronómicamente diversos, y sería matemáticamente imposible mantener una apariencia de un inventario razonable de los recursos de la Web.
…
Cada recurso en la Web, no importa cúan único o complicado sea, obedece un protocolo. Este protocolo tiene tres aspectos resaltables, éstos son:
- Cada recurso conoce cómo se representa a sí mismo al consumidor.
- Cada recurso sabe cómo hacer una transición de un estado a otro
- Cada recurso sabe como autodestruirse.
La AOR es mas un paradigma que un acercamiento de arquitectura, que considera que los recursos son elementos de la Web. La parte clave, de todas formas, es que pueden ser descubiertos, y una vez que son descubiertos pueden representarse a sí mismos. No hay un requerimiento de conocimiento previo del recurso para establecer una conversación, al contario que las habilidades cognitivas de un servicio en la AOS. La AOR está completamente basada en REST y aprovecha sus ventajas – simplicidad, conocimientos técnicos mínimos y URI para cada recurso. El uso de elementos básicos de la WWW original hace que sea fácil que dos recursos se comuniquen.
La única desventaja que le veo a la AOR es que está bien definido para la Web. Aunque puede haber implementaciones análogas en otras áreas, así como AOS no está conceptualizada en plataformas no-Web. Hay nuevos desarrollos apareciendo en esta área, pero aún no está tan maduro como la AOS.
Epílogo
Si se analizan, todos estos acercamientos se centran en tener un interfaz estandarizado.La AOR es más simple que la AOS, y usa los hipervínculos efectivamente para alcanzar una base más sólida. Pero si eso es un requisito será determinado por las necesidades de la Empresa.
¿Como desarrollador de software qué me interesa de todo esto? Bien, estos paradigmas están a punto de definir la dirección hacia la que la programación Web se dirigirá en el futuro. La que domine sobrevivirá. De todas maneras, para ser dominante tendrá que demostrar ser leal a la Web y a sus negocios. Si las dos coexisten, será crítico identificar la aplicabilidad de cada una de ellas. Si no, habrá que prepararse para manejar sus desventajas. De cualquier forma, esto afectará al negocio en el que sean usadas. Y con la Web jugando un papel importante, ¡este impacto no debe ser ignorado!
Referencias del autor:
_____
Por cierto, el post lo descubrí vía menéame.
