La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

SOA (Service Oriented Architecture) Architectures Orientées Services

Présentations similaires


Présentation au sujet: "SOA (Service Oriented Architecture) Architectures Orientées Services"— Transcription de la présentation:

1 SOA (Service Oriented Architecture) Architectures Orientées Services
PRESENTER PAR Ahmed LAFTIMI CNAM RESPONSABLES DE FILIERE Monsieur Bruno Van Moerkercke NFE 107

2 Objectif de la présentation => Définir, Identifier
Sommaire Partie I  -Entropie des systèmes d’Information Partie II - Les Architectures orientées services Partie III - SOA-Concepts et Composants Conclusion, Bilan & Perspectif Insérez une carte du pays. Objectif de la présentation => Définir, Identifier

3 Introduction Problématique Face au changement quoi faire ?
Évolution des Systèmes d’information Architecture Processus Fluides Le grand défit de l’informatique est les problèmes de communication et de l’intégration entre application hétérogènes au sein d’une entreprise, les acteurs ont tenté de les résoudre par divers méthodes et technologies ; Scriptes pilotés par des patch Par FTP échange de fichiers Middleware orientés messages EAI Avec CORBA ils ont essayé de porté une réponse standardisé à la problématique mais malheurseent sans réel succès . Or l’empilement des applications , bien entendu avec leur problématique sur de longue annnée , et l’abscence de solutions architecturale a conduite à une situation de blocage vis a vis des exigences des métiers , ce qui a pousée à la naissance des situations de Silos Les architectures SOA offrent aujourd’hui la solution pour résoudre ces problématiques Presentation va définir les SOA et les usages Exposer le conceptes de service Eclairsie l’amalagame entre SOA et web service Mieux aligner le SI (Système d’Information) et les métiers, faciliter l’accès à l’information et rendre les processus plus fluides. SOA est une approche d’architecture et ne fait pas l’hypothèse sur la technologie de mise en œuvre et la conception des Web Services a été menée dans l’objectif de répondre au mieux aux enjeux de l’architecture SOA. Ainsi, les Web Services sont une technologie pour mener une démarche SOA. Mettre en place une Architecture Orientée Services consiste à concevoir et construire un système d’information et les applications qui la composent à partir d’un ensemble de service logiciels indépendants, mais capables de communiquer les un avec les autres. L’objectif de ce document est d’établir un aperçu globale sur les différents spécifications qu’on pourrait mettre en ouvre dans le cadre d’une architecture SOA. En quelques années, l’architecture orientée service (SOA) est devenue un thème majeur pour les systèmes d’information d’entreprise. Plus qu’une nouvelle technologie ou méthode, c’est la convergence de plusieurs approches existantes, et l’émergence d’une forte adhésion des directions informatique et métier à un même objectif : une meilleure agilité des systèmes face aux transformations nécessaires. SOA POUR UNE MEILLEURE AGILITE

4 Sommaire Partie I -Entropie des systèmes d’Information
Partie II - Les Architectures orientées services Partie III - SOA-Concepts et Composants Conclusion, Bilan & Perspectif Cette partie rappel l’évolution des technologies informatiques et ses conséquence en terme d’entropie pour le système d’information. Et le constat de la difficulté à maintenir un SI homogène et rationnel

5 Partie I - Entropie des systèmes d’Information
Histoire -> 1ER Génération Centralisation et terminaux passifs Le Mainframe Ordinateur central Terminaux Serveur unique Avantage : assure la haute disponibilité et l’intégrité des données et offre à l’entreprise un système cohérent et fiable. Inconvénient : Couts d’acquisition et d’exploitation sont élevés L informatique conçu des applications monolitiques, d’où lidée que toute l’informatique des entreprise était centrée dans un serveur unique : Mainframe . Le mainframe représente ainsi un ordinateur central de grande puissance chargé de gérer les sessions utilisateurs des différents terminaux qui lui étaient reliés. Il support en général des applications de gestion essentielles pour l’entreprise, c'est-à-dire de gérer de manière centralisée, l'ensemble des applications métiers de l'entreprise.

6 Partie I - Entropie des systèmes d’Information
Histoire -> 2éme Génération Introduction Histoire informatique Solutions et limits Application client/Serveur Computer Personnel Architecture client/serveur Avantage : faible coût des nouvelles applications plus légères Inconvénient : duplications d’informations , le poste de travail deviens charge de plusieurs exécutables Applis délocalisées, données centralisées Avec l’invention du Pc (Computer Personnel), l’informatique commence à être utilisée par tous les profils de l’entreprise grâce au faible coût des nouvelles applications plus légères, en architecture clients/Serveur. L'architecture client/serveur désigne un mode de communication entre plusieurs ordinateurs d'un réseau qui distingue un ou plusieurs postes clients du serveur : chaque logiciel client peut envoyer des requêtes à un serveur. Un serveur peut être spécialisé en serveur d'applications, de fichiers, de terminaux, ou encore de messagerie électronique. Malheureusement la croissance rapide des SI et l’absence de gouvernance de cette croissance a abouti à des duplications d’informations. De plus le poste de travail deviens charge de plusieurs exécutables difficiles à maintenir et de multiples interface s’est révélée complexe à maitriser.

7 Partie I - Entropie des systèmes d’Information
Histoire -> 3éme Génération Re-centralisation, interfaces client relookées Application Web Pas de logiciel sur le poste de travail Accès à distant via un navigateur web aucune installation de logiciel n'est nécessaire sur le poste client, un navigateur web suffit ; possibilité d'accès distant ; compatibilité avec différents systèmes d'exploitation : Windows, Linux… En génie logiciel, une application web (parfois appelée "Web App") est une application livrée aux utilisateurs à partir d'un serveur web par un réseau tel que l’Internet ou l’Intranet. Les applications web sont populaires pour de nombreuses raisons : grâce à l'ubiquité du Navigateur Web comme client, parfois appelé « client léger ». La capacité de mettre à jour et maintenir des applications web sans distribuer ni installer le logiciel sur potentiellement des milliers d'ordinateurs de clients.

8 Partie I - Entropie des systèmes d’Information
Histoire -> 4éme Génération Web services et SOA ?

9 Partie I - Entropie des systèmes d’Information
État des lieux des SI État actuel Hétérogène Redondant Coût de maintenance État cible Homogène Rationnel Rigide Agile Chacune de ces technologies citées ont bien marque leur place dans l’histoire de l’informatique, bien évident, chacune a ses avantages et ses inconvénients. Par ailleurs, la généralisation de l’outil informatique dans les directions métiers fait que les utilisateurs attendent toujours plus du SI (Système d’Information), soit au niveau d’agilité, soit au niveau de l’intégration des acteurs externes de leur SI. Il devient donc vital de trouver des moyens de mieux gérer et homogénéiser le système d’information. Le constat est que le DSI doivent trouver un moyen d’organiser et de maîtriser cette hétérogénéité Et rationaliser la mise en commun d’information transverses à l’entreprise un référentiel Divergence Besoins métier SI Alignement Besoins métier SI

10 Partie I - Entropie des systèmes d’Information
Réponses actuelles -> Urbanisation -> Modèle de référence Processus métier Fonctionnel Use cases Applicatif Applications & logiciels Physique Infrastructure La première réponse historique à la rationalisation du SI est la démarche dite l’urbanisation . L’urbanisation des SI travaille sur : Processus métiers Communications inter applicative Sur la mise en place d’un référentiel transverses Resulat : Le système d’information d’une entreprise est représenté selon quatre niveaux d’architecture: L’architecture métier : processus métier de l’entreprise L’architecture fonctionnelle : blocs fonctionnels et flux d’information supports à la réalisation des processus métier, indépendamment des technologies mises en œuvre, L’architecture applicative : blocs applicatifs et échanges, supports à la réalisation des blocs fonctionnels et des flux. L’architecture technique : infrastructure sur laquelle sont implémentées et exécutés les blocs fonctionnels . Objectif est d’avoir une vue d’ensemble du SI

11 Partie I - Entropie des systèmes d’Information
Réponses actuelles -> Urbanisation -> Phénomène vertical Processus rigides Processus complexes Processus non transférables + Composants peu réutilisables Hétérogénéité technologique = Problématiques des silos applicatifs Métier Fonctionnel Applicatif Physique Division A Division B Le problème hétérogénéite technologique et plus que les applications sont mal équipés pour communiquer avec les autres blocs on parle de fonctionnement en silos

12 Partie I - Entropie des systèmes d’Information
Réponses actuelles -> Urbanisation -> Phénomène horizontal Métier Fonctionnel Applicatif Physique Redondance Données Traitements Parc applicatif rigide Interdépendance élevée Difficulté d’évolution Chaque silo est généralement autonome et isolé en terme de processus, d’interface home/machine, de socle technique. Ainsi la vision par couche des urbanistes se heurte à une réalité technique qui bloque leur démarche globale de rationalisation. Et les communications inter applicatives sont souvent gérées au cas par cas en fonctions des besoins d’où l’idée « Syndrome du plat de spaghettis » « Syndrome du plat de spaghettis ???»

13 Partie I - Entropie des systèmes d’Information
Réponses actuelles -> Outillage silos spaghetti Commentaire EAI NON OUI Coût d’implémentation élevé Propriétaire, dépendance envers l’éditeur Point de passage obligé Workflow Coût élevé d’adaptations aux applications existantes élevé Portail Paramétrage laborieux Framework applicatif Potentiel élevé de réutilisation et de composition Forte adhérence technologique Réutilisation non généralisable à l’ensemble du SI Réponses à cette problématique par les outils EAI, Workflow, les portails web, les langages objet  On est convaincu que la démarche d’urbanisation est louable. Les solutions jusqu’à maintenant ne donnent pas satisfaction, les outils EAI, et Workflou sont limitée et s’applique dans un monde propriétaire et favorise le fonctionnement par silos. Conclusion : les outils d’urbanisation cités ci-dessus ont conduit à une frustration car les solutions sont parcellaires et dépendantes des technologies et des éditeurs Les exigences des métiers et de la DSI vis-à-vis d’un SI agile sont exprimées aujourd’hui en ces termes, un SI doit être capable de : s’adapter rapidement à une fusion ou une réorganisation des équipes. de déployer rapidement des procédures sur la base d’un modèle fourni par les métiers. Fournir une interface même pour les clients les fournisseurs Doit pérenniser ses briques existantes et favoriser la réutilisation. EAI (Enterprise Application Integration) Workflow est un flux d'informations au sein d'une organisation

14 Sommaire Partie I -Entropie des systèmes d’Information
Partie II - Les Architectures orientées services Partie III - SOA-Concepts et Composants Conclusion, Bilan & Perspectif Pour bien saisir l’impact de SOA sur les entreprises, il convient de revenir sur les bases de ce concept. Trop souvent assimilé à des technologies, SOA n’est qu’un principe d’architecture, qui concerne tant l’organisation de l’entreprise que celle de son informatique. Trop souvent des projets s’enlisent parce que l’entreprise n’a pas pris en compte cette double dimension. D’un point de vue technique, les SOA préconisent la structuration d’applications par assemblage de composants applicatifs et non plus, comme par le passé, sur la base d’une ou deux applications monolithiques. Baptisés « services », les composants applicatifs peuvent être de type technique (accès aux données, système de reprise sur erreur, etc.) ou métier (commande, facture, etc.). La définition de cette granularité est, comme la mise à plat des processus de l’entreprise, une étape déterminante

15 Partie I - Entropie des systèmes d’Information
SOA Concrétise le modèle d’urbanisation Processus métier Fonctionnel Use cases Applicatif Applications & logiciels Physique Infrastructure Métier Technique Vue logique Le concept de SOA met d’emblée en avant l’importance de l’architecture du SI . La démarche SOA a en effet pour objectif général de faire évoluer cette architecture afin de répondre au problèmes des silos . Une solution stratégique favorise la modélisation des couches d’abstraction entre un monde réel des processus les technologie utilises , ce qui va concrétiser la vue Logique ( service) qui va répertorie les fonctions métiers et les présente sous forme de services.

16 Partie II - Les Architectures orientées services
Qu’est ce que SOA SOA est apparu en 1996 dans une note de recherche du Gartner Group. « L’architecture orientée service constitue un style d’architecture basée sur le principe de séparation de l’activité métier en une série de services. » « Ces services peuvent être assemblés et liés entre eux selon le principe de couplage lâche pour exécuter l’application désirée. » « Ces services sont définis a un niveau supérieur de la traditionnelle approche composants » Gartner - Septembre 2005 Selon le Gartner Group, plus de 75% des projets d’entreprise des années 2008 reposeront sur les SOA (Service Oriented Architecture).   Gartner, Inc., fondée en1979, est une entreprise américaine de conseil et de recherche dans le domaine de la technologie. Le terme SOA est apparu en 1996 dans une note de recherche du Gartner Group. Selon le Gartner Group, plus de 75% des projets d’entreprise des années 2008 reposeront sur les SOA (Service Oriented Architecture). L’objectif de cette partie est de chercher en claire ce qui ce cache derrière ces trois lettres « SOA ». Et présenter les concepts clefs tels que le concept de services et le concept de composition de service, en mettant en évidence la relation qui doit s’établir entre les clients des services et les fournisseurs.

17 Partie II - Les Architectures orientées services
Qu’est ce que SOA-> Définition Selon l’OASIS « l’architecture orientée service (SOA ): est un paradigme d’organisation des ressources distribuées, potentiellement contrôlées par des domaines différents. » L’objectif de cette partie est de chercher en claire ce qui ce cache derrière ces trois lettres « SOA ». Et présenter les concepts clefs tels que le concept de services et le concept de composition de service, en mettant en évidence la relation qui doit s’établir entre les clients des services et les fournisseurs. Une architecture orientée services (notée SOA pour Services Oriented Architecture) est une architecture logicielle s'appuyant sur un ensemble de services simples. L'objectif d'une architecture orientée services est donc de décomposer une fonctionnalité en un ensemble de fonctions basiques, appelées services, fournies par des composants et de décrire finement le schéma d'interaction entre ces services. L'idée sous-jacente est de cesser de construire la vie de l'entreprise autour d'applications pour faire en sorte de construire une architecture logicielle globale décomposées en services correspondant aux processus métiers de l'entreprise. Lorsque l'architecture SOA s'appuie sur des web services, on parle alors de WSOA, pour Web Services Oriented Architecture OASIS (Organisation for Avancement of Structured Information Standards)

18 Partie II - Les Architectures orientées services
Qu’est ce que SOA-> Naissance de la notion SOA Le SI de l'entreprise est généralement constitué d'applications en silo = -Transversalité - Vision Globale La solution à ce problème EAI ? Elle consiste à développer des connecteurs spécifiques permettant de faire communiquer entre-eux les différents silos de l'entreprise. (Enterprise Application Integration, traduisez intégration des applications de l'entreprise) Partenaires = connections Comme on l’a vu au chapitre 1, l’entreprise, construite historiquement autour des silos verticaux. Imaginez : l'arrivée d'un nouveau partenaire dans votre organisation. Quasi instantanément vous serez en mesure de connecter votre prise de commande à la sienne, son système de facturation au vôtre, et les gains en terme d'efficacité de votre organisation seront évidents. Résultat : plus de doubles saisies, plus de développement de programmes d'interface, une cohérence globale du SI obtenue avec de moindres efforts. Les outils EAI, etc. ont déjà ouvert la voie de cette orientation.

19 Partie II - Les Architectures orientées services
Qu’est ce que SOA-> Naissance de la notion SOA-> POA ET EDA EDA( Event Driven Architecture) : Propagation automatisée des nouvelles informations métiers dans le SI pour éviter la désynchronisation de multiples référentiels. Nécessite la mise en place l’outils EAI. POA( Process Oriented Architecture) : application modéliser comme un processus, ce qui nécessite la mise en place d’un moteur pour automatiser ces processus ( Workflou) SOA trouve la solutions aux problématique des autres solutions

20 Partie II - Les Architectures orientées services
Qu’est ce que SOA-> Naissance de la notion SOA Programmation structure = robuste et réutilisable Langage purement procéduraux -> Code réutilisable? = (fonctions + des procédures) Fichier sépare Programmation Orientée Objet (POO) -> Code réutilisable? = définition et l'assemblage de briques logicielles (Objets) ; Envoie des messages grâce aux appels des méthodes Solutions de transports au delà des frontière des SI --->>> Problèmes de compatibilité entre plateformes Besoin de standardisation et la mise en commun des protocoles ( SOAP, XML,….) La pensé orientée services Pour comprendre l'avènement et en quoi consiste le SOA, il est nécessaire de bien identifier que le but de la programmation structurée, est d’écrire du code qui soit robuste et réutilisable. Au tout début, il n’existait que les langages purement procéduraux, la seule façon d’écrire du code réutilisable était d’écrire des fonctions et des procédures dans un fichier séparé du corps du programme, et de faire appel à ce fichier chaque fois que nécessaire. Ensuite, est apparue la Programmation Orientée Objet (POO). Elle était innovante dans le sens ou le concept même d’ « objet » permet l’encapsulation et donc de masquer la complexité des opérations. Les objets peuvent s’envoyer des messages, grâce aux appels de méthodes exposées par l’objet avec lequel ils souhaitent communiquer sans pour autant savoir comment ledit objet implémente le traitement qu’on lui demande d’exécuter. Malgré le fait que des technologies comme DCOM, RMI ou .Net Remoting permettent de transporter les objets et donc de dépasser les frontières de la machine grâce au réseau, on s’est souvent heurté à des problèmes de compatibilité entre plateformes, d’où le besoin d’une standardisation et la mise en commun des protocoles (SOAP, XML, …). De là est née la notion d’architecture orientée services (SOA). SOAP (Simple Object Access Protocol) est un protocole d'échange

21 Partie II - Les Architectures orientées services
Vision POO et SOA ? -> savoir où se situent les différences Modèle orienté objets (POO) Vision POO et SOA ? Pour mieux comprendre la vision SOA, il est bien de faire distingue deux écoles : une orientée objets et l'autre orientée services. Modèle orienté objets (POO) Voici une architecture à trois couches classique avec un modèle objet : On remarque tout de suite le nombre de liens entre la couche Présentation et les objets métiers. Le code client doit jongler directement avec le modèle objet de la couche métier, ce qui a pour conséquence de lier celle-ci très fortement à un modèle spécifique et requiert un nombre d'appels important entre les deux couches. La multiplication des appels entre couches pose problème lors de la mise à disposition à distance des objets métiers, et que le nombre d'objets à manipuler réduit l'indépendance entre couches et complexifie la prise en main de la couche métier. Modèle orienté services (SOA) Voici une architecture orientée services qui reposerait sur les mêmes objets métiers : On remarque que l'on a introduit un niveau d'indirection supplémentaire sous la forme de services. La couche présentation ne manipule plus directement les objets métiers, mais passe par des services. Les objets métiers se trouvent dans des bibliothèques de classes directement chargées dans le même processus que les services et par conséquence coût des appels aux objets métiers est très faible. Les services agissent comme des boites noires faisant abstraction de la complexité du modèle objet, présentant un ensemble de fonctionnalités restreints et permettant de réduire les échanges entre les couches. Modèle orienté services (SOA) Services ?

22 Partie II - Les Architectures orientées services
Qu’est ce que SOA-> Couverture des besoins SOA apporte au SI : • De la réutilisabilité ? • De l’interopérabilité ? • De la flexibilité ? • SOA est un concept qui n’est pas lié à la technologie.. • Une implémentation s’effectue sur la base de normes et de standards. La clé : l’agilité Des services sans état Des services interopérables Des services faiblement couplés Les services inscrit dans une urbanisation SOA sont conçus pour être sans-état afin de pouvoir être utilisé en dehors de tout contexte applicatif Les services sont définis selon les standards du marché de manière à pouvoir être utilisés facilement aussi bien en interne qu’en externe du SI Les combinaisons de réarrangement des services métiers selon des préceptes de couplage lâche offrent de nombreuses possibilité vis à vis de l’évolution du métier Depuis le début, le terme SOA est évoqué mais la traduction de cet acronyme « Service-Oriented Architecture » par Architecture Orientée Service ne permet pas de comprendre exactement ce qu'il signifie. Une définition simple pourrait être la notion d'intégrer et de manipuler les différents composants d'un système informatique en tant qu'ensembles fonctionnels appelés services. Cette architecture à la mode répond aux problèmes de réutilisation d'outils (ou produits) des entreprises. Pour mieux comprendre sa définition, il faut voir cette architecture comme une philosophie. C'est une approche permettant de réutiliser et d'organiser des ressources existantes, dans une solution autorisant une interopérabilité entre plateformes et environnements, une évolutivité des modules applicatifs et une flexibilité autorisant l'utilisation dynamique d'applications. Cette solution permet donc d'intégrer divers systèmes : chaque ressource peut être accessible en tant que service possédant une interface. L'implémentation du fournisseur de service est donc libre de changer sans qu'il y ait un impact sur son utilisation. On peut voir ce service comme une boîte noire : on sait qu'elle va rendre le service voulu sans savoir comment est faite la boite noire. On peut choisir de la remplacer par un autre service implémenté différemment mais répondant aussi à la même fonctionnalité. Un exemple concret est le service qui a été créé par la SNCF : réserver une place de train. Une architecture SOA a été implémentée et l'un des services offre la possibilité de réserver une place de train : que l'on y accède de leur site internet ou d'un guichet, le service est le même. La personne qui fait la réservation utilise un client pour se connecter : un consommateur de service.

23 Partie II - Les Architectures orientées services
Qu’est ce que SOA-> Principes Les 4 grands principes du SOA La définition des services Les services sont autonomes Les clients et les services ne partagent que des contrats La compatibilité est basée sur les règles Service Les 4 grands principes du SOA Le principe même de SOA repose sur les 4 principes suivants : - La définition du service est explicite : Un service est une classe exposée à travers les réseaux. Le but de ce service est de fournir une prestation bien définie (exemple : fournir la date et l’heure dans un pays donné). Les détails d’un service (la manière dont il doit être appelé, les paramètres à spécifier…) sont contenus dans un document standardisé, qui fait office de contrat entre le client et le serveur. - Les services sont autonomes : Un service se doit d’être totalement autonome. On doit pouvoir le remplacer ou le déplacer sans que cela affecte d’autres services. Un service implémente ses propres composants et ses propres méthodes d’accès aux données, il ne doit dépendre d’aucun élément externe. Les clients et les services ne partagent que des contrats : On a vu dans le premier principe du SOA, que les services exposent des contrats pour exposer aux clients leurs fonctionnalités et comment les utiliser. Cette interface est la seule chose que le serveur partage avec le client. Comme en programmation orientée objet, le client n’a pas a connaitre comment procède le service pour arriver à ses fins. En aucun cas, le service et le client ne doivent partager du code. - La compatibilité est basée sur les règles : Nous verrons plus tard dans les chapitres suivants qu’il est possible et même recommandé de sécuriser l’accès à un service, en utilisant un nom d’utilisateur et un mot de passe par exemple. Voici un schéma permettant de présenter les composants fondamentaux d’une architecture SOA :  Les applications consomment des services distants, pouvant réaliser des tâches métiers et/ou techniques, en s’échangeant des messages ( ).  Chaque service possède un contrat qui fournit des spécifications techniques sur les opérations qu’il propose (signature, données à fournir entrée, données retournée…).  et  Chaque contrat possède un schéma, qui décrit des messages échangées entre les services et les applications qui les consomment. Message à traiter Application 1 Contrat Implémentation Application 2 Message traité Service 1 Service 2

24 Partie II - Les Architectures orientées services
Qu’est ce que SOA-> Services Cycle de vie des services Identifier   Mettre en place Maintenir Le concept d’application composite  Les services au cœur SOA SOA présent un modèle d’architecture informatique basée sur l’émergence d’une couche de services. Ces services offrent une vue logique des traitements et données existant déjà ou à développer. Un service, met à disposition d’acteurs(humains ou logiciels) intervenants dans des processus métiers, un accès vers une ou plusieurs fonctions métiers. Un service vise à être simple d’emploie et réutilisable . Un service SOA dialogue avec ses consommateurs sous une forme standardisée, tant sur le plan technique que sur le plan métier 2.2.4 Concept de service Les services au cœur SOA SOA présent un modèle d’architecture informatique basée sur l’émergence d’une couche de services. Ces services offrent une vue logique des traitements et données existant déjà ou à développer. Et chaque service encapsule ces traitements et données et masque ainsi l’hétérogénéité du système d’information Cycle de vie des services Identifier les services à mettre en place ; Pour cela il doit répondre à quelque critère suivant : Il permet la réutilisation Il permet l’interopérabilité, offerte via Internet à d’autre SI Il autorise son emploi dans une composition. Mettre en place les services ; La mise en place d’un service distingue donc d’une part la modélisation du contrat qui décrit le service rendu, d’autre part l’implémentation du service, qui doit respecter le contrat défini, et enfin les modalités de déploiement . Maintenir les services ; Rentre dans un cadre de gestion de version et d’évolution de composants logiciels Le concept d’application composite ; Dans une approche SOA, un service peut être consommé soit par : Un utilisateur, via une application composite interactive, Un système traditionnel comme un batch , Un processus métier, Ou au autre service SOA L’approche SOA favorise la construction de nouveaux services par composition de services existants et cette composition devient son tour un service. De plus la composition de service ne s’arrête pas non plus aux frontières du SI. L’approche SOA favorise la construction de nouveaux services par composition de services existants et cette composition devient son tour un service. De plus la composition de service ne s’arrête pas non plus aux frontières du SI.

25 Sommaire Partie I -Entropie des systèmes d’Information
Partie II - Les Architectures orientées services Partie III - SOA-Concepts et Composants Conclusion, Bilan & Perspectif Une SOA place donc au cœur de l’architecture d’un système d’information les services, qui sont les briques de base de construction, puis les processus métier qui les orchestrer. Les applications mises à la dispositions des acteurs sont alors construites par composition de processus et de service. Processus et services sont de véritables composants logiciels, qui vont permettre de faire le liant entre la vision métier et la vision technique. C’est la différence fondamentale par rapport à de l’EAI classique : un EAI n’est qu’un moyen mis en œuvre pour interconnecter des applications hétérogènes, et pour lequel les processus métiers sont noyés. Une SOA est un véritable précepte d’architecture, dans laquelle des ressources applicatives hétérogènes se trouvent présenter par les services, et pour les processus sont explicites et donc facilement maîtrisables et utilisables.

26 Partie III - SOA-Concepts et Composants
Silos Hermétique Monolithique Fragile Partagé Collaboratif Interopérable Une SOA est organisée selon les niveaux suivants : Interaction avec les acteurs : ensembles des composants permettant aux acteurs d’interagir avec le système d’information. Les acteurs sont des utilisateurs, pour lesquels on mettra typiquement en place des solutions de type portail permettant de traiter la diffusion multi-canal de l’information, ou des systèmes externes dans le cadre d’échange B2B. Processus : ensemble des composants logiciels permettant de réaliser les processus métier de l’entreprise par une orchestration de tâches automatiques ou utilisateurs. Services : ensemble des composants permettant de réaliser les services de l’entreprise et peut combiner plusieurs services de granularité plus fine. Ressources applicatives : peuvent être des progiciels propres à l’entreprise, les basses de données, des applications existants, etc.

27 Applications composites
Partie III - SOA-Concepts et Composants Applications composites Services métier 3.1-Services métier  Un service métier est la représentation d’une activité métier élémentaire ou complexe. Les services métiers sont un élément de base d’une architecture SOA. Au sein du système d’information, des opérations techniques sont également partageables et réutilisables. Les trois forme que la création d’un service au sein d’SI : l’exposition des services existantes, issues de progiciels ou autre applications, sous forme de services. L’utilisation de services de source externe, Le développement de nouveaux services pour combler les manques observés. Exemple : Lorsque une compagnie d’assurances pourra proposer la commercialisation et le suivi de ses contrats à ses courtiers, à travers l’externalisation de ces fonctions sous forme de services, tout en sécurisant l’accès a son système d’information. 3.2-Les applications composites   La notion d’application composite fait référence aux applications construites par combinaison de services multiples. Cela se présente dans les offres que propose certaine entreprise à leurs collaborateurs et partenaires des environnements de travail de plus en plus personnalisés pour faciliter les échanges et le partage d’information. Cela va pleinement bénéficier de l’approche SOA, qu’il s’agisse de la mise à disposition rapide de nouvelle fonctions, de l’intégration.

