Architecture n-tiers

Architecture n-tiers 

Chapitre 2: SOA Dr.Ghada Besbes 

1 

Introduction 

• La création d’applications dans l’entreprise est très souvent pilotée par des besoins à très court terme 
• Développement d’une application sous tel délai avec telles fonctionnalités 
• Modélisation et développement dirigé par les choix/contraintes techniques 
• Pas de discussion entre maitrise d’ouvrage (le client) et maitrise d’oeuvre (l’équipe de développement)‏ 
• Décalage entre besoins métier et leur réalisation (constituants informatiques)‏ 
• Pas de place pour la prise en compte de l’évolution des besoins fonctionnels au niveau de l’application 2 

Introduction 

• Le découpage présentation/traitement/base de données de l’architecture 3-tiers sert à découpler au maximum une couche de l’autre mais favorise le cloisonnement en silos applicatifs indépendants (blocs monolithiques)‏ 

3 

Introduction 

• Les tiers communiquent via un protocole de transport spécifique qui nécessite une configuration réseau 
• Problématique de l’intégration en entreprise 
• Entreprises découpées en départements fonctionnels y compris leurs systèmes d’information‏ 
• Processus métiers de + en + interdépartementaux 
• Les processus qui franchissent les frontières des départements doivent pouvoir prendre en compte les activités et processus des autres départements. 

4 

Introduction 

Coûts considérables dans la gestion des flux entre départements 

et dans l’intégration de leurs SI 5 

Introduction 

Plat de spaghettis 

• Développements coûteux 
• Interconnexions redondantes (point à point)‏ 
• Grande complexité 
• Maintenance difficile 

6 

SOA 

7 

1 

SOA 

• SOA dénote une architecture orientée services (Service Oriented Architecture) 
• Lancée par Gartner Group, elle définit un modèle d’interaction applicative mettant en oeuvre des connexions en couplage faible entre divers composants logiciels. 
• « une vision d’un système destinée à traiter toute application comme un fournisseur de service ». 
• Architecture logicielle s’appuyant sur un ensemble de services simples. 
• Objectif: Décomposition d’une fonctionnalité en un ensemble de fonctions basiques, appelées services. 

8 

SOA 

Qu’est ce que SOA? 

• « 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 à un niveau supérieur de la traditionnelle approche composants » Gartner – Septembre 2005 9 

SOA 

• La mise en place d’une architecture SOA répond à un besoin de: 
• Réutilisation des traitements, 
• Interopérabilité 
• Fiabilité, 
• Hétérogénéité. 
• Une architecture orientée services consiste essentiellement en une collection de services qui interagissent et communiquent entre eux. 

10 

SOA 

• Le paradigme SOA : Chercher, Publier et Consommer 

11 

SOA 

• L’approche à services est un paradigme informatique qui propose de construire des applications à partir de services. Ces services sont fournis par des organisations tierces et peuvent évoluer dynamiquement . 
• Cette approche repose sur trois acteurs (Fournisseur de service, Annuaire de service et Consommateur de service) et trois interactions (Chercher, Publier et Consommer). 

12 

SOA 

Acteurs 

• Fournisseur de services: 
• Le fournisseur de service a pour rôle de fournir des services qui implémentent une description de service. Les descriptions de service sont publiées dans un registre de services afin de supporter la découverte de services. 
• Annuaire/registre de services: 
• C’est l’intermédiaire entre les fournisseurs et les consommateurs de services. Il stocke des descriptions de services qui, entre-autres, référencent leurs fournisseurs. Le registre fournit des mécanismes permettant de l’interroger pour obtenir des références vers les fournisseurs. 
• Consommateur de services: 
• L’acteur consommateur de service est le client qui requiert un service. Pour pouvoir interagir avec ce dernier, le consommateur doit être lié à un fournisseur après sa découverte dans le registre. 

13 

SOA 

Interactions 

• La publication : Un fournisseur de service s’enregistre auprès du registre de service pour publier sa description de service. Un fournisseur peut avoir plusieurs types de services. 
• Recherche/découverte : Le consommateur de service interroge le registre afin de trouver les services qu’il requiert. 
• Consommation/invocation et liaison : Une fois que le service est découvert, son invocation consiste à établir une liaison entre le consommateur et le fournisseur pour permettre son utilisation. 

14 

SOA 

15 

Un service Web 

