Geen Barrières voor Integratie

Geen Barrières voor Integratie De vijf valkuilen en hoe u ze kunt vermijden

15

Inleiding Hoeveel mensen binnen uw organisatie zien informatietechnologie niet alleen als iets dat verandering mogelijk maakt, maar in veel gevallen ook als iets dat groei in de weg staat? In het huidige bedrijfsklimaat, waar de veranderingen elkaar razendsnel opvolgen en klanten steeds veeleisender worden, wordt IT gezien als een van de zaken die binnen een organisatie het moeilijkst kunnen worden gewijzigd.

Hoewel al het mogelijke is gedaan om een hoge kwaliteit en nauwkeurigheid van de informatie in deze documentatie te kunnen garanderen, geeft Information Builders/iWay Software geen enkele garantie, expliciet noch impliciet, met betrekking tot ‘Geen Barrièrres voor Integratie: de vijf valkuilen en hoe u ze kunt vermijden’ en de overige inhoud van dit document, welke in de huidige staat wordt geleverd. Information Builders/iWay Software, aan haar gelieerde ondernemingen of andere leveranciers

Een goede strategische afstemming van IT op de business is een van de belangrijkste succesfactoren. De sleutelwoorden in dit verband zijn integratie, SOA (Service Oriented Architecture), EDA (Event Driven Architecture) en ESB (Enterprise Service Bus). Als u in staat bent bestaande applicaties doelmatig te integreren, kunt u uitzien naar een toekomst waarin IT daadwerkelijk de groei bevordert en daardoor uw bedrijf sterker maakt. Hiervoor is het wel zaak dat de CIO en de ITorganisatie hun aandacht verleggen van het leveren van een efficiënte IT naar het creëren van nieuwe mogelijkheden in markten waar de concurrentie hevig is. Zijn er barrières die dit verhinderen? Bij Information Builders geloven we in ‘Business without Barriers’. We helpen klanten al meer dan 32 jaar die barrières te slechten die het realiseren van de bedrijfsdoelstellingen in de weg staan. We doen dit door oplossingen te bieden die integratie eenvoudiger maken en alle interne en externe gebruikers direct bruikbare informatie verschaffen.

zijn in geen geval aansprakelijk voor directe, speciale of incidentele schade, of gevolgschade (inclusief, zonder beperking, schade als gevolg van winstderving, onderbreking van de bedrijfsactiviteiten, verlies van bedrijfsinformatie of overige financiële verliezen) direct of indirect voortkomend uit het gebruik (of het niet kunnen gebruiken) van of het gestelde vertrouwen in de inhoud van deze documentatie. Copyright © 2007 Information Builders, Inc. Alle rechten voorbehouden. Alle in deze publicatie

In deze gids bespreken we de vijf valkuilen van integratie en hoe u ze kunt vermijden. Zie het als een survivalgids die u kunt gebruiken om sterk genoeg te worden om te overleven in de zakelijke jungle van morgen. Information Builders Maart 2007

vermelde producten en productnamen zijn (gedeponeerde) handelsnamen van de respectievelijke bedrijven.

14 2

15 3

Inhoudsopgave De Context: Applicatie-integratie versus applicatieontwikkeling

De Context: A  pplicatie-integratie versus applicatieontwikkeling 5

Valkuil 1: De gedachte dat het alleen maar over services gaat 9 Valkuil 2: Niet inzien dat de Enterprise Service Bus in feite een onjuiste benaming is 13 Valkuil 3: Te veel request- en reply-protocollen 22 Valkuil 4: Niet beseffen dat BPEL applicaties niet integreert, maar daadwerkelijk maakt 24 Valkuil 5: Het idee dat SOA-integratie voor programmeurs is, en niet voor analisten Aanbevelingen

29 30

Het is belangrijk dat u weet wat het verschil is tussen integratie van uw huidige applicaties in een SOA-omgeving en het maken van nieuwe applicaties op basis van services.

Toestand Traditionele programmeermethoden zorgen ervoor dat iets in een bepaalde toestand (statefull) wordt gehouden. Zo worden objecten voor het lezen in bestanden altijd geschreven op basis van diverse methoden die in de juiste volgorde moeten worden aangeroepen: met ‘open’ wordt het bestand geopend, met ‘next’ wordt steeds een nieuw record gelezen en met ‘close’ wordt het bestand gesloten nadat het programma alle records heeft gelezen. Tijdens dit proces gebruikt het leesobject een cursor om te onthouden waar het zich binnen het bestand bevindt. Met andere woorden, de cursor houdt het leesobject in een bepaalde toestand, in de periode tussen het openen en sluiten van het bestand. SOA maakt gebruik van toestandloze (stateless) services voor zowel het integreren als ontwikkelen van applicaties. Bij elke aanroep wordt steeds opnieuw een service gestart: er worden geen gegevens bijgehouden over eerder uitgevoerde acties. Dit is een betrekkelijk nieuw model voor het ontwikkelen van applicaties, waardoor programmeurs gedwongen worden anders te denken. Als u bijvoorbeeld een toestandloze (stateless) service wilt maken voor het lezen in een bestand, moet de interface van de service de naam bevatten van het bestand dat moet worden geopend, evenals het nummer of de sleutel van het eerste record dat moet worden geretourneerd en het aantal records dat moet worden geretourneerd.

14 4

15 55

Toch worden voor integratie al veel langer toestandloze services gebruikt, zij het niet altijd onder dezelfde naam. EDI-interfaces (Electronic Data Interchange) maken bijvoorbeeld gebruik van eenrichtingsverkeer voor berichten die aangeven of een bedrijfsproces al dan niet is voltooid. Er zijn weliswaar interne mechanismen voor het bijhouden van de toestand van het bedrijfsproces op basis van verzonden en ontvangen berichten, maar het mechanisme dat zorgt voor het verzenden en ontvangen is zelf toestandloos.

