[Azure] Introduction Azure Services Platform (Windows Azure, .NET Services, Live Services, SQL Services)
Introduction à Azure Services Platform
Petite présentation de Azure Services Platform:
Windows Azure est un système d’exploitation “On the cloud” vous permettant d’héberger vos applications dans les DataCenters de Microsoft.
Plusieurs interêts à utiliser la plateforme Azure: haute disponibilité, adaptation à la volée des besoins de votre service, respect de la philosophie S+S (Software + Service)…
Voici l’architecture global de Azure Services Platform:
Image de www.techheadbrothers.com
Vous remarquez sur le schéma ci-dessus que la plateforme Azure est composée de plusieurs sous-entités:
- Live Services: c’est là où nous trouvons des systèmes comme Live Mesh nous permettant de voir son réseau de contacts live, ses devices, ses news etc…
- .NET Services: outils pour exposer vos services sans vous soucier des problèmes réseaux (Firewall, DMZ…)
- SQL Services: c’est la version “on the cloud” de SQL Server vous permettant de stocker / requêter / synchroniser des objets.
- SharePoint Online, Dynamics CRM Online, Exchange Online …: Ce sont les deux produits que vous connaissez, hebergés sur du Azure en version allegée.
- Windows Azure: ne pas confondre avec Azure Services Platform, c’est l’outil qui nous permettra d’héberger nos sites et services dans les data centers de Microsoft.
Pour vous préparer au développement Windows Azure il vous faut:
Après installation, vous trouverez dans Visual Studio la possibilité de créer des projets Cloud Service:
Nouveau projet Windows Azure
Il existe deux gros types de projets pour Windows Azure, le type Web Cloud Service et le type Worker Cloud Service.
Architecture de Windows Azure
Le Web Cloud Service représente le “Web Role”. Le “Web Role” expose grâce à HTTP/HTTPS un service WCF ou un site ASP.NET.
Le Worker Cloud Service représente le “Worker Role”. C’est un processus qui fait le lien entre les données (SQL Services) et le Web Role.
Sur le schéma précédent, vous pouvez voir qu’il existe plusieurs systèmes de persistance:
- Le blob storage: Données binaires
- Le queue storage: Pile FIFO
- Le table storage: tables sans relations
Vous entendrez souvent parler de “fabrique”: cette fabrique sur Azure permet l’automatisation de l’allocation des ressources.
Créer un site ASP.NET pour Windows Azure
Rendez-vous ici: https://lx.azure.microsoft.com/Cloud/Provisioning/default.aspx pour créer un nouveau projet.
Puis, si votre token est bien valide, votre compte est approvisionné:
Selectionnez Hosted Services puis configurez votre projet:
Une fois le projet créé, vous arrivez sur une page contenant deux notions: Production et Staging.
Production: C’est la partie visible directement sur http://juliendblog.cloudapp.net/
Staging: C’est le stade avant déploiement sur un domaine généré à la volée.
Maintenant il nous faut créer notre site ASP.NET.
Revenons dans Visual Studio pour créer un Web Role:
Architecture de la solution générée:
Le projet Web Role contient une simple page ASP.NET “Hello Word”.
Le projet JuliendBlog contient la configuration Azure de notre projet.
Lors de la compilation vous remarquerez que l’outil “Development Storage” qui exploite SQL Express s’éxécute et effectue diverses initialisations. Il permet de simuler tout le côté persistance de Azure (Table, Queue, Blob).
Un autre outil s’éxécute “Development Fabric” qui est l’équivalent de la Fabric Azure en local:
Il ne manque plus qu’à déployer notre solution sur Azure. Passez votre projet en mode Release puis cliquez sur Publish. Cet outil va vous générer deux fichiers:
Vous pouvez tester votre application en cliquant sur “Run” puis l’url générée:
Et mettre le projet en production sur votre adresse:
L’application est désormais accessible à partir de juliendblog.cloudapp.net (attention, parfois il y a 15/20 min d’attente avant que votre site soit accessible).
Un exemple de projet connu porté sous Windows Azure: Blog Engine.
Créer un service WCF pour Windows Azure
Comme vu précédemment, il faut créer une solution Azure de type Web Role que l’on nommera MyService.
A laquelle on rajoute un service WCF:
Puis modifiez le web.config pour utiliser le type de binding “basicHttpBinding”.
Exécutez votre service afin de générer le proxy avec un second visual studio représentant votre client:
Enfin déployez sur Azure comme vu ci-dessus. Modifier le .config de votre client pour mettre la bonne adresse:
<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IService1"
maxBufferSize="2147483647"
maxReceivedMessageSize="2147483647">
<security mode="None" />
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint
address="http://juliendblog.cloudapp.net/Service1.svc" `
binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_IService1"
contract="ServiceReference1.IService1"
name="BasicHttpBinding_IService1" />
</client>
</system.serviceModel>
</configuration>
Persistance de données pour Windows Azure
Il existe trois types de persistance dans Windows Azure Storage:
Pour activer la gestion de données pour votre projet Azure, direction le portail:
Le portail va vous fournir 3 URL vous permettant d’exploiter les 3 types de persistances: 
Nous allons sauvegarder chaque appel au service fait ci-dessus avec le système Queue.
Notre service contient cette méthode:
string DoWork(string test);
A noter que pour vos développements, la persistance de données est permise en local grâce à Development Storage qui utilise SQL Server express 2005/2008 et qui permet de développer en offline en émulant le stockage “on the cloud”.
Ajoutez la référence à StorageClient livré avec le SDK d’Azure.
public string DoWork(string test)
{
string accountName = "juliendblog";
string accountKey = "Key here";
string address = "http://queue.core.windows.net";
StorageAccountInfo info =
new StorageAccountInfo(new Uri(address), null, accountName, accountKey);
QueueStorage qs = QueueStorage.Create(info);
MessageQueue q = qs.GetQueue("test");
if (!q.DoesQueueExist())
q.CreateQueue();
q.PutMessage(new Message(test));
return "Vous avez tapé " + test;
}De même pour retrouver ce qui a été mis dans la pile utilisez q.GetMessage().ContentAsString();
Worker Role pour Windows Azure
Le worker role est une class library contenant une méthode Start appelée au démarrage par la fabrique Azure et une méthode Stop lors de l’arrêt de l’hébergement.
C’est l’équivalent d’un “Batch” qui ira lire Windows Azure Storage et fera des traitements.
Pas de communication directe entre le Rôle Web et le Rôle Worker.
Image d’une présentation aux techdays 2009
Comment ajouter un worker à notre service WCF ? Faites un clic droit sur Role:
Puis ajoutez un worker:
public override void Start()
{
RoleManager.WriteToLog("Information", "Worker Process entry point called");
while (true)
{
Thread.Sleep(10000);
RoleManager.WriteToLog("Information", "Working");
//Traitements, lecture Queue, Table, Blobs
}
}Introduction à SQL Services
SQL Services s’appuie sur SQL Data Services (SDS), c’est la version “On The Cloud” de SQL Server.
SDS supporte:
- Les tables, les indexes et les vues
- Les contraintes, triggers
- Les Procédures stockées
SQL Services est requêtable à partir d’un client (Winforms, ASP.NET…) de plusieurs façons:
- Grâce aux drivers traditionnels (ODBC, OLEDB…) qui utiliseront TDS (SQL Over HTTP)
- Grâce à une application WCF hébergée dans Windows Azure en tant que “Web Role”
- Grâce à ADO.NET Data Service / ADO.NET Entity Framework dans Windows Azure qui exposera vos données avec la technologie HTTP/REST
Schéma représentant SQL Service
Un post de Sebastien Warin en parle davantage. Les équipes promettent que nous pourrons utiliser les drivers habituels et que nous n’aurons qu’une connectionstring à changer pour exploiter SDS.
Comment cela se passe dans SDS ?
Image MSDN
Normalement, vous avez des tables qui contiennent des enregistrements. Ici, ce sont des Contrainers qui contiennent des entities.
Vous trouverez le SDK pour SDS ici.
Ce SDK contient SDS Explorer qui va nous permettre de créer une autorité, des containers et des entities.
SDS Explorer
Vous trouverez ici un tutorial pour SDS Explorer.
Il existe une alternative à SDS Explorer, Omega SDS réalisée en Silverlight 2:
https://onlinedemo.cerebrata.com/omega.sdsclient/current/default.aspx
Omega SDS
Utiliser SQL Services
Pour approvisionner votre compte afin d’utiliser .NET Services et SQL Services, identifiez vous ici: http://go.microsoft.com/fwlink/?LinkID=129428
Puis direction http://portal.ex.azure.microsoft.com/gettingstarted.aspx pour créer votre projet et modifier votre mot de passe.
Dans un premier temps nous allons utiliser Omega SDS afin de concevoir nos entities on the cloud. Connectez-vous avec les identifiants récupérés lors de votre inscription (ci-dessus).
A gauche vous pouvez voir les Authorities, par exemple “juliendblog”.
Il faut maintenant créer un contrainer (par exemple Employees):
Et enfin nos entities, pour cela on ajoute des Flexible Entities. Les types supportés sont
string
binary
Boolean
decimal
dateTime
A ce stade, vous pouvez requêter votre SDS grâce à l’onglet Query dans Omega SDS:
from e in entities select e
Nous renvoie:
<s:EntitySet xmlns:s="http://schemas.microsoft.com/sitka/2008/03/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:x="http://www.w3.org/2001/XMLSchema">
<Test>
<s:Id>a93f99e9-d2b5-4e78-b9ce-d336fae944cb</s:Id>
<s:Version>132709423</s:Version>
<Nom xsi:type="x:string">DOLLON</Nom>
<Prenom xsi:type="x:string">Julien</Prenom>
<Date xsi:type="x:dateTime">1987-07-19T00:00:00</Date>
</Test>
<Test2>
<s:Id>e473a92a-3a86-4170-9c9e-0448d156effa</s:Id>
<s:Version>132709432</s:Version>
<Nom xsi:type="x:string">Valentin</Nom>
<Prenom xsi:type="x:string">Pauline</Prenom>
<Date xsi:type="x:dateTime">1988-12-22T00:00:00</Date>
</Test2>
</s:EntitySet>On peut aussi sélectionner par rapport à un ID:
from e in entities where e.Id == "a93f99e9-d2b5-4e78-b9ce-d336fae944cb" select e
<s:EntitySet xmlns:s="http://schemas.microsoft.com/sitka/2008/03/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:x="http://www.w3.org/2001/XMLSchema">
<Test>
<s:Id>a93f99e9-d2b5-4e78-b9ce-d336fae944cb</s:Id>
<s:Version>132709423</s:Version>
<Nom xsi:type="x:string">DOLLON</Nom>
<Prenom xsi:type="x:string">Julien</Prenom>
<Date xsi:type="x:dateTime">1987-07-19T00:00:00</Date>
</Test>
</s:EntitySet>Et par une propriété:
from e in entities where e["Nom"] == "VALENTIN" select e
<s:EntitySet xmlns:s="http://schemas.microsoft.com/sitka/2008/03/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:x="http://www.w3.org/2001/XMLSchema">
<Test2>
<s:Id>e473a92a-3a86-4170-9c9e-0448d156effa</s:Id>
<s:Version>132709432</s:Version>
<Nom xsi:type="x:string">Valentin</Nom>
<Prenom xsi:type="x:string">Pauline</Prenom>
<Date xsi:type="x:dateTime">1988-12-22T00:00:00</Date>
</Test2>
</s:EntitySet>Cependant, comment faire interagir mon application en C# avec SQL Services ?
Vous trouverez toutes les actions CRUD sur la msdn : http://msdn.microsoft.com/en-us/library/cc512437.aspx
Petit test rapide, je lance SVCUTIL pour générer le proxy:
svcutil.exe /noLogo /out:"ssdsClient.cs" /language:csharp ^
/config:app.config ^
/n:*,SDSTest.ssdsClient ^
/serializable ^
/ser:DataContractSerializer ^
/importXmlTypes ^
https://database.windows.net/soap/v1/
Puis je rajoute à un projet Winforms le app.config généré et la classe ssdsClient.cs.
Je rajoute également les références à System.Runtime.Serialization et System.ServiceModel.
Puis je teste un Select sur l’employee Valentin:
using (proxy = new SitkaSoapServiceClient("BasicAuthEndpoint"))
{
proxy.ClientCredentials.UserName.UserName = "juliendblog";
proxy.ClientCredentials.UserName.Password = "motdepass";
Scope myEntityScope = new Scope();
myEntityScope.AuthorityId = "juliendblog";
myEntityScope.ContainerId = "Employees";
//ID de l'employee pour la selection
myEntityScope.EntityId = "e473a92a-3a86-4170-9c9e-0448d156effa";
try
{
Entity myEmployee = proxy.Get(myEntityScope);
MessageBox.Show(myEmployee.Properties["Nom"].ToString());
}
catch (FaultException<Error> ex)
{
MessageBox.Show(ex.Message);
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
}
A noter que d’après ce post il existe une version avec ADO.NET Data Services.
Introduction à .NET Services
.NET Services remplace désormais BizTalk Services. Il met à disposition:
-
Service Bus: Possibilité de communication par message depuis/vers Azure
-
Access Control: Qui dit zone public, dit contrôle d’accès
- Workflow: Processus métier sur Azure
Tout ceci permet d’éviter:
- La compléxité en entreprise lors de l’exposition d’un service (DMZ ? Firewall ?)
- Les communications difficiles entre client/server en dehors de l’entreprise
La différence entre exposer un service WCF sur Windows Azure ou .NET Services est que .NET Services fournit une sorte de “mise en relation”, c’est-à-dire qu’il n’héberge pas directement le service WCF (contrairement à Windows Azure).
.NET Services n’implique pas forcément que le service soit hébergé sur le Cloud (Web Role sur Windows Azure) mais puisse être hébergé sur un serveur quelconque.
Le SDK de .NET Services est téléchargeable ici.
Utiliser .NET Services
Nous allons créer un simple WCF consommé par un client:
Le fichier de configuration App.config côté client et serveur:
<configuration>
<system.serviceModel>
<services>
<!-- Application Service -->
<service name="Microsoft.ServiceBus.Samples.EchoService">
<endpoint contract="Microsoft.ServiceBus.Samples.IEchoContract"
binding="netTcpRelayBinding" />
</service>
</services>
</system.serviceModel>
</configuration>Vous remarquez que le Binding est différent d’un binding de base en WCF, voici les équivalences:
Image de la session “.NET Services” des techdays 2009
Le code Serveur se compose d’un contrat et d’une implémentation comme un WCF classique. La différence se trouve lors de l’hébergement du service (code côté Service):
TransportClientEndpointBehavior userNamePasswordServiceBusCredential
= new TransportClientEndpointBehavior();
userNamePasswordServiceBusCredential.CredentialType
= TransportClientCredentialType.UserNamePassword;
userNamePasswordServiceBusCredential.Credentials.UserName.UserName
= "juliendblog";
userNamePasswordServiceBusCredential.Credentials.UserName.Password
= "motdepasse";
//sb://juliendblog.servicebus.windows.net/EchoService/
ServiceHost host = new ServiceHost(typeof(EchoService), address);
Lors du Hosting de notre service, nous lui attribuons une adresse de type:
sb://nom_de_la_solution.servicebus.windows.net/Nom_Endpoint/
Ainsi que nos credentials de notre compte .NET Services (de même pour le ChannelFactory côté client).
L’exemple de code ci-dessus est disponible dans le SDK .NET Services: C:\Program Files\Microsoft .NET Services SDK (March 2009 CTP)\Samples\ServiceBus\GettingStarted\Echo\CS35
Introduction à Live Services
Live Services permet la synchronisation entre les gens, leurs périphériques, leurs données et leurs applications.
Vous trouverez ici un post “Créer votre première application Silverlight pour Live Mesh”
Conclusion
Je pense que Azure va révolutionner les applications de demain. Plus de soucis d’OS, d’hardware, de déploiement, de sauvegarde, de load balancing etc… On se concentre essentiellement sur le côté metier et l’aspect S+S.
Petit bémol quand même, malgré le gros coup marketing je trouve qu’on est encore assez loin d’un produit fini mais cela nous laisse de belles perspectives à venir !
Merci à Julien Corioland qui m’a prété son compte live pour utiliser le compte Azure !