Services et composants

Transcription

1 - 1 - Services et composants Module BPM & SOA SI5 - Master 2 IFI

2 - 2 - Quels sont les liens entre objets et services?

3 Évolution des paradigmes liés à la réutilisation Technologie procedurale Technologie objet Technologie composant Procedures, Pascal, C,... Objects, Classes, Smalltalk, C++,... Composants, Containers Interfaces in et out, EJB, CCM, Raffinement Encapsulation et Spécialisation Composition par assemblage - 3 -

4 XML parsing dans Tomcat Copyright aspectj.org En rouge, les lignes de code concernées par le parsing Bonne modularisation : code concentré en un seul endroit - 4 -

5 URL pattern matching dans Tomcat Copyright aspectj.org En rouge, les lignes de code pour gérer la correspondance d URLs Bonne modularisation : code concentré en 2 endroits - 5 -

6 Trace dans Tomcat Copyright aspectj.org En rouge, les lignes de code pour tracer l exécution Mauvaise modularisation : le code est mélangé, éparpillé et redondant - 6 -

7 Quelques unes des limites de la POO «programming in the small» Interactions entre objets enfouies dans le code Structure et architecture de l application peu visibles Évolution fastidieuse Gestion de la consistance d un changement délicate - 7 -

8 Objets et encapsulation Granularité encore trop fine Mal adaptée à la programmation à grande échelle Couplage fort et périmètre non défini Rend difficile la réutilisation Accroît la complexité des Systèmes OO - 8 -

9 Programmation constructive (ou par composition) «programming in the large» (programmation à gros grain) Motivation : le «time to market» Amélioration de la productivité et de la qualité des logiciels Réduction des coûts Approche : réduire la complexité et «monter» le niveau d'abstraction Décrire l'architecture et les interactions entre instances Assembler plutôt que développer La modélisation des composants est intégrée à UML

10 Analogie avec les composants électroniques, legos, puzzles

11 Analogie avec les composants électroniques, legos, puzzles * * Composants logiciels * Des unités interchangeables

12 Structure d un composant Interactions avec un composant ce qui est fourni par le composant ce qui est utilisé par le composant modes de communication Interfaces fournies Interface de configuration Configuration du composant propriétés (attributs publics) connexions cycle de vie (arret, redemarrage,...) contraintes techniques (transaction, persistance, sécurité,...) Interfaces requises! Type de composants vs instance de composants

13 Notion d interfaces & de contrats Une interface est un contrat d utilisation Quelles sont les conditions de déclenchement des exceptions? Qu en est-il des accès concurrents? Quelles conditions y-a-t-il sur les valeurs des opérations? Dans quel ordre faut-il appeler les opérations? Différents niveaux de contractualisation Syntaxique : signature d opération (interfaces Java) Comportemental : assertions UML/OCL, Fractal/Confract, JML,... Synchronisation : automates (StateCharts, protocoles Sofa,...) Qualité de services : attributs spécifiques (temps de réponse, précision du résultat, cout d'accès,...) Plus les interfaces d un composant sont détaillées, plus la composition du composant avec son environnement est définie et claire

14 Points de vue Arbre V.I. Nourriture M.I. CalculDuVol Arbre V.I. Couleurs,Taille M.I. Dessiner Arbre V.I. Taille,Poids, Couleur,feuillage M.I. Grandir Arbre V.I. prixdevente Temps-De-Coupe M.I. Calcul-Profit Arbre V.I. valeur-estimée M.I. Estimer-Valeur Calculer-Taxe Découpage de la spécification des fonctionnalités d un composant en plusieurs interfaces Localisation des dépendances inter-composants et réduction de l impact des changements Gestion des points de vue utilisateur

15 Interface requise, notion de port et utilisation des composants Interface requise Un composant précise les interfaces fournies par d'autres composants qu'il utilise pour réaliser ses traitements Moyen de composition des composants et meilleure visibilité des dépendances Port Un composant fournit des mécanismes pour être connecté, éventuellement dynamiquement, à d'autres composants. Un port correspond à une interface fournie ou requise. Utilisation d un composant On ne s adresse pas directement à un composant comme pour un objet Obligation de passer par l un de ses ports

16 Exemple de composant : distributeur de boissons To use a vending machine, you put money into it and make a selection. When you make your selection, the vending machine goes through several steps; verifying that it has received sufficient amount, computing change and making sure selected item is in stock. The item you selected and change get out of the vending machine. ( De temps en temps la machine doit aussi être : réapprovisionnée réparée Que fournit la machine? Que requière-t elle?

17 Exemple de composant : distributeur de boissons payer, sélectionner, prendreproduit, prendremonnaie, ouvrir, remplir, mettremonnaie, mettreproduit, fermer Distributeur de boissons encaisser, calculerappoint, majstock

18 Exemple de composant : distributeur de boissons payer, sélectionner, prendreproduit, prendremonnaie, ouvrir, remplir, mettremonnaie, mettreproduit, fermer Distributeur de boissons encaisser, calculerappoint, majstock

19 Exemple de composant : distributeur de boissons Consommateur payer, sélectionner, prendreproduit, prendremonnaie encaisser, calculerappoint Facturation Fournisseur ouvrir, remplir, mettremonnaie, mettreproduit, fermer Distributeur de boissons majstock Stock Dépanneur ouvrir, fermer Modularité au niveau des fournis mais aussi au niveau des requis Flexibilité d utilisation : on exporte que ce que l on utilise vraiment

20 Constat Peu de guidelines Dans quel cas utiliser un composant? Dans quel cas continuer à utiliser un objet? Est ce que tout doit devenir composant? Est ce que tout peut devenir composant? On a besoin des 2 niveaux de granularité! Mais quand passer de l un à l autre?

21 Identification des composants Méthode Grady Booch / Softeam A partir d un diagramme de classes UML Regrouper les classes en catégories Limiter le regroupement à 12 classes max Propriété d une catégorie : ensemble de classes stable, consistant, mono préoccupation, continu (agrégat de classes) Le choix de la création des catégories est en partie empirique : l important est de promouvoir les catégories d un projet à l autre

22 Exemple de composant : gestion bancaire

23 Exemple de composant : gestion bancaire Encaissement Portefeuille Client Devis Ventes

24 Exemple de composant : gestion bancaire Portefeuille Client Encaissement Ventes Devis

25 Assemblage de composants et interactions L'assemblage de deux composants se fait en connectant un port de sortie (interface requise) avec un port d'entrée (interface fournie) qui doivent respecter un contrat Type de communication Un mode d'interaction doit être choisi pour que la connexion soit établie Composite Les composants peuvent être composés d'autres composants Assemblages manipulables comme des composants Re-configuration dynamique Permet de modifier l'application à chaud sans modification du code en manipulant les assemblages Utilité très importante dans le cadre de l informatique ambiante Apparition & disparition de services suivant le contexte

26 Assemblage de composants : distributeur de boissons Consommer: payer, selectionner, prendreproduit, prendremonnaie Réapprovisionner: ouvrir, remplir, mettremonnaie, mettreproduit, fermer Réparer: ouvrir, fermer Distributeur de boissons Facturer: encaisser, rendremonnaie GererStock: majstock Contrat Contrat Facturation Facturer: encaisser, rendremonnaie GererStock: majstock Stock

27 Assemblage de composants : gestion bancaire Portefeuille Client Encaissement Ventes Devis

28 Re-configuration dynamique Consommer: payer, selectionner, prendreproduit, prendremonnaie Facturer: encaisser, rendremonnaie Réapprovisionner: ouvrir, remplir, mettremonnaie, mettreproduit, fermer Réparer: ouvrir, fermer Distributeur de boissons

29 Re-configuration dynamique Consommer: payer, selectionner, prendreproduit, prendremonnaie Réapprovisionner: ouvrir, remplir, mettremonnaie, mettreproduit, fermer Réparer: ouvrir, fermer Distributeur de boissons Facturer: encaisser, rendremonnaie Facturation version

30 Re-configuration dynamique Consommer: payer, selectionner, prendreproduit, prendremonnaie Réapprovisionner: ouvrir, remplir, mettremonnaie, mettreproduit, fermer Réparer: ouvrir, fermer Distributeur de boissons Facturation version 1 Facturer: encaisser, rendremonnaie Facturation version

31 Composition et vérifications Interconnexions manquantes ou invalides Propriétés de vivacité et de sûreté Contractualisation m n p... A B Si les composants en entrée sont corrects, l'opération de composition garantit que le composant résultant est correct également

32 Les composants dans la nature Spécifications : EJB (Enterprise Java Beans) CCM (CORBA Component Model) Fractal Beaucoup de concepts Pas d unification SCA (Service component Architecture) => pour SOA... Différentes façons de les implémenter Plates-formes d'éxecution Pour EJB : IBM Websphere, BEA Weblogic, Jboss, Jonas,... Pour SCA : Apache Tuscany, IBM Websphere, HydraSCA, fabric3, Il n existe pas un unique modèle à composants Pas un modèle meilleur que les autres Utilisation d'un modèle particulier guidée par les besoins applicatifs et techniques

33 Convergence composants / services Ports de composants = services Le service désigne le point de vue du consommateur, c est à dire la vue externe du composant Composant = fournisseur / consommateur de services Notion de contrat très importante dans les SOA Norme SCA, un représentant de cette convergence Initiative IBM, Oracle, BEA, SAP, Sun, TIBCO, But : structurer l'implémentation des SOA Indépendance langage de programmation protocoles de communication

34 Choix communication au niveau des connecteurs WSDL/SOAP Java RMI JMS... Assemblage de composants SCA Choix du langage d implémentation Java C++ BPEL... Source : oasis-open.org

35 Lien entre composants et architectures techniques pour l orienté services?

36 Architecture triangulaire Toutes les parties ne sont pas forcément réifiées Source : Didier Donsez

37 Standards de l architecture triangulaire Les standards sont un élément clé d une SOA, ils assurent l interopérabilité UDDI Microsoft, IBM, HP Universal Description Discovery and Integration Enregistre les services Les trois piliers des Services Web WSDL W3C Web Services Description Language Décrit le contrat WSDL W3C Web Services Description Language Décrit le contrat SOAP W3C Simple Object Access Protocol Transporte

38 SOA et web services Attention à ne pas confondre les 2! SOA est un ensemble de concepts : Une SOA peut se mettre en œuvre sans Web Services Les WS sont de l ordre de la technologie : On peut utiliser les Web Services sans faire de SOA Les WS constituent la meilleure solution standardisée disponible

39 Architecture triangulaire enrichie Services annotés et recherchés sémantiquement

40 Autre déclinaison de l architecture triangulaire : WOA avec REST (Representational State Transfer) Les services Restful exposent leurs données et fonctionnalités en tant que ressources à travers des URI Principe d uniformité des interfaces : les consommateurs interagissent avec les ressources à travers un ensemble prédéfini et fixe de verbes (essentiellement CRUD) Plusieurs représentions des ressources sont acceptées URLs HTTP methods Content- Types i.e., GET, POST, PUT, DELETE i.e., (X)HTML, XML, JSON, txt

41 Architecture triangulaire avec composants Les fournis et requis sont explicités (en vert) Fournisseurs et consommateurs sont des composants Implémentation dédiée en SCA

42 Impact sur les couches SOA *

43 Impact sur les couches SOA *

44 Impact sur les couches SOA * Ces différents modes de couplage sont nécessaires et dépendent du niveau dans l architecture

45 Conclusions

46 Chronique d une évolution Assembleur Langages machine Langages procéduraux objets * * composants services services Niveaux d abstraction grandissant Source : école Hes SO

47 Paradoxe des principes fondamentaux Utilisation de standards MAIS un standard reste un standard tant qu il y a hégémonie (cf échec de CORBA) Course à la spécification W3C vs OASIS vs OMG UML BPEL WS-CDL BPMN SOAML ebxml BPSS

48 Paradoxe des principes fondamentaux Pas de remise en cause de l existant lors d évolutions technologiques MAIS les éditeurs nous asservissent avec leurs suites d outils services

49 Paradoxe des principes fondamentaux Découplage entre fournisseurs et consommateurs de services MAIS pas de garde fou par rapport au couplage fort entre fournisseurs et consommateurs possiblement réintroduit par la couche IT services

50 Paradoxe des principes fondamentaux Découplage entre fournisseurs et consommateurs de services Mais les services sont fortement couplés à une présentation (IHMs) c est- à- dire les consommateurs ultimes! Lorsque des services sont orchestrés, comment les présenter à l utilisateur? Comment obtenir une orchestration de leur IHM? Flight Application Hotel Application IHM * IHM * service Tour operator Application? IHM *? service * Les IHM ne sont pas des services actuellement Orchestration de services

51 Paradoxe des principes fondamentaux Indépendance des ressources vis à vis de ceux qui les utilisent MAIS la gestion des données et leur virtualisation est encore un enjeu Les services doivent être sans état MAIS beaucoup proposent de fédérer l accès aux données par des services

52 Quelques références Quelques modèles à composants du passé et du présent CCM spec Fractal spec Service Component Architecture (SCA) OpenCCM Sofa