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?