luglio 2005 - Posts
Con grande piacere annuncio che abbiamo pubblicato ieri sera il sito della DevLeap Conference 2005. La conferenza si terrà a Milano il 23 e 24 novembre di quest'anno.
Per approfondirne i contenuti vi rimando al sito:
http://devcon2005.devleap.com/
Per noi è un evento importante. Date un'occhiata al sito, fateci sapere cosa ne pensate (dell'evento prima di tutto, ma anche del sito :-) ... ) e non dimenticatevi di prenotare il vostro posto!
Bridge The Gap!
Giusto giovedì durante il OneDay su SOA Security ho detto che il team di WSE aveva "promesso" una build al mese fino all'uscita della final release, ma che in luglio non era ancora uscito nulla.
Invece proprio durante i OneDay è uscita una nuova CTP:
http://www.microsoft.com/downloads/details.aspx?familyid=77ae2e71-c5eb-4c4d-b24d-c6c289b49a95&displaylang=en
Per completezza riporto le novità principali che introduce WSE3:
- Espone ASMX su diversi protocolli di trasporto
- Tramite un SoapService che wrappa gli ASMX
- Supporta i 64 bit (visto che gira su .NET 2.0)
- Integrazione con l’IDE di Visual Studio 2005
- Migliorie varie alle prestazioni
- C'erano secondo me alcuni punti da vedere/riconsiderare in particolare nel codice di gestione dei listener di SoapService
- WS-SecurityPolicy aggiornate e migliorate
- Compatibilità “wire-level” con Indigo
- La versione finale di WSE3 sarà compatibile con la versione finale di Indigo, a livello di messaggi "sul cavo"
- MTOM (Message Transmission Optimization Mechanism ) al posto di WS-Attachments
- Con WS-Attachments viene utilizzato DIME per trasferire all'interno di un DIME Message N DIME Record. Il primo DIME Record è il messaggio SOAP originale, i successivi DIME Record sono i file allegati o i loro chunk, che uniti costituiscono l'intero file. Ciò che passa sul cavo non è più un messaggio SOAP ma un messaggio DIME che dai due lati viene impacchettato e spacchettato.
- Con MTOM invece gli allegati sono inseriti all'interno del messaggio e ciò che passa sul cavo è pur sempre un messaggio SOAP
- Perchè tutto questo?! Perchè con WS-Attachment non era possibile applicare WS-Security agli allegati, visto che WS-Security lavora con il messaggio SOAP. Con MTOM invece possiamo firmare, criptare e autenticare i messaggi, compresi i loro eventuali allegati
- WS-* updates
- Tools e Wizard
- Security Settings Tool: rinnovato
- Configuration file migration (da WSE 2.0 a WSE 3.0): comodo
- WseWsdl3.exe: rinnovato
Occhio che la CTP di luglio ha qualche problema di integrazione con VS.NET 2005: http://blogs.msdn.com/mpowell/archive/2005/07/21/441625.aspx .
http://www.microsoft.com/italy/msdn/eventi/webcast/passati/default.mspx
nella classifica dei top 10 WebCast dell'ultimo anno fiscale. :-) Vivissimi complimenti a Corrado per la prestazione!
Per quanto mi riguarda, pensavo di vedere un WebCast su SOA piuttosto che sullo sviluppo di Smart Client.
Comunque la classifica, al di là delle sciocchezze sul mio posizionamento, è decisamente interessante, perchè a mio avviso racchiude in sé una sorta di messaggio/percorso evolutivo/di crescita:
- Per affrontare bene lo sviluppo con .NET occorre capire bene cosa è l'OOP
- Poi occorre imparare il linguaggio di programmazione .... quale se non C#?
- Seguono le applicazioni "pre-confezionate" (DNN) per fare i primi esperimenti e - perché no - i primi lavori
- Quindi ci si preoccupa di muoversi bene nell'accesso ai dati (problema che da sempre assilla i programmatori coscienziosi)
- Poi si migliora la qualità complessiva del codice
- Ed ecco che si vogliono sviluppare applicazioni Smart Client
- Già ma se vogliamo creare Smart Client servono interfacce utente Windows Forms ricche ed evolute
- Nel frattempo però facciamo il porting da ASP ad ASP.NET di quello che abbiamo, perchè .NET è davvero forte e ormai non possiamo più farne a meno ...
Forse sarà il frutto dell'ottima Saint Sixtus che mi sono bevuto stasera, ma io lo leggo così.
Oggi abbiamo aperto un pacco ricevuto nei giorni scorsi da un nostro cliente.
Si tratta di un PC sul quale dobbiamo installare un'applicazione che abbiamo realizzato. Il PC verrà poi messo presso uno dei punti vendita del cliente, quindi sarà accessibile al pubblico che potrà farci di tutto un po' :-) ....
Bene ... tutto mi sarei aspettato tranne un dispositivo di sicurezza fisica :-) come questo:
Altro che Code Access Security e SOA Security!!!!! :-D
Un anno fa durante le sessioni su SOA e Indigo, alla DevLeap Conference 2004 di Bologna e Napoli, avevo detto che non era in programma il porting di Indigo su Compact Framework. A distanza di un anno sembra che la situazione non sia purtroppo cambiata, come si legge da questo post:
http://weblogs.asp.net/pgielens/archive/2005/07/16/419624.aspx
che riporta un estratto di un messaggio inviato in un newsgruop su Indigo, da Richard Turner, uno dei PM Microsoft dell'area Web Services. Non ci sono "plan" a riguardo, cioè ad oggi non è ancora deciso se, come e quando ci sarà un Indigo per CF.
Mi sembra francamente poco ragionevole, anche perchè "Indigo Mobile" aprirebbe le porte a scenari decisamente interessanti. Penso non solo alla produttività individuale o alla collaborazione aziendale, ma anche e sopratutto all'automazione industriale e ai sistemi embedded. D'altra parte i device mobili non hanno le stesse risorse di un PC, quindi non possiamo pretendere di farci sempre esattamente le stesse cose che faremmo con un PC ... ma mandare un messaggio XML via socket non è una "missione impossibile" ...
Questo post segnala un tool, alla sua seconda versione, per eseguire controlli di unit testing sulle orchestrazioni BizTalk.
Tra l'altro l'autore del tool segnala anche la disponibilità di "Orchestration Profiler" un tool nuovo di zecca (dei primi di luglio) per creare report CHM sulle orchestrazioni e sul coverage dei test eseguiti sulla soluzione.
Direi che conviene dare uno sguardo ad entrambi i prodotti.
La generazione dinamica e automatica del codice è da sempre un tema di interesse, sia per chi la supporta che per chi la critica e non la userebbe nemmeno sotto tortura.
Io a volte la uso e aggiungo anche che in diversi casi, persone contrarie ad usarla, si sono ricredute dopo aver capito quale sia il mio (e non solo mio) approccio alla faccenda.
Mi riferisco alla possibilità di costruire in modo automatizzato il codice delle nostre applicazioni. Spesso risulta utile quando:
- si devono creare dei modelli ad oggetti abbastanza articolati, dove la gran parte delle classi hanno caratteristiche comuni (possibilmente derivate da classi base comuni) e si devono solo specializzare, caso per caso, dei comportamenti. Ad esempio ridefinendo dei metodi virtual. Si può allora decidere di creare per bene a manina la classe base. Poi generare in qualche modo (CodeDOM se si vuole essere eleganti, StringBuilder se si vuole essere meno eleganti :-) e forse anche un po' goffi ;-) ...) il codice delle classi da essa derivate, con già i metodi in override e una bella throw new Exception("Method not implemented!); al loro interno, giusto per non dimenticarsi di implementarli davvero. Si tratta solo di un caso di 1000 e più ai quali pensare
- si voglino avere dei modelli aziendali di scrittura del codice. Se devo creare una collection non la scrivo, ma la genero con un tool aziendale (ad es.) e poi ne personalizzo il comportamento.
- ecc.
Farlo solo per avere N classi uguali delle quali poi non tocchiamo nulla né ora né mai, non ha senso. Ma farlo per avere un pezzo di lavoro già svolto in automatico, senza errori banali (!!!), ordinato, pulito e nel rispetto di regole di scrittura aziendali, invece ha secondo me molto senso.
Oggi stavo facendo un po' di ricerca sull'argomento, per un progetto al quale sto lavorando (del quale forse scriverò qualcosa anche qui nei prossimi giorni) e mi sono imbattuto in un sito web del quale non voglio perdere l'indirizzo. Siccome potrebbe servire anche a voi lo metto qui: http://www.codegeneration.net/ . Si tratta in sostanza di una sorta di directory dei siti e contenuti sul tema della generazione del codice, non solo per .NET ma più in generale con diversi linguaggi e ambienti.
Come si legge in questi articoli:
http://www.mcpmag.com/news/article.asp?EditorialsID=819
http://www.mcpmag.com/news/article.asp?EditorialsID=821
I percorsi di certificazione Microsoft sono prossimi a dei cambiamenti abbastanza significativi... almeno nei prossimi mesi avremo qualche esame nuovo da sostenere, giusto per non perdere il vizio :).
Nelle ultime 48 ore ho scambiato un paio di email con Alessandro Perilli, a proposito di AJAX.
Negli ultimi mesi stiamo assistendo alla nascita e all'evoluzione di applicazioni web anche molto complesse (GMail ne è un esempio eccellente, ma anche Outlook Web Access e altre). Questa complessità porta a sempre nuove esigenze, che nell'ultimo periodo hanno trovato risposta nella nuova frontiera della tecnologia web: AJAX (Asynchronous Javascript and XML). Essendo io un uomo che in gran parte vive :-) di XML, Web Services e architetture distribuite .... dovrei essere contento di questo fatto.
Sapere poi che anche Microsoft, per bocca del papà di ASP.NET, annuncia l'imminente uscita (settembre 2005 a PDC) di un add-on per ASP.NET 2.0 per supportare AJAX in ASP.NET 2.0 e il fatto che in ASP.NET V.Next avremo supporto nativo per AJAX, con nome in codice ATLAS, dovrebbe riempirci tutti di gioia ed entusiasmo.
Io sollevo però qualche dubbio e manifesto qualche perplessità. Mi spiego meglio: siamo sicuri che sia giusto voler farcire di mille e una funzionalità il povero HTML, poi D-HTML, poi XHTML, ecc.. che era nato con lo scopo di mostrare hypertesti e ora invece si trova sempre più spesso a dover sostituire applicazioni Windows in modo più o meno efficace e più o meno sofferto per lo sviluppatore?
Non sarebbe forse meglio dire:
- HTTP è un linguaggio per trasferire hypertesti dal server al client, su esplicita richiesta del client verso il server
- HTML ha un suo ruolo: impaginare hypertesti in modo sganciato dalla piattaforma.
- DHTML consente, sotto certe condizioni, di aggiungere qualche funzionalità interattiva/grafica al codice HTML, per renderlo più bellino graficamente e da un punto di vista della usabilità.
- Stiamo sempre più riempiendo HTTP, HTML e DHTML di "porcheria" :-) (ViewState, Session, async callbacks, Java, JavaScript, ActiveX, Windows Forms Controls, XML, XSLT, DSO, AJAX, Flash, ecc.) per poter correre una gara di Formula1 con un triciclo :-)
- Ora abbiamo bisogno di un nuovo metalinguaggio, probabilmente basato da subito e al 100% su XML, pensato per descrivere interfacce utente ricche e finalizzato a costruire le UI degliu Smart Client in archiettura SOA.
- Deve essere indipendente dalla piattaforma che ne fa il rendering
- Deve essere concordato dalle grandi aziende che danno la direzione al mercato (IBM, Microsoft, Sun, Oracle, Google, ecc.) e standardizzato dal W3C e/o da OASIS esattamente come accade per le specifiche del mondo WS-*
Non ha secondo me troppo senso assistere al proliferare di N diverse piattaforme per raggiungere risultati tra loro simili dal punto di vista della "User Experience" ma diversi come compatibilità e supporto delle piattaforme. Meglio prendersi alcuni mesi di tempo e poi partire tutti su una nuova strada, certa e unica che non trovarsi circondati di N piattaforme linguaggi che si intersecano e si completano a vicenda.
Certo una scelta come questa è molto difficile da prendere, per le grandi aziende, perchè significherebbe ricreare da zero il client container di questo nuovo metalinguaggio, di fatto mettendo a rischio le quote di mercato acquisite in tutti questi anni con prodotti come Internet Explorer, Firefox, ecc.
Cosa ne pensate? I commenti sono aperti.
PS: Si vede che ormai ho 30 anni ... una volta parlavo di tecnologia :-) adesso di andamento del mercato ... spero di non diventare rapidamente vecchio come Marco :-).
Vedo che nelle ultime 48 ore sono arrivate diverse iscrizioni ai OneDay che terremo io e RoB a proposito della sicurezza di ASP.NET e di SOA.
Qualora altri abbiano intenzione di iscriversi, chiedo loro la cortesia di farlo entro questa settimana, se possibile, in modo che possiamo organizzarci per i pasti e la preparazione del materiale.
Grazie.
Con grande piacere diamo il benvenuto a Caterina Coriani :-) !
Vivissimi complimenti a Silvano e Serena!!! Adesso noi zii :-) di DevLeap abbiamo ben due nipotini (Riccardo Russo e Caterina Coriani) ... chissà chi sarà il prossimo! ;-)
Con grande piacere annuncio che la connettività Internet della mia sala server è stata ripristinata.
Ho rinunciato a capire la vera natura del guasto e la ragione dei tempi così lunghi ... perché voglio dormire sereno :-) nelle prossime notti.
Ora il sito DevLeap è nuovamente raggiungibile nella sua nuova forma e linea!
Enjoy the new DevLeap experience! :-)
Sarà mica colpa del nuovo motore del sito?! Forse qualcuno di voi l'avrà pensato :-) ... magari, dico io, nel senso che potremmo intervenire e risolvere il problema.
Invece la verità è che da questo sabato (2 luglio), a causa di un guasto fisico sulla rete ATM della mia zona, la connessione S-DSL della mia sala server (dove è ospitato anche DevLeap) è interrotta e stiamo usando un backup ISDN multicanale, che però ovviamente non è paragonabile ad una S-DSL Flat :-( ! L'ipotesi più accreditata è che, essendoci N cantieri aperti in città in questi giorni, molti dei quali qui intorno alla zona del mio ufficio, qualcuno abbia tranciato i cavi con una ruspa o qualcosa di simile ....
Il gestore della connettività, che per questa tratta è Telecom (per quanto ne so), sta indagando il guasto ma non ha ancora trovato il punto preciso dove riparare il cavo.
I.NET, che è il mio provider di connettività e di banda, mi sta tenendo informato degli sviluppi, ma è legato all'evolversi della situazione da parte di telecom, visto che la tratta ATM locale è gestita da Telecom (per quel che ho capito) .... ma sono 72 ore che siamo sul backup.
Che rabbia!!!!!! :-(
Esistono sempre più tecnologie per "integrare" le applicazioni e le piattaforme. In questo whitepaper segnalato da
Scott Woodgate (PM di BizTalk Server) si evidenziano le principali tecnologie Microsoft per l'integrazione e si forniscono alcune linee guida per scegliere quali usare. Proprio una decina di giorni fa parlavo con
Marco, a proposito delle differenze tra BizTalk Server e SQL SSIS.