¿La composición del servicio SOA realmente funciona en la práctica?

15

Uno de los principales principios de diseño del servicio SOA es el principio de Composabilidad del Servicio ( https://en.wikipedia.org/wiki/Service_composability_principle ).

La idea es que al componer nuevos servicios utilizando los existentes como bloques de construcción, uno puede desarrollar rápidamente nuevos servicios. De forma análoga a cómo llama a los métodos existentes de objetos cuando implementa nuevos métodos. Aquí es donde se supone que proviene gran parte del aumento de la productividad de SOA.

ingrese la descripción de la imagen aquí

¿Alguien realmente hace esto en la práctica? He visto esto repetido infinitamente en texto escrito, pero no he experimentado implementaciones de trabajo en el mundo real. La mayor parte del texto también omite cualquier mención del manejo de transacciones , lo que me parece ser el mayor obstáculo para realizar servicios componibles.

Primero, realmente necesita abordar el problema de las transacciones antes de poder componer cualquier servicio no trivial. Claro, si el ejemplo tiene los servicios "findCurrentTime ()" y "writeLogMessage ()", es fácil no preocuparse por las transacciones, pero no cuando se tienen ejemplos del mundo real como "depositMoney ()" y "retirewMoney ()".

Sé de dos opciones:

  1. Implemente transacciones reales con WS-Atomic Transaction o tal
  2. Implemente una solución basada en compensación que compense la llamada a A con "cancelA ()" o somesuch si falla la llamada a B

Ambos me parecen muy problemáticos / casi inutilizables:

  • Transacción WS-Atomic
    • una gran cantidad de complejidad, más consejos que he encontrado simplemente advierte "dolor en el culo, no lo hagas"
    • el soporte es limitado, por ejemplo, si toma ESB de código abierto, las principales alternativas ServiceMix, Mule o WSO2 no lo admiten
  • compensaciones
    • implementar el manejo de compensaciones me parece muy complejo. ¿Qué hacemos si el servicio A tiene éxito y nunca recibimos una respuesta del servicio B y no sabemos si falló o tuvo éxito? Manejar dicha lógica manualmente (como implementador de servicios de composición) me hace querer cortarme las muñecas: ¡este es el tipo de trabajo que algunas herramientas deberían hacer por mí!
    • Tampoco veo cómo puede tener métodos de compensación en servicios no triviales. Digamos que su servicio A es "depositMoney ()" y que tiene éxito, alguna otra acción transfiere rápidamente el dinero a otro lugar y luego recibimos "compensteDepositMoney ()", ¿qué hacemos ahora? Parece una gran lata de gusanos.

Para mí, parece que la composición del servicio es un principio SOA tan fundamental que realmente no obtienes los beneficios de SOA si no puedes (convenientemente) componer los servicios . Cual es la realidad ¿El 90% de los usuarios de SOA usan "SOA criplled" sin una composición de servicio real? ¿O la mayoría de los usuarios de hecho usan la composición del servicio y estoy exagerando la dificultad?

Janne Mattila
fuente
+1 esta es una gran pregunta, y es una pena que no haya recibido mucha atención.
Gaz_Edge

Respuestas:

0

¡La respuesta corta es sí!

He visto esto en varias organizaciones financieras grandes y ha funcionado bien.

Los problemas de transacción son complejos, pero generalmente son manejados por middleware (costoso) como Oracles WebLogic EAI o IBMs Websphere ESB.

James Anderson
fuente
No hay mucha discusión, así que creo que estoy seleccionando su respuesta. Supongo que la composición del servicio funciona si pones la cantidad necesaria de esfuerzo y utilizas las herramientas adecuadas.
Janne Mattila
Como una pregunta de seguimiento, tengo curiosidad por saber qué porcentaje de implementaciones de SOA lo hacen "correctamente" y usan una composición de servicio real. Mi presentimiento sería bastante bajo, como 10% ... ¿Me equivoco?
Janne Mattila
4

Sí, se puede hacer que funcione en la práctica. Sin embargo, puede que no sea el mejor enfoque y quizás se use como la opción predeterminada más de lo que debería. En mi opinión, SOA se hizo popular como una forma de integrar sistemas heredados a medida que las organizaciones evolucionaron su TI para automatizar tareas cada vez más grandes. Puede ser muy desordenado, pero posiblemente valga la pena si los sistemas heredados pueden reutilizarse. Si tiene la suerte de comenzar un proyecto de campo verde, se deben considerar otros enfoques antes de asumir que es el mejor camino a seguir.

Para responder a algunas de sus preocupaciones más específicas ...

Puedes usar transacciones:

  1. WS-TX es un PITA y lo evitaría.
  2. Todos sus servicios pueden estar ejecutándose en un único servidor de aplicaciones, en cuyo caso puede abarcarlos todos con una transacción XA. Es por eso que se inventaron cosas como los servidores de aplicaciones.

Considerando el enfoque basado en la compensación:

Las acciones compensatorias solo deben considerarse cuando ha habido una falla. ¿La herramienta de composición de servicios tiene un indicador que puede controlar que se borra cuando se ejecuta un paso de flujo de trabajo la primera vez, pero se establece en invocaciones posteriores? Como la posible bandera de reenvío en JMS. Luego puede usar lo que se llama un compromiso de fase 1.5, lo que básicamente significa seguir adelante si el indicador está despejado, pero si el indicador está configurado, primero realice una llamada para verificar si el estado ya está actualizado y debe realizarse por segunda vez . Esto todavía requiere el manejo manual de errores, y puede ser complejo o incluso imposible, como lo señala.

En algunas situaciones no importa:

Este es el enfoque eventualmente consistente. Supongamos que un servicio envía un correo electrónico. Si la composición del servicio falla y se reinicia, el correo electrónico se envía nuevamente. Eso es un poco molesto para el destinatario, pero probablemente se den cuenta de que es un duplicado y que todo puede continuar sin mucho problema.

También puede mantener un registro de los correos electrónicos enviados, y usarlo para quitar el duplicado cuando se establece el indicador, y de esa manera solo enviar el correo electrónico una vez.

Puede usar la mensajería asincrónica para dividir las transacciones en partes más pequeñas:

Considere una cola JMS que es transaccional. Su coordinador de servicios puede actualizar su estado y publicar un mensaje en la cola en un solo Tx. Los servicios posteriores pueden quitar mensajes y actualizar su estado en un solo Tx. Ahora está coordinando servicios en múltiples unidades de trabajo, pero cada una es atómica. Si algo falla y debe reiniciarse, no hay problema.

Esto todavía significa que está haciendo transacciones XA sobre la base de datos y una cola JMS, pero esto puede ser eficiente usando el último gambito de recursos para evitar la sobrecarga completa de XA.

Alternativamente, puede usar este patrón pero con un compromiso de fase 1.5 a la base de datos y JMS. O bien, puede ejecutar JMS sin transacciones, pero hacerlo más confiable mediante la agrupación.

La mensajería asincrónica también puede ayudar a desacoplar los sistemas, ya que los productores y los consumidores pueden ser más independientes entre sí, reduciendo la cantidad de acoplamiento en el sistema global y haciéndolo más flexible. Este tipo de desacoplamiento es bastante esencial cuando se trata de grandes organizaciones con muchos servicios diversos.

usuario2800708
fuente
¡Gran respuesta! Mi único comentario en la última sección donde habla sobre JMS y la mensajería asincrónica con transacciones, me temo que esto puede dar una mala impresión de las capacidades aquí. La transacción de un consumidor de servicios para enviar el mensaje solo garantizará que el mensaje haya sido enviado y puesto en la cola. No tenemos tales garantías sobre lo que hará el consumidor, y mucho menos incluso si van a leer el mensaje.
maple_shaft
Si necesita alguna respuesta, se debe enviar un mensaje utilizando una identificación de correlación para que coincida con el original enviado. La orquestación del servicio puede estar segura de que la solicitud se procesó una vez que recibe la respuesta.
user2800708
+1 para "Por eso se inventaron cosas como los servidores de aplicaciones". He estado luchando con este problema durante semanas. Estoy comenzando un nuevo proyecto y quiero usar SOA, tener todos los servicios en la misma caja para permitir una consistencia transaccional completa parece ser el camino a seguir, ¡gracias!
Gaz_Edge
-1

No, es un mito. Esta es una intención incorrecta al diseñar la arquitectura del servicio. Hay un montón de problemas:

  1. Acoplamiento muy ajustado. Si se cambió un servicio, debe probar todo el sistema.
  2. Dichos servicios son muy finos, por lo que hay mucha comunicación interna.
  3. Como resultado de ser fino, hay muchos de los servicios. El sistema se está volviendo difícil de entender, las consultas son cada vez más difíciles de rastrear.
  4. Los servicios de entidad están mal encapsulados: ninguna de las reglas de negocio se verifica allí, esta lógica está en los servicios de operación. Por lo tanto, cualquier servicio puede llamar a cualquier servicio de entidad y actualizar sus datos con una consulta de actualización común presente en su interfaz. Este tipo de servicios de entidad a menudo se denominan centrados en datos, en oposición a los servicios centrados en el proceso y el comportamiento.
  5. La naturaleza innata de la comunicación entre estos servicios es sincrónica. Entonces, lo más probable es que el transporte elegido sea http. De ahí todos sus inconvenientes de los que hablaré un poco más adelante.

Hay aún más formas incorrectas de abordar la arquitectura de servicio . Así que ten cuidado.

Zapadlo
fuente
@downvoter ¿No estás de acuerdo? No lo discutas, ¿por qué molestarte, solo vota abajo?
Zapadlo