Differences

This shows you the differences between two versions of the page.

--- wiki:epims4_0m2:developer:ep-webservices [2008/07/16 08:31]
dupierris
+++ wiki:epims4_0m2:developer:ep-webservices [2009/06/08 14:38] (current)
@@ Line 9: / Line 9: @@
 \\
-{{ epWS_general.png }}
+{{ epws_general.png }}
 >> **Figure 1** : Schématisation du fonctionnement des web-services.
@@ Line 23: / Line 23: @@
 Cette section décrit l’organisation des packages ainsi que les points d’interaction entre eP-WebServices et eP-Core.
-==== 1.Général ====
+==== Général ====
 {{ epWS_fonctionmt.png }}
@@ Line 31: / Line 31: @@
-==== 2.eP-WebServices ====
+==== eP-WebServices ====
-eP-WS est un projet Web normal intégrant une librairie particulière permettant de faire des web-services, sa structure est la suivante :
+eP-WS est un projet Web normal intégrant une librairie particulière permettant de faire des web-services. On retrouve donc sous le répertoire WEB-INF:
-{{ epWS_structure_project.png }}
+  * geronimo-web.xml : intégration au serveur d'application geronimo
+  * services.xml : déclaration des services pour [[ cxf_web-services|CXF]]
+  * springWSAppContext.xml : fichier spring définissant le lien entre les beans d'implémentation des services et les services [[ cxf_web-services|CXF]]
+  * web.xml : fichier classique d'application web, contenant également la définition pour [[ cxf_web-services|CXF]]
-Ce module contient 4 packages :   En gros : model, services, exception, test
-{{ epWS_packages.png }}
+=== et eP-CoL  ===
-  * Les objets du package model représentent les objets du modèle nécessaires au fonctionnement d'eP-WS et non présent dans eP-Core (RobotSample, VirtualPlate spécifique, PlateDescriptor etc...).
+Pour la partie communication, eP-WebServices utilise la librairie [[ep-col|eP-CoL]]. Cette librairie définit
-  * Les objets du package services représentent les classes d'implémentation (et leur interface) traitant les requêtes des utilisateurs et les réponses d'eP-Core. XFire se base sur les interfaces pour définir les services proposés et sur les classes d'implémentation pour les exécuter.
+    * les classes représentant tous les objets qui seront échangés entre les applications. Ces objets sont le plus souvent une vue simplifiée/condensées des objets du domaine d'eP-Core.
-  * Les objets du package exception représentent les exceptions spécifiques à eP-WS.
+    * les interfaces des services qui sont proposés par eP-WebServices
-  * Les objets du package test représentent les classes de tests d'eP-WS.
-=== Détails du package model ===
-Ce package contient les classes spécifiques aux web-services, et de ce fait non présents dans eP-Core.
-  * **IVirtualPlate & VirtualPlate** : Classes représentant des plaques virtuelles. :!: Elles ne représentent pas le même objet que les classes ''IVirtualPlate'' et ''VirtualPlate'' d'eP-Core (dans le code les classes d'eP-Core sont "surnommé" //Business Virtual Plate// et celles d'eP-WebServices //WS Virtual Plate//. Ex la méthode ''businessVPlateToWsVPlate(...)'' qui transforme une plaque du modèle d'eP-Core en plaque du modèle d'eP-WS). Ces classes spécifiques d'eP-WebServices représentent une plaque virtuelle en associant un ''PlateDescriptor'' et une liste de ''RobotSample'' (voir plus loin pour la description de ces 2 objets). Ces plaques virtuelles ne contiennent donc pas, à la différence des objets d'eP-Core, de liste de puits pointant vers des planning robot. Pour figurer ces puits la liste est de taille définie (nb colonnes * nb lignes de la plaque) et à chaque emplacement il y a un ''RobotSample'' pour figurer un puits remplit ou ''null'' pour un puits vide.
-  * **IRobotSample et RobotSample** : Classes représentant des échantillons planifié pour le robot. Par rapport au modèle d'eP-Core cet objet regroupe l'ensemble des informations du RobotPlanning et quelques information utiles concernant l'échantillon. Il permet de transmettre un objet de taille raisonnable ne contenant que les informations utiles. En effet si le modèle d'eP-Core avait été utilisé transmettre un ''RobotPlanning'' aurait transmis en même temps l'ensemble des infos de l'échantillon correspondant, l'ensemble des infos sur l'étude liée etc...etc...
+eP-WebServices contient 2 packages :
+  * cea.edyp.ws.model contient l'implémentation des objets du modèle d'eP-CoL nécessaire aux services
+  * cea.edyp.ws.service contient l'implémentation des services définis dans eP-CoL.
-  * **PlateDescriptor** : Classe représentant de façon succincte les informations essentielles concernant une plaque virtuelle : nom, date de planification, nombre de colonne et de ligne, l'état de verrouillage, l'acteur ayant verrouillé si il y a lieu. Cet objet permet de ne pas transmettre une grosse quantité d'information qui ne serait pas utile.
+eP-WebServices étends ''IComVirtualPlate'' d'eP-CoL afin d'ajouter les fonctionnalités d'ajout et de supression d'échantillons.
-==== 3. Services Disponibles ====
+==== implémentation ====
-=== PlateServices ===
+Ce paragraphe décrit les spécificités au niveau implémentation des objets et services définit dans eP-CoL.
-Ce "pack" contient les services généraux de consultation des plaques.
-  * **getAllRobotSamples()** (retour : List<IRobotSample>) : Donne la liste complète des échantillons planifiés sur le robot de préparation. Ces échantillons sont donnés sous la forme de //RobotSample// (cf //détails du package model//).
+__''IVirtualPlate & VirtualPlate'' : Classes représentant des plaques virtuelles.__
+:!: Elles ne représentent pas le même objet que les classes IVirtualPlate et VirtualPlate d'eP-Core (dans le code les classes d'eP-Core sont “surnommé” Business Virtual Plate et celles d'eP-WebServices WS Virtual Plate. Ex la méthode businessVPlateToWsVPlate(…) qui transforme une plaque du modèle d'eP-Core en plaque du modèle d'eP-WS). Ces classes spécifiques d'eP-WebServices représentent une plaque virtuelle en associant un PlateDescriptor et une liste de RobotSample. Ces plaques virtuelles ne contiennent donc pas, à la différence des objets d'eP-Core, de liste de puits pointant vers des planning robot. Pour figurer ces puits la liste est de taille définie (nb colonnes * nb lignes de la plaque) et à chaque emplacement il y a un RobotSample pour figurer un puits remplit ou null pour un puits vide.
-  * **getUnassignedSamples()** (retour : List<IRobotSample>) : Donne la liste des échantillons planifiés sur le robot de préparation mais encore non assignés à une plaque virtuelle. Ces échantillons sont donnés sous la forme de //RobotSample// (cf //détails du package model//).
-  * **getAllVirtualPlates()** (retour : List<PlateDescriptor>) : Donne la liste complète des //PlateDescriptor// représentant de façon succinctes les plaques virtuelle présentes.
-  * **getVirtualPlate(String name)** (retour : IVirtualPlate) : Donne la plaque virtuelle correspondant au nom donné.
+===== 4. Construction d'un nouveau Web-service =====
-  * **isValidPlateName(String name)** (retour : boolean) : Permet de savoir si un nom de plaque est utilisable ou non. Renvoi //True// si le nom n'est pas encore utilisé dans le système, //False// si oui.
+Un web-service, avec CXF, est composé d'une interface et de sa classe d'implémentation (ex : PlateStorage et IPlateStorage). L'ensemble des méthodes présentent dans l'interface constituera les méthodes disponibles pour le service. La classe d'implémentation contient ces même méthodes plus des méthodes permettant aux services de fonctionner (test de valeurs, transformation de paramètres etc...).  Cette classe d'implémentation contient aussi en tant qu'attribut un (ou des) délégué(s) qui sont les services d'eP-Core nécessaires aux traitement de la requête.
-=== PlateStorage ===
-Ce "pack" contient les services d'enregistrement d'informations concernant les plaques.
-  * **createVirtualPlate(IVirtualPlate vPlate)** : Créer une plaque virtuelle à partir de celle donnée en paramètre.
-  * **updateVirtualPlates(Collection<IVirtualPlate> vPlateCol)** : Met à jour les plaques virtuelles de la liste donnée en paramètre.
-==== 4. Utilisation d'XFire ====
-=== a. Configuration ===
-La configuration de XFire se fait dans le fichier xfire-servlet.xml. Le fichier de configuration de l'appli web, web.xml, et un fichier de configuration de Spring, springWSAppContext.xml, (Spring utilisé dans eP-Core) contiennent aussi des réglages nécessaires au fonctionnement de XFire.
-  * xfire-servlet.xml : il permet de configurer la servlet qu'utilise Xfire (celle-ci va recevoir les requêtes, les traiter et les transmettre au classes d'implémentation des services) et de déclarer les "nom de domaines" de chaque services.Déclaration du domaine pour le service plateServicesExporter :
-<code xml>
-<bean class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
-        <property name="urlMap">
-            <map>
-                <entry key="/PlateServices">
-                    <ref bean="plateServicesExporter"/> <!-- Le bean xfire du webservice contact -->
-                </entry>
-         </property>
- </bean>
-</code>
-Déclaration du bean du service plateServicesExporter :
-<code xml>
-<!-- plate Web services declaration -->
-    <bean id="plateServicesExporter" class="org.codehaus.xfire.spring.remoting.XFireExporter">
-        <property name="serviceFactory">
-            <ref bean="xfire.serviceFactory"/>
-        </property>
-        <property name="xfire">
-            <ref bean="xfire"/>
-        </property>
-        <property name="serviceBean">
-            <ref bean="plateServices"/> <!-- Le bean Spring déclaré dans springWSAppContext.xml -->
-        </property>
-        <property name="serviceClass">
-            <value>cea.edyp.platews.services.IPlateServices</value> <!-- L'interface du service -->
-        </property>
-    </bean>
-</code>
-  * web.xml : permet de déclarer la servlet XFire au niveau de l'appli Web et le fichier de paramêtrage du Spring d'eP-Core propre a eP-WS : Déclaration de la servlet XFire :
-<code xml>
-<!-- Xfire servlet -->
-    <servlet>
-        <!-- Servlet using the "name"-servlet.xml file for configuration -->
-        <servlet-name>xfire</servlet-name>
-        <servlet-class>
-           org.springframework.web.servlet.DispatcherServlet
-        </servlet-class>
-    </servlet>
-    <servlet-mapping>
-        <servlet-name>xfire</servlet-name>
-        <url-pattern>/*</url-pattern>
-    </servlet-mapping>
-</code>
- Déclaration des fichiers de configuration de spring :
-<code xml>
-<context-param>
-        <param-name>contextConfigLocation</param-name>
-        <param-value>
-           /WEB-INF/springWSAppContext.xml,
-           classpath:org/codehaus/xfire/spring/xfire.xml
-        </param-value>
-    </context-param>
-</code>
-  * springWSAppContext.xml : permet de déclarer dans le context Spring les beans propres aux web-services :
-<code xml>
-<bean id="plateServices" class="cea.edyp.platews.services.PlateServices">
-        <property name="delegate">
-            <ref bean="robotPlanningService"></ref> <!-- Le bean du service eP-Core utilisé comme délégué par le web-service-->
-       </property>
-</bean>
-</code>
-==== 5. Construction d'un nouveau Web-service ====
-Un web-service, avec XFire, est composé d'une interface et de sa classe d'implémentation (ex : PlateStorage et IPlateStorage). L'ensemble des méthodes présentent dans l'interface constituera les méthodes disponibles pour le service. La classe d'implémentation contient ces même méthodes plus des méthodes permettant aux services de fonctionner (test de valeurs, transformation de paramêtres etc...).  Cette classe d'implémentation contient aussi en tant qu'attribut un (ou des) délégué(s) qui sont les services d'eP-Core nécessaires aux traitement de la requête.
 Pour construire un web-service il faut donc :
   * 1/ déterminer les méthodes nécessaire à ce service.
-  * 2/ écrire l'interface du service déclarant ces méthodes.
+  * 2/ écrire l'interface du service déclarant ces méthodes dans eP-CoL !!.
   * 3/ déterminer le(s) service(s) d'eP-Core nécessaires.
-  * 4/ écrire la classe d'implémentation de ce service + les méthodes de fonctionement utile (les classes d'implem peuvent étendre de classes générique tel que PlateGenericWebServices pour les services liés aux plaques de préparation robot)
+  * 4/ écrire la classe d'implémentation de ce service (dans eP-WebServices) + les méthodes de fonctionnement utile (les classes d'implem peuvent étendre de classes générique tel que PlateGenericWebServices pour les services liés aux plaques de préparation robot)
-  * 5/ déclarer la classe d'implem comme bean spring dans le fichier de configuration springWSAppContext.xml.
+  * 5/ déclarer la classe d'implem comme bean spring dans le fichier de configuration springWSAppContext.xml Voir [[.:cxf_web-services|CXF]].
-  * 6/ déclarer le services comme bean dans xfire-servlet.xml en le liant 1)au bean spring de la classe d'implem et 2) à l'interface correspondante
+  * 6/ déclarer le services comme bean dans services.xml. Voir [[.:cxf_web-services|CXF]]
-  * 7/ déclarer le domaine du service dans xfire-servlet.xml (exemple : /PlateServices)
 Après avoir lancer l'appli il suffit d'interroger l'adresse domaine ?WSDL (ex : /PlateServices?WSDL) pour récupérer la description du services et construire une requête.

ePims

User Tools

Site Tools

Differences

Page Tools