In de vorige blog las je over de Applicatie Service Componenten (ASC’s) in SynTounch Integrated Data Architecture Framework (SIDAF) die verantwoordelijk zijn voor het beheer van jouw business data en transacties. Het komt er dus op neer dat de ASC’s de applicatielogica in SIDAF vormen. Zoals je wellicht hebt gelezen in mijn vorige blog voldoet een ASC idealiter aan een negental principes. Hoewel er een grote mate van verschil kan bestaan tussen de afzonderlijke ASC’s zijn er ook diverse gedeelde kenmerken aan te wijzen. In deze blog ga ik verder in op de samenstelling van een ASC, waarbij er vijf vaste elementen te benoemen zijn en twee optionele.
1. Dataopslag
Een ASC beheert over het algemeen één of meerdere specifieke bedrijfsobjecten. De data hiervan moet worden opgeslagen op een veilige en persistente manier. Daarom heeft de ASC de beschikking over een data storage functionaliteit. Deze wordt ingevuld door een specifieke Standaard Technologie Service (STS).
SIDAF stelt dat alleen de ASC zelf deze operationele data rechtstreeks mag benaderen. Indien de data voor andere doeleinden benodigd is (bijvoorbeeld voor andere ASC’s als referentiedata of voor BI en analytics), dien je de data via interfaces op gecontroleerde manier uit te wisselen. Voor het uitwisselen of het opslaan van historische data kan eventueel een tweede aparte datastore worden ingezet: een RDS (Read-only Datastore).
2. Interfaces
Een ASC beschikt over één of meerdere interfaces om de beheerde data te ontsluiten. Er zijn een aantal typen interfaces beschikbaar, waarvoor specifieke STS’en zijn benoemd.
- API: Voor het eenvoudig opvragen van data of het initiëren van transacties op deze data.
- Event-uit: Voor het signaleren van wijzigingen op en het distribueren van masterdata.
- Event-in: Voor het luisteren naar en het ontvangen van referentiedata.
- Applicatie Read-only Datastore (A-RDS): Een aparte datastore die bijvoorbeeld door ETL-/ELT-processen benaderd kan worden.
3. Business logica
Een ASC kent en bewaakt de business logica en bedrijfsregels rond de beheerde businessobjecten. Vanuit kwaliteitsoogpunt dient de ASC deze regels te bewaken, bijvoorbeeld door het weigeren van foutieve input. Daarnaast zal een businessobject een specifieke levenscyclus met bijbehorende statussen kennen die de ASC registreert en bewaakt.
4. Autonome runtime omgeving
Idealiter draait een ASC in een eigen runtime omgeving, zoals een Docker container. Deze containers draaien in principe los van andere omgevingen en hebben hun eigen systeembronnen. Dat betekent dat als een container crasht dit geen invloed heeft op andere containers en andere ASC’s. Dit zorgt ervoor dat een ASC runtime in hoge mate autonoom is. En dat komt ten goede van de stabiliteit.
5. Monitoring
Een ASC maakt onderdeel uit van een groter geheel met processen en andere ASC’s. Het functioneren van een ASC is weliswaar autonoom, maar beïnvloedt wel de totale operatie van de organisatie. Het vraagt om een bepaalde transparantie omtrent het functioneren. Daarom dient de ASC op een standaard wijze te rapporteren aan een centrale monitor. Zo kunnen specifieke issues proactief getackeld worden. Monitoringevents kunnen op verschillende niveaus gedefinieerd worden: ASC-, domein- en organisatieniveau.
Optionele componenten
Behalve de bovengenoemde standaard onderdelen kennen ASC’s ook een tweetal optionele elementen. Deze licht ik hieronder toe.
User interface/UX
Een ASC kan voor gebruikers ontsloten worden via één of meerdere User Interfaces (UI). Vaak zullen deze gebruikmaken van de ASC API’s die toegang bieden tot data en specifieke systeemtransacties. Echter zal in de praktijk een UI vaak onderdeel zijn van een portaalomgeving, waarin de UI-ontsluiting voor meerdere gerelateerde ASC’s tegelijk is ondergebracht. In dat geval behoort de UI niet specifiek tot de ASC zelf.
Referentiedatabase
Een ASC is vaak afhankelijk van de data van andere ASC’s. Ter illustratie: een ‘klantorder’-ASC gebruikt specifieke klantdata uit een ‘Klant’-ASC. Omdat SIDAF streeft naar autonome ASC’s is een directe verstrengeling met het ‘Klant’-ASC via een synchrone realtime API-verbinding niet wenselijk. Referentiedata kan hierbij een oplossing zijn. De ‘klantorder’-ASC kan bijvoorbeeld een kopie van de relevante klantgegevens opslaan uit de ‘Klant’-ASC, die events aanleveren aan de klantorder.
In deze blog las je over de samenstelling van ASC’s in SIDAF. Wil je meer weten over SIDAF of de ASC’s? Neem dan contact met ons op.
De volgende blog binnen de SIDAF serie zoomt in op hoe je een ASC in de praktijk het beste kunt realiseren.
