Tags: Apex | Oracle | Oracle Forms

Oracle Forms migratie (finally) made easy!

Het lijkt al jaren een utopie: Oracle Forms migratie richting nieuwe technologieën, waarbij het resultaat van de migratie geen extra beperkingen of vereisten oplevert. Een utopie, dat wil zeggen, tot voor kort. Want met QAFE is er eindelijk een goed antwoord op de toenemende vraag naar effectiever- en efficienter - migreren van Oracle Forms.

Een terugblik

Forms Migratie staat al jaren hoog op de agenda van veel bedrijven. Oracle Forms kent dan ook een relatief lange geschiedenis. Het speelde in de jaren '90 goed in op de ¿Client-Server¿- architectuur die toen domineerde. Met de opkomst van internet verschoof de balans van die marktsituatie langzaam. Voornamelijk J2EE (nu JEE) en .NET wonnen aan kracht.

Het verschil

Client-Server, zoals bij Oracle Forms, gaat uit van een dedicated connection naar een database. En in het algemeen geldt: connections eisen resources en die zijn door hardware gelimiteerd. In een N-tier omgeving als JEE en .NET is het daarentegen mogelijk potentieel miljoenen gebruikers te hebben. Zie Google of MSN met bijvoorbeeld 100 connecties i.p.v. voor elke user een aparte connectie.

Oracle Forms

Rond 2000 onderkent Larry Ellison (CEO Oracle) de situatie en geeft hij aan dat alles richting internet en webtechnologie gaat. Hij besluit die slag vanuit 2-tier, met behulp van Java-technologie, te slaan. Vanaf Oracle Forms 9i zijn de Forms van Oracle dan ook ¿WebForms¿, gebaseerd op Java Applets. Echter, er zaten nog de nodige beperkingen aan, waaronder het feit dat dit een plugintechnologie is en alsnog een client install nodig had van een Java-plugin.

JHeadstart intermezzo

In de tussentijd, rond 2001, ontwikkelt Oracle Nederland JHeadstart, waarmee de Oracle Forms ¿echt¿ naar het web kunnen. Helaas zien gebruikers en developers de bui al hangen. Voor gebruikers waren er ineens meer handelingen nodig om hetzelfde te bewerkstelligen, als in de traditionele Client- Server (Web)Forms. Developers moesten op hun beurt de programmeermindset omschakelen naar Object Georienteerd (O.O.) ontwikkelen, omdat Java de basis was van de backend.

Begrijpelijk dat de adaptie van JHeadstart tegenviel. Developers bleven nu eenmaal veel productiever met de Oracle Designer en Forms Developer. Dat JHeadstart van proprietary oplossing (UIX) naar Struts en vervolgens naar ADF is gemigreerd, heeft de zaak logischerwijs ook geschaad.

Leergeld

De les is dat gebruikerservaringen goed moeten zijn en dat je ontwikkelaars niet moet frustreren met nieuwe talen en alternatieve logica (Oracle Developers denken vanuit de data, terwijl een O.O.-ontwikkelaar vooral vanuit classes/overerving redeneert).

Tot zover de theorie. In de praktijk stond de wereld ondertussen niet stil. De internetgeneratie is flink verwend door producten als GMail, Flickr.com, Online Office programma's, etc.

Web 2.0

Een voorbeeld? Vroeger moest Office op elke PC/laptop geïnstalleerd worden wat veel onderhoud(skosten) betekende. Google Docs biedt inmiddels het leeuwendeel van de Office-functionaliteit online. Anytime, any place, zonder installatie, zonder gedoe, mét goede backups en tal van sharingfeatures. Een schoolvoorbeeld van maximaal gebruikersgemak en functionaliteit, bereikbaar voor een maximaal groot publiek.

Dus

Op basis van de huidige bestaande voorbeelden, zou de sprong naar Oracle (Web)Forms (applet technologie) rechtsstreeks in de browser, ook niet moeilijk moeten zijn. Zonder concessies te doen aan de GUI. De praktijk tot nog toe bewijst jammergenoeg het tegendeel. De gemigreerde forms moeten toch zware concessies doen aan layout en dus gewenning voor de eindgebruiker.

SOA dan?

Service Oriented Architecture (SOA) is een geformaliseerde en gestandaardiseerde manier van Component Based Development. Oude wijn, CBD bestaat al een tijdje, in nieuwe zakken. Daarom overigens niet minder sterk. SOA heeft terecht veel terrein gewonnen. Maar het is complex.

Wijsheid in het geval van Forms migratie

Sinds het moment dat Oracle aankondigde dat Oracle Forms niet verder te ontwikkelen (Oracle Application Development Tools Statement of Direction, 2009), zijn bedrijven actief om alternatieven te bedenken. JHeadstart is al gevallen. VGO Software heeft ook een oplossing. Beiden maken gebruik van Java Server Faces-technologie. Een reactie vanuit de JEE-wereld op .NET Forms van Microsoft, uit de tijd dat page-oriented applicaties de norm waren. Dat was toen.

De huidige ontwikkelingen hebben laten zien dat het model van internetapplicaties zodanig is veranderd, dat applicaties in een browser hetzelfde gedrag kunnen vertonen als hun ¿native/ desktop¿-variant. Adobe (Flex), Google (WebTool Kit), Microsoft (SilverLight), Sun(JavaFX) laten zien dat het kan. Waarom die mogelijkheden links laten liggen?

