Examen de l’architecture des services web de Breeze

L’architecture Breeze sépare la couche de présentation des informations de la couche applicative et ce, de façon élégante. Les communications de l’interface utilisateur à l’application sont basées exclusivement sur XML. C’est pour cela que vous disposez automatiquement d’un accès via services web à l’application et aux données après l’installation du serveur Breeze. C’est là, techniquement, une option que vous devez acheter et dont l’installation requiert l’obtention ou la sélection d’un code d’accès*. En dehors de ces conditions, le serveur fournit une structure facilement accessible. Si votre serveur est installé sur breezedev.entreprise.fr, par exemple, l’URL principale permettant d’accéder à vos services web sera breezedev.entreprise.fr/api/xml. L’architecture est présentée en Figure 1.

Figure 1. Architecture des services web de Breeze

Le servlet XML/API de Breeze se tient à l’écoute de requêtes comprenant des informations d’authentification, des informations liées à la session, la requête d’action, et les paramètres associés. Les actions sont demandées par nom. Par exemple, la requête permettant d’obtenir les réunions actuelles est appelée report-my-meetings. Chaque requête que vous envoyez doit comprendre le nom de l’action et tout autre paramètre nécessaire. La requête est envoyée via HTTP au format XML ou sous la forme de paramètres dans l’URL. Le serveur Breeze répond à la requête en récupérant les données dans la base de données lorsque nécessaire et forme la réponse en tant que document XML, qui est renvoyé à votre application.

Les interactions avec Breeze ne sont pas emballées dans une « enveloppe » comme c’est le cas pour SOAP, et aucune validation du code XML avec un schéma n’est nécessaire. De futures versions des services web pourraient prendre ces fonctions en charge. Pour l’instant, il vous suffit d’analyser la réponse XML dans votre application.

Conception de l’application

Il est toujours judicieux de penser à l’organisation de l’application et aux stratégies de développement avant de commencer à rédiger le code. Il vous faudra décider de la façon dont vous allez séparer la couche de présentation de la couche d’exécution. Pensez à la structure à suivre. La structure MVC (modèle/vue/contrôleur) est généralement celle adoptée. Pour cet exemple, le « contrôleur » pourrait être le servlet XML/API Breeze alors que l’application Breeze pourrait être le « modèle ». Votre application est une vue permettant de présenter les réunions. Simple, non ?

Votre première application affiche toutes les réunions. L’application suivante pourrait afficher tous les cours actifs ou tous les cours suivis au cours de la semaine précédente. Un des principes de base devrait donc être de créer du code réutilisable autant que faire se peut. Le code qui permet d’établir la connexion avec les services web de Breeze est un excellent candidat pour ce qui est de la réutilisation. Dans cet article, vous allez créer une classe API qui encapsule tous les détails de la connexion et réalise l’analyse XML. Cette méthode permettra à un programmeur JSP de créer d’autres applications sur la base de votre travail.

L’application donnée en exemple comporte une page d’ouverture de session de même qu’une page destinée à l’affichage de la liste des réunions. Une simple page HTML suffit au traitement de la fonction d’ouverture de session. La page devant afficher la liste des réunions fait référence à vos classes réutilisables et doit donc être une page JSP. Vous allez créer un JavaBean pour traiter l’interaction API et l’analyse XML, et une classe Meeting pour capturer les données des réunions une fois la réponse XML analysée. Vous pouvez maintenant créer les fichiers dont vous avez besoin :

• Login.html : un formulaire d’ouverture de session devant recueillir le nom d’utilisateur et son mot de passe. Vous pouvez créer des champs pour l’URL du serveur et le code d’accès à l’API, qui seront utilisés dans le cadre de vos tests. Vous devrez ensuite supprimer et enregistrer ces paramètres dans un fichier de propriétés protégé sur le serveur. Sélectionnez la méthode GET et l’action MyMeetings.jsp.
• MyMeetings.jsp : un tableau contenant le nom de la réunion dans une cellule de la ligne et la date/heure de début dans la cellule suivante. Ce fichier ne contient pour l’instant que du code HTML. Vous ajouterez du code Java à l’étape suivante.
• Meetings.java : une classe avec le nom de votre choix. Cette classe devrait comprendre des chaînes protégées pour le nom de la réunion, sa description, l’URL sur laquelle l’utilisateur doit cliquer pour participer à la réunion et un objet Date protégé. Votre constructeur devrait accepter le nom, la description, l’URL de la réunion et une chaîne de date qui devra être analysée dans l’objet Date. La méthode getDate devrait renvoyer une chaîne et non pas l’objet Date.
• XMLApiBean.java : une autre classe dans le même paquetage que Meetings.java. C’est dans cette classe que le plus gros du travail a lieu. Créez des chaînes protégées pour tous les paramètres d’accès – tels que l’URL du serveur, le nom d’utilisateur, le mot de passe et le code d’accès – et pour JESSIONID, qui est fourni pour authentifier les appels API une fois la connexion réussie. Le constructeur devrait accepter tous ces éléments.

Vous devriez également configurer votre projet dans votre environnement de développement pour une application web. Assurez-vous d’inclure les fichiers JAR dans votre application web ou de les ajouter au chemin CLASSPATH de votre serveur d’applications Java. Vous pouvez maintenant commencer à travailler sur le code.

Page 2 sur 6

Page précédente

Page suivante