Geen Barrières voor Integratie

Transcriptie

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

2 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 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 vermelde producten en productnamen zijn (gedeponeerde) handelsnamen van de respectievelijke bedrijven. Een goede strategische afstemming van IT op de business is een van de belangrijkste succesfactoren. De sleutelwoorden in dit verband zijn integratie, SOA ( Oriented Architecture), EDA (Event Driven Architecture) en ESB (Enterprise 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. 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

3 Inhoudsopgave De Context: -integratie versus applicatieontwikkeling 5 Valkuil 1: De gedachte dat het alleen maar over services gaat 9 Valkuil 2: Niet inzien dat de Enterprise 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 29 Aanbevelingen 30 De Context: -integratie versus applicatieontwikkeling 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

4 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. 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. 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 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 transactieomgeving worden uitgevoerd (zoals een applicatieserver). 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. 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. 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

5 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 serviceregisters 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 namespace 1 en daarom is er een transformatie nodig. Valkuil 1: De 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. Met het bovenstaande in gedachten, zullen we nu de vijf valkuilen bespreken. Kanalen Kanaaladapters WAP- Portaal Interactief Niet-interactief Webportaal Spraakportaal Voorportaal CC- Portaal $ Middleware Broker/GW adapters s Claims Verkoop Financiën Bedrijf Res. 1 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. 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 8 159

6 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 ). 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. 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. 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 servicegeoriënteerde architectuur (SOA), namelijk een bedrijfsdomein-gerichte architectuur. 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 introduceren. 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. Manager versie 1 Domein- bus Routering Gateway Kanaal Overeengekomen document document Partnerversie 1 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 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

7 Manager Bedrijfsschulden versie 2 Domeinservicebus Gateway Kanaal Kanaal Routering document Overeengekomen dokument Partnerversie 1 Partnerversie 2 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. 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. Valkuil 2: Niet inzien dat de Enterprise 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). Bank Detailbank Activabeheer Aandelen Vorderingen Hypotheken Derivaten Vreemde valuta Landenschulden Groothandelsbank De domeinen met een semantisch knooppunt worden aangeduid met witte stippen

8 Vorderingen heeft semantische knooppunten voor bepaalde instrumenten, omdat dit aansluit op de structuur van de bank en de manier waarop het geld wordt besteed. Aangezien budgetten bepalen hoe de infrastructuur 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 implementeren van een intermediair voor vreemde valuta van gedachten is veranderd en besloot de volgende architectuur te implementeren: Detailbank Bank Groothandelsbank 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 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. Aandelen Vorderingen Effectendiensten Message Broker Message Broker Hypotheken Derivaten Vreemde valuta De structuur van de bank na reorganisatie. Landenschulden Bedrijfsschulden PUT Proxy Queue Uitwisselingsprotocol Queue GET 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 back- 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 14 15

9 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 Anwendung om 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. Zelfs als deze barrière uit de weg geruimd zou worden (AMQP 3 probeert dit probleem op te lossen) is het nog steeds beter om het concept Enterprise 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. 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 Het 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 verkeer

10 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 Interactive 96.1 JETS Grootboek (US/CROC/ EMEA) 96.1, 98.1 Airmiles (Casablanca) (CROC) 96.2 GNA Global New Accts 97.2 FAS/AV (US/CROC/ EMEA) 96.1 ENLIST 97.2 Balboa Verzekeringsmaatschappij 96.2 CIM Massamarketing Memo/BT (US/CROC) 97.2 CAS&AA (US/ CROC/EMEA) 95.1, 98.1 CARP (US/ CROC/EMEA) 97.2, 98.1 WFIS (US/CROC/ EMEA) 97.2 CC90 s (US/CROC/ EMEA) 97.1 CMHDB Marketing (EMEA) 98.1 Credit MIS Tabel leegmaken (US/CROC/ EMEA) 96.2 ABS 97.2 De Loitte & Touche/ E&Y 97.2 Bedrijfsactiviteiten (Nieuwe rekeningen) Fraude Bedrijfsactiviteiten (Inzameling) Autorisaties Bedrijfsactiviteiten (GRMS, Ltrwrtg, Effectisering) Premies & Rapporten A/R Afgifte/Heruitgifte Cyclisch Terugkoop Niet-monetair FED Factory Geschillen Verslaglegging Klantenservice CRS (US/ CROC/EMEA) 97.2, 98.1 ACE (EMEA) 98.1 SECRETS 97.2 STARS 97.2 DELUXE/ Harland Chequeboeklev. - VS) 97.2 VA (EMEA) 98.1 AECB Centurion Inclearing 97.2 GNAT (US/ CROC/EMEA) 97.1, 98.1 Centurion ACAPS 97.2 Inter-Centre hulpprogramma (EMEA) 98.1 SDP 97.2 AEGIS 97.2 Fraudebewaking 97.1 MFE Mar- keting- Front-end 95.2 Data Warehouse 97.2 GRMS (US/CROC/ EMEA) 97.1, 98.1 FDR (US) 95.1 SCS (CAD) 97.1 PCO Plasticproductie (EMEA) 98.1 EMEAkaartverwerking (EMEA) 98.1 Legenda: Batchinterface Realtime interface Zowel batch- als real-time interface Derden AECB/ AET-FS 97.2 CPS klanten- Profiel- Systeem (US/CROC/ EMEA) 97.1, 98.1 FINCAP (EMEA) 98.1 FINCAP (US/CROC) 95.1, 97.2 SEIMS 97.2 VRU (USCROC/ EMEA) 96.1, 98.1 Express-Net 97.2 De interfaces met debiteuren van een klant

11 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: 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 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. Routering Gebruik van een semantisch knooppunt ter vervanging van rechtstreeks berichtenverkeer

12 Valkuil 3: Te 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 integratie. 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! Op dezelfde manier weerhoudt het ontbreken van de vereiste interoperabiliteit mensen ervan integratie toe te passen, maar het echte probleem is het beheersen van de semantische kenmerken van alle bedrijfsdomeinen. RPC-protocollen, inclusief webservices, lossen het interoperabiliteitsprobleem 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 webservices 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 communicatie tussen front-end en services, maar dat is niet hetzelfde als integratie tussen applicaties. Het lijkt misschien redelijk om een front-end een 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 integreren 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 s 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. procedure Integratie-interface Gebruikersinterface Gebruikersinterface-laag Dialoogprocedure Bedrijfslaag Bedrijfsprocessen Bedrijfsfuncties 4 Een WSDL-koppelingsstijl (Eng.: binding style ) kan RPC of document zijn (WSDL staat voor Web s Description Language). Het gebruik kan zowel gecodeerd als literal zijn

13 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: Niet beseffen dat BPEL applicaties niet integreert, maar daadwerkelijk maakt 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 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. Message Brokers Alleen op uitnodiging 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 Wat maakt het uit? Berichttoepassingen 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:

14 e/bericht 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 verplaatsen uit het kwadrant linksonder, moet de applicatie worden opgeschaald voor een hogere berichtwaarde of voor beheer van hoogwaardige transacties, zoals hieronder afgebeeld. BPM Message Brokers Wat maakt het uit? Verzendbarrière Alleen op uitnodiging Complexiteitsbarrière Berichtentoepassingen Berichten/Seconde 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. 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 compensatie 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. 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

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 instantiedatabase 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: Het 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 programmeertaal 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 gegevenselementen 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 implementatierestricties. Met dit soort metagegevens, ook wel conceptuele metagegevens 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

16 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 eventuele 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 doorgegeven 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. 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 waarschijnlijk 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 of bellen met +31 (0)

17 Information Builders Information Builders, al meer dan 32 jaar een vernieuwende kracht in de ICT-industrie, heeft inmiddels al meer dan 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 klanten, waaronder de meeste Fortune 100-bedrijven en een groot aantal Amerikaanse overheidsinstanties, voorzien van kwaliteitssoftware en kwalitatief hoogstaande services. Information Builders heeft zijn hoofdkantoor in New York en heeft wereldwijd 90 kantoren. Het bedrijf heeft mensen in dienst en werkt samen met meer dan 350 partners. 14