Coulouris définit les systèmes distribués comme « des systèmes dans lesquels des composants matériels et/ou logiciels existant dans un réseau informatique communiquent et coordonnent leurs actions en échangeant des messages ».
Ce concept est devenu populaire ces dernières années en raison de plusieurs facteurs. Le premier facteur qui a favorisé le développement des systèmes distribués a été l'émergence des réseaux locaux à haut débit. Un autre facteur important a été l'avancée technologique dans les performances des ordinateurs personnels et le développement de logiciels pour prendre en charge les applications distribuées. Les systèmes distribués sont liés au concept du Web et de l'Internet. Avec l'évolution du Web, et l'apparition de nouveaux domaines, interactions, besoins et applications, le concept de Web 2.0 apparaît. Ce terme a été inventé par Tim O'Reilly en 2004 pour désigner une deuxième génération dans l'histoire du Web basée sur des communautés d'utilisateurs et une gamme particulière de services, tels que les réseaux sociaux, les blogs, les wikis ou les folksonomies, qui encouragent la collaboration et la rapidité échange d'informations entre utilisateurs.
Les premières architectures pouvant être considérées comme orientées services (SOA) étaient basées sur CORBA (Common Object Request Broker Architecture), qui agissait comme une couche d'abstraction pour interconnecter les différents éléments de l'architecture et construire des services. D'autres technologies antérieures étaient DCOM (Distributed Component Object Model) ou RPC (Remote Procedure Protocol). Avec la nécessité de concevoir et d'implémenter efficacement des systèmes distribués sur le Web, plusieurs défis se posent, certains centrés sur le développement lui-même (performance, expérience utilisateur, etc.) et d'autres complémentaires, basés sur la réutilisabilité et la compatibilité des services. De ces besoins découlent des services Web, qui fournissent des mécanismes standardisés pour interconnecter différents utilisateurs avec des serveurs d'information.
ARCHITECTURES ORIENTÉES SERVICE
Selon SOA (Service Oriented Architecture) sont des architectures logicielles qui définissent l'utilisation de services pour supporter les besoins métiers, dont l'objectif est de réaliser le moins de couplage possible entre les agents logiciels. Un service est une unité de travail effectuée par un fournisseur de services pour obtenir un résultat final souhaité par un consommateur de services. Le fournisseur de services et le consommateur de services sont tous deux des rôles joués par des agents logiciels, et non par des propriétaires de logiciels. De manière générale, une architecture orientée services est une solution logicielle destinée à permettre à une entreprise d'organiser et d'exploiter différents processus. Avec la SOA, les applications logicielles ne sont plus des blocs massifs de fonctions et de processus. Au lieu de cela, ces applications sont constituées de services modulaires assemblés. N'oubliez pas qu'un service est une simple fonction logicielle (comme l'annulation d'un CD). Il peut être exécuté à la demande par n'importe quel système, quel que soit le système d'exploitation, la plate-forme, le langage de programmation ou l'emplacement géographique.
Ce qui est révolutionnaire dans SOA, ce n'est pas le concept lui-même, qui existe depuis longtemps, mais le fait qu'il peut être mis en œuvre sur le WWW (World Wide Web). De la même manière que les pages Web se chargent sur n'importe quelle plate-forme, les services Web fonctionnent de la même manière quelle que soit la plate-forme, car ils sont créés à l'aide de
normes universelles.
L'idée de SOA découle directement de la programmation orientée objet, qui suggère une relation entre les données et leur traitement. Ainsi, ils définissent formellement les services via des interfaces indépendantes de la plate-forme sous-jacente et du langage de programmation. Ces interfaces cachent les particularités de leur implémentation, ce qui les rend indépendantes de développeur et langage de programmation. Grâce à ces architectures, il est possible de concevoir et de mettre en œuvre des systèmes hautement évolutifs qui reflètent la logique métier et facilitent en même temps l'interaction entre différents systèmes propriétaires ou tiers. La raison pour laquelle nous voulons que quelqu'un d'autre fasse le travail pour nous, c'est parce qu'il s'agit d'experts. Utiliser un service est généralement moins cher et plus efficace que de le faire soi-même. Ainsi, la plupart d'entre nous comprennent que nous ne pouvons pas être des experts en tout. La même règle peut être appliquée à la construction de systèmes logiciels.
Les interfaces sont très importantes, si elles ne sont pas bien définies ou ne fonctionnent pas, le système ne fonctionne pas. L'intégration d'un plus grand nombre d'interfaces coûte cher et augmente également le risque d'erreurs dans les applications distribuées. Les interfaces distantes sont la partie la plus lente de la plupart des applications distribuées. Avec tout cela, au lieu de créer de nouvelles interfaces pour chaque application, il est plus logique de réutiliser des interfaces génériques pour toutes les applications.
Ainsi, puisque nous n'avons que quelques interfaces génériques disponibles, nous devons inclure une sémantique spécifique à l'application dans les messages. Nous pouvons envoyer n'importe quel type de message à travers nos interfaces, mais il y a quelques règles à respecter pour dire qu'une architecture est orientée services.
– Premièrement, les messages doivent être descriptifs et non instructifs, car le fournisseur de services est responsable de la résolution du problème. Par exemple, ce serait similaire à la situation d'aller au restaurant et de dire au serveur ce que vous aimeriez boire et vos préférences, mais nous ne devrions pas expliquer au cuisinier comment préparer vos plats, étape par étape.
‐ Deuxièmement, les prestataires de services ne seront pas en mesure de comprendre votre demande si leurs messages ne sont pas rédigés dans un format, une structure et un vocabulaire compréhensibles par toutes les parties concernées. Ainsi, limiter le vocabulaire et la structure des messages est un
nécessaires à une communication efficace. Plus le message est étroit, plus il est facile à comprendre.
- Troisièmement, la possibilité d'extensions est d'une importance vitale. Le monde est un endroit en constante évolution, tout comme l'environnement dans lequel vit le logiciel. Ces changements nécessitent des changements correspondants dans le logiciel système, les consommateurs des services, des fournisseurs et des messages qu'ils échangent. Si les messages ne sont pas extensibles, les consommateurs et les fournisseurs sont verrouillés sur une version spécifique du service. La contrainte et l'extensibilité sont profondément liées, vous avez besoin des deux, et augmenter l'une signifie réduire l'autre. L'idéal est d'atteindre un équilibre correct.
– Quatrièmement, une SOA doit disposer d'un mécanisme permettant au consommateur de découvrir un fournisseur de services dans le contexte d'un service recherché par le consommateur. Le mécanisme devrait être souple et non un registre centralisé.
- Cinquièmement, Service sans état : Chaque message qu'un consommateur envoie à un fournisseur doit contenir toutes les informations nécessaires au fournisseur pour le traiter. Cette restriction rend un fournisseur de services plus évolutif, car le fournisseur n'a pas besoin de stocker des informations d'état entre les demandes. Cela peut être appelé un « service de production de masse » car chaque demande peut être traitée de manière générique. Cette restriction offre également plus de visibilité, car tout logiciel de surveillance peut inspecter indépendamment une demande et en extraire l'intention. Cela permet également une récupération facile après des pannes partielles car il n'y a pas d'états intermédiaires, ce qui rend le service plus fiable.
- Sixièmement, les requêtes idempotentes (sans modification) : les requêtes en double reçues par un agent logiciel ont le même effet qu'une seule requête. Cette exigence permet aux fournisseurs et aux consommateurs d'augmenter la fiabilité globale du service, en répétant simplement la demande en cas d'échec.
On peut donc dire que la SOA n'est pas un outil, mais un ensemble de normes permettant de construire de nouvelles applications, plus dynamiques et moins dépendantes. SOA facilite l'accès à la logique métier et aux informations sur plusieurs services de manière systématique, et peut également orchestrer plusieurs services distants pour en composer un seul. la plupart de les définitions identifient l'utilisation des Web Services, que nous verrons au chapitre suivant, dans la mise en place d'une architecture orientée services. Cependant, il peut être mis en œuvre à l'aide de toute autre technologie basée sur les services.