Le stub est la partie du code générée automatiquement par un compilateur IDL vers un langage de programmation cible. Ce code est utilisé par le client lors des invocations statiques. Il est le lien entre le client et l'ORB.
Il traduit :

• les invocations du client en messages transmissibles sur le réseau : opération "marshalling",
• les messages qui proviennent de l'ORB dans le langage choisi : opération "unmarshalling".

Le squelette statique (skeleton) est la partie du code générée automatiquement par un compilateur IDL vers un langage de programmation cible. Ce code est utilisé par l'Adaptateur d'objet lors des invocations statiques. Il est le lien entre l'ORB et l'objet d'implémentation.
Il reconstitue la requête du client de façon à invoquer la méthode requise en langage choisi  : opération "unmarshalling".
Il traduit les paramètres de retour en messages transmissibles sur le réseau : opération "marshalling".

La référence d'objet est une structure désignant l'objet CORBA. Elle est contenue dans l'espace mémoire de l'application cliente et permet à celle-ci de dialoguer avec l'objet distant. Cette structure contient les informations nécessaires à l'ORB pour localiser l'objet. Ces informations sont dépendantes du protocole de transport utilisé. Par exemple, une référence IOR du protocole IIOP contient le nom de la machine et le port TCP/IP du serveur où est localisé l'objet (en plus, de l'identifiant global unique désignant l'interface IDL de l'objet).

L'Adaptateur d'objet (Object Adapter)  est une entité qui assiste l'ORB pour délivrer les requêtes aux objets et à leurs activations. D'une manière primordiale, l'Adaptateur d'objet permet d'associer les implantations des objets avec l'ORB. Les adaptateurs d'objets peuvent être spécialisés pour fournir des services pour certains modèles d'implantation d'objet. Tous les adaptateurs doivent fournir les fonctionnalités suivantes :

• l'enregistrement des implantations : l'adaptateur doit connaître les informations décrivant les implantations d'objets comme, par exemple, le nom des exécutables stockant le code d'implantation des objets. Ces informations sont emmagasinées dans le référentiel des implémentations.
• la génération et l'interprétation des références d'objets : l'adaptateur génère les références des objets CORBA pour le compte desquels il agit. De plus, lorsqu'une requête est envoyée à destination d'un objet, il sait interpréter la référence d'objet contenue dans la requête afin d'activer l'objet destinataire.
• l'activation des implantations d'objets,
• l'invocation des opérations,
• la participation à la sécurité : l'adaptateur peut travailler en collaboration avec le service Sécurité.
• la désactivation des implantations d'objets.

Le référentiel d'implémentations est le responsable de l'enregistrement des serveurs dans le système (enregistrement de la commande exécutable). Il est contrôlé par la commande putit dans les commandes associées lsit, catit, rmit. Il est défini par une interface IDL et il est implémenté par un processus démon.

L'interface de l'objet définit un type abstrait d'objets CORBA, c'est à dire l'ensemble des opérations et attributs de ses instances. Elle précise la signature de chaque opération.  Celle-ci se définit par l'intermédiaire du langage OMG-IDL.

La requête est le mécanisme d'invocation d'une opération sur un objet. Lorsqu'une requête est émise, elle contient la référence de l'objet destinataire, le nom de l'opération et l'ensemble des valeurs des paramètres en entrée.

L'ORB ou bus CORBA achemine les requêtes de l'application cliente vers l'objet en masquant tous les problèmes d'hétérogénéité (langages, systèmes d'exploitation, matériels, réseaux).

L'objet CORBA est le composant logiciel désigné par une référence et recevant les requêtes émises par les applications clientes. Cet objet accepte uniquement les requêtes pour les opérations décrites dans son interface.

Le processus d'activation est le processus d'association d'un objet d'implantation à un objet CORBA. Lorsqu'une requête arrive à destination d'un objet CORBA, le bus active une implantation et lui transmet la requête. Au cours du temps, un même objet CORBA peut se voir associer des implantations distinctes. (VOIR BOA)

L'implantation de l'objet est l'entité codant l'objet CORBA à un instant donné. Cette entité stocke l'état de l'objet CORBA et fournit une réalisation pour chaque opération de l'objet. Au cours du temps, un même objet CORBA peut se voir associer des implantations différentes.

Le code d'implantation regroupe les traitements associés à l'implantation des opérations de l'objet CORBA. Cela peut être par exemple une classe Java aussi bien qu'un ensemble de fonctions C.

L'application serveur est la structure d'accueil des objets d'implantation et des exécutions des opérations. Cela peut être par exemple un processus Unix.

GIOP (General Inter-ORB Protocol) spécifie un ensemble de formats pour les messages ainsi qu'une représentation commune des données échangées entre les ORBs. La représentation des données communes est basée sur la spécification CDR (Common Data Representation).

IIOP (Internet Inter-ORB Protocol) est l'implémentation du protocole GIOP basé sur TCP/IP.

Object Management Group(OMG) est un consortium international créé en 1989 et regroupant plus de 850 acteurs du monde informatique : des constructeurs (IBM, Sun), des producteurs de logiciel (Netscape, Inprise, IONA Tech.), des utilisateurs (Boeing, Alcatel) et des institutionels et universités (NASA, INRIA, LIFL). L'objectif de ce groupe est de faire émerger des standards pour l'intégration d'applications distribuées hétérogènes à partir des technologies orientées objet. Ainsi les concepts-clés mis en avant sont la réutilisabilité, l'intéropérabilité et la portabilité des composants logiciels.

Les services objet communs (CORBAServices) fournissent sous forme d'objets CORBA, spécifiés grâce au langage OMG-IDL, les fonctions nécessaires à la plupart des applications réparties. Actuellement, l'OMG a défini des services pour les annuaires (Nommage et Vendeur), le cycle de vie des objets, les relations entre objets, les évenements, les transactions, la sécurité, la persistance, etc. Au fur et à mesure des besoins, l'OMG ajoute de nouveaux services communs.

Le service Nommage (Naming Service) est l'équivalent des "pages blanches" : les objets sont désignés par des noms symboliques. Cet annuaire est matérialisé par un graphe de répertoires de désignation.

Le service Vendeur (Trader Service) est l'équivalent des "pages jaunes" : les objets peuvent être recherchés en fonction de leurs caractéristiques.

Le service Cycle de Vie (Life Cycle Service) décrit des interfaces pour la création, la copie, le déplacement et la destruction des objets sur le bus. Il définit pour cela la notion de fabriques d'objets ("Object Factory).

Le service Propriétés (Property Service) permet aux utilisateurs d'associer dynamiquement des valeurs nommées à des objets. Ces propriétés ne modifient pas l'interface IDL, mais représentent des besoins spécifiques du client comme par exemple des annotations.

Le service Relations (Relationship Service) sert à gérer des associations dynamiques (appartenance, inclusion, référence, auteur, emploi, …) reliant des objets sur le bus. Il permet aussi de manipuler des graphes d'objets.

Le service Externalisation (Externalization Service) apporte un mécanisme standard pour fixer ou extraire des objets du bus. La migration, le passage par valeur, et la sauvegarde des objets doivent reposer sur ce service.

Le service Persistance (Persistent Objetc Service) offre des interfaces communes à un mécanisme permettant de stocker des objets sur un support persistant. Quel que soit le support utilisé, ce service s'utilise de la même manière via un "Persistent Object Manager". Un objet persistant doit hériter de l'interface "Persistent Objetc" et d'un mécanisme d'externalisation.

Le service Interrogations (Query Service) permet d'interroger les attributs des objets. Il repose sur les langages standards d'interrogation comme SQL3 ou OQL. L'interface Query permet de manipuler les requêtes comme des objets CORBA. Les objets résultats sont mis dans une collection. Le service peut fédérer des espaces d'objets hétérogènes.

Le service Collections (Collection Service) permet de manipuler d'une manière uniforme des objets sous la forme de collections et d'itérateurs. Les structures de données classiques (listes, piles, tas, …) sont construites par sous-classement. Ce service est ainsi conçu pour être utilisé avec le service d'interrogations pour stocker les résultats de requêtes.

Le service Changements (Versionning Service) permet de gérer et de suivre l'évolution des différentes versions des objets. Ce service maintient des informations sur les évolutions des interfaces et des implantations. Cependant, il n'est pas encore spécifié officiellement.

Le service Sécurité (Sécurity Service) permet d'identifier et d'authentifier les clients, de chiffrer et de certifier les communications et de contrôler les autorisations d'accès. Ce service utilise les notions de serveurs d'authentification,de clients/rôles/droits (et délégation de droits), d'IIOP sécurisé.

Le service Transactions (Object Transaction Service) assure l'exécution de traitements transactionnels impliquant des objets distribués et des bases de données en fournissant les propriétés ACID.

Le service Concurrence (Concurrency Service) fournit les mécanismes pour contrôler et ordonnancer les invocations concurrentes sur les objets. Le mécanisme proposé est le verrou. Ce service est conçu pour être utilisé conjointement avec le service Transactions.

Le service Evénements (Event Service) permet aux objets de produire des événements asynchrones à destination d'objets consommateurs à travers des canaux d'événements. Les canaux fournissent deux modes de fonctionnement. Dans le mode "push ", le producteur a l'initiative de la production, le consommateur est notifié des événements. Dans le mode "pull ", le consommateur demande explicitement les événements, le producteur est alors sollicité.

Le service Notification (Notification Service) est une extension du service précédent. Les consommateurs sont uniquement notifiés des événements les intéressant. Pour cela, ils posent des filtres sur le canal réduisant ainsi le trafic réseau engendré par la propagation des événements inintéressants.

Le service Messagerie (CORBA Messaging [OMG-CM])  définit un nouveau modèle de communication asynchrone permettant de gérer des requêtes persistantes lorsque l'objet appelant et l'objet appelé ne sont pas présents simultanément sur le bus. Cela permet d'avoir des fonctionnalités proches des MOMs (" Message Oriented Middleware ").

Le service Temps (Time Service) fournit des interfaces permettant d'obtenir une horloge globale sur le bus (Universal Time Object), de mesurer le temps et de synchroniser les objets.

Le service Licences (Licensing Service) permet de mesurer et de contrôler l'utilisation des objets, et cela en vue de facturer les clients et de rémunérer les fournisseurs.

Les Interfaces de domaine (Domain Interfaces) définissent des objets de métiers spécifiques à des secteurs d'activités comme la finance (e.g. monnaie électronique), la santé (e.g. dossier médical) et les télécoms (e.g. transport multimédia). Leur objectif est de pouvoir assurer l'interopérabilité sémantique entre les systèmes d'informations d'entreprises d'un même métier : les "Business Object Frameworks" (BOFs).

Les utilitaires communs (CORBAfacilities) sont des canevas d'objets ("Frameworks") qui répondent plus particulièrement aux besoins des utilisateurs. Ils standardisent l'interface utilisateur, la gestion de l'information, l'administration, le Workflow, etc.

Les objets applicatifs (Application Objects) sont ceux qui sont spécifiques à une application répartie et ne sont donc pas standardisés. Toutefois, dès que le rôle de ces objets apparaît dans plus d'une application ils peuvent alors rentrer dans une des catégories précédentes et donc être standardisés par l'OMG.