Teilen über

Entwerfen von Serviceverträgen

In diesem Thema wird beschrieben, was Serviceverträge sind, wie sie definiert werden, welche Vorgänge verfügbar sind (und welche Auswirkungen für den zugrunde liegenden Nachrichtenaustausch haben), welche Datentypen verwendet werden, und andere Probleme, die Ihnen beim Entwerfen von Vorgängen helfen, die die Anforderungen Ihres Szenarios erfüllen.

Erstellen eines Servicevertrags

Dienste machen eine Reihe von Vorgängen verfügbar. Definieren Sie in Windows Communication Foundation (WCF)-Anwendungen die Vorgänge, indem Sie eine Methode erstellen und mit dem OperationContractAttribute Attribut markieren. Wenn Sie dann einen Dienstvertrag erstellen möchten, gruppieren Sie Ihre Vorgänge, indem Sie sie entweder innerhalb einer schnittstelle deklarieren, die mit dem ServiceContractAttribute Attribut gekennzeichnet ist, oder indem Sie sie in einer Klasse definieren, die mit demselben Attribut gekennzeichnet ist. (Ein einfaches Beispiel finden Sie unter How to: Define a Service Contract.)

Methoden, die kein Attribut besitzen OperationContractAttribute , sind keine Dienstvorgänge und werden nicht von WCF-Diensten verfügbar gemacht.

In diesem Thema werden die folgenden Entscheidungspunkte beim Entwerfen eines Servicevertrags beschrieben:

  • Gibt an, ob Klassen oder Schnittstellen verwendet werden sollen.

  • So geben Sie die Datentypen an, die Sie austauschen möchten.

  • Die Arten von Austauschmustern, die Sie verwenden können.

  • Ob Sie explizite Sicherheitsanforderungen als Teil des Vertrags festlegen können.

  • Die Einschränkungen für Betriebseingaben und -ausgaben.

Klassen oder Schnittstellen

Sowohl Klassen als auch Schnittstellen stellen eine Gruppierung der Funktionalität dar und können daher beide verwendet werden, um einen WCF-Dienstvertrag zu definieren. Es wird jedoch empfohlen, Schnittstellen zu verwenden, da sie direkt Serviceverträge modellieren. Ohne Implementierung können Schnittstellen nicht mehr als eine Gruppierung von Methoden mit bestimmten Signaturen definieren. Implementieren Sie eine Dienstvertragsschnittstelle, und Sie haben einen WCF-Dienst implementiert.

Alle Vorteile verwalteter Schnittstellen gelten für Dienstvertragsschnittstellen:

  • Servicevertragsschnittstellen können eine beliebige Anzahl anderer Servicevertragsschnittstellen erweitern.

  • Eine einzelne Klasse kann eine beliebige Anzahl von Serviceverträgen implementieren, indem diese Servicevertragsschnittstellen implementiert werden.

  • Sie können die Implementierung eines Dienstvertrags ändern, indem Sie die Schnittstellenimplementierung ändern, während der Dienstvertrag unverändert bleibt.

  • Sie können Ihren Dienst versionieren, indem Sie die alte Schnittstelle und die neue implementieren. Alte Clients stellen eine Verbindung mit der ursprünglichen Version her, während neuere Clients eine Verbindung mit der neueren Version herstellen können.

Hinweis

Wenn Sie von anderen Dienstvertragsschnittstellen erben, können Sie keine Vorgangseigenschaften außer Kraft setzen, z. B. den Namen oder den Namespace. Wenn Sie versuchen, dies zu tun, erstellen Sie einen neuen Vorgang im aktuellen Servicevertrag.

Ein Beispiel für die Verwendung einer Schnittstelle zum Erstellen eines Dienstvertrags finden Sie unter How to: Create a Service with a Contract Interface.

