[Azure] SQL Data Services : le nouveau plan !

Vendredi 13 mars 2009

SQL Data Services (SDS) est l’un des services offert sur la « Azure Services Platform » qui offre une « extension de la plateforme SQL Server sur le cloud Windows Azure ». D’ailleurs son nom initial était « SQL Server Data Services ».

image

SDS avait été annoncé au MIX08 comme un service de base de données flexible utilisant les protocoles standard d’Internet (REST, XML, …). C’est depuis la PDC08 en Novembre 2008 que nous avons pu découvrir et jouer avec cette nouvelle technologie.

De part sa conception « on-the-cloud » SDS fourni une haute disponibilité et monté en charge. De plus l’administration est complètement délégué et automatisé par le service, plus besoin de gérer la configuration, maintenance ou la mise en place de plan de backup. SQL Server devient alors un service à la demande que je créé ou supprime en fonction de mes besoins et paye en fonction de ce que je consomme.

SDS reposait alors sur un modèle de donnée nommé ACE :

  • Authority : unité géographique associé a un nom DNS (https://<MonAutorite>.data.database.windows.net/) et contient des containers
  • Container : unité de consistance contenant des entités
  • Entity : unité de stockage constitué de propriétés type Clé/Valeur.

Le schéma n’était donc pas imposé (on pouvait mettre par exemple une entité « Client » et « Facture » dans un même container – de même plusieurs versions d’une entité pouvait cohabiter), ce qui donné le coté « flexible » de ce service. La base de données étant après exposée en REST ou SOAP sur les front-end SDS et nous utilisions une syntaxe « à la LINQ » pour le requêtage.

Oui mais voilà, ça c’est du passé : oubliez tout ce que vous savez sur SDS :)

SDS : Le nouveau plan

Nous étions sans nouvelle de l’équipe SDS depuis fin octobre 2008, date à laquelle SDS fut présenté à la PDC08. Fin février la team SDS nous explique pourquoi son silence : « on a un nouveau plan, il sera annoncé prochainement » !

Après presque deux semaines de suspense, ce mardi 10 mars 2009, l’équipe SDS nous annonce :

  • On oublie le modèle ACE qui sera supprimé au profit d’un traditionnel modèle de SGBD (tables, SP, triggers, vues, index, ….)
  • On oublie la syntaxe de requêtage à la LINQ au profit du T-SQL

En clair SDS devient véritablement un SQL Server hébergé sur le cloud Windows Azure et accessible comme un service !

Ce qui est bon pour nous développeurs, c’est qu’il n’y aura « quasiment » aucune migration à apporter dans nos applications que l’on utilise un serveur local « on premise » ou Azure « on the cloud ». L’équipe SDS parle d’une « expérience » où il n’y aurait que notre chaine de connexion (connectionString) à changer !

Coté technique tout fonctionnera sur le protocole TDS (Tabular Data Stream) le protocole qu’utilise déjà SQL Server ! Vous utiliserez SDS tout comme vous utilisez un serveur MS-SQL aujourd’hui !

Coté sécurité c’est une authentification SQL qui sera proposée et le tout encapsulé dans du SSL pour garantir la confidentialité des communications.

Et la flexibilité du modèle de donnée et utilisation des protocoles standards Internet dans tout ca ?

Pour le coté « flexible » il faut se tourner vers le Azure Storage Table qui fourni un modèle de donnée flexible basé sur des entités ayant une collection de propriétés dans la même ligné que le modèle ACE. Cela stoppera les confusions dans le rôle que remplissent ces deux services.

Pour ce qui est de l’utilisation des protocoles standard internet comme le REST, nous utiliserons ADO.NET Data Services (Astoria) pour exposer nos bases de données qu’elles soient « on premise » (SQL Server) ou « on the cloud » (SDS).

Next Step

Pour l’instant rien de tout ça n’est encore concret ! Aucune annonce quant à la disponibilité d’une première version de ce nouveau SQL Data Services mais j’aurai la chance de pouvoir assister à la session « What’s New in Microsoft SQL Data Services MIX09-T06F » au MIX09 à Las Vegas la semaine prochaine où nous aurions certainement plus d’information sur le sujet.

Sources :

TechDays 2008 : Soyez au coeur de l’événement…

Dimanche 10 février 2008

logo

Vous vous souvenez peut-être de l’ édition 2007 qui m’avais d’ailleurs valus la 4ème place du concours de blog, cette année les TechDays 2008 en quelques points :

  • Plus de 25 parcours (de l’IT au dev, en passant que le chefs de projet, DSI, etc..) et 280 sessions techniques
  • Les grands spécialistes dans chaque domaine (plus de 350 speakers)
  • Des Workshops et Hands-on Lab (by Supinfo)
  • Plus de 15.000 personnes sur les 3 jours
  • Cette année en plus, le lancement officiel de SQL Server 2008 et Windows Server 2008 !

Et ça commence dès demain, du 11 au 13 février au Palais des Congrès de Paris :D

Cette année j’ aurais en plus la chance d’ animer une session sur « IIS7 pour les développeurs » avec Sébastien Bovo de Microsoft France le lundi 11 février de 11h à 12h. Nous aurons l’ occasion de revenir sur les grandes nouveautés de la nouvelle version du serveur web de Microsoft en quelques points :

  • L’architecture modulaire du pipeline IIS
  • L’ interaction (asp).NET avec les IHttpHandler et IHttpModule
  • Le nouveau système de configuration full-XML
  • La nouvelle console d’administration IIS et les API .NET

Je n’ en dis pas plus pour le moment, vous retrouverez de toute façon l’ intégralité des sessions sur le site des TechDays après l’ événement.

En tout cas, pour ceux qui seront présent, je vous souhaite de bons TechDays en espérant y vous retrouver là-bas et pour ceux qui n’ y seront pas il n’ est pas encore trop tard pour prendre un train ;)

Je pars faire mon parcours, mes affaires et répéter ma session… A demain !

Applications connectés/déconnectés avec la réplication transactionnelle SQL Server 2005

Dimanche 25 février 2007

Il y a quelque temps je cherchais a mettre en place une architecture d’application connectée/déconnectée !
Typiquement j’ai plusieurs clients qui se connectent à un serveur de base de donnée pour centraliser leurs données ! Mais ces clients sont mobiles et n’ont pas toujours de connectivité. Ils doivent donc posséder une version locale du serveur la plus a jour possible pour continuer a travailler et se synchroniser avec le serveur dès qu’ils retrouvent la connexion pour mettre a jour les données modifiées en local pendant la déconnexion et répliquer les nouvelles données du serveur.

L’application est lourde, difficile de revenir dans le code, trop de boulot ! Je me suis donc débarrassé du problème en laissant SQL Server 2005 le gérer pour moi !

Pour cela, sur le serveur central (avec un SQL Server 2005 Standard ou +) la base de donnée a été publié au travers une « Publication transactionnelle prenant en charge les abonnements mis à jour » dans les outils de réplication que propose SQL Server 2005.
Il ne reste plus qu’a installer SQL Server 2005 Express (et gratuite :) ) et de venir l’abonner à la publication du serveur central.
L’application n’a plus qu’a venir taper sur l’instance sqlexpress locale et MSSQL gère le reste :)
Elle est pas belle la vie ?? Encore faut-il arriver a configurer le tout… :p

Pour cela il nous faut :

  • 1 serveur avec SQL Standard ou +
  • X client(s) possedant une instance d’SQL (SQL Express fait très bien l’affaire !)
  • SQL Studio Management Standard/Express pour configurer tout ça (bien que des scripts peuvent être réalisé pour un déploiement plus simple !)

Les étapes pour mettre tout ça en place :

1er étape : connexion et résolution de nom
Libre à vous de choisir la connexion avec votre serveur. Pour ma part les clients étaient connectés via un simple VPN Windows pour garantir un 1er niveau de sécurité. Mais après il ne faut pas oublier la résolution des noms NETBIOS ! Il faut d’une part que votre client sache résoudre le nom du serveur MAIS AUSSI que votre serveur sache résoudre le nom du client. Pour cela le plus sûr et simple est d’installer un serveur WINS sur le serveur. Vous trouverez WINS dans « Ajout et supp. de programme » sur votre serveur Windows 2000 ou 2003. Sur les clients il faudra juste dans les options avancées TCP/IP de votre connexion, entrer l’IP de votre serveur WINS.
A Savoir : dans le cas d’un adresse IP dynamique (DHCP) de vos clients, il faut garder a l’esprit le processus de résolution de noms par Windows :

  1. Interrogation du cache local (sachant que la durée de vie d’un enregistrement est de 10min)
  2. Interrogation du serveur WINS
  3. Broadcast sur le réseau
  4. Interrogation du fichier local LMHOST

Ce qu’il faut en retenir, c’est que si votre client vient a perdre la connexion puis se reconnecte sous une adresse IP différente, il se peut que votre serveur ne puisse pas résoudre son nom pendant moins de 10min, le temps que l’ancien enregistrement dans son cache local expire !

2ème étape : SQL Server sur le réseau Par défaut un SQL Server 2005 Standard ou + est configuré pour accepter les connexions distantes mais ce n’est pas le cas de la version express qui par défaut n’accepte que les connexions locales.

Pour cela dans « SQL Server 2005 Surface Aera Configuration » > « Service and connections » : autoriser les connexions locales et distances TCP/IP et par « pipe ».

