August 2007 - Posts
Come ho segnalato anche nel mio blog in inglese, oggi io e RoB abbiamo completato le demo della nostra sessione sulla SharePoint Custom Authentication che terremo alla SharePoint Conference 2007, il prossimo 19 e 20 settembre a Segrate.
Tra le parti che troviamo più interessanti e stimolanti c'è l'uso di Windows CardSpace per l'autenticazione forms su un Publishing Portal pubblico e con accesso anonimo consentito.
Se volete vedere che faccia ha il risultato ... date uno sguardo al post inglese, se invece volete capire come l'abbiamo realizzato: iscrivetevi alla conferenza :-) !
Sono proprio contento di scoprire che ora WCS è in beta su Live. Qui trovate maggiori dettagli e i passi per configurare una vostra Card personale. Spero che partendo da Live, WCS si diffonda presto anche su altri siti e portali.
Da poco sono stati rilasciati i nuovi SDK di MOSS2007 e WSS3. Tra le novità più interessanti c'è sicuramente il fatto che adesso è disponibile un tool per definire i file di configurazione di BDC e c'è un esempio di Protocol Handler. Qui in particolare trovate maggiori dettagli sul nuovo BDC tool.
Anche le estensioni di Visual Studio 2005 per WSS sono state riviste e aggiornate. Potete scaricarle da qui, ma restano sempre in CTP.
L'altro giorno ho pubblicato un post nel quale facevo riferimento alla possibilità di scrivere un Message Inspector per WCF. Qualcuno mi ha chiesto maggiori dettagli in merito, quindi ho pensato di scrivere da qui alle prossime settimane qualche post che spieghi le modalità di estensione di WCF.
In questo post del mio blog in inglese spiego come creare un Message Inspector per avere accesso diretto al contenuto SOAP di un messaggio destinato ad un servizio WCF. Nei post successivi mi occuperò di altre tipologie di estensioni all'infrastruttura.
Ho letto questo post di Don Box a proposito dei SOA Tenents e del fatto che per alcune persone essi sarebbero da rivedere/ritirare in quanto non realistici e non attuabili. Innanzitutto condivido completamente la premessa fatta da Don Box sul fatto che non ha senso cancellare la storia e sul fatto che i SOA Tenents sono da considerare come un'indicazione della strada giusta da seguire nel lavorare in ottica SOA, ma non sono un dogma che deve essere seguito in tutto e per tutto e sempre!
Troppo spesso vedo persone aggrapparsi a dogmi, regole e pattern perdendo di vista il vero oggetto dell'architettura software da realizzare. Ovviamente le regole, le guideline, i pattern, ecc. servono e sono utilissimi per evitare di reinventare la ruota e per condividere conoscenza, ma non devono secondo me diventare una ossessione, anzi dovrebbero fare "naturalmente" parte della definizione delle soluzioni. In questi anni ho seguito diverse aziende di software in Italia, per svolgere attività di consulenza su soluzioni SOA, non sempre però i requisiti erano tali da sposarsi correttamente con la filosofia SOA. Condivido assolutamente le idee alla base della Service Orientation, ma proprio per questo non voglio che se ne faccia un uso improprio o un abuso.
Mi preme poi entrare nel merito di una specifica lamentela fatta in questo post: <<WCF Contracts are still CLR-Classes, not Schema or Contract>>.
Devo dire che personalmente nemmeno io amo la definizione dei contratti tramite interfacce e attributi, ma d'altra parte è altrettanto vero che ci sono N modi di aggirare questo fatto, per esempio usando XSD.EXE se si lavora con XmlSerializer oppure "SVCUTIL.EXE /DCONLY" se si lavora con i DataContract. Per altro anche WSSF fornisce tra le varie recipe anche quelle per generare i contratti WCF a partire da WSDL e XSD. Oppure ancora ci sono ottimi strumenti con WSCF di Thinktecture. La validazione XSD dei messaggi poi è assolutamente possibile sfruttando ad esempio un MessageInspector di WCF. Ovviamente non è un'opzione sempre attiva e non è disponibile "by default" come behavior, ma è disponibile nei sample e c'è la rete piena di esempi. Ciò che conta secondo me è che si possa fare e che sia relativamente semplice farlo. Poi non è sensato, e non lo è stato mai nemmeno prima (con ASMX) o in altri ambienti (Java ad es.) validare sempre e comunque i messaggi, a maggior ragione non è sensato nel caso di WCF che non prevede comunicazione solo tra piattaforme differenti ma spesso anche solo .NET su .NET, come erede di .NET Remoting/COM/COM+/DCOM, dove quindi potremmo non avere bisogno di un overhead di validazione XSD.