bolug bonner linux user group
news about wissen files archive hilfe suchen  

 

archive :: BoLUG

druckfassung

BoLUG

Re: Netzwerktransparente Objecte

To: BOLUG <bolug@xxxxxxxxxxx>
Subject: Re: Netzwerktransparente Objecte
From: Dirk Huenniger <hunniger@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 16 Sep 2005 14:34:54 +0200
>Ja, viele. Das hängt davon ab was du erreichen willst.
>
>Inzwischen sind Corba, (D)COM, OO-RMI und ... vom Sockel gestoßen. Alles was
>Objekte oder Referenzen darauf übers Netz überträgt wird mehr oder weniget
>verpönnt. Der Grund dafür ist schlechte / keine Skalierbarkeit. Sprichst du
>mit einem einmaligem, eindeutig adressierbarem Objekt bist du an sein Schicksal
>gebunden und wenn du nichts unternimmst stirbst du mit ihm.
>
>Der neue Trend heißt nun SOA (Service Oriented Architecture). Im Netz siehst
>du nur Dienste mit denen du nur Nachrichten austauschst. Bei diesem Entwurf
>ist es vollkommen egal mit wem du sprichst z.B. auf einer Server Farm. Der
>Scheduler könnte dir jedesmal einen anderen Sachbearbeiter zuweisen.
>
>Spätestens hier dämmert es langsam. Das ganze ist schon längst vorhanden.
>Nehne z.B. SunRPC. Das ist ein defacto Standard und so etabliert, dass IBM es
>sogar in BOS (Basic Operating System Services) intergriert hat. Abgesehen
>davon, dass es von jeder Platform unterstützt wird (auf der C Ebene) gibt es
>sogar eine reine Java Implementierung (irgendwo an der RWTH Aachen).
>  
>
Vielen Dank,
Eine Frage noch dazu...
Ersterns RPC für Python ist nicht wirklich frei. Mit einem RPC kann ich
eine Routine auf einem  Zielrechner aufrufen und bekommt einen wert
zurück. Objekte gibt es dort erst einmal nicht. In meiner Frage sagte
ich jedoch:

>/ Sei A eine Klasse/
>/ Sei B eine Klasse/
>/ /
>/ A und B seinen Netzwerktransparent implementiert./
>/ Herr X kompielirt ein Programm das anzeigt wie viele Instanzen vom A und/
>/ B zur Zeit auf einem bestimmten Server verfügbar sind./

Wo es keine Objekte gibt da gibt es auch keine Instanzen und man kann
auch kein Programm schreiben, dass anzeigt welche Instanzen von Objekten
gerade existieren. Danach habe ich gefragt und diese Frage hast du also
nicht beanwortet. Sorry will dir nix böses aber das ist nun mal so.
Natürlich ist mein Problem über RPC lösbar. Man kann eine methode auf
dem Zielrechner definieten, welche eine Liste aller auf dem Zielrechner
vorhanden Objekte zurückliefert. Ferner kann man für jedes Objekt  eine
Methode definieren, die zurückgiebt welche Attribute des Objects
wiederum Objekte sind und welcher Klasse sie jeweils angehören. Dazu
muss ich auf dem Zielrechner eine Ensprechende Verwaltungsstruktur
programmieren. Dann kann ich via RPC die beschreibenen Methoden aufrufen
und meine Infromationen erhalten. Und so dass Programm des Herrn X
schreiben und es funtioniert. Die hierzu notwendigen structuren sind
jedoch nicht in RPC enthalten sondern müssen von mir expliziet
programmiert werden. Insofern ist das von mir angegebene Problem unter
Verwendung von RPC alleine erst einmal nicht trivial. 

Meine Anwendung bezieht sich auf gebiete in denen wenig bandbreite zur
verfügung  steht. zB. Microcontroller über RS232 oder in
meine konkreten Fall 1m Teleskop eine über ISDN Leitung mit (kleinem)
Vorschaufenster und vielen Insturmenten. XML-RPC was wohl ein
verbreiteter Standart ist nutzt die Bandbreite nicht sehr effizient:

<methodCall>
   <methodName>examples.getStateName</methodName>
   <params>
      <param>
         <value><i4>41</i4></value>
         </param>
      </params>
   </methodCall>

Meine Anwendung bezieht sich auf Geräte Mirocontroller usw. Und dabei
gibt es drei Kernpobleme:

-Jeder Client muss jederzeit den Zustand aller Geräte kennen.
-Jeder Clinet darf jederzeit ein Operation in einem Gerät anstossen.
-Jeder Client darf jederzeit ein Operation in einem Gerät durchführen
und muss nach Beendiung über Erfolg / oer Misserfolg unterreichtet werden.
-Ein Gerät muss Introspezierbar sein. Dass heist es muss angbenen können
aus welchen Teilen es besteht und wie diese Teile heissen.
Ein Client der nichts über das gerät an sich weiss kann sich einloggen
die Liste der Teile erfragen und die Zustände aller teile des Gerätes
dem Benutzer anzeigen.

