• les annotations de mapping
• les apis
• la sémantique (cascade …)
• et le  JP-QL

Plus d’infos sur le blog d’Emmanuel Bernard

Alors qu’au début, il n’y avait que Infinispan, on peut désormais y trouver MongoDB et Ehcache. D’autres types viendront surement. Ici, Ehcache est utilisé non pas comme un cache mais comme un datastore noSQL clé/valeur.

Configuration

Pour effectuer des insertions dans Ehcache via OGM, c’est vraiment simple. Après avoir ajouter la dépendance hibernate-ogm-ehcache à votre POM, il faut ensuite faut un fichier persistence.xml.

<persistence xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
version="2.0">

  <persistence-unit name="ogm-ehcache" transaction-type="JTA">
    <provider>org.hibernate.ogm.jpa.HibernateOgmPersistence</provider>
    <properties>
      <property name="hibernate.ogm.datastore.provider"
      value="ehcache"/>
      <property name="hibernate.transaction.jta.platform"
      value="org.hibernate.service.jta.platform.internal.JBossStandAloneJtaPlatform"/>
    </properties>
  </persistence-unit>
</persistence>

Note : Actuellement, les transactions, qui sont gérées de manière native par Ehcache, ne fonctionnent pas avec OGM.

Il faut ensuite instancier l’entityManager.

   Configuration cfg = new OgmConfiguration().
        setProperty("hibernate.ogm.datastore.provider", "ehcache").
        addAnnotatedClass(Appli.class).addAnnotatedClass(Platform.class);

    TransactionManager tm = getTransactionManager();
    EntityManagerFactory emf = Persistence.createEntityManagerFactory("ogm-ehcache");

    try {
      EntityManager em = emf.createEntityManager();

Many-to-One

Le modèle est le suivant : 2 classes, Appli et Perform.

 
@Entity @Indexed
public class Appli {
  @Id
  @GeneratedValue(strategy = GenerationType.TABLE, generator = "appli")
  @TableGenerator(
      name = "appli",
      table = "sequences",
      pkColumnName = "key",
      pkColumnValue = "apply",
      valueColumnName = "seed"
  )
  public Long getId() { return id; }
  public void setId(Long id) { this.id = id; }
  private Long id;

  public String getName() { return name; }
  public void setName(String name) { this.name = name; }
  private String name;

  @ManyToOne
  @IndexedEmbedded
  public Platform getPlatform() { return platform; }
  public void setPlatform(Platform platform) { this.platform = platform; }
  private Platform platform;
}

 
@Entity  @Indexed
public class Platform {

  @Id
  @GeneratedValue(generator = "uuid")
  @GenericGenerator(name="uuid", strategy="uuid2")
  public String getId() { return id; }
  public void setId(String id) { this.id = id; }
  private String id;

  @Field
  public String getName() { return name; }
  public void setName(String name) { this.name = name; }
  private String name;
}

On crée ensuite un objet learnAnimals de type Appli qui a pour plateforme itunes.

 Platform itunes = new Platform();
 itunes.setName("iTunes");
 Appli learnAnimals = = new Appli();
 learnAnimals.setName("J apprends les animaux" + i);
 learnAnimals.setPlatform(itunes);

On persiste de la meme manière qu’avec hibernate.

 tm.begin();
 em.persist(learnAnimals);
 Long leanAnimalsId = learnAnimals.getId();
 em.flush();
 em.close();
 tm.commit();

Et voilà, l’objet learnAnimals est persisté. Mais à la différence d’une persistance classique avec Ehcache, qui fonctionne par sérialisation/déserialisation des objets, le modèle est déshydraté.

tl;dr

Pour une entité, elle est donc stockée dans une store ENTITIES avec le modèle clé/valeurs suivant :
Clé
Chaque clé est de type EntityKey, classe qui contient entre autre :

private final String table;
private String[] columnNames;
private Object[] columnValues;

On aura par exemple : {table=’Appli’,columnNames=[‘id’],columValues=[‘1’]} pour l’appli qui a pour identifiant la valeur 1.

Pour la valeur, elle est construite sous la forme d’une map.
Ainsi pour un object Appli qui contient une Plateforme, la map aura cette forme :

Clé           |  Valeur
id            | 1
name          | monAppli
platform_id   | 65d2183a-3a73-4079-83fb-57f9072e0915

A l’insertion c’est un peu plus compliqué. On passera par des objets transitoires, des aggregats nommé TupleOperation qui contiennent le nom de la colonne, sa valeur et son type TupleOperationType, celui-ci pouvant prendre 3 valeurs, PUT, PUT_NULL et REMOVE.
On a donc en fait :

Key         | Value
id          | {columnName='id',columnValue='1'.columnType=TupleOperationType.PUT}
name        | {columnName='name',columnValue='monAppli'.columnType=TupleOperationType.PUT}
platform_id | {columnName='platform_id',columnValue='2886a75c-11ae-4f3d-a132-8d58010382b3'.columnType=TupleOperationType.PUT}

La valeur PUT indiquera qu’il faut faire un

  map.put( action.getColumn(), action.getValue() );

C’est à dire pour le premier exemple :

  map.put('id',1)

Un remove aurait entrainé une suppression de la paire clé/valeur. Un PUT_NULL fait la même chose qu’un PUT.

On a donc bien inséré en base  :

Clé           |  Valeur
id            | 1
name          | monAppli
platform_id   | 65d2183a-3a73-4079-83fb-57f9072e0915

On aura une entrée similaire dans le meme cache ENTITIES pour les objets de types Platform. Pour résumer, on a donc :

Map<EntityKey,Map<String,Object>>

La deuxième store est la store ASSOCIATION. Elle n’est utile que dans les relations plus complexes.On y reviendra par la suite. Dans ce cas, elle reste vide.

La troisième store est la store des IDENTIFIERS, qui stocke les informations relatives aux séquences, notamment toutes celles qui permettent de gérer de manière automatique les identifiants.

Many-to-Many

On définit maintenant une application comme pouvant être associée à N plateforme. Le modèle de Platform ne change pas, celui d’Appli légerement.

 
@Entity @Indexed
public class AppliManyToMany {
  @Id
  @GeneratedValue(strategy = GenerationType.TABLE, generator = "appli")
  @TableGenerator(
      name = "appli",
      table = "sequences",
      pkColumnName = "key",
      pkColumnValue = "apply",
      valueColumnName = "seed"
  )
  public Long getId() { return id; }
  public void setId(Long id) { this.id = id; }
  private Long id;

  public String getName() { return name; }
  public void setName(String name) { this.name = name; }
  private String name;

  @ManyToMany
  @IndexedEmbedded
  public List getPlatforms() { return platforms; }
  public void setPlatforms(List platforms) { this.platforms = platforms; }
  private List platforms=null;

}

En ce qui concerne la table ENTITY, elle est un peu modifié.
La clé reste identique, par contre l’enregistrement ayant pour clé platform_id n’existe plus. On a uniquement :

Clé           |  Valeur
id            | 1
name          | monAppli

L’association est désormais portée par un enregistrement dans la table ASSOCIATION.
La clé, de type AssociationKey, similaire à une EntityKey, représentant l’id 5 :
{table=’AppliManyToMany_Platform’, columnNames=[AppliManyToMany_id], columnValues=[5]}

La valeur est toujours une Map :
Clé (de type RowKey) : {table=’AppliManyToMany_Platform’, columnNames=[AppliManyToMany_id, platforms_id], columnValues=[5, 6301e8be-307f-4884-b3a1-5ec0dad7c3e5]}
Valeur (sous la forme d’une Map): {AppliManyToMany_id=5, platforms_id=2886a75c-11ae-4f3d-a132-8d58010382b3}}
On a donc une structure de la forme :

  Map<AssociationKey,Map<RowKey,Map<String,Object>>>

