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.

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


Indledning
Arkitekturoverblik
Logisk arkitektur
Fysisk datamodel
Teknologiarkitektur

 

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.

SOSI-DCC-arkitektur

Logisk arkitektur

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


* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.


Når en besked modtages fra en WSC til videreforsendelse til en WSP, gennemløbes følgende flow:

 Whitelistning checkes: Hvis ikke WSCens IP adresse optræder i komponentens whitelist, afbrydes kaldet og et fejlsvar returneres til WSCen

  1. Routning slås op i komponentens konfiguration: På baggrund af SOAPAction i HTTP headeren, og evt. ServiceIdentifier i URL'ne, afgøres hvorhen beskeden skal routes. Hvis routningsinformation ikke findes i komponentens konfiguration afbrydes kaldet og der returneres et fejlsvar
  2. Beskeden parses: Der foretages en SAX parsning af beskeden hvor relevante parametre opsamles
  3. Kaldet til WSPen kan kun foregå synkront med timeout. 
  4. Beskeden sendes til WSPen


I denne 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.


Teknologiarkitektur

Komponentens konfiguration specificeres som udgangspunkt i XML i en fil. Det er muligt at angive dynamisk routningsinformation i en database og lade komponenten med jævne mellemrum indlæse opdateringer i konfigurationen på runtime. Dette er beskrevet mere detaljeret i installationsvejledningen.

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


  • No labels