Ca veut dire que pour faire un appel RPC entre C#/Delphi/.. et une appli Java, la solution préconisée est d'installer un serveur d'application JEE ? C'est pas "un peu" lourd ?Envoyé par Alain Defrance
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Ca veut dire que pour faire un appel RPC entre C#/Delphi/.. et une appli Java, la solution préconisée est d'installer un serveur d'application JEE ? C'est pas "un peu" lourd ?
non, tu peux faire l'appel directement en java avec la librairie qui va bien, par contre si tu veux passer par une couche intermediaire qui te fasse du monitoring, de l'alerting, de la validation, tu peux utiliser un serveur d'application.
tu as le choix (ecraser le T-rex ou la mouche quoi)
Oui, bien sur il y a d'autre solution qu'un serveur d'appli. Mais je parle de solution "préconisée", c'est à dire incluse dans un JDK officiel.
Est-ce qu'il y a une solution pour faire un appel RPC standard* vers Java en JSE ? Ou est-on obligé de passer par JEE ?
(*) Par standard je veux dire interopérable, genre xmlrpc, soap, rest, ...
oui RPC n'est pas lié a J2EE (pas plus que le monitoring etc...)
RMI : http://java.sun.com/docs/books/tutorial/rmi/index.html
Corba : http://java.sun.com/developer/online...rba/corba.html
Bonjour,
Que ca soit pour publier un ws en RPC Style, l'intérroger, ou passer par du RMI qui fait du corba ca se fait en JSE, et ceci sans lib supplémentaire, c'est comprit dans le JDK 1.6.
De plus ca se fait très facilement ...
JEE fournit un confort autre, mais la plupart des choses possible en JEE sont possible en JSE. Ce n'est juste pas managé par un serveur (il n'y en a pas).
J'ôte RMI de la liste car (tout comme le Remoting en C#) ce n'est pas vraiment interopérable. Ca nous laisse CORBA.
Ce que je trouve tout de même moins pratique que http/json, mais bon, c'est personnel.
On fait du WS RPC-Style, Document-Style, REST-Style en java très facilement sans JEE, uniquement avec le JDK 1.6.
Si ca répond à ta question
Oui, en partie. J'ai souvent la problématique de faire communiquer des applis hétérogènes (C, C#, java, ...).
La solution est souvent du RPC sur socket (tcp/ip), car c'est ce qui est le plus interopérable à mon sens. Je choisis également souvent le protocole HTTP car c'est facile a implémenter (et souvent déjà codé). De plus, c'est assez polyvalent (affichage d'info dans un browser web, par exemple). Le format des données oscille entre du plain-text, du xml, du json ou des formats exotiques.
Bref tout ca pour dire que lorsque l'appli est en Java (JSE), il n'y a pas de solution intégrée au JSE pour faire ce genre de chose. Sun a récemment ajouté un serveur HTTP au JDK, mais ce n'est pas un "standard" du langage (sans parler des bugs). La solution "officielle" reste JEE. La solution que j'utilise c'est l'ajout de librairie tierce a JSE, car c'est moins lourd.
D'ou mes interrogations/remarques:
- JEE est trop lourd pour faire un simple RPC
- JSE n'intègre pas de possibilité de faire du RPC simple (sauf Corba)
- Je suis le seul a avoir ces problématiques et faire des "micro" web-service n'intéresse que moi
Salut,
A moins qu'on arrive pas à se comprendre, c'est faux ...Bref tout ca pour dire que lorsque l'appli est en Java (JSE), il n'y a pas de solution intégrée au JSE pour faire ce genre de chose. Sun a récemment ajouté un serveur HTTP au JDK, mais ce n'est pas un "standard" du langage (sans parler des bugs). La solution "officielle" reste JEE. La solution que j'utilise c'est l'ajout de librairie tierce a JSE, car c'est moins lourd.
D'ou mes interrogations/remarques:
- JEE est trop lourd pour faire un simple RPC
- JSE n'intègre pas de possibilité de faire du RPC simple (sauf Corba)
- Je suis le seul a avoir ces problématiques et faire des "micro" web-service n'intéresse que moi
Je sais pas exactement sur quoi tu travail, mais le JDK seul en version 1.6 permet tout à fait de faire du RPC over HTTP/SMTP.
L'api JWS est là pour ça. Si ça t'interesse je peux te fournir un bête exemple plus tard (là je suis au bureau). Mais un micro web service ca se déploie en 2 ligne de code dans un pauvre main JSE, sans serveur JEE.
En effet c'est lourd de déployer un serveur JEE pour un petit ws, heureusement c'est pas nécéssaire.
Ah oui, c'est vrai, tu as raison. J'avais totalement oublié que l'API JAX-WS était incluse dans le JSE-6.
Bon, je retire mes commentaires précédents. Désolé, désolé, désolé...
Pas de problèmes, ca arrive aussi aux plus grands de se tromperAh oui, c'est vrai, tu as raison. J'avais totalement oublié que l'API JAX-WS était incluse dans le JSE-6.
Bon, je retire mes commentaires précédents. Désolé, désolé, désolé...
Java EE 6
La sortie de Java EE6 est une bonne nouvelle mais le souci pour nombreux développeurs c'est où trouver la doc sur ses différents composants et APIs
y a t-il une application exemple comme PetStore pour le EE5.
Il y a le Pet Catalog.
Java EE 6 App.
Merci à vous.
Les apps ne couvrent pas tous les APIs de EE6 y apas les JSF2.0, un framework basé sur les servelets 3.0,CDI,Bean validation,....
Le peu de tapage que faisait l'arrivée de cette version la laissait croire mineure.
En tout cas, elle apparaissait moins révolutionnaire que JEE 5.
Pourtant, à mes yeux, celle-là rafle la mise: la disparition d'XML y est pour beaucoup. Quel soulagement réellement, dans les simplifications que cela apporte!
L'ensemble des évolutions d'APIs associées ajoute à son intérêt.
Il va être très difficile aux entreprises de résister aux arguments de JEE 6, à mon avis. Parce que, ce qui arrive avec, c'est effectivement du lourd: c'est une machine de guerre.
La société qui l'emploiera prendra un avantage sur celle qui restera en retrait sur des versions très inférieures (JEE 1.4 et en dessous, voire pas de JEE du tout).
Pour ma part, je parie sur cette version: elle me semble futée et capable de limiter les constructions techniques qu'amenait J2EE dans les projets.
C'est autant d'efforts en moins pour former de nouveaux arrivants.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager