Webservice: Aufbau der Response-Dokumente Client-sensitiv?

malT · Hält's aus hier Beiträge: 3

Moin moin,

anscheinend ist die Stuktur eines Response-Dokumentes eines Delphi-Webservices abhängig von dem abfragenden Client. So erhalten ein Java- und ein Delphi-Client bspw. unterschiedliche <SOAP-ENV:Body>-Starttags:

Java-Client:

markieren

Quelltext

1:
2:
3:

  <SOAP-ENV:Body
    SOAP-ENC:encodingStyle="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:NS2="urn:de_somecompany_somemodule">

Delphi-Client:

markieren

Quelltext

1:
2:

  <SOAP-ENV:Body
    SOAP-ENC:encodingStyle="http://schemas.xmlsoap.org/soap/envelope/">

Zusätzlich stellt sich die Darstellung verschachtelter Typen etwas unteschiedlich dar. Nehmen wir an es gibt folgende Klassen, mit einer Referenz TKreis->TFarbe:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:

TKreis = class(TObject)
  private
    FDurchmesser: Integer;
    FFarbe: TFarbe;
  published
    Durchmesser: Integer read FDurchmesser write FDurchmesser;
    Farbe: TFarbe read FFarbe write FFarbe;
  end;

TFarbe = class(TObject)
  private
    FHex: String;
  published
    Hex: String read FHex write FHex;
  end;

Im Response-Dokument eines WebService würde ein TKreis nun auf zweierlei Arten -je nach Client- zurückgegeben (vereinfachte Darstellung):

Java-Client (TFarbe-Knoten separat):

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:

<SOAP-ENV:Body>
  <TKreis>
    <Durchmesser>7</Durchmesser>
  </TKreis>
  <TFarbe>
    <String>FFFFFF</String>
  </TFarbe>
</SOAP-ENV:Body>

Delphi-Client (TFarbe-Knoten 'inline'):

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:

<SOAP-ENV:Body>
  <TKreis>
    <Durchmesser>7</Durchmesser>
    <TFarbe>
      <String>FFFFFF</String>
    </TFarbe>
  </TKreis>
</SOAP-ENV:Body>

Kann mir jemand sagen, wie sich dieses 'client-sensitive' Verhalten erklären lässt und wie man es ggfs. abstellt? Nach meinem Verständnis wäre es geeigneter, wenn eine Server-Schnittstelle allen Clients im gleichen Format antwortet.

TIA

malte.

malT · Hält's aus hier Beiträge: 3

Hallo,

UPDATE: es handelt sich um keine client-spezifischen Fehler. Die wechselnden Response-Formate können auch mit konstantem Client erzeugt werden. Die client-abhängigkeit war meine erste, naheliegendste Vermutung, die sich aber nicht bestätigt hat.

Hier noch ein paar Angaben zur Implementierung/Laufzeitumgebung des WebService:

Delphi 7
ISAPI DLL
IIS 5.0

Der Server liefert in ca. 10% der Fälle ein geändertes Format des Response-Dokumentes wie in meinem vorigen Post geschildert. Es gibt mittlerweile Hinweise darauf, daß die in 90% der Fälle verwendete Variante nicht SOAP 1.2 kompatibel ist.

Wie gesagt, verwendet werden verschachtelte Objektklassen, teilweise als Arrays.

Hat jemand irgendwelche Erfahrung mit diesem Thema und kann mir sachdienliche Hinweise/Links nennen?

Danke und viele Grüße

malte.

malT · Hält's aus hier Beiträge: 3

Moin,

in der Quality Central sind wir fündig geworden: qc.borland.com/wc/qcmain.aspx?d=14222 zeigt wie wichtig es ist,

[highlight]TSOAPDomConv.Options in the SOAP-WebModul:

[soTryAllSchema, soRootRefNodesToBody, soUTF8InHeader, soUTF8EncodeXML][/highlight]

zu beachten.

"soRootRefNodesToBody" sorgt dafür, daß eien SOAP 1.2 kompatibles Response-Format, das nur Vorwärts-Verweise enthält, erstellt wird.

Das erklärt zwar noch nicht, warum das Response-Format _unterschiedlich_ war. Wir haben uns das mittlerweile damit begründet, daß die Option nicht initialisiert wird, wenn auf false gesetzt und der Server zufällige Werte in den Speicherbereichen hat.

malte.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme