1. Webservice gateway

DCC'en er placeret på platformen mellem en klient (webservice consumer) og øvrige services (webservice provider). DCC's primære funktion er at fungere som en webservice gateway, der router et webservice kald til fra en klient til en specifik service på platformen. For klienter findes der med DCC en veldefineret snitflade for at kalde specifikke services på platformen, der begrænser kravet til klienten om kendskab til bl.a. den præcise lokation af specifikke services. Med denne egenskab står det samtidig operatøren af platformen frit for, at placere services som ønsket. For hver service der routes til kan konfigureres en række egenskaber for håndteringen af routningen, som eksempelvis en kald-timeout-grænse. Endvidere kan det nævnes, at DCC udelukkende benytter sig af statisk routing og det derfor er nødvendigt for enhver service, at definere en routing til sig overfor DCC, hvis servicen ønskes udstillet overfor klienter til platformen. DCC er kompatibel med DGWS 1.1.

En del af det oprindelige formål med DCC var desuden at understøtte flere typer af kald-semantik (synkron og asynkron) på platformen, men der understøttes på nuværende tidspunkt udelukkende synkrone kald. Som følge af dette vil nærværende vejledning udelukkende beskrive den synkrone afkoblingsmodel. Den asynkrone afkoblingsmodel beskrives ikke.

Bemærk at DCC ikke er en webservice provider men udelukkende en software-router for disse. Der eksisterer af samme årsag ingen WSDL for DCC, men udelukkende et XML-skema, som definerer SOAP-header elementer.

1.1. Konfiguration og kald

Routings-konfiguration angives overfor DCC som XML-tekst. 

1.1.1. Endpoint

En service der kan routes til er defineret ved et endpoint i DCC-routing-konfigurationen. For hver af disse, angives både overordnede service-informationer i endpoint-definitionen, bl.a. den HTTP URL, hvor den specifikke service kan kaldes og underordnet information om de service-operationer, der ønskes udstillet under denne service, i action-definitionen.

1.1.2. SOAPAction

En SOAPAction anvendes med DCC, som en del af routingsinformationen og SOAPAction er påkrævet i HTTP-headeren på ethvert HTTP-kald til DCC[1]. En SOAPAction-beskrivelse er en del af service-definitionen i DCC-routing-konfigurationen og skal være defineret i den til servicen hørende WSDL. Den fuldt kvalificerede SOAPAction er i DCC-routing-konfigurationen nedbrudt og fordelt på endpoint-definitionen og action-definitionen. Opløsningen af routingen til en specifik service-operation foregår ved en sammensætning af information om SOAPAction fra både endpoint og action. En SOAPAction kan være udstillet flere gange gennem DCC'en - i dette tilfælde bruges attributten ServiceIdentifier til at skelne mellem de udstillede actions.

Her et eksempel på en fuldt kvalificeret SOAPAction, som identificerer servicen DetGodeCPROpslag og dennes operation getPersonInformation. Denne SOAPAction skal være defineret i den til servicen hørende WSDL på den SOAP-operation det drejer sig om:

http://rep.oio.dk/medcom.sundcom.dk/xml/wsdl/2007/06/28/getPersonInformation

Denne SOAPAction er i DCC opdelt så den del, der kvalificerer til en service er:

http://rep.oio.dk/medcom.sundcom.dk/xml/wsdl/2007/06/28/

Og resten, som kvalificerer til en operation er:

getPersonInformation

Med yderligere viden om HTTP URL-path til servicen giver det eksempelvis følgende DCC-routing-konfiguration for endpoint og action:

<Endpoint	URL="http://nsp:8080/stamdata-cpr-ws/service/DetGodeCPROpslag"
			ActionPrefix="http://rep.oio.dk/medcom.sundcom.dk/xml/wsdl/2007/06/28/">
	<Action Name="getPersonInformation" ServiceIdentifier="service-1">
	...
	...
	</Action>
</Endpoint>

URL-host er relativ til miljøet.

For en klient der ønsker at få routet sit HTTP-kald til en service er det nødvendigt, at tilføje en HTTP-header med navnet 'SOAPAction' og værdien sat til den fuldt kvalificerede SOAPAction, eksempelvis:

...
Content-Type: text/xml; charset=utf-8;
SOAPAction: "http://rep.oio.dk/medcom.sundcom.dk/xml/wsdl/2007/06/28/getPersonInformation"
...
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
...
</soapenv:Envelope>

Når DCC kaldes kan den udfra HTTP-header med navnet 'SOAPAction', og evt. ServiceIdentifier angivet i url'en, opløse disse værdier til en specifik service og operation, hvor kaldet skal routes til. Inden den endelige service kaldes kan der ske en forandring i indholdet af den medsendte SOAP-envelope, som beskrevet senere i denne guide.

1.1.3. SOSI-GW som Proxy

Det er muligt at specificere i DCC-routing-konfigurationen, at kald skal routes over SOSI-GW inden en service kaldes. SOSI-GW vil efterfølgende kalde den endelige service. Dette giver mening, hvor der anvendes MOCES-certifikater mod en service. Ved denne type routing hjælpes klienter ved at overlade opgaven med, at opbevare SOSI ID-kort til SOSI-GW. Rent praktisk fungerer dette ved, at angive i DCC-routing-konfigurationen om service-kald skal routes gennem SOSI-GW. Angives dette kan samtidig også angives en værdi for den maksimale alder i minutter på SOSI ID-kort fundet i SOSI-GW cache. DCC sørger så for, at indsætte denne værdi i kaldet inden routningen til SOSI-GW, som vil afvise kaldet, hvis alderen er overskredet. Denne type routning-konfiguration benyttes typisk af services, som ønsker en specifik styring af SOSI ID-kortets alder eller ønsker at håndtere SOSI ID-kort opbevaringen udenfor eget system. Med tilføjelse af oplysninger omkring SOSI-GW ser DCC-routing-konfigurationen eksempelvis således ud:

<Endpoint	URL="http://nsp:8080/stamdata-cpr-ws/service/DetGodeCPROpslag"
			ActionPrefix="http://rep.oio.dk/medcom.sundcom.dk/xml/wsdl/2007/06/28/"
			ProxyURL="http://localhost:8080/sosigw/proxy/soap-request"
			IdcardMaxAgeMinutes="10">
	<Action Name="getPersonInformation">
	...
	...
	</Action>
</Endpoint>

Overfor klienter der kalder services, som først routes over SOSI-GW gælder både SOSI-GW service-definitionen og den endelige service-definitionen. Det betyder at klienter skal kunne forholde sig til svar fra både SOSI-GW og den endelige service. Se endvidere SOSI-GW.

1.1.4. WS-addressing

DCC sørger for, på baggrund af egen konfiguration, at berige SOAP-envelope med WSA-headers. Eksisterende WSA-headers i HTTP-kaldet til DCC fjernes inden DCC kalder videre. De understøttede WSA namespaces i DCC er:

• http://schemas.xmlsoap.org/ws/2004/08/addressing
• http://www.w3.org/2005/08/addressing

1.1.5. Afkoblingsmodel og timeout

Som tidligere nævnt understøttes der udelukkende synkrone kald i den såkaldte afkoblingsmodel. Endvidere er det muligt at specificere, hvor lang tid (i millisekunder) et kald må vare inden DCC returnerer et svar til klienten. Dette er uanset om den tilsigtede service har svaret. Afkoblingsmodellen og timeout angives i DCC-routing-konfigurationen for hver action, eksempelvis:

...
...
	<Action Name="getPersonInformation">
		<DecouplingModel>synchronous_timeout</DecouplingModel>
		<Timeout>30000</Timeout>
	</Action>
...
...

