Robusta : Java & RESTful Web Services

Restful Web Services au Toulouse JUG

2010-12-24T11:23:17Z

Voici le slidecast de ma présentation sur REST au Toulouse JUG. C’est un peu long, mais l’essentiel se trouve dans les 15 premières minutes.

Enjoy.

L’introspection en Javascript

2010-08-04T12:55:39Z

Petit article rapide pour donner un exemple d’introspection, c’est-à-dire la faculté de récupérer la valeur d’un attribut, ou d’exécuter une fonction en connaissant le nom de l’attribut ou de la fonction.

Vite fait :

alert(myObject['attributeName']);

affiche la valeur de l’attribut attributeName de l’objet myObject.

alert ( (myObject['functionName'])() );

affiche ce que renvoie la fonction functionName() de myObject.

A quoi ca sert ?

L’introspection est courante en Java lorsque l’on travaille sur les Annotations. En Groovy, c’est la base du metaprogramming et autre ‘magie’ du langage.

En Javascript, je l’utilise surtout pour créer des composants ExtJs :

/* Au passage, voici une façon de créer une Class en Javascript */
function ComboObject(id, name){
this.id=id;
this.name=name;
}

/* Et d'ajouter dynamiquement une fonction */
ComboObject.prototype.toString = function(){
return this.name+" ("+this.id+"); ";
};

var o1 = new ComboObject(1, "Jo");
var o2 = new ComboObject(2, "Jo2");
var o3 = new ComboObject(3, "Jo3");
var o4 = new ComboObject(4, "Jo4");

var array = [o1, o2, o3, o4];

new SimpleCombo(
{
xtype : 'simple-combo',
model : array,
valueField: 'id',
displayField: 'name'
}
);

La machinerie interne de mon SimpleCombo utilise assez simplement l’introspection et l’on peut déclarer ‘à droite’ l’attribut sur lequel on travail. Le combo affichera l’attribut name et le formulaire enverra la valeur id. Si displayField n’est pas renseigné, on peut alors exécuter la fonction toString().

GWT n’est pas tout à fait du Java

2009-08-16T16:34:21Z

GWT émule en effet certaines fonctionnalités de Java pour les traduire en Javascript dans l’environnement d’un navigateur web standard.
Importez simplement une bibliothèque quelconque, comme JDOM, et vous aurez des messages d’erreurs en pagaye. Seule des bibliothèques spécialement conçues pourront être utilisées à la fois en GWT client et dans n’importe quelle JVM.

A chaque fois que vous écrivez du code Java fonctionnant à la fois côté serveur et client, il faut garder en tête de :

– GWT utilise directement les composants du navigateur : il utilise le DOM interne, ainsi que l’objet XmlHttpRequest- et donc ne connait ni Sax, ni JDOM, si le java.net.HttpClient
– Ne pas utiliser de fonctions System : il n’y a pas de compatibilité entre la JVM et le moteur du navigateur. java.util.Locale est incompatible avec GWT car est capable de lire une Locale par défaut dans le System de la JVM
– Ne pas lire un fichier : il est très malheureusement impossible d’utiliser les ResourceBundle pour internationaliser son code.
– Ne pas se mêler des Charset : le fonctionnement est trop différent entre la JVM et le navigateur. Je ne suis pas spécialiste, mais concrètement, les fonctions de type public byte[] getBytes(« UTF-8″) ne fonctionneront pas. Cela rend les fonctions de types MD5 et base64 sont pour l’instant incompatibles.
– Vérifier la liste des fonctions émulées : une fonction assez simple comme Class.getSimpleName() n’est pas émulée.

Alors est-il possible d’écrire une bibliothèque Java utilisable – et utile – côté client et serveur ? Oui, vous y arriverez en y passant suffisamment de temps et à la simple condition de maîtriser le concept de l’interface. Vous pouvez aussi attendre Octobre et la sortie de Robusta Web Library qui vous facilitera grandement la tâche.

Google App Engine : De la grêle dans les nuages

2009-07-04T11:39:00Z

Google App Engine est le système de Cloud Computing de Google. Par rapport à ses concurrents, il innove en quelques points :

