&Datenbank: Webservice als DB-Schnittstelle

[LeKuchen]

Hallo zusammen,
ich habe mir letztens mal überlegt, einen Webservice als Datenbankschnittstelle für ein Webprojekt zu nutzen, wie folgt:

Abfrage wird als XML Code an den Webservice geschickt. Der schickt eine XML-Datei mit Ergebnis zurück.
-Dadurch hätte man eine imho geniale Trennung der gesamten DB-Schicht von der Anwendung.
-Für das Anbinden anderer Datenbanken an das Webprojekt müsste man nur den Webservice entsprechend ändern, bzw. dieser soll auch modular aufgebaut sein für die ensprechenden DataProvider.
-Der Webservice kann auch von anderen Applikationen genutzt werden, die auf die Datenbank zugreifen.

Jemand sowas schon gemacht bzw. was spricht gegen solch eine Lösung?
Gruß,
LeKuchen

[Ludger]

Hi,

-Dadurch hätte man eine imho geniale Trennung der gesamten DB-Schicht von der Anwendung.

BOAH, SUPER IDEE.

-Für das Anbinden anderer Datenbanken an das Webprojekt müsste man nur den Webservice entsprechend ändern, bzw. dieser soll auch modular aufgebaut sein für die ensprechenden DataProvider.

Auch supi.

-Der Webservice kann auch von anderen Applikationen genutzt werden, die auf die Datenbank zugreifen.

Ja.

Jemand sowas schon gemacht bzw. was spricht gegen solch eine Lösung?

Was spricht dafuer? (Diese Frage war ernstgemeint, der Rest nicht)

Gruss,
Ludger

[LeKuchen]

Hallo,

Was spricht dafuer? (Diese Frage war ernstgemeint, der Rest nicht)

Eben die drei oben genannten Punkte. Und die Bereitstellung der Daten als XML. Können einige Datenbanksysteme noch nicht wirklich. Aber erkläre mir, warum ich das nicht so machen soll....deshalb frage ich ja hier im Forum.

-LeKuchen

[LeKuchen]

P.S.:
Ich denke dabei an eine Web-Anwendung, die:
-auf vielen verschiedenen Plattformen serverseitig läuft
-viele verschiedene RDBMS genutzt werden können
-mit anderen Anwendungen kommuniziert bzw. Daten austauscht.

[Ludger]

Hi,

P.S.:
Ich denke dabei an eine Web-Anwendung, die:
-auf vielen verschiedenen Plattformen serverseitig läuft
-viele verschiedene RDBMS genutzt werden können
-mit anderen Anwendungen kommuniziert bzw. Daten austauscht.

Du hast keinen Datenserver, sondern einen Geschaeftslogikserver im Sinn, stimmts?

Gruss,
Ludger

[LeKuchen]

Hallo,

Du hast keinen Datenserver, sondern einen Geschaeftslogikserver im Sinn, stimmts?

Einen Datenserver hatte ich nie im Sinn. Habe nochmal recherchiert. Habe eher einen "Data Access Tier" im Sinn.

Siehe: http://www.15seconds.com/issue/011023.htm
bzw. http://www.15seconds.com/issue/030317.htm

Gruß

[Ludger]

Hi,

Eben die drei oben genannten Punkte. Und die Bereitstellung der Daten als XML. Können einige Datenbanksysteme noch nicht wirklich. Aber erkläre mir, warum ich das nicht so machen soll....deshalb frage ich ja hier im Forum.

also eine Aufteilung der Aufgaben (der Logik) in:

• Praesentation (z.B. HTML-Output mit z.B. Perl)
• Geschaeftslogik (Leasingratenberechnung ;-)
• Datenbank
  wuerde ja Sinn machen. Und das kann man z.B. mit einem Datenserver, einem Webserver (z.B. incl. Perl) und z.B. einem SOAP-Webservice als Geschaeftslogikserver umsetzen.

Aber der von Dir skizzierte Server, was macht der? Der stellt Daten bereit und ist zwiebelschichtig von einer XML-Schicht und Web-Schicht umgeben.

Welche Vorteile siehst Du denn da?

• Dass der Datenserver per HTTP(S) erreichbar ist?    :-(
• Dass XML-Output kommt?   (Koennen manche Datenserver schon "von Haus aus".)
• Dass getrennt ist, was nicht zusammengehoert? (Eher das Gegenteil ist der Fall.)
• Einfachheit?   (Noeeh)

Ist ein Architektur-Lapsus, oder?

Gruss,
Ludger

[LeKuchen]

Hallo,

also eine Aufteilung der Aufgaben (der Logik) in:

• Praesentation (z.B. HTML-Output mit z.B. Perl)

Ja, aber nur: Das Design/Layout. (XHTML/XSLT)

• Geschaeftslogik (Leasingratenberechnung ;-)

Unter Deiner "Geschaeftslogik" verstehe ich einen Application Layer mit der Programmiersprache meiner Wahl. (.NET)

• Datenbank

Der bekommt die Daten aus Datenbank bzw. einem RDBMS.

Aber der von Dir skizzierte Server, was macht der?

Der von mir skizzierte Webservice bildet eine Zwischenschicht zwischen RDBMS und Application Layer.

Welche Vorteile siehst Du denn da?

Die Applikation soll mit mehreren RDBMS laufen. Über den Zwischenlayer bleibt die Applikation unangetastet von Änderungen des RDBMS. Die Applikation schickt Anweisungen an den Webservice, der diese dann für das RDBMS spezifisch umsetzt. (SQL hier, ist nicht SQL da). Daten kommen immer im gleichen Format zur Applikation zurück.

• Dass der Datenserver per HTTP(S) erreichbar ist?    :-(

k.A., noch keine Gedanken drüber gemacht.

• Dass XML-Output kommt?

Ja, manche, aber bei weitem noch nicht alle und teilweise dürftig. (RDBMSe: MySQL, MSSQL, PostgreSQL, Oracle)

• Dass getrennt ist, was nicht zusammengehoert? (Eher das Gegenteil ist der Fall.)

Haeh, versteh ich nicht. Wo ist da was zusammen, was nicht zusammen gehört?
Gruß,
LeKuchen

[Ludger]

Hi,

Aber der von Dir skizzierte Server, was macht der?

Der von mir skizzierte Webservice bildet eine Zwischenschicht zwischen RDBMS und Application Layer.

also, wenn Du sowas gemeint hast wie "die serverseitige Logik (ASP, oder weiss der Teufel was) holt sich XMLs vom von Dir skizzierten Webservice und generiert nur noch das Style (XSLs) dazu", dann geht das ansatzweise schon in die richtige Richtung. Allerdings waere es m.E. noch cooler, wenn das RDBMS bereits das XML-Output besorgt, also die von Dir beschriebene Zwiebelschicht ums RDBMS herum nicht benoetigt wird.

Du kannst sicher sein, dass in diese Richtung gedacht und gearbeitet wird. M$ kommt da mit diesem XML-Package (und natuerlich schon mit der grandiosen XML-Syntax beim SELECT ;-) fuer den 2000er SQL, Oracle ist bestimmt schon weiter. Gut, wies bei MySQL aussieht muesstest Du selbst nachschauen, genauso wie beim 2005er von M$.

Welche Vorteile siehst Du denn da?

Die Applikation soll mit mehreren RDBMS laufen. Über den Zwischenlayer bleibt die Applikation unangetastet von Änderungen des RDBMS. Die Applikation schickt Anweisungen an den Webservice, der diese dann für das RDBMS spezifisch umsetzt. (SQL hier, ist nicht SQL da). Daten kommen immer im gleichen Format zur Applikation zurück.

OK.

• Dass der Datenserver per HTTP(S) erreichbar ist?    :-(

k.A., noch keine Gedanken drüber gemacht.

Performance und Traffic und so.   :-(

• Dass getrennt ist, was nicht zusammengehoert? (Eher das Gegenteil ist der Fall.)

Haeh, versteh ich nicht. Wo ist da was zusammen, was nicht zusammen gehört?

Das, was Du skizziert hast, gehoert zusammen, wenn ich Dich richtig verstanden habe. Also warum eine Zwischenschicht?

Gruss,
Ludger