meer beperkingen dan ontwikkeling van applicaties in een SOA-omgeving. Bij applicatieontwikkeling in een SOA-omgeving kunnen alle services die voor een bepaalde functie worden aangeroepen in één enkele transactie­ omgeving worden uitgevoerd (zoals een applicatie­server). Dit betekent dat alle compenserende transacties en overige transactionele zaken op de applicatieserver kunnen worden beheerd, en dat probleemloos een procedureaanroep kan worden gebruikt om een service iets te laten uitvoeren namens een andere service.

We kunnen daarom concluderen dat toestandloosheid (en daarmee servicegerichtheid) goed aansluit op integratie, terwijl het voor het ontwikkelen van applicaties een vrij nieuw begrip is.

Bij de integratie van applicaties in een SOA-omgeving worden de bron en het doel van een event (‘gebeurtenis’) uitgevoerd binnen verschillende transacties. Als de bron toegang wil hebben tot het resultaat van de doelverwerking, moet er eerst een ander event ontstaan. Met andere woorden: applicatie-integratie in een SOA is eigenlijk meer gericht op events (Event Driven Architecture) dan op services. Een bedrijfstransactie kan resulteren in één event maar ook in meerdere events, die elk als een afzonderlijke transactie worden behandeld.

Transacties Zowel bij de integratie als de ontwikkeling van applicaties in een SOAomgeving wordt gebruik gemaakt van toestandloze services, maar er is een groot verschil tussen deze twee als het gaat om transacties. Transacties spelen een rol bij zowel de implementatie van services (als een ‘logical unit of work’) als bij de bedrijfsprocessen (als een ‘business unit of work’). Een ‘logical unit of work’ (LUW) is een verzameling bewerkingen die worden uitgevoerd volgens het alles-of-niets-principe: of allemaal wel, of allemaal niet. De term ‘business unit of work’ (BUW) verwijst naar de uitvoering van een bedrijfsproces waarbij meerdere LUW’s betrokken kunnen zijn. Zo kan bij traditionele transactieverwerkingssystemen bijvoorbeeld een pseudo CICSconversatie worden gebruikt om het aanroepen van LUW’s te beheren, totdat de gebruiker de BUW heeft voltooid. Alle applicaties maken gebruik van transacties en daarom is applicatieintegratie in feite eerder ‘transactiegericht’ dan ‘servicegericht’. Anders gezegd, integratie van applicaties in een SOA-omgeving kent 6 14

Semantiek Bij integratie gaat het vooral over betekenis. Met andere woorden, de grootste uitdaging bij integratie bestaat uit de transformatie van de betekenis van een bericht wanneer het van bron naar doel wordt verzonden. Als u applicaties niet kunt integreren omdat de bron niet kan communiceren met het doel, is interoperabiliteit uw grootste probleem. Pas wanneer deze barrière uit de weg is geruimd (bijvoorbeeld met behulp van iWay-adapters), kunt u het echte probleem gaan oplossen: de semantische transformatie. Integratie in een SOA-omgeving heeft derhalve alles te maken met het transformeren van bronberichten naar doelberichten, eventueel met een ander berichttype als intermediair. 7

Toch wordt bij de ontwikkeling van applicaties in een SOA-omgeving verondersteld dat de interface van de aanroeper dezelfde is als die van de service die wordt aangeroepen. Daarom ook worden er service­ registers gemaakt voor mensen die nieuwe services maken om daarmee bestaande services te orkestreren. Deze veronderstelling snijdt evenwel geen hout als de orkestratie-workflow en de services die worden georkestreerd zich in verschillende applicaties bevinden. Technisch gezien hebben de aanroepende applicatie en de service niet dezelfde namespace1 en daarom is er een transformatie nodig. Met het bovenstaande in gedachten, zullen we nu de vijf valkuilen bespreken.

Valkuil 1: D  e gedachte dat het alleen maar over services gaat Iedereen heeft het altijd over services als het over SOA gaat, maar kanalen worden vrijwel nooit genoemd. En dat is jammer, want integratie is net zo goed afhankelijk van de gebruikte kanalen als van de aangeroepen services. In de onderstaande afbeelding ziet u een traditionele broker/gatewayconfiguratie waarin meerdere services via hetzelfde kanaal lopen. Interactief Kanalen

WAPPortaal

Webportaal

Spraakportaal

Niet-interactief Voorportaal

CCPortaal

Bedrijf

Res.

$

Kanaaladapters Middleware

Broker/GW

Serviceadapters Services

1

8

Een XML-namespace is een W3C-standaard voor het opslaan van elementen en attributen (met unieke namen) in een XML-instantie. Een XML-instantie kan element- of attribuutnamen uit meerdere XML-vocabulaires bevatten. Als aan elk vocabulair een namespace wordt toegekend, kan de dubbelzinnigheid tussen elementen of attributen met identieke namen worden opgelost. Alle elementnamen in een namespace moeten uniek zijn.

Claims

Verkoop

Financiën

De services vertegenwoordigen een bedrijfsfunctionaliteit en hoeven alleen te worden gewijzigd wanneer een dergelijke kernfunctionaliteit wijzigt. We weten dat een vereiste zoals ‘inkooporder aanmaken’ veel minder vaak wordt gewijzigd dan de technologie waarmee het aanmaken van de inkooporder wordt geïmplementeerd, en dat daarom de serviceinterfaces stabieler zijn dan de kanalen waarop ze worden geïmplementeerd. Als de implementatie van een service wordt gewijzigd, is het natuurlijk mogelijk dat de eigenaar van de service de service-interface moet 15 9

