Autor Beitrag
tmzll
Hält's aus hier
Beiträge: 11



BeitragVerfasst: Mi 09.11.11 16:16 
Hallo,

Ich bin eigentlich Java Entwickler, bin aber im Rahmen eines Probearbeitens gerade mit Delphi in Kontakt geraten. Einige Erinnerungsreste aus der Berufsschule konnte ich wieder "restaurieren", ich bin jetzt seit einer Woche dran.

Ich würde gerne einen Webservice schreiben, welcher mir Zugriff auf verschiedene Dienste gewährt. Zum Beginn wollte ich das ganze minimalistisch halten, und habe mich an dieses Tutorial gehalten:
www.delphi-treff.de/...services/einleitung/

Den Webservice habe ich auf einem Apache Server deployed, ich konnte das WSDL in einen Client importieren, und erhielt eine RemoteException:
"Ein XML-Dokument muss ein Element der obersten Ebene enthalten.
Zeile: 0"

Als erstes wollte ich herausfinden, ob das Problem auf Client- oder Serverseite liegt, und habe mir SoapUI heruntergeladen, hier das WSDL importiert, und Anfragen gesendet. Als Antwort kam immer wieder der selbe Fehler. Daraufhin habe ich eine neue SOAP Server Anwendung in Delphi erstellt, habe mir mit dem Wizard ein Interface erstellen lassen, welches die Beispielmethoden enthält. Von mir generierter Code: Gar keiner, alles von der IDE. Der selbe Fehler.

Ich bin jetzt mit meinem Latein erst mal am Ende, der Apache sollte da ja eigentlich keine Probleme bereiten, oder? Für mich klingt es so, als würde der Server versuchen, ein ungültiges XML zu parsen. Das von SoapUI generierte XML ist aber valide, auf jeden Fall besitzt es ein gültiges Top Level Element... Hat jemand von euch hier Erfahrungswerte, oder einen Tipp für mich?

Gruß,

Tim
smt
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 45



BeitragVerfasst: Mi 09.11.11 17:18 
schreibst du mit delphi den soap server oder benutzt du den soap-service als client?
ah.. habs zu spät gesehen. Du schreibst einen Soap-Server mit Delphi.

Also ich hab auch bereits schon einige SOAP-Server/REST-Service mit Delphi geschrieben, allerdings war dies bei Delphi < 2010 nicht im "Lieferumfang" enthalten, deshalb musste man sich hier mit Speziallösungen behelfen. Ich bin dann bei RemObjects gelandet, die einen sehr guten Soap-Server anbieten - allerdings kostenpflichtig. Die Alternative (so wie es dann auch meistens gemacht habe - und auch immer noch mache): Ich bin auf REST umgestiegen und hab das ganze selbst ausprogrammiert mit den Indy Komponenten.

vg sascha

Moderiert von user profile iconNarses: Beiträge zusammengefasst

ach noch was: Hast Du das ganze mal als VCL Anwendung (also ohne Apache) laufen lassen? Ist vielleicht zum Entwickeln einfacher und schneller. Das ganze kannst Du später dann immer noch in eine ISAPI.DLL umbauen.
Also ich hab das mal eben in Rad Studio XE2 gemacht und die WSDL ohne Probleme von einem PHP Programm importiert bekommen. Ob das ganze auch in D2010 funktioniert kann ich Dir leider sagen, daß ich diese Version nicht habe.

VG Sascha
tmzll Threadstarter
Hält's aus hier
Beiträge: 11



BeitragVerfasst: Mi 09.11.11 22:59 
Hey,

REST wäre vielleicht noch eine Lösung, da habe ich noch gar nicht dran gedacht, danke!
Eine ISAPI.DLL muss ich in einem IIS laufen lassen, oder? Hast du Erfahrungen, was da am unkompliziertesten ist? Apache, IIS, oder etwas anderes?
Das WSDL zu importieren, ist nicht so das Problem, ich denke mal ganz klar, dass der von mir geschriebene Server fehlerhaft ist.

Inwiefern meinst du als VCL? Also komplett Standalone? Da hatte ich mich kurz vor Feierabend mal dran versucht, das ganze dann aber nicht zum Laufen gebracht... Morgen ist ja auch noch ein Tag ;)

Vielen Dank für deine Hilfe, schonmal. Ich melde mich, sobald es etwas neues gibt!
tmzll Threadstarter
Hält's aus hier
Beiträge: 11



BeitragVerfasst: Do 10.11.11 09:49 
Hallo,

als kleiner Nachtrag: Das Problem ist gelöst. Ich benutze jetzt anstatt dem Apache 2 den Microsoft IIS, und die Kommunikation klappt tadellos. Es scheint hier wirklich eine Fehlkonfiguration (oder einen Bug?) im Apache gewesen zu sein... dem möchte ich jetzt aber aus Zeitgründen nicht weiter nachgehen.

Gruß,

Tim