Publicitando SOA

En el sitio de Tibco, en la imagen central, hay una pestaña que dice "SOA". Al seleccionarla, aparece un recuadro con una serie de declaraciones graciosas sobre SOA: primero, una serie de personas anónimas pelean por la atención del usuario, y en el portafolio de uno de ellos se lee: "Muchos vendors ofrecen una solución SOA". Luego, explican: SOA --> Same Old Approach. Aparece a continuación una persona y a su lado pasan rápidamente gabinetes que dicen SOA, al estilo de Matrix. "Hay mucho SOA allá afuera". "Necesitas alguien que tenga blood, sweat and years".
Hay tres o cuatro pequeños episodios similares en corriendo uno tras de otro, en el que ofrecen entre otras cosas varias acepciones de SOA: Sell Old Applications, Sad Opportunistic Attempt, Seriously Over-Advertised, Shovel On Adjectives,.. Cuando muestran imágenes que representan las soluciones SOA de la competencia, le ponen siempre un asterisco; el asterisco lleva a una letra pequeña que empieza corriendo lentamente y acaba a toda velocidad, y que dice algo como "Aplican restricciones. No se garantiza la interoperabilidad con productos que no cumplen con las especificaciones de ..."

Me pareció muy buena propaganda, y conociendo a Tibco, seguramente tienen un producto bueno para respaldar su marketing.

Sin embargo, no creo que el quid del SOA esté en
la interoperabilidad. Desde siempre me ha parecido que SOA es una gran idea pero que no puede ser aplicada como panacea: hay muchos puntos todavía "asterisqueables" en las especificaciones de web services, como transacciones, orquestación, autenticación, incluso attachments. Creo que el verdadero problema es crear fácilmente clientes genéricos que consuman los servicios, y que sepan descubrirlos y utilizarlos de una forma sencilla. Creo que antes de comprar una solución SOA se debe averiguar si es SOA-Server o SOA-Client o ambas, y qué tipo de generación de código utiliza. En mi mente, el SOA-Server siempre tiene que venir acompañado de un Application Server o de un motor de BPM (Business Process Management), de lo contrario básicamente te están dejando a ti la tarea de hacer deploy manual de los servicios generados. Supongo que existirán herramientas que sepan hacer este deploy en multitud de servidores, pero me parece que, a menos que siempre utilices el servidor preferido por tu vendor, corres el riesgo de que, cuando las cosas no funcionen o se caigan, te encuentres con dos compañías apuntándose con el dedo entre sí y tú enmedio sintiéndote miserable.

He visto muchas soluciones que convierten en web service una clase cualquiera de Java (un POJO) y me parece que es suficientemente sencillo hacer esto, pero en cuanto a la generación de clientes de web services, es decir, de programas que sepan consumir esos web services, tienen demasiadas deficiencias: generan código repetitivo e ininteligible, crean clases "helpers" al por mayor, no utilizan soluciones genéricas y se parecen demasiado a un EJB (en el mal sentido). En un proyecto en particular en que estuve, dos equipos tuvimos que hacer la integración con una nueva interfase (web services, por supuesto) hacia el sistema central. El otro equipo utilizó la generación de código del WebSphere Developer Studio, y yo me limité a programar un cliente genérico basado en Axis. La interfase consistía en ocho o nueve servicios, y mi solución quedó implementada con tres clases y un archivo de configuración (además de las librerías necesarias); la otra solución la vi en su forma final y utilizaba unas 100 clases, más o menos 10 por cada servicio. Cada vez que creaban un cliente para algún servicio en particular, echaban a andar el wizard y ¡voilá! quedaba mágicamente funcionando el código. Claro que todavía hacía falta integrarlo con sus propias clases, pero eso es irrelevante; lo interesante es que conforme se fueron agregando servicios al sistema central, me llamaban para preguntarme "¿Cuándo puedes venir para que nos crees el código que hace falta? Es que ya hay tres nuevos servicios..." Yo les decía que no hacía falta, que simplemente abrieran el archivo de configuración, agregaran una línea que apuntara al WSDL, otra en la que especificaran el nombre del método a utilizar, y cambiaran el JSP que enviaba los datos (lo hice como JSP porque no tenían idea de qué era Ant y no estaba dispuesto a "migrar" mi proyecto al Developer Studio aquél). Para el otro equipo, siempre hacía falta que fuera un consultor un par de días a hacer los cambios en las clases y echar a andar nuevamente el wizard. Al cabo de un par de iteraciones, el cliente les pidió que cambiaran su código para utilizar clases parametrizables, porque ya estaba harto de que le cobraran cada vez que hubiera cambiecitos. Y eso, a mi entender, es el valor principal de una solución SOA: poder generar fácilmente la infraestructura para consumir servicios con nada o poco de código, sin tener que ensuciarse las manos con el parser de XML ni la especificación de SOAP, o preocuparse por las versiones de las librerías.

Claro que siempre es útil saber someramente cómo funciona la solución, porque siempre sale un pelo en la sopa: la librería que utiliza tu solución es incompatible con tu app server, la versión de Java es distinta, o la versión de SOAP es la que te ocasiona problemas, el WSDL no es visible desde internet (o sí es visible pero el servicio no), etc...
(Y por cierto, para hacer debugging de web services no hay como el TCPMon de Axis - org.apache.axis.utils.tcpmon- ).

Así que ya quedamos en que no hay sustituto para estar informado y saber más o menos cómo "trabaja" la solución, pero el ideal es por supuesto llegar a un nivel de abstracción y estabilidad que no tengamos que preocuparnos por detalles, así como ocurre mientras escribo esto, y no estoy pensando en si mi Centrino Dual Core 2 estará dividiendo correctamente las tareas en procesos simultáneos virtuales, o si el Firefox no tendrá algún problema con cajas te texto de más de 1,500 caracteres...

Y por cierto, ya le corto aquí, para no hacer corajes si en efecto alguna de estas cosas está funcionando mal. Uno nunca sabe.