Soap Client und Upload von Dateien

[Sergej_Molotov]

Hallo Zusammen,

ich versuche gerade mit einem Soap-Client eine Datei zu Server hochzuladen.

Zur Zeit habe ich aber noch keine Idee, wie ich das File/Stream an mein THTTPRIO-Objekt anbinde, damit es später im MIMEBoundary enthalten.

Server ist in Java geschrieben und Client eben in Delphi.

Hinweis:
Ich möchte auf keinen Fall meine Files in einem byte-Array versenden, da dies bei großen Files Probleme verursacht.

Hat jemand vielleicht ne idee?

Danke

[mjustin]

Zitat:

Zitat von Sergej_Molotov

ich versuche gerade mit einem Soap-Client eine Datei zu Server hochzuladen.

Zur Zeit habe ich aber noch keine Idee, wie ich das File/Stream an mein THTTPRIO-Objekt anbinde, damit es später im MIMEBoundary enthalten.

Server ist in Java geschrieben und Client eben in Delphi.

Threads die dazu eventuell passen könnten:

TSOAPAttachment that's not streamed...partial success
http://www.delphigroups.info/2/11/347650.html

Support for DIME
https://forums.codegear.com/message....essageID=92900

Verbesserte Soap-Unterstützung:
(voraussichtlich) Delphi 2010

Edit: Je nach Komplexität der Soap-Requests könnte man einen Java Client schreiben, und den HTTP Verkehr mit Don's Proxy oder Fiddler verfolgen, und mit Delphi dann die gesamte Soap-Kommunikation zu Fuss programmieren.

[Sergej_Molotov]

In Delphi 2010 ist alles genauso bescheiden. Dafür das Soap ein angeblicher Standard ist, aber jedes Framework (Delphi Soap oder jax-ws) es wieder für sich auslegt, kann man das nur mit viel gefrickel hinbekommen.

[Bernhard Geyer]

Zitat:

Zitat von Sergej_Molotov (Beitrag 1142519)

In Delphi 2010 ist alles genauso bescheiden. Dafür das Soap ein angeblicher Standard ist, aber jedes Framework (Delphi Soap oder jax-ws) es wieder für sich auslegt, kann man das nur mit viel gefrickel hinbekommen.

Delphi hat noch nie optimalen SOAP-Support geliefert.

Und aufgrund der vielen Probleme mit SOAP gehen/gingen viele Firmen dahin statt SOAP JSON zu verwenden. Google dürfte mittlerweilen komplett auf JSON umgeschwenkt sein:

Vorteil:
- Weniger Overhead
- Verständlicher
- Gebräuchliche Web-Techniken können mit JSON einfach kombiniert werden.

[mquadrat]

Kommt immer auf's Umfeld an. Oder gibt es inzwischen eine JSON Entsprechung für die Sachen, die in WS* spezifziert sind? Also 2-Phase-Commit, WS-Security und der ganze andere Kram...

[mjustin]

Zitat:

Zitat von mquadrat (Beitrag 1142550)

Kommt immer auf's Umfeld an. Oder gibt es inzwischen eine JSON Entsprechung für die Sachen, die in WS* spezifziert sind? Also 2-Phase-Commit, WS-Security und der ganze andere Kram...

JSON könnte man als "moderne CSV Datei" sehen. Auf Entsprechungen nützlicher XML und SOAP Standards wie Validierung per XSD & Co., Transformationen (XSL) und Web Service Description Language (WSDL) verzichtet man. Für Entwickler die viel mit HTML / JavaScript Anwendungen und leichtgewichtigen (REST-) Webservices zu tun haben, ist es aber sicher einfacher zu nutzen als SOAP.

[mquadrat]

Also für WSDL gibt es in JSON inzwischen JSON-Schema als Alternative. Wird aber noch nicht so breit unterstützt. Mit JSON-P gibt's ja auch einen RFC Standard. Der Witz ist allerdings, dass dadurch JSON auch immer komplexer wird, also genau das was alle an SOAP immer kritisieren ;)