È questa rottura SOA?

6

Abbiamo un po 'di disaccordo nel nostro team e mi piacerebbe sentire le opinioni di altre persone. Abbiamo una soluzione matura che utilizza un modello di Entity Framework, a cui si accede da un livello di repository, a cui si accede a sua volta da un livello di business logic. Le classi BLL implementano interfacce, che sono anche implementate dai servizi in un progetto WCF. I servizi WCF sono wrapper molto sottili intorno alle classi BLL e ogni chiamata di servizio è fondamentalmente un one-liner che passa la chiamata attraverso la BLL. Abbiamo un progetto WPF che utilizza i servizi WCF per l'accesso ai dati.

Abbiamo recentemente aggiunto un progetto ASP.NET MVC4 alla soluzione, per fornire l'accesso Web ad alcune delle funzionalità del progetto WPF. Poiché il server Web si trova sulla stessa rete locale del database SQL Server e della cartella Web WCF, ho aggiunto un riferimento al progetto BLL dal progetto MVC e ho effettuato l'accesso ai dati direttamente tra i controller MVC e le classi BLL.

Il nostro superiore tecnico si è opposto a questo e ha detto che stavo rompendo SOA. Vuole che aggiunga i riferimenti ai servizi WCF al progetto MVC e acceda ai dati tramite WCF.

Il mio argomento contro questo è che passare attraverso WCF non aggiunge nulla di beneficio al progetto MVC, ma danneggia le prestazioni (lo so per certo, come ho provato). Dato che i servizi WCF passano le chiamate direttamente nelle classi BLL, che implementano le stesse interfacce, non vedo come sia più SOA utilizzare WCF che chiamare direttamente i metodi BLL. Inoltre, le prestazioni sono fondamentali in questo progetto MVC e non voglio fare nulla che possa influire sulle prestazioni a meno che non ci sia un buon motivo per farlo. Non riesco a vedere nessuna buona ragione qui. Anche se ottimizziamo il progetto WCF, sarà sempre più lento dell'accesso diretto ai BLL.

Secondo le definizioni di SOA che ho visto (per esempio, vedi la sezione Definizioni nell'articolo SOA di Wikipedia link ), i nostri BLL sono decisamente all'interno dello schema. Non vedo alcun requisito per utilizzare i servizi Web per chiamarlo SOA. Certo, i servizi web sono una forma di SOA, ma non sono l'unica forma. Per quanto posso vedere, un approccio a strati, che è in definitiva la nostra, è completamente conforme al principio di SOA. Ora mi rendo conto che forse non ho esposto la sua argomentazione in modo molto strong, ma questo principalmente perché non riesco a capirlo. Spero che alcune persone che sono più competenti di me possano venire e offrire alcuni commenti in un modo o nell'altro. Ci incontreremo per discutere di questo domani, e sono sicuro che mi spingerà molto strong a usare WCF invece di riferire direttamente le BLL. Se ha ragione, allora è giusto, dovremo subire il colpo di performance. Tuttavia, se in questo caso non vi è alcun vantaggio nell'uso di WCF, allora devo essere in grado di spiegare perché il modo in cui l'ho fatto finora è completamente SOA.

Apprezzerei qualsiasi commento.

    
posta Avrohom Yisroel 18.03.2015 - 13:46
fonte

3 risposte

3

Fammi solo accertarmi di aver corretto le mie supposizioni prima di provare a dare la mia opinione: Se ho capito bene, hai distribuito un server che espone le sue interfacce tramite WCF e queste interfacce corrispondono a quelle del tuo BLL. Ora, vuoi distribuire un sito web che convive con i tuoi servizi WCF e che acceda al tuo DAL attraverso la BLL?

Se il caso è come l'ho capito, allora sono d'accordo con il tuo tecnico senior, semplicemente perché ora dovrai assicurarti che le librerie BLL distribuite sia nel server WCF sia nel progetto ASP.NET siano sempre in sincronia. Tuttavia, se il risultato della performance è degno di nota, allora opporrei contro questo approccio poiché il guadagno è molto più piccolo del costo.

Se tuttavia, ciò che si vuole fare è avere i servizi WCF e il sito ASP.NET live side-by-side nello stesso IIS / Sito Web / AppPool, quindi penso che il proprio senior abbia sbagliato e io (personalmente ) pensa di aver sbagliato SOA. Un servizio "normale" dovrebbe vivere la propria vita e, a seconda di quanto grande è il servizio, potrebbe avere una normale architettura a più livelli. In un'architettura a più livelli hai una o più visualizzazioni, un dominio, alcuni BLL e uno o più DAL. In questo caso si sta semplicemente aggiungendo una vista: "Ieri abbiamo esposto la nostra logica applicativa tramite WCF, ma ora la esponiamo anche tramite ASP.NET". Secondo me, passare a WCF in questo caso, equivale ad aggiungere un layer REST / JSON su un layer WS / SOAP e fare tutta la traduzione necessaria tra di loro. Perché dovresti farlo se sono davvero solo viste differenti della stessa applicazione?

    
risposta data 18.03.2015 - 14:15
fonte
0

Facciamo un passo indietro e affrontiamo termini più semplici: indipendentemente dal fatto che l'architettura del tuo sistema si adatti al paradigma SOA, trattiamo con » sistemi distribuiti « e » architettura client-server «.

Qual è l'obiettivo principale, scegliendo un sistema distribuito? Il disaccoppiamento . Dato che stai utilizzando un server del database e la logica aziendale è il client , il tuo sistema è ( leggermente ) disaccoppiato e potrebbe essere chiamato distribuito .

Se ottengo la giusta architettura, hai un database, che viene utilizzato da un livello aziendale per eseguire determinate operazioni sui dati. Il livello aziendale stesso è (solo) accessibile tramite WCF . Quindi questo assicura un ampio disaccoppiamento dei componenti:

1) Database

