January 2011 - Posts - Roberto Brunetti

Nostre applicazioni WP7

Oggi, la nostra moneta è tornata nella home page:

e Kind Love è rientrata nelle raccomandazioni

Le altre proseguono la loro corsa.

Posted: Jan 27 2011, 05:26 PM by rob | with no comments

Windows Azure: il punto sui componenti

A distanza di un anno dal rilascio e dall’entrata in vigore del sistema di billing, Windows Azure si presenta ad oggi con un fornito set di componenti per accogliere diverse tipologie di soluzioni.

Windows Azure ad oggi è in versione 1.9 basata su sistema operativo Windows Server SP2 o in versione 2.1 su sistema Windows Server 2008 R2.

L’SDK è arrivato alla versione 1.3 e, fra le sue varie componenti, troviamo anche una importante opportunità: far girare le applicazioni in modalità Full IIS.

Si vedano i post precedenti per le novità della 1.3, sia per quanto riguarda l’SDK che per quanto riguarda i Windows Azure Tools 1.3:

http://blogs.devleap.com/rob/archive/2010/12/17/windows-azure-tools-1-3-news-1-x.aspx
http://blogs.devleap.com/rob/archive/2010/12/20/windows-azure-tools-1-3-2-x.aspx
http://blogs.devleap.com/rob/archive/2011/01/04/windows-azure-tools-1-3-3-x.aspx

Per quanto riguarda Windows Azure AppFabric abbiamo la situazione più calda, in quanto, oltre a Service Bus e Access Control, rilasciti ad aprile 2010, vedremo le seguenti novità nel corso del 2011:

Alcune novità per il Service Bus stesso testabili già oggi in beta sulla Lab environment.

Alcune novità anche per Access Control disponibili in preview sulla Lab environment.

Un nuovo componente denominato Caching per fornire una cache distribuita per applicazioni Windows Azure e SQL Azure. Nella prima metà del 2011 è stato pianificato il rilascio definitivo, menter è già testabile la versione beta sempre sulla Lab environment.

Per quanto riguarda l’integrazione di applicazioni, siano esse cloud-based o appliaczioni on-premises, alcune servizi che conosciamo oggi nella sfera di BizTalk Server, saranno disponibili come componenti di AppFabric. Per adesso non è disponibile una CTP che arriverò nel corso del 2011.

Le applicazioni moderne sono composte da diverse componenti e la possibilità di ospitarne tutti o alcuni sul cloud aumenta non solo la complessità delle interazioni fra di essi, ma anche la gestione delle installazioni, versioning e aggiornamenti. Per questo, nel 2011 vedrà la luce una CTP di Composite App che consente di gestire e automatizzare le fasi di deployment e management; questo componente consente di ospitare direttamente alcuni componenti e servizi come i classici servizi WCF o i workflow di WF.

Posted: Jan 17 2011, 08:13 AM by rob | with no comments

Filed under: Azure

Windows Azure Connect

Una delle novità che vedrà la luce nel corso del 2011 è rappresentata da Windows Azure Connect.

Direttamente dalla documentazione ufficiale, “con Windows Azure Connect si possono configurare connessioni dirette fra uno o più computer (o macchine virtuali) nella rete locale con Web Role e Worker role che girano in Windows Azure”.

In questa prima fase occorre chiedere il codice di attivazione per partecipare al programa beta e, una volta ottenuto occorre seguire i seguenti passi:

1) Dal nuovo portale scegliere la sezione Virtual Network

2) Scegliere la subscription per la quale si vuole attivare il “gruppo” virtuale di macchine. Nel mio caso, come si può vedere ho scelto per mostrare questo post una mia subscription di test

3) La prima volta che si sceglie il menù Connect viene richiesto di attivare la subscription e appena risposto “Yes” si presenta la seguente maschera:

4) Occorre installare il Local Endpoint, ovvero il software locale che apre un endpoint sulla macchina per essere inserita nella rete virtuale insieme al ruole nel cloud. L’installazione si attiva tramite il pulsante relativo.

Ci viene proposto l’url da cui scaricare il software che contiene direttamente il token di attivazione. Non è possibile salvare il ”download” in quanto contiene l’activation token.

Il token è possibile comunque richiederlo in ogni momento tramite il pulsante “Get Activation Token”.

5) Lo stesso token deve essere fornito nel Service Model del role che vogliamo connettere. Aprire da Visual Studio la configurazione del Role e incollare il token dopo aver abilitato Virtual Network

Visual Studio inserisce in automatico l’importazione del modulo di Connect nel file ServiceDefinition.csdef.

E confiugra con il Token il relativo valore nel file di configurazione.

VS configura anche ai valori di default una serie di altri settaggi.

6) Fare il deploy del progetto su Windows Azure e tornare nella configurazione della Virtual Network

I primi due progetti rappresentano le due istanze di Web Role del progetto su Windows Azure, mentre la terza è l’instanza del Local Endpoint