Aucune configuration du serveur ni de la base de donnée : on dépose son application dans un conteneur.
Il n’y a pas à choisir dans une gamme de serveurs : les requêtes seront exécutées par Google, et on sait qu’ils le font bien
La facturation est faite selon les coûts réels : si votre application fait un bide, vous ne payez rien
L’application est développée en un seul langage : Python, ou Java depuis Mars

Cette différentiation colle vraiment à l’innovation. Un bon programmeur Java avec une idée peu créer son application sans perdre de temps à configurer linux+apache+ssl ni faire un prévisionnel des capacités de serveur. Avec Edupassion.com, je sais de quoi je parle. Et si personne ne se connecte, il n’y a pas de coût de serveur inutile, et là aussi je sais… euh passons.

Malheureusement, concrètement, App Engine en Java ne marche pas.

Il est très simple de créer une application HTML, avec Ajax et même GWT, puis de l’uploader. C’est ce que j’ai fait pour le site de mon entreprise, Robusta Web. Si le site en fonctionne pas, essayez… trois minutes plus tard ! D’après le log, à cause d’une jsp déclanchant com.google.apphosting.api.DeadlineExceededException et java.security.PrivilegedActionException. Il semble que la security passe ou bloque de temps à autre. Etonnnant !

J’ai tout de suite essayé d’installer JAX-RS avec Jersey, mais non, pas possible, le container refuse. On propose une version adaptée, qui marche un peu, mais bloque aléatoirement l’accès au site – cette fois-ci avec une vraie exception. Normal, c’est du bidouillage.

Plus gênant est l’utilisation des JSP et son mapping. http://www.robustaweb.com/myjax/bond/ fonctionne, mais pas http://www.robustaweb.com/myjax/bond . Différence subtile, pas contraire aux spécifications assez muettes, mais juste incroyable.

Mais le grand problème est l’accès aux données. D’une part à cause des couches successives JPA->JDO->Implementation Google->DataNucleus->BigTable, comme l’avait déjà fait remarqué Bruno Marchesson. Pour faire court, quoi que vous tentiez, cela échouera :).

J’ai quand même réussi à « persister » quelques objets, et même à les lire. Mais s’il existe peut-être des logiciels permettant de visualiser ces données, aucun n’est clairement référencé. Alors qu’avec une table MySql, vous n’avez aucun problème à savoir ce que vos tests ont générés.

Pour l’instant App Engine me parait donc inutilisable dès qu’il s’agit de sauver des données. Il semble dangereux d’y mettre un simple site avec des JSP. Quelques pages HTML peut-être….

Mais n’oublions pas que App Engine est en Early Access, et je suis plutôt optimiste : Google developpe très bien ses produits quand ils trouvent un public en face. J’y retournerai dans six mois.

Robusta Web Toolkit : Un peu de Buzz pour REST & Java

2009-06-17T16:02:52Z

Je finis cette semaine une première version public de Robusta Web Toolkit (RWT). Cette bibliothèque s’est construite au fil des trois dernières années lors de la construction d’Edupassion.com.

Depuis un peu plus d’un an, l’architecture d’Edupassion est passée RESTful et j’ai décidé d’épurer la biblitohèque afin de fournir un ensemble d’outils légers et cohérents facilitant les usages fréquents lors d’un processus REST. Simplicité et Productivités sont (en principe ) les maîtres mots.

Le premier tutoriel est en cours d’écriture, et RWT est téléchargeable dans une version qui évoluera encore un peu, l’essentiel du travail restant étant d’écrire une documentation convenable.

Vous pouvez toutefois vous amuser avec :

VerySimpleXml pour SAX (RwtSax) ou JDOM (RwtJdom)
Les classes utilitaires Couple et CoupleList
Des Clients Http simplifié et spécialisés, à partir du Client Sun (RwtSunClient, idéal pour les applets) ou du client Apache (RwtApacheClient)
Un ResourceController pour JAX-RS (JaxRsResourceController)

La version 0.9 stable et quasi définitive sera disponible au plus tard la semaine prochaine. En espérant des commentaires et peut-être quelques add-on de la communauté pour une version 1.0 en Septembre.

