Ministère de l’e nseignement Supérieur et de la Recherche scientifique

Université Virtuelle de Tunis

Développement Orienté Services

Introduction aux SOA

Université Virtuelle de Tunis Développement Orienté Services Introduction aux SOA

1. Introduction

L’architecture orientée service (SOA) s’est imposée aujourd’hui comme 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’un style d’architecture et de gouvernance de SI.

Dans ce chapitre, nous présentons les raisons qui ont poussé à l’apparition de cette architecture à travers une vision générale et historique des architectures des SI.

2. Des architectures distribuées classiques, vers une architecture SOA

1. Architectures à base de composants

Une application distribuée est définie par un ensemble de composants qui collaborent pour l’exécution de tâches communes. Ces composants sont des objets logiciels hétérogènes, crées pour interagir avec d’autres composants, distants géographiquement et interconnectés via un réseau de communication, et qui encapsulent certaines fonctionnalités ou un ensemble de fonctionnalités.

L’objectif de l’ingénierie des logiciels à base de composants était d’augmenter la productivité, la qualité et la réponse aux demandes du marché dans les meilleurs délais grâce à l’automatisation et la standardisation de la production. Plusieurs solutions ont fait leur preuve : DCOM, CORBA, EJB, RMI, .NET Remoting, … Cependant ses solutions présentent des faiblesses, notamment au niveau de la représentation des données qui est souvent spécifique, l’interopérabilité qui n’est garantie que lorsque les composants utilisent la même solution et la nécessité d’une configuration réseau à cause de l’usage de protocoles de transport spécifiques.

2. Evolution des architectures distribuées

Les applications distribuées ont évolué au cours du temps suivant les besoins des entreprises et l’évolution des technologies. On est passé donc, de simples applications avec une architecture client/serveur, puis à des architectures fondées sur les applications web, jusqu’aux architectures SOA.

Université Virtuelle de Tunis Développement Orienté Services Introduction aux SOA

Architecture client/serveur

Architecture fondée sur les applications web

Architecture orientée services

Les applications distribuées ont été conçues au départ selon l’architecture client/serveur. C’était des applications intra-entreprise, limitées à un sous ensemble de langages de programmation souvent procéduraux. Afin de garantir l’efficacité et la rapidité du traitement, ces applications étaient fortement couplées et s’appuyaient sur des protocoles de transport propriétaires.

Avec l’expansion de l’Internet, les applications web sont apparues, avec comme grande particularité leur ouverture. Il est ainsi permis à un utilisateur d’interagir directement avec le programme et ce sans contrainte géographique. Ces applications, ayant un service monolithique, s’appuyaient sur un référencement via des annuaires de sites non standardisés.

Les architectures SOA sont venues donc pour pallier aux lacunes des applications distribuées précédentes. Leur principe est fondé sur le fait que des programmes informatiques, conçus avec des technologies différentes et tournant sur des OS différents, peuvent interagir entre eux et ce sans se connaître grâce à des annuaires standardisés. Les architectures SOA exploitent pleinement les atouts de l’approche orienté objet avec une décomposition des services en sous services avec possibilité de réutilisation.

3. Architectures SOA : Principes et Motivations

SOA (Service Oriented Architecture) est un style d’architecture organisé à partir de services métiers communs mutualisés pour un ensemble de lignes métiers ou d’applications.

« SOA is an approach to designing software that dissolves business applications into separate “services” that can be used independent of the applications of which they’re a part and computing platforms on which they run. »

Le Service (ou Composant) désigne le fondement de ce modèle d’interaction entre applications. Le paradigme SOA est basé sur la publication, la recherche et la consommation, comme le montre la figure ci-dessous :

Jay DiMare, IBM Global Services, 2006

Université Virtuelle de Tunis Développement Orienté Services Introduction aux SOA

Qu’est-ce qu’un service ?

« Un Service est un composant logiciel distribué, exposant les fonctionnalités à forte valeur ajoutée d’un domaine métier » [XEBIA BLOG : 2009] Grâce aux services, les applications peuvent être vues comme un ensemble de services métiers, structurés et correctement décrits, dialoguant selon un standard international plutôt qu'un ensemble d'objets et de méthodes entremêlés.