• Le service est un composant clef de l’Architecture Orientée Services. 
• Consiste en une fonction ou fonctionnalité bien définie. 
• Expose une interface qui définit le traitement offert sous la forme d’un message d’entrée et d’un autre de réponse. 
• L’avantage essentiel des services web concerne le fait que le client consommateur n’a pas besoin de connaître l’identité du fournisseur du service 
• Le client doit simplement exprimer son besoin 
• Face à un besoin, plusieurs fournisseurs de services peuvent exister 
• Chacun ayant des caractéristiques de coût, de performance, de fiabilité, etc. 
• Le client choisit le fournisseur (i.e. le service) correspondant le mieux à ses besoins. 

16 

Un service Web 

Les services 

• Ils sont accessibles via le web par des protocoles bien connus 
• Ils interagissent via XML 
• Ils sont localisables à partir de registres 
• Ils sont entièrement transversaux aux plates-formes et très faiblement couplés 
• Un service résout un problème donné, 
• Les services peuvent être combinés pour résoudre des problèmes de plus en plus complexes, 

Une architecture orientée services se focalise sur une décomposition plus abstraite dans la résolution des problèmes. On parle de résolution dirigée par les services. 17 

Un service Web 

• Partage les caractéristiques suivantes d’un objet 
• Modulaire (ensemble de fonctionnalités qui font sens)‏ 
• Partage les caractéristiques suivantes d’un composant 
• Boite noire (séparation interface/implémentation)‏ 
• Indépendant de la localisation 
• Neutralité vis-à-vis des protocoles de transport 
• Les services Web sont réutilisables indépendamment de: 
• la plate-forme (UNIX, Windows,…) 
• leur implémentation (Java, C++, Visual Basic,…) 
• l’architecture sous-jacente (.NET, J2EE,…) 18 

Propriétés des services 

1. Contrat Standardisé 

• Contrat entre le fournisseur de service et le consommateur de service 
• Trois types de contrat sont à distinguer 1. Lié à la syntaxe du service (opération, messages d’entrée, 

messages de sortie, …) 2. Lié à la sémantique du service (définition de règles et de 

contraintes d’usage, …) 3. Lié à la qualité de service (temps de réponse attendu, 

procédures en cas de panne, temps de reprise après interruption, …) 

Conditions Générales de Vente in Règlement Intérieur 

Vos droits/Vos devoirs 19 out 

Propriétés des services 

2. Couplage faible 

• Un service ne peut pas appeler un autre service. Il délègue cette fonction à un traitement spécialisé dans l’enchaînement (fonction d’orchestration). 
• L’utilisation d’une orchestration évite que les services aient besoin de connaître les autres services 

20 Le couplage fort rend difficile la réutilisation et accroît la complexité des systèmes 

Propriétés des services 

 L’orchestration favorise l’indépendance des services et assure que des services n’appellent pas directement d’autres services 

21 

Propriétés des services 

22 

Propriétés des services 

Exemple de couplage fort : Gestion de prêts 

calculateRisk 

23 Entités LoanAgent 

LoanApproval SMSGateway 

sendConfirmation 

 LoanAgent est lié à LoanApproval et Loan  LoanApproval est lié à Account  Loan est lié à SMSGateway 

Account Loan createLoan checkCredit 

Propriétés des services 

Gestion de prêts en couplage faible 

Services CheckAccount Balance 

Calculate LoanRisk CreateLoan Qu’est ce que LoanProcess ? 

24  Un processus métier ! 

Il permet d’orchestrer les services => couplage faible 

Notify LoanProcess 

ViaSMS 

Propriétés des services 

3. Activation à distance et interopérabilité 

• Un service doit être activable à distance indépendamment de sa technologie 
• L’activation se fait par l’envoi (et la réception) d’un message XML 
• Le service doit exposer une interface d’utilisation qui est la même indépendamment de sa localisation sur le réseau 
• L’appel au service fonctionne quelque soit le langage et les système d’exploitation du consommateur (utilisateur du service) 

25 

Propriétés des services 

• L’objet des Services Web est la communication d’application à application (A2A) sur Internet. 
• Le but est de faciliter l’intégration des applications d’entreprise et le e-commerce spécialement en « Business To Business » (B2B). 
• Pour ce faire, l’architecture des Services Web doit supporter les transactions asynchrones (« mode message ») aussi bien que les transactions synchrones (« Remote Procedure Call » ou RPC), 
• Le codage des données est effectué en XML, ce qui conduit à des documents que l’homme et la machine peuvent interpréter 
• Les systèmes doivent être interopérables. 

26 

Propriétés des services 

4. Abstraction 

• Fonctionnement du service dit en « boîte noire » 
• Seul le contrat exposé au consommateur du service est connue 
• Le fonctionnement interne du service ne doit pas être visible(logique métier et implémentation) 
• Il est par conséquent important d’assurer la prédictibilité d’un service: Pas de variation dans le comportement et dans la réponse d’un service lors de la réception d’une requête 

27 

Propriétés des services 

5. Découvrabilité 

• Un service doit être accessible depuis un entrepôt ou un annuaire pour faciliter sa découverte 
• Le fournisseur de services a la charge de déposer et de mettre à jour ses services depuis l’annuaire 
• Le service est enrichi par un ensemble de méta-données pour faciliter la recherche du consommateur de services 

28 

Propriétés des services 

6. Autonomie 

• Un service doit disposer de l’ensembles des informations nécessaires à son exécution 
• Ne doit dépendre d’aucun service externe (couplage faible) 
• Garantir l’autonomie d’un service permet de s’assurer de sa prédictibilité 

29 

Synthèse 

…Vers… 

• Orienté fonctionnalités 
• Orienté processus 
• Conçu pour durer 
• Conçu pour changer 
• Cycle de 
• Développement et développement long 

déploiement interactif 

• Silos applicatifs 
• Couplage fort 
• Orienté Objet 
• Orchestration de Services 
• Couplage faible 
• Orienté message 

30 

Depuis… 

Avantages 

Architecture adaptative Réutilisation du code (Construire les services une seule fois et les utiliser fréquemment) Améliorer l’agilité et la flexibilité du métier Faciliter la maintenabilité Faciliter la gestion des processus métier Offrir la capacité à casser les barrières organisationnelles (silos) Réduire en temps le cycle de développement des produits Réduire la complexité de la solution Garantir une intégration standardisée et le support de clients hétérogènes L’évolutivité, permettant aux applications de greffer de nouveaux modules afin de répondre aux nouveaux besoins fonctionnels 

31 

Limitations 

Manque de maturité des standards Lenteur d’exécution Difficile à effectivement implémenter Les contraintes imposées dans la contractualisation 

32 

STANDARDS DES SOA 

33 

2 

Standards des SOA 

• Les standards sont un élément clé d’une SOA, ils assurent l’interopérabilité 

SOAP 

WSDL 

UDDI W3C 

W3C 

Microsoft, IBM, HP Simple Object 

Web Services 

Universal Description Access Protocol 

Description Language 

Discovery and Integration 

Transport Décrit le contrat 

Annuaire 

34 

Standards des SOA 

• UDDI : Universal Desciption, Discovery and Integration peut être vu comme les pages blanches (ou jaunes) des services web. 
• C’est un annuaire permettant à des fournisseurs de présenter leurs services à des ‘clients‘. 
• WSDL : Web Service Description Langage est un langage reposant sur XML dont on se sert pour décrire les services web. 
• Il est indispensable à UDDI pour permettre aux clients de trouver les méthodes leur permettant d’invoquer les services web. 
• SOAP : Simple Object Access Protocol est un protocole basé sur XML et qui définit les mécanismes d’échanges d’information entre les clients et les fournisseurs de service web. 
• Les messages SOAP sont susceptibles d’être transportés en HTTP, FTP… 35 

Standards des SOA 

De nombreuses normes sont utilisés dans cette architecture : 

• « SOAP » pour l’échange de messages 
• « XML » langage de base pour décrire tous les documents sur lesquels les messages sont construits 
• « HTTP » pour transporter les messages, « WSDL » pour décrire les services 
• « UDDI » pour les publier. 
• L’approche « Services Web » constitue un changement fondamental dans la manière de concevoir et réaliser les applications informatiques et de programmer les ordinateurs. 
• Les standards sont un élément clé d’une SOA, ils assurent l’interopérabilité 

36 

Fonctionnement d’un web service 

37 

Standards des SOA: SOAP 

• SOAP (Simple Object Access Protocol) 
• Un protocole standard de communication. 
• C’est l’épine dorsale du système d’interopérabilité. SOAP est un protocole décrit en XML. 
• Il se présente comme une enveloppe pouvant être signée et pouvant contenir des données ou des pièces jointes. 

38 

Standards des SOA:WSDL 

• WSDL (Web Services Description Language) 
• Un langage de description standard. 
• C’est l’interface présentée aux utilisateurs. 
• Décrit les interface des services 
• Il indique comment utiliser le service Web et comment interagir avec lui. 
• WSDL est basé sur XML et permet de décrire de façon précise les détails concernant le service Web tels que les protocoles, les ports utilisés, les opérations pouvant être effectuées, les formats des messages d’entrée et de sortie et les exceptions pouvant être envoyées. 

39 

Standards des SOA:UDDI 

• UDDI (Universal Description, Discovery and Integration) 
• Un standard pour la publication et la découverte des informations sur les services Web 
• Il fournit l’infrastructure de base pour la publication et la découverte des services Web. 
• UDDI permet aux fournisseurs de présenter leurs services Web aux clients. 
• Afin d’être découvert, un service doit être publié 

40 

Fonctionnement d’un web service 

41 

Fonctionnement d’un web service 

Le scenario complet 1. Définition, description du service 

• On doit décrire d’un point de vue informatique ce que fait le service, la solution qu’il propose, … 
• La définition est faite en WSDL au sein du fournisseur de services (i.e. le serveur d’applications) 2. Publication du service 
• Une fois le service définit et décrit en termes de mise en œuvre, il peut être déclaré dans un annuaire, on parle alors de publication du service afin de le rendre accessible aux clients. 
• La publication sera effectuée au sein d’un annuaire dédié UDDI. 3. Recherche du service 
• Le client se connecte sur un annuaire (UDDI) pour effectuer une recherche de service. 42 

Fonctionnement d’un web service 

6. Enregistrement au service web 

• Une fois le service trouvé par le client, ce dernier doit s’enregistrer auprès du fournisseur associé au service. Cet enregistrement indique au fournisseur l’intention du client d’utiliser le service suivant les conditions décrites dans la publication. 7. Mise en œuvre du service 
• Le client peut invoquer le service suivant les conditions inscrites au sein de l’annuaire lors de la publication du service web (étape 2) 

43 

ORCHESTRATION 

44 

2 

Introduction 

• Les Services Web sont la nouvelle vague des applications web. Ce sont des applications modulaires, auto-contenues et auto- descriptives qui peuvent être publiées, localisées et invoquées depuis le web. Les services web effectuent des actions allant de simples requêtes à des processus métiers complexes. Une fois qu’un service web est déployé, d’autres applications (y compris des services web) peuvent le découvrir et l’invoquer. 
• Une plate-forme d’orchestration s’avère nécessaire pour chaîner l’appel à plusieurs services. La solution serait d’orchestrer les services web simplement en les combinant suivant certaines spécifications afin d’assurer leurs bonnes exécutions. 

45 

Problématique 

• Des processus business de plus en plus complexes 
• Plusieurs applications 
• Exécution en parallèle 
• Partenaires multiples 
• Faisant intervenir des systèmes différents 
• J2EE/.NET 
• Besoin d’évolution 
• Changement de partenaires 
• Changement de processus 

46 

Définition 

• Le mot « orchestration » est pris du contexte de la symphonie musicale où les différents instruments musicaux devraient travailler ensemble en harmonie. 
• L’orchestration revient à faire correspondre à chaque processus métier un ensemble de scénarios d’enchaînement de services Web, en fonction de la logique applicative à mettre en œuvre tout en assurant: 
• La succession des tâches 
• Le contrôle de la bonne exécution 
• Les reprises en cas d’incident… 

47 

Définition 

• Un processus métier décrit des interactions entre des agents (personnes, services, organisations) et des systèmes d’information (logiciels, sous-systèmes). Les différentes entités qui interagissent dans un processus donné sont les participants de ce processus. Le processus métier est déterminé par un objectif précis : produire une facture d’achat de fournitures, éditer un catalogue électronique, etc. 
• Un processus métier, dans le domaine des services web : 
• Repose sur la coopération entre applications participantes 
• Peut être de courte ou de longue durée 
• Peut échouer partiellement et déclencher des situations d’exception 

48 

Fonctionnalités 

• Orchestrer: Invoquer, contrôler et coordonner un ensemble d’activités afin d’en restituer une liste ordonnée d’appels de services web. 
• Correspondre à chaque processus métier un ensemble de scénarios d’enchaînement de services Web 
• Prendre en charge l’assemblage des services, la conservation des enchaînement des services web découverts, leur synchronisation 
• Processus intra entreprise : 
• Processus inter services 
• Processus inter systèmes 
• Etc…. 
• Processus inter entreprise : 
• Relations fournisseurs 
• Grande distribution 
• Administrations 
• Etc…. 

49 

Exemple 

50 

Avantages 

• Interopérabilité 
• Séparer la logique processus de la logique application 
• Applications Business changent très peu 
• Possibilité de changer le processus sans impact sur les applications 
• Agilité de l’entreprise 
• Présenter le processus comme un service 
• Invisible pour l’utilisateur 
• Gestion de la sécurité 

51 

Conclusion 

• Les outils d’orchestration agissent comme des tours de contrôle qui 

appellent successivement différents services Web selon un scénario 

donné. 

• Les outils de développement de scénario et d’orchestration sont 

donc indissociables pour le moment. 

• La mise en oeuvre, l’exécution et la gestion de la logique d’orchestration se révèlent complexes et impliquent un ensemble de besoin en terme d’infrastructure 

52 

télécharger gratuitement Architecture n-tiers