Übersicht über Kanalebene

Die Kanalschicht bietet eine Abstraktion des Transportkanals sowie Nachrichten, die auf dem Kanal gesendet werden. Es enthält auch Funktionen für die Serialisierung von C-Datentypen in und aus SOAP-Strukturen. Die Kanalschicht ermöglicht die vollständige Steuerung der Kommunikation mithilfe von Nachrichten , die aus gesendeten oder empfangenen Daten bestehen und Körper und Kopfzeilen enthalten, sowie Kanäle , die Nachrichtenaustauschprotokolle abstrahieren und Eigenschaften zum Anpassen von Einstellungen bereitstellen.

`Message`

Eine Nachricht ist ein Objekt, das Netzwerkdaten kapselt – insbesondere Daten, die über ein Netzwerk übertragen oder empfangen werden. Die Nachrichtenstruktur wird durch SOAP definiert, mit einer separaten Gruppe von Kopfzeilen und einem Nachrichtentext. Die Header werden in einem Speicherpuffer platziert, und der Nachrichtentext wird mithilfe einer Datenstrom-API gelesen oder geschrieben.

Diagram showing the header and body of a message.

Obwohl das Datenmodell einer Nachricht immer das XML-Datenmodell ist, ist das tatsächliche Drahtformat flexibel. Bevor eine Nachricht übertragen wird, wird sie mithilfe einer bestimmten Codierung (z. B. Text, Binary oder MTOM) codiert. Weitere Informationen zu Codierungen finden Sie unter WS_ENCODING .

Diagram showing several message encoding formats.

Kanal

Ein Kanal ist ein Objekt, das zum Senden und Empfangen von Nachrichten in einem Netzwerk zwischen zwei oder mehr Endpunkten verwendet wird.

Kanäle haben zugeordnete Daten, die beschreiben, wie die Nachricht beim Senden adressiert wird. Das Senden einer Nachricht auf einem Kanal ist wie das Platzieren in einer Rutsche – der Kanal enthält die Informationen, wo die Nachricht gehen soll und wie sie dorthin gelangen.

Diagram showing channels for messages.

Kanäle werden in Kanaltypen kategorisiert. Ein Kanaltyp gibt an, welche Richtung Nachrichten fließen können. Der Kanaltyp gibt auch an, ob der Kanal sitzungslos oder sitzungslos ist. Eine Sitzung wird als abstrakte Methode zum Korrelieren von Nachrichten zwischen zwei oder mehr Parteien definiert. Ein Beispiel für einen sitzungsvollen Kanal ist ein TCP-Kanal, der die TCP-Verbindung als konkrete Sitzungsimplementierung verwendet. Ein Beispiel für einen sitzungslosen Kanal ist UDP, der keinen zugrunde liegenden Sitzungsmechanismus aufweist. Obwohl HTTP über zugrunde liegende TCP-Verbindungen verfügt, wird diese Tatsache nicht direkt über diese API verfügbar gemacht und daher gilt HTTP auch als sitzungsloser Kanal.

Diagram showing sessionful and sessionless channel types.

Obwohl Kanaltypen die Richtungs- und Sitzungsinformationen für einen Kanal beschreiben, geben sie nicht an, wie der Kanal implementiert wird. Welches Protokoll sollte der Kanal verwenden? Wie schwer sollte der Kanal versuchen, die Nachricht zu übermitteln? Welche Art von Sicherheit wird verwendet? Ist es Singlecast oder Multicast? Diese Einstellungen werden als "Bindung" des Kanals bezeichnet. Die Bindung besteht aus folgenden Komponenten:

Diagram showing a list of channel properties.

Listener

Um mit der Kommunikation zu beginnen, erstellt der Client ein Channel-Objekt. Aber wie ruft der Dienst sein Channel-Objekt ab? Dies geschieht durch Erstellen eines Listeners. Das Erstellen eines Listeners erfordert dieselben Bindungsinformationen, die zum Erstellen eines Kanals erforderlich sind. Nachdem ein Listener erstellt wurde, kann die Anwendung Kanäle aus dem Listener annehmen. Da die Anwendung möglicherweise in akzeptierten Kanälen zurückfällt, behalten Hörer in der Regel eine Warteschlange von Kanälen, die bereit sind, zu akzeptieren (bis zu einigen Kontingenten).