7) Creare un gruppo fra le instanze locali e remote:

8) Una volta costruito il gruppo le macchine sono connesse tramite IPv6 e la connessione viene protetta con IPSec.

Provare per credere…basta un ping per nome del ruolo.

Posted: Jan 16 2011, 06:51 PM by rob | with 16 comment(s)

Windows Azure Step by Step–by Roberto Brunetti

Uscirà a metà maggio il mio nuovo libro su Windows Azure: si tratta di un volume “Passo Passo” e ha quindi l’obiettivo, negli undici capitoli, di guidare il lettore nella costruzione di esempi che sfruttino la piattaforma Windows Azure.

I primi capitolo introducono la piattaforma, il portale, l’SDK per Visual Studio per poi lasciare il posto al Windows Azure Storage Account e Windows Azure AppFabric. Un intero capitolo è dedicato a SQL Azure.

Due capitoli di “contorno” sono dedicati all’architettura delle applicazioni e all’acceso alle informazioni e alle Management API dall’esterno.

A metà maggio uscirà la versione inglese e dopo qualche tempo…la localizzazione in italiano.

Posted: Jan 15 2011, 01:23 PM by rob | with no comments

Filed under: Azure

Windows Azure Tools 1.3 3/x

Proseguiamo l’elenco delle novità della nuova versione dell’SDK.

In questa puntata vediamo come inserire più Web Site nell stesso Web Role: è possibile infatti creare più siti web, su porte diverse oppure sfruttando gli host header, all’interno dello stesso Web Role.

E’ anche possibile creare virtual directory e virtual application mappando logicamente directory di un progetto web: vedremo questa parte nella prossima puntata.

Proviamo a partire da zero creando un nuovo progetto con il template classico di Windows Azure Project. Ho scelto Web Form per semplicità visto che non ci interessa distrarci con cose che non sono importanti.

La situazione di partenza è questa.

Nel file ServiceDefinition.csdef è sufficiente inserire un secondo Site e indicare per entrambi una physicalDirectory come attributo. Le differenze rispetto al default sono in bold.

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="WindowsAzureProject8" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
<WebRole name="WebRole1">
    <Sites>
      <Site name="Web1" physicalDirectory="..\WebRole1">
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" hostHeader="a" />
        </Bindings>
      </Site>
      <Site name="Web2" physicalDirectory="..\WebRole1">
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" hostHeader="b" />
        </Bindings>
      </Site>
    </Sites>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="http" port="80" />
    </Endpoints>
    <Imports>
      <Import moduleName="Diagnostics" />
    </Imports>
</WebRole>
</ServiceDefinition>

Il path da usare è ovviamente relativo visto che non esistono “percorsi fisici” su Windows Azure. Nel mio caso punta al progetto WebRole1. Utilizzando “..” si scende di una directory come sempre: il punto di partenza da considerare è il file ServiceDefinition ovvero un punto all’interno del progetto Azure.

Occhio che così facendo il WebRole di default (localhost:81) non risponde più.

Se è necessario che risponda occorre aggiungere una definizione anche per l’host header di default:

Gli altri due elementi in bold consentono di specificare un classico Host Header ovvero il valore che il web site riceve da un browser e che indica l’host richiesto. Ho usato “a” e “b” solo per testimoniare che non devono essere niente di “predefinito”: chiaramente un DNS deve essere in grado di risolvere questi nomi che potrebbero, nella realtà essere “www.devleap.com” e “www.devlead.com”, i nostri due siti pubblici supponendo di volerli mappare sullo stesso site.

E’ possibile indicare una sottodirectory all’interno del progetto, ad esempio:

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="WindowsAzureProject8" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
<WebRole name="WebRole1">
    <Sites>
      <Site name="Web1" physicalDirectory="..\WebRole1\devleap">
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" hostHeader="www.devleap.com" />
        </Bindings>
      </Site>
      <Site name="Web2" physicalDirectory="..\WebRole1\devlead">
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" hostHeader="www.devlead.com" />
        </Bindings>
      </Site>
    </Sites>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="http" port="80" />
    </Endpoints>
    <Imports>
      <Import moduleName="Diagnostics" />
    </Imports>
</WebRole>
</ServiceDefinition>

In questo caso due sottodirectory del progetto vengono associate ai due differenti host header.

Sarà sufficiente indicare al nostro DNS mantainer che www.devleap.com e www.devlead.com sono alias verso “xxx.cloudapp.net” dove “xxx” è il nome del nostro Hosted Service su Windows Azure per ottenere il risultato desiderato.

In locale, anche IIS si comporta di conseguenza, creando due Web Site e due application pool corrispondendi:

Il mio progetto Azure è sotto c:\temp come si nota dal mapping.

Ecco gli application pool, anch’essi con nomi temporanei.

Posted: Jan 04 2011, 10:33 PM by rob | with no comments

Roberto Brunetti

Recent Posts

Tags

Navigation

.NET Programming

Archives