Common Object Request Broker Architecture CORBA Common Object Request Broker Architecture Mise en pratique avec Orbacus en JAVA Mireille Blay-Fornarino blay@essi.fr Extraits de JM Geib, C. Gransart, P. Merle http://www.iona.com/products/orbacus_home.htm - 1 - 1 1

Plan du Cours I Introduction II OMG-IDL III L’architecture CORBA Intégration d ’applications CORBA : la réponse de l ’OMG l ’OMG : promouvoir la standardisation Le modèle client serveur orienté objet L ’architecture OMA II OMG-IDL Interface Definition Language III L’architecture CORBA Composantes du Bus Mise en œuvre Services Interopérabilité IV. Conclusion CORBA 3.0 CORBA et les autres CORBA Component Model (CCM) Mireille Blay-Fornarino - 2 -  

Consensus pour l’interopérabilité 1.1-histoire Consensus pour l’interopérabilité Le problème : Intégration des applications Pas de consensus sur les langages de programmation Pas de consensus sur les plate-formes de développement Pas de consensus sur les systèmes d’exploitation Pas de consensus sur les protocoles réseau Pas de consensus sur les formats des données manipulées par les applications Recherche d’un Consensus pour l’interopérabilité « The bad news is that there will never be a single operating system, single programming language, or single network architecture that replaces all that has passed; The good news is that you can still manage to build systems economically in this environment. » «  Model Driven Architecture » by Richard Soley and the OMG Staff Strategy Group CORBA est le fruit d’un long travail de consensus effectué par les membres d’un consortium international OMG. C’est la réponse du groupe de l’OMG au besoin d’interopérabilité entre de nombres de plus en plus inmportant de hadware et logiciel . De façon simple Corba permet ux applications dee communiquer avec d’autres sans se préocupper de la localisation des objets ou de qui les a modélisé. En 91 Corba 1.1 définit le langage d’interface et l’interface qui permet aux objets client/serveur de se connecter avec un ORB spécific. En décembre 94 Corba 2.0 est adopté qui définit comment les ORB fournit par différents vendeurs peuvent communiquer. Component Software is making this interoperability possible. Applications are changing; customers are less willing to accept huge, monolithic do-everything applications and are looking for smaller components which they can combine flexibly and dynamically to create tools focused on their particular business needs. And components will only work together if they have been designed and built on standard interfaces. Since interoperability must span the enterprise and even go beyond it to customers’ and suppliers’ systems, these interfaces must be independent of platform, operating system, programming language, even network protocol; anything less will create “islands of interoperability” insulated from each other by arbitrary technological barriers which keep us from realizing the benefits we’re entitled from our investment in computing. - 3 - 3 3

Plate-forme client/serveur orientée objets 1.2 CORBA? CORBA Common Object Request Broker Architecture : CORBA Plate-forme client/serveur orientée objets Un standard pour l’interopérabilité entre objets Support pour différents langages Support pour différentes plate-formes (interopérabilité) Communications au travers du réseau Des services (Distributed transactions, events, ... ) Guides et modèles de programmation CORBA (Common Object Request Broker Architecture) is a distributed object-oriented client/server platform. It includes: • an object-oriented Remote Procedure Call (RPC) mechanism • object services (such as the Naming or Trading Service) • • interoperability protocols • programming guidelines and patterns CORBA replaces ad-hoc special-purpose mechanisms (such as socket communication) with an open, standardized, scalable, and portable platform. Mission Promouvoir la technologie orientée objet dans les systèmes informatiques distribués Objectif Favoriser l’intéropérabilité et la portabilité d’applications réparties à travers : une terminologie unique dans le domaine de l’objet; un model de référence commun; des interfaces et des protocoles communes. 1.1 What is CORBA? Fundamentally, the Common Object Request Broker Architecture (CORBA) is a distributed client/server platform with an object-oriented spin. The idea is to provide an object-oriented programming model for distributed computing to programmers that is as close as possible to programming with ordinary local objects. The job of CORBA is take all the grunt work out of distributed programming, so you can focus on your business logic instead of having to worry about distribution infrastructure. CORBA consists of a large set of specifications that run to thousands of pages. However, the fundamental services it provides can be summarized as above. Apart from an RPC mechanism, CORBA offers a number of services that take care of common chores, provides language bindings for a number of popular programming languages, defines an interoperability protocol so implementations from different vendors can interoperate, and it defines a number of programming guidelines and patterns (often enshrined in specific APIs) that you use when you develop applications. CORBA enables you to get away from having to worry about infrastructure and ad-hoc and home-grown communication mechanism and replaces them with a an open and standardized platform that is both portable and scalable. « CORBA replaces ad-hoc special-purpose mechanisms (such as socket communication) with an open, standardized, scalable, and portable platform. » - 4 -

Historique Minimum Corba RealTime Corba Corba Component Model 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 2000 2002 CORBA 2.1 CORBA 3.0 Fondation de l’OMG Publication de l’OMA Publication CORBA 1.1 Publication CORBA 1.2 Mapping IDL/C++ Adoption CORBA 2.0 CORBA 2.3 Publication CORBA 1.0 Minimum Corba RealTime Corba Corba Component Model l’OMG établi en 89, avec 8 membres à l’origine, a aujourd’hui plus de 760 membres. Le but de l’OMG est la définition de l’OMA dont CORBA fait partie. Corba dans l’OMA implémente l’ORB.On se concentrera surtout sur CORBA accessoirement sur les services et facilities. décembre 90 : CORBA 1.0 puis début 91 1.1 qui définit IDLet l ’API pour communiquer avec l ’ORB. Dans toutes les versions 1. x on ne disait pas comment les ORBs pouvaient communiquer entre eux. Fevrier 92 CORBA 1.1 = première version largement publiée des spécifications CORBA. interface du BOA et de la gestion mémoire Décembre 93 : on élimine plusieurs ambiguïtés surtout en ce qui concerne la gestion mémoire et les comparaisons de référence d’objets : Août 96 : Corba 2.0 : DSI, extension de IR, GIOP, IIOP¨, …. Transactions services …travail avec OLE2/COM Corba 2.0 introduit un protocole qui permet la communication entre ORB définit par des vendeurs différents. IIOP (EyeOP prononcé) nécessaire pour que les ORB soient considérés conformes à la 2.0. Août 97 : CORBA 2.1 : ajout de caractéristiques liées à la sécurité (IIOP secure), ajout de 2 langages cibles Ada et Cobol, extensions des types IDL, Février 98 : Corba 2.2 : POA, IDL/JAVA spec. Fin septembre : IDL JAVA Language mapping, … Relase Commercial en 99 : - 5 - 6 6

Object Management Group (OMG) I.3. OMG Object Management Group (OMG) consortium international créé en 1989 but non lucratif regroupement de plus de 460 organismes constructeurs (SUN, HP, DEC, IBM, ...) environnements systèmes (Microsoft, OSF, Novell, ...) outils et langages (Iona, Object Design, Borland, ...) produits et BD (Lotus, Oracle, Informix, O2, ...) industriels (Boeing, Alcatel, Thomson, ...) institutions et universités (INRIA, NASA, LIFL, W3C) http://www.omg.org The World’s Best Standardization Process « In addition to its technologies, OMG has the world’s best standardization process. Executing our process, building consensus as they converge on technical details, OMG members produce each new specification in nine to seventeen months. Proven in the marketplace with the standardization of CORBA, the CORBAservices, Domain Facilities, UML, the MOF, and OMG’s other modeling standards, the process is one of our group’s major assets. » Au début des années 80, les technologies objets prennet une place de plus en plus importante dans la réalisation des projets informatiques de grandes sociétés comme Data General Corportaion, Hewlett-Packard ou Sun MicroSystems, les ingénieurs de ces sociétés se réunissent pour échanger idées et expériences et donneront naissance à l ’OMG. En 89, le consortium fut créé et de nouvelles sociétés se joignirent HyperDesk et IONA technologie. Des gens de tous horizons : fournisseurs de matériels (SUN, HP, DEC ou IBM) de grands utilisateurs Boeing, Motorola, Alcatel Aujourd ’hui on y trouve aussi des producteurs de logiciels Netscape, Iona tech, Visigenic,… des intituts et universités NASA, INRIA, LIFL L ’objectif est la définition de standard pour l ’intégration d ’appli distribuées et hétérogènes fondées Les trois concepts clefs suivants : la réutilisation des composants, l ’interopérabilité et la portabilité. l ’élément clé de la vision de l ’OMG c ’est CORBA (Common Object Request Architecture) : un middleware orienté Objet. Objectif: faire émerger des standards pour l’intégration d’applications distribuées hétérogènes et la réutilisation de composants logiciels Ils ne produisent pas de logiciels. sa force c ’est la présence de la plupart des compagnies intéressées par les développement OO Basée aux Etats Unis avec des représentations au Royaume Uni, au Japon en Australie et en Allemagne. - 6 - 4 4

Organisation et procédures I.3. OMG Organisation et procédures Comité technique détermine la direction de l’architecture et des normes; émet des RFI (Request For Information) pour vérifier la disponibilité des technologies; émet des RFP (Request For Proposal) pour obtenir des propositions de spécifications; évalue les propositions et propose une sélection; fait des recommandations au comité directeur sur les choix des technologies. Comité directeur prend les décisions finales pour l’adoption des spécifications. Le processus de standardisation de l ’OMG repose sur des appels à propositions. l ’OMG définit alors les problème qu ’elle désire résoudre et les membres fournissent des propositions basées sur des technologies déjà commercialisées. Les soumissions sont discutées jusqu ’à l ’obtention d ’une solution unique. Ca va de plus en plus vite 8 semaines ???? The OMG technology adoption process is based on government-like Request for Proposal cycles: Since adopted technology must be based on commercially-available software, an RFI is issued to establish what technology will shortly be commercially available, and what requirements OMG should and could put on specifications. Then a specific RFP (with a set of requirements) is sent out; responses comprise both a specification for perusal by the TC, and a set of terms and conditions of license, used by the Business Committee to determine if the technology will be commercially available. After parallel evaluation and recommendation processes, the OMG Board of Directors makes a final decision. The OMG provides a “level playing ground” for members. The smallest members (such as APM, a Cambridge, UK-based research consortium) have a vote equal to the largest members (such as IBM, a huge conglomerate based in the US). - 7 - 7 7

OMG en résumé OMA : pour l ’architecture logicielle I.3. OMG OMG en résumé L ’OMG prône l ’utilisation d ’une approche basée sur les technologies « objet » (devenu « modèle ») pour offrir une vue unique d ’un système distribué et hétérogène OMA : pour l ’architecture logicielle OMA = Object Managment Architecture  MDA (Model Driven Architecture) CORBA : pour le  « middleware » technique CORBA = Common Object Request Broker Architecture UML pour la modélisation UML = Unified Modeling language MOF pour la méta-modélisation MOF = Meta-Object Facility - 8 -

Le modèle client/serveur orienté objet (1) I.4. Client/serveur Le modèle client/serveur orienté objet (1) Application Cliente ORB Application Serveur Interface d’objet Objet Code d’implantation Référence d’objet Requête Objet Corba Activation Servant ORB: Object Request Broker : Bus à Objets répartis - 9 -

Client/Serveur (2) Rôle du client : I.4. Client/serveur Client/Serveur (2) Rôle du client : invoquer des services par envoie de requête accès à « l’objet » destinataire via une référence accès à l ’implantation via une interface Fundamentally, client/server computing is about different and distinct computational entities (tasks, threads, processes, computers, systems) that cooperate to get some work done. The entities are servers (which are passive and offer service), and clients (which are active and obtain service). The same entity can act as both a client and a server at different times or even simultaneously. A very simple example of a client/server system is the UNIX print spooler. The lpsched (or lpd) process is a server that runs permanently and waits for instructions from clients to print something; the lp (or lpr) command is a client that contacts the server with a print request. Even though the communication between the two is very simple, the print spooler exhibits all the fundamental characteristics of a client/server system. Adding object-oriented features to client/server computing means to transparently support the fundamental principles of object orientation: the separation of interfaces from implementations, inheritance, and polymorphism. These features mean that you get object-orientation that "extends across the wire", which means that you can access a remote object much as if it were local. (This is in sharp contrast to client/server platforms such as DCE, which has no real notion of objects or polymorphism and makes it very hard to naturally extend an OO programming model to distributed systems.) - 10 -

I.4. Client/serveur Client/Serveur (3) L ’infrastructure de distribution reçoit une requête pour « un objet » destinataire Localisation du serveur actif ou non Activation éventuelle du serveur Rôle du serveur : Activation par le serveur du servant concerné Le serveur détermine et exécute la méthode spécifiée par la requête et passe les résultats éventuels à l infrastructure qui les ramènent vers le client Fin de l ’activité du serveur Arrêt complet du serveur qui en informe alors l ’infrastructure. - 11 -

Définitions (1/3) Client fournissent des services. I.4. Client/serveur Définitions (1/3) Client Entité capable d’émettre des requêtes vers des objets qui fournissent des services. Le client manipule des références vers des objets distants. Référence Objet Objet manipulé par le client pour invoquer des services sur un objet distant : objet implémentation. Terme usité : proxy Un proxy est un représentant local au client d’un objet distant. L’application cliente est un prgme qui invoque à l’exécution, des traitements sur des objets à travers le bus CORBA. Ces applications sont écrites avec des lges classiques de programmation. la référence de l’objet est une structure de données désignant l’objet CORBA dans l ’ORB. Elle est contenue dans l’espace mémoire de l’application cliente et permet à celle-ci de dialoguer avec l’objet distant (le serveur). Cette structure contient l’information nécessaire au bus Corba pour localiser l’objet. Cela peut être un simple pointeur si l’application cliente et l’application serveur sont dans le même espace mémoire. Dans le cas d’un objet situé sur une autre machine, la référence contient alors des info indiquant, par ex., l’adresse réseau de la machine distante. Dans CORBA IIOP on parle de Interoperable Objet référence IOR. - 12 - 10 10