28 Partie III - SOA-Concepts et Composants
L’infrastructure logicielle ESB : Entreprise Service Bus Les Référentiels Les outils de BPM (Business Process Management 3.3.1 ESB : Entreprise Service Bus Un ESB est à base de SOA au niveau de l’entreprise, permettant aux entreprises d’intégrer des applications et des processus comme des services basés sur les standards, commandés par événement (event-driving) fortement distribués, avec une gestion centralisée de l’infrastructure. Sans point unique de défaillance, les ESBs sont par nature fiables et linéairement évolutifs et n’ont aucun goulot d’étranglement de performance. Construit entièrement sur les standards de l’industrie incluant les Services XML et Web, l’ESB ouvre la nouvelle voie des solutions d’intégration globales et accessibles, unifiant les applications et l’infrastructure d’une entreprise et donnant un plus aux services informatiques qui cherchent à mettre en place des solutions les plus performantes par la réutilisation, la flexibilité et la rapidité de mise en oeuvre. Figure 9 : ESB / Entreprise Service Bus 3.3.2 Les Référentiels Le référentiel de service ce n’est pas qu’un simple annuaire. Il permet à la fois de stocker des informations technique et formelles relatives aux services, telles que leur adresse d’accès, détaille de leur fonction, mais également des informations(méta données) peu être contextuelles, comme leurs caractéristiques opérationnelles ou le nom et la branche d’activité de l’entreprise dont ils dépendent. Le référentiel métier permet de garantir une cohérence des données dans une bases dans un système d’information. La solution de MDM« Master Data Management » permettre de gérer d’une façon centralisée afin de proposer une source d’information unique pour les données de références. 3.3.3 Les outils de BPM (Business Process Management (Orchestration de Services) Le BPM en tant que moyen d’optimisation et de gestion des processus métiers joue un grand rôle pour la SOA. Le BPM renforce l’utilité de la SOA pour le métier, car la SOA flexibilise les processus surtout pour les tâches automatisées. L’intérêt du BPM est de mettre en avant une approche fonctionnelle à la problématique d’intégration des applications. Cette alliance BPM/SOA est également source d’une meilleure communication entre les équipes métier et IT facilitant une meilleure compréhension des attentes de chacun. 3.3.4 Le pilotage des Services Supervision de l’activité métier (BAM : Business Activity Monitoring) Le BAM couvre les tâches de suivi d’activité des processus métier. Il donne une vue quasi instantanée des processus et de proposer des tableaux de bord bâtis à partir d’indicateurs de performance clés (KPI : Key Performance Indicator). Il donne une vue métier pour compléter la mise en œuvre des politiques de qualité de service (SLA : Service Level Agreement). Suivi des Services (BSM : Business Service Management) Le BSM permet aux responsables techniques comme métier de disposer d’une correspondance entre les activités des services vues d’un point de vue métier et les ressources informatiques qui les prennent en charge. 3.3.5 EDA : Event-Driven Architecture EDA « est un style d’architecture logicielle pour lequel les différents composants logiciels communiquent de manière totalement asynchrone grâce la publication et la souscription d’événements ». Généralement, l’idée sous-jacente est qu’une SOA serait pilotée par les consommateurs de services, de façon assez mécanique, suivant une fréquence fixe et un mode requête/réponse indéfectiblement synchrone. D’autre part, certains services ou enchaînements de services ne seraient pas toujours déclenchés à l’initiative d’un consommateur, mais pourrait être déclenchés par un évènement métier ou technique de fréquence variable. C’est ainsi qu’est arrivée la notion d’EDA, susceptible de gérer l’évènementiel. On voit que cette notion répond à des lacunes du modèle SOA, ceci afin de l’enrichir, et non de s’y opposer ou de proposer un modèle alternatif. https://www-304.ibm.com/ MDM : consiste a créer un référentiel central de données d’Entreprise . Livre Orange ; Urbanisation & Intégration de système «  Valtech Technology consulting » Livre Orange ; Urbanisation & Intégration de système «  Valtech Technology consulting »

29 Partie III - SOA-Concepts et Composants
SOA et Web Service ->Protocole et normes Comme on l’a vu SOA est une approche d’architecture et ne fait pas d’hypothèse sur la technologie de mise ne œuvre. En particulier , l’amalgame souvent fait entre SOA et les Web SERVICES est une erreur de ne pas bien comprendre SOA. La conception des spécifications Web Services a été menée dans l’objectif de répondre au mieux aux enjeux des architectures SOA .Ainsi, les Web Services sont une technologie très pertinente pour mener une démarcher SOA. Pour bien comprendre comment développer un Web Service, nous allons regarder un scénario générique. Une entreprise fournisseure de widgets veut rendre disponible certains services de gestion d'inventaire à l'externe. Elle le fait déjà par une interface Web qui nécessite d'être opérée par des humains ;-) chez ses clients, mais voudrait le faire de façon automatisée avec un Web Service. Typiquement, le Web Service sert à rendre disponible à plus grande des fonctionnalités déjà implémentée par des intergiciels (middleware). Dans une architecture trois tiers à la J2EE, l'interface de notre Web Service sera le point limite (endpoint) équivalent à la couche présentation (ex: jsp, asp, html) dans un site Web. 3.4 PROTOCOLE ET NORMES La SOA est un ensemble de services distribués au travers du réseau. Comme les processus métiers, les présentations, les logiques applicatives et les données sont séparés dans des couches distincts et faiblement couplées, il faut des outils complets de gestion de chacun de ces composants. Les architectures SOA reposent principalement sur l’utilisation d’interface d’invocation (SOAP) et de vocabulaire de description de données (WSDL et XML) qui doivent être communs à l’ensemble des acteurs de services (Utilisateurs/fournisseurs). Pour mettre en pratique cette théorie, une implémentation s'est vite imposée : les Web Services. Même si ce n'est pas l'unique choix d'implémentation, elle est souvent associée à SOA.

30 Partie III - Les Architectures orientées services
SOA et Web Service ->Infrastructure La normalisation actuelle autour des Web Services est cependant un vaste chantier qui va bien au-delà de la simple invocation d'une méthode d'un objet distant. Différents travaux ont ainsi démarré pour tenter de définir une véritable infrastructure distribuée.  Normalisation des services transverses sur trois axes horizontaux: - Couche de transport : Définition de la structure des messages utilisés par les applications pour se découvrir et dialoguer entre elles, - Couche de sémantique : Normalisation des données participant aux échanges selon des critères métier, - Couche de gestion des processus : Standardisation de la gestion des processus métier qui s'étendent sur plusieurs applications disponibles sur l'Internet. Normalisation des services transverses sur trois axes verticaux: - Service d'annuaire : Standardisation des moyens d'accès à un service à partir d'une requête portant sur le contenu d'un service ou sur un fournisseur, - Service de sécurité : Normalisation des moyens permettant de couvrir les problématiques d'authentification et de gestion des droits d'accès, - Service de transaction : Normalisation des moyens permettant de garantir l'intégrité des transactions longues impliquant plusieurs Web Services.

31 Partie III - Les Architectures orientées services
SOA et Web Service ->fonctionnement REST, un style d'architecture, pas un standard REST est un style d'architecture, pas un standard. Il n'existe donc pas de spécifications de REST. Il faut comprendre le style REST et ensuite concevoir des applications ou des services Web selon ce style. Bien que REST ne soit pas un standard, il utilise des standards. REST concerne l'architecture globale d'un système. Il ne définit pas la manière de réaliser dans les détails. En particulier, des services REST peuvent être réalisés en .NET, JAVA, CGI ou COBOL. Le concept des Web Service s'articule actuellement autour des trois acronymes suivants : SOAP (Simple Object Access Protocol) est un protocole d'échange inter-application indépendant de toute plate-forme, basé sur le langage XML. Un appel de service SOAP est un flux ASCII encadré dans des balises XML et transporté dans le protocole HTTP. WSDL (Web Services Description Language) donne la description au format XML des Web Services en précisant les méthodes pouvant être invoquées, leur signature et le point d'accès (URL, port, etc..). C'est, en quelque sorte, l'équivalent du langage IDL, (Interactive Data Language), est un langage de programmation propriétaire apparu a la fin des années 1970, et qui est rapidement monté en puissance dans les domaines de la télédétection et de l'astronomie. pour la programmation distribuée CORBA. UDDI (Universal Description, Discovery and Integration) normalise une solution d'annuaire distribué de Web Services, permettant à la fois la publication et l'exploration. UDDI se comporte lui-même comme un Web service dont les méthodes sont appelées via le protocole SOAP. Ils ont été définis, pour la plus grande part, par le W3C (World Wide Web Consortium), qui a été fondé pour promouvoir la compatibilité des technologies du Web et émet des recommandations à valeur de standards industriels. Un Web Service peut, dans un exemple simple, laisser un client communiquer avec lui en utilisant des messages XML qui répondent au standard SOAP (Simple Object ou Service Oriented Architecture Protocol). Il représente donc le format d'échange de données dont les protocoles primaires sont HTTP et HTTPS. Prenons un Web service donnant, pour un identifiant client particulier et un identifiant produit, le prix du produit désiré. Un message SOAP contenant les bonnes informations et un champ prix vide pourra être envoyé au service. En retour, sera renvoyé le message avec le prix du produit renseigné. Un fichier WSDL (Web Services Description Language) décrit un web service : c'est la fameuse interface évoquée précédemment dans la description d'un service. Pour faire un rapprochement, on peut voir ce fichier comme une interface en langage JAVA, on connaît les méthodes mais par leur implémentation. Un registre UDDI Universal Decription Discovery and Integration) est un annuaire basé sur XML qui permet de publier des services et facilite leur découverte par d'autres services en définissant comment ils interagissent. Un scénario d'utilisation possible est donc la publication d'un fournisseur de service (donc de son WSDL) auprès d'un registre en créant tout d'abord une entreprise et une catégorie de service. Un client demande ensuite à un registre UDDI la localisation d'un service qui correspond au service venant d'être ajouté à l'annuaire. Le WSDL du service demandé est alors reçu par le client qui peut communiquer avec le fournisseur de services en SOAP. SOA est une théorie et on ne doit pas oublier que l'on peut faire une architecture SOA sans Web Services et inversement car, réaliser des web services, ne veut pas dire mettre en place une architecture SOA. « Une façon de concevoir et d'implémenter les applications de l'entreprise qui possèdent un couplage faible, sont à grandes mailles et sont des services réutilisables, accessibles par des interfaces bien définies et indépendantes de toute plateforme. » Cette définition n'inclut donc pas de protocole de communication obligatoire et il n'y a aucune restriction évoquée : pas d'obligation d'envoyer des messages SOAP en HTTP. SOA est beaucoup plus que seulement des Web Services et sa vraie force intervient réellement quand il n'y a plus ces restrictions et autorise les services à être invoqués par une multitude de protocoles. L'ESB permet justement de mettre en oeuvre un environnement ne se limitant pas aux limites évoquées. Le fonctionnement des services web repose sur un modèle en couches, dont les trois couches fondamentales sont les suivantes : Échange , visant à décrire la structure des messages échangés par les applications. Découverte, pour permettre de rechercher et de localiser un service web particulier Description, dont l'objectif est la description des interfaces des services web

32 Partie III - Les Architectures orientées services
SOA et Web Service ->fonctionnement Les partenaires – Le fournisseur de service crée le service Web, puis publie son interface ainsi que les informations d'accès au service, dans un annuaire de services Web. – L'annuaire de service rend disponible l'interface du service ainsi que ses informations d'accès, pour n'importe quel demandeur potentiel de service. – Le demandeur de service accède à l'annuaire de service pour effectuer une recherche afin de trouver les services désirés. Ensuite, il se lie au fournisseur pour invoquer le service. • Les standars – Langage XML : Décrit les informations – Protocole SOAP : Exécute les services à distance – Langage WSDL : Décrit l’ interface des services – Norme UDDI : Trouve les services dont on a besoin

33 Bilan, Perspectif et Conclusion,
Bilan et perspectif SOA n’est pas une technologie SOA ne signifie pas Web Services Web service ne signifie pas SOA SOA ne résout pas les problèmes existent dans les implémentations SOA nécessite un langage métier commun (Contrat, grammaire xml ) SOA est une affaire de compromis SOA n’est pas une technologie SOA ne signifie pas Web Services Web service ne signifie pas SOA cela veut dire même si on expose tous des web services, tous les concepts SOA seront respectés SOA ne résout pas les problèmes existent dans les implémentations SOA nécessite un langage métier commun (Contrat, grammaire xml ) SOA est une affaire de compromis

34 Bilan, Perspectif et Conclusion,
Marché SOA https://www.pac-online.com Comment expliquer cela ? Le marché SOA est résistant car il est l’architecture du futur. Il permet d’allier flexibilité et contrôle tout en optimisant les coûts et en créant des différentiels compétitifs par rapport à des approches progicialisées. Bien sûr, les SOA ne tiennent pas toutes les promesses que les directions marketings des fournisseurs de technologies leur prêtent, mais les responsables informatiques sont de plus en plus mûrs concernant ce qu’ils peuvent en attendre. Selon notre toute dernière enquête parue en mars 2009, les entreprises qui lanceront des projets SOA seront plus nombreuses que celles qui ne le feront pas. Le marché SOA en France est marqué par la domination de quatre éditeurs (Oracle, IBM, Software AG et Tibco) et cinq intégrateurs (Logica, Capgemini, IBM, Atos Origin, Solucom). Le caractère oligopolistique de ce marché pourrait entraîner à terme un problème de diffusion de la technologie, dans la mesure où peu d’acteurs de taille moyenne assurent le relais vers les PME. Malgré cet obstacle, les architectures SOA seront majoritaires d’ici 2012, les projets actuels d’architecture suivant cette voie dans leur grande majorité.

35 Oligopolistique de ce marché
Bilan, Perspectif et Conclusion, Marché SOA Insérez une photo d'une plante ou d'un animalque l'on peut trouver dans le pays. (Oracle, IBM, Software AG et Tibco) Oligopolistique de ce marché (Logica, Capgemini, IBM, Atos Origin, Solucom

36 Distributed Computing:
Bilan, Perspectif et Conclusion, Marché STANDARD Distributed Computing: Grid (Globus -> OGSA) Applications: Web Services (SOAP, WSDL, UDDI) Operating System: Linux Information: World-wide Web (html, http, j2ee, xml) Cette partie rappelle brièvement l’évolution des technologies informatiques et ses conséquence en terme d’entropie pour les système d’information. Communication: (pop3,SMTP,Mime) Réseau Internet (TCP/IP)

37 Bilan, Perspectif et Conclusion,
Bilan et perspectif Avantages Inconvénients - Obligation d'avoir une modélisation poussée Possibilité de découpler les accès aux traitements Localisation et interfaçage transparents (ouverture accrue) Possibilité de mise en place facilitée à partir d'une application objet existante Réduction des coûts en phase de maintenance et d'évolution Facilité d'amélioration des performances pour des applications importantes (répartition des traitements facilitée - Coûts de conception et de développement initiaux plus conséquents Nécessité d'appréhender de nouvelles technologies Existant non SOA dans les entreprises Performances réduites pour des traitements simples (couche supplémentaire) Il est important de noter que plusieurs acteurs du marché du logiciel s’inscrivent dans cette dynamique. On y trouve tout d’abord les acteurs dont l’origine est le middleware de type serveur d’applications ou plateforme EAI. Viennent ensuite les acteurs dont l’origine est le système d’exploitation, ou la base de données et enfin les acteurs dont l’offre d’origine est une offre répondant aux problématiques métiers connus sous le nom de PGI (Progiciels de Gestion Intégrés). Certains ont une offre logiciels + services. On parle fréquemment d’approche « top – down » ou « bottom - up » pour illustrer la transformation et la fourniture de nouvelles offres de ces acteurs. Quelle que soit l’approche, une convergence existe puisque la mise en oeuvre d’une architecture SOA nécessite des composantes incontournables comme les solutions d’intégration et d’interopérabilité ESB (Enterprise Service Bus), la gestion des données maîtres MDM (Master Data Management), la plateforme de composition et d’exposition de services et les outils nécessaires à la gouvernance et à la sécurité des solutions. Il est donc important de pouvoir estimer si cette mouvance se traduira par une évolution de l'existant, ou si elle engendrera plutôt une refonte majeure des architectures déjà en place. Le rôle des standards des Services Web est de concevoir un environnement SOA permettant l’optimisation économique des ressources sans fausser la compétition.

38 Bilan, Perspectif et Conclusion,
Agilité Réduction(Time to Market ) Partage des ressources applicatives Réutilisation Facilité d’intégration Beaucoup de pièces Flux Important Coût de recherche d’erreur(Correctif) Mettre en place SLA(Financier) Que faut-il faire ? Comment le faire ? Qui doit le faire ? Comment est-ce piloté et mesuré ? Important de mettre en place une solution de gouvernance SOA. L’architecture orienté service met en œuvre une approche dont le concept primaire est le service. Le processus d’urbanisation manipulant le concept de service sera plus fluide SI moins rigide => alignement par rapport au besoins métier Gouvernance SOA La SOA apporte de nombreux avantages (agilité, réduction du "time to market", partage des ressources applicatives, réutilisation, facilité d'intégration ...) mais la SOA créée aussi de nouvelles problématiques que les applications traditionnelles ne connaissaient pas : Il y a beaucoup plus de "pièces en mouvement" (les services, à couplage lâche par définition) qui ne se connaissent pas. Le poids des "flux" devient au moins aussi important que le poids des "ressources". Ainsi, il faut pouvoir monitorer les flux autant que les ressources. Quand quelque chose ne va pas, la cause peut venir de sources très distinctes et diverses : Chercher l'erreur coûte cher. Il est donc important de mettre en place une solution de Gouvernance SOA et cela dès les premières étapes des projets. Dans des contextes B2B, on s'aperçoit que de plus en plus de services sont exposés à des partenaires, à des fournisseurs ... et les entreprises se doivent de garantir la qualité des services qu'elles exposent. Des SLA (Service Level Agreements) seront mis en place. La qualité des services applicatifs pourra avoir un impact financier important. En B2C, le mode de fonctionnement "self-care" est de plus en plus fréquent et la qualité des services applicatifs exposés par l'entreprise et accédés par les clients est primordiale. Plutôt que d'être informée par ses clients mécontents d'un problème d'indisponibilité ou de performance de service applicatif, l'entreprise est capable de détecter un problème potentiel et peut mettre en place le correctif qui s'impose.   La multiplicité des pièces en mouvements rend la visibilité de bout en bout beaucoup plus difficile, et pourtant c’est elle qui compte puisqu’elle reflète précisément l’expérience de l’utilisateur. La gouvernance doit donc permettre de rendre compte de la qualité de service sur un parcours de services, et non seulement sur des appels de services individuels. Bien évidemment, la détection des goulets et des erreurs doit également commencer par le « tout »  et descendre par la suite sur les composants (services) individuels. SLA ( Service Level Agreements )

39 Bibliographie Site Internationaux :
https://www-304.ibm.com/ Recherche bibliographique : SOA, Le guide de l’architecte du SI ; de Xavier Fournier-Morel, Pascal Hrojean , Guillaume Plouin, Cyril Rognon Edition SQLI ISBN Livre blanc : SOA : Architecture Logique Principes, structures et bonnes pratiques, Copyright © SOFTEAM 2007 Méthodologie SOA en six domaines Révéler les avantages métiers d’une Architecture Orientée Services Copyright © 2005 BEA Systems SOA et urbanisme Le rôle des Architectures Orientées Services dans l’alignement métier des Systèmes d’Information Copyright © Unilog Management Les Architectures Orientées Services Copyright ©

40 Question & Réponse Merci © Suzanne Porter


Télécharger ppt "SOA (Service Oriented Architecture) Architectures Orientées Services"

Présentations similaires


Annonces Google