SOAP: MYSQL-DB Zugriff

[sephraina]

Hallo Zusammen

Ich hab da mal eine Frage bezüglich SOAP und MYSQL-DB Zugriff.
-Bevor ich noch in die falsche Richtung los programmiere 8-):

Ich habe mich etwas mit SOAP auseinander gesetzt und bekomme auch eine einfach Client-Serveranwendung zum laufen.
(siehe Tutorial: http://www.delphi-treff.de/tutorials...t/webservices/ )

Zum Hintergrund:
Ich will eine SOAP-Anwendung schreiben, mittels welcher man vom Client aus (nebenbei der Client soll in einer Androidapp laufen) dann über "SOAP: Client --> Server" am Schluss auf eine MYSQL-DB zugreifen kann und von dort einige Tabellen mit Inhalten in die Clientanwendung geladen werden sollen. Diese Tabellen/Inhalte sollen/können dann ergänzt werden und nachher wieder zurückgespielt werden.

Zu meiner Idee:
Ich dachte mir das könnte so ablaufen, dass der Zugriff auf die DB im Server programmiert wird und im Client die Funktion, die die Abrufspezifikationen aufnimmt und an den Server weitergibt.
Dann muss ja der Server die Tabellen schicken? (hier habe ich noch keine Idee oder geht das automatisch?)
Der Client muss dann 'nur' noch die empfangen Daten richtig in die Darstellung packen.
Und am Schluss wieder schicken (Weiss ich auch noch nicht wie...) und der Server muss sie richtig an die DB weiterleiten.

Sorry, sind mal wieder 100 Fragen in einem Thema, aber ich hoffe doch jemand kann mir hierbei helfen.
Es geht mir vor allem um das Verständnis, was wo (Server-/Client-Seitig) laufen soll, und wie die Daten übergeben werden sollten.

Gruss und Danke schon im Voraus

sephraina

[mjustin]

Ist SOAP zwingend gefordert / gewünscht? Falls es auch mit Android etc. laufen soll, wäre eine RESTful API (JSON über HTTP/S) ein gängiger Weg.

[mkinzler]

Hier würde sich doch eher rein Rest(ful) Service anbieten.

[Darlo]

Reicht dafür nicht auch dies Aüp tethering?

http://docwiki.embarcadero.com/RADSt..._App-Tethering

[mkinzler]

Aber nur, wenn er die App im Betrieb ( wenn WLAN) oder in der Nähe seines PCs ( wenn BlueTooth) verwenden will.

[Bernhard Geyer]

SOAP um einen indirekten DB-Zugriff zu ermöglichen.
Und da wundert man sich das alles immer langsamer wird und mehr speicher benötigt ...

Wenn du eh schon einen Webserver hast: Wieso nicht gleich die Anwendung als Web/Browserlösung implementieren?

[mjustin]

Zitat:

Zitat von sephraina (Beitrag 1298668)

Der Client muss dann 'nur' noch die empfangen Daten richtig in die Darstellung packen.
... und der Server muss sie richtig an die DB weiterleiten.

Genau, darauf läuft es hinaus. Wenn der Client und der Server Indy verwenden können, ist es relativ einfach: auf dem Android Gerät wird eine Indy HTTP Client Komponente verwendet (TIdHTTP). Diese kann mit der Methode "Get" eine Web-Adresse auf deinem Server aufrufen, zum Beispiel ganz einfach: "http://meinserver/tabelle1". Auf dem Server empfängt in einer Delphi Anwendung der Indy HTTP Server (TIdHTTPServer) diese Anfrage des Clients. Und wenn die vorige Anfrage eintrifft, sendet er zum Beispiel den Inhalt der "Tabelle 1" der Datenbank in Form einer Textdatei an den Client zurück. Das bedeutet, dass die Indy Client Komponente die das "Get" gesendet hat, als Ergebnis einen String als Antwort vom Server erhält, in dem die Tabelle 1 als Text steht. Das ist das Grundprinzip, auf dem man dann nach und nach die Kommunikation aufbauen würde.

[sephraina]

Hmmm, zuerst mal Danke an Alle für die Antworten.

Dann doch eher REST...
Habe ich mir schon vorher überlegt, aber die Tutorials (vor allem von embarcadero) gehen so ziemlich schnell auf DataSnap über.
Leider wird aber DataSnap in meiner Delphiversion nicht unterstütz, was heissen würde, ich müsste alles neu schreiben, oder gibts da Vorarbeiten (Codeschnipselbeispiele für die ganzen GET, POST usw.), die mir einen Anhaltspunkt/Starthilfe geben könnten?

Gruss und Danke

[mkinzler]

http://www.delphipraxis.net/184570-e...erstellen.html

[mjustin]

Zitat:

Zitat von sephraina (Beitrag 1298683)

(Codeschnipselbeispiele für die ganzen GET, POST usw.), die mir einen Anhaltspunkt/Starthilfe geben könnten?

Hier ist ein POST Beispiel für JSON an einen Webserver. Es erfordert allerdings Indy 10.6.2, und da es HTTPS verwendet auch die SSL Bibliotheken im gleichen Verzeichnis wie die Anwendung. Man kann aber das https://httpbin.org/post auch durch http://httpbin.org/post ersetzen, dann geht es ohne SSL Bibliotheken.

Delphi-Quellcode:

program JSONPostExample;
 
{$APPTYPE CONSOLE}
 
uses
  IdHTTP, IdGlobal, SysUtils, Classes;
 
var
  HTTP: TIdHTTP;
  RequestBody: TStream;
  ResponseBody: string;
begin
  HTTP := TIdHTTP.Create;
  try
    try
      RequestBody := TStringStream.Create('{"日本語":42}',
        TEncoding.UTF8);
      try
        HTTP.Request.Accept := 'application/json';
        HTTP.Request.ContentType := 'application/json';
        ResponseBody := HTTP.Post('https://httpbin.org/post',
          RequestBody);
        WriteLn(ResponseBody);
        WriteLn(HTTP.ResponseText);
      finally
        RequestBody.Free;
      end;
    except
      on E: EIdHTTPProtocolException do
      begin
        WriteLn(E.Message);
        WriteLn(E.ErrorMessage);
      end;
      on E: Exception do
      begin
        WriteLn(E.Message);
      end;
    end;
  finally
    HTTP.Free;
  end;
  ReadLn;
  ReportMemoryLeaksOnShutdown := True;
end.

Serverseitig hat man dann natürlich auch noch ein wenig zu tun, im Beispiel wird httpbin.org verwendet, an dem man einfache Tests für GET, POST, PUT, etc. vom Client aus durchführen kann.

[Mavarik]

Zitat:

Zitat von sephraina (Beitrag 1298683)

Hmmm, zuerst mal Danke an Alle für die Antworten.

Dann doch eher REST...

Ich nehme auch lieber SOAP...

Viel einfacher und deutlich handlicher, weil "einfache Proceduren" aufrufen...

Größere Daten einfach vorher packen!

Klar hat man mehr Overhead... Würde auch nur Dif's schicken...

Mavarik

[Darlo]

Habe bei einem aktuellen Projekt auch Soap durchgesetzt. Performance und Skalierbarkeit reichen bei dem Projekt dicke. Habe bei mal vier Anfragen pro Sekunde getestet, lag alles im Bereich von 300ms.

[vagtler]

Zitat:

Zitat von Darlo (Beitrag 1298720)

Habe bei einem aktuellen Projekt auch Soap durchgesetzt. Performance und Skalierbarkeit reichen bei dem Projekt dicke. Habe bei mal vier Anfragen pro Sekunde getestet, lag alles im Bereich von 300ms.

Krass. Damit hättest Du unsere Akzeptanzkriterien beim Antwortverhalten von Schnittstellen mindestens um Faktor 10 gerissen...

[Darlo]

Da hängt ne komplexe Rechnung hinter... Die dauert schon seine Zeit. Die Werte waren nicht die reine Antwortzeit!

[Bernhard Geyer]

Zitat:

Zitat von Darlo (Beitrag 1298734)

Da hängt ne komplexe Rechnung hinter... Die dauert schon seine Zeit. Die Werte waren nicht die reine Antwortzeit!

AH. Also doch eher Businessobjekte die du per SOAP komplett übertragen willst statt nur (wie bisher diskutiert) "dumme" Tabelleninhalte.
Dafür ist natürlich SOAP ganz gut geeignet wenn man das so zusammenfast das alles über eine Abfrage übertragen angefragt und wieder zurück übertragen wird.
Dann hat man "nur" den großen Overheader der XML-Übertragung gegenüber eine JSON-Lösung.

[Mavarik]

Zitat:

Zitat von vagtler (Beitrag 1298732)

Zitat:

Zitat von Darlo (Beitrag 1298720)

Habe bei einem aktuellen Projekt auch Soap durchgesetzt. Performance und Skalierbarkeit reichen bei dem Projekt dicke. Habe bei mal vier Anfragen pro Sekunde getestet, lag alles im Bereich von 300ms.

Krass. Damit hättest Du unsere Akzeptanzkriterien beim Antwortverhalten von Schnittstellen mindestens um Faktor 10 gerissen...

Viele Leute haben eine Ping der höher liegt...

Aber 4 gleichzeitig? Von selben Gerät? Wie viele Anfragen der Server bewerkstelligt, hängt doch nur von der Netzwerkanbindung ab und ggf. von der Prozessorleistung...
Und da müssen es echt viele Anfragen sein um zu sagen... Hätten wir nicht den XML Overhead würde es noch gehen...

Mavarik

[Sir Rufo]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1298739)

