dimanche 20 octobre 2013

JEE


     Un bien petit acronyme derrière lequel se cachent bien d'autres acronymes avec beaucoup de concepts derrières. L'objet de ce post n'est pas d'en faire le détail (il existe de très bon livres, articles techniques à ce sujet) mais plutôt de donner une approche générale et quelques points de repères.

JEE : c'est quoi

     Pour commencer c'est déjà un acronyme signifiant Java Entreprise Edition. Souvent source de confusion la dénomination J2EE peut aussi être rencontrée. Le changement a eu lieu au moment du passage J2EE 1.4 à JEE5 : abandon de la dénomination java2 pour java et incrément des numéros 1.x à x directement.

     Ensuite c'est une spécification (caractérisée par une JSR) regroupant un ensemble de spécifications (elles même caractérisées par des JSR).

Les spécifications JEE et leur JSR principale :
     Au delà la spécification il y a une implémentation de référence (Glassfish, Metro, ...) mais chaque éditeur, projet peut proposer une implémentation compatible avec la spécification. Par exemple IBM avec son serveur applicatif Websphere propose ses propres implémentations d'un certain nombre de composants JEE.

Il est possible de download les bundles et exemples de codes :
http://www.oracle.com/technetwork/java/javaee/downloads/index-jsp-140710.html

On peut aussi via un repository Maven récupérer les implémentations des composants JEE7 :
https://wikis.oracle.com/display/GlassFish/Java+EE+7+Maven+Coordinates

JEE : ça sert à quoi

     JEE propose des composants, services, containers, standards permettant de faciliter l'intégration des applications développées au sein d'un systèmes d'information.
  • Par exemple pour les développements orienté Web : les servlet, JSP, JSF.
  • Ou encore JNDI (Java Naming Directory Interface) qui permet de décorréler son code applicatif de constantes propre aux environnements locaux tel des path sur la machine, ... Le code utilise des clés et le serveur via un "arbre JNDI" fourni les constantes locales correspondant à ces clés.
  • mais aussi les EJB, webservices, ...

     Après le développeur reste libre d'utiliser ces composants ou de choisir une alternative (hors JEE) quand il y en a. Par exemple utiliser des Spring Beans plutôt que des EJB.

Derrière la spécification : l’implémentation

     Comme je le disais plus haut pour un composant de JEE je peux avoir derrière la spécification plusieurs implémentations proposées.

     Par exemple JEE6 contient JPA 2.0 (Java Persistance API) piloté par la JSR 317 qui est implémenté par un certain nombre de solutions :
  • Hibernate
  • OpenJPA
  • EclipseLink (anciennement TopLink)
     En utilisant une implémentation autre que la RI (Reference Implementation) le développeur pourra aussi avoir le choix entre rester sur le standard  (JPA 2.0 dans ce cas) et demeurrer compatible avec toutes les implémentations JPA 2.0 ou utiliser des fonctionnalités spécifiques (hors spec) de la solution. Ceci aura pour conséquence de le lier plus fortement à l'implémentation qu'il a choisi. Ce n'est pas forcément un problème mais il faut en être conscient.

     Les serveurs applicatifs de par leur fonction sont amenés à proposer des services JEE et doivent donc fournir leur implémentation de ces services aux applications qu'ils hébergent.

     Les différents serveurs peuvent implémenter (et ainsi proposer) tout ou une partie de JEE. Par exemple Tomcat propose un container web permettant de déployer un war et faire tourner des servlet mais pas d'EJB.

     Pour répondre à ces implémentations partielles de JEE, Oracle avec JEE6 à mis en place la notion de profiles (avec le Web Profile).

     Oracle liste également les serveur applicatifs qui sont certifiés JEE compliant
http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html

Quelques matrices de compatibilité serveurs applicatifs / JEE

Liste générale : http://en.wikipedia.org/wiki/Comparison_of_application_servers#Java
Tomcat (Apache) : http://tomcat.apache.org/whichversion.html
TomEE (Apache) : http://tomee.apache.org/comparison.html
WAS (IBM) : http://en.wikipedia.org/wiki/IBM_WebSphere_Application_Server
Jetty (Eclipse Fondation)
http://wiki.eclipse.org/Jetty/Starting/Jetty_Version_Comparison_Table
http://en.wikipedia.org/wiki/Jetty_%28web_server%29
Weblogic (BEA - Oracle) : http://en.wikipedia.org/wiki/Oracle_WebLogic_Server

