[WebServices][axis] question sur la méthode service()

Peut-on charger n'importe quel type de Web Service avec la méthode :

ex:

Code:

---

1 2 3 4 5

Service service = new Service( new URL("http://localhost:8080/wsdl/echo.wsdl"), new QName("Calculatrice") );

---

axis gére les web services de type *.jws mais qu'en est-il pour les services .Net ?

peut-on par exemple l'utiliser dans le cas d'un service .Net :

Code:

---

1 2 3 4 5

Service service = new Service( new URL("http://localhost/WebTest/Service1.asmx?wsdl"), new QName("Service1Soap") );

---

Salut,

il te faut une "souche cliente" pour invoquer un service web. Axis a une classe utiltaire pour generer cette souche a partir du .wsdl.

Ce qui est important pour deploiement, c'est le .wsdl et non pas le .jws ou le .net. Le .jws est juste une facilite pour le deploiement et la generation du .wsdl.

Une souche cliente ? çà ne serait pas avec l'utilitaire WSDL2Java par hasard ?.

On ne peut pas juste dans une classe java déclarer un service avec son URL et son QName pour l'utiliser, il faut obligatoirement générer un stub client ?

Citation:

---

Une souche cliente ? çà ne serait pas avec l'utilitaire WSDL2Java par hasard ?.

---

oui, cette classe te permet, notamment, de generer une API a partir des types definis dans le .wsdl.
Comment est-ce que tu comptes, par exemple, exploiter le resultat de retour de ton service?

Comme un EJB en fait, je compte récupérer l'interface du service Web et appeler les méthodes de cette interface. mais je ne connais pas encore le moyen de faire çà dynamiquement sans passer par WSDL2Java.

il y a 3 méthodes pour invoquer un WS
- les stubs (autogénérés en générale)
- les "proxy ..." je sais plukoi, dsolé ca va me revenir
- les proxy dynamiques DII

je ne sais plus si Axis gere les 2 derniers, je pense oui à 90%!

Citation:

---

les stubs (autogénérés en générale)

---

je n'ai teste que la premiere facon.

Citation:

---

Comme un EJB en fait, je compte récupérer l'interface du service Web et appeler les méthodes de cette interface

---

Quand tu implementes un client d'EJB, avoir les souches "clients", ne suffit pas. Si une methode distante renvoie un type Toto, il faut, cote client, avoir la defitition de cette classe.

Citation:

---

- les "proxy ..." je sais plukoi, dsolé ca va me revenir
- les proxy dynamiques DII

---

Ca m'interesse aussi, est-ce que cela veut dire que tu peux :
passer par un annuaire
invoquer le service que tu veux
et interpreter le resultat?

Je ne vois pas comment exploiter, cote java, des resultats, qui peuvent etre de type complexe et seulement decrit dans le .wsdl

topo sur l'invocation de services web :

2.3 L’invocation des services
Une fois le fournisseur de services choisi, il reste au client à effectuer l’invocation de ce fournisseur afin d’obtenir le service souhaité. Il existe deux types d’invocation : l’invocation statique et l’invocation dynamique. Pour utiliser un service, un client choisit l’un ou l’autre de ces deux types d’invocation.

