ottobre 2003 - Posts
Come ha detto lui Don Box è l'Ammiraglio di Indigo, ma lui (Steve Swartz) è il comandante e si occupa dell'architettura.
Ecco il suo nuovo blog:
http://www.stevesw.com/blog/
Ha promesso di tenerci aggiornati sugli sviluppi e le evoluzioni di Indigo.
Link:
http://www.stevesw.com/blog/
Ah finalmente un po' di codice interessante che mostra le potenzialità di Indigo!
Ottima sessione di Steve Swartz a proposito della estensibilità di Indigo.
Tra le informazioni importanti che sono emerse:
- Indigo che stiamo vedendo e provando noi è già diverso da quello al quale stanno lavorando in Microsoft, soprattutto sono cambiati i nomi di alcune classi e namespace, perché come ha detto SteveSw nel mondo del software si fa più in fretta a cambiare i nomi che non il codice :-) !
- Si sta già pensando (lavorando?!) a Indigo V. 2 perché un po' troppe volte nel parlare/rispondere a domande SteveSw ha specificato "in this version" oppure "in Indigo V1, but the next version ...."
- Indigo V1 sarà reso disponibile anche per il Compact Framework, anche se probabilmente non in concomitanza con l'uscita di Indigo per Windows/Longhorn, ma un attimo dopo, pare non troppo dopo
- Finalmente con Indigo ci sono dei meccanismi di estensione delle funzionalità che sono "pluggabili" e che permettono anche di agganciare facilmente (non come con i ReflectorImporter e ReflectorDescriptor di oggi!) le descrizioni ai contratti WSDL
- Avremo anche con Indigo un tool "simile" a WSDL, si chiamerà WSDLGEN.EXE (se non cambia nome nel frattempo :-) ...) che genererà sul client le interfacce corrispondenti ai servizi esposti sul server. Non è chiaro se produrrà anche le interfacce lato server partendo dal WSDL ... ma forse questo non è più un problema, per come funziona Indigo.
Due ulteriori novità o possibili novità:
- gruppi di validazione per i validation controls
- forse sarà possibile avere diversi pulsanti di default per diverse form o gruppi di controlli di validazione
Come dobbiamo muoverci, nello sviluppo di Web Service, da qui all'uscita di Indigo?
Ecco alcune risposte:
Interoperabilità tra Indigo e ...:
- ASMX e WSE saranno in grado di parlare con Indigo
- COM+ e MSMQ dovranno essere aggiornati alle versioni disponibili con Longhorn
- .NET Remoting dovrà essere aggiornato
Conversione da oggi a Indigo:
- WSE e MSMQ dovremo riscrivere parte del codice e la migrazione non sarà facile
- ASMX, Remoting, COM+ avremo dei path e dei WithePaper per una facile migrazione
- Esisterà un Namespace System.ServiceModel.Compat che andrà a sostituire sia System.Web.Services che System.EnterpriseServices e che consentirà una migrazione "quasi indolore" da oggi a Indigo
In quanto a .NET Remoting non conviene utilizzare Channels e Sink custom perchè in Indigo andranno riscritti.
Con COM+ non conviene usare API dirette, Queued Componens, LCE e CRM perché non esisteranno più. Altrettanto non conviene usare gli attributi per la configurazione automatica dei componenti nel catalogo COM+ in quanto non esisteranno più.
ATTENZIONE: "WSE is just for early adopters that can pay the price of complete or partial rewriting of their code"!
Lo so a me WSE piace ... ma WSE2 non sarà aggiornabile ad Indigo, sarà però in grado di parlare con Indigo, quindi possiamo sempre utilizzarlo oggi e renderlo interoperabile domani, senza migrarlo ad Indigo.
Interessante infine il fatto che stanno prevedendo un nuovo moniker da usare in COM/VBScript/JScript per consentirci di usare Indigo, dal punto di vista del client, con semplici script (VBS/JS).
Nel pomeriggio seguirò una sessione di approfondimento (livello 400) sulle porte e i channel di Indigo ... ci sentiamo dopo.
Ecco i miei appunti sulla sessione in oggetto:
Security
- quando usiamo la FormsAuthentication i cookies non sono più necessari, abbiamo la cookieless login
<authentication>
<forms cookieless="UseCookies|AutoDetect|UseUri|..." ... />
</authentication>
- è possibile far decidere al server, automaticamente, se usare o meno i cookies a seconda del client che si connette al nostro server (cookieless="AutoDetect")
- il ticket sarà inserito nella URI come per la cookieless session
- possiamo definire una sola form di login per client mobili e
desktop, non siamo più costretti ad averne due diverse, infatti tutti i controlli di ASP.NET 2.0 sono mobile-aware, quindi anche
le form di autenticazione
- non è ancora stato stabilito definitivamente come proteggere il
ticket, ovviamente verrà definito prima della RTM, ma c'è tempo :)
- SQL7/SQL2000/Yukon/MsJet sono supportati per il Data Storage dei dati
relativi a Membership e Role Manager
- Provider Model Design Pattern: regole per definire un provider, realizzate tramite alcune interfacce e classi base da implementare e derivare. Servono per implementare i prorpri Provider.
- LoginView, PasswordRecovery, Login, LoginName, LoginStatus,
ChangePassword, CreateUser sono nuovi controlli per la gestione delle comuni attività legate alla security
- Le password di default sono salvate nel DB non in chiaro ma hashed
- C'è una funzionalità "Who Is Online" per avere la lista degli utenti "loggati"
- C'è già un sistema predefinito per il reset delle password basato su Question/Answer
- Esiste un metodo "GeneratePassword" per creare in automatico password uniche
- Possiamo usare tutti gli automatismi o sostiture i livelli che preferiamo (Data Access Layer, Business Logic Layer)
- Possiamo condividere utenti e ruoli tra diverse applicazioni
- Ci sono metodi per gestire tutti gli utenti (GetAllUsers per esempio, che per ora danno accesso diretto a tutti gli utenti, in futuro saranno utilizzabili a pagine/chunk)
Membership
- Nel web.config avremo una sezione di configurazione apposita
<membership defaultProvider="YukonProvider" ...>
<providers>
<add name="AspNetSQlProvider" ... />
<!-- e tutte le altre azioni -->
</providers>
</membership>
- DA VERIFICARE: SQL Server Team sta lavorando ad una versione light di SQL Server simile ad access come facilità d'uso, ma con la stabilità di SQL. (Silvano cosa ne sai?)
Roles
- Il motore di gestione dei ruoli può lavorare bene unitamente alla parte di Membership, ma non sono necessariamente legate tra loro
- <rolesManager .../> consente di configurare i ruoli in modo rapido, senza dover scrivere tutto il codice di prima per creare il cookie con i ruoli, proteggerlo, rileggerlo, ecc.
- non necessita di un lookup sul db ad ogni richiesta
- può lavorare con cookie criptati
- il roleManager non è attivo di default, occorre attivarlo nel web.config
Ne parlavamo ieri sera a cena (eravamo io, Marco, Luca, RoB e Gab) ed ecco
che vedo
un post di Marco (che sta seguendo più di me la parte di Avalon, io
sto seguendo Indigo) che conferma la mia idea.
Con un bel XSLT già oggi non è difficile passare da XAML ad ASPX, se poi
Microsoft ci semplifica ancora di più la strada ...
Oggi ho iniziato a vedere e capire come funziona e come è organizzato
Indigo.
Devo dire che le sessioni di Don Box (non me ne voglia) ma come stile non
mi hanno entusiasmato come al solito. Ho la sensazione che Don Box sia un
po' stanco questa volta. Forse il super lavoro per preparare Indigo lo ha
stancato troppo.
In ogni caso ecco i punti fondamentali che ho recepito fin qui:
- COM+, .NET Remoting, ASMX sono stati fusi in Indigo
- Possiamo fare tutto con Indigo e usare Indigo come client di tutto
(intendo sempre COM+, .NET Remoting, ASMX)
- Indigo si basa su: messaggi, servizi, porte, canali
- Oggi conviene sviluppare ASMX o componenti COM+. Non conviene molto
investire su .NET Remoting, se non quando è indispensabile (tra AppDomain
diversi in un unico processo)
- Remoting sarà comunque supportato da Indigo anche se non dovrà essere
usato come default
- Il motore di Indigo è completamente slegato dalla struttura fisica delle
classi che vogliamo esporre. Infatti potremo pubblicare anche metodi privati
come se fossero dei WebMethod (anche se adesso si parla di ServiceMethod)
Preoccupante il fatto che Don Box non abbia eseguito nemmeno una demo,
ok che siamo alla versione alpha .... ma speravo di vedere qualcosa di
funzionante oltre a quanto mostrato nella keynote.
Pare comunque che domani Don Box faccia il bis ...
Lunedì sera ho trascorso una piacevole serata, davanti a qualche birra e
qualche stuzzichino, con alcuni dei personaggi di Microsoft che lavorano
ad Indigo.
Tutto era nato dalla richiesta di Doug Purdy di incontrare chi era
interessato e coinvolto nello sviluppo di Web Service ASP.NET, per fare
due chiacchere a proposito di Indigo e del nuovo motore di serializzazione
di Indigo.
La serata si è spostata quasi subito dal centro congressi all'hotel
dove dormono la gran parte degli speaker Microsoft a PDC.
Abbiamo parlato di serializzazione, ma anche di cose molto più frivole.
Ho avuto l'occasione di conoscere Doug, Steve Swartz, Jim Miller, Chris
Anderson, Eric Rudder e alcuni ragazzi molto in gamba che lavorano con i
Web Service da un bel po' di tempo e che erano come me "customer" ospiti
della serata.
I punti più importanti dal punto di vista tecnico, emersi durante la birrata
sono:
- Non hanno previsto e non prevedono per il futuro un motore di
serializzazione che mappi 1 a 1 tutte le possibili configurazioni che si
possono ottenere con XSD (restriction, enum, ecc.). Mi spiegavano che
hanno provato a farlo, sono arrivati a supportare quasi un buon 90% delle
funzionalità, ma si sono resi conto che il codice risultante ero troppo
sovraccarico di attributi. Allora hanno deciso che la soluzione migliore è
lavorare con file XSD e XSD.EXE quando le classi/le strutture dati sono
semplici. Quando la complessità sale, visto che stiamo comunque parlando
sempre di Web Service, conviene trattare direttamente gli XmlNode e usare
da codice XmlReader (eventualmente Validating) e XmlDocument, a seconda dei
casi.
- IXmlSerializable esisterà in Whidbey ed esisterà ancora a lungo (Doug ha
detto "per sempre"...) e anzi lo stanno supportando e migliorando. Stasera
alla sessione sulla serializzazione vedrò di scoprire ulteriori dettagli.
- Steve Swartz ci ha invitato ad utilizzare tool come XmlSpy o simili per
disegnare i contratti WSDL e poi ad implementare i Web Service partendo da
lì, per slegare completamente l'implementazione fisica, dal servizio.
Ovviamente chi mi conosce o sorbisce i miei articoli/blog sa che ho
ascoltato molto volentieri simili raccomandazioni.
I punti non tecnici (cioè quelli + interessanti):
- un PM ha le stesse responsabilità di un marketing manager ... ma guadagna
meno :-)
- Chris Anderson è rimasto stupito di non vedere decine di POST nel blog
di Don Box subito dopo la demo che hanno fatto alla keynote. Gli abbiamo
dato una giustificazione del perché non era accaduto: non andava la WiFi
nella sala :-D !
- sempre Chris Anderson ha spedito nel suo blog una fotografia di Doug
che cercava in tutti i modi di nascondere il fatto che stava bevendo una
birra ... ma non ci è riuscito :-), in compenso ci siamo visti una
"demo" :-) in diretta di blogx con tanto di invio di MMS diretto nel blog!
Fico :-)! Dovremo farlo anche nel blog di DevLeap!
Prima di tutto ecco gli obiettivi dichiarati da Scott Guthrie:
- ridurre le linee di codice di 2/3
- administration e management migliorati
- estensibilità della piattaforma
- performance e scalabilità
Ecco le novità introdotte da ASP.NET 2.0 (anzi 1.2 per ora), o almeno
quelle che ci hanno fatto vedere per ora...
L'architettura è su 3 blocchi di componenti/controlli/funzionalità:
1) "ASP.NET Building Block API"
- Membership
- Role Manager
- Personalization
- Site Navigation
- Database Caching
- Management
"Page Framework"
- MasterPages
- Themes/Skins
- Adaptive UI
"Control Buckets" (oltre 40 controlli)
- Security
- Data
- Navigation
- Web Parts
Inoltre:
- Non sono più necessarie le Front Page Extensions. Ora possiamo utilizzare:
- File System, FTP, IIS
- Directory based development
- Non serve più un'intera DLL
- Possiamo ricompilare le singole pagine
- HTML source preservation: il designer non distrugge più il nostro codice HTML
- HTML formatting engine (rules personalizzate per la formattazione del codice sorgente HTML)
- Intellisense everywhere (web.config, XML, HTML, inline code, ecc.)
- HTML tag navigator (per spostarsi meglio nel codice HTML e per comprimere/espandere il codice HTML come nelle region)
- Supporto ad XHTML 1.0
- WCAG Accessibility Compliance Checker (questo è molto importante per chi
deve lavorare con la pubblica amministrazione!)
- Supporto nativo ed integrato con VS.NET alle master pages
- Migliorato il supporto all'editing del code-behind
- Single file page editing
- Non serve più di avere IIS. Esiste un Web Server ad uso locale
(solo localhost) che è in sostanza l'evoluzione di Cassini
- Motore di "Publish Web" (synchronization/publication engine)
- Supporta servizi non HTTP (Indigo per esempio)
Ci sono parecchi controlli già pronti per svolgere molte attività che prima
erano noiose e rubavano tempo prezioso (griglie, login, welcome message, panels, site personalization, ecc.).
Si tratta di capire quanti di questi controlli fanno le cose "nel modo
giusto" prima di farsi prendere da entusiasmi magari non giustificati.
Voglio vedere bene il codice e capire "se vale la pena di usarli" oppure no.
In ogni caso è positivo poter costruire in pochi minuti/ore un sito "serio"
come impostazione dei contenuti.
Se poi tutti i controlli precotti saranno anche prestazionali, potremo
usarli in tutte le situazioni, altrimenti solo per costruire al volo delle
bozze o dei siti semplici, a basso traffico.
Stay tuned ... vado a seguire la presentazione di Indigo.
La KeyNote è stata quasi al 100% su Longhorn.
Sembra davvero un sistema interessante (non vedo l'ora di rientrare a casa
e installarlo).
Il sistema è basato su una parte di servizi fondamentali, che comprendono
anche il CLR, e tre blocchi che sovrastano i servizi "fundamental".
I tre blocchi sono:
- Avalon: per lo strato di presentazione all'utente
- WinFS: per la gestione del file system
- Indigo: per la parte di messaggistica e collaboration
Tutto è programmabile con un SDK (che abbiamo avuto insieme al sistema).
La grafica è molto spinta e l'obiettivo è quello di far sentire a proprio
agio anche gli utenti meno "PC-oriented" proponendo un paradigma d'uso
del PC molto simile a quello di un qualsiasi altro strumento della vita
comune.
Hanno semplificato enormente la parte di deployment delle applicazioni,
consentendo a noi sviluppatori di rilasciare, ed installare quindi,
applicazioni senza richiedere alcun intervento da parte dell'utente, nel
rispetto delle policy di security ovviamente.
Per gestire questa grafica spinta ovviamente serviranno risorse hardware
adeguate ...
La parte per me più interessante della keynote è stata quella relativa ad
Avalon.
Ecco la prima applicazione Avalon che ho visto (l'ha scritta
Don Box :-)...):
[vanilla.cs]
using System;
using System.MessageBus;
using System.Storage;
using System.Storage.Core;
using MSAvalon.Windows;
using MSAvalon.Windows.Controls;
namespace PDC
{
public partial class MyWindow: Window
{
public class Item
{
public String Title;
public String Description;
public String Content;
}
void BlogIt(object o, ClickEventArgs a)
{
Item i = new Item();
i.Title = theTitle.Text;
i.Description = theDescription.Text;
i.Content = theContent.Text;
Port p = new Port();
p.Open();
try
{
ISendChannel c = p.CreateSendChannel(new Uri("http://www.gotdotnet.com/team/dbox/post.aspx"));
Message m = new Message(new Uri("uuid:00020812-0000-0000-c000-000000000046"), i);
m.Encoding = new AsmxEncoding(System.Text.Encoding.UTF8); // sparirà
c.Send(m);
}
finally
{
p.Close();
}
}
void Pushed(object o, ClickEventArgs a)
{
MessageBox.Show(bob.Text);
ContactPickerDialog dlg = new ContactPickerDialog();
dlg.PropertyRequest.PropertyType = ContactProperty.Contact;
if (dlg.ShowDialog(this) == DialogResult.OK)
{
bob.Text = dlg.SelectedContacts[0].Contact.DisplayName.Value;
}
}
void Search(object o, ClickEventArgs a)
{
ResultList.Items.Clear();
ItemContext c = ItemContext.Open();
foreach (Document d in c.FindAll(typeof(Document),
"Authors.DisplayName= 'Chris Anderson'"))
{
ResultList.Items.Add(d.Title);
}
}
[STAThread]
static void Main()
{
Application app = new Application()
MyWindows win = new MyWindow();
app.Run();
}
}
}
[vanilla.xaml]
<windows xmlns="http://schemas.microsoft.com/2003/xaml"
xmlns:def="Definition"
def:class="PDC.MyWindow"
Text="Hello World!"
Visible="true" />
<Canvas DockPanel.Dock="Fill">
<video Opacity="0.371" Source=c:\Filmato.vmw" Stretch="Fill"
RepeatCount="9999" Width="100%" Height="100%" />
<TransformDecorator DockPanel.Dock="Fill"
Transform="rotate 10 scale 2.3 2.3">
<TextPanel>
Title: <TextBox ID="theTitle" Width="100%" Height="20pt" />
Description: <TextBox ID="theDescription" Width="100%" Height="20pt" />
Content: <TextBox ID="theContent" Width="100%" Height="20pt" />
<Button Click="BlogIt">Invoke Blogging</Button>
<LineBreak />
<TextBox Background="#44FF0000" ID="bob"
width="2in" Height="20pt" />
<Button Background="#440000FF"
click="Pushed">Push me</Button>
<LineBreak />
<Button Click="Search">Search</Button>
<ListBox ID="ResultList" Background="#77FFFFFF">
<ListItem>Item 1</ListItem>
</ListBox>
</TextPanel>
</TransformDecorator>
</Canvas>
</windows>
Cosa è la parte XAML?
E' una grammatica XML (con mio grande piacere) che potremo utilizzare per
definire i layout e i controlli che definiscono le interfacce utente delle
nostre applicazioni.
L'aspetto interessante è che potremo modificare la parte XAML senza dover
intervenire sul codice che implementa le funzionalità delle nostre
applicazioni.
Inoltre potremo gestire diverse configurazioni di layout a seconda degli
utenti che utilizzeranno le nostre applicazioni, senza dover modificare la
parte di implementazione, ma lavorando solo a livello di layout.
Interessante il fatto che avremo la possibilità di utilizzare dei designer
grafici (Adobe ha mostrato una demo a tal proposito) con i quali potremo
consentire ai grafici di "disegnare" le interfacce delle applicazioni
Avalon. Dal design invece di avere il classico JPEG, PNG o simili, da
realizzare via codice, potremo generare direttamente codice XAML al quale
poi associare l'implementazione.
In pratica abbiamo una forte separazione tra codice e presentazione anche
nelle applicazioni Windows e non più soltanto nelle applicazioni Web ASP.NET.
Di Indigo si è visto relativamente poco nella KeyNote.
Mi riservo di parlarne meglio tra un'oretta dopo che avrò visto la prima
vera sessione!
Penso che dovrò cambiare la mia agenda di PDC. Scott Woodgate ha segnalato nel suo blog (l'ho visto solo ora) che mostrerà una demo "funzionante" di integrazione tra BizTalk Server 2004, Indigo e Yukon....
Link:
http://blogs.gotdotnet.com/scottwoo/
More Posts
Next page »