vendredi 25 novembre 2011

JSF JQuery Mobile archetype updated with JQuery Mobile 1.0 !


I'm proud to announce a new release of a maven archetype for JSF JQuery Mobile dev !
Updates are :
  • JQuery 1.6.4
  • JQuery Mobile 1.0
It's a quick start (tested with Maven 2.1.0, 2.2.X, 3.X) and runs at least with Glassfish 3.1.1, Tomcat 7, Tomcat 6.
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.

vendredi 11 novembre 2011

Riding the Camel : the beginning


Camel is an Apache project : it's a wonderful toolbox to write applications dealing with integration problems.

Integration problems ? Not me !


What does Camel really mean by claiming itself an integration framework ?
Well, it means that you can use Camel as a ground to support common use cases in information system (IS) integration :
  • take datas from one place (file, FTP, HTTP, JMS, ...) to another (memory, file, FTP, HTTP,JMS, ...) to another with or without transformations
  • manage asynchronous exchange from one point to another in your IS
  • open routes inside your IS to establish bridges between isolated zones
  • expose webserivce in a standard way : REST, JAX-WS
  • communicate with other ISs
  • ...

Integration problems ? Me too !


Camel can be used inside your application (batch, webapp, ...) for various needs not marked as "integration problems":
  • reading CSV file to object
  • support asynchronous processing : a massive business request for printing datas, ...
  • executing system commands
  • search in a LDAP repository
  • ...

A quick ride with Camel


Camel implements Enterprise Integration Patterns. EIPs are a bible of pragmatic solutions to common integration problems : how to transport and route messages in IS.
It sounds like ESB stuff, quite foggy and complicated but Camel deals with all this in a pragmatic, lightweight and smart way.
First of all Camel does not claim itself an ESB.
Yes, you can find some core ESB features in Camel, that's not the point !
Most vehicles share same basic components but is a Ferrari a Hummer ?
So now, here is a simple use case :
A web application must display earthquakes that have occured world wide in the last seven days.
Datasource is provided by US Gov and is updated continously : a minute based update will suffice.

The datasource is here.
So, how can Camel help me ?
Well, Camel is provided with lots of components dealing with lots of protocols and proposing few useful concepts.
Here is the core "integration" code :
from("quartz://dataTimer?cron=0+*+*+*+*+?").to("direct:datas");
from("direct:datas")
        .to("http4://earthquake.usgs.gov/earthquakes/catalogs/eqs7day-M1.txt")
        .unmarshal().csv().process(new Processor(){
                public void process(Exchange exchange) throws Exception {
                        Message message = exchange.getIn();
                        List<List<String>> datas = (List<List<String>>) message.getBody();
                        // Skip header
                        datas = datas.subList(1, datas.size()-1);
                        // Process my data
                        for(List<String> row:datas){
                                // Process Row
                                String datetime = row.get(3);
                                String region = row.get(9);
                                String magnitude = row.get(6);
                                // Do something smart
                        }
                }
});
This sample code shows you Camel core concepts.

Core concepts


Camel is a routing and a mediation engine: routing is about to transport informations from one place to another.
It means that Camel uses the Route concept to interact with its environment.
Route concept defines a way to process informations from Endpoint toEndpoint, it has a start and an end, like a real world route.
Informations are encapsulated into Exchange : in and out informations are stored in Message objects inside an Exchange.
Camel Endpoint is an implementation of Message Endpoint Pattern. SomeEndpoint receive Exchange from outside the Route to which they belong, some produce exchanges into the Route by themselves, some make both.
Endpoints in Camel are represented by their URI : an Endpoint URI tells about the endpoint nature and configuration.
And Endpoint is created by a Component: a Camel component is an Endpoint factory.
When Camel tries to solve an Endpoint URI, it picks up the Component associated to the URI protocol part and asks the Component for creation of the Endpoint.
For instance : quartz://dataTimer?cron=0+*+*+*+*+?
Tells Camel to find a Component knowing how to deal with "quartz" protocol. When the Component is found, Camel asks it to create the Endpoint with the URI. If it succeeds Endpoint is added to the current Route.
The sample code shows us basic use of RouteBuilder. RouteBuilder is a very convenient tool to build routes. It's a Java DSL who tries to hide complexity by providing an API close to fluent language.
from("quartz://dataTimer?cron=0+*+*+*+*+?").to("direct:datas");
This line creates a new RouteDefinition object (using the URI), and then invokes "to" method on RouteDefinition object.
The first URI tells us that the Quartz Component is involved.
The last URI shows the Direct Component usage.
This line creates a route based on Quartz and Direct components.
The quartz endpoint will produce an exchange every minute and send it to the next endpoint which will send the exchange to the "datas" endpoint in a synchronous way.
As you can guess this first route is about to trigger the polling of datas through the second route, every minute.
Now:
from("direct:datas")
        .to("http4://earthquake.usgs.gov/earthquakes/catalogs/eqs7day-M1.txt")
        .unmarshal().csv().process(new Processor(){
                public void process(Exchange exchange) throws Exception {
                        ...
                }
});
This line creates a route with the first endpoint as "direct:datas".
The "to" method creates an endpoind based on HTTP4 component and returns aProcessorDefinition[7] object.
When activated by an incoming exchange, this endpoint will issue an HTTP request to get the datas and send an exchange including datas to the next endpoint. The default format is byte array.
Here there is no endpoint after polling datas.
The unmarshal method invoked on a ProcessorDefinition object adds aDataFormat to this processor definition and tells Camel to use this data format to process the "in" value of current exchange.
Then the "csv" method says it is csv dataformat. It uses Camel CSV Dataformat.
It goes like this :
Create route -> Create endpoint datas as a synchronous endpoint -> Get earthquake.usgs.gov/earthquakes/catalogs/eqs7day-M1.txt -> Process datas as CSV -> Invoke custom processor
This article is not provided with complete source code because i want you to understand basic Camel concepts.
Here is a diagram of some Camel core concepts :



The next article will show many ways to integrate Camel in your (mavenized) app.





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 24 septembre 2011

How to fresh up an old API and make it look concise, productive, clean (at last !) ?


I'm an architect of JEE framework we call Orion (MVC, IOC, Persistence, Transaction, Logging, ...).
It's an old one, we started with JDK 1.4 seven years ago.
Some parts of the Orion API are quite heavy and suffers from youth defects, but they perform well .
This API provides a way to create a Query with standard concepts : conjunction, disjunction, operators, joins, ...
Here is a use case : ask the datasource for "people with name starting with a 'D' and living in 'PARIS' "
Query query = new Query();
query.setClazz(People.class);
query.setDistinct(true);
Conjunction and = new Conjunction();
and.addExpression(new SimpleExpression(new Criterion("name"),new StartsWith(),new Parameter("D")));
and.addExpression(new SimpleExpression(new Criterion("place"),new Equals(),new Parameter("PARIS")));
query.setExpression(and);
If i could rewrite some parts of this API, i'd do it right now.
But there are many applications depending on this old,heavy API.
So what can i do to bring an elegant, concise, productive way of using this API without changing the API ?

Internal DSL

An internal DSL can improve dramatically an API usage.
Internal DSL means that we use a real programming language, like Java, to build a small set of API to support a specific domain.
DSL is a hot and huge subject but can be very simple in practice.
Our use case (the Orion API) is elegantly supported by an internal DSL pattern : the Expression Builder pattern.

Improving query manipulation

Here we go with QueryBuilder class:
public class QueryBuilder {
    
    private Query query;
    
    public QueryBuilder(){
        this.query = new Query();
    }
    
    public Conjunction and(Expression ...expressions){
        Conjunction conjunction = new Conjunction();
        for(Expression expr:expressions){
            conjunction.addExpr(expr);    
        }
        return conjunction;
    }
    public Disjunction or(Expression ...expressions){
       Disjunction disjunction = new Disjunction();
        for(Expression expr:expressions){
            disjunction.addExpr(expr);    
        }
        return disjunction;
   }
   
   public SimpleExpression equals(String name,Object value){
       return new SimpleExpression(new Criterion(name),new Equals(),new Parameter(value));
   }
   
   public SimpleExpression startsWith(String name,Object value){
       return new SimpleExpression(new Criterion(name),new StartsWith(),new Parameter(value));
   }
   
   public QueryBuilder where(Expression expression){
       this.query.setExpression(expression);
       return this;
   }
   
   public QueryBuilder distinct(){
       this.query.setDistinct(true);
       return this;
   }

