Discussion :

[Jeweller]

Hello!
Je viens de m'appercevoir d'un problème de génération du WSDL en XMLRAD2006R2 (la derniere version "officielle") avec le binding à document.
Celui-ci ne fonctionne pas comme les versions précédentes et surtout ne fonctionne pas comme il devrait (à mon sens) puisque les fichiers xsd (schema) de chaque xmlservices ne sont pas chargés... j'ai l'impression en fait que la logique a été inversée ??
Pour corriger le problème j'ai remplacé le XMLservice "WSDL" actuel par celui de la version précédente, qui fonctionne bien, dans xmladm_dmd.pas.

Changement de comportement (sans prévenir!) ou bug ?

Michael

[Jeweller]

J'ai un autre soucis avec le WSDL généré par XMLRAD, j'en profite pour remettre ce vieux thread sur le tapis

Le TargetNameSpace n'est pas fixe, à chaque invocation du WSDL, XMLRAD génère une description avec un namespace qui correspond à l'url consommée. cf XMLAdm_dmd.pas:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
  URL := 'http://'+Context.Values['XMLC_Host']+Context.Values['XMLC_ScriptName'];
  TargetNameSpace := URL+'/wsdl';

J'ai l'impression que ca pose des problèmes lorsque que l'on consomme les WebServices depuis Visual Studio (2005 ou 2008, même combat), si l'on compile une appli à partir d'un WSDL générée depuis un serveur A, et qu'on déploie ensuite cette appli en prod sur le serveur B, il faut regénérer le WSDL et donc reconstruite le projet VS car la signature des méthodes est différente !
Pourquoi XMLRAD modifie le namespace dans son WSDL (XMLRAD 2007 semble se comporter de la même façon)?
Est ce que c'est sous VS qu'il y a une mauvaise consommation des Webservices XMLRAD ?

Qqn a t-il déjà expérimenté ce genre de chose (WebServices XMLRAD et VS)?
Merci pour vos idées,
Michael

[Jeweller]

Bon apparement ce n'est pas si simple... même avec un namespace "fixe" il y a des soucis. J'en reviens à mon premier post, pkoi le bindingstyle est -il "inversé" ? Apparement en mode rpc cela fonctionne bien, mais j'ai besoin du mode document pour inclure mes descriptions XSD de chaque XMLService pour que VS ouvre automatiquement un dataset avec le resultat (fonctionnalité qui a visiblement été dégradé depuis la 2006R2 ?) ? Est ce que c'est le mode document qui "force" en quelque sorte l'adressage des WebServices sous VS ?
Bref, quelle est la marche à suivre et quelle est la direction prise par XMLRAD2009 à ce sujet ?

Michael

[Jeweller]

Apres plusieurs heures passées avec le support de Microsoft, il s'avère que si sous VS (ou autre!!) on importe le WSDL en binding document depuis une URL http://A, le namespace attendu lors de la consommation doit être http://A... si ce n'est pas le cas, cela signifie que la signature de la méthode a changée et donc sa consommation est refusée (potentiellement pas la même car le namespace est différent!!).
XMLRAD ne permet donc pas ce mode de consommation car le namespace est dynamique (fonction de l'url invoquée).

Je propose une évolution pour XMLRAD2009: (En plus de support de VS, ce qui n'est pas [encore] le cas!).
Positionner un namespace pour le WSDL et les réponses SOAP qui soit fixe, voir paramétrable (par exemple http://schemas.xmlsoap.org/wsdl/).
De cette façon

Qu'en pensez vous ?
Michael

[Jeweller]

Même combat avec le ServiceName dans le WSDL, celui ci indexé avec le nom de l'instance de l'application XMLRAD (XMLC_InstanceName).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

definitions name="InstanceName" targetNamespace="urn:mycompagny.com/ws1" ...

Or si l'on déploie la même application sur le même serveur à deux URL différentes (une base de prod, une base de test par exemple), on aura 2 noms d'instance différents, et donc 2 WSDL différents!! Alors qu'il s'agit de la même application, c'est juste l'URL qui change, on ne devrait pas avoir ce comportement car cela oblige dans certains cas la reconstruction de l'application consommatrice.

Je propose donc pour XMLRAD2009:

• Le support des consommations par Visual Studio (gestion du XMLC_SoapEnvelopeNS)

• La création d'un paramètre XMLC_TargetNameSpace pour le WSDL et les réponses SOAP

• La création d'un paramètre XMLC_WebServiceName pour le "ServiceName" dans le WSDL

• Le support du BindingStyle=Document avec l'import des XSD dans le WSDL comme dans les versions antérieures

Michael