Zitat:

Zitat von Darlo (Beitrag 1298734)

Da hängt ne komplexe Rechnung hinter... Die dauert schon seine Zeit. Die Werte waren nicht die reine Antwortzeit!

AH. Also doch eher Businessobjekte die du per SOAP komplett übertragen willst statt nur (wie bisher diskutiert) "dumme" Tabelleninhalte.
Dafür ist natürlich SOAP ganz gut geeignet wenn man das so zusammenfast das alles über eine Abfrage übertragen angefragt und wieder zurück übertragen wird.
Dann hat man "nur" den großen Overheader der XML-Übertragung gegenüber eine JSON-Lösung.

• Diskutiert haben wir bisher über die Anforderung vom TE.
• Darlo nimmt SOAP für seine komplexen Rechnungen, was für ihn ok ist.
• Darlo <> TE

;)

Mit REST kann man auch komplexe Business-Objekte übertragen, am Server auswerten, durchnudeln, ... und ist nicht auf JSON beschränkt. Eigentlich auf gar nichts beschränkt, der REST-Server muss es nur verstehen, was ich dem schicke

[Mavarik]

Zitat:

Zitat von Sir Rufo (Beitrag 1298786)

Mit REST kann man auch komplexe Business-Objekte übertragen, am Server auswerten, durchnudeln, ... und ist nicht auf JSON beschränkt. Eigentlich auf gar nichts beschränkt, der REST-Server muss es nur verstehen, was ich dem schicke

Aber

Delphi-Quellcode:

Var
  SoapFace : IMySoapInterface;
  NR       : Integer;
begin
  SoapFace := HTTPRIO as IMySoapInterface;
  
  NR := SoapFace.HoleneueRechnungsNummer; 
  // 
  SoapFace.ErzeugeNeueRechnung(NR,Daten,Kunde,Lieferanschrift);
  SoapFace.VersendeRechungsPDFPereMail(Kunde.eMail);
  SoapFace.ErgänzeLastSchriftliste;
end;

Liest sich deutlich besser im Source...
Klar kann man sich dafür auch Proceduren schreiben die JSON erzeugen...

Mavarik