...

Snitfladebeskrivelser og fejlhåndtering

Førhen håndterede og verificerede komponenterne selv sikkerheden. Det gav derfor mening, at sikkerhedsmodellen blev udtrykt i snitfladebeskrivelserne for komponenterne. I flere komponenter har vi således for nuværende flere versioner af den samme snitflade: En til DGWS og en til IDWS.

Med introduktionen af NSP Security API er det ikke længere nødvendigt for den enkelte komponent at beskrive og håndtere DGWS og IDWS konkret i koden. Det kan derfor lade sig gøre at udstille snitfladebeskrivelser, der er renset for sikkerhedsprotokollen, da komponenten kan anvende NSP Security API.

Med tiden er der opstået behov for at NSP Security API kan håndterre REST baserede services og JSON Web token  (JTP-H profil). Komponenter der gør brug af dette, og vil levere en fejl tilbage til anvenderen i selve REST-kaldet, så fejlen kan findes i svaret fra kaldet i JSON format.

Hvis komponenterne renses for sikkerhedsprotokol-afhængige snitfladebeskrivelser og kode, vil der på sigt blive mindre kode at vedligeholde.

I forhold til at rapportere fejl tilbage til anvenderne ville man før NSP Security API være tvunget til at gøre dette på en sikkerhedsprotokolafhængig måde f.eks. ved at sende en DGWSFault tilbage.
Med introduktionen af For SOAP services giver NSP Security API gives ansvaret for at levere fejl tilbage til anvenderne på den rigtige (i praksis DGWS-agtige eller IDWS-agtige) måde til NSP Security API. Komponenten skal blot kaste en javax.xml.ws.soap.SOAPFaultException, og så vil platformen tage sig af resten.

Med tiden er der opstået behov for at NSP Security API kan også håndtere REST baserede services og JSON Web token  (JTP-H profil) der er REST baserede og her vil en evt. fejl kunne findes i svaret fra . Komponenter der gør brug af dette, leverer eventuelle fejl tilbage til anvenderen i selve REST-kaldet i JSON format.

Aktørmodellering og dokumentation

...