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

Dispo en standard: RMI, SOAP, CORBA.
 

jaxp aussi non?

JAXP, derrière l'un de ces 3 là (voir même derrière JCA). Mais JAXP ne te fait pas la connection.  
 

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 ?

Un truc genre javax.xml.rpc ?

nan?

le plus simple en java c'est RMI ...

JAXRPC pour le rpc et JAXM pour les messages :
 

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/

>>> 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)

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...

y a des implémentations java de xml-rpc, mais c'est pas standardisé par sun, à ma connaissance ... sun est parti sur SOAP ...

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)

 
 
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...

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...
 
   

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

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.

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.

 
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]
 
 
 
 

tres joli

mais j'ai pas réussi mon dernier effet

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

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" )

 
 les chaussettes d'hiver?  
 
(desole, j'ai pas m'en empecher, chrisbk est meme pas venu la faire )

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...

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 ...

dans mon cas c'est un vrai besoin d'appel de methode
(genre donne moi les bidules qui correspondent au client X)

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 !!!

 
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
 
 

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".

 
 
ouais, ben en tant que porte parole des codeurs de cobol, je m'insurge, voila

vous savez ce qu'elles vous disent mes DTD