Server / Client (Applet) - Objekt übergeben

ReiTerMaNiaC

Grünschnabel
Hi ihrs,
ich hab eine Frage zum Thema Server/Client/Applet...wär super wenn mir jemand einen Tipp geben könnte, da meine Diplomarbeit hieran hängt und die Zeit etwas knapp ist. :)

Zu meinem Problem: Ich habe ein Programm [4], das folgendes macht:
Es erstellt ein OntModel [1], basierend auf nem Ontologie-File. Dann wird ein Submodel (D2RQ [2]) geaddet, basierend auf einem Mapping, das zwischen Ontologie-File und einer MySQL-DB vermittelt. Aus diesem Model wird dann ein Graph erstellt, in ein Display eingebunden und über ein Panel visualisiert (Visualisierung: prefuse [3]). Im Endeffekt soll das ganze schön in nem Browser von jedermann aufzurufen sein, also wohl per Applet.

Das Problem an der Sache ist: das Einlesen des D2RQ-(Sub)Models dauert ca. 3 Minuten --> für einen browsenden User viel zu lang. Ich dachte mir, ich könnte das Umgehen, indem ein Teil der Prozedur (inkl. v.a. des Model-Initialisierens) als Server-Applikation o.ä. läuft und ein vom User aufgerufenes Applet dann einfach darauf zugreift.
Also simpel ausgedrückt: der zeitaufwendige Teil des Codes soll irgendwie permanent laufen, nur hab ich quasi keine Ahnung, wie. :)
Habe mir erste Infos über Verteilte Client/Server Programme bzw. RMI angeschaut, aber ich befürchte das ganze wird etwas kompliziert, da ich ja ein ganzes Objekt (das OntModel oder später Graph, GraphDisplay, GraphPanel) übergeben muss. Außerdem weiß ich nicht genau, ob das initialisierte OntModel an dem Punkt "einsatzbereit" ist oder evtl. erst später bei Bedarf auf Datenbank und Ontologie-File zugreift...
Auch ist das OntModel, wenn ich das Prinzip richtig verstanden hab, nicht "serialisierbar", was die Lösung mit RMI wohl problematisch macht.

Was mir sehr helfen würde, wäre ein Stoß in die richtige Richtung, welche "Technologie" ich dafür ranziehen muss (RMI, CORBA, simples Server-Programm, keine Chance mit Applet, Web Service!?, ein einfacher Befehl der die eine Prozedur offen hält), bevor ich mich da mit diversen Sachen rumschlag, obwohl es damit gar nicht funktionieren kann.


Schon mal im Vorraus vielen Dank

Gruß,
Flo


[1] http://jena.sourceforge.net/javadoc/com/hp/hpl/jena/ontology/OntModel.html
[2] http://sites.wiwiss.fu-berlin.de/suhl/bizer/d2rq/javadoc/de/fuberlin/wiwiss/d2rq/ModelD2RQ.html
[3] http://prefuse.org/

[4] Code-Snippet:
Code:
// ontology that will be used
String ont = "file:../data/ontology.owl";
        
// create an empty ontology model using Pellet spec
OntModel p_ontModel = ModelFactory.createOntologyModel(PelletReasonerFactory.THE_SPEC);        
        
// read the file
p_ontModel.read(ont);
        
// create and add D2RQ model as a submodel
ModelD2RQ d2rqMod = new ModelD2RQ("file:../data/mapping.n3");
p_ontModel.add(d2rqMod);
        
// Step 1 - Create the directed Prefuse graph from the ontModel
OWLGraphConverter graphConverter = new OWLGraphConverter(p_ontModel, true);
Graph graph = graphConverter.getGraph();
        
// Step 2 - Create a graph display, using the graph distance filter.
GraphDisplay graphDisp = new GraphDisplay(graph, GRAPH_DISTANCE_FILTER);
        
// Step 3 - Create a panel for the graph display, showing the legend and the 
// widget to control the number of hops of the graph distance filter.
m_graphPanel = new GraphPanel(graphDisp, LEGEND, HOPS_CONTROL_WIDGET);
 
