Discussion :

[afrikha]

Bonjour ,

Je m'interroge sur la meilleure manière de faire communiquer un client swing avec des EJB de point de vue sécurité et volume des données échangées.

Je cherche donc des informations pour :

• utiliser https pour RMI.
• connaître le volume des données échangées (sérialistion binaire,...)
• est-ce qu'un ACC (Application Client Container) me serait utile ? (à priori j'utiliserai Glassfish comme serveur d'application)

Merci d'avance pour votre aide

[tig_drag]

bonjour, c mon premier msg donc dsl si ma reponse ne serait pas 'pro'

pour l'échange EJB swing, je vois pas où se situe le pb d'autant que l'invocation de l'EJB se fait automatiquement par le client indépendamment de ça nature.
une fois t'es en mode 'Remote' (je suppose) t'as plus interet a configurer une connexion RMI ou quoi que ce soit.
pour la sécurité c l'un des service offert par defaut par les ejb. franchement j'ai jamais utiliser ce volé, mais je te conseil de voir les tutos.

bon chance.

[alexismp]

Pas de firewall possible avec ACC, mais le développement est particulièrement simplifié avec la possibilité de faire de l'injection.

[afrikha]

Pas de firewall possible avec ACC, mais le développement est particulièrement simplifié avec la possibilité de faire de l'injection.

humm, c'est embêtant ça

je suppose que IIOPS ne passe pas le firewall non plus, non ?
Dans ce cas, la seule solution que je vois c'est du HTTPS pour RMI (les web services seraient trop lents) , d'autres solutions ?
Pour la mise en oeuvre du https pour rmi, ça se fait au niveau de la configuration du serveur d'application ou bien ça passe par du code ? (des liens sur le sujet seraient les bienvenues, google n'est pas très bavard à ce sujet )

Merci pour votre aide !

[alexismp]

les web services ne sont pas trop lents si tu choisis bien ta technologie et constituent la solution la plus pragmatique.

[afrikha]

les web services ne sont pas trop lents si tu choisis bien ta technologie et constituent la solution la plus pragmatique.

Certainement, mais j'ai besoin d'avoir une rapidité maximale avec une sécurité acceptable.
Dois-je comprendre que ce n'est pas possible de faire du RMI sur du HTTPS ?

Merci pour tes éclaircissements

@+

[alexismp]

Faire du tunnel de IIOP dans HTTP n'a jamais été simple.
Qu'entends-tu par "rapidité maximale"?
Pourquoi, dans ton cas, penses-tu que les web services seraient plus lents?

[afrikha]

Faire du tunnel de IIOP dans HTTP n'a jamais été simple.

ok, aurais-tu tout de même des liens sur la mise en place ? (en dernier recours)

Qu'entends-tu par "rapidité maximale"?

Le volume des données échangées entre le client et le serveur peut-être conséquent, la seule solution est de faire du lazy-loading ce qui risque de multiplier les échanges client/serveur. Si on ajoute à cela des contraintes de type temps réel (haute fréquence de rafraichissement), je pense que "rapidité maximale" devient claire

Pourquoi, dans ton cas, penses-tu que les web services seraient plus lents?

Je n'ai pas fait de test mais le fait que les web services sont plus lents que RMI revient presque toujours dans tout ce que je lis. De plus ça me paraît logique sinon pourquoi Sun irait créer IIOP si c'est pour avoir un truc plus lent que HTTP et qui en plus ne passe pas les firewall ?

Merci pour l'intêret que tu portes à cette problématique

@+

[alexismp]

Qu'entends-tu par "volume conséquent"?
Avec les parseurs XML de streaming et des stack Web Services récentes, il n'y a pas de raison que ce soit un problème. A titre d'exemple, avec Metro (la stack WS de GlassFish), on obtient des résultats sur de gros volumes (plusieurs centaines de Mo) proches du temps de réponse d'une utilisation HTTP "pure". Tout dépend de ta structure de données et de sa complexité.

Ceci dit, tu as également la possibilité de faire une architecture RESTful en utilisant simplement HTTP comme transport : chunking, caching, etc.. sont intégrés et testés depuis des années à grande échelle Coté Java, JAX-RS propose d'exposer facilement des POJO sous forme de ressource REST. Reste que le coté client HTTP en Java, il n'y a pas de solution miracle...

IIOP: c'est le protocole de CORBA. RMI l'a adopté (initialement c'était JRMP) après une longue bataille comme notre industrie en a régulièrement. Donc pas de paternité Sun pour IIOP.

[afrikha]

Salut ,

Qu'entends-tu par "volume conséquent"?

Quelques dizaines de Mo.

Avec les parseurs XML de streaming et des stack Web Services récentes, il n'y a pas de raison que ce soit un problème. A titre d'exemple, avec Metro (la stack WS de GlassFish), on obtient des résultats sur de gros volumes (plusieurs centaines de Mo) proches du temps de réponse d'une utilisation HTTP "pure". Tout dépend de ta structure de données et de sa complexité.

Ceci dit, tu as également la possibilité de faire une architecture RESTful en utilisant simplement HTTP comme transport : chunking, caching, etc.. sont intégrés et testés depuis des années à grande échelle

Je ne saisis pas très bien la différence entre ces deux architectures. Avec des stack Web Services, on fait du mapping Objet/XML et pour la seconde on transmet de simples String, c'est ça ?
Il y a des parseurs XML que tu recommandes en particulier ?
Pour la seconde, il y a quand même une possibilité d'avoir assez rapidement quelque chose de pas propre, contrairement à XML qui permet de bien structurer les données.

Merci beaucoup

[alexismp]

Non, avec REST heureusement ce n'est pas nécessairement des chaînes de caractères.
JAX-RS et en particulier Jersey possèdent la notion de "ProduceMime" qui permet à un POJO d'être exposé et consommé en JSON, XML, etc...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
    @Path("helloworld")
    public class HelloWorldResource {
 
       @GET
       @ProduceMime("text/xml")
       public String getData() {
           return new Data();
       }
    }

Avec SOAP, il y a un contrat sous la forme de WSDL. Il n'y a pas d'équivalent en REST. Certains diront que ce n'est pas nécessaire.