vendredi 27 avril 2012

Java encoding (UTF) tips and tricks




Starts Java with default encoding for streams :

java ... -Dfile.encoding=UTF-8 ...


Read a file encoded in :

File inputFile = new File("...");
BufferedReader myFileReader = new BufferedReader(new InputStreamReader(new FileInputStream (inputFile), Charset.forName("UTF-8")));


Write a file with encoding :

File outputFile = new File("...");
BufferedWriter myFileWriter = new BufferedWriter(new OutputStreamWriter(new FileOutputStream(outputFile),Charset.forName("UTF-8")));



Convert bytes to String using encoding :

byte[] stringBytes = ...;
String convertedString = new String(stringBytes,Charset.forName("UTF-8"));          



Convert String to bytes using encoding :

String myString = ...;          
byte[] stringBytes = myString.getBytes(Charset.forName("UTF-8"));



To be continued ...





Contrat Creative Commons
the jee architect cookbook by Olivier SCHMITT est mis à disposition selon les termes de la licence Creative Commons Paternité - Pas d'Utilisation Commerciale - Pas de Modification 3.0 Unported.

samedi 21 avril 2012

LESS : scripting CSS


CSS  makes the buzz since we discover day after day the powerful CSS 3 features : 3D, Shadows, Transformations, Media Queries, ...


But if you look at HTML you can see many powerful technologies to make HTML page dynamic : PHP, JSP, JSF, ASP, ...


Whitout them, building webapp 2.0 would be just that hard !


We are living a time where customers want more customisation, where your webapps are touched by many differents devices. We definitly need dynamic CSS !


LESS  does the job by extending CSS.


With LESS you can add theme support, refactor your duplicated CSS code , customize look and feel on the fly, ...


Using LESS is using CSS with new syntaxic sugar.


But at the end of the day, a browser only knows CSS : you have to perform a LESS to CSS translation. 


You can use two modes for this:
  • dynamic :  LESS style sheet are translated on the fly by the browser 
  • static : via a LESS compiler, CSS are then deployed like usual CSS


Now, a quick overview of LESS.


Variables



Variables allow you to  manage gracefully common style values like colors :


@some-color: #FF34AA;

#myid { color: @some-color; }
.myclass { color: @some-color; }


LESS CSS translation :

#myid { color: #FF34AA; }
.myclass { color: #FF34AA; }


Mixins



With mixins you can embed any CSS inside another declaration.

.margined {
  margin-top: 1em;
  margin-bottom:1em;
}
#banner a {
  color: black;
  .margined;
}
ul {  
  .margined;
}

Target  embeds all styles defined in mixin :

#banner a {
  color: black;
  margin-top: 1em;
  margin-bottom:1em;
}

ul {  
  margin-top: 1em;
  margin-bottom:1em;
}

You can add args to mixins !


.margined (@height:1em){
  margin-top: @height;
  margin-bottom:@height;
}


#banner a {
  color: black;
  .margined(1.5em);
}

ul {  
  .margined;
}


Translates as :

#banner a {
  color: black;
  margin-top: 1.5em;
  margin-bottom:1.5em;
}

ul {  
  margin-top: 1em;
  margin-bottom: 1em;
}

See the default arg value feature on @height !

You can add many args to a mixin like a method.

 

Arithmetics



You can add, divide, multiply, substract variable :

@simple: 5%;
@double: @simple * 2;
@halfdouble: @simple + @double;

color: #666 / 3;
background-color: @somecolor + #250;
height: 100% / 2 + @double;

LESS keeps consistency with units, then 10px * 2 compute as 20px.



Playing with colors



These are very handy functions to build a theme for instance.

Some snippets:


lighten(@somecolor, 30%);     // 30% more ligther than @somecolor 
darken(@somecolor, 30%);      // 30% more darker than @somecolor

saturate(@somecolor, 3%);    // 3% more saturated than @somecolor
desaturate(@somecolor, 3%);  // 3% more saturated than @somecolor

Time to play



If you want to see LESS in action, have a look on Boostrap Twitter which is based on it.


LESS concepts will be a great bunch of features to add to official CSS.

But, Java ecosystem does not offer a good support for LESS compilation.


We'll see later how to integrate LESS on the server side with Rhino Javascript engine.






Contrat Creative Commons
the jee architect cookbook by Olivier SCHMITT est mis à disposition selon les termes de la licence Creative Commons Paternité - Pas d'Utilisation Commerciale - Pas de Modification 3.0 Unported.


lundi 16 avril 2012

Du style pour vos services web : la théorie


De nos jours, les piles logicielles pour implémenter des services webs sont légions.
De plus, la plupart de ces piles proposent des approches de développement très productives : JAX-WS et JAX-RS par exemple.
Mais ces piles abordent les aspects techniques des services webs : sérialisation XML, espace de nommage, génération de client, ...
Elles ne sont que de peu d'utilité pour adresser des questions parfois complexes:
  • comment gérer les changements ?
  • quelle est le mode d'invocation qui apporte la plus grande scalabilité ?
  • comment obtenir une API de service web cohérente avec le métier du SI ?
  • quel style pour quel client ?


   Cet article se propose de répondre à quelques questions par l'entremise du style.


Le style RPC


Le style RPC (Remote Procedure Call) consiste à exposer une procédure distante plus ou moins telle que l'originale, c'est à dire avec la même signature que la procédure invoquée sur le système d'information distant.
Ce style a permet de coller au plus près de la couche métier du SI cible.
Cependant, il comporte des inconvénients :
  • les clients du service web peuvent être cassés si la signature de la procédure change.
  • la logique métier du SI distant est exposée directement ce qui peut poser des problèmes au client : granularité des objets métiers, complexité, performance

Très souvent, un service RPC sera appelé en mode synchrone :

Enfin, un service web de style RPC peut être invoqué de manière asynchrone.

Cela se passe en deux temps, d'abord le client invoque le service web et reçoit un accusé de réception. Enfin, le service web rappelle le client (callbak) lorsque le résultat est prêt. La pile JAX-WS supporte ce mode asynchrone.
Une autre manière d'implémenter un service asynchrone consiste non pas à reposer sur un composant technique mais à prévoir ce mode dès les spécifications fonctionnelles du service.
Le service web concerné renvoie un accusé de réception qui contient un code retour et un identifiant d'appel. Un deuxième service est proposé pour récupérer le résultat de l'appel : le client doit alors implémenter une logique de polling pour obtenir le résultat.


Le style Message


Le style Message consiste à échanger des messages dont le contenu sera analysé par le système d'information distant pour sélectionner la procédure à invoquer.
Généralement, l'API du service web propose un type de message pour l'invocation du service et un autre type pour la réponse.
La forme réelle de la procédure métier du SI est complètement cachée, il s'agit d'une reformulation complète via le concept de messagerie. L'API du service web est taillée sur mesure pour les besoins du client. Les procédures métiers du SI distant ont dans ce cas un rapport très lointain avec l'API du service web.
Ce style convient quand :
  • un grand nombre de procédure sont disponibles avec une sémantique proche : l'encapsulation des informations d'invocation et de réponse suivant le pattern Message permet de limiter le foisonnement de l'API du service web.
  • les informations nécessaires à l'invocation sont complexes et variées : lorsque de nombreux arguments sont nécessaires comme des informations métiers (heure de départ, nombre de passager, ...) et techniques (version de la procédure, format de retour, compression, ...)
  • le SI distant change fréquemment
Ce style est plus volontiers mis en oeuvre sur un mode asynchrone : le client n'est dans ce cas pas bloqué par l'invocation du service web.
Il reçoit dans un premier temps un accusé de réception qui lui indique simplement si le message a été correctement reçu.
Ensuite le service web traite la demande éventuellement en s'appuyant sur un dispositif asynchrone de type messagerie (JMS) ou évènementielle (SEDA) .
Lorsque la demande est traitée alors le client est informé du résultat de cette demande via un message de réponse.
Si le client tolère le mode asynchrone alors il est possible d'atteindre un haut niveau de scalabilité.
Il peut être pertinent d'utiliser le pattern Builder pour aider le client à construire des messages pour l'invocation du service ou à lire les messages de réponse.






Le style Resource



Le style Resource s'appuie sur les préceptes définis par l'architecture REST.

Le protocole HTTP est utilisé comme cadre conceptuel et technique pour définir et implémenter les services.

Tout est ici "ressource" que le client peut toucher via une URI associée à une seule et même ressource.
Une ressource peut par contre être touchée via plusieurs URIs.

Le protocole HTTP définit des verbes qui ont une sémantique précise :

- GET pour obtenir la représentation d'une ressource
- PUT pour créer ou mettre à jour une ressource
- DELETE pour supprimer une ressource
- POST peut être utilisé comme PUT ou DELETE (environnement ou ces verbes sont interdits) ou pour des comportements qui ne rentrent pas dans les cases PUT ou DELETE.
- ...

HTTP propose aussi :
- des codes de retour : 200, 404, 500, ... qui seront eux aussi utilisé par vos services REST pour communiquer le résultat des opérations.
- une gestion des représentations via les types MIME

Enfin, HTTP définit certains verbes comme idempotents : GET, HEAD, OPTIONS ne doivent pas provoquer de changement d'états quelque soit le nombre d'invocations.

Quant à POST, DELETE, PUT, ils ne sont pas idempotents.


Les opérations que vous proposerez à vos clients devront rentrer dans les cases conceptuelles définies par REST et HTTP. Par exemple, une requête HTTP est structurée d'une certaine manière (paramètres encodés) et contient uniquement des données au format texte.

Si cela vous convient alors ce style peut vous apporter beaucoup :

- un cadre conceptuel, technique robuste et bien connu
- des possibilités d'optimisation via des mécanismes de cache
- des facilités de support de clients variés
- toléré par les mécanismes de sécurité tel que les parefeux
- particulièrement adapté et performant dans le contexte d'applications RIA (ajax)




Nous avons vu trois styles de conception pour vos services webs : indépendamment de toute pile technique, il est important de bien connaître ces styles et leurs applications.


Nous verrons dans d'autres articles des implémentations concrètes de ces styles.




Contrat Creative Commons
the jee architect cookbook by Olivier SCHMITT est mis à disposition selon les termes de la licence Creative Commons Paternité - Pas d'Utilisation Commerciale - Pas de Modification 3.0 Unported.

jeudi 12 avril 2012

JSF JQuery Mobile archetype updated with JQuery Mobile 1.0.1 and JSF 2.1 !


I'm proud to announce the 1.4 release of a maven archetype for JSF JQuery Mobile dev !
Updates are :
  • JQuery 1.7.1
  • JQuery Mobile 1.0.1
  • JSF 2.1 with Mojarra 2.1.7 implementation
It's a quick start (tested with Maven 2.1.0, 2.2.X, 3.X) and runs at least with Glassfish 3.1.2, Tomcat 7.
mvn archetype:generate -Dfilter=jqmobile
It's not intended to cover all needs but simply give a your project a quick start.
I will update this archetype with best practices time after time.
Don't forget to apply best practice (corporate POM, ...).
Hope you enjoy !




Contrat Creative Commons

the jee architect cookbook by Olivier SCHMITT est mis à disposition selon les termes de la licence Creative Commons Paternité - Pas d'Utilisation Commerciale - Pas de Modification 3.0 Unported.

samedi 7 avril 2012

Choisir une architecture : ordonner les exigences


Le cahier des charges


L'ONU, organisation bien connue, souhaite disposer de deux services connectés sur le référentiel des pays qu'elle reconnaît:
  • à destination de ses partenaires : un service web à accès public qui donne accès en lecture au référentiel
  • à usage interne : une application à accès restreint qui gère le référentiel dédié aux agents de l'ONU.
Dans les mois ou années qui suivront la mise en production de ces services, de nouveaux services pourront être ajoutés.
Nous nous attacherons à traiter le cas du service web.

Capturer les exigences


La meilleure approche pour capturer les exigences implicites consiste à utiliser une approche reconnue et pragmatique : FURPS.
FURPS est un acronyme qui signifie :
  • Functionality
  • Usability
  • Reliability
  • Performance
  • Supportability
Cette approche permet de capturer des exigences implicites qui peuvent prendre une importance considérable. Je vous renvoie à l'excellent article rédigé par un architecte senior (l'expérience des anciens !!!!) d'IBM.

Les exigences du service web


Le client ne donne pas toujours une liste claire d'exigences. Certaines sont explicites d'autres déduites.
Ainsi, si un client demande que l'architecture passe le cap des dix années de service, il apparaît très risqué voire dangereux de proposer le dernier framework à la mode développé par quelques personnes et sur lequel la visibilité ne dépasse pas 6 mois.
En étudiant le cahier des charges, on remarque que les services proposés sont à destination du monde entier. Ceci implique que ces services seront disponibles 24/24 et 7/7 pour couvrir l'ensemble des fuseaux horaires.
La durée d'exploitation de ces services est fixée à 10 ans. Dans ce cadre, seul un standard reconnu et bien établi peut garantir une telle pérennité. Les standards proposés par l'OASIS en matière de services webs semblent répondre à cette exigence même si ils sont parfois décriés. Ils apportent l'universalité souhaitée et des spécifications claires sur les formats de données et d'échanges.
On notera que le client ne demande pas de SLA en terme de performances, ce qui paraît raisonnable dans la mesure ou ce type de service web peut être extrêmement sollicité. Ceci veut dire que les clients du service web devront tenir compte de cette contrainte : le service sera disponible mais répondra quand il pourra.
Il se peut aussi que le client pense que l'exigences de performance va de soit : grave erreur ! Il convient parfois de lever ce genre d'ambiguité au plus vite.
On remarquera aussi que le client ne précise pas de taux ! A vous de lui proposer un ou plusieurs taux raisonnables. En effet, même si un taux de 99,999% est séduisant sur le papier, cela a-t'il un sens par rapport à la criticité du service ? A priori non.
Cependant, l'universalité du service implique un taux forcément élevé dans la mesure ou l'on souhaite que le monde entier puisse accéder à ce service aux heures ouvrables. Nous proposerons un taux minimal de 95% qui implique une indisponibilité maximale d'une heure en moyenne par jour.
Voici une liste d'exigences explicites et déduites :
  • EX-OASIS : le service web se conformera aux standards WS-* de l'OASIS
  • EX-COVER : la couverture de code par les tests automatisées sera proche de 100%
  • EX-AQ : le code respectera l'état de l'art de la qualité logicielle
  • EX-MAIN : les solutions retenues (services, qualité, ...) permettront de minimiser les coûts de maintenance pour la durée de vie des services estimées à 10 ans
  • EX-REU : la réutilisation du code sera maximale
  • EX-FORGE : la fabrication des livrables suivra un processus identifié et reproductible : binaires, sources, documentations, rapports, publications, ...
  • EX-DISPO : les services seront disponibles 24/24 et 7/7 à 95%.

Ordonner les exigences


Les exigences et les besoins exprimés sont de différents ordres : certains sont très structurants, d'autres bcp moins.
L'architecte doit ordonner ces éléments du cahier des charges pour s'approcher de l'architecture idéale, c'est à dire celle qui répond aux cahiers des charges et non pas celle que votre organisation à l'habitude de vendre.
Une représentation en arbre des exigences permet de visualiser les liens et les hiérarchies de ces exigences.
Voici l'arbre des exigences construit à partir du cahier des charges :


