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:
- Implementar transacciones reales con WS-Atomic Transaction o similares
- 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?