Plus haut niveau que les socket [JAVA] - Java - Programmation
Marsh Posté le 04-01-2005 à 09:31:18
ReplyMarsh Posté le 04-01-2005 à 09:34:01
JAXP, derrière l'un de ces 3 là (voir même derrière JCA). Mais JAXP ne te fait pas la connection.
Marsh Posté le 04-01-2005 à 09:35:58
ok bon j'y connais rien. je savais meme pas qu'on avait du soap en standard; depuis quand?
et pq ils mettent pas un proto *simple* genre xml-rpc en standard, au lieu (ou a coté) du mastodonte qu'est soap ?
Marsh Posté le 04-01-2005 à 10:13:11
ReplyMarsh Posté le 04-01-2005 à 10:30:14
tuxbleu a écrit : Ou du moins quelque chose de plus hait niveau que les sockets ? |
le plus simple en java c'est RMI ...
Marsh Posté le 04-01-2005 à 11:23:00
JAXRPC pour le rpc et JAXM pour les messages :
Citation : |
Marsh Posté le 05-01-2005 à 12:42:06
Lam's a écrit : Un truc genre javax.xml.rpc ? |
euh, me semblait bien que ct pas en standard:
http://java.sun.com/j2se/1.5.0/docs/api/
?
edit: bon, ok: http://java.sun.com/j2ee/1.4/docs/api/
Marsh Posté le 05-01-2005 à 12:47:39
>>> ben en fait, dans les packages javax.xml.rpc et sous-packages, je ne vois que des trucs jaxp et soap, rien de relatif à l'xml-rpc (le protocole, pas le nom generique, donc)
Marsh Posté le 05-01-2005 à 12:48:59
Ah, c'est du J2EE. J'avait même pas fait gaffe en fait.
De toute façon, je recommende plutôt SOAP que les XML-RPC. La spec fait 2 pages, et c'est plus ou moins le standard de nos jours...
Marsh Posté le 05-01-2005 à 12:49:33
y a des implémentations java de xml-rpc, mais c'est pas standardisé par sun, à ma connaissance ... sun est parti sur SOAP ...
Marsh Posté le 05-01-2005 à 12:50:24
c'est méchamment plus lourd pourtant; pour des trucs simplistes (la plupart des ws que j'ai vu jusqu'a present...), xml-rpc est à mon sens plus adapté, plus facile à mettre en oeuvre (autant du point de vue client que serveur)
Marsh Posté le 05-01-2005 à 12:51:26
benou a écrit : y a des implémentations java de xml-rpc, mais c'est pas standardisé par sun, à ma connaissance ... sun est parti sur SOAP ... |
comme déjà dit dans un topic-à-bide, j'aimerais exposer un meme service sous les deux protocoles, et j'avais rien trouvé qui parle de ce genre de situation...
Marsh Posté le 05-01-2005 à 12:54:34
the real moins moins a écrit : c'est méchamment plus lourd pourtant; pour des trucs simplistes (la plupart des ws que j'ai vu jusqu'a present...), xml-rpc est à mon sens plus adapté, plus facile à mettre en oeuvre (autant du point de vue client que serveur) |
Bah oui. Tout comme CORBA est un excellent standard d'objets distribués qui n'est presque plus utilisé pour démarrer un projet.
Mais c'est ni toi ni moi qui ne décidont dans ce bas monde. C'est les modes informatiques. L'évolution, c'est:
Nobody got fired for choosing IBM
Nobody got fired for choosing Windows
Nobody got fired for choosing C++
Nobody got fired for choosing Java
Nobody got fired for choosing EJB
Nobody got fired for choosing Web Services
Y a qu'à voir comment Sun se démène pour triturer les specs de J2EE pour que tout puisse être basé sur les Web Services (tout en imposant que RMI/IIOP soit le standard de communication). C'est quand même pas mal un effet de mode...
Marsh Posté le 05-01-2005 à 12:55:06
en même temps, logiquement, le protocole en lui même t'as pas à le manipuler => soap ou xmlrpc, tu t'en fous tant que tu as des couches d'abstraction correctes ...
maintenant, si tu dois faire le truc à la mano ou avec des APIs, je pense aussi que xml-rpc est plus simple à mettre en place, vu que SOAP c'est quand même un sacré bordel ...
ce qui se fait aussi bcp c'est de se mettre d'accord sur une dtd et de s'échanger du xml par http ... c'est hyper simple et ca répond à 90% des cas d'utilisation
Marsh Posté le 05-01-2005 à 12:57:32
ben le concept des web services est valide à mon avis, c'est les protocoles autour qui sont ptet pas au poil.
et si, en l'occurence c'est moi qui décide.
Marsh Posté le 05-01-2005 à 12:57:56
benou a écrit : |
Oui, je vois ça beaucoup en ce moment (depuis au moins 1 an en fait).
edit: je veux dire, ça fait au moins 1 an que ça s'est accéléré, et que la plupart des protocoles conçus à partir de 0 qu'on nous demande de manipuler (middleware dans le milieu télécom) sont du XML/HTTP.
Marsh Posté le 05-01-2005 à 13:04:04
benou a écrit : en même temps, logiquement, le protocole en lui même t'as pas à le manipuler => soap ou xmlrpc, tu t'en fous tant que tu as des couches d'abstraction correctes ... |
moi non, mais le client oui: donc si j'ai les deux >> plus de souplesse pour mon client
idem, je pense au client qui doit appeler mon service (puisqu'a la base c'est pour ça qu'on fait un service, pas juste pour faire joli au près des investisseurs
ben l'xml-rpc c'est pas plus compliqué que ça, et ça a l'avantage d'etre standardisé -> moins de problèmes de commm, moins de choses à apprendre ou à inventer (genre la maniere de documenter mon service etc)
vous l'aurez compris, je pense ici à ce que je considère comme un "vrai" [#FFFF00] web service , pour un client distant, pas un truc utilisé par ma boite en interne![/#FF0033]
Marsh Posté le 05-01-2005 à 13:07:38
mais j'ai pas réussi mon dernier effet
Marsh Posté le 05-01-2005 à 13:10:28
ben je peut te dire que la solution xml dtdisé sur de l'HTTP, c'est utilisé pour tout un tas de projets avec tout un tas de client et que ca leur/nous convient très très bien !
C'est simple, performant, bref efficace !
au contraire, dès que tu mets en place des VRAIS protocoles de web services, ca devient la merde parce qu'il faut que le client en face ait la bonne API qui soit compatible avec ton format de message et qui de plus tourne et s'interface correctement avec son système d'information, et qu'en plus les développeurs la connaisse et sachent l'utiliser.
bref, tu passes bcp plus de temps à "utiliser le standard" qu'à redévelopper une solution spécifique à ton besoin.
Le problème c'est l'intéropérabiltée
Marsh Posté le 05-01-2005 à 13:12:37
ben voilà, on en revient donc à dire que soap et consorts sont trop complexes pour ce qu'on leur demande non?
d'ou mon interet pour xml-rpc qui me semble simplissime, et que je vois difficilement comment un proto maison pour etre plus simple (mais pas necessairement plus complexe non plus hein, c vrai)
(donc en résumé le sujet de mon topic à bide c'était : "comment rendre les clients ET les investisseurs heureux sans trop me casser le cul" )
Marsh Posté le 05-01-2005 à 13:13:09
Citation : Plus haut niveau que les socket |
les chaussettes d'hiver?
(desole, j'ai pas m'en empecher, chrisbk est meme pas venu la faire )
Marsh Posté le 05-01-2005 à 13:17:15
benou a écrit : ben je peut te dire que la solution xml dtdisé sur de l'HTTP, c'est utilisé pour tout un tas de projets avec tout un tas de client et que ca leur/nous convient très très bien ! |
Enfin, avec un xsd. Parce qu'une dtd, ça fait un peu "étudiant"
Ceci-dit, en suivant ce concept, tu perds la standardisation qui fait que n'importe quelle API serait capable de parser un message SOAP avec une faute dans l'enveloppe. Tu ne définis pas non plus la sémantique en cas de perte de connexion, etc. Ni comment bootstrapper le service. Bref, c'est sympa, mais il manque quand même de petites choses...
Marsh Posté le 05-01-2005 à 13:17:36
the real moins moins a écrit : ben voilà, on en revient donc à dire que soap et consorts sont trop complexes pour ce qu'on leur demande non? |
ouais, xml-rpc c'est (beaucoup!) plus simple que SOAP, mais un xml spécifique à tes besoins c'est encore plus simple que xml-rpc
et puis xmlrpc c'est pour du rpc à la base. La plupart du temps, le besoin c'est plus de l'échange d'info (plus ou moins volumineuse et verbeuse) sous forme de Q/R => plutot des "messages" que des "appels de methodes" si tu vois la nuance ...
Marsh Posté le 05-01-2005 à 13:19:01
dans mon cas c'est un vrai besoin d'appel de methode
(genre donne moi les bidules qui correspondent au client X)
Marsh Posté le 05-01-2005 à 13:20:19
Lam's a écrit : Ceci-dit, en suivant ce concept, tu perds la standardisation qui fait que n'importe quelle API serait capable de parser un message SOAP avec une faute dans l'enveloppe. Tu ne définis pas non plus la sémantique en cas de perte de connexion, etc. Ni comment bootstrapper le service. Bref, c'est sympa, mais il manque quand même de petites choses... |
comme je disais, ca couvre 90% des besoins ... les trucs dont tu parles sont plutôt rares, et de plus très couteux à mettre en place !!
Et tu as encore le problême de l'intéropérabilité : la gestion des transactions SOAP, et toutes ces fonctions avancées, c'est encore loin d'être les doigts dans le nez sur toutes les plateformes !!!
Marsh Posté le 05-01-2005 à 16:42:19
Lam's a écrit : Enfin, avec un xsd. Parce qu'une dtd, ça fait un peu "étudiant" |
L'"étudiant" signale qu'il connait toute une chiée d'IDE qui permettent le clic droit --> generate XML schema / RelaxNG / DTD ...
il dit que meme à la fac on utilise plus les DTD
Marsh Posté le 05-01-2005 à 16:45:04
Jubijub a écrit : L'"étudiant" signale qu'il connait toute une chiée d'IDE qui permettent le clic droit --> generate XML schema / RelaxNG / DTD ... |
c'tait une blague (et même pas addressée aux étudiants qui trainent ici).
On va dire que ça fait old-skool, genre: "je fais des web services en cobol, moi monsieur".
Marsh Posté le 05-01-2005 à 16:46:46
Lam's a écrit : c'tait une blague (et même pas addressée aux étudiants qui trainent ici). |
ouais, ben en tant que porte parole des codeurs de cobol, je m'insurge, voila
Marsh Posté le 05-01-2005 à 16:47:18
Reply
Marsh Posté le 04-01-2005 à 09:28:10
J'ai un programme que j'ai programmé en socket.
Vous connaissez une sorte de Corba en Java ?
Ou du moins quelque chose de plus hait niveau que les sockets ?
merci d'avance.
tuxbleu