Newsgroup: it.comp.dotnet
Titolo: WCF e servizi stateless

Ciao a tutti,
Premessa: per chi frequenta i forum di Guisa.org questo potrebbe 
sembrare crosspost. In realtà non lo è. :-)
Ho una domanda "di concetto". Dal basso della mia esperienza, ho capito 
che se in una applicazione ho un service layer che comunica con il mondo 
esterno tramite Dto, i servizi nel service layer devono essere stateless.
Ora, avrei la necessità di esporre questo service layer in un WCF. Che 
faccio: devo layerizzare di nuovo (i.e. doppi servizi e doppi Dto)? 
Oppure basta mettere gli attributi giusti sui servizi definiti nel 
service layer?
Grazie,
Giulio
-- 

 service layer?
Direi che dipende dal dettaglio di come sono architettati i servizi in
questione. Se sono solo facade e la logica sta "sotto", direi di si',
altrimenti sei giunto al punto in cui vale la pena di astrarre appunto
una facade.
-LV

 una facade.
Ti espongo il caso concreto. Ho un servizio che ritorna un Dto molto 
complesso. A questo livello è implementato un QueryObject, i.e. chi 
consuma il service layer può interrogare il servizio con un oggetto che 
viene poi interpretato dall'implementazione del servizio e trasformato 
in una serie di query LINQ sui repository delle varie entità (i cui 
risultati vengono poi spiattellati su una lista di dto).
Ora, la mia idea è quella di esporre il servizio in questione come 
servizio WCF. Per questa cosa qui, mi sto facendo alcuni problemi. Il 
primo - più banale - è di "riusabilità": se volessi usare il servizio 
senza l'infrastruttura WCF avrei comunque un riferimento a 
System.ServiceModel e System.Runtime.Serialization (per i Dto). Poco 
male. :-)
Il secondo riguarda la gestione della sessione, ecc ecc... In un 
contesto 
ASP.NET
 la vita della sessione viene definita nel Global.asax e 
non riesco a figurarmi un modo per fare la stessa cosa in WCF, anche 
perché non sono ancora riuscito a figurarmi come creare le istanze dei 
servizi tramite IoC.
Quello che sto pensando di fare è di:
- inserire i Dto in un assembly a parte e marcarli come DataContract
- creare dei servizi-façade che altro non fanno che instanziare i 
servizi veri, passarli i Dto e rimandare indietro altri Dto (quindi 
façade->Dto)
- creare un service layer "normale" (quindi servicelayer->Dto).
Hai/avete qualche link a qualche risorsa introduttiva?
Ciao,
Giulio
-- 

 servizi tramite IoC.
Suppongo che ci siano vari modi, fino ai piu' custom: ma il tuo
quesito qui diventa troppo specifico per le mie... specifiche
competenze tecniche.
-LV

 Global.
Rettifico: in 
asp.net
 per me lo stato non esiste :-P. Nel global.asax:
- faccio il bootstrap dell'applicazione nell'application startup
- per ogni richiesta instanzio (all'inizio) e "flusho" (alla fine) la 
sessione di NHibernate
Ciao,
Giulio
-- 

 servizi WCF?
il cuore della risposta dovrebbe essere: SOA?
Perchè voui esporre un servizio?
.m
-- 
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCTS
http://mvp.support.microsoft.com
blog @ 
http://milestone.topics.it
whynot [ at ] topics [ dot ] it

 Perchè voui esporre un servizio?
Ottima osservazione. :-)
Diciamo che sto cercando di gestire al meglio una situazione abbastanza 
"complessa". Ho una applicazione web che oltre a fare il suo lavoro deve 
gestire dei job periodici in background e una specie di demone che gira 
sempre. Una piccola porzione dell'app web funge da management console 
anche per questo demone e per i vari job (verifica quali job sono in 
esecuzione, avvia/stoppa...).
La mia idea era quindi di avere un service layer nell'applicazione web 
che altro non fosse che una interfaccia a un servizio WCF che facesse da 
façade per:
- il modello vero e proprio
- il demone che gira
- i vari job
Pensavo di realizzare tutto in WCF visto che l'idea di esporre una 
interfaccia basata (ad esmepio) su remoting in un servizio windows mi fa 
impallidire (innanzitutto perché non l'ho mai fatto, in secondo luogo 
perché con WCF mi pare assolutamente più facile).
Ciao e grazie (e buona giornata/settimana),
Giulio
-- 

 con WCF mi pare assolutamente più facile).
ottima scelta. Quale è il problema quindi?


 Quale è il problema quindi?
Il problema nasce dalla mia ignoranza/inesperienza. Finora, quando ho 
sviluppato applicazioni web, ho sempre usato un Service Layer fatto di 
servizi "stateless". La comunicazione tra il SL e il Presentation Layer 
(PL) è fatta tramite Dto. Fin qui, nessun problema.
In questa situazione, il servizio WCF non può essere propriamente 
stateless, in quanto il demone, i job, ecc ecc... prevedono che ci sia 
"qualcosa" di sempre caricato. Quello che mi viene in mente allora è: PL 
-> Servizio WCF -> l'implementazione del servizio vede quello che deve 
fare, eventualmente parla con il demone e/o con i job, e poi -> 
orchestra una chiamata al service layer (stateless).
Di fatto o ri-layerizzato, introducendo un façade. Con i Dto me la sono 
cavata con una soluzione "a la" separated interface e li ho estratti in 
un assembly a parte, marcandoli con DataContract e DataMember (in modo 
da poterli usare tali e quali nell'interfaccia del servizio WCF). Qui 
nasce il problema: di fatto, buona parte del façade mappa 1:1 i metodi 
del service layer. Mi chiedevo allora se avesse senso esporre 
direttamente il service layer come servizio WCF (ok, a occhio la 
risposta è "NO", ma mi sarebbe piaciuto avere un riscontro).
Ciao e grazie,
Giulio
-- 

 (stateless).
direi di si, orchestra e restituisce al client un token per 
identificare il job.


 direi di si
Ottimo! :-)
Grazie,
Giulio
--