Pool de connexion Mysql sur Glassfish : Victoire :)

2009-06-06T18:55:37Z

Mais que ce fût dur !

J’avais déjà fait une vidéo sur la création d’un pool de connexion MySQL sur Glassfish. Malheureusement, lors de la pratique en test réel avec une application web et des alpha-testeurs, plus rien ne fonctionnait au bout de quelques heures : « Impossible to resize Pool » x 500 dans mes logs.

Créer plus de Connexions possibles n’a pas servi à grand chose (j’ai testé avec 256 au lieu de 16 :)) ). Par contre j’ai voulu pingé le pool grâce à l’interface de Glassfish. Lorsqu’aucune application n’est déployé, le pool ne ping pas puisque le .jar de Mysql n’est pas installé par défaut.

J’ai donc :

Copié mon Mysql Connector/J dans /usr/share/glassfish/lib
Précisé le .jar dans le Classpath de la JVM du serveur
Ajouté tant qu’à faire de la mémoire : c’est un serveur java !

D’une part je ping, et de plus je peux maintenant bombarder mon serveur de requêtes. J’en déduis peut-être à tort qu’utiliser le mysql.jar dans le /lib de son .war ne tient pas très bien la route.

Le serveur encaisse bien son millier de requêtes, et pour l’instant, je n’ai pas d’avertissements d’OVH .

Screencast : Fabriquer des Composants Javabeans

2008-12-20T14:37:02Z

Bonjour,

Voici deux vidéos-tutoriels permettant de fabriquer des composants Javabeans de façon simple, rapide et avec du code propre grâce à Netbeans

– I) Beans Binding : Synchroniser la valeurs d’une propriété avec celle d’un formulaire
– II) Programmation par Events : Réduire les combinaisons if/else avec une programmation modulaire, pilotée par les Events customizés.

Deux vidéos devraient arriver après les fêtes. Les articles pour Dev.com…. en avril

Swing : Productivité boostée avec les composants Javabeans

2008-12-20T14:17:11Z

Il y a peu, un Javabean était pour une simple classe avec un constructeur sans arguments et des getters/setters. Cela fait 18 mois que je travaille côté serveur et je viens juste de me remettre à mon applet Swing.

Coté Client, les Javabeans peuvent être utilisé par Netbeans pour créer des composants structurés pouvant interagir avec d’autres composants ou votre JPanel via des Events. Concrètement, c’est un élément supplémentaire de votre Palette, comme un JComboBox ou une JTable.

Il est possible de définir soi-même les Events agissant sur votre objet. Ainsi, au lieu de gérer 25 composants Swings standards (JButton, JLabel, JCombo) sur un seul Panel, vous aurez 5 Javabeans avec 5 chacun composants Swing interagissants avec des Events.

Le Javabeans va modifier son comportement selon les données entrantes (myJavabean.setTeacher() ) ou les Events. J’ai ainsi considérablement limité le nombre de if/else, mais en augmentant par contre le nombre de Classes. Selon l’auteur de XP, il faut limiter le nombre de Classes, mais ici je considère un package comme étant une Classe.

Au final, il y a beaucoup moins de bugs et j’ai refait en une semaine ce qui m’avait pris – je débutais – plusieurs mois !

JDBC est-il plus rapide que JPA ?

2008-11-24T06:14:07Z

En ce moment, je réécris totalement le code serveur du site Edupassion.com. Et après avoir découvert JPA il y a seulement quelques semaines, je suis maintenant sûr que la plupart des accès à la base de données d’Edupassion seront fait en JPA : plus simple à maintenir.

Cependant certaines requêtes seront très fréquemment utilisées par les utilisateurs : l’accès aux tokens d’authentification, et l’accès aux notes pour les profs et élèves. Il me parait donc logique de faire du JDBC pour optimiser ces deux-trois cas d’utilisation. Mais JDBC est-il vraiment plus rapide ? JPA vs JDBC : voici ce que j’ai trouvé sur java.net :

L’architecture est plus importante que la technologie :

[QUOTE]
The performance is completely
dependent on what you want to achieve and what actual providers you are
using. You should decide for a technology on a design or architecture
level. If you really want to decide on a performance level, you have not
understood what both are good for. Both are neither competitive, nor
comparable.
[/QUOTE]

A première vue, cela ne m’apporte rien. Un visiteur passe donc apporter la contradiction : puisque JPA est basé sur JDBC, un excellent programmeur serait capable de faire toujours mieux avec JDBC qu’avec JPA. Encore faudrait-il qu’un bon développeur existe – cela me rappelle Lex&Yacc …

[QUOTE]
With JPA vs JDBC, this is exactly the same. JDBC is the building block upon which JPA is built. JPA (as a result of standing on the
shoulders of JDBC) can never be faster than _properly tuned_ raw JDBC.
However, the JDBC code that most developers will write is going to be
slower than JPA 99% of the time…
[/QUOTE]

La réponse qui tue : JPA et JDBC n’ont pas le cache au même endroit (?!).

[QUOTE]
the JPA cache is on the client side, while the JDBC / DBMS cache is on the server side. Assuming a JDBC-based JPA implementation, you will benefit from this double buffering (if you have luck, the object is in the client side JPA cache; if you have not so good luck, it is found in the server side JDBC / DBMS cache; if you have bad luck, you must go down to the hard disc). If you do JDBC on the client side, then there is no client cache (unless your particular driver vendor implemented one directly in the client side driver). So, a JPA query will return client side cached objects, while a JDBC query must forward the server side cached data over the LAN. In sum, you have far more LAN transport with JDBC than with JPA. Unless you have client and server on the same machine, what is untypical in Client-/Server computing
[/QUOTE]

Pour ce que j’arrive à traduire et surtout comprendre, plus la quantité de données échangées entre JPA/JDBC et le serveur MySQL est importante à chaque requête, plus il est préférable de s’orienter vers JPA. Pour récupérer un token, ce serait JDBC, alors que pour récupérer un ensemble de notes dispersées entre plusieurs classes, groupes et périodes, ce serait JPA.

Ce dernier point me fait dire que si je veux faire du benchmarking, il n’aurait pas grand sens. A court terme, ma base de données est évidemment sur le même serveur, mais si j’ai un peu de succès, ca ne sera plus le cas.

Je pense que je vais m’arrêter là

2008-11-11T16:20:55Z

JPA (Java Persistence API) sera sans doute le dernier de mes joujoux technologiques pour bâtir l’architecture de la plateforme pédagogique Edupassion.com.

Tout cela fait beaucoup de technologies pour un seul homme. Ext-JS risque d’être le point faible… et le plus visible.

Le projet est donc séparé en 6 modules :

Code Browser : HTML reçu par la front view, Ajax vers le web service
Front view (Module Edupassion) : Distribution du HTML, redirection au Web Service
Web Service (module wsedupassion) : http -> JSP -> Javabean -> validation -> accès données -> analyse -> résultat xml
Code métier (module e-library) : contient les classes School, Teacher, Student, Work, etc.
Accès données (module JPA+Crud) : Les classes Entities sont générées par Netbeans 6.5. Le Crud convertit ces entities en classes métiers de e-library.
La base de donnée : On y accède soit par les entities, soit par des requêtes JPA, et parfois par des requêtes jdbc.

JPA
La seule originalité est la séparation franche entre les Entities issues de la Bdd et les classes métiers qui en sont presque des clones. Mais pour moi il est hors de question de rajouter la moindre ligne au milieu d’un code remplit d’annotation et de requêtes à mon avis difficile à maintenir.

J’apprécie cependant énormément de faire un Crud via ces Entities plutôt que par JDBC. La maintenance est plus simple, puisque, par exemple, en renommant une colonne de ma BDD, Netbeans génèrera des classes différentes et fera remarquer une erreur dans le code de mon CRUD. Cela est impossible avec du JDBC pur.

REST
L’accès aux web service se fait par REST, via des requêtes GET, POST, PUT et DELETE. Il a fallut pour cela modifier le fichier de Prototype, ce qui n’est pas très difficile. Un Web Service RESTFul permet principalement une montée en charge du projet sereine, sans modifier le code source.