Voor mijn werkgever ben ik bezig met de implementatie van een ESB dat als basis zou moeten gaan dienen voor een SOA Architectuur.
Zoals te lezen in de Computable is dit eigenlijk niet direct de goede benadering. Dit is meer een bottom up benadering terwijl een meer top down benadering nodig is. In ieder geval vertikaal waarbij je begint bij de business functionaliteit (indiensttreding van een werknemer), en deze case verticaal implementeerd (BPM, EAI, Data).
In ons project zijn we eigenlijk meer bezig met EAI met Messaging i.p.v. de "service" benadering.
Messaging in een SOA omgeving
Ik zal dit nader proberen uitleggen. Als voorbeeld neem ik de indiensttreding van een werknemer en om het voorbeeld eenvoudig te houden onderken ik slechts een paar stappen:
1) Invoer werknemer met NAW gegevens
2) Werknemer moet een IT account krijgen
3) Werknemer krijgt een kostenplaats binnen het financieel systeem
In dit scenario spelen 3 systemen applicaties een rol:
A) Systeem invoer werknemer waar hij en personeelsnummer krijgt
B) Systeem waar financiele afhandeling en grootboek bijgehouden wordt
C) Systeem waar IT accounts worden aangemaakt
In mijn beeld kun je dit scenario op de volgende manieren aanpakken:
I) Je zet op de ESB een Medewerker (CDM) bericht. De 3 systemen zullen onafhankelijk van elkaar het bericht oppikken en hiermee aan de slag gaan (zie stappen 1-3). Dus 1 systeem zal de werknemer toevoegen aan het HRM systeem. Het financieel systeem zal een kostenplaats voor de werknemer aanmaken en het IT systeem zal een IT account aanmaken.
II) Er worden 3 verschillende CDM Entiteiten op de ESB geplaatst (Medewerker, Account, Kostenplaats). Dit zijn in feite drie verschillende CRUD operaties op Domein entiteiten.
Laten we deze twee mogelijkheden nader bekijken. In het eerste geval is de oplossing meer EAI gebaseerd. Hiermee bereik je data herbruikbaar op de ESB. Het heeft echter als nadeel dat de verschillende functionaliteiten niet afzonderlijk herbruikbaar zijn (toevoegen kostenplaats, aanmaken IT account). Dit is bij de tweede oplossing wel het geval.
Dus je Domein Model is zeer belangrijk in de je SOA oplossing.
Zoals te lezen in de Computable is dit eigenlijk niet direct de goede benadering. Dit is meer een bottom up benadering terwijl een meer top down benadering nodig is. In ieder geval vertikaal waarbij je begint bij de business functionaliteit (indiensttreding van een werknemer), en deze case verticaal implementeerd (BPM, EAI, Data).
In ons project zijn we eigenlijk meer bezig met EAI met Messaging i.p.v. de "service" benadering.
Messaging in een SOA omgeving
Ik zal dit nader proberen uitleggen. Als voorbeeld neem ik de indiensttreding van een werknemer en om het voorbeeld eenvoudig te houden onderken ik slechts een paar stappen:
1) Invoer werknemer met NAW gegevens
2) Werknemer moet een IT account krijgen
3) Werknemer krijgt een kostenplaats binnen het financieel systeem
In dit scenario spelen 3 systemen applicaties een rol:A) Systeem invoer werknemer waar hij en personeelsnummer krijgt
B) Systeem waar financiele afhandeling en grootboek bijgehouden wordt
C) Systeem waar IT accounts worden aangemaakt
In mijn beeld kun je dit scenario op de volgende manieren aanpakken:I) Je zet op de ESB een Medewerker (CDM) bericht. De 3 systemen zullen onafhankelijk van elkaar het bericht oppikken en hiermee aan de slag gaan (zie stappen 1-3). Dus 1 systeem zal de werknemer toevoegen aan het HRM systeem. Het financieel systeem zal een kostenplaats voor de werknemer aanmaken en het IT systeem zal een IT account aanmaken.
II) Er worden 3 verschillende CDM Entiteiten op de ESB geplaatst (Medewerker, Account, Kostenplaats). Dit zijn in feite drie verschillende CRUD operaties op Domein entiteiten.
Laten we deze twee mogelijkheden nader bekijken. In het eerste geval is de oplossing meer EAI gebaseerd. Hiermee bereik je data herbruikbaar op de ESB. Het heeft echter als nadeel dat de verschillende functionaliteiten niet afzonderlijk herbruikbaar zijn (toevoegen kostenplaats, aanmaken IT account). Dit is bij de tweede oplossing wel het geval.
Dus je Domein Model is zeer belangrijk in de je SOA oplossing.
Reacties
Een reactie posten