Voor elke service in een soa moeten we nadenken over policies, ofwel de regels die gelden voor het aanroepen van een service. Moet de aanroep vanuit een consument (een applicatie of andere service) geaudit worden? Moet de aanroep versleuteld (encrypted) zijn? Moet de aanroep geauthenticeerd en geautoriseerd worden? Legio policies kunnen er bestaan voor het aanroepen van een service.
Uiteraard kunnen we een verzameling policies voor een service definiëren en ze voor alle consumenten van deze service laten gelden. Maar het ligt meer voor de hand dat voor verschillende consumenten verschillende policies gelden. Bijvoorbeeld, voor een externe applicatie die een van onze services over het internet aanroept, gelden misschien hele strenge regels op het gebied van beveiliging. Als dezelfde service door een interne applicatie aangeroepen wordt, is versleuteling geen vereiste. Ook kunnen er voor beide applicaties geheel afwijkende service level agreements gelden.
De policies moeten ergens geïmplementeerd worden. Globaal zijn er twee methoden. Ten eerste kunnen we ze binnen de service implementeren, waardoor ze een onderdeel van de body van de service worden. Ten tweede kunnen we ze buiten de service implementeren. In feite leggen we dan een extra servicelaag bovenop onze eigen service. Onze service bevat dan alleen de logica, en alle policies zijn er buiten gedefinieerd.
De tweede aanpak is sterk te verkiezen boven de eerste. Tevens raden we aan om dit niet zelf te ontwikkelen, maar hiervoor een service oriented architecture (soa) beheerproduct aan te schaffen, zoals die van Amberpoint en SOA Software, of een van de vele andere. De meeste producten bieden de mogelijkheid om zogenaamde proxy services te creëren waarin de policies worden afgedwongen. De ontwikkelaars van de services hoeven zich alleen maar met de logica bezig te houden.
Deze aanpak heeft enkele voordelen. Ten eerste, policies die gelden voor een bepaalde combinatie van consument met service zijn in een registry opgeslagen. De proxy service zal bij een binnenkomende aanroep bekijken welke policies voor de betreffende consument nageleefd moeten worden. Vervolgens worden dan alle relevante controles en acties uitgevoerd. Als er autorisatierechten gecontroleerd moeten worden, of als het binnenkomende document ‘ontsleuteld’ moet worden, dan wordt dat door de proxy service uitgevoerd. Willen we de policies veranderen, dan hoeven we die alleen in de registry aan te passen, in plaats van dat we de code van de service moeten wijzigen.
Ten tweede, de service zelf hoeft zich geen zorgen te maken over de verschillende policies die gelden voor verschillende consumenten. Een proxy service zal in de registry kijken en op dat moment bepalen welke policies nageleefd moeten worden. Dit voorkomt dat de ontwikkelaars van de service zelf voor elke consument moeten bijhouden welke policies relevant zijn.
Indien een service vereist dat de aanroepen versleuteld worden, dan moet de consument de aanroep versleuteld versturen. Dus hier dient code voor geschreven te worden. Als de aanroep van buitenaf komt, dan hebben we daar niets mee te maken. Het is niet onze code. Maar als de consument intern is, dan kunnen we ook hier de beheerproducten inzetten om bepaalde policies te implementeren. Er draait dan bij de consument een module die de uitgaande aanroep oppakt, in de registry opzoekt welke policies er gelden en vervolgens de aanroep zodanig aanpast dat deze past bij de consument. Ofwel, als de service verwacht dat de aanroep versleuteld wordt, dan versleutelt deze de module aan de kant van de consument. Het resultaat is dat als we in de registry voor een bepaalde combinatie van service en consument een policy aanpassen, dat beide dan direct gewijzigd zijn. We hoeven geen letter code te schrijven.
Om een goed onderhoudbare implementatie van policies te krijgen, moeten we deze buiten de consument en buiten de service implementeren. Het is sterk aan te raden om hiervoor soa beheerproducten in te zetten. Een soa dient een flexibele architectuur te zijn. Met deze oplossing van proxy services zullen aspecten als service level agreements en beveiliging geen verlammend effect hebben.
