Vraiment pas dynamiques à cette conférence. Les BOF imposés n'ont pas eu lieu, sauf celui sur Modula 3 qui regroupait une dizaine de personnes en rond. Sinon, discussions informelles dans le hall du Marriott tard le soir. Elles portaient sur Java principalement, et c'est Doug Lea qui répondait aux questions, nombreuses, que les gens se posaient. C'est étonnant de voir que Java est très largement connu de nom, mais très peu en détails (en fait, la plupart des gens présents n'avaient même pas lu l'article d'introduction)
CORBA est bien là. Ce n'est plus du vaporware. Les implémentations ont atteint une fiabilité certaine, et certains speeches m'ont aidé à voir plus clair, et à poser quelques jalons sur les spec que j'avais lues sans trop les visualiser jusqu'à présent
Toujours là, et plus vivants que jamais. Le fait qu'un système soit MT n'est même plus considéré comme un atout majeur, c'est tout juste si l'auteur précisait entre deux transparents "ah j'oubliais, naturellement le système est multi-thread"
De moins en moins de toolkits fournissent l'asynchronisme. Alors que je prenais ça au début pour une défense (ou une explication) de cette lacune dans CORBA, il semble que tout le monde s'oriente de plus en plus franchement vers "synchronisme uniquement". L'asynchronisme s'obtient avec du synchronisme dans un thread séparé
... était le langage numéro deux de cette conf, derrière C++. Je ne sais pas trop quoi en déduire : il me semblait que c'était Smalltalk, mais on dirait que Modula 3 fait une percée remarquée (naturellement les présentations M3 étaient faites par des gens de Dec mais il y avait aussi des projets basés sur M3, comme par exemple l'Obliq de Cardelli)
Je n'ai pas fini de vous en reparler. Le concept n'est pas neuf, mais pour la première fois il est cristallisé et extrêmement bien synthétisé dans un bouquin écrit par quatre auteurs (surnommé le "gang of four"). L'un d'eux (John Vlissides) a fait un tutorial, cf. plus bas. Une chose est sûre : il n'y a pas un article technique qui ne mentionne pas ce livre dans sa bibliographie. Il faut absolument le lire, ou au moins le survoler pour avoir une idée de quoi il parle.
Je vous avais parlé de COM l'année dernière après avoir assisté à la conférence sur OLE 2 par la Chief Architect de Microsoft. Je ne m'étais pas trop arrêté sur COM parce qu'à l'époque, ce n'était rien de plus que la couche de base d'OLE (et de quelques autres services). Mais là le ton a complètement changé. COM est beeaucoup plus achevé et se pose comme concurrent direct de CORBA, et ce n'est pas sans raison, comme vous verrez dans les comptes-rendus le concernant (il y en a deux : le tutorial COM et le pot-pourri qui rassemblait les gars de COM et les gars de CORBA)
Un modèle à garder en vue, il fonctionne bien et fournit une implémentation très correcte de CORBA, ajouté en plus à leur mécanisme de compatibilité binaire C++ (ce n'est pas du pipo, cf. plus bas). SOM, et son successeur DSOM (D pour distributed) sont à la base d'OS/2 depuis le tout début
Attention gourou. Si son nom ne vous est pas familier, entrez-le dans votre bbdb, ce mec est impressionnant : programmeur expérimenté C++, très familier avec les méthodologies OO, auteur d'articles remarquables à la fois dans la forme (graphiques, benches, etc...) et dans le fond, et en plus il trouve le temps de faire des contrats avec l'industrie. J'avais regardé les premières versions de ACE (AKA Tcp_wrappers) et elles n'etaient pas très convaincantes. Mais c'était il y a deux ans, et maintenant il a créé un véritable framework qui fonctionne impeccablement (et est assez complexe aussi... on n'a rien sans rien). Voir plus bas.
J'ai rapporté quatre livres:
Chappell s'est présenté d'emblée comme quelqu'un qui vient du "monde ouvert" mais qui a été séduit par le côté obscur ("Just like you, I spent years of my life hating Microsoft. I was wrong. OLE is full of odd and cool stuff"). Il se dit avoir été très enthousiaste quand CORBA est apparu mais a rapidement perdu ses illusions devant la lenteur avec laquelle les progrès ont été faits. La mort dans l'âme, il s'est donc intéressé à la technologie Microsoft et là il a vraiment pris son pied.
Le gars a l'air honnête, ce n'est pas un Microsoft zealot, et le reste du tutorial a achevé de me convaincre sur la validité de ses arguments
OLE est une cible mobile. Il est construit au-dessus de COM (Common Object Model, ou aussi Component Object Model, c'est l'ancien nom).
A ce niveau, Chappell demande combien de personnes n'ont jamais utilisé Windows. Une personne lève le doigt sur une soixantaine
OLE 2.0 ne concerne pas seulement les documents composés (compound). C'est en fait la caractéristique la moins intéressante. Il n'y aura pas de OLE 3.0. En fait, le numéro de version n'est même plus prononcé. On dit "OLE" et tout le monde sait qu'il s'agit du 2.0.
COM existe aussi sur Mac. Il est prévu sur d'"autres" pas de précision plateformes pour 1Q96, mais sans date plus précise. Quel que soit le système cible, il devra supporter l'Object Broker de Microsoft.
OLE n'est pas une technologie de design, c'est une technologie logicielle. Il se compose de plusieurs parties :
Trois motivations à la base de l'effort COM/OLE :
1- il faut pouvoir distribuer des binaires
2- on doit pouvoir accéder aux composants par-dessus la barrière du langage de programmation
3- il doit être possible d'ajouter des composants au système, et que les anciens composants puissent les utiliser immédiatement sans recompilation
COM permet ces trois points, et il crée donc ce nouveau type de software qu'est le "Component Software" (VBX fait ça pour Visual Basic).
Compétition :
Petite aparté complètement en relation avec cette dernière phrase. J'ai lu le texte qui suit dans un minuscule entrefilet quelque part dans un magazine. Vu l'importance de ce que cela sous-entend, il me paraît nécessaire de le mentionner à ce niveau :
<< The OMG has voted to request proposals on linking CORBA and Microsoft's COM. Jeff Alger, Senior Product Manager in Microsoft's Enterprise developers group, says his company is helping the OMG with the process of getting a CORBA-COM gateway standard created, early mid-96. But some analysts doubt that Microsoft ultimately cares for interoperability. They point to the company's work with DEC to make portions of OLE available on UNIX machines, a move which would break OLE's current single-platform limitation and reduce the need for CORBA compatibility. >>
Pas très surprenant quand on y réfléchit deux minutes.
OLE/réseau ("Network OLE") utilise les DCE RPC, mais DCE n'est pas OO (cela dit, HP a développé un OODCE, et IBM veut mettre SOM sur DCE).
Question de l'assistance sur CORBA, à laquelle Chappell répond en disant qu'il ne faut pas parler de "CORBA" parce que les specs sont trop floues et trop sujettes à interprétation pour que la question soit suffisamment précise. Il faut parler d'une "implémentation spécifique de CORBA" pour que la question ait un sens (SOM, Orbix, etc...). Chappelle ajoute qu'il est optimiste quant à l'avenir de OLE/COM en dehors des mondes Window, NT, Mac (j'ai personnellement quelques doutes)
Chappell fait alors une remarque humoristique sur le fait qu'il faudrait inventer une nouvelle mesure de temps : l'année Microsoft. C'est avec ce genre de remarques, associé à sa connaissance certaine des deux mondes, qu'il a réussi à intéresser l'audience sans coup férir
Tous les objets COM supportent plusieurs interfaces, toutes dérivées de "IUnknown". Un client n'a pas besoin de connaître plus que les méthodes de l'objet cible, et comment les invoquer. Vu d'un client, un objet n'est rien d'autre qu'une interface.
COM définit deux choses :
Chaque interface est identifié par une IID, et chaque classe par une CLSID. Ces deux ID sont des GUID (global user id's), qui représentent une méthode de nommage unique à tout le système). L'interface de base (IUnknown, dont héritent toutes les interfaces) est très simple : elle s'occupe de produire des pointeurs (QueryInterface()) et de gérer le comptage de références (AddRef(), Release()).
Chaque objet COM est implémenté comme un serveur. Ils peuvent être de trois types :
Par ce principe, COM rejoint complètement la position du gang des quatre, clairement exposée dans les 30 premières pages de leur livre. Je ne sais pas si c'est un hasard, ou une convergence naturelle vers le meilleur design basé sur l'expérience
Je détaille les divers aspects de COM dans les sections qui suivent.
En gros, les storages sont des noeuds et les streams sont des feuilles. On accède au stockage structuré avec les interfaces IPersist* (IPersistStorage, IPersistStream, IPersistFile).
Les Monikers répondent à l'interface IMoniker. A l'origine, ils ont été créés pour stocker des documents liés, mais ils sont devenus bien plus génériques.
Avant, sous Windows, les seuls moyens de transferts étaient le clipboard ou bien DDE. Maintenant, il y a des Data Objects, qui répondent à l'interface IDataObject. Ils peuvent regrouper des objets très différents : storage, stream, fichier ordinaire ou encore de la mémoire). L'UDT spécifie en plus un mécanisme de notification (IAdviseSink), un peu comme les propriétés X, afin de spécifier
L'Automation vient du groupe qui développe Visual Basic, et non pas du groupe d'OLE. Il a été conçu pour VB à l'origine, donc très facile à utiliser. L'Automatisation fonctionne avec une identité (DISPID, dispatch id) sur laquelle un switch() est effectué. Cette méthode se prête naturellement mieux à un langage interprété. Un objet peut supporter l'information de type dynamique (RTTI), une bibliothèque de types étant un fichier créé en ODL (Object Description Language) (ITypeLib, ITypeInfo).
L'application conteneur permet à un document créé par une application serveur d'être incrustée ou liée à un document qu'elle crée. Une application peut être
L'activation sur place permet une édition visuelle du document. Un double-clic sur l'objet incrusté provoque les application suivantes :
Je vous relate son tutorial tel quel dans cette section, mais il faudrait qu'on consacre une mini-réunion aux Design Patterns. Autre introduction très valable : C++ Report Juin 95, p18 (celui que j'ai rapporté). Ce qui suit peut vous sembler assez fumeux et abstrait, mais ça vous paraîtra plus clair quand vous serez un peu plus familier avec les Design Patterns. C'est *réellement* intéressant, tous les développeurs devraient lire ce bouquin, même ceux qui n'utilisent pas nécessairement la POO.
Le développement OO est bien plus que le simple dessin de diagrammes. La réutilisabilité la plus puissante n'est pas la réutilisabilité du code, mais celle du design. Un bon designer faudrait vraiment trouver un mot français pour design se repose sur son expérience. Les systèmes OO exploitent des structures récurrentes (i.e. qu'on retrouve régulièrement) de designs qui promeuvent :
Une Design Pattern se compose de plusieurs parties :
Les DP sont indépendantes du langage d'implémentation (dans le livre, c'est C++ et Smalltalk qui sont utilisés pour donner des exemples d'implémentation). Mais une DP, ce n'est *pas* du code.
A ce stade, John donne l'exemple de la DP "Observer" : on a des données (par exemple des chiffres de production) qui sont "observées" par plusieurs clients, qui les gèrent (les affichent) chacun différemment : un graphe barres, un camembert, une courbe. Une modification de la base de données doit entraîner une mise à jour visuelle de tous les observeurs. Inversementsi un observeur est modifié, la base de données doit également être modifiée (et par rebond, les autres observeurs). La DP "Observer" capture ce schéma très typique, et fournit une solution si vous avez à implémenter un tel modèle.
Les DP ont quatre objectifs :
La description d'une DP suit le modèle suivant (repris pour chacune d'entre elle dans le livre) : son but (intent), synonymes, motivation, applicability (?), structure (en notation OMT quelque peu modifiée), participants, collaborations, implémentation, exemple de code, usages connus une des choses que les auteurs ont gardée à l'esprit pour chaque DP est que pour qu'elle figure dans le livre, elle doit avoir au moins deux usages connus. Les exemples les plus cités dans le livre sont Interviews, ET++, etc... et enfin DP voisines.
Vlissides a alors illustré ce modèle avec la DP "Observer".
Les bénéfices des DP sont multiples :
Le live peut paraître un peu rébarbatif à lire étant donné qu'il est composé à 75% de l'énumération des 23 patterns. Comme les auteurs le disent en introduction, il n'est pas vraiment destiné à être lu de bout en bout, mais à être consulté quand le besoin de fait sentir. Personnellement, je suis en train de le finir et je l'ai lu en continuité sans aucune difficulté. Maintenant, si vous ne devez en lire qu'une partie, je vous suggère le plan suivant :
Il a commencé en disant qu'il était rassuré de voir que la salle était à peu près pleine, contrairement au speech OLE qui avait lieu dans la salle à côté
L'informatique distribuée (ID) a plusieurs avantages :
Sources de complexité de l'ID :
Il n'y a maintenant plus aucune excuse pour utiliser des mécanismes bas-niveau (sockets, select(), fork()/exec(), etc...). Les Design Patterns et les frameworks permettent d'élever le développement des services :
Schmidt fait alors une aparté pour dire quelques mots sur le livre Design Patterns ("a classic book" dit-il) : quasiment tous les exemples donnés dans le bouquin viennent du monde des interfaces graphiques, ce qui est une preuve que l'usage des DP ne compromet en rien la vitesse d'exécution
Le reste du tutorial est consacré à l'exposition de son projet en collaboration avec Motorola : il s'agit de gérer la communication entre plusieurs dizaines de satellites et une base terrestre, dans un projet d'imagerie. Inutile de dire que des communications fiables et rapides sont une obligation.
Schmidt conclut en disant que pour l'ID, il est indispensable de savoir ce qui se passe "sous le capot", quel que soit le niveau d'abstraction offert par la toolkit utilisée (que ce soit ACE ou CORBA). Par exemple, CORBA ne garantit pas qu'un send() ne bloquera pas en sortie (inadmissible pour son projet). Même remarque sur la taille de la queue des sockets, qui influe énormément sur les performances. C'est un point sur lequel il revient dans son papier (voir plus bas) autre réflexion typique d'un technicien .
Schmidt revient alors sur les Design Patterns. Quand il a dû porter ACE sur NT, il n'a pas pu *du tout* réutiliser son code, *mais* il a pu réutiliser les patterns (par exemple, select()/poll() sur Unix devient WaitForMultipleObjects() sur NT. Remarque intéressante (car elle vient d'un pro-Unix, et non pas d'un pro-Microsoft "NT's got very reasonable programmation things".
Citation de la pattern "Reactor", qui est utilisée dans Xt, Interviews, CORBA, et de l'"Iterator" (STL, gestion lectures des répertoires read_dir() etc...).
Schmidt a aussi fait une démonstration particulièrement convaincante de l'usage des templates en C++ pour commuter d'une application single-threaded vers une multi-threaded en modifiant une ligne de source. Plusieurs cas de figure :
Il y avait deux parties à ce tutorial. La première est consacrée à SOM (intéressant, comme je vous le disais en introduction) est la deuxième à la programmation de méta-classes, à propos de laquelle Ira a été très enthousiaste ("don't leave after the break, cos' this will know you off your socks") mais au final, c'est assez fumeux.
La programmation OO est représentée par l'encapsulation est le polymorphisme, mais elle a fait beaucoup de promesses qu'elle n'a pas tenues. Un des gros problèmes du développement OO est la (absence de) compatibilité binaire.
SOM (System Object Model) est une technologie pour les bibliothèques de classes orientés objet qui fournit les fonctionnalités suivantes :
Les plateformes de SOM :
DSOM (Distributed SOM) permet l'invocation de méthodes distantes via un proxy ou un ORB, sous OS/2 et Win3.1 (TCP/IP, IPS, SPX, NetBIOS) et AIX (TCP/IP, IPX/SPX).
Une classe SOM doit subir quelques contraintes avant de devenir DSOM :
SOM garantit la compatibilité binaire au travers des différentes versions (en général, les interfaces binaires ne supportent pas le sous-classage : elles appellent la mauvaise méthode). Dans l'idéal, seule une altération de l'application devrait entraîner une recommpilation. Il est donc nécessaire d'identifier des "transformations sûres" (safe transformation), i.e. des modifications du source qui ne devraient pas entraîner d'incompatibilité binaire.
Dans un langage procédural, c'est assez simple. Il y en a cinq :
Echelle des temps :
Avr 92 : SOM 1.0, OS/2 2.0
Sep 93 : SOM 2.0, OS/2 2.0
Oct 94 : SOM 2.1, OS/2 Warp
Deuxième partie du tutorial : Metaclass programming. J'ai dix lignes de notes mais je vais même pas les retaper. Ou bien c'est trop génial et j'ai rien compris (je suis pourtant un peu familier avec CLOS et Self) ou bien c'est du fogware.
Leur mécanisme d'activation des objets a pour but d'être souple, d'offrir un protocole simple, basé sur Modula 3 comme vous voyez, il n'y a pas que DEC à l'utiliser . Les interfaces sont écrites en IDL avec de l'héritage simple (pas d'héritage multiple en IDL).
Le modèle du client peut avoir deux formes de références :
Pour cela, il est nécessaires de définir trois classes par service : persistance, transaction, et les deux à la fois. La conclusion de l'article est que l'ajout de dynamique est viable et qu'il ajoute peu d'overheads par rapport à l'approche statique (benchmarks à l'appui).
Les tests ont consisté à faire des mesures en faisant varier la taille des queues des sockets (de 8k a 64k), sur des câbles Etherne 10Mb et ATM 155b. Aucun des ORB ne supportait CORBA 2.0.
C et ACE sont très proches en performances, prouvant que les wrappers C++ n'ajoutent pratiquement aucun overhead. Les ORB sont loin derrière. C/ACE n'ont atteint que 50% du potentiel théorique d'ATM à cause des Sparc, qui sont des goulets d'étranglement à des vitesses si élevées. Avec ATM, le réseau n'est donc plus du tout le facteur limitant dans la transmission Une conclusion auxiliaire de Doug consiste à dire que les réseaux haute vitesse sont d'excellents moyens de faire apparaître des faiblesses d'optimisation du code réseau, celles-ci étant en général masquées par le faible débit du câble. Autrement dit, toutes les applications qui doivent aller vite devraient obligatoirement passer le "test du feu" qui consiste à tourner sur ATM .
Par exemple, les "sequence" de CORBA vont plus vite que les "string" (ce sont tous les deux des types IDL) parce que les "string" ont un paramètre "length" dont la consultation coûte cher sur des réseaux haut débit.
C/ACE se comportent mieux quand la taille de la queue des sockets est augmentée elle était de 100k max. en Solaris 5.3 et ils l'ont abaissée à 64k max. en Solaris 5.4. C'est ça le progrès .
ORBIX est meilleur que ORBeline sur ce plan car il fournit des hooks pour faire ce genre de réglage fin, c'est ce genre de détail qui fait affirmer Doug que même pour des interfaces de haut niveau, il faut impérativement avoir une idée de ce qui se passe "sous le capot" (cf. ma remarque en intro).
Avec un profiler, il a déterminé que ACE/C passaient l'essentiel de leur temps dans send()/write(), et que le coût de méthodes virtuelles peut donc être complètement négligé. En revanche, les ORB passent une grande partie de leur temps dans write(), memcpy() et strlen(), à cause des recopies incessantes des données dans les données d'instances.
C'est le but du projet FOREST. Il utilise OBJECTStore (un OODBMS) qui fournit la persistance d'objets C++ et un modèle de client-serveur) et VESTA (qui stocke des composants sous une forme non modifiable).
FOREST intègre le management de configurations, l'édition et la construction de systèmes. C'est une base de données partagées par les utilisateurs. ça pourrait peut-être intéresser le SEMIR, dans le principe du moins. Dans la pratique, je ne sais pas si ça reste encore expérimental ou s'ils arrivent vraiment à manager des sites avec ça
Je ne vais pas détailler la solution qu'il propose vu que celle-ci est intimement liée à Modula 3 et à ses primitives de debug. J'estime que le titre, très prometteur, tient un peu de l'arnaque car il laisse entendre une solution générale, alors que celle-ci est en fait spécifique à Modula 3
Java est conçu pour construire des applications distribuées "safe". James n'avait pas du tout pensé à écrire un langage qui serait utilisé pour bâtir des systèmes distribués. Il avait commencé avec C++ mais ça a rapidement dégénéré, et l'idée de Java est venue. Hotjava a été écrit à partir de standards externes (nntp, ftp, http, etc...). Java en quelques mots en toute modestie précise-t-il : OO, distribué, interprété, robuste, safe, neutre du point de vue architecture Anselm est bien placé pour confirmer que c'est un peu exagéré dans la pratique , portable, permet de hautes performances, etc...
La sécurité repose la vérification du bytecode, sur des espaces de noms clairement définis, et des politiques indépendantes dans les packages de haut niveau (réseau, systèmes de fichiers). Java est disponible sur NT, Solaris. Win95 et Mac pour bientôt, et d'autres portages en considération.
. Luca Cardelli
On connaît Obliq, je passe.
. Antony Courtney
Il présente Phantom, un langage interprété pour des applications distribuées. Phantom a été démarré en 1994 et était basé sur le scopique lexical distribué d'Obliq. Phantom est similaire par bien des côtés à Java personnellement, je ne trouve pas, je soupçonne Courtney d'essayer de surfer la vague montante et a une syntaxe correspondant à un sous-ensemble de Modula 3, typé statiquement.
Initialement, il était destiné à implémenter un système de conférece distribuée tiens tiens mais il a rapidement évolué. Sa principe innovation est que le client est dynamiquement étendu. Actuellement, l'utilisateur interagit avec des serveurs, mais ceux-ci ne communiquent pas entre eux Courtney touche à un domaine un peu plus social de l'Internet là (et que j'estime particulièrement intéressant): W3 promeut énormément une consultation statique et solitaires des informations. Courtney voudrait aller au-delà . Sa prochaine étape est donc de faire communiquer des clients WEB entre eux.
. Nitin Borwanker
Intervention un peu clownesque et utopique IMHO, mais il parle quand même avec conviction . Borwanker est un défenseur des Protocoles OO, pas des Langages OO. Il y a en effet de nombreux problèmes avec le code :
Question amusée de Gosling a Borwanker : "dois-je comprendre que tu es pour le protocole finger ? " (plus gros ver de l'Internet connu). Borwanker reconnaît à contre-coeur qu'il y a des défauts à son approche...
Autre remarque amusante de Gosling, mais en dehors du sujet : il a déjà reçu en mail une macro emacs écrite en elisp qui implémente un interprète Basic au complet .
Plutôt décevante la confrontation au final. Gosling n'essayait pas trop de défendre Java, un peu normal vu que c'est probablement le langage qui a le plus de chance de s'imposer dans ce domaine
Phantom, an interpreted language for distributed programming
Antony Courtney
Le problème avec C++ c'est que si l'application est très générale, cela représente beaucoup de travail. Si l'application est plus spécifique, cela restreint l'interaction. HTML et CGI n'ont qu'un lot restreint de codes et données. Ils sont sans état, ont une réponse interactive horrible et leur syntaxe rend la rédaction de documents à la main fastidieuse pas vraiment un problème pour moi, ils sont tous les deux appelés à être utilisés par des générateurs automatiques IMHO .
Phantom permet la distribution transparent du code et des données. Il garantit la sécurité sur le réseau et est un vrai langage. Il exclut les features qui ne sont pas safe, incorpore les threads et possède un GC. L'utilisation du scoping lexical d'Obliq permet un accès contrôlé aux ressources locales. Il est basé sur une machine virtuelle byte-codée, utilise Tk et les pthreads du MIT.
Futur : compléter le support de la distribution dans le runtime et implémenter l'authentification.
Est-il possibiler de généraliser tout en conservant la sécurité fournie par les types ? Oui, avec des "functoids".
Ce sont des templates de classes Fun
Lingua Franca -> C++ translator -> C++ déclarations (avec client/serveur,
RTTI)
interface grid {
long get (in int, in int)
set (in int, in int, in int long)
};
Exemple d'utilisation par un client :
#include CORBA::impl_is_ready() // CORBA pret ?
p = grid::_bind(); // recherche sur le reseau
try {
p -> set(2, 3, 123); // stockage dans la grille de 123 a la position
2,3
p -> get(2, 3);
}
catch {
...
}
L'implémentation consiste à écrire une classe C++
qui hérite de _sk_grid (le squelette généré
par la compilation de l'interface IDL) :
class grid_i : public virtual _sk_grid { // grid_i = implementation
// implémentation (C++) des opération set() get()
etc...
}
L'implémentation se fait en C++ standard, mais il faut faire
attention à la mémoire (par exemple, toujours retourner des
copies des données). Ensuite, on enregistre le serveur auprès
de CORBA ("putit grid /net/corba/grid").
L'écriture d'une application COM passe par les mêmes étapes
que CORBA. Une application COM utilise en plus un numéro d'identité
unique (déjà évoqué dans le tutorial COM) :
une UUID. La syntaxe de leur IDL est légèrement différente
:
void set ([in] short n, [in] short n, [in] long value)
La compilation de l'interface IDL fournit un fichier de plus :
grid.h, grid_i.c (interface commune)
grid_p.c dlldata.c (lien à la DLL et squelette d'implémentation).
COM ne gère pas les exceptions, contrairement à CORBA
Don avoue qu'il aurait bien aimé avoir le mécanisme d'exception
de CORBA mais il possède un modèle binaire, contrairement
à CORBA où c'est totalement non spécifié. Trois
exécutables sont créés à la fin du processus
: le client, le serveur et une DLL (qui contient le proxy).
A chaque interface correspond une classe C++, et à chaque opération
correspond une fonction membre. Si l'appel de la méthode se révèle
être un appel local, aucun code Microsoft ne s'interpose entre le
client et le serveur. Sinon, c'est le proxy qui est utilisé (avec
des vptr et des vtbl).
La somme des deux donne Electro ORB (CORBA 2.0), dont le champ d'application
est : systèmes à distribution fiable, applications client-serveur,
groupware, transmissions de données efficaces.;
Les groupes sont créés en étendant le BOA (Basic
Object Adaptor) avec BOA::create_groupe(), BOA::join_group (), etc... Electro
ORB sera disponible en août.
Tactiques utilisées : interfaces fortes, typage fort, sépraration
claire de l'interface et de l'implémentation, héritage des
interfaces, objets distribuées.
L'héritage de l'implémentation est différent de
l'héritage de l'interface cf. le chapitre d'introduction du livre
Design Pattern . Les objets sont des instances d'interfaces. Les auteurs
ont aussi fait attention de ne pas implémenter toutes les fonctionnalités
qui leur venaient à l'esprit afin de ne pas créer un monstre.
Les objets travaillent sur la base de contrats, matérialisés
par les interfaces, et qui établissent ce que les objets peuvent
faire. Elles sont faites en IDL mais légèrement plus étendu
leur version inclut des modes de paramètres supplémentaires
que in, out et in out : borrow, copy, consume, produce. Ils ont essayé
de convaincre l'OMG d'ajouter ces nouveaux modes à IDL mais ont
échoué .
Les objets de Spring exportent des objets de comparaison afin de déterminer
de façon sûre les équivalences par exemple, un fichier
en Unix est représenté par un entier, et peut être
comparé avec un temps en seconde ou bien encore une quantité.
Notez que c'est également un des arguments (très sensés
IMHO) avancés par Schmidt pour justifier ACE .
Il existe des mappings de leur IDL pour C++ et Java. Spring est utilisé
pour son propre développement un signe certain que ça
commence à être solide . Il existe actuellement une centaine
d'interfaces : threads, mémoire virtuelle, nommage, fichiers, devices,
etc...
Les auteurs ont fait beaucoup de pression dans la conférence
pour gagner des utilisateurs : distribution de compilations d'articles
écrits sur Spring, appels à testeurs, etc...
Il possède une séparation très claire des types
et des classes si vous n'êtes pas convaincu que la classe d'un
objet est très différente avec le type de cet objet, lisez
l'introduction du livre Design Pattern . Un type peut avoir de multiples
impléemtations.
La généricité est réalisée via des
composants génériques. BALLOON sépare l'implémentation
d'une interface potentielle.
Les auteurs ont illustré leur langage avec un exemple d'échiquier
simplifié : une tour, un fou et une reine, héritant de tour
et fou pour implémenter ses déplacements. Le langage offre
des primitives de synchronisation pour retarder l'utilisation d'une méthode
jusqu'à ce qu'une autre méthode soit exécutée.
Generic containers for a distributer object store
Carstein Weich
STL permet de paramètrer le type de l'élément,
la structure du conteneur, fournit des algorithmes réutilisables,
et utilise une structure séquentielle comme primitive de base. Carstein
veut utiliser Modula 3, il a donc exclu STL.
Il donne un exemple d'implémentation en Modula 3, rien de
nouveau. Je me demande l'intérêt de sa présentation
Lingua Franca : an IDL for structural subtyping distributer
object systems
Patrick Muckelbauer, Vincent Russo
Purdue University, West Lafayette
Le but est de construire un système distribué de manière
structurée et fortement typée afin de minimiser le couplage
entre les composants. Les collections autonomes d'objets constituent des
domaines. L'approche utilisée utilise IDL.
Pot-pourri : COM/CORBA
Modérateur : Mark Linton
Indubitablement un des points forts de cette conférence. COM
et CORBA étaient chacun représentés par deux personnes
qui ont démontré pas à pas la constitution d'un client
CORBA puis COM. Le client doit fournir un accès distant à
une grille (un tableau bi-dimensionnel. Ce pot-pourri a été
surnommé par Linton "laptop wars" parce que les deux partis ont
fait leur présentation avec des portables sur barco (sp?) , en utilisant
des transparents rédigés avec Powerpoint. C'est surtout ce
dernier point qui était intéressant : les CORBA ont choisi
l'exemple, et les COM ont alors repris leurs transparents en faisant les
modifications pour l'adapter à COM. Il ressort que ces transformations
sont mineures, et que COM et CORBA sont *extrêmement* voisins. La
séance a duré un peu plus d'une heure mais elle aurait dû
prendre un après-midi entier. Dommage.
Writing a CORBA application
La présentation est faite par un gars d'Iona. La création
d'une application CORBA se fait en plusieurs étapes :
Tous ces processus ont été illustrés avec des exemples
de code. Extrait de l'interface IDL :
Writing a COM application
Quelques mots sur le présentateur : il s'appelle Don Box et m'a
très fortement impressionné. Point de vue physique, pour
ceux qui ont vu Wayne's World, il ressemble comme deux gouttes d'eau à
Wayne : longs cheveux blonds, lunettes en écailles carrées,
légère barbe. Il a une voix qui porte, et est véritablement
intéressant pour chaque mot qu'il prononce. Il est aussi très
drôle. Pendant tout le temps qu'il était assis, il portait
une veste par-dessus un tee-shirt blanc avec un petit logo Windows dessus.
Quand son tour est venu, il s'est levé, a retiré sa veste,
a marché au centre de l'estrade, a tourné le dos à
l'assistance genre "je mets de l'ordre dans mes transparents" alors que
c'était en fait pour montrer le dos de son tee-shirt, sur lequel
était marqué en gros caractères "Windows 95 sucks
less".
Adding group communication and fault-tolerance to
CORBA
Silvano Maffeis
Cornelle University, Ithaca
Problèmes dans CORBA :
Supports actuels de CORBA :
Il faudrait quelque chose come ISI ou Horus. ISIS tourne sur Unix, VMS
et Windows. C'est un produit commercial très stable. Horus est un
système runtime et des bibliothèques C. Il est très
souple et adaptable. Il autorise du multicase ATM sur UTP
The Spring object model
Sanjay Radia, Graham Hamilton, Peter Kessler, Michael Powell
SunSoft Inc.
Spring est le "nouvel" je dirais : expérimental OS de Sun.
Il a démarré en décembre 1988. Il fournit une distribution
transparente, sécurité, uniformité et modèle
des applications cohérents (contrairement à Unix qui, par
exemple, a besoin de plusieurs serveurs de noms tous différents
: numérotation des machines, partages de /etc/hosts, etc...).
Integration of concurrency control in a language with
subclassing and subtyping
Calors Baquero, Rui Oliveira, Francisco Moura
Universidade do Minho, Portugal
La gestion explicite de la concurrence cause une forte interférence
avec l'héritage. Les auteurs ont donc créé un langage,
BALLOON, qui est un langage OO pour expérimenter la concurrence.
Universitatsstr Klagenfurt, Austria
Le but est de créer une base de données distribuées,
stockée en mémoire, et basée sur l'implémentation
des ensembles. Quelles primitives sont nécessaires ? insert(), remove(),
map(), member?(). Implémentations possibles : rassembler des composants,
utiliser des types customs ou encore des algorithmes prédéfinis
(STL).