Discussion :

[imad_zer1]

Bonjour,
J'ai un PFE sur les service web .
Le projet consiste a ajouter un module en web service qui permet l'interfaçage entre un outil client et une application JEE .et même que les fonctionnalités de l'application je dois les mettre en service web.
j'ai un simulateur d'un maison intelligent qui je dois l'ajouté une couches des services web(les capteurs, les actionnaire ,les personnes seront en forme des services web)

Ma question est :
je vais commencer la partie de modélisation avec UML j'aimerai savoir vos orientations concernait les diagrammes que je dois réaliser de même est ce que j'ai besoin connaitre les diagrammes de l'application JEE existante pour réaliser les digramme de ce nouveau module ??

Merci d'avance

[EyZox]

Ce n'est pas très clair, je vais essayé de reformuler, dit-moi si ça correspond à ton besoin.

Tu as une application cliente et une application J2EE.
Tu souhaites dans un premier temps faire communiquer l'application cliente et l'application J2EE à l'aide d'un Web Service.
On a donc (Application Cliente) <-> (Web Service) <-> (Application J2EE) où le client ne communique pas directement avec l'application J2EE mais passe par le Web Service et inversement.
Tu es chargé du développement du Web Service.

Je ne suis pas très expérimenté en diagramme, je ne pourrais t'aider la dessus.
Pour moi un simple diagramme de flux suffit puisque ton Web Service ne réalise pas de traitement métier, il se contente d'attendre les demandes de l'application cliente, d'appeler les services métier de l'application J2EE correspondant, puis de renvoyer une réponse à l'application cliente.

Dans ce cas, tu n'as pas besoin de connaitre le fonctionnement technique de l'application cliente et J2EE. Tu as juste besoin de savoir ce que tu es censé recevoir de la part du client et à quel service métier la demande client fait référence.

[Robin56]

Pas mieux que ce qui a été dis précédemment. Pour le développement d'un WebService, il y a besoin :
- De connaître les différents appels,
- De connaître les différents envois,
- De connaître les données échangées dans un sens et dans l'autre.

Un diagramme de flux est donc suffisant et je confirme qu'il n'est pas de ton ressort de savoir ce qu'il se passe de l'autre côté.

Il faut donc clairement identifier de quoi les applications externes auront besoin en terme de service et ce qu'ils veulent t'envoyer.

[imad_zer1]

Merci, j’ai compris un peu ce que vous voulait dire, mais dans l’application par exemple j’ai une class « capteur » (comme capteur de mouvement, de température) cette class je dois la mettre comme un service je suis très perturbé, j’avais essayé de modifier l’ancien diagramme de class mais j’ai coincé alors maintenant j’essaie de le construire à nouveau, maintenant si vous avez une idée plus efficace aidez-moi svp parce que je suis coincé et je suis pas capable d’avancé sur mon mémoire.
Merci encore une fois

[EyZox]

Avant de t'attaquer aux classes (que normalement tu n'as pas a modifier), fait ce que Robin56 t'as conseillé de faire.

Il faut donc clairement identifier de quoi les applications externes auront besoin en terme de service et ce qu'ils veulent t'envoyer.

Ce travail là, ce sera la base de tout !
Un Web Service, c'est juste un composant qui reçoit des requêtes, qui fait un traitement et qui retourne une réponse.
La partie traitement existe déjà dans ton application J2EE, donc ton Web Service se contente de recevoir une requête, d'appeler les méthodes de l'application J2EE et de retourner une réponse.
Il faut que tu saches quelles requêtes tu es censé recevoir et qu'est ce que tu dois retourné.

Par exemple :

Requête : /temperature?capteur=XX
Réponse : <La temperature du capteur XX>

Une fois que tu as construit cette liste, tu pourra créer tes class de WebService.
Le Web Service possédera par exemple une référence vers le capteur pour pouvoir l’interroger lors d'une requête et retourner la température via son getter.