DeepZoom viene creato mediante il tool gratuito DeepZoom Composer 

La prima cosa che dobbiamo fare in un progetto silverlight che deve utilizzare la customizzazione di un oggetto DZ è quella di inserire il tag

<MultiScaleImage x:Name=”myDzObj” Source"=”dzOutput.xml” />

Tale output è ottenuto mediante il composer di DeepZoom a questo punto possiamo facilmente aggiungere un po ‘ di interativià agendo sugli eventi, quindi per esempio aggiungiamo MouseEnter e MouseLeave

<MultiScaleImage x:Name=”myDzObj” Source"=”dzOutput.xml” MouseEnter="DeepZoomObject_MouseEnter" MouseLeave="DeepZoomObject_MouseLeave"/>

Nel code behind possimo facilmente andare a gestire i due eventi

myDzObj.ZoomAboutLogicalPoint(3, .5, .5);

myDzObj.ZoomAboutLogicalPoint(.3, .5, .5);

in tal modo eseguendo il run possiamo vedere che l’immagine ingrandisce e rimpicciolisce con l’hover del mouse.

Attualmente mi sarebbe piaciuto incorporare le funzionalità DZ in un applicazione WPF ma non sono suportate e quindi è necessario incorpoare Silverlight nella mia applicazione WPF, speriamo che in futuro sia disponibile direttamente questa feature.

Innanzitutto farei un cappello introduttivo per sottolineare che le operazioni su database sono solo un caso specifico di transazionalità, e, sebbene di laraga diffusione, possiamo definire un’attività transazionale qualsiasi attività che esegue un operazione di persistenza, persistenza che sia secondo il paradigma ACID ovvero:

Atomica

Consistente

Isolata

Durevole

• Atomica significa che tutte le operazioni appartenente al contesto transazionale devono essere considerate come un unica operazione.
• Consistente significa che prima e dopo l’operazione transazionale non siano violate le regole di integrità
• Isolata significa che le attività coninvolte al contestono non abbiano impatti reali fino alla loro conclusione
• Durevole sitgnifica che i dati siano memorizzati in forma durevole (quindi salvati da qualche parte)

L’oggetto che il framework ci fornisce per supportare questo principo è il conosciutissimo TransactionScope che nel caso più semplice è scritto così:

using (TransactionScope ts = new TransactionScope()) {
….
ts.Complete();
}

Inutile dire che la using è una convenzione per la disposizione dell’oggetto TransactionScope al termine della sua reale necessità. Segnalo inoltre che anche se la forma più comune di utilizzo delle TransactionScope sia quella sopra cita è bene tenere a mente che abbiamo a disposizione una gestione più capillare mediante la semplice costruzione dell’oggetto TransactionScope

• TransactionScopeOption.Required (default) – la transazione viene creata solo se occorre
• TransactionScopeOption.RequiredNew – la transazione viene creata comunque
• TransactionScopeOption.Suppress – elimina il blocco corrente al blocco transazionale precedente

I parametri sopra elencati sono necessari qualora abbiamo una complessità tale da dover gestire operazioni transazionali nidificate, e, in tal caso desideriamo gestire il singolo blocco in modo programmatico, ovvero nel caso di RequiredNew obblighiamo l’autonomia del blocco transazionale indipendemente dal precedente e, nel caso di Suppress, obblighiamo che indipendentemente dalla nidificazione il blocco transazionale sia eseguito “al di fuori”.

Preciso che ad oggi qualsiasi attività transazionale viene gestita tramite l’oggetto Distributed Transaction Coordinator introdotto da Windows NT e talvolta in produzione dobbiamo preoccuparci che il serivizio sia correttamente avviato (Da SqlServer 2005 sono state introdotte le lightweight transaction che consentono un considerevole incremento di performance rispetto a MSDTC).

In questo articolo analizziamo comunque tutte le attività transazionali che non hanno necessariamente a che fare con la DbCommand e quindi con ADO.NET ma che abbiano invece una responsabilità differente, ipotizziamo ad esempio il salvataggio su un file che prima scrivere fisicamente il file vogliamo che le informazioni siano in un file tempomporaneo e vogliamo consentire la particpazione del nostro oggetto transazionale a un contesto più ampio, e nel caso specifico faccio riferimento al pattern architetturale Unit Of Work che ci consente di tenere traccia dei cambiamenti fino a un livello da noi definito.

Bene, veniamo alla seconda parte dell’articolo per vedere come far partecipare un nostro oggetto custom al contesto di un TransactionScope. La parte del leone la fa il transaction Manager che internamente è l’oggetto che fisicamente si preoccupa di invocare la Commit (nel caso sia andato tutto bene – metodo Complete, oppure la rollback – disposizione del transaction scope).

Il transaction manager, invoca un oggetto che implementi l’interfaccia IEnlistmentNotification la quale consente di tenere traccia di uno stato ed eseguire la commit solo all’occorrenza, quindi, qualsiasi oggetto che implementa la IEnlistmentNotification è in grado di partecipare ad un particolare contesto transazionale, e, nel caso di Ado.Net Microsoft lo ha implementato al posto nostro, tale funzionalita aimè non è presente nelle operazioni che abbiano però un ambito applicativo differente dai database e quindi per tutte le operazioni che richiedano una gestione particolare.

Ipotizziamo un proxy wcf che vogliamo che effettivamente invochi l’operazione a effettivo termine di tutte le attività dipendenti e che non siano da lui consciute ma dal programma; in questo caso sfrutteremo le partial class per estendere il nostro proxy e implementare dunque la IEnlistmentNotification.

Tutto sommato la realizzazione di un oggetto transazionabile è oltremodo semplce e qui c’è la definizione dei metodi da implementare:

public interface IEnlistmentNotification
{
void Commit( Enlistment enlistment );
void InDoubt( Enlistment enlistment );
void Prepare( PreparingEnlistment preparingEnlistment );
void Rollback( Enlistment enlistment );
}

Il metodo commit e rollback sono i metodi che verranno richiamati al termine dell’operazione per la persistenza o il rollback mentre una nota speciale vanno per i due metodi Prepare e InDubt che sono coinvolti a quel tipo di transazioni che avvengono in due fasi, mentre InDubt viene eseguito quando tutto sembra essere ok ma qualche Prepare della catena di oggetti ha perso la sua consistenza e quindi sarà nostra premura organizzarci di conseguenza.

Bene, è tutto e rimando alla documentazione ufficiale di MSDN o al più all’uso di reflector per gli esempi anche perchè wordpress in cui ospito il blog non è il massimo per eseguire il post di codice, ma mi organizzerò prima o poi.

La risposta si chiama WAS o meglio Windows Actiovation Services, cioè un estensione di IIS non installata di default che consnte il trasporto sotto tutti i protocolli disponibili con wcf e con qualche accorgimento anche ai canali “custom”.

Per chi volesse provare questa feature, consiglio l’installazione di windows 7 per un ambiente di sviluppo oppure windows server 2008 R2 per un ambiente di test e produzione. Diciamo comunque che giocheremo con un paio di comandi  che i nostri colleghi sistemisti conoscono o dovrebbero conoscere bene.

Per prima cosa l’installazione dei servizi WAS avviene tramite il pannello di controllo e l’aggiunta di funzionalità Windows, nella mia versione in inglese si chiama Windows Communication Foundation Non Http Activation, e la loro installazione è banale alla pari di un’installazione di IIS 7.

Ora dobbiamo aprire la command line ( chi non ha disabilitalo la UAC deve avere concedere i privilegi amministrativi, con il comando run as administratori).

A questo punto è possibile assegnare i vari binding utilizzabili da IIS

%windir%\System32\inetsrv\appcmd.exe set site “Default Web Site” — +bindings.[protocol=’net.pipe’, bindinginformation=*’]

ora ogni applicazione di IIS che lo ospitera i nostri servi non http dovrà avere il suo mapping WAS cioè

%windir%\system32\inetsrv\appcmd set app “Default Web Site/MyApplication” /enabledProtocols:http,net.pipe

e con questo abbiamo finito! Naturalmente è possibile eseguire questa procedura con qualsiasi protocollo di WCF.

La versione di Windows 7 Ultimate è quella più completa, si possono aggiornare le interfacce in 35 lingue (evidentemente anche a Redmond hanno saputo che in Italia abbiamo un sacco di arabi e cinesi) ma attenzione, molto spesso ho visto nei negozi la versione N di Windows 7 Ultimate, e udite utite, ecco la gabola, un utente si aspetta di avere le funzionalità multimediali e tutte le feature strabilianti incluse nella nuova versione dell’ultimo sistema uscito da Microsoft, ebbene nonostante il costo (che non è proprio a buon mercato) la versione N di Windows non possiede le funzionalità multimediali. Ecco dunque le scuse di Microsoft a questo indirizzo tutte le feature mancanti.

