GWT RPC encapsulant un service ?

Version imprimable

02/12/2010, 17h48
M4v3rick

GWT RPC encapsulant un service ?
Bonjour, je débute en GWT.

Situation actuelle:
- Eclipse Galileo SR2 + GWT Designer + Tomcat + Mule + mass plugins ;)
- GWT 2.0.4
- Ext-GWT 2.2.0

J'ai une application client lourd Java - serveur Java (Tomcat) avec un ESB (Mule)

On me demande de créer un client léger (AJAX) => Je me lance sur la voie GWT (Java to AJAX)

J'ai donc écrit une application GWT qui "permetrait" de:
- se loguer (user, password) via une Dialog
- se déloguer (sessionId) via un SplitButton
- ajouter un record dans une table via une InputDialog
- demander la liste des records de cette table et les afficher dans une grille, dans un formulaire et dans une arborescence (histoire de faire un petit tour dans les widgets GXT)

J'ai implémenté un RemoteXXXService, RemoteXXXServiceAsynch (CLIENT) et RemoteXXXServiceImpl (SERVER)

===> R P C

avec pour le moment une seule méthode (login)
Dans l'implémentation - côté serveur - j'ai codé ce qui suit:
Code:

1 2 3 4 5 6 7 8 @Override public String login(String user, String password) { return "OK" + user + "-" + password; }
Tout simple quoi....

Mon premier test est d'utiliser mon interface cliente:
- Je donne un user: "Brol"
- Je donne un password: "123"
- J'utilise correctement mon service qui me retourne "OKBrol-123" que j'affiche au niveau du client dans un message alert de base.

bref; génial ça marche...

Maintenant, voici ma question:
J'aimerai que mon service "RemoteXXXServiceImpl" ne fasse pas cette implémentation simpliste mais délègue cette tâche à un autre service - qui "appartient" à une application tiers.

Ce service est "appelable" directement via l'url suivante (elle est bidon pour des questions de confidentialité):

http://127.0.0.1:8889/my-application...l&password=123

Ah oui, je suis en local... (je fais du test :D)

- J'ai donc un serveur pour "MyApplicationServer" (écrite en Java) et démarré en local (serveur Tomcat 5-5-17) => port 8888

- J'ai un client MULE 3.0 (ESB) démarré également en local pour permettre à ma "MyApplication" d'exposer un service sur le BUS de Communication => port 8889

- J'ai mon application GWT démarré en local (sur un autre port, ==> le 8890)

Bref:
Comment faire pour avoir un truc ressemblant à:
Code:

1 2 3 4 5 6 7 8 @Override public String login(String user, String password) { return MyApplicationServer.getXXXService().login(user, password); }
ou plus complexe => Je ne sais pas, je demande :D
Sachant que le String retourné sera un document XML contenant par exemple
Code:

1 2 3 4 5 6 <?xml version="1.0" encoding="UTF-8"?> <response> <status>OK</status> <sid>6277edc2-5f45-40bb-8855-fdegfdb8ef7d</sid> </response>
avec sid comme "session id" correspondant au login du user "Brol" avec le password "123"

Pourriez-vous m'aider?

Merci d'avance
06/12/2010, 12h10
M4v3rick

Bon, j'ai beau chercher, je ne trouve pas tellement il y a d'informations... je suis noyé.

Pour faire simple:

