(DIPLOMARBEIT) Kommunikation Client <-> Server mittels SOAP

[Hopsel]

Hi alle!

Ich kenne keine anderes Forum, in dem sich so viele qualifizierte Leute tummeln.
Deshalb hoffe ich, dass ihr mir mit eurer Meinung helfen könnt.

Für meine Diplomarbeit soll ich eine Zentraldisposition für Speditionen konzipieren.
Dabei sollen einzelne Standorte (z. B. Hamburg, München, Berlin) über einen zentralen Server Dispositionsdaten (insb. Lieferungen/Sendungen/Touren) austauschen können.

Folgende Punkte sind wichtig:

• die Speditionen sind meist kleine oder mittelgroße Unternehmen (Preisfrage)
• die Speditionen setzen schon das Programm meiner Firma ein
• die Kommunikation mit einem Server, der die Dispositionsdaten verwaltet, muss über das Internet erfolgen

Damit ich jetzt keinen konzeptionellen Fehler zu Beginn mache, würde ich gern eure Meinung zu meinen bisherigen Gedanken hören:

• Aufgrund der Kostenfrage würde ich die Kommunikation zwischen Klienten
    und Server über SOAP und HTTP(S) bewerkstelligen.
    (Stichwort: "Service-orientierte Architekturen mit Web Services")

• Die Serverapplikation würde mit PHP und MySQL entwickelt werden, so
    dass sie auf gängigen Webservern eingesetzt werden kann

• Auf die lokalen Anwendungen (Delphi, MSSQL 2005/8 Express) habe ich
    selbstverständlich Einfluss. Auch hier ist eine Implementierung der
    Kommunikation mittels SOAP kein Problem.

• Performanceprobleme des Servers sind nicht zu erwarten, da im Mittel
    niemals mehr als 50 Zugriffe pro Minute erfolgen.

Meine grundsätzlichen Fragen:
1. Ist die Umsetzung über einen Webservice, der mittels SOAP mit den
   einzelnen Standorten kommuniziert prinzipiell zu empfehlen?
2. Welche Alternativen gibt es?

Auch weitere Anmerkungen, Meinungen und Kritiken sind herzlich willkommen.

Ich danke euch für eure Aufmerksamkeit,

MfG H☼psel

[dedlfix]

Hi!

Damit ich jetzt keinen konzeptionellen Fehler zu Beginn mache, würde ich gern eure Meinung zu meinen bisherigen Gedanken hören:

• Aufgrund der Kostenfrage würde ich die Kommunikation zwischen Klienten
    und Server über SOAP und HTTP(S) bewerkstelligen.
    (Stichwort: "Service-orientierte Architekturen mit Web Services")

Muss es SOAP sein oder reicht auch was leichtgewichtigeres?

• Performanceprobleme des Servers sind nicht zu erwarten, da im Mittel
    niemals mehr als 50 Zugriffe pro Minute erfolgen.

Hast du schon Erfahrung, wie sich der SOAP-Overhead auf die Zugriffe pro Minute auswirkt?

1. Ist die Umsetzung über einen Webservice, der mittels SOAP mit den einzelnen Standorten kommuniziert prinzipiell zu empfehlen?

Kommt drauf an, welche Vorteile SOAP gegenüber den Alternativen bietet. Zu SOAP gehören ja auch noch ein paar weitere Dinge, wie WSDL und UDDI, die auch Verarbeitungszeit kosten, wenn du sie nutzen willst.

2. Welche Alternativen gibt es?

REST und die Daten in selbst definiertes XML eingepackt (auch JSON kann sich eignen)
WDDX (nicht ganz so bekannt und verbreitet, dafür recht schlank)
WCF (wenn du komplett .NET nehmen wolltest)

Lo!

[Hopsel]

Hi dedlfix!

Du bist klasse. =)
Die richtigen Stichworte zu finde, wenn man sich in ein neues Thema einarbeitet, finde ich immer sehr schwierig.

Muss es SOAP sein oder reicht auch was leichtgewichtigeres?

Nein, aber SOAP ist wahrscheinlich das bekannsteste Protokoll. Deswegen habe ich viel dazu gefunden.
Zwei wichtige Punkte habe ich in meinen Ausführungen übrigens Vergessen: Authentifizierung und Autorisierung.
Eine einfache Übergabe eines Identifizierungsmerkmals dürfte aber auch mit den anderen Verfahren kein Problem darstellen.

Hast du schon Erfahrung, wie sich der SOAP-Overhead auf die Zugriffe pro Minute auswirkt?

