La naturaleza del Software

Haciendo un repaso de nuestra historia, me he dado cuenta que llevamos dedicados más de veinte años a la tarea de construir software para clientes privados y públicos de toda naturaleza.

Fundamentalmente hemos desarrollado software de gestión empresarial, pero no solo, hemos dado soluciones a problemas de toda naturaleza. Desde hace ya más de diez años estamos centrados en la consultoría tecnológica y en diseño de arquitecturas de software.

 

Gracias a estos últimos años, empiezo a vislumbrar algunos patrones repetidos en los éxitos y fracasos. Creo que es momento de poner en limpio todo lo aprendido en estos veinte años. Por ello, me siento con ganas de deciros cuales son nuestros diez mandamientos en los diseños de arquitectura:

El software es un negocio y como tal hay que tratarlo

Básicamente, todo lo que hacemos, parte de una necesidad que cubrir, un resultado esperado, un presupuesto asignado que alguien paga y una serie de personas que lo hacen.

Resumiendo, lo que lo primero que tenemos que tener claro en todo proyecto es:

  • ¿Qué vamos a resolver?
  • ¿Cuanto cuesta?
  • ¿Quien lo paga?
  • ¿Quién lo hace?
  • ¿Cuál es el beneficio?

sabri-tuzcu-331970

Si alguna de estas preguntas no tiene respuesta directa, ya hemos fracasado.

 

El software es de naturaleza compleja

Sin lugar a dudas, el software es de naturaleza compleja, tienes que aprender a lidiar con esa complejidad. De igual forma, el cliente y todos los agentes intervinientes en el proceso, también tienen que entender esta cuestión.

johannes-plenio-377226

Si alguien de peso en el proceso productivo no entiende esta cuestión, ya hemos fracasado.

 

El problema a resolver se puede describir perfectamente en una página

Si el cliente no es capaz de describir el problema en una página, es que no tiene claro cual es su problema.

Si después de que el cliente te lo cuente de forma simple, no eres capaz de plasmarlo en una página, es que no entendiste el problema que el cliente te describió.

patrick-tomasso-71909

Si no somos capaces de describir el problema en una página, ya hemos fracasado.

 

Las personas mienten

Cuando conversas con el cliente, analista, jefe de proyecto respecto al problema que quieren resolver, no siempre enfocan bien la descripción de su problema.

Normalmente este mal enfoque se produce por:

  • Desconocimiento del detalle del negocio.
  • Por quererte engañar, mejorando su posición de cara a la negociación.
  • Por no poder o querer contarte ciertas realidades (lo que yo llamo sus miserias).
  • Por intentar dar soluciones técnicas al problema sin disponer del conocimiento tecnológico necesario.

peyman-naderi-379105

Si no descubrimos lo que nos ocultan, ya hemos fracasado.

 

Simple, pero que resuelva

Para que una solución tecnológica perdure en el tiempo tiene que partir de un pequeño producto que resuelva el problema de forma clara (mínimo producto viable).

johannes-plenio-262511

Si no la solución a desarrollar no es simple, ya hemos fracasado.

 

La documentación es una representación de la realidad, no la realidad en si misma

Los documentos que recibes, son una representación de la realidad, no la realidad en si misma. Normalmente, si profundizas un poco verás que la realidad es diferente.

Estos documentos los recibimos de múltiples fuentes; cliente, analista, desarrolladores, operaciones, testing, QA, jefes de proyecto… todos ellos los tienes que poner en duda.

MagrittePipe

Si no somos capaces de encontrar la realidad subyacente, ya hemos fracasado.

 

Programar es el arte de introducir nuevos errores

Cuando picas código, estás añadiendo nuevos errores en la ejecución de tu programa. Ser ordenado y aburrido ayuda a minimizarlos.

Cada línea de tu código es importante, una sola línea puede tirar por tierra todos tus esfuerzos.

Un buen diseño de arquitectura permite la introducción de nuevos errores sin provocar el fallo del sistema. Para ello tienes que determinar cual es el centro del mismo y aislarlo del resto de componentes.

Cuando alguien comete un error en el proceso productivo, no le matarás, más bien harás lo contrario. Le contarás las implicaciones de su error, le ayudarás a mejorar sus habilidades, le reforzarás en sus aciertos y todo ello con la intención de que crezca en el proceso. Un buen profesional del mundo del software es difícil de encontrar y muy fácil de perder.

markus-spiske-109588

Si no somos ordenados y aburridos, ya hemos fracasado.

 

Las modas, modas son

Está muy de moda…

  • NodeJS/AngularJS
  • Cloud/Containers/Micro-servicios
  • AgileXP/Scrum
  • PMP/ITIL
  • DevOps

Son modas… solo unas pocas perduran, otras pocas mutan y el resto perece.

clem-onojeghuo-146651

Aplica las modas en la medida justa, en la medida que sienten bien al proyecto, si nos excedemos, ya hemos fracasado.

Cuantas menos personas conformen el proyecto mejor es la comunicación entre ellas

Cada día más es habitual ver grandes proyectos formados por decenas de personas. A más personas en un proyecto peor es la comunicación entre ellos.

Trocea bien el sistema a desarrollar, que cada grupo se focalice en su parte y evita solapamientos.

Haz responsable del código a los programadores, haz responsable de la arquitectura a los arquitectos, haz responsable de las garantías a QA.

daria-shevtsova-57340

Si no conseguimos un grupo de personas adecuadas para el proyecto, ya hemos fracasado.

Servicios Web – II

Fuente original: http://jordisan.net/proyectos/Autent_y_auth-J_Sanchez.pdf

Con la proliferación de los servicios web en Internet, surgió un problema de relevancia, la autenticación. Los servicios disponibles han crecido enormemente, y la mayoría de usuarios utilizan  múltiples aplicaciones de terceros: por ejemplo, un usuario consulta su correo en un sistema de webmail, desde el teléfono o desde su cliente de correo. También es habitual la participación en redes sociales como facebook, linkedin, tuenti o twitter, etc. La mayoría de esas aplicaciones requieren que el usuario se autentique; es decir, que demuestre de algún modo (habitualmente usando un identificador de usuario único y una contraseña asociada) que es quien dice ser.

Al tratarse de aplicaciones independientes entre sí, en principio cada una de ellas utilizaría  su propio sistema de autenticación y de gestión de datos personales, lo cual implica inconvenientes al usuario cada vez más graves a medida que el número de sistemas que utiliza crece.

Surge la necesidad de conocer cuales son las tendencias actuales respecto a la autenticación y autorización en Internet.

Autenticación vs. autorización

Antes de seguir, es necesario hacer una distinción clara entre dos tipos de servicios ofrecidos por las tecnologías que vamos a describir.

  • Autenticación: consiste en un sistema para certificar que el usuario es quien dice ser; lo más común es utilizar una combinación de identificador de usuario único y contraseña.
  • Autorización: consiste en dar acceso a una serie de recursos a un usuario o sistema (para ello, el usuario o el sistema previamente tendrán que haberse autenticado).

Protocolos y estándares ampliamente adoptados

Una primera solución evidente al problema de la autenticación sería el uso  de algún tipo de certificado personal (basado, por ejemplo, en el estándar X.509) emitido y validado por alguna autoridad central  de confianza. Si bien este tipo de certificados son útiles para gestiones  con determinadas entidades,  no son prácticos en general para el acceso a servicios de Internet. Por este motivo han surgido varios protocolos de autenticación y autorización en Internet.

OpenID

image
El protocolo abierto OpenID, cuya primera versión fue definida en 2005 para su uso en el sitio web LiveJournal, es un protocolo de autenticación federada, y consiste básicamente en que el usuario selecciona un servidor externo (el “proveedor” de OpenID) que va a ser el que va a validar su identidad en un sistema determinado (el “consumidor” de OpenID).

Problemas de OpenID:

  • Complejidad: no se implementa fácilmente.
  • Seguridad: es un protocolo muy vulnerable al  phishing.
  • Privacidad: los proveedores de OpenID tendrán mucha información del usuario.
  • Confianza: ¿quién es realmente el usuario?.
  • Usabilidad: puede ser incómodo  y/o complejo  para el usuario.
  • Adopción: los proveedores de servicios tienen pocos motivos para aceptarlo como autenticación.
  • Disponibilidad: se incrementa la dependencia de servidores.
  • Patentes: no es un protocolo “tan” abierto.