Diagram showing channels in the Listener queue.

Initiieren der Kommunikation (Client)

Um die Kommunikation auf dem Client zu initiieren, verwenden Sie die folgende Sequenz.

WsCreateChannel
for each address being sent to
{
    WsOpenChannel           // open channel to address
    // send and/or receive messages
    WsCloseChannel          // close channel
    WsResetChannel?         // reset if opening again
}
WsFreeChannel

Annehmen der Kommunikation (Server)

Um eingehende Kommunikationen auf dem Server zu akzeptieren, verwenden Sie die folgende Sequenz.

WsCreateListener
WsOpenListener
for each channel being accepted (can be done in parallel)
{
    WsCreateChannelForListener
    for each accept
    {
        WsAcceptChannel     // accept the channel
        // send and/or receive messages
        WsCloseChannel      // close the channel
        WsResetChannel?     // reset if accepting again
    }
    WsFreeChannel
}
WsCloseListener
WsFreeListener

Senden von Nachrichten (Client oder Server)

Um Nachrichten zu senden, verwenden Sie die folgende Sequenz.

WsCreateMessageForChannel
for each message being sent
{
    WsSendMessage       // send message
    WsResetMessage?     // reset if sending another message
}
WsFreeMessage

Die WsSendMessage-Funktion lässt das Streaming nicht zu und geht davon aus, dass der Textkörper nur ein Element enthält. Um diese Einschränkungen zu vermeiden, verwenden Sie die folgende Sequenz anstelle von WsSendMessage.

WsInitializeMessage     // initialize message to WS_BLANK_MESSAGE
WsSetHeader             // serialize action header into header buffer
WsAddressMessage?       // optionally address message
for each application defined header
{
    WsAddCustomHeader   // serialize application-defined headers into header buffer
}
WsWriteMessageStart     // write out the headers of the message
for each element of the body
{
    WsWriteBody         // serialize the element of the body
    WsFlushBody?        // optionally flush the body
}
WsWriteMessageEnd       // write the end of the message

Die WsWriteBody-Funktion verwendet Serialisierung zum Schreiben der Textkörperelemente. Um die Daten direkt in den XML Writer zu schreiben, verwenden Sie die folgende Sequenz anstelle von WsWriteBody.

WS_MESSAGE_PROPERTY_BODY_WRITER     // get the writer used to write the body
WsWriteStartElement
// use the writer functions to write the body
WsWriteEndElement
// optionally flush the body
WsFlushBody?        

Die WsAddCustomHeader-Funktion verwendet serialisierung, um die Kopfzeilen auf den Headerpuffer der Nachricht festzulegen. Um den XML Writer zum Schreiben einer Kopfzeile zu verwenden, verwenden Sie die folgende Sequenz anstelle von WsAddCustomHeader.

WS_MESSAGE_PROPERTY_HEADER_BUFFER   // get the header buffer 
WsCreateWriter                      // create an xml writer
WsSetOutputToBuffer                 // specify output of writer should go to buffer
WsMoveWriter*                       // move to inside envelope header element
WsWriteStartElement                 // write application header start element
// use the writer functions to write the header 
WsWriteEndElement                   // write appilcation header end element

Empfangen von Nachrichten (Client oder Server)

Um Nachrichten zu empfangen, verwenden Sie die folgende Sequenz.

WsCreateMessageForChannel
for each message being received
{
    WsReceiveMessage            // receive a message
    WsGetHeader*                // optionally access standard headers such as To or Action
    WsResetMessage              // reset if reading another message
}
WsFreeMessage

Die WsReceiveMessage-Funktion lässt das Streaming nicht zu und geht davon aus, dass der Textkörper nur ein Element enthält und dass der Typ der Nachricht (Aktion und Schema des Textkörpers) vorn bekannt ist. Um diese Einschränkungen zu vermeiden, verwenden Sie die folgende Sequenz anstelle von WsReceiveMessage.