Définitions (2/3) Requête I.4. Client/serveur Définitions (2/3) Requête Emise par un client pour demander l’exécution d’une opération sur un objet cible. La requête contient l’opération à exécuter, l’objet cible et les paramètres éventuels. Interface Description d’un ensemble d’opérations disponibles sur un objet. Spécification des interfaces en IDL. Opération Entité identifiable caractérisée par une signature décrivant les paramètres de la requête et les valeurs de retour. La requête est le mécanisme d’invocation d’une opération sur un objet. L’application cliente peut envoyer des requêtes à destination des objets par l’intermédiaire de la référence et de l’interface de celui-ci. Lorsqu’une requête est émise elle contient la ref de l’objet destinataire, le nom de l’opération et l’ensemble des valeurs des paramètres en entrée. La requête est ensuite transportée par le bus Corba à destination de l’objet. En retour, si l’opération s’est déroulée correctement la requête contient le résultat produit par celle_ci et les valeurs des paramètres en sortie. Dans le cas, où il n’y a pas de résultat attendu la requête en retour contient juste une information indiquent la fin de l’exécution de l’opération. En cas de problème elle contient l’info décrivant l’exception déclenchée par l’opération invoquée. - 13 -

Définitions (3/3) Serveur I.4. Client/serveur Définitions (3/3) Serveur application qui crée des objets CORBA et rend les services fournis par ces objets accessibles à d’autres applications. Objet implémentation Objet situé sur le serveur qui implémente le code des méthodes des opérations définies en IDL. L’implantation de l’objet est une entité codant à un instant donné un objet CORBA. Cette entité stocke l’état de l’objet CORBA et fournit une réalisation pour chaque opération de l’objet. Cela peut-être une structure de donnée C ou ine instance d’une classe d’un LAO comme C++, Java.. Il peut aussi être un objet d’une base de donnée. Un objet peut être à la fois serveur et client. - 14 -

ORB (2/2) Composant central du standard CORBA qui gère : I.5. OMA ORB ORB (2/2) Composant central du standard CORBA qui gère : la localisation d’objet la désignation des objets l’empaquetage des paramètres (marshalling) le dépaquetage des paramètres (unmarshalling) l’invocation des méthodes la gestion des exceptions l ’activation automatique et transparente des objets De plus, il fournit des caractéristiques telles que : la liaison avec « tous » les langages de programmation un système auto-descriptif l ’interopérabilité entre les bus Location transparency The client does not know or care whether the target object is local to its own address space, is implemented in a different process on the same machine, or is implemented in a process on a different machine. Server processes are not obliged to remain on the same machine forever; they can be moved around from machine to machine without clients becoming aware of it (with some constraints, which we discuss in Unit 22). • Server transparency adire dans la transparence The client does not need to know which server implements which objects. La liaison avec les langages de programmation : assurés par des transformations frd IDL en construction directement exploitables via un précompilateur IDL. La transparence des invocations: le choix du moyen de transport en fonction de la localisation des objets qui est alors transparente même processus, différents process même machine, ou … invocations d ’opérations statiques et dynamiques : statique la + utilisée elle permet aux programmeurs d ’écrire les invocations sur les objets en utilisant les souches de communication produites par un précompilateur IDL. (typage est vérifié dans la phase de compilation.) dynamique utilise les interfaces des objets durant l exécution grâce à un référentiel des interfaces. à partir des info extraites , un pgme peut construire dynamiquement les invocations à destination des objets. Les opérations invoquées ne sont connues qu ’à l  ’exécution donc mécanisme plus souple mais aussi plus coûteux en temps d ’exécution. Un système auto-descriptif : Le bus contient des métaDonnées décrivant les interfaces des objets. Celles-ci sont stockées dans le référentiel des interfaces. Utilisées entre autres par des outils tels aue les générateurs de code à la volée, ateliers de G.L. ou navigateurs d ’interfaces. Activation automatique des objets : les objets sont en mémoire uniquement s ’ils sont utilisés par une application cliente. communication entre différents bus: pas de technologie imposée pour l ’implantation du bus. cependant des règles et protocoles sont définis pour permettre le dialogue entre différentes implantations. soit par des conversion de requêtes entre bus, soit par l ’usage de protocole commun. 2 familles : 1) Protocoles à usage général instancié à partir du protocol générique (General Inter-ORB Protocol GIOP) et 2) celle dédiée spécifiquement à des environnements distribués (Environment Specific In.. ESIOP) . IIOP (Internet ..) est l ’instanciation de GIOP sur la couche de transport TCP/IP de l ’internet. - 15 -

Bus Corba : fonctions ... Client serveur ORB I.5. OMA ORB Référence -> faire(param1,param2,...) Return Unmarshaling Unmarshaling faire(param1,param2,...) Return ORB Marshaling 010010010110110101111 Marshaling 10010110110 Facilite la communication entre objets en particulier il permet de localiser un objet seulement à partir d’une référence. 1. Localisation de l ’objet implémentation correspondant à la référence (serveur) . 2. On vérifie que le serveur est prêt 3. on transforme les paramètres de la requête alors du serveur correspond. C’est aussi le marshalling CORBA c’est le standard qui implémente les capacités de l’ORB. on-the-wire format spécifie le format dans lequel les données sont transmises à travers le réseau pour être transformées. Ce mécanisme de conversion est transparent à l ’utilisateur. Cette approche permet une indépendance vis à vis des plateforme. réseau - 16 - 11 11

ORB : Liaison avec « tous » les langages de programmation I.5. OMA ORB ORB : Liaison avec « tous » les langages de programmation C++ Java Smalltalk Ada Souche Souche Souche Souche Bus Corba Souche = STUB ou squelette Facilite la communication entre objets en particulier il permet de localiser un objet seulement à partir d’une référence. C’est aussi le marshalling CORBA c’est le standard qui implémente les capacités de l’ORB. - 17 - 11 11

Object Management Architecture OMA Object Management Architecture - 18 -

Object Management Architecture I.5. OMA Object Management Architecture Description d’une architecture de Gestion d’Objets classifiant les objets en fonction de leurs rôles et définissant les bases des futures spécifications incluant : une prise en compte des problèmes d’intégration dans des environnements distribués; un modèle d’objets abstrait; l’architecture du modèle de référence; InterOpérabilité entre ORBs un glossaire des termes utilisés l ’OMG définit aussi une vision globale de la construction d ’applications réparties : l ’Object Management Architecture guide OMAG dite aussi OMA. Objectif classifier les différents objets aui interviennent dans une application en fonction de leur rôle. en 90, l’OMG publie le guide de l’OMA, révisée en 92, les détails des facilities sont ajoutés en 95. C’est avant tout une architecture orientée Objet incluant des traits tels que l’héritage d ’interface et le polymorphisme. L ’objectif était de se baser sur l ’objet mais il fallait pallier les divergences entre concepts utilisés. Cela a donné lieu à la définition d ’un modèle de référence : Objet Management Architecture Guide (concept objets et une architecture globale d ’intégration des services orientés objet) Utiliser des services standardisés à la conception, l’implantation et l’exécution. - 19 - 8 8