Hallo,

Also simpel ausgedrückt: der zeitaufwendige Teil des Codes soll irgendwie permanent laufen, nur hab ich quasi keine Ahnung, wie.
Habe mir erste Infos über Verteilte Client/Server Programme bzw. RMI angeschaut, aber ich befürchte das ganze wird etwas kompliziert, da ich ja ein ganzes Objekt (das OntModel oder später Graph, GraphDisplay, GraphPanel) übergeben muss. Außerdem weiß ich nicht genau, ob das initialisierte OntModel an dem Punkt "einsatzbereit" ist oder evtl. erst später bei Bedarf auf Datenbank und Ontologie-File zugreift...
Auch ist das OntModel, wenn ich das Prinzip richtig verstanden hab, nicht "serialisierbar", was die Lösung mit RMI wohl problematisch macht.

Also ich würde dir empfehlen in diesem fall doch RMI zu verwenden, da dies viel einfacher zu verwenden ist als händische LowLevel Socket Kommunikation und CORBA.

Je nachdem wie deine Serverseite ausschaut könntest du den Ontology Model Server beispielsweise als Servlet bzw.
als mini Server inner halb des ServletContainers (Tomcat,Catalina) laufen lassen. Dazu kannst du beispielsweise
einen ContextListener implementieren, der beim Start deiner WebAnwendung die RMIRegistry startet und die entsprechenden
Serverdienste via RMI exportiert (von aussen zugreifbar macht). Beim Beenden deiner Webanwendung wird dann der Service wieder "Unexported" und die RMIRegistry heruntergefahren.

Da dein OntologyModel, welches du am server erzeugst und am Client verwenden möchtest, nicht Serialisierbar ist musst du dort eben beim Server eine Serialisierbare (übertragungs optimierte) Repräsentation vom
eigentlichen Modell erzeugen und dies an den Client schicken.(So ne Art DTO, Data Transfer Object) Der Client muss dann natürlich wissen, wie er diese Repräsentation wieder in das ursprüngliche Modell umwandeln kann. Weiterhin gäbs noch die Möglichkeit die Serialisierung entsprechend anzupassen in dem man an den zu serialisierenden Objekten entsprechende readObject(...) / writeObject(...) definiert alternativ dazu gäbs dann noch die Möglichkeit mit dem Externalizable Interface.

Ein Beispiel zu RMI findest du hier:
http://www.tutorials.de/forum/java/231847-rmi-unter-java-5-a.html

Wenn du mit dem Applet dann via RMI auf den Server zugreifen möchtest musst du dem Applet entsprechende Berechtigungen mitgeben(policy Files, Permissions)
und es gegebenenfalls signieren:
http://www.tutorials.de/forum/java/232026-textdateien-mit-applet-auslesen.html

Gruß Tom
 
Hi Tom,

vielen Dank für die Tipps
RMI Client/Server zu erstellen ist kein Problem, das hab ich heute schon mal getestet. Aber wie erwartet ging das Übertragen wegen der fehlenden Serialisierbarkeit nicht.


Da dein OntologyModel, welches du am server erzeugst und am Client verwenden möchtest, nicht Serialisierbar ist musst du dort eben beim Server eine Serialisierbare (übertragungs optimierte) Repräsentation vom
eigentlichen Modell erzeugen und dies an den Client schicken.(So ne Art DTO, Data Transfer Object) Der Client muss dann natürlich wissen, wie er diese Repräsentation wieder in das ursprüngliche Modell umwandeln kann.

Hab ne Weile nach DTOs gesucht aber wenig konkretes gefunden, mit dem ich was anfangen konnte...bin leider auch alles andere als ein Java-Profi.
Kannst Du mir hierzu noch was genaueres sagen oder hättest Du idealerweise ein einfaches Beispiel? Das wär echt super!


