Déploiement des Web Services
m (a renommé Developpement:WebService6 en Déploiement des Web Services (ws)) |
|||
Ligne 1 : | Ligne 1 : | ||
{{#customtitle:Déploiement des Web Services}} | {{#customtitle:Déploiement des Web Services}} | ||
− | = | + | ===Documents WSDL=== |
− | + | ||
− | ==Documents WSDL== | + | |
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 : | ||
− | http://localhost/myapp/server/soap.l1000?wsdl=Nom_du_paquet_de_service | + | http://localhost/myapp/server/soap.l1000?wsdl=Nom_du_paquet_de_service |
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. | ||
− | ==Transformation des adresses de service== | + | ===Transformation des adresses de service=== |
Lorsque vous implémenter 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 | Lorsque vous implémenter 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, l’adresse du service est l’adresse contenue dans son descriptif de service (WSDL) qu’il a obtenu lors de | + | 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. | Ce mécanisme est accessible dans l’administrateur. | ||
− | ==Appel d’un serveur spécifique.== | + | ===Appel d’un serveur spécifique.=== |
+ | Dans certains cas il est possible de que vous souhaitiez appelé 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'> | |
− | + | ||
− | < | + | |
var inst:ICinteropService; | var inst:ICinteropService; | ||
begin | begin | ||
inst := ICinteropService.Create; | inst := ICinteropService.Create; | ||
− | inst.HostName := | + | inst.HostName := 'http://marseille/comptaibilite/serveur/soap'; |
… | … | ||
end ; | end ; | ||
− | </ | + | </source> |
− | 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 | + | 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 : |
− | < | + | <source lang='delphi'> |
var inst:ICinteropService; | var inst:ICinteropService; | ||
begin | begin | ||
inst := ICinteropService.Create; | inst := ICinteropService.Create; | ||
− | inst.HostName := | + | inst.HostName := 'Marseille'; |
… | … | ||
end ; | end ; | ||
− | </ | + | </source> |
et de définir l’adresse de Marseille dans l’administrateur. | et de définir l’adresse de Marseille dans l’administrateur. | ||
− | ==Boucle local.== | + | ===Boucle local.=== |
− | + | ||
Si vous construisez une application métier qui expose des services métiers à travers des Web Service 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. | Si vous construisez une application métier qui expose des services métiers à travers des Web Service 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=== |
− | + | ||
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. | 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 : | Utilisez pour cela la variable LoopMode définie sur les objets supportant les services distants : | ||
− | < | + | <source lang='delphi'> |
var inst:ICinteropService; | var inst:ICinteropService; | ||
begin | begin | ||
Ligne 62 : | Ligne 57 : | ||
… | … | ||
end ; | end ; | ||
− | </ | + | </source> |
Les valeurs de LoopMode sont : | Les valeurs de LoopMode sont : | ||
+ | |||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
Ligne 80 : | Ligne 76 : | ||
|} | |} | ||
− | + | {{info|Le mode mlmSOAP n’est utile qu’a des fin de test de cohérence entre la sérialisation entrante et sortante.}} | |
− | { | + | |
− | + | ||
− | + | ||
− | |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 » : | 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 » : | ||
{{#images:image25.png|Web_Services_1000}} | {{#images:image25.png|Web_Services_1000}} | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | {{ | + | {{info|Modifier le mode par défaut n’est utile qu’a des fins de test ; cette modification n’est pas conservée lors de l’ouverture de l’application.}} |
− | [[Category: | + | {{Footer|Web Services (ws)}} |
+ | [[Category:Web Services]] |
Version du 22 août 2009 à 08:59
Sommaire |
Documents WSDL
Le serveur 1000 offre un point d’accès pour obtenir les fichiers WSDL :
http://localhost/myapp/server/soap.l1000?wsdl=Nom_du_paquet_de_service
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émenter 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 appelé 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 Service 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 : Modifier le mode par défaut n’est utile qu’a des fins de test ; cette modification n’est pas conservée lors de l’ouverture de l’application. |