Het ligt voor de hand dat nieuwe concepten als het Web en e-handel intensief steunen op nieuwe technologieën. Alle ogen zijn daarom gericht op de oorlog tussen Microsoft en Java. Microsoft heeft een enorme achterban aan ontwikkelaars, terwijl Java technisch gezien superieur is.
Java geniet de steun van de rest van de industrie, die anti-Microsoft is, en heeft daardoor genoeg kritische massa om de kindertijd door te komen. Het is onvermijdelijk dat we op den duur van Visual Basic naar Java gaan. Java belooft een betere toekomst, terwijl Visual Basic nogal beperkt is. In onze industrie geven technische georiënteerde ontwikkelaars de voorkeur aan Java; hun invloed zal toenemen.
De strijd tussen de gevestigde en de nieuwe orde is dus een normale situatie. Deze keer is Microsoft de ‘oude hap’, wat aantoont hoe snel dingen kunnen veranderen. Visual Basic werd ooit aangeprezen als de opvolger van bejaarde producten als Cobol en RPG. Dat was in zekere zin ook waar, omdat de nieuwe applicaties een grafisch interface nodig hadden en de visuele benadering van Visual Basic (en betere producten, zoals Delphi) zeer productief bleek te zijn. Niemand ging RPG uitbreiden met gui-functies. Applicaties hebben echter vele facetten, en het grafisch interface is daar slechts één van. Veel belangrijker is de bedrijfslogica in het hart van de applicatie. Voor het grafische interface was Visual Basic een verbetering ten opzichte van de oude karaktergeoriënteerde Cobol-interfaces, maar als programmeertool was het zwak. Het dunne client-model zou het beste van twee werelden verenigen: de visuele capaciteiten van Visual Basic op de client, gekoppeld aan de krachtige, robuuste, gegevensgerichte multi-user kwaliteiten van Cobol en RPG op de server. Het ligt zó voor de hand dat je nauwelijks kunt geloven dat deze architectuur niet de norm voor alle client/server-applicaties geworden is.
Veel professionele ontwikkelaars voegden wel dunne client-gui’s aan bestaande toepassingen toe. Daarbij maakten ze gebruik van ‘remote procedure calls’ (RPC). Het hadden er veel meer moeten zijn, maar het waren er genoeg om Cobol en RPG in leven te houden. Daarnaast is de Cobol-kennis door het millenniumprobleem goed op peil gehouden. De grootste uitdaging na 2000 is hoe we deze kennis het beste kunnen benutten.
Oppervlakkig gezien is e-handel een ander voorbeeld van een nieuw concept dat alleen nieuwe vaardigheden en technologieën zal aantrekken; EJB versus ASP enzovoort. Deze keer zijn er echter goede alternatieven. Allereerst realiseren de meeste organisaties zich nu dat hun investering in client/server-applicaties op basis van Visual Basic een regelrechte ramp is – al zullen ze dat nooit toegeven. Het muntje is nu wel gevallen. In de tweede plaats lijkt het niet zinvol om toepassingen voor e-handel helemaal opnieuw te ontwerpen. E-handel is immers niets anders dan een nieuwe manier om een interactief bestelsysteem op te zetten. Er zijn natuurlijk belangrijke verschillen, zoals het gebruik van web-browsers als clients en de problemen rond beveiliging en prestatie als je Internet als toegangsmedium gebruikt. Maar al deze problemen hangen samen met de client-kant. Als we dikke client-applicaties even laten voor wat ze zijn, dan is de ‘back-end’ ofwel de server-kant van bestaande ordersystemen goed genoeg voor de meeste e-handelsapplicaties.
Waar het om gaat is het volgende. Nieuwe toepassingen voor e-handel kunnen EJB’s gebruiken om toegang tot de relationele database te krijgen. Dat is echter niet verstandig, omdat dit betekent dat alle bestaande bedrijfslogica opnieuw in Java ontwikkeld moet worden. Het is veel slimmer (een les die we geleerd hebben van dikke en dunne clients in eigen huis?) om aan de client-kant nieuwe technologie in te zetten en aan de server-kant gebruik te maken van bestaande bedrijfslogica en databases, samen met ondersteunende systemen zoals facturering, logistiek en dergelijke.
De applicatieserver moet opnieuw worden ontwikkeld, maar hoeft alleen client-functies te verrichten. De applicatieserver communiceert via EJB met bestaande transactiesoftware, zoals Cics of Tuxedo. Hieruit volgt dat Cobol en RPG waarschijnlijk de beste tools zijn om de ‘back-end’ van een e-handelsapplicatie te ontwikkelen, naast de meer traditionele bedrijfstoepassingen. Op deze manier kunnen we optimaal gebruik maken van onze vaardigheden – Java voor de nieuwe client-onderdelen, Cobol en RPG voor de server. Verrassend genoeg kunnen Cobol/RPG en Java gelukkige partners zijn!
