Zyan Framework: Benutzung verschachtelter Objekte möglich?

Hallo.

Ich teste gerade etwas mit dem Zyan Framework von Rainbird rum und muss erstmal sagen, dass ich doch sehr begeistert bin. Endlich mal ein Framework in dieser Richtung, welches einem einiges abnimmt. Dafür schon mal Dank an Rainbird und Co.

Allerdings habe ich auch noch 2 Fragen:

1. Kann man mit Zyan auch komplexe Typen benutzen?
   Ich würde gerne so etwas machen:

Shared.IEchoServer proxy = connection.CreateProxy<Shared.IEchoServer>();
proxy.SubClass.Name = "4567";
string s = proxy.SubClass.Name; // = "1234"

Die Eigenschaft 'SubClass' gibt eine Referenz einer simplen Klasse zurück und diese hat eine Eigenschaft Name, welcher per Default auf "1234" gesetzt ist. Weise ich der Eigenschaft jetzt "4567" zu und rufe diese erneut ab, ist der Wert immer noch "1234". Geht das per se nicht, oder muss dafür etwas spezielles beachtet werden.

2. Wie verhält es sich mit der Lebensdauer eines Remoting-Objekts und was passiert, wenn das Gerät (CE-Device) eine neue IP-Adresse zugewiesen bekommt?

Danke

Gruß
Friedel

Hallo Friedel,

Endlich mal ein Framework in dieser Richtung, welches einem einiges abnimmt. Dafür schon mal Dank an Rainbird und Co.

Schön dass Dir das Zyan Framework gefällt.

1. Kann man mit Zyan auch komplexe Typen benutzen?

Zyan "denkt" in Komponenten, nicht in Objektmodellen. Du kannst nur auf Komponenten zugreifen, die Du vorher mit RegisterComponent veröffentlicht hast. Rückgabewerte von Eigenschaften dieser Komponenten werden nicht automatisch auch als Komponenten veröffentlicht.

Generell solltest Du serverseitig so statuslos wie möglich programmieren. Zyan trägt dem Rechnung indem Komponenten standardmäßig SingleCall-aktiviert veröffentlicht werden. Das heißt, für jede Clientanfrage wird eine separate Instanz erzeugt und nach Verarbeitung der Anfrage gleich wieder entsorgt. So bleibt der Server völlig statuslos, skaliert optimal und kann auch in Verbindung mit Enterprise-Features wie Netzwerklastverteilung eingesetzt werden.
Alternativ kann man Komponenten Singleton aktiviert veröffentlichen. Dabei wird eine gemeinsame Instanz der Komponente erzeugt und zur Verarbeitung aller Clientanfragen verwendet (Singleton Komponenten müssen deshalb threadsicher programmiert werden). Singleton-Instanzen leben solange, wie der Komponentenkatalog existiert. Es wird nicht - wie bei Remoting - mit Leases und Sponsoren gearbeitet. Clientaktivierte Objekte unterstützt Zyan überhaupt nicht. Und das ist auch gut so. Die wären nämlich Gift für die Skalierbarkeit.

Du solltest nicht klassisch objektorientiert denken, wenn es um verteilte Anwendungen geht. Die Objektorientierung predigt Vereinigung von Logik und Daten in Klassen. In einer verteilten Umgebung taugt dieser Ansatz nichts. Da musst Du Logik und Daten strikt voneinander trennen. Und die Logik vorzugsweise statuslos halten. Wenn Du doch mal Status brauchst, bietet Zyan dafür Sitzungen und Sitzungsvariablen an (wie z.B. bei ASP.NET üblich).

Ich würde gerne so etwas machen:

  
Shared.IEchoServer proxy = connection.CreateProxy<Shared.IEchoServer>();  
proxy.SubClass.Name = "4567";  
string s = proxy.SubClass.Name; // = "1234"  
  