Le premier bénéfice de ce découpage est la facilité de maintenance de l'application, ainsi que l'interopérabilité permettant de modifier facilement un composant (un service) pour le remplacer par un autre, éventuellement développé par un tiers. Qui plus est, les services permettent de réduire la complexité d'une application car le développeur peut se focaliser sur un service, indépendamment du reste de l'application.

Les services web facilitent non seulement les échanges entre les applications de l'entreprise mais surtout permettent une ouverture vers les autres entreprises. Les premiers fournisseurs de services web sont ainsi les fournisseurs de services en ligne (météo, bourse, planification d'itinéraire, pages jaunes, etc.), mettant à disposition des développeurs des API (Application Programmable Interface) payantes ou non, permettant d'intégrer leur service au sein d'applications tierces.

Voici les différents aspects caractérisant les services :

Contrat standardisé

Un contrat est établi entre le fournisseur de service et le consommateur de service. On distingue trois types de contrat :

• Lié à la syntaxe du service (opération, messages d’entrée, messages de sortie, …).

• Lié à la sémantique du service (définition de règles et de contraintes d’usage, …)

• Lié à la qualité de service (temps de réponse attendu, procédures en cas de panne, temps

de reprise après interruption, …).

Le service s’appuie sur des standards d’interopérabilité pour faciliter le dialogue (exemple : WSDL).

Couplage lâche

Université Virtuelle de Tunis Développement Orienté Services Introduction aux SOA L’une des caractéristiques principales de l’architecture SOA c’est qu’elle garantit un couplage lâche entre ses composants. En effet, l’échange entre le fournisseur de service et le consommateur doit se faire à travers des messages (couplage lâche vis-à-vis de son environnement). L’architecture utilise ainsi un orchestrateur afin d’éviter que les services

aient besoin de connaître les autres services .

Couplage fort

Couplage lâche

Abstraction

Le contrat du service ne doit contenir que les informations pertinentes à son invocation. On peut ainsi assimiler le fonctionnement du service en « boîte noire », où seul le contrat exposé au consommateur du service est connue et que le fonctionnement interne du service, c’est-à dire la logique métier et l’implémentation, ne doit pas être visible. Il est par conséquent important d’assurer la prédictabilité d’un service, c’est-à-dire éviter qu‘il y ait des variations dans le comportement et dans la réponse d’un service lors de la réception d’une requête.

Réutilisabilité / Découvrabilité

Un service doit être accessible depuis un entrepôt ou un annuaire pour faciliter sa découverte. C’est le fournisseur de services qui 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. La publication s’appuie sur des standards (UDDI, ebXML). Le service est aussi conçu afin qu’il puisse être réutilisé. Autonomie / Sans état

Un service doit disposer de l’ensemble des informations nécessaires à son exécution. Il ne doit dépendre donc d’aucun service externe (couplage lâche). Il doit être aussi autonome ce qui permet d’assurer sa prédictabilité. Un service doit être sans état de façon à minimiser la consommation de ressources.

Composabilité

Un service doit fonctionner de manière modulaire et non pas intégrée. Il faut ainsi assurer la décomposition d’un service complexe en sous services plus simples entre eux (garantie l’autonomie), cette décomposition est par la suite gérée par un orchestrateur (couplage lâche).

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

Université Virtuelle de Tunis Développement Orienté Services Introduction aux SOA 3. Services WEB

1. Réponse aux SOA

Les Services Web sont actuellement l’alternative la plus courante et la plus évidente pour concevoir des architecture SOA. Ce sont en effet des composants qui sont basés sur les protocoles et les langages du Web : HTTP, XML, TCP/IP pour la couche réseau. Leur grand avantage est donc qu’ils ne nécessitent pas une configuration réseau particulière. Ils ont la particularité aussi d’être auto-suffisants puisqu’ils contiennent toutes les informations à leurs utilisations, à la fois pour leur recherche, publication et consommation. Pour cela ils disposent d’éléments essentiels comme les annuaires et les contrats qui décrivent leur fonctionnement et qui permettent ainsi aux clients de les consommer. Plusieurs standards ce sont mis à la définition des Services Web, on cite les plus importants : W3C, OASIS, WS-I et IETF.

