Hi!
Warum soll die Kommunikation über Rechner- und Netzwerkgrenzen
hinweg nicht funzen?
„Funzen“? Süss… *streichel*
Sie funktioniert, ist aber meines Erachtens nach für die Anwender viel zu kompliziert gelöst.
Der von dir beschriebene Anwendungsfall ist aus meiner Sicht
schon JMS lösbar (bin nicht so der JMS-Experte, aber das ist
ja nur ein Prinzip):
Klar, aber eben viel komplizierter als es sein müsste und zudem noch abhängig von der Implementierung. Die Standardimplementierung von SUN ist kostenpflichtig, die Alternativen sind nicht komplett oder interpretieren Teile der Spezifikation unterschiedlich, so dass ein späterer Wechsel zu einem anderen System oft nicht bzw. nur mit sehr viel Aufwand möglich ist.
Wenn der Server die Kenntnis der Listener hat, dann kann er
sowohl einen Vorwärts- als auch Rückwärtskanal aufbauen. Ob
dies nun via Queue oder Topic gelöst wird, sei mal
dahingestellt.
Klar geht das, aber diese ganze Arbeit (Öffnen der Kanäle auch für die Antwort, Synchronisation bei synchroner Kommunikation, Sammeln der Antworten von mehreren Listenern, Beachten von Timeouts falls kein Listener antwortet, etc.) bleibt beim Anwender hängen! Der kann bei keiner mir bekannten Implementierung so etwas einfaches machen wie beispielsweise:
IrgendEinObject response = MessageSystem.publish(kanal, nachricht, timeout);
Und beim Versenden des Events kann er ja eine angemessene Zeit
auf Antwort von allen Listenern warten und diese dann
verwerten. Thema Multithreading.
Siehe oben - man muss sich um alles selbst kümmern. Das führt meiner Meinung nach den Sinn einer solchen Library ad absurdum, da sie dem Anwender die Arbeit nicht erleichtert.
Zumindest wäre dies jetzt mein Ansatz, das Problem zu lösen.
Aber ich komme nicht aus der Web-Ecke, daher kann ich auch
falsch liegen.
Das ist noch ein zusätzliches Problem. Bei webbasierten Anwendungen sind so viele verschiedene Techniken im Einsatz, die zu einem System zusammen setzen muss, dass eine synchrone Kommunikation von einer webbasierten Anwendung, die abhängig von der Aktion des Anwenders im Browser eine Aktion auf dem Server auslöst, deren Antwort auf dem Client verarbeitet werden soll, eine ziemlich komplizierte Sache darstellt.
Beispiel:
Der User markiert im Browser einen Datensatz, den er löschen möchte und klickt auf „Löschen“. Dies löst im Browser ein JavaScript aus, das eine Nachricht mit dem Kontext (diesen Datensatz löschen) an den Server schickt. Dieser publiziert diese Nachricht auf dem Server (z.B. Tomcat), woraufhin die darauf registrierten Listener (z.B. in Java entwickelt) anlaufen, die Nachricht verarbeiten und darauf reagieren. Einer der Listener schickt ein „ok, es darf gelöscht werden“, ein anderer Listener schickt ein „Es sind Abhängigkeiten vorhanden. Sollen diese auch gelöscht werden?“. Diese Antworten werden vom Message-System gesammelt und als Antwort an den Client geschickt. Dieser hat brav gewartet und muss nun einen Dialog für den User anzeigen, z.B.: „In dem Ordner XY befinden sich noch 7 Dateien. Möchten Sie den Ordner wirklich inklusive der Dateien löschen?“. Antwortet der User mit „Ja“, wird wieder eine Nachricht an den Server geschickt, welcher den Löschvorgang dann ausführt.
Versuche dieses, bei Webanwendungen alltägliche, Szenario mal mit einer der vorhandenen Implementierung (egal, ob JMS oder nicht) abzubilden. Du codest dich für diese eine Aktion zu Tode! Ergo: Viel zu kompliziert in der Anwendung.
Dennoch wäre es interessant, wenn ihr da schon etwas eigenes
stricken wollt, wenn du hier entsprechende Infos dazu
hinterlässt.
Gerne - wir haben bei uns in der Firma entschieden, eine Akstraktionsschicht zu entwickeln, die auf bekannten Technologien aufsetzt (z.B. Prototype, Apache ActiveMQ), die sich jedoch austauschen lassen (Plugin-Prinzip), welche für den Anwender (Entwickler) jedoch ungleich einfacher zu benutzen ist und obige Szenarien kapselt.
cu
McPringle