L'EX-MAIN nous indique ensuite que l'architecture cible devra tenir le choc pendant 10 ans. Tous les choix techniques qui composeront l'architecture finale devront respecter cette exigence.
Le deuxième noeud important de l'arbre des exigences est l'EX-AQ : la qualité logicielle.
Cette exigence se décline en trois sous exigences :
  • la couverture de code par les tests : un élément reconnu de la qualité logicielle que nous verrons plus tard.
  • la réutilisation du code : factoriser le code facilite la maintenance et les évolutions du logiciel.
  • la fabrication des livrables : un processus de fabrication fiable et reproductible est un élément clef de la qualité.
Enfin, l'exigence EX-OASIS implique qu'il faut choisir une solution qui supporte ces standard : probablement que le support d'une version du Basic Profile est à retenir.
La bonne compréhension des exigences et de leurs relations est fondamentale pour proposer une architecture adaptée: il est aisé de se perdre dans l'étendue des solutions techniques disponibles.
Dans le prochain article nous tenterons de proposer une solution adaptée.




Contrat Creative Commons
the jee architect cookbook by Olivier SCHMITT est mis à disposition selon les termes de la licence Creative Commons Paternité - Pas d'Utilisation Commerciale - Pas de Modification 3.0 Unported.

Choisir une architecture logicielle : qu'est ce que l'architecture ?


L’architecture logicielle décrit d’une manière symbolique et schématique les différents composants d’un ou de plusieurs systèmes informatiques, leurs interrelations et leurs interactions.
Nous nous intéresserons plus particulièrement au modèle d'architecture orientée objet avec un découpage en couches qui est probablement le modèle le plus adapté à la réalisation d'application déployée sur le web.
Nous définirons ce modèle d'architecture de la manière suivante :
C'est un empilement de composants logiciels de différentes natures, créant ainsi une division en couche logicielle hiérarchisée. Chaque couche regroupe des composants traitant d'un même domaine (la sécurité, l'accès aux données, ...) et dépend elle même de la couche inférieure.
Les composants du système intègrent des données et des opérations de traitement de ces données.
Ils sont conçus sur les principes suivants :
  • encapsulation : concerne l'architecture détaillée de chaque objet, les données étant protégées d'accès direct par une couche d'interface. De plus, les sous-fonctions, inutiles pour utiliser l'objet, sont masquées à l'utilisateur de l'objet.
  • héritage : permet d'éviter la redondance de code et facilite l'extensibilité du logiciel, les fonctionnalités communes à plusieurs classes d'objets étant regroupées dans un ancêtre commun.
  • polymorphisme : permet d'utiliser des objets différents (possédant des comportements distincts) de manière identique, cette possibilité est réalisée par la définition d'interfaces à implémenter.

La suite au prochain épisode ...




Contrat Creative Commons
the jee architect cookbook by Olivier SCHMITT est mis à disposition selon les termes de la licence Creative Commons Paternité - Pas d'Utilisation Commerciale - Pas de Modification 3.0 Unported.

LESS : les CSS dynamiques



Les CSS sont à l'honneur depuis quelques temps grâce aux nouveautés de la version 3 toutes plus impressionantes les unes que les autres : 3D, Ombrages, Transformations, Media Queries, ...


Cependant, quand on s'intéresse à son binôme, le HTML, on note que les développeurs ont à 
leur disposition toute une panoplie de solutions pour rendre le HTML dynamique : PHP, JSP, JSF, ASP, ... et ce depuis fort longtemps !


Sans ces technologies, le développement d'application web dynamique serait très difficile.


A l'heure, ou les utilisateurs demandent toujours plus de personnalisation des interfaces, ou les sites web sont ou seront accédés par une variété incroyable de périphériques de toutes tailles comment se passer de feuilles de style dynamiques ?


LESS répond à ce besoin en proposant une extension au langage CSS.


LESS permet d'adresser facilement des problématiques comme le support de thèmes dans les applications, la factorisation des styles, ...


Ces problématiques sont importantes pour la maintenance, l'agilité des applications webs , ...


Coder en LESS consiste à écrire des CSS en ajoutant des éléments syntaxiques nouveaux.


Au final, les navigateurs ne comprennent que le langage CSS. 


Il faut inévitablement passer par une phase de transformation LESS > CSS selon deux modes :

  • dynamique : sur le navigateur de l'utilisateur
  • statique : via un compilateur LESS, puis déployées de manière standard avec l'application 


Voici quelques une de ces extensions.


Les variables



Les variables permettent de factoriser des éléments de style très communs comme les couleurs par exemple. 


@some-color: #FF34AA;

#myid { color: @some-color; }
.myclass { color: @some-color; }


La compilation donnera la CSS suivante :

#myid { color: #FF34AA; }
.myclass { color: #FF34AA; }




Les mixins



Cette extension permet d'embarquer n'importe quelle classe qui définit un ensemble de style à l'intérieur d'une autre classe.



.margined {
  margin-top: 1em;
  margin-bottom:1em;
}
#banner a {
  color: black;
  .margined;
}
ul {  
  .margined;
}



La classe cible, l'id ou l'élément reçoit alors tous les styles définis dans la classe embarquée :

#banner a {
  color: black;
  margin-top: 1em;
  margin-bottom:1em;
}

