Csatornaréteg áttekintése

A csatornaréteg absztrakciót biztosít az átviteli csatornáról, valamint a csatornán küldött üzenetekről. A C-adattípusok SOAP-struktúrákba és -struktúrákból történő szerializálására szolgáló függvényeket is tartalmaz. A Csatornaréteg lehetővé teszi a kommunikáció teljes vezérlését üzenetekkel, amelyek adatok küldéséből vagy fogadásából állnak, és amelyek tartalmazzák a törzseket és a fejléceket, valamint csatornákkal, amelyek az üzenetcsere protokolljait absztrahálják és tulajdonságokat biztosítanak a beállítások testreszabásához.

Üzenet

A üzenet egy olyan objektum, amely a hálózati adatokat foglalja magában– különösen a hálózaton keresztül továbbított vagy fogadott adatokat. Az üzenet struktúráját a SOAP határozza meg, különálló fejléckészlettel és üzenettörzsgel. A fejlécek egy memóriapufferbe kerülnek, és az üzenet törzse stream API-val olvasható vagy írható.

Bár az üzenet adatmodellje mindig az XML-adatmodell, a tényleges drótformátum rugalmas. Az üzenetek továbbítása előtt a rendszer egy adott kódolással (például szöveg, bináris vagy MTOM) kódolja azt. A kódolással kapcsolatos további információkért lásd a WS_ENCODING.

Csatorna

A csatorna egy olyan objektum, amely üzeneteket küld és fogad egy hálózaton két vagy több végpont között.

A csatornák társított adatokkal rendelkeznek, amelyek azt írják le, hogyan címet az üzenet küldésekor. Az üzenet küldése egy csatornán olyan, mintha egy csúszdában helyeznék el – a csatorna tartalmazza azokat az információkat, ahová az üzenetnek mennie kell, és hogy hogyan juthat hozzá.

A csatornák csatornatípusokba vannak kategorizálva. A csatorna típusa határozza meg, hogy az üzenetek milyen irányban haladhatnak. A csatorna típusa azt is azonosítja, hogy a csatorna munkamenet-alapú vagy munkamenet nélküli- e. A munkamenetek az üzenetek két vagy több fél közötti összekapcsolásának absztrakt módjáként definiálhatók. A munkamenet-alapú csatornákra példa egy TCP-csatorna, amely a TCP-kapcsolatot használja konkrét munkamenet-implementációként. A munkamenet nélküli csatornákra példa az UDP, amely nem rendelkezik mögöttes munkamenet-mechanizmussal. Bár a HTTP rendelkezik mögöttes TCP-kapcsolatokkal, ez a tény nem érhető el közvetlenül ezen az API-on keresztül, ezért a HTTP munkamenet nélküli csatornának is tekinthető.

Bár a csatornatípusok a csatorna irányát és munkamenetadatait írják le, nem határozzák meg a csatorna implementálásának módját. Milyen protokollt használjon a csatorna? A csatorna mennyire próbálja meg kézbesíteni az üzenetet? Milyen típusú biztonságot használnak? Egyszeri vagy csoportos küldésről van szó? Ezeket a beállításokat a csatorna "kötésének" nevezzük. A kötés a következőkből áll:

• Egy WS_CHANNEL_BINDING, amely azonosítja a használni kívánt átviteli protokollt (TCP, UDP, HTTP, NAMEDPIPE).
• Egy WS_SECURITY_DESCRIPTION, amely meghatározza a csatorna biztonságát.
• Egy WS_CHANNEL_PROPERTYkészlet, amely további választható beállításokat ad meg. A tulajdonságok listáját lásd a WS_CHANNEL_PROPERTY_ID.

Hallgató

A kommunikáció megkezdéséhez az ügyfél létrehoz egy Channel-objektumot. De hogyan kapja meg a szolgáltatás a Channel objektumot? Ez figyelőlétrehozásával történik. A figyelő létrehozásához ugyanazokra a kötési információkra van szükség, mint a csatorna létrehozásához. Miután létrehozott egy figyelőt, az alkalmazás elfogadhatja a csatornákat a figyelőből. Mivel az alkalmazás lemaradhat a csatornák elfogadásában, a hallgatók általában olyan csatornákat tartanak sorban, amelyek készen állnak az elfogadásra (valamennyi kvótáig).

Kommunikáció kezdeményezése (ügyfél)

Az ügyfélen való kommunikáció elindításához használja az alábbi sorozatot.

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