Quelques liens pour aller plus loin

points d'entré pour la documentation Oracle Java :
http://docs.oracle.com/javaee/
http://docs.oracle.com/javase/

Quelques samples de code JEE7 (websocket, batch, json, and so on) :
https://blogs.oracle.com/arungupta/entry/java_ee_7_samples_galore
https://blogs.oracle.com/arungupta/entry/java_ee_7_key_features

Support de JEE7 dans Kepler (petit dernier d'eclipse) :
http://www.jabby-techs.fr/eclipse-kepler-est-arrive/

Un historique des versions JEE
http://en.wikipedia.org/wiki/Java_EE_version_history

Présentation des composants et modèle JEE 6
http://fr.slideshare.net/shreeg/java-ee-6-component-model-explained

dimanche 13 octobre 2013

Quelques mots sur Protobuf

Protobuf c'est quoi

     Pour un projet c'est tout d'abord une technologie qui doit être partagée entre le fournisseur et le consommateur de data.

     La technologie définie un format d'échange au travers un fichier décrivant le (les) objet(s) échangé(s). A partir de ce fichier un compilateur génère des classes (Java, C#, ... fonction du besoin). Producteur et consommateur du flux de données s'échangent un flux de bytes que les classes générées sont à même de produire (output de méthode) et consommer (input d'une méthode retournant une instance de l'objet).

Avantages :
  • La réduction du volume échangé, les données étant réduites à un flux de byte minimaliste.
  • La solution permet d'avoir producers et consummers dans des technologies différentes (Java, C#, ...).
Les inconvénients :
  • La lisibilité des messages échangés tant que ces bytes arrays n'ont pas été désérialisées.
  • Sensibilité aux changements de formats (normal on est sur un contrat d'échange donc sur des conventions).
  • Sensibilité à la version protobuf utilisée de part et d'autres pour générer les classes (à vérifier).

En terme d'artefacts il faut donc :
  • un fichier .proto définissant le format du message (contrat d'interface).
  • en tooling un compilateur (exe, so, ...) dépendant de la plateforme, générant les classes java à partir du .proto.
  • idéalement un plugin maven pour intégrer cette phase de génération de classes dans le cycle de build du projet .

     Au niveau intégration, le plugin maven doit pouvoir accéder au compilateur proto. De même si l'on veut (via M2e) intégrer le cycle de build dans Eclipse, il faut définir une variable eclipse pointant l'exe.

     Le plugin intégrant eclipse et Maven (M2e) ne gère pas toujours bien les étapes de génération de classes proto (cycle de build sans fin, ...). Une manière simple est de regrouper toutes ses classes à générer (proto, wsdl, xsd, ...) dans un projet avec son pom spécifique. Une fois le jar généré ne l'utiliser qu'en dépendance (et pas projet ouvert) sous Eclipse.

Quelques urls

Protobuf :

Plugin Maven pour protobuf :

Les solutions proposant un service équivalent :
Un benchmark de différentes librairies de Serialization :
http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

Un comparatif Protobuf vs Thrift :
http://blog.octo.com/serialisation-thrift-et-protocol-buffers/

dimanche 6 octobre 2013

JavaOne, Devoxx et consoeurs


     Attention le post suivant peut un peu piquer les yeux, c'est un catalogue d'urls sur la thématique des conférences.

Le pourquoi du comment :

     Déjà c'est mon blog et je trouve cela pratique d'avoir un post ou je peux retrouver ces urls facilement.

     Ensuite je trouve qu'on (nous développeurs) se plaint souvent de ne pas être formé alors qu'on à la chance d'être dans un domaine où l'autodidacte qui en a la volonté peut accéder à tout le contenu qui lui est nécessaire pour avancer. C'est encore plus vrai au sein des technologies faisant bon accueil aux tendances open source tel Java. Que cela soit via le web, les tutoriaux, les blogs, les livres (là on rentre plus dans une problématique de cout) et justement les conférences ainsi que les user group qui ont fleuri ces dernières années. Ce catalogue montre qu'il y a beaucoup de choix (pour y aller ou se renseigner sur les feedback à posteriori). Après la ressource rare à notre époque c'est le temps, à nous de le prendre.

Les User Group à Paris

     Tendance récente qui commence à se compter en années. Ces users groups organisent des soirées gratuites regroupant des utilisateurs de technologies (souvent des développeurs mais pas que) autour de présentations de différents formats. Ces moments en dehors des présentations elles même sont également l'occasion d'échanger avec d'autres développeurs, de voir des tendances IT se dessiner, rencontrer quelques people du dev.

Paris JUG : http://www.parisjug.org/xwiki/bin/view/Main/WebHome
PerfUserGroup : http://blog.octo.com/compte-rendu-du-performance-user-group-1/
Scala User Group : https://groups.google.com/forum/#!forum/paris-scala-user-group
Parisjs (JavaScript user group) : http://parisjs.org/
Google Developer Group : http://www.meetup.com/gdg-paris/
Paris Android User Group : http://www.paug.fr/
Spring User group : https://groups.google.com/forum/#!forum/sugfr
Paris coding Dojo : http://wiki.agile-france.org/cgi-bin/wiki.pl?DojoDeveloppement

Les grandes conférences techniques

Celles de Google :
Goto : http://gotocon.com/
GoogleIO : https://developers.google.com/events/io/

Concernant Eclipse
EclipseCon : http://www.eclipsecon.org/

Plus sur le coeur Java
JavaOne : http://www.oracle.com/javaone/index.html
JVM Language Summit : http://openjdk.java.net/projects/mlvm/jvmlangsummit/
JFokus : http://www.jfokus.se/jfokus/
Jazoon : http://jazoon.com/
JTRES (Java Technologies for Real Time) : un site par event (http://jtres2013.atego.com/)

Technologies dont Java mais aussi tooling, nouveautés
QCon SanFrancisco : http://qconsf.com/
QCon London : http://qconlondon.com/
Devoxx : http://www.devoxx.com/
StrangeLoop : https://thestrangeloop.com/

Plus sur les tendances open source
FOSDEM : https://fosdem.org/
Oscon (Open Source Convention d'OReilly) : http://www.oscon.com

Côté web la WWW conférence un site par event : http://www2013.wwwconference.org/

Ted : http://www.ted.com/
Sdc (Scandinavian Developer Conférence) http://www.scandevconf.se/

Les conférences sur Paris


     Ce ne sont pas les plus nombreuses mais on commence à en avoir quelques unes intéressantes.

La fameuse Devoxx Paris, pour plus de détail sur son organisation il y a de nombreux post très intéressant sur le blog de Nicolas Martignole, le Touilleur Express

USI (université du SI organisé par Octo) : http://www.usievents.com/fr/

EclipseDay (ne semble pas réitérer) : http://www.eclipsedayparis.com/
Whatsnext (ne semble pas réitérer) : http://www.whatsnextparis.com/

Les supports

     Pour finir quelques sites permettant de retrouver les supports de ces conférences

samedi 5 octobre 2013

Java, jdk, jcp, jee & co

Quelques points de repère pour s'y retrouver dans cette galaxie d'acronyme qui constitue l'écosystème Java.

Terminologie

  • JRE : Java Runtime Environment
  • JDK : Java Development Kit
  • JVM : Java Virtual Machine
  • JIT : JustInTime
  • JAR,(Java Archive) WAR (Web Application Archive), EAR (Entreprise Application Archive)
  • JSE : Java Standard Edition
  • JEE : Java Entreprise Edition
  • API : Application Programming Interface
  • TCK : Technology Compatibility Kit
  • JUG : Java User Group
  • JCP : Java Community Process
  • JSR : Java Specification Request
  • JCP Members, Spec Leader, Expert
  • EC Executive Committee
 

Pour commencer JVM, JRE, JDK, JSE, JEE

     Le coeur, la machine virtuelle java (JVM) est ce qui exécute le bytecode (instructions issues de la compilation du code Java contenu dans une archive JAR, WAR, EAR). Une JVM est spécifique à chaque système, je ne pourrais pas faire tourner une JVM destinée à un système Windows sur un Linux par exemple, par contre tout archive java (code compilé, archivé dans un JAR, WAR, EAR) pourra s'exécuter sur n'importe quelle JVM.

     Il existe différentes JVM fournies par différents éditeurs, les plus célèbres étant :
  • HotSpot de Sun (maintenant Oracle)
  • JRockit de BEA (maintenant Oracle)
  • J9 d'IBM
     En temps qu'utilisateur (end user comme on dit) de solutions Java je n'ai besoin que d'une JRE (déjà installée, que je récupère sur le site d'Oracle ou que mon browser favori me propose d'installer si elle manque). Cette JRE me permettra de faire tourner une JVM qui exécutera sur mon système l'application java que je souhaite utiliser.

     En temps que développeur, j'ai besoin d'un peu plus, il me faut un JDK qui contient une JRE, les outils de compilations, JSE pour les API de base pour développer.... Je peux également avoir besoin d' api JEE  (Servlet, EJB, JNDI, ...) pour pouvoir coder si j'opte pour une application déployée sur un serveur applicatif qui me fournira les services correspondant.

     Pour finir java est versionné (Wikipedia - historique des versions). Ce qui peut parfois semer le trouble, il y a eu un renommage au moment du passage à la version suivant Java 1.4 (en fait Java 2 1.4 d'où J2SE et J2EE) :
  • en effet étant Java 2 depuis quelques années il a été décider de supprimer ce 2 sans utilité
  • incrémenter le nombre directement plutôt que 1.x
     Par conséquent on est passé de J2EE 1.4 à JEE 5. Je développerais dans un autre article ce qu'est JEE, pour faire rapide c'est une spécification qui regroupe un ensemble de spécifications.

Pour downloader JDK, JRE : http://www.oracle.com/technetwork/java/javase/downloads/index.html

Le Java Community Process (JCP)

     C'est une organisation créée par Sun en 1998 qui pilote les évolutions de Java. Elle formalise via un workflow, des validations et votes les évolutions concernant Java.
     Ce processus en est actuellement à la version 2.9 depuis le 15 aout 2012, il est décris ici ainsi que ses versions précédentes. La version 1.0 date de décembre 1998.

     Une évolution est matérialisée par une JSR (Java Specification Request) qui va suivre le workflow défini par le process. Ces étapes vont comprendre une étude, des réunions d'expert, passage des TCK, une validaton par l'executive committee, ... le tout cadré par un ou plusieurs spec leader.

     Chaque JSR est accessible sur le site, par exemple JSE 7 est la JSR 336. On peut ainsi consulter la spécification, voir les dates et résultats des différentes étapes ainsi que consulter le vote final qui décide de son adoption ou non (le Final Approval Ballot).

     Les membres de l'EC (executive Committee) sont ceux qui au travers le vote final ont pouvoir de décision. On y retrouve :
  • des sociétés IT tel qu'IBM, Google, CloudBees, Azul, RedHat, ...
  • la fondation Eclipse
  • depuis la reprise par Oracle des JUG (SouJava, London Java Community)
  • des sociétés utilisatrices de technologies comme Nokia, Credit Suisse, Goldman Sachs, ...

dimanche 29 septembre 2013

La maison du développeur : son environnement


     Bon voilà effectivement je le savais : ouverture du blog depuis quelques temps déjà et pas encore pris le temps d'écrire. Donc je prends quelques minutes (heures ... on verra quand j'aurais terminé) et je commence un premier post plus technique : l'environnement de développement.

     Pourquoi ce thème : parce qu'installer un environnement de développement c'est une opération qu'en temps que développeur on répète régulièrement, que les patterns d'un environnement commence à être bien posés en terme de features, outils, .... Et surtout quand j'aurais besoin de monter un nouvel environnement j'aurais toutes les urls sous la main. Ce sera aussi un snapshot pour voir dans quelques temps si j'utilise toujours les même outils. Enfin comme le dit le titre c'est vrai que l'on y passe tellement de temps à l'utiliser, le configurer, le remettre au carré, ... c'est un peut notre maison.

     Bien entendu l'objet n'est pas de poser l'environnement idéal. Chacun a ses habitudes, bonnes ou mauvaises, les besoins peuvent varier fonction du contexte (une équipe de développeurs WorldWide n'aura pas les même besoins qu'un développeur seul chez lui) et puis l'informatique est un monde dynamique, en peu de temps il sortira de nouveaux outils.

L'environnement ça comprend quoi :

Dans les grandes lignes, un environnement de développement (pour un développeur Java) c'est :
  •  un EDI
  • un gestionnaire de source (installé en local ou via service d'hébergement type GitHub, SourceForge)
  • des jdk
  • outil de build (Maven, ....)
  • un usine de dev (scheduling de build, tests, déploiement)
  • accès à un linux (en cas de serveur à gérer)
  • éventuellement une base de données
  • un wiki pour la documentation
  • un bugtracking

Quand au choix à mon sens ce qu'il faut :
  • Une stack cohérente, qui s'intègre bien et s'adapte aux utilisations qui peuvent se présenter.
  • Une intégration facile entre les différents composants (plugin, ...),
  • Des produits "main stream", largement utilisés par les développeurs afin que les sources d'informations, tutoriaux, forum ... rendent l'information rapides à trouver
  • Des produits suivis avec des sorties de versions régulières est un peu plus (permet d'intégrer rapidement les évolutions)
 

Ma stack favorite (open source) 

 

JDK (le coeur pour un développeur java) :
http://www.oracle.com/technetwork/java/javase/downloads/index.html
ou les previous release (cela peut toujours servir) :
http://www.oracle.com/technetwork/java/javase/archive-139210.html

Un outil de build : Maven 3
http://maven.apache.org/

un gestionnaire de source :
Subversion : http://subversion.apache.org/
Git : http://git-scm.com/

Un EDI : Eclipse (www.eclipse.org/downloads/), la dernière version étant Kerpler
--> Intégration EDI/build : M2e inclu dans la distribution Eclipse JavaEE
--> accès à un linux : Remote System Explorer (inclu dans la distribution Eclipse), permet d'ouvrir des terminaux Linux, transfert de fichiers, ...
--> integration gestionnaire de source
     Git : EGit (inclu dans les distribution eclipse) http://eclipse.org/egit/
     Subclipse (http://subclipse.tigris.org/) : plugin eclipse permettant l'interaction avec SVN

Fonction des besoins, un serveur applicatif (light ou moins light) :
Tomcat : http://tomcat.apache.org/
Jetty : http://www.eclipse.org/jetty/
Glassfish : https://glassfish.java.net/
JBossAs : https://www.jboss.org/jbossas

Un serveur d'intégration continue :
Jenkins (http://jenkins-ci.org/), se déploie dans un Tomcat

Des métriques pour suivre la qualité du code :
Sonarqube (http://www.sonarqube.org/) se déploie dans un Tomcat, peut nécessiter une base de donnée pour conserver les métriques
Checkstyle (http://checkstyle.sourceforge.net/), findbugs (http://findbugs.sourceforge.net/), PMD (http://pmd.sourceforge.net/) intégré via différents plugin existant dans Eclipse, Maven, Jenkins, Sonar
Google code pro eclipse plugin (https://developers.google.com/java-dev-tools/codepro/doc/)

Base de données :
MySQL : http://www.mysql.fr/
MariaDB (la reprise de MySql en open source) : https://mariadb.org/

BugTracking :
Mantis : http://www.mantisbt.org/

Tooling divers et varié :
NotePad++
http://notepad-plus-plus.org/fr/
Et ses plugin (dont XML plugin utile) : http://sourceforge.net/projects/npp-plugins/files/

Process Explorer (pas toujours evident à trouver, différentes versions peuvent être download sur différents sites, je n'ai pas trouvé de point d'entré récent sur ce projet. Dommage l'outil est pratique)

Transfert de fichiers :
FileZilla : https://filezilla-project.org/
Winscp : http://winscp.net/eng/docs/lang:fr

Connexion terminal linux :
http://www.putty.org/
Accompagné de putty ConnectionManager 
(http://www.unixmantra.com/2013/04/putty-connection-manager-tabbed-putty.html#.UkhRRX80_7E)
ou superPutty (http://code.google.com/p/superputty/)

Wiki :
JspWiki http://jspwiki.apache.org/

Regroupe les fonctionnalités Wiki, bugtracking, ...
http://www.redmine.org/

Voilà pour la stack que j'utilise régulièrement. Après bien entendu il existe pour chacun (ou presque) de ces composants des alternatives ayant également ses avantages.

Quelques alternatives (liste non exhaustive)


 EDI :

Build :
Serveur d'intégration continue :
Gestionnaire de source :
 

dimanche 25 août 2013

Je prends la route

Ce blog se veut le carnet de voyage d'un développeur Java dont les articles (ou tout du moins les notes) vont marquer le chemin tels les cailloux du petit Poucet.

Au fil de mes pérégrinations sur cet océan d'informations que sont nos mondes (virtuels ou réels) j'y poserais mes remarques, réflexions et repères.