Newsgroup: it.comp.dotnet
Titolo: [WCF] WCF o no? (Dummy inside)

Ciao a tutti,
vi espongo brevemente il mio scenario (che fa comunque il paio con 
quello che ho esposto nel thread "Gestione delle transazioni".
Ho un dominio [1] che rappresenta una rubrica telefonica comune a 
diverse applicazioni:
- un client X (WPF o Web) di posta elettronica che si basa sulla rubrica 
dato che i contatti sono dotati anche di indirizzo e-mail
- un client Y Web che permette di editare la rubrica
- un demone Z windows (o comunque qualcosa che "giri sempre") che compie 
dei task periodici sulola ribrica (es: vede quanti contatti festeggiano 
oggi il compleanno e manda a tutti un SMS di auguri, oppure una mail di 
auguri in prossimità del Natale, ecc ecc...)
Attualmente le stesse librerie che implementano il Dal, il business 
layer, ecc ecc... sono oggetto di *tre* diversi deployment. A occhio mi 
verrebbe da dire che una significativa miglioria potrebbe essere quella 
di installare una specie di "backoffice" comune che giri magari in un 
servizio WCF con cui il client di posta e il client web dialogano e che 
"ospita" il demone.
Ora iniziano le domande:
1. secondo voi è un approccio fattibile?
2. se fattibile, è valido?
3. Attualmente le applicazioni X e Y hanno un presentation layer che 
dialoga con un service layer tramite Dto. Quindi avrò una cosa tipo:
class ContactDto { ... }
interface IContactService
{
     ContactDto GetById(object id);
}
class FooDto { ... }
IFooService
{
	FooDto GetByLabel(string label);
}
interface IGreetingsMessageService
{
	string GetBirthdayMessage(object contactId);
}
i vari servizi vengono iniettati in un container Unity al bootstrap 
delle applicazioni, in ogni presentation layer (Controller, ViewModel, 
ecc ecc...) vengono iniettati i servizi che servono. Posso replicare la 
stessa cosa in un hosting WCF? Cioè, posso avere IContactService, 
IFooService, IGreetingService in un unico punto e "risolverli" (in uno 
scenario DI + IoC)?
4. come posso verificare che sia solo l'applicazione X ad accedere al 
dato metodo del dato servizio? E' possibile poi implementare una 
autenticazione a più livelli (del tipo: l'app X può accedere al metodo 
blablabla ma solo se l'utente loggato in X è un admin)?
Grazie in anticipo,
Giulio
[1] ovviamente si tratta di un esempio. :-)
-- 

 2. se fattibile, è valido?
Se per valido intendi efficace, direi proprio di no.
Implementerei tutta la logica, operativa ma anche di servizio
(autenticazione, logging, ecc.) in un unico applicativo (e'
semplicemente una "Rubrica") esposto da WCF: cioe', in un gergo che
puo' esserti piu' familiare, due soli layer principali, model e
application. Dopodiche' qualunque client ti occorra sviluppare avra'
una logica super-leggera di pura presentazione.
Considerazione a margine per i piani alti: invece di organizzare tutti
quei corsi su pattern e framework e salti mortali per andare su
Nettuno passando da Andromeda, sarebbe il caso di concentrarsi sul
"keep it simple", che e' davvero lo skill piu' importante nonche' il
piu' sottovalutato.
My 2c anyway,
-LV


 piu' sottovalutato.
In che senso? Nella mia (limitata) esperienza, una ampia conoscenza di 
"pattern e framework e salti mortali" mi aiuta a centrare sempre la 
soluzione più semplice. Se fossi stato più skillato, magari non avrei 
usato le tre applicazioni diverse in prima istanza. :-)
Tornando a bomba sul mio problema: credo che ora il problema più grande 
sia l'autenticazione "a due livelli"... pensi/ate che sia possibile 
senza troppi spargimenti di sangue? ;-)
Ciao,
Giulio
-- 

 senza troppi spargimenti di sangue? ;-)
Intendi a due ruoli? Guarda l'autenticazione/autorizzazione in WCF,
sono sicuro che si tratta ancora di uno scenario abbastanza base,
soprattutto dopo una semplificazione architetturale come sopra.
-LV

 Intendi a due ruoli?
No, intendo proprio due livelli di autenticazione.
Se l'utente è Admin dell'applicazione X può fare A e B, altrimenti solo 
B. Se invece è Admin dell'applicazione Y può fare A, D, E, altrimenti 
non può fare nulla.
Ciao,
Giulio
-- 

 non può fare nulla.
Si puo' comunque riformulare in termini di un solo bacino utenti con
differenti ruoli: ovvero, di nuovo, si tratta di mettere al centro il
core/model, dopodiche' diventa tutto molto piu' lineare e standard.
-LV

 differenti ruoli
[cut]
Uhm... non mi è molto chiato (per ignoranza mia, sia chiaro). Puoi darmi 
qualche dritta "introduttiva" (link, ecc ecc...)?
Grazie,
Giulio
-- 

 qualche dritta "introduttiva" (link, ecc ecc...)?
Link davvero non saprei, ma si tratta semplicemente di avere un unico
archivio utenti (corrispondenti a utenti reali come nel caso delle UI,
oppure a processi come nel caso del demone). A tali utenti vanno
associati dei ruoli, ciascuno con le opportune autorizzazioni.
Insomma, ci sono alcune varianti al livello implementativo
(organizzazione flat piuttosto che gerarchica dei ruoli), ma al
livello concettuale il tutto e' assolutamente canonico.
-LV

 oppure a processi come nel caso del demone).
Ah, ok... non so come si mappa un utente su un processo ma credo che 
Google possa essere My Friend in questo caso. :-) Per il discorso delle 
UI, onestamente, faccio pià fatica a "concepire" quello che mi serve. Le 
due applicazioni hanno utenti diversi, e possono poter fare le stesse 
cose... va be', vedrò di inventarmi qualche porcata. :-D
Ciao e grazie,
Giulio
-- 

 cose... va be', vedrò di inventarmi qualche porcata.
Ma quale google e google d'Egitto! :) Una tabella utenti, con
username, password e ruolo associato (e magari, se serve, specifica
degli IP o canali autorizzati per quell'utente o ruolo, ecc.):
dopodiche' il client di turno semplicemente passa le credenziali e
viene autenticato/autorizzato. Again, tutto molto canonico.
-LV


P.S. Su quel punto, guardati semplicemente l'autenticazione/
autorizzazione sotto WCF.
-LV

 che ti ho illustrato io al database accede solo e solamente il model.
Infatti sto cercando di ricondurmi a questo caso (ma il db potrebbe 
essere modificato anche da altri applicativi non di mia competenza).
Grazie,
Giulio
-- 

 essere modificato anche da altri applicativi non di mia competenza).
Se' davvero cosi', o il database e' propriamente incapsulato e piu' di
meta' dei problemi che mi hai posto non esistevano proprio, oppure non
c'e' verso di fare qualcosa di pulito. Comunque almeno la tua porzione
la devi architettare a dovere, e poi succeda quel che succeda almeno
non e' responsabilita' tua.
E adesso dimmi un semplice grazie e torna a lavorare.
-LV

 the place.
Comincio a capire.
Cosa intenti però come "dipendenza circolare"?


 Cosa inten[d]i però come "dipendenza circolare"?
Nella sua forma base: se A, B e C sono tre componenti del sistema, hai
una dipendenza circolare quando A->B, B->C e C->A, dove la freccia sta
per "dipende da".
Le dipendenze circolari, facilmente individuabili disegnando appunto
un grafo delle dipendenze, sono assolutamente da evitare sia al
livello concettuale che implementativo perche' rendono impossibile il
disaccoppiamento dei componenti e provocano effetti collaterali a
cascata (tutte le logiche si complicano esponenzialmente, e nei casi
peggiori hai il proverbiale effetto: correggo da una parte e mi si
rompe dall'altra), tanto che le tecniche di inversion of control sono
state pensate proprio a mitigare/risolvere tali circolarita', fermo
restando pero' che una buona impostazione di base evita i problemi a
monte e l'IoC come altri pattern dovrebbe essere applicato ai soli
casi limite dove altrimenti la circolarita' sarebbe proprio
inevitabile.
HTH,
-LV

 Io avevo gia' capito, ma siamo in uno spazio pubblico.
Già.



Un semplice grazie non in firma era sufficiente.
-LV