WsReadMessageStart              // read all headers into header buffer
for each standard header
{
    WsGetHeader                 // deserialize standard header such as To or Action
}
for each application defined header
{
    WsGetCustomHeader           // deserialize application defined header
}
for each element of the body
{
    WsFillBody?                 // optionally fill the body
    WsReadBody                  // deserialize element of body
}
WsReadMessageEnd                // read end of message

Die WsReadBody-Funktion verwendet Serialisierung zum Lesen der Textkörperelemente. Um die Daten direkt aus dem XML-Reader zu lesen, verwenden Sie die folgende Sequenz anstelle von WsReadBody.

WS_MESSAGE_PROPERTY_BODY_READER     // get the reader used to read the body
WsFillBody?                         // optionally fill the body
WsReadToStartElement                // read up to the body element
WsReadStartElement                  // consume the start of the body element
// use the read functions to read the contents of the body element
WsReadEndElement                    // consume the end of the body element

Die WsGetCustomHeader-Funktionen verwenden die Serialisierung, um die Header aus dem Headerpuffer der Nachricht abzurufen. Um den XML-Reader zum Lesen eines Headers zu verwenden, verwenden Sie die folgende Sequenz anstelle von WsGetCustomHeader.

WS_MESSAGE_PROPERTY_HEADER_BUFFER   // get the header buffer 
WsCreateReader                      // create an xml reader
WsSetInputToBuffer                  // specify input of reader should be buffer
WsMoveReader*                       // move to inside header element
while looking for header to read
{
    WsReadToStartElement            // see if the header matches the application header
    if header matched
    {
        WsGetHeaderAttributes?      // get the standard header attributes
        WsReadStartElement          // consume the start of the header element
        // use the read functions to read the contents of the header element
        WsReadEndElement            // consume the end of the header element
    }
    else
    {
        WsSkipNode                  // skip the header element
    }
}                

Antwort anfordern (Client)

Das Ausführen einer Anforderungsantwort auf dem Client kann mit der folgenden Sequenz erfolgen.

WsCreateMessageForChannel               // create request message 
WsCreateMessageForChannel               // create reply message 
for each request reply
{
    WsRequestReply                      // send request, receive reply
    WsResetMessage?                     // reset request message (if repeating)
    WsResetMessage?                     // reset reply message (if repeating)
}
WsFreeMessage                           // free request message
WsFreeMessage                           // free reply message

Die WsRequestReply-Funktion setzt ein einzelnes Element für den Textkörper der Anforderungs- und Antwortnachrichten voraus, und dass der Typ der Nachricht (Aktion und Schema des Textkörpers) vorn bekannt ist. Um diese Einschränkungen zu vermeiden, kann die Anforderungs- und Antwortnachricht manuell gesendet werden, wie in der folgenden Sequenz gezeigt. Diese Sequenz stimmt mit der früheren Sequenz für das Senden und Empfangen einer Nachricht überein, mit Ausnahme der angegebenen Stelle.

WsInitializeMessage     // initialize message to WS_BLANK_MESSAGE
WsSetHeader             // serialize action header into header buffer
WsAddressMessage?       // optionally address message

// the following block is specific to sending a request
{
    generate a unique MessageID for request
    WsSetHeader         // set the message ID            
}

for each application defined header
{
    WsAddCustomHeader   // serialize application-defined headers into header buffer
}
WsWriteMessageStart     // write out the headers of the message
for each element of the body
{
    WsWriteBody         // serialize the element of the body
    WsFlushBody?        // optionally flush the body
}
WsWriteMessageEnd       // write the end of the message

WsReadMessageStart      // read all headers into header buffer

// the following is specific to receiving a reply
{
    WsGetHeader         // deserialize RelatesTo ID of reply
    verify request MessageID is equal to RelatesTo ID
}

for each standard header
{
    WsGetHeader         // deserialize standard header such as To or Action
}
for each application defined header
{
    WsGetCustomHeader   // deserialize application defined header
}
for each element of the body
{
    WsFillBody?         // optionally fill the body
    WsReadBody          // deserialize element of body
}
WsReadMessageEnd        // read end of message                

Antwort anfordern (Server)

Um eine Anforderungsnachricht auf dem Server zu empfangen, verwenden Sie dieselbe Sequenz wie im vorherigen Abschnitt zum Empfangen von Nachrichten.

Um eine Antwort oder Fehlermeldung zu senden, verwenden Sie die folgende Sequenz.

WsCreateMessageForChannel
for each reply being sent
{
    WsSendReplyMessage | WsSendFaultMessageForError  // send reply or fault message
    WsResetMessage?     // reset if sending another message
}
WsFreeMessage

Die WsSendReplyMessage-Funktion setzt ein einzelnes Element im Textkörper voraus und lässt das Streaming nicht zu. Um diese Einschränkungen zu vermeiden, verwenden Sie die folgende Sequenz. Dies entspricht der früheren Sequenz zum Senden einer Nachricht, verwendet jedoch WS_REPLY_MESSAGE anstelle von WS_BLANK_MESSAGE beim Initialisieren.

// the following block is specific to sending a reply
{
    WsInitializeMessage // initialize message to WS_REPLY_MESSAGE
}
WsSetHeader             // serialize action header into header buffer                                
WsAddressMessage?       // optionally address message
for each application defined header
{
    WsAddCustomHeader   // serialize application-defined headers into header buffer
}
WsWriteMessageStart     // write out the headers of the message
for each element of the body
{
    WsWriteBody         // serialize the element of the body
    WsFlushBody?        // optionally flush the body
}
WsWriteMessageEnd       // write the end of the message

Nachrichtenaustauschmuster

Die WS_CHANNEL_TYPE diktieren das Nachrichtenaustauschmuster für einen bestimmten Kanal. Der unterstützte Typ variiert je nach Bindung wie folgt:

Nachrichtenschleifen

Für jedes Nachrichtenaustauschmuster gibt es eine bestimmte "Schleife", die zum Senden oder Empfangen von Nachrichten verwendet werden kann. Die Schleife beschreibt die rechtliche Reihenfolge der Vorgänge, die zum Senden/Empfangen mehrerer Nachrichten erforderlich sind. Die Schleifen werden unten als Grammatikproduktionen beschrieben. Der Begriff "End" ist ein Empfang, bei dem WS_S_END zurückgegeben wird (Siehe Windows Rückgabewerte für Webdienste), der angibt, dass im Kanal keine weiteren Nachrichten verfügbar sind. Die parallele Produktion gibt an, dass für parallele(x & y) der Vorgang x gleichzeitig mit y durchgeführt werden kann.

Die folgenden Schleifen werden auf dem Client verwendet:

client-loop := client-request-loop | client-duplex-session-loop | client-duplex-loop
client-request-loop := open (send (receive | end))* close // WS_CHANNEL_TYPE_REQUEST
client-duplex-session-loop := open parallel(send* & receive*) parallel(send? & end*) close // WS_CHANNEL_TYPE_DUPLEX_SESSION
client-duplex-loop := open parallel(send & receive)* close // WS_CHANNEL_TYPE_DUPLEX

Die folgenden Schleifen werden auf dem Server verwendet:

server-loop: server-reply-loop | server-duplex-session-loop | server-duplex-loop
server-reply-loop := accept receive end* send? end* close // WS_CHANNEL_TYPE_REPLY
server-duplex-session-loop := accept parallel(send* & receive*) parallel(send* & end*) close // WS_CHANNEL_TYPE_DUPLEX_SESSION
server-input-loop := accept receive end* close // WS_CHANNEL_TYPE_INPUT

Die Verwendung der WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING auf dem Server erfordert einen erfolgreichen Empfang, bevor das Senden auch mit einem Kanal vom Typ WS_CHANNEL_TYPE_DUPLEX_SESSION zulässig ist. Nach dem ersten Empfang. Die reguläre Schleife gilt.

