Mucho se habla de SOA ultimamente, son las siglas de moda en la arquitectura T.I. Las ofertas de empleo hablan de SOA, google arroja más de 40 millones de resultados… Sin embargo, en este artículo quiero volver un poco al origen, repasar los conceptos básicos, la esencia de lo que significa este concepto.
Según una de las definiciones que más me gusta, la de Mary E. Shacklett, SOA es:
… una técnica que ha surgido del desarrollo de software orientado a objetos que fue evolucionando hacia la creación de servicios web que encapsulan piezas de software de negocio usadas en la web para coordinar procesos de negocio de empresa.
Pero para entender realmente lo que significa SOA, es necesario examinar los principios sobre los que se asienta, son estos:
- Contratos de servicio estandarizados: forma parte de la esencia misma de un servicio. Para que se considere un servicio, su interfaz de entrada/salida (su contrato con el cliente) tiene que estar explícitamente declarado. Los campos que forman parte de este interfaz deben estar correctamente tipados y ser conocidos. Con la ayuda de los estándares como WSDL y XSD, el contrato del servicio está autodescrito.
Por consiguiente, los servicios web con un campo de entrada y otro de salida, en el que se inserta a su vez un XML como contenido (que no está descrito en ninguna parte) no puede considerarse un servicio web, a pesar de que parece que son los que más abundan. - Servicios con bajo acoplamiento: hace referencia al nivel de dependencia entre servicios, entre el proveedor y el consumidor. Cuanto menos acoplamiento se logra una mayor independencia para el diseño del servicio y su posterior evolución
- Abstracción: este principio pone el enfásis en ocultar los detalles internos del servicio, tanto como sea posible. El servicio debe ser una caja negra, únicamente definido por su contrato, que a su vez es el mínimo acoplamiento posible con el consumidor del mismo
- Reusabilidad: como es conocido, la arquitectura SOA no busca la sustitución de las lógicas de negocio actuales sino que proporciona una forma de reaprovechar todos estos activos encapsulandolos en servicios para que a su vez puedan ser reutilizados por otros servicios.
- Autonomia: Este principio indica que el servicio tiene un alto grado de control sobre su entorno de ejecución y sobre la lógica que encapsula
- Sin estado: el tratamiento de una gran información de estado afectaría gravemente a la escalabilidad del servicio, poniendo en riesgo su disponibilidad. Idealmente, todos los datos que necesita el servicio para trabajar provienen de los parámetros de entrada.
- Capacidad de descubrimiento: al servicio se le dota de meta datos, gracias a los cuales puede ser descubierto de manera efectiva. Estos meta datos pueden ser interpretados de manera automática pudiendo ser reutilizados. Para ello es necesario disponer de un mecanismo de descubrimiento (llamado registro de servicios) como por ejemplo el UDDI.
- Composición: define la capacidad de un servicio para formar parte de un servicio más complejo. A medida de que la arquitectura SOA se consolide, los nuevos servicios (de más alto nivel) podrán implementarse a partir de los servicios de más bajo nivel ya existentes. La implementación de nuevos servicios se reducirá al mínimo y que los nuevos se crearán a partir de otros ya pre existentes.
- Interoperabilidad: este principio no formaba parte de los 8 principios originales ya que en realidad es una propiedad que forma parte de todos ellos. Cada uno de los anteriores contribuye a la interoperabilidad de alguna manera. En las arquitecturas SOA, el problema de la falta de esta cualidad es uno de los más importantes. Hay que tener en cuenta que muchos de los servicios que intervienen se implementan con una tecnología diferente, incluso con un sistema operativo distinto.
Por ejemplo, se puede tener un servicio realizado en Java ejecutándose sobre Linux que invoca a otro implementado en .net corriendo en una máquina con Windows. Históricamente las especificaciones que dan forma a los servicios web (como WSDL, SOAP, etc.) eran tan ambiguos que las dos partes estaban prácticamente condenadas a no entenderse. Iniciativas como el Basic Profile 1.0 han contribuido a eliminar estas ambiguedades, simplificando estos estándares, logrando que el consumidor y el proveedor del servicio puedan comunicarse entre sí.
Comparte este artículo…
Blog de Andrés Hevia 
28/02/2010 at 12:53
Hola de nuevo a todo@s.
Creo que la la arquitecura SOA, entendida como plantean los estándares de los «grandes», basada en WSDL, grandes máquinas funcionando como servidores de aplicaciones, más máquinas funcionando como directorios de descubrimiento, etc… ha muerto. Está en declibe. Sólo la usarán los dinosaurios corporativos retro que no tienen la valentía de tomar decisiones empresariales a nivel TI para situarlos en la cresta de la ola.
Por contra, los gigantes modernos, que mueven cientos de veces las operaciones que las grandes corporaciones tradicionales, crecen, escalan e invierten en métodos modernos.
Por poner un ejemplo, Google comenzó implementando la arquitectura SOA mediante WSDLs, y a un sigue haciéndolo en su API de adSense, por ejemplo, mientras que en el resto de servicios ofrecidos, fue trasladando y orientando su arquitectura a otros tipos de «servicios».
Pasó por REST (statless, claro), lo que le ofrecía mayor capacidad de escalabilidad sin la dependencia del creciemiento en máquinas tipo servidores de aplicaciones y registries. Abarató su coste de crecimeinto, facilitando así mismo la escalabilidad, alta disponibilidad, etc.
De REST devolviendo XML, dio una nueva vuelta de tuerca, devolviendo datos en formatos JSON como respuesta a peticiones transparentes, por GET o PUT tradicionales, consiguiendo unas APIs facilmente manejables y extensibles.
El «contrato» del servicio pasaba a ser leible por un humano, rebajando por tanto el nivel de exigencia técnica necesaria para crear clientes. Multiplicó la usabilidad, reutilización e interoperabilidad, dejando al sistema de «contratos» mediantes WSDLs a la altura debida: perfil bajo, complicado y engorroso.
Si nos fijamos en los «top 10» de las empresas de alto movimiento de datos en internet, TODAS usan estos métodos: servicios REST stateless, basados en su mayor parte en JSON, construyendo maravillas basadas en ATOM, RSS, etc…
Digamos que los WSDLs fueron los pañales para un recien nacido con brillante futuro por delante. Pero ese niño está a punto de matricularse en la Universidad, a pesar de que sus papis quieran y se empeñen en seguir vistiéndolo de marinerito… papi IBM y mami SUN/Oracle, sin olvidarnos de su «discolo» tío Microsoft, al que nunca le gustó el traje y prefirió hacerle uno propio…
Al final el chaval, que es un poco «grunge», se ha vestido como ha querido, ha crecido, y usa marcas como «json», mucho más baratas, de mercadillo… de trincheras, no sé si me explico…
SOA basada en WSDL, con IBM WAS, IBM Registry, IBM… y soportado por Oracle/SUN, sigue siendo una máquina perfecta de venta que reporta grandes beneficios a estas compañías, pero eso no significa ni que sean «la panacea» ni la «via adecuada», tanto para crecer como para evolucionar.
Es duro, ¿verdad?
Salu2.
28/02/2010 at 14:39
Hola, estoy de acuerdo contigo en que los estándares de los web services (WSDL, SOAP, etc.) son engorrosos y difíciles de aprender. Sin embargo no estoy de acuerdo en que están en declive en el ámbito de una gran empresa. Los web services proporcionan funcionalidades que no aportan los REST o JSON, como por ejemplo la seguridad (WS-Security, SAML), Attachments y toda las parafernalia del WS-*
Creo que hay que diferenciar dos escenarios, el que describes basado en la interacción con el usuario final basado en un navegador (con reglas más laxas) y un escenario B2B, de intercomunicación entre servicios de empresa, de máquina a máquina, de transacciones, donde sí aplica el estándar web services (con normas más rígidas).
22/04/2016 at 11:35
Hola, que tal,
Totalmente de acuerdo y bien respondido. En una interacción B2B definitivamente es necesario emplear una arquitctura SOA basada en Web Services SOAP/WSDL/XML donde deba de existir mecanismos de seguridad. Prueba de ello es la arquitectura implementada en mi lugar de trabajo para las transacciones de un banco entre plataformas heterogeneas como Altamira, AIX y Web y en donde se requiere contar con mecamismos de seguridad.
En comparación con REST, tal vez sea más complejo aunque en lo personal a mi no me parece difícil ni engorroso los estándares WSDL/XML y me parecen más confiables.