Gewinnung eines geeigneten Objektmodells

  Zusätzlich zu den im vorigen Abschnitt angesprochenen Konvertierungen gibt es natürlich noch eine Reihe offener und für das Design des CORBA-Agenten substantielle Kritikpunkte, die nachfolgend aufgezählt sind. Es sei an dieser Stelle daran erinnert, daß das Ziel der Arbeit darin besteht, einen Agenten zu erhalten, der möglichst vollständig objektorientierten Prinzipien entspricht.

• Zwischen den einzelnen Klassen fehlt (bis auf die Enthaltenseinsbeziehung zur Systemklasse) jegliche Hierarchie
  Eine Enthaltenseinshierarchie ist nur ansatzweise (eben mit der Systemklasse) realisiert, eine Vererbungshierarchie fehlt gänzlich. Damit sind zwei wesentliche Möglichkeiten der Objektorientierung noch nicht ausgeschöpft. Polymorphismus wird damit zwangsläufig auch nicht unterstützt. Dies sind unmittelbare Konsequenzen aus dem Internet-Informationsmodell, das keinerlei Beziehungen zwischen Objektklassen (weder Vererbung noch Enthaltensein) kennt.
• Die noch vorhandenen Typvariablen  widersprechen objektorientierten Grundsätzen
  Beispiele für solche Typvariablen in obigen MIB-Ausschnitten sind Type in der Storage-Klasse oder Type in der Device-Klasse. Damit ist es zwar möglich, verschiedene Arten der Objektklasse Storage (durch entsprechendes Setzen der Typvariablen) zu bilden, die Objektstruktur ist jedoch für die unterschiedlichen Arten von Speicherobjekten (Hauptspeicher, Festplatten, Magnetbänder, Disketten) dieselbe; die stark differierenden Eigenschaften der einzelnen Typen werden somit nicht berücksichtigt. Hier wird das Fehlen einer Vererbungshierarchie im Internet-Informationsmodell deutlich.
• Die Problematik der ,,Pushbutton``-Variablen  bleibt bestehen
  Das Problem, daß die Wertzuweisung an eine Variable unmittelbar eine Operation auslöst, ist auch in diesem ersten Objektmodell vorhanden. Dies resultiert aus der Tatsache, daß SNMP keine Action-Protokolldateneinheit kennt und diese Funktionalität durch die Set-PDU nachgebildet werden muß.
• Die Variablentypen  beschränken sich nur auf ASN.1-Grundtypen
  Auch Variablen mit stark eingeschränktem Wertebereich, wie z.B. OpState oder AdState in der Klasse Processor, besitzen im ersten Objektmodell einen einfachen integer-Datentyp. Während dieser Punkt auf den ersten Blick als ein ,,kosmetisches`` Problem erscheint, so sind Überlegungen bezüglich der Einschränkung der Wertebereiche von Attributen hinsichtlich späterer Konformitätstests wichtig.

Das objektorientierte Prinzip der Datenabstraktion (Encapsulation) ist in diesem Stadium bereits berücksichtigt: Wäre diese erste Version als Basis für die Implementierung herangezogen worden, so hätte der IDL-Compiler Rahmendateien erzeugt, in denen die einzelnen Attribute als private gekennzeichnet, also nur über spezielle get-/set-Operationen (deren Rahmen ebenfalls erzeugt würden) zugreifbar gewesen wären. Es ist somit nicht möglich, auf die Attribute über andere als die bei der Implementierung vorgesehenen Wege zuzugreifen, was dem Konzept der Datenabstraktion entspricht.