Ensuite dans MMC « SQL Server Configuration Manager » vérifier que le protocole TCP/IP dans la configuration réseau de votre instance SQLEXPRESS est bien activé.

Pour finir, relancer votre instance SQM et activer le démarrage automatique d’ SQL Browser et lancer-le !

A ce stade, vous devez être en mesure de vous connectez du client sur le serveur et du serveur sur le client !

3ème étape : MSDTC et le réseau MSDTC pour Microsoft Distributed Transaction Coordinator doit être lancé sur le client ET serveur pour permettre la réplication. Pour cela, dans « Services » dans outils d’administration, activé le démarrage automatique de ce serveur et lancer-le !

Il faut aussi que votre serveur et client autorisent les connexions à distances.
Pour cela, toujours dans les outils d’administration, dans « Services de composants » accéder aux propriétés de votre « Poste de travail ».

Sous l’onglet « MSDTC » > « Configuration de la sécurité » :

Pour activer les options suivantes :

Notes : A ce stade, les préliminaires pour mettre en place la réplication transactionnelle sous SQL Server 2005 est OK. Du coté du firewall il faut ouvrir le port SQL (1433) et MSDTC (process msdtc.exe) coté serveur comme client

4ème et 5ème étape : Configuration de la publication coté serveur et de l’abonnement du client
Pour cela je vois renvoi sur un article de Fabrice publié sur ASP-PHP ici. Bien que le type de publication ne soit pas la même la configuration est quasi-identique a part qu’il vous faudra prendre le type « Publication transactionnelle prenant en charge les abonnements mis à jour » et non « par capture instantanée » comme dans l’article.
De plus lors de la configuration de l’abonnement (coté client), il faudra définir a « en attente » la « méthode de mise a jour » :)

Quand tout s’est déroulé avec succès, votre client récupèrera toute la base (ce qui peut être long la 1er fois, tout dépends de la taille de votre base !). Puis amusez-vous a mettre faire des modifications en local en connecté/déconnecté et voyez comment les autres clients se synchronisent !

Certes dans certaine application ça a ses limites (pas de contrôle réelle sur la synchronisation, régle de « si pas modifié, je peux injecter mes données » qui peut provoquer pas mal de perte de donnés si il y a beaucoup de mise a jour, etc..etc..) mais pour ma part ça répondait aux besoins donc expédié avec 0 lignes de code (enfin si 1: la connString dans le App.config :p) et quelques heures recherches/configuration/tests :)

Merci Mr SQL :)

Windows Sharepoint Service 3 (WSS) : Installation de la beta 2

Jeudi 20 juillet 2006

Windows Sharepoint Service est une sorte de CMS qui permet la création de sites collaboratifs pour le partage de documents et d’informations. On peut par exemple créer des sites communautaires, des wikis, des blogs, etc…

Microsoft a mis à disposition la version 3.0 en bêta 2 de WSS gratuitement pour pouvoir tester l’engin. WSS permet nottament l’intégration à Office (MOSS). Il devient très facile d’ouvrir sont Word 2007, d’y taper un article, un post, … puis de l’enregistrer non pas dans un fichier mais directement sur votre site WSS.

Pour l’installation, il vous faudra un Windows 2003 Server, si possible en R2 et en anglais (je n’ai pas testé, mais je pense pas que l’on puisse l’installer sur une FR). N’oubliez pas de le mettre a jour :)
Ensuite, dans l’Ajout et Suppression de programme, installez le Framework .NET 2.0 :

Suite a cela, le plus simple est d’installer seulement les runtimes pour Workflow Foundation plutôt que toutes les briques du .NET Framework 3.0.

Enfin, vous pourrez démarrer l’installation de WSS3 en choissant l’installation « Basic » :

SQL Express sera installé pour faire office de SGDB. Il serait utile aussi d’installer le Management Studio Express pour pouvoir parcourrir les BDD.

Une fois l’installation de WSS terminée, il faudra executer SharePoint Products and Technologies Configuration Wizard pour :

  • Configurer l’accée à la base de donnée. Dans le cadre dans d’une installation « Basic », Microsoft SQL Server 2005 Express Edition sera installé et configuré.
  • Installer et configurer les fonctionnalités et services de WSS.
  • Configurer la sécurité.
  • Créer un site WSS de démo.

Après cela, vous accederez a l’interface Web d’admin du site WSS créé par défaut. Et la c’est QUE DU BONHEUR :-D

Téléchargements :

Note importante : n’installez pas VS2005 avant WSS ou du moins n’installez pas SQL Express avant WSS sinon vous risquez d’avoir des problèmes lors de la configuration de WSS qui se bloque à l’étape 2 : Création de DB…. J’en ai fait les frais : 1 journée de perdu :)