Tuesday, October 30, 2007

WebServices, WSE e il tracing...

Sto scrivendo un Servizio che, se tutto va come deve andare, verrà esposto al mondo pubblico. Il servizio per garantire la fruibilità dal maggior numero di linguaggi possibili viene erogato in varie versioni:
  • WebService SOAP: il più tradizionale, vengono erogate le funzionalità indispensabili (1) e l'autenticazione viene gestita con un meccanismo custom basato su SoapHeader, l'idea è quella di garantire il canale con SSL;
  • WSE3 e WCF: le funzionalità avanzate di BackOffice e Amministrazione, oltre che quelle di base, sono erogate sia attraverso WSE3.0 che WCF;
ed è proprio WSE3.0 che ieri mi ha dato un bel po' di grattacapi, stavo facendo un po' di Load Testing, mi sono costruito un paio di applicazioni console che martellano il servizio di richieste e praticamente era un disastro... dopo poche (veramente poche) richieste il servizio cominciava a vacillare e ne venivano perse nel nulla un sacco, all'inizio panico soprattutto perchè neanche sul client ricevevo la benchè minima Exception, nulla di nulla, semplicemente almeno il 30% delle richieste finivano nel nulla.
Alla fine ho scoperto che la causa era proprio WSE o meglio il tracing di WSE che era abilitato (lo avevo abilitato tempo fa all'inizio dello sviluppo) e ormai il file di trace era un po' grosso (450Mb circa) facendo andare in bomba tutto...
Ma la cosa più subdola è stata che dall'editor dei settings di WSE il tracing risultava disabilitato! nulla di più falso... il problema alla fine è che l'editor dei settings di WSE non va molto d'accordo con gli Web Application Project di VS2005 e quindi scrive i sui settaggi in un file app.config e non nel file web.config... maledetto lui.
Disabilitato il tracing di WSE il servizio a ripreso a scheggiare come un missile senza perdersi per strada nulla, molto bene!
Ne approfitto per fare anche io una considerazione sul post di Igor e di conseguenza su quello di Marco De Sanctis: quoto in pieno le considerazioni di Marco sui DTO e mi spingo ancora un po' più in la, nei servizi che sto sviluppando non ho la più pallida idea di chi potranno essere i client e la scelta è stata di ridurre all'osso la complessità dei DTO eliminando anche molti dei tipi (nei DTO) che potrebbero portare a problemi. Ad esempio il Business Object lato server ha una proprietà di tipo Guid questa viene passata atteraverso un DTO sotto forma di stringa e viene documentato che dovrebbe essere trattata come un Guid, stessa sorte per i tipi DateTime che vengono convertiti in stringhe in formato UTC.
Tutto questo non per criticare le scelte di Igor, anzi, ma semplicemente per dire che nel momento in cui ci si deve spingere verso la piena interoperabilità è necessario prevedere anche le situazioni più estreme.
.m

1 comment:

  1. Imported comment, original author: Igor Damiani

    nessun problema, Mauro, anzi... :-)Detto bello in chiaro, alla fin fine è come dicevo io fin dall'inizio, cioè cercare di esporre attraverso i DTO pochi "tipi complessi", ma stringhe, bool ed int, senza coinvolgere più di tanto le classi che appartengono al domain-model.Quoto appieno la tua frase "nei servizi che sto sviluppando non ho la più pallida idea di chi potranno essere i client", ma questo imho significa appunto far "viaggiare" tipi base e non tipi appartenenti al domain-model che potrebbero tirare in ballo altri problemi legati alla tecnologia in uso, che è quello che voglio/vogliame evitare.ciaooo!

    ReplyDelete