Anpassningstjänster

I vissa fall kan den nationella arkitekturen inte efterföljas och då uppstår ett behov av anpassningstjänster. Typiskt gäller detta för existerande så kallade legacy system, eller för system där det beroende på prioriteringar helt enkelt tar för lång tid innan standardiserade tjänstekontrakt är framtagna. Det ska poängteras att för att få bästa möjliga förutsättningar att hantera hela livscykeln så bör anpassningstjänster ligga så nära källan som möjligt. Inte minst då det yttersta målet alltid är att så snabbt som möjligt ersätta en anpassning med en en standardlösning.

...

• Tjänsten får en hög tillgänglighet och blir automatiskt last-balanserad
• Stöd för rullande uppgraderingar
• Brandväggs- och certifikathantering är färdigt 

Ytterligare krav

För de fall att standard RTP plattformen inte räcker till, och det kan handla om behov av databastransaktioner eller asynkron köhantering så måste således denna typ av resurser allokeras och även hanteras utifrån förvaltningsperspektivet. Vem som sedan tar detta ansvar och bär motsvarande kostnader är inte givet och självfallet kan en lösning innebära att nuvarande RTP plattformen byggs ut för att möta nya krav. En annan lösning är att helt enkelt utifrån perspektivet exekvering behandla anpassningstjänsten som vilken tjänsteproducent som helt där nödvändiga servers, certifikat, etc allokeras helt utanför RTP systemets domän.

Förvaltning av programvara för anpassningstjänster

Anpassningstjänsters ska i enlighet med RIV-TA riktlinjerna baseras på öppen källkod och finnas tillgängliga på Google Code. Det kan initialt kännas som enklast att lägga alla anpassningstjänster på samma projektplats, Men det finns också ganska starka skäl att inte försöka hålla samman de öppna källkodsprojekten:

...

 Initialt så måste varje projekt/program hitta en effektiv form för förvaltning av programvaran ifråga och sedan kan respektive projektplats refereras från en sammanställning på sll-rtjp projektplatsen.

Personuppgiftsadapter