Si je veux utiliser un service (que je peux invoquer dans un navigateur sous forme d'une URL avec des paramètres, un bète POST)

Puis-je écrire l'appel à ce service (ce service est disponible sur une autre machine bien entendu) dans l'implémentation du côté serveur?
Si oui, comment?

Sinon:
Dois-je utiliser le RequestBuilder du côté client? Suis-je obligé de faire cela?

Aujourd'hui, l'écriture de mon RequesBuilder me renvoit un response.getStatusCode() == 0 (sous Firefox)
Quand j'exécute mon application GWT dans Firefox => ça ne marche pas (sans doute à cause de la police SOP mais je ne sais pas du tout pourquoi ni comment la contourner)

Quand j'exécute mon application GWT dans Internet Explorer => ça marche, le response.getStatusCode() me renvoit bien 200...
06/12/2010, 16h55
benwit

1) Utiliser les service RPC de GWT :
La partie cliente appel la partie serveur.
L'url du service est défini par le nom du module + le nom indiqué en annotation dans l'interface du service.
En théorie, tu n'as pas à gérer cela manuellement car l'échange des objets est gérée par GWT
(JS->TXT) ->(TXT->Java) pour les requêtes et (Java->TXT) ->(TXT->JS) pour les réponses.
PS : tu vois avec Firebug les messages TXT échangés en POST.

2) La partie cliente appelle elle-même un serveur HTTP (quelque soit la techno) et il faut effectivement utiliser un RequestBuilder pour gérer la réponse.
Tu as donc trouver. Après, il faudrait creuser pourquoi cela ne fonctionne pas avec Firefox ? Utiliser le debugger de GWT et passer en pas à pas.

3) La partie serveur appelle elle-même un serveur HTTP (quelque soit la techno). Il faut utiliser pour cela une librairie Java tel que HTTPClient (ton serveur devient le client du serveur que tu appelles).

Ok, merci pour ces précisions.

Alors, ce que j'ai fait: (et qui fonctionne tant avec IE qu'avec Firefox)

- Client GWT (utilisant la librairie GXT ou Ext-GWT pour les widgets complexes)
+ déclaration du service dans le web.xml (balises servlet et servlet-mapping) vers les interfaces suivantes:
MyRemoteService, MyRemoteServiceAsync
+ utilisation du service

CODE pour utiliser le service (côté client)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 final MyRemoteServiceAsync myRemoteService = GWT.create(MyRemoteService.class); final AsyncCallback<String> callback = new AsyncCallback<String>() { @Override public void onSuccess(String result) { Window.alert("Cool !!!\nThe result is: " + result); } @Override public void onFailure(Throwable caught) { Window.alert("KO ???\nThe problem is: " + caught.getMessage()); } }; myRemoteService.login(user, password, callback);
- Serveur GWT (RPC) : une seule classe
+ MyRemoteServiceImpl
cette implémentation fait appel au service qui est disponible sur une autre machine

CODE pour implémenter mon service (déléguer l'appel à un autre serveur):
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 // my method to use an external service to log in a user @Override public String login(String user, String password) { // the external service is available on a local server (test) final String url = "http://127.0.0.1:8889/myapplication/login"; final HttpClient client = new HttpClient(); final PostMethod postClient = new PostMethod(url); // sets parameters postClient.setParameter("user", user); postClient.setParameter("password", password); client.getParams() .setParameter(HttpMethodParams.RETRY_HANDLER, new DefaultHttpMethodRetryHandler()); String response = null; try { // executes the call of the external service client.executeMethod(postClient); // converts to a serialized object response = new String(postClient.getResponseBody()); } catch (IOException e) { e.printStackTrace(); } postClient.releaseConnection(); return response; }
Par la suite, je remplacerai l'appel du côté serveur dans la MyRemoteServiceImpl vers une URL d'une machine distincte et non plus depuis un serveur démarré en local avec un autre port...

=> final String url = "http://127.0.0.1:8889/myapplication/login";
sera remplacé par une "vraie" URL

Pour résumer:

Mon client GWT fait un appel à "son serveur GWT" via son RPC. Mon implémentation de service GWT délègue la tâche à un service disponible sur un autre serveur.

J'ai encore deux questions:

Aujourd'hui, le service (http://127.0.0.1:8889/myapplication/login) est un service de base me permettant de calculer un "SessionId". Ce service est écrit en Java et remballe une String (Java) qu'un ESB (MULE) transforme en chaîne de caractères (un document XML)...

Demain, ce service sera sans aucun doute un service Web (WSDL) ET accessible en https pour des raisons évidentes de sécurité.

1 ) Cela va-t-il me demander d'adapter mon code?

