Remotable-Objekte verwenden

Nach oben zu Nicht-skalare Typen in aufrufbaren Interfaces verwenden

Verwenden Sie TRemotable als Basisklasse beim Definieren einer Klasse zur Repräsentation eines komplexen Datentyps in einem aufrufbaren Interface. In Fällen, in denen Sie für gewöhnlich einen Record oder eine Struktur als Parameter übergeben würden, definieren Sie stattdessen einen Nachkommen von TRemotable, wobei jedes Element des Records bzw. der Struktur eine als published deklarierte Eigenschaft der neuen Klasse ist.

Folgendes ist veraltet:

Sie können steuern, ob die published Eigenschaften der TRemotable-Ableitung als Elementknoten oder als Attribute in der entsprechenden SOAP-Codierung des Typs erscheinen. Wenn eine Eigenschaft als Attribut erscheinen soll, verwenden Sie die stored-Direktive der Eigenschaftsdefinition und weisen ihr den Wert AS_ATTRIBUTE zu: property MyAttribute: Boolean read FMyAttribute write FMyAttribute stored AS_ATTRIBUTE; __property bool MyAttribute = {read=FMyAttribute, write=FMyAttribute, stored= AS_ATTRIBUTE; Wenn Sie keine stored-Direktive hinzufügen oder der stored-Direktive einen anderen Wert zuweisen (sogar eine Funktion, die den Wert AS_ATTRIBUTE zurückgibt), wird die Eigenschaft nicht als Attribut, sondern als Knoten codiert.

AS_ATTRIBUTE ist veraltet. Es arbeitet zwar noch in altem Quelltext, die Verwendung des Indexwertes einer Eigenschaft ist jedoch die bevorzugte Vorgehensweise. Mit der Eigenschaft Index lässt sich festlegen, ob eine Eigenschaft ein Attribut, ein nicht gebundenes Element, ein optionales Element oder ein Textwert ist oder ob sie den Wert NULL haben kann. Die Unterstützung für optionale Elemente hängt von dem Eigenschaftsattribut stored ab, das auf eine Methode zeigt, die TRUE zurückgibt, wenn die Eigenschaft festgelegt wurde, bzw. FALSE wenn nicht.

Das folgende Beispiel illustriert die Unterstützung für ein optionales Attribut und ein Textelement:

type
{ This stores the languages that the system supports }
  Thumbnail = class(TRemotable)
  private
    FText: WideString;
    FExists: WideString;
    FExists_Specified : boolean;
    procedure SetExists(Index: Integer; _prop_val: WideString);
    function Exists_Specified(Index: Integer): boolean;

  published
    property Text: WideString index IS_TEXT read FText write FText;
    property Exists: WideString index IS_ATTR or IS_OPEN read FExists write SetExists stored Exists_Specified;
  end;

implementation

  procedure Thumbnail.SetExists(Index: Integer; _prop_val: WideString);
  begin
    FExists := _prop_val;
    FExists_Specified := true;
  end;

  function Thumbnail.Exists_Specified(Index: Integer): boolean;
  begin
    Result := FExists_Specified;
  end;
end.

 class Thumbnail : public TRemotable {
 private:
    WideString      FText;
    WideString      FExists;
    bool            FExists_Specified;
    void __fastcall SetExists(int Index, WideString _prop_val)
    {  FExists = _prop_val; FExists_Specified = true;  }
    bool __fastcall Exists_Specified(int Index)
    {  return FExists_Specified;  }
   __published:
    __property WideString       Text = { index=(IS_TEXT), read=FText, write=FText };
    __property WideString     Exists = { index=(IS_ATTR|IS_OPTN), read=FExists, write=SetExists, stored = Exists_Specified };
 };

Wenn der Wert der neuen TRemotable-Ableitung einen skalaren Typ in einem WSDL-Dokument repräsentiert, sollten Sie stattdessen TRemotableXS als Basisklasse verwenden. TRemotableXS ist eine TRemotable-Ableitung, die zwei Methoden zur Konvertierung der neuen Klasse in ihre String-Darstellung ermöglicht. Implementieren Sie diese Methoden durch Überschreiben der Methoden XSToNative und NativeToXS.

Für bestimmte, häufig verwendete skalare XML-Typen werden von der Unit XSBuiltInst bereits Remotable-Klassen definiert und registriert. Diese sind in der folgenden Tabelle aufgeführt:

Remotable-Klassen :

XML-Typ	Remotable-Klasse
dateTimetimeInstant	TXSDateTime
date	TXSDate
time	TXSTime
durationtimeDuration	TXSDuration
decimal	TXSDecimal
hexBinary	TXSHexBinary
string	TXSString
boolean	TXSBoolean
integer	TXSInteger
long	TXSLong

Hinweis:  Sie können TXSString, TXSBoolean, TXSInteger und TXSLong für Fälle verwenden, bei denen ein String-, Boolean-, Integer- oder Long-Wert nil (NULL oder 0 für C++) sein kann. Den Typ TXMLData können Sie verwenden, wenn die gesendeten oder empfangenen Daten nicht festgelegt sind. TXMLData kann für die Übergabe von XML-Rohdaten — wie z.B. ein Schema — in einer SOAP-Botschaft verwendet werden.

Nachdem Sie eine Remotable-Klasse definiert haben, müssen Sie sie, wie unter Nicht-skalare Typen registrieren beschrieben, in der Remotable-Typ-Registrierung registrieren. Diese Registrierung erfolgt auf Servern automatisch, wenn Sie das Interface registrieren, von dem die Klasse verwendet wird. Auf Clients wird der Code zum Registrieren der Klasse automatisch generiert, wenn Sie das WSDL-Dokument importieren, in dem der Typ definiert ist. Ein Beispiel für das Definieren und Registrieren einer Remotable-Klasse finden Sie unter Remotable-Objekt (Beispiel).

Tipp: Sie sollten die Nachkommen von TRemotable in einer eigenständigen Unit getrennt vom Rest der Server-Anwendung (einschließlich der Units, die aufrufbare Interfaces deklarieren und registrieren) implementieren und registrieren. Auf diese Weise können Sie den Typ für mehr als ein Interface verwenden.

Anlagen repräsentieren

Ein wichtiger Nachkomme von TRemotable ist InvokeRegistry.TSoapAttachment. Diese Klasse repräsentiert eine Anlage. Sie kann als Wert für einen Parameter oder als Rückgabewert einer Methode in einem aufrufbaren Interface verwendet werden. Anlagen werden mit SOAP-Botschaften als separate Teile eines mehrteiligen Formulars gesendet.

Wenn eine Web-Service-Anwendung oder der Client eines Web-Services eine Anlage erhält, wird die Anlage in eine temporäre Datei geschrieben. TSoapAttachment ermöglicht Ihnen, auf die temporäre Datei zuzugreifen oder ihren Inhalt in einer permanenten Datei oder einem Stream zu speichern. Wenn die Anwendung eine Anlage senden muss, erstellt sie eine Instanz von TSoapAttachment und weist ihr einen Inhalt zu, indem sie einen Dateinamen, einen Stream, von dem die Anlage gelesen werden kann, oder einen String angibt, der den Inhalt der Anlage repräsentiert.

Referenzverwaltung bei Remotable-Objekten

Eine der Fragen, die sich bei der Verwendung von TRemotable-Ableitungen ergeben, ist diejenige nach dem Zeitpunkt der Erstellung und der Freigabe von Remotable-Objekten. Die Server-Anwendung muss natürlich ihre eigenen lokalen Instanzen dieser Objekte erstellen, da sich die aufrufende Routine in einem separaten Prozessraum befindet. Um damit umgehen zu können, erstellen Web-Service-Anwendungen einen Datenkontext für eingehende Anforderungen. Der Datenkontext besteht fort, während die Anforderung vom Server behandelt wird, und wird freigegeben, sobald alle Ausgabeparameter in einer Antwortbotschaft weitergereicht wurden. Wenn der Server lokale Instanzen der Remotable-Objekte erstellt, fügt er diese dem Datenkontext hinzu, und diese Instanzen werden anschließend gemeinsam mit dem Datenkontext freigegeben.

In bestimmten Fällen möchten Sie möglicherweise verhindern, dass eine Instanz eines Remotable-Objekts nach einem Methodenaufruf freigegeben wird. Enthält das Objekt beispielsweise Statusinformationen, ist es effizienter, die gleiche Instanz immer wieder zu verwenden. Sie verhindern, dass das Remotable-Objekt gemeinsam mit dem Datenkontext freigegeben wird, indem Sie dessen Eigenschaft DataContext ändern.

Siehe auch

• Nicht-skalare Typen registrieren
• Remotable-Objekt (Beispiel)