Sie können jedoch eine Klasse verwenden, um einen Servicevertrag zu definieren und diesen Vertrag gleichzeitig zu implementieren. Der Vorteil, Ihre Dienste zu erstellen, indem Sie ServiceContractAttribute direkt auf die Klasse und OperationContractAttribute direkt auf die Methoden der Klasse anwenden, liegt in der Schnelligkeit und Einfachheit. Die Nachteile sind, dass verwaltete Klassen keine mehrfache Vererbung unterstützen und daher nur jeweils einen Dienstvertrag implementieren können. Darüber hinaus ändert jede Änderung der Klassen- oder Methodensignaturen den öffentlichen Vertrag für diesen Dienst, wodurch nicht geänderte Clients daran gehindert werden können, Ihren Dienst zu verwenden. Weitere Informationen finden Sie unter Implementieren von Serviceverträgen.

Ein Beispiel, das eine Klasse verwendet, um einen Dienstvertrag zu erstellen und gleichzeitig zu implementieren, finden Sie unter How to: Create a Service with a Contract Class.

An diesem Punkt sollten Sie den Unterschied zwischen der Definition Ihres Servicevertrags mithilfe einer Schnittstelle und mithilfe einer Klasse verstehen. Der nächste Schritt besteht darin, zu entscheiden, welche Daten zwischen einem Dienst und seinen Clients hin und her weitergegeben werden können.

Parameter und Rückgabewerte

Jeder Vorgang verfügt über einen Rückgabewert und einen Parameter, auch wenn dies der Wert ist void. Im Gegensatz zu einer lokalen Methode, bei der Sie Verweise auf Objekte von einem Objekt an ein anderes übergeben können, übergeben Dienstvorgänge keine Verweise auf Objekte. Stattdessen übergeben sie Kopien der Objekte.

Dies ist wichtig, da jeder Typ, der in einem Parameter oder Rückgabewert verwendet wird, serialisierbar sein muss; Das heißt, es muss möglich sein, ein Objekt dieses Typs in einen Bytestrom und aus einem Bytestrom in ein Objekt zu konvertieren.

Primitive Typen sind standardmäßig serialisierbar, ebenso wie viele Typen in .NET Framework.

Hinweis

Der Wert der Parameternamen in der Vorgangssignatur ist Teil des Vertrags, und die Groß- und Kleinschreibung wird beachtet. Wenn Sie denselben Parameternamen lokal verwenden möchten, aber den Namen in den veröffentlichten Metadaten ändern möchten, lesen Sie die Informationen unter .System.ServiceModel.MessageParameterAttribute

Datenverträge

Dienstorientierte Anwendungen wie Windows Communication Foundation (WCF)-Anwendungen sind so konzipiert, dass sie mit der größtmöglichen Anzahl von Clientanwendungen auf Microsoft- und Nicht-Microsoft-Plattformen zusammenarbeiten. Für die größtmögliche Interoperabilität empfiehlt es sich, Ihre Typen mit den DataContractAttribute und DataMemberAttribute Attributen zu kennzeichnen, um einen Datenvertrag zu erstellen. Dies ist der Teil des Servicevertrags, der die Daten beschreibt, die Ihre Dienstvorgänge austauschen.

Datenverträge sind Opt-In-Stil-Verträge: Es wird kein Typ oder Datenmemmer serialisiert, es sei denn, Sie wenden das Datenvertragsattribut explizit an. Datenverträge sind unabhängig vom Zugriffsbereich des verwalteten Codes: Private Datenelemente können serialisiert und an anderer Stelle gesendet werden, damit sie öffentlich zugänglich sind. (Ein grundlegendes Beispiel für einen Datenvertrag finden Sie unter How to: Create a Basic Data Contract for a Class or Structure.) WCF behandelt die Definition der zugrunde liegenden SOAP-Meldungen, die die Funktionalität des Vorgangs sowie die Serialisierung Ihrer Datentypen in und außerhalb des Nachrichtentexts ermöglichen. Solange Ihre Datentypen serialisierbar sind, müssen Sie beim Entwerfen Ihrer Vorgänge nicht über die zugrunde liegende Nachrichtenaustauschinfrastruktur nachdenken.

