Architecture technique Carine Souveyet (5 jours)

Architecture Logicielle Définition : « Un programme ou un système logiciel est composé de composants logiciels. L’architecture de ce programme ou d’un système est une ou plusieurs structures décrites par les propriétés externes et visibles des composants logiciels et les liens entre ces composants. »

Architecture Logicielle Description de l’architecture : « architecture logicielle est décrite de manière informelle par un diagramme avec des boites et des liens accompagné par un texte en langage naturel » => pas de modèle de description. Par contre les modèles architecturaux permettent de clarifier la différence sémantique des composants et des interactions.

Caractéristiques d’une architecture logicielle Une architecture logicielle est définie pour satisfaire un objectif. Une architecture logicielle peut être évaluée par rapport aux critères suivants : « extension fonctionnelle » « adaptation contextuelle » « réutilisabilité des composants logiciels »

Architecture d’un SI Plusieurs niveaux d’abstraction : Architecture Métier (fonctionnelle) Architecture Technique

Architecture Métier d’un SI L’objectif de l’Architecture Métier : Est de décrire : la distribution des processus métier pris en charge par le SI sur des composants logiciels, leurs interactions. L’urbanisme des SI se focalise sur l’architecture métier

Architecture Métier d’un SI L’architecte Métier (ou Urbaniste) : doit Connaître l’entreprise au sens large (processus métier de l’entreprise, aspects organisationnels et stratégiques de l’entreprise) Connaître les besoins fonctionnels et non fonctionnels des acteurs de l’entreprise vis à vis du SI Maîtriser les règles d’urbanisme des SI

Architecture Métier d’un SI Connaissances Métiers de l’entreprise et besoins non fonctionnels Techniques et règles d’urbanisation Cartographie Architecture Métier Architecte Métier (Urbaniste)

Architecture Technique d’un SI L’objectif de l’Architecture Technique : Est de décrire : L’ensemble des types d’application nécessaire pour la mise en œuvre de l’architecture métier et les communications à envisager entre ces types d’application

Architecture Technique d’un SI L’architecte technique : doit Connaître l’architecture Métier Connaître les besoins non fonctionnels du SI Maîtriser les techniques de développement Maîtriser les techniques d’intégration d’application

Architecture Technique d’un SI Architecture Métier et besoins non fonctionnels Techniques de développement et Techniques d’intégration d’applications Architecture Technique Architecte Technique

Architecture Technique En résumé Entrée Acteurs Compétences Architecture Métier Entreprise Modelling, NFR Architecte Urbaniste Règles d’urbanisation Architecture Technique Architecture Métier, NFR Architecte technique EAI et techniques de développement

Compétences techniques Styles architecturaux Style en couches Patterns architecturaux Pattern “Model-View-Controller” Stratégies d’intégration d’applications (EAI) Bus logiciel, serveur d’application, BPM, portail Techniques de développement par composants EJB, portlet, composant CORBA, tâches ... Techniques de développement à base de services WSDL, connecteur JCA, SOAP, MOM, UDDI, XSLT, XML

STYLE ARCHITECTURAL(1) Architecture « en couches » (Layered) Les types d’application de l’ architecture technique sont répartis en couche Un rôle est associé à chaque couche. Les types d’application d’une couche Exemples : architecture 1tier, 2tier, 3tier, Ntier

STYLE ARCHITECTURAL(2) Architecture « 1tier» Application standalone Architecture « 2tier» Application client/serveur Application web client serveur Couche 1 Couche 2

STYLE ARCHITECTURAL(3) Architecture « 3tier» client serveur serveur Couche 1 Couche 2 Couche 3 Serveur de présentation Client universel données

Architecture « N-tier » ... BDD LDAP ERP Service externe SGBDR Mainframe Progiciel Service de sécurité Browser Pages HTML SERVEUR D ’APPLICATION d’ admin. Enterprise Application Integration Services Invariants $$ DIFFUSION

Patterns architecturaux - 2 couches « Interface/Application » - « Model-View-Controller » (MVC) - 3 couches : « MVC » + Source de données - Presentation-Abstraction-Control « PAC »