Beachten Sie, dass Kanäle vom Typ WS_CHANNEL_TYPE_REQUEST und WS_CHANNEL_TYPE_REPLY zum Senden und Empfangen von unidirektionale Nachrichten (sowie das Standardmuster für die Anforderungsantwort) verwendet werden können. Dies wird erreicht, indem Sie den Antwortkanal schließen, ohne eine Antwort zu senden. In diesem Fall wird auf dem Anforderungskanal keine Antwort empfangen. Der Rückgabewert WS_S_END Verwendung der WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING auf dem Server erfordert einen erfolgreichen Empfang, bevor das Senden auch mit einem Kanal vom Typ WS_CHANNEL_TYPE_DUPLEX_SESSION zulässig ist. Nachdem der erste Empfang der regulären Schleife angewendet wurde.

wird zurückgegeben, was angibt, dass keine Nachricht verfügbar ist.

Client- oder Serverschleifen können parallel miteinander ausgeführt werden, indem mehrere Kanalinstanzen verwendet werden.

parallel-client: parallel(client-loop(channel1) & client-loop(channel2) & ...)
parallel-server: parallel(server-loop(channel1) & server-loop(channel2) & ...)

Nachrichtenfilterung

Ein Serverkanal kann empfangene Nachrichten filtern, die nicht für die Anwendung vorgesehen sind, z. B. Nachrichten, die einen Sicherheitskontext einrichten. In diesem Fall werden WS_S_END von WsReadMessageStart zurückgegeben, und auf diesem Kanal stehen keine Anwendungsnachrichten zur Verfügung. Dies signalisiert jedoch nicht, dass der Client die Kommunikation mit dem Server beenden soll. Weitere Nachrichten sind möglicherweise auf einem anderen Kanal verfügbar. Siehe WsShutdownSessionChannel.

Abbruch

Die WsAbortChannel-Funktion wird verwendet, um ausstehende IO für einen Kanal abzubrechen. Diese API wartet nicht darauf, dass der IO-Vorgang abgeschlossen ist. Weitere Informationen finden Sie in der WS_CHANNEL_STATE Zustandsdiagramm und dokumentation für WsAbortChannel .

Die WsAbortListener-API wird verwendet, um ausstehende IO für einen Listener abzubrechen. Diese API wartet nicht darauf, dass der IO-Vorgang abgeschlossen ist. Das Abbrechen eines Listeners führt dazu, dass alle ausstehenden Annahmen abgebrochen werden. Weitere Informationen finden Sie im WS_LISTENER_STATEZustandsdiagramm und WsAbortListener .

TCP

Die WS_TCP_CHANNEL_BINDING unterstützt SOAP über TCP. Die SOAP over TCP-Spezifikation baut auf dem .NET Framing-Mechanismus auf.

Die Portfreigabe wird in dieser Version nicht unterstützt. Jeder Listener, der geöffnet wird, muss eine andere Portnummer verwenden.

UDP

Die WS_UDP_CHANNEL_BINDING unterstützt SOAP über UDP.

Es gibt eine Reihe von Einschränkungen mit der UDP-Bindung:

  • Es gibt keine Unterstützung für Sicherheit.
  • Nachrichten können verloren oder dupliziert werden.
  • Nur eine Codierung wird unterstützt: WS_ENCODING_XML_UTF8.
  • Nachrichten sind grundsätzlich auf 64k beschränkt und haben häufig eine größere Chance, verloren zu gehen, wenn die Größe die MTU des Netzwerks überschreitet.

HTTP

Die WS_HTTP_CHANNEL_BINDING unterstützt SOAP über HTTP.

Informationen zum Steuern von HTTP-spezifischen Headern auf dem Client und dem Server finden Sie unter WS_HTTP_MESSAGE_MAPPING.

Um nicht-SOAP-Nachrichten auf dem Server zu senden und zu empfangen, verwenden Sie WS_ENCODING_RAW für WS_CHANNEL_PROPERTY_ENCODING.

BENANNTEPIPES

Die WS_NAMEDPIPE_CHANNEL_BINDING unterstützt SOAP über benannte Rohre, wodurch die Kommunikation mit dem Windows Communication Foundation (WCF)-Dienst mithilfe von NetNamedPipeBinding ermöglicht wird.

Korrelieren von Anforderungs-/Antwortnachrichten

