Introduction

1. Introduction Architecture de systèmes d’information Architecture (Larousse) : "Art de concevoir et de construire un bâtiment selon des partis pris esthétiques et des règles techniques et déterminés". Ne pas confondre avec architecture des ordinateurs Rôle d’un architecte Concevoir les différentes briques du système d’information et s’assurer de leur interopérabilité. Il veille aussi à l’évolution de ces briques. Il doit s’assurer d’une bonne orchestration de ces briques en termes de qualité, performance, de flexibilité et de sécurité. Positionnement stratégique par rapport au fonctionnement de l’entreprise.

2. Introduction Architecture et intégration de systèmes L’intégration de systèmes est avant tout une démarche logicielle. L’architecte va plus loin que l’intégrateur en intégrant des paramètres d’urbanisation, des règles d’entreprise, des contraintes d’harmonisation et de sécurité. Les compétences de l’architecte englobent la programmation, les réseaux, les bases de données, les mainframes, les traitements batchs, les technologies Web et les règles métier de l’entreprise. Ses connaissances doivent être constamment à jour dans tous ces domaines. Il assiste efficacement le DSI et participe à toutes les décisions stratégiques concernant le système d’information. Il a une connaissance rigoureuse et exacte de la cartographie du système d’information.

3. Introduction Cartographie du SI Diagramme illustrant toutes les briques d’un système d’information.

4. Introduction Considérations stratégiques L’architecte de SI doit constamment jauger ses décisions à la lumière des questions suivantes : Quels sont les avantages et inconvénients techniques de cette approche? Cette solution est-elle flexible? Quel est le coût de mise en œuvre et de maintenance? Cette technologie a-t-elle un avenir? Approche "custom" ou "package" ? Le niveau de performances est-il acceptable? Le niveau de qualité est-il suffisant? La solution est-elle fiable et sécurisée? Quel est le retour sur investissement (ROI) de cette solution ? Cela vaut-il la peine de remplacer/faire évoluer l’existant?

5. Design patterns : définition Design patterns Les problèmes auxquels font face concepteurs et développeurs sont rarement exceptionnels. Ils sont en fait souvent récurrents. Et la réapparition systématique de ces problèmes a poussé la communauté des concepteurs à échafauder des solutions réutilisables. Ainsi est née une approche visant à élever la réutilisabilité au niveau de la conception et de l'architecture des systèmes orientés objets, par l’emploi de modèles capturant la sémantique et la structure de solutions utilisées de façon récurrente pour résoudre des problèmes survenant dans des contextes similaires. Un patron est donc une solution répondant à un problème récurrent, dans un contexte spécifique. Connaître les principaux patrons est très utile à tout développeur du monde objet, surtout dans le cadre de grands projets (basés sur le modèle objet). En effet, l'appréhension d'un système développé en utilisant des patterns est grandement facilitée, puisque leur identification permet de comprendre plus vite les différentes parties du système en question et d'avoir ainsi une vue de plus haut niveau plus rapidement.

6. Différents types de patterns Patterns architecturaux Ce sont des modèles pour des architectures logicielles concrètes et peuvent donc être vus comme des patrons à grande échelle. Ils spécifient les différents sous-systèmes et composants d'un système, leurs responsabilités, ainsi que les règles d'organisation de leurs interrelations. L'un des modèles architecturaux les plus connus est le modèle MVC (Model – View – Controller). Patterns de conception Un patron de conception fournit un schéma pour raffiner les sous-systèmes ou les composants d'un système logiciel. Il décrit une structure de composants communiquant entre eux et solutionnant un problème de conception récurrent. On peut compléter cette définition en ajoutant la notion de contexte attaché au problème et indissociable de celui-ci. Un patron de conception peut donc être vu comme la description d'un problème et de sa solution.