2.3.1 L’invocation statique
Lorsque le client d’un service utilise l’invocation statique il doit posséder la souche du service en question. Les plates-formes J2EE, CORBA et DCOM mettent à disposition de tels mécanismes avec, respectivement, les RMI, Remote Method Interface [RMI98], les SII Statique Invocation Interface et les RPC-DCE, Distributed Computing Environment - Remote Procedure Call. L’accès aux Services Web est réalisé en utilisant des protocoles d’échange de messages fonctionnant au-dessus de HTTP, comme par exemple SOAP [MGH+01] ou XML-RPC [XML03]. Comme avec les mécanismes d’invocation cités ci-dessus, le client doit posséder la souche du service. Cette souche est nécessaire pour encapsuler la requête dans le format attendu par le service. L’utilisation de l’invocation statique oblige le client à posséder la souche du fournisseur qu’il invoque. Un client peut être amené à utiliser un grand nombre de services. Il doit alors stocker un grand nombre de souches, ce qui peut être pénalisant pour des clients légers, à faible capacité de stockage. Tout en utilisant l’invocation statique, il est possible de résoudre ce problème de stockage. Ainsi, la plate-forme J2EE permet d’aller dynamiquement, à l’exécution, rechercher sur le réseau, les classes nécessaires à l’invocation du fournisseur. Pour utiliser cette solution le client doit connaître l’adresse à laquelle se trouve ces classes. Quant à elle, la plate-forme JINI propose plusieurs types d’interactions client-service, suivant le contexte d’utilisation du service. Soit le code du service est téléchargeable et exécutable par le client, alors une copie du service est transmise au client et celui-ci l’utilise en local. Soit, si ce n’est pas le cas, le Lookup service de JINI fournit la souche au client. Les invocations peuvent alors être effectuées statiquement. Sur le même modèle, la plate-forme Salutation propose un Driver Manager auquel les clients peuvent faire appel, pour obtenir les drivers d’un service.

2.3.2 L’invocation dynamique
Ce type d’invocation permet à un client d’invoquer un service même s’il ne possède pas la souche du service. Le client peut alors instancier une requête générique en positionnant lui-mëme les paramètres dans la requête, ce qui lui évite de posséder la souche générant une requête spécifique. De la même façon qu’elles proposent des mécanismes d’invocation statique, les plates-formes Java, CORBA et DCOM proposent des mécanismes d’invocation dynamique qui sont respectivement les RMI Dynamic, les DII Dynamic Invocation Interface et l’Automation Service.
L’invocation dynamique peut être vue comme une solution au problème de stockage évoqué pour l’invocation statique puisqu’elle permet d’invoquer un fournisseur sans en posséder le fichier souche. Mais ce type d’invocation est plus complexe à mettre en oeuvre et plus lourd du point de vue des traitements nécessaires à sa réalisation que l’invocation statique, ce qui peut être pénalisant pour des clients à faible capacité de traitement.

http://lifc.univ-fcomte.fr/publis/pub/2004/RR2004-07.pdf

Nycos62> attention les WS ne sont pas des objets distribués (passage par valeur, pas par référence). La comparaison avec Corba, rmi, ... peut être trompeuse

Pour répondre à tes questions
1) l'interopérabilité avec .net est réglée depuis Axis (ancienment ApacheSoap), surtout si tu utilise le style "doc-litteral" par opposition à "rpc-encoded"

2) a propos des types d'invoquation:

Citation:

---

JAX-RPC defines one static model and two dynamic models for the client side to invoke a remote procedure. In the static model, stubs are used and the code-generation tools generate the stubs. One dynamic model is based on generating a proxy object dynamically using java reflection APIs and another is based on Dynamic Invocation an Interface (DII) using the Call object.

---

Sachant que le modele a base de réflexion n'est jamais utilisé en dehors de tests...

3) l'invocation dynamique n'est gérée qu'à moitiée par Axis: tourne toi plutot vers WSIF qui gère correctement le mapping des beans

Je m'avance peut-être un peu vite mais apparement WSIF ne permet pas de récupérer dynamiquement un objet interface par le quel on peut utiliser le WebService.

Il permet juste d'utiliser directement une méthode d'un Service Web :

type simple

Code:

---

java clients.DynamicInvoker samples/simpleSOAP.wsdl getQuote IBM

---

ce code sert à invoquer la méthode getQuote du service simpleSOAP d'IBM.

type complexe

Code:

---

java complexsoap.client.dynamic.Run samples/complexsoap/Zip2Geo.wsdl 10005

---

ce code permet d'invoquer le service Zip2Geo qui à partir d'un "Zip code" renvoie la ville, le pays, la longitude, la latitude...

:?

a ma connaissance, il n'existe que la classe WSDL2Java qui crée un stub interface sur le disque et non un objet interface directement en mémoire :cry: