Table of Contents

Indledning

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.

...

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.  I det følgende gives et overblik.
Designdokumentet er gældende for SOSI-DCC version 2.5.X.Indledning

Arkitekturoverblik

...

DCC er placeret mellem en anvender – som her kaldes for webservice consumer (WSC) – og en serviceudbyder, her kaldet webservice provider (WSP).
Som illustreret på nedenstående figur sender WSCen webservice requests til WSPen igennem komponenten og modtager responsen direkte ved synkron kommunikation.

...

Logisk arkitektur

Komponenten er implementeret som simpel Servlet, som danner indgangspunktet for indkommende webservice kald.

...

I denne synkrone afkoblingsmodel håndteres forsendelsen af en SynchronousDispatcher som starter en DCCServiceCall instans på i en separat worker-trådExecutor. Som nedenstående figur illustrerer, venter dispatcheren til worker-tråden Executoren 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. 

...

Teknologiarkitektur

Komponentens konfiguration specificeres som udgangspunkt i XML i en fil. Det er muligt at dynamisk genindlæse konfigurationen ved kald til ReloadConfiguration angive dynamisk routningsinformation i en database og lade komponenten indlæse opdateringer fra den på runtime.  Indlæsning af konfigurationen sker automatisk igennem DCCConfigReloadService baggrundsjobbet - se driftsvejledningen.

Ved opstart af komponenten indlæses konfigurationen, som indeholder routningsinformation og en default afkoblings-model for de operationer, der skal kunne kaldes igennem komponenten.

Komponenten deployes på en JEE applikations server Web Application 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.