Qual der Wahl: HTTPService, Webservice oder RemoteObjects?

[RAHSKAR_II]

Hi!

Stehe vor der Aufgabe zum ersten Mal eine Serverkommunikation mit Flex zu erstellen (Datenbankanwendung) und kann mich nicht entscheiden, welche die beste/einfachste/sicherste Herangehensweise ist.

So wie ich das sehe steht zur Wahl


HTTPService
Webservice über SOAP+WSDL
RemoteObjects über AMFPHP, ColdFusion oder andere Drittanwendungen


Als Backend würde ich PHP + MySQL bevorzugen, wäre aber auch gegenüber anderen Techniken nicht unbedingt abgeneigt.

Kriterien meiner Anwendung sind:


Benutzerkontensteuerung (also Zugriffserlaubnis muss stets überprüft werden)
Video-Streaming (wobei dies möglicherweise unabhängig von der Entscheidung hier ist?)
große Datenmenge, häufige Serverzugriffe


Ich konnte leider nirgends eine direkte Gegenüberstellung (jedenfalls nicht nach dem Prinzip "das ist hier besser als das") finden und frage deswegen nach Euren persönlichen Erfahrungen und Vorlieben.

Grüße,
Maik

[Brunôt]

Wenn Du keinerlei technische Beschränkungen hast, würde ich es zuerst einmal mit der kostenlosen Version der LifeCycle Data Services bzw. BlazeDS probieren. Nachteil: Du bist dabei an diese Technologie bzw. Hersteller gebunden.

Mit SOAP bist Du unabhängig vom Hersteller - sowhl client- als auch serverseitig. Du könntest z.B. den Flex- durch einen .Net-Client austauschen. Oder serverseitig von PHP auf Java, C# ... umstellen. Nachteil bei SOAP: grosser Overhead beim Datentransfer und beim Ein-/Auspacken der Daten.

[RAHSKAR_II]

Hallo!

Ich bin immernoch am Suchen nach der besten Möglichkeit die Serverseite zu programmieren, denn ich will auf keinen Fall irgendwann vor der Aufgabe stehen alles für eine andere Technologie zu portieren.

Das ich Remote Objects verwenden werde ist nun bereits klar, die Gründe hierfür:


HTTPServices sind zu simpel und sind auf der Client-Seite im Code unschön zu verwenden, außerdem erhält man nur untypisierte Objekte zurück oder muss auf Serverseite umständlich XML-Tags um die Daten herum basteln.
SOAP bzw. Webservices sind zu overheadlastig (sowohl was den Transport übers Kabel angeht, als auch die Programmierung (wenn ich mir nur diese WSDL-Dateien angucke...))
Remote Objects erlauben gegenüber Webservices und HTTPServices nicht nur die Verwendung des schnellen binären Übertragungsformat AMF3 sondern man hat die Möglichkeit Klassentypen auf Client-Seite mit Serverklassen zu mappen und erhält so als Result-Objekte bereits typisierte Objekte, die nicht mehr konvertiert werden müssen.


Nun hab ich mir zur Verwendung von Remote Objects AMFPHP, Weborb und SabreAMF genauer angesehen und würde davon Weborb bevorzugen. Die Management-Console und der Service-Browser sind wirklich nett. Außerdem sind in AMFPHP alle Pfadangaben Unix-Style (also "/", statt "\"), was den Einsatz unter Windows nicht (bzw. nicht ohne weiteres) möglich macht. Weborb setzt dagegen je nach Betriebssystem "/" oder "\". Ich möchte unter Windows entwickeln, aber das Produkt unter Linux einsetzen.

Mit dem oben empfohlenen BlazeDS kann ich leider nicht so warm werden, da die Informationen hierzu im Internet leider noch (ist ja noch nicht lange Open Source) sehr rar gesät sind. Außerdem verwirrt es mich, dass die LifeCycle Data Services ständig in Verbindung mit PDF und interne Firmenorganisation genannt werden(??). Ich weiß momentan nicht einmal ob es Streaming beherrscht.

Dies ist eine gute Überleitung, die mich zu meiner eigentlichen Frage führt ;-).

Da Weborb für PHP leider kein Streaming oder Server Push beherrscht, wäre hier Red5 eine Ersatzlösung (nein, den Flash Data Server können wir nicht bezahlen ;-) ).

Kann man Red5 als vollwertigen Ersatz zu z.B. Weborb + PHP verwenden oder ist es gebräuchlicher beides nebeneinander laufen zu lassen? Ist also Red5 vorwiegend auf Streaming ausgelegt und z.B. nicht für den massiven Einsatz von "einfachen" Remote Object-Calls, die vorwiegend Datenbankabfragen machen, geeignet?

[Psycho2481]

Wow, das nenne ich mal eine Auslegung!

Ich schlafe seit Anfang der Woche nicht ruhig, weil ich ein Flex/mysql-Projekt gestartet habe und keinen blassen Schimmer hatte, wie ich das ganze sicher mache. Deine Argumentation hat mir gerade ein Magengeschwür weniger verpasst ;-)

Danke dafür!

[RAHSKAR_II]

Meine weiteren Erkenntnisse seitdem:

Habe Red5 ausprobiert und obwohl ich sagen muss, dass ich glaube, dass das ganze ne super Sache ist und man auch ein gesamtes Projekt mit Red5 machen könnte, hab ich es erstmal wieder sein gelassen, der Grund:

Die verfügbaren Dokus sind grauenhaft.

Ich habe auch nach ewigem googlen nichts brauchbares gefunden, die zwei/drei Tutorials die man sofort findet sind der hinterletzte Sch***, drucken nur Code ab ohne zu erklären. So kam es also dazu, dass ich zwar eine remote Funktion aufrufen konnte (dank des einzigen brauchbaren Tutorials auf www.video-flash.de, was aber genau nach dieser Stelle aufhört), aber keine Ahnung habe, wie das jetzt mit Streaming oder Shared Objects funktionieren soll.
Auch eine javadoc bzw. Adobe ähnliche Hilfe gibt es, ist aber um Längen schlechter.

Deswegen habe ich es erstmal wieder sein gelassen und muss zunächst ohne Streaming auskommen.


2 nicht so schöne Sachen die mir bis jetzt im Zusammenhang mit Weborb aufgefallen sind:

- Möchte man Dateien uploaden (über Filereference::upload() ) hat man das Problem, dass man diese interne AS-Funktion nicht mit Remote Objects in Verbindung bringen kann, sondern man muss einen URLRequest machen und damit auf Serverseite ein normales php-Skript warten haben, das ohne Weborb (das gilt natürlich auch für AMFPHP, SabreAMF usw.) operiert. Dies ist nicht so schön für die Programmarchitektur.

- Eine Benutzerauthentifizierung ist nicht über die ActionScript Funktion setCredentials() möglich, wenn man den Benutzer gegen eine Datenbank authentifizieren möchte, sondern nur über Klartextdateien. Das ist eine Schwachstelle von Weborb. Ich habe die Entwickler hier ( http://www.themidnightcoders.com/forum/default.aspx?g=posts&m=1491ד ) gefragt, ob sich das in der bald kommenden Version 3 ändern soll, habe aber die Antwort nicht ganz verstanden... Eigentlich gibt es für die aktuelle Version 2.0.2 einen manuellen Quelltextpatch der im gleichen Forum beschrieben wird, aber bei mir nicht funktioniert hat.

So long,
Maik