Met middleware kunnen organisaties reeds geïnstalleerde systemen blijven gebruiken en losjes koppelen aan nieuwe en toekomstige platformen. Er bestaan, naast Microsoft, diverse leveranciers van middleware, en een universele standaard ontbreekt. Over de kloof tussen principe en praktijk.
| De Paradox van de Strijd Aanbieders vechten zich dood op de markt van bedrijfssytemen. NT, Unix, Netware. Sparc, Intel, Alpha. Oracle, SQL Server, DB2. Oorlog dus, en dan met name een publicitaire oorlog. Maar klanten relativeren, en dat doen ze al tijden. Die weten dat je systemen door elkaar moet kunnen gebruiken. Exclusiviteit, daar houden ze niet zo van. Die boodschap begint nu door te dringen. Verslaggevers Jasper Bakker en Roy op het Veld verkennen het slagveld en de strijdende partijen en geven uitleg over de Paradox van de Strijd. |
Dit probleem van koppeling en integratie is in wezen ontstaan door de gesloten aard van diverse IT-systemen die elk incompatibel zijn met de ander. Vaak hopen leveranciers daarmee klanten aan zich te binden. En wanneer eenmaal een meerderheid van de markt is veroverd, kan er gesproken worden van een ‘de facto’-standaard. Ondertussen worstelen gebruikers met hun kluwen aan verschillende IT-‘eilandjes’. Inmiddels is het gebruik van middleware al behoorlijk doorgedrongen als uitweg. Met deze tussenlaag-software kunnen organisaties reeds geïnstalleerde systemen blijven gebruiken en dus de daarin gepleegde investeringen, maar ook losjes koppelen aan nieuwe en toekomstige platformen.
Vier vormen middleware
Hoe simpel de voorstelling van middleware ook is, het fenomeen kent complexe uitingsvormen. Alleen het aantal standaarden al doet de welwillende IT-manager huiveren. Hoe kan een product als standaard getypeerd worden, als er verscheidene technologieën zijn die hetzelfde doel nastreven en dus de titel ‘standaard’ verbinden aan hun product? We noemen DCE (Distributed Computing Environment), Com+ (Component Object Model), Corba (Common Object Request Broker Architecture) en andere soms asynchrone middlewaretechnologieen. Vele IT-spelers zijn betrokken bij de middleware-markt. Inprise, Platinum, Oracle, Netscape, IBM, Compuware, Sun, Sybase, Bea Systems, Software AG, Iona, allemaal leveren ze middleware of softwareproducten waar middleware deel van uitmaakt.
Middleware kan vier verschillende gedaanten aannemen. Transactie-verwerking, die de communicatie tussen applicaties, objecten en wat niet al regelt, is er één. Het op-afstand aanroepen van programma-logica (remote procedure call) is een volgende; dat zorgt ervoor dat de logica van een enkele applicatie gedistribueerd kan worden over een netwerk zodat de verscheidene functionele componenten zich op fysiek verschillende locaties bevinden. Berichtenverkeer (message-oriented) is de derde vorm, en draagt zorg voor de gegevens-uitwisseling tussen programma’s die met elkaar weer een gedistribueerde applicatie kunnen vormen. Denk aan een combinatie van bijvoorbeeld databanken voor inkoop en verkoop. En tot slot is er de object-georiënteerde gedaante waardoor objecten over heterogene netwerken kunnen functioneren als een applicatie.
Deze vier vormen onderscheiden zich nog eens op een ander vlak van elkaar; wordt er synchroon dan wel asynchroon gecommuniceerd? In het eerste geval moeten beide – of zelfs meerdere – kanten van de gegevensstroom actief (online) zijn en is er een rechtstreekse verbinding vereist. Bijvoorbeeld tussen client en server, of tussen de diverse applicatiedelen. Vaak moet de ene kant wachten op antwoord van de andere kant. In het tweede geval, asynchrone communicatie, verloopt het verkeer via een tussenpunt of via een later tijdstip. Denk aan een server met een berichtenrij (message que) of aan een nachtelijke ‘batch’-operatie waarbij gegevens worden uitgewisseld en ververst. De meeste leveranciers zijn het er wel over eens dat beide communicatiesoorten nodig zijn, afhankelijk van de toepassing. Is die bedrijfskritisch of afhankelijk van tijd? Wel wordt er een trend naar meer en meer synchrone communicatie gesignaleerd. ‘Zelfs’ van e-mail verwachten mensen al dat het direct aankomt.
Afspraken
Zoals gezegd bestaat er geen universele standaard op deze markt, maar heeft een aantal leveranciers individueel of gezamenlijk afspraken gemaakt over de manier waarop softwarecomponenten met elkaar communiceren. DCE is een inmiddels in onbruik geraakte ‘standaard’ van de Open Software Foundation (OSF) voor Unix-platformen. De in 1995 verwachte doorbraak bleef uit, waarna Corba in combinatie met Java het publicitaire en praktische voortouw namen. Het grote voordeel van gedistribueerde Corba/Java-applicaties is dat ze in principe platformonafhankelijk zijn en dus ook op niet-Unixmachines kunnen draaien. Corba wordt door de Object Management Group (OMG) gespecificeerd en onderhouden, een standaardisatie-organisatie zonder winstoogmerk die de grote softwareproducenten behoudens Microsoft tot zijn leden rekent. Waar de Unix-markt zijn neus enigszins begon op te halen voor DCE, rook Microsoft zijn kans en baseerde zijn componentenmodel (Com) op de redelijk volwassen maar in de markt afglijdende Unix-technologie. Met dien verstande dat Com voor het Windows NT-platform ontworpen is.
Naast de strubbelingen met Unix en Windows NT is er nog een andere wereld, waar IBM al jaren en jaren heerst; de mainframe-omgeving. Op dit platform zijn Cics (Customer Information Control System) en MQ Series (Message Que) de absolute alleenheersers en dus standaarden voor respectievelijk synchrone en asynchrone middleware. Met behulp van MQ Series sturen softwarecomponenten berichten naar elkaar toe. Een verkoopsysteem stuurt bijvoorbeeld via een bericht een order naar het factureringssysteem. Het voordeel is dat het versturende systeem geen rechtstreekse verbinding hoeft te onderhouden met het ontvangende systeem. Grote en drukke omgevingen zouden anders niet kunnen functioneren. Cics is meer georiënteerd op het online verwerken van transacties. Naast middleware voor mainframesystemen heeft IBM overigens het Corba-product Component Broker, dat geïntegreerd is in de applicatie- annex webserver Websphere.
Eén technologie
Elk platform heeft dus zijn middlewaretechnologieen. Op NT maakt Microsoft de dienst uit met Com+, op Unix de OMG met Corba en op het mainframe IBM met Cics en MQ Series. De trend op de middlewaremarkt bestaat uit het slaan van bruggen tussen de verschillende technologieën. Middleware tussen de middleware als het ware. Het uiteindelijke doel van middleware is dat er slechts één technologie overblijft, die door alle bedrijven toegepast wordt. Een vergelijking uit de wereld van de consumentenelektronica dringt zich op. Geen enkele consumentenelektronica-leverancier denkt er tegenwoordig nog over om een eigen video-technologie te ontwikkelen. In de jaren tachtig is de strijd gestreden tussen Betamax, Video 2000 en VHS. Met de laatste als duidelijk winnaar.
In het artikel ‘Componentenlijm van Microsoft (Computable, 20 november) hebben we de ontwikkelingen rond Microsofts Com+ reeds uitvoerig aan de orde gebracht. Vooral opvallend was de openheid van de technologie naar andere platformen. Microsoft beseft dat het geen marktaandeel kan veroveren in de prestigieuze bovenkant van de markt zonder ‘poorten’ aan te bieden die Com+ koppelt met Unix-machines en mainframes. De heterogene infrastuctuur van de grote IT-gebruikers in de financiële-, verzekerings- en telecomwereld (waar gedistribueerde systemen en dus ook middleware zijn eerste toepassingen kent) hebben Microsoft gedwongen tot het openstellen van zijn producten.
DCE
DCE was één van de eerste en goed functionerende middlewaretechnologieën voor Unix. Volgens de gebruikers ervan zijn er op Unix nog geen goede alternatieven beschikbaar voor DCE. Deze gebruikers zijn vaak fanatieke voorvechters van een bepaalde visie op technologie, namelijk hun technologie. Ondanks de verschillen tussen de Unix-dialecten van bijvoorbeeld Hewlett-Packard, IBM en Sun, kunnen ontwikkelaars met DCE door slechts één keer in te loggen verscheidene applicaties benaderen. Ondanks het feit dat Corba nog geen sluitende definitie heeft voor beveiliging en netwerkbeheer, lijkt de kans gering dat DCE zal overleven als Corba en Java uitgroeien tot volwassen, platformonafhankelijke, maar vooral veel toegepaste technologieën. Bovendien heeft DCE de naam lastig te programmeren te zijn.
Bea Systems, met zijn transactie-monitor Tuxedo één der groten in de middleware-markt, onderstreept de lastige natuur van DCE. Volgens deze softwareleverancier was het eens een schitterend idee, dat echter tekort schoot op het gebied van de inzetbaarheid. Op dat punt kom je weer met beide voeten op de grond, aldus Bea, dat hamert op het enorme belang van inzetbaarheid. Volgens deze visie bevindt 30 procent van de middleware-ijsberg zich buiten het zicht en besteden teveel leveranciers en gebruikers het merendeel van hun tijd en budget aan dat stukje. Terwijl zowel ontwikkelaars als gebruikers juist zouden moeten denken aan fundamentele zaken als fail-over, de lastenverdeling en de uitbreidingsmogelijkheden voor nieuwe, toekomstige systemen en functionaliteit. Voor de uiteindelijke werking van de applicatie kijk je eerst naar de architectuur, zo predikt deze middleware-leverancier. Ook daar heeft DCE gefaald in de ogen van Bea; de implementatie is afhankelijk van de ondersteuning in de hardware. Daar is weliswaar een standaard voor, maar die hapert op het verschil in snelheid waarmee fabrikanten nieuwe versies opnemen in hun apparatuur.
Inprise, het voormalige Borland, heeft ontwikkeltools als Delphi waarmee naast Corba- en Com- ook DCE-componenten gebouwd kunnen worden. Inprise claimt middleware voor alle standaarden te leveren. Oracle is explicieter dan Inprise en kiest bewust voor Corba als middleware-standaard. Het biedt ondersteuning voor de rest, maar zet Corba duidelijk in het centrum. Oracle biedt vanuit zijn applicatieserver of vanuit de database koppelingen naar DCE- of Com+-componenten. Tijdens de bouw van gedistribueerde systemen gebruikt het daar bij voorkeur standaardproducten van middlewareleveranciers voor. Oracle zit naar eigen zeggen niet in maar op de middlewaremarkt.
Ook Compuware biedt in de productie-omgeving van Uniface koppelingen naar zoveel mogelijk middlwaretechnologieen, waaronder Com+, Corba en transactieprotocollen als Tuxedo.
Corba
App Center, de applicatieserver van Inprise komt volgende maand op de markt en integreert alle middlewareproducten met een applicatie beheertool en een ontwikkeltool. De applicatieserver wordt daarmee een hulpmiddel voor het ontwikkelen en in productie brengen van gedistribueerde applicaties.
Inprise’s middleware bestaat uit een transactieserver en de Object Request Broker (ORB) van het geacquireerde Visigenic. Deze Visibroker is reeds 2,5 jaar op de markt en was daarmee één van de eerste middlewareproducten die de Corba-standaard in de praktijk bracht. In tegenstelling tot DCE, dat via een zogenoemde remote procedure call (rpc) werkt, maken Corba-producten gebruiken van een ander communicatiemechanisme. Met rpc worden functies in andere DCE-componenten aangeroepen, terwijl ORB’s een method, een apart programma, aanroepen.
In de Inprise-omgeving zijn momenteel geen ansynchrone protocollen beschikbaar, maar daar wordt aan gewerkt, meldt het bedrijf. Belangrijk is de brug die DCE-componenten met hun ‘Corba-collega’s’ laat communiceren. Het probleem daarbij is dat niet alle Corba-producten op de markt de OMG-standaard op dezelfde wijze hebben geïmplementeerd. DCE kent dit probleem niet. Een DCE-object is een DCE-object. Een Corba-object volgens Iona is niet per definitie hetzelfde als een Corba-object volgens Inprise. De standaardspecificatie van de OMG heeft geen oplossing voor bepaalde aspecten. Leveranciers als Inprise willen hun klanten toch iets aanbieden op het gebied van beveiliging en netwerkbeheer, die in Corba onvoldoende geregeld zijn. Gevolg: elke leverancier implementeert deze extra’s op zijn eigen manier waardoor de standaard geen standaard meer is. Gebruikers die componenten van verschillende implementaties willen gebruiken in één gedistribueerd systeem moeten op deze punten nog handwerk verrichten om alles aan elkaar te breien. Inprise meent dat de verschillen tussen de leveranciers steeds kleiner worden en verwacht dat Corba binnen twee jaar een echte standaard is. Inprise heeft een brug tussen Corba en Com in de maak. De OMG heeft hiervoor het Iiop (Internet Inter ORB Protocol) ontwikkeld. Software AG heeft op dit gebied – Com-diensten poorten naar een Unix-omgeving – namens Microsoft veel pionierswerk verricht.
Geen grove afwijkingen
In tegenstelling tot Inprise, meent Oracle dat Corba wel uniform geïmplementeerd is. Het bedrijf erkent wel dat sommige middlewarebouwers ‘eigen dingen’ aan de standaard toevoegen om zich te onderscheiden. Maar volgens Oracle mogen de resulterende componenten daarvan eigenlijk niet het stempel ‘Corba’ dragen. De softwaregigant redeneert dat gebruikers die kiezen voor een Corba-implementatie met niet-standaard extra’s, met een lock-in situatie geconfronteerd worden. Ze kunnen namelijk niet zonder meer Corba-technologie van anderen integreren.
Ook Sun Microsystems belijdt Corba en ziet geen grove afwijkingen, ondermeer doordat het bedrijf nauw betrokken is bij de ontwikkeling van de Corba-standaard. Daar bovenop biedt het Enterprise Java Beans (EJB), die weer een abstractielaag tussen de middleware vormt. De trend is volgens Sun naar het loskoppelen; we zijn al los van de processor, we komen los van het besturingssysteem en zelfs de gebruikers-interface en met EJB ook van de middleware. Uiteindelijk gaat het om de diensten en niet om de applicaties, aldus Sun. Deze technologie staat nog enigszins in de kinderschoenen, maar de specificaties zijn open waardoor ‘beans’ van verschillende leveranciers in wezen uitwisselbare componenten zijn. Dit leidt tot een strijd om de beste implementatie op basis van dezelfde standaard. Die wordt namelijk bepaald middels een industrie-werkgroep waar ieder zijn stem kan laten horen. Zo werken
Bea, Oracle en IBM samen met Sun aan de EJB-specificaties.
Bea hecht dus ook sterk aan het onderliggende Corba, maar erkent wel dat er grote verschillen zijn tussen de diverse Corba-producten op de markt. Zo vereist de meeste middleware een directe verbinding, aldus Bea. De software van dat concern doet het net even anders; het gebruikt een interne software-matige ‘message-switch’ die het aantal verbindingen drastisch verlaagd, wat ook het beheer eenvoudiger maakt. Ondertussen proberen databankleveranciers wel een mouw te passen aan dit probleem van verbindingen, maar dat kan weer uitlopen op een bedrijfsspecifieke, gesloten oplossing waardoor de gebruiker vastzit aan zijn leverancier.
Uniforme implementatie
Op dit gebied tekent zich een dilemma af voor de IT-industrie. Aan de ene kant is het voor individuele leveranciers aantrekkelijk producten aan te bieden op basis van een unieke technologie. Daardoor kunnen klanten alleen door een grootschalig vervangingstraject overstappen naar een andere leverancier. Unieke ofwel proprietary technologie schermt de markt af. Zolang Corba geen Corba is, speelt dit fenomeen een rol. Aan de andere kant is de gehele industrie gebaat bij een uniforme implementatie van Corba, omdat anders de markt naar alternatieven gaat zoeken. Zeker in de onderkant van de markt worden gedistribueerde applicaties gebouwd op basis van Com+ van Microsoft. Gebruikers weten wat ze krijgen en blijven verwijderd van de verschillen in Corba-producten. Vooral Oracle hamert erop dat Corba ‘zuiver’ geïmplementeerd moet worden. Verdere functionaliteit moet in die visie onafhankelijk van de middleware gebouwd zijn, zodat deze niet bijt met andere componenten. Het bedrijf is ervan overtuigd dat middleware in de toekomst universeel is, vergelijkbaar met VHS in de videowereld.
Bermudadriehoek
Middleware is desondanks nog geen universeel wondermiddel. Zo gaapt er een gat tussen principe en praktijk. Sommige populaire middleware-diensten gebruiken namelijk nog steeds gesloten implementaties van een open standaard. Applicaties zijn hierdoor afhankelijk van het product van één leverancier. Verder vormt de grootte van het aantal middleware-diensten een belemmering voor het gebruik. Om de IT-omgeving beheerbaar te houden, moeten gebruikers een klein aantal diensten selecteren die tegemoet komen aan hun vereisten voor functionaliteit en platform-bereik. Bovendien moeten ontwikkelaars nog steeds harde keuzes maken bij het programmeren van nieuwe applicaties. Middleware vermindert weliswaar de moeilijkheidsgraad voor het programmeren van gedistribueerde software, maar toch is er nog de keuze welke functionaliteit aan de client- en welke aan de server-kant wordt geplaatst.
Het dilemma komt in wezen neer op een ‘Bermudadriehoek’ die bestaat uit de applicaties, de platformen en de IT-afdeling. Bedrijfskritische software gaat naar schatting minstens tien jaar mee. Platformen, waaronder besturingssystemen, netwerken en databanken zijn te verstaan, halen twee tot vijf jaar. Die discrepantie in tijd en mogelijk ook functionaliteit moet de IT-staf zien op te vangen. Daarbij spelen er nog factoren mee als overeenkomsten voor dienstenniveau’s, de beschikbaarheid van voldoende geschoold personeel en de integratie van overgenomen bedrijven. Een verkeerde balans tussen deze drie puzzelstukken waar middleware tussendoor moet glijden, zorgt ervoor dat ‘rightsizen’ omslaat in ‘kapsizen’.
De genoemde beperkingen van middleware kunnen natuurlijk overkomen worden. Dit vereist echter een gedegen afweging door gebruiker van de benodigde functionaliteit. Gaat het om gedistribueerde systeemdiensten, zoals communicatie tussen programma’s, om toegang tot gedistribueerde diensten en het onderliggende netwerk, of om beheerdiensten waarmee de gedistribueerde omgeving valt te overzien? Zoals bij eigenlijk alle technologie staat of valt de effectiviteit van middleware met de beschouwing vooraf.
Roy op het Veld en Jasper Bakker, redacteuren
