Présentation

Article

1 - QUELQUES DÉFINITIONS POUR DRESSER LE DÉCOR

  • 1.1 - Architectures orientées objets
  • 1.2 - Architectures orientées ressources
  • 1.3 - Architectures orientées services
  • 1.4 - Définition du style d’Architecture Orientée Services (SOA)

2 - COMMENT CHOISIR UN STYLE D’ARCHITECTURE ?

3 - REST

4 - SOAP

5 - REST OU SOAP POUR LES WEB SERVICES ?

6 - LE TRAVAIL DE L’ARCHITECTE OU COMMENT APPLIQUER LE STYLE SOA

7 - CONCLUSION

8 - ANNEXES

  • 8.1 - Exemples d’utilisation de REST et de SOAP
  • 8.2 - Définition de Services Web, XML, SOA, EAI
  • 8.3 - Ressource et Objet

| Réf : H6002 v1

Conclusion
Architectures orientées services SOA

Auteur(s) : Jean-Paul FIGER

Date de publication : 10 août 2006

Pour explorer cet article
Télécharger l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !

Sommaire

Présentation

NOTE DE L'ÉDITEUR

Cet article est la version actualisée de l'article du même nom et du même auteur paru dans nos éditions en 2006.

16/05/2018

RÉSUMÉ

La technologie SOA (Service Oriented Architecture ou Architecture orientée services) est un style d’architecture dont l’objectif premier est de fournir un couplage lâche entre les agents logiciels. Le style SOA simplifie et donc pousse à la réutilisation de services existants avec comme conséquence la nécessité de bien définir des standards de données. Après avoir dressé une liste complète de tous les styles et modèles d’architecture existants, cet article détaille l’architecture SOA et explique comment la reconnaître. De nombreux exemples viennent illustrer les propos de l’article.

Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.

Lire l’article

Auteur(s)

  • Jean-Paul FIGER : Directeur Innovation et Nouvelles Technologies, Capgemini

INTRODUCTION

Ce dossier est destiné principalement à tous ceux qui s’intéressent à l’architecture des systèmes informatiques. Il a pour but d’expliquer la « révolution » qui se cache derrière le style SOA, la manière de reconnaître une architecture SOA et les conséquences de son introduction dans les entreprises.

Le sigle SOA (Service Oriented Architecture ou Architecture orientée services) est devenu à la mode début 2005 grâce aux succès du déploiement de l’Internet dans le public et dans les entreprises. En quelques mois, tous les fournisseurs de produits ou de services se sont découverts plus SOA les uns que les autres. La lecture attentive de leur documentation laisse perplexe car des discours marketing ou techniques insipides démontrent à l’évidence que leurs produits ou méthodes, restés inchangés, ne sont conformes ni de près, ni de loin au style SOA.

Le style SOA peut s’appliquer à toutes les technologies pour tout type de réalisation. Cependant, la révolution SOA est tirée par les standards de l’Internet. C’est donc naturellement ce qui servira de cadre à cet article, en particulier pour les exemples.

Il existe deux groupes de travail du W3C (World Wide Web Consortium http://www.w3.org) qui couvrent le sujet SOA, un sur l’architecture du World Wide Web http://www.w3.org/TR/2004/REC-webarch-20041215/ dont la lecture est indispensable et un autre sur les web services http://www.w3.org/2002/ws/ (SOAP + WSDL) dont nous verrons plus loin les graves faiblesses.

Nota :

La traduction de certains termes anglais en français n’étant pas encore estampillée par l’Académie française, j’ai mis [entre crochets] le terme anglais dont ma traduction est issue.

Cet article est réservé aux abonnés.
Il vous reste 95% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

VERSIONS

Il existe d'autres versions de cet article :

DOI (Digital Object Identifier)

https://doi.org/10.51257/a-v1-h6002


Cet article fait partie de l’offre

Technologies logicielles Architectures des systèmes

(240 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS

Lecture en cours
Présentation

7. Conclusion

Le style d’architecture SOA, défini par un couplage lâche, des services sans état et hautement interopérables, n’est pas une nouveauté en soi. Ces principes sont recommandés depuis les débuts de l’informatique. Ce qui a changé, c’est le contexte. Avec Internet, on accède facilement à tous les services où qu’ils soient dans le monde. L’URI associé au DNS (Domain Name System ) fournit gratuitement une infrastructure de nommage et d’adressage mondial dont le coût de déploiement n’est pas à la portée d’une entreprise quelle que soit sa taille. Le XML définit une syntaxe unique pour tous les documents qui, associée au codage Unicode utf-8 permet de représenter l’ensemble des alphabets du monde. Aujourd’hui, l’interopérabilité des services, c’est-à-dire leur interconnexion sans programmation spécifique ne dépend plus que de l’adoption de vocabulaire de données standards ce qui est en bonne voie dans de nombreux domaines. Dans ce contexte, le style SOA est une obligation. Les sociétés qui ont des centaines de millions d’utilisateurs ont bien compris l’enjeu et fournissent déjà une large gamme de services aux centaines de milliers de développeurs qui interconnectent leurs applications. En revanche, l’offre des vendeurs de produits n’a, en général, de SOA que le nom. Middleware avec état (stateful ) non extensible sans débauche de matériel, nommage et adressage local, services fortement couplés. Ce n’est pas quelques connecteurs SOAP qui peuvent modifier en profondeur l’architecture d’un produit. Il faudra donc attendre beaucoup plus longtemps pour que cette révolution pénètre dans les grandes entreprises.

HAUT DE PAGE

Cet article est réservé aux abonnés.
Il vous reste 94% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

Cet article fait partie de l’offre

Technologies logicielles Architectures des systèmes

(240 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS

Lecture en cours
Conclusion
Sommaire
Sommaire

BIBLIOGRAPHIE

  • (1) - FOWLER (M.) -   « Analysis Patterns »  -  (1997).

  • (2) - FIELDING (R.T.) -   *  -  http://www.ics.uci.edu/%7Efielding/

  • (3) -   Dissertation REST  -  , http://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm.

  • (4) -   Syntaxe des URI,  -  http://www.gbiv.com/protocols/uri/rfc/rfc3986.html

  • (5) -   *  -  IANA, http://www.iana.org/assignments/media-types/

  • (6) -   Architecture of the World Wide Web,  -  http://www.w3.org/TR/webarch/

  • (7) -   « URIs, Addressability, and the use of HTTP GET and POST »,  -  http://www.w3.org/2001/tag/doc/whenToUseGet.html

  • ...

Cet article est réservé aux abonnés.
Il vous reste 92% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

Cet article fait partie de l’offre

Technologies logicielles Architectures des systèmes

(240 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS