CORBA - DII u DSI?

[flashray]

Hallo,

hätte jemand eine Idee in welchen konkreten Fällen das Dynamic Invocation Interface und das Dynamic Skeleton Interface anstatt der statischen Stubs und Skeletons verwendet werden sollte?

Wenn die Verteilte Anwendung aus einem bestimmten Server und beliebigen aber bestimmten Clients besteht, so sind Stubs und Skeletons ausreichend, da alle nötigen Infos im voraus bekannt sein sollten.

Wüsste jemand einen realen Anwendungsbereich für Verteilte Systeme in der erst zur Laufzeit ein Teil der Informationen festgestellt werden können, für welche das DII und DSI notwendig wären?


Vg Erdal

 

[Thomas Darimont]

Hallo!

hätte jemand eine Idee in welchen konkreten Fällen das Dynamic Invocation Interface und das Dynamic Skeleton Interface anstatt der statischen Stubs und Skeletons verwendet werden sollte?

Beispielsweise wenn die Interface Beschreibung (IDL) nicht vorliegt / in einer alten Form vorliegt / geändert wurde und man trotzdem einen Aufruf durch ein Clientseitiges Interface (Java Interface) über CORBA machen möchte kann das Laufzeit System den Methodenaufruf per Introspection in einen "passenden" übersetzen.

Schau dir die Seiten hier mal an...
http://microsites.cmp.com/documents/s=9063/cujcexp2007vinoski/

http://www.ddj.com/dept/cpp/184403840

http://www.ddj.com/dept/cpp/184403847

Bei Java RMI gibt es auch das Konzept von Stubs (Clientseitig) und Skeletons (Serverseitig) wobei beide Artefakte in aktuellen Java Versionen (Skeletons werden seit Java 1.2 und Stubs seit Java 1.3 nicht mehr benötigt). Das wird dort unter der Haube dann auch alles per Reflection / Interceptoren und Dynamic Proxies bewerkstelligt. Dadurch wird die Entwicklung von verteilen Systemen die über RMI kommunizieren erheblich vereinfacht.
http://today.java.net/pub/a/today/2004/06/01/RMI.html

Gruß Tom

 

[flashray]

Hallo Tom,

Beispielsweise wenn die Interface Beschreibung (IDL) nicht vorliegt / in einer alten Form vorliegt / geändert wurde und man trotzdem einen Aufruf durch ein Clientseitiges Interface (Java Interface) über CORBA machen möchte kann das Laufzeit System den Methodenaufruf per Introspection in einen "passenden" übersetzen.

Ich bin gerade beim Durcharbeiten des folgenden Buches:
Implementing Distributed Systems with Java and CORBA (Markus Aleksy, Axel Korthaus, Martin Schader)

Zu Kapitel 6 gibt es folgende Fragen im Buch:
2. When using the DII, a client is implemented without knowing the interface definition of the server object. Identify real-world applications where that scenario would be interesting.
3. When using the DSI, a server is implemented without knowing the interface definition of the server object. Identify real-world applications where that scenario would be interesting.

In den Links die du gepostet hast, (nach dem ersten Überfliegen) werden die Vorteile des dynamischen Ansatzes abstrakt vorgestellt und das wie beschrieben. Aber keinen Hinweis gegeben bei welchen Projekten, Aufgabenbereichen, Anwendungsfällen man die statische Implementierung des CORBA vermeiden sollte.

Beispielsweise könnte man sagen, ein Passwortbewahrungsanwendung sollte eher lokal arbeiten und zugreifbar sein und dafür ist eine Javaapplikation geignet. Eine Telefonbuch Anwendung hingegen muss laufend aktualisiert werden, so macht eine im Web verfügbare Anwendung die leicht zentral zu aktualisieren ist, mehr Sinn. Hierfür würde sich bspw. ein Applet eignen. Für ein E-Shop von Amazon oder Ebay wären die Möglichkeiten eines Applets nicht ausreichend den komplexen, umfassenden Bedarf dieser Anwendung zu genügen. Hier käme dann eine J2EE Applikation in Frage. Braucht man auf einer Webseite bspw. nur eine simple Animation, so wäre ein Applet die erste Wahl. Sind es aber hingegen komplexe mit dem Benutzer iteragierende Anwendungen wären Servlets besser.

Kann man solch eine Klassizifierung auch nicht für statische und dynamische CORBA Anwendungsfälle vornehmen?


Vg Erdal

 

[Thomas Darimont]

Hallo!

Stell dir doch mal folgendes Client-Server Szenario vor...
Ein Server bietet Dienste über eine CORBA Schnittstelle
an. Ein Client der diese Dienste aufrufen möchte kennt
die Service-Schnittstelle jedoch nicht. Der Server bietet über CORBA nun eine Methode an mit der der Client Meta Data über die angebotenen Dienste erhalten kann... (welche Typen werden zur Kommunkation verwendet, welche Operationen gibt es, usw.) In diesen Metadaten könnte nun beispielsweise Beschreiben werden, dass es die Operationen operationA(), operationB() und operationC() gibt die für den Anwendungsfall X in der Reihenfolge C,B,A aufgerufen werden müssen. Wenn der Client nun den Anwendungsfall X aufrufen möchte, so schickt er vom Client aus eben per DII eine entsprechende Anfrage an den Server. Der Client hat ja über den Meta Daten Dienst des Servers genügend Wissen über die Dienste des Servers um mit ihnen zu Arbeiten.

Der Client fragt also zunächst den Server was er denn so alles kann (welche Dienste gibt es?) und wie man mit ihnen arbeitet (welche Typen sind definiert und wie werden die einzelnen Dienste parameterisiert).

Die Verwendung von DII erlaubt eben "hoch dynamische" Clients deren Funktionalität nicht statisch an ein bestimmtes Interface gebunden ist. Wenn eine neue Funktionalität auf dem Server implementiert und als CORBA Dienst veröffentlicht wurde, kann der Client diesen neuen Dienst ansprechen in dem er sich vom Server die passenden Meta Daten (Dienstbeschreibung) abholt und anschließend den Dienst entsprechend aufruft.

Gruß Tom