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

Navega tus respuestas
15

Uno de los principales principios de diseño de servicios SOA es el principio de capacidad de servicio. ( enlace ).

La idea es que al componer nuevos servicios utilizando los existentes como bloques de construcción, uno Puede desarrollar rápidamente nuevos servicios. Algo análogo a cómo llamas a los métodos existentes. de objetos cuando implementas nuevos métodos. Aquí es donde se supone que gran parte de la productividad de SOA debe provenir.

¿Alguienrealmentehaceestoenlapráctica?HevistoestorepetidasincesarporescritoTexto,peronoheexperimentadolasimplementacionesdelmundorealamímismo.LamayoríadeEltextotambiénomitecualquiermencióndemanejodetransacciones,quemeparecequeeselElmayorobstáculoenlarealizacióndeservicioscompostables.

Primero,realmentenecesitasabordarelproblemadelastransaccionesantesdepodercomponercualquierServiciosnotriviales.Claro,sielejemplotieneservicios"findCurrentTime ()" y "writeLogMessage ()" es fácil no preocuparse por las transacciones, pero no cuando se tienen datos reales. ejemplos mundiales como "depositMoney ()" y "retirMoney ()".

Sé de dos opciones:

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

Ambos de estos parecen muy problemáticos / casi inutilizables para mí:

  • Transacción WS-Atómica
    • un lote de complejidad, la mayoría de los consejos que encontré solo advierten "dolor en el culo, no hazlo "
    • 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 las 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 tenido éxito? El manejo de dicha lógica de forma manual (como implementador de servicios de composición) hace que Quiero cortarme las muñecas. ¡Este es el tipo de trabajo que una herramienta debería hacer por mí!
    • Tampoco veo cómo puede tener métodos de compensación en servicios no triviales. Decir su servicio A es "depositMoney ()" y eso tiene éxito, otra acción rápidamente transfiere el dinero a otra parte, y luego recibimos "compensateDepositMoney ()", ¿qué hacemos? ¿lo hacemos ahora? Parece una gran lata de gusanos.

A mi parecer, la composición de servicio es un principio de SOA tan fundamental que usted realmente no obtiene los beneficios de SOA si no puede (convenientemente) redactar servicios . Cual es la realidad El 90% de los usuarios de SOA usan "SOA dañada" sin servicio real componsition? O la mayoría de los usuarios utilizan la composición del servicio y exagero. la dificultad de la misma?

    
pregunta Janne Mattila 27.05.2013 - 10:17

3 respuestas

0

¡La respuesta corta es Sí!

He visto esto en varias grandes organizaciones financieras 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.

    
respondido por el James Anderson 27.05.2013 - 11:00
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 evolucionaban su TI para automatizar tareas cada vez más grandes. Puede ser muy desordenado, pero posiblemente valga la pena si se pueden reutilizar los sistemas heredados. Si tiene la suerte de comenzar un proyecto de campo verde, se deben considerar otros enfoques antes de asumir que es la mejor manera de hacerlo.

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

Puedes usar transacciones:

  1. WS-TX es un PITA y lo evitaría.
  2. Es posible que todos sus servicios se ejecuten en un solo servidor de aplicaciones, en cuyo caso puede abarcarlos todos con una transacción XA. Esta es la razón por la que se inventaron los servidores de aplicaciones.

Teniendo en cuenta el enfoque basado en la compensación:

Las acciones de compensación solo deben considerarse cuando se produce un error. ¿La herramienta de composición de servicios tiene un indicador que puede controlar y que se borra cuando se ejecuta un paso de flujo de trabajo la primera vez, pero se establece en las invocaciones posteriores? Al igual que la posible reenviar bandera en JMS. Luego puede usar lo que se denomina una confirmación de fase 1.5, que básicamente significa seguir adelante si el indicador está despejado, pero si el indicador está establecido, primero realice una llamada para verificar si el estado ya está actualizado y debe realizarse una segunda vez. . Esto aún requiere un 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 muchos problemas.

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

Puede usar mensajes asíncronos 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 enviar un mensaje a la cola en una sola Tx. Los servicios descendentes pueden quitar mensajes y actualizar su estado en una sola Tx. Ahora está coordinando servicios en múltiples unidades de trabajo, pero cada uno es atómico. Si algo falla y hay que reiniciarlo, 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 utilizando la última estrategia de recursos para evitar la sobrecarga de XA.

Como alternativa, puede utilizar este patrón pero con una confirmación de fase 1.5 en la base de datos y JMS. O puede ejecutar JMS sin transacciones, pero hacerlo más confiable mediante la agrupación en clústeres.

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

    
respondido por el user2800708 18.05.2015 - 11:42
-1

No, es un mito. Esta es la mala intención de tener al diseñar la arquitectura de servicios. Hay un montón de problemas:

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

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

    
respondido por el Zapadlo 15.11.2017 - 08:45

Lea otras preguntas en las etiquetas

Manejo de renovación de token / caducidad de sesión en una API RESTful Uso de la gramática del lenguaje natural en API fluida