wijzigen. Hierbij moet wel rekening worden gehouden met de complexiteit die dergelijke wijzigingen met zich meebrengen. Deze complexiteit kan worden gecompenseerd met de regel ‘drie flows en twee transformaties’. (Meer informatie over deze zaken kunt u vinden in de white paper ‘De vijf gouden regels voor integratie’).

Om zo flexibel mogelijk te kunnen zijn, zouden services moeten worden gemaakt op een manier die eenvoudige herconfiguratie via kanalen mogelijk maakt. Dit levert zelfs nog meer op dan alleen een service­ georiënteerde architectuur (SOA), namelijk een bedrijfsdomein-gerichte architectuur.

Het kanaal bestaat uit drie delen: de technische interface waardoor de services worden aangeroepen, de semantische weergave van de service en de relaties tussen de verschillende services. Kanalen zijn een ITvertaling van de manier waarop de business is gestructureerd. Denk bijvoorbeeld aan een B2B-kanaal (Business-to-Business) dat (1) elektronische inkooporders kan ontvangen via EDI (Electronic Data Interchange), (2) korting berekent en CRM functionaliteit toevoegt via webservices en (3) via JMS-berichten orders verstuurt naar andere delen binnen de organisatie die verantwoordelijk zijn voor de uitvoering. Dit elektronische proces is een 1-op-1 weergave van de manier waarop inkoop en orderuitvoering binnen de bedrijfsvoering zijn geregeld. En vergeet niet: de manier waarop een bedrijf inkooporders verwerkt wordt vaker gewijzigd dan het feit dat er inkooporders worden verwerkt.

Kanalen zorgen ervoor dat er geen problemen met verschillende versies ontstaan. In een SOA-omgeving kan de implementatie van een service worden gewijzigd. De eigenaar van de service kan de semantische kenmerken van de service wijzigen door een nieuw schema te introdu­ ceren.2 Men kan proberen verschillende gebruikers van dienst te zijn door twee services te gebruiken (d.w.z. twee verschillende implementaties van dezelfde bedrijfsfunctie). Het is echter beter om dezelfde service via twee kanalen uit te voeren, waarbij het ene kanaal de oude semantische kenmerken gebruikt en het andere de nieuwe, zoals hieronder afgebeeld. Service Manager Applicatiedocument

Aangezien integratie altijd betrekking heeft op meerdere applicaties, en vaak ook op meerdere bedrijfsdomeinen, moet de eigenaar van de kanalen zich op een ander niveau bevinden dan die van de services. Kanalen moeten het eigendom zijn van (lees: worden betaald door) een bedrijfsdomein. Het bovenstaande laat zien dat services relatief stabiel zijn omdat ze een bedrijfsactiviteit vertegenwoordigen. De implementatie van een service kan echter wel vaker wijzigen, omdat deze telkens wordt gewijzigd wanneer een nieuwe technologie wordt geïntroduceerd. En kanalen wijzigen zelfs nog vaker, omdat deze veranderen wanneer een bedrijfsrelatie verandert.

Applicatie

Trans­ formatie

Trans­ formatie

Gateway

Kanaal

Overeengekomen document Partnerversie 1

Serviceversie 1 Routering

In de bovenstaande afbeelding wordt de implementatie weergegeven van een versie 1-kanaal voor een service. Vervolgens wordt de service gewijzigd en maakt een nieuwe partner gebruik van een voorziening van de nieuwe service. Het versiebeheer vindt plaats zoals op de volgende pagina is weergegeven. 2

14 10

DomeinServicebus

In deze context praten we over het type XML-schema dat ook wel XSD wordt genoemd. Het XMLschema bevat een verzameling regels waaraan een XML-document moet voldoen om als ‘geldig’ te worden aangemerkt.

15 11

Service Manager Applicatie­ document Applicatie

Domeinservicebus Trans­ formatie

Trans­ formatie

Gateway

Kanaal

Serviceversie 2

Overeengekomen dokument Partnerversie 1

Route­ ring

Kanaal Partnerversie 2

Trans­ formatie

Het effect van de twee verschillende versies vinden we terug in de servicebus die het kanaal beheert, niet in de service. De applicatie merkt niets van de wijze waarop zijn services worden gebruikt en is zich er ook niet van bewust dat andere applicaties zijn services aanroepen aan de hand van andere semantische kenmerken. De servicebus fungeert als een lokaal semantisch knooppunt.

Valkuil 2: N  iet inzien dat de Enterprise Service Bus (ESB) in feite een onjuiste benaming is De structuur van de business zou moeten bepalen wie de eigenaar is van een integratieproces. Voor het beheer van de semantische kenmerken van een interface zou elk bedrijfsdomein derhalve een logisch semantisch knooppunt moeten hebben (dergelijke knooppunten kunnen op diverse manieren worden geïmplementeerd). Een voorbeeld: een grote bank die in aandelen handelt, gebruikt hiervoor één enkel semantisch knooppunt. De bank verhandelt tevens vorderingen en gebruikt hiervoor vijf semantische knooppunten (voor hypotheken, derivaten, vreemde valuta, landenschulden en bedrijfsschulden). Vanuit technisch oogpunt hebben ze geen zes semantische knooppunten nodig; alle transformaties van domein naar domein zouden in feite door één knooppunt kunnen worden verwerkt. Het onderstaande model werd oorspronkelijk gebruikt in EAI-projecten (Enterprise Application Integration) met een broker (dit verklaart tevens waarom zo veel mensen moeite hebben het verschil tussen ESB’s en integratie-brokers te zien).

Dit illustreert een belangrijk aspect van het nut van een servicebus: de bus transformeert berichten van de ene vorm naar de andere. De transformatie is semantisch, van de ene interface naar de andere. In de praktijk is een servicebus dus een soort ‘semantisch knooppunt’.

Bank

Detailbank

Groothandelsbank

Aandelen

Hypotheken

Activabeheer

Vorderingen

Derivaten

Vreemde valuta

Landenschulden

Bedrijfsschulden

De domeinen met een semantisch knooppunt worden aangeduid met witte stippen.

14 12

15 13

Vorderingen heeft semantische knooppunten voor bepaalde instrumen­ ten, omdat dit aansluit op de structuur van de bank en de manier waarop het geld wordt besteed. Aangezien budgetten bepalen hoe de infrastruc­ tuur wordt uitgebreid, is het niet waarschijnlijk dat een bedrijf ooit één enkel semantisch knooppunt zal implementeren. Van een architect mag niet worden verwacht dat hij kan uitleggen waarom er zo veel bedrijfsdomeinen zijn – dat is de taak van de manager van de grootbankier – maar hij zou wel moeten kunnen uitleggen hoe semantische knooppunten kunnen bijdragen aan de interactie tussen deze domeinen. Nu wil het geval dat de manager tijdens het implemen­ teren van een intermediair voor vreemde valuta van gedachten is veranderd en besloot de volgende architectuur te implementeren:

Bank

Detailbank

Groothandelsbank

Aandelen

Vorderingen

Effecten­ diensten

Vreemde valuta

Landenschulden

Hypotheken

Derivaten

Activabeheer

office. Dit kan onderdeel zijn van een strategie om vanuit de instrumentgerichte Productbank een afzonderlijke Handelsbank op te zetten, vergelijkbaar met de manier waarop de backoffice een Transactiebank vertegenwoordigt. In een doelmatige IT-architectuur moet derhalve de implementatie van deze services gescheiden blijven van de manier waarop ze zijn georganiseerd (d.w.z. de kanalen). Er is ook een technische reden waarom het moeilijk is één enkel semantisch knooppunt te gebruiken – en waarom het ook moeilijk is een Enterprise Service Bus te gebruiken (servicebussen fungeren immers als semantische knooppunten). Dit heeft te maken met de manier waarop brokers berichten uitwisselen). Als u een bericht verstuurt (PUT) naar het ene knooppunt, wilt u waarschijnlijk dat een applicatie in het andere knooppunt het bericht ontvangt (GET). Dit kan alleen als de twee semantische knooppunten (eigenlijk brokers van berichten) berichten met elkaar kunnen uitwisselen. De meeste berichtensystemen kunnen dit. Sonic MQ, WebLogic JMS, WebSphere MQ en iWay Queue Manager beschikken bijvoorbeeld allemaal over protocollen voor het uitwisselen van berichten met systemen van hetzelfde type. Er bestaat echter geen standaardprotocol voor uitwisseling tussen verschillende berichtensystemen. Message Broker

Bedrijfs­ schulden

Applicatie

PUT

Proxy Queue

Message Broker Uitwisselings­ protocol Queue

GET

Applicatie

De structuur van de bank na reorganisatie.

De bank heeft de backoffice afgescheiden van de twee divisies die per instrument zijn gestructureerd. Het is voorstelbaar dat aandelen en schuldderivaten worden samengevoegd zodat Derivaten een afzonderlijk domein vormen. Het is tevens voorstelbaar dat de frontoffice wordt afgescheiden van de frontoffice van Vorderingen en Effecten, net zo als het creëren van Effectendiensten kan worden afgescheiden van de back14

Communicatie tussen twee semantische knooppunten (of intermediairs) kan alleen plaatsvinden als er een uitwisselingsprotocol voor de betreffende berichtensystemen voorhanden is. Uitwisselingsprotocollen zijn evenwel producteigen. Zo lang de brokers voor de berichtuitwisseling 15

van hetzelfde type zijn, is dit geen probleem. Maar verschillende typen intermediairs (zoals BEA en Sonic) kunnen geen berichten uitwisselen, en dit werpt een barrière op. Als het ene domein WebLogic JMS gebruikt, een ander Sonic MQ en een derde domein Tibco Rendezvous, is er geen protocol voorhanden om Anwendung berichten uit te wisselen. Bovendien hebben deze berichtensystemen geen van allen eigen voorzieningen om voor uitwisseling gebruik te maken van webservices. Dit betekent dat er in elke complexe omgeving een brug moet worden geslagen tussen berichtensystemen – om de ‘integrator te integreren’, als het ware.

Trans­Service for­matie ­­­

Trans­­­­for­matie Service Applicatie

Trans­Service for­matie ­­­

Trans­­­­for­matie Service Applicatie

Zelfs als deze barrière uit de weg geruimd zou worden (AMQP3 probeert dit probleem op te lossen) is het nog steeds beter om het concept Enterprise Service Bus te vermijden. De term ‘enterprise’ impliceert hetzelfde type servicebus voor elk onderdeel van het bedrijf. Maar aangezien we allemaal weten dat de beschikbare budgetten bepalen hoe de infrastructuur eruit ziet, is het beter dat architecten en commerciële mensen semantische knooppunten maken voor domeinen. De overstap van monolithisch of rechtstreeks (point-to-point) berichtenverkeer naar berichtenverkeer via een broker is uitsluitend een kwestie van tijd en geld. Als rechtstreeks berichtenverkeer wordt gebruikt, zijn de kosten voor het onderhouden van het domein hoog omdat er bij elke wijziging regressietests moeten worden uitgevoerd van het ene eindpunt naar het andere. Het knooppunt kan het probleem met de regressietests oplossen, zoals aangegeven in de afbeelding hiernaast.

Applicatie Trans­­­­for­matie

Trans­­­­for­matie Service Applicatie

Trans­­­­for­matie Service Applicatie Trans­Service for­matie ­­­

Trans­­­­for­matie Service

Point-to-point-integratie: elke wijziging van een interface kan invloed hebben op alle andere applicaties. Uiteindelijk wordt het erg kostbaar om dit te onderhouden. 3

14 16

H  et Advanced Message Queuing Protocol (AMQP) is een protocol voor berichtenverkeer in de applicatielaag (bovenste OSI-laag), en is bedoeld om berichtenimplementaties algemeen beschikbaar te maken, op dezelfde manier als SMTP dat doet voor e-mailverkeer.

15 17

Hieronder ziet u een voorbeeld, ontleend aan de praktijk van een echte klant, van een aantal interfaces met debiteuren (in totaal zijn er 120 interfaces).

Centrax 96.1

ARGRM 97.2

Call Inter­ active 96.1

JETS Grootboek (US/CROC/ EMEA) 96.1, 98.1

Airmiles (Casablanca) (CROC) 96.2

FAS/AV (US/CROC/ EMEA) 96.1

GNA Global New Accts 97.2

CIM Massa­ marketing Memo/BT (US/CROC) 97.2

Balboa Verzekeringsmaatschappij 96.2

ENLIST 97.2

CAS&AA (US/ CROC/EMEA) 95.1, 98.1 CARP (US/ CROC/EMEA) 97.2, 98.1 CRS (US/ CROC/EMEA) 97.2, 98.1

Bedrijfsactiviteiten (Nieuwe rekeningen)

WFIS (US/CROC/ EMEA) 97.2 CC90’s (US/CROC/ EMEA) 97.1

Bedrijfsactiviteiten (Inzameling)

Credit MIS Tabel leegmaken (US/CROC/ EMEA) 96.2

Cyclisch

Niet-monetair

Bedrijfsactiviteiten (GRMS, Ltrwrtg, Effectisering)

Geschillen

ACE (EMEA) 98.1 SECRETS 97.2

A/R

Fraude

CMHDB Marketing (EMEA) 98.1

Premies & Rapporten

Autorisaties

Verslaglegging

Afgifte/Heruitgifte

Terugkoop

FED Factory

STARS 97.2 DELUXE/ Harland Chequeboeklev. - VS) 97.2

Klantenservice

VA (EMEA) 98.1 AECB Cen­turion Inclearing 97.2

ABS 97.2 De Loitte & Touche/ E&Y 97.2

GNAT (US/ CROC/EMEA) 97.1, 98.1 Inter-Centre hulp­ programma (EMEA) 98.1

Centurion ACAPS 97.2 Fraudebewaking 97.1

MFE MarketingFront-end 95.2

Legenda: Batchinterface

Data Warehouse 97.2

GRMS (US/CROC/ EMEA) 97.1, 98.1

Realtime interface

FDR (US) 95.1

SCS (CAD) 97.1

PCO Plastic­ productie (EMEA) 98.1

EMEAkaart­ verwerking (EMEA) 98.1

Zowel batch- als real-time interface

AECB/ AET-FS 97.2

CPS klanten­ ProfielSysteem (US/CROC/ EMEA) 97.1, 98.1

FINCAP (EMEA) 98.1

SDP 97.2 AEGIS 97.2 FINCAP (US/CROC) 95.1, 97.2

SEIMS 97.2

VRU (USCROC/ EMEA) 96.1, 98.1

Express-Net 97.2

Derden

De interfaces met debiteuren van een klant.

14 18

15 19

Deze bank heeft 9 maanden nodig gehad om regressietests uit te voeren voor een wijziging die in tien minuten had kunnen worden doorgevoerd. De oplossing bestaat uit het herindelen van de interfaces teneinde een semantisch knooppunt te maken:

Service

Trans­­for­matie

Trans­­for­matie

Service Applicatie

Service

Trans­­for­matie

Trans­­for­matie

Service Applicatie

Trans­­for­matie

Trans­­for­matie

Service

Applicatie

Applicatie Routering Trans­­for­matie

Wijzigingen hoeven nu alleen in het semantisch knooppunt te worden getest, zodat berichten niet langer van het ene eindpunt naar alle andere eindpunten hoeven te gaan. De twee transformaties zijn van groot belang – deze zorgen voor ‘loose coupling’ door de semantische verschillen tussen de domeinen met elkaar in overeenstemming te brengen (zie de white paper ‘De vijf gouden regels voor integratie’ voor meer informatie over de regel ‘drie flows en twee transformaties’). Het lijkt alsof de servicebus (het semantisch knooppunt) een centrale positie inneemt, maar dit komt doordat de bus eigendom is van het bedrijfsdomein. De servicebus moet communiceren met vele andere semantische knooppunten in het bedrijf, net als een manager communiceert met vele andere managers binnen het bedrijf. Leveranciers zullen software onder de naam Enterprise Service Bus op de markt blijven brengen, omdat klanten hierom vragen. Maar het zal u inmiddels niet meer verbazen dat een ESB alleen goed kan werken als u dit type barrière uit de weg ruimt, zodat u de software niet overal binnen het bedrijf hoeft in te zetten.

Service Applicatie

Service

Trans­­for­matie

Trans­­for­matie

Service

Gebruik van een semantisch knooppunt ter vervanging van rechtstreeks berichtenverkeer.

14 20

15 21

Valkuil 3: T  e veel request- en reply-protocollen Elke vijf of zes jaar introduceren IT-goeroe’s met veel bombarie weer een nieuw RPC-protocol (Remote Procedure Call) als de oplossing voor nagenoeg alle integratieproblemen – DCE, CORBA en webservices zijn hier recente voorbeelden van. Maar de praktijk wijst steevast anders uit. Dergelijke protocollen lossen misschien wel interoperabiliteitsproblemen op, maar geen integratieproblemen. Dit heeft te maken met het verband tussen interoperabiliteit en inte­gratie. Dit verband kunnen we illustreren aan de hand van de volgende analogie. Een atleet die de marathon gaat lopen, brengt nog even snel een bezoek aan het toilet voordat de wedstrijd begint – en sluit zichzelf per ongeluk op in het toilet. Zijn directe probleem is uit het toilet te geraken, want anders kan hij de marathon niet lopen. Maar zijn echte doel is het lopen van de marathon!