Denne konfiguration har klienter mulighed for at overstyre ved, at angive en anden afkoblingsmodel i en SOAP-header i HTTP-kaldet til DCC, eksempelvis:

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:dcc="http://www.sosi.dk/2007/07/decoupling-component-1.0.xsd">
	<S:Header>
		...
		...
		<dcc:DecouplingHeader>
			<dcc:DecouplingModel>synchronous_timeout</dcc:DecouplingModel>
			<dcc:Timeout>10000</dcc:Timeout>
		</dcc:DecouplingHeader>
		...
	</S:Header>
	...
</S:Envelope>

Bemærk, at det er kun understøttet at angive typen på afkoblingsmodellen som 'synchronous_timeout' og enheden for 'timeout' er i millisekunder. Afkoblingsmodellen skal være angivet på den ene eller anden måde overfor DCC. Denne specifikke header fjernes af DCC inden HTTP-kaldet routes videre til den endelige service.

1.1.6. URL-suffix

Services kan stille krav om at få bevaret HTTP URL-path indeholdt i den kaldte URL. Dette gøres i praksis ved en stjernenotation i DCC-routing-konfigurationen, eksempelvis:

<Endpoint	ActionPrefix="http://docs.oasis-open.org/wsn/bw-2/PullPoint/" 
            URL="http://127.0.0.2:8080/pullpoint/service/*">
	<Action Name="GetMessagesRequest">
	...
	...
    </Action>

Denne type routing-konfiguration giver en klient mulighed for at kalde DCC og få HTTP URL'ens path videreført af DCC i kaldet til den endelige service, eksempelvis med udgangspunkt i ovenstående og med et klientkald mod DCC, der ser således ud:

http://nsp:8080/decoupling/pullpoint/service/CONSUMER-ID-6b83f706-0902-4827-a3e0-5f1d4e86f05c

Bemærk, at 'SOAPAction' er sat i HTTP-headeren med værdien http://docs-oasis-open.org/wsn/bw-2/PullPoint/GetMessagesRequest.

I dette tilfælde vil HTTP URL path udgøres af alt, hvad der står efter http://nsp:8080/decoupling/ i URL'en og derfor vil DCC kalde den endelige service med:

http://127.0.0.2:8080/pullpoint/service/pullpoint/service/CONSUMER-ID-6b83f706-0902-4827-a3e0-5f1d4e86f05c

I tilfælde af at kaldet inkluderer en ServiceIdentifier, fjernes denne (men resten afsuffikset bevares).  Et kald kan f.eks. se således ud:

http://nsp:8080/decoupling/service/service-1/pullpoint/service/CONSUMER-ID-6b83f706-0902-4827-a3e0-5f1d4e86f05c

I dette tilfælde vil den første forekomst af '/service/<service-identifier>' blive brugt til opløsning af hvilken operation der skal kaldes, og medtages ikke i det viderestillede kald. DCC vil derfor kalde den endelige service med:

http://127.0.0.2:8080/pullpoint/service/pullpoint/service/CONSUMER-ID-6b83f706-0902-4827-a3e0-5f1d4e86f05c

1.2. Grafisk oversigt

Følgende er et grafisk eksempel på, hvordan et kald kan routes fra en klient til en service på platformen.

1. En klient opbygger et kald indeholdende en SOAP-envelope med bl.a. DCC header, ID-kort og service request i SOAP-body.
2. DCC på platformen kaldes via HTTP.
3. Udfra oplysninger i HTTP-header felt 'SOAPAction', og evt. ServiceIdentifier-del af URL, afgøres udfra DCC-routing-konfigurationen hvem der skal modtage kaldet og kaldet tilpasses udfra samme.
4. Kaldet kan gå en af to veje:
   1. SOSI-GW, hvor denne bl.a. håndterer kaldet mht. ID-kort og herefter kalder den endelige service
   2. direkte til den endelige service, som håndterer kaldet og udarbejder et svar
5. Svaret kan gå en af to veje:
   1. SOSI-GW, som giver svaret videre til DCC, uden videre modifikation
   2. direkte fra service til DCC
6. DCC afleverer svaret til den kaldende klient