Post

Visualizzazione dei post da novembre, 2012

WCF RESTful service: esposizione del servizio

Previously on "Zen Programming"... Nel precedente post abbiamo visto come realizzare un servizio RESTful basato su WCF; ma ci siamo fermato al più bello, cioè a come "hostare" il servizio web su IIS. Prima di tutto abbiamo bisogno di un file ".svc"...eh, ma sarebbe troppo facile...no? Quindi ho colto l'occasione per illustrarvi un'altra meravigliosa caratteristica di WCF, detta "service activation": l'handler del servizio sarà generato utilizzando solo la configurazione dell'applicazione, senza un file reale che funga da endpoint per l'invocazione. Per far questo abbiamo bisogno di un "service host factory", cioè una classe che eseguirà la generazione (la "produzione", essendo "factory") dell'istanza del servizio basato sull'interfaccia "ISimpleRestService". Il codice è autoesplicativo: basta derivare la classe base "ServiceHostFactoryBase" ed eseguire l'over

WCF RESTful service: cuocere per 5 minuti e servire

Spesso mi capita di lavorare con soluzioni architetturalmente articolate, che magari prevedono l'esposizione di servizi web in grado di permettere una certa interoperabilità o comunicazioni con sistemi esterni. Sempre più di frequente l'interoperabilità di cui parlo si applica anche all'interno della stessa piattaforma software, tra moduli divesi; tutte queste entità devono collaborare insieme con lo scopo prefissato dal flusso funzionale. Quando l'obiettivo è creare un servizio web, la scelta che nella maggior parte delle volte si fa è quella di SOAP, cioè quella di un web service "standard", che si basa su un contratto che l'utilizzatore deve "accettare" prima di poter dialogare con l'entità che "offre" il servizio. Naturalmente io non ho mai fatto eccezione a questa regola, se non quando mi sono dovuto confrontare con una soluzione che basava sulla comunicazioni tra servizi web, la maggior parte del proprio source code. Con i

Cancellazione fisica vs cancellazione logica dei dati

Finalmente dopo lungo tempo trovo il tempo di bloggare qualche "inutile sbrodolata"... L'altro giorno mi trovavo presso un cliente che, giustamente, lamentava problemi di performance su un applicativo. La discussione è stata piuttosto lunga e si sono toccati tanti temi; fino a che non si arriva alla fatidica domanda che ha fatto scaturire questo post: "Ma questo software utilizza la cancellazione fisica dei dati oppure la cancellazione logica?". "Logica...", rispondo io. E lui: "Per quale motivo è stata fatta questa scelta? Non è che i motivi di questa lentezza sono causati da questa scelta?". Rapidamente ho dovuto "radunare le mie forze", e ricordarmi tutti i motivi per cui, anni fa, ho intrapreso questa strada come "default" per i miei progetti (con le dovute eccezioni). A seguire, vi riporto quello che i miei 4 neuroni sono riusciti a partorire dopo la riflessione... «Quando si esegue la progettazione di un siste