Adam Bien est venu présenter sa vision de l’architecture Java EE lors de la session de Juillet du Paris JUG. Ce premier article présente la première partie de la soirée, plutôt dédiée aux concepts et à la théorie.
Les applications développées sous la plateforme JEE 6 sont maintenant très légères. On est loin de l’ancienne affirmation “les EJBs sont très lourds” ; celle-ci fait désormais partie du passé. Adam Bien a démontré la puissance de la plateforme et il nous a donné envie de la réapprendre, surtout avec la deuxième partie de la conférence qui a été entièrement pratique comme il nous l’avait promis. Le niveau du contenu théorique a été assez avancé. Nous vous conseillons la lecture, ou relecture rapide, de l’article précédent – Adam Bien / JEE6 / Architecture – où vous est présenté Adam et dans lequel on vous plonge dans le contexte; ensuite vous pourrez repasser à cette partie plus détaillée qui s’appuie sur les concepts déjà traités.
Commençons par la théorie des architectures !
Grâce aux design patterns comme “Convention over Configuration”, l’injection de dépendances et les annotations, l’architecture des applications JEE6 est considérée LIGHTWEIGHT ! Que signifie “lightweight” ? Lightweight indique que l’architecture est rapide, simple, petite, légère, “facile”, lean (maigre) et qu’elle facilite le développement itératif et incrémental des applications d’entreprise.
Notez que le mot facile se trouve entre guillemets : Attention ! On peut mettre en péril la réussite des projets si on sous-estime les difficultés et challenges lors du design et de l’implémentation sous JEE6. Comme on l’avait déjà évoqué dans notre article précèdent, afin de répondre aux besoins réels des applications d’entreprise, on nous propose deux approches d’architecture opposées :
Adam utilise l’acronyme SOA afin de faciliter la compréhension, mais il a aussi souhaité faire la distinction en utilisant les termes “Design Piloté par le Service” car le concept SOA a un sens encore plus large. Concept apparu après l’EAI (“Enterprise Application Integration”), le SOA essaie de répondre aux besoins d’intégration et d’architecture au sens global. Avec le SOA on regarde le système d’information d’une entreprise comme un groupe de services au lieu de un groupe d’applications comme avec son précurseur EAI. Il existe aussi une nouvelle approche, ROA (Ressource Oriented Architecture), qui nous parle d’un vision ressource. Mais au delà des concepts, il faut du travail pour la réalisation des applications !
Les deux types architectures décrits par Adam – DDD et SOA – sont des designs que l’on peut choisir pour développer les applications, et les deux s’appuient sur le pattern ECB comme l’on va voir ci-après. Le pattern ECB existe depuis longtemps et il est indépendant de la plateforme JEE6 (ce n’est pas un pré-requis).
Similaire au pattern MCV (Model View Contrôler), il n’est pas consacré qu’à la couche présentation. Il est composé de trois éléments : Entity, Control et Boundary
.
‘Entity’ : Élément persistent et passif (il a besoin d’un contexte d’exécution pour fonctionner) qui contient non seulement les données persistantes mais également une partie de la logique métier.
‘Control’ : Élément orchestrateur qui implémente un scénario donné. Il orchestre les entités pour récréer un scénario fonctionnel particulier, mais la logique métier propre à chaque type d’entité reste encapsulée dans l’entité.
‘Boundary’ : Élément qui se trouve en périphérie du système ou sous-système et s’occupe de la communication. Certains Boundarys s’occupent de l’entrée au système depuis l’extérieur (front-end) ; les autres fournissent la sortie (back-end).
Sur ce point, se pose une question importante : Avez-vous compté le nombre de couches ? Il y en a deux. La couche “Boundary”, et la couche “Business” qui contient les éléments de contrôle et les entités.
Oui, la couche DAO a disparu pour les opérations CRUD, mais elle sera encore là. Pourquoi ? La réalité est qu’on aura besoin des DAO dans la plupart des applications afin de respecter le principe DRY (Don’t Repeat Yourself) et la séparation des responsabilités. Une application classique réalise les mêmes opérations constamment. Sans un DAO dédié, les queries répétées seront arrosées par toute la couche business et cette duplication du code réduira considérablement la maintenance.
Pour bien expliquer ce point : il s’agit simplement de ne plus jamais créer les DAO par défaut et uniquement parce que ce design pattern du catalogue J2EE le dit. Le pattern DAO n’est plus considéré la meilleure pratique à mettre en place. Aujourd’hui on va plutôt travailler en refactoring : Identifier le code dupliqué dans la couche business pour après le factoriser dans un DAO. Sans duplication de code, mieux vaut déléguer directement à l’EntityManager depuis la couche business. Une couche DAO sans un vrai besoin augmentera l’effort de maintenance (plus de code, plus de tests) sans apporter une réelle valeur ajoutée.
Grâce aux generics, à partir du JDK 5 nous pouvons utiliser une couche DAO générale et très puissante qui fournira une API transverse aux applications. Ainsi, pour vous illustrer cela avec un peu de code :
@Stateless
@Local(CrudService.class)
@TransactionAttribute(TransactionAttributeType.MANDATORY)
public class CrudServiceBean implements CrudService {
@PersistenceContext
EntityManager em;
public T create(T t) {
this.em.persist(t);
this.em.flush();
this.em.refresh(t);
return t;
}
@SuppressWarnings("unchecked")
public T find(ClLibraryass type,Object id) {
return (T) this.em.find(type, id);
}
public void delete(Object t) {
Object ref = this.em.getReference(t.getClass(), t);
this.em.remove(ref);
}
public T update(T t) {
return (T)this.em.merge(t);
}
public List findWithNamedQuery(String namedQueryName){
return this.em.createNamedQuery(namedQueryName).getResultList();
}
[...]
}
Dans ce code on voit un Service DAO qui est implémenté par un EJB @Local et @Stateless. On injecte le contexte persistent (@PersistentContext) et EntityManager. On utilise les génériques <T> pour factoriser le code qui est commun à n’importe quelle entité. CrudService est l’interface qui sera exposé au client.
Comme on verra dans notre article suivant, l’utilisation des interfaces avec les EJBs n’est plus obligatoire. Dans ce point de la conférence, un débat a commencé : Est-il une bonne pratique le développement Interface + Implémentation ? Réaliser systématiquement une implémentation interface + classe ajoutera des fichiers à maintenir, et rendra l’application moins légère et l’API plus complexe. L’idée d’une interface est d’exposer une API et cacher l’implémentation. Par conséquent, si une classe ne changera pas d’implémentation, l’utilisation des interfaces n’apportera aucune valeur. Si l’API ne sera jamais exposé au client, non plus. Sur ce point, lors de la partie questions/réponses, deux bonnes pratiques ont été évoquées :
Aussi l’usage de designs patterns comme “Strategy” imposent l’utilisation des interfaces. Ensuite, avec ECB en tête, Adam est passé à l’implémentation de deux approches opposées : l’architecture pilotée par le domaine et l’architecture pilotée par le Service.
Comme vous pouvez constater dans l’image, les deux approches basent leur architecture sur le pattern ECB. 
Afin de ne pas répéter notre article précèdent, et d’expliquer facilement le diagramme, voici un tableau récapitulatif.
Piloté par le Domaine vs Piloté par le service
| DDD (Domain Driven Design) | SOA (Service Driven Design) | |
| Principal | Domaine (Entity) | Service (Control) |
| Programmation | Cherche l’orientation objet pure | Approche procédural |
| ECB – Entity | PDO – Persistent Domain Objet. Contient du logique métier. Les entités ont leur état encapsulé et un comportement bien précis (true objects) | Anemic Object Model – Structure de données sans comportement qui expose son état à partir des modificateurs (get/set). Ne contient aucun logique métier |
| ECB – Control | Ne contient quasiment pas de logique métier. Très léger, parfois inexistant. | Implémente toute le logique métier. |
| ECB – Boundary : | Gateway – Expose et manage les entités (PDO). Nature Stateful (EJB @Stateful) | Façade – Cache les entités derrière les services. Nature Stateless (EJB @Stateless) |
| Nombre de couches : | 2 couches, pas besoin de DTO (Data Transfert Object) | plus de 2 couches. besoin de DTO (Data Transfert Object) |
| La couche DAO : | utilise la stratégie décrite précédemment | utilise la stratégie décrite précédemment |
| S’intègre bien avec : | REST | SOAP |
La vaste majorité des application J2EE / JEE existantes ont été développées avec l’approche procédural d’orientation au service. Avec les EJBs 2.x, penser à l’approche DDD n’était pas seulement une aberration, mais était quasiment impossible due à la complexité.
Les deux architectures opposées sont des meilleures pratiques dans des contextes particuliers. Ne soyons pas sectaires et restons ouverts aux deux approches. Dans la pratique, la plupart des projets du monde réel auront besoin d’une architecture mixte.
Adam a voulu nous transmettre un message aussi important que l’effet de connaître les frameworks du marché et les design patterns.
« Pensez toujours au vrai besoin, au contexte et à la valeur ajoutée »
Une architecture en 5 couches dans la pratique n’apportera aucune valeur si notre application reste monolithique. Grâce aux nouveautés de JEE 5 et 6, on peut réaliser des applications beaucoup plus légères qui répondront au vrai besoin. Rappelons-nous qu’on n’applique pas les designs patterns pour le plaisir, mais pour répondre au besoin et pour obtenir une valeur ajoutée.
« Rester petit mais penser grand »
Lorsqu’on est confronté à la réalisation d’une architecture, il est très important de bien identifier les cas d’évolutions probables auxquels l’application sera sujette. Dans ce contexte, on ne doit cependant pas réaliser le design d’une architecture en assurant toutes les possibilités d’évolution pour anticiper tous les besoins possibles, auquel cas on risque de rester éternellement dans la phase « design » sans en réaliser le développement. En anticipant seulement les besoins les plus probables on pense grand, tout en restant petit. Une second article est dédié aux démonstrations de code de la deuxième partie de soirée.
Pratique – EJB 3.x et Adam en action
Le mardi 6 Juillet est le dernier Paris JUG avant la rentrée. Pour cette occasion, on compte sur la présence d’un speaker d’excellence : Adam Bien. Il va nous présenter deux architectures opposées – Lean Service Oriented Architecture (SOA) et Domain Driven Architecture – ainsi que la façon dont on les implémente sous la plateforme JEE 6 grâce aux EJB 3.
Histoire de vous mettre l’eau à la bouche, je vais vous présenter rapidement Adam Bien et les sujets qui seront traités plus en détail, argumentés, et accompagnés d’exemples pratiques et de retours d’expérience le mardi 6 juillet au Paris JUG.
Adam Bien est un consultant indépendant, formateur Java, architecte du software et développeur qui implémente des architectures Java à grande échelle au sein des entreprises allemandes.
Nommé Java Champion en Janvier 2007, il est membre de NetBeans Dream Team, de Sun Advantage Partner, Glassfish System Integrator, du groupe d’experts Java Community Process (EJB 3.1, JPA 2.0, Java EE 6) et il est fortement impliqué dans les technologies Cloud, Grid et P2P. Actuellement, il travaille en parallèle comme architecte et développeur au sein de plusieurs projets d’architecture J2EE/Java EE 5/MDA et au sein des architectures EAI basés en composants pour Java EE et .Net.
Il est aussi connu pour ses nombreux articles et livres publiés dans le cadre Java/J2EE/J EE et l’architecture distribuée. Parmi ses livres, on peut trouver plusieurs ouvrages en allemand (“Enterprise Architekturen”, “Java EE 5 Architeckturen”, “Struts” etc. ) ainsi que son dernier livre publié en 2009 et écrit en anglais : “Real World Java EE patterns” où il explore les défis de Cloud Computing.
Depuis des années, les EJB ont toujours été identifiés comme une technologie trop lourde. Effectivement, jusqu’à la version EJB 2 cette réputation était justifiée. Mais depuis la version EJB 3 tout a changé et on peut affirmer à présent que les EJB sont très légers. Ils sont configurés par annotation (non par de tonnes de XML), intégrés avec JPA (Java Persistence API), scalables au sein des machines multicore et avec multiples CPU, et constituent une solution standard et portable pour les applications métiers d’entreprise.
Le principe du design pattern “Convention over configuration” est le suivant : Les applications se basent sur des conventions au lieu de se baser sur la configuration. Ainsi, elles chercheront à réduire le nombre de fichiers de configuration, fourniront une configuration par défaut (convention par règle de nommage) mais permettront aussi la substitution des valeurs par défaut via la configuration (à partir des fichiers ou une autre source de données).
La mise en place de ce pattern passe par l’utilisation des annotations. Les EJB 3 ont toujours besoin de la même quantité d’information pour fonctionner. Cette information étant la même dans 80% des cas, il suffit, par exemple, de placer l’annotation @Stateless sur une classe POJO (Plain Old Java Object) pour lui donner le comportement de base d’une entité de session.
Il s’agit de retirer des objets la gestion des dépendances entre les objets et de la confier à un conteneur, le conteneur des EJBs dans ce cas. Ainsi, pour utiliser une instance EJB, on se servira de l’annotation @EJB pour l’injecter, pour utiliser une ressource (JMS, Datasource) on utilisera l’annotation @Ressource etc.
ex : Voici un EJB qui “injecte” un autre EJB de service. Le conteneur des EJBs s’occupe de chercher l’instance du Service pour que le client puisse l’utiliser.
@Stateless
public class ClientBean implements Client {
@EJB
private Service service;
public String sayHello() {
return this.service.getMessage();
}
}
La plateforme JEE 6 permet grâce aux EJBs d’implémenter deux approches d’architecture opposées :
Dans le modèle d’architecture SOA, comme son nom l’indique, l’entité la plus importante est le Service. On peut considérer un service comme un contrat, un use case, même un story, qui exécute une ou plusieurs opérations (transactions). Le principe est de l’exposer au système d’information et d’encapsuler non seulement son implémentation mais aussi sa localisation.
Les bases d’une implémentation avec Java/JEE sont les interfaces et les packages. La fonctionnalité d’un package est exposée via une interface (parfois par plusieurs). On définira d’abord les interfaces des services à exposer, pour ensuite créer les classes qui implémenteront leur logique métier.
Diviser les responsabilités – “divide and conquer”- facilite la réutilisabilité et améliore la maintenance du code. Ainsi, sans trop détailler :
Les annotations des EJBs seront placées sur la classe d’implémentation et jamais sur l’interface; ainsi, les services exposés sont indépendants de l’API EJB et leur implémentation est complètement encapsulée.
Si les façades implémentent la logique d’accès et les services la logique métier, il ne reste plus grand chose aux objets du domaine. Ils encapsulent un état mais n’ont aucune logique métier. Les entités JPA sont des classes annotées @Entity qui contiennent des attributs, des accesseurs (getter/setter) et c’est tout. Ce pattern (même considéré un anti-pattern par les puristes de la POO) est connu sous le nom “Anemic Object Model” et colle parfaitement avec les besoins de SOA.
La majorité des applications d’entreprise J2EE/ J EE d’aujourd’hui sont proches de l’architecture décrite précédemment. Néanmoins, elle convient parfaitement jusqu’au moment où le comportement dépend du type des objets. L’implémentation des services utilise alors des instructions du type “instanceof” ou encore des blocs“if/else” et “case” pour s’y adapter. Ceci est la conséquence directe du “Anemic Object Model” qui déplace le contrôle en dehors des entités au détriment des services et façades où se trouve la vrai logique métier.
L’architecture pilotée par le domaine est basée sur l’utilisation de vrais objets (true objects). Ces objets encapsulent leur état et fournissent également des comportements, bien définis en fonction du type.
Les objets du domaine sont le socle de l’application. Ils gèrent leur état, la persistance de leur état et implémentent la logique métier. Il arrive même dans certains cas que l’on n’ait pas besoin d’utiliser de service.
Les entités PDO (Persistent Domain Object) sont persistantes. Ainsi, chaque changement, au niveau de leur état ou de leurs relations, sera automatiquement synchronisé avec le moteur de persistance à la fin de la transaction. Ils seront exposés publiquement; cela oblige le concepteur à bien réfléchir à l’API qui sera fournie au client.
Les PDO sont passifs et ne démarquent pas de transactions ; ils ont besoin d’un contexte d’exécution pour fonctionner.
Cela va nous poser un problème à cause de la nature stateless des applications Java EE : après l’invocation d’une méthode transactionnelle, via un service ou un service façade, toutes les entités JPA – les PDO – sont détachées. Le client perd le contexte transactionnel; on est constamment obligé de transporter et de “merger” tout le contexte entre le client et le serveur avec les difficultés que cela implique.
Solution: Créer un “anti service façade” – un gateway. On ne cache plus les entités derrière une façade, on les expose le plus possible aux couches supérieures telles que la couche Présentation et on permet à ces couches de les modifier directement . Cette stratégie, contradictoire avec les principes J2EE classiques sur la maintenance, semble dans certains cas plus pratique dans les projets du monde réel. Il s’agit tout simplement de se débarrasser des couches inutiles et d’exposer la couche domaine à la couche présentation. Chaque changement du domaine est directement visible depuis l’IHM.
Une gateway est implémentée par une classe annotée @Stateful et @Local – un EJB – qui manage aussi les transactions et contient l’EntityManager et le contexte persistent.
Ce qui est une bonne pratique chez l’un est un anti-pattern chez l’autre. Or, les deux approches opposées sont applicables, parfois complémentaires et nécessaires.
Java EE 6 et les EJBs permettent les deux types d’implémentations. Un point à noter, l’approche SOA semble avoir une bonne affinité avec SOAP et les WebServices. Par contre, l’approche Domaine semble mieux s’accorder avec des architectures de type REST qui est focalisé sur une manipulation directe des ressources.
Les inscriptions ouvriront Jeudi 1er le matin. Soyez prêtes, ces temps-ci les place partent très vite. Si vous voulez recevoir la notification de l’ouverture par e-mail jeudi matin pour pouvez vous abonner à la mailing list Annonces du JUG.
les 24 et 25 mai à Lyon
En continuant à utiliser le site, vous acceptez l’utilisation des cookies. Plus d’informations
Les paramètres des cookies sur ce site sont définis sur « accepter les cookies » pour vous offrir la meilleure expérience de navigation possible. Si vous continuez à utiliser ce site sans changer vos paramètres de cookies ou si vous cliquez sur "Accepter" ci-dessous, vous consentez à cela.