« Architecture/Application » Modèle « Interface/Application » : objectif : séparer la gestion de l’interface utilisateur de la gestion de l’application pour pouvoir changer l’interface. limites : la partie « interface » doit connaître la partie « applicative » et vice-versa => réutilisation quasi-impossible.

« Interface/application » Le développement de l ’application en « couches » Option de Menu « Enregistrer » Bouton Image « Enregistrer Combinaison de touches « Ctrl s » Objets graphiques réactifs composant l ’interface graphique Couche Interface Couche Applicative Objets ou procédures réalisant les fonctions de l’application indépendamment du moyen utilisé pour l’invoquer Procédure Enregistrer

« Interface/application » Le développement de l ’application en « couches » Option de Menu « Enregistrer » Bouton Image « Enregistrer Combinaison de touches « Ctrl s » Objets graphiques réactifs composant l ’interface graphique Couche Interface Couche Applicative Objets ou procédures réalisant les fonctions de l’application indépendamment du moyen utilisé pour l’invoquer Procédure Enregistrer Ce style est valable pour les boites à outils intégrant le traitement d’un Événement dans l’objet graphique.

-Exemple : schéma dynamique PILE c1 : la pile n’est pas vide empiler(i) dépiler() Afficher() vide?() 1 Afficher sélectionnée  c1:1 c1:1 c1:1 AfficherPile(int[]) MessagePileVide MessageempilerOk Resultatdépiler(int) c1:1 1 1 c1:2 2 acteur Empiler sélectionnée Dépiler sélectionnée

Exemple : Schéma de classes Application Pile getModel() View getView() Application() Pile empiler(int) int dépiler () boolean vide?() int[] afficher() View View() abonnerEmpiler(ActionListener) abonnerDepiler(ActionListener) abonnerAfficher(ActionListener) String lireValeur() afficherMessage (String) resultatDépiler(int)

« Model/View/controller » Amélioration du style « Interface/application » Boite à outils offrant deux types d’objets les objets graphiques (déclenchant l’événement) et les objets dynamiques (traitant l’événement graphique) Possibilité de réutiliser les composants de la couche « view » et les composants de la couche « model ».

« MVC » Modèle « MVC » objectif : séparer la gestion de l’interface utilisateur de la gestion de l’application pour pouvoir changer l’interface. Augmenter la réutilisation en faisant en sorte que la partie « model » ne connaît pas la partie « view » et vice versa. Seule la partie « controller » fait le pont entre les deux parties. Conséquences : réutilisation possible de composants de la couche « model » ou de la couche « view » et par contre la couche « controller » n’est pas considérée comme réutilisable ».

-Exemple : schéma dynamique PILE c1 : la pile n’est pas vide empiler(i) dépiler() Afficher() vide?() 1 Afficher sélectionnée  c1:1 c1:1 c1:1 AfficherPile(int[]) MessagePileVide MessageempilerOk Resultatdépiler(int) c1:1 1 1 c1:2 2 acteur Empiler sélectionnée Dépiler sélectionnée

Exemple : Schéma de classes Application Pile getModel() View getView() Application() Pile empiler(int) int dépiler () boolean vide?() int[] afficher() View ContEmpiler View() abonnerEmpiler(ActionListener) abonnerDepiler(ActionListener) abonnerAfficher(ActionListener) String lireValeur() afficherMessage (String) resultatDépiler(int) ContEmpiler(Application) actionPerformed(ActionEvent) ContDepiler implements ContEmpiler(Application) actionPerformed(ActionEvent) Classes réutilisées ContAfficher App ContEmpiler(Application) actionPerformed(ActionEvent) <<ActionListener>>

Exemple : Schéma de classes Couche View Application Pile getModel() View getView() Application() Pile empiler(int) int dépiler () boolean vide?() int[] afficher() View ContEmpiler View() abonnerEmpiler(ActionListener) abonnerDepiler(ActionListener) abonnerAfficher(ActionListener) String lireValeur() afficherMessage (String) resultatDépiler(int) ContEmpiler(Application) actionPerformed(ActionEvent) ContDepiler implements ContEmpiler(Application) actionPerformed(ActionEvent) ContAfficher App ContEmpiler(Application) actionPerformed(ActionEvent) <<ActionListener>>

Exemple : Schéma de classes Application Couche Model Pile getModel() View getView() Application() Pile empiler(int) int dépiler () boolean vide?() int[] afficher() View ContEmpiler View() abonnerEmpiler(ActionListener) abonnerDepiler(ActionListener) abonnerAfficher(ActionListener) String lireValeur() afficherMessage (String) resultatDépiler(int) ContEmpiler(Application) actionPerformed(ActionEvent) ContDepiler implements ContEmpiler(Application) actionPerformed(ActionEvent) ContAfficher App ContEmpiler(Application) actionPerformed(ActionEvent) <<ActionListener>>

Exemple : Schéma de classes Application Couche Controller Pile getModel() View getView() Application() Pile empiler(int) int dépiler () boolean vide?() int[] afficher() View ContEmpiler View() abonnerEmpiler(ActionListener) abonnerDepiler(ActionListener) abonnerAfficher(ActionListener) String lireValeur() afficherMessage (String) resultatDépiler(int) ContEmpiler(Application) actionPerformed(ActionEvent) ContDepiler implements ContEmpiler(Application) actionPerformed(ActionEvent) ContAfficher App ContEmpiler(Application) actionPerformed(ActionEvent) <<ActionListener>>

« MVC+source de données » Au niveau d’une application => Développement en 3 couches (MVC + Source de données) Objectif : Évolution possible de la source de données sans toucher à la logique de l’application. Changer la source de données : Changer la structure des tables, changer de SGBD, changer de protocole, répartir les données sur plusieurs bases…

« MVC+source de données » 3 Couches : View : couche gérant l’aspect visualisation Controller : partie permettant de synchroniser la couche view et la couche model Model : couche représentant la logique de l’application Source de données : couche gérant les différentes sources de données nécessaires à l’application (aussi bien en lecture qu’en écriture)

Architecture 3 tier niveau logique Application getModel() getView() View <<SourceDonnées>> Controller délègue Controller Model getApplication()

« MVC+source de données » Source de données : couche gérant les différentes sources de données nécessaires à l’application (aussi bien en lecture qu’en écriture). Cette couche contient les appels au pilote qui code et décode les trames envoyées au serveur. Application du pattern de Factory et Interface pour rendre la couche model indépendante de l’accès au serveur.

Pattern « PAC » « PAC » : « Presentation-Abstraction-Control » objectif : l’application est décomposée en plusieurs composants construits en suivant le style « MVC ». Les composants sont appelés des « PAC » agents avantages : réutilisation possibles de composants construits sur plusieurs couches.

Pattern « PAC » Approche par composant plus macroscopique Exemple : L’écritoire Composants PAC : Règles R1, A1, C1, C2…

Stratégies d’EAI Intégration d’application d’entreprises Objectif : faire coopérer toutes les applications de l’entreprise Technique permettant de manipuler le SI comme si il était réalisé par une seule application Faire évoluer le SI en intégrant de nouvelles applications coopérant avec les anciennes

Classification des techniques d’EAI Niveau d’intégration Techniques Espace de travail numérique Portail Processus Business Process Management (BPM) Transactions Serveur d’applications Données Bus logiciel

Classification des techniques d’EAI Niveau d’intégration Techniques outils Espace de travail numérique Portail Jetspeed Processus Business Process Management (BPM) Moteur de Workflow connecté à un bus logiciel Transactions Serveur d’applications WebSphere, WebLogic .. Données Bus logiciel Corba, RMI, DCOM, MQSeries …

Utilisation des techniques d’EAI Bus logiciel (Middleware) : plateforme de base permettant d’intégrer des applications hétérogènes. Serveur d’application : outil permettant de diffuser sur un serveur toutes les transactions métiers impactant les applications “back-office”. Ces transactions sont utilisées par les applications “front-office”. (Façade Métier)

Utilisation des techniques d’EAI Portail : outil permettant de gérer et de personnaliser les espaces de travail des utilisateurs. (Moteur de portail : couche haute du serveur web).

Utilisation des techniques d’EAI BPM : outil permettant de gérer les processus métier au niveau technique afin d’automatiser la communication entre les applications et/ou entre les acteurs. Cette technique permet d’automatiser les communications entre les applications bureautiques et les applications “back-office”.

Utilisation des techniques EAI ... BDD LDAP ERP Service externe SGBDR Mainframe Progiciel Service de sécurité Browser Pages HTML SERVEUR D ’APPLICATION d’ admin. Enterprise Application Integration Services Invariants $$ DIFFUSION

Architecture N-tier Concepts : Serveur d’application : Serveur permettant à des applications distantes sur un réseau local d’accéder aux services offerts par des objets métiers. Bus logiciel (Middleware) : plateforme d’intégration d’applications pour faire cohabiter et coopérer les nouvelles applications avec les anciennes applications. (3 types de coopération : Message, RPC, objet).

Architecture N-tier En termes de développement : Applications « Front-end » Développement indépendants des applications « Back-end » Serveur d’application (couche métier) : Façade « métier », Services métiers encapsulés dans des objets métiers, Services métiers offerts aux applications « Front-end » à partir d’un bus logiciel Services métiers invoquant les services offerts par les applications « Back-end » fédérées sur un bus logiciel Applications « Back-end »

Bus logiciel (MiddleWare) Faire cohabiter et coopérer les nouvelles applications avec les anciennes applications.

Intégration d’applications Appli a Appli b Appli c Machine B Appli A Appli B Appli C Machine A Appli 1 Appli 2 Appli 3 Machine C

Intégration d ’applications L’ajout d’une application à un environnement ayant n applications peut amener à construire : n liens de communication et 2*n interfaces d’applications

Bus unique de communication : Middleware Application 1 Application 2 Application 3 Application 4 Application 5 Application 6

Middleware Bus logiciel ou Plate-forme répartie Application La plate-forme d ’intégration fournit aux applications des interfaces standardisées masquant les spécificités du système (indépendance entre les applications et le système & portabilité des sources des applications) Application Chaque système d ’exploitation offre des interfaces de programmation spécifiques pour contrôler les couches de communication réseau et les périphériques matériels Une plate-forme répartie permet d ’interconnecter et de faire communiquer des applications et des services distribués et hétérogènes Interfaces standardisées Plate-forme d’intégration Interfaces spécifiques aux systèmes OS, réseau matériel

Panorama des types de middlewares Dans le panorama des bus logiciels, on distingue trois catégories : Le middleware par échange de messages (MOM) Le middleware par appel de procédure éloignée (RPC) Le middleware orientée objet (Corba – RMI- DCOM)

Principe par messages Application A Application B Début programme Attacher_files Déposer_message Lire_message File de sortie File d ’entrée Middleware par file d’attente Application A Application B

Principe RPC Unité de distribution est une fonction ou une procédure (temps de traitement >au temps de transmission). Programme principal Procédure A Procédure B Stub client Middleware RPC Stub serveur Procédure A Procédure B Interface écrite en IDL Client Serveur

Comparatif Le middleware par échange de messages (MQSeries) Le middleware fait le facteur sans interpréter le message qui est échangé Les applications émetteur et récepteur doivent avoir un pilote spécifique pour coder et décoder le message Peu évolutif, transport uniquement sans gestion de protocole Possibilités de faire : asynchrome, synchrone et du broadcast Le middleware par appel de procédure éloignée (RPC) Le message échangé est structuré comme un appel de procédure Le middleware code et décode le message => pas de développement spécifique sur les applications Possibilités uniquement synchrone Unicité des noms de procédure pour une même application Les paramètres d’entrée et de sortie des procédures ne peuvent être que des types simples (pas de types structurés)

Comparatif Le middleware orientée objet (Corba – RMI- DCOM) Même chose que ceux de type RPC Encapsulation objet des procédures Objets distribués (on accède à une référence d’objet et on invoque une méthode sur cette référence). DCOM & RMI permettent de passer en paramètre d’entrée ou paramètre de sortie un objet (objet de type serialisable)

Limites des Middlewares Les middlewares sont des techniques d’EAI de base très coûteuses et propriét aires Les types de connecteurs proposés pour intégrer une application sur le bus sont propriétaires => alternative (middleware orienté XML, connecteur JCA)

Serveurs d’application Objectif des EJBs déclaré par Sun « The Entreprise JavaBeans architecture is a component architecture for the development and deployment of object-oriented distributed entreprise level applications. Applications written using the entreprise JavaBean architecture are scalable, transactional and multi-user secure.

Vue générale du framework Objets métiers servlet Container EJB Container Databases & Backend Systems Logique applicative relative au Web (framework struts) client HTTP server EJB Server Communication via le protocole HTTP Objets distribués : technique de « bus logiciel » (RMI, Corba…) Objets distribués ou accès bases de données : technique « bus logiciel » ou JDBC

Serveur d’application Application de l’architecture « N-tier » La logique applicative est mise sur un serveur dédié à cela (serveur d’application) Utilisation combinée des techniques de « Multithreading » et « Multiprocessing » Factorisation et partage des ressources métiers entre plusieurs applications « FrontEnd ». Possibilité d’avoir des canaux d’accès différents à une même application (Web, Teléphone portable, palm …)

Serveur d’application Application de l’architecture « N-tier » L’approche « N-tier » est une architecture qui peut s’avérer plus facile à faire évoluer techniquement (répliquer les serveurs …) Le serveur d’application est une « façade » métier à toutes les applications BackEnd de l’entreprise (EAI). Cette application est utilisée par toutes les applications FrontEnd => offre une indépendance entre les deux types d’applications FrontEnd et BackEnd. Ce principe permet de mettre en place de nouveaux services métiers au niveau du serveur d’application sans avoir à casser les applications BackEnd existantes (ajouter une nouvelle application BackEnd sur le bus logiciel).

Serveur d’application Application de l’architecture EJB L’approche par composants EJB offrent au niveau serveur la portabilité et la réutilisation dans le développement des objets métiers.

BPM Moteur de Workflow intégré à un bus logiciel pour faire communiquer plusieurs applications « back-end » et outils type bureautique (agenda, mail, chat …).

BPM Modélisation des processus techniques sous forme de Workflow (Taches, Connecteurs). Les tâches peuvent être des tâches systèmes ou utilisateurs. Le moteur de workflow contrôle l’exécution du processus en déterminant à la fin de l’exécution d’une tâche, les tâches suivantes à exécuter et lance leurs exécutions. Bénéfice de ce type d’outil : opérationnalise les Model-driven architectures Technique se plaçant entre les serveurs de présentation et les serveurs d’application

Portail Moteur de Portail permet de définir des pages Web selon des profils utilisateurs ou utilisateurs. Les composants intégrés dans les pages ou templates de page sont des « Portlets ». Simuler à travers les techniques Web les fonctionnalités de personnalisation du « bureau ». Personnalisation du contenu et du style.

Portail Portail : couche logicielle s’ajoutant au dessus d’un serveur Web Outils d’administration comme une base de données pour la connexion des utilisateurs et la configuration de chaque espace personnalisé. Souvent utilisé pour normaliser les espaces de travail des différents employés d’une entreprise selon leur rôle. De plus en plus utilisé comme technique permettant d’améliorer la relation avec le client.

Techniques de développement par composants Niveau d’intégration Techniques Composants Espace de travail numérique Portail Portlets Processus Business Process Management (BPM) tasks Transactions Serveur d’applications EJB, Active X Données Bus logiciel Composants Corba Applications

Techniques à base de service Web services SOAP WSDL UDDI Middleware orienté XML (JAXM, JAXRPC) Connecteur JCA

Techniques à base de service Web services : composants métiers distribués sur le Web (services back-office) WSDL : descripteur normalisé définissant les procédures fournis par un service SOAP : Simple Object Access Protocol Sur-couche sur le protocole HTTP protocole utilisé pour l’invocation d’un service trame codée en XML

Techniques à base de service UDDI : Uniform Discovery Directory Interface Interface standardisée pour rechercher un service Web et obtenir en résultat le descripteur WSDL du service en question. Pour publier un service Middleware Orienté XML supportant le protocole SOAP pour faire communiquer l’application demandant un service avec l’application fournissant le service. Le style ‘RPC’ est utilisé lorsque la communication est synchrone (request-reply) Le style ‘Message’ est utilisé lorsque la communication est asynchrone (one-way, sollicitation).

Techniques à base de service Connecteur JCA (Java Connector Application) : Les connecteurs JCA sont utilisés comme technique d’emballage pour accéder aux services fournis par une application (technique d’emballage normalisée)

Plan Développement Web Développement de Composants Métier « Vers un développement par composants » Développement de Composants Métier