Kommunikáció elfogadása (kiszolgáló)

A kiszolgáló bejövő kommunikációjának elfogadásához használja az alábbi sorrendet.

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

Üzenetek küldése (ügyfél vagy kiszolgáló)

Üzenetek küldéséhez használja az alábbi sorozatot.

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

A WsSendMessage függvény nem engedélyezi a streamelést, és feltételezi, hogy a törzs csak egy elemet tartalmaz. A korlátozások elkerülése érdekében használja a következő sorrendet a WsSendMessagehelyett.

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

A WsWriteBody függvény szerializálással írja a törzselemeket. Ha közvetlenül az XML-íróba szeretné írni az adatokat, használja a következő sorozatot WsWriteBodyhelyett.

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?        

A WsAddCustomHeader függvény szerializálással állítja be a fejléceket az üzenet fejlécpufferébe. Ha az XML-íróval szeretne fejlécet írni, használja a következő sorozatot WsAddCustomHeaderhelyett.

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

Üzenetek fogadása (ügyfél vagy kiszolgáló)

Az üzenetek fogadásához használja az alábbi sorozatot.

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

A WsReceiveMessage függvény nem engedélyezi a streamelést, és feltételezi, hogy a törzs csak egy elemet tartalmaz, és hogy az üzenet típusa (a törzs művelete és sémája) előre ismert. A kényszerek elkerülése érdekében a következő sorozatot használja a WsReceiveMessagehelyett.

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

A WsReadBody függvény szerializálással olvassa be a törzselemeket. Az adatok közvetlen olvasásához az XML-olvasóból, a WsReadBodyhelyett a következő sorozatot használja.

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

A WsGetCustomHeader függvények szerializálással kapják le a fejléceket az üzenet fejlécpufferéből. Ha a XML-olvasót szeretné használni egy fejléc olvasásához, használja a következő sorozatot WsGetCustomHeaderhelyett.

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

Válasz kérése (ügyfél)

A kérés-válasz végrehajtása az ügyfélen az alábbi sorrendben végezhető el.

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

A WsRequestReply függvény a kérés és a válaszüzenetek törzsének egyetlen elemét feltételezi, és hogy az üzenet típusa (a törzs művelete és sémája) előre ismert. A korlátozások elkerülése érdekében a kérés és a válaszüzenet manuálisan is elküldhető, ahogyan az alábbi sorrendben látható. Ez a sorozat megegyezik az üzenet küldésének és fogadásának korábbi sorozatával, kivéve a feljegyzett elemeket.

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                

Válasz kérése (kiszolgáló)

Ha kérésüzenetet szeretne kapni a kiszolgálón, használja ugyanazt a sorozatot, amelyet az üzenetek fogadásáról szóló előző szakaszban ismertetett.

Válasz vagy hibaüzenet küldéséhez használja az alábbi sorozatot.

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

A WsSendReplyMessage függvény egyetlen elemet feltételez a törzsben, és nem teszi lehetővé a streamelést. A korlátozások elkerülése érdekében használja az alábbi sorozatot. Ez megegyezik az üzenetküldés korábbi sorozatával, de az inicializáláskor WS_BLANK_MESSAGE helyett WS_REPLY_MESSAGE használ.

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

Üzenetváltási minták

A WS_CHANNEL_TYPE egy adott csatorna üzenetváltási mintáját határozza meg. A támogatott típus a kötéstől függően változik, az alábbiak szerint:

• WS_HTTP_CHANNEL_BINDING támogatja a kliensen a WS_CHANNEL_TYPE_REQUEST típust és a kiszolgálón a WS_CHANNEL_TYPE_REPLY típust.
• WS_TCP_CHANNEL_BINDING támogatja a WS_CHANNEL_TYPE_DUPLEX_SESSION az ügyféloldalon és a WS_CHANNEL_TYPE_DUPLEX_SESSION a kiszolgáló oldalon.
• WS_UDP_CHANNEL_BINDING támogatja a kliensen a WS_CHANNEL_TYPE_DUPLEX-et és a szerveren a WS_CHANNEL_TYPE_INPUT-et.
• WS_NAMEDPIPE_CHANNEL_BINDING támogatja a WS_CHANNEL_TYPE_DUPLEX az ügyfélen, és a WS_CHANNEL_TYPE_INPUT a kiszolgálón.

Üzenet feldolgozási hurkok

