Is AIA een prefab SOA oplossing?

Augustus 2010 - Oracle’s  Application Integration Architecture wordt soms gepositioneerd als een prefab-Service Oriented Architecture. Is dit wel zo? Zo ja, hoe werkt dat dan? Zo nee, wat is het dan wel? Om deze vragen te beantwoorden moet eerst gekeken worden wat SOA is en daarna wat AIA precies is.

In deze Whitebook wordt uitgelegd wat AIA is: Wat kun je ermee en hoe kan het ons helpen bij het integreren van bedrijfssystemen.

Wat is SOA?

Wat SOA precies is, is een lastige vraag omdat iedereen zijn eigen definitie hanteert. Wat in veel definities naar voren komt is dat bedrijfsprocessen worden samengesteld uit algemeen beschikbare ‘services’. Het denken in services is zeer belangrijk. Dit is in tegenstelling tot de traditionele gedachte dat alles draait om systemen die alles kunnen en geen informatie delen met andere systemen. In SOA is informatie-uitwisseling juist wel belangrijk.

Een bedrijfsproces samengesteld uit losse ‘business services’ .

In de praktijk blijkt het niet eenvoudig te zijn om een service geschikt te maken als bouwblok voor een bedrijfsproces. Dit komt met name omdat je te maken hebt met al aanwezige systemen (‘legacy’) waarin deze gedachte niet is doorgevoerd.

Een veel toegepaste component in een SOA is een Enterprise Service Bus. Applicaties communiceren dan niet rechtstreeks met elkaar, maar via een ‘bus’. Om applicaties dezelfde taal te laten spreken wordt in elke koppeling het applicatie specifieke object vertaald naar een applicatie onafhankelijk object; dit wordt het Canoniek Data Model genoemd. Het maken van  toekomstvaste ‘canonieke’ objecten die netjes gedefinieerd zijn en onafhankelijk zijn van de systemen is vaak een uitdaging. Eigenschappen kunnen in de loop van de tijd verdwijnen of bijkomen. Een ander probleem is dat applicaties op het eerste gezicht dezelfde entiteit gebruiken, maar dat er uiteindelijk toch semantische verschillen zijn.

De Enterpise Service Bus laat applicaties met elkaar communiceren via de ‘bus’.

Wat is AIA?

AIA betekent Application Integration Architecture. AIA Foundation Pack is een uitbreiding op Oracle Fusion Middleware. De architectuur is gebaseerd op open standaarden en op ervaringen met integratievraagstukken: zogenaamde ‘best practices’. Eigenlijk bestaat AIA voornamelijk uit richtlijnen waaraan te realiseren componenten moeten voldoen. De meegeleverde tooling ondersteunt het maken componenten volgens deze richtlijnen.

De AIA Stack is een uitbreiding op Fusion Middleware

In eerste instantie is AIA een platform waarmee Oracle applicaties met elkaar kunnen integreren. Hierbij moet je denken aan bijvoorbeeld Siebel CRM, JD Edwards en Oracle E-Business Suite. Op basis van de AIA architectuur kunnen standaard integraties worden gekocht: de Process Integration Packs. Er is bijvoorbeeld een Order to Cash PIP. Hiermee kan Oracle Siebel CRM als front-end systeem worden geïntegreerd met Oracle E-Business Suite als ERP systeem.

Uiteraard kan het platform ook worden gebruikt om integraties met andere (bijvoorbeeld maatwerkapplicaties) systemen te realiseren. AIA biedt kant-en-klare objecten die je kunt toepassen in integraties: Enterprise Business Objects (EBO). Om te bouwen volgens het AIA programmeermodel moet een aantal regels worden gevolgd:

• Services worden gegroepeerd per entiteit. AIA levert ongeveer honderd domein objecten uiteenlopend van SalesOrderEBO tot ItemEBO. Naast generieke objecten zijn er ook een aantal branche specifieke uitbreidingen gedefinieerd. Met behulp van zogenaamde extension hooks is het mogelijk om zelf uitbreidingen maken op bestaande objecten. Uiteraard is het ook mogelijk om nieuwe objecten toe te voegen.
• Vertalingen van applicatie specifiek formaat naar het Canonical Data Model gebeurt in specifieke componenten: de zogenaamde Application Business Connector Services (ABCS). Een ABCS is vergelijkbaar met de adapter in een ESB.
• Bedrijfsprocessen zijn te realiseren middels de Enterprise Business Flows. Dit zijn componenten die zijn geïmplementeerd als BPEL proces en kunnen verschillende EBS functies aanroepen.
• De manier waarop foutsituaties worden afgehandeld gebeurt in verschillende type componenten op dezelfde manier.
• Bestemmingen naar externe systemen worden op een centrale plaats geconfigureerd.
• Naamgevingsconventies voor componenten.

Om te controleren of componenten voldoen aan alle regels kan de toepassing PIPAuditor worden gebruikt. Eigenlijk is de PIPAuditor overbodig omdat er ook een  Service Generator wordt meegeleverd. Deze maakt het mogelijk om in een aantal stappen een ABCS te genereren. Het voordeel van een generator is evident: er hoeven minder regels code geschreven te worden en de broncode ziet er voor alle componenten hetzelfde uit, wat de leesbaarheid verhoogt. Voor de eenvoudige services moet alleen de transformatie handmatig gemaakt worden. Complexere services zullen meer aanpassingen nodig zijn.

