La composizione del servizio SOA funziona effettivamente nella pratica?

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 (costoso) come Oracles WebLogic EAI o IBMs Websphere ESB.

Sì, può essere fatto funzionare nella pratica. Tuttavia, potrebbe non essere l'approccio migliore e forse è usato come opzione predefinita più del dovuto. A mio parere, SOA è diventato popolare come metodo di integrazione dei sistemi legacy in quanto le organizzazioni hanno sviluppato il loro IT per automatizzare attività sempre più grandi. Può essere molto caotico, ma probabilmente ne vale la pena se i sistemi legacy possono essere riutilizzati. Se sei abbastanza fortunato da avviare un progetto sul campo verde, devono essere presi in considerazione altri approcci prima di assumere che sia il modo migliore per andare.

Per rispondere ad alcuni dei tuoi dubbi più specifici ...

Puoi utilizzare le transazioni:

1. WS-TX è un PITA e vorrei evitarlo.
2. Tutti i servizi potrebbero essere in esecuzione in un singolo server applicazioni, nel qual caso è possibile estenderli tutti con una transazione XA. Questo è il motivo per cui sono stati inventati cose 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 un passaggio del flusso di lavoro la prima volta, ma impostato sulle successive chiamate? Come il possibile flag di rinvio in JMS. Quindi puoi usare quello che viene chiamato un commit di fase 1.5, che in pratica significa andare avanti se il flag è chiaro, ma se il flag è impostato, prima effettua una chiamata per verificare se lo stato è già aggiornato e deve essere fatto una seconda volta . Ciò richiede ancora la gestione manuale degli errori e può essere complesso o addirittura impossibile come sottolineato.

In alcune situazioni non è importante:

Questo è l'approccio alla fine coerente. Supponi che un servizio invii un'email. Se la composizione del servizio fallisce e viene riavviata, l'e-mail viene nuovamente inviata. Questo è un po 'fastidioso per il destinatario, ma probabilmente si rende conto che è un duplicato e tutto può continuare senza molti problemi.

Potresti anche tenere un log delle email inviate e usarlo per ridimensionare quando viene impostato il flag, e in questo modo invia l'email una sola volta.

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

Considera una coda JMS che è transazionale. Il coordinatore del servizio può aggiornare il suo stato e inviare un messaggio alla coda in un singolo Tx. I servizi downstream 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 funziona e deve essere riavviato, nessun problema.

Ciò significa che stai ancora eseguendo transazioni XA sul database e su una coda JMS, ma può comunque essere efficiente utilizzando l'ultima risorsa per evitare l'overhead completo di XA.

In alternativa puoi usare questo modello ma con un commit di fase 1.5 al database e JMS. OPPURE è possibile eseguire JMS senza transazioni ma renderlo più affidabile mediante il clustering.

La messaggistica asincrona può anche aiutare a disaccoppiare i sistemi, in quanto 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 organizzazioni di grandi dimensioni con molti servizi diversi.

No, è un mito. Questa è l'intenzione errata da avere durante la progettazione dell'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 a grana fine, quindi c'è molta comunicazione interna.
3. Come risultato di essere a grana fine ci sono molti servizi. Il sistema sta diventando difficile da capire, le query sono sempre più difficili da rintracciare.
4. Entity-services sono scarsamente incapsulati: nessuna delle regole aziendali viene verificata lì, questa logica è in funzione. Quindi qualsiasi servizio può chiamare qualsiasi servizio di entità e aggiornare i suoi dati con una query di aggiornamento comune presente nella sua interfaccia. Questo genere di servizi di entità viene spesso definito come incentrato sui dati, al contrario dei servizi incentrati sui processi e centrati sul comportamento.
5. L'innata natura della comunicazione tra questi servizi è sincrona. Quindi le possibilità sono che il trasporto scelto sia http. Quindi tutti i suoi inconvenienti di cui parlerò un po 'più tardi.

Ci sono ancora più modi sbagliati per avvicinarsi all'architettura di servizio . Quindi sii prudente.