Twee protocollen is één te veel

EDI-verkeer wordt daarom traditioneel over private, zogenaamde value added netwerken (VAN), geleid. De beheerders van die netwerken zijn verantwoordelijk voor de beveiliging. Iedere VAN vormt echter een eiland, interconnectieprotocollen als X.400 ten spijt. Bovendien zijn de kosten voor het gebruik ervan vele malen hoger dan de kosten van een internetverbinding. Inmiddels kent internet voldoende beveiligingsmechanismen, die door standaardprotocollen en standaardsoftware worden ondersteund. Een aantal sectoren in het bedrijfsleven maakt zich nu dan ook op de overstap naar internet te maken. De levensmiddelenhandel grijpt de beschikbaarheid van XML aan om de door EDI ondersteunde bedrijfsprocessen te herontwerpen. De automobielindustrie benut internet met nieuw ontwikkelde samenwerkingsmodellen, zowel aan de voor- (verwerving van onderdelen) als aan de achterkant (levering van automobielen). De gezondheidszorg is in veel landen, vaak in samenhang met de sociale en private verzekeringssector, internetcommunicatie aan het uittesten. Ook de banken zijn zich aan het oriënteren. Dit is slechts een greep. Ellende XML- en EDI-berichten worden uitgewisseld tussen computerapplicaties, vaak zonder dat medewerkers er bovenop zitten (normaliter worden de logfiles eens per dag bekeken door een systeembeheerder). Wat kan hier misgaan? Berichten kunnen onderweg worden verminkt, afgetapt, vervalst, zij kunnen vertraging oplopen of zoekraken. Om deze potentiële ellende het hoofd te bieden kunnen de volgende maatregelen worden getroffen: • -Het bericht kan worden voorzien van een elektronische handtekening, die de integriteit van het bericht garandeert en het koppelt aan de afzender. • -Het bericht kan zo worden versleuteld dat het alleen door de beoogde ontvanger is te lezen. • -De ontvangst van ieder bericht kan worden bevestigd en die ontvangstbevestiging kan worden voorzien van een elektronische handtekening. Daarbij moeten nog allerlei operationele zaken worden afgesproken, zoals het te gebruiken versleutelingsalgoritme, het sleutelbeheer, de herzendingsfrequentie, de escalatieprocedure et cetera. Wanneer een XML- of EDI-verbinding wordt opgezet is deze problematiek maar een klein deel van wat er moet worden geregeld en ingericht. Verreweg de meeste tijd en moeite verdwijnt in het totstandbrengen van de koppelingen met de applicaties, het waarborgen van de gegevensintegriteit en het inbedden in de organisatie en werkwijzen. Dit zijn vooral organisatorische maatregelen. De techniek hoort beschikbaar te zijn en achter de schermen te functioneren. Als die techniek gebaseerd is op standaardprotocollen, omvat het implementeren ervan niet veel meer dan het installeren van een standaardsoftwarepakket. Kiezen Er zijn twee protocollen beschikbaar voor veilig zakelijk berichtenverkeer over internet (zie kader). Twee protocollen lijkt er één te veel. Er moet gekozen worden of dubbel geïnvesteerd. Het is verstandig te kiezen. Niet van bedrijf tot bedrijf, zelfs niet van sector tot sector, maar voor heel e-Nederland, of zelfs heel e-Europa. Die keuze moet dan wel goed worden gefundeerd. Er zijn twee opties: AS2 en ebMS. Met AS2 kan het zakelijk berichtenverkeer over internet afdoende worden beveiligd. Een aantal grote bedrijven in de Verenigde Staten heeft die conclusie al getrokken. Met name Wal-Mart (de grootste Amerikaanse supermarktketen) past nu voor zijn EDI-verkeer via internet AS2 toe. Maar er zit een addertje onder het gras. In de toekomst willen we een EDI-bericht, maar vooral een XML-bericht, niet in isolement uitwisselen, maar als onderdeel van een conversatie of proces. We willen gebruikmaken van web services, die elkaar in cascade op een wel beschreven en goed te controleren wijze aanroepen. Bovendien willen we niet met iedere handelspartner (of web-serviceleverancier) handmatig aparte afspraken hoeven maken hoe we de protocollen inzetten (wanneer en hoe vaak herzenden, wat te doen bij uitzonderingen). We willen eigenlijk dat dit profileren en opzetten van het protocol automatisch gebeurt. In AS2 kan deze context van een bericht niet worden aangegeven en AS2 biedt ook geen ondersteuning voor het zetten van de protocolparameters. Om deze redenen is ebMS ontwikkeld. Hoewel dit protocol vooral is ontwikkeld om ebXML-berichtenverkeer te ondersteunen, kunnen er, als ‘payload’ (de eigenlijke berichteninhoud), ook niet-ebXML-berichten worden meegegeven, zoals EDI-berichten of binaire bestanden. De ebMS-structuur bevat een aparte envelop, die allerlei metagegevens over de payload kan bevatten, alsmede verwijzingen naar de procescontext en routeringsinformatie. Vertraging van sommige berichten stuurt daardoor niet de hele conversatie in de war. De mogelijkheid om in ebMS routeringsinformatie in de envelop te vermelden, maakt het mogelijk eenvoudiger te migreren van EDI-systemen, waarbij van een ‘value added’ netwerk gebruik wordt gemaakt, naar ‘peer-to-peer’-berichtenverkeer via internet. De handelspartners die op een VAN zijn aangesloten kunnen als uiteindelijke bestemming in de envelop worden aangeduid, terwijl het omvattende bericht aan de VAN wordt geadresseerd. AS2 biedt deze faciliteiten niet. AS2-berichten staan op zichzelf, ebMS-berichten kunnen in het kader van een bewaakt bedrijfsproces worden uitgewisseld. In AS2 wordt het gehele bericht versleuteld, ebMS biedt de mogelijkheid van deelversleuteling, waardoor migratie en conversie vanuit een VAN-omgeving makkelijker worden. Een bedrijf dat zijn communicatie op AS2 baseert, moet met ieder van zijn klanten om de tafel gaan zitten om afspraken te maken over de operationele instellingen van de communicatie. AS2 is daarmee alleen geschikt voor gesloten gemeenschappen. Gebruikt een bedrijf ebMS, dan kan het gebruikmaken van het ebXML-mechanisme van profilering en overeenstemming (CPP/A), dat geautomatiseerd verloopt. Gevolg is dat veel technisch overleg wordt bespaard. Wanneer een bedrijf AS2 gebruikt moet het per berichttype en per klant specifieke instructies geven aan de VAN voor doorroutering. Bij iedere mutatie (wanneer ook klanten bijvoorbeeld overgaan van EDI naar XML, of van VAN naar peer-to-peer) moeten die instructies worden herzien. EbMS ondersteunt doorroutering, daar hoeft alleen de envelopadressering te veranderen. Kosten Producten die het AS2-protocol ondersteunen zijn momenteel even hoog geprijsd als producten die ebMS ondersteunen. De AS2-markt is beter voorzien. EbMS-software is vaak ingebed in een veel omvattender suite voor Business Process Management. Uiteraard zijn zulke suites duurder, maar er is ook zuivere, voordelige, ebMS-berichtendienstsoftware te koop. Voor beide protocollen zijn open-sourcepakketten voorhanden. De Drummond Group test de interoperabiliteit van zowel AS2- als ebMS-software (www.drummondgroup.com). Volgens Rik Drummond, auteur van de AS2-specificatie, is het aantal producten dat AS2 ondersteunt momenteel groter dan het aantal ebMS-producten, maar hij verwacht dat over vijf jaar AS2 geheel zal zijn verdrongen door ebMS als gevolg van de toenemende behoefte aan middleware-gestuurd Business Process Management, dat wel door ebMS, maar niet door AS2 wordt ondersteund. De markt kan er over een jaar heel anders uitzien. Veel is afhankelijk van beslissingen van grote gebruikers op de korte termijn. Die beslissingen zijn strategisch, niet alleen voor henzelf maar voor de hele Europese markt. Zij bepalen voor langere tijd de wijze waarop het zakelijk internetverkeer wordt ingericht. Zij zouden dus niet moeten worden geleid door de dagprijs van de nu beschikbare software, maar door een toekomstvisie. Grote retailbedrijven (Wal-Mart, Carrefour, Auchan) overwegen echter hun leveranciers te verplichten AS2 te ondersteunen. Ook Albert Heijn experimenteert momenteel met AS2. Men kan zich afvragen welke visie achter die overwegingen schuilgaat. Omvat die visie niet meer dan het voortbouwen op berichtgeoriënteerde EDI-systemen, gebaseerd op vooraf gemaakte bilaterale afspraken? Grote retailers, die vooroplopen bij de invoering van nieuwe logistieke concepten, worden verondersteld de weg te bereiden om ‘supply chains’ procesgeoriënteerd te besturen. Dat kan alleen door gebruik te maken van technologie zoals ebXML en web services. EbMS past daar beter in dan AS2. De ontwikkeling die Wal-Mart in de VS heeft ingezet met het toepassen van AS2 lijkt ingegeven door opportunisme en kortetermijndenken. De Europese retail, die logistiek in veel opzichten verder is dan de Amerikaanse, moet oppassen hier niet in mee te gaan. Strategische keuze De Amerikaanse gezondheidszorg heeft op advies van Gartner voor ebMS gekozen. EbMS biedt (volgens Gartner) door zijn protocolonafhankelijkheid, zijn inbedding in web services, maar vooral zijn ondersteuning van ebXML de beste mogelijkheden om uit te groeien tot hét internetprotocol voor zakelijk berichtenverkeer. EbXML maakt gestructureerd berichtenverkeer flexibel en toegankelijk, ook voor het midden- en kleinbedrijf. EbXML wordt breed gesteund door gebruikersgroepen (zoals de automobielindustrie, de verzekeringsbranche, de reiswereld, maar ook de retail) en de softwareindustrie. De keuze tussen AS2 en ebMS is een strategische. Bedrijven, en vooral het midden- en kleinbedrijf, zullen niet dubbel investeren. Projecten die nu van start gaan bepalen de infrastructuur die we nog jaren gaan gebruiken. Zo’n keuze moet weloverwogen worden genomen. Willen Nederland en Europa de ontwikkelingen in de Verenigde Staten bijbenen of voorbijstreven (dit laatste is de ambitie van de Europese Unie), dan moeten we onze kaarten zetten op de toekomst (ebMS) en niet op het snel verouderende heden (AS2). Kader 1: AS2 De Internet Engineering Task Force (IETF) heeft al in 1996 een conceptspecificatie uitgebracht hoe EDI- en XML-berichten in een e-mailbericht kunnen worden verpakt. Dit concept heette ‘draft-ietf-ediint-as1’, koosnaam: AS1. Het is inmiddels gepromoveerd tot RFC3335 (RFC staat voor ‘Request For Comments’, een enigszins eufemistische aanduiding voor IETF Standaard). De specificatie beschrijft hoe in een e-mailbericht aangegeven kan worden wat voor type bericht (Edifact, XML of eigen brouwsel) ingesloten is, hoe het bericht kan worden versleuteld en van een elektronische handtekening voorzien en hoe het kan worden bevestigd. Het AS1-protocol is specifiek geschikt voor internet-e-mailverkeer (SMTP). Omdat veel applicatie-applicatieverkeer in plaats daarvan van webprotocollen (HTTP) gebruikmaakt, is later ‘draft-ietf-ediint-as2’, ofwel AS2, ontwikkeld. AS2 biedt dezelfde functionaliteit als AS1, maar dan over HTTP, met als extraatje dat de ontvangst van berichten direct ‘synchroon’ in dezelfde sessie kan worden bevestigd. Dat kan niet via e-mail: de ontvangstbevestiging is daar een separaat bericht. AS2 heeft nog steeds de conceptstatus en kan dus in theorie zomaar worden gewijzigd. Kader 2: EbMS EbMS (Electronic Business Messaging Service) is één van de resultaten van het ebXML (electronic business XML)-project. Dat is een gezamenlijk project van Oasis, de organisatie die de XML-standaarden ontwikkelt en beheert en UN/Cefact, de organisatie die de EDI-standaarden onder haar hoede heeft. Het ebXML-project heeft geleid tot een compleet bouwwerk van standaarden dat niet alleen de infrastructuur omvat maar ook de inhoudsbeschrijving van berichten en processen en het mechanisme hoe een zakelijke elektronische relatie kan worden opgezet. EbMS is onlangs geadopteerd door de internationale standaardisatieorganisatie ISO en wordt gepubliceerd als ISO 15000-2. EbMS biedt de mogelijkheid om het bericht in de context van een conversatie of proces te plaatsen, en te verwijzen naar afspraken over protocolparameters. EbMS biedt een profilering en matchingprotocol (Collaboration Protocol Profile/Agreement - CPP/A) waarmee het beheer geautomatiseerd kan worden. EbMS is gebaseerd op SOAP (Simple Object Access Protocol, het protocol voor web services) en is onderdeel van een groter bouwwerk (ebXML). EbMS is hiermee meer algemeen toepasbaar en toekomstvaster dan AS2. Kader 3: Vergelijking AS2 en ebMS AS2 - HTTP-specifiek - Bericht is grootste eenheid - Eén bericht per keer - Beperkt aantal formaten (XML, Edifact, X12) - Beperkt aantal parameters/metagegevens in protocol vastgelegd - Geen routing mogelijk voorbij directe ontvanger - Alleen encryptie van totale inhoud mogelijk - Geen verwijzing naar parameterbestand - Niet bruikbaar voor web services EbMS - Kan worden geïmplementeerd op ieder internetprotocol (HTTP/FTP/ SMTP) - Bericht kan worden geplaatst in context van conversatie en proces - Verschillende berichten per keer mogelijk - Onbeperkt uitbreidbaar aantal formaten - Uitbreidbaar aantal parameters/metagegevens in aparte envelop - Berichtdelen kunnen verschillend gerout worden (multi-hop) - Encryptie van envelop en delen van inhoud mogelijk - Verwijzing naar parameterbestand (Collaboration Protocol Agreement) - Bruikbaar voor peer to peer en web service Fred van Blommestein is adviseur bij Berenschot (fjb@berenschot.com). Gait Boxman is technisch consultant bij TIE (gait.boxman@tie.nl). Beiden zijn actief betrokken bij de UN/Cefact ebXML-standaardisatie.