viernes
jun012007
Qué %#?!@ es SOA ... bueno eso creo
viernes, junio 1, 2007 at 4:10PM
Echo un vistazo a la discusión de TheServerSide.com sobre SOA como sucesor de CORBA, enseguida surge una larguísima discusión sobre qué es SOA y que no es SOA, cualquiera que no tenga una idea un poquito clara del tema creerá que es una discusión sobre el sexo de los ángeles. Después de 90 mensajes alguien se atreve a decir:
"Granted I haven't read all 90 messages in this thread, but I read enough to see this:
SOA is not this. SOA is not that.You don't understand what SOA is.
....yeah, I guess I don't. "
(si alguien lo necesita puedo traducirlo)
Bueno, realmente es una ironía, el autor del mensaje *sí* sabe qué es SOA:
"SOA is distributed procedural programming. Services are stateless request-response calls on arbitrary destinations."
Estoy seguro que algunos añadireis algo más
El problema de las "malditas" siglas (Service Oriented Architecture) es que son demasiado abstractas, tan abstractas que apenas se pueden entender si no se pone un ejemplo usando tecnologías concretas.
Lo mejor es partir del problema "que pretende resolver" antes de tragarse uno algo que "habrá que usar porque todo el mundo habla de ello".
Consideremos un par de aplicaciones clásicas monolíticas cliente/servidor donde el servidor es una base de datos y las aplicaciones se usan a través de una interfaz de usuario. Ambas aplicaciones gestionan dos diferentes sistemas de información.
Necesitaríamos *integrar* ambas aplicaciones, pues ambos sistemas de información están de alguna forma correlados. Tres opciones: 1) hacer una nueva como suma de las dos si es posible (mismo lenguaje etc) 2) rehacerlas totalmente 3) integrarlas (conectarlas) con en una tercera con algún tipo de "middleware".
Si elegimos la tercera necesitaremos "abrir" ambas aplicaciones monolíticas, el proceso de "abrir" cada aplicación es lo que hace que sea SOA, o mejor dicho es posible abrirla "a lo SOA". Cualquier técnica que permita recibir ordenes desde "fuera" es abrir la aplicación (sockets, mensajes de Windows, IPC, RPC, un URL via HTTP, CORBA, RMI, EJB remoto, JMS, Ice, SOAP, brokers de mensajes ...)
Bien, pues con cualquiera de estos métodos de acceso podemos construir "servicios", cada petición recibe algo, hace "algo" y devuelve algo (respuesta). Este es un concepto de servicio en sentido muy genérico.
Sin embargo esto no es un "servicio SOA" tal y como se suele entender, de igual manera que "un componente software" aunque pudiéramos definir como un "elemento reusable sin modificación", una simple función no se considera hoy que sea un "componente" (modernamente ojo).
De igual manera un servicio es "SOA" si realiza una "funcionalidad completa y autónoma". Por ejemplo: lo que no se consideraría un servicio SOA es la devolución de la edad de un cliente, pues para obtener la información completa del cliente tendríamos que llamar varias veces, una para el nombre, otra para la edad etc. El servicio más bien sería "obtener la información personal del cliente".
La autonomía del servicio es también un concepto SOA importante, se traduce en que para pedir la petición de datos del cliente no es necesaria una petición previa... ¿y el login? la información del login del quien la pide podría ir en la propia petición.
Hasta aquí la parte "sencilla" el problema es la tendencia actual por parte de los promotores de SOA de coordinar de forma externa el conjunto de llamadas posibles de un sistema SOA: que si orquestación, que si coreografía, que si gobierno, que si transaccionalidad, que si identificación, concurrencia, localización/descripción de servicios...).
Muchas características/necesidades están ya resueltas en los sistemas "SOA" que usan EJBs, por ejemplo los EJBs tienen su propio sistema de transmisión de transacciones de forma "transparente".
El "problema" es que los EJBs obviamente no son interoperables con otros sistemas (.Net claro), además si algún día se quiere acceder "tras el firewall" los EJBs no son buena opción, por lo que se está tendiendo a repetir "todo" en un sistema de servicios web estandarizado y de ahí viene tanto WS-*.
Una sucesión de invocaciones WebServices a servicios SOA puede considerarse lógica de negocio ¿no?, pues otra tendencia es a intentar modelar esta lógica de negocio directamente con tecnologías WebServices, ahora ya no estamos en una sucesión de llamadas Java sino en una descripción de acciones usando XML, dichos XMLs son bastante chungos de definir "a pelo" por ello se promueve que a través de herramientas visuales se programen estas secuencias de acciones de modo visual "y flexible" usando diagramas de flujo.
Esta tendencia "si prospera" y se lleva al límite podría hacer que cada vez más los servicios fueran muy "simples" y la lógica de negocio estuviera "programada visualmente" con estándares WebServices. El que esto sea realidad "al límite" el tiempo lo dirá, el mundo del software lleva décadas mejorando las técnicas de modelado de un sistema de información en los lenguajes convencionales, es muy difícil que sean "casi totalmente reemplazados" por toneladas de diagramas de flujo que a fin de cuentas es programación estructurada... y aparatosa.
¿Estáis de acuerdo con esta visión?
Si SOA es aproximadamente igual a integración ... ¿de verdad necesitas SOA? ¿cuando?
¿cuando es suficiente RMI?
¿necesitas organizar los servicios SOA en un alto nivel?
"Granted I haven't read all 90 messages in this thread, but I read enough to see this:
SOA is not this. SOA is not that.You don't understand what SOA is.
....yeah, I guess I don't. "
(si alguien lo necesita puedo traducirlo)
Bueno, realmente es una ironía, el autor del mensaje *sí* sabe qué es SOA:
"SOA is distributed procedural programming. Services are stateless request-response calls on arbitrary destinations."
Estoy seguro que algunos añadireis algo más
El problema de las "malditas" siglas (Service Oriented Architecture) es que son demasiado abstractas, tan abstractas que apenas se pueden entender si no se pone un ejemplo usando tecnologías concretas.
Lo mejor es partir del problema "que pretende resolver" antes de tragarse uno algo que "habrá que usar porque todo el mundo habla de ello".
Consideremos un par de aplicaciones clásicas monolíticas cliente/servidor donde el servidor es una base de datos y las aplicaciones se usan a través de una interfaz de usuario. Ambas aplicaciones gestionan dos diferentes sistemas de información.
Necesitaríamos *integrar* ambas aplicaciones, pues ambos sistemas de información están de alguna forma correlados. Tres opciones: 1) hacer una nueva como suma de las dos si es posible (mismo lenguaje etc) 2) rehacerlas totalmente 3) integrarlas (conectarlas) con en una tercera con algún tipo de "middleware".
Si elegimos la tercera necesitaremos "abrir" ambas aplicaciones monolíticas, el proceso de "abrir" cada aplicación es lo que hace que sea SOA, o mejor dicho es posible abrirla "a lo SOA". Cualquier técnica que permita recibir ordenes desde "fuera" es abrir la aplicación (sockets, mensajes de Windows, IPC, RPC, un URL via HTTP, CORBA, RMI, EJB remoto, JMS, Ice, SOAP, brokers de mensajes ...)
Bien, pues con cualquiera de estos métodos de acceso podemos construir "servicios", cada petición recibe algo, hace "algo" y devuelve algo (respuesta). Este es un concepto de servicio en sentido muy genérico.
Sin embargo esto no es un "servicio SOA" tal y como se suele entender, de igual manera que "un componente software" aunque pudiéramos definir como un "elemento reusable sin modificación", una simple función no se considera hoy que sea un "componente" (modernamente ojo).
De igual manera un servicio es "SOA" si realiza una "funcionalidad completa y autónoma". Por ejemplo: lo que no se consideraría un servicio SOA es la devolución de la edad de un cliente, pues para obtener la información completa del cliente tendríamos que llamar varias veces, una para el nombre, otra para la edad etc. El servicio más bien sería "obtener la información personal del cliente".
La autonomía del servicio es también un concepto SOA importante, se traduce en que para pedir la petición de datos del cliente no es necesaria una petición previa... ¿y el login? la información del login del quien la pide podría ir en la propia petición.
Hasta aquí la parte "sencilla" el problema es la tendencia actual por parte de los promotores de SOA de coordinar de forma externa el conjunto de llamadas posibles de un sistema SOA: que si orquestación, que si coreografía, que si gobierno, que si transaccionalidad, que si identificación, concurrencia, localización/descripción de servicios...).
Muchas características/necesidades están ya resueltas en los sistemas "SOA" que usan EJBs, por ejemplo los EJBs tienen su propio sistema de transmisión de transacciones de forma "transparente".
El "problema" es que los EJBs obviamente no son interoperables con otros sistemas (.Net claro), además si algún día se quiere acceder "tras el firewall" los EJBs no son buena opción, por lo que se está tendiendo a repetir "todo" en un sistema de servicios web estandarizado y de ahí viene tanto WS-*.
Una sucesión de invocaciones WebServices a servicios SOA puede considerarse lógica de negocio ¿no?, pues otra tendencia es a intentar modelar esta lógica de negocio directamente con tecnologías WebServices, ahora ya no estamos en una sucesión de llamadas Java sino en una descripción de acciones usando XML, dichos XMLs son bastante chungos de definir "a pelo" por ello se promueve que a través de herramientas visuales se programen estas secuencias de acciones de modo visual "y flexible" usando diagramas de flujo.
Esta tendencia "si prospera" y se lleva al límite podría hacer que cada vez más los servicios fueran muy "simples" y la lógica de negocio estuviera "programada visualmente" con estándares WebServices. El que esto sea realidad "al límite" el tiempo lo dirá, el mundo del software lleva décadas mejorando las técnicas de modelado de un sistema de información en los lenguajes convencionales, es muy difícil que sean "casi totalmente reemplazados" por toneladas de diagramas de flujo que a fin de cuentas es programación estructurada... y aparatosa.
¿Estáis de acuerdo con esta visión?
Si SOA es aproximadamente igual a integración ... ¿de verdad necesitas SOA? ¿cuando?
¿cuando es suficiente RMI?
¿necesitas organizar los servicios SOA en un alto nivel?
Reader Comments