Anforderungs-/Antwortnachrichten werden auf zwei Arten korreliert:

  • Die Korrelation erfolgt mithilfe des Kanals als Korrelationsmechanismus. Wenn Sie beispielsweise WS_ADDRESSING_VERSION_TRANSPORT und WS_HTTP_CHANNEL_BINDING die Antwort für die Anforderungsnachricht verwenden, wird die Anforderung durch die Tatsache korreliert, dass es sich um den Entitätstext der HTTP-Antwort handelt.
  • Die Korrelation wird mit den Headern "MessageID" und "RelationTo" durchgeführt. Dieser Mechanismus wird mit WS_ADDRESSING_VERSION_1_0 und WS_ADDRESSING_VERSION_0_9 (auch bei verwendung WS_HTTP_CHANNEL_BINDING) verwendet. In diesem Fall enthält die Anforderungsnachricht den MessageID-Header. Die Antwortnachricht enthält einen RelatesTo-Header, der den Wert des MessageID-Headers der Anforderung aufweist. Der Aspx-Header ermöglicht dem Client, eine Antwort mit einer gesendeten Anforderung zu korrelieren.

Die folgenden Kanalebenen-APIs verwenden automatisch die entsprechenden Korrelationsmechanismen basierend auf dem WS_ADDRESSING_VERSION des Kanals.

Wenn diese APIs nicht verwendet werden, können die Kopfzeilen manuell hinzugefügt und mit WsSetHeader oder WsGetHeader zugegriffen werden.

Benutzerdefinierte Kanäle und Listener

Wenn die vordefinierte Gruppe von Kanalbindungen nicht den Anforderungen der Anwendung entspricht, kann eine benutzerdefinierte Kanal- und Listenerimplementierung definiert werden, indem WS_CUSTOM_CHANNEL_BINDING beim Erstellen des Kanals oder Listeners angegeben werden. Die tatsächliche Implementierung des Kanals/Listeners wird als Reihe von Rückrufen über WS_CHANNEL_PROPERTY_CUSTOM_CHANNEL_CALLBACKS oder WS_LISTENER_PROPERTY_CUSTOM_LISTENER_CALLBACKS Eigenschaften angegeben. Sobald ein benutzerdefinierter Kanal oder Listener erstellt wurde, ist das Ergebnis ein WS_CHANNEL - oder WS_LISTENER-Objekt , das mit vorhandenen APIs verwendet werden kann.

Ein benutzerdefinierter Kanal und listener kann auch mit Service Proxy und Service Host verwendet werden, indem der WS_CUSTOM_CHANNEL_BINDING Wert in der WS_CHANNEL_BINDING-Aufzählung und die eigenschaften WS_CHANNEL_PROPERTY_CUSTOM_CHANNEL_CALLBACKS und WS_LISTENER_PROPERTY_CUSTOM_LISTENER_CALLBACKS beim Erstellen des Dienstproxys oder Diensthosts angegeben werden.

Sicherheit

Der Kanal ermöglicht es, den Arbeitsspeicher zu beschränken, der für verschiedene Aspekte von Vorgängen verwendet wird, z. B. durch Eigenschaften:

Diese Eigenschaften verfügen über Standardwerte, die für die meisten Szenarien konservativ und sicher sind. Standardwerte und alle Änderungen an ihnen sollten sorgfältig auf potenzielle Angriffsvektoren ausgewertet werden, die denial of Service durch einen Remotebenutzer verursachen können.

Der Kanal ermöglicht das Festlegen von Timeoutwerten für verschiedene Aspekte von Vorgängen durch Eigenschaften wie:

Diese Eigenschaften verfügen über Standardwerte, die für die meisten Szenarien konservativ und sicher sind. Die steigenden Timeoutwerte erhöhen die Zeit, mit der eine Remotepartei eine lokale Ressource lebendig halten kann, z. B. Arbeitsspeicher, Sockets und Threads, die synchrone I/O ausführen. Eine Anwendung sollte die Standardwerte auswerten und vorsicht verwenden, wenn ein Timeout erhöht wird, da potenzielle Angriffsvektoren geöffnet werden können, die denial of Service von einem Remotecomputer verursachen können.

