Syntaktische Nachbearbeitung der generierten IDL-Schnittstellen

 

Als CORBA-Entwicklungsumgebung wird, unter anderem, das IBM SOMobjects Developer Toolkit [#!IBMSOM94!#] eingesetzt; es umfaßt einen CORBA 1.2-konformen Object Request Broker, einen IDL-Compiler, die CORBA-Laufzeitumgebung und mehrere zu den OMG-Standards konforme Dienste [#!sompg296!#].

Die vom CASE-Tool erzeugten IDL-Schnittstellenbeschreibungen können in diesem Fall nicht unmittelbar als Eingabe für den IDL-Compiler eingesetzt werden, da Nachbearbeitungen an folgenden Stellen erforderlich sind:

• Definition von Attributtypen
  Datentypen, die nicht zu den IDL-Grundtypen gehören, müssen - sofern sie nicht in der Attributdeklaration festgelegt sind - gesondert definiert werden. Weiter ist zu beachten, daß der SOM IDL-Compiler zwar Sequenzen kennt, oft jedoch nicht den Datentyp, über dem die Sequenz definiert wurde. Dem Auftreten von sequence$\langle$Processor$\rangle$ muß die Definition der Objektklasse Processor vorangehen.
• Ableitung aller IDL-Interfaces von SOMObject
  Die Konventionen des SOM IDL-Compilers verlangen, daß alle auftretenden Schnittstellen von der Objektklasse SOMObject abgeleitet werden.
• Ergänzung aller IDL-Dateien um eine ,,Implementation Section``
  Hierbei muß dem IDL-Compiler mitgeteilt werden, in welche Dynamic Link Library (DLL) die spätere Ausgabe geschrieben werden soll. Außerdem müssen noget- oder noset-Anweisungen für Nur-Lese- bzw. Schreib-Lese-Attribute eingefügt werden, um zu verhindern, daß der Compiler automatisch interne get- oder set-Operationen erzeugt, die den entsprechenden Attributwert liefern bzw. setzen. Dies ist notwendig, da der einzubindende Code bereits existiert.

Es sei an dieser Stelle erwähnt, daß die Notwendigkeit der manuellen Nachbearbeitung von IDL-Schnittstellen ausschließlich auf die Unzulänglichkeiten dieses Werkzeuges zurückzuführen ist. Versuche mit neuesten CORBA-Toolkits (OrbixWEB, VisiBroker for Java) haben gezeigt, daß die vom CASE-Tool generierten Schnittstellenbeschreibungen in der Regel problemlos akzeptiert werden. Dieser Teilabschnitt hat folglich anhand eines ,,worst-case-Szenarios`` aufgezeigt, welcher Anpassungsaufwand durch unausgereifte ORB-Implementierungen entstehen kann.