User Tools

Site Tools


wiki:epims4_0:developer:ep-webservices

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
wiki:epims4_0:developer:ep-webservices [2008/03/25 10:23]
barthe
wiki:epims4_0:developer:ep-webservices [2009/06/08 14:38] (current)
Line 1: Line 1:
-====== ​[/!\En cours]Guide d'​implémentation d'​eP-WebServices ======+====== Guide d'​implémentation d'​eP-WebServices ======
  
 ===== 1. Introduction ===== ===== 1. Introduction =====
  
 eP-WebServices est le module permettant l'​accès à eP-Core à l'aide de web-services. Cela permet à des application externes (eP-Back par exemple) d'​interroger eP-Core en utilisant des requêtes HTTP contenant du XML. De ce fait on peut ouvrir à "​l'​extérieur"​ certaines fonctionnalités bien précises d'​eP-Core. eP-WebServices est le module permettant l'​accès à eP-Core à l'aide de web-services. Cela permet à des application externes (eP-Back par exemple) d'​interroger eP-Core en utilisant des requêtes HTTP contenant du XML. De ce fait on peut ouvrir à "​l'​extérieur"​ certaines fonctionnalités bien précises d'​eP-Core.
 +
  
 ===== 2. Technologies ===== ===== 2. Technologies =====
 +\\
  
-Figure 1 : Schématisation du fonctionnement des web-services. 1/ Le fournisseur fournit un document au format WSDL permettant de décrire le service proposé (adresse, arguments acceptés en entrée, type de retour etc…). 2/ Le client interroge le diffuseur afin de récupérer la description du service. ​ 3/ Après avoir construit sa requête selon le schéma demandé le client l’envoie au fournisseur du service qui traite la demande et réexpédie la réponse.+{{ epws_general.png }}
  
-La technologies utilisée pour implémenter les web-services est XFire (version 1.2.6). Cette librairie permet de générer automatiquement les documents WSDL et de gérer les services à partir de la classe ​d'implémentation du service (et de son interface).+>> **Figure 1** : Schématisation du fonctionnement des web-services.  
 +>> ​ - 1/ Le fournisseur fournit un document au format WSDL permettant de décrire le service proposé (adresse, arguments acceptés en entrée, type de retour etc…).  
 +>> ​ - 2/ Le client interroge le diffuseur afin de récupérer la description du service. ​  
 +>> ​ - 3/ Après avoir construit sa requête selon le schéma demandé le client l’envoie au fournisseur du service qui traite la demande et réexpédie la réponse. 
 + 
 + 
 +La technologies utilisée pour implémenter les web-services est CXFPour plus d'information sur cette librairie ​et son utilisation,​ se reporter au chapitre [[.:​cxf_web-services|suivant]] ​
  
 ===== 3.  Architecture ===== ===== 3.  Architecture =====
Line 15: Line 23:
 Cette section décrit l’organisation des packages ainsi que les points d’interaction entre eP-WebServices et eP-Core. 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 }}
  
-Figure 2 : Fonctionnement d'​eP-webservices (eP-WS). - eP-WS fonctionne comme un fournisseur de web-services normal (voir figure 1)  sauf qu'il intègre la notion de diffuseur et qu'il délègue le traitement de la requête à eP-Core. - eP-WS est donc un intermédiaire entre un utilisateur extérieur et eP-Core :il reçoit la requête SOAP, la décode, la transmet à eP-Core qui lui renvoie la réponse. eP-WS traite celle-ci en la modifiant au besoin et en la codant en SOAP, puis il l'​envoie à l'​utilisateur.+>> **Figure 2** : Fonctionnement d'​eP-webservices (eP-WS). ​ 
 +>> ​- eP-WS fonctionne comme un fournisseur de web-services normal (voir figure 1)  sauf qu'il intègre la notion de diffuseur et qu'il délègue le traitement de la requête à eP-Core. ​ 
 +>> ​- eP-WS est donc un intermédiaire entre un utilisateur extérieur et eP-Core :il reçoit la requête SOAP, la décode, la transmet à eP-Core qui lui renvoie la réponse. eP-WS traite celle-ci en la modifiant au besoin et en la codant en SOAP, puis il l'​envoie à l'​utilisateur.
  
-==== 2.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-WebServices ====
  
-Ce module contient 4 packages ​  En gros model, ​services, ​exception, test    ​+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: 
 +  * 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 webcontenant également la définition pour [[ cxf_web-services|CXF]]
  
  
-  * 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...). +=== et eP-CoL  ===
-  * 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 objets du package exception représentent les exceptions spécifiques à eP-WS. +
-  * Les objets du package test représentent les classes de tests d'​eP-WS.+
  
 +Pour la partie communication,​ eP-WebServices utilise la librairie [[ep-col|eP-CoL]]. Cette librairie définit
 +    * 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 interfaces des services qui sont proposés par eP-WebServices  ​
  
-==== 3. Utilisation d'​XFire ==== 
  
-=== aConfiguration ===+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.
  
-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.+eP-WebServices étends ''​IComVirtualPlate''​ d'eP-CoL afin d'​ajouter les fonctionnalités d'​ajout et de supression d'​échantillons.
  
-  * 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 : +==== implémentation ====
-<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 : +Ce paragraphe décrit les spécificités au niveau implémentation des objets et services ​définit ​dans eP-CoL.
-<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 :  +__''​IVirtualPlate & VirtualPlate''​ : Classes représentant des plaques virtuelles.__  
-<code xml> +:!: 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 RobotSampleCes 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.
-<!-- 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>​ 
  
-==== 4. Construction d'un nouveau Web-service ====+===== 4. 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.+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.
  
 Pour construire un web-service il faut donc : Pour construire un web-service il faut donc :
   * 1/ déterminer les méthodes nécessaire à ce service.   * 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.   * 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. 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.
 +
wiki/epims4_0/developer/ep-webservices.1206437016.txt.gz · Last modified: 2008/09/24 15:35 (external edit)