Welchen Wert sollte proxy.Subclass.Name haben, wenn ein anderer Client die Eigenschaft abfrägt?
Ich kann Dir nur von dieser Vorgehensweise abraten (unabhängig davon, ob man das mit Zyan hinbekommt, oder nicht; Für Zyan 3.0 ist ein Feature geplant, um Komponentenreferenzen zurück zum Client geben zu können). Du hättest dabei den Status auf dem Server. Der Status sollte beim Client liegen.

Die Eigenschaft 'SubClass' gibt eine Referenz einer simplen Klasse zurück und diese hat eine Eigenschaft Name, welcher per Default auf "1234" gesetzt ist. Weise ich der Eigenschaft jetzt "4567" zu und rufe diese erneut ab, ist der Wert immer noch "1234". Geht das per se nicht, oder muss dafür etwas spezielles beachtet werden.

Standardmäßig wird Deine Komponente SingleCall aktiviert veröffentlicht. Sie lebt also immer nur einen Methodenaufruf lange und vergisst danach alles (was nicht persistiert wurde, oder eine Sitzungsvariable ist). Du könntest die Aktivierungsart auf Singleton ändern (bei RegisterComponent als Parameter angeben). Damit wäre das Problem, dass Subclass nicht als Komponente registriert ist, aber noch nicht gelöst.

2. Wie verhält es sich mit der Lebensdauer eines Remoting-Objekts und was passiert, wenn das Gerät (CE-Device) eine neue IP-Adresse zugewiesen bekommt?

Lebensdauert für ...
... SingleCall-Komponenten: 1 Methodenaufruf lang
... Singleton-Komponenten: Solange der Komponentenkatalog existiert, in welchem die Komponenten registriert wurden.

Solange Du weder Events noch Callbacks verwendest, sollten wechselnde IP-Adressen kein Problem sein. Falls Du aber Events/Callbacks verwendest, könnte es sein, dass nach dem Wechsel der IP-Adresse Events nicht mehr gefuert und Callbacks nicht mehr aufgerufen werden, da die zwischengespeicherte Rückrufadresse ja nicht mehr stimmt. Nur wenn alle beteiligten Geräte über DNS-Namen verfügen, können Events/Callbacks auch nach einem Adresswechsel korrekt angesprochen werden. Das TcpDuplexProtocolSetup hat momentan genrell noch Probleme mit wechselnen IP-Adressen (ist ja aber auch noch nicht ganz fertig).

Wenn Du mir genauer beschreibst, was Du mit Zyan machen wilst, kann ich Dir detailliertere Vorschläge machen.

Hallo Rainbird.

Vielen Dank erst mal für deine Ausführliche Antwort.
Irgendwie habe ich mir das schon gedacht, dass mein
Ansatz irgendwie nicht so toll ist. In kein Framework passt
das Konzept.

Da du mir angeboten hast, mein Problem genauer zu schildern,
mache ich dies jetzt einfach mal: 😃

Ich habe eine Anwendung auf einem PC, welche per Remoting mit
einem Windows-Dienst arbeitet. Dieser Dienst wiederrum kann sich
mit beliebig vielen anderen PCs mit diesem laufendem Service
verbinden, oder sich direkt mit mehreren CE-Geräten. Es ergibt
sich so ein Baum mit beliebiger Tiefe. An jedem Endknoten des
Baumes ist ein CE-Gerät zu finden.
Die CE-Geräte zeichnen unentwegt Daten auf (Messdaten).
Ich hatte mir überlegt, eine Komponente (DeviceController) zu schreiben,
welche sowohl als Service als auch auf den CE-Geräten läuft. Mit Hilfe
von sognannten (DeviceController-)Services hätte man die
DeviceController entsprechend ihrer Aufgaben parametrieren können.
Eine der wichtigsten Aufgaben wäre das Sammeln der Daten der
angeschlossenen DeviceController gewesen (z.B. einmal am Tag
alle angefallenen Daten abholen), diese zu analysieren und
dann auf geeigneten Medien zu speichern. Auf Anfrage von wiederrum
darüber liegenden DeviceControllern rückt der entsprechende DeviceController
diese gesammelten und analysierten Daten raus.
(So ergibt sich zum Beispiel Kassel-Nord + Kassel-Süd = Kassel,
Kassel + Wolfhagen = Nordhessen, Nordhessen + Südhessen = Hessen, usw.)
Diese DeviceController-Komponente wollte ich nun per Remoting übermitteln.
Damit wäre es egal gewesen, wo ein DeviceController in der Hierarchie ist,
ich hätte diesen einfach anzeigen und parametrieren können, da ja
alle gleich sind und sich "nur" durch ihrer (aktiven) Services
unterscheiden.

Ich hoffe ich habe den Sachverhalt einigermaßen verständlich beschreiben.

Danke, dass du dir überhaupt die Zeit nimmst über mein Problem nachzudenken.

Gruß
Friedel

Nachdem ich jetzt noch mal etwas Zeit hatte, mir das ganze anzusehen, scheint es ja gar nicht möglich zu sein, dass Zyan-Framework auf einem Windows CE-Gerät laufen zu lassen, da z.B. wichtige DLLs wie System.Runtime.Remoting fehlen. Habe wohl Microsoft .NET Framework 3.5 Client Profile und Compact Framework 3.5 (leider) durcheinander geworfen. Dann ist dieses Framework, so gut es auch für "normale" PCs funktioniert, für mich nicht zu gebrauchen; wie so viele andere Frameworks auch.

Langsam verliere ich gewaltig die Lust an Remoting und Compact Framework. Ich kann einfach nicht glauben, dass ich der einzige bin, der für oben beschriebenes Szenario eine Lösung braucht. Wieso wurde im CF so eine Funktionalität einfach entfernt? Klar, irgendwas muss raus, aber das komplette Remoting inkl. Serialisierung der Objekte? Wer bitte hat das entschieden?

Trotzdem tolles Framework von dir Rainbird. Danke, dass du meine Fragen so ausführlich beantwortet hast.

Wenn ich mich Irre und Zyan doch auf CE lauffähig wäre, wäre das ein Fehler von mir, über den ich mich sehr freuen würde 😉.

Gruß
Friedel

Hallo Friedel,

direkte Kommunikation über Remoting (und damit auch Zyan, da dies auf Remoting aufgebaut ist) geht mit dem Compact Framework leider nicht. Für die Remoting-Unterstützung fehlen wesentliche Features wie Reflection und Binärserialisierung.

Es gibt allerdings eine kommerzielle Bibliothek, die .NET Remoting fürs Compact Framework nachrüstet: http://gotcf.net/Default.aspx

Ist allerdings nicht kostenlos. 499 US$ für eine Entwicklerlizenz und 10 CE-Gerätelizenzen.

Alternativ kannst Du Webservices verwenden, um zentral Funktionalität für Deine CE-Geräte anzubieten. Das ist zwar in Sachen Komfort von Zyan weit entfernt, aber dafür mit CF Bordmitteln machbar.

Für eine zukünftige Zyan Version ist ein Silverlight-Client angedacht. Bisher ist das allerdings nur eine Idee. http://zyan.codeplex.com/workitem/783

Wenn Du sowohl volle .NET-Clients als auch CF-Clients hast, kannst Du Zyan auch für die vollen .NET Clients einsetzen und die Zyan-Komponenten mit Webservices für die CF-Clients wrappen.

Gruß

Rainbird

Hallo Rainbird.

Ich habe AsGoodAsItGets schon probiert und was soll ich sagen, der Name ist Programm. Es gibt einfach keine "gute" Lösung für Remoting auf dem Compact Framework. Ist halt so. Aber mit AsGoodAsItGets ist es zumindest möglich.

Danke für die Antworten.

Gruß
Friedel

PS: Ich werde Zyan auf jeden Fall im Auge behalten.