Overzicht van kanaallagen

De kanaallaag biedt een abstractie van het transportkanaal en berichten die op het kanaal worden verzonden. Het bevat ook functies voor de serialisatie van C-gegevenstypen van en naar SOAP-structuren. De kanaallaag maakt volledige controle over communicatie mogelijk door middel van berichten bestaande uit gegevens die worden verzonden of ontvangen en die lichamen en headers bevatten, en kanalen die abstracte protocollen voor berichtuitwisseling bieden en eigenschappen bieden voor het aanpassen van instellingen.

Bericht

Een bericht is een object dat netwerkgegevens inkapselt, met name gegevens die via een netwerk worden verzonden of ontvangen. De berichtstructuur wordt gedefinieerd door SOAP, met een discrete set kopteksten en een berichttekst. De headers worden in een geheugenbuffer geplaatst en de berichttekst wordt gelezen of geschreven met behulp van een stream-API.

Hoewel het gegevensmodel van een bericht altijd het XML-gegevensmodel is, is de werkelijke draadindeling flexibel. Voordat een bericht wordt verzonden, wordt het gecodeerd met behulp van een bepaalde codering (zoals Tekst, Binair of MTOM). Zie WS_ENCODING voor meer informatie over coderingen.

Kanaal

Een -kanaal is een object dat wordt gebruikt voor het verzenden en ontvangen van berichten in een netwerk tussen twee of meer eindpunten.

Kanalen hebben gekoppelde gegevens waarin wordt beschreven hoe u adres het bericht wanneer het wordt verzonden. Het verzenden van een bericht op een kanaal is vergelijkbaar met het plaatsen ervan in een chute. Het kanaal bevat de informatie waar het bericht naartoe moet gaan en hoe u het daar kunt krijgen.

Kanalen worden onderverdeeld in kanaaltypen. Een kanaaltype geeft aan welke richtingsberichten kunnen stromen. Het kanaaltype geeft ook aan of het kanaal sessionful is of sessieloos. Een sessie wordt gedefinieerd als een abstracte manier om berichten tussen twee of meer partijen te correleren. Een voorbeeld van een sessievol kanaal is een TCP-kanaal, dat gebruikmaakt van de TCP-verbinding als de concrete sessie-implementatie. Een voorbeeld van een sessieloos kanaal is UDP, dat geen onderliggend sessiemechanisme heeft. Hoewel HTTP onderliggende TCP-verbindingen heeft, wordt dit feit niet rechtstreeks beschikbaar gesteld via deze API en wordt HTTP daarom ook beschouwd als een sessieloos kanaal.

Hoewel kanaaltypen de richtings- en sessiegegevens voor een kanaal beschrijven, geven ze niet op hoe het kanaal wordt geïmplementeerd. Welk protocol moet het kanaal gebruiken? Hoeveel moeite moet het kanaal doen om het bericht te bezorgen? Welk soort beveiliging wordt gebruikt? Is het singlecast of multicast? Deze instellingen worden de 'binding' van het kanaal genoemd. De binding bestaat uit het volgende:

• Een WS_CHANNEL_BINDING, waarmee het overdrachtsprotocol wordt geïdentificeerd dat moet worden gebruikt (TCP, UDP, HTTP, NAMEDPIPE).
• Een WS_SECURITY_DESCRIPTION, waarmee wordt aangegeven hoe het kanaal moet worden beveiligd.
• Een set WS_CHANNEL_PROPERTYs, waarmee aanvullende optionele instellingen worden opgegeven. Zie WS_CHANNEL_PROPERTY_ID voor de lijst met eigenschappen.

Luisteraar

Om te beginnen met communiceren, maakt de client een kanaalobject. Maar hoe krijgt de service het Kanaalobject? Dit gebeurt door een Listener-te maken. Voor het maken van een listener is dezelfde bindingsinformatie vereist die nodig is om een kanaal te maken. Zodra een listener is gemaakt, kan de toepassing Kanalen van de listener accepteren. Omdat de toepassing kan achterblijven bij het accepteren van kanalen, houden listeners doorgaans een wachtrij met kanalen die klaar zijn om te accepteren (tot een bepaald quotum).

Communicatie starten (client)

Gebruik de volgende reeks om communicatie op de client te starten.

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

Communicatie accepteren (server)

Gebruik de volgende reeks om binnenkomende communicatie op de server te accepteren.

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

Berichten verzenden (client óf server)

Gebruik de volgende volgorde om berichten te verzenden.

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

De WsSendMessage-functie staat streaming niet toe en gaat ervan uit dat de hoofdtekst slechts één element bevat. Gebruik de volgende volgorde in plaats van WsSendMessageom deze beperkingen te voorkomen.

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

De functie WsWriteBody maakt gebruik van serialisatie om de hoofdtekstelementen te schrijven. Als u de gegevens rechtstreeks naar de XML Writer wilt schrijven, gebruikt u de volgende reeks in plaats van 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?        

De functie WsAddCustomHeader maakt gebruik van serialisatie om de headers in te stellen op de headerbuffer van het bericht. Als u de XML Writer wilt gebruiken om een koptekst te schrijven, gebruikt u de volgende reeks in plaats van 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 application header end element

Ontvangen van berichten (client of server)

Gebruik de volgende volgorde om berichten te ontvangen.

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

De WsReceiveMessage-functie staat streaming niet toe en gaat ervan uit dat de hoofdtekst slechts één element bevat en dat het type bericht (actie en schema van de hoofdtekst) vooraf bekend is. Gebruik de volgende volgorde in plaats van WsReceiveMessageom deze beperkingen te voorkomen.

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

De functie WsReadBody maakt gebruik van serialisatie om de hoofdtekstelementen te lezen. Als u de gegevens rechtstreeks vanuit de XML Reader-wilt lezen, gebruikt u de volgende volgorde in plaats van 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

De functies WsGetCustomHeader gebruiken serialisatie om de headers op te halen uit de headerbuffer van het bericht. Als u de XML Reader- wilt gebruiken om een koptekst te lezen, gebruikt u de volgende reeks in plaats van 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
    }
}                

Antwoord aanvragen (client)

Het uitvoeren van een verzoek-antwoord op de client kan met de volgende reeks worden gedaan.

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

De WsRequestReply functie gaat uit van één element voor de hoofdtekst van de aanvraag- en antwoordberichten, en dat het type bericht (actie en schema van de hoofdtekst) vooraf bekend is. Om deze beperkingen te voorkomen, kan het verzoek en antwoordbericht handmatig worden verzonden, zoals wordt weergegeven in de volgende volgorde. Deze reeks komt overeen met de eerdere volgorde voor het verzenden en ontvangen van een bericht, behalve waar vermeld.

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                

Antwoord aanvragen (server)

Als u een aanvraagbericht op de server wilt ontvangen, gebruikt u dezelfde volgorde als in de vorige sectie over het ontvangen van berichten.

Gebruik de volgende volgorde om een antwoord- of foutbericht te verzenden.

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

De WsSendReplyMessage functie gaat uit van één element in de hoofdtekst en staat streaming niet toe. Gebruik de volgende volgorde om deze beperkingen te voorkomen. Dit is hetzelfde als de eerdere volgorde voor het verzenden van een bericht, maar gebruikt WS_REPLY_MESSAGE in plaats van WS_BLANK_MESSAGE bij het initialiseren.

// 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

Berichtuitwisselingspatronen

De WS_CHANNEL_TYPE bepaalt het berichtuitwisselingspatroon dat mogelijk is voor een bepaald kanaal. Het type dat wordt ondersteund, varieert afhankelijk van de binding, als volgt:

• WS_HTTP_CHANNEL_BINDING ondersteunt WS_CHANNEL_TYPE_REQUEST op de client en WS_CHANNEL_TYPE_REPLY op de server.
• WS_TCP_CHANNEL_BINDING ondersteunt WS_CHANNEL_TYPE_DUPLEX_SESSION op de client en WS_CHANNEL_TYPE_DUPLEX_SESSION op de server.
• WS_UDP_CHANNEL_BINDING ondersteunt WS_CHANNEL_TYPE_DUPLEX op de client en WS_CHANNEL_TYPE_INPUT op de server.
• WS_NAMEDPIPE_CHANNEL_BINDING ondersteunt WS_CHANNEL_TYPE_DUPLEX op de client en WS_CHANNEL_TYPE_INPUT op de server.

Berichtlussen

Voor elk patroon voor het uitwisselen van berichten is er een specifieke 'lus' die kan worden gebruikt om berichten te verzenden of te ontvangen. De lus beschrijft de juridische volgorde van de bewerkingen die nodig zijn voor het verzenden/ontvangen van meerdere berichten. De lussen worden hieronder beschreven als grammaticaproducties. De term 'end' is een ontvangst waarbij WS_S_END wordt geretourneerd (zie Windows Web Services Retourwaarden), waarmee wordt aangegeven dat er geen berichten meer beschikbaar zijn in het kanaal. De parallelle productie geeft aan dat voor parallel(x & y) de bewerking x gelijktijdig met y kan worden uitgevoerd.

De volgende lussen worden op de client gebruikt:

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

De volgende lussen worden op de server gebruikt:

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

Voor het gebruik van de WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING op de server is een geslaagde ontvangst vereist voordat verzenden is toegestaan, zelfs met een kanaal van het type WS_CHANNEL_TYPE_DUPLEX_SESSION. Na de eerste ontvangst. de reguliere lus is van toepassing.

Houd er rekening mee dat kanalen van het type WS_CHANNEL_TYPE_REQUEST en WS_CHANNEL_TYPE_REPLY kunnen worden gebruikt voor het verzenden en ontvangen van berichten in één richting (evenals het standaardpatroon voor het beantwoorden van aanvragen). Dit wordt bereikt door het antwoordkanaal te sluiten zonder een antwoord te verzenden. In dit geval wordt er geen antwoord ontvangen op het aanvraagkanaal. De retourwaarde is WS_S_END Het gebruik van WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING op de server vereist een geslaagde ontvangst voordat verzenden is toegestaan, zelfs met een kanaal van het type WS_CHANNEL_TYPE_DUPLEX_SESSION. Na de eerste ontvangst geldt de gebruikelijke loop.

wordt geretourneerd, wat aangeeft dat er geen bericht beschikbaar is.

Client- of serverloops kunnen parallel met elkaar worden uitgevoerd met behulp van meerdere kanaalexemplaren.

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

Berichtfiltering

Een serverkanaal kan ontvangen berichten filteren die niet zijn bedoeld voor de toepassing, zoals berichten die een beveiligingscontext tot stand brengen. In dat geval wordt WS_S_END geretourneerd door WsReadMessageStart en zijn er geen applicatieberichten beschikbaar op dat kanaal. Dit geeft echter niet aan dat de client bedoeld is om de communicatie met de server te beëindigen. Er zijn mogelijk meer berichten beschikbaar op een ander kanaal. Zie WsShutdownSessionChannel.

Afgelasting

De functie WsAbortChannel wordt gebruikt om wachtende IO voor een kanaal te annuleren. Deze API wacht niet totdat de IO-bewerking(en) zijn voltooid. Zie het WS_CHANNEL_STATE statusdiagram en de documentatie voor WsAbortChannel- voor meer informatie.

De WsAbortListener-API wordt gebruikt om in behandeling zijnde IO voor een listener te annuleren. Deze API wacht niet totdat de IO-bewerking(en) zijn voltooid. Het afbreken van een listener zal ertoe leiden dat alle openstaande acceptaties ook worden afgebroken. Zie het WS_LISTENER_STATE statusdiagram en WsAbortListener- voor meer informatie.

TCP

De WS_TCP_CHANNEL_BINDING ondersteunt SOAP via TCP. De SOAP via TCP-specificatie bouwt voort op het .NET-framemechanisme.

Delen van poorten wordt niet ondersteund in deze versie. Elke geopende listener moet een ander poortnummer gebruiken.

UDP

De WS_UDP_CHANNEL_BINDING ondersteunt SOAP via UDP.

Er zijn een aantal beperkingen met de UDP-binding:

• Er is geen ondersteuning voor beveiliging.
• Berichten kunnen verloren of gedupliceerd zijn.
• Er wordt slechts één codering ondersteund: WS_ENCODING_XML_UTF8.
• Berichten zijn fundamenteel beperkt tot 64.000 en hebben vaak een grotere kans dat ze verloren gaan als de grootte groter is dan de MTU van het netwerk.

HTTP

De WS_HTTP_CHANNEL_BINDING ondersteunt SOAP via HTTP.

Zie WS_HTTP_MESSAGE_MAPPINGom HTTP-specifieke headers op de client en server te beheren.

Als u niet-SOAP-berichten op de server wilt verzenden en ontvangen, gebruikt u WS_ENCODING_RAW voor WS_CHANNEL_PROPERTY_ENCODING.

NAMEDPIPES

De WS_NAMEDPIPE_CHANNEL_BINDING ondersteunt SOAP via named pipes, waardoor communicatie met de WCF-service (Windows Communication Foundation) mogelijk is met behulp van NetNamedPipeBinding.

Correleren van aanvraag-/antwoordberichten

Aanvraag-/antwoordberichten worden op twee manieren gecorreleerd:

• Correlatie wordt uitgevoerd met behulp van het kanaal als het correlatiemechanisme. Wanneer u bijvoorbeeld WS_ADDRESSING_VERSION_TRANSPORT gebruikt en WS_HTTP_CHANNEL_BINDING het antwoord voor het aanvraagbericht is gecorreleerd aan de aanvraag door het feit dat dit de entiteitstekst van het HTTP-antwoord is.
• Correlatie wordt uitgevoerd met behulp van de MessageID en RelateTo-headers. Dit mechanisme wordt gebruikt met WS_ADDRESSING_VERSION_1_0 en WS_ADDRESSING_VERSION_0_9 (zelfs bij gebruik van WS_HTTP_CHANNEL_BINDING). In dit geval bevat het aanvraagbericht de MessageID-header. Het antwoordbericht bevat een RelateTo-header met de waarde van de MessageID-header van de aanvraag. Met de Header RelateTo kan de client een antwoord correleren met een aanvraag die wordt verzonden.

De volgende API's van de kanaallaag gebruiken automatisch de juiste correlatiemechanismen op basis van de WS_ADDRESSING_VERSION van het kanaal.

• WsRequestReply
• WsSendReplyMessage
• WsSendFaultMessageForError

Als deze API's niet worden gebruikt, kunnen de headers handmatig worden toegevoegd en geopend met behulp van WsSetHeader- of WsGetHeader-.

Aangepaste kanalen en luisteraars

Als de vooraf gedefinieerde set kanaalbindingen niet voldoet aan de behoeften van de toepassing, kan een aangepaste implementatie van een kanaal en listener worden gedefinieerd door WS_CUSTOM_CHANNEL_BINDING op te geven bij het maken van het kanaal of de listener. De daadwerkelijke implementatie van de zender/de luisteraar wordt gespecificeerd als een reeks callback-functies via de eigenschappen WS_CHANNEL_PROPERTY_CUSTOM_CHANNEL_CALLBACKS of WS_LISTENER_PROPERTY_CUSTOM_LISTENER_CALLBACKS. Zodra een aangepast kanaal of listener is gemaakt, is het resultaat een WS_CHANNEL of WS_LISTENER object dat kan worden gebruikt met bestaande API's.

Een aangepast kanaal en listener kunnen ook worden gebruikt met Service-Proxy en Service-Host door de waarde WS_CUSTOM_CHANNEL_BINDING op te geven in de opsomming WS_CHANNEL_BINDING en de eigenschappen WS_CHANNEL_PROPERTY_CUSTOM_CHANNEL_CALLBACKS en WS_LISTENER_PROPERTY_CUSTOM_LISTENER_CALLBACKS bij het maken van de Service-Proxy of Service-Host.

Veiligheid

Het kanaal maakt het mogelijk om de hoeveelheid geheugen te beperken die wordt gebruikt voor verschillende aspecten van bewerkingen via eigenschappen zoals:

• WS_CHANNEL_PROPERTY_MAX_BUFFERED_MESSAGE_SIZE,
• WS_CHANNEL_PROPERTY_MAX_STREAMED_MESSAGE_SIZE,
• WS_CHANNEL_PROPERTY_MAX_STREAMED_START_SIZE,
• WS_CHANNEL_PROPERTY_MAX_HTTP_REQUEST_HEADERS_BUFFER_SIZE,
• WS_CHANNEL_PROPERTY_MAX_SESSION_DICTIONARY_SIZE.

Deze eigenschappen hebben standaardwaarden die conservatief en veilig zijn voor de meeste scenario's. Standaardwaarden en eventuele wijzigingen in deze waarden moeten zorgvuldig worden geëvalueerd op basis van mogelijke aanvalsvectoren die denial of service kunnen veroorzaken door een externe gebruiker.

Met het kanaal kunnen time-outwaarden worden ingesteld voor verschillende aspecten van bewerkingen via eigenschappen zoals:

• WS_CHANNEL_PROPERTY_CONNECT_TIMEOUT,
• WS_CHANNEL_PROPERTY_SEND_TIMEOUT,
• WS_CHANNEL_PROPERTY_RECEIVE_RESPONSE_TIMEOUT,
• WS_CHANNEL_PROPERTY_RECEIVE_TIMEOUT,
• WS_CHANNEL_PROPERTY_RESOLVE_TIMEOUT,
• WS_CHANNEL_PROPERTY_CLOSE_TIMEOUT.