Nein, noch gar nicht. Das ist vorerst eine reine Mutmaßung.

2. Welche Alternativen gibt es?
   REST und die Daten in selbst definiertes XML eingepackt (auch JSON kann sich eignen)
   WDDX (nicht ganz so bekannt und verbreitet, dafür recht schlank)
   WCF (wenn du komplett .NET nehmen wolltest)

Diese Stichpunkte sind für mich sehr wertvoll. Da habe ich erstmal wieder Stoff, mit dem ich mich beschäftigen kann.

Generell hatte ich in meine Überlegungen auch einfache HTTP-Request ohne SOAP einbezogen. Das geht ja dann eher in die Richtung REST.

Ich hatte gehofft, dass SOAP gute Rahmenbedingungen für meine Insellösung liefern könnte, allerdings komme ich so langsam zu der Einsicht, dass Konzepte wie UDDI und WSDL nicht unbedingt notwendig sind und das gesamte Konzept nur aufblähen und nicht zu Verständlichkeit beitragen würden.

Eine Eigenentwicklung auf der Basis von XML über HTTP erscheint mir inzwischen in ihren Vorteilen (Verständlichkeit, Umsetzung, Wartung, Dokumentation, etc.) sinnvoller, als auf einen festen Standard zu setzen.

Dank dir,
H☼psel

[Christian Seiler]

Hallo,

Eine Eigenentwicklung auf der Basis von XML über HTTP erscheint mir inzwischen in ihren Vorteilen (Verständlichkeit, Umsetzung, Wartung, Dokumentation, etc.) sinnvoller, als auf einen festen Standard zu setzen.

Du könntest Dir evtl. auch JSON anschauen. Douglas Crockford (der "Entdecker" von JSON) hat vor einiger Zeit eine Präsentation gehalten, in der er erklärt, warum JSON sich gut für den Datenaustausch eignet. Kleine Warnung: Natürlich ist die Präsentation ziemlich einseitig pro-JSON und anti-XML, aber mir hat sie ein paar interessante Denkanstöße gegeben.

Ansonsten kann ich meinem Vorredner nur zustimmen: SOAP will man eigentlich nicht, außer man kann es vermeiden. Es ist ziemlich kompliziert zu nutzen. Ferner verlangen manche Implementierungen z.B. immer ein WSDL - auch wenn Du keins willst - und damit musst Du Dich mit WSDL und XML Schema (<- uargh!) auseinandersetzen und zwangsweise ein WSDL anbieten zu Deinem Service, damit Du damit nicht auf die Schnauze fliegst. Meiner Erfahrung nach führt SOAP/WSDL auch dazu, dass man das Zeug nicht mehr dokumentiert, weil man ja alles im WSDL stehen hat - dummerweise ist ein WSDL-File eben kein Ersatz für eine gute Dokumentation der Services. Wenn Du also doch bei XML bleiben willst, dann mach ein eigenes, zugeschnittenes Format, das Du vor allem dokumentieren (!) solltest (was bedeutet was etc.). Schema/DTD dazu ist dann eher die Kür als Pflicht in meinen Augen. Weil dann auch hier wieder die Gefahr besteht, dass man Schema/DTD als Ersatz für die Dokumentation nimmt und nicht wirklich dokumentiert. Zum Vergleich: Die HTML-DTDs selbst machen z.B. nur einen winzigen Bruchteil des HTML-Standards aus.

Viele Grüße,
Christian

[Hopsel]

Hi Christian!

Danke für deine Antwort.

SOAP will man eigentlich nicht, […]

Zu dem Schluss komme ich inzwischen auch. =)
Ich denke, ich werde mich für eine leichtgewichtigere Variante entscheiden.

Das Video fand ich eher unterhaltend als informativ. Dennoch werde ich JSON in meine Überlegungen einbeziehen.

[…] das Du vor allem dokumentieren (!) solltest […]

Das ist quasi der Sinn dieser Diplomarbeit: Konzeption und saubere Dokumentation.

Danke auch für deine Einschätzung zum Thema WSDL.

MfG H☼psel

[fastix®]

Moin!

• die Speditionen setzen schon das Programm meiner Firma ein

Aha. Es wird also ein Programm verwendet...

1. Ist die Umsetzung über einen Webservice, der mittels SOAP mit den
      einzelnen Standorten kommuniziert prinzipiell zu empfehlen?

Kommt darauf an.

2. Welche Alternativen gibt es?

Der überwiegende Anteil dürfte auf reine "Datenbankarbeit" entfallen. Ich vermute dahinter steht ein gutes, gebräuchliches, leistungsfähiges, netzwerkfähiges DBMS in welchen sich auch Rechte sehr fein festlegen lassen und welche ggf. ganz oder teilweise auch zu lokalen hosts repliziert werden kann. Wenn die Programmiersprache verschlüsselte/komprimierte Verbindungen zu Deiner Datenbank beherrscht, dann würde ich darüber nachdenken welchen zwingenden Grund es gibt für die Übermittlung der Daten eine (rechenintensive) Zwischenschicht einzubauen. Selbst wenn die Verbindung Client -> Datenbank unverschlüsselt abläuft kann man über ein VPN nachdenken.

Welche Vorteile Dir SOAP bringt musst Du wissen oder erst herausarbeiten - und es sollte ein wichtiger Grund aus dem Geschäftsprozess heraus sein

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Hopsel]

Hi fastix®!

2. Welche Alternativen gibt es?
   Der überwiegende Anteil dürfte auf reine "Datenbankarbeit" entfallen.

Nun ja, die Konzeption der Datenbank ist nicht so sehr das Problem. Das stempel ich unter Routinearbeit ab. Mit ging es eher um die Frage der Kommunikation zwischen Client und Server.

Ich vermute dahinter steht ein gutes, gebräuchliches, leistungsfähiges, netzwerkfähiges DBMS in welchen sich auch Rechte sehr fein festlegen lassen und welche ggf. ganz oder teilweise auch zu lokalen hosts repliziert werden kann.

Wie im OP geschrieben gibt es eine lokale Anwendung für Speditionen, die auf Delphi und MSSQL 2008 Express basiert.
Diese Anwendung soll um eine Möglichkeit erweitert werden, über das Internet kostengünstig Dispositionsdaten mit anderen Standorten (die die gleiche Anwendung nutzen) auszutauschen.
Dafür soll ein Webserver genutzt werden, der mit PHP und MySQL arbeitet. Dieser stellt dann die einzelnen Daten für alle Standorte zur Verfügung und bietet eine Schnittstelle zur Bearbeitung dieser Daten (Lesen, Ändern, Löschen) an.

Wenn die Programmiersprache verschlüsselte/komprimierte Verbindungen zu Deiner Datenbank beherrscht, dann würde ich darüber nachdenken welchen zwingenden Grund es gibt für die Übermittlung der Daten eine (rechenintensive) Zwischenschicht einzubauen. Selbst wenn die Verbindung Client -> Datenbank unverschlüsselt abläuft kann man über ein VPN nachdenken.

Ein sehr guter Gedanke, den ich unbedingt in meine Überlegungen mit einschließen werde.

Danke für deine Antwort und Gedanken zum Thema.

MfG H☼psel

[dedlfix]

Hi!

Wenn die Programmiersprache verschlüsselte/komprimierte Verbindungen zu Deiner Datenbank beherrscht, dann würde ich darüber nachdenken welchen zwingenden Grund es gibt für die Übermittlung der Daten eine (rechenintensive) Zwischenschicht einzubauen. Selbst wenn die Verbindung Client -> Datenbank unverschlüsselt abläuft kann man über ein VPN nachdenken.
Ein sehr guter Gedanke, den ich unbedingt in meine Überlegungen mit einschließen werde.

Ganz ohne Zwischenschicht würde ich das aber nicht in Angriff nehmen, denn dann müssten die Clients alle Informationen zum Datenschema haben und im ungünstigsten Fall alle gleichzeitig geändert werden. Zumindest Kapslungen in Stored Procedures und Views sollten in Betracht gezogen werden.

Das ist übrigens kein Sicherheitsfeature, denn das EXECUTE-Recht allein reicht nicht, SELECT usw. sowie Zugriffrechte auf die von den SPs und Views angesprochenen Tabellen braucht man trotzdem. Und dann kann man auch direkt zugreifen. Es geht lediglich darum, diszipliniert diesen Direktzugriff zu vermeiden und eine nach außen hin gleich bleibende beziehungsweise zu älteren Client-Versionen kompatible API zu schaffen.

Lo!

[O'Brien]

Hi,

1. Ist die Umsetzung über einen Webservice, der mittels SOAP mit den
      einzelnen Standorten kommuniziert prinzipiell zu empfehlen?

nur wenn Opera als Client verwendet wird.

Schönen Sonntag noch!
O'Brien