7. Classification des patterns Patterns : classification Le GoF (Gang of Four, nom donné aux auteurs de « Design Patterns – Catalogue de modèles de conceptions réutilisables) propose une classification des design patterns suivant deux critères : Le rôle du modèle, qui traduit ce qu'il fait : créateur : création des objets. Ces patrons fournissent des interfaces de création des objets, évitant ainsi l'instanciation directe des objets. Le programme gagne en flexibilité en décidant quels objets doivent être créés pour un cas donné. Exemples : fabrique (abstract factory, factory method), singleton structurel : composition des classes ou des objets. Ces patrons servent à regrouper des objets dans des structures plus grandes, comme par exemple des interfaces utilisateur complexes. Exemples : adaptateur, composite, décorateur, façade, proxy comportemental : définition des interactions entre classes et objets, et de la répartition des responsabilités. Ces patrons définissent une communication entre les objets. Exemples : commande, itérateur, observateur, stratégie Le domaine (ou la portée) du modèle, qui précise si le modèle s’applique à des classes ou à des objets : les modèles de classes traitent des relations entre les classes et leurs sous-classes les modèles d'objets traitent des relations entre les objets

8. Exemple de pattern Patterns : exemple Le pattern Singleton Ce modèle créateur permet de s'assurer que la classe n'aura qu'une seule instance, accessible par un point d'entrée unique (une méthode) bien déterminé. Implémentation L’instance unique est conservée comme membre de classe (protégé pour permettre l’héritage), créée par un constructeur accessible uniquement par la classe et ses dérivées (donc également en accès protégé). Le point d’entrée est une méthode publique statique (ne nécessitant heureusement la création préalable d’aucune instance de singleton).

9. Exercice Singleton Un singleton sert à contrôler le nombre d'instances d'une classe présent à un moment donné. C'est souvent très pratique pour les classes sans état et effectuant toujours les mêmes traitements. Un singleton est construit grâce à des méthodes de classes. Ces méthodes appartiennent à une classe et peuvent être accédées indépendamment de l'objet. Compléter le code suivant pour implémenter correctement le pattern Singleton public CanvasFactory { /** Donnée de classe contenant l'instance courante */ private ??? CanvasFactory instance = new CanvasFactory(); /** Constructeur privé interdisant l'instanciation en dehors de cette classe */ ??? CanvasFactory () {} /** Singleton de la classe courante */ public ??? CanvasFactory getInstance() { ??? ; } ... } Typiquement l'usage de la classe CanvasFactory se fera ainsi : CanvasFactory cf = CanvasFactory.getInstance();

10. Client Serveur Objet Objet Middleware CORBA - Principe simplifié

11. Qu'est ce que C.O.R.B.A. ? • CORBA ( Common Object Request Broker Architecture ) est un environnement réparti (middleware). • Défini par l'OMG • Créé en 1989 • But non lucratif • Plus de 850 membres (Sun, IBM, Microsoft, ...) • Crée et maintient les spécifications • CORBA • UML • http://www.omg.org

12. Objectifs de CORBA • Fournir un environnement ouvert • les membres participent aux spécifications • Fournir un environnement portable • les API sont définis pour rendre les applications portables ( quelque soit le produit CORBA utilisé ) • Fournir un environnement interopérable • Permettre aux applications CORBA de collaborer entre elles.

13. Le bus CORBA Le bus CORBA = ORB NT UNIX UNIX PC PC Sparc

14. La vue réelle du bus CORBA Réseau TCP/IP ORB PC/NT ORB PC/UNIX ORB Sparc/UNIX NT UNIX UNIX PC PC Sparc

15. Architecture de CORBA IDL

16. Serveur et objets • Un serveur CORBA peut héberger plusieurs objets CORBA. • Chaque objet est accessible indépendamment des autres objets du serveur. • Chaque objet exprime son offre de services. Pour cela, on utilise un langage de description de services appelé IDL CORBA.

17. Composants générés automatiquement • Stub : partie cliente • Skeleton : partie serveur • Object Adapter : enregistrement des objets • ORB : passage de message • IIOP : Internet Inter-ORB Protocol

18. Objet CORBA

19. Le langage IDL CORBA • Il s'agit de décrire au sein d'une interface ( vue cliente de l'objet ) la liste des services offerts ( ensemble de fonctions ). interface Horloge { string donne_heure_a_paris(); string donne_heure_a_pekin(); };

20. La compilation IDL • Une description IDL est compilée pour générer les amorces nécessaires au mécanisme RPC. souche Génération de l'amorce cliente description IDL Génération de l'amorce serveur squelette

21. Intervention des amorces C.O.R.B.A. Client Java Objet C++ Protocole IIOP Souche Java Squelette C++ ORB Java PC/NT ORB PC/UNIX ORB C++ Sparc/UNIX NT UNIX UNIX PC PC Sparc

22. Souche : Coté client • Fonctions de la souche : • Prépare les paramètres d’entrée de l’invocation • Décode les paramètres de sortie et le résultat • Souche statique • Une par type d’objet serveur à invoquer • Identique aux talons clients RPC • Générée à la compilation à partir de l’interface IDL • Souche dynamique • Souche générique construisant dynamiquement tout type de requêtes • Permet d’invoquer des objets serveurs que l’on découvre à l’exécution (i.e. dont on ne connaît pas l’interface à la compilation : Référentiel d’interfaces)

23. Squelette : Côté serveur • Fonctions du squelette : • décode les paramètres d’entrée des invocations • prépare les paramètres de sortie et le résultat • Squelette statique • un par type d’objet serveur invocable • identique aux talons serveurs RPC • généré à la compilation à partir de l’interface IDL • Squelette dynamique • squelette générique prenant en compte dynamiquement tout type de requêtes • permet de créer à l’exécution des classes d’objets serveurs (i.e. que l’on ne connaissait pas à la compilation)

24. L'identité d'un objet C.O.R.B.A. • Chaque objet C.O.R.B.A. est associé à une référence d'objet qui forme son identité. • Deux objets C.O.R.B.A. du même type ( exemple deux objets Horloge ) ont deux identités différentes. Les références d'objets sont le moyen d'accès à un objet. serveur

25. L'adaptateur d'objets Serveur Objet A Objet B Squelette A Squelette B Client Adaptateur d'objets Souche A Le bus C.O.R.B.A. ( O.R.B. )

26. L'adaptateur d'objets • Fonctions • Interface entre les objets CORBA et l’ORB • Enregistrement et recherche des implantations d’objets • Génération de références pour les objets • Gestion de l’instanciation des objets serveurs • Activation des processus dans le serveur • Aiguillage des invocations de méthodes vers les objets serveurs • Différents type d’adaptateur • BOA (Basic Object Adapter) • POA (Portable Object Adapter)

27. Les communications avec CORBA • Les participants à un échange CORBA communiquent à l'aide d'un protocole spécifique à CORBA : IIOP ( Internet Inter-ORB Protocol ). • Le protocole IIOP est indépendant du langage de programmation, du système d'exploitation et de la machine utilisée. Un client Java pourra utiliser un serveur C++

28. Normalisation des communications • Protocoles d’interopérabilité entre ORBs conformes à CORBA 2 • GIOP : General Inter-ORB Protocol • Messages : request, reply, cancelrequest, … • nécessite un protocole de transport fiable, orienté connexion • IIOP (Internet IOP) : instanciation de GIOP sur TCP • Autres implantations de GIOP au-dessus de HTTP, RPC DCE, RPC Sun • Composants du protocole • CDR : Common Data Representation • Format de données d’encodage des données • IOR : Interoperable Object References (références d’objets)

29. L'annuaire C.O.R.B.A. • L'annuaire C.O.R.B.A. est un service. • Il s'agit d'un serveur qui enregistre des associations nom / référence d'objet. • Un serveur peut enregistrer ses objets dans l'annuaire. • Un client peut récupérer l'accès à un objet en consultant l'annuaire.

30. Compilation d'une description IDL • La description doit être compilée afin de générer les amorces ( souche et squelette ) requises pour l'établissement de la communication inter-processus. • A l'issu de la compilation, plusieurs fichier sont créés : • Le squelette • La souche, • L'interface • Les opérations de l'interface

31. Conclusions • Solution non propriétaire • Standard • Libre choix de l’implémentation et du langage • Solution fonctionnelle d’interopérabilité • Plusieurs implémentations libres et open-source • Mais.. Mise en œuvre assez complexe..

32. Objet distribué (rmi)

33. Middleware Explicite transfer(Account account1, Account account2, long amount) { // 1: Call middleware API to perform a security check // 2: Call middleware API to start a transaction // 3: Call middleware API to load rows from the database // 4: Subtract the balance from one account, add to the other // 5: Call middleware API to store rows In the database // 6: Call middleware API to end the transaction }

34. Middleware implicite

35. Architecture 3-tiers

36. Les Enterprise JavaBeans • Spécification d’une architecture permettant la création d’applications distribuées • Implantations de la spec : • WebLogic, Jonas,IBM Websphere, Jboss • Composant développé pour être exécuté sur un serveur d’EJB • Ne pas confondre avec un Java bean

37. Les Enterprise JavaBeans

38. Objectifs des EJB • Fournir une plate-forme standard pour la construction d’applications distribuées en Java • Simplifier l’écriture de composants serveurs • Portabilité • Considérer le développement, le déploiement et l’exécution des applications

39. Division des responsabilités • Le fournisseur de bean • Produit les composants métier • Le fournisseur de conteneur EJB • Fournit l’environnement permettant l’exécution des beans • Le fournisseur de serveur EJB • Fournit l’environnement d’exécution pour un ou plusieurs conteneurs • L’assembleur d’application • Le déployeur (installateur) • L’administrateur

40. Les Enterprise Beans • Composants qui peuvent être déployés dans un environnement multi-tiers et distribué. • Exposent une interface qui peut être appelé par ses clients • Configurés de façon externe • L’interface et l’implantation du bean doivent être conforme à la spécification EJB • Les clients peuvent être • Une servlet • Une applet • Un autre bean

41. Les Enterprise Beans

42. Les types de Beans • Session Beans : contiennent la logique métier de l’application • Stateful session bean • Stateless session bean • Message bean : contiennent la logique orientée message • Entity Beans : contiennent la logique de gestion des données persistantes • Attention! Depuis la spec. Java EE 5 les Entity Beans sont ‘deprecated’. Sun préconise l’utilisation de l’API JPA pour le mapping Objet-Relationnel.

43. Session Bean • Fournit un service à un client • Durée de vie limitée à celle du client • Effectue des calculs ou des accès à une base de donnée • Peut être transactionnel • Non recouvrable • Peuvent être sans état ou conversationnel (stateless ou stateful)

44. Exemple de Session bean import javax.ejb.Stateless; @Stateless public class SimpleSessionBean implements SimpleSession { private String message = “Je suis un session bean !"; public String getMessage() { return message; } }

45. L’interface L’interface décrit le contrat avec les clients import javax.ejb.Remote; @Remote public interface SimpleSession { public String getMessage(); }

46. Message Driven Bean • Intégration des EJB et de JMS • Interactions asynchrones • Utilisé pour réagir à des messages JMS • Stateless bean • Une seule méthode dans l’interface • onMessage()

47. Intérêt des EJB • Simplicité de l’écriture des composants • Mais le design est plus complexe • Portabilité des composants • A l’exception des adaptations des serveurs • Réutilisation/Composition • Il faut quand même programmer • Indépendance par rapport aux vendeurs • Migration pas toujours évidente d’une plate-forme à une autre

48. Bénéfices d’un serveur d’EJB • Gestion automatisée des stocks de ressources • Gestion automatisée du cycles de vie des composants • Gestion de la concurrence • Scalabilité • Fonctionnalités déclaratives • Disponibilité et tolérance aux pannes • Modèle d’objet distribué

49. Pourquoi la messagerie? • Couplage fort • Le client dépend de l’interface du serveur • Le client doit «connaître» le serveur (Référence) • Dépendance temporelle • Le client et le serveur doivent être simultanément disponibles • Communication synchrone/bloquante (habituellement) • Le client est bloqué entre l’envoi de la requête et l’arrivée de la réponse

50. Middleware orienté message • Les middlewares orientés messages (MOM) proposent une infrastructure permettant l’échange de messages dans une architecture répartie.