Weiterhin gäbs noch die Möglichkeit die Serialisierung entsprechend anzupassen in dem man an den zu serialisierenden Objekten entsprechende readObject(...) / writeObject(...) definiert alternativ dazu gäbs dann noch die Möglichkeit mit dem Externalizable Interface.

An das zu serialisierende Objekt (OntModel) komme ich wohl leider nicht dran (bzw. es wäre etwas viel Arbeit), denn das steckt in externen Bibliotheken (jars). Damit fällt diese Variante wohl weg.


Vielen Dank nochmal

Gruß,
Flo
 
Hallo,

Hab ne Weile nach DTOs gesucht aber wenig konkretes gefunden, mit dem ich was anfangen konnte...bin leider auch alles andere als ein Java-Profi.
Kannst Du mir hierzu noch was genaueres sagen oder hättest Du idealerweise ein einfaches Beispiel? Das wär echt super!
Also in deinem Fall müsste ein DTO genau so viel Information Tragen wie du brauchst um dein Model Objekt an der Client Seite wieder aufzubauen. Zum effizienten Datenaustausch könnte man sich dann beispielsweise Implementierungsdetails zunutze machen und beispielsweise nur die Grundlegenden internen Strukturen Serialisieren / Umwandeln.

Hab mir das ganze mal angeschaut ( http://sourceforge.net/project/showfiles.php?group_id=111002 ) leider scheint die interne Struktur recht komplex zu sein was eine Implementierung einer eigenen Serialisierungsstrategie ohne weitere Kenntnisse dieses Frameworks IMHO nur schwer möglich macht. Deshalb würde ich hier nun folgendes ausprobieren. Scheinbar kann man ein Model in verschiedenen anderen Repräsentationen speichern (z.Bsp. ein im N3 Format eingelesenes Model als RDF etc.) (Hoffe ich erzähle keinen Quatsch). Jedenfalls würde ich einfach mal ausprobieren, ob ich ein Model das ich im n3 Format langwierig eingelesen und gebaut habe nicht in ein anderes Repräsentationsformat (mittels der entsprechenden Writer (RDFWriter?)) wandeln kann welches sich u.U. schneller wieder einlesen und aufbauen lässt. Dieses neue Model könntest du dann auf der Platte (oder in einem ByteArrayOutputStream) speichern und dieses dann an den Client Streamen. Dort verwendest du dann einen entsprechenden Reader um wieder dein Model herzustellen.

Gruß Tom
 
Hallo,
[...]
Hab mir das ganze mal angeschaut ( http://sourceforge.net/project/showfiles.php?group_id=111002 ) leider scheint die interne Struktur recht komplex zu sein was eine Implementierung einer eigenen Serialisierungsstrategie ohne weitere Kenntnisse dieses Frameworks IMHO nur schwer möglich macht. Deshalb würde ich hier nun folgendes ausprobieren. Scheinbar kann man ein Model in verschiedenen anderen Repräsentationen speichern (z.Bsp. ein im N3 Format eingelesenes Model als RDF etc.) (Hoffe ich erzähle keinen Quatsch). Jedenfalls würde ich einfach mal ausprobieren, ob ich ein Model das ich im n3 Format langwierig eingelesen und gebaut habe nicht in ein anderes Repräsentationsformat (mittels der entsprechenden Writer (RDFWriter?)) wandeln kann welches sich u.U. schneller wieder einlesen und aufbauen lässt. Dieses neue Model könntest du dann auf der Platte (oder in einem ByteArrayOutputStream) speichern und dieses dann an den Client Streamen. Dort verwendest du dann einen entsprechenden Reader um wieder dein Model herzustellen.

Gruß Tom

Hi Tom,

habe es heute wirklich mal mit dem RDFWriter / Reader probiert und das scheint eine sehr praktikable Lösung für mein Problem zu sein. Vielleicht nicht elegant, aber sehr praktikabel! :)
Irgendwie hatte ich das bisher ziemlich ignoriert und per se für unbrauchbar erklärt...

Vielen Dank für die Hilfe

Gruß,
Flo
 
Zurück