CHAPITRE I : INTRODUCTION AU SYSTEMES
DISTRIBUES
DEFINITION DES CONCEPTS
Architecture
L’architecture spécifie la structure d’un système. On parle d’architecture fonctionnelle pour
définir les services du système, d’architecture technique pour les composants techniques
utilisés et d’architecture applicative pour décrire le découpage en sous-systèmes.
Pour mieux cerner le concept d’architecture qui est souvent mal compris parce qu’on la situe
dans la structure résultante d’un modèle. L’architecture n’est pas la conséquence du modèle
mais préside au contraire à son organisation. Cette organisation fixe des directives générales
au développement, et les structures qu’elle induit aident au maintien de l’intégrité du
modèle.
Ainsi en empruntant les termes de Pascal Roque et Franck Vallée, l’architecture est définie
comme : l’ensemble des décisions d’organisation du système logiciel qui défend les intérêts de son
propriétaire final. Les intérêts s’expriment en termes d’exigences fonctionnelles, techniques et
économiques. L’architecture y répond par l’intégration de plusieurs styles de développement
informatique qu’elle adapte aux éléments logiciels d’un contexte existant.
Nous passons en suite en revue différentes architectures logicielles existantes qui constituent
le socle de toutes les applications informatiques.
CONCEPTS ARCHITECTURAUX
Les concepts d’architecture ont subi de nombreuses évolutions depuis les premiers
développements d’applications.
Les premières applications étaient composées d’une seule « pièce », pour ne pas dire d’une
seule fonction linéaire et totalement séquentielle. Si cette solution avait l’avantage d’être
performante, elle avait aussi de nombreux inconvénients : évolution difficile, maintenance
lourde, partage difficile des données…
Pour éviter ces désagréments, de nouveaux systèmes ont vu le jour. Les bases de données ont
tout d’abord simplifié le partage et l’échange de données. L’arrivée d’Internet et des réseaux
d’entreprise ont ensuite permis l’utilisation d’applications clientes plus génériques (les
navigateurs web, par exemple). Leurs architectures ont dû ainsi évoluer, afin de séparer au
mieux les différentes parties de ces applications.
On a alors assisté au succès du modèle 3-tiers (3 parties) qui s’est finalement généralisé en un
modèle n-tiers, découpant l’application en n parties.
L’industrialisation des développements et la taille grandissante des équipes ont aussi
participé à l’évolution de ce nouveau modèle de découpage. Les développeurs, souhaitant
accélérer leurs développements, ont dû factoriser leur travail pour ne pas avoir à toujours «
tout recréer » à chaque projet. Ils ont, pour cela, développé des « briques » réutilisables et
interconnectables facilement, réduisant, ainsi, le temps et le coût des développements.
CATEGORIE D’ARCHITECTURE
1. Application monolithique
Une application monolithique est un programme constitué d’un seul bloc et s’exécutant sur
une seule machine. Ces applications sont généralement utilisées dans le domaine du temps
réel ou bien au sein d’applications demandant de grandes performances. Elles restent
également omniprésentes dans le monde du grand public, étant utilisées en Standalone1 sur
les machines personnelles.
L'avantage de cette structure c'est que l'application possède un grand niveau de performance
en terme de temps de réponse. Le problème, c'est de pouvoir déployer cette application sur
l'ensemble du parc machines de l'entreprise, avec également le souci de la gestion des
versions.
2. Application client-serveur
Dès l'apparition des réseaux, ces applications ont cherché à évoluer et ont abouti à des
architectures dites client-serveur, permettant de séparer la partie cliente qui s'intéresse plus
particulièrement à l'IHM, et de regrouper la partie applicative sur un serveur.
Cependant, le développement de ce genre d'application nécessite la création d'un protocole
de communication entre le client et le serveur. Ce protocole étant souvent propriétaire,
l'évolution de ces applications doivent se faire par les mêmes développeurs. Par ailleurs, le
serveur doit gérer la connexion de plusieurs clients en même temps.
1
Standalone : de manière autonome.
Pour les systèmes d'information d'entreprise, ces solutions restent trop limitées. En effet, leur
problème majeur est leur manque de séparation entre les différents éléments qui les
constituent. C'est également le manque de standard qui a poussé la communauté au concept
de séparation par tiers afin d'optimiser leurs développements.
3. Application multi-tiers
Dans le milieu professionnel, les applications doivent être plus robustes et travaillent
généralement sur des gros volumes de données. Elles doivent, de plus, connecter différents
départements au sein même d'une entreprise.
La maintenance et la stabilité de ces applications sont donc des priorités pour les architectes
et les développeurs. Différents modèles existent. Le plus connu est sans doute le modèle trois-
tiers, largement utilisé par les grandes entreprises ayant besoin de systèmes complexes basés
sur la même organisation des informations : la logique métier.
Ce modèle permet donc d'avoir plusieurs applications différentes avec une même logique
métier, elles peuvent alors mettre en place facilement des applications distribuées dans un
environnement hétérogène2.
De manière théorique, une application distribuée est une application découpée en plusieurs
unités. Chaque unité peut être placée sur une machine différente, s'exécuter sur un système
différent et être écrite dans un langage différent.
a. Le modèle trois-tiers :
Ce modèle est une évolution du modèle d'application client-serveur. L'architecture trois-tiers
est donc divisée en trois niveaux :
Tiers client qui correspond à la machine sur laquelle l'application cliente est
exécutée.
Tiers métier qui correspond à la machine sur laquelle l'application centrale est
exécutée.
Tiers accès aux données qui correspond à la machine gérant le stockage des
données.
2
Environnement hétérogène : environnement logiciel et/ou matériel de différentes natures et/ou versions (par exemple, un
parc de machines sous les systèmes Windows, Linux, Solaris, Mac OS X…).
Ce système utilise un navigateur pour représenter l'application sur la machine cliente, un serveur
Web pour la gestion de la logique de l'application et un serveur de bases de données pour le stockage
des données. La communication entre le serveur Web peut s'effectuer via le protocole HTTP, la
communication avec la base de données via l'API JDBC.
La séparation entre le client, l'application et le stockage, est le principal atout de ce modèle.
Toutefois, dans des architectures qui demandent de nombreuses ressources, il sera assez
limité. En effet, aucune séparation n'est faite au sein même de l'application, qui gère aussi
bien la logique métier que la logique fonctionnelle ainsi que l'accès aux données.
b. Le modèle multi-tiers :
Dans le cadre d'applications beaucoup plus importantes, l'architecture trois-tiers montre ses
limites. L'architecture multi-tiers est simplement une généralisation du modèle précédent qui
prend en compte l'évolutivité du système et évite les inconvénients de l'architecture trois-
tiers vus précédemment.
Dans la pratique, on travaille généralement avec un tiers permettant de regrouper la logique
métier de l'entreprise. L'avantage de ce système, c'est que ce tiers peut être appelé par
différentes applications clientes, et même par des applications classiques, de type fenêtrées,
qui ne passent donc pas par le serveur Web. Entre parenthèses, dans ce dernier cas de figure,
nous nous retrouvons de nouveau avec une architecture trois-tiers.
Si l'architecture est bien étudiée dès le début et s'exécute sur une plate-forme stable et
évolutive, le développeur n'aura alors plus qu'à connecter les différents systèmes entre eux.
De même, les types de clients peuvent être plus variés et évoluer sans avoir d'impact sur le
cœur du système.
La logique métier est la principale de toute l'application. Elle doit s'occuper aussi bien de
l'accès aux différentes données qu'à leurs traitements, suivant les processus définis par
l'entreprise. On parle généralement de traitement métier qui regroupe :
la vérification de la cohésion entre les données,
l'implémentation de la logique métier de l'entreprise au niveau de l'application.
Il est cependant plus propre de séparer toute la partie accès aux données de la partie
traitement de la logique métier. Cela offre plusieurs avantages.
Tout d'abord, les développeurs ne se perdent pas entre le code métier (représenté par les
EJB3s de type session), qui peut parfois être complexe, et le code d'accès aux données
(représenté par les entités), plutôt élémentaire mais conséquent. Cela permet aussi d'ajouter
un niveau d'abstraction sur l'accès aux données et donc d'être plus modulable en cas de
changement de type de stockage. Il est alors plus facile de se répartir les différentes parties
au sein d'une équipe de développement.
D'une façon générale, nous pouvons présenter l'architecture globale d'une informatique
distribuée sous formes de couches. La couche métier se situe ainsi au-dessus de la couche de
persistance avec comme point d'entrée les technologies de la couche présentation : les
applications Web au travers de JSF4 (JavaServer Faces) ou les applications "Standalone" plus
classiques au travers de Swing.
Application en couches
Même s’il est intéressant de séparer les traitements sur différents serveurs, cela ne règle pas
tout. La maintenance et l’évolution d’une application seront facilitées si l’architecture
logicielle de base est bien conçue. Contrairement à l’architecture physique qui est au niveau
matériel, l’architecture logicielle se situe au niveau même de l’application exécutée dans un
tiers : on parle alors de couches applicatives. L’architecte doit y séparer les traitements et les
regrouper dans des ensembles.
Une couche est un sous-système possédant un comportement et des interfaces, et non un
simple groupement d’entités. Le principe de couche n’est pas uniquement lié au
développement mais se retrouve également en réseau avec le modèle OSI5. L’avantage
3 EJB (Enterprise JavaBeans) : Les EJB sont des composants coté serveur qui encapsulent la logique métier et la prennent en charge ; ils
s’occupent aussi de la sécurité.
4 JSF (JavaServer Faces) : Technologie qui permet des créer des composants web riches et qui respecte l’approche RAD (Rapid Application
Development)
5
Modèle OSI : base commune à la description du processus de fonctionnement de tout réseau informatique
([Link]
majeur du découpage en couches est de pouvoir séparer les traitements, réduisant alors leur
couplage6. L’évolution et le maintien de l’application en sont alors facilités.
Généralement, la couche « Persistance » permet d’accéder aux données, la couche « Services
» gère les règles métiers, la couche « Présentation » gère le rendu des données… Il ne faut
cependant pas confondre les couches et les outils. En effet, les outils sont indépendants de
l’application alors que l’implémentation des couches est généralement étroitement liée à
celle-ci. L’organisation de ces couches et leur interconnexion sont très souvent basées sur les
design patterns 7et les bonnes pratiques de développement.
Le couplage est donc un principe à prendre très au sérieux dans tout développement. Il est
important de bien étudier les différentes couches et leurs couplages pour ne rendre abstrait
que les éléments nécessaires.
DÉTAILS DES COUCHES
L’architecture logicielle d’une application est, dans de nombreux cas, constituée des couches
suivantes :
• présentation (client),
• application,
• métier, ou logique business,
• accès aux données.
Couche présentation
La couche présentation est liée au type de clients utilisés. Si vous souhaitez travailler avec un
client riche, vous devrez utiliser l’ensemble des outils et des librairies mis à disposition pour
ce type de client.
Dans une architecture Java EE, on utilise principalement des applications web pour
l’interface utilisateur. En effet, lorsque votre application n’a aucunement besoin d’utiliser des
composants graphiques très spécifiques, il est bien plus pratique d’utiliser les possibilités
d’un navigateur HTML que de développer spécialement une application graphique.
Dans le cas d’une application web, l’application cliente doit interpréter le HTML envoyé. La
génération de celui-ci se situe donc au niveau du serveur d’applications.
En Java EE, les composants utilisés par le développeur sont les JSP (JavaServer Pages), les
TagLibs8 et les JSF (JavaServer Faces). Cette couche est également nommée Vue, dans le
concept du MVC9 (Modèle Vue Contrôleur).
La couche présentation n’est cependant pas toujours synonyme de graphique. La couche
présentation d’un service web10, par exemple, est la représentation XML des données
retournées par celui-ci.
6
Couplage : mesure abstraite de dépendance entre des éléments liés ([Link]
[Link]#h3n1).
7
Design pattern : modèle de conception destiné à résoudre les problèmes récurrents suivant le paradigme objet
8
TagLib : bibliothèques de balises JSP qui agissent comme des extensions au HTML ou au XML.
9
MVC (Modèle vue contrôleur) : modèle de conception séparant le modèle de données, l’interface utilisateur et la logique de
contrôle.
10
Les services web sont une sorte de logique métier offerte à une application cliente (c’est-à-dire un consommateur de
service) via une interface de service.
Couche application
La couche application sert de médiateur entre la couche présentation et la couche métier, et
contrôle l’enchaînement des tâches. Elle est chargée de connaître et de gérer l’état (connecté,
en attente, déconnecté…) des sessions des clients connectés, si l’état est de type «
conversationnel ». Cette couche représente le contrôleur dans un modèle MVC.
Le composant de base utilisé dans un environnement Java EE est la servlet11. Ces composants
servent de point d’entrée à l’application. Ils doivent traiter la requête et faire les appels
nécessaires afin de récupérer ou d’enregistrer des données. Ils redirigeront, enfin,
l’application cliente vers la partie adéquate de la couche présentation.
Couche métier
La couche métier est la couche principale de toute application. Elle doit s’occuper aussi bien
des accès aux différentes données qu’à leurs traitements, suivant les processus définis par
l’entreprise. On parle généralement de traitement métier. Cette expression regroupe :
• la vérification de la cohésion entre les données,
• l’implémentation de la logique métier de l’entreprise au niveau de l’application,
• la gestion du workflow12
Dans le domaine de l’assurance, par exemple, un traitement métier pourrait s’apparenter à
une méthode de calcul d’une prime d’assurance.
Dans le cas d’applications Java EE de grande envergure, cette couche est représentée par les
EJB (Entreprise JavaBeans).
Ces composants sont particulièrement adaptés aux panels hétérogènes de clients (Web, client
riche, client d’un autre langage…) devant se connecter à une même logique métier.
MODÈLE EJB
Le modèle d’architecture « distribuée » impose l’idée qu’une application est découpée en
plusieurs unités. Cependant, il serait quasi impossible de créer ce type d’application « from
scratch » (à partir de rien). En effet, la seule phase de création de la plate-forme supportant ce
type d’applications aurait un coût important aussi bien en termes d’argent que de temps.
Des standards ont alors vu le jour. Le plus général est sans aucun doute Corba 13 qui
correspond au modèle idéal des applications distribuées. Cependant, la lourdeur et la
complexité de mise en œuvre de ce genre d’applications sont les inconvénients majeurs de
cette technologie. C’est pourquoi, un modèle plus restrictif mais plus performant a réussi à
gagner une part de marché importante : le modèle EJB. C’est, bien entendu, celui que nous
allons utiliser et décrire tout au long de ce cours. Même s’il se base sur le protocole standard
IIOP14, pour l’échange de données, il reste principalement utilisé dans le monde Java.
Nous détaillerons le point essentiel de ces technologies qui est « l’objet distribué ». Puis nous
nous consacrerons plus en détail à l’implémentation et l’architecture EJB.
11
Les servlets sont des programmes Java fonctionnant côté serveur au même titre que les CGI et les langages de script tels
qu’[Link] ou PHP
12
Workflow : processus de traitement métier à plusieurs étapes.
13
Corba (Common Object Request Broker Architecture) : standard d’objets distribués permettant d’interconnecter différentes applications
(développées avec différents langages) et de partager des objets entre celles-ci ([Link]
14
IIOP (Internet Inter-ORB Protocol) : protocole de transport utilisé pour la communication entre les objets Corba.
Objets distribués
La communication entre les applications, comme nous l'avons vu dans nos différentes études
antérieures, a été introduite par la programmation client-serveur et le principe des sockets15.
Ce modèle de bas niveau oblige les concepteurs et développeurs à inventer des protocoles
pour faire communiquer leurs applications.
Avec l'arrivée de la programmation orientée objet, la communauté a souhaité développer des
standards et surtout faciliter la communication inter-applications via des modèles de plus
haut niveaux par l'intermédiaire de la technique d'objets distants. Ainsi, des objets existent
sur différentes machines et communiquent entre eux, c'est ce que nous définissons par objets
distribués.
Les objets distribués sont une solution à ce problème d'efficacité. Nous pouvons les
considérer simplement comme des objets pouvant communiquer entre eux par le réseau de
façon autonome. Il est souhaitable, alors, d'avoir un mécanisme permettant, au développeur
d'application cliente, d'effectuer un appel de méthode sur l'objet de façon ordinaire, sans se
préoccuper du format de la requête. De la même façon, le développeur de l'application
serveur pourra répondre aux applications clientes, sans avoir à s'inquiéter du protocole à
mettre en place. Au travers de ce mécanisme, nous utilisons ainsi un objet à distance.
La meilleure solution consiste à utiliser des proxy 16qui se chargent de gérer le protocole
réseau. Il faut alors un proxy serveur et un proxy client.
L’évolution des technologies a permis le développement de standards pour l’implémentation
de cette couche réseau. On retrouve :
• Corba : il prend en charge l’appel de méthodes entre objets distribués
indépendamment de leur langage. Corba utilise le protocole Internet Inter-ORB
communément appelé IIOP.
• RMI 17: un Corba pour Java. C’est une implémentation spécifique à Java, basée sur le
protocole IIOP.
• SOAP 18: protocole utilisé par les services web. Ce protocole est indépendant du
langage, étant basé sur XML. Il n’est pas lié non plus à un protocole de
communication, mais est, la plupart du temps, utilisé via HTTP.
Même si SOAP semble une technologie d’avenir en matière d’objets distribués, elle reste
beaucoup plus limitée en termes de fonctionnalités que RMI. L’implémentation des objets
distribués en Java EE est réalisée par les composants EJB. Il existe une possibilité d’utiliser
SOAP pour accéder à certains EJB, toutefois les applications clientes utilisent généralement
RMI.
Architecture EJB
Une architecture EJB est composée d’au moins 3-tiers : une machine cliente, une machine
contenant la logique applicative et une base de données.
15 Socket : technologie Java permettant d’effectuer des connexions client/serveur élémentaires.
16
Proxy : objet créé lorsque le client active un objet distant. Il agit comme la représentation locale d’un objet distant et assure que tous les
appels effectués sur le proxy sont acheminés vers ce dernier.
17 RMI (Remote Method Invocation) correspond au modèle d'invocation à distance mis en œuvre par Java. Grâce à RMI, Java permet l'accès
via un réseau aux objets se trouvant sur un ordinateur distant.
18 SOAP (Simple Object Access Protocol - Protocole simple d'accès aux objets) est l'espéranto des services Web et de leurs clients, utilisés
pour l'invocation et le passage des paramètres et des valeurs de retour
Dans ce type d’architecture, les EJB se situent dans le tiers « logique applicative ». Les EJB
implémentent la logique métier de l’application et représentent une abstraction de l’accès à la
base de données. Cependant, l’architecture EJB est avant tout une architecture évolutive.
Les EJB sont des applications exécutées côté serveur mais également englobées dans un
conteneur.
Le conteneur EJB
Un conteneur, c’est avant tout une « boîte noire » qui gère :
• la communication avec les services d’infrastructure,
• des applications et leur cycle de vie lié aux clients.
Le conteneur travaille de pair avec le serveur, fournissant, à eux deux, l’environnement
d’exécution pour les EJB.
Le conteneur simplifie la vie du développeur grâce à une réduction des codes à réaliser, une
simplification des traitements (traitements automatiques), et une maintenance réduite
(séparation des couches par niveaux d’abstraction). En effet, le conteneur est à la fois une
application gérant des applications mais également un outil qui génère du code pour chaque
EJB.
C’est aussi le conteneur qui va permettre au développeur d’utiliser les services
d’infrastructure disponibles au sein du serveur EJB, comme la connexion à la base de
données, la gestion des transactions…
Le rôle principal du conteneur EJB est, cependant, de gérer le cycle de vie des applications
EJB qui lui sont associées. C’est lui qui les déploie, les stoppe et les redéploye, tout en gérant
leur conformité avec les spécifications du serveur. Il permet également de contrôler les
composants qui sont à sa charge.
Le client
Le tiers client est représenté par les applications se connectant aux EJB. Ces applications sont
généralement écrites en Java, toutefois, il est également possible de se connecter à un EJB
avec un client écrit dans un autre langage via un accès par service web.
Les clients Java utilisent généralement JNDI 19et RMI pour se connecter et pour appeler les
méthodes des EJB. De ce fait, ils peuvent aussi bien être des applications graphiques
fenêtrées (appelées clients riches), d’autres EJB, des applications internes, et, bien
évidemment, des clients légers (navigateur web). Il est également possible de faire
communiquer les systèmes extérieurs avec une messagerie inter applications, comme JMS20.
Java Naming and Directory Interface (JNDI) fournit les fonctionnalités de nommage et d’annuaire aux applications écrites en Java.
19
JMS (Java Message Service) est une API standard de Java permettant aux applications de créer, d’envoyer, de recevoir et de lire les
20
messages de façon asynchrone.
De façon imagée, le client est le public qui écoute le concert. Le client a fait la demande pour
rentrer dans la salle et a payé son ticket à la caisse (RMI), par un revendeur (HTTP, services
web…) ou par petites annonces (JMS).
Visibilité des EJB
Au-delà de la simple délimitation des différentes couches applicatives, les EJB définissent la
manière dont interagissent les différents intervenants d’une architecture Java EE.
Ils définissent, de plus, les possibilités offertes aux divers clients (application Java, applet,
application s’exécutant sur le même serveur d’applications) et les modalités de
communication.
Ainsi, il sera possible de définir des EJB suivant deux perspectives pour le client : une vue
locale (local) et une vue distante (remote).
Visibilité locale
En adoptant une vue locale (local) pour un EJB, tout client exécuté dans la même machine
virtuelle (autre EJB, servlet...) est en mesure d’appeler les méthodes de cet EJB. Dans cette
vue, les appels de méthode de l’EJB par le client sont effectués comme dans toute application
Java classique (Java SE). Les arguments sont passés par référence et il est possible, pour le
client de modifier directement les objets récupérés.
Il en résulte une démarcation plus faible de l’EJB vis-à-vis de ses clients. Il faut alors
envisager que différents clients manient le même objet au même moment et donc anticiper
les effets indésirables que cela peut induire.
En revanche, l’utilisation d’une vue locale permet d’optimiser les performances du serveur
d’applications et de minimiser les ressources. Celui-ci n’a alors pas à s’occuper des
spécificités liées au transport via le réseau (pas de sérialisation des objets, aucune
communication réseau…).
Visibilité distante
En adoptant une vue distante (remote), un EJB met à disposition ses méthodes à des clients
s’exécutant sur des machines virtuelles différentes, et donc sur des machines physiques
différentes (applets, applications Java, etc.).
Dans le cadre d’une vue distante, les démarcations sont plus fortes entre un EJB et son client.
Les appels de méthodes se font via la technologie RMI, les arguments et valeurs de retour
doivent être sérialisés et ne se transmettent plus par référence. Il n’est alors plus possible
qu’un client modifie le même objet d’un autre client, et il est donc plus aisé de délimiter les
différents domaines de sécurité.
Par contre, l’utilisation d’une vue distante a aussi des inconvénients. Les objets devant être «
transportables » à distance, le conteneur doit sérialiser/désérialiser ces objets pour les
transmettre via le réseau. Il en résulte des temps de traitements plus élevés par rapport aux
appels locaux.
Visibilité service web
Les services web se répandent de plus en plus sur Internet, parce qu’ils permettent d’utiliser
n’importe quel service à partir de n’importe quel langage.
Il est possible de spécifier la visibilité de votre EJB avec le type webservice pour qu’il puisse
être utilisé à la manière d’un service web.
Comment choisir le type d’accès ?
L’adoption d’une vue locale ou distante se décide lors de la création des EJB. Il est tout à fait
possible d’envisager l’utilisation de ces deux vues simultanément, mais il faudra prendre en
compte le fait qu’elles ne sont pas totalement équivalentes (notamment au niveau de la
sécurité avec les passages par référence/valeur).
La différence principale entre ces deux types est sans doute l’accès local ou l’accès à distance.
Si l’application cliente s’exécute au sein de la même machine virtuelle alors la vue locale sera
certainement la plus appropriée et inversement pour la vue à distance. Le choix ne doit pas
être générique, mais doit être fait par rapport aux besoins de l’application. Il est cependant
possible de favoriser les accès locaux en plaçant un intermédiaire (le conteneur web) entre les
EJB et le client distant.
La vue webservice, quant à elle, est à utiliser lorsque le client n’est pas écrit en Java ou lorsque
vous souhaitez rendre votre service le plus ouvert possible. Typiquement, si vous souhaitez
donner la possibilité à vos acheteurs de consulter votre catalogue de produits de n’importe
quelle manière, il peut être judicieux de leur donner l’accès à un tel service web.
Pour reprendre notre comparaison à un orchestre, la vue locale serait celle d’un spectateur
présent dans la salle et la vue distante, celle d’un spectateur écoutant sur sa radio la
rediffusion mise à disposition par l’orchestre. La vue webservice serait, quant à elle, celle
d’une chaîne TV externe, téléchargeant l’enregistrement du concert complet, mis à
disposition par l’orchestre (Business to Business).