Ein substanzielles Problem ist das Behandeln von allgemeinen Datentypen, dargestellt durch den JAVA-Typ Object. Insbesondere in dem hier vorliegenden Szenario ist ein Festlegen des Datentyps durch die generische Handhabung der MBean-Server Schnittstelle nicht möglich, da z.B. ein zu setzendes Attribut immer verschiedene Datentypen zugewiesen bekommen kann, was einen allgemeinen Platzhalter erforderlich macht. Durch das Konstrukt des Metaklassenmodells in JAVA kann stets zu einem durch Object übertragenen Objekt die zugehörige Klasse und damit eine genaue Beschreibung ermittelt werden. Aufgrund des Metaklassenprinzips ist ein sogenanntes ``Casten'', d.h. Rückumwandeln in den ursprünglichen Objekttyp möglich.
Durch das Übertragen durch CORBA geht diese Metaklassenbeschreibung von JAVA verloren, so dass ein einfaches Abbilden auf den allgemeinen CORBA Datentyp Any entfällt. In CORBA ist eine eigene standardisierte Lösung für das Übermitteln der zugehörigen Objektinformationen entwickelt worden [OMG01, Kapitel 10.7]: der Typ Any besteht aus dem Wert als auch aus einem TypeCode, der eine Beschreibung des Wertes darstellt. Ein TypeCode besteht aus einem kind Feld und optional aus Parametern. Eine standardisierte kind Belegung ist z.B. tk_string für den Datentyp String, so dass unabhänigig der CORBA Implementierung ein Wert in einem Any mit dem TypeCode tk_string auch wieder als String interpretiert werden kann. Zusätzliche Informationen wie die Länge einer Sequenz oder deren Typ werden in den Parametern abgelegt.
Unter diesen Voraussetzungen kann eine Übertragung als allgemeiner Typ Any erfolgen: Durch Auslesen der Metaklasseninformationen zu dem zu Object gehörenden Objektes kann der Typ festgestellt und entsprechend ein Any Element mit dem zugehörigen TypeCode angelegt werden, dem dann das Objekt zugewiesen wird. Das Gleiche geschieht andersherum beim Empfangen eines Any Elementes: aufgrund von TypeCode und Zusatzinformationen kann ein entsprechender JAVA-Datentyp angelegt und mit dem übertragenen Wert belegt werden, der dann als allgemeines Objekt weiterverarbeitet werden kann. Eine entsprechende Funktionalität ist exemplarisch für die gängigsten Datentypen in den Methoden any2obj und obj2any realisiert, womit eine Umwandlung des allgemeinen Datentyps in beide Richtungen für den Gebrauch in der Adapterlogik zur Verfügung steht.
Eine interessante Alternative für die Behandlung von unbekannten Datentypen wäre noch die Möglichkeit der Serialisierung des allgemeinen Objektes, das als serieller Bytestrom übertragen werden könnte. Ein Verarbeitung des Bytestromes wäre zwar auf Klientseite aufgrund fehlender Informationen nicht möglich, doch könnte dieser wiederum als Quelle für weitere Verarbeitungsinstanzen dienen, die das serialisierte Objekt wieder interpretieren könnten (denkbar wäre die Rückführung des serialisierten Objektes in eine JAVA-Umgebung, die entsprechende Deserialisierungsroutinen anbietet).
Außer den durch CORBA standardisierten TypeCodes werden zu in IDL definierten Klassen ebenfalls TypeCodes generiert, die damit für die Übertragung als Any vorbereitet sind und die Menge der übertragbaren Objekte erweitert. Die Definition des zugehörigen Typecodes zu xxx geschieht auf JAVA-Seite in der Klasse xxxHelper.java. Damit ist auch der Bereich der im Kapitel Design angesprochenen komplexeren JAVA-Objekte abgedeckt, die damit ebenfalls als allgemeiner Datentyp übertragen werden können.