Re: Client / Serveur, ou en sommes-nous ?
Presque. Tu crees juste une instance d'Echange dans Local1 ;-) Non , en fait dans local 1, Registry .bind est un dynamic proxy qui simule l'interface Echange et qui fait le Marshall/unMarshall Donc un réel Appel distribué on passe par HTTP Je parlais de ces deux lignes qui ne devraient pas etre dans Local1. // publish an instance of Exchange Registry.publish( exchange, new Exchange() ); Merci pour l'exemple. Effectivement c'est simple. Mais ce n'est pas multi-langage. Si bien sur !! mais ce n'est pas clair dans l'example que j'ai posté trois seconde avant de prendre train désolé en fait le serveur publie le service sur l'URL http://localhost:8004/glue/echange; , mais il publie aussi le wsdl!! dans un autre url (http://localhost:8004/glue/echange; l'équivalent de l'IDL) D'accord. Je ne savais pas que le WSDL etait genere. Mecri. Guillaume
Re: Client / Serveur, ou en sommes-nous ?
Guillaume Desnoix wrote: Presque. Tu crees juste une instance d'Echange dans Local1 ;-) Non , en fait dans local 1, Registry .bind est un dynamic proxy qui simule l'interface Echange et qui fait le Marshall/unMarshall Donc un réel Appel distribué on passe par HTTP Je parlais de ces deux lignes qui ne devraient pas etre dans Local1. // publish an instance of Exchange Registry.publish( exchange, new Exchange() ); désolé(je me disais aussi...) Merci pour l'exemple. Effectivement c'est simple. Mais ce n'est pas multi-langage. Si bien sur !! mais ce n'est pas clair dans l'example que j'ai posté trois seconde avant de prendre train désolé en fait le serveur publie le service sur l'URL http://localhost:8004/glue/echange; , mais il publie aussi le wsdl!! dans un autre url (http://localhost:8004/glue/echange; l'équivalent de l'IDL) D'accord. Je ne savais pas que le WSDL etait genere. Mecri. Guillaume
Re: Client / Serveur, ou en sommes-nous ?
Guillaume Desnoix wrote:
marc wrote:
Enfin je crois
Presque. Tu crees juste une instance d'Echange dans Local1 ;-)
Non , en fait dans local 1, Registry .bind est un dynamic proxy qui
simule l'interface Echange et qui fait le Marshall/unMarshall
Donc un réel Appel distribué on passe par HTTP
Merci pour l'exemple. Effectivement c'est simple. Mais ce n'est pas
multi-langage.
Si bien sur !! mais ce n'est pas clair dans l'example que j'ai posté
trois seconde avant de prendre train désolé
en fait le serveur publie le service sur l'URL
http://localhost:8004/glue/echange; , mais il publie aussi le wsdl!!
dans un autre url (http://localhost:8004/glue/echange; l'équivalent de
l'IDL)
et donc après tu peut ecrire un client dans n'importe quel language qui
supporte SOAP attaquant l'url de ce service
python perl, C#, C++ et le reste !! en générant stub et skeleton, ou en
réalisant un invocation dynamique( exactelment comme en corba)
en fait en python tu peut aussi faire
une ligne du type(je n'ai pas d'example excat sous la main )
server=soapserver(http://localhost:8004/glue/echange.wsdl;)
server.getRate(fr,us)
c'est aussi simple !!!
Alors voici le meme en Corba (sachant que Dodico est notre equivalent
a Glue, une lib qui factorise le code d'initialisation). Pas beaucoup
plus complique ?
/* IDL */
interface IExchange {
float getRate(string country1,string country2);
};
/* JAVA */
public class Exchange extends IExchangeImpl
{
public float getRate(String country1, String country2) {
return 122.69f;
}
}
public class Publish1 {
public static void main(String[] args) {
CDodico.bind(exchange,new Exchange());
}
}
public class Local1 {
IExchange exchange=IExhangeHelper.narrow
(CDodico.find(exchange));
System.out.println(exchange.getRate(usa,japan);
}
Guillaume
Re: Client / Serveur, ou en sommes-nous ?
Prend Soap avec Axis c'est vraiment cool, c'est type. Tu sais envoye des objects et recevoir des ojects java. Avec soap tu ecrit ton object serveur, avec des methods, qui ont des parametres natif, collection, array, what ever. Et tu les appelles de facon transparente ! Les objects peuvent etres evolué, polymorphique etc Si par ex dans ton service tu a un object Range et un Object ExtRange une fonction add(Range aRange ) Si tu l'appelle via soap, le serveur recevera le bon type d'object ! Si il y avait un Map d'object, idem etc Dominique |-+- | | Herve AGNOUX | | | herve.agnoux@diaam-inform| | | atique.com | | | | | | 22/11/2002 09:52 | | | Please respond to java| | | | |-+- ---| | | | To: [EMAIL PROTECTED] | | cc: (bcc: Dominique Gallot/BRU/MASTERCARD) | | Subject: Re: Client / Serveur, ou en sommes-nous ? | ---| Le Jeudi 21 Novembre 2002 18:52, jerome moliere a écrit : si cela interesse quelqu'un je la lmettrai en ligne sur mon pauvre site :) [...] Si jamais tu le fais, préviens moi, je ferai une annonce sur xml-tech, où beaucoup de gens s'intéressent à SOAP (et si tu n'y vois pas d'inconvénients, bien sûr). Depuis quelques temps, je m'implique plus sur http://xmlfr.org, que tu connais peut être. J'essairai d'y faire un compte-rendu de cette discussion, s'il continue d'y avoir des choses concernant SOAP et XML. Avec un CC sur java@, bien sûr. En attendant, la solution prudente pour moi semble être CORBA ? J'y connais rien, cela vaut le coup ? La facilité affichée des Web Services ne serait qu'apparente ? RMI doit être rejeté définitivement ? Je précise que je n'ai pas besoin de transférer des centaines de mega-octets à 150.000 connexions simultanées ! Il s'agit d'un dialogue type administration, pour piloter à distance un proxy (à distance signifie en général par une fenêtre située sur le même PC que le proxy). Il peut y avoir des objets moyennements élaborés (c'est vrai que s'il faut que je convertisse tout en chaîne de caractères ou en XML c'est un peu chiant, mais faisable), et il peut aussi y a voir des listes (type tableau excel), de l'ordre du megaoctet (en mode non-verbeux). L'important, c'est la fiabilité, puisque c'est de l'administration. A+. -- SARL diaam informatique - 04 50 77 12 60 Ingenierie, développements de systèmes d'information http://www.diaam-informatique.com
Re: Client / Serveur, ou en sommes-nous ?
Cedric Beust wrote: jerome moliere wrote: mon avis personnel est que CORBA reste la norme la plus aboutie , En Europe, oui. Aux USA, CORBA est inexistant. Corba donne de la performance certe mais en contrepartie est relativement complexe d'utilisation Dans bien 80% des application distribuées que j'ai pu rencontré il est bien plus utilisé en dessous de son cadre de fonctionalité c'est a dire comme un si:mple RPC et parfois même la contrainte de performance n'est même pas importante Dans ce cadre SOAP est une execlente alternative ! je pense que CORBA ne devrait être utilisé que dans des produit logicile lourdement distribué, et ayant des contrainte de securité, transaction ou autre service la plus fiable et la plus utilisable, même si c'est pas toujours trivial a coder (le POA est un joli joujou :)) J'ai fait un test de SOAP, on en reparlera dans 4/5 ans, pour l'instant : Uh, tu es serieux ? D'accord, les Web Services restent encore une technique de pointe, mais on a de plus en plus de clients qui se lancent dedans. C'est a ce jour la solution la plus prometteuse pour l'integration. Je suivrai ici cedric , nous utilisons GLUE de themindelectric, le produit est nettement plus performant que axis(regarder leur benchmark !!), j'ai aussi d'autre comparatif qui donne ce produit comme aussi rapide que .NET d'autre part il est très facile a utiliser dans des cas simple, et gratuit dans un grand nombre d'application commerciale, et ce qui ne gache rien possede une bonne documetation *Pour avoir tester differente implmementation de SOAP voici mes different commentaires: -Axis : immature peu performant mal documenté -WASP produit enorme difficile a mettre en, oeuvre mais reste un concurrnet serieux, grace a son extensibilté possibilté d'implemeter soap sur d'autre protocole,passage par reference -GLUE le meilleur compromis que j'ai trouvé en terme de performance et de souplesse d'utilisation -pySOAP et sa lib perl concurrente interresante implementation mais laissant a desirer enbter me de maturité -JAX-RPC je'n parle en dernier car pour moi , c'est une vrai deception ce produit n'est pas du tous au niveau de produit comme WASP ou GLUE en terme de souplesse et de documentation et je dirai quel dommage - en general, inutilisable car trop verbeux, sur mon test SOAP transporte 3 fois plus de données qu'une solution XML a base de Castor JDO, 10 fois plus qu'une serialisation Java... bref en termes de perf c'est 10 fois plus lent que du http/XML en Java... Ce n'est pas parce qu'il transporte dix fois plus d'octets qu'il est dix fois plus lent. La pratique montre que pour les paquets habituellement echanges, cette surcharge est negligeable comparee aux autres goulets d'etranglement. Si tu veux te faire une idee plus precise (et objective ;-)), je te suggere de jeter un coup d'oeil aux API offertes par Amazon et Google, c'est un joujou sympa pour se faire les dents sur les Web Services. Pour en revenir a hervé je lui conseillerai de jeter un coup d'oeil sur GLUE et sa doc, pour una application d'admin Glue me semble IDEAL
Re: Client / Serveur, ou en sommes-nous ?
Cedric Beust [EMAIL PROTECTED] writes: | - en general, inutilisable car trop verbeux, sur mon test SOAP | transporte 3 fois plus de données qu'une solution XML a base de | Castor JDO, 10 fois plus qu'une serialisation Java... | bref en termes de perf c'est 10 fois plus lent que du http/XML en | Java... | | Ce n'est pas parce qu'il transporte dix fois plus d'octets qu'il est | dix fois plus lent. La pratique montre que pour les paquets | habituellement echanges, cette surcharge est negligeable comparee aux | autres goulets d'etranglement. Je suis d'accord que les arguments de volume de données ne sont pas très pertinents, mais pour ma part, je trouve ce standard SOAP inutilement complexe: o Je ne connais aucune implémentation de l'ensemble de la spec. On ne peut même pas compter sur tous les types primitifs. o Certaines fonctionnalités sont stupides, je pense en particulier aux paramètres in/out ou aux sparse arrays. Tout cela conduit à une interopérabilité douteuse. Il me semble que XML RPC est une solution nettement plus réaliste. -- Michel CASABIANCA
RE: Client / Serveur, ou en sommes-nous ?
Title: RE: Client / Serveur, ou en sommes-nous ? Salut ! Tout cela conduit à une interopérabilité douteuse. Il me semble que XML RPC est une solution nettement plus réaliste. Oui, enfin, tout dépend du volume du retour. En utilisant la norme préconisée par le site www.xmlrpc.com, avec une connexion par socket, une requête retournant 2000 lignes d'environ 10 colonnes mettait plus de 10 secondes à s'afficher du côté client. Certes, c'était sans optimisation, avec un parser pour Visual Basic, et mes connaissance très limitées en XML, mais il faut pas être devin pour savoir que leur description très verbeuse n'est pas adaptée à des volumes importants et qu'une flux de plusieurs Megs ne sera pas rapide à analyser. Donc, on a été obligés de passer à des choses plus bestiales mais beaucoup plus rapides. Cependant, j'ai entendu parler de projets d'optimisation matérielle liée à des flux XML (compression/décompression dans les couches basses). L'avenir peut être meilleur. Olivier -- Michel CASABIANCA
Re: Client / Serveur, ou en sommes-nous ?
OLIVIER CAYRON [EMAIL PROTECTED] writes: | Tout cela conduit à une interopérabilité douteuse. Il me semble que | XML RPC est une solution nettement plus réaliste. | | Oui, enfin, tout dépend du volume du retour. En utilisant la | norme préconisée par le site www.xmlrpc.com, avec une connexion | par socket, une requête retournant 2000 lignes d'environ 10 | colonnes mettait plus de 10 secondes à s'afficher du côté client. Il est clair que XML RPC n'est pas adapté à cette utilisation. -- Michel CASABIANCA
Re: Client / Serveur, ou en sommes-nous ?
Guillaume Desnoix wrote: marc: Corba est relativement complexe d'utilisation Disons qu'il faut 2-3 jours pour comprendre le principe si on part de zero Tu est cour , les POA c'est quand même un poco complexe, et comprendre tous les services annexe Sécurité, transaction,IIOP et le reste voir la norme ! ca prend nettement plus de 2 jours (enfin pour moi) Sauf bien sur si on l' utilise comme un simple RPC . Corba, dans son utilisation premiere, n'est pas complexe en Java, les Holders c'est super propre et intuitifs moi je trouve pas trop, la gestion des erreur un peu plus en C++, penible en C (et autres langages non OO) et franchement ultra-simple en Python, Perl, ... Sauf a faire du pur C, SOAP est plus complexe. Toutefois, on devrait voir arriver progressivement de bons outils qui genereront tout ce qu'il faut pour que ce soit (presque) transparent (en gros comme Corba). ces outils existe déja et je t'ai même cité une liste !!! et la je te rejoint sur le fait que certaine implemention ne sont pas a maturité est était bien plus complexe a utilisé que Corba en simple RPC En fait je crois vraiment que certaines implementation de SOAP on vraiment nuit a ce standard il n'y a qu'a voir voir votre agressivité sur ce standard !!! Le seul et unique avantage de SOAP est qu'il passe les parefeux mal configures. Et qu'il beneficie de certains materiels comme les repartiteurs de charge http. En gros, c'est pourri comme protocole mais ca s'integre bien dans une architecture web. C'est donc a reserver a cette usage. Dans bien 80% des application distribuées que j'ai pu rencontré il est bien plus utilisé en dessous de son cadre de fonctionalité Ca, c'est de l'argument ! , J'essaye juste d'argumenter avec l'experience que j'ai des middleware(et je crois sincèrement pouvoir dire que j'en ai une) guillaume maintenant si tu juge que ce n'est pas un argument peut être a tu raison , a près tous a moi il ma fallu plus de 2jours pour comprendre(du moins essayer ) CORBA A+ marc Guillaume PS: Pour Herve, tu as une introduction a Corba dans le numero (1) de novembre du magazine L'Informaticien.
Re: Client / Serveur, ou en sommes-nous ?
Disons qu'il faut 2-3 jours pour comprendre le principe si on part de zero Tu est cour , les POA c'est quand même un poco complexe, et comprendre tous les services annexe Sécurité, transaction,IIOP et le reste voir la norme ! ca prend nettement plus de 2 jours (enfin pour moi) Sauf bien sur si on l' utilise comme un simple RPC C'est bien ce que je sous-entendais. 2-3 jours pour s'y mettre, pour creer des objets sur une machine et y acceder depuis une autre. En gros, pour faire du SOAP. Corba est beaucoup plus riche avec quantité de services mais ceux-ci sont facultatifs (et d'ailleurs absents du JRE standard). De la meme maniere que les services annexes de SOAP sont en cours de definition ailleurs et sont absents de SOAP lui-meme. Ce que j'essaye de dire, c'est que SOAP est plus complique que CORBA et que SOAP+UDDI+WSDL+... est plus complique que CORBA+SERVICES. Corba, dans son utilisation premiere, n'est pas complexe en Java, les Holders c'est super propre et intuitifs moi je trouve pas trop, la gestion des erreur Les Holders et Helpers: c'est propre (comment faire autrement compte tenu des limites de Java ?), ce n'est pas complique mais ce n'est pas intuitif (faut bien s'occuper pendant ces 2-3 jours). un peu plus en C++, penible en C (et autres langages non OO) et franchement ultra-simple en Python, Perl, ... Sauf a faire du pur C, SOAP est plus complexe. Toutefois, on devrait voir arriver progressivement de bons outils qui genereront tout ce qu'il faut pour que ce soit (presque) transparent (en gros comme Corba). ces outils existe déja et je t'ai même cité une liste !!! et la je te rejoint sur le fait que certaine implemention ne sont pas a maturité est était bien plus complexe a utilisé que Corba en simple RPC En fait je crois vraiment que certaines implementation de SOAP on vraiment nuit a ce standard il n'y a qu'a voir voir votre agressivité sur ce standard !!! ;-) Je me suis un peu emporte. J'en ai marre d'entendre tout le temps que Corba c'est complique alors chaque annee depuis six ans, nos stagiaires apprenent ca tres rapidement. Dans bien 80% des application distribuées que j'ai pu rencontré il est bien plus utilisé en dessous de son cadre de fonctionalité Ca, c'est de l'argument ! , J'essaye juste d'argumenter avec l'experience que j'ai des middleware(et je crois sincèrement pouvoir dire que j'en ai une) guillaume maintenant si tu juge que ce n'est pas un argument peut être a tu raison , a près tous a moi il ma fallu plus de 2jours pour comprendre(du moins essayer ) CORBA Ok. Ce que tu as ecrit, c'est que 80% des applis distribuees n'utilisent qu'une petite partie (le coeur) de Corba. Je suis d'accord avec toi mais je n'en tire pas les memes conclusions. Si je prends le meme raisonement, 80% des applis Java n'utilisent pas java.rmi ou java.security. Donc il ne faut pas utiliser Java ? Il faut l'utiliser que pour des projets ayant des contraintes de securite, de transaction ou autre service ? Corba est un ensemble de reponses elegantes aux problemes de distribution. Il permet de faire du client/serveur multi-langages multi-os en une dizaine de ligne. En ce sens, il est nettement plus adapte pour faire un outil d'admin, du calcul reparti ou du multi-agent que SOAP. Cordialement (I mean it) A+ Guillaume
Re: Client / Serveur, ou en sommes-nous ?
Guillaume Desnoix wrote:
Disons qu'il faut 2-3 jours pour comprendre le principe si on part
de zero
Tu est cour , les POA c'est quand même un poco complexe, et
comprendre tous les services annexe
Sécurité, transaction,IIOP et le reste voir la norme ! ca
prend nettement plus de 2 jours (enfin pour moi)
Sauf bien sur si on l' utilise comme un simple RPC
C'est bien ce que je sous-entendais. 2-3 jours pour s'y mettre, pour
creer des objets sur une machine et y acceder depuis une autre. En
gros, pour faire du SOAP. Corba est beaucoup plus riche avec quantité
de services mais ceux-ci sont facultatifs (et d'ailleurs absents du
JRE standard). De la meme maniere que les services annexes de SOAP
sont en cours de definition ailleurs et sont absents de SOAP lui-meme.
Ce que j'essaye de dire, c'est que SOAP est plus complique que CORBA et
que SOAP+UDDI+WSDL+... est plus complique que CORBA+SERVICES.
Corba, dans son utilisation premiere, n'est pas complexe en Java,
les Holders c'est super propre et intuitifs moi je trouve pas trop,
la gestion des erreur
Les Holders et Helpers: c'est propre (comment faire autrement compte
tenu des limites de Java ?), ce n'est pas complique mais ce n'est pas
intuitif (faut bien s'occuper pendant ces 2-3 jours).
la j'avoue être de mauvaise foi mais tu m'a un peu agresser ;) car après
tous y a des holder dans les webservice
aussi ce je rejoint le mail de Michel casabianca sur le fait que on se
branle des holder dans les webservices
car si on doit les utiliser autant faire du corba , et sur le fair QUE
XML-RPC me semble plus clean,
mais bon c'est moi dans le vent
un peu plus en C++, penible en C (et autres langages non OO) et
franchement ultra-simple en Python, Perl, ...
Sauf a faire du pur C, SOAP est plus complexe. Toutefois, on devrait
voir arriver progressivement de bons outils qui genereront tout ce
qu'il faut pour que ce soit (presque) transparent (en gros comme
Corba).
ces outils existe déja et je t'ai même cité une liste !!!
et la je te rejoint sur le fait que certaine implemention ne sont pas
a maturité est était bien plus complexe a utilisé que Corba en simple
RPC
En fait je crois vraiment que certaines implementation de SOAP on
vraiment nuit a ce standard
il n'y a qu'a voir voir votre agressivité sur ce standard !!!
;-) Je me suis un peu emporte. J'en ai marre d'entendre tout le temps
que Corba c'est complique alors chaque annee depuis six ans, nos
stagiaires apprenent ca tres rapidement.
Dans bien 80% des application distribuées que j'ai pu rencontré il
est bien plus utilisé en dessous de son cadre de fonctionalité
Ca, c'est de l'argument ! ,
J'essaye juste d'argumenter avec l'experience que j'ai des
middleware(et je crois sincèrement pouvoir dire que j'en ai une)
guillaume maintenant si tu juge que ce n'est pas un argument
peut être a tu raison , a près tous a moi il ma fallu plus de
2jours pour comprendre(du moins essayer ) CORBA
Ok. Ce que tu as ecrit, c'est que 80% des applis distribuees
n'utilisent qu'une petite partie (le coeur) de Corba. Je suis d'accord
avec toi mais je n'en tire pas les memes conclusions.
Si je prends le meme raisonement, 80% des applis Java n'utilisent pas
java.rmi ou java.security. Donc il ne faut pas utiliser Java ? Il faut
l'utiliser que pour des projets ayant des contraintes de securite, de
transaction ou autre service ?
Corba est un ensemble de reponses elegantes aux problemes de
distribution. Il permet de faire du client/serveur multi-langages
multi-os en une dizaine de ligne. En ce sens, il est nettement plus
adapte pour faire un outil d'admin, du calcul reparti ou du
multi-agent que SOAP.
Cordialement (I mean it)
Bon ok ,
Alors voila je vais juste coller dessous un example de webservice avec
glue et tu pourra apprecier la simplicité service WEB avec Glue car je
crois réelement
que certaine implemenations SOAP on porté tord a ce standard !!!
l' Interface que tu veut publier
/**
* Exchange rate methods
*/
public interface IExchange
{
/**
* Return the exchange rate between two countries
* @param country1 The country to convert from
* @param country2 The country to convert to
* @return The exchange rate
*/
float getRate( String country1, String country2 );
}
/'implementation de cet interface
public class Exchange implements IExchange
{
public float getRate( String country1, String country2 )
{
return 122.69F; // always return a constant for this demo
}
}
///lancement du serveur
import electric.registry.Registry;
import electric.server.http.HTTP;
public class Publish1
{
public static void main( String[] args )
throws Exception
{
// start a web server on port 8004, accept messages via /glue
HTTP.startup( http://localhost:8004/glue; );
// publish an instance of Exchange
Registry.publish( exchange, new Exchange() );
}
}
le client
// source: examples\local\Local1.java
Re: Client / Serveur, ou en sommes-nous ?
Cedric Beust wrote: Si tu veux te faire une idee plus precise (et objective ;-)), je te suggere de jeter un coup d'oeil aux API offertes par Amazon et Google, c'est un joujou sympa pour se faire les dents sur les Web Services. Un article sur ce sujet : http://zdnet.com.com/2100-1104-966546.html -- Cédric http://beust.com/weblog
Client / Serveur, ou en sommes-nous ?
Bonjour, Si vous suivez le film, vous comprenez le contexte de ma question, qui est cette fois-ci tout à fait dans le sujet. Cela fait une éternité que j'ai pas fait de client / serveur en java. A la préhistoire, j'aimais bien le RMI. Mais avec l'arrivée de la civilisation j'ai entendu parler de quantité de trucs très élaborés comme les SOAP/RPC/CORBA... Piouf ! Pour le coup j'ai pas besoin d'un truc très élaboré. Il faut avant tout que ce soit fiable. Mon client est un peu un administrateur ; ce serait bien de pouvoir administrer depuis un réseau, mais faut pas que ça me complique la vie. Dans la série Ce serait bien... Mais faut pas..., où en est-on ? -- SARL diaam informatique - 04 50 77 12 60 Ingenierie, développements de systèmes d'information http://www.diaam-informatique.com
Re: Client / Serveur, ou en sommes-nous ?
Herve AGNOUX wrote: Bonjour, Si vous suivez le film, vous comprenez le contexte de ma question, qui est cette fois-ci tout à fait dans le sujet. Cela fait une éternité que j'ai pas fait de client / serveur en java. A la préhistoire, j'aimais bien le RMI. Mais avec l'arrivée de la civilisation j'ai entendu parler de quantité de trucs très élaborés comme les SOAP/RPC/CORBA... Piouf ! Pour le coup j'ai pas besoin d'un truc très élaboré. Il faut avant tout que ce soit fiable. Mon client est un peu un administrateur ; ce serait bien de pouvoir administrer depuis un réseau, mais faut pas que ça me complique la vie. Dans la série Ce serait bien... Mais faut pas..., où en est-on ? mon avis personnel est que CORBA reste la norme la plus aboutie , la plus fiable et la plus utilisable, même si c'est pas toujours trivial a coder (le POA est un joli joujou :)) J'ai fait un test de SOAP, on en reparlera dans 4/5 ans, pour l'instant : - cote serveur rien a faire pour mettre a disposition ton code sur le web - cote client, prepares toi a sortir la cle de 12 car bonjour la rigolade des que tu ne veux pas serialiser une simple String (jene parle meme pas de collections que tu ne peux pas serailiser) - en general, inutilisable car trop verbeux, sur mon test SOAP transporte 3 fois plus de données qu'une solution XML a base de Castor JDO, 10 fois plus qu'une serialisation Java... bref en termes de perf c'est 10 fois plus lent que du http/XML en Java... si cela interesse quelqu'un je la lmettrai en ligne sur mon pauvre site :) - a noter,que l'implementation actuelle Axis (apache) en 1.0 doit avoir de gros problemes de perfs... la demo du stockquote en local est edifiante: 0.6s en moyenne, sur mon bi proc pour retourner une chaine hardcodee (0.65 ) bref la misere RMI est un peu lent, pose plein de problemes, n'offre pas de services (tolerance aux pannes, persistence etc..) les EJB sont trop neufs pour etre sur que ton appli aura des temps de reponse corrects sans devoir trop bidouiller... typiquement essaies un findAll sur une table de 30 entrees au prealable augmente la memoire via -Xmx autrement ca petera au bout de 15 ou 20 mn... Jerome
Re: Client / Serveur, ou en sommes-nous ?
Cedric Beust wrote: jerome moliere wrote: mon avis personnel est que CORBA reste la norme la plus aboutie , En Europe, oui. Aux USA, CORBA est inexistant. j'etais sur que tu reagirais :) mais c'est meme pas un troll... la plus fiable et la plus utilisable, même si c'est pas toujours trivial a coder (le POA est un joli joujou :)) J'ai fait un test de SOAP, on en reparlera dans 4/5 ans, pour l'instant : Uh, tu es serieux ? D'accord, les Web Services restent encore une technique de pointe, mais on a de plus en plus de clients qui se lancent dedans. C'est a ce jour la solution la plus prometteuse pour l'integration. ils ont de l'argent a perdre...:) Oui je sais EAI, etc plein de jolis concepts, mais regardes les limitations de l'archi et dis moi si selon toi, toutes les applications n'utilisent que des strings ? pas de collections, pas d'objets un peu fins ? on ferait du PHP pas de soucis, mais en langage fortement type, revenir aux strings systematiquement, c'est reducteeur non? - en general, inutilisable car trop verbeux, sur mon test SOAP transporte 3 fois plus de données qu'une solution XML a base de Castor JDO, 10 fois plus qu'une serialisation Java... bref en termes de perf c'est 10 fois plus lent que du http/XML en Java... Ce n'est pas parce qu'il transporte dix fois plus d'octets qu'il est dix fois plus lent. La pratique montre que pour les paquets habituellement echanges, cette surcharge est negligeable comparee aux autres goulets d'etranglement. tu veux dire quoi la ? que le temps de transport est negligeable par rapport au temps de process serveur, puis interpretation client ? ca depend du deploiement vous avez quoi comme reseau chez BEA ? viens voir des LAN en clientele et tu verras si tu campes sur cette position...quand t'as une appli multi site avec du numeris 64K au milieu, il faut faire gaffe quand même ... Si tu veux te faire une idee plus precise (et objective ;-)), je te suggere de jeter un coup d'oeil aux API offertes par Amazon et Google, c'est un joujou sympa pour se faire les dents sur les Web Services. je la connais, c'est assez sympa oui... mais google fonctionne avec un page by page iterator... donc ok, tu renvoies les 10 premiers resultats de ta requete, quel challenge :) imagines que tu veuilles renvoyer pour une sortie d'un etat tous les clients de telle ou telle region (3000 disons) , crois tu que celà soit jouable ? j'essaie d'etre objectif, as tu teste Axis ? moi oui si tu trouves normal, qu'en localhost, pour renvoyer une valeur codee en dur, sur un bi proc 1800Mhz, il faille 0.6s bein , pas moi je sais que dans ce laps de temps, je suis capable de serailiser/deserialiser 1500 lignes de commande alors que cette requete, ne represente pas le volume/complexite d'une seule!!! c'est un effet de mode, mais c'est inutilisable (ou du moins tel quel), je ne vois que la possibilite d'exposer certaines parties tres light d'appli via une telle mecanique , mais avec combien de limitations en plus a debuguer c'est l'enfer mais l'aspect le plus genant est l'extreme pauvrete pour quelle lourdeur des dialogues, si tu ne veux pas reecrire tout le code de serialisation t'es limite a des beans quasiment naifs(setName, getName etc..). J'ai l'impression de revenir 10ans en arriere a l'epoque ou transmettre une chaine via le reseau etait reservee a une elite..mais de l'eau a coule sous les ponts depuis non? Jerome