Pour cet exemple, il n’y a qu’une seule plateforme, celle qui a l’id 6301e8be-307f-4884-b3a1-5ec0dad7c3e5, ainsi, on a donc un unique enregistrement dans la map.

Si on prends un exemple où une application est associée à deux personnes (appli avec id= 6):
On pourrait avoir comme clé principale :
table=’AppliManyToMany_Platform’, columnNames=’AppliManyToMany_id’, columnValues=’6′

Puis comme value les couples clés/valeurs suivants :
RowKey 1 :
Clé (RowKey) : {table=’AppliManyToMany_Platform’, columnNames=[AppliManyToMany_id, platforms_id], columnValues=[6, b705d241-b6dd-4a81-9fb2-2f9f732530d7]}
Valeur associée (sous forme de map): {AppliManyToMany_id=6, platforms_id=b705d241-b6dd-4a81-9fb2-2f9f732530d7}
RowKey 2 :
Clé (RowKey) : {table=’AppliManyToMany_Platform’, columnNames=[AppliManyToMany_id, platforms_id], columnValues=[6, 2886a75c-11ae-4f3d-a132-8d58010382b3]}
Valeur associée (sous forme de map): {AppliManyToMany_id=6, platforms_id=2886a75c-11ae-4f3d-a132-8d58010382b3}

On a donc bien pour l’application 6 deux plateformes, la plateforme b705d241-b6dd-4a81-9fb2-2f9f732530d7 et la 2886a75c-11ae-4f3d-a132-8d58010382b3 . Le framework se servira des identifiants dans un deuxième temps pour retrouver dans la table ENTITIES les plateformes correspondantes et les ‘ajoutera’ dans la liste des plateformes de l’application id=6. Pour avoir une idée encore plus concrète, il y a des schémas dans la documentation d’OGM.

A venir : Hibernate Search, Lucene et autres recherches avec Hibernate OGM.

Minimiser le nombre de composants à déployer

Au niveau du déploiement,  la première bonne pratique est de minimiser le nombre de composants à déployer.  Ce qui ne veut pas dire qu’il faut déployer des applications monolithiques mais bien qu’il est important de chercher  et d’essayer de regrouper les composants de manière cohérente.
Il est courant pour le déploiement d’un unique EAR ou WAR de devoir dupliquer certains fichiers ou de devoir modifier certaines configuration sur d’autres serveurs. Chaque ‘micro-tâche’ de déploiement peut être source d’erreurs, moins il y en a plus il y a de chance que cela se passe bien ou que le retour en arrière soit aisé.

Ainsi, on peut retrouver la situation suivante : le contenu statique est contenu dans l’archive EAR avec l’ensemble du code nécessaire à l’application. Ce contenu statique sera dupliqué sur un serveur http simple dans une optique d’optimisation d’accès aux ressources statiques. On y accède via un filtrage des URLs en utilisant un mécanisme de routage en amont.

Cela fait donc 3 étapes pour une livraison :

• déploiement de l’application,
• déploiement des ressources statiques,
• mise à jour des règles de routages.

De plus, il est fréquent que le point de routage soit en plus sur un serveur mutualisé, ce qui augmente le risque d’impact de la mise à jour pour la web application déployée sur les autres applications dont les routes transitent par ce point de routage.  La principale raison évoquée est le fait de gagner en performance.
La proposition de Cyrille est d’utiliser le mécanisme de proxy-cache http, pouvant être facilement mis en place par l’équipe infrastructure  avec des outils tels que que Varnish Cache, squid, ibm Fast Response Cache Accelerator (FRCA) voir un simple module apache http comme mod_cache.
Il n’y a plus de déploiement des fichiers sur un serveur statique, plus de besoin de modifier les règles de routage.
Un autre exemple sur la nécessité du regroupement des différentes briques par cohérence est le double filtrage lié à la sécurité. Il est fréquent d’avoir en amont un premier filtrage par adresse IP puis dans un deuxième temps un filtrage sur un couple login/mot de passe. L’idée est dans ce cas de regrouper ses deux actions ensemble, que ce cela soit sur le firewall, en java ou autre mais à un même point . De plus, cela permet également de pouvoir faire un filtrage par login et par adresse IP en même temps c’est à dire de contrôler par exemple que le login ‘admin’ ne puisse être utilisée que par l’adresse IP X et l’adresse IP Y.

Cohabiter en bonne intelligence

