La composizione del servizio SOA funziona davvero nella pratica?

Uno dei principali principi di progettazione del servizio SOA è il principio di Composibilità del servizio ( https://en.wikipedia.org/wiki/Service_composability_principle ).

L'idea è che componendo nuovi servizi utilizzando quelli esistenti come elementi costitutivi, è possibile sviluppare rapidamente nuovi servizi. In modo analogo al modo in cui chiamate metodi esistenti di oggetti quando implementate nuovi metodi. È da qui che dovrebbe derivare gran parte dell'aumento della produttività della SOA.

Qualcuno lo fa davvero in pratica? L'ho visto ripetutamente all'infinito nel testo scritto, ma non ho sperimentato di persona l'implementazione del mondo reale. La maggior parte del testo omette anche qualsiasi menzione della gestione delle transazioni , che mi sembra essere il maggiore ostacolo nella realizzazione di servizi compostabili.

Innanzitutto, è davvero necessario affrontare il problema delle transazioni prima di poter comporre qualsiasi servizio non banale. Certo, se l'esempio ha i servizi "findCurrentTime ()" e "writeLogMessage ()" è facile non preoccuparsi delle transazioni, ma non quando si hanno esempi del mondo reale come "depositMoney ()" e "drawMoney () ".

Conosco due opzioni:

1. Implementare transazioni reali con WS-Atomic Transaction o simili
2. Implementare una soluzione basata sulla compensazione che compensi la chiamata ad A con "cancelA ()" o qualcosa del genere se la chiamata a B fallisce

Entrambi mi sembrano molto problematici / quasi inutilizzabili per me:

• Transazione WS-Atomic
  • un sacco di complessità, maggior parte dei consigli che ho trovato appena avverte "spina nel fianco, non lo fate"
  • il supporto è limitato, ad esempio se si utilizzano ESB open source, le principali alternative ServiceMix, Mule o WSO2 non lo supportano
• compensazioni
  • l'implementazione della gestione dei compensi mi sembra molto complessa. Cosa facciamo se il servizio A ha esito positivo e non riceviamo mai una risposta dal servizio B e non sappiamo se ha fallito o è riuscito? Gestire tale logica manualmente (come implementatore di servizi di composizione) mi fa venire voglia di tagliarmi i polsi - questo è il tipo di lavoro che uno strumento dovrebbe fare per me !.
  • Inoltre, non vedo come si possano avere metodi di compensazione in servizi non banali. Supponi che il tuo servizio A sia "depositMoney ()" e che abbia successo, qualche altra azione trasferisce rapidamente i soldi altrove, e quindi riceviamo "compensateDepositMoney ()", cosa facciamo ora? Sembra una grande lattina di vermi.

A mio avviso , la composizione dei servizi è un principio SOA così fondamentale che non si ottengono realmente i vantaggi della SOA se non è possibile (convenientemente) comporre servizi . Qual è la realtà? Il 90% degli utenti di SOA utilizza "criplled SOA" senza una vera e propria consulenza di servizio? O la maggior parte degli utenti utilizza effettivamente la composizione del servizio e sto esagerando la sua difficoltà?

La risposta breve è Sì!

Ho visto questo fatto in diverse grandi organizzazioni finanziarie e ha funzionato bene.

I problemi di transazione sono complessi ma generalmente gestiti da middleware (costosi) come Oracles WebLogic EAI o IBM Websphere ESB.

Sì, può essere fatto funzionare nella pratica. Tuttavia, potrebbe non essere l'approccio migliore ed è forse usato come opzione predefinita più di quanto dovrebbe. A mio avviso, la SOA è diventata popolare come modo per integrare i sistemi legacy man mano che le organizzazioni hanno evoluto il loro IT per automatizzare attività sempre più grandi. Può essere molto disordinato ma probabilmente ne vale la pena se i sistemi legacy possono essere riutilizzati. Se sei abbastanza fortunato da iniziare un progetto sul campo verde, prima di dare per scontato che sia il modo migliore di procedere, dovresti prendere in considerazione altri approcci.

Per rispondere ad alcune delle tue preoccupazioni più specifiche ...

Puoi usare le transazioni:

1. WS-TX è un PITA e lo eviterei.
2. Tutti i tuoi servizi potrebbero essere in esecuzione in un singolo server delle applicazioni, nel qual caso puoi estenderli tutti con una transazione XA. Questo è il motivo per cui sono stati inventati elementi come i server delle applicazioni.

Considerando l'approccio basato sulla compensazione:

Le azioni compensative devono essere prese in considerazione solo in caso di fallimento. Lo strumento di composizione del servizio ha un flag che può controllare che viene cancellato quando si esegue una fase del flusso di lavoro per la prima volta, ma impostato su invocazioni successive? Come il possibile rinvio flag in JMS. Quindi è possibile utilizzare quello che viene chiamato commit di fase 1.5, che in pratica significa andare avanti se il flag è chiaro, ma se il flag è impostato, effettuare prima una chiamata per verificare se lo stato è già aggiornato e deve essere effettuato una seconda volta . Ciò richiede ancora la gestione manuale degli errori e può essere complesso o addirittura impossibile come indicato.

In alcune situazioni non importa:

Questo è l'approccio eventualmente coerente. Supponiamo che un servizio invii un'email. Se la composizione del servizio fallisce e viene riavviata, l'e-mail viene inviata di nuovo. Questo è leggermente fastidioso per il destinatario, ma probabilmente si rendono conto che è un duplicato e tutto può continuare senza troppi problemi.

È inoltre possibile tenere un registro delle e-mail inviate e utilizzarlo per annullare la duplicazione quando è impostato il flag e in tal modo inviare l'e-mail una sola volta.

È possibile utilizzare la messaggistica asincrona per suddividere le transazioni in parti più piccole:

Considera una coda JMS che è transazionale. Il coordinatore del servizio può aggiornare il suo stato e pubblicare un messaggio nella coda in un singolo Tx. I servizi a valle possono rimuovere i messaggi e aggiornare il loro stato in un singolo Tx. Ora stai coordinando i servizi in più unità di lavoro, ma ognuna è atomica. Se qualcosa non riesce e deve essere riavviato nessun problema.

Ciò significa ancora che si stanno eseguendo transazioni XA sul database e una coda JMS, ma ciò può essere comunque efficiente utilizzando l'ultima risorsa di risorse per evitare il sovraccarico di XA.

In alternativa è possibile utilizzare questo modello ma con un commit di fase 1.5 per il database e JMS. O è possibile eseguire JMS senza transazioni ma renderlo più affidabile tramite il clustering.

La messaggistica asincrona può anche aiutare a disaccoppiare i sistemi, poiché produttori e consumatori possono diventare più indipendenti l'uno dall'altro, riducendo la quantità di accoppiamento nel sistema globale e rendendolo più flessibile. Questo tipo di disaccoppiamento è praticamente essenziale quando si tratta di grandi organizzazioni con molti servizi diversi.

No, è un mito. Questa è un'intenzione sbagliata quando si progetta un'architettura di servizio. C'è un sacco di problemi:

1. Accoppiamento molto stretto. Se un servizio è stato modificato, è necessario testare l'intero sistema.
2. Tali servizi sono molto precisi, quindi c'è molta comunicazione interna.
3. Come risultato della granulosità ci sono molti servizi. Il sistema sta diventando difficile da capire, le query stanno diventando più difficili da tracciare.
4. I servizi di entità sono incapsulati male: nessuna delle regole di business viene verificata lì, questa logica è nei servizi operativi. Pertanto, qualsiasi servizio può chiamare qualsiasi servizio di entità e aggiornare i suoi dati con una query di aggiornamento comune presente nella sua interfaccia. Questo tipo di servizi alle entità viene spesso definito come incentrato sui dati, anziché sui servizi incentrati sui processi e incentrati sul comportamento.
5. La natura innata della comunicazione tra questi servizi è sincrona. Quindi le probabilità sono che il trasporto scelto sia http. Da qui tutti i suoi svantaggi di cui parlerò un po 'più tardi.

Esistono modi ancora più sbagliati per avvicinarsi all'architettura di servizio . Quindi sii cauto.