Client-Server Architektur oder anderes ?

[hanspeter]

Ich plane gerade das Redesign einer größeren Applikation.
Das Programm ist vom Ansatz her eine "klassische" Client-Serverlösung.
Es wird mit Select eine Liste angefordert und angezeigt.
Ein einzelner Datensatz wird bearbeitet und zurückgeschrieben.
Das Rückschreiben zieht eine Reihe Aktionen nach sich, die jetzt auf dem Client ausgeführt werden
und dann in die Datenbank übertragen werden.(Teilweise über WLAN)
Ein Teil der Verarbeitung erfolgt in stored Procedure , die mir aber teilweise zu unflexibel sind.
Externe Procedures wären eine weitere Möglichkeit.

Inzwischen experimentiere ich aber auch mit einem Interface auf Basis von SOAP.
Also zwischen Firebird und den Clients noch ain Applikationsserver.
Der Ansatz scheint mir im Moment sehr interessant.

Statt die gesamte Verarbeitung im Client, werden die Rohdaten auf dem Server abgeliefert und dort
von Serviceprogrammen verarbeitet. Das Ergebnis könnte asynchron dann zurückgegeben werden.

Dazu würde ich mich über Meinungen freuen.

Gruß Peter

[p80286]

Hallo Peter,

schwierig dazu etwas allgemeingültiges zu sagen. Ich würde das so aufbauen, das der Datenverkehr minimiert wäre. Also z.B. beim Eintragen eines neuen Datensatzes, den Benutzer und die Eintragunszeit/Datum durch die DB generieren lassen. Oder voneinander abhängige Tabelleneinträge auf dem Server verarbeiten z.B. Bei Löschung eines Liferanten auch gleich die zugehörigen Adresssätze löschen (wenn kein Verweis auf andere Lieferanten vorhanden ist!). Auf der anderen Seite sollten Funktionen wie z.B. Datumsprüfung eher auf dem Client laufen.

SOAP sehe ich da eher kritisch. Ich benutze als Anwender eine DB die die Kommunikation über SOAP abwickelt (abwickeln kann) und ich bin damit nicht richtig glücklich, aldiweil sie des öfteren eine "Konrad Zuse Gedenkminute" einlegt. Aber das ist natürlich auch stark von der Infrastruktur und dem Netzverkehr abhängig.

Gruß
K-H

[mjustin]

Einige Punkte die für einen Applikationsserver und Web Services sprechen:

* die Logik ist zentral, aber nicht in der Datenbank hinterlegt (SQL-Prozeduren sind in 24/7 Umgebungen nicht empfehlenswert, wenn anläßlich einer Änderung alle Benutzer das System verlassen müssen)

* Änderungen an der zentralen Anwendungslogik erfordern keine Änderung der Clients

* über Web Services ist die API der Anwendung fest definiert, Clients können in verschiedener Weise erstellt werden: GUI Frontend, Kommandozeilentools oder Dienste, Webanwendungen - auch in verschiedenen Programmiersprachen nebeneinander

* Lastverteilung (Skalierbarkeit): man kann einfach ein paar Server draufwerfen, wenn die Anwendung bei wachsender Anzahl Clients den Applikationsserver überlastet

Standards wie SOAP oder REST (für synchrone Verarbeitung) und Message Queues (für asynchrone Auftragsverarbeitung) helfen ab einer bestimmten Anwendungsgröße sehr, den Boden nicht zu verlieren - erfordern aber auch einen etwas höheren Aufwand...

Cheers,

[hanspeter]

Zitat von mjustin:

Standards wie SOAP oder REST (für synchrone Verarbeitung) und Message Queues (für asynchrone Auftragsverarbeitung) helfen ab einer bestimmten Anwendungsgröße sehr, den Boden nicht zu verlieren - erfordern aber auch einen etwas höheren Aufwand...
Cheers,

Ich habe jetzt mein erstes ASP.NET Projekt fertig gestellt und bin von der Webtechnologie recht angetan.
Da mir bei einem Programm( >1.2 Mio Quellzeilen) langsam die Komplexität über den Kopf wächst, suche ich nach einer Lösung.
Viele Aufgaben die jetzt vom Client erledigt werden, könnten eigentlich von zentralen Serverproceduren erledigt werden. Da Firebird keine Transaction
in SP kennt, bleibt eigentlich nur die Lösung auf dem Server Verarbeitungsprogramme anzutriggern.
SP in Firebird, besonderst wenn sie mit vielen Datenbankoperationen länger laufen, erzeugen mir immer wieder einen deadlook.
Die Möglichkeiten mit Delphi ein großes Programm zu modularisieren, sind einfach zu beschränkt und störanfällig.
Das konkrete Programm steuert große Sportveranstaltungen.
Hier mal ein Beispiel:
Ein externer Client ist ein Richterarbeitsplatz. Hier wird eine Startliste und eine temporäre Ergebnisliste vom Server angefordert und angezeigt.
Im Polling muss gelegentlich nachgefragt werden, ob sich etwas in der Liste geändert hat. Ein Serverrequest bei Listenänderung wäre die bessere Lösung.
Es wird ein Ergebnis erfasst. Das Ergebnis wird in der Ergebnisliste einsortiert und es erfolgt eine temporäre Platzierung. Bereits die Ergebnissortierung ist nicht trivial und erfordert unter Umständen mehrere Durchläufe.(z.B. kombinierte Wertungen.) Danach muss die neue Rangierung auf dem Server geschrieben werden.
Diese Rangierung wird z.B. life von Anzeigeplätzen und vom Fernsehschriftgenerator abgerufen.
Was ich mir, mit den Webtechnologien im Hinterkopf vorstelle ist ein quasi asynchroner Betrieb.
Der Client fordert eine Startliste an und zeigt diese an.
Immer wenn sich in dieser Liste etwas ändert, dann sendet der Server einen Request.
Der Client schickt ein Ergebnis zum Server.
Der Server ordnet dieses ein, nimmt die Rangierung vor und sendet dann einen Request, das sich im Ergebnis etwas geändert hat.
Der betreffende Client holt sich dann die neue Liste ab.
Der Effekt, den ich mir vorstelle, wäre auf dem Server eine GUI lose Programmierung Baustein Input - Baustein Output ein fast linearer Programmablauf.
Firebird kann zwar einen Event schicken. Diesen Event kann ich aber nicht mit zusätzlichen Spezifikationen versehen. Die Abfrage des Events erfolgt letztendlich im Polling-Betrieb.
Hier bin ich gerade dabei die Möglichkeiten modernerer Technologien auszuloten und deshalb für jeden Ratschlag dankbar,

Peter

[Bernhard Geyer]

SOAP würde möglichst vermeiden (Interop/Performance/Sicherheitsaspekte). Nicht ohne Grund sind schon viele SOAP-Schnittstellen von Google/Amazon & Co. wieder verschwunden. Wenn dann ein REST-Ansatz auf "alte" Schnittstellen.

[Phoenix]

Ich bin gerade dabei einen (kleinen!) Bugtracker zu entwickeln, und zwar als 3-Tier Lösung.

Das Projekt brauche ich noch für mein Studium

Das Backend wie gehabt eine stinknormale Datenbank (dabei soll es wirklich vollkommen egal sein, ob MS SQL, Oracle, MySQL oder was anderes), das Middle-Tier sollen ASP.NET Web services sein (die dann sowohl SOAP als auch REST-Like angesprochen werden können). Vorne ist vorerst 'nur' eine Silverlight-Anwendung geplant, möglicherweise aber auch eine kleiner Windows-Forms Applikation zur Verwaltung (User management etc., je nachdem, ob das bei Winforms oder Silverlight schneller implementiert ist - das wird sich zeigen).

Damit ich mich nicht um den Datenbankzugriff kümmern muss, will ich einen OR-Mapper einsetzen, und habe mich in einer 20-Seitigen Analyse (das Projekt hab ich noch für mein Studium gebraucht ) für NHibernate entschieden. Zum einen weil es kostenlos ist, und zum anderen weil man damit wohl wirklich alles sauber und Testbar abdecken kann.

Das ist der nächste Punkt - ich will das Projekt wirklich sauber durchziehen. Das heisst Unit-Tests für jede Klasse mit einem Verhalten (dumme Klassen die nur Daten/Properties haben und keine Methoden braucht man nicht testen), Integrationstests für jede Funktionalität.

Das klingt alles sehr gut, sehr professionell und vor allem sehr sauber. Ich weiss aber schon gar nicht, wie ich anfangen soll und wollte gestern beginnen. Ich habe es dran gegeben und einen halben Tag nur nach Infos im Netz gesucht, wie man am besten die Daten zwischen Mittelschicht und Client austauscht (DataTransferObjects), war mir dann aber auf einmal nicht mehr sicher, wie ich meine Businesslogik von NHibernate entkoppele. Performance wegen lazy loading waren da meine Bedenken, und die Business-Objekte wären sonst auch extrem eng gekoppelt.

Kurzum: Ich habe mir erstmal zwei Bücher bestellt, von denen ich mir erhoffe dass sie meine Fragen beantworten.
Ich weiss, dass ich den Bugtracker mit Delphi in knapp einer Woche hinrotzen könnte, aber die Lösung wäre dann auf Windows begrenzt, nicht drei- sondern Zwischichtig und hätte mit Sicherheit ziemlich genau 0 Unit-tests. Ich schätze ich brauche 5-6 Wochen, wenn ich das 'professionell' machen will (ginge genauso mit Delphi, nur läuft die Mittelschicht dann leider nicht auf Linux- bzw. Mac-Servern, und das sollte schon drin sein).