All diese Features hat wenn auch in grauenhafter implementierung hat das
INDI protokoll http://indi.sourceforge.net/.
Dafür habe ich auch einen Python Client geschrieben:
http://pygtkindiclient.sourceforge.net/
Das INDI Protokoll ist GROSSER MIST also NIEMALS benutzen (auch nicht
meinen Client). Allenfalls für reine Amateurprobleme
aber niemals im professionellen Bereich.  Es beweist das dass Konzept
der Introspection funktioniert und es ist stabil und man kann damit
geräte Steuern. Es bietet 4 Teile und man muss jedes gerät in diesen 4
Teilen modellieren. Man kann keine eigenen Teile hinzufügen. Die
Baumstruktur ist auf 3 Ebenen beschränkt und das XML ist von kleinen
Microcontrollern schwer zu parsen und überträgt noch recht viel
überflüssige information.

Ich möchte von einem Steurprotokoll weiterhin fordern
-Man darf dem Protokoll eigene Typen von Teilen hinzufügen.
-Das Protokoll braucht eine belibig tiefe Baumstruktur in der Geräte
geordnet werden können.
- Ein Client muss mit dem Server aushandeln welche Typen von Geräten
kommunizirt werden sollen und auch nur diese sollen kommuniziert werden.

Wenn es so ein Protokoll schon gibt ist es toll dann kann ich in meiner
Diplomarbeit u.ä. auch schreiben, dass man es benutzen soll. Und das
wäre super. Weil hier in unserem institut das noch keiner weiss. Wenn es
das noch nicht gibt muss ich hinschreiben das mal jemand so etwas machen
soll, und eine provisorische Protokolldefinition angeben.
Gruss Dirk


PS: Ich schreibe hier mal grob meine Idee hin:
Ich habe mir das jedoch nur für einen Spezialfall überlegt. Meine SOA
ist zur allgemeinen Instrumentensteurung gedacht und
extrem simpel gestrickt. Dafür kann man sie auch auf einem
Mircocontroller mit 8 Kbyte ROM und 1 Kbyte Implementieren und hat
noch genug Platz für Anwendungen. Weiterhin kommt eine Expat Parser
damit klar. Die Idee ist: Das Treiberprogamm im Microcontroller sagt dem
Protokollprogramm im Microcontroller, dass es ein Schaltbares Bit hat.
Dabei definiert es eine callbackroutine die aufgerufen werden soll
sobald jemand eine Änderung des Bits wünscht, ferner gibt er den
jetzigen zustand des Bits an. Ein Graphische Oberfläche schickt dem
Microcontroller eine Liste mit Services die sie versteht (unter anderem
auch Schaltbares bit). Das Protokollporgramm im Micorcontroller stellt
fest, dass es den Service schaltbares Bit versteht und schickt der GUI
den Zustand des Bits sowie ein je einen String für den einen und den
anderen Zustand des bits. Die GUI überlegt sich wo sie noch platz hat
und stellt das Bit als Lämpchen und daneben zwei beschriftete Schalter
für An und Aus dar. Klickt der Benutzer den Button, schickt die GUI den
Zustand des Schlaters jedoch nicht die Strings zurück. Das
Protokollprogramm im Mircocontroller ruft daraufhin die callback routine
im Treiberprogramm des Microcontrollers mit dem von der GUI gewünschten
Zustands des Bits auf und diese ändert das bit und informiert die
Protokollprogramm über den neun zustand des Bits, dieses wiederum die
GUI.  Das selbe Procedere für andere Services und eine einfache
Möglichkeit eigene servies zu definieren (callback mit binärdaten). In
der basisvariante sogar keinen einzigen sinnvollen service sondern nur
die möglichkeit sinnvolle services zu definiren. Dann noch ein Repeater
der über RS232 mit dem Microcontroller redet und über TCP/IP mit dem
Rest der Welt. Dynamisches GUI und API in einer platformunabhängingen
Hochsprache. Sowie eine belibig tiefe Baumstruktur in der Objekte
benannt sind. Ein Object ist hier einfach etwas was einen Namen hat und
services anbieten darf. Ein Service wird representiert durch ein XML
attribut. Ein Client bestellt irgenetwas bei einem service
in dem er das entrechede XML Attibut verschickt und als Wert einträgt
was es es genau von dem Service will. Der Service schickt auf selbigen
Wege die Ergebnisse des vom Client Bestellten aktion dar. Momentan habe
ich noch die nebenbedinung eingebaut, dass ein
Protokollprogramm im microcontroller ein XML attributs nicht
verschickten darf, wenn er sich nicht geändert hat, auch wenn das
Treiberprogramm dies wünscht. Ferner sich die GUI jederzeit neu
verbinden und so den erneuten versand der werte verlagen.









 « Vorige im Thread  Dieser Thread  Nächste im Thread » 

 

seitenanfang


 

news about wissen files archive hilfe suchen  
kontakt letzte änderung: 16.09.2005