...

Nærværende dokument udgør designdokumentet for SOSI-DCC komponenten, også kendt som SOSI Afkoblingskomponenten. SOSI-DCC fungerer som webservice gateway, og dens hovedfunktioner er routning af requests , samt håndhævelse af timeout-grænser på webservice kald samt asynkron afkobling af webservice kald med tilhørende retry-mekanisme. Formålet med komponenten er primært at understøtte flere typer af kald-semantik. Et godt eksempel er behovet for en fleksibel garanti for svartider, hvor en klient til afkoblingskomponenten i et web service kald kan specificere, at kaldet skal forsøges gennemført inden for et antal millisekunder. Hvis svaret ikke er kommet inden for det angivne antal millisekunder, afbryder komponenten kommunikationen med den pågældende web service, og returnerer en fejl til klientsystemet. Afkoblingskomponenten understøtter også andre typer af kald. Dette gennemgås i   I det følgende gives et overblik.
Designdokumentet er gældende for SOSI-DCC version 2.15.X.

Anchor
_Toc118880960 _Toc118880960

Arkitekturoverblik

...

1. Whitelistning checkes: Hvis ikke WSCens IP adresse optræder i komponentens whitelist, afbrydes kaldet og et fejlsvar returneres til WSCen
2. Routning Følgende slås op i komponentens konfiguration:
   1. Routning: 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.
   2. Timeout: 
   3. ProxyURL: 
   4. WS-addressing:
3. Beskeden parses: Der foretages en SAX parsning af beskeden hvor relevante parametre opsamles
4. Afkoblingsmodel identificeres: Der afgøres hvorvidt kaldet Kaldet til WSPen skal kan kun 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 konfigurationtimeout. 
5. Beskeden sendes til WSPen

...

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.
Image Removed
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.
Image Removed
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.
Image Removed
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.
Image Removed
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.
Image Removed
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.
Image Removed
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ø.

Anchor
_Toc118880962 _Toc118880962

Fysisk datamodel

...

Komponenten deployes på en JEE applikations server som skal stille både en JMS provider og en CommonJ provider til rådighed.
Som illustreret nedenunder skal der fra WSCen være netværksadgang til komponentens HTTP endpoint og svar køen. Adgang til komponenten reguleres via whitelistning i komponenten på baggrund af WSCens IP adresse Adgangskontrol kunne også overlades til applikations serveren, eksempelvis via SSL autentifikation med klient certifikater. Begrænsning af adgangen til svar køer foregår gennem JMS implementationens egne sikkerhedsmekanismer.
Komponenten skal selvfølgelig også have netværksmæssig adgang til WSPen.

Som vist i nedenstående figur kan komponenten også konfigureres til at kalde en WSP igennem en webservice proxy, som for eksempel SOSI-Gateway.