‘applicatie’ te noemen, maar wanneer een architect een front-end ontwerpt om toestandloze services aan te roepen, is hij in feite bezig applicaties in lagen onder te brengen, niet met het inte­greren van de applicatie. Het stapelen van applicaties vindt plaats op technisch niveau of applicatieniveau, terwijl er bij applicatie-integratie services op bedrijfs­ niveau moeten worden geconstrueerd vanuit services op applicatieniveau. Deze barrière is inmiddels onderkend: toen bleek dat Microsoftwebservices geen IBM-webservices konden aanroepen, is de WS-Iorganisatie (Web Services Interoperability) opgericht. En in Basic Profile 1.0 van de WS-I wordt gesteld dat de RPC-modus niet moet worden gebruikt. In plaats hiervan moet voor webservices, voor zover mogelijk, de stijl ‘document/literal’4 worden gebruikt. Deze zijn gebaseerd op berichtenuitwisseling in plaats van RPC. Sommigen noemen dergelijke toestandloze technische services ‘processen’, en toestandloze bedrijfsprocessen ‘procedures’. Dit wordt hieronder weergegeven. Gebruikers­interface-laag

Op dezelfde manier weerhoudt het ontbreken van de vereiste interopera­ biliteit mensen ervan integratie toe te passen, maar het echte probleem is het beheersen van de semantische kenmerken van alle bedrijfs­domein­en. RPC-protocollen, inclusief webservices, lossen het interopera­biliteits­ probleem meestal op via ‘tight coupling’ van de eindpunten, maar dit maakt integratie aan de hand van ‘loose coupling’ onmogelijk. En eigenlijk is dit ietwat vreemd, als we bedenken wat er over web­services geschreven wordt. Webservices op basis van RPC, met een op RPC gebaseerde integratie tussen de front-end applicatie en de toestandloze services die worden aangeroepen, lijken veel vaker voor te komen dan andere webservices. RPC is uiteraard ook de beste methode voor commu­ nicatie tussen front-end en services, maar dat is niet hetzelfde als integratie tussen applicaties. Het lijkt misschien redelijk om een front-end een 14 22

Dialoogprocedure

Gebruikers­ interface

Bedrijfslaag Bedrijfs­ processen Bedrijfsfuncties

Serviceprocedure

Integratie-interface 4

E en WSDL-koppelingsstijl (Eng.: ‘binding style’) kan ‘RPC’ of ‘document’ zijn (WSDL staat voor Web Services Description Language). Het gebruik kan zowel gecodeerd als literal zijn.

23 15

In de afbeelding op de vorige pagina speelt de serviceprocedure dezelfde rol als de dialoogprocedure in de gebruikersinterface. De dialooginterface is echter synchroon (RPC), terwijl de integratieinterface asynchroon is (berichtenverkeer). RPC wordt nog steeds gebruikt voor communicatie tussen de serviceprocedure en de bedrijfsprocessen, maar niet tussen de ene applicatie en de andere. Dit is een subtiel maar essentieel verschil. We kunnen dus concluderen dat de ‘services’ in een SOA-omgeving primair gestuurd moeten worden door events, en alleen als het echt niet anders kan door RPC-protocollen (request/reply).

Valkuil 4: N  iet beseffen dat BPEL applicaties niet integreert, maar daadwerkelijk maakt Sommige argumenten in het voordeel van BPEL (Business Process Execution Language) lijken overtuigend. Gebruikers hoeven geen nieuwe services te maken, maar kunnen een bestaande service naar een BPELpalet slepen, een paar tests uitvoeren en de service vervolgens direct gebruiken. Dit is natuurlijk prachtig, maar helaas is de werkelijkheid veel gecompliceerder. Een van de problemen is dat processen op basis van BPEL via ‘loose coupling’ moeten worden gekoppeld aan de services die erdoor worden georkestreerd. Als er bijvoorbeeld twintig op BPEL gebaseerde bedrijfsprocessen zijn die getCustomerInfo aanroepen, moet het niet zo zijn dat u ze allemaal moet wijzigen wanneer iemand in Marketing besluit dat deze service moet worden gewijzigd. Dit betekent dat u BPEL moet integreren met de services voordat u ze orkestreert. Dit staat echter volkomen haaks op de normale gang van zaken – BPEL moet niet worden gebruikt om applicaties te integreren, applicaties worden geïntegreerd om BPEL te kunnen gebruiken! (Meer informatie over dit onderwerp kunt 14 24

u vinden in de white paper ‘De vijf gouden regels voor integratie’.) Hoe ziet een dergelijke integratie eruit? Als de aangeroepen services niet worden uitgevoerd door dezelfde applicatieserver als de BPEL, moet de XML van de BPEL (de semantische kenmerken van de eigenaar van het BPEL-mechanisme) ten minste worden vertaald naar de XML van de services (de semantische kenmerken van de eigenaar van service). Hiervoor moet in ieder geval de namespace worden gewijzigd, en waarschijnlijk nog veel meer. Een ander probleem met BPEL is de schaalbaarheid (een specifiek en fundamenteel probleem met orkestratie in het algemeen). Dit probleem heeft twee kanten: verwerkingscapaciteit en complexiteit.

e/Bericht

Message Brokers

Alleen op uitnodiging

Wat maakt het uit?

Bericht­ toepassingen

Berichten/Seconde

De verticale en horizontale assen vertegenwoordigen respectievelijk de waarde en de snelheid van een bericht. Dit levert vier kwadranten op waarin een applicatie zich kan bevinden: 25 15

Berichten met een lage snelheid en een lage waarde. Er is weinig reden om ons erg druk te maken over de wijze waarop deze applicaties worden geïmplementeerd. Berichten met een hoge snelheid en een hoge waarde. Dit zijn naar alle waarschijnlijkheid toch al derde generatie middleware-applicaties, en nieuwe middleware kan alleen op uitnodiging worden gebruikt. Berichten met een lage snelheid en een hoge waarde. Deze applicaties komen in aanmerking voor messagebrokers, vooropgesteld dat de kosten van de broker in verhouding staan tot de waarde van het bericht. Berichten met een hoge snelheid en een lage waarde. Deze applicaties zijn geschikt voor toepassingen waarbij de kosten van de broker evenredig zijn met de waarde van de transactie. De ervaring leert dat EAI-brokers veel te kostbaar zijn voor dit type applicaties. Tegenwoordig bevinden de meeste orkestratieapplicaties zich in het kwadrant ‘Wat maakt het uit?’. Om een orkestratieapplicatie te verplaat­ sen uit het kwadrant linksonder, moet de applicatie worden opgeschaald voor een hogere berichtwaarde of voor beheer van hoogwaardige transacties, zoals hieronder afgebeeld.

Alleen op uitnodiging

Wat maakt het uit?

Berichten­ toepassingen

Complexi­ teitsbarrière

Opschalen in de andere richting betekent dat de berichtsnelheid moet worden verhoogd. Sommige orkestratiemechanismen hebben evenwel een capaciteitsprobleem. Een BPEL-mechanisme moet veel meer werk verzetten dan een transactiemonitor, die alleen berichtkoppen (‘headers’) controleert en berichten aan de hand van een eenvoudige set regels naar programma’s verstuurt. Eerst moeten voor elk

BPM Verzendbarrière 14 26

Als u services en events op bedrijfsniveau (coarse-grained) gebruikt, hoeft u zich geen zorgen te maken over de implementatiedetails van de services, maar wel over wat er moet gebeuren als de service niet werkt of niet beschikbaar is. Wanneer er in een toestandloze flow een fout optreedt, kunt u de fout herleiden tot de verzendende transactie en het bericht als fout classificeren. In een BPEL-flow moet u hetzelfde doen en alle voorafgaande acties vervolgens ongedaan maken. Integratiespecialisten noemen dit compensatie. Dit betekent wel dat er voor elke service die u orkestreert een extra interface voor compensatie moet zijn. Voor activiteiten die door mensen worden uitgevoerd, moet ook rekening worden gehouden met compen­ satie nadat verwerking ‘s nachts heeft plaatsgevonden. Hiervoor is een derde interface nodig. Voor orkestratie van transacties met een hoge waarde moeten de service-interfaces kunnen beschikken over een eigen interne compensatie. Maar in de huidige technologie is dit duidelijk niet het geval.

e/Bericht

Message Brokers

Laten we eerst naar de hogere waarde kijken. Wat bij orkestratie direct in het oog springt, is de eenvoud van het ideale scenario; dat wil zeggen hoe het proces eruit ziet wanneer er niets verkeerd gaat. En dat is prima voor transacties met een lage waarde, maar niet voor transacties met een hoge waarde. Naarmate de waarde toeneemt, moeten we ons steeds meer zorgen gaan maken over wat er moet gebeuren wanneer er wel dingen verkeerd gaan. Bij elke activiteit moeten we rekening houden met het proefondervindelijk oplossen van problemen. Dit maakt de flow erg complex.

Berichten/Seconde 27 15

binnenkomend bericht correlatiesets worden opgezocht (vergelijkbaar met de regels in een transactiemonitor). Tot hier is er nog geen verschil. Maar vervolgens moet de inhoud van het bericht worden ontleed om de waarde van de correlatiesets te bepalen: BPEL kan vanuit een header niets versturen. Maar dit wordt nog verder gecompliceerd doordat het BPEL-mechanisme deze waarden moet gebruiken om in de instantie­ database te zoeken naar instanties (processen in uitvoering) waarin het bericht een activiteit afsluit. Dit is veel complexer dan versturen via een transactiemonitor en werpt een enorme barrière op. Er zijn schattingen die aangeven dat deze route duizend keer langzamer is. Deze schattingen zijn niet uit de lucht gegrepen; er zijn ook bewijzen voor. Provisioningapplicaties voor nutsbedrijven werken al langere tijd met workflows, waarbij er binnen deze applicaties een groot aantal procesinstanties in uitvoering staan (tot een half miljoen). Er zijn berichten dat er in Frankrijk voor een van dit soort applicaties een 72-voudige UNIX-processorconfiguratie nodig is om een aanvaardbare verwerkingscapaciteit te realiseren. Binnen de huidige technologie is het dan ook erg moeilijk om BPEL uit het ‘Wat maakt het uit?’-kwadrant te halen.

Valkuil 5: H  et idee dat SOA-integratie voor programmeurs is, en niet voor analisten In een persbericht aan het eind van de jaren zestig zei automatiseringspionier Grace Hopper over COBOL: “Nu kunnen uw programmeurs hun programma’s voortaan in het Engels schrijven”. In één opzicht delen we haar visie: programmeurs zijn productiever als ze met een intuïtief te begrijpen interface kunnen werken. Aan de andere kant kunnen we, vanuit het perspectief van onze tijd, vaststellen dat de meeste COBOL-programma’s nauwelijks iets met het Engels gemeen hebben. En daar is ook een goede reden voor: een program­meertaal verschilt fundamenteel van het gesproken Engels. En dit geldt ook voor programmeertalen die schuil gaan achter grafische stroomdiagrammen. Alle webservice-metagegevens zijn fysieke gegevens. Als u een webservice maakt op basis van een SAP-systeem, krijgt u elementen met onbegrijpelijke afkortingen van Duitse definities. Als u een webservice maakt op basis van een database, krijgt u gegevens­ elementen die corresponderen met onbegrijpelijke namen die door de programmeur zijn toegekend aan kolommen in de databasestructuur. Logische metagegevens zijn ontdaan van alle implementatiegegevens uit de metagegevens, zoals fysieke gegevenstypen en implementatie­ restricties. Met dit soort metagegevens, ook wel conceptuele meta­ gegevens genoemd, kan een analist wel overweg, omdat er gebruik wordt gemaakt van bedrijfsterminologie. Deze gegevens houden geen verband met best practices voor implementatie, zoals normalisatie en prestatieoptimalisering. Helaas kunnen zakelijke gebruikers alleen processtromen schrijven (om services te maken) als ze kunnen beschikken over conceptuele metagegevens. Jammer genoeg biedt de huidige technologie vrijwel

14 28

29 15

geen mogelijkheden om webservices weer te geven aan de hand van conceptuele metagegevens, en er is weinig kans dat dit in de nabije toekomst zal veranderen. Dit betekent dat het maken van processen op basis van BPEL een taak voor programmeurs zal blijven, ook als de programmeertaal niet direct zichtbaar is.

Aanbevelingen Nu we de valkuilen hebben blootgelegd, kunnen we een aantal conclusies trekken over integratie in een SOA-omgeving en aangeven hoe u even­ tuele barrières uit de weg kunt ruimen. Hieronder vindt u enkele tips over hoe u op dit moment het beste kunt omgaan met SOA: • Eerst integreren, dan orkestreren. Maak eerst de toestandloze (stateless) processtromen waarin wordt beschreven hoe een business event wordt verwerkt – een event-driven proces, niet gebaseerd op RPC – en bepaal vervolgens hoe de events moeten worden doorge­ geven van de ene omgeving naar de andere. • Voer eerst de ‘draaistoelintegratie’ uit. Het ‘lowest-hanging fruit’ verwijst naar een event in het ene systeem dat leidt tot een verschillend event, in een ander systeem. De term ‘draaistoel’ is ontleend aan het beeld van een werknemer die in een event in het ene systeem initieert (bijvoorbeeld purchaseOrderAccepted), vervolgens z’n stoel draait, voor een andere monitor gaat zitten en dezelfde gegevens in een ander systeem invoert. Draaistoelintegratie levert niet alleen direct rendement op maar kan, als het wordt uitgevoerd met het hergebruik van businessevents en services in het achterhoofd, tevens initiële events aanbieden voor andere bedrijfsprocessen.

14 30

• Voer hierna de batchprocessen uit. Een batchproces wordt in gang gezet door een verzameling binnenkomende gegevens – een verzameling events – en biedt derhalve automatisch de mogelijkheid om de verzameling op te splitsen in afzonderlijke events. • Voer vervolgens de orkestraties uit. Aangezien events en services op basis van ‘loose coupling’ moeten worden gemaakt voordat de orkestraties kunnen worden geïmplementeerd, zullen projecten waarbij het eerst moet worden georkestreerd pas na geruime tijd rendement opleveren. Maar wanneer er eenmaal events en services zijn gemaakt ter ondersteuning van draaistoelintegratie en batchprocessen, kunnen hiermee op een rendabele manier orkestraties worden gemaakt die ook op de juiste manier kunnen worden geëvalueerd. • Houd altijd rekening met compensatie. Houd, wanneer u een serviceinterface maakt voor orkestratiedoeleinden, rekening met compensatie – zowel na directe als nachtelijke verwerking. En aangezien u waar­ schijnlijk wilt dat alle services kunnen worden hergebruikt, is het ook verstandig om er over na te denken hoe de services moeten worden gecompenseerd als voor het initiële project geen compensatie nodig was.

Meer informatie Voor meer informatie over de manier waarop Information Builders toonaangevende bedrijven ondersteunt bij het integreren van hun bedrijfstransacties, kunt u een bezoek brengen aan www.informationbuilders.nl of bellen met +31 (0)20 456 33 33.

15 31

Information Builders Information Builders, al meer dan 32 jaar een vernieuwende kracht in de ICT-industrie, heeft inmiddels al meer dan 12.000 klanten meer inzicht verschaft in hun business, waardoor gebruikers op alle niveaus beter onderbouwde beslissingen kunnen nemen. Information Builders levert oplossingen voor Business Intelligence (WebFOCUS) en Integratie/SOA (iWay Software) die op basis van operationele en financiële bedrijfsgegevens informatie bieden waarop actie kan worden ondernomen. De WebFOCUS-suite is een oplossing voor allesomvattende bedrijfsinformatie en real-time verslaglegging via het web. Het product voldoet volledig aan de verslagleggingsbehoeften van grote ondernemingen, variërend van de behoeften van analisten en ‘power users’ tot de meest uiteenlopende behoeften van talloze eindgebruikers. iWay Software levert oplossingen voor integratie (SOA) die zorgen voor een snelle bedrijfsintegratie. Klanten kunnen hun investering snel terugverdienen door met iWay het programmeren van maatwerk terug te dringen en problemen snel op te lossen, en tegelijkertijd stapsgewijs een flexibele architectuur op te zetten die lange-termijnprojecten ondersteunt. De bekroonde technologie van Information Builders’ heeft al meer dan 12.000 klanten, waaronder de meeste Fortune 100-bedrijven en een groot aantal Amerikaanse overheids­ instanties, voorzien van kwaliteitssoftware en kwalitatief hoogstaande services. Information Builders heeft zijn hoofdkantoor in New York en heeft wereldwijd 90 kantoren. Het bedrijf heeft 1.600 mensen in dienst en werkt samen met meer dan 350 partners.

14