Deze eigenschappen hebben standaardwaarden die conservatief en veilig zijn voor de meeste scenario's. Het verhogen van time-outwaarden verhoogt de tijdsduur dat een externe partij een lokale resource kan vasthouden, zoals geheugen, sockets en threads die synchrone I/O uitvoeren. Een toepassing moet de standaardwaarden evalueren en voorzichtig zijn bij het verhogen van een time-out, omdat er mogelijk aanvalsvectoren ontstaan die denial of service van een externe computer kunnen veroorzaken.

Enkele van de andere configuratieopties en overwegingen bij het ontwerpen van toepassingen die zorgvuldig moeten worden geëvalueerd bij het gebruik van DE WWSAPI-kanaal-API:

• Wanneer u de kanaal-/listenerlaag gebruikt, is het aan de toepassing om kanalen aan de serverzijde te maken en te accepteren. Op dezelfde manier is het aan de toepassing om kanalen aan de clientzijde te maken en te openen. Een toepassing moet een bovengrens voor deze bewerkingen plaatsen, omdat elk kanaal geheugen en andere beperkte resources zoals sockets verbruikt. Een toepassing moet met name voorzichtig zijn bij het maken van een kanaal als reactie op een actie die wordt geactiveerd door een externe partij.
• Het is aan de toepassing om de logica te schrijven om kanalen te maken en ze te accepteren. Elk kanaal verbruikt beperkte resources, zoals geheugen en sockets. Een toepassing moet een bovengrens hebben voor het aantal kanalen dat het wil accepteren, of een externe partij kan veel verbindingen maken, wat leidt tot OOM en dus denial of service. Het moet ook actief berichten van deze verbindingen ontvangen met behulp van een kleine time-out. Als er geen berichten worden ontvangen, treedt er een time-out op voor de bewerking en wordt de verbinding vrijgegeven.
• Het is aan een toepassing om een antwoord of fout te verzenden door de SOAP-headers ReplyTo of FaultTo te interpreteren. De veilige procedure is om alleen een ReplyTo- of FaultTo-header te respecteren die 'anoniem' is, wat betekent dat de bestaande verbinding (TCP, HTTP) of bron-IP (UDP) moet worden gebruikt om het SOAP-antwoord te verzenden. Toepassingen moeten uiterst voorzichtig zijn bij het maken van resources (zoals een kanaal) om een ander adres te beantwoorden, tenzij het bericht is ondertekend door een partij die kan spreken voor het adres waarnaar het antwoord wordt verzonden.
• De validatie die in de kanaallaag wordt uitgevoerd, is geen vervanging voor gegevensintegriteit die wordt bereikt via beveiliging. Een toepassing moet vertrouwen op beveiligingsfuncties van de WWSAPI om ervoor te zorgen dat deze communiceert met een vertrouwde entiteit en moet ook vertrouwen op beveiliging om de gegevensintegriteit te waarborgen.

Op dezelfde manier zijn er opties voor berichtconfiguratie en overwegingen bij het ontwerpen van toepassingen die zorgvuldig moeten worden geëvalueerd bij het gebruik van de WWSAPI-bericht-API:

• De grootte van de heap die wordt gebruikt om de kopteksten van een bericht op te slaan, kan worden geconfigureerd met behulp van de eigenschap WS_MESSAGE_PROPERTY_HEAP_PROPERTIES. Als u deze waarde verhoogt, kan er meer geheugen worden verbruikt door de headers van het bericht, wat kan leiden tot OOM.
• De gebruiker van het berichtobject moet zich realiseren dat de API's voor headertoegang O(n) zijn met betrekking tot het aantal headers in het bericht, omdat ze op duplicaten controleren. Ontwerpen waarvoor veel headers in een bericht nodig zijn, kunnen leiden tot overmatig CPU-gebruik.
• Het maximum aantal kopteksten in een bericht kan worden geconfigureerd met behulp van de eigenschap WS_MESSAGE_PROPERTY_MAX_PROCESSED_HEADERS. Er is ook een impliciete limiet op basis van de grootte van de geheugenheap van het bericht. Als u beide waarden verhoogt, kunnen er meer headers aanwezig zijn, wat de tijd verlengt die nodig is om een header te vinden (bij gebruik van de API's voor toegang tot headers).