Sur un même serveur physique

Le deuxième aspect du déploiement abordé est sur le fait de cohabiter en bonne intelligence.  Au niveau de la cohabitation de plusieurs applications sur un même serveur, les  recommandations sont simples :
Minimiser les répertoires absolus et faire en sorte que chaque fichier soit dans un répertoire préfixé par un identifiant d’application (possible d’utiliser le group id et l’artifact id du composant par exemple ou plus simple /etc/my-application.
Organiser l’utilisation des ports réseaux en séparant un préfixe definissant l’application et un suffixe définissant le service par exemple, si 100 correspond à l’application Facture, on aura le port du serveur http sur 10080, le port du SSL sur 10043. Cette séparation permet de faire cohabiter de manière organisée 100 applications.

Sur un même serveur d’application

En ce qui concerne la bonne cohabitation sur un même serveur d’application, il faut de la même manière minimiser les répertoires absolus (c’est à dire privilégier les chemins relatifs comme (${java.io.tmpdir}/my-app1/) et les rendre lisible en les préfixant par l’artifact id (et le group id si besoin) pour empêcher les collisions entre répertoire.
Cyrille recommande également de limiter au maximum les variables java statiques qui impactent l’ensemble du serveur, il vaut mieux les définir par application.
Au niveau des paramètres de configuration, la question est posée de savoir si il vaut mieux mettre les fichiers de configuration directement dans l’archive ou au contraire de les externaliser. La décision dépend de la situation, par exemple, si l’équipe d’exploitation ne désire pas que l’équipe de développement possède les accès base de données, la configuration se fera à l’extérieure de l’application.
Une autre recommandation au sujet des paramètres de configuration est de limiter le nombre de paramètres dont la valeur change suivant les environnements : en isolant ses réseaux virtuels, il est possible de conserver des noms de bases de données identiques, de conserver les noms de hosts.

Dans le cas où l’équipe d’exploitation propose d’utiliser des noms incluant par exemple les différents environnements ex : monappli-dev , monappli-rec, ma-bdd-dev, ma-bbd-rec il est possible de proposer un compromis avec la création d’alias. La multiplication des paramètres de configuration est souvent source de problème lors des déploiements. De même, il n’y a pas lieu de faire changer les ports d’écoute.
Cette recommandation impose qu’il n’y ait pas de perméabilité entre les zones de développement, de recette et de production. Dans une précédente mission, il suffisait d’utiliser foxy-proxy, plugin firefox de configuration de proxy pour switcher automatiquement de mon application web de prod vers mon application web d’homologation. Dans ce cas, l’homologation était fermée, impossible d’avoir accès à Internet par exemple. Il est également conseillé, par sécurité, de modifier par exemple le logo sur l’homologation ou de jouer avec des codes couleurs pour indiquer de manière visuelle l’environnement sur lequel on se trouve mais aussi d’ajouter un filtrage sur les ip appelantes (bloquer les ips ou changer les mots de passes). A l’aide des .profile, il est possible d’indiquer directement sur la console ‘prod’ ou ‘valid’, avec putty de changer les couleurs etc.

Savoir ce qui est réellement déployé

Un autre point important du déploiement est de déployer des composants qui soient réellement traçables. On ne déploie que des composants taggés sur lesquels aucun commit n’aura été effectué (règle d’entreprise respectée/ utilisation de la fonctionnalité d’hook pour SVN) et/ou on empêche le redéploiement ( utilisation de la fonctionnalité Disable Redeployement de Nexus)) pour pouvoir connaître avec précision les classes déployées.   Des outils comme Nexus ou Archiva permettent facilement de déployer des archives sur différents environnements en garantissant leur conformité.

Voilà les différents axes abordés sur la partie ‘déploiement’, la présentation, qui a durée 2 heures environ et a abordé 5 axes différents (seul le premier a été présenté ici), a été dense ! Pour ceux que cela intéresse plus en détails, Cyrille devrait publier ses slides dans quelques semaines et organisera à la mi mai une formation de 2 jours sur le thème. Pour le suivre sous twitter : @Cyrilleleclerc .