Ruolo di WCF in applicazioni distribuite.

Ciao a tutti, ecco il mio primo post con il nuovo account ... Purtroppo ho perso quello vecchio.

Allora volevo discutere riguardo il ruolo di WCF in applicazioni distribuite. Mi piacere fare alcune considerazioni riguardo quello che si puo' e non si puo' fare e perche'.

Partirei con il discorso dei dati passati. Ho riscontrato divergenze riguardo il concetto di passare Dto attraverso WCF per nascondere il dominio, ma se andiamo a leggere un paio di definizioni ci accorgiamo che anche Fowler dichiarava che:
"When you're working with a remote interface [lo interpreto come WCF ...], such as Remote Facade (388), each call to it is expensive. As a result you need to reduce the number of calls, and that means that you need to transfer more data with each call" ... e qui fa poi riferimento ai Dto.

Secondo: posso dichiarare che il service layer, in alcuni casi, e' il mio servizio WCF? Avere un servizio WCF che funge da interfaccia verso il repository, quindi verso il DAL, e' sbagliato? Perche'? Se la mia necessita' e' quella di NON esporre il dominio al client ma solamente un sub-dominio di DTO, cosa c'e' di sbagliato nell' usare questo approccio?

Se tutto cio' non ha senso allora la mia ultima domanda e': quando e perche' devo usare WCF e quando invece va evitato come la peste?

Per chi non fosse .NET oriented, possiamo tranquillamente interpretare il mio termine WCF con un piu' ampio concetto di SOA.

 

Ciao raffaeu,

You wrote on 10/03/2010 :
> Partirei con il discorso dei dati passati. Ho riscontrato divergenze riguardo
> il concetto di passare Dto attraverso WCF per nascondere il dominio, ma se
> andiamo a leggere un paio di definizioni ci accorgiamo che anche Fowler
> dichiarava che: "When you're working with a remote interface [lo interpreto
> come WCF ...], such as Remote Facade (388), each call to it is expensive. As
> a result you need to reduce the number of calls, and that means that you need
> to transfer more data with each call" ... e qui fa poi riferimento ai Dto.

concordo, ma qui non si parla di dto ma piuttosto di cosa e quanto
passare, i dto secondo me (nella loro implementazione nel mondo dei
servizi) nascono per risolvere il problema della interoperabilit� e
della non serializzabilit� di alcuni tipi.

In generale comunque non ho nulla contro i dto :-)

> Secondo: posso dichiarare che il service layer, in alcuni casi, e' il mio
> servizio WCF? Avere un servizio WCF che funge da interfaccia verso il
> repository, quindi verso il DAL, e' sbagliato? Perche'? Se la mia necessita'
> e' quella di NON esporre il dominio al client ma solamente un sub-dominio di
> DTO, cosa c'e' di sbagliato nell' usare questo approccio?

nulla

> Se tutto cio' non ha senso allora la mia ultima domanda e': quando e perche'
> devo usare WCF e quando invece va evitato come la peste?

in realt� va sempre bene, lo strumento � una cosa l'uso che ne fai
un'altra

> Per chi non fosse .NET oriented, possiamo tranquillamente interpretare il mio
> termine WCF con un piu' ampio concetto di SOA.

ecco il nocciolo sta qui, bisognerebbe chiedersi

* "perch� ci metto wcf?"
* perch� fa figo? o perch� ho veramente un'architettura basata su SOA?
* e se non ho un modello che abbraccia i principi di SOA sto usando wcf
male o va bene lo stesso?

domande che hanno una risposta solo ed esclusivamente se le caliamo in
un contesto concreto.

..m

--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCP
http://mvp.support.microsoft.com
http://blogs.ugidotnet.org/topics
whynot [ at ] topics [ dot ] it

Poi mi dici dove hai trovato l' avatar dei Kiss ... [:)]

Allora diciamo pure che la soluzione adottata e' sbagliata.

Guardiamo il requisito del cliente:
1) nascondere il dominio nelle applicazioni client
2) non fornire accesso diretto al data layer dal client, onde evitare stupide queries del tipo uow.Find<Product>() {Tradotto in SELECT *}

