Alternative Datenübermittlung

[Tom]

Hello,

ich bastele für einen Kunden für diverse Foren und Online-Datenbanken an einem alternativen Datenübertragungsformat.

Der Sinn dahinter ist, dass es inzwischen diverse Anbieter gibt, die von denselben Leuten fast die gleichen Daten erfragen, um sie dann innerhalb ihrer Webapplikationen und -portale wieder zur Verfügung zu stellen. Den Kunden geht das inzwischen ziemlich auf den Senkel, dass sie alle Daten mehrfach verbreiten müssen.

Es soll daher ein Zentralserver entstehen, der alle anderen mit den Updates versorgt.

Allerdings soll das bei HTTP bleiben. Auch die normalen Eingabe-Scripte der Betreiber sollen bleiben, lediglich durch Übertragung eines zusätzlichen Paramters sowie Keys soll die Antwort des Scriptes "servergegrecht" werden.

Wie würdet Ihr da machen?

Als Sprache ist im Moment PHP mit ca. 96% ganz vorne. Man könnte also alle Features dieser Sprache nutzen, wenn nicht eine andere Lösung eben mindestens so gut ist, dass sie die verbleibenden 4% sprengen könnte.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Cheatah]

Hi,

Es soll daher ein Zentralserver entstehen, der alle anderen mit den Updates versorgt.

also mit einem "zentralen" Datenformat, welches von allen anderen ggf. individuell gehandhabt wird. Richtig? Dann bietet sich XML an.

Allerdings soll das bei HTTP bleiben.

Bei HTTP und XML fällt mir sofort SOAP ein. Wenn die Schnittstelle aber nur aus "liefere die Daten" bzw. "nimm sie an" besteht, wäre das über's Ziel hinaus geschossen.

Auch die normalen Eingabe-Scripte der Betreiber sollen bleiben,

Was kann ich mir darunter vorstellen?

Wie würdet Ihr da machen?

Ein XML definieren, die bisherigen Formate beim Empfang in dieses konvertieren (falls nötig), bei der Auslieferung eine Konvertierung beim Empfänger erwarten. Über den letzten Punkt musst Du natürlich mit den Empfängern reden.

Als Sprache ist im Moment PHP mit ca. 96% ganz vorne.

Was sagt dieser Prozentsatz aus?

Cheatah

[Ludger]

Hi,

Bei HTTP und XML fällt mir sofort SOAP ein. Wenn die Schnittstelle aber nur aus "liefere die Daten" bzw. "nimm sie an" besteht, wäre das über's Ziel hinaus geschossen.

warum? Der Ueberbau ist doch, geeignete Module vorausgesetzt, vgl. mit einem low level XML server, gering.

Als Sprache ist im Moment PHP mit ca. 96% ganz vorne.

Was sagt dieser Prozentsatz aus?

Nichts Gutes.

Gruss,
Ludger

[Cheatah]

Hi,

Bei HTTP und XML fällt mir sofort SOAP ein. Wenn die Schnittstelle aber nur aus "liefere die Daten" bzw. "nimm sie an" besteht, wäre das über's Ziel hinaus geschossen.
warum? Der Ueberbau ist doch, geeignete Module vorausgesetzt, vgl. mit einem low level XML server, gering.

der Überbau mag gering sein, aber er ist da - und muss von vielen verschiedenen Kommunikationspartnern implementiert werden. Aus Erfahrung kann ich Dir sagen: Das ist ein _großer_ Überbau.

Cheatah

[Ludger]

Hi,

der Überbau mag gering sein, aber er ist da - und muss von vielen verschiedenen Kommunikationspartnern implementiert werden. Aus Erfahrung kann ich Dir sagen: Das ist ein _großer_ Überbau.

hast Du mal mit VS einen SOAP server geschrieben?

Gruss,
Ludger

[Cheatah]

Hi,

hast Du mal mit VS einen SOAP server geschrieben?

nein, aber ich habe mit Kunden gesprochen, die mit unseren Servern kommunizieren wollten.

Cheatah

[Ludger]

Hi,

hast Du mal mit VS einen SOAP server geschrieben?

nein, aber ich habe mit Kunden gesprochen, die mit unseren Servern kommunizieren wollten.

und da gab es Probleme. PHP- oder Perlclients moeglicherweise.

Aber verglichen mit "Array-Formaten" (ich assoziiere da u.a. COBOL-"Austauschdateien fester Breite") sicherlich eine guenstigere Wahl.

Nicht SOAP folgende, aber XML sprechende Server sind natuerlich auch OK. Aber, wenn man .NET-clients hat (bzw., man weiss wie man z.B. Perlclients mit SOAP::Lite fit macht), dann ist es eine gute Idee mit VS zu kommen.

Ich habe da, huestl, Erfahrung, huestl.

Gruss,
Ludger

[Cheatah]

Hi,

hast Du mal mit VS einen SOAP server geschrieben?
nein, aber ich habe mit Kunden gesprochen, die mit unseren Servern kommunizieren wollten.
und da gab es Probleme.

die man immer hat, wenn man es mit einem vielen Recht machen möchte. In einem anderen Projekt mussten unsere Partner Daten in einem CSV-Format hinter einer URL bereitstellen. Was man bei einer so einfachen Aufgabe alles erlebt ... von wirrsten CSV-Versuchen über Excel- und XML-Daten bis hin zu einem Frameset(!), in dem sich irgendwo ein Link(!) auf die CSV-Ressource befand.

PHP- oder Perlclients moeglicherweise.

Nein, nicht die verwendete Technik ist verantwortlich. Frei nach Men in Black: Menschen sind intelligent. Die Leute aber sind dumm. Wenn mehr als ein, zwei, vielleicht drei Partner etwas machen müssen, kommen die unglaublichsten Ergebnisse bei raus - garantiert.

Nicht SOAP folgende, aber XML sprechende Server sind natuerlich auch OK.

Klar. SOAP bietet Vorteile bei der Schnittstelle; aber wenn die Funktionsvielfalt minimal ist und man nur wenig Dynamik in den Requests zu erwarten hat (also jeder für sich immer nur das gleiche macht), ist es eine gigantische Fehlerquelle ohne einen sichtbaren Nutzen. Sofern also die Vorteile in die Marginalität bzw. Potenzialität abrutschen, würde ich definitiv darauf verzichten. HTTP mit den reinen Nutzdaten - egal ob XML, CSV oder was immer - reicht oft völlig aus.

Ich habe da, huestl, Erfahrung, huestl.

*g* Wir alle, Ludger, wir alle :-)

Cheatah

[Ludger]

Hi,

PHP- oder Perlclients moeglicherweise.

Nein, nicht die verwendete Technik ist verantwortlich.

ich habe mal 8 Stunden erfolglos versucht dem Artikel http://www.microsoft.com/germany/msdn/library/xmlwebservices/AufrufenEinesNETbasiertenWebServiceMithilfeDerSOAPLitePerlBibliothek.mspx folgend einen .NET SOAP-Call inkl. Parameteruebergabe mit SOAP::Lite zu realisieren. Nachdem ich den "Fall" einer Kollegin uebergeben habe, hat diese aufbauend auf meiner Grundlagenforschung es nach weiteren 4 Stunden geschafft. Das Problem war, dass einige Sachen nicht so funktionieren, wie im genannten Artikel bzw. in http://www.soaplite.com/ beschrieben. (Arrays als Parameter wurden nicht richtig verpackt.)

Gruss,
Ludger

[Cheatah]

Hi,

Nein, nicht die verwendete Technik ist verantwortlich.
ich habe mal 8 Stunden erfolglos versucht [...]

ich habe nicht behauptet, die Technik sei absolut problemfrei und würde zu trivialen Implementierungen führen ;-) Bei technischen Problemen kann man aber technische Beratung durchführen. Bei galoppierendem Unsinn ist eine Lösung jedoch nicht ganz so zielgerichtet möglich.

Cheatah

[Tom]

Hello,

also mit einem "zentralen" Datenformat, welches von allen anderen ggf. individuell gehandhabt wird. Richtig? Dann bietet sich XML an.

Drüber nachgedacht hae ich da auch, weil es ja sicher ein paar Jahre Bestand haben wird.
Ich dachte aber auch daran, einfach ein gepacktes "array-Format" zu senden. Schließlich wird es der Server der Gegenstelle sein, der ggf. nach neuen Daten fragt, oder aber im "Push" neue Daten erhalten wird von einem Trustie-Server. Da die ganzen Scripte für Datenerfassung im Prinzip fertig sind, braucht man diese nur noch um die Detektion eines Zertifikates erweitern und einen Post to Host absetzen, der natürlich beim Zentralserver für jede Gegenstelle separat eingestellt werden muss.

Der Zentralserver bekommt dann als Quittung keine HTML-Seite, sondern auch ein Ddatenarray in HTTP zurück.

Als Sprache ist im Moment PHP mit ca. 96% ganz vorne.

Dass 96% der Betreiber mit PHP arbeiten. Aber das ist kein Argument dafür, dass man eventuell doch ein anderes Interface installiert, wenn das mit 4% der sonstigen Arbeit erledigt wäre (oder so ähnlich).

Die Systeme sollen so weit wie möglich autark bleiben. Allerdings würden sie eben eine zusätzliche Funktion (oder Klasse) in ihre Portale einbinden, die dann den Datenaustausch im Hintergrund ermöglicht.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Cheatah]

Hi,

[XML]

Drüber nachgedacht hae ich da auch, weil es ja sicher ein paar Jahre Bestand haben wird.

das möchte man meinen, ja :-)

Ich dachte aber auch daran, einfach ein gepacktes "array-Format" zu senden.

Das nennt sich CSV. Simpel, aber unflexibel.

Da die ganzen Scripte für Datenerfassung im Prinzip fertig sind, braucht man diese nur noch um die Detektion eines Zertifikates erweitern und einen Post to Host absetzen, der natürlich beim Zentralserver für jede Gegenstelle separat eingestellt werden muss.

Man kann aus XML z.B. mittels XSLT wieder CSV erzeugen, wenn es sein muss. I.d.R. kann aber XML auch recht leicht direkt verwendet werden. Ich drücke es mal so aus: Wenn Dir an Deinem CSV _irgend_ etwas nicht behagt, egal was, dann nutze die Gelegenheit, um auf XML umzustellen.

Dass 96% der Betreiber mit PHP arbeiten.

Ach so. Das ist beim Datenformat aber nur ein sehr geringes Argument :-)

Die Systeme sollen so weit wie möglich autark bleiben.

Das kannst Du mit einem "neutralen" Format wie XML am ehesten garantieren. Und wie gesagt, wenn es unbedingt sein muss, kannst Du beim Ausliefern auch ein beliebiges Format erzeugen.

Allerdings würden sie eben eine zusätzliche Funktion (oder Klasse) in ihre Portale einbinden, die dann den Datenaustausch im Hintergrund ermöglicht.

Jupp. Das kann auch etwas ganz anderes als PHP sein.

Cheatah