No, per vostra sfortuna non sono scomparso 
. E' solo che dopo un durissimo "tour de force" lavorativo, la ristrutturazione di casa mia e le feste, passate veramente in un lampo, ho avuto davvero poco tempo per fare quello che avrei voluto. E' strano. Ogni volta prima di un periodo di ferie progetto tutto quello che vorrei fare. Avevo in mente:
- di scrivere un paio di articoli
- di continuare la serie WCF REST
- di completare il "restauro" della mia mountain bike
- di fare un po di sport (footing, bici, partita di tennis...)
- di completare la lettura di "Gomorra"
- di scrivere un controllo per WCF REST Starter Kit
- di fare un paio di modifiche al sito dotnetside.org
- di godermi qualche bel film
Risultato? Ho scritto solo mezzo articolo 
ma almeno la ristrutturazione di casa mia è in dirittura d'arrivo (o almeno lo spero).
Quanto a noi di DotNetSide, ci stiamo rimettendo in moto dopo un periodo di pausa. Ho in mente diverse cose che prenderanno forma nei prossimi mesi. Se ci sono proposte di qualunque tipo fatevi pure avanti e non esitate a contattarci, a noi farebbe davvero molto piacere.
I buoni propositi per il nuovo anno sono tanti ed è inutile elencarli. Spero di poterli realizzare con calma e serenità ed auguro lo stesso a tutti voi.
Anche se con qualche giorno di ritardo...Buon Anno!!!
Tanti auguri di Buon Natale a tutti !!!
Il PortSharing è un meccanismo che permette, come è facile intuire, di condividere la stessa porta su diversi servizi. Nel mio specifico caso mi serviva per esporre i metadati del mio servizio su un secondo endpoint. Partiamo con l'osservare la configurazione del servizio. Definisco un baseAddress acquisito come indirizzo primario del mio servizio e come indirizzo, con l'aggiunta del segmento mex, dei metadati esposti con l'utilizzo della specifica WS-MetadataExchange:
<services>
<service name="MyService"
behaviorConfiguration="MyService_ServiceBehavior">
<host>
<baseAddresses>
<add baseAddress="net.tcp://localhost:9999/MyService"/>
</baseAddresses>
</host>
<endpoint address=""
binding="netTcpBinding"
contract="IMyService"
bindingConfiguration="MyService_netTcpBinding"/>
<endpoint address="mex"
binding="netTcpBinding"
contract="IMetadataExchange"
bindingConfiguration="MyService_mexBinding"/>
</service>
</services>
I due endpoint fanno riferimento a due sezioni netTcpBinding dove imposto l'attributo portSharingEnabled:
<bindings>
<netTcpBinding>
<binding name="MyService_netTcpBinding" maxConnections="5"
portSharingEnabled="true">
<security mode="None">
<transport protectionlevel="None"/>
<security>
</binding>
<binding name="MyService_mexBinding"
portSharingEnabled="true">
<security mode="None">
<transport protectionlevel="None"/>
<security>
</binding>
</netTcpBinding>
</bindings>
Per abilitare la visualizzazione dei metadati impostiamo il relativo behavior del servizio:
<serviceBehaviors>
<behavior name="MyService_ServiceBehavior">
<serviceMetadata />
</behavior>
</serviceBehaviors>
Infine, affinchè tutto funzioni, da VS2008 Command Prompt dobbiamo eseguire, come amministratore della macchina, il tool da riga di comando:
C:\sc.exe config NetTcpPortSharing start= demand (Attenzione, lo spazio tra start= e demand è importante!!!)
Questo comando ci consente di avviare il servizio NetTcpPortSharing su richiesta, e quindi al primo utilizzo. Ora non ci resta che eseguire la nostra applicazione...
Maggiori info.
Refactoring continuo. Mi accorgo sempre di più come questo sia importante, quasi necessario. Ogni volta che vedo del codice, anche e soprattutto se scritto da me, sono tentato di riscriverlo completamente. In una forma migliore, più leggibile forse. Ma anche semplicemente per riorganizzarlo. Tendo a migliorare (chiaramente 
) la parte di codice che mi passa tra le mani. Ovviamente il tutto senza causare regressioni.
Capita anche a voi? Avete anche voi questo istinto/bisogno irrefrenabile?
Da oggi ho un fastidiosissimo problema su VS2008 SP1. In pratica non riesco a visualizzare le proprietà di nessun progetto. Causa problemi di connessione del nostro gestore nazionale, oggi non ho potuto chiedere a zio google perciò ho provato a far partire visual studio con il parametro /ResetSettings. Niente. Non ha funzionato. Stasera quindi ho chiesto consiglio e la risposta "sembra" essere arrivata. In pratica il tutto si dovrebbe risolvere con il comando:
devenv.exe /resetskippkgs
e dire che ci avevo pensato ma mi sembrava non c'entrasse nulla e ormai stanco non ci ho neanche provato.
Domani a mente fresca sarà il mio primo pensiero appena in ufficio. Vi farò sapere... 
UPDATE: Funziona perfettamente !!!
Con questo post inizio una serie dedicata a REST e al suo utilizzo all'interno di WCF. Partiamo quindi dall'inizio. Cos'è REST? REST sta per REpresentional State Transfer ed indica uno stile architetturale (non una tecnologia o una specifica, tenetelo bene a mente) per la realizzazione di soluzioni distribuite.
Non mi dilungo molto sulla definizione di REST per la quale vi rimando alle seguenti risorse:
Anche nella precedente versione di WCF era possibile utilizzare REST, ma si doveva scrivere parecchio codice prima di raggiungere un risultato accettabile. Nella versione 3.5, invece, sono state introdotte diverse novità che semplificano di molto l'approccio ma soprattutto l'integrazione con le altre tecnologie come ASP.NET AJAX e Silverlight.
Concetti base di REST
L'approccio REST, trattandosi appunto di uno stile architetturale, ci impone l'adozione di alcune regole. Innanzitutto, a differenza di quanto accadde nelle SOA, l'obiettivo principale non è il servizio reso, ma la risorsa con la quale intendiamo interagire. La risorsa deve necessariamente essere identificata univocamente e per questo necessità di un URI ben definito. Immaginiamo di voler accedere alle informazioni della risorsa "fabio.cozzolino" che identifica un utente nel dominio dotnetside.org. A quel punto il suo URI potrebbe essere:
http://dotnetside.org/members/fabio.cozzolino
In questo modo viene identificato univocamente l'utente "fabio" nel dominio dotnetside.org. Identificata la risorsa, posso decidere quali sono i metodi HTTP che devo utilizzare per richiedere la risorsa stessa o modificarne lo stato.
| Metodo HTTP |
Descrizione |
| GET |
Recupera una risorsa
E’ in sola lettura
Cacheable
|
| PUT |
Aggiorna una risorsa
Utilizzato anche per creare le risorse se il client ne conosce l’indirizzo a priori
Idempotent
|
| DELETE |
Cancella la risorsa specificata
Idempotent
|
| POST |
Crea una nuova risorsa
Unsafe
|
Il vantaggio di utilizzare i metodi HTTP consiste nel fornire le nostre applicazioni di una interfaccia unica e condivisa. GET,PUT,DELETE,POST sono metodi universalmente conosciuti e ampiamente supportati da diversi framework. In sostanza, quindi, l'utilizzo dell'HTTP, dei suoi metodi e più ampiamente anche dei suoi messaggi di risposta (Status Code) consente l'accesso alla nostra applicazione a qualsiasi client che li supporta, semplificandone l'utilizzo rispetto al più complesso sistema gestito in SOA.
REST sostituisce SOAP?
E' questa una domanda piuttosto frequente alla quale cercherò di dare una risposta definitiva. ASSOLUTAMENTE NO!!! Parliamo di due cose decisamente differenti. SOAP è un protocollo per lo scambio di messaggi tra un client ed un servizio. A SOAP, basato su xml e il cui formato è sostanzialmente molto semplice, si sono via via aggiunte negli anni una serie di specifiche (WS-*), di sicuro necessarie, che ne hanno reso però complesso l'utilizzo.
Ma con REST non stiamo scoprendo l'acqua calda. Esiste da diversi anni. Semplicemente il crescere di soluzioni web che fanno uso di AJAX o di Silverlight richiedono lo sviluppo di servizi semplici, facilmente consumabili. Questo ha portato alla ricerca di una soluzione alternativa a quella Service Oriented, spostando l'attenzione quindi su una soluzione ora definita come Resource Oriented (ROA, Resource Oriented Architecture).
Nei prossimi post vedremo come utilizzare REST in WCF.
Oggi abbiamo superato quota 1000 ISCRITTI !!! Un risultato grandissimo. GRAZIE a tutti!!!
Tutto questo si aggiunge all'ottima partecipazione avuta ieri durante l'evento Microsoft Days'08. Durante la giornata erano presenti all'incirca 300 persone mentre al Community After Hour eravamo sulla cinquantina di presenti. Un evento con un bacino di partecipanti più ristretto ma che hanno tenuto duro fino alla conclusione quando le lancette segnavano ormai inesorabilmente le 22:30.
E' sempre un piacere incontrare vecchi e nuovi amici. La community cresce e ci fa davvero molto piacere. Ed il prossimo anno ne vedrete delle belle, promesso ... .
Come promesso durante l'evento, nei prossimi giorni approfondirò molti dei temi trattati attraverso una serie di post. A breve pubblicherò anche le slide e le demo fatte durante l'evento. Nel frattempo giusto qualche foto scattate con la mia fotocamera di emergenza, il telefonino :
Pietro all'opera...
Giuseppe, un fiume in piena ... 
Manca ormai pochissimo alla tappa di Bari dei Microsoft Days'08 e i preparativi fervono. La sera, a partire dalle 18:00, vi aspettiamo con il Community After Hour e ho finalmente il piacere di annunciarvi che, oltre alle tre sessioni già previste, si aggiunge una sessione di apertura tenuta da Giuseppe Dimauro. Giuseppe è un grande amico di .netSide e, quando può, come in questo caso, ci dà molto volentieri una mano. Da parte mia non posso che ringranziarlo e ribadirgli che il suo contributo è davvero molto importante per noi.
Oltre all'evento community, noi di .netSide saremo presenti tutto il giorno e disponibili a chiacchierare con chiunque di voi abbia il piacere di farlo. Fatevi avanti, saremo lì apposta .
Per tutto il resto ... ci vediamo mercoledì, vi aspettiamo...
Se non siete ancora registrati potete farlo da qui
BASTA! è attualmente la più grande ed importante conferenza tedesca su .NET.
Finalmente ora sbarca anche in italia grazie alla collaborazione con Dino
Esposito, più volte speaker nell'edizione tedesca, che insieme a Sebastian Meyen
ha creato BASTA!Italia, un evento con tre giorni di workshop e sei track
differenti previsto a Roma dal 16 Marzo al 18 Marzo 2009. Un evento sicuramente
imperdibile.
Per chi è interessato fino al 12 Dicembre è possibile prenotarsi con la
formula del Very Early Bind. Prima prenotate più risparmiate.
Tutte le info sul sito ufficiale: http://www.bastaitalia.it.
... che hanno vinto un premio, compreso chi ha vinto il buono per il libro di Simone, vi chiedo di ricontattarmi privatamente attraverso questa pagina semplicemente per confermare i vostri contatti (email, etc...) al fine di poter ricevere il vostro premio. Grazie.
Negli ultimi giorni la notizia è rimbalzata molto. Forse troppo. Ad una prima lettura non mi era sembrato di aver letto che Microsoft ha deciso di "ammazzare" Linq To SQL. E' chiaro che due prodotti che in sostanza hanno lo stesso obiettivo si pestano un po i piedi. Una scelta è quindi d'obbligo e mi sembra scontato che Linq To Entities e Entity Framework hanno la meglio. E' semplice. Microsoft sta investendo davvero molto in Entity Framework.
Ecco che Microsoft ha voluto essere schietta e "avvisare" le community di sviluppatori che Linq To Entities sarà la strada maestra, quella su cui conviene investire. Ed è stata l'impressione che personalmente ho avuto dopo aver letto il post. Ma vari commenti che ho letto successivamente mi hanno un attimo lasciato perplesso. Linq To SQL è già morto? Anche se qualcuno è contento ... probabilmente no. Anzi, Linq To SQL continuerà a vivere ma vedrà crescere molto più rapidamente il suo fratellino, che senza dubbio un giorno, quando sarà grande, avrà deciso cosa fare.
L'ho detto diversi mesi fa: ero e sono convinto che Linq To SQL confluirà in Linq To Entities. Quello che funziona in Linq To SQL verrà senza dubbio introdotto in Linq To Entities. Chi ha investito in Linq To SQL continuerà (forse) ad utilizzarlo e non credo che nelle prossime versioni del .NET Framework verrà eliminato. Di sicuro non dobbiamo aspettarci novità, quelle sono riservate a Linq To Entities. Ma credo che l'investimento attualmente fatto in progetti, già conclusi o magari in corso di realizzazione, che sfruttano Linq To SQL non è assolutamente in bilico. L'avviso mira semplicemente a dire: se dovete investire, fatelo in Linq To Entities ma soprattutto diteci cosa salvereste di Linq To SQL. E lo hanno chiarito oggi.
Ma nel frattempo che si fa? Se Linq To SQL non evolverà e se Linq To Entities v1, la versione attualmente distribuita, è praticamente inutilizzabile, che si fa? Cosa dobbiamo utilizzare se vogliamo utilizzare un OR/M? NHibernate o ci scriviamo una DAL "old-style"? Boh...
Vedremo nei prossimi mesi, quelli che ci dividono dall'uscita del .NET Framework 4.0.
La mia non è la voce ufficiale Microsoft, assolutamente no. Sono solo mie considerazioni che vorrebbero aprire ad una discussione. I commenti sono aperti.
Per chi volesse già provare la prossima versione di Visual Studio ecco la pagina con tutti i riferimenti:
https://connect.microsoft.com/VisualStudio/content/content.aspx?ContentID=9790&wa=wsignin1.0
Il download è disponibile grazie ad una immagine per Virtual PC, una modalità già percorsa in passato e che ritengo sicuramente migliore rispetto all'installazione su macchine reali, cosa che non mancava mai di "infestarci" il pc ... .
Da quando uso l'Inversion of Control...vivo meglio. Sembra quasi uno spot pubblicitario ma è la verità. Anche se di sicuro, purtroppo, non ho vinto i 100milionidieuro, con l'IoC risolvo davvero molti problemi e in un tempo così ridotto da non crederci. Non ho scoperto l'acqua calda, questo è sicuro, ma solo oggi trovo il tempo per iniziare a parlarne.
Giusto qualche link per iniziare:
I tool più diffusi con .NET:
Se ne conoscete altri, fatemelo sapere. Io utilizzo il Windsor Container e magari posto qualcosa nei prossimi giorni. Perchè? Risponde perfettamente alle mie attuali esigenze.
... è ormai tracciata. E' infatti disponibile la prima CTP pubblica di Oslo, un set di tool per lo sviluppo di applicazioni Model-Driven. Tutto quello che volete sapere su Oslo lo trovate qui:
Oslo Developer Center
Ps.: si vede che c'è la PDC???
E' stato da poco rilasciato su codeplex uno starter kit completamente dedicato alla creazione di servizi REST con WCF. Contestualmente un nuovo dev center concentra tutti i link e le risorse (Screencasts, whitepapers, documentation, roadmap, etc...) in un unica pagina. Imperdibili.
Vi ricordo che durante il Community After Hour parleremo proprio di questo e di molto altro...non mancate!!!
More Posts
Next page »