abbey-483932_640

Comunmente se asocia la palabra SOA a un producto concreto de un fabricante. Me refiero por supuesto al ESB que los mayores proveedores del sector nos han venido ofreciendo desde hace ya algunos años: IBM, Oracle, Software AG.

Nada más lejos de esto. SOA es un paradigma de diseño. Es más, cualquier “cosa” que cumpla con los 8 famosos principios de Thomas Erl y compañia será SOA. Obviamente no se dice nada de que para conseguir esto haga falta un producto concreto como el ESB ni nada parecido.

Así pues, ¿es posible hacer SOA “sin SOA?. Y entendamos esta pregunta como si si puede tener un sistema SOA sin los productos que normalmente asociamos a esto, la respuesta, por supuesto, es que sí.

¿Cual sería el sistema SOA? Bueno, bonito y barato, y también, por que no, muy ligero y con un gran rendimiento.

Vamos a pensar por ejemplo en un conjunto de servicios REST (decenas o cientos) que podemos usar en la empresa. Por supuesto, este sistema empresarial tiene que cumplir los 8 principios:

El tema de los contratos de los servicios REST es un tema complicado por el momento porque no hay una estándar que se use masivamente.
Además, no hay que olvidar que lo de “estandarizados” se refiere a que en los posible, los servicios usarán los mismos tipos de datos. Es decir, si tenemos un tipo “cliente” hay que procurar que todos los servicios usen el mismo tipo para evitar las excesiva transformación de datos en tiempo de ejecución.

En resumen, un sitio donde se recoja el contrato de los servicios, que puede venir expresado en lenguaje natural con ejemplos de mensajes de entrada y salida sería necesario. Este sitio podría hacerse por ejemplo con un servidor de wordpress. Algo sencillo, potente y sobre todo barato.

Lograr unos servicios con bajo acoplamiento viene “de caja” si usamos servicios REST. El uso del protocolo HTTP nos permite tener un bajo acoplamiento.

Por otra parte para que los clientes de los servicios no sepan la dirección donde están desplegados los servicios necesitamos un mecanismo como un registro de servicios. Esto se puede hacer por ejemplo utilizando el mecanismo de DNS que tenemos en la red, o algo menos exótico, utilizar el mismo servidor wordpress al que me refería antes para publicar un sencillo servicio al que se le pase el ID del servicio y nos devuelva la URL del mismo.

Si tenemos los servicios bien definidos siguiendo las buenas prácticas de REST y el contrato de los mismos accesible en una herramienta como nuestro registro de los servicios, podremos ocultar los detalles de la implementación interna del servicio logrando una total abstracción.

Obviamente para que un servicio sea reutilizable tiene que ser lo suficientemente agnóstico y genérico para servir en más de un escenario. Es fundamental que tenga el grano apropiado, ni muy de bajo nivel ni muy genérico tal que sólo sirva para un fin concreto.

De nuevo, este principio tiene más que ver con el diseño y nuestra capacidad de organizarnos internamente que con la tecnología.

Un servicio REST puede cumplir perfectamente el principio de autonomía. Al invocarse de manera remota puede estar escrito en cualquier lenguaje, con cualquier base de datos y ser complemente autónomo en cuanto a su ámbito de ejecución.

Por supuesto, los servicios tienen que implementarse sin estado. Aunque parezca mentira, es muy habitual encontrarse con servicios web que mantienen estado, incluso en los que hay que hacer login/logout para usarlos ¿¿¡¡!!??.

Para lograr que los servicios tengan capacidad de descubrimiento, es necesario tener en cuenta las dos  vertientes, en tiempo de desarrollo un servicio tiene que ser descubrible por las personas, para que lo puedan incorporar en su diseño. Por otra parte, en tiempo de ejecución, tiene que ser descubrible por un programa (el cliente del servicio).

De nuevo, gracias a nuestra herramienta de registro, la implementación con wordpress nos cubriría ambas vertientes. Tendremos por ejemplo, una página o un “post” por cada servicio. Un servicio de consulta por HTTP nos servirá para este propósito en tiempo de ejecución.

Evidentemente un servicio REST puede ser compuesto con otro, no hay más que ver cualquier mashup que se publica en internet.

Prácticamente cualquier programa informático puede invocar a un servicio mediante HTTP. Además los servicios REST pueden utilizar diferentes formatos de representación (puede ser XML o JSON). Debido a esto, es la forma más interoperable que conozco.

En definitiva, podemos hacer SOA “sin SOA”, es decir, sin comprar una pesada suite de fabricante.

Conclusión

Como conclusión me quedaría con la siguiente: no confundamos SOA con un producto comercial. Se puede hacer SOA sin comprar el ESB más caro y al contrario, se puede tener un carísimo ESB y tener un jaleo descomunal en la empresa en lugar de tener servicios. Para ello, claro, hay que saber usar las herramientas que tenemos y no tratar de hacer un arco de iglesia cuando no hace falta.

Anuncios