Partager via


Modèle de programmation

Au début de la programmation informatique, chaque programme a été écrit en tant que bloc monolithique volumineux, rempli de goto instructions. Chaque programme devait gérer ses propres entrées et sorties sur différents périphériques matériels. À mesure que la discipline de programmation a mûri, ce code monolithique a été organisé en procédures, avec les procédures les plus couramment utilisées packées dans les bibliothèques pour le partage et la réutilisation.

instructions goto monolithiques versus procédures emballées dans des bibliothèques partagées

Le langage de programmation C prend en charge la programmation orientée procédure. En C, la fonction principale est reliée à toutes les autres fonctions comme des boîtes noires. Par exemple, la procédure principale ne peut pas savoir comment les procédures A, B et X effectuent leur travail. La procédure principale appelle uniquement une autre procédure ; il n’a aucune information sur la façon dont cette procédure est implémentée.

isolation des activités effectuées en dehors des procédures

Les langages de programmation orientés procédure fournissent des mécanismes simples pour spécifier et écrire des procédures. Par exemple, le prototype de fonction C standard ANSI est une construction utilisée pour spécifier le nom d’une procédure, le type du résultat qu’il retourne (le cas échéant) et le nombre, la séquence et le type de ses paramètres. L’utilisation du prototype de fonction est un moyen formel de spécifier une interface entre les procédures.

Microsoft RPC s’appuie sur ce modèle de programmation en autorisant les procédures, regroupées dans les interfaces, à résider dans des processus différents de ceux de l’appelant. Microsoft RPC ajoute également une approche plus formelle de la définition de procédure qui permet à l’appelant et à la routine appelée d’adopter un contrat pour l’échange à distance de données et l’appel de fonctionnalités. Dans le modèle de programmation MICROSOFT RPC, les appels de fonction traditionnels sont complétés par deux éléments supplémentaires.

  • Le premier élément est un fichier .idl/.acf qui décrit précisément le mécanisme d’échange de données et de passage de paramètres entre l’appelant et la procédure appelée.
  • Le deuxième élément est un ensemble d’API d’exécution qui fournissent aux développeurs un contrôle granulaire de l’appel de procédure distante, y compris les aspects de sécurité, la gestion de l’état sur le serveur, la spécification des clients qui peuvent communiquer avec le serveur, et ainsi de suite.