Category: Windows Azure


Quand les problèmes s’en mèlent…

Une des phases du développement d’une application réside dans la résolution de problèmes. Même si très peu de développeurs apprécient d’être confrontés à des problèmes et de passer un nombre important d’heures à leur résolution, je considère que l’intérêt d’un projet est proportionnel au nombre de difficultés à surmonter pour le mener à bien. Qui ne s’est pas déjà arraché les cheveux à essayer de comprendre pourquoi ceci ou cela ne fonctionne pas, ou mal ? Mais la satisfaction que l’on ressent lorsqu’enfin on réussi à mettre le doigt sur ce qui ne va pas est bien réelle !

Pour ma part, arriver à surmonter une difficulté me procure le plaisir de m’être dépassé et d’avoir approfondi mes connaissance sur un point précis. De plus, les environnements de développement nous proposent toujours de nouveaux outils pour nous aider dans notre tâche, comme les JUnits ou les Unit Tests en C#. Je ne vais pas ici discuter du réel intérêt de réaliser ces tests car il devient évident pour peu que l’on ait commencé à les faire. Mais malgré ces avancées, il reste toujours des problèmes plus coriaces, ou indépendants de notre volonté.

Il m’est arrivé récemment l’un de ces problèmes avec Windows Azure. Vendredi soir, alors que je faisais des essais avec un web service de gestion de queues de message, j’ai demandé à la plateforme de supprimer un package. Seulement, je ne sais pourquoi mon package est en cours de suppression depuis ce moment. C’est embêtant car je ne peux plus déployer d’autre package pour ce projet. Je ne peux, en fait, plus rien faire. Autre point plus problématique, c’est que le temps d’utilisation de la machine virtuel est décompté. Autrement dit, et puisque je suis limité à 2 000 heures, mon crédit de temps va rapidement être consommé.

Suppression d'un package

Heureusement, ce projet s’effectue en groupe, et j’ai toujours la possibilité de déployer mon package sur un autre compte.

Bien entendu, un problème ne vient jamais seul. Après quelques heures à préparer mon service de gestion de queues Azure, je n’arrive plus à effectuer des requêtes vers mon compte de queues et de tables Azure. Après un peu de temps passé à essayer de comprendre le pourquoi, il s’avère que le service appelé reconnaît le contenu du header « Authorization » comme n’étant pas valide. Ce qui est dérangeant, c’est principalement que ça fonctionnait très bien puis que, sans raison apparente, il m’est impossible de m’authentifier. Alors bon, j’ai effectué de nombreux tests pour palier à ce problème, mais en vain. J’utilise une petite librairie (StorageClient) proposée par Microsoft pour aider à la gestion des Azure Queues et Tables et je me suis dit que le problème pouvait venir de là.

J’ai donc cherché plus avant et décidé de créer « à la main » la requête REST; toujours en vain. Après une journée et une bonne partie de la nuit à essayer de comprendre, j’en ai déduis que la seule possibilité était que le format du header « Authorization » ait été modifié. Pourtant, non seulement je n’en trouve nulle trace, mais ça me semble peu judicieux de la part de Microsoft. Même s’il s’agit d’une CTP (Community Technology Preview), plusieurs projets utilisant des queues ou des tables sont déjà déployés. Une telle modification aurait un impact trop important pour que cela ait eu lieu.

J’en conclu donc que c’est le moment pour moi de faire une petite pause; tout du moins en ce qui concerne cette partie du projet. Je ne désespère pas de comprendre le pourquoi du comment, quand j’aurai pris un peu de recul…

Récemment, j’avais présenté le moyen d’utiliser le protocole REST pour effectuer une requête HTTP de type « PUT » en Java. Ceci était valable pour l’ajout d’un fichier vidéo (de type « .wmv ») sur la plateforme Silverlight Streaming.

Je vais ici présenter deux cas relatifs à la suppression et à la copie d’un fichier vidéo présent sur cette plateforme (le code sera ici en C#).

Copie

Dans notre architecture, lorsqu’un utilisateur souhaitera louer une vidéo, il a été décidé qu’une requête de type « COPY » soit effectuée pour copier le FileSet du fichier vidéo. C’est le lien vers cette copie qui sera ensuite expédié vers l’utilisateur.

On démarre ici avec plusieurs variables principales :

  • L’objet contenant la requête
  • Deux chaînes de caractères contenant respectivement l’emplacement du FileSet et le nom du futur FileSet copié
  • Deux chaînes de caractères contenant respectivement l’identifiant et la clé du compte SLS
  • Une autre chaîne contenant l’adresse du SLS (https://silverlight.services.live.com)

HttpWebRequest _requete;

string _fileName = « C:/Users/GuillaumeGas/Desktop/essaiVideoNumberOne/ »;

string _fileSetName = « copy »;

string _ID, _Key;

string serviceRoot = « https://silverlight.services.live.com/ »;

Dans un premier temps, il va falloir effectuer une authentification, ainsi qu’une recherche de l’emplacement du fichier à copier.

if (_fileSetName != «  » && _fileName != «  ») {

// Récupération du nom du FileSet à copier

FileInfo _fInfo = new FileInfo(_fileName);

string _fileNameOnly = _fInfo.Name;

_requete = (HttpWebRequest)HttpWebRequest.Create(_serviceRoot + _ID + « / » + _fileSetName);

}

// Authentification credentials

_requete.Credentials = new NetworkCredential(_ID, _Key);

// Déclaration de la méthode COPY

_requete.Method = « COPY »;

// Envoi de la réponse

_requete.Headers[« Destination »] = _serviceRoot + _ID + « /copy »;

HttpWebResponse _resp = (HttpWebResponse)_requete.GetResponse();


Au final, on a réussi à copier le FileSet. Notons que la copie s’effectue de façon instantanée.

Suppression

Le principe est le même, à la seule différence qu’on effectue une requête de type DELETE.

Ici, imaginons qu’on souhaite supprimer notre copie précédemment créée :

if (_fileSetName != «  ») {

_requete = (HttpWebRequest)HttpWebRequest.Create(_serviceRoot + _ID + « / » + _fileSetName);

}

On définit alors la requête DELETE :

// Déclaration de la méthode DELETE

_requete.Method = « DELETE »;

// Envoi de la réponse

HttpWebResponse _resp = (HttpWebResponse)_requete.GetResponse();


La suppression de la copie s’effectue alors instantanément.

Architecture interne – Azure

Cet article va présenter un peu plus en détail l’application de « Video On Demand » dont nous avions déjà parlé précédemment.

gestionws

Les différents WebServices seront disponibles via la plateforme Windows Azure. Le client (via une interface homme-machine élaborée à partir de Microsoft Silverlight) pourra ainsi les interroger grâce à WSDL (Web Services Description Langage). Par la suite, ces services lui permettront d’accéder aux données et d’effectuer les actions souhaitées.

Pour l’instant, les WebServices que nous avons retenus sont les suivants :

  • Identification
  • Recherche
  • Compte
  • Locations
  • Compte
  • Consultation
  • Administration

D’autres fonctionnalités seront probablement ajoutées au projet ultérieurement.

Les WebServices serviront également à la transmission de vidéos, et l’apport de la technologie Silverlight Streaming servira à leur sauvegarde.

Idée d’Architecture

L’existant:

Présentation de l'existant

PRESENTATION

Tous les magasins sont équipés suivant le même schéma : une base de données est alimentée par une application contrôlée par le magasin. Les employés peuvent, à partir de cette application, ajouter une vidéo à louer, en retirer une, spécifier si une vidéo est disponible…

Comme son nom l’indique, il s’agit d’une application qui avait été développée avant cette étude. Lors de la création de son architecture, la technologie Java/J2EE avait été retenue.

ARCHITECTURE DETAILLEE

Architecture détaillée

Puisqu’il nous est nécessaire de nous appuyer sur cette application, il est important d’en connaître son architecture détaillée. Ce projet n’étant pas un cas réel, il n’est pas possible de l’étudier.

Par conséquent, et puisqu’un lien important existe entre notre projet et cette application, nous allons devoir la créer. Ainsi, nous avons décidé d’utiliser une architecture dite “modèle, vue, contrôleur” (MVC). Autrement, nous allons ajouter un tiers qui servira de relais entre la borne interactive ou l’application magasin et la base de données.

Ainsi, l’interface consultée par les utilisateurs (que ce soit sur la borne ou le poste) sera développée en Java. Afin d’accéder aux données, elle interrogera un serveur GlassFish au travers de web services. De plus, l’utilisation de Hibernate permettra une gestion simple de la persistance des objets dans la base de données relationnelle.

Application de VOD :

ARCHITECTURE

L’étude de l’existant fini, il est maintenant essentiel de s’intéresser à l’application de VOD. Le projet s’inscrivant dans le cadre du partenariat entre l’EPSI et Microsoft France, nous sommes avons décidé d’utiliser des technologies proposés par cette entreprise. C’est la raison pour laquelle l’interface de consultation sera réalisée au travers de Silverlight.Cette interface pourra interroger des web services, que nous aurons rendu disponibles via Windows Azure. De cette façon, l’utilisateur aura la possibilité de créer un compte, dont les informations seront enregistrées dans une base de donnée relationnelle gérée par SQL Data Services. Ces web services permettront d’accéder aux données concernant les vidéos, à savoir la liste complète de celles-ci, leur Architecturegenre, les informations cinématographiques (réalisateur, acteurs, durée, …). En plus de cela, des informations supplémentaires seront disponibles. En effet, le propre des réseaux sociaux étant l’échange, il sera possible de laisser des commentaires et des notes sur les vidéos, ou encore de la conseiller à un ami.

De plus, ces web services serviront à transmettre les vidéos, qui seront sauvegardées par la technologie Silverlight Streaming. Il sera ainsi possible de limiter le temps pendant lequel un utilisateur peut visionner une vidéo.

INSERTION DE DONNEES

Pour terminer, il faut faire le lien entre cette application et l’existant. En effet, cette application perdrait une grande partie de son intérêt s’il n’était pas possible de profiter du large catalogue de vidéos proposé par les 600 magasins de “TonTube”. C’est ici que les web services prennent toute leur ampleur. En effet, en hébergeant cette architecture sur Windows Azure, il est possible de rendre visible l’un d’eux par une application externe.

Dès lors, et puisque l’existant est constitué de web services également, il suffit d’en ajouter un à cette dernière. Son rôle sera de fournir les informations à l’application de VOD, lors de l’ajout d’une vidéo dans un point de location. Le service en charge de recevoir ces données vérifiera alors si la vidéo est déjà présente dans le catalogue. Si ce n’est pas le cas, il le spécifiera à l’application qui l’a contacté. Celle-ci lui transmettra alors le film, qui sera enregistré par Silverlight Streaming.

Cela permettra, par ailleurs, d’enregistrer les nouveautés. Ainsi, il sera possible d’envoyer une lettre d’information aux utilisateurs enregistrés; et de les tenir informés de l’ajout de nouvelles vidéos.

Récapitulatif :

En fin de compte, les deux parties du projet (existant et VOD) restent très indépendantes. Même si elles sont toutes deux basées sur une architecture 3-tiers, la seule utilisation de deux web services permet une communication optimale entre eux. Pour ce qui est de l’existant, un applicatif Java, installé sur la borne et sur le poste du magasin demandent ou envoient des informations à un serveur GlassFish. Celui-ci, au travers de Hibernate, interroge ou met à jour la base de données du magasin.

Lorsqu’une vidéo est ajoutée, l’application, sur le serveur, va en informer un web service situé “dans les nuages”. A ce moment, si la nouvelle vidéo n’est pas référencée, elle est ajoutée. De cette façon, l’utilisateur pourra accéder aux web services, au travers d’une interface réalisée avec Silverlight.

C’est ainsi que, tout au long de ce projet, nous aurons la possibilité d’appréhender les dernières technologies de Microsoft, tout en mettant en oeuvre des concepts tels que le cloud computing, l’interopérabilité et les web services.