Mit 3-Tier (inbesondere wenn Du auch in der Mittelschicht eine saubere Architektur haben willst) bürdest Du Dir ungeheuer viel Arbeit, Recherchen und Frustration auf - und das, bevor Du auch nur eine einzige Zeile geschrieben hast. Ich bin mir zwar ungeheuer sicher, dass sich das hinterher auszahlt.

Durch Test-Driven-Development hast Du eine bessere Trennung und bist vor allem gezwungen, alles was Du codierst zu testen, und der Aufwand - auch wenn er nur ein klein wenig höher ist - sorgt dafür, dass Du beim Entwickeln kein Feature-Creeping betreibst (also mehr als gefordert einbaust), und es zeigt Dir durch die fehlschlagenden Tests sofort auf, wenn Du später durch eine Änderung irgend was wichtiges kaputt gemacht hast. Das sorgt für weniger Fehler und damit zu einem viel geringeren Wartunsgaufwand (und zusätzlich dem Vorteil, dass eine Fehlerbehebung weniger neue Fehler produziert).

Möglicherweise werde ich den Bugtracker mal als Produkt rausbringen, deswegen will ich diesen Aufwand treiben (ausserdem muss ich darüber eine 40-Seitige Dokumentation bei meiner Hochschule abgeben, das geht mit einem 1-Wochen Delphi Projekt nicht ), aber wenn das Vorhaben kommerziell ist, dann würde ich mir ganz ehrlich folgendes Überlegen:

• 3-tier ohne Tests ist kommerzieller Selbstmord (durch zu viele mögliche Fehlerquellen)
• 3-tier stellt hohe Anforderungen an die Kunst des Schnittstellen-Designs
• die Komplexität einer Anwendung erhöht sich massiv
• Den Vorteil sieht man erst viel später

Ich würde den Ansatz also nur wählen, wenn er wirklich erforderlich ist, und dann vor allem auch konsequent Umsetzen. Die Gefahr ist groß, dass Du mit einer Security-Überprüfung nur einen Button auf der Oberfläche ausblendest, diese Überprüfung aber in der Mittelschicht vergisst (kann ja eh keiner Auslösen...). Doch, denn eine REST Schnittstelle kann jeder zur Not mit einem Browser bedienen.

Ich will Dich um himmels willen nicht davon abhalten - aber es wird ziemlich Aufwändig werden.

[mjustin]

Zitat von hanspeter:

Firebird kann zwar einen Event schicken. Diesen Event kann ich aber nicht mit zusätzlichen Spezifikationen versehen. Die Abfrage des Events erfolgt letztendlich im Polling-Betrieb.
Hier bin ich gerade dabei die Möglichkeiten modernerer Technologien auszuloten und deshalb für jeden Ratschlag dankbar,

Peter

Für asynchrone Eventübermittlung mit Nutzdaten, die ganz ohne Polling auskommt, gibt es Message Broker (z.B. Apache ActiveMQ oder OpenMQ, beide Open Source) und Message Queues (z.B. Microsoft Message Queue MSMQ, das mittlerweile schon in jeder Windows Vista Home Ausgabe enthalten ist).
Mit den entsprechenden C#, C oder Delphi Clients kann man dann an der Stelle, an der das Event erzeugt wird, eine Nachricht an den Broker senden, mit allen erforderlichen Parametern. Der Broker hält diese Information für alle interessierten Clients bereit (publish/subscribe, wie ein "Broadcast") oder sendet sie an exakt einen "Worker"-Client (peer-to-peer, z.B. für Lastverteilung). Sender und Empfänger müssen nicht gleichzeitig am Broker angemeldet sein, und auch bei einem Neustart des Brokers gehen die Nachrichten nur verloren wenn die Persistenzfunktion nicht verwendet wird. Mehrere Broker können für erhöhte Ausfallsicherheit auch in Clustern zusammenarbeiten.

Viele Internet Anwendungen machen Gebrauch dieser asynchronen Kommunikation. Wer sich also jenseits von Datenbanken und Web Services nach Lösungen umschaut, landet schnell bei Message Oriented Middleware:

http://de.wikipedia.org/wiki/Message...ted_Middleware

Und weitere Infos z.B. hier:


ActiveMQ, skalierbare Infrastruktur durch Messaging
http://www.topfstedt.de/weblog/?p=292

Enterprise Middleware mit ActiveMQ
http://www.swissitmagazine.ch/softwa...rticles/158881

Dopplr: It's made of messages
http://www.slideshare.net/carsonifie...h-presentation


Nachtrag: wer es ganz "Web 2.0"-mäßig machen möchte, kann Amazon's Simple Queue Service (SQS) einsetzen - da liegt der Message Broker in der Amazon Server Cloud, er kann daher von überall über das Internet angesprochen werden. (Aus Delphi auch problemlos über ein SOAP Interface.)

Cheers,