ul {  
  margin-top: 1em;
  margin-bottom:1em;
}

De plus, les mixins peuvent être paramétrés !


.margined (@height:1em){
  margin-top: @height;
  margin-bottom:@height;
}


#banner a {
  color: black;
  .margined(1.5em);
}

ul {  
  .margined;
}


Donne :


#banner a {
  color: black;
  margin-top: 1.5em;
  margin-bottom:1.5em;
}

ul {  
  margin-top: 1em;
  margin-bottom: 1em;
}

Notez la valeur par défaut de l'argument @height !

Il est aussi possible de déclarer plusieurs arguments pour un mixin un peu comme pour une fonction.

 

Opérations



Les opérations permettent d'effectuer quelques calculs simples : addition, soustraction, multiplication, division.


Un petit exemple ici :

@simple: 5%;
@double: @simple * 2;
@halfdouble: @simple + @double;

color: #666 / 3;
background-color: @somecolor + #250;
height: 100% / 2 + @double;

A noter que LESS conserve les unités, ainsi 10px * 2 donne 20px.



Fonctions pour les couleurs



Ces fonctions sont très pratiques pour décliner un jeu de couleurs par exemple pour élaborer un thème.

Voici quelques exemples:


lighten(@somecolor, 30%);     // 30% plus lumineux que @somecolor 
darken(@somecolor, 30%);      // 30% plus sombre que @somecolor

saturate(@somecolor, 3%);    // 3% plus saturé que @somecolor
desaturate(@somecolor, 3%);  // 3% moins saturé que @somecolor




Pour conclure



Nous avons fait un petit tour d'horizon des fonctionnalités proposées par LESS.

Si vous souhaitez voir LESS en action dans un projet tout aussi intéressant je vous conseille de jeter un oeil sur Boostrap Twitter qui en fait un usage intensif.


J'ai peu utilisé LESS mais je trouve ce projet bien conçu et tout à fait indispensable.


Il serait très intéressant que les concepts LESS deviennent réellement une extension officielle de la norme CSS.


Le seul manque important à mon sens est l'absence d'outillage côté JEE pour la compilation des feuilles LESS.  


Il serait également intéressant de disposer d'une grammaire  ANTLR par exemple, qui permettrait de proposer un support des IDEs pour les fichiers LESS  : complétion, coloration syntaxique, ...

Mais nous verrons plus tard comment intégrer LESS côté serveur JEE grâce au moteur Javascript Rhino. 







Contrat Creative Commons
the jee architect cookbook by Olivier SCHMITT est mis à disposition selon les termes de la licence Creative Commons Paternité - Pas d'Utilisation Commerciale - Pas de Modification 3.0 Unported.