Obwohl die typische WCF-Anwendung die Attribute DataContractAttribute und DataMemberAttribute verwendet, um Datenverträge für Vorgänge zu erstellen, können Sie andere Serialisierungsmechanismen verwenden. Die Standardmechanismen ISerializable, SerializableAttribute und IXmlSerializable sorgen dafür, dass Ihre Datentypen in die zugrunde liegenden SOAP-Nachrichten serialisiert werden, die sie von einer Anwendung zur anderen übertragen. Sie können weitere Serialisierungsstrategien anwenden, wenn Ihre Datentypen spezielle Unterstützung benötigen. Weitere Informationen zu den Auswahlmöglichkeiten für die Serialisierung von Datentypen in WCF-Anwendungen finden Sie unter Angeben der Datenübertragung in Dienstverträgen.

Zuordnen von Parametern und Rückgabewerten zu Nachrichtenaustauschvorgängen

Dienstvorgänge werden durch einen zugrunde liegenden Austausch von SOAP-Nachrichten unterstützt, die Anwendungsdaten hin und her übertragen, zusätzlich zu den daten, die von der Anwendung benötigt werden, um bestimmte Standardsicherheits-, Transaktions- und sitzungsbezogene Features zu unterstützen. Da dies der Fall ist, diktiert die Signatur eines Dienstvorgangs ein bestimmtes zugrunde liegendes Nachrichtenaustauschmuster (MEP), das die Datenübertragung unterstützen kann, und die Funktionen, die ein Vorgang erfordert. Sie können drei Muster im WCF-Programmiermodell angeben: Anforderungs-/Antwort-, Unidirektionale und Duplexnachrichtenmuster.

Anfrage/Antwort

Ein Anforderungs-/Antwortmuster ist eines, in dem ein Anforderungssender (eine Clientanwendung) eine Antwort empfängt, mit der die Anforderung korreliert wird. Dies ist der Standard-MEP, da er einen Vorgang unterstützt, bei dem mindestens ein Parameter an den Vorgang übergeben wird und ein Rückgabewert an den Aufrufer übergeben wird. Das folgende C#-Codebeispiel zeigt z. B. einen einfachen Dienstvorgang, der eine Zeichenfolge verwendet und eine Zeichenfolge zurückgibt.

[OperationContractAttribute]
string Hello(string greeting);

Es folgt der entsprechende Visual Basic-Code.

<OperationContractAttribute()>
Function Hello (ByVal greeting As String) As String

Diese Vorgangssignatur bestimmt die Form des zugrunde liegenden Nachrichtenaustauschs. Wenn keine Korrelation vorhanden ist, kann WCF nicht ermitteln, für welchen Vorgang der Rückgabewert vorgesehen ist.

Beachten Sie, dass die Dienstvorgänge, die void zurückgeben (Nothing in Visual Basic), Anforderungs- und Antwortnachrichtenaustausche sind, es sei denn, Sie geben ein anderes zugrunde liegendes Nachrichtenmuster an. Das Ergebnis für Ihre Operation ist, dass der Client die Verarbeitung anhält, bis die Rückgabenachricht empfangen wird, es sei denn, ein Client ruft den Vorgang asynchron auf, obwohl diese Nachricht im Normalfall leer ist. Das folgende C#-Codebeispiel zeigt einen Vorgang, der erst zurückgegeben wird, wenn der Client eine leere Nachricht als Antwort empfangen hat.

[OperationContractAttribute]
void Hello(string greeting);

Es folgt der entsprechende Visual Basic-Code.

<OperationContractAttribute()>
Sub Hello (ByVal greeting As String)

Das vorangehende Beispiel kann die Leistung und Reaktionsfähigkeit des Clients verlangsamen, wenn der Vorgang lange dauert, aber es gibt Vorteile für Anforderungs-/Antwortvorgänge, auch wenn sie zurückgegeben werden void. Die offensichtlichste ist, dass SOAP-Fehler in der Antwortnachricht zurückgegeben werden können, was angibt, dass eine dienstbezogene Fehlerbedingung aufgetreten ist, unabhängig davon, ob es sich um kommunikation oder verarbeitung handelt. SOAP-Fehler, die in einem Dienstvertrag angegeben sind, werden als FaultException<TDetail> Objekt an die Clientanwendung übergeben, wobei der Typparameter der im Dienstvertrag angegebene Typ ist. Dies erleichtert das Benachrichtigen von Clients über Fehlerbedingungen in WCF-Diensten. Weitere Informationen zu Ausnahmen, SOAP-Fehlern und fehlerbehandlung finden Sie unter Angeben und Behandeln von Fehlern in Verträgen und Diensten. Ein Beispiel für einen Anforderungs-/Antwortdienst und -client finden Sie unter How to: Create a Request-Reply Contract. Weitere Informationen zu Problemen mit dem Anforderungsantwortmuster finden Sie unter Request-Reply Services.

Unidirektional

Wenn der Client einer WCF-Dienstanwendung nicht warten sollte, bis der Vorgang abgeschlossen ist und SOAP-Fehler nicht verarbeitet, kann der Vorgang ein unidirektionales Meldungsmuster angeben. Ein unidirektionales Verfahren ist eine Operation, in der ein Client einen Vorgang aufruft und die Verarbeitung fortsetzt, nachdem WCF die Nachricht in das Netzwerk geschrieben hat. Normalerweise bedeutet dies, dass der Client fast sofort weiterläuft, es sei denn, die gesendeten Daten in der ausgehenden Nachricht sind extrem groß (oder es tritt ein Fehler beim Senden der Daten auf). Dieser Typ von Nachrichtenaustauschmuster unterstützt ereignisähnliches Verhalten von einem Client zu einer Dienstanwendung.

Ein Nachrichtenaustausch, in dem eine Nachricht gesendet wird und keine empfangen wird, kann keinen Dienstvorgang unterstützen, der einen anderen Rückgabewert angibt als void; in diesem Fall wird eine InvalidOperationException Ausnahme ausgelöst.

Keine Rückgabemeldung bedeutet auch, dass kein SOAP-Fehler zurückgegeben werden kann, um Fehler bei der Verarbeitung oder Kommunikation anzugeben. (Die Kommunikation von Fehlerinformationen, wenn Vorgänge unidirektionale Vorgänge sind, erfordert ein Duplexnachrichtenaustauschmuster.)

Um einen unidirektionalen Meldungsaustausch für einen Vorgang anzugeben, der void zurückgibt, legen Sie die IsOneWay-Eigenschaft auf true fest, wie im folgenden C#-Codebeispiel gezeigt:

[OperationContractAttribute(IsOneWay=true)]
void Hello(string greeting);

Es folgt der entsprechende Visual Basic-Code.

<OperationContractAttribute(IsOneWay := True)>
Sub Hello (ByVal greeting As String)

Diese Methode ist identisch mit dem vorherigen Anforderungs-/Antwortbeispiel, aber wenn Sie die IsOneWay Eigenschaft auf true festlegen, bedeutet dies, dass die Methode zwar identisch ist, der Dienstvorgang jedoch keine Rückmeldung sendet, und Clients kehren sofort zurück, sobald die ausgehende Nachricht an die Kanalschicht übergeben wurde. Ein Beispiel finden Sie unter How to: Create a One-Way Contract. Weitere Informationen zum unidirektionalen Muster finden Sie unter Unidirektionale Dienste.

Doppelhaus

Ein Duplexmuster zeichnet sich durch die Fähigkeit des Dienstes und des Clients aus, Nachrichten unabhängig voneinander zu senden, unabhängig davon, ob sie einseitige oder Anforderungs-/Antwortnachrichten verwenden. Diese Form der bidirektionale Kommunikation ist nützlich für Dienste, die direkt mit dem Client kommunizieren müssen, oder für die Bereitstellung einer asynchronen Benutzeroberfläche auf beiden Seiten eines Nachrichtenaustauschs, einschließlich ereignisähnlichem Verhalten.

Das Duplexmuster ist etwas komplexer als die Anfrage/Antwort- oder unidirektionalen Muster wegen des zusätzlichen Mechanismus zur Kommunikation mit dem Client.

Um einen Duplex-Vertrag zu entwerfen, müssen Sie auch einen Rückrufvertrag entwerfen und den Typ dieses Rückrufvertrags der CallbackContract Eigenschaft des ServiceContractAttribute Attributs zuweisen, das Ihren Servicevertrag kennzeichnet.

Zum Implementieren eines Duplexmusters müssen Sie eine zweite Schnittstelle erstellen, die die Methodendeklarationen enthält, die auf dem Client aufgerufen werden.

Ein Beispiel für das Erstellen eines Diensts und eines Clients, der auf diesen Dienst zugreift, finden Sie unter How to: Create a Duplex Contract and How to: Access Services with a Duplex Contract. Ein Arbeitsbeispiel finden Sie unter Duplex. Weitere Informationen zu Problemen bei der Verwendung von Duplexverträgen finden Sie unter Duplexdienste.

Vorsicht

Wenn ein Dienst eine Duplexnachricht empfängt, wird das ReplyTo-Element in dieser eingehenden Nachricht betrachtet, um zu bestimmen, wohin die Antwort gesendet werden soll. Wenn der Kanal, der zum Empfangen der Nachricht verwendet wird, nicht gesichert ist, kann ein nicht vertrauenswürdiger Client eine schädliche Nachricht mit dem Zielcomputer senden, was zu einem Denial of Service (DOS) dieses Zielcomputers ReplyToführt.

Out-Parameter und Ref-Parameter

In den meisten Fällen können Sie in Parameter (ByVal in Visual Basic) und out und ref Parameter (ByRef in Visual Basic) verwenden. Da die Parameter out und ref angeben, dass Daten aus einem Vorgang zurückgegeben werden, gibt die folgende Vorgangssignatur an, dass ein Anforderungs-/Antwortvorgang erforderlich ist, selbst wenn die Vorgangssignatur void zurückgibt.

[ServiceContractAttribute]
public interface IMyContract
{
  [OperationContractAttribute]
  public void PopulateData(ref CustomDataType data);
}

Es folgt der entsprechende Visual Basic-Code.

<ServiceContractAttribute()> _
Public Interface IMyContract
  <OperationContractAttribute()> _
  Public Sub PopulateData(ByRef data As CustomDataType)
End Interface

Die einzigen Ausnahmen sind die Fälle, in denen Ihre Signatur eine bestimmte Struktur aufweist. Beispielsweise können Sie die NetMsmqBinding Bindung verwenden, um nur dann mit Clients zu kommunizieren, wenn die Methode zum Deklarieren eines Vorgangs void zurückgibt. Es darf kein Ausgabewert vorhanden sein, weder ein Rückgabewert noch ref oder out Parameter.

Darüber hinaus erfordert die Verwendung out oder ref Parameter, dass der Vorgang über eine zugrunde liegende Antwortnachricht verfügt, um das geänderte Objekt zurückzugeben. Wenn der Vorgang eine unidirektionale Operation ist, wird zur Laufzeit eine InvalidOperationException Ausnahme ausgelöst.

Angeben der Nachrichtenschutzebene für den Vertrag

Beim Entwerfen Ihres Vertrags müssen Sie auch die Nachrichtenschutzebene für Dienste festlegen, die Ihren Vertrag implementieren. Dies ist nur erforderlich, wenn die Nachrichtensicherheit auf die Bindung im Endpunkt des Vertrags angewendet wird. Wenn die Bindung die Sicherheit ausgeschaltet hat (d. h., wenn die vom System bereitgestellte Bindung den System.ServiceModel.SecurityMode auf den Wert SecurityMode.None setzt), müssen Sie die Nachrichtenschutzstufe des Vertrags nicht festlegen. In den meisten Fällen bieten vom System bereitgestellte Bindungen mit angewendeter Sicherheit auf Nachrichtenebene eine ausreichende Schutzstufe, und Sie müssen nicht die Schutzebene für jeden Vorgang oder für jede Nachricht berücksichtigen.

Die Schutzebene ist ein Wert, der angibt, ob die Nachrichten (oder Nachrichtenteile), die einen Dienst unterstützen, signiert, signiert und verschlüsselt oder ohne Signaturen oder Verschlüsselung gesendet werden. Die Schutzebene kann auf verschiedenen Bereichen festgelegt werden: Auf Dienstebene, für einen bestimmten Vorgang, für eine Nachricht innerhalb dieses Vorgangs oder eines Nachrichtenteils. Werte, die auf einem Bereich festgelegt werden, werden zum Standardwert für kleinere Bereiche, es sei denn, dies wird explizit außer Kraft gesetzt. Wenn eine Bindungskonfiguration nicht die erforderliche Mindestschutzstufe für den Vertrag bereitstellen kann, wird eine Ausnahme ausgelöst. Und wenn für den Vertrag keine Schutzebenenwerte explizit festgelegt werden, steuert die Bindungskonfiguration die Schutzebene für alle Nachrichten, wenn die Bindung die Nachrichtensicherheit aufweist. Dies ist das Standardverhalten.

Von Bedeutung

Die Entscheidung, ob verschiedene Bereiche eines Vertrags explizit auf weniger als das vollständige Schutzniveau von ProtectionLevel.EncryptAndSign festgelegt werden sollen, ist in der Regel eine Entscheidung, die Abwägungen zwischen einem gewissen Maß an Sicherheit und erhöhter Leistung beinhaltet. In diesen Fällen müssen Sich Ihre Entscheidungen um Ihre Vorgänge und den Wert der ausgetauschten Daten drehen. Weitere Informationen finden Sie unter Sichern von Diensten.

Im folgenden Codebeispiel wird beispielsweise weder die ProtectionLevel Eigenschaft noch die ProtectionLevel Eigenschaft für den Vertrag festgelegt.

[ServiceContract]
public interface ISampleService
{
  [OperationContractAttribute]
  public string GetString();

  [OperationContractAttribute]
  public int GetInt();
}

Es folgt der entsprechende Visual Basic-Code.

<ServiceContractAttribute()> _
Public Interface ISampleService

  <OperationContractAttribute()> _
  Public Function GetString()As String

  <OperationContractAttribute()> _
  Public Function GetData() As Integer

End Interface

Bei der Interaktion mit einer ISampleService Implementierung in einem Endpunkt mit dem Standard WSHttpBinding (dem Standard System.ServiceModel.SecurityMode, das Message ist), werden alle Nachrichten verschlüsselt und signiert, da dies die Standardschutzstufe ist. Wenn ein ISampleService Dienst jedoch mit einem Standard BasicHttpBinding verwendet wird (dem Standard SecurityMode, das ist None), werden alle Nachrichten als Text gesendet, da für diese Bindung keine Sicherheit besteht und daher die Schutzebene ignoriert wird (das heißt, die Nachrichten werden weder verschlüsselt noch signiert). Wenn SecurityMode in Message geändert würde, würden diese Nachrichten verschlüsselt und signiert (da dies jetzt die Standardschutzebene der Bindung wäre).

Wenn Sie die Schutzanforderungen für Ihren Vertrag explizit angeben oder anpassen möchten, legen Sie die ProtectionLevel Eigenschaft (oder eine der ProtectionLevel Eigenschaften in einem kleineren Bereich) auf die Ebene fest, die Ihr Servicevertrag erfordert. Um eine explizite Einstellung zu verwenden, ist es erforderlich, dass die Verbindung diese Einstellung mindestens innerhalb des verwendeten Bereichs unterstützt. Im folgenden Codebeispiel wird beispielsweise ein ProtectionLevel Wert explizit für den GetGuid Vorgang angegeben.

[ServiceContract]
public interface IExplicitProtectionLevelSampleService
{
  [OperationContractAttribute]
  public string GetString();

