Om Java 2EE en.Net kan niemand heen
Het vervangen van monolithische, inflexibele applicatiearchitecturen door op componenten gebaseerde architecturen is al een aantal jaren gaande. De laatste tijd raakt die vervanging in een stroomversnelling. De toolsets van voor het tijdperk van componentgebaseerd werken, zoals vierdegeneratietalen en transactiemonitors als CICS en Tuxedo, worden al jaren in een minderheid van alle ontwikkelprojecten toegepast. Maar in grotere softwareprojecten verliezen ze nu ook snel terrein. Dit jaar staan ze voor het eerst in minder dan 50 procent van de gevallen aan de basis van de grotere bedrijfsapplicaties. Die trend zet onverminderd door, voorspelt Gartner. Eind 2006 wordt nog maar 15 tot 20 procent van de grote softwareprojecten met deze toolsets gebouwd. Hun plaats wordt overgenomen door componentgebaseerde architecturen. Daarbij strijden twee ontwikkelomgevingen om de gunst van de ontwikkelaars: J2EE en.Net. J2EE is verder Er is volgens Pezzini weinig discussie over mogelijk dat J2EE de verst ontwikkelde toolset is. J2EE is in 1998 door Sun Microsystems op de markt gebracht met aanmerkelijke inbreng van IBM en van softwareleveranciers als BEA. In de jaren daarna zijn er tal van elementen aan toegevoegd. Microsofts.Net is pas dit jaar in de vorm van de ontwikkelomgeving Visual Studio.Net op de markt gekomen. Weliswaar bouwt.Net conceptueel voort op eerdere architecturen als Com+ en het daarvan afgeleide DNA2000, toch vormt.Net een duidelijke breuk met Microsofts verleden. ".Net heeft een geheel eigen opzet met geheel nieuwe application programming interfaces gekregen om de architectuur te optimaliseren voor zwaardere systemen dan pc’s. Met Com+ was men wat dat betreft wel aan het eind van de mogelijkheden. Consequentie is wel dat Com+toepassingen niet op.Net draaien. Migratie zal voor bedrijven en onafhankelijke softwareleveranciers een behoorlijke kostenpost betekenen en veel tijd vergen", zegt Massini. "Maar wat belangrijker is: omdat.Net een geheel nieuwe opzet heeft gekregen, is het nog lang niet uitgekristalliseerd. Men mag verwachten dat.Net nog aanmerkelijk zal evolueren, de komende drie jaar." Rijpheid van de omgeving is echter niet het enige criterium dat men bij de afweging tussen J2EE en.Net moet aanleggen, stelt Pezzini. Nadeel van J2EE is bijvoorbeeld, dat het in het volwassenwordingsproces een behoorlijk complexe omgeving is geworden. "Dat betekent dat je goed geschoolde ontwikkelaars nodig hebt, en die zijn duur en moeilijk te vinden. De meeste J2EEimplementaties gebruiken daarom maar een klein gedeelte van de mogelijkheden van de toolset." Ook het feit dat Java de enige programmeertaal is binnen deze architectuur, maakt de drempel tot adoptie redelijk hoog. Bovendien is er een veelheid van leveranciers betrokken bij de verdere ontwikkeling van J2EE, wat tot vertraging en onder omstandigheden zelfs tot een splitsing der wegen kan leiden. Microsoft daarentegen heeft de verdere ontwikkeling van.Net in eigen hand en hoeft geen consensus te zoeken met andere partijen. De opstap naar het.Netplatform is voor ontwikkelaars bovendien een stuk simpeler, omdat er een veelheid aan programmeertalen wordt ondersteund, waaronder Visual Basic. "Veel van de huidige 3 miljoen VBontwikkelaars zullen wel een extra inspanning moeten plegen om de opstap te kunnen maken, maar het hoeft geen betoog dat ze makkelijker de weg zullen vinden naar.Net dan naar J2EE", aldus Pezzini. Daar staat tegenover dat.Net alleen op het Windowsplatform draait. Daardoor is.Net geen aantrekkelijke architectuur voor softwareleveranciers. De meeste houden zich dan ook verre van.Net, met als enige opvallende uitzondering Siebel. Bovendien moet men.Net gezien de ontwikkelfase van het product toch behandelen als nieuwe technologie die zich nog moet bewijzen, hoewel het volgens de eerste berichten wel goed ontworpen en stabiel is, aldus Pezzini. Kleine projecten Pezzini’s conclusie is echter niet dat men.Net vooralsnog links moet laten liggen. Als platform is het zonder meer geschikt voor kleine tactische projecten. Voor systemen die tot honderd gelijktijdige gebruikers moeten kunnen bedienen, heeft.Net op grond van het gebruiksgemak, de ontwikkelproductiviteit en de kosten zelfs de voorkeur. Voor echt grote bedrijfskritische projecten moet men zich verlaten op J2EE, meent Pezzini. Daartussen is een grijs gebied waarbij men van geval van geval moet bekijken wat het beste is. Daarbij is het oppassen voor de fout om aan te nemen dat de ‘cost of ownership’ voor.Net wel altijd lager zal zijn, waarschuwt Pezzini. Op middellange termijn zullen ontwikkelorganisaties zich op moeten maken voor een volgende architectuuromslag. Die wordt noodzakelijk omdat.Net en J2EE conceptueel al weer een jaar of vijf oud zijn. "Qua opzet is de onderliggende architectuur daardoor monolithisch van aard. Antwoorden op hedendaagse uitdagingen, zoals applicatieintegratie en ‘event driven’verwerking om de Real Time Enterprise gestalte te kunnen geven, zijn daarin niet opgenomen. Bij J2EE zijn of worden dergelijke mechanismen wel via ‘addons’ ingebracht, en Microsoft zal dat ongetwijfeld ook doen, maar zolang ze niet in de kern van de ontwikkelomgeving zijn ingebouwd, kun je niet spreken van een stabiele, gestandaardiseerde oplossing", meent Pezzini. Opkomst web services De web services die nu in opkomst zijn, vormen niet de oplossing voor dat probleem. "De overgang naar een servicegeoriënteerde manier van verwerking via het internet kan een oplossing brengen voor de beperkingen van J2EE en.Net, maar dat gebeurt niet op korte termijn. Het werken met web services vraagt, net zoals de gedistribueerde architecturen als Corba waar ze schatplichtig aan zijn, behoorlijk wat planning en bijbehorende expertise voordat ze effectief ingezet kunnen worden, en dat moeten bedrijven zich eigen maken. Belangrijker nog, is dat de nu gedefinieerde web servicesstandaarden, zoals SOAP, UDDI en WSDL, te zamen niet meer bieden dan een simpel mechanisme voor ‘remote procedure calls’. Voor echte bedrijfstoepassingen is dat te mager. Of de voorliggende aanvullende voorstellen tot de benodigde standaarden leiden, valt nog te bezien. De implementaties van SOAP van Microsoft en Borland zijn nu al niet identiek."