eP-Core est le module d'accès à la BD. Ce module permet d'obtenir les objets Java représentant les données de la BD ePims ainsi que les services permettant d'agir sur ces objets. Ce module est déployé de façon indépendante sur le serveur d'application Java Geronimo afin d'être utilisé et partagé par les autres modules de présentations et de service du système.

Figure 1 Architecture globale de l’application

Le schema représente la totalité de l'application ePims. eP-Core représentele noyau de cette application, il ne contient pas ce qui se rapporte à la couche présentation càd interfaces Web, il constitue le point d’accès aux données de l’application ainsi qu’aux actions sur ces données (création, modification, suppression) au travers d’interfaces accessibles par toutes les couches de l’application.

Comme indiqué sur ce schéma, les technologies utilisées dans l'application ePims sont les suivantes:

• Les JSP/JSF sont utilisés pour la partie présentation
• Au niveau de la logique applicative, on utilise le framework Spring qui est un conteneur léger et qui permet, d’une part, d’isoler les différentes technologies utilisées et faciliter ainsi la substitution d’une implémentation par une autre, d’autre part, Spring prend en charge la partie transactionnelle de O/RM.
• Hibernate a été choisi pour la partie O/R Mapping. Ce framework a, entre autres, l’avantage de s’interconnecter facilement avec Spring.

Les cibles Ant principales définies pour eP-Core sont :

• configure.dist : Configure le projet pour une distribution de production (copie des fichiers de configutations, mise en place de librairies…)
• compile.dist : compile les classes Java et appel configure.dist.
• configure.test : Même configuration que précédement mais utilise les fichiers de configuration pour exécuter les tests JUnit.(appel de configure.dist)
• compile.test : compile les classes Java et appel configure.test.
• configure.dev : Même configuration que configure.dist mais utilise les fichiers de configuration pour le mode développement.(appel de configure.dist)
• compile.dev : compile les classes Java et appel configure.dev.
• dist : créer une distribution de ep-Core comme module geronimo … appel toutes les cibles nécessaire à cette création
• dist.dev : idem dist mais appel compile.dev au lieu de compile.dist.
• dev.create.onejar : Temporaire ! Créer un seul .jar contenant toutes les librairies (lib/*) ainsi que eP-Core.jar créer lors d'une execution de dist. N'appèle pas dist qui doit donc avoir été exécuté avant !
• publish.libs : a exécuter après un dist. N'appèle pas dist qui doit donc avoir été exécuté avant ! Copie dans un sous-répertoire défini par la propriété <ivy.distrib.dir> toutes les librairies nécessaire a eP-Core et eP-Core. Ceci afin de permettre a eP-Web, par exemple, de référencer ces librairies sans les intégrer. En effet; dans la distrib finale d'eP-Web (ou autre module de l'application J2EE) ne doit pas intégrer eP-Core mais référencera cette librairie intégrée a Geronimo.

Cette section décrit l’organisation des packages ainsi que les points d’interaction entre les objets des différents frameworks.eP-Core ne concernant pas tout ce qui se rapporte à la partie présentation, seuls les objets de persistance de données et ceux propre à la logique applicative sont définis.

Figure 2 Diagramme de classe globale

• Les objets du package BO (BusinessObject) représentent les données du model (en l’occurrence celles de la base de données). Ces objets ne contiennent que des informations (des attributs) mais pas de ‘comportements’. Ils sont accessibles dans toutes les couches de l’application.
• Le package DAO contient les classes qui ont la charge de la persistance des données (utilisation du framework Hibernate). Seules les interfaces doivent être accédées afin de permettre tout changement d’implémentation de manière transparente. En effet, le framework Spring permet de spécifier (aux classes services) la classe d’implémentation via le mécanisme d’inversion de contrôle (IoC) par injection par accesseur : utilisation d’un fichier de configuration et accès aux setter méthodes. Spring prend également en charge la gestion des sessions/transactions pour Hibernate : les classes DAO doivent étendre la classe HibernateDaoSupport qui prend en charge les accès JDBC.
• Le package Service contient les interfaces qui doivent être utilisées par toutes les autres applications (ou couches) afin de manipuler (créer, modifier, supprimer) les objets de données. Les classes d’implémentation des services doivent définir des setter méthodes pour les classes DAO afin d’être configurées par Spring (voir paragraphe précédent).

En résumé, la couche model rend visible d’une part les objets représentant les données (package BO) et, d’autre part, les interfaces Services qui permettent de manipuler ces données.

On retrouve donc dans les fichiers de configuration xml : (spring-*.xml)

• La définition de la dataSource utilisée par Hibernate pour accéder à la DB.
• La définition des différentes propriétés propres à Hibernate (mapping files…)
• La définition des dao : description des beans et spécification de la propriété hibernateTemplate.
• La définition des services : description du bean et spécification des propriétés qui seront positionnées via les accesseurs.

REMARQUE : ServiceLocator recherche dans l’ApplicationContext qui lui est spécifié les beans correspondants à l’implémentation de IXXXService (définit dans spring-*.xml).