#noSOAP

Uno de los primeros conceptos que se aprenden cuando se estudia SOA es que no es lo mismo web services (SOAP) que SOA. SOA es un estilo de diseño de software dirigido a las necesidades de negocio, que sigue unos principios básicos. La mejor prueba de esto es que hay bastantes empresas que tienen decenas o quizás cientos de servicio web (con una implementación estándar de SOAP, WSDL, etc. etc.) y no es SOA en absoluto.

¿Por qué puede ser esto? lo más típico es que tienen una integración punto a punto. Es decir, aunque la comunicación se establezca mediante el servicio web, y por tanto en remoto, hay una relación directa entre el cliente y el consumidor. Por lo tanto, se establece un acoplamiento (si bien es cierto que mucho menor que con otras alternativas ya que es sólo en runtime) entre todos los consumidores y proveedores de los servicios. Imaginaros por ejemplo 100 clientes contra 300 endpoints. Potencialmente desde cada cliente se podría llamar a los 300 endpoints, y no solo, si hacemos un servicio compuesto, desde cada endpoint de los proveedores se podría llamar (potencialmete) a los otros 299. Es fácil de imaginarse la maraña de conexiones que se establecen y la pesadilla de su gestión. ¿que pasa si cambiamos un endpoint de sitio (de servidor)? ¿cuántos cambios deberíamos tener?
En definitiva, está claro que no por tener servicios web perfectamente estándar, se tenga SOA. Para ello es neceario algo más: como el desacoplamiento del punto a punto y que el cliente no sepa dónde se ejecuta el servicio.

También puede ocurrir al revés. Puedo tener SOA sin tener SOAP. El ejemplo más palmario es REST. REST es más ligero y por tanto más fácil de utilizar (aunque también es verdad que tiene menos funcionalidades que SOAP y WS-* relacionados).

Pero incluso no es necesario ir tan lejos como con REST. Se puede tener SOA con otras tecnologías y forma de comunicarse que en un principio no identificamos como SOA.

Por ejemplo, ¿puede un sistema que se basa en el intercambio y transformación de ficheros de texto considerarse como SOA? Pues aunque nos choque en un principio, en mi opinión sí, siempre y cuando cumpla con los principios de SOA por supuesto.

¿Cuáles serían estos principios aplicados a un sistema de este tipo? veamos dos de los más importantes brevemente:

Desacoplamiento: es necesario evitar la integración punto a punto. Por eso es necesario tener una capa intermedia entre el cliente y el servidor que actúe de intermediario y evite que el consumidor y el proveedor dialoguen directamente. En una arquitectura clásica esto se implementa mediante un ESB. Sin embargo, no hay que olvidar que un “bus” antes de nada es un patrón de diseño que persigue precisamente esto. Es posible implementar el patrón de diseño Bus sin un ESB.
Contrato bien definido: aunque estemos hablando de intercambiar ficheros, podemos tener una definición de interfaz o metadatos del tipo de fichero que estamos tratando. Por ejemplo, podría ser un fichero XML que describa los campos que contiene el fichero (de longitud fija, con separador de campos, etc. etc.)

En conclusión:
Por lo tanto, creo que de la misma manera que se está popularizando el concepto de noSQL en relación a los gestores de persistencia. Ojo, que no significa NO SQL, si no Not Only SQL. Es decir, tener en cuenta que en determinadas ocasiones es mejor un repositorio no relacional (como el usado por Amazon, Google, Facebook, etc.) que uno relacional (como Oracle o DB2).
Pues bien, creo que tendríamos que pensar en el noSOAP, es decir, not only SOAP. Hay ocasiones en que por la naturaleza y casuística del problema es mejor implementar SOA (por supuesto) pero no con SOAP, si no con otras aproximaciones (y no me refiero solo a REST).

Anuncios