Espacio SOA

Creo que decir aquí, que las empresas se están interesando por SOA, no sería nada nuevo… hoy en día, cada vez más, las empresas se interesan por SOA, sus aplicaciones prácticas; y de hecho, la mayoría de las grandes empresas españolas están apostando cada vez más por soluciones y arquitecturas de este tipo.

El problema viene a veces en la manera de hacer rentable las fuertes inversiones que se realizan para acometer proyectos de este tipo. Ya a principios de año, apostaba por AJAX como algo realmente importante dentro de este mundo; ya que es la cara más facil de mostrar de estos proyectos (en algunos foros especializados, se habla desde hace tiempo de AJAX + SOA = la Próxima "Killer App").
De hecho, a lo que deberían tender estas arquitecturas en un futuro sería a algo del tipo SOA Internet… Una SOA de Internet, con multitud de servicios web disponibles (independientemente de que fueran de pago o gratuitos) y herramientas que permitieran su "visualización" por medio de composición de los mismos y AJAX como cara principal…

El motivo principal de plantear AJAX en este juego, radica en que SOA no deja de ser un middleware; una serie de componentes que se comunican y ofrecen servicios de manera más o menos unificada. Pero a la hora de la verdad, la forma más facil de consumir estos recursos es por medio de clientes que sean capaces de invocarlos.

Las aplicaciones web más tradicionales, han sido hasta ahora los que han jugado ese rol de cliente. Pero dada la explosión y éxito de las aplicaciones web (principalmente motivado por la Web 2.0) está claro que el futuro pasa por AJAX y sus distintas formas.

Una vez que estamos convencidos de que AJAX va a ser un punto importante en nuestro desarrollo, tenemos que prestar atención a la manera en que se integra con el resto de componentes de nuestra arquitectura.

Una forma (en mi opinión erronea) de integrar AJAX con servicios web de una arquitectura SOA, es por medio de lo que se llama "Cliente/SOA": básicamente consiste en realizar peticiones a los distintos servicios web de que dispongamos desde la parte cliente (esto es desde los desarrollos de AJAX que realicemos).
Esto, creo que es erróneo, ya que nos hace perder toda gobernabilidad sobre la arquitectura; dicho control pasa a ser propiedad del cliente y eso es algo que no deberíamos permitir.

La forma correcta sería tratar todas las peticiones de AJAX a través de un canalizador de las mismas (a modo de firewall) que permitiera tener el control y enrutarlas según los requerimientos que tuvieramos. Esto podría hacerse perfectamente con un ESB (un bus de servicios) que permitiera aceptar peticiones HTTP desde la interfaz (o incluso la parte servidora de la interfaz, como suele ser) y redirigiera las peticiones según fuera necesario a los distintos servicios web que tuvieramos disponibles (incluso podría aplicarsele políticas de seguridad, auditorias, transformaciones de datos, etc…).

Yo, personalmente creo en este modelo, y de momento ya ando metido en un proyecto propio con ambos jugadores en el terreno de campo (tanto AJAX como SOA). Pero bueno, ya os ire contando más cosas; porque de momento no puedo decir mucho…