  [OperationContractAttribute(ProtectionLevel=ProtectionLevel.None)]
  public int GetInt();
  [OperationContractAttribute(ProtectionLevel=ProtectionLevel.EncryptAndSign)]
  public int GetGuid();
}

Es folgt der entsprechende Visual Basic-Code.

<ServiceContract()> _
Public Interface IExplicitProtectionLevelSampleService
    <OperationContract()> _
    Public Function GetString() As String
    End Function

    <OperationContract(ProtectionLevel := ProtectionLevel.None)> _
    Public Function GetInt() As Integer
    End Function

    <OperationContractAttribute(ProtectionLevel := ProtectionLevel.EncryptAndSign)> _
    Public Function GetGuid() As Integer
    End Function

End Interface

Ein Dienst, der diesen IExplicitProtectionLevelSampleService Vertrag implementiert und über einen Endpunkt verfügt, der den Standardwert WSHttpBinding verwendet (der Standardwert System.ServiceModel.SecurityMode, der lautet Message) hat das folgende Verhalten:

  • Die GetString Vorgangsnachrichten werden verschlüsselt und signiert.

  • Die GetInt Vorgangsnachrichten werden als unverschlüsselter und nicht signierter Text (d. h. nur Text) gesendet.

  • Der GetGuid Vorgang System.Guid wird in einer nachricht zurückgegeben, die verschlüsselt und signiert ist.

Weitere Informationen zu Schutzstufen und deren Verwendung finden Sie unter Grundlegendes zur Schutzebene. Weitere Informationen zur Sicherheit finden Sie unter Sicherheitsdienste.

Weitere Anforderungen für die Operationssignatur

Einige Anwendungsfeatures erfordern eine bestimmte Art von Vorgangssignatur. Die NetMsmqBinding-Bindung unterstützt beispielsweise permanente Dienste und Clients, in denen eine Anwendung während der Kommunikation neu gestartet und ohne Meldungsverlust genau dort fortgesetzt werden kann, wo sie angehalten wurde. (Weitere Informationen finden Sie unter Warteschlangen in WCF.) Dauerhafte Vorgänge dürfen jedoch nur einen in Parameter verwenden und keinen Rückgabewert aufweisen.

Ein weiteres Beispiel ist die Verwendung von Stream Typen in Vorgängen. Da der Stream-Parameter den gesamten Nachrichtentext enthält, muss eine Eingabe oder Ausgabe (d. h. ref-Parameter, out-Parameter oder Rückgabewert) vom Typ Stream sein und die einzige Eingabe oder Ausgabe in Ihrem Vorgang sein. Darüber hinaus muss der Parameter oder Rückgabetyp entweder Stream, System.ServiceModel.Channels.Message oder System.Xml.Serialization.IXmlSerializable sein. Weitere Informationen zu Datenströmen finden Sie unter "Große Daten und Streaming".

Namen, Namespaces und Verschleierung

Die Namen und Namespaces der .NET-Typen in der Definition von Verträgen und Vorgängen sind wichtig, wenn Verträge in WSDL umgewandelt werden und wann Vertragsnachrichten erstellt und gesendet werden. Daher wird dringend empfohlen, Dienstvertragsnamen und Namespaces explizit mithilfe der Name- und Namespace-Eigenschaften aller unterstützenden Vertragsattribute, wie etwa der ServiceContractAttribute, OperationContractAttribute, DataContractAttribute, DataMemberAttribute und anderer Vertragsattribute, festzulegen.

Sind die Namen und Namespaces nicht explizit festgelegt, verändert die Verwendung der IL-Obfuskation für die Assembly die Namen und Namespaces des Vertragstyps. Dadurch ergeben sich Änderungen beim WSDL- und Übertragungsaustausch, wodurch üblicherweise Fehler auftreten. Wenn Sie die Vertragsnamen und Namespaces nicht explizit festlegen, aber die Verschleierung verwenden möchten, verwenden Sie die ObfuscationAttribute Und-Attribute ObfuscateAssemblyAttribute , um die Änderung der Vertragstypnamen und -namespaces zu verhindern.

Siehe auch

  • Last updated on