Ora mi permetto anche un commento personale, possibile che a nessuno di Microsoft sia venuto in mente che a un cliente che ha appena installato la versione N gli venga un coccolone al termine dell’installazione?

Purtroppo in rete non esistono molte informazioni a riguardo quindi fate bene attenzione se non avete la banda larga (mi immagino il paesino di montagna) e non avete voglia di scaricare 250 mega di features.

Torniamo dunque alla spiegazione dell’impostazione SSL su IIS 7. La versione di Windows che uso io è in inglese per tradizione .

1. Creare un nuovo sito 
   
2. Creare un certificato di test oppure importare un certificato regolarmente autorizzato.
   
   Fare doppio click sull’icona di creazione di un nuovo certificato
    
   Premere il link di creazione di un certificato con firma autogenerata
   
   inserire un nome che distingua il nostro certificato e premere ok
   
   Nell’elenco dei certificati compare il nostro nuovo certificato
3. Abilitare il binding Https
   
   
   Selezionare il pulsante Add
   
   Aggiungere dunque il protocollo https e selezionare il certificato che abbiamo creato

Questa è tutta la procedura necessaria per aver avviato ill supporto http al nostro sito, naturalmente in fase di navigazione avendo creato un certificato di test è necessario autorizzare la navigazione con un certificato di fonte anonima.

Et voilà ora è possibile interagire sulla porta 443 in SSL.

naturalmente è possibile anche utilizzare la vecchia utility makecert.exe eseguibuike dal prompt dei comandi di Visual Studio.

Inutile dire che ogni applicazione ASP.NET che si rispetti, sia anche con MVC necessiti del proprio application pool, in modo da non interferire nei processi di altri siti esistenti.

Sono stato impressionato da Outlook 2010 che ha un interfaccia devvero divertentente mi propongo dunque di pubblicare un video con una anteprima

Ormai ci siamo i paradigmi stanno cambiando velocemente e con EL 5 le novità non mancano e probabilmente sarà anche da valutare l’ipotesi di adottare nuovi approcci architetturali il futuro è alle porte e su codeplex già esiste un progetto fantastico il Common Service Locator

http://www.codeplex.com/CommonServiceLocator

Le differenze nel paradigma stanno in questi spezzoni di codice

Oggi:

DatabaseFactory.CreateDatabase(“mia istanza”)

oppure

Container.Resolve<Database>(“mia istanza”)

Il futuro

   1: new TypeRegistration<Database>(

   2:     () => new SqlDatabase(

   3:                 ConnectionString,

   4:                 Container.Resolved<IDataInstrumentationProvider>(Name)))

   5:     {

   6:         Name = Name,

   7:         Lifetime = TypeRegistrationLifetime.Transient

   8:     };

oppure

   1: var configurator = new UnityContainerConfigurator(Container);

   2:

   3: EnterpriseLibraryContainer.ConfigureContainer(

   4:     configurator,

   5:     configurationSource);

Ciò che occorre è creare delle istanze di alcuni oggetti e assegnare un nome di tipo stringa alla nostra connessione e utilizzare il namespace System.Windows.Messaging , gli oggetti sono 2

LocalMessageReceiver per la parte server

LocalMessageSender per la parte client

Nell’esempio allegato si potrà vedere come ciò che scriviamo in un textbox è perfettamente visibile in un textblock in una istanza completamente diversa del plugin, vale anche nella modalità out of browser

Le porzioni di codice sono tutte nel costruttore

Parte clent

private readonly LocalMessageSender _sender;

public MainPage()

{

InitializeComponent();

_sender = new LocalMessageSender(“myreceiver”);

myTextBox.KeyUp += ((sender, args) =>

{

_sender.SendAsync(args.Key.ToString());

}

);

}

Parte server

_receiver = new LocalMessageReceiver(“myreceiver”);

_receiver.MessageReceived += ((sender, args) =>

{

myText.Text += args.Message;

}

);

try

{

_receiver.Listen();

}

catch (ListenFailedException exception)

{

MessageBox.Show(string.Format(“Il local connection receiver non può essere instanziato\n{0}”,

exception.Message));

}

Gli effetti che si possono effettuare sono notevoli con un codice banale. L’unica menzione è che la spedizione dei messaggi deve essere fatta in modalità asincrona altrimenti impatterebbe sull’istanza del browser.

Vediamo ora le novità per i DataBinding

Per prima cosa finalmente in Microsoft hanno implementato il supporto per il binding su elementi visuali

{Binding ElementName=mioElemento, Path=MiaProprietà} che già usiamo estensivamente in WPF e a cui siamo abbituati in ambito smart client.

Anche nel caso di Silverlight 3 è stato implementata la possibilità di collegare le fonti dati al CollectionViewSource che equivale al BindingNavigatore nelle applicazioni SmartClient in Windows Form, sacrificando la possibilità di effetuare il grouping. Anche in questo caso il codice è semplicissimo

myDataSource.Source = new DataProvider().Employees;

myDataSource.Filter += ((sender, args) =>

{

}

);

myListBox.ItemsSource = myDataSource.View.SourceCollection;

Naturalmente il codice del mio UserControl istanzia al suo interno una ClooectionView che effettua il dispatch degli elementi tramite la propria View, per fare questo ho ipotizzato anche un filtro che nel nostro esempio è vuoto in quanto suggerisco i video di Beth Massi su WindowsClient per approfondimenti sullaCollectionView e il databinding (consideriamo che il grouping non è supportato su Silverlight!)

Questo è il link del codice nell’esempio dove troviamo sia il binding che le local connections http://www.4shared.com/file/145868837/8115df4/SiverlightLocalConnections.html

Ricordo anche che per le cose rapidissime nel Silverlight toolkit è presente anche il mitico DataGrid, che personalmente non amo molto ma consente di sviluppare le cose con una rapidità impressionante.

In linea di massima mi chiedo, che senso ha sviluppare ancora applicazioni Windows Form? Secondo me per quando riguarda il codice nuovo, quindi quello prodotto da zero, la risposta è non ha alcun senso.

Ho fatto come Marzullo mi sono fatto una domanda e mi sono dato una risposta, va bè!

Per capire meglio di cosa stiamo parlando è opportuno fare un piccolo esempio introducendo appunto policy applcation block che ha anche un’età superiore di Unity, tale breve esempio anche se non fa parte delle più recenti tecnologie sarà moloto utile a scopo didattico.

Giusto per capire introdurre meglio l’ambito di discussione stiamo introducendo ciò che in gergo architetturale viene chiamato Separation of Concerns. Supponiamo dunque di avere un livello di business che deve semplicemente eseguire operazioni aritmetiche con due numeri.

public class MyAspectClass

{

public int Multiply(int a, int b)

{

try

{

return a + b;

}

catch (Exception e)

{

if (ExceptionPolicy.HandleException(“MyExceptionPolicy”, ex))

{

throw;

}

}

}

public int Subtract(int a, int b)

{

try

{

return a – b;

}

catch (Exception ex)

{

if (ExceptionPolicy.HandleException(“MyExceptionPolicy”, ex))

{

throw;

}

}

}

}

Come si può facilmente vedere è necessario ripetere la stessa gestione delle eccezioni in entrambi i metodi di moltiplicazione e sottrazione cioè è questo tipo di concern è chiamato comunemente aspect o cross-cutting concern.

Implementiamo dunque il Weaving cioè l’iniezione di codice nella nostra classe, che si può ottenere che differenti modalità cioè a compile time o a runtime. Questo tipo di comportamento con il più recente application block Unity viene chiamato Interception e probabilmente dedicherò un post apposito a unity per parlare dell’interception e come può essere utilizzato con davvero poche linee di codice.

Per prima cosa definimo il comportamento cioè quello che in gergo viene chiamato advice cioè
un intercettore che che sarà posto metà tra il chiamante e il chiamato e che effetturà delle azioniall’ingresso e all’uscita di quando un pezzo di codice viene processato.Modificheremo allora le policy sui due metodi che abbiamo scritto in prcedenza in modo tale da omettere la gestione delle eccezioni( naturalmente questo è solo un esempio di come tutti gli aspetti ripetitivi possano essere iniettati a livello applicativo). Andremo dunque a effettuare un Marshalling sulla nostra semplice classe e a decorare i metodi con alcune policy, la nostra classettina diventerà dunque:

public class MyAspectClass: MarshalByRefObject

{

[ExceptionCallHandler("MyExceptionPolicy")]

public int Multiply(int a, int b)

{

return a + b;

}

[ExceptionCallHandler("MyExceptionPolicy")]

public int Subtract(int a, int b)

{

return a – b;

}

}

La decorazione dei metodi sarà configurata con una policy che si chiamaMyExceptionPolicy definita altrove e nella fattispecie configurata tramite file .config.

Ovviamente il codice risulta molto più sentetico e leggibile, ma scriveremo la regola di gestione delle eccezioni solo una volta con una netta facilità di manutenzione. Possiamo a questo punto individuare un problema, cioè che se per caso avremmo necessità di cambiare il nome della nostra policy di gestione dell’eccezione dovremmo andare a mano a modificare i punti in cui questa eccezione è richiamata con un notevole dispendio di tempo e la possibilità di perderci qualcosa per strada che non è detto che emerga nei test unitari.

Un’altro metodo decisamente più efficace è quello di intercettare gli handler su una classe in modo da non dover passare tramite l’uso di attributi questo metodo è chiamato interception e fa la parte del leone nel più recente application block che è Unity.

Per fare queste cose definendo dele policy che accppiano regole e handler, in modo che se una avviene una determinata regola viene scatenato l’handler relativo.

A questo punto per definire meglio le regole di applicazione delle policy come nella tabella che segue:

Supponiamo di voler creare una regola che controlii l’espirazione di un oggetto, faremo così:

[ConfigurationElementType(typeof(CustomMatchingRuleData))]

public class MyTimeOfDayRule : IMatchingRule

{

private readonly DateTime _beginTimeSpan;

private readonly DateTime _endTimeSpan;

public MyTimeOfDayRule(NameValueCollection configValues)

{

_beginTimeSpan = DateTime.Parse(configValues["BeginTimeSpan"]);

_endTimeSpan = DateTime.Parse(configValues["EndTimeSpan"]);

}

#region IMatchingRule Members

bool IMatchingRule.Matches(MethodBase member)

{

DateTime currentTime = DateTime.Today;

return (currentTime >= _beginTimeSpan && currentTime <= _endTimeSpan);

}

#endregion

}

Naturalmente in casi reali spesso vengono definite molte regole che saranno testate a runtime mediante la seguente catena logica

Ora per utilizzare la nostra regola IMatchingRule dobbiamo configurare anche un handler che esegua delle operazione a fronte del match, EL fornisce anche una serie di handler predifiniti che sono in grado di comunicare con gli altri application block, essi sono:

Naturalmente è possibile definire il nostro handler e pertanto avremo dovremo implementare l’interfaccia ICallHandler per crere una classe che si comporti da da Handler, vediamone un esempio:

public class CreateFileHandler: ICallHandler

{

private readonly string _fileName;

#region ICallHandler Members

public CreateFileHandler(NameValueCollection configValues)

{

_fileName = configValues["FileName"];

}

public IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext)

{

FileStream stream = File.Create(_fileName);

input.InvocationContext["CreatedFileStream"] = stream;

IMethodReturn msg = getNext()(input, getNext);

FileStream returnStream = msg.InvocationContext["CreatedFileStream"] as FileStream;

if (returnStream != null)

try

{ returnStream.Close();}

catch {}

if (stream != null)

try { stream.Close(); }

catch { }

return msg;

}

public int Order { get; set; }

#endregion

}

E’ abbastanza intuibile come venga collocato mediante l’interfaccia ICallHandler nella catena delle chiamate illustrata prima

Non ci resta che assemblare il tutto medinte il PolicyInjector

public class MyAspectClass : MarshalByRefObject

{

[ExceptionCallHandler("MyExceptionPolicy")]

[ValidationCallHandler]

[RangeValidator(typeof(Int32), "0",

RangeBoundaryType.Inclusive, "0", RangeBoundaryType.Ignore,

MessageTemplate = "Value must be greater than zero.") ]

public int Multiply(

[RangeValidator(typeof(Int32), "0",

RangeBoundaryType.Inclusive, "0", RangeBoundaryType.Ignore,

MessageTemplate = "Value must be greater than zero.")]

int a,

[RangeValidator(typeof(Int32), "0",

RangeBoundaryType.Inclusive, "0", RangeBoundaryType.Ignore,

MessageTemplate = "Value must be greater than zero.")]

int b

)

{

return a + b;

}

[ExceptionCallHandler("MyExceptionPolicy")]

public int Subtract(int a, int b)

{

return a – b;

}

}

Ora configuriamo il tutto tramite l’utility di configurazione e provvediamo alla costruzione della nostra classe in questo modo

static void Main(string[] args)

{

MyAspectClass c = PolicyInjection.Create<MyAspectClass>();

c.Multiply(0, 5);

Console.ReadLine();

}

Il codice dell’esempio è scaricabile da qui: http://www.4shared.com/file/145800910/ef751dad/Policy_application_block.html