SOA toepassen met de focus op services

November 2011 - Vandaag de dag is de uitdaging voor een IT’er niet hoe je een service bouwt maar hoe je een degelijke kwaliteitsservice bouwt gebaseerd op gedegen design principes.Verder moet een dergelijke service integreerbaar zijn in een architectuur die de business processen niet alleen ondersteunen maar ook nog eens bevorderen. Dit Whitebook laat in vogelvlucht zien welke zaken hierin een rol kunnen spelen.

Omdat de auteur momenteel aan een project werkt waarin service security een grote rol speelt, zal ook hier aandacht aan besteed worden.

Methodieken

De methodieken voor het toepassen van SOA binnen een organisatie kunnen als volgt worden opgesomd:

1. referentiearchitectuur definiëren
2. bedrijfsarchitectuur definiëren
3. services identificeren, specificeren en realiseren
4. semantisch model definiëren
5. implementatie van de service georienteerde oplossingen

Referentiearchitectuur

De referentiearchitectuur is een beproefde sjabloonarchitectuur voor een gegeven domein waarin de grootste gemene deler wordt uitgedrukt.
Deze architectuur is zeer omvangrijk. Gelet op consistentie, is het zaak om te beginnen met een minimum architectuur die de specifieke mechanismen benoemt die gebruikt gaan worden door de consumers en providers. Een dergelijke consistentie reduceert het werk benodigd voor ontwikkeling, integratie en onderhoud.

Een minimum architectuur zal de volgende aspecten moeten beschrijven:

1. welke type services zijn er (bijv. business, integratie, extern, etc.)
2. welke interfaces en functies door alle services moeten worden gebruikt (bijv. logging)
3. technische infrastructuur
4. basaal semantisch model
5. identificeer de belangrijkste en vooral de gemeenschappelijke bedrijfsprocessen
6. indentificeer de belangrijkste groepen van de services die de bedrijfsprocessen ondersteunen.
7. levenscyclus van een proces
8. roadmap met daarin enerzijds de prioriteit van de service implementatie en anderzijds een plan van aanpak voor het uitbouwen van de architectuur.

Bedrijfsarchitectuur

De bedrijfsarchitectuur speelt in op de behoeften van gebruikers met aandacht voor de volgende zaken: Welke “human actors” zijn betrokken bij het systeem. Welke gebruikersprocessen met bijbehorende functies spelen een rol en welke gegevens zijn van belang binnen die processen. Daarnaast zijn gebruikersvriendelijkheid met in het verlengde performance van het systeem belangrijk.

Kort samengevat: de bedrijfsarchitectuur vertaalt de bedrijfsstrategie in uitvoerbare processen: "alignment of business and IT".

Schematisch gezien beantwoordt de bedrijfsarchitectuur de volgende vragen:

1. met welke soort bedrijf heeft u te maken
2. wat zijn de doelstellingen van het bedrijf
3. wat is de bijbehorende strategie
4. welke informatie is hiervoor benodigd
5. welke processen, services, entiteiten en regels spelen hier een rol
6. welke bestaande applicaties leveren hieraan een bijdrage

Er zijn modelleringstalen die  de relatie tussen de business en SOA inzichtelijk kunnen maken. Het doel van dergelijke talen is om de verschillende domeinen binnen een organisatie (business, applicaties, infrastructuur) met elkaar te integreren, door de ontwikkeling van een gemeenschappelijke visuele taal. Hierbij worden de processen op hoog niveau geïdentificeerd en in een architectuurcontext geplaatst. Voor de uitwerking in workflows moeten zogenaamde domeinspecifieke talen worden gebruikt en dat is waar Business Process Modeling om de hoek komt kijken.

SOA stelt bedrijven in staat om snel te reageren op veranderingen, doordat SOA flexibiliteit biedt op het gebied van IT. SOA legt de nadruk op het ontkoppelen van service verleners- en afnemers. Het onderliggende concept is dat een verandering in de service implementatie niet hoeft te leiden tot aanpassingen aan de kant van de service afnemers.

Als de business architectuur helder is dan volgt het bepalen van de gemeenschappelijke semantiek en de service context.  Semantische interoperabiliteit is een essentieel onderdeel van SOA omdat service afnemers en service verleners informatie onderling moeten uitwisselen die beiden begrijpen. Zonder semantische interoperabiliteit ontstaat data welke niet begrijpelijk en daardoor niet waardevol en bruikbaar is. Zonder semantiek bestaat data simpelweg uit betekenisloze strings.

Een opgeleverde service die berichten communiceert die alleen door de bouwers te begrijpen is, is verre van interoperabel. WSDL generatie in plaats van contract first en de 1 op 1 vertaling van een technische API naar een service leidt tot tight coupling en uiteindelijk tot chaos, omdat dan de service niet vanuit de business behoefte maar vanuit een technische behoefte is opgesteld.

Het canonieke model definieert de common semantics en is cruciaal voor een succesvolle SOA. Een canon is de afspraak hoe men gegevens uitwisselt, welke structuur welke metagegevens. Een voorbeeld van een referentie canoniek model is te vinden in de Oracle Application Integration Architecture (AIA) geschikt voor retailers/kruideniers.

Services

Nadat het canonieke model is bepaald kan worden begonnen met opzetten van de services. De service interface zal de details van de service implementatie moeten verhullen. De service interface beschrijft de functies van de service in termen van expliciete operaties. Het schema van de informatie waarop de operaties acteren is afgeleid van het semantische of canonieke model. Een belangrijke aspect van een service is dat ze stateless moet zijn. Dit vanwege schaalbaarheid, betrouwbaarheid, failover etc.

De methodiek voor ontwerp van het service model is iteratief en incrementeel. Begin op een hoog niveau, waarbij de belangrijkste stappen van de use cases worden doorlopen. Werk vervolgens de service details uit, waarbij ook aandacht besteed moet worden aan uitzonderingssituaties en foutafhandeling.

Aanvullende informatie behoeften op service niveau moeten leiden tot aanpassing van het canonieke model. Services moeten worden ontworpen met aandacht voor aanpassingen. Revisions en minor changes hebben geen grote impact. Major changes zijn echter niet backward compatible. Ervan uitgaande dat de services op basis zijn van SOAP dan is de meest schaalbare aanpak het definiëren van een nieuwe namespace voor iedere major version van een xml schema.Een minor version geeft men aan als een schema versie binnen de major version namespace.

Security

Een belangrijk cross-cutting concern bij services is security. Security is in de eerste plaats begaan met access control. De eerste stap in access control is authenticatie. Authenticatie betekent het valideren van de identiteit van een subject (gebruiker, applicatie, webservice etc.). Naast enkelzijdige authenticatie waar alleen de gebruiker geïdentificeerd moet worden, is wederzijdse authenticatie mogelijk waarbij ook de server zich moet identificeren.

Met behulp van identity propagation kunnen de gebruikersgegevens worden gepropageerd naar onderliggende services. Uiteindelijk willen we toe naar een Single Sign On (SSO). Er zijn verscheidene WS-security standaarden die hierin voorzien.

Autorisatie is de tweede stap in access control en bepaalt de bevoegdheid van een geauthenticeerde gebruiker.  Op basis van de username zal worden bepaald wat de bevoegdheden en inzagerechten zijn van de ingelogde gebruiker.

Architectonische flexibiliteit inzake autorisatie wordt meestal bereikt door het logische scheiden van verantwoordelijkheden in Policy Enforcement Points (PEP) en Policy Decision Points (PDP).  Role-Based Access Control (RBAC) is een algemene autorisatie strategie waarbij security rollen worden gedefinieerd en aan subjects worden toegekend en resource control policies worden vastgelegd gekoppeld aan deze security roles. 

Een PDP is een punt waarop access control beslissingen worden genomen op basis van de vastgelegde policies met betrekking tot resources en de rollen van de ingelogde gebruiker. De handhaving en uitvoering van deze beslissingen ligt in handen van de PEP.

Tegenwoordig spelen de OASIS standaarden SAML en XACML hierin een grote rol. De Security Assertion Markup Language (SAML) is een op XML gebaseerd request/response protocol dat gebruikt wordt voor het doorgeven van subject authenticatie gegevens, toegangsrechten en attribuutinformatie. SAML tokens kunnen prima  met WS-security worden gebruikt alsook met andere bericht protocollen. De kracht van SAML ligt met name op het gebied van federated identity waarbij authenticatie over meerdere security domeinen benodigd is.

De eXtensible Access Control Markup Language (XACML) is een request/response protocol om policy decisions te kunnen uitvragen. Via een Policy Administration Point kunnen XACML policies door een administrator worden vastgelegd. Deze worden vervolgens beschikbaar gesteld aan de PDP, die op verzoek van een PEP een toegangscontrolebeslissing kan nemen.

De voordelen van SAML/XACML kunnen als volgt worden opgesomd:

1. Het is een standaard.
   Je hoeft niet je eigen systeem te bouwen en SAML/XACML wordt steeds vaker ingezet zodat het makkelijker wordt om te interopereren met andere applicaties die deze taal gebruiken.
2. Het is generiek.
   Het kan worden ingezet in iedere omgeving. Eén policy/beleidsregel die is neergelegd kan door meerdere applicaties worden gebruikt en doordat één taal wordt gebruikt is policy management veel eenvoudiger.
3. Het is gedistribueerd.
   Een neergelegde policy kan op haar beurt refereren aan andere policies die zich op verschillende locaties kunnen bevinden. Hierdoor kunnen verschillende mensen en groepen onderdelen van de overkoepelende  policy beheren en XACML weet de diverse onderdelen om te smeden tot een enkel autorisatie besluit.
4. Het is krachtig.
   De taal is uitbreidbaar, maar in standaard vorm al zeer bruikbaar. De standaard taal ondersteunt een grote verscheidenheid aan data typen, functies en regels omtrent het combineren van de resultaten van verschillende policies.

Het data flow diagram hieronder geeft de belangrijkste actoren weer in het XACML domein.

In een volgend Whitebook zullen wij verder in gaan op het Policy Information Point (PIP).

Naast access control houdt security zich ook bezig met versleutelen van berichten. Het voert te ver om hier uitgebreid op in te gaan. Er zou hier een compleet whitebook aan gewijd kunnen worden.

Conclusie

Het ontwerpen van een service binnen een SOA vereist een gedegen aanpak juist vanwege het feit dat een service geen eilandje mag zijn binnen het IT landschap maar onderdeel uitmaakt van het grotere geheel, namelijk de business met al z’n bedrijfsprocessen en afhankelijkheden.

Wat betreft security zijn de meest elegante en veilige oplossingen vaak de eenvoudigste. Bij over-engineering neemt de kans op bugs en daarmee gepaarde kwetsbaarheden toe. Het gebruik van best practices, open standaarden (e.g. SAML en XACML), en blueprints vereenvoudigt het beveiligen van de SOA aanzienlijk

Referenties

• Applied SOA: Service-Oriented Architecture and Design Strategies by Michael Rosen, Boris Lublinsky, Kevin T. Smith and Marc J. Balcer (Jun 16, 2008)
• OASIS eXtensible Access Control Markup Language (XACML)
• SOA realization: Service design principles