Je parle de la partie serveur où je fait appel à des objets de type HttpClient et PostMethod.

2 ) Pour ce qui est de la partie client, je n'utilise plus de RequestBuilder mais le système RPC de GWT; est-ce bien comme cela qu'il fallait faire?

Etant donné que ça fonctionne, je dirai que oui, mais à la fois, n'étant pas expert dans le domaine, je préfère demander.

06/12/2010, 21h43
benwit

Citation:

Cela va-t-il me demander d'adapter mon code?

Tant que les paramètres HTTP et la réponse HTTP sont identiques (même si l'implémentation différe : WS, ...), je ne pense pas que le code ait besoin d'être modifié.
Pour en être sûr, il faudrait vérfier au niveau de la lib HTTPClient s'il y a des limites pour HTTPS.
Dans un navigateur web, la seule différence entre HTTP et HTTPS peut parfois être vu par l'acceptation d'un certificat. Il faudrait vérifier au niveau de la lib HTTPClient sur ce point.
Si tu trouves des choses sur ce point, ce serait intéressant d'avoir ton retour.

Citation:

Pour ce qui est de la partie client, je n'utilise plus de RequestBuilder mais le système RPC de GWT; est-ce bien comme cela qu'il fallait faire?

Cette façon de faire se défend.
Maintenant, si c'est le client qui appelait directement l'url en question, on pourrait y voir plusieurs avantages :
- Pas besoin d'une partie serveur en Java si elle ne fait rien d'autre que le lien vers l'autre serveur.
- Un intermédaire de moins donc potentiellement plus optimale.
- L'accès HTTPS serait peut être moins contraignant ? car c'est le navigateur qui demanderait de l'accepter ?

Ceci dit, que ce soit le serveur qui passe lui-même cet appel peut avoir également ses avantages :
- les urls appelées sont découplées du client et n'impactent pas le client si elles viennent à changer.
- les urls sont inconnues du client et pourraient donc être appelées uniquement de certaines IP (celle de ton serveur) Cela peut donc être une protection supplémentaire ?

A toi de voir ce qui correspond le mieux à tes besoins.
06/12/2010, 22h50
M4v3rick

Hé bien, tu éclaircis certains points.

Mon métier veut un haut niveau de sécurité => le fait d'utiliser le RPC ajoute une couche supplémentaire en "cachant" les URL.

Le point de vue maintenance est très intéressant également.

Et d'après nos premiers "requirements", il est également intéressant d'avoir une partie serveur pour des applications "plus simples" et qui appelleraient du côté serveur des services 'distants' mais qui nous sont propres (propres à des serveurs sécurisés).

Pour ce qui est de la différence entre http et https, j'ai eu les mêmes échos en réunion la semaine passée: la seule différence serait l'acceptation de certificats. Cela pourrait également simplifier le déploiement de certains produits en ligne si on gère nous même cette "contrainte" bien qu'il y aurait toujours une couche de transcription dans nos transactions. Pour être un peu plus "clair" au niveau de la sécurité, nous utilisons deux modules: un module logique (via programmation) et des modules hardware (type HSM pour Hardware Security Module).

Enfin, le fait d'avoir passé ma "requête" via l'architecture RPC permet de valider la transaction tant sous IE que sous Firefox. Avec le RequestBuilder, nous étions confrontés à un problème de violation de la police SOP (Same Origin Policy) du fait de la complexité au niveau développement.

En ce moment, je réalise un POC (proof of concept) en GWT qui a pour but d'offrir l'équivalent d'une perspective d'une application RCP client-serveur (Eclipse) en version Web.

Un de mes collègues réalise un POC similaire, mais cette fois en Flex - histoire d'évaluer ces deux voies et de faire un choix technologique pour nos futurs développements.

Comme nous avons pas mal d'outils écrits dans des langages différents, nous voudrions dans un premier temps exposer des services des-dits applicatifs par le moyen d'un ESB.

=> Avant de nous lancer dans la voie du développement web, Nous cherchons à trouver les meilleurs outils, les meilleures pratiques pour obtenir :
- un très haut niveau de sécurité
- du code Java-Like (simplicité d'apprentissage / de faisabilité)
- des outils intégrés ou intégrables dans notre environnement Eclipse (développement, debug, tests)
- avec un bon niveau de support / documentation / aide extérieure
- une technologie récente et qui va perdurer
- une maintenance facilitée
- un Look&Feel professionnel -> nous ne faisons pas dans le site de présentation de photos de voyages mais plutôt dans la gestion de données sensibles (Tableaux, Arbres, Filtres, Formulaires, Tris, Editeurs spécifiques etc - du lourd mais en version Web)
07/12/2010, 09h34
benwit

Citation:

Envoyé par M4v3rick

=> Avant de nous lancer dans la voie du développement web, Nous cherchons à trouver les meilleurs outils, les meilleures pratiques pour obtenir :
- un très haut niveau de sécurité
- du code Java-Like (simplicité d'apprentissage / de faisabilité)
- des outils intégrés ou intégrables dans notre environnement Eclipse (développement, debug, tests)
- avec un bon niveau de support / documentation / aide extérieure
- une technologie récente et qui va perdurer
- une maintenance facilitée
- un Look&Feel professionnel -> nous ne faisons pas dans le site de présentation de photos de voyages mais plutôt dans la gestion de données sensibles (Tableaux, Arbres, Filtres, Formulaires, Tris, Editeurs spécifiques etc - du lourd mais en version Web)

Sécurité :
Avec GWT et RPC, tout est encodé en texte et passe en POST. Si ce n'est pas très compliqué d'écrire une telle requête, c'est déjà moins accessible que le GET où il suffit de bidouiller l'URL.
Si le contenu échangé par RPC est lisible, il est possible de masquer le nom des classes Java des objets échangés.
De plus GWT étant développé par Google, ils sont particulièrement concernés par la sécurité. Pour illustration, ils ont ajouté dans leur dernière version un composant SafeHtml pour se prévenir des injections SQL.

Code Java-Like :
Code Java pour la partie cliente et éviter d'écrire du Javasript
Code Java standard pour la partie serveur

Outils intégrés dans l'IDE :
Un des points fort de GWT. On peut débugger/refactorer dans Eclipse.

Support/Doc :
Il y en a pas des tonnes mais pas moins non plus que les technos concurrentes. Le site de Google est de plus en pus fourni.

Une technologie récente et qui va perdurer :
Flex, c'est du Flash ? si Flash n'est pas encore sur le point de mourir (particulièrement adapté au multimédia) qu'en est-il pour des applications face à l'arrivée de HTML 5 ?
GWT étant mené par Google, je pense que la techno est pérenne et comme c'est un compilo, on pourrait imaginer un nouveau compilo Java->XXX si la partie cliente subissait de grandes évolutions (XXX remplaçant Javascript).

Une maintenance facilitée :
si c'est surtout une question d'organisation et de rigueur, il faut quand même constaté que des langages fortement typés comme Java (+ la notion de packages, de tests unitaires) permettent de faire des applications plus maintenable.

Un Look&Feel professionnel :
Si l'approche SPI (Single Page Interface) n'est pas toujours la plus appropriée pour des sites d'informations, elle n'est en rien gênante pour des applications web de gestion.

Client Lourd ?
Si les framework comme GXT ne peuvent pas être aussi "stylisés" facilement que les composants GWT de base. Pour des applications de Gestion, cela donne un look pro sans trop se prendre la tête.