Concepts (1/2) s i t objet m u p b l objet sur client I.5. OMA Modèle objet Concepts (1/2) Vue d’un objet dans une application monolithique Vue d’un objet dans une application d'objets distribués s t u b s q e l t invocation distante i m p l objet Un Stub c’est un petit morceau de code qui permet à un client d’accéder à un composant serveur. Cette partie de code est compilé avec la partie cliente de l’application. Les squelettes sont des morceaux de code du coté serveur que vous chargé quand vous implémentez un serveur. Stubs et squelette sont générés par le compilateur IDL. objet sur client Proxy objet sur serveur Servant Legende impl = objet implementation - 20 - 17

Concepts (2/2) I.5. OMA client pur client serveur serveur pur Modèle objet Concepts (2/2) client pur client serveur serveur pur objet client objet serveur invocation distante obj1 Impl c- obj1 s objet serveur objet serveur obj3 Impl s obj2 Impl s invocation distante invocation distante objet client c- obj2 objet client c- obj3 Traditionnellement un client est un composant qui consomme des services fournis par un ou plusieurs serveurs. Le serveur est lui un composant ou des composants qui fournissent des services à d’autres composants. Si un composant créée des objets et permet à d’autres composants d’avoir des références sur ces objets ce composant agit comme un serveur pour cet objet. Application 1 Application 2 Application 3 Legende : c-obji : objet client obji obji Impl : objet implementation obji s : squelette - 21 - 18

Architecture du modèle de référence I.5. OMA Architecture du modèle de référence Objets applicatifs Spécifiques Finance Télécom Santé Interfaces de domaine Workflow DataWare IHM Administration Utilitaires communs CORBA Bus d’objets répartis (O.R.B.) Licences Transactions Persistance Propriétés Changements Events Nommage Vendeur Sécurité Relations Collections Temps Externalisation Interrogations Cycle de vie Concurrence Services objet communs (CORBA Services) Orienté Système : ORB et services Objets ; Orienté application : applicatioon object et Common Facilities Pour favoriser l’intégration et l’interopérabilité d'applications réparties hétérogènes, l’OMG propose un guide décrivant une architecture de gestion des objets appelé l’Objet Management Architecture Guide. Cette archi est globale car elle vise à prendre en compte toutes les fonctionnalités nécessaires à la construction d’appli dans un environnement ouvert et distribué aussi bien au niveau des composantes techniques et/ou système (transactions, persistance) qu ’au niveau des composantes proches des applications comme l ’interface utilisateur ou les documents composites. De plus la modularité de ces composantes permet de ne construire une application qu ’en choisissant les services strictement nécessaires. Cette architecture structure ces fonct. en 4 grandes catégories de composantes : Le bus d ’objets répartis (ORB object Request Broker) :assure le transport des requête et masque tous les pbmes d hétérogénéité : il permet aux objets de communiquer de façon transparente. Dans la 2.0 l ’interopérabilité est étendue aux bus…(clef de voûte) Les services objet Commun :spécifiés par des IDL, abstractions aux fonctions système de base telles que nommage, persistance, cycle de vie, transactions, sécurité (16 services de base ont été spécifié ….). Cette base permet d ’écrire des appli indépendantes des mécanismes sous-jacent du système et donc la portabilité de ces applis. annuaire (vendeur et Nommage), cycle de vie, relations, events, transactions... Utilitaires communs ouCorba facilities : canevas de composants logiciels(frameworks) : prise en charge de fonctionnalités communes à beaucoup d ’applications telles que interface utilisateur, gestion de l ’info, administration du système, gestion des tâches Interfaces de domaine : modélisent des domaines d ’activités (santé(dossier médicale), finance(monnaie électronique), télécom, échanges commerciaux : aussi dits objets de métier. Idée: permettre l ’interopérabilité entre des systèmes d ’informations d ’entreprises d ’un même métier : Business Object Frameworks BOFs objets applicatifs : objets de métiers ?? développés spécifiquement pour une application. Très spécifiques, ils ne sont pas standardisés et sont simplement décrits par une ID, mais ils peuvent le devenir... - 22 - 11 11

Processus de développement - 23 -

3- Le langage IDL Le contrat IDL Un « esperanto » pour les objets Client d ’objets Fournisseur d ’objets Stub IDL Bus CORBA Squelette IDL Après ce tour d ’horizon de l ’env. Corba, interessons nous à présent au langage de définition d ’interface définit par l ’OMG, OMG IDL Une interface OMG IDL correspond à l ’abtraction d ’un type d ’objet, API que l'ont veut rendre publique elle contient donc les opérations exportées et utilisées par les autres objets mais pas forcément toutes les méthodes implantés par la classe d'objet. Java d ’un côté, C++ de l ’autre. Ce contrat isole le client des détails d ’implantation des objets I;E; de l ’ens. des logiciels et du matériel choisi pour leur implantation. Le fournisseur peut lui implanter plusieurs versions des objets en fonction de la qualité de service demandée. Il permet également l ’indépendance vis à vis du bus. Objets Corba - 24 - 17 17

Étapes de mise en oeuvre Spécification interface IDL Compilation interface IDL Implantation des objets Corba Implantation du serveur Implantation du client Enregistrement du serveur Enregistrement du serveur peut se faire aupres d'un service de nommage Côté client Côté serveur Utilisation du service Nommage - 25 -

Spécification interface IDL (1/2) 1- Exemple introductif Spécification interface IDL (1/2) Un objet grid est un tableau contenant des valeurs. Les valeurs sont accessibles grâce aux opérateurs get et set qui peuvent être invoqués à distance. objets grid Appel de get et set sur l'objet grid distant Processus client Processus serveur - 26 -

Spécification interface IDL (2/2) 1- Exemple introductif Spécification interface IDL (2/2) interface Grid { readonly attribute short height; readonly attribute short width; void set (in short n, in short m, in long value); long get(in short n, in short m); void copyIn(inout Grid g); }; - 27 -

Interface Definition Language 3. IDL Description Le langage IDL Interface Definition Language langage de spécification d’interfaces, supportant l’héritage multiple; indépendant de tout langage de programmation ou compilateur (langage pivot entre applications); langage utilisé pour générer les stubs, les squelettes et pour définir les interfaces du Référentiel d’interface; la correspondance IDL-langage de programmation est fournie pour les langages C, C++, Java, Smalltalk, Ada, Cobol. Après ce tour d ’horizon de l ’env. Corba, interessons nous à présent au langage de définition d ’interface définit par l ’OMG, OMG IDL Langage de description La norme internationale ODP à adopté IDL comme standard pour la description de ses propres objets. Langage indépendant d ’un langage. Mais quand même très proche de C++! interface (avec héritage multiple sans surcharge) Sa gammaire est relativement simple et décrite en moins de 36 pages dans la norme Corba 2.0. - 28 - 17 17

