Er ontstaan gaandeweg twee e-commerce-architecturen, één voor interactieve ‘consumer-to-business’ (C2B)-applicaties en de andere voor ‘business-to-business’-omgevingen. Er zijn natuurlijk veel varianten, verfijningen en combinaties. B2B-applicaties kunnen interactief zijn, maar kennen altijd een vorm van interactie tussen zakelijke applicaties over een netwerk.
Deze applicaties zijn meestal gebaseerd op berichtensystemen. Sommige daarvan zijn ‘point-to-point’, maar het grootste deel vormt in feite de nieuwe generatie edi-systemen en biedt in die hoedanigheid netwerkmogelijkheden (many-to-many). Voor deze klasse van systemen is een aanbieder nodig die zorgt voor de vertaling en distributie van berichten.
De technische basisarchitectuur is inmiddels algemeen beschikbaar. Voor interactieve C2B-omgevingen wordt gebruik gemaakt van browsertechnologie , voor B2B-omgevingen van ’transaction messaging’-mechanismen. De relationele database is de gemeenschappelijke back-end.
De basisarchitectuur voor een C2B-applicatie is er één met een dunne client en een applicatieserver die de functionaliteit tussen de browser-client en de database verzorgt. Dit zou in theorie gebaseerd kunnen zijn op bestaande transactiemechanismen, maar in plaats daarvan is er een nieuwe generatie applicatieserver-platforms gecreëerd. Sommige daarvan zijn gebaseerd op specifieke Microsoft-technologie, maar de meeste maken gebruik van Java op de server. B2B-omgevingen worden steeds vaker gebaseerd op XML-services, die worden aangesloten op bestaande applicaties door aan de ene kant gegevens te extraheren en die gegevens aan de andere kant aan te bieden. Met behulp van specifieke Schema’s en API’s wordt de B2B-dienst tot een standaard, al zal het interface met bestaande applicaties altijd extra aandacht vergen.
Terwijl deze architecturen uitgroeien tot de facto standaarden, wordt er ook een gezonde vooruitgang geboekt op het gebied van ontwikkeltools. Lagere programmeertalen zoals C, VB en Java worden nog steeds ondersteund, maar er zijn ook hogere ontwikkelomgevingen die Java en dergelijke genereren en die lijken op de oudere 4GL-technieken. Voorbeelden zijn Aptivity, SilverStream en Cold Fusion, maar ook tools zoals Websphere en WebLogic. Daarnaast zijn er tools voor het ontwikkelen en testen van XML en Schema’s, zoals Stilo WebWriter.
En zo gebruiken de meeste organisaties deze en andere tools om hun eigen e-commerce-applicaties te ontwikkelen. Maar net als een gewone applicatie kan ook een e-commerce-omgeving hetzij in huis worden ontwikkeld, hetzij met behulp van een pakket worden geïmplementeerd. Ook op dit vlak zijn er verschillende smaken. Sommige pakketten zijn in de klassieke zin, gericht op specifieke eisen. Andere zijn flexibeler en worden gepositioneerd boven het 4GL-concept. Ze bieden met name de infrastructuur en de ‘libraries’ met herbruikbare componenten, waardoor de implementatie sneller en eenvoudiger verloopt. Sommige pakketten staan volop in de belangstelling – zoals Commerce-one, Ariba en I2 – omdat IBM ze probeert te bewegen hun systeem naar Websphere of iets vergelijkbaars te ‘porten’.
Toch is er een potentieel probleem. Al deze systemen zijn ontwikkeld om ze zo snel mogelijk op de markt te kunnen brengen. De meeste zijn ontstaan uit applicaties die voor specifieke klanten zijn gebouwd (of voor specifieke sectoren, zoals het bankwezen). Deze producten zijn meestal gebaseerd op de algemeen geaccepteerde standaarden die hierboven zijn genoemd, maar tijdens de ontwikkeling ervan waren er nog geen kernproducten voorhanden, anders dan een NT Server of een Java Virtual Machine. Als gevolg hiervan biedt elk product noodgedwongen een uitgebreide runtime-ondersteuning, zoals Java componentmanagers en recovery-diensten. Verder heeft elk product ‘adapters’ om de specifieke eigenschappen van de gebruikte databases (Oracle, DB2 en Sybase) te kunnen ondersteunen.
Op de huidige leveranciersspecifieke aard van deze e-commerce-omgevingen heb ik geen kritiek, omdat de standaarden nog niet volledig waren toen ze ontwikkeld werden. De volgende fase is veel belangrijker. Sleutel tot de toekomst is Enterprise Java Beans (EJB). De volgende EJB-versie 1.0 is niet uitgebreid genoeg om alle benodigde runtime-functionaliteit te bieden; specifieke uitbreidingen blijven nodig. Maar versie 1.2 komt eraan en versie 2 wordt begin volgend jaar verwacht. Medio 2001 zouden er genoeg producten moeten zijn die de volledige set EJB-diensten ondersteunen. Daarom is er een grote behoefte aan ontwikkelomgevingen, component-libraries en producten op applicatieniveau, maar niet aan runtime-ondersteuning.
Het is helder dat de meeste leverancier van applicatieservers en hogere ontwikkeltools hun producten naar EJB’s porten, maar dat is moeilijk voor een leverancier die in de begindagen zijn eigen runtime-systeem heeft ontwikkeld en dat nu moet wegdoen. Daardoor is een herpositionering van bestaande leveranciers onvermijdelijk. Wie doorbijt en zijn eigen runtime-omgeving desinvesteert zal overleven, wie dat niet doet trekt zichzelf omlaag. Dit betekent ook dat de grens tussen bedrijven met een focus op applicatie-ontwikkelomgevingen en bedrijven gericht op applicaties verder zal vervagen. IBM, Microsoft, BEA en dergelijke zullen hun steun geven aan leveranciers die waarde kunnen toevoegen aan Websphere en vergelijkbare initiatieven.
Martin Healey, pionier ontwikkeling van op Intel gebaseerde computers en c/s-architectuur. Directeur van een aantal IT-bedrijven en professor aan de Universiteit van Wales.
