Primera Definición (Simple): “SOA es la agregación de componentes que satisfacen una necesidad de negocio” (Pallos). O, lo que es lo mismo, SOA es a la arquitectura tecnológica actual lo que “persona humana” es a “persona”. Resulta, pues, que “la nueva ola tecnológica” representa el reconocimiento de la dirección históricamente errónea del software y de sus tecnologías asociadas y, a la vez, el pivote para el aprovechamiento del nuevo enfoque en el ámbito empresarial de negocios/servicios. Así que SOA es… ¡como el vinagre!: Difícil de describir sin probarlo (pero con regusto)

SOA (Service-Oriented Architecture) es el paradigma bajo el que se sostienen las arquitecturas modernas de integración, y supone que el acceso a los servicios debe ser independiente de las plataformas software de desarrollo y explotación de éstos, así que se asume la mensajería [asíncrona] basada en paquetes semiestructurados (como, por ejemplo, en XML) como medio de comunicación inter-sistemas, y exige, por fin, que los servicios para los clientes sean distintos de los otros servicios necesarios para satisfacerlos.

Una cosa es acceder a una página Web dedicada a la información meteorológica [como http://eltiempo.terra.es (que supone la interacción del usuario con una aplicación que le deja navegar, visionar publicidad, etc.)]; y otra cosa es acceder a un servicio Web a preguntar, específicamente, el tiempo que hace en Madrid [de lo que obtenemos una respuesta simple (tanto o más que la pregunta)]. ¡Y aquí se acaba nuestra interacción! Es el equivalente a mandar un SMS y recibir una cancioncita, pero aplicado a cualquier servicio de negocio.

En lugar de ofrecer servicios completos (tipo sitios web) –o además de hacerlo– las empresas han visto (o están viendo o verán) las ventajas de publicar servicios simples que puedan ser utilizados por múltiples dispositivos y sistemas (e incluso combinados por los mismos usuarios o por terceros). Es… ¡El Lego! (otra vez). Pero esta vez… promete.

La idea es vieja (pero la técnica es ahora simple): se trata de encontrar un campo común, un puente, entre los intereses del negocio y las necesidades tecnológicas, y se trata de decidir (como en las conductas sexuales) quién tiene que dar el primer paso; quién impone y quien acepta. Los servicios inteligibles por el dominio del negocio tienen la prevalencia (SOA dixit), y la técnica se ajustará a tales requisitos. O sea: primero se conciben los servicios (la comprobación de una firma digital, las notas de un examen, el estado de un pedido, etc.), y luego se sitúan en una plataforma de servicios adscrita a SOA, y se publicitan.

Hay que buscar aquellos servicios que pueden ser invocados por un usuario final y, a la vez, por organizaciones y sistemas más sofisticados que, en adición, pueden combinarlos en paquetes. Pero los servicios no se encuentran como “requisitos funcionales” de un análisis de negocio, sino más bien como “utillaje” del comportamiento de sus usuarios. Así que hay que cambiar la dirección de búsqueda del negocio y de su imbricación con la tecnología: el servicio se determina por su uso plausible, y su implementación debe esconderse al usuario.

No se trata tanto de un avance técnico como del [re-]conocimiento de que la tecnología no es un fin en sí misma; o que los usuarios son los habitantes de los productos de desarrollo tecnológico. Pero el problema es que tal consciencia se traduce en una actitud de “suavización orientada-al-usuario” de interfaces programáticas difíciles-de-entender. No se suele dar, pues, reconversión de enfoques, sino más bien matización de los existentes. Pero, claro, ¡Esto no parece casar con la idea inicial!

SOA es, en breve, una reacción y… una respuesta al creciente “user empowerment” originado por la explosión Web; pero también una apuesta comercial contra los productos pequeños y los COTS, así como una apoyatura publicitaria para llevar a un nivel inteligible por usuarios no-técnicos los productos de las grandes compañías e instituciones. O sea: SOA en el fondo es buena, pero más en el fondo es sesgada (porque… ¿en quién confiar para saber si se está utilizando apropiadamente?). A no ser que tomemos del acrónimo (pues nada hay más que eso) lo que nos interesa: ¡El interés por lo que el usuario quiere/necesita!

Precisamente porque se evidencia que una idea simple requiere de explicaciones diversas, transparencias y quizás hipnosis y terapia… SOA es difícil de vender para convencer. Pero la realidad es que… ¡no hay alternativa!

Hay que calibrar si los clientes (necesarios) del enfoque SOA podrán abordar su implementación y mantenimiento. Y la respuesta es, mayormente… ¡No!, pues la simplicidad tecnológica es difícil de alcanzar. Y no se trata sólo de proveer las plataformas técnicas, sino de entender la casuística de uso, en diferentes dominios de negocio, de los e-servicios. Porque SOA trata de crear plataformas de servicios simples (accesibles, usables) apoyadas en plataformas técnicas complejas, con suficientes capacidades transaccionales, de brokering y de interconexión; y parece que cada empresa tendría que montar ambas zonas: la de negocio y la técnica (tal vez desaprovechándo ambas, pero sobre todo la técnica). Porque… ¿quién garantizaría el despliegue adecuado de los servicios, su mantenimiento, la privacidad de una posible confederación; su base técnica, al fin?

Claro que, al final, no se sabe si SOA está asociado a… ¿qué? ¿A Servicios Web? ¿A XML? ¿Al negocio electrónico? ¿A un buen montón de nuevos acrónimos? En realidad se trata tan sólo de un concepto para el que la implementación –su realización práctica– puede ser… ¡cambiante!, aunque interesa conocer el estado actual de los productos de soporte del esquema SOA.

Empezaremos con… ¡Servicios Web! Examinemos por tanto, en tal sazón, la estructura de un artículo técnico actual: “XML bla bla bla bla bla SOAP bla bla bla bla SAX bla bla bla bla WSDL bla bla, re-XML bla bla Java bla bla BPEL4WS bla bla bla bla bla UDDI bla bla bla XML bla bla bla WS-T bla bla bla WS-C bla bla XLANG, bla bla bla WSCM bla bla bla bla XOCP bla bla bla WSXL bla, bla bla bla bla bla WSFL bla bla bla. Web Services bla bla bla bla bla BTP bla bla XML bla bla bla bla XML bla XML bla XML bla XML bla XML bla”. Y, peor, la definición formal de SOA: “A Web Service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via Internet-based protocols [W3C (WSDL 1.1)]”; o su traducción simple a lenguaje práctico: “A Web Service bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla blabla bla bla bla XML bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla blablabla bla bla bla bla bla XML bla bla bla bla bla bla bla bla bla bla bla bla bla bla [W3C (WSDL 1.1)]”; o, por fin, su definición negocial: “A Web Service bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla blabla bla bla bla XML bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla blablabla bla bla bla bla bla XML bla bla bla bla bla bla bla bla bla bla bla bla bla bla [W3C (WSDL 1.1)]”. Nos queda poco más que “Servicios Web”. Pero hay más, claro.

Web Services son componentes software identificables en X-net que, en combinación flexible y con sliding computacional, pueden descubrirse y componerse para proveer servicios especializados a clientes heterogéneos. (Hacer caso omiso). O sea: un Web Service ha de ser... ¡Listo!: la petición ha de ser tan simple como la respuesta, así que la composición flexible, como en Tecnología de Objetos y Componentware, obliga a una absoluta independencia de las respuestas y favorecerá esquemas de composición y fusión en clientes.

Se traza una meta, lejana o no, y en lugar de aprovechar el proceso, hasta alcanzarla todo es oscuridad. Es como ir en coche por un túnel en lugar de disfrutar del paisaje y del trayecto. Este efecto se conoce como “Carencia de Vida Social de la Información”, y define un problema que representa una variación del Efecto Martillo (aplíquenlo a XML o a tecnologías parejamente simples y desaforadamente empleadas): Cuando se le regala a un niño un martillo descubre que todas las cosas necesitan ser martilleadas.

¡Zanjemos el e-Tema! Nos importa muy poco si los paquetes de intercambio/invocación de e-servicios son XML o binarios, o si se cumplen estándares WSDL o UDDI, pues lo importante es la definición de los servicios y su soporte. Claro que… ¿Quiénes somos “nosotros”? Pues los prescriptores o los garantes de los servicios mismos. Y lo anterior no es sino el credo comercial de los nuevos servicios telemáticos. Web Services son e-Servicios accesibles vía protocolos normalizados Internet (…y punto.). e-Servicios son servicios disponibles, con segmentación de perfiles, en una plataforma de multi-acceso telemático [y punto, también].

La base de una plataforma de e-servicios es que ya no se pueden dar sistemas X-Céntricos (ERP-céntricos, CRM-céntricos, etc.), sino que éstos se considerarán –directamente– como “sistemas heredados” (sean nuevos o viejos o pendientes de instalación o parametrización) y se les dotará de adaptadores para el nuevo esquema. Esto supone que la necesidad de solidez y garantía en la plataforma middleware se impone a los criterios de elección y uso de paquetes esenciales, lo que, al fin, significa que el negocio se ha desplazado hacia las áreas de control de e-servicios. Claro que podría alegarse que la mayor eficacia se alcanza con la máxima dependencia, pero la verdad es que la eficiencia a ultranza genera la máxima ineficacia (ejemplo del Puzzle de Números Móviles: ¡pregúntennos!). Y es que la Ley de Moore y otras garantizan que la indirección software de servicios no afectará al comportamiento de sus usuarios, pero sí se apreciará sobremanera la eficiencia y simplicidad operativa de la plataforma de base (la portadora de los e-servicios); así que… ¿quién será su garante?

Imaginemos que la Administración Pública decide publicar sus e-servicios en un repositorio UDDI; pensemos que las entidades locales desean similares publicaciones y su punto de control; asimilemos que las empresas privadas requieren espacio para la combinación de servicios (en actividades comerciales de brokering o fusión); estimemos que buena parte del negocio electrónico (o mixto) depende de las interfases protegidas con otros negocios en un espacio sólido; asumamos que… En fin: lo común es el requisito del espacio de negocio; su comunalización; su puesta en disposición y su eficacia en ejecución; su fiabilidad garantizada, al fin.

La inversión en plataformas de switching y publicación/recuperación de e-servicios es alta, la curva de aprendizaje/mantenimiento muy pronunciada, y la sensación de control deviene muy pequeña. Al menos si se asume cada vez por separado. Y la única razón para hacerlo así suele ser la retención del control sobre la especificidad del negocio frente a iniciativas sesgadas también por su propio negocio. Así que se da un importante nicho negocial para e-garantes “prudentes”: esto es: en las plataformas buscadas se dan las condiciones de negocio de “Red Distributiva” descritas por Tapscott.

¿Cómo conceptuar, discriminar, aplicar y validar todo lo anterior en una empresa o institución concreta? ¡Pues mediante nuestros servicios, claro! (SOA, al fin, en su sentido amplio).