Exemple 3. IDL interface attribut opérations exception opérations Description Exemple interface account { readonly attribute float balance; attribute string description; void credit (in float f); void debit (in float f); }; interface currentAccount : account { readonly attribute float overdraftLimit; interface bank { exception reject {string reason;}; account newAccount (in string name) raises (reject); currentAccount newCurrentAccount (in string name, in float limit) void deleteAccount (in account a); }; interface attribut opérations exception 3 types d’objets sont ici décrit Account, …. Chacun définit des opérations Overdraft : decouvert opérations - 29 - 19 19

3. IDL Description Eléments IDL Une spécification IDL définit un ou plusieurs types, constantes, exceptions, interfaces, modules,... pragma constantes types de base au format binaire normalisé nouveaux types (typedef, enum, struct, union, array, sequence) exceptions types de méta-données (TypeCode, any) pragma: fixer les identifiants. Les pragmas IDL sont des directives permettant au précompilateur IDL de générer et créer des identifiant globaux (Utile pour le référentiel des interfaces) La norme définit les 3 pragmas : prefix : utilisé dans la génération des identifiants le + utilisé (utilisation du nom du domaine Internet. version :permet d ’associer un numéro de version à un identifiant IDL ID : fixer précisément l ’identifiant associé à une def IDL. #pragma prefix « omg.org » module ServiceDate { IDL:omg.org/ServiceDate typedef unsigned short Mois; #pragma version Mois 1.2; IDL:omg.org/ServiceDate/Mois:1.2 typedef unsigned short Annee; #pragma ID Annee « IDL:monde/Annee:2.3 » IDL:monde/Annee:2.3  constantes : nom symbolique à des valeurs particulières : const Ident = expression types de base au format binaire normalisé : élémentaires : entiers, flottants, booleans, caractères, chaînes, types composés composés : énumérations, structures, union, tableaux, séquences des types dynamiques auto-déscriptifs (TypeCode et any). ??? nouveaux types permet de créer un nouveau type de donnée. (typedef (aussi dit alias) , enum, struct, union, array, sequence) par exemple typedef sequence<Positif> Des entiersPositifs; typedef unsigned long EntierPositif; que l ’on retrouve dans intreface Premier plus clair de manipuler des jours qu ’un entier de 16bits exception : chaque exception définir un type de données structuré constitué d ’un ens. de champs typé types de méta-données (TypeCode, any) cf plus loin - 30 - 18 18

3. IDL Description Eléments IDL Un module permet de limiter la validité des identificateurs Interface : ensemble d’opérations et de types =>classe C++ Syntaxe : Interface | [<héritage>] { <interface Body>}; opération (synchrone ou asynchrone sans résultat) attribut (possibilité de lecture seule) Surcharge Interdite Réutilisation de spécifications existantes (#include) - 31 - 18 18

Exemple 3. IDL module définitions de type interface opérations Description Exemple module unService { typedef unsigned long EntierPositif; typedef sequence<Positif> desEntiersPositifs; interface Premier { boolean est_premier ( in EntierPositif nombre); desEntiersPositifs nombres_premiers (in EntierPositif nombre); }; module monApplication { interface MonService { unService::EntierPositif prochainPremier(..); module définitions de type interface opérations Nous noterons une syntaxe très proche de C++, avec cependant en plus le mode passage des paramètres et la liste des exceptions d’une opération. Le concept d ’interface est l ’équivalent des interface Java, ou des classes abstraites C++. La sémantique des typedef n ’est pas très claire : sous-type ou alias (en général alias). En général utilisé dans un but de lisibilité des contrats IDL. - 32 -

Exemple 3. IDL Description Description d’un service pour manipuler des dates. La notion de modules permet de regrouper des définitions communes à un ou plusieurs services. Ici on trouve des définitions de types et 3 définitions d’interfaces. Jour et années sont représentés par des entiers positifs. On remarque la structure date. L’attribut année8courante permet de consulter et de modifier la date courante. - 33 - 19 19

Attribut IDL Définition d’attribut interface account { Equivaut à : Description Attribut IDL Définition d’attribut interface account { readonly attribute float balance; attribute string description; ... }; Equivaut à : float get_balance(); string get_description(); void set_description(in string s); Attention la notion d’attributs IDL ne doit pas être confondue avec les attributs d’instances. Ce n’est qu’une construction syntaxique pour exprimer simplement une paire d’opérations d’accès à une propriété d’un objet. Il faut ensuite implanter ces opérations.Celles-ci peuvent tres bien ne pas utiliser d ’attribut température consulte un capteur externe, ... Ces attributs sont tjs publiques comme tout ce qui est dans les IDLs. - 34 - 22 22

Operations (1/2) Paramètres nommés void op1 (in long input, 3. IDL Description Operations (1/2) <uneOpération> ::= <modeInvocation> <typeRetour> <identificateur> ‘ (‘ <paramètres> ‘ ) ’ <clausesExceptions><clausesContextes> Paramètres nommés et associés à un mode Opérations bloquantes par défaut void op1 (in long input, out long output, inout long both); interface account; interface bank { account newAccount (in string name); void deleteAccount (in account old); }; Client uneBanque L’identificateur d’une opération est unique. Liste des paramètres in : transport du client vers l’objet out : transport en retour de l’objet vers le client in out : dans un sens puis dans l’autre. Le type de retour est void quand rien n’est retourné. mode d ’invocation : par défaut synchrone I.E. que le client attend la fin d ’exécution de l ’opération pour reprendre la suite de son activité. exceptions : indique optionnellement les exceptions pouvant être déclenchées par cette opération. contextes : variables d ’environnement du client vers l ’objet. Tres peu utilisée, car on préfère passer des informations telles que le contexte d ’exécution du client via des paramètres. void afficher () context (« DISPLAY »); demande l ’adresse de l ’ecran graphique ou DISPLAY sous X-Windows. IMPORTANCE DE préciser les types de données et leur format binaire pour une gestion automatique de l'hétérogénéité. newAccount calcul retours - 35 - 23 23

Pourquoi différents modes de passage de paramètres ? in : Données fournies par le client out : Données retournées par l ’objet inout : Données clientes modifiées par l ’objet Répartition Passage par copie - 36 -

Opérations (2/2) oneway void notify (in string message); 3. IDL Description Opérations (2/2) oneway void notify (in string message); Opération non bloquante Pas de paramètre de type out, inout ou d’exceptions Valeur de retour : void Pas d ’exceptions déclenchées. L’appelant ne sait alors pas si l’opération a été effectivement exécutée 0 ou n fois, + spécifications d ’un service pour les communications asynchrones. Tous les paramètres en in et type de retour void. Corba assure seulement qu’elle sera exécuté avec the best effort et que si l’opération arrive elle ne sera exécutée qu’une seule fois. La plupart des environnements CORBA assure la délivrance et l ’exécution de l ’opération. elle ne peut déclencher aucune exception aussi est-il difficile de déterminer si l ’exécution a réussi ou non. Client uneBanque notify(«ok ») méthode finie - 37 - 24 24

Exceptions Gestion explicite de la part du client 3. IDL Description Exceptions exception reject {string reason;}; account newAccount (in string name) raises (reject); exception DateErronnee { String raison; }; CORBA::Exception CORBA::UserException CORBA::SystemException Des exceptions CORBA standardisées UNKNOWN NO_PERMISSION BAD_PARAM NO_IMPLEMENT COM_FAILURE OBJECT_NOT_EXIST INV_OBJREF ………. Similaire à la définition d ’une structure elles peuvent avoir plusieurs champs de valeurs typées. Ce qui permet d ’informer le client sur le contexte et les raisons qui ont provoqué l ’exception. Des exception Systeme elles ne doivent pas être précisées parmis les exceptions qui peuvent être déclenchées par une opération: leur déclaration est implicite. cf. en 14 jours P. 56-57 en faire la photocopie?? ou P.97 UNKNOWN = le bus ne la connaît pas. BAD8PARAM: un paramètre invalide a été transmis à une primitive du bus. COMM_FAILURE : problème de communication sur le réseau NO8PERMISSION : non autorisation d ’invoquer une opération (lié au contrôle d ’accès du serveur Sécurité) NO_IMPLEMENT : l ’implantation d ’une opération est non disponible OBJECT… invocation sur un objet déjà détruit les ref sur cet objet doivent être détruites. INV_OBJE.. une référence d ’objet est invalide Gestion explicite de la part du client - 38 -

Définitions circulaires 3. IDL Description Définitions circulaires module Circulaire { interface B; interface A { void utiliséB(in B unB); } interface B { void utiliséA(in A unA); Les attributs de A sont présents en un seul exemplaire dans D. Aujourd’hui si un objet est l’implanattion de plusieurs interface alors il doit y avoir une interface les combinant qui a été défini. Mais cela devrait changer comme en Java. - 39 - 25 25

Héritage multiple A B C D 3. IDL interface A { ... } Description Héritage multiple interface A { ... } interface B : A { ... } interface C : A { ... } interface D : B, C { ...} A B C Les attributs de A sont présents en un seul exemplaire dans D. héritage seulement de spécifications mais deux interface ne peuvent pas définir un même nom d’opération. Ce problème doit être résolu en éléminant les conflist de nom (A REVOIR) Aujourd’hui si un objet est l’implanattion de plusieurs interface alors il doit y avoir une interface les combinant qui a été défini (OMG-MI) Mais cela devrait changer comme en Java ou en COM. D - 40 - 25 25

Types de base et autres types 3. IDL Description Types de base et autres types Types de base short long unsigned short unsigned long float double char boolean octet …... Types construits struct union enum Types génériques array sequence string Langage fortement typé. Type scalaire 15 : void, entier, réel, chaine, octet, boolean, caractère types complexes : énumération, structure, union, tableau, séquence. Type dynamiques typeCode : n ’importe quel type IDL.et any : n ’importe quelle valeur IDL en conservant son typeCode. Ces méta-types permettent de de spécifier des contrats IDL indépendant des types de données manipulées eg une pile d ’any stocke n ’importe quelle valeur. et bien sûr des types objets : ceux de l ’utilisateur Notons l ’absence de pointeurs présents seulement dans certains langages Un caractère par ex. dans la définition de constante est noté ‘ A ’, ‘ \n ’ ’ ¨ ’ « Une Chaîne de caractère » Union permet d’exprimer une structure à discriminant. On l’a gardé par souci de compatibilité mais les pgmeurs lui préfèrent le type Any. Définition de tableaux de taille fixe : nombre de dimensions et taille sont fixés à la déclaration typedef Date[10] TableauDates; const unsigned short Taille = 100; typedef float [Taille] [Taille]MatriceCarreDeFlottants; Les pgmmeurs préfèrent l ’utilisation de tableaux dynamiques ou séquence IDL. séquence : le nombre d ’éléments est fixé à l ’exécution, ce qui permet le transport d ’ens non borné de valeurs. On peut fixer une taille maximale.Toutes les valeurs d ’une séquence doivent être du même type (ou any ou un dérivé). sequence <Television> televisionInventory Ex. pour retourner les jours fériés, sans ce type on aurait du retourner un tableau de 366 éléments, ici l ’allocation se fera à l ’exécution. MétaTypes Types de données dynamiques et auto-descriptifs any TypeCode - 41 - 21 21

Type Any interface PileDeChaines { readonly attribut string sommet; 3. IDL Description Type Any interface PileDeChaines { readonly attribut string sommet; void poser(in string valeur); string retirer(); }; interface PileGénérique { readonly attribut Any sommet; readonly attribut TypeCode typeDesValeurs; void poser(in Any valeur); Any retirer(); }; MétaType de données : I.E. des types de données contenant une valeur et une info décrivant le type de celle-ci. TypeCode : permet de stocker la description de tout autre type IDL. Par ex. S ’il contient une structure, il en contiendra le nom et la liste de tous ses champs (leur nom et TypeCode associé). Any permet de stocker n ’importe quelle valeur IDL et son TypeCode associé. Utilisé dans tous les contextes où il est nécessaire de transporter des valeurs dont le type n ’est pas encore connu au moment des phases de conception IDL ou pour définir des opérations dont l ’un des paramètres est polymorphe. Ces types sont à la base des mécanismes dynamiques du bus CORBA. - 42 -

Exemple Compilation interface IDL vers Java 1- Exemple introductif Exemple Compilation interface IDL vers Java Grid.idl jidl … Grid.idl A écrire Compilateur IDL/Java Généré Répertoire grid Répertoire grid Répertoire grid Répertoire grid Client Serveur GridOperations.java _GridStub.java GridPOA.java Ya aussi GridOperations Si j’ai un module j’ai un repertoire. Sinon je crois que l’option package me donne un repertoire… Le code de l’implementation squelette c’est des appels aux fonctions de l’utilisateur… dont on encapsule la reponse dans la requete recu en parametre. On voit tres bien la lecture de la requete… l’execution… la recuperation du resultat ou de l’exception attendue… Le stub … on voit l’identifiant de l’IDL, la creation de la requete, le passage par in out etc… la transformation des parametres en Any, … l’invocation Helper lui définit les fonctions de manipulation de GRID en any, extraction d’un any, la creation du typeCode, … la conversion de type a partir d’une Stream…. In.read_object … x’est de la lecture d’IOR ????? La creation de Stub et son association a l’objet d’implementation … ca m’a l’air tes reflexif ici… et le narrow … _impl genere un exemple avec le suffixe _impl In order to implement this application in Java, the interface specified in IDL is translated to Java classes similar to the way the C++ code was created. The ORBACUS IDL-to-Java translator jidl is used like this: jidl --package hello Hello.idl This command results in several Java source files on which the actual implementation will be based. The generated files are Hello.java, HelloHelper.java, HelloHolder.java, HelloOperations.java, HelloPOA.java and _HelloStub.java, all generated in a directory with the name hello. I Grid.java Client.java Grid_Impl.java GridHelper.java Serveur.java GridHolder.java - 43 -

Les classes Stubs et Squelettes 1- Exemple introductif Les classes Stubs et Squelettes implantation du stub public class _GridStub ……. Grid envoie de requêtes invisible par le programmeur instanciée automatiquement par GridHelper (narrow) Utilise le DII pour assurer la portabilité du binaire implantation du squelette public abstract class GridPOA ………. GridOperations reçoit et décode des requêtes doit être héritée par l’implantation 1.Extends Org.omg.corba.portable.ObjectImpl 2.dynamicImplementation … marchalling D'autres approches par delegation TIE surtout si on un systeme proprietaire et que l'on ne veut pas en heriter... - 44 -

Implémentation du serveur (1) 1- Exemple introductif Implémentation du serveur (1) 1. Initialiser le bus CORBA obtenir l’objet ORB 2. Initialiser l’adaptateur d’objets obtenir le POA 3. Créer les implantations d’objets 4. Enregistrer les implantations par l’adaptateur 5. Diffuser leurs références afficher une chaîne codifiant l’IOR 6. Attendre des requêtes venant du bus 7. Destruction du Bus - 45 -

Implémentation du client 1- Exemple introductif Implémentation du client 1. Initialiser le bus (objet ORB) 2. Créer les souches des objets à utiliser 2.a. obtenir les références d’objet (IOR) 2.b. convertir vers les types nécessaires narrow contrôle le typage à travers le réseau 3. Réaliser les traitements Rem. : éviter l’opérateur bind (2.a + 2.b) spécifique à chaque produit donc non portable - 46 -

Objets CORBA A CORBA object is an object with an interface defined in CORBA IDL. CORBA objects have different representations in clients and servers. •A server implements a CORBA object in a concrete programming language, for example in C++ or Java. This is done by writing an implementation class for the CORBA object and by instantiating this class. The resulting implementation object is called a servant. •A client that wants to make use of an object implemented by a server creates an object that delegates all operation calls to the servant via the ORB. Such an object is called a proxy. When a client invokes a method on the local proxy object, the ORB packs the input parameters and sends them to the server, which in turn unpacks these parameters and invokes the actual method on the servant. Output parameters and return values, if any, follow the reverse path back to the client. From the client’s perspective, the proxy acts just like the remote object since it hides all the communication details within itself. A servant must somehow be connected to the ORB, so that the ORB can invoke a method on the servant when a request is received from a client. This connection is handled by the Portable Object Adapter (POA) The Portable Object Adapter in ORBACUS replaces the deprecated “Basic Object Adapter” (BOA). (The BOA was deprecated by the OMG because it had a number of seri-ous deficiencies and was under-specified.) The POA is a far more flexible and powerful object adapter than the BOA. The POA not only allows you to write code that is portable among ORBs from different vendors, it also provides a number of features that are essen-tial for building high-performance and scalable servers. - 47 -

Passage d ’un objet par référence ou par valeur Processus A Processus B Objet Processus A Processus B Objet invocation d ’une méthode invocation d ’une méthode copie d ’objet créée référence Objet serialized Object Processus A Processus B Processus A Processus B invocation d ’une méthode référence Objet Objet copie Objet Objet Si on a une série de message à envoyer à un objet on sera distant toujours ca a un coût…. Seul l ’état de la copie est modifié. résultat - 48 -

Le cycle de vie des objets Problème actuellement, 1 grille = 1 serveur pas de création/destruction d’objets à distance seulement invocation d’opérations Solution notion de fabrique d’objets exprimée en OMG-IDL C’est un canevas de conception : Design pattern voir aussi le service LifeCycle Autres usages de la fabrique : - gestion de droits, load-balancing, polymophisme, … - 49 -

L’implantation de la fabrique creerGrille Grille Grille Fabrique - 50 -

L’implantation de la fabrique Grille Grille Fabrique detruireGrille - 51 -

Interface IDL d ’une fabrique de Grilles module grilles { . . . interface Fabrique { Grid newGrid(in short width,in short height); }; }; Here is our Java implementation of the Product interface: 1 // Java 2 public class Product_impl extends ProductPOA 3 { 4 public void destroy() 5 { 6 byte[] id = _default_POA().servant_to_id(this); 7 _default_POA().deactivate_object(id); 8 } 9 } 2 Servant class Product_impl is defined as an implementation of the Product interface. 6,7 The destroy operation deactivates the servant with the POA. As long as no other refer-ences to the servant are held in the server, the object will be eligible for garbage collec-tion. Here’s our implementation of the factory: 2 public class Factory_impl extends FactoryPOA 4 public Product createProduct() 6 Product_impl result = new Product_impl(orb_); 7 org.omg.PortableServer.POA poa = ... // Get servant’s POA 8 byte[] id = ... // Assign an ID 9 poa.activate_object_with_id(id, result); 10 return result._this(orb_); 11 } 12 } 2 Servant class Factory_impl is defined as an implementation of the Factory interface. 4-11 The createProduct operation instantiates a new Product servant, activates it with the POA, and returns an object reference to the client. void destroyGrid (in Grid g); - 52 -

Scénario d ’obtention de la référence du service de nommage Client ou Serveur ORB resolve_initial_references ("NameService"); CosNaming:: NamingContext conversion ajout,retrait,lecture,... - 53 -

Notion de chemin d’accès - 54 -

Enregistrer un objet Opération pour publier un Objet en général, opération réalisée par le serveur Scénario Type 1. Créer un objet 2. Construire un chemin d ’accès (Name) 3. Appeler l ’opération « bind » ou « rebind » avec le chemin et la référence de l ’objet void bind (in Name n, in Object obj) raises (NotFound, CannotProceed, InvalidName, AlreadyBound); - 55 -

Retrouver un objet Opération réalisée par un client ou un serveur Scénario type : construire un chemin d ’accès (Name) appeler l ’opération « resolve » avec le chemin convertir la référence obtenue dans le bon type Object resolve (in Name n) raises (NotFound, CannotProceed, InvalidName) - 56 -

Une application d’administration de la fabrique Création d’une nouvelle grille et mise à disposition par le service Nommage 1. Initialiser le bus CORBA 2. Obtenir le service Nommage (NS) 3. Obtenir la fabrique depuis le NS 4. Créer un répertoire 5. Enregistrer le répertoire dans le NS - 57 -

What is ORBacus? http://www.ooc.com/ob/. ORBACUS is an Object Request Broker (ORB) that is compliant with the Common Object Request Broker Architecture (CORBA) specification (2.4 + features 3) • Full CORBA IDL support • C++ and Java language mappings • Simple configuration and bootstrapping • Portable Object Adapter • Objects by Value • Portable Interceptors • Single- and Multi-threaded • Active Connection Management • Fault Tolerant Extensions • Dynamic Invocation and Dynamic Skeleton Interface •Dynamic Any • Interface and Implementation Repository • Pluggable Protocols • IDL-to-HTML and IDL-RTF documentation tools • Includes Naming, Trading, Event, Notify, Property Services,balancing,… ORBacus ORBacus is a fully CORBA-compliant ORB that is distributed as source code. Lacking many of the qualities of service of Orbix E2A, ORBacus is not typically suited to the extremely demanding scalability requirements of enterprise applications. However, its smaller footprint makes it more easily embedded in ISV products. ORBacus is an ORB for CORBA enthusiasts, who enjoy the ability that source code access affords them to look under the hood and diagnose potential problems in their application or underlying infrastructure. ORBacus is available in two language versions: C++ and Java. ORBacus 4.1, the current version of ORBacus, is a fully CORBA 2.4 compliant ORB. It offers support for such advanced features as the Portable Object Adaptor (POA) and Objects by Value (OBV). ORBacus also supports some of the features in the upcoming CORBA 3 standard, including Portable Interceptors. Read what's new in 4.1. ORBacus has available the following CORBA Services: ORBacus Names is an implementation of the new Interoperable Naming Service specification, with support for URL-style references for simple and convenient application bootstrapping, and with a journaled database for high performance and data integrity ORBacus Events is a full implementation of the Event Service specification - including typed events - that reduces complexity in large-scale applications by decoupling event consumers and suppliers ORBacus Properties™ implements the Property Service specification and can be used co-located or stand-alone, providing a flexible way to dynamically extend objects at runtime ORBacus Times™ is an implementation of the Time Service specification ORBacus Trader is a searchable database of object metadata - with a journaled database to prevent data loss - that is compliant with the Trading Service specification ORBacus Notify is a high performance, C++ based implementation of the OMG Telecom Domain Task Force's Notification Service Specification, with support for persistent event channels, configurable QoS, event filtering, and structured events and run-time system management Who Is Using This Product ORBacus is in use in a variety of applications in end-user organizations and ISVs in the telecommunications (Incomit, Syndeo, Alcatel), e-commerce (Datalex, CommerceRoute, Resonate), financial (Crux Financial Engineering, System Programming and Network Computing), defense (U.S. Ballistic Missile Defense Organization), and petroleum (Schlumberger) industries. Benefits Source code access makes ORBacus highly portable Interoperable with Orbix E2A-based applications Directly supported by the ORBacus engineering organization, some of the world's best CORBA talent Features C++ and Java language mappings CORBA 2.4 compliant Simple configuration and bootstrapping Portable Interceptors Single- and Multi-threaded Active Connection Management Fault Tolerance Extensions Dynamic Invocation and Dynamic Skeleton Interface Dynamic Any Interface and Implementation Repository Pluggable Protocols IDL-to-HTML and IDL-RTF documentation tools Includes Naming, Event, Time and Property Services Objects by Value More info - click here Concurrency models describe the strategies an ORB employs for concurrent communication and request execution. There is no "one size fits all" approach with respect to concurrency models. Selecting the proper concurrency model for a particular application is essential to ensure correct behavior and to optimize performance. ORBacus supports a multitude of concurrency models, with two main categories: single-threaded and multi-threaded.  In contrast to many other ORBs, which support nested callbacks in multi-threaded mode only, the ORBacus architecture supports nested callbacks even in single threaded mode. Furthermore, it takes only a few initialization steps to integrate ORBacus with existing single-threaded event dispatchers such as X11 and Windows, and custom event dispatchers are also supported.  Multi-threading is essential for high-load, large-scale architectures. With multi-threading, you can fully exploit the power of your multi-processor hardware. ORBacus provides a fully thread-safe library and several request dispatch models: thread-per-client, thread-per-request, and thread pool.  Active Connection Management  ORBacus clients and servers can be configured so that idle connections are reclaimed automatically, saving important system resources such as threads, sockets, or memory. Using active connection management, you can design server applications that can support thousands of clients.  The Open Communications Interface  ORBacus applications are not restricted to using only IIOP. Using the Open Communications Interface (OCI), it's easy to "plug-in" new transport protocols, such as SSL, ATM, or even IP multicast. The OCI allows the construction of `light-weight' plug-ins, meaning that the ORB core handles most of the protocol logic. Based on the POA and Messaging Quality of Service (QoS) framework, you have flexible control over protocol selection and connection reuse strategies.  With the OCI, your application can gain access to protocol specific data. For example, if you are using an IIOP plug-in, you can determine the remote IP address and port of a caller or callee. Furthermore, OCI callbacks provide an interceptor-like facility at the transport level. Callbacks for incoming and outgoing connection establishment can be installed, as well as callbacks for connection closure. This can be used for security enforcement, or simple forms of distributed garbage collection.  The Portable Object Adapter  ORBacus 4 is based on the new Portable Object Adapter (POA). In contrast to the Basic Object Adapter (BOA), the POA allows you to write server code that is highly portable to other ORB products.  In addition to portability, the POA offers many other advantages. For example, you can have several POAs in one single application, with each POA being responsible for a set of objects with common characteristics (such as activation or persistence). You can also have several POA managers, with each of them controlling the flow of requests for a group of POAs.  Another advantage of the POA is its extreme scalability. Using servant managers and default servants, it's possible to design servers that can handle thousand or even millions of objects.  The Implementation Repository  Production environments commonly need the ability to start servers on demand, and the flexibility to migrate servers to different hosts without adversely affecting clients. The ORBacus 4 Implementation Repository (IMR) provides this functionality, along with an administrative application that simplifies configuration and maintenance using an intuitive graphical user interface.  Objects by Value  In ORBacus 4, objects are not restricted to being passed only by reference. Using "valuetypes", objects can also be passed by value. Valuetypes are similar to structs, but support operations, inheritance and arbitrary sharing semantics. The latter is especially important for defining complex data structures, such as lists, trees, or graphs.  Abstract interfaces provide an even higher degree of flexibility. An instance of an abstract interface can either be a regular object reference or a valuetype, as determined at runtime. This allows a mixture of local and remote objects having the same interface, and whose location is transparent to the client. Portable Interceptors  ORBacus 4 is the first ORB to implement the new Portable Interceptor specification. Interceptors provide a "hook" for adding code that is called upon each operation invocation, both on the server and the client side. This can be used to build CORBA services, such as an Object Transaction Service or a Security Service, or to build distributed debugging tools. For example, it's easy to write an interceptor that logs all operation invocations, including exceptions, return values, and parameters.  Fault Tolerance Extensions  CORBA object references consist of one or more so-called "profiles". Each profile designates a different protocol and/or a different server. If a request fails, ORBacus 4 transparently switches to the next profile, facilitating the development of redundant client/server applications. A simple `iormerge' tool is provided that merges several server references into one.  - 58 -

Conclusion CORBA : ça marche et c’est simple Choisir son langage d’implantation C++ : complexe et moins portable Java : portable et plus lent Choisir son bus 1 bus = 1 bibliothèque mixer les bus : c’est possible Expérimentez en TPs ! - 59 -