Page History

...

Komponenten er implementeret som simpel Servlet, som danner indgangspunktet for indkommende webservice kald. Ved opstart af komponenten indlæses konfigurationen, som indeholder routningsinformation og en default afkoblings-model for de operationer, der skal kunne kaldes igennem komponenten.
Når en besked modtages fra en WSC til videreforsendelse til en WSP, gennemløbes følgende flow:

1. Whitelistning checkes: Hvis ikke WSCens IP adresse optræder i komponentens whitelist, afbrydes kaldet og et fejlsvar returneres til WSCen
2. Routning slås op i komponentens konfiguration: På baggrund af SOAPAction i HTTP headeren afgøres hvorhen beskeden skal routes. Hvis routningsinformation ikke findes i komponentens konfiguration afbrydes kaldet og der returneres et fejlsvar
3. Beskeden parses: Der foretages en SAX parsning af beskeden hvor relevante parametre opsamles
4. Afkoblingsmodel identificeres: Der afgøres hvorvidt kaldet til WSPen skal foregå synkront med timeout, asynkront eller asynkront ved timeout. Hvis ikke WSCen har specificeret afkoblingsmodellen i beskeden, benyttes default afkoblingsmodellen for den pågældende operation som er angivet i komponentens konfiguration
5. Beskeden sendes til WSPen

I det følgende gennemgås konceptuelt hvordan videreforsendelsen håndteres for de forskellige afkoblingsmodeller.

Synkron med timeout

I den synkrone afkoblingsmodel håndteres forsendelsen af en SynchronousDispatcher som starter en DCCServiceCall instans på en separat worker-tråd. Som nedenstående figur illustrerer, venter dispatcheren til worker-tråden modtager svar fra WSPen, hvorefter svaret returneres. Hvis timeout-grænsen overskrides inden worker-tråden modtager svar fra WSPen, afbrydes kaldet, og en timeout-fejl genereres og returneres.


Asynkron
Ved asynkron invokation er der en AsynchronousDispatcher som på samme måde som ovenfor starter kaldet til WSPen på en separat worker-tråd. Dispatcheren sætter beskeden på komponentens egen Redo kø og starter en AsynchronousReplier på en anden worker-tråd. Derefter returner dispatcheren med et status svar om at beskeden sendes asynkront.
Replieren venter nu på at et svar på kaldet foreligger. Når svaret modtages fjernes beskeden fra redo køen og svaret afleveres asynkront til WSCen via en Svar kø (hvor hver WSC har sin egen svar kø). For at sikre at ingen beskeder går tabt, foregår kø-operationerne i samme transaktion.
Dette asynkrone flow er illustreret i nedenstående figur.

I det tilfælde hvor replieren ikke modtager nogen form for svar fordi der enten opstår et timeout eller en netværksfejl i kommunikationen med WSPen, terminerer replieren og beskeden forbliver på redo køen indtil den bliver forsøgt gensendt, se 'Retry' afsnittet længere nede. Nedenstående figur viser flowet ved timeout eller netværksfejl.


Asynkron ved timeout
I denne afkoblingsmodel er det en QueueAfterTimeoutDispatcher som på lige fod med de andre dispatchere starter kaldet til WSPen på en separat worker-tråd.
Nedenstående figur viser flowet når svaret fra WSPen foreligger inden timeout grænsen er nået.

I de tilfælde hvor timeout grænsen overskrides afbrydes kaldet ikke, i stedet sættes beskeden på redo køen og en ny replier startes på en separat worker-tråd. Derefter returnerer dispatcheren med et status svar om at beskeden sendes asynkront.
Præcis som i det helt asynkrone tilfælde venter replieren nu på svar fra WSPen. Når svaret er modtaget fjernes beskeden fra redo køen og svaret placeres på WSCens svar kø som vist i figuren nedenunder.


Hvis der ikke modtages svar fra WSPen på grund af timeout eller netværksfejl forbliver beskeden på redo køen – igen præcis som i det asynkrone tilfælde.
Retry
Komponenten har sin egen CommonJ TimerManager som periodisk starter en RedoTimerListener, der sørger for at gensende asynkrone beskeder som fejlede på grund af timeout eller fordi der opstod en fejl i netværkskommunikationen.
RedoTimerListeneren læser beskederne på redo køen og kalder derefter en ny RedoDispatcher for hver af beskederne. Dispatcheren starter kaldet til WSPen på en separat worker-tråd og starter derefter en replier på en anden worker-tråd.
Som illustreret i nedenstående figur venter replieren indtil svaret fra WSPen foreligger og lægger derefter svaret på WSCens svar kø. I samme transaktion fjernes den oprindelige besked fra redo køen.

I de tilfælde hvor replieren ikke modtager noget svar fra WSPen, enten fordi der opstår en fejl i netværkskommunikationen eller fordi den konfigurerede timeoutgrænse for asynkrone invokationer overskrides, forbliver beskeden på køen som illustreret på nedenstående figur.

Komponenten vil periodisk forsøge at gensende en besked op til et konfigurerbart antal gange. Hvis ikke det lykkedes at kalde WSPen med succes i forsøgene returnerer komponenten derefter et fejlsvar til WSCen på dens svar kø.

...