Eh bien, voilà : l’équipe Kumoe arrive à la fin de la période définie pour la création de ce projet d’interopérabilité Microsoft/Java. Plusieurs semaines de travail, de galères, de nuits blanches, d’avis divergents et, avant tout, de découvertes passionnantes.

Ce projet fut avant tout pour nous l’occasion de travailler sur un projet très complet, regroupant à lui seul différents outils qui vont prendre de plus en plus d’importance au fil des années. Et durant cette période de travail, nous avons pu découvrir ces techniques et les expérimenter avec beaucoup d’intérêt, en dépit d’un planning particulièrement court et chargé.

J’en profite donc, au nom de toute l’équipe, pour annoncer que le code source du projet sera rendu disponible sur ce blog. Vous pourrez donc y trouver tout ce dont ce sur quoi nous avons travaillé durant plus d’un mois, ainsi que les différentes parties du projet que nous avons finalisées dans les derniers jours.

Voici donc les liens :

Partie “Silverlight & SDS” : http://kewlshare.com/dl/4e2a295e43e0/KUMOE_MICROSOFT.rar.html

Partie “Java & SQL” : http://kewlshare.com/dl/ee90032947a6/KUMOE_JAVA.rar.html

Les sources concernant la queue de messages seront disponibles avant le jeudi 5 février.

Note : Sur les liens ci-dessus, pour télécharger le code source, il vous suffit de cliquer sur le bouton “Free User”.

Précisions

Durant les derniers mois de travail, nous avons rencontré quelques problèmes pour le déploiement de la solution sur Azure (voir les captures d’écran ci-dessous), mais voici cependant l’adresse où elle se trouvera : http://kumoe.cloudapp.net

Et voici un petit aperçu de l’allure de l’application de VOD :

Nous allons ensuite appliquer le concept MVC (Modèle Vue Contrôleur) en utilisant les EJB Session et Entity. Le schéma ci-dessous précise les parties Client et Serveur, dans le cadre d’une procédure d’authentification à partir de l’application Back Office :

Deux projets Java sont créés ici : une application de type EntrepriseApplicationClient, et une autre de type EJBModule :

Voici les différentes étapes de l’authentification :

1 – Interface Homme/Machine (partie Vue), avec bouton pour valider l’authentification :

2 – Utilisation de l’EJB Session avec son interface (partie Contrôleur) :

a) Interface

b) Implémentation

3 – EJB Entity (partie Modèle)

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é.

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…

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.

Silverlight Streaming nécessite un compte LiveID, et permet un stockage gratuit de streaming de 10 Go maximum. Il faut savoir qu’en cas de dépassement de stockage, il faudra passer par une option payante.

Procédure

Pour uploader un fichier vidéo, la première étape consiste d’abord à récupérer un identifiant (numéro de compte SLS) et une clé. Pour cela, il suffit de s’inscrire sur le site suivant : http://silverlight.live.com.

Une fois l’identifiant et la clé récupérés, il est possible d’uploader une vidéo en cliquant sur l’option “Manage Video”. A noter que l’option “Manage Applications” fait de même pour les applications Silverlight.

L’upload d’un fichier (au format “.wmv”, “.avi”, “.mpeg”, “.mov”…) nécessite l’emplacement du fichier, ainsi qu’un titre. Une fois que le fichier est uploadé, une URL statique est fournie pour accéder au fichier vidéo.

Procédure avec communication REST

Je vais aborder ici la procédure d’authentification sur Silverlight Streaming par requête REST. Notons qu’il est indispensable pour cela d’avoir les identifiants (Account ID et Account Key).

Le code suivant (en C#) présente la procédure d’authentification (par souci de simplicité, j’ai choisi le mot “foo” en guise d’Account ID) :

Concernant la gestion des vidéos avec REST, nous allons recourir aux requêtes HTTP suivantes :

• PUT, pour l’ajout d’une vidéo
• DELETE, pour la suppression d’une vidéo
• COPY, pour la duplication d’une vidéo

Pour la procédure d’identification (vue ci-dessus) et l’ajout de fichiers sur la plateforme Silverlight Streaming, nous allons nous appuyer sur les librairies du framework Restlet (www.restlet.org). Ses librairies sont directement téléchargeables sur le site, et devront ensuite être implémentées parmi les librairies de l’application Java (Back Office).

Uploader un fichier avec PUT.

A partir de là, nous allons voir comment uploader un fichier sur Silverlight Streaming.

La procédure présentée au sommet de cet article donnait les indications suivantes : il s’agit avant tout de s’identifier sur la plateforme, de donner un nom à sa vidéo (qui correspondera au répertoire qui contiendra la vidéo) et de valider l’upload. Il faut également savoir qu’une fois présente sur le site, la vidéo sera appelée “video.wmv”.

Pour effectuer l’upload de fichier de façon logicielle, nous allons effectuer une requête de type PUT, basée sur les librairies de Restlet, au sein d’une application Java.

Dans un premier temps, il convient de recenser et d’initialiser les données utiles :

Ensuite, après avoir initialisé les données, il s’agit de concevoir le répertoire (ou FileSet) qui contiendra la vidéo sur la plateforme. On utilise pour cela la méthode MKCOL. Le code se présente de la façon suivante :

Enfin, il ne reste plus qu’à envoyer la requête PUT pour l’upload de la vidéo :

De cette façon, il est possible d’uploader facilement une vidéo sur l’interface Silverlight Streaming. Tout ce code sera implémenté dans notre application Back Office et exécuté lorsque l’utilisateur souhaitera uploader une vidéo sur la plateforme Silverlight Streaming.

Par la suite, il va s’agir d’effectuer une requête HTTP avec les méthodes DELETE et COPY.

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.

L’architecture comprendra différents JavaBeans (EJB : Entreprise JavaBeans) qui seront interrogés par un client léger. Ces EJB assureront les différentes fonctionnalités d’identification, de recherche et de gestion (films, locations et clients). Pour chacune de ces fonctionnalités, des fonctions d’ajout, de modification, de suppression et de consultation seront implémentées.

Les différents EJB Session communiqueront avec les EJB Entity, qu faciliteront l’utilisation de l’unité de persistance (Hibernate).

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

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 genre, 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.

Comme je l’ai dit, ce projet est issu du partenariat entre notre école et Microsoft France. Mais plus précisément, en quoi consiste celui-ci ? Il s’agit de nous former sur certaines des dernières technologies de Microsoft et sur l’interopérabilité avec le monde Java. Principalement, nous allons utiliser le nouveau système d’exploitation Windows Azure et Silverlight pour mettre en place une application “dans les nuages”. Dans le cloud computing, toute l’infrastructure du système d’information est mutualisée à l’échelle d’internet. Concrètement, cela signifie que l’informatique qui ne concerne pas directement le métier de l’entreprise est externalisé sur des serveurs distants. De cette façon, elle peut passer plus de temps sur son cœur de métier.

Le principe même du cloud computing repose sur la notion de web services. Il s’agit d’un ensemble de fonctionnalités exposées sur un réseau (internet ou intranet) permettant la communication et l’échange de données entre applications et systèmes hétérogènes. Ainsi, au travers d’un web service, une application développée sous une technologie Microsoft (C#, pour exemple), sera capable de communiquer avec une application Java. On voit apparaître ici une autre notion: l’interopérabilité. Pour résumer, l’interopérabilité consiste à faire fonctionner plusieurs applicatifs ensemble. Pour aller plus loin, on ne peut parler d’interopérabilité que si l’on connaît intégralement toutes les interfaces d’une application.

En généralisant ce concept de web services, le cloud computing fait intervenir deux nouvelles idées: le IaaS et le SaaS. Derrière ces termes obscures, que se cache-t-il ? En fait, il s’agit d’acronymes: IaaS signifiant Infrastructure As A Service; SaaS voulant dire Software As A Service.

Le principe de “software as a service” repose sur l’hébergement à distance d’applications. Par exemple, un CRM hébergé sur internet sera considéré comme un SaaS. En effet, un système de gestion de relation clients comporte beaucoup de fonctionnalités. En ce sens, un CRM ne peut pas exister sous une autre forme qu’une application.

Le principe de “infrastructure as a service” est, quant à lui, beaucoup plus large. L’idée générale de cloud computing étant de permettre à l’entreprise de se recentrer sur son métier, le besoin d’externaliser les applicatifs liés à l’infrastructure est apparu. Pour être plus précis, il s’agit de tout ce qui est nécessaire à la vie de l’entreprise, mais qui n’est pas lié à son activité. Par exemple, un serveur de mail est très important pour une entreprise, en tant que moyen principal de communication et de transmission d’informations. De cette façon, les “web mail” (live mail, gmail… ) ont vu le jour.

C’est donc dans l’esprit d’utiliser les dernières technologies de Microsoft (Windows Azure, Silverlight 2.0, SQL Data Services) et les concepts dont j’ai parlé ci-dessus (cloud computing, interopérabilité, web services) qu’un projet nous a été donné. Mais ce projet, quel est-il ? Pour ma part, je distingue deux grandes parties: l’existant et ce qu’il faut faire. Cela peut sembler étrange, mais puisque l’existant devra être réalisé par nous, il s’agit d’une partie indépendante du projet.

Voici le scénario: une société propose la location de vidéos depuis plus de 10 ans, dans plus de 600 magasins. Suite à la généralisation de la “video on demand”, l’entreprise voit ses parts de marché diminuer. L’entreprise souhaite donc trouver de nouveaux relais de croissance tout en s’appuyant sur ses différenciateurs :

• sa présence sur de multiples points de vente
• son large catalogue de vidéos

C’est ainsi que le projet a vu le jour. L’entreprise va proposer son propre service de VOD, en minimisant les coûts d’exploitation et en étendant le catalogue de vidéos au travers de partenariat entre magasins. Pour être plus clair, la liste des vidéos disponibles doit comprendre la totalité des offres des magasins. Quelques fonctionnalités “bonus” sont aussi demandées: la vidéo n’est disponible que pour une durée de 24 heures; les abonnés sont informés de la disponibilité de nouvelles vidéos; l’authentification peut se faire via Live ID ou Open ID.

Pour continuer la liste des contraintes, l’interface de streaming doit être faite avec Silverlight, alors que l’existant sera développé en Java. De plus, le stockage des données sera effectué au travers de Azure SQL Data Services et SQL Express.

Enfin, le projet étant destiné à implémenter une application “dans les nuages”, le nom de notre projet devait refléter ce besoin de nous diriger “vers les nuages”. D’où la traduction en japonais : “Kumoe”.