PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Kommunikation C# -> PHP (Webservice)


komplex
2009-07-06, 00:09:25
Hallo Forum,

folgende Sache habe ich vor und frage mich, wie das ganze am besten umzusetzen ist.
Es gibt einen Client, welcher lokal läuft und in C# geschrieben ist. Dieser bereitet diverse Daten auf, welche anschließend in eine externe MySQL-Datenbank (auf nem Webspace) geschrieben werden sollen.
Dass C# direkt mit der DB kommuniziert ist leider keine Option.

Ich denke mal, es geht auf jeden Fall in die richtige Richtung, wenn man einem PHP-Skript die vorbereiteten Daten übergibt und dieses sich dann um die Datenbankverbindung und Queries kümmert.

Als Laie auf diesem Gebiet hätte ich jetzt einfach mal die Daten per Post an das PHP-Script geschickt. Eine eventuelle Rückantwort hätte das PHP-Skript dann als Text bereitstellen können, welche der Client dann noch auslesen muss. Aber das ist wohl wirklich zu Laienhaft ;D

Wie geht man da üblicherweise vor?

Ich habe jetzt was von "SOAP" gelesen, welches in PHP5 ja integriert sein soll. Ich weiß nun, dass es auf jeden Fall zur Cross-Platform Kommunikation verwendbar ist, aber die Arbeitsweise hab ich immernoch nicht kapiert. Könnte jemand versuchen, die Funktionsweise grob in eigene Worte zu fassen?

Eine Bedingung: Leuten, welche den C# Client nicht besitzen, soll es nicht möglich sein, Daten an das PHP-Script zu übergeben. Damit meine ich nicht, dass das hacksicher und x-fach verschlüsselt sein muss, nur sollte man nicht mit Windows-Bordmittteln als Otto-Normaluser den Datenstrom manipulieren können. Wenn das ein geübter wirklich umgehen will, dann wird er es auch schaffen, keine Frage.

Aber es geht mir jetzt - vorausgesetzt das ist überhaupt die übliche Vorgehensweise - erstmal um dieses SOAP. Danke.

Unfug
2009-07-06, 00:43:59
SOAP ist für diesen Verwendungszweck eher nicht gedacht.
SOAP tauscht unter verschiedenen Servern Daten aus, weshalb man auf dem Server auch eine entsprechende Komponente benötigt, die SOAP Daten lesen kann. Da du aber ein WebSpace hast und kein ROOT Server, kannst Du auch keine solche Komponente installieren.

robobimbo
2009-07-06, 09:16:41
SOAP ist ein Standardprotokoll im XML Format, das es WebServices ermöglicht miteinander Daten auszutauschen.

Für ein WebService brauchst Du, wie schon Unfug gesagt hat, ein Programm / Teil des Webservers das auf Anfragen auf einem bestimmten Adresse / Port lauscht und Anfragen entgegennimmt.

Prinzipiell ist der Ablauf der Kommunikation nicht anders wie du das mit deinem POST und dem entsprechenden response geschildert hast, benotigt aber im dafür auch mehr Infrastruktur.

Kinman
2009-07-06, 09:17:59
SOAP ist für diesen Verwendungszweck eher nicht gedacht.
SOAP tauscht unter verschiedenen Servern Daten aus, weshalb man auf dem Server auch eine entsprechende Komponente benötigt, die SOAP Daten lesen kann. Da du aber ein WebSpace hast und kein ROOT Server, kannst Du auch keine solche Komponente installieren.

Warum sollte das so sein? Es gibt einfach ein SOAP Skript, welches am Server liegt und bei dem call aufgerufen wird. Wenn SOAP aktiviert ist, sollte es somit auch mit einem normalen Webspace funktionieren.

--

Dieser Link zeigt sehr einfach, wie man mit PHP einen SOAP Server realisiert.
http://www.html-world.de/program/phpex_9.php

http://de.wikipedia.org/wiki/SOAP ist auch lesenswert

universaL
2009-07-06, 10:59:36
mhm,

schau dir mal "rest" - webservices an (http://en.wikipedia.org/wiki/Representational_State_Transfer , ka wie gut die wikipedia erklärung ist, kenne das ganze eigentlich nur aus der rails-sicht.), da spart man sich den ganzen umständlichen kram von soap und es funzt trotzdem ;)

Demirug
2009-07-06, 11:09:41
Wenn der Client sowieso schon in C# geschrieben ist würde ich WCF nehmen. Das ist einfach und beherscht die ganzen Standardprotokolle inklusive der entsprechenden Sicherheitsfeatures.

The_Invisible
2009-07-06, 14:38:44
warum soll es unbedingt kompliziert sein?

POST/GET mit JSON als datenformat reicht vollkommen und ist sogar ressourcenschonend gegenüber den anderen "enterprise" dingern.

mfg

Gast
2009-07-06, 16:55:12
warum soll es unbedingt kompliziert sein?

POST/GET mit JSON als datenformat reicht vollkommen und ist sogar ressourcenschonend gegenüber den anderen "enterprise" dingern.

mfg

Manuelle Http Requests machen und dann diesen JSON Kram manuell parsen? Und was soll daran bitte einfacher sein? Es kann wohl kaum einfacher gehen als einen simplen Webverweis eines WebService in VS hinzuzufügen (oder wenn man kein VS hat sich den Proxy über soapsuds generieren lassen).

Berni
2009-07-06, 20:02:07
Nix manuell parsen: http://de.php.net/manual/de/function.json-decode.php
Zu überlegen wäre auch, wie du das Ganze vernünftig absicherst falls das im Internet steht.

Gast
2009-07-06, 22:43:51
Nix manuell parsen: http://de.php.net/manual/de/function.json-decode.php
Zu überlegen wäre auch, wie du das Ganze vernünftig absicherst falls das im Internet steht.

Wahnsinn, eine Funktion die eine named value collection zurückliefert. Das kannst du doch nicht ernsthaft als produktiv ansehen und über ein XML DOM mit XPath Abfrage stellen?

Außerdem, einen Webservice Proxy hat man über wsdl in einer Minute erstellt (dazu gibt es genügend Tools). Dann braucht man auch keinen sinnlosen String parsen, sondern kann eine normale Funktion aufrufen und bekommt eine entsprechende Datenstruktur zurück.

XML ist ein langer und weit verbreiteter Industriestandard, es gibt keinen Grund darauf zu verzichten.

Coda
2009-07-06, 22:57:10
Nö, nur braucht mand as alles in diesen Fällen fast nie. XML ist oft genug einfach Overkill.

Und JSON ist jetzt auch nicht gerade etwas neues. Die ganzen Google-APIs basieren darauf, genauso Dinge wie CouchDB.

Demirug
2009-07-06, 23:03:07
Wenn mein Client eine JavaScript Anwendung ist würde ich JSON jederzeit XML vorziehen. Genau für diesen Fall ist JSON nämlich gedacht. Da ich auf der Serverseite aber dann auch auf C#+WCF setzten würde spielt das letzten Endes auch keine Rolle. Ob XML, JSON oder beides ist ja dann nur noch eine Frage der Konfiguration.

Gast
2009-07-07, 09:18:39
Nö, nur braucht mand as alles in diesen Fällen fast nie. XML ist oft genug einfach Overkill.


Da muss man schon wirklich sehr anspruchsvolle Lösungen haben, damit dieser Overkill sich bemerkbar macht und man sich Gedanken über Performanceoptimierung machen muss. In meinem Arbeitsbereich kenne ich keine einzige Service Orientierte Infrastruktur, wo JSON anstatt XML zur Kommunikation verwendet wird.

JSON wird hauptsächlich für AJAX verwendet, dabei sollte man es auch belassen. Aber wie Demirug schon sagte, letztendlich ist es nur eine Frage der Konfiguration, vorausgesetzt man verwendet ein gutes Framework.

Trotzdem bieten XML Webdienste einfach deutlich mehr Funktionalität, auch gerade bei der Implementierung von Sicherheitsaspekten.