È un abuso di SOA usarlo come livello di astrazione del database? [chiuso]

2

Ho una domanda sull'esigenza o meno di utilizzare un livello SOA per i server delle applicazioni per comunicare con il database. Un server di applicazioni Web può ovviamente connettersi direttamente a un database, ma nella campagna pubblicitaria per rendere tutto SOA, gli architetti richiedono che ogni cosa debba effettuare una chiamata SOA ai server midtier che si collegano al database.

Per me, sembra terribilmente dispendioso avere un'applicazione nello stesso datacenter del database e le applicazioni possono accedere direttamente al server del database, ma non lo fanno. C'è già un livello di astrazione sui server delle applicazioni che sembra identico a quello che alla fine finiremo con SOA, quindi non si tratta di un'interfaccia migliore.

Usando SOA stai aggiungendo un sacco di passaggi per creare la richiesta, inviarla, riceverla e quindi decodificare e infine effettuare la chiamata al database e quindi devi comprimerla, inviarla, avere ha ricevuto, decodificato e finalmente puoi usare i dati.

Da quanto ho letto su SOA, è utile quando hai distribuito geograficamente sistemi in cui un server di Boston ha bisogno di informazioni da un server di Seattle e non c'è modo che una connessione diretta al database sia possibile. Ciò è utile anche quando hai molti clienti diversi che devono chiamare un punto centrale per ricevere i dati in base a un contratto fisso.

Tuttavia, utilizzare SOA come mezzo per comunicare direttamente con il proprio database dalla propria applicazione sembra essere un completo abuso del concetto e sembra offrire un piccolo vantaggio mentre rallenta significativamente le transazioni. Un tipico utilizzo sarebbe quello di chiamare un proc memorizzato e invece di chiamarlo direttamente, devi usare una chiamata SOA a un server midtier per ottenere esattamente le stesse informazioni.

Quindi, sono pazzo o cosa? Tutti stanno semplicemente bevendo SOA Kool Aid e applicando SOA a tutto fino al punto di assurdità? O c'è davvero qualche vantaggio nel fare questo?

    
posta Franklin 21.01.2015 - 18:42
fonte

3 risposte

4

Ci sono molti fattori nel tuo stack di applicazioni che possono indicare o contro-indicare l'uso di SOA, quindi sarà molto difficile dirti se tutto ciò che stanno chiedendo è appropriato.

Dirò che non penso che dovresti specificamente non usare SOA solo perché le macchine si trovano nello stesso data center. Cosa fare se è necessario applicare un nuovo schema di sicurezza o spostare alcuni server o supportare server in diversi data center per l'implementazione DR-1 oppure passare a un nuovo software di database o ...

Uno dei vantaggi di SOA è che astrae i problemi per lo sviluppatore front-end o anche per lo sviluppatore di livello intermedio (a meno che tu non sia responsabile per db api).

    
risposta data 21.01.2015 - 18:54
fonte
2

La SOA ha molti vantaggi oltre ad aumentare l'efficienza rispetto a una confezione di database non elaborata.

Il vantaggio più importante è che fornisce uno strato di astrazione che può essere utilizzato per consentire a un database sottostante di evolvere la sua progettazione senza la necessità di sincronizzare le versioni con tutti i consumatori dei dati archiviati (questo è particolarmente importante se il database è gestito da un team diverso per i suoi consumatori, ma è comunque utile anche se entrambi sono gestiti dallo stesso team, in quanto consente al team di concentrarsi sulle modifiche a un aspetto del sistema alla volta)

    *
risposta data 21.01.2015 - 20:18
fonte
1

Non è un abuso se la tua organizzazione lo richiede. Se ci sono problemi di sicurezza o guida / governance architettonica che lo impongono, allora è garantito.

L'abbiamo esaminato con un audit di terze parti e una delle preoccupazioni di audit di terze parti è stata che il nostro livello di servizio interagiva direttamente con il database. Avevamo un livello di applicazione Web e un livello di servizio. Il servizio aveva un livello di accesso ai dati e interagiva con il database tramite stored procedure. Il livello dati e servizio si trovavano nella stessa zona di rete.

Fondamentalmente, il team di architettura ha esaminato la ricerca di terze parti e ha chiesto cosa sarebbe stato necessario fare.

La risposta era di aggiungere un altro servizio che avrebbe interagito solo con il database. Ciò ha comportato maggiori costi per il progetto e aumentato il rischio di rendimento. I nostri SLA erano meno di 100ms per chiamata. Né il costo aggiuntivo né il rischio di rendimento erano accettabili per l'azienda.

A causa dei costi e dei rischi, il team ha deciso che non era necessario farlo. Ma la tua situazione potrebbe essere diversa.

Tenendo conto di tutte le cose, hai ragione uccidi. Ho visto SOA fino all'estremo dove sono necessari 1/2 dozzetti di servizi per ottenere i dati richiesti. I dati sono sparsi ai quattro venti. Vuoi un mezzo felice.

    
risposta data 21.01.2015 - 20:26
fonte

Leggi altre domande sui tag