Mi propio manifiesto SOA (SOA IMHO)

En una entrada reciente acerca de SOA, realicé una reflexión acerca de las diferentes concepciones que se han aportado acerca de este concepto y la controversia generada al respecto. Me gustaría incidir en el hecho de que se trata de mi interpretación humilde y subjetiva acerca de SOA, por lo cual no pretendo despreciar opiniones en otra dirección ni mucho menos… En la diversidad radica la auténtica riqueza.

Como ya apunté en dicho post, mi definición para SOA es:
“Una arquitectura débilmente acoplada diseñada para resolver las necesidades de los procesos de negocio (BPM) de una empresa”
A primera vista, esta definición puede parecer demasiado simple: ¿dónde están SOAP, WSDL, servicios web, WS-* y los demás estándares asociados a este concepto? En realidad, una arquitectura orientada a servicios no precisa del uso de estos estándares para ser considerada como tal, y no debemos confundir arquitecturas con tecnologías, planos con hormigón…En el pasado, las arquitecturas débilmente acopladas se basaban en otras tecnologías como por ejemplo CORBA y DCOM; así como diversos enfoques basados en el intercambio de documentos, tales como EDI, para lograr integración B2B. Muchas de estas tecnologías ocupan todavía hoy un amplio sector de mercado, y están siendo complementadas, en algunos casos, y reemplazadas progresivamente, en otros tantos, por el uso de otras nuevas.Pienso que la definición aportada es válida puesto que refleja la verdadera motivación de SOA: Satisfacer las necesidades de una empresa, lo cual no se puede garantizar mediante el uso de unas tecnologías u otras, sino mediante el uso apropiado de cualquiera de ellas.

Hablando en términos más concretos, la arquitectura orientada a servicios de una empresa puede que sólo se parezca a la de otra empresa en el hecho de que aglutine unos cuantos servicios, sin entrar a comparar las tecnologías en que estén implementados respectivamente. Es probable que haya una serie de servicios comunes, de propósito similar, entre ambas arquitecturas (por ejemplo, servicios de autenticación y login de usuarios); no obstante, por lo demás es muy probable que ambas arquitecturas no tengan prácticamente nada en común, más allá de la motivación para la que fueron diseñadas (satisfacer necesidades de negocio).

Muchos analistas confunden los términos “arquitectura orientada a servicios” e “implementación orientada a servicios”. Este hecho añade confusión al debate y difumina el verdadero significado de los conceptos relacionados con SOA. Esto puede llevar a resultados nefastos a nivel empresarial.Confundir arquitectura con implementación genera resultados caóticos. Es por ello que, a menudo, me escandaliza ver artículos que tratan de explicar el concepto de SOA y derivan en un tutorial sobre cómo implementar servicios web y proporcionan guías de buenas prácticas de programación… Esta es una de las causas fundamentales por las que SOA es un concepto tan críptico hoy en día… Los esfuerzos para promover el uso de arquitecturas débilmente acopladas se centran en el ¿cómo? , no en el ¿qué? (contraposición de cuestiones a la que prometo dedicar una entrada en el futuro cercano, bueno, quizá medio… :-P)Como ya comentábamos, los conceptos asociados a SOA no son nuevos, muchos de ellos son evoluciones de ideas que fueron introducidas previamente por CORBA, DCOM, DCE y otras… Pero, a diferencia de estas iniciativas previas, la promesa clave de SOA es posibilitar la optimización de procesos de negocio a través de la interoperabilidad entre estándares abiertos.A pesar de que dichos estándares son importantes, no debemos olvidar que no son el concepto clave de SOA… Los estándares no definen una arquitectura, y una arquitectura no conduce unívocamente a una implementación concreta…

“Al fin y al cabo, será la implementación válida de una arquitectura bien diseñada la que generará beneficios de negocio, no la arquitectura en sí misma.”

                                                           

SOA es un enfoque arquitectural para la creación de sistemas construidos a partir de servicios independientes, autónomos. Con SOA, la integración entre dichos sistemas se diseña “a priori” frente al concepto tradicional en el cual la integración se construía “a posteriori”. Es por ello que la solución final tiende a ser un conjunto de servicios integrados, desarrollados en diferentes lenguajes, alojados en un conjunto heterogéneo de arquitecturas, en las cuales exista una gran variedad de modelos de seguridad, procesos de negocio…


A pesar de que este concepto pueda sonar complejo, insisto en que no se trata de algo tan novedoso, mucha gente coincide en afirmar que el concepto de SOA es la evolución lógica de experiencias asociadas con el diseño y desarrollo de sistemas distribuidos basados en tecnologías disponibles desde hace tiempo. Muchos de los conceptos asociados con SOA, como por ejemplo los servicios, el descubrimiento y el late binding ya existían en tiempos de CORBA y DCOM. De forma parecida, muchos principios de diseño de servicios comparten conceptos como la encapsulación, abstracción y definición de interfaces claros con la filosofía de orientación a objetos.

¿Significa el revuelo ocasionado por SOA y los servicios que las tecnologías de la información no estaban orientadas a servicios en el pasado? Realmente, NO, no significa eso… Sin la aplicación de dichos principios, el diseño e implementación de dichos sistemas habría sido inabordable.No obstante, hay un factor clave, determinante en el contexto empresarial que SOA aborda de una forma más efectiva que las filosofías anteriores: la capacidad de reacción al cambio. Si las tecnologías no son capaces de reaccionar y readaptarse a las necesidades y oportunidades empresariales de manera rápida, estas tecnologías serán percibidas como un freno y no como un factor optimizador de estos procesos.SOA se compromete a posibilitar una respuesta mucho más rápida por parte de estas tecnologías ante condiciones de mercado variables. Sin embargo, SOA es una filosofía arquitectural, y por ello no siempre resultará un concepto viable desde el punto de vista de su implementación sobre un determinado proceso de negocio.  Cada organización puede tener diferentes requerimientos y expectativas para SOA debido a la gran variedad de necesidades de negocio y objetivos. Este hecho es una de las razones por las que describir SOA es un reto. SOA, como cualquier otra iniciativa, debe proporcionar un valor añadido para la organización. De lo contrario, no merece la pena ni sentarse a hablar sobre su posible adopción… La mejor forma para asegurarse de que la inversión en SOA proporcionará un retorno de la inversión favorable para una empresa es conseguir alinear los conceptos de SOA con los procesos de negocio claves para cada organización.

A pesar de esta obviedad, sigue existiendo mucha confusión en torno a SOA, algo sobre lo que espero aportar un poco más de luz en próximas entradas.

8 comentarios en “Mi propio manifiesto SOA (SOA IMHO)”

  1. Sin ningún ánimo de ofender:

    “A pesar de esta obviedad, sigue existiendo mucha confusión en torno a SOA, algo sobre lo que espero aportar un poco más de luz en próximas entradas.”

    Esperemos, porque desde luego en esta entrada creo que te has enrollado a escribir tanto para no decir absolutamente nada. De nuevo, te lo digo sin ánimo de ofender. Es que honestamente sueltas unas cuantas palabras y luego dices que esto no equivale a lo otro pero realmente no explicas ni uno ni lo otro.

    Algunos puntos:

    “SOA es un enfoque arquitectural para la creación de sistemas construidos a partir de servicios independientes, autónomos.”

    ¿Que es exactamente autónomo? ¿Que constituye un servicio autónomo?

    “Con SOA, la integración entre dichos sistemas se diseña “a priori” frente al concepto tradicional en el cual la integración se construía “a posteriori”

    ¿Que sistema se diseña con integración a posteriori exactamente?

    “Muchos analistas confunden los términos “arquitectura orientada a servicios” e “implementación orientada a servicios”

    ¿Que tiene que ver esto con SOA en particular? Lo mismo se puede aplicar a cualquier sistema donde se confuden la arquitectura a alto nivel con una implementación en concreto.

    eso es solo por nombrar algunas cosas….

  2. Interesantes dudas, Anonimo. A ver si puedo resolverlas de forma clara y concisa, he tratado de no resultar ambiguo en el post, pero a veces no es tan sencillo, jeje.

    Por orden:

    1.- ¿Que es exactamente autónomo? ¿Que constituye un servicio autónomo?

    Quizá el uso de la palabra autónomo haya causado confusión en mi explicación. Como bien sabemos ambos, SOA es un enfoque de arquitectura débilmente acoplada. Esto significa que existirá un bajo acoplamiento (idealmente, ninguno) entre servicios. Imagina una arquitectura SOA que involucra a tres servicios A, B y C. Según lo comentado, podría desarrollarse una completa implementación y despliegue del servicio A y que su funcionamiento sea óptimo, sin que exista necesidad alguna de que los servicios B y C estén todavía creados. Esto nos abre una serie de perspectivas interesantes en cuanto al modelo de desarrollo basado en arquitecturas SOA, como por ejemplo el desarrollo incremental. De estos matices hablaré más adelante cuando realice un análisis sobre el concepto de SOA Maturity Model, del cual ya se está hablando con cierto rigor en “la literatura”. 🙂

    2.- ¿Que sistema se diseña con integración a posteriori exactamente?

    En este punto, me he permitido un cierto paralelismo literario dentro de la frase que, creo, te ha podido liar un poco. En concreto me refiero a: la integración (…) se diseña “a priori” frente al concepto tradicional en el cual la integración se construía “a posteriori”

    ¿Qué quiero decir con esto? En dicha frase trato de incidir en la importancia de la definición de contratos de servicio (interfaces de servicio) de manera previa a la implementación del propio servicio, lo cual facilita mucho la interoperabilidad entre varios sistemas involucrados en dicho servicio en la práctica.

    Esto es una ventaja muy grande respecto a sistemas clásicos en los cuales la interoperabilidad se realizaba “ad hoc” (sin querer entrar en una u otra tecnología) mediante diversas técnicas como la invocación de procedimientos remotos o, incluso, la creación de “parches” para lograr interoperabilidad entre sistemas a nivel de datos (por ejemplo); lo cual incrementaría el nivel de acoplamiento de nuestra arquitectura y sería muy negativo en factores tan interesantes como la reusabilidad.

    3.- ¿Que tiene que ver esto con SOA en particular? Lo mismo se puede aplicar a cualquier sistema donde se confuden la arquitectura a alto nivel con una implementación en concreto.

    Estoy de acuerdo, no es SOA el único concepto en el cual sucede ese efecto. Por la propia naturaleza de la mente del ser humano, tendemos a comprender mejor ejemplos concretos que conceptos abstractos y cuando un determinado concepto es algo complejo de explicar, se tiende a ejemplificar.

    Esta tendencia hacia la ejemplificación, aunque no es dialécticamente algo deseable (los puristas del arte del debate podrían machacarme aquí), sí que podemos aceptarla. El problema surge cuando la inmensa mayoría de explicaciones del concepto derivan en una ejemplificación basada en escenarios de uso que involucran una serie de tecnologías concretas (WCF, WS, struts, WebSphere…) y digo problema ya que esta tendencia puede llevar a errores en la percepción del concepto por parte de quien lo lee y trata de aprender en qué consiste. De ahí que me guste incidir mucho en este concepto y me enrolle un poco más de la cuenta, quizá 🙂

    Espero haber aclarado un poco tus observaciones, gracias por plantearlas y para nada ofenden.

    Un saludo

  3. “sin que exista necesidad alguna de que los servicios B y C estén todavía creados.”

    Si hay dependencia, entonces no puede existir esto. Si el servicio puede funcionar si B y C entonces no existe dependencia. Con lo cual rozamos lo absurdo.

    ¿Que es el “desarrollo incremental.”?

    “Esto es una ventaja muy grande respecto a sistemas clásicos en los cuales la interoperabilidad se realizaba “ad hoc” (sin querer entrar en una u otra tecnología) mediante diversas técnicas como la invocación de procedimientos remotos”

    Aquí te has ido completamente por las ramas. El RPC es un modelo válido de invocacion y no tiene nada que ver con lo que hablas de integración “a posteriori”. Estás mezclando conceptos completamente.

    Respecto al último punto entonces (3), ves que no aclara ni tiene relación concreta con SOA con lo cual no entiendo el propósito de escribir un párrafo entero para nada.

    Es decir, has intentado “aclarar” o “postular” tu interpretación de SOA pero creo que has mezclado conceptos que no tienen nada que ver y mucho menos has dicho lo que tu interpretas con SOA. Igual con esa primera frase hubiera sido suficiente porque el resto la verdad es que tiene poco sentido y no hace más que liar el lector. Lo peor es que realmente no hay fundamento (por lo menos en lo que se refiere a SOA) en el texto.

    Lo siento. De nuevo te digo que es sin ánimo de ofender, pero estoy completamente en desacuerdo con tu post y creo que puede llevar a confusión a mucha gente. Veo aquí lo que he visto en muchos sitios cuando se define SOA: dar unos aires “abstractos” y de alguna forma “intelectual” (a falta de otra palabra) para realmente decir poco.

    De todos modos agradezco las aclaraciones. Lamentablemente a mi no me han convencido.

    Gracias.

  4. Vaya, parece que ahora cobra mayor sentido la metáfora del elefante, jeje.

    Intento contestar:

    1.- Si hay dependencia, entonces no puede existir esto. Si el servicio puede funcionar si B y C entonces no existe dependencia. Con lo cual rozamos lo absurdo.

    Es que no hay motivo alguno para que exista dependencia entre esos 3 servicios. Identifica cada uno de esos servicios con un proceso de negocio determinado, que sea independiente de los otros dos, ¿influye para algo en el funcionamiento de A que los servicios B y C estén todavía en fase de desarrollo?

    Más aún, ¿influye en algo para A que, una vez están en pleno funcionamiento los tres servicios, el servicio B deba ser reimplementado debido a cambios en el proceso de negocio del cual se ocupa? La respuesta, espero que estés de acuerdo, es NO. Y al final, este razonamiento nos conduce con uno de los factores claves de SOA y que ya comentaba hacia el final del post: la agilidad.

    2.- ¿Qué es “desarrollo incremental”?
    http://es.wikipedia.org/wiki/Desarrollo_iterativo_y_creciente

    3.- El RPC es un modelo válido de invocacion y no tiene nada que ver con lo que hablas de integración “a posteriori”.

    RPC implica el conocimiento de la implementación concreta de un módulo desde otro para llamar a ciertos procedimientos del mismo. De igual forma, si el módulo al cual estamos invocando sufre variaciones de implementación en el futuro, es más que probable que tengamos que revisar los módulos desde los cuales es llamado y realizar modificaciones. El débil acoplamiento por el cual apuesta SOA se ve claramente infringido aquí…

    En ningún momento hablo de su validez como
    método en si mismo, pero sí de su falta de alineación con los conceptos de SOA.

    Respecto al último punto, veo que sí guarda relación directa con SOA, más en concreto con una tendencia a la hora de explicar SOA, tendiendo hacia la ejemplificación en cuanto al uso de unas tecnologías u otras, que ha causado confusión desde hace tiempo y ha provocado que mucha gente identifique SOA con el uso de unos mecanismos y tecnologías concretas.

    Agradezco tus observaciones, las cuales no entro a valorar más allá del fondo técnico de las mismas. Temo que vía comentarios tal vez no lleguemos a explicarnos ambos bien, te invito a contactar conmigo a través de mi usuario de geeks mediante algún correo más extenso (con ello no quiero privar del debate al resto de lectores ni mucho menos, tan sólo aclarar dudas muy puntuales de alguno de ellos, que quizá no afecten al resto ya que tampoco se han pronunciado sobre ellas).

    Nuevamente, muchas gracias por tus observaciones.

    Un saludo

  5. Punto por punto:

    1. Entonces volvemos a lo primero. ¿Que es un servicio autónomo?

    2. ¿Que tiene que ver esto con SOA o no SOA? O sea, quien dice que yo no puedo progresivamente desarrollar un sistema basado en “SOA”. Estás confundiendo ahora metodologías con arquitecturas.

    3. Perdona pero RPC, no hablando a nivel de implementación es un modelo de llamada, al igual que lo es llamads a servicios web o llamadas a servicios WCF. ¿O es que de antes tu no tienes que tener conocimiento del contrato de tu servicio, sea por descubrimiento del WSDL o no? No confundamos implementación con arquitectura.

    “Respecto al último punto, veo que sí guarda relación directa con SOA, más en concreto con una tendencia a la hora de explicar SOA, tendiendo hacia la ejemplificación en cuanto al uso de unas tecnologías u otras, que ha causado confusión desde hace tiempo y ha provocado que mucha gente identifique SOA con el uso de unos mecanismos y tecnologías concretas.”

    De verdad es que has escrito un párrafo sin decir absolutamente nada. ¿Cómo está relacionado una cosa con la otra?

    Si no quieres seguir el debate, estás en tu pleno derecho. Mis comentarios iniciales fueron porque no estoy de acuerdo con tu post y creo que puede llevar a confusión a los lectores (que parece que hay otro que tampoco entiende despues de leer tu post lo que es SOA…digo por los comentarios).

    Yo no creo que tenga dudas de lo que es SOA y por ello realmente no tengo necesidad de seguir debatiendo esto en privado. Honestamente he dicho todo lo que he tenido que decir. Seguir comentado párrafos que suenan muy bien pero sin fundamento no es realmente productivo y veo que van por ahí los tiros.

    Gracias y hasta otra.

  6. 1.- Dudo que sea necesario volver a esa pregunta a tenor de mi respuesta última, de todos modos, un poco más arriba la tienes 🙂

    2.- ¿Acaso yo he dicho que no se pueda? Más bien al contrario, lo considero una de las ventajas de SOA. Respecto a confundir arquitecturas con metodologías, para nada. Te recuerdo que una arquitectura no es un fin en si misma, y debe reportar una serie de beneficios a posteriori. Este es uno de ellos.

    3.- Sobre SOA vs RPC, te recomiendo estas lecturas:

    http://blogs.sun.com/rtenhove/entry/soa_services_rpc

    http://www.xml.com/pub/a/ws/2003/09/30/soa.html

    De la segunda me gustaría destacar este pasaje:

    “Effectively, it (RPC) prescribes both system behaviors and application semantics. Because system behaviors are very difficult to prescribe in a distributed environment, applications created with SOAP RPC are not interoperable by nature. Many real life implementations have confirmed this.

    Faced with this difficulty, both WS-I basic profile and SOAP 1.2 have made the support of RPC optional. RPC also tends to be instructive rather than descriptive, which is against the spirit of SOA. ”

    Respecto al último punto, guarda relación con SOA en cuanto a la tendencia a la hora de explicar SOA. Lo digo bien clarito en ese párrafo en el cual no digo nada 🙂

    Estaré encantado de seguir el debate, es más, te invito a que describas SOA minuciosamente puesto que afirmas no tener ninguna duda sobre lo que es SOA (algo que te sitúa en un nivel superior al mío, sinceramente yo tengo algunas dudas sobre SOA aún, no en lo referido desde un punto de vista técnico pero sí en lo referido a algunos matices relacionados con BPM). Será todo un placer leerlo y seguro que yo entre otra mucha más gente en la comunidad aprendemos mucho gracias a ello.

    Gracias y espero tu post sobre ello, o comentario, como prefiera.

    Un saludo

  7. 1. Recuerdamelo por favor que no lo encuentro

    2. Lee tu propio post. Llevas todo el rato diciendo que lo contrario. Y yo en ningún momento he confundido arquitectura con metodología. Lo contrario, he dicho que tu los estás mezclando. Lee detedinadamente tu post y ya verás donde.

    3. NO hace falta que me mandes enlaces para explicarme lo que es o no es RPC. Sé lo que es y en función de las necesidades de ampliación y versionado podrías o no hacerlo con RPC sujeto a más o menos restricciones (dependiendo ya de gustos). Mi comentario era porque estabas mezclando implementación de nuevo.

    Por último, la verdad ya no quiero seguir. POnerme a leer otra vez todo lo que has escrito para demostrarte que te estás contradiciendo incluso en tus propias respuestas y cambiando de opinion no servirá de nada. Eso ya es cosa tuya.

    Con esto yo ya lo doy por zanjado. Si te hace ilusión, vamos a decir que me has vencido. Has ganado el debate! Felicidades.

  8. No se trata de eso, de verdad. Soy de los que piensan que en un debate ganan todos los que participan.

    Sinceramente me encantaría leer tu visión sobre SOA, más allá de puntualizaciones a aspectos de mi post. Pienso que sería enriquecedor no sólo para mí sino para toda la comunidad.

    Un saludo

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *