Déploiement des Web Services
(→Liste des services disponibles) |
|||
| (4 révisions intermédiaires par un utilisateur sont masquées) | |||
| Ligne 2 : | Ligne 2 : | ||
===Documents WSDL=== | ===Documents WSDL=== | ||
| + | |||
| + | ====Liste des services disponibles==== | ||
| + | |||
| + | L'URL suivante retourne une page HTML qui recense l'ensemble des '''services métiers''' (paquets de services et requêtes) disponibles. | ||
| + | |||
| + | http://localhost/myapp/server/soap.l1000?wsdl | ||
| + | |||
| + | ====Accès au fichier WSDL d'un service==== | ||
Le serveur 1000 offre un point d’accès pour obtenir les fichiers WSDL : | Le serveur 1000 offre un point d’accès pour obtenir les fichiers WSDL : | ||
| + | Pour un paquet de service : | ||
http://localhost/myapp/server/soap.l1000?wsdl=Nom_du_paquet_de_service | http://localhost/myapp/server/soap.l1000?wsdl=Nom_du_paquet_de_service | ||
| + | |||
| + | Pour une requête publiée : | ||
| + | http://localhost/myapp/server/soap.l1000?wsdl=query.Nom_de_la_requete.drp | ||
La réponse est le document WSDL du paquet demandé ou une faute SOAP en cas d’échec. | La réponse est le document WSDL du paquet demandé ou une faute SOAP en cas d’échec. | ||
| Ligne 11 : | Ligne 23 : | ||
===Transformation des adresses de service=== | ===Transformation des adresses de service=== | ||
| − | Lorsque vous | + | Lorsque vous implémentez des Services en utilisant des Web Services il est probable que leur adresse physique dépende de la configuration du déploiement chez votre client. Par exemple un service dont l’adresse en cours de développement est http://localhost/myapp/serveur/soap.l1000 sera déployé sur un serveur de production de votre client comme http://dupontsa/comptabilite/serveur/soap.l1000 |
Cependant, pour un client WS, l’adresse du service est l’adresse contenue dans son descriptif de service (WSDL) qu’il a obtenu lors de l'importation et stocké dans le paquet métier correspondant. Il est donc nécessaire de disposer d’un mécanisme permettant de transformer les adresses des services en adresses réelles de déploiement au moment de l’exécution. | Cependant, pour un client WS, l’adresse du service est l’adresse contenue dans son descriptif de service (WSDL) qu’il a obtenu lors de l'importation et stocké dans le paquet métier correspondant. Il est donc nécessaire de disposer d’un mécanisme permettant de transformer les adresses des services en adresses réelles de déploiement au moment de l’exécution. | ||
| Ligne 18 : | Ligne 30 : | ||
===Appel d’un serveur spécifique.=== | ===Appel d’un serveur spécifique.=== | ||
| − | Dans certains cas il est possible de que vous souhaitiez | + | Dans certains cas il est possible de que vous souhaitiez appeler l’implémentation d’un serveur spécifique à la place du serveur défini dans le document WSDL ; pour cela utilisez la variable HostName définie sur les objets supportant les services distants : |
<source lang='delphi'> | <source lang='delphi'> | ||
| Ligne 43 : | Ligne 55 : | ||
===Boucle local.=== | ===Boucle local.=== | ||
| − | Si vous construisez une application métier qui expose des services métiers à travers des Web | + | Si vous construisez une application métier qui expose des services métiers à travers des Web Services il est possible que votre code métier ait besoin d’appeler ces services. Lorsque l’implémentation de ces services est présente dans le modèle métier au moment de l’appel, il peut être souhaitable d’utiliser directement cette implémentation au lieu d’effectuer un appel externe sur un serveur implémentant ce Web Service. |
===Contrôle du mode de bouclage local=== | ===Contrôle du mode de bouclage local=== | ||
| Ligne 82 : | Ligne 94 : | ||
{{#images:image25.png|Web_Services_1000}} | {{#images:image25.png|Web_Services_1000}} | ||
| − | {{info| | + | {{info|Modifiez le mode par défaut n’est utile qu’à des fins de test ; cette modification n’est pas conservée lors de l’ouverture de l’application.}} |
{{Footer|Web Services (ws)}} | {{Footer|Web Services (ws)}} | ||
[[Category:Web Services]] | [[Category:Web Services]] | ||
Version actuelle en date du 17 décembre 2009 à 17:39
Sommaire |
Documents WSDL
Liste des services disponibles
L'URL suivante retourne une page HTML qui recense l'ensemble des services métiers (paquets de services et requêtes) disponibles.
http://localhost/myapp/server/soap.l1000?wsdl
Accès au fichier WSDL d'un service
Le serveur 1000 offre un point d’accès pour obtenir les fichiers WSDL :
Pour un paquet de service :
http://localhost/myapp/server/soap.l1000?wsdl=Nom_du_paquet_de_service
Pour une requête publiée :
http://localhost/myapp/server/soap.l1000?wsdl=query.Nom_de_la_requete.drp
La réponse est le document WSDL du paquet demandé ou une faute SOAP en cas d’échec.
Transformation des adresses de service
Lorsque vous implémentez des Services en utilisant des Web Services il est probable que leur adresse physique dépende de la configuration du déploiement chez votre client. Par exemple un service dont l’adresse en cours de développement est http://localhost/myapp/serveur/soap.l1000 sera déployé sur un serveur de production de votre client comme http://dupontsa/comptabilite/serveur/soap.l1000
Cependant, pour un client WS, l’adresse du service est l’adresse contenue dans son descriptif de service (WSDL) qu’il a obtenu lors de l'importation et stocké dans le paquet métier correspondant. Il est donc nécessaire de disposer d’un mécanisme permettant de transformer les adresses des services en adresses réelles de déploiement au moment de l’exécution.
Ce mécanisme est accessible dans l’administrateur.
Appel d’un serveur spécifique.
Dans certains cas il est possible de que vous souhaitiez appeler l’implémentation d’un serveur spécifique à la place du serveur défini dans le document WSDL ; pour cela utilisez la variable HostName définie sur les objets supportant les services distants :
var inst:ICinteropService; begin inst := ICinteropService.Create; inst.HostName := 'http://marseille/comptaibilite/serveur/soap'; … end ;
Le nom de serveur que vous définissez ainsi sera utilisé à la place de l’adresse défini dans la classe de service distant ; ce nom sera toutefois transformé suivant la liste d’alias de service définie dans l’administrateur. Il est donc préférable d’écrire :
var inst:ICinteropService; begin inst := ICinteropService.Create; inst.HostName := 'Marseille'; … end ;
et de définir l’adresse de Marseille dans l’administrateur.
Boucle local.
Si vous construisez une application métier qui expose des services métiers à travers des Web Services il est possible que votre code métier ait besoin d’appeler ces services. Lorsque l’implémentation de ces services est présente dans le modèle métier au moment de l’appel, il peut être souhaitable d’utiliser directement cette implémentation au lieu d’effectuer un appel externe sur un serveur implémentant ce Web Service.
Contrôle du mode de bouclage local
Le mode de bouclage local est défini globalement pour l’ensemble des services ; il est néanmoins possible de contrôler ce mode au moment de l’appel du service.
Utilisez pour cela la variable LoopMode définie sur les objets supportant les services distants :
var inst:ICinteropService; begin inst := ICinteropService.Create; inst.LoopMode := mlmNone; … end ;
Les valeurs de LoopMode sont :
| mlmDefault | Utilise le mode de bouclage défini par défaut. |
| mlmDirect | Appel l’implémentation locale. |
| mlmSOAP | Appel l’implémentation locale en utilisant la sérialisation SOAP |
| mlmNone | N’utilise pas l’implémentation locale. |
|
Note : Le mode mlmSOAP n’est utile qu’a des fin de test de cohérence entre la sérialisation entrante et sortante. |
Il est aussi possible d’agir sur le mode de bouclage par défaut ; ouvrez le concepteur de modèle puis l’option « Préférences » :
|
|
Note : Modifiez le mode par défaut n’est utile qu’à des fins de test ; cette modification n’est pas conservée lors de l’ouverture de l’application. |
