SOAP: MYSQL-DB Zugriff

[Mavarik]

Zitat von sephraina:

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 von 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.

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 von Darlo:

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 von vagtler:

Zitat von 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.

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 von Bernhard Geyer:

Zitat von Darlo:

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 von Sir Rufo:

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