Jos Nieuwenhuis


BPEL voor Java programmeurs

Ik heb net een project achter de rug waarin ik voornamelijk heb geprogrammeerd met BPEL. BPEL blijkt duidelijk iets anders te zijn als Java. BPEL heeft een ander toepassingsgebied dan Java, namelijk integratie: het combineren van gegevens van verschillende gegevensbronnen. Je zou dit ook in Java kunnen doen, maar BPEL is bij uitstek geschikt voor dit toepassingsgebied. Java heeft een veel groter toepassingsgebied; je kunt Java voor bijna alle software toepassingen gebruiken.

In Java wordt de programmacode verdeelt over objecten waarvoor geldt dat deze objecten slechts 1 verantwoordelijkheid hebben. Vaak hebben deze objecten slechts een afhankelijkheid naar 1 of enkele andere objecten. Unittests zorgen ervoor dat alle functionaliteit wordt getest elke keer dat de code wordt gecompileerd. Java kent een enorme bibliotheek aan functies, daarnaast zijn er vele raamwerken die kunnen helpen bij het realiseren van functionaliteit.

In BPEL is dit totaal anders. Vaak heeft een BPEL proces meerdere verantwoordelijkheden en is het unittesten beperkt mogelijk. Logica kan niet worden opgesplitst in kleine brokjes. De BPEL syntax is beperkt tot een klein aantal taken. Het is wel mogelijk om Java gebruiken binnen BPEL, maar dit wordt eigenlijk alleen gedaan als het niet mogelijk is om het op een BPEL manier te doen. Het gebruik van Java in een BPEL proces is een beetje onhandig omdat de variabelen in het BPEL proces naar Java variabelen gekopieerd moeten worden en weer terug.

Het grote veschil tussen Java en BPEL is het abstractieniveau. In Java schrijf je programmacode en in BPEL bouw je met voorgedefinieerde bouwblokken: je sleept componenten naar een canvas en configureert deze componenten. Vanwege het visuele karakter lijkt BPEL toegankelijker en makkelijker te leren. Maar deze eenvoud is bedriegelijk. Eenvoudige dingen zijn op een eenvoudige manier te bouwen, bijvoorbeeld een component dat gegevens uit een database haalt of naar een database schrijft. Als er gegevensverrijking moet plaatsvinden vanuit een andere gegevensbron, dan kan het BPEL programma heel complex worden, bijvoorbeeld als er in een lijst van elementen gezocht en gewijzigd moet worden.

Tips hoe BPEL toe te passen:

1. Vermijd bedrijfslogica in bedrijfsprocessen

Gebruik BPEL alleen voor dingen waarin het goed is: transformeren en combineren van gegevens uit verschillende bronnen. Pas geen bedrijfslogica toe. Dit hoort thuis in de bron- of doelapplicaties. Bedrijfslogica kan snel veranderen en dan zou je elke keer dat er een bedijfsregel wijzigt de code moeten aanpassen. Dit is niet handig aangezien de ESB alleen verantwoordelijk zou moeten zijn om systemen te voorzien van informatie. Als je ook bedrijfslogica toepast is het ondoorzichtig.

2. Test alle situaties

Test alle mogelijke scenarios ook als je zeker bent dat de code werkt. Bepaalde logica werkt in BPEL anders dan in Java. Bijvoorbeeld het vergelijken van numerieke waarden. Deze moeten vaak expliciet naar een nummer worden geconverteerd om te voorkomen dat je strings met elkaar vergelijkt.

smaller

Als variabele i de waarde 100 heeft, dan is het resultaat van de vergelijking false, omdat je strings vergelijkt (ook als de waarde uit een XML object komt waarin het als numeriek is gedefinieerd). Onderstaande vergelijking geeft wel het gewenste reultaat:

smaller

3. Kijk uit met het mappen van ogenschijnlijk dezelfde entiteiten

