Fehlende globale Sicht auf große IT-Infrastrukturen

  Neben diesen Vorteilen zeigen sich bei JDMK aber auch teils gravierende Nachteile und konzeptionelle Schwächen.
JDMK bietet keine standardisierten Lokalisierungs- oder Namensdienste an. Es werden auch keine Mechanismen zur Verfügung gestellt, um Dienste wie den Corba Naming- oder einen Trading Service zu nutzen. Daher muß der Entwickler selbst ein Namensschema etablieren und durchsetzen. Eine Ortstransparenz beim Zugriff, wie sie z.B. bei Corba mit Interoperable Object References (IORs) gegeben ist, läßt sich nur ausgesprochen schwer realisieren. Der Zugriff auf M-Beans erfolgt immer über einen Protokollidentifikator, den Host, einen bestimmten Port und den Objektnamen des M-Beans. Alle diese Informationen und ein bestimmtes Grundwissen über die beim jeweiligen CMF registrierten Beans müssen den Anwendern bekannt sein. Da JDMK kein eigenes Informationsmodell definiert und auch keine Gateways zwischen den verschiedenen Protokollen zur Verfügung gestellt werden, muß ein Agent von Hand angepaßt werden, um wirklich multiprotokollfähig zu sein. Um bspw. einen unter JDMK entwickelten SNMP-Agenten auch in der gewohnten Weise aus einer Corba basierten Managementanwendung ansprechen zu können, reicht es nicht, einfach den IIOP-Adapter zu registrieren.

Der Metadata Service, der dazu verwendet werden kann, Informationen über registrierte M-Beans abzufragen, ist immer nur lokal zu einem CMF definiert, d.h. es gibt keinen globalen Metadata-Service oder ein globales Interface Repository. Die einzige Möglichkeit, alle gerade aktiven CMFs zu finden, bietet der Discovery Service, der eine Broadcast-Nachricht verschickt, auf die die Agenten antworten. Um dann bspw. alle Agenten zu finden, die eine bestimmte Methode implementieren, muß jeder Agent bzw. jedes CMF, z.B. über den Filtering Service, abgefragt werden.

Auch Konzepte, um eine organisatorische Unterteilung in Domänen bzw. eine funktionale Gliederung in Gruppen zu ermöglichen, sind kaum vorhanden und müssen vom Entwickler selbst realisiert werden.

Eine Interagentenkommunikation ist nur zwischen Master- und Subagenten vorgesehen. Es sind auch keine bzw. nur schwache Ansätze vorhanden, um eine Kooperationsfähigkeit bei den Agenten möglich zu machen.

JDMK-Agenten besitzen nicht die Möglichkeiten, in einem Netz zu migrieren. Das CMF stellt keine Plattform für mobile Agenten, im Sinn der OMG Mobile Agent Systems Interoperability Facility (MASIF) [10] dar, sondern einen Rahmen und Infrastrukturdienste für M-Beans. JDMK-Agenten werden auf einem System instantiiert und sind dann nicht mehr in der Lage, ein anderes System ,,zu besuchen``.

Aufgrund der angeführten konzeptionellen Schwächen ist es relativ schwierig, mit Hilfe von JDMK-Managementanwendungen für große, heterogene IT-Infrastrukturen, in denen eine große Anzahl an verschiedenen Agenten benötigt wird, zu entwickeln. JDMK ist, wenn die Konzeption der mitgelieferten Dienste betrachtet wird, nur für kleinere, lokale IT-Infrastrukturen, in denen die Anzahl und der Grad der Diversifikation der Agenten sehr beschränkt bleibt, geeignet. Da der globale Fokus auf ein großes System fehlt, wird JDMK in seinem momentanen Zustand in solchen Umgebungen auch nicht skalieren.