   QueryBuilder clazz(Class aClass) {
       this.query.setClazz(aClass);
       return this;
   }

   
   Query getQuery(){
       return this.query;
   }    
}
Now, the same Query but built using our DSL :
QueryBuilder qb = new QueryBuilder();
qb.clazz(People.class).where(
      qb.and(
               qb.startsWith("name","D"),
               qb.equals("place", "PARIS")
               
)).distinct();
Query query = qb.getQuery();
The DSL version is much more readable. It hides the process of created a query to focus on user need : to express easily a query.
A more complex sample :
QueryBuilder qb = new QueryBuilder();
qb.clazz(People.class).where(
      qb.and(
               qb.startsWith("name","D"),
               qb.equals("place", "PARIS"),
               qb.or(
                   qb.equals("role", "admin"),
                   qb.equals("role", "manager")
               )                
      )
).distinct()
Finally, i can keep my old API and offer an easy way to implement most common use cases. I can improve my builder : it can accept an existing query and act as a deluxe wrapper.
Your turn !!!




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.

A Maven archetype quick start for JSF JQuery Mobile dev !


I'm proud to announce the release of a Maven archetype for JSF JQuery Mobile dev !
It's a quick start (tested with Maven 2.1.0, 2.2.X, 3.X) and runs at least with Glassfish 3.1.1, Tomcat 7, Tomcat 6.
mvn archetype:generate -Dfilter=jqmobile -DarchetypeCatalog=http://oss.sonatype.org/content/repositories/releases/archetype-catalog.xml
This artefact should be available very soon from Maven Central repository, so the archetypeCatalog argument will be useless.
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 17 septembre 2011

L'accessibilité est-elle l'amie du développeur ?


Depuis quelques années, le nombre de navigateurs se multiplient avec les plateformes (PC, Netbook, Smart Phone, Tablet, ....) et de plus en plus de personnes de tous âges et de toutes conditions ont accès à Internet.
Nous développeurs serons-nous capable de répondre aux attentes de tous nos utilisateurs ?
Les applications webs sont-elles réservées à une élite dotée des meilleures capacités physiques et cognitives ?
L'accessibilité peut nous aider à construire des applications ouvertes au plus grand nombre tout en ayant des effets de bords positifs sur les performances, la maintenance et la qualité des applications.
En effet, dans le contexte d'une refonte de notre cadriciel web maison, j'ai du mener une étude pour mesurer les impacts de l'application de règles d'accessibilité. Les résultats de mon étude montre que l'accessibilité doit être au coeur du processus de développement.

WCAG 2.0 : l'accessibilité appliquée au web


Le consortium W3C propose la norme WCAG pour l'accessibilité des contenus webs aux personnes en situation de handicap.
Un handicap est selon Wikipedia :
la limitation des possibilités d'interaction d'un individu avec son environnement, causée par une déficience qui provoque une incapacité, permanente ou non et qui mène à un stress et à des difficultés morales, intellectuelles, sociales ou (et) physiques.
Nous baserons nos réflexions sur cette norme qui définit 4 grands principes à respecter :
  • Perceptible : l'information et les composants de l'IHM doivent être présentés à l'utilisateur de façon à ce qu'il puisse les percevoir.
  • Utilisable : les composants de l'IHM et de navigation doivent être utilisables.
  • Compréhensible : rendre le contenu textuel lisible et compréhensible.
  • Robuste : optimiser la compatibilité avec les agents utilisateurs actuels et futurs, y compris les technologies d'assistance.
Chaque principe est décliné en plusieurs règles d'accessibilité à respecter. Chaque règle est associée à un niveau d'accessibilité : A, AA ou AAA.
Plus le niveau est élevé plus la règle est complexe et coûteuse à implémenter.
Evidemment, l'utilisation d'un cadriciel web supportant WCAG et un niveau d'accessibilité donné (AA par exemple) est un atout déterminant pour la mise en oeuvre du référentiel WCAG dans vos applications webs. Le cadriciel permet alors d'absorber une grande partie des coûts.

Mise en oeuvre du WCAG


Il est important de comprendre qu'il ne faut pas appliquer bêtement ce référentiel.
Tout d'abord, il convient de choisir un niveau d'accessibilité pour vos contenus webs. D'ailleurs, plusieurs niveaux d'accessibilité peuvent coexister au sein d'une application web qui regroupe des contenus différents.
En effet, il peut être plus judicieux de proposer un niveau AA pour les contenus les plus populaires, un AAA sur les quelques contenus critiques puis un niveau A sur la majorité des contenus , plutôt que de se fixer un niveau AA sur tous les contenus.
Le référentiel WCAG est accompagné d'un guide technique qui propose des solutions pour la mise en oeuvre de chaque règle.
Il est aussi crucial de comprendre que la mise en oeuvre du WCAG doit se faire dès la conception de l'application.
Quelque exemples de règle :
  • Règle 1.4.3 (AA) : la présentation visuelle du texte et du texte sous forme d'image a un rapport de contraste d'au moins 4,5:1
  • Règle 1.4.4 (AA) : à l'exception des sous-titres et du texte sous forme d'image, le texte peut être redimensionné jusqu'à 200 pour cent sans l'aide d'une technologie d'assistance et sans perte de contenu ou de fonctionnalité.
  • Règle 3.3.1 (A) : si une erreur de saisie est détectée automatiquement, l'élément en erreur est identifié et l'erreur est décrite à l'utilisateur sous forme de texte.
  • Règle 4.1.1 (A) : à moins que les spécifications ne le permettent, dans un contenu implémenté via un langage de balisage, les éléments ont des balises de début et de fin complètes, ils sont imbriqués conformément à leurs spécifications, ils ne contiennent pas d'attributs dupliqués et chaque ID est unique.
Si tous les développements sont faits quand vous essayez d'appliquer le référentiel alors vous serez contraints de revoir la totalité des contenus webs .
Ceci implique que l'équipe de développement, du chef de projet au développeur doivent connaître les règles à appliquer avant de commencer à développer l'application.
Comme on vient de le voir, l'accessibilité a un impact important sur l'équipe de développement.
Mais quels sont les bénéfices que vous pouvez en tirez ?

Les coûts de développement et de maintenance


Certaines règles (1.3.1, 1.4.5, ...) vous contraignent à séparer la présentation de l'information, de l'information elle même. Cela se traduit par une utilisation de feuilles CSS et de XHTML.
Très vite on en vient à envisager la mise en place de thèmes basés sur CSS car si l'on veut présenter de l'information pour des publics différents au moindre coût (daltonien, mal voyant, normal, smartphone, tablet, ...), c'est la bonne pratique à mettre en oeuvre.
Cette factorisation des éléments de présentation dans les CSS permet d'avoir un code XHTML plus clair et de cibler les changements sur quelques CSSs plutôt que de revoir chaque contenu HTML ou XHTML de l'application.
Certaines règles mettent en avant le respect de la syntaxe XHTML (4.1.1) ou l'ajout de méta données (4.1.2), ceci permet l'utilisation d'outils de validation ou transformation.
En effet, imaginez que votre application contient des composants de type "Calendrier" traduit en XHTML sous la forme d'un amas de DIV.
En utilisant l'attribut role vous allez indiquer que cette zone avant informe correspond à un composant graphique de type calendrier :
  <div id="cal1"  role="calendar" ...>
     <!Code XHTML >
  </div>
Ce faisant vous ouvrez la voie à des applications intéressantes comme la transformation de contenu XHTML.
Imaginez que votre client vous demande de revoir la charte graphique et ergonomique de l'application, vous pourrez ainsi utiliser une transformation des composants XHTML par une technologie quelconque qui supporte XHTML et XSLT.

Les performances


Certaines règles poussent à privilégier l'utilisation de texte plutôt que d'images ce qui réduit le nombre de requêtes HTTP et diminuent l'utilisation de la bande passante :
  • l'information véhiculée par du texte est nettement plus compressible que les images.
  • avec la diminution du nombre de requêtes HTTP, vos serveurs seront moins sollicités.
D'autres règles promeuvent une navigation claire ainsi que des mécanismes de navigation et d'interactivité maîtrisés par l'utilisateur. En effet, nombre de site web proposent des contenus qui multiplient les requêtes via des composants qu'IHM que l'utilisateur subit.
Quelques règles impliquées dans l'amélioration des performances : 1.4.5, 3.2.5, ....

Conclusion


L'accessibilité est un élément fondamental des applications webs. Pour être sans douleur, elle doit être prise en compte dès la conception et doit structurer la réalisation ou la maintenance de tous les éléments d'IHM.
Quelques références :



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.