Minden üzenetcsere-mintához létezik egy adott "hurok", amely üzenetek küldéséhez vagy fogadásához használható. A hurok a több üzenet küldéséhez/fogadásához szükséges műveletek jogi sorrendjét ismerteti. A ciklusokat az alábbiakban nyelvtani produkciókként ismertetjük. A "vég" kifejezés egy olyan vételt jelöl, ahol a WS_S_END értéket kapjuk vissza (lásd a Windows Web Services visszatérési értékeit), amely azt jelzi, hogy a csatornán nem érhetők el további üzenetek. A párhuzamos termelés azt határozza meg, hogy a párhuzamos (x & y) esetében az x művelet egyidejűleg y-vel is elvégezhető legyen.

Az ügyfél a következő hurkokat használja:

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

A kiszolgáló a következő hurkokat használja:

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

A WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING használatához a kiszolgálón sikeres fogadásra van szükség, mielőtt a küldés engedélyezett még egy WS_CHANNEL_TYPE_DUPLEX_SESSIONtípusú csatornán is. Az első érkezés után. a normál hurok alkalmazható.

Vegye figyelembe, hogy az WS_CHANNEL_TYPE_REQUEST és WS_CHANNEL_TYPE_REPLY típusú csatornák használhatók egyirányú üzenetek küldésére és fogadására (valamint a szabványos kérés-válasz mintára). Ez úgy érhető el, hogy válasz küldése nélkül bezárja a válaszcsatornát. Ebben az esetben nem érkezik válasz a kérelemcsatornára. A visszatérési érték WS_S_END akkor, ha a kiszolgáló használja a WS_SECURITY_CONTEXT_MESSAGE_SECURITY_BINDING funkciót, sikeres fogadást igényel, mielőtt a küldés engedélyezve lenne, még akkor is, ha WS_CHANNEL_TYPE_DUPLEX_SESSIONtípusú csatornát használ. Az első lépés után a szokásos ciklus lép életbe.

vissza lesz adva, jelezve, hogy nincs elérhető üzenet.

Az ügyfél- vagy kiszolgálóhurokok párhuzamosan futtathatók több csatornapéldány használatával.

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

Üzenetszűrés

A kiszolgálócsatornák szűrhetik az alkalmazásnak nem szánt fogadott üzeneteket, például azokat az üzeneteket, amelyek biztonsági környezetet hoznak létre. Ebben az esetben WS_S_END vissza lesz küldve a WsReadMessageStart által, így ezen a csatornán nem lesznek elérhetők alkalmazásüzenetek. Ez azonban nem jelenti azt, hogy az ügyfél véget akart vetni a kiszolgálóval való kommunikációnak. Előfordulhat, hogy további üzenetek érhetők el egy másik csatornán. Lásd: WsShutdownSessionChannel.

Törlés

A WsAbortChannel függvénnyel törölhető a csatornához tartozó, függőben lévő IO. Ez az API nem várja meg, amíg az IO-művelet(ek) befejeződnek. További információt a WsAbortChannelWS_CHANNEL_STATE állapotdiagramjában és dokumentációjában talál.

A WsAbortListener API-val megszakítható a függőben lévő IO a figyelő számára. Ez az API nem várja meg, amíg az IO-művelet(ek) befejeződnek. A figyelő megszakítása a folyamatban lévő elfogadások megszakadását is okozza. További információért tekintse meg a WS_LISTENER_STATE állapotdiagramot és WsAbortListener.

TCP

A WS_TCP_CHANNEL_BINDING tcp-en keresztül támogatja a SOAP-t. A SOAP TCP-protokollon keresztüli specifikációja a .NET-keretezési mechanizmusra épül.

A portmegosztás ebben a verzióban nem támogatott. Minden megnyitott figyelőnek más portszámot kell használnia.

UDP

A WS_UDP_CHANNEL_BINDING támogatja a SOAP-t UDP-en keresztül.

Az UDP-kötés számos korlátozással rendelkezik:

• Nincs támogatás a biztonsághoz.
• Előfordulhat, hogy az üzenetek elvesznek vagy duplikálva lesznek.
• Csak egy kódolás támogatott: WS_ENCODING_XML_UTF8.
• Az üzenetek alapvetően 64k-ra korlátozódnak, és gyakran nagyobb eséllyel vesznek el, ha a méret meghaladja a hálózat MTU-ját.

HTTP

A WS_HTTP_CHANNEL_BINDING HTTP-en keresztül támogatja a SOAP-t.