Nu zul je zeggen dat dit niet het probleem is van de programmeur, maar van de analist. Dit is waar. Echter analisten maken ook fouten en vaak blijken de dingen toch anders te zijn dan dat ze in eerste instantie lijken. Elke applicatie heeft een bepaald doel. In een salarissyteem is een medewerker anders gemodelleerd dan in een planningsysteem. Ook al lijken ze het zelfde; het zijn eigenlijk totaal verschillende objecten. In een salarissysteem is een medewerker iemand die een salarisstrook krijgt. In een planningsysteem is een medewerker een persoon die in het bedrijf werkt. Uitzendkrachten staan niet in het salarissysteem, maar wel in een planningspakket. Hoe gaan de systemen om met het wijzigen van een dienstverband: iemand gaat op een bepaald moment van een parttime contract naar een fulltime contract. Hoe gaan de verschillende systemen hiermee om.

Soms hebben attributen van objecten dezelfde naam, maar hebben ze toch een andere inhoud / definitie.
bijvoorbeeld datum uit dienst. In het ene systeem is dit de laatste dag dat iemand in dienst is, terwijl in het andere systeem dit de eerste dag dat iemand uit dienst is. Het attribuut BSN blijkt niet in alle systemen op dezelfde manier gevuld te worden: soms is het een numeriek veld en soms een varchar veld. Eventuele voorloopnullen zullen verdwijnen als de waarde in een numeriek veld wordt gezet.

3. Geen gegevens opslaan in de ESB

Behalve DVM (mapping van codes) en XREF (mapping van primaire sleutels) zouden er geen waarden in de ESB opgeslagen mogen worden. Dit kan een probleem zijn als een systeem niet om kan gaan met toekomstige wijzigingen.

4. Gebruik codestandaarden en richtlijnen

Denk goed na over naamgeving van componenten en variabelen. Doe je dit niet dan doet iedereen het op zijn eigen manier en dan wordt het een zootje. Het zoeken van componenten en het aanpassen van code is een stuk eenvoudiger als iedereen op dezelfde manier werkt.

5. Begin zo vroeg mogelijk met load testen

Soms zijn de gevolgen van concurrency niet goed in te schatten. Begin daarom zo vroeg mogelijk met het opzetten van loadtests. Uit loadtest komen probleemsituaties naar voren die vaak direct op te lossen zijn. In sommige situaties kun je handig gebruik maken van retry policies in combinatie met database constraints.

6. Maak alle berichtuitwisseling asynchroon

Tenzij je zeker weet dat je direct een antwoord krijgt, gebruik altijd asynchrone uitwisseling van berichten. Wanneer een bepaalde service wordt uitgevoerd hangt af van hoe druk het op de ESB is. In bijna alle gevallen is het niet nodig om te wachten op een antwoord. Als er een antwoord teruggestuurd wordt kan een callback worden toegepast (delayed response).

7. Reduceer het aantal remote aanroepen

Remote aanroepen zijn slecht voor de performance en load op het systeem. Probeer het aantal aanroepen te combineren zodat in een enkele aanroep alle informatie wordt opgehaald. Dit geldt ook voor het opslaan van gegevens. Combineer bijvoorbeeld database transacties in 1 stored procedure in plaats van verschillende database transacties vanuit BPEL.

8. Maak transformaties zo simpel mogelijk

Intergratie is bedoeld om gegevens te transformeren en eventueel te verrijken. Beperk bedrijfslogica, omdat deze in applicaties thuishoren en niet in de integratielaag.

9. Bewaar geen gegevens op de integratielaag (behalve Cross-Reference gegevens)

In de integratielaag dien je geen gegevens op te slaan. Een uitzondering hiervoor zijn Cross-Reference gegevens: verschillende systemen gebruiken verschillende sleutels (primairy keys). Met behulp van een XREF tabel kun je de sleutel van een applicatie vertalen naar een sleutel van een andere applicatie. Sleutels dienen buiten de eigen applicatie betekenisloos te zijn. Een sleutel waaraan een bepaalde betekenis gekoppeld is is vragen om problemen. Als een object wordt gemuteerd en daardoor een ander soort object wordt zou geen gewijzigde sleutel mogen krijgen. Dit lijkt logisch, maar het komt helaas soms toch voor dat de waarde van een sleutel wel een betekenis heeft: bijvoorbeeld in een bepaald systeem hebben vaste medewerkers een nummer in een andere range dan losse medewerkers. Als een losse medewerker een vast contract krijgt zou het nummer dat aan hem gekoppeld is moeten worden gewijzigd.

Datum: 13 maart 2012 - BPEL,Java

Geen reacties

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.