OAuth

image

El protocolo abierto OAuth, a diferencia de OpenID, es un protocolo de autorización; más exactamente, de delegación de acceso; es decir, permite definir cómo un tercero va a acceder a los  recursos propios. Empezó a definirse en 2006 y en 2007 se publicó la primera versión oficial.  El propósito de este protocolo es, pues, que un usuario que tiene determinados recursos en un servidor (el “proveedor” de OAuth) pueda dar acceso a un tercero (el “consumidor”, usualmente un sitio web) a parte o todos esos recursos, sin necesidad de que ese tercero conozca su usuario y contraseña, ya que con esos datos tendría el control total de la cuenta.

Problemas de OAuth:

  • Complejidad.
  • Orientado a navegadores.
  • Seguridad.
OAuth 2.0

imageOAuth 2.0  pretende ser una versión revisada y simplificada de OAuth. Aventaja a la versión anterior en una mayor simplicidad de implementación, y en una arquitectura más robusta y que da soporte a mayor número de plataformas.

Existe cierta confusión sobre si OAuth es o no un protocolo de autenticación de usuario. Estrictamente hablando  no lo es, ya que no define ningún mecanismo  explícito destinado a autenticar la identidad del usuario. Por tanto, cuando se habla del  “mecanismo de autenticación de OAuth”, en realidad  se están refiriendo al mecanismo de autenticación propio del sitio web proveedor de OAuth, que puede ser cualquiera: autenticación http básica, OpenID, etc.

 

Nuevos Protocolos y estándares

OpenID OAuth Hybrid Protocol

Como hemos visto, OpenID y OAuth son protocolos con objetivos distintos aunque complementarios: autenticación de usuario (federada) y autorización, respectivamente. El protocolo híbrido OpenID OAuth  combina ambos sistemas, integrándolos en una interfaz única.

Facebook Connect

Debido al enorme incremento de usuarios y, en consecuencia, de datos personales que ha experimentado Facebook en los últimos años, la compañía lanzó en 2008 su propio sistema conocido como Facebook Connect.  Con ese movimiento, Facebook pretendía posicionarse como repositorio central de identidad de los usuarios en Internet. En la actualidad Facebook parece haber  abandonado Facebook Connect para adoptar el protocolo 2.0 de OAuth.

OpenID Connect

El protocolo OpenID Connect es la última propuesta para reactivar OpenID. Su propósito es redefinir y simplificar el protocolo construyéndolo sobre el protocolo OAuth; de ese modo se aprovecha el trabajo desarrollado para OAuth, que parece  estar  extendiéndose rápidamente, dotándolo de una funcionalidad estándar de autenticación que, como hemos visto anteriormente, no posee.

 

Otros sistemas

Algunos de los grandes proveedores de servicios en Internet han definido, en algún momento, su sistema propio  de autenticación y/o autorización. Sin embargo, la mayoría de ellos están adoptando  estándares  como OpenID y, especialmente, OAuth; es el caso, por ejemplo, de MySpace, Twitter o Yahoo!.

Otro estándar abierto para el intercambio de recursos de identidad es Security Assertion Markup  Language (SAML). Está basado en XML, y su principal propósito es servir de marco para protocolos de autenticación federada. Este protocolo sirve de base para algunos sistemas propietarios de single-sign-on, pero no es utilizado por los grandes proveedores de servicios en Internet.

 

Resumiendo

image

Blog | Tienda

Servicios Web – II

Servicios Web – I

imageHoy hablaremos de la importancia de los servicios web en la informática moderna.

El motivo de empezar esta nueva serie de artículos tiene que ver con el futuro lanzamiento del motor de JavaScript de WebKit fuertemente integrado en Velneo V7 (http://twitter.com/#!/varquitecto). También tiene que ver con uno de nuestros productos en desarrollo, PaaSOS ESB.

No os perdáis esta serie de artículos ya que todos estos conocimientos serán necesarios para exprimir estas tecnologías en esta nueva etapa.

Empecemos por el principio:

Un servicio web (en inglés, Web service) es una pieza de software que utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones.

Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de ordenadores como Internet. La interoperabilidad se consigue mediante la adopción de estándares abiertos.

Wikipedia:http://es.wikipedia.org/wiki/Servicio_web

Guía breve: http://www.w3c.es/divulgacion/guiasbreves/ServiciosWeb

Los web services supusieron una revolución ya que permitieron integrar distintos lenguajes y plataformas (sobre todo a nivel de datos o servicios).

Para comprender el alcance, es importante conocer cada uno de los conceptos que giran en torno a los servicios web. Empecemos por el concepto Web Services Protocol Stack, que no es más que el conjunto de formatos, protocolos y servicios.  Continuemos desglosando los componentes que inicialmente formaron esta pila de protocolos y servicios.

A destacar:

Formato para los datos
  • XML (eXtensible Markup Language): Es un formato, ampliamente utilizado, basado en etiquetas.
Protocolos
  • SOAP (Simple Object Access Protocol) o XML-RPC (XML Remote Procedure Call):
  • Otros comúnmente aceptados (utilizados típicamente en combinación con sistemas de colas distribuidos y transaccionales): HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol), o SMTP (Simple Mail Transfer Protocol).
Metadatos
  • WSDL (Web Services Description Language): Es el lenguaje de la interfaz pública para los servicios Web. Es una descripción basada en XML de los requisitos funcionales necesarios para establecer una comunicación con los servicios Web.

image

Directorio
  • UDDI (Universal Description, Discovery and Integration): Protocolo para publicar la información de los servicios Web. Es un protocolo para meta-directorios de servicios web.
Seguridad
  • WS-Security (Web Service Security): Protocolo de seguridad aceptado como estándar. Garantiza la autenticación de los actores y la confidencialidad de los mensajes enviados.
Optimización
  • MTOM (Optimización de Transmisión de Mensajes para SOAP): Recomendación del W3C.

Y llegó el problema:

XML/WSDL/SOAP es complejo y pesado por lo que una nueva iniciativa REST (Representational State Transfer) fue ganando adeptos en toda la web como una alternativa más simple a SOAP y a los servicios web basados en ella. Varios grandes proveedores Web 2.0 migraron a esta tecnología, incluyendo a Yahoo, Google y Facebook, quienes marcaron como obsoletos sus servicios XML/WSDL/SOAP y pasaron a usar un modelo más fácil de usar, orientado a los recursos.

REST define un conjunto de principios poniendo el foco en los recursos del sistema, cómo se accede a dichos recursos y cómo se transfieren por HTTP.

 

image
 
Los 4 principios de REST

Una implementación concreta de un servicio web REST sigue cuatro principios de diseño fundamentales:

  • Utiliza los métodos HTTP de manera explícita.
  • No mantiene estado.
  • Expone URI’s con forma de directorios.
  • Entrega XML (eXtensible Markup Language), JSON (JavaScript Object Notation), HTML (HyperText Markup Language) u otros.

Los defensores de REST han creído que estas ideas son tan aplicables a los problemas
de integración de aplicaciones como lo son XML/WSDL/SOAP. Pero la verdad es que REST no es la cura para todo, algunas características de diseño de REST no son apropiadas para ciertas aplicaciones.

 

Conclusión:

REST surgió como una alternativa para diseñar servicios web con menos dependencias (más ligeros y sencillos), que su contraparte SOAP+WSDL. De algún modo, REST es la vuelta a los orígenes de la Web, ya que incide en los primeros estándares de Internet, URI y HTTP.

image

http://jelabra.blogspot.com/2007/03/clase-de-soap-vs-rest.html

XML sobre HTTP es una interfaz muy poderosa que permite que aplicaciones internas, como interfaces basadas en JavaScript Asincrónico + XML(AJAX) puedan conectarse, ubicar y consumir recursos. De hecho, es justamente esta gran combinación con AJAX lo que generó el interés por REST.

Blog | Tienda

Servicios Web – I