Sonstige Klassen und Vereinbarungen

Weitere Festlegungen zu dem Informationsmodell:

• Sämtliche benötigten Ausnahmen werden wie oben beschrieben in das Informationsmodell übernommen. Dabei soll eine zusätzliche Ausnahme JMX_IIOPAdaptorException hinzugefügt werden, durch die alle im IIOP-Adapter auftretenden Ausnahmen gekapselt und an den Klient übertragen werden können.
• Die Klasse JMX_Notification ist als Abbild der Klasse Notification als Struktur definiert, da sie ebenfalls nur beschreibenden Charakter hat.
• JMX_NotificationListener und JMX_NotificationFilter werden als IDL-Interfaces umgesetzt.
• Als häufig benötigte Klasse ist es sinnvoll, JMX_Attribute ebenfalls als Object-By-Value Klasse vorzusehen.
• Die Klasse AttributeList ist von der JAVA-Klasse ArrayList abgeleitet und bedarf spezieller JAVA-Klassen, die in dieser Form nicht in anderen Programmiersprachen anzutreffen ist. Daher wird anstelle der AttributeList ein Standardarray der Klasse JMX_Attribute verwendet (siehe z.B. getAttributes in JMX_MBeanServer).
• Zu den Methoden queryMBeans und queryNames in MBeanServer gibt es mit dem Konzept der QueryExp (siehe JMX-API) die Möglichkeit, zusätzliche logische Ausdrücke für die Suchanfragen zu definieren. Da aber jedes Element in den Ausdrücken als eine Klasse dargestellt wird und die Suchanfragen damit vielfach verschachtelt aufgebaut sind, ist eine solche Übernahme in die verteilte, nicht auf JAVA basierende Umgebung nur durch hohe Aufwendungen zu realisieren. Als normale Interfaces deklariert, würden mit jedem weiteren logischen Element zusätzliche kaskadierende Aufrufe entstehen und als Object-By-Value würde dies eines hohen Implementierungsaufwandes bedürfen. Daher soll dieses Konzept aus der Beschreibung ausgeklammert werden und als allgemeiner Typ Object für eine spätere Erweiterungsmöglichkeit zur Verfügung stehen.