Les Services Web sont modulaires de façon à ce qu’une application doit être décomposée en un ensemble de services. Ces derniers sont gérés et synchronisés grâce à un orchestrateur.

2. Technologies disponibles

Deux familles de Services Web se distinguent actuellement :

• Services Web « étendues » : ils s’appuient sur des standards UDDI / WSDL / SOAP. Ils possèdent des annuaires de Services Web de type UDDI afin de permettre leur publication et leur recherche, s’appuient sur des contrats de type WSDL pour décrire leur fonctionnement et sur le protocole SOAP pour envoyer les messages.

• Services Web REST (Representational State Transfer) : défini par la thèse de Roy

Fielding en 2000. Il utilise directement HTTP au lieu d’utiliser une enveloppe SOAP et ceci grâce à l’utilisation des URI afin de nommer et identifier une ressource. Des méthodes HTTP (POST, GET, PUT et DELETE) sont utilisées pour effectuer les opérations de base CRUD.

3. Services Web étendus

Les Services Web étendus reposent sur une trilogie de fonctions qui sont : la publication, la recherche et la consommation. Ces fonctions se basent sur les standards suivants :

- UDDI : pour la découverte d’un Service Web dans un annuaire

- WSDL : pour la description d’un Service Web (le contrat)

Université Virtuelle de Tunis Développement Orienté Services Introduction aux SOA

- SOAP : pour l’envoi messages, le protocole HTTP est le plus souvent utilisé pour le transfert, mais d’autres protocoles sont possibles aussi comme SMTP, FTP et JMS.

Annuaire UDDI

Interrogation de l’annuaire UDDI pour rechercher des contrats WSDL suivant des critères spécifiques

WSDL

Document WSDL est utilisé comme contrat du Service Web

Consommateur du Service

Message SOAP est envoyé pour consommer ( invoquer) un Service Web

Fournisseur du Service

Ci-dessous la pile des standards utilisés pour développer et exécuter des Services Web étendus:

Orchestration

Langage de processus métier BPEL

Sécurité (WS-Security)

Transaction (WS- Transactions)

Fiabilité (WS-RM) WSD, UDDI

SOAP 1.1 et 1.2

HTTP, SMTP, FTP, BEEP, JMS

Qualité de Service

Découverte & Description

Message

Transport

4. Services Web REST

Les services Web REST sont exploités pour construire des Architectures Orientées Données

(DOA). REST n’est pas un standard, car il n’existe pas de spécification W3C la définissant, c’est plutôt un style d’architecture basé sur un mode de compréhension du Web. REST s’appuie donc sur les standards du Web, à savoir : le protocole http et les URLs. Une sécurisation via SSL pour l’invocation des services et le transfert des messages peut être utilisée.

Ci-dessous la pile des standards utilisés pour développer et exécuter des Services Web REST :

Orchestration

Qualité de Service

Découverte & Description

Message

Transport

Langage de processus métier BPEL

http Basic, SSL / TLS

WADL, ATOM, …

MIME Types (Text, JSON, XML, …)

HTTP, FTP

Université Virtuelle de Tunis Développement Orienté Services Introduction aux SOA 5. Fournisseurs de Services Web

Deux types de fournisseurs de Services Web sont à distinguer : fournisseurs de Services Web « Orientés Web » (public) et fournisseurs de Services Web « Entreprise » (privé).

Les grands noms du Web sont présents et leurs services sont accessibles : Amazon, eBay, Delicious, Facebook, Flickr, Google, Twitter, WheatherBug, Yahoo, Zillow, Zvents.

Pratiquement tous les fournisseurs de Services Web exploitent l’architecture REST (besoins de performance). Certains (comme Google) ont arrêtés les Services Web étendus, tandis qu’eBay propose encore des Services Web étendus.

Plateformes de Développement

La grande majorité des plateformes de développements fournissent le support de Services Web (outils et APIs) : Plateforme .NET, Plateforme Java, Plateforme PHP, C++, Python, …

Les outils fournis permettent de : manipuler des messages SOAP, manipuler des données au format XML, faire le mapping XML / Classe (Marshall, Unmarshall) et accéder à la couche http. Dans ce cours, nous utiliserons la plateforme Java qui est bien outillée, gratuite, accessible, légère et qui respect les standards.