2) Business Logic

3) Un livello di presentazione ( WPF )

Se vuoi, puoi fare un ulteriore passo avanti e dividere (2) in componenti più piccoli senza disturbare (1) o (3) : Supponiamo di avere un endpoint per accounting un altro endpoint per impiegati , le modifiche sono trasparenti per (1) o (3) . L'unico punto di accoppiamento è il punto finale ; quindi potresti anche fare una dividere a metà , un'applicazione indipendente sta facendo contabilità un'altra dipendenti senza apportare modifiche a (1 ) o (3) .

Se ora aggiungi » un riferimento al progetto BLL dal progetto MVC e hai fatto accesso ai dati direttamente tra i controller MVC e le classi BLL. « sei stringere il disaccoppiamento di nuovo. Ogni cambiamento importante nella BLL forza le modifiche nel tuo MVC -Project.

Our senior technical chap objected to this, and said I was breaking SOA. He wants me to add WCF service references to the MVC project, and access the data via WCF.

Ha ragione.

My argument against this is that going via WCF does not add anything of benefit to the MVC project, but hurts the performance Au contraire: it looses the coupling, which has clear advantages as said above.

Se danneggia le tue prestazioni, il tuo problema probabilmente si trova altrove .

Furthermore, performance is critical in this MVC project, and I don't want to do anything that will impact the performance unless there is a very good reason to do so.

Vai e correggi il problema delle prestazioni prima di discuterne ulteriormente.

Even if we optimise the WCF project, it is still always going to be slower than accessing the BLLs directly.

Sì. Questo sarà sempre il caso. Ma non è rilevante. Il link stesso è per lo più il fattore più veloce - se non vai al tuo ops-ragazzo. Il più delle volte il problema è una query non efficiente o lenta businesslogic . Fai i compiti prima lì e non ti interessa il sovraccarico causato da una chiamata alla WCF .

I don't see any requirement to use web services to call it SOA

Il punto è: indipendente dal suo nome, il suo scopo è disaccoppiare .

A parte: Perché bitching in giro?

If he's right, then fair enough, we'll have to suffer the performance hit.

Questo non ha senso (in primo luogo) e altro: è puramente teatrale . Vai e chiedigli le sue ragioni, esprimi le tue preoccupazioni e trova una soluzione insieme! .

    
risposta data 18.03.2015 - 14:57
fonte
0

Riesco a capire la tua opinione, sono stato in una posizione simile con troppi layer WCF tutti sulla stessa scatola, ognuno dei quali ha passato la stessa chiamata nello stack.

Tuttavia! il punto di SOA è che puoi orchestrare i tuoi servizi. se salti un livello, hai perso quella flessibilità.

ad es. Voglio che eventuali chiamate alla logica X attivino anche la logica Y. Posso aggiungere la chiamata extra al servizio o aggiungere ulteriore routing alla mia orchestrazione. Ma se la tua app chiama direttamente la logica X, salterà la mia iniezione logica Y.

Solo perché attualmente non hai un Y logico logico, il servizio non ha valore.

Prestazioni: WCF non aggiungerà una quantità significativa di tempo alla tua chiamata web. Se è qualcosa che non va, e il servizio ti offre opzioni di cache e scalabilità.

    
risposta data 19.05.2015 - 16:20
fonte

Leggi altre domande sui tag