Versimpelde weergave van de berichtenstroom in AIA: Applicatie A roept een EBS service aan welke wordt uitgevoerd door applicatie B. In de Requestor ABCS wordt het bericht van A omgezet in het canonieke formaat (EBO). Voor het vertalen van identifiers wordt  gebruik gemaakt van een cross-reference table (XREF). De service (EBS) kan een bedrijfsproces (EBF) aanroepen of een ABCS Provider van de aanleverende applicatie.

AIA biedt ook een test-raamwerk genaamd CAVS. Met CAVS (Composite Application Validation System) kunnen componenten getest kunnen worden al dan niet in samenhang met andere componenten. Zo is het mogelijk om de functionaliteit van applicaties of andere componenten te simuleren (stubs). Eventuele wijzigingen in de vertaaltabellen worden na de test ongedaan gemaakt. Op deze manier zijn de testen herhaalbaar. De testen kunnen zowel handmatig als automatisch uitgevoerd worden.

Wat zijn de voor- en nadelen van AIA?

De voordelen van AIA zijn:

• AIA biedt een raamwerk. Dit betekent dat je het wiel niet opnieuw hoeft uit te vinden. In AIA zijn ideeën verwerkt gebaseerd op ervaringen in de praktijk.
• De gecentraliseerde foutafhandeling is zeer goed doordacht. Er wordt met een generiek Fault object gewerkt die in foutsituaties wordt gevuld en opgeslagen. Standaard komen alle foutmeldingen in een workflow applicatie, zodat het mogelijk is deze meldingen in de eerste lijn support terecht te laten komen. Het is eenvoudig om de standaard verwerking aan te passen en/of te vervangen door je eigen systeem voor fout-alarmering.
• De verzameling van voorgedefinieerde objecten bespaart veel tijd.
• De mogelijkheid om gebruik van een standaard integratie (PIP). Dit scheelt ontwikkel- en  testwerkzaamheden.
• AIA blijkt eenvoudig om mee te werken. Voor ontwikkelaars is het maken van interfaces snel te leren. De concepten van AIA zijn eenvoudig te begrijpen.
• Met de Service Generator is een hoge productiviteit te halen.

Er zijn ook een paar nadelen van AIA te noemen:

• De meeste EBS’s bestaan alleen uit CRUD-achtige functies: Create, Query, Update, Delete. Dit zijn geen ‘echte’ bedrijfsfuncties, maar technische functies. Volgens de SOA gedachte moet een service betrekking hebben op een bedrijfsfunctie. Deze bedrijfsfuncties zijn uiteraard wel toe te voegen aan een EBS, maar de verleiding bestaat om alleen gebruik te maken van de functies die standaard aanwezig zijn.
• Doordat de EBO objecten in vele situaties toepasbaar moeten zijn, is de structuur van de objecten vaak zeer algemeen gedefinieerd. Het is daardoor lastig om de juiste toepassing van elementen te begrijpen. Hierdoor kunnen objecten makkelijk verkeerd worden gebruikt.

Is AIA een SOA oplossing?

AIA is gebaseerd op het idee van de Enterprise Service Bus: applicaties communiceren met elkaar via een service laag. Deze service laag maakt gebruik van een Canoniek Data Model: de Enterprise Business Objects. Dus: ja, AIA is een oplossing die gebruikt kan worden voor SOA.

Er is één belangrijke maar: AIA is in eerste instantie een oplossing vanuit de techniek. Echter, SOA is niet zozeer een technisch probleem, maar vooral een organisatorisch probleem. Techniek is hierin slechts ondersteunend.

Is AIA een prefab–SOA oplossing?

Als je een prefab oplossing beschouwt als een stuk software wat je installeert en daarna niet hoeft aan te passen, dan zal dit zelden het geval zijn. De kans dat één van de aangeboden PIP integraties precies aansluit op de gewenste bedrijfsprocessen is niet zo groot. Systemen zijn namelijk bijna nooit standaard. Daarnaast bestaat de IT infrastructuur uit vele maatwerk applicaties waarmee ook moet worden geïntegreerd. Dit is uiteraard afhankelijk van de mate waarop de systemen zijn aangepast. Ook is het de vraag in hoeverre de generieke objecten van AIA aansluiten bij het bedrijfsspecifieke domeinmodel. Omdat AIA gericht is op veel verschillende soorten bedrijven en bedrijfstakken zijn de objecten dusdanig algemeen dat in de praktijk veel uitbreidingen nodig blijken te zijn.

Conclusie

Om AIA een ‘prefab’ oplossing te noemen gaat wat ver. Je kunt namelijk geen kant-en-klare SOA oplossing kopen. Elke organisatie is anders en ook elk integratie probleem is anders. Of één of meerdere standaard integraties (PIP) gebruikt kunnen worden is uiteraard afhankelijk van het IT landschap. Vervolgens kun je de vraag stellen: Heeft AIA zin zonder dat er gebruik wordt gemaakt van PIPs. Het antwoord daarop is: Ja, want heel veel denkwerk is al voor je gedaan. AIA biedt een uitstekend raamwerk waarmee systeem integraties zijn te realiseren. De principes waarop AIA is gebaseerd zijn goed doordacht en zullen in de praktijk handig blijken te zijn.

Dus AIA biedt een nuttig raamwerk. Het is voorzien van een aantal handige tools voor het realiseren van integratie-oplossingen. Dit heeft veel voordelen. Zo hoef je bijvoorbeeld niet meer na te denken over technische foutafhandeling.

Referenties

• Oracle Application Integration Architecture