Perche' WCF? Sinceramente non lo so, diciamo pure che faceva figo e che era stupido usare gli .asmx nel 2009, un po' come usare una applet, non ha senso oggi.

L' architettura dovrebbe essere SOA, per il semplice motivo che dovrebbe esistere un 'centro' di business e distribuzione dei dati e diverse applicazioni client che non conoscono nulla se non i dto prelevati da WCF.
E" chiaro che prima o poi ti scontri con il client che carica una griglia paginata di dati, e ha bisogno di fare una cosa del tipo
svc.GetOrder(....., 10, 1) che dovrebbe avere una firma del tipo GetOrder(string name, int items, int page). Questo e' solo un esempio.

In SOA cosa faresti? Un Dto per ogni metodo che rappresenta i criteri di ricerca disponibili? In modo da avere una cosa del tipo:
GetOrder(SearchOrderCriteriaDto criteria); e cosi' via?

Se mi dici di si, mi sparo ... li ...

Ciao raffaeu,

You wrote on 10/03/2010 :
> Poi mi dici dove hai trovato l' avatar dei Kiss ... [:)]

su un disco storico ce ho in casa :-)

> Allora diciamo pure che la soluzione adottata e' sbagliata.

io non l'ho mica detto :-)

> Guardiamo il requisito del cliente:
> 1) nascondere il dominio nelle applicazioni client

perch�?

> 2) non fornire accesso diretto al data layer dal client, onde evitare stupide
> queries del tipo uow.Find() {Tradotto in SELECT *}

Questo mi piace ;-)

> Perche' WCF? Sinceramente non lo so, diciamo pure che faceva figo e che era
> stupido usare gli .asmx nel 2009, un po' come usare una applet, non ha senso
> oggi.

La scelta tencnologica incide molto poco in questo caso.

> L' architettura dovrebbe essere SOA, per il semplice motivo che dovrebbe
> esistere un 'centro' di business e distribuzione dei dati e diverse
> applicazioni client che non conoscono nulla se non i dto prelevati da WCF. E"
> chiaro che prima o poi ti scontri con il client che carica una griglia
> paginata di dati, e ha bisogno di fare una cosa del tipo svc.GetOrder(.....,
> 10, 1) che dovrebbe avere una firma del tipo GetOrder(string name, int items,
> int page). Questo e' solo un esempio.
>
> In SOA cosa faresti? Un Dto per ogni metodo che rappresenta i criteri di
> ricerca disponibili? In modo da avere una cosa del tipo:
> GetOrder(SearchOrderCriteriaDto criteria); e cosi' via?

cominciamo a mettere i puntini sulle "i", SOA significa rispettae i 4
principi fondamentali:
http://www.soainstitute.org/articles/article/article/the-four-tenets-of-service-orientation.html

se non sono SOA mica vuol dire che sto sbagliando semplicemente vuol
dire che sto usando wcf per mettere in piedi un application server per
un'applicazione client-server e ci sono tantissimi buoni motivi per
farlo.

Quindi non � tanto SOA o non SOA che determina cosa fare quanto
piuttosto i requisiti non funzionali e il macro-scenario, ad esempio:

- ho necessit� di poter raggruppare n chiamate ad un servizio in
maniera atomica *senza* dover tenere in considerazione le transazioni
distrbuite (il male assoluto :-));
- ho necessit� di poter gestire il versioning dei messaggi e dei
servizi in maniera trasparente;
- devo poter supportare il funzionamento side-by-side di versioni
diverse dei messaggi e dei servizi;
- devo scalare orizzontalmente, veramente non solo sulla carta;
- devo essere idempotente e contestualmente distribuito, ma veramente
distribuito;
- ho scenari in cui i dati sono distribuiti in-the-cloud e la
consistenza degli stessi non � garantita da vincoli relazionali (perch�
non ha senso un vincolo relazionale in-the-cloud)

..m

--
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCP
http://mvp.support.microsoft.com
http://blogs.ugidotnet.org/topics
whynot [ at ] topics [ dot ] it