Programma's ontwerpen: Een service ontwerpen

“He who serves best profits most”
                                                - Rotary Motto

Services zijn programma’s die werken op de achtergrond; ze zijn de kern van vele oplossingen dankzij hun modulaire aard. Ze zijn door hun bouw en werking gemakkelijk te gebruiken in andere oplossingen, omdat hun ontwerp dit bijna afdwingt.

Een ‘service’ bestaat uit 2 onderdelen:

-       een ‘interface’: een conventie voor de interne besturing

-       verwerkingscomponenten: de technische programmatuur

De verwerkingscomponenten doen het ‘echte’ werk, terwijl de interface bepaalt hoe de informatie aangeleverd moet worden en hoe men het resultaat mag verwachten. Wanneer men de interne werking van componenten niet hoeft te ontwikkelen (vanwege bijv. Een framework), kan men spreken van ‘black boxing’ – een ‘magisch’ principe. Tegenovergesteld is het ‘white boxing’: de techniek wordt ‘uitgevonden’ zodat het kan dienen als een ‘black box’.

Vanwege deze opbouw is een service zeer gemakkelijk te ontwerpen in een schema:

Ter illustratie nemen we een iets praktischer voorbeeld, namelijk het verfraaien van een rapportage door er een ‘voorblad’ aan toe te voegen voor ieder rapport dat naar de ‘service’ wordt verstuurd:

Als deze ‘service’ geïmplementeerd zou worden, kon het overal gebruikt worden. Theoretisch is deze service ‘klaar’. Het vervult 1 specifiek doel en stelt de eisen weer, tezamen met het resultaat. Echter is het ontwerp niet veilig noch robuust. De service voert geen controle uit of het ‘type’ voorblad bestaat, wat er gedaan zou moeten worden bij een fout en dergelijke.

 Zoals dit ontwerp laat zien, worden er symbolen gebruikt om specifieke gebeurtenissen te illustreren. Deze symbolen binnen het stroomdiagram is de ‘notatie’ voor het ontwerp. Eventuele fouten worden afgehandeld door de status ‘fout’ terug te geven. De service bepaalt niet dat het teruggeeft (een ‘service’ geeft ALTIJD wat terug), maar kan wel informatie verschaffen over hetgeen wat teruggegeven wordt.

Omdat ‘services’ onzichtbaar zijn, kunnen ze allerlei informatie meesluizen, zoals de status of types. Het doel echter is wel om een service echt een enkele taak te laten vervullen: services die alles willen afhandelen worden dan steeds complexer en foutgevoeliger. Het is dan wijzer om voor iedere taak een soortgelijke, maar toch unieke service te ontwerpen en een overkoepelende service die deze aanspreekt naar aanleiding van argumenten. Het is namelijk gemakkelijker om kleine onderdelen te ‘onderhouden’ dan grote ‘spaghetti’-services.

Een ‘interface’ voor een service is niet hetzelfde als dat van een applicatie; hoewel beide over besturing gaan, richt die van een service op data typen in tegenstelling tot die van applicaties, welke zich richt op methoden.

Meer lezen over Informatie Technologie? Klik hier voor de inhoudsopgave voor alle artikelen!

©SamRain
Services