Re: kommunikation Client <-> Server

  • From: Michael Gruetzner <Michael_Gruetzner@xxxxxx>
  • To: idefix@xxxxxxxxxxxxx
  • Date: Sun, 22 Jun 2003 22:39:52 +0200

Roland Kruggel wrote:

Am Samstag Juni 21 2003 15:46 schrieb Michael Gruetzner:

Roland Kruggel wrote:

Am Samstag Juni 21 2003 13:45 schrieb Michael Gruetzner:

Hallo,

ich habe mich gestern intensiv mit SOAP auseinandergesetzt. Trotz
der einfachen Installation der benötigten Komponenten ist es mir
bis jetzt noch nicht gelungen einen funktionierenden Webservice zu
erstellen. Ausserdem habe ich feststellen müssen, dass das
"Deployen" eines Webservice mit unerwartet hohem
Konfigurationsaufwand verbunden ist(und dass es nicht funktioniert
;-) ).
Das alles hat mich dazu gebracht, nochmal darüber nachzudenken, ob
SOAP wirklich das Non-plus-ultra ist. Nach diesem Reinfall, bin ich
der Meinung, dass wir doch nochmal über andere Middleware
Technologien nachdenken sollten.

Hallo Michael,


manchmal ist der Schritt von der Theorie zur Praxis doch erheblich.
Ich kenne das. Es liest sich ganz einfach, aber dann ...

Vorschlag meinerseits.
MySQL ist ja schon als Client/Server konzipiert. Bietet also schon
diese Infrastruktur. Laß uns die gesamte Datenbankkommunikation in
eine eigene Klasse packen. Wenn sich dann noch jemand zu uns
gesellt der SOAP 'im Schlaf' kann, denn können wir diese Klasse
einfach austauschen. Ich glaube bei oop ist das einfach möglich :)

Ich glaube nicht, dass eine klasse für die DB und Buissenes Logik
ausreicht. Es wird wohl eher darauf hinauslaufen, dass wir ein
komplexes Framework entwickeln. Dieses können wir dann in einem
Serverobjekt zusammenfassen und z.B. per RMI freigeben.


Ja, ok. Wie der Klassenaufbau letztentlich wird steht je noahc auf einem anderen Blatt.

Ich stelle mit das so vor. wir definieren eine Klasse Db. Alle anfragen werden aus dem Programm aus an die Klasse Db gestellt. Der komplette SQL string wird deiser Klasse übergeben. Das Return kommt auch nur aus dieser Klassen. Db wiederum ist abgeleitet von der Klasse DbBasis. In DbBasis wird die kommunikation mir den SQL-Server geregel. Am anfang als direkte Verbindung zu MySQL.

Wir können dann die Klasse DbBasis austauschen gegen eine DbBasisSoap, die die Kommunikation über Soap regelt.

So grob Schematisch dargestellt.

Ich hab mir noch folgendes überlegt: wir trennen die Geschäfts- und DB logik im Server. Alle Klassen, die für die DB Logik zuständig sind, liegen in einem jar Archiv, das vom Server zur laufzeit geladen wird. Damit können wir das DB "Modul" nach belieben austauchen um z.B. statt MySQL auch Oracle oder DB2 zu unterstützen. Ich meiner Meinung nach sehr flexibel. Was hälst du davon?

Was die Middleware Technologie betrifft, müssen wir uns unbedingt vorher darüber im Klaren sein, welche wir verwenden, denn schliesslich baut die ganze Architektur darauf auf. Wenn wir das nicht richtig machen, kommen wir später in Teufels Küche(Ich kenne Projekte, die daran zerbrochen sind). Ich schlage daher folgendes Vorgehen vor:

Wir tragen zu allen in Frage kommenden Middleware Technologien die Vor- und Nachteile zusammen und treffen dann die Entscheidung.

MfG
Michael

Damit habe
ich auch schon praktische erfahrung und das währe Ideal, obwohl wir
damit an Java gebunden sind - was allerdings auch nicht so schlimm
ist. Dafür ist eine spätere Migration auf CORBA relativ leicht
möglich und wir haben eine einfache Schnittstelle zur
Aussenwelt(Client).

Michael


Ich habe gestern auch ein wenig über SOAP gelesen. Hat nicht nur
vorteil. Die Kommunikation zwischen Server und Client geschieht ja
mittels XML. Daraus ergibt sich einen höhere Netzbelastung von
Faktor 10. Auch nicht unerheblich.

cu

-- panic("Attempted to kill the idle task!"); 2.2.16 /usr/src/linux/kernel/exit.c


cu



--
/* vsprintf.c -- Lars Wirzenius & Linus Torvalds. */
 *
 * Wirzenius wrote this portably, Torvalds fucked it up :-)
 */
        2.2.16 /usr/src/linux/lib/vsprintf.c

--
Projekt: Warenwirtschaft. Projektname: Jana
Infos: http://jana.bbf7.de

--------------------------------------------------------------------
Zum AUSTRAGEN schicken Sie eine Mail an idefix-request@xxxxxxxxxxxxx
mit dem Subject "unsubscribe". 
mailto:idefix-request@xxxxxxxxxxxxx?subject=unsubscribe

Mailarchive: //www.freelists.org/archives/idefix
Probleme? Mail an mailto:rkruggel@xxxxxxx (deutsch)

Other related posts: