Architecture cible Louis Martin Chaire de logiciel libre Finance sociale et solidaire UQAM 28 novembre 2010
Table des matières 1 Introduction 4 1.1 Un guide pragmatique avant tout.................. 4 1.2 Un guide en évolution... 4 1.3 L architecture vue comme une plateforme de développement... 5 1.4 Une architecture à géométrie variable... 5 2 Domaines d application visés 6 2.1 Spécifications désirées... 6 2.1.1 Indépendance face aux systèmes d exploitation... 6 2.1.2 Alphabet latin... 6 2.1.3 Internationalisation I18N et la localisation L10N... 6 2.1.4 Multidevise... 7 2.1.5 Sécurité............................ 7 2.1.6 Répondant aux normes du domaine............ 7 2.2 Scénarios d exploitation....................... 7 2.2.1 Utilisation à faible volume.................. 8 2.2.2 Utilisation à fort volume... 8 2.2.3 Utilisation par un prestataire de services d infogérance.. 8 2.2.4 Utilisation mixte interne et services d infogérance.... 8 2.2.5 Virtualisation......................... 9 3 Caractéristiques recherchées 10 3.1 Homogène... 10 3.2 Indépendante du système d exploitation SE........... 10 3.3 Adaptable... 10 3.4 Ouverte................................ 11 3.5 Sécurisée................................ 11 3.6 Pérenne................................ 11 3.7 Répondant aux normes du domaine... 11 3.8 Avec un couplage faible....................... 11 3.9 Simple... 12 1
TABLE DES MATIÈRES 2 4 Le choix d une plateforme de développement de référence 13 4.1 Le besoin d une preuve de concept... 13 4.2 La JVM comme plateforme de développement........... 13 5 Architecture multi-niveau 15 5.1 L architecture proposée....................... 15 5.2 Niveau présentation......................... 15 5.2.1 Effervescence du domaine.................. 15 5.2.2 Facteurs considérés... 15 5.2.3 Approches recommandées.................. 16 5.2.4 Défis particuliers....................... 16 5.2.5 Utilisation d un coordonnateur d application....... 17 5.3 Niveau métier... 18 5.3.1 Approche service....................... 19 5.3.2 Validation des données.................... 19 5.3.3 Moteur de flux de travaux et moteur de règles....... 19 5.4 Niveau persistance... 20 5.4.1 Bases de données....................... 20 5.4.2 Mappage objet-relationnel ORM............ 21 5.4.3 Production des rapports et l intelligence d affaires.... 21 5.4.4 Modèles universels de données... 22 5.5 Services transversaux......................... 22 5.5.1 Authentification et autorisation... 24 5.5.2 Journalisation......................... 24 5.5.3 Surveillance et supervision des services........... 24 5.5.4 Configuration des services.................. 24 5.5.5 Ordonnanceur... 24 5.5.6 Messagerie... 24 5.5.7 Gestion électronique des documents............ 25 6 Conclusion 26 6.1 Validation du présent document par des pairs........... 26 6.2 Réalisation d une preuve de concept................ 26 6.3 Rédactions de guides d utilisation.................. 26 7 Annexe 28
Table des figures 5.1 Relations entre les principaux niveaux de l architecture cible... 16 5.2 Dépendance envers le package «objets métier»... 19 5.3 Déploiement minimum de l architecture cible........... 23 3
Chapitre 1 Introduction «Noussommesdesratsquiconstruisenteux-mêmeslelabyrinthe dont ils se proposent de sortir» 1 Le présent document décrit l architecture système cible d une famille de logiciels libres pour l économie sociale et solidaire. Cette architecture devra être validée par une série de consultations auprès des contributeurs de la Chaire et par une preuve de concept. Néanmoins, il est àremarquerquelescomposantssuggérésont été testés et, dans la majorité des cas, ont été utilisés pour des systèmes en production. Le document s adresse aux concepteurs de logiciels désirant participer à la réalisation des logiciels de l AI2L. 1.1 Un guide pragmatique avant tout L architecture décrite dans ce document est une architecture cible. Elle ne doit pas être interprétée comme un absolu. Des dérogations seront possibles et, dans certains cas, même requises en fonction des impératifs du moment. À titre d exemple, nous pouvons citer l intégration de progiciels existants remplissant de façon adéquate une fonction critique pour l organisation utilisatrice. En fait, l architecture proposée tente de faciliter ce genre d intégration. Il faut cependant garder à l esprit de ne pas mettre en péril l intégrité de l ensemble, en particulier au niveau de la sécurité, par l introduction d un maillon plus faible. 1.2 Un guide en évolution Le domaine de l informatique évolue rapidement. Les manières de faire et les meilleures pratiques se modifient au gré des usages et de l expérience acquise. Bien malin celui qui peut établir une architecture ne nécessitant aucune mise à 1. définition des membres de l OuLiPo Ouvroir de littérature potentielle prêtée à Raymond Queneau http://www.oulipo.net/ 4
CHAPITRE 1. INTRODUCTION 5 niveau régulière. La présente architecture ne fait pas exception. En conséquence, elle devra faire l objet d une mise à niveau annuelle formelle pour y intégrer les nouveaux développements dans le domaine et prendre en compte les commentaires des utilisateurs suite à l expérience acquise. Les changements proposés devront être accompagnés, le cas échéant, de recommandations pour faciliter la migration vers la nouvelle cible. 1.3 L architecture vue comme une plateforme de développement L architecture cible est vue comme une plateforme de développement. Elle sert d assise pour les développeurs désirant contribuer au projet par l ajout de fonction sous la forme de services. En fonction de l évolution des besoins et des contributions, certains outils pourront s ajouter pour faciliter le travail des développeurs. 1.4 Une architecture à géométrie variable Le point de vue adopté pour le présent document étant celui des développeurs, l architecture y est décrite d un point de vue logique. Cependant, prenant en considération les différents scénarios d exploitation, nous nous sommes assurés que l architecture physique puisse se décliner sous plusieurs formes sans impacter le modèle logique utilisé pour le développement.
Chapitre 2 Domaines d application visés Les applications visés par l architecture cible couvrent, à terme, l ensemble du domaine de l économie sociale. Ce vaste domaine couvrent plusieurs champs, citons à titre d exemple, sans exclure les autres secteurs : l assurancedespersonnesetdesbiens; l épargnecollective; lefinancement,enparticulierlesinstitutionsfinancièressocialementresponsables IFSR ; etplusieursautresinitiativesreliéesaudomainedel économiesociale,par exemple, les structures d insertion par l activité économique SIAE. Les organisations ciblées par la famille de logiciels se caractérisent par un volume d opérations relativement faible : de quelques dizaines à quelques milliers d opérations quotidiennes. 2.1 Spécifications désirées 2.1.1 Indépendance face aux systèmes d exploitation L architecture cible doit pouvoir fonctionner sous les systèmes d exploitation courants, en particulier sous les systèmes d exploitation sous licence libre. 2.1.2 Alphabet latin Pour l instant, seul l alphabet latin sera pris en charge. 2.1.3 Internationalisation I18N et la localisation L10N Les logiciels devront permettre l internationalisation et la localisation selon les pratiques usuelles. 6
CHAPITRE 2. DOMAINES D APPLICATION VISÉS 7 2.1.4 Multidevise Les logiciels devront permettre l utilisation de plusieurs devises. La conversion d une devise à l autre ne sera pas automatique. Nous soulignons ce dernier point car lorsque le multidevise est mentionné, plusieurs personnes croient que cela inclut une conversion automatique. 2.1.5 Sécurité Le domaine de la sécurité des systèmes informatiques est immense et évolue rapidement au gré des attaques et des parades à ces attaques. L approche privilégiée du point de vue des développeurs est une architecture prenant en considération la sécurité d une façon la moins intrusive possible au niveau du code applicatif. Cet objectif est atteint si la sécurité est orthogonale transversale relativement au code applicatif. De cette façon, la sécurité peut être implémentée : Àplusieursniveaux: auniveauphysique; auniveauéquipement; auniveauréseau; auniveaulogiciel. Aveclapossibilitéd activerdescontrôlesounon,selonlescontextesparticuliers, sans impacter les applications elles-mêmes. 2.1.6 Répondant aux normes du domaine Les applications développées devront répondre aux normes reconnues du domaines. Plusieurs normes sont indépendantes d un domaine spécifique et d autres ne s appliquent qu à un domaine précis. Au fur et à mesure de l avancement des travaux, les normes auxquelles les applications répondront seront identifiées de façon plus précise. Parmi les cibles souhaitées, nous pouvons citer, à titre indicatif et préliminaire : ContentManagementInteroperabilityServices CMIS del organisation OASIS pour l accès aux systèmes de gestion électronique des documents ; LesguidesdelaGlobalReportingInitiative GRI et la récente norme ISO-26000 pour faciliter la triple reddition de compte financière, sociale et environnementale ; Lesdifférentesréglementationsnationales. 2.2 Scénarios d exploitation L architecture présentée cherche à répondre aux scénarios d exploitation suivants :
CHAPITRE 2. DOMAINES D APPLICATION VISÉS 8 2.2.1 Utilisation à faible volume Ce cadre d utilisation se caractérise par : unfaiblevolumedetransactions; unnombrelimitéd utilisateurs souventmoinsdedix; uneconnaissancelimitéedel informatique; uneexpertiserudimentairedessainespratiquesd exploitationdessystèmes opérationnels critiques ; unparcd équipementminimal. 2.2.2 Utilisation à fort volume Ce cadre d utilisation se caractérise par : unvolumedetransactionsdemoyenàélevé; unnombred utilisateursallantdeplusieursdizainesàquelquescentaines; unebonneconnaissancedel informatique souventparuneéquipede développement interne ; une bonne expertise de l exploitation des systèmes opérationnels critiques souventparuneéquiped exploitationinterne; unparcd équipementsrelativementimportant. 2.2.3 Utilisation par un prestataire de services d infogérance Ce cadre d utilisation se caractérise par : unepriseenchargedessystèmesdeplusieursdizainesdeclientsetplus; uneutilisationintensivedesbandespassantes; uneexigenced untauxderéponserapide; unvolumedetransactionsélevé; unetrèsbonneconnaissancedel informatique; uneexcellenteexpertisedel exploitationdessystèmesopérationnelscritiques ; unparcd équipementsimportant; des normes de qualité rigoureuses ; desauditsexternesfréquents. 2.2.4 Utilisation mixte interne et services d infogérance Ce cadre d utilisation semble devenir de plus en plus populaire en particulier avec l offre grandissante de services s appuyant sur l informatique dans les nuages cloud computing. Dans ce cadre, une organisation choisit d exploiter àl internequelquesservicesetd enconfierd autreseninfogérance.l ensemble doit fonctionner de façon transparente pour les utilisateurs finaux.
CHAPITRE 2. DOMAINES D APPLICATION VISÉS 9 2.2.5 Virtualisation L architecture cible doit pouvoir être exploitée en virtualisation 1.Lavirtualisation permet de diminuer les besoins en serveur physique, de favoriser une plus grande utilisation des équipements Green IT 2 etdefaciliterlamiseen place des mécanismes de sécurité. 1. La virtualisation consiste à faire fonctionner sur un seul ordinateur plusieurs systèmes d exploitation comme s ils fonctionnaient sur des ordinateurs distincts. Tiré de http://fr.wikipedia.org/wiki/virtualisation 2. Green computing (en français informatique verte) ou encore green information technology (abréviation green IT) est un concept consistant à tenir compte des contraintes et des coûts en énergie (alimentation électrique et climatisation) des matériels informatiques. Tiré de http://fr.wikipedia.org/wiki/green_computing
Chapitre 3 Caractéristiques recherchées L architecture logique cible vise les caractéristiques suivantes : 3.1 Homogène Si possible, une seule architecture logique pour l ensemble des modes d exploitation prévus voir la section 2.2 pour une description plus détaillée de ces modes d exploitation. 3.2 Indépendante du système d exploitation SE Cette indépendance permet d utiliser les équipements déjà en place s ils répondent aux autres exigences : performance, capacité de mémoire vive, etc. Cette indépendance rend possible une migration d un SE vers un autre. Cependant pour faciliter une telle migration, il est important que les ajouts apportés àlaprésentearchitecture,pourrépondre,parexemple,àdesbesoinsspécifiques d un utilisateur donné, respectent les mêmes principes d indépendance face au SE. L indépendance face aux SE nous amène à recommander UTF-8 Universal Character Set transformation format 8 bits pour l encodage de tous les différents types de fichiers : sources, configurations, HTML, CSS, JavaScript, XML, etc. 3.3 Adaptable Plusieurs utilisateurs voudront intégrer à l architecture des modules qui leurs sont propres ou encore donner une signature visuelle distinctive aux logiciels. 10
CHAPITRE 3. CARACTÉRISTIQUES RECHERCHÉES 11 3.4 Ouverte L architecture logique cible devrait pouvoir accommoder, dans la mesure du possible, des modules externes pouvant répondre adéquatement à des besoins ciblés. Ces modules externes sont susceptibles d avoir été réalisés dans plusieurs langages de programmation. L architecture cible doit donc pouvoir accommoder des modules polyglottes. 3.5 Sécurisée L architecture cible doit permettre la mise en place des mécanismes de sécurité exigés par la nature des applications visées et par les meilleures pratiques du domaine. Voir la section 2.1.5 sur les différents volets de la sécurité. Idéalement, nous visons que la sécurité soit orthogonale 1 au modèle logique utilisé pour le développement. 3.6 Pérenne L architecture cible doit offrir une base solide pour les prochaines dix à quinze années. Personne ne peut prédire le futur avec précision, les choix devant être faits seront basés sur l expérience de l équipe et leur vision du futur méthode Delphi informelle 2. 3.7 Répondant aux normes du domaine L architecture cible doit respecter au maximum les normes du domaine. Ces normes peuvent être des normes de facto normesétabliesparlapratiqueet non par un organisme de réglementation. 3.8 Avec un couplage faible La notion de couplage représente, dans le présent contexte, le degré d indépendance relative entre les services d un système. Nous dirons que le couplage est faible si un changement dans un service demande peu de changement au niveaux des autres services du systèmes. Uncouplageseraqualifiédefortsiun 1. In geometry, orthogonal means "involving right angles" (from Greek ortho, meaning right, and gon meaning angled). The term has been extended to general use, meaning the characteristic of being independent (relative to something else). It also can mean : nonredundant, non-overlapping, or irrelevant. In computer terminology, something such as a programming language or a data object is orthogonal if it can be used without consideration as to how its use will affect something else. Tiré de http://searchstorage.techtarget.com/ 2. La méthode Delphi est une méthode de prévision, utilisée en particulier en gestion de projet ou en prévision économique. Le principe de cette méthode est que des prévisions réalisées par un groupe d expert structuré sont généralement plus fiables que celles faites par des groupes non structurés ou des individus. Tiré de http://fr.wikipedia.org/
CHAPITRE 3. CARACTÉRISTIQUES RECHERCHÉES 12 changement dans un service impacte plusieurs autres services et demande en conséquence des modifications à ces derniers. 3.9 Simple «Entianonsuntmultiplicandapraeternecessitatem» Guillaume d Ockham «Lasimplicitéestlasophisticationsuprême» Léonard de Vinci «Il semble que la perfection soit atteinte non quand il n y a plus rien à ajouter, mais quand il n y a plus rien à retrancher» Antoine de Saint-Exupéry Lorsque l ensemble des caractéristiques décrites plus haut sont prises en compte dans une architecture, il reste un dernier tour de manivelle à donner : celui de simplifier l architecture résultante par un réusinage 3 refactoring.cette simplification rend plus facile la compréhension de l architecture cible par les développeurs et exige moins d effort pour être implémentée.l architecture cible doit pouvoir se moduler de différentes façons tout en offrant un modèle unique pour les développeurs. 3. La refactorisation (anglicisme venant de refactoring) est une opération de maintenance du code informatique. Elle consiste à retravailler le code source non pas pour ajouter une fonctionnalité supplémentaire au logiciel mais pour améliorer sa lisibilité, simplifier sa maintenance, ou changer sa généricité (on parle aussi de remaniement). Une traduction plus appropriée serait réusinage. C est donc une technique qui s approche de l optimisation du code, même si les objectifs sont radicalement différents. Tiré de http://fr.wikipedia.org/wiki/refactoring
Chapitre 4 Le choix d une plateforme de développement de référence 4.1 Le besoin d une preuve de concept La description d une architecture cible est importante, principalement pour comprendre les motifs pris en compte dans son élaboration. Cependant l architecture seule ne suffit pas. Pour illustrer son fonctionnement et aider les développeurs à participer au projet, il faut pouvoir disposer d une plateforme de développement de référence permettant d illustrer en pratique le fonctionnement de l architecture cible. Cette plateforme de développement de référence n exclut pas l apport éventuel de services implémentés sous une autre plateforme de développement. Ces services devront toutefois pouvoir cohabiter avec la plateforme de développement de référence. 4.2 La JVM comme plateforme de développement Le choix de la JVM Java Virtual Machine s est imposé rapidement. Les principaux facteurs justifiant ce choix sont : PlusieursimplémentationsdelaJVMexistentsurlemarché. L implémentationlaplusconnue celledesun/oracle estdisponible sous les principaux systèmes d exploitation : Unix/Linux, Windows, Mac OS X, etc. D autres implémentations, certaines disponibles en libre, fonctionnent sous l un ou plusieurs de ces systèmes d exploitation. LaplateformeJavaestbienrépandueetestconnuedenombreuxdéveloppeurs. Plusieursbibliothèques,cadresd application frameworks etlogiciels complets sont disponibles en libre sous cette plateforme. Plusieurslangagesdeprogrammationfonctionnentsouscetteplateforme 1 1. Le site http://www.robert-tolksdorf.de/vmlanguages.html donne une liste de plus de 13
CHAPITRE 4. LE CHOIX D UNE PLATEFORME DE DÉVELOPPEMENT DE RÉFÉRENCE14 rendant possible une programmation polyglotte plus optimale dans certains contextes. Parmicesnombreuxlangages,plusieurssontdeslangagesdynamiques,en particulier Groovy. L utilisation des langages dynamiques est populaire. Certains auteurs indiquent que les langages dynamiques permettent des gains de productivité de 2,5 à 3 fois par rapport à un langage comme Java ou C#. D autres auteurs critiquent l utilisation des langages dynamiques soulignant qu avec ces derniers des erreurs, captées à la compilation par les langages traditionnels, causent des erreurs à l exécution. LelangageScala 2 permettant une programmation orientée objet et aussi une programmation fonctionnelle est également disponible sous la plateforme. Enfin,ladisponibilitédelangagestelsqueGroovyetScalaoffrelapossibilité de développer des langages applicatifs domain specific language 3 (DSL).Ceslangagesapplicatifspeuvents avérerunoutilprécieuxpour permettre l adaptation rapide des programmes à un contexte d utilisation particulier. 200 langages fonctionnant sous la JVM. 2. Scala is a general purpose programming language designed to express common programming patterns in a concise, elegant, and type-safe way. It smoothly integrates features of object-oriented and functional languages, enabling Java and other programmers to be more productive. Code sizes are typically reduced by a factor of two to three when compared to an equivalent Java application. Tiré de http://www.scala-lang.org/ 3. In software development and domain engineering, a domain-specific language (DSL) is a programming language or specification language dedicated to a particular problem domain, a particular problem representation technique, and/or a particular solution technique. The concept isn t new special-purpose programming languages and all kinds of modeling/specification languages have always existed, but the term has become more popular due to the rise of domain-specific modeling. Tiré de http://en.wikipedia.org/wiki/domain-specific_language
Chapitre 5 Architecture multi-niveau 5.1 L architecture proposée L architecture logique proposée est courante. Elle est composée d une structure à quatre niveaux : Leniveauprésentation Leniveaulogiquemétier Leniveaupersistance Leniveaudesservicestransversaux La figure 5.1 illustre la visibilité directe des niveaux proposés. Les sections suivantes décrivent plus en détail chacun de ces niveaux. 5.2 Niveau présentation 5.2.1 Effervescence du domaine Depuis ces dernières années, le niveau présentation connaît plusieurs changements et offre plusieurs cadres d application frameworks. La grande diffusion d appareils mobiles téléphones dits intelligents, tablettes, etc. génère le besoin d accéder aux applications patrimoniales depuis ces dispositifs. L utilisation de ces dispositifs pour des applications multi-niveaux s appuie sur Internet et en particulier sur le protocole HTTP/HTTPS 1. 5.2.2 Facteurs considérés Les points pris en compte dans notre réflexion pour le niveau présentation sont : Laproportionimportantedeseffortspour développer ce niveau. Certains vont jusqu à avancer que le niveau présentation demande de 40 à 60 % de l effort total d un projet. 1. Respectivement HyperText Transfer Protocol et HyperText Transfer Protocol Secured 15
CHAPITRE 5. ARCHITECTURE MULTI-NIVEAU 16 Figure 5.1 Relations entre les principaux niveaux de l architecture cible La flexibilité requise par les différentes organisations susceptibles d utiliser nos logiciels. Le niveau présentation est une vitrine, on veut pouvoir y mettre un logo, des couleurs propres à sa signature corporative, etc. L adhésionauxnormesouvertesetlargementutilisées. Lasimplicitéetlaflexibilitédeséchangesentreleclientetleserveur. Lapossibilitéd utiliserlamêmemanièredefaireautantpourlesapplications grand public que pour les applications réservées au personnel de l organisation. Lafacilitéd installeretdemettreàjourlesapplicationsduniveauprésentation. L indépendanceduniveauprésentationenregarddestechnologiesutilisées pour le niveau métier. Laréductiondel utilisationdelabandepassante. 5.2.3 Approches recommandées Le fureteur comme plateforme privilégiée L utilisationdehtml4 etbientôthtml5 L utilisationdecss etbientôtcss3 L utilisationdesbibliothèquesjquery incluantajax L utilisationd uncoordonnateurauniveauserveur 5.2.4 Défis particuliers La sécurité Lacompatibilitéentrelesdifférentsfureteurs Firefox3.6+,Chrome, Opera, Safari 5+, IE 9+ Ladisciplinededéveloppement:développementd unmanueldestyleet des meilleures pratiques
CHAPITRE 5. ARCHITECTURE MULTI-NIVEAU 17 Ladifficultédestests Ladisponibilitédeplateformesdedéveloppement 5.2.5 Utilisation d un coordonnateur d application Le coordonnateur d application 2 agit comme un intermédiaire entre le client fureteur et le niveau métier. Son rôle principale est de recevoir les requêtes Ajax 3 émises par le client fureteur et, le cas échéant, de faire appel aux services métier pour y répondre. Le coordonnateur d application est le premier et le plus important bastion de protection entre un client fureteur considéré comme vulnérable et le niveau métier. Le coordonnateur doit s assurer de prendre en charge les meilleurs pratiques de protection 4.Leséchangesentrelefureteuretlecoordonnateurdoiventêtre établis de telle sorte que quelqu un de l extérieur ne puisse pas, dans la mesure du possible, induire le fonctionnement interne du système. Nous favorisons une API 5 entre le fureteur et le coordonnateur s éloignant du patron de conception REST 6 et s approchant plus d une API classique de style RPC 7.Ilexisteun couplage fort entre le fureteur et le coordonnateur, il est donc conséquent de l utiliser une API propre aux deux partenaires. L approche proposée permet d implémenter le coordonnateur dans n importe quel langage car le coordonnateur communique avec les services métier en utilisant le patron de conception REST. De plus le coordonnateur n est pas dépendant d un cadre d application donné par exemple, Struts, GWT, etc. Le format recommandé des échanges entre le fureteur et le coordonnateur est JSON. Les essais réalisés tendent à démontrer que le format JSON 8 facilite 2. Le patron de conception «coordonnateur d application» est aussi connu sous le nom de «contrôleur» ou «contrôleur façade». Dans le présent contexte, nous nous référons à l approche de Craig Larman décrite en particulier dans UML 2 et les Design Patterns 3e éd. chez Pearson France 2005 ISBN13 : 9782744070907. 3. Asynchronous Javascript and XML 4. Voir le site http://www.owasp.org/ dédié à la sécurité des applications de type WEB et en particulier, leur dernière édition des «Dix risques de sécurité applicatifs WEB les plus critiques». 5. Une interface de programmation (Application Programming Interface ou API) est une interface fournie par un programme informatique. Elle permet l interaction des programmes les uns avec les autres de manière analogue à une interface homme-machine rend possible l interaction entre un homme et une machine. Tiré de http://fr.wikipedia.org/wiki/interface_de_programmation 6. REST Representational State Transfer est une manière de construire une application pour les systèmes distribués comme le World Wide Web. Le terme a été inventé par Roy Fielding en 2000. REST n est pas un protocole ou un format, c est un style d architecture, c est le style architectural original du Web. Tiré de http://fr.wikipedia.org/wiki/representational_state_transfer 7. En informatique et en télécommunication, RPC (Remote Procedure Call) est un protocole réseau permettant de faire des appels de procédures sur un ordinateur distant à l aide d un serveur d applications. Ce protocole est utilisé dans le modèle client-serveur et permet de gérer les différents messages entre ces entités. Tiré de http://fr.wikipedia.org/wiki/remote_procedure_call 8. JSON JavaScript Object Notation est un format de données textuel, générique, dérivé de la notation des objets du langage ECMAScript. Il permet de représenter de l infor-
CHAPITRE 5. ARCHITECTURE MULTI-NIVEAU 18 la programmation JavaScript au niveau du fureteur. Du côté coordonnateur, des bibliothèques existent pour tous les langages courants permettant de créer des représentations JSON facilement. En Java, nous avons utilisé JSON-LIB http://json-lib.sourceforge.net/. 5.3 Niveau métier Concernant les échanges entre les coordonnateurs du niveau présentation et les services du niveau métier, le patron de conception REST est favorisé. La même approche est également favorisée pour les échanges entre les services métier. Cette approche est plus simple d utilisation que les nombreux standards 9 associés à SOAP 10 et ses différentes déclinaisons. Le cadre d application recommandé pour REST est Jersey qui est l implémentation de référence de la norme JAX-RS. Concernant les échanges entre les coordonnateurs et les services REST, plusieurs choix sont possibles, parmi les plus courants mentionnons XML, JSON et la sérialisation des objets. Les tests effectués démontrent que la sérialisation d objet et le format JSON offrent une performance de près de huit fois supérieure relativement à l utilisation d un format XML. Un service REST peut supporter plusieurs formats différents, le client transmet avec sa requête les formats qu il préfère et le service y répond dans la mesure du possible par ordre de préférence indiqué par le client. Dans un environnement homogène de type JAVA incluant le dialecte Groovy la sérialisation des objets offre une simplicité et des performances intéressantes. Bien entendu, les classes échangées doivent être accessibles au niveau du client et au niveau du service. La figure 5.2 illustre cette dépendance. De plus cette approche permet d utiliser Hibernate-Validator pour annoter les objets métier permettant ainsi d avoir à un endroit unique les spécifications de validation et de pouvoir exécuter ces validations autant au niveau du coordonnateur qu au niveau du service et même,à certains égards, au niveau de mation structurée. Créé par Douglas Crockford, il est décrit par la RFC 4627 de l IETF. Tiré de http://fr.wikipedia.org/wiki/javascript_object_notation 9. Pour vous convaincre de ce point, consultez le site http://www.innoq.com/soa/ws-standards/poster/. 10. SOAP ancien acronyme de Simple Object Access Protocol est un protocole de RPC orienté objet bâti sur XML. Il permet la transmission de messages entre objets distants, ce qui veut dire qu il autorise un objet à invoquer des méthodes d objets physiquement situés sur un autre serveur. Le transfert se fait le plus souvent à l aide du protocole HTTP, mais peut également se faire par un autre protocole, comme SMTP. Le protocole SOAP est composé de deux parties : une enveloppe, contenant des informations sur le message lui-même afin de permettre son acheminement et son traitement, un modèle de données, définissant le format du message, c est-à-dire les informations àtransmettre. SOAP a été initialement défini par Microsoft et IBM, mais est devenu une référence depuis une recommandation du W3C, utilisée notamment dans le cadre d architectures de type SOA Service Oriented Architecture pour les Services Web WS-*. Tiré de http://fr.wikipedia.org/wiki/soap
CHAPITRE 5. ARCHITECTURE MULTI-NIVEAU 19 Figure 5.2 Dépendance envers le package «objets métier» la persistance. Le diagramme suivant illustre la dépendance entre les différents types de package espaces de nommage en Java dans un tel contexte. 5.3.1 Approche service L approche service utilisant le patron de conception REST est retenue. Cette façon de faire permet d accueillir dans l architecture cible des services réalisés dans des langages de programmation autres que Java, Groovy ou Scala. Les services sont représentés, avec le patron de conception REST, sous la forme de ressources. Les ressources sont identifiées par un URI 11. Un catalogue des ressources sera utilisé pour centraliser les informations sur celles-ci et pour indiquer les méthodes OPTIONS GET HEAD POST PUT DELETE permises pour chacune d elles et les formats supportés pour les représenter. 5.3.2 Validation des données Pour la validation des données, tel que décrit plus haut, nous favorisons Hibernate Validator l implémentation de référence pour la JSR 303. 5.3.3 Moteur de flux de travaux et moteur de règles Au niveau des processus et des règles d affaires, nous considérons que la majorité des applications à réaliser auront une complexité de faible à moyenne. 11. Un URI, de l anglais Uniform Resource Identifier, soit littéralement identifiant uniforme de ressource, est une courte chaîne de caractères identifiant une ressource sur un réseau (par exemple une ressource Web) physique ou abstraite, et dont la syntaxe respecte une norme d Internet mise en place pour le World Wide Web (voir RFC 3986). Tiré de http://fr.wikipedia.org/wiki/uniform_resource_identifier