Einige der anderen Konfigurationsoptionen und Anwendungsdesignaspekte, die bei verwendung der WWSAPI-Kanal-API sorgfältig ausgewertet werden sollten:

  • Wenn Sie die Kanal-/Listener-Ebene verwenden, ist es bis zur Anwendung, um Kanäle auf der Serverseite zu erstellen und zu akzeptieren. Ebenso ist es bis zur Anwendung erforderlich, um Kanäle auf der Clientseite zu erstellen und zu öffnen. Eine Anwendung sollte eine obere Grenze für diese Vorgänge setzen, da jeder Kanal Speicher und andere eingeschränkte Ressourcen wie Sockets verbraucht. Eine Anwendung sollte besonders vorsichtig sein, wenn Sie einen Kanal als Reaktion auf eine Aktion erstellen, die von einer Remotepartei ausgelöst wird.
  • Es ist bis zur Anwendung, um die Logik zum Erstellen von Kanälen zu schreiben und sie zu akzeptieren. Jeder Kanal verbraucht begrenzte Ressourcen wie Arbeitsspeicher und Sockets. Eine Anwendung sollte über eine obere Grenze für die Anzahl der Kanäle verfügen, die sie akzeptieren möchten, oder eine Remotepartei könnte viele Verbindungen herstellen, die zu OOM führen und daher denial of service. Es sollte auch aktiv Nachrichten von diesen Verbindungen mit einem kleinen Timeout empfangen. Wenn keine Nachrichten empfangen werden, wird der Vorgang ausgedauert und die Verbindung sollte freigegeben werden.
  • Es ist bis zu einer Anwendung, um eine Antwort oder einen Fehler zu senden, indem Sie die Soap-Header "ReplyTo" oder "FaultTo" interpretieren. Die sichere Vorgehensweise besteht darin, nur einen ReplyTo- oder FaultTo-Header zu ehren, der "anonym" ist, was bedeutet, dass die vorhandene Verbindung (TCP, HTTP) oder quell-IP (UDP) verwendet werden soll, um die SOAP-Antwort zu senden. Anwendungen sollten bei der Erstellung von Ressourcen (z. B. einem Kanal) extrem vorsichtig sein, um auf eine andere Adresse zu antworten, es sei denn, die Nachricht wurde von einer Partei signiert, die für die Adresse sprechen kann, an die die Antwort gesendet wird.
  • Die Überprüfung, die auf der Kanalebene durchgeführt wurde, ist kein Ersatz für die Datenintegrität, die durch Sicherheit erreicht wird. Eine Anwendung muss sich auf Sicherheitsfeatures der WWSAPI verlassen, um sicherzustellen, dass sie mit einer vertrauenswürdigen Entität kommunizieren und sich auch auf sicherheit verlassen müssen, um die Datenintegrität zu gewährleisten.

Ebenso gibt es Nachrichtenkonfigurationsoptionen und Anwendungsentwurfsüberlegungen, die bei verwendung der WWSAPI-Nachrichten-API sorgfältig ausgewertet werden sollten:

  • Die Größe der zum Speichern der Kopfzeilen einer Nachricht verwendeten Heap kann mithilfe der WS_MESSAGE_PROPERTY_HEAP_PROPERTIES-Eigenschaft konfiguriert werden. Die Erhöhung dieses Werts ermöglicht es, mehr Arbeitsspeicher von den Kopfzeilen der Nachricht zu nutzen, die zu OOM führen können.
  • Der Benutzer des Nachrichtenobjekts muss erkennen, dass die Headerzugriffs-APIs O(n) im Hinblick auf die Anzahl der Kopfzeilen in der Nachricht sind, da sie nach Duplikaten suchen. Designs, die viele Kopfzeilen in einer Nachricht erfordern, können zu übermäßiger CPU-Nutzung führen.
  • Die maximale Anzahl von Kopfzeilen in einer Nachricht kann mithilfe der WS_MESSAGE_PROPERTY_MAX_PROCESSED_HEADERS-Eigenschaft konfiguriert werden. Es gibt auch eine implizite Grenze basierend auf der Größe des Heaps der Nachricht. Durch die Erhöhung dieser Werte können mehr Kopfzeilen vorhanden sein, die die Zeit, die erforderlich sind, um einen Header zu finden (bei Verwendung der Headerzugriffs-APIs).