WebServices, WSE e il tracing...
- 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;
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