Az ügyfél és a kiszolgáló HTTP-specifikus fejléceinek szabályozásához lásd: WS_HTTP_MESSAGE_MAPPING.

Ha nem SOAP-üzeneteket szeretne küldeni és fogadni a kiszolgálón, használja a WS_ENCODING_RAWWS_CHANNEL_PROPERTY_ENCODING.

NAMEDPIPES

A WS_NAMEDPIPE_CHANNEL_BINDING támogatja a SOAP-t nevesített csöveken keresztül, lehetővé téve a Windows Communication Foundation (WCF) szolgáltatással való kommunikációt a NetNamedPipeBinding használatával.

Kérés/válaszüzenetek korrelációja

A kérelem-/válaszüzenetek kétféleképpen vannak korrelálva:

• A korreláció a csatornát használja korrelációs mechanizmusként. Ha például WS_ADDRESSING_VERSION_TRANSPORT és WS_HTTP_CHANNEL_BINDING használ, akkor a kérés üzenetére adott válasz a HTTP-válasz entitástörzseként korrelál a kéréssel.
• A korreláció a MessageID és a RelatesTo fejlécek használatával történik. Ezt a mechanizmust WS_ADDRESSING_VERSION_1_0 és WS_ADDRESSING_VERSION_0_9 (WS_HTTP_CHANNEL_BINDINGhasználata esetén is) használják. Ebben az esetben a kérelemüzenet tartalmazza a MessageID fejlécet. A válaszüzenet tartalmaz egy RelatesTo fejlécet, amely a kérelem MessageID fejlécének értékét tartalmazza. A RelatesTo fejléc lehetővé teszi, hogy az ügyfél korrelálja a választ egy elküldött kéréssel.

A következő csatornaréteg API-k automatikusan használják a megfelelő korrelációs mechanizmusokat a csatorna WS_ADDRESSING_VERSION alapján.

• WsRequestReply
• WsSendReplyMessage
• WsSendFaultMessageForError

Ha ezek az API-k nincsenek használatban, a fejlécek manuálisan is hozzáadhatók és elérhetők WsSetHeader vagy WsGetHeaderhasználatával.

Egyéni csatornák és figyelők

Ha az előre definiált csatornakötések nem felelnek meg az alkalmazás igényeinek, akkor egy egyéni csatorna- és figyelő-implementáció definiálható a csatorna vagy a figyelő létrehozásakor WS_CUSTOM_CHANNEL_BINDING megadásával. A csatorna/figyelő tényleges megvalósítása visszahívások készleteként van megadva WS_CHANNEL_PROPERTY_CUSTOM_CHANNEL_CALLBACKS vagy WS_LISTENER_PROPERTY_CUSTOM_LISTENER_CALLBACKS tulajdonságokon keresztül. Miután létrehozott egy egyéni csatornát vagy figyelőt, az eredmény egy WS_CHANNEL vagy WS_LISTENER objektum, amely használható a meglévő API-kkal.

Az egyéni csatornák és figyelők szolgáltatásproxyval és szolgáltatásgazda- is használhatók a WS_CHANNEL_BINDING számbavétel WS_CUSTOM_CHANNEL_BINDING értékének megadásával, valamint a szolgáltatásproxy vagy szolgáltatásgazda létrehozásakor a WS_CHANNEL_PROPERTY_CUSTOM_CHANNEL_CALLBACKS és WS_LISTENER_PROPERTY_CUSTOM_LISTENER_CALLBACKS tulajdonságok megadásával.

Biztonság

A csatorna lehetővé teszi a műveletek különböző aspektusaihoz használt memória mennyiségének korlátozását olyan tulajdonságokon keresztül, mint például:

• 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.

Ezek a tulajdonságok alapértelmezett értékekkel rendelkeznek, amelyek a legtöbb forgatókönyv esetében konzervatívak és biztonságosak. Az alapértelmezett értékeket és azok módosításait gondosan ki kell értékelni a potenciális támadási vektorokkal szemben, amelyek szolgáltatásmegtagadást okozhatnak egy távoli felhasználó számára.

A csatorna lehetővé teszi az időtúllépési értékek beállítását a műveletek különböző aspektusaihoz a következő tulajdonságokon keresztül:

• 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.

Ezek a tulajdonságok alapértelmezett értékekkel rendelkeznek, amelyek a legtöbb forgatókönyv esetében konzervatívak és biztonságosak. Az időtúllépési értékek növelése növeli azt az időt, ameddig egy távoli fél életben tarthat egy helyi erőforrást, például a memóriát, a csatlakozókat és a szálakat, amelyek szinkron I/O-val foglalkoznak. Az alkalmazásnak ki kell értékelnie az alapértelmezett értékeket, és körültekintően kell eljárnia az időtúllépés növelésekor, mivel potenciális támadási vektorokat nyithat meg, amelyek szolgáltatásmegtagadást okozhatnak egy távoli számítógépről.

Néhány egyéb konfigurációs beállítás és alkalmazástervezési szempont, amelyeket alaposan ki kell értékelni a WWSAPI Channel API használatakor:

• A csatorna/figyelő réteg használatakor az alkalmazás feladata, hogy csatornákat hozzon létre és fogadjon el a kiszolgáló oldalán. Hasonlóképpen, az alkalmazás feladata, hogy csatornákat hozzon létre és nyisson meg az ügyféloldalon. Egy alkalmazásnak felső határt kell szabnia ezeknek a műveleteknek, mivel minden csatorna memóriát és más korlátozott erőforrásokat, például foglalatokat használ fel. Az alkalmazásoknak különösen óvatosnak kell lenniük, amikor egy távoli fél által aktivált műveletre válaszul létrehoznak egy csatornát.
• Az alkalmazás feladata, hogy megírja a logikát a csatornák létrehozásához és elfogadásához. Minden csatorna korlátozott erőforrásokat, például memóriát és csatlakozókat használ fel. Egy alkalmazásnak felső határt kell szabnia az elfogadandó csatornák számának, vagy egy távoli fél számos kapcsolatot létesíthet, ami OOM-hoz és ezáltal szolgáltatásmegtagadáshoz vezethet. Emellett aktívan fogadhat üzeneteket ezekről a kapcsolatokról egy kis időtúllépéssel. Ha nem érkezik üzenet, a művelet időtúllépést fog végrehajtani, és a kapcsolatot ki kell szabadítani.
• Az alkalmazástól függ, hogy a ReplyTo vagy a FaultTo SOAP fejlécek értelmezésével küld-e választ vagy hibát. A biztonságos eljárás az, hogy csak egy "névtelen" Válasz vagy FaultTo fejlécet tart tiszteletben, ami azt jelenti, hogy a SOAP-válasz elküldéséhez a meglévő kapcsolatot (TCP, HTTP) vagy forrás IP-címet (UDP) kell használni. Az alkalmazásoknak rendkívül körültekintően kell eljárniuk erőforrások (például csatorna) létrehozásakor, hogy egy másik címre válaszoljanak, kivéve, ha az üzenetet egy olyan fél írta alá, amely a válasz címzettjeként tud beszélni.
• A csatornarétegben végzett ellenőrzés nem helyettesíti a biztonsággal elért adatintegritást. Az alkalmazásoknak a WWSAPI biztonsági funkcióira kell támaszkodniuk annak biztosítása érdekében, hogy megbízható entitásokkal kommunikáljanak, és az adatintegritás biztosítása érdekében a biztonságra is támaszkodniuk kell.

Hasonlóképpen vannak olyan üzenetkonfigurációs beállítások és alkalmazástervezési szempontok is, amelyeket gondosan ki kell értékelni a WWSAPI Message API használatakor:

• Az üzenet fejléceinek tárolására használt halom mérete a WS_MESSAGE_PROPERTY_HEAP_PROPERTIES tulajdonság használatával konfigurálható. Az érték növelése lehetővé teszi, hogy az üzenet fejlécei több memóriát használjanak fel, ami OOM-hoz vezethet.
• Az üzenetobjektum felhasználójának tisztában kell lennie azzal, hogy a fejléc-hozzáférési API-k O(n) az üzenet fejléceinek száma tekintetében, mivel ellenőrzik az ismétlődések keresését. Az üzenetekben sok fejlécet igénylő kialakítások túlzott processzorhasználathoz vezethetnek.
• Az üzenetek fejléceinek maximális száma a WS_MESSAGE_PROPERTY_MAX_PROCESSED_HEADERS tulajdonság használatával konfigurálható. Az üzenet halommérete alapján implicit korlát is van érvényben. Mindkét érték növelésével több fejléc jelenhet meg, ami növeli a fejléc kereséséhez szükséges időt (amikor a fejléc-hozzáférési API-kat használjuk).