Praktisch

Stel dat je Oracle Forms nu wil migreren, en je wil niet onderdoen in usablility. Voor welke technologie kies je dan op de presentatielaag? En - voor we het vergeten - hoe wordt SOA geïmplementeerd? Moeten alle Oracle Developers overgaan op Java ? Hoeveel tijd en geld gaat het kosten? Ben ik al mijn investeringen kwijt? Migreren blijft hoe dan ook een berg vragen oproepen.

Zonder voor eigen parochie te willen preken, zijn wij de mening toegedaan dat we met QAFE een effectief antwoord bieden op bovenstaande én andere vragen. Het is namelijk weldegelijk mogelijk om zowel richting Web2.0 te gaan, als om tegelijkertijd over te stappen op SOA. Let wel: Web2.0 in de zin van ¿het einde van F5¿, we hebben geen voorkeur voor GWT/Adobe/etc.

QAFE

QAFE is een nieuw framework, gemaakt door Java en Oracle Developers vóór Java en Oracle Developers. Als nieuwbouw-platform, maar - uiteindelijk het onderwerp van dit artikel - ook om migratie van Oracle Forms mogelijk te maken. Als gezegd: zonder concessies te doen op de layout en mét meer dan voldoende body voor SOA.

Voordelen

De voordelen zijn meerledig. De developer hoeft niet meer Java te leren, zijn kennis van SQL/PL-SQL is direct bruikbaar. Het enige wat de developer zou moeten beheersen is een basisstructuur van XML. Kinderspel. Specifieke presentatietechnologieën hoeven bovendien niet geleerd te worden. Vanuit QAFE een Javascript/ HTML gebaseerde applicatie opleveren? Geen punt! Tegelijkertijd een Adobe Flex-representatie van die applicatie? Ook geen punt!

Technologie-onafhankelijk

Door technologie-onafhankelijk applicaties te definiëren in QAFE, is het mogelijk om future-proof te werken. QAFE ondersteunt naast de huidige, ook de toekomstige GWT-versies en/of andere 2.0-platformen. De developer hoeft zich zodoende niet om de randvoorwaarden druk te maken. Hij kan direct aan de slag en - ongehinderd door de waan van de dag - blijven ontwikkelen in QAFE. Om nog sneller te ontwikkelen bieden we uiteraard tal van tools om de productiviteit aanzienlijk verder te verhogen. QAFE
Screenshot van een Form die via QAFE Forms technologieonafhankelijk is gemaakt en daardoor te presenteren is in Adobe Flex. Iets wat we niet kunnen laten zien, maar wel goed is om te weten, is dat de schermen data-aware zijn. Dat betekent dat CRUD, LOV's, Domain, navigate (next/ previous record) functioneren. Schematisch overzicht van processing.
Schematisch overzicht van processing. Met snippet van de QAML-code (code die in feite de out-put is van QAFE Forms Migratie) in het midden. Gevolgd door een screenshot van een gemigreerde Oracle Form in Google Webtoolkit output én Adobe Fex output. Oude Oracle Forms binnen één omgeving nog steeds beschikbaar
Zogeheten ¿big bang¿-implementaties zijn met QAFE niet nodig. Oude Oracle Forms zijn binnen één omgeving nog steeds beschikbaar.

Afgezien van de technologische voordelen biedt QAFE alle facetten die elke Enterprise Applicatie minstens moet hebben; en gaat het in ontwikkel, uitrol-, beheer- en gebruiksgemak nog een aantal stappen verder. Zowel in nieuwbouw, bij het bouwen van applicaties ¿from scratch¿, als bij specifiekere trajecten, zoals Oracle Forms migratie. De uitgangspunten bij het laatstgenoemde voorbeeld zijn het klassieke werken vanuit FMB of vanuit Designer. Voor Oracle Forms versies vanaf versie 6, zijn beiden mogelijk.

Conclusie?

Het doorhakken van meerdere knopen in één klap, is met QAFE een feit. En waar wij pretenderen dat QAFE a ¿dream come true¿ is voor ontwikkelaars, is de winst zo mogelijk nog groter voor de organisaties die ermee werken. QAFE sluit namelijk naadloos aan op álle traditionele systemen en databases, waardoor volledig investeringsbehoud een feit is. Dat geldt zowel voor hard- en software, als ook voor kennis, aangezien het platform uitgaat van bestaande programmeertalen.

Winst

Niet in de laatste plaats zijn het uiteindelijk de applicatiegebruikers waar het om gaat. Wie kiest er tenslotte nog voor om te werken met langzaam ladende schermen die voortdurend ververst moeten worden? Wij niet. Zij ook niet. En vele manjaren automatisering achter de schermen van QAFE durven te wedden: u heeft vast ook een hekel aan tijd verspillen.

NB

Het voert te ver om hier ook nog in te gaan op waarom QAFE meer is dan ‘just another framework met een RIA’, dus daarover graag een volgende keer meer. In We love IT, of op www.qafe.com of in een persoonlijk gesprek: 070 319 5000.

Lees meer over Qualogy
Ga terug naar We Love IT uitgave 2 - 2009
Advertentie