ApEx MashUp’s

Eén van de onderdelen van het Web2.0 gedachtegoed is MashUp’s. Maar wat zijn dat nou eigenlijk? En wat heb je eraan? En als je er een zou willen, kun je zoiets realiseren met Oracle Application Express? Op deze vragen willen we graag in dit artikel een antwoord geven. Want naar ons idee is het nuttig, maar vooral ook leuk en lang niet zo ingewikkeld als je misschien denkt.

Web 2.0 en MashUp’s

Onder Web2.0 worden over het algemeen webapplicaties verstaan die aanzetten tot sociale interactie of uit collectieve bijdragen bestaan. Ook betreft het vaak programmeertechnieken die een veelzijdige en gebruikersvriendelijke interface mogelijk maken zoals AJAX. MashUp’s voldoen perfect aan deze eigenschappen. Een MashUp is niets anders dan het combineren van verschillende gegevens, die onderling een relatie hebben, maar uit verschillende bronnen komen. Door deze data te koppelen en de combinatie in een specifieke presentatievorm weer te geven ontstaat er voor de gebruiker een duidelijke meerwaarde en rijkere beleving van de informatie.

Een mooi voorbeeld is onderstaand plaatje:

Figuur 1

Informatie van de politie van Chicago over ‘Violent Crimes’ is gecombineerd met een plattegrond van de stad met daarin alle wijken weergegeven. Voor mensen die willen verhuizen naar Chicago zal het plaatje veel meer informatie geven dan de politiedatabase met alle gegevens.

Verzekeraars kunnen met behulp van het plaatje snel en eenduidig de risicopremies voor nieuwe verzekeringen bepalen. Op het moment dat beide bronnen (de politiedatabase en de kaartinformatie) realtime beschikbaar zijn en via Internet kunnen worden ontsloten, heb je altijd een actuele weergave beschikbaar.

Business value

De meeste MashUp’s maken gebruik van publieke content en zijn zelf ook publiekelijk beschikbaar. Maar er zijn ook Enterprise MashUp’s, die bronnen van binnen de eigen organisatie gebruiken. Enterprise MashUp’s hebben een aantal voordelen ten opzichte van publieke MashUp’s en zijn daarom het overwegen meer dan waard. Wat te denken van customer service medewerkers die, terwijl ze een klant te woord staan over de eigen producten en diensten, realtime informatie beschikbaar hebben over vergelijkbare diensten van de concurrent, binnen de eigen applicatie, op hetzelfde scherm? Zo zijn er tal van situaties te bedenken waarbij een MashUp zorgt voor een verrijking of verbetering van de beschikbare data, zodat medewerkers hun werk efficiënter of beter kunnen uitvoeren.

Hoe werkt dit nu in Oracle Application Express?

Uitgangspunt bij de volgende twee scenario’s is de voorbeeld-applicatie van Oracle Application Express (ApEx). Dit is een webapplicatie voor een (web-)winkel en die de mogelijkheid biedt om klant- en productinformatie te onderhouden, en de gemaakte bestellingen te bekijken.

Scenario 1: Een server-side MashUp

We willen de productinformatie van onze applicatie uitbreiden met data van derden. Nu bieden verschillende organisaties een Application Programming Interface (API) aan voor het gebruik van hun data en/of functionaliteit. Amazon.com is zo’n organisatie. Door de eigen productinformatie uit te breiden met de data van Amazon.com, hebben de gebruikers extra informatie ter beschikking om de eigen productinformatie bij te werken of eventueel de prijs scherper te stellen.

Figuur 2

ApEx biedt vanuit het framework de mogelijkheid om server-side webservices te consumeren. In de shared components kan met het aanmaken van een webservice reference de functionaliteit die Amazon biedt beschikbaar worden gemaakt in de applicatie. In de webservice reference dienen een aantal zaken te worden gespecificeerd:

endpoint / url
SOAP request bericht
Naam van de Collection waar het SOAP response in wordt opgeslagen.

In dit scenario wordt gebruik gemaakt van twee webservices van Amazon, namelijk ItemSearch, voor het opzoeken van betreffend product in de Amazon catalogus en ItemLookup, om uitgebreide informatie over dit product op te vragen.

Figuur 3

In het SOAP request bericht worden de parameters met #APPLICATION_ITEMS# gedefinieerd. Hierop is 1 uitzondering, namelijk #AMAZON_KEY#, dit betreft een unieke sleutelwaarde die na registratie bij Amazon wordt verschaft. Deze is als Application Substitutie Value gedefinieerd. Voor aanroep van de item search operatie is het volgende SOAP request bericht opgesteld.

Hiermee wordt gespecificeerd dat van het gezochte product (<Keywords>) uit alle categorieën (<SearchIndex>) 1 zoekresultaat (<Count>) wordt teruggeven met een gemiddelde gedetailleerdheid aan informatie (<ResponseGroup>).

Aangezien deze ItemSearch niet alle benodigde informatie over het gezochte product oplevert, wordt een tweede webservice reference, ItemLookup, aangemaakt. Met deze webservice wordt gedetailleerde productinformatie inclusief de productreviews opgevraagd. Deze operatie werkt middels een door Amazon bepaalde ItemId, die door de ItemSearch operatie kan worden bepaald. In het SOAP request wordt ook deze parameter met gelijknamige application item gedefinieerd.

Om vervolgens gebruik te maken van deze webservice reference dient de pagina waar de productinformatie wordt getoond (in de demo-applicatie pagina 6), te worden uitgebreid met de volgende componenten:

Computation van de Application_items die in het SOAP request worden meegestuurd
Process voor aanroepen van de WebServices
een Region voor het tonen van betreffende informatie Met de computations worden de parameters voor de webservice aanroepen bepaald, zo wordt bijvoorbeeld het application item item_name afgeleid van het page-item P6_PRODUCT_NAME

Figuur 4

Vervolgens moet een page-process worden aangemaakt om gebruik te maken van de webservice reference. Een page-process kan op verschillende momenten van rendering van pagina worden gestart. Aangezien er gebruik wordt gemaakt van een waarde van een item op de pagina moet de aanroep van de webservice te gebeuren na het proces dat de waarden van de page-items bepaald, het default fetch row page-process. Op deze wijze wordt de product detailpagina uitgebreid met het bepalen van de Application items en de aanroep van de gedefinieerde webservice operaties. Bij de webservice reference is aangegeven hoe het response bericht wordt opgeslagen, namelijk in een collection. Een collection is een mechanisme waar tijdelijk informatie per gebruiker wordt bijgehouden. Het is dus gekoppeld aan de session state informatie. Deze informatie kan met een SQL-query worden opgevraagd voor bijvoorbeeld het maken van een Report. Hier wordt dus gebruik van gemaakt om de gewenste gegevens op het scherm weer te geven. Omdat het repsonsebericht als XML wordt opgeslagen in deze collection, gebruiken we de XML-functie extractValue om een waarde uit het bericht te lezen.

Met toevoeging van een SQL-report region met gegeven SQL-query als basis wordt naast de al beschikbare informatie over het betreffend product nu ook de extra informatie van Amazon op het scherm weergegeven. Op soortgelijke wijze kan, uiteraard afhankelijk van de informatie uit het responsebericht van de webservice operaties, relevante informatie aan de gebruiker getoond worden. Het geheel komt er dan zo uit te zien:

Figuur 5

Scenario 2: Een client-side MashUp

Een andere optie is een client-side MashUp. Hierbij wordt aanvullende informatie door de client opgevraagd en in dit scenario ook asynchroon. We willen de beschikbare klantinformatie in de applicatie uitbreiden met locatiegegevens door middel van Google Maps. Voor het toevoegen van Google Maps wordt een javascript API beschikbaar gesteld. In dit voorbeeld wordt de kaart-functionaliteit gebruikt in combinatie met de in de demo-applicatie geregistreerde klantinformatie. Dit gebeurt geheel client-side, middels javascript . Op de betreffende pagina (pagina 7 in de demo-applicatie) wordt een (leeg) html-region toegevoegd. Deze wordt voorzien van een custom regionId, gMapsDiv om vanuit de javascript naar dit gebied op de pagina te verwijzen.

Vervolgens dient de specifieke javascript code voor het gebruik van Google Maps aan de pagina te worden toegevoegd. Allereerst wordt de javascript API toegevoegd, met een include van <script type="text/javascript" src="http://www.google.com/jsapi?key=#GOOGLE_KEY#"></script>

Ook in dit voorbeeld wordt gebruik gemaakt van een specifieke key die als applicatie substitutie value (#GOOGLE_KEY#) is gedefinieerd.

Vervolgens zijn in dit voorbeeld twee custom functies geschreven, namelijk Initialize and ShowAddress. Met de Initialize functie wordt de Maps functionaliteit als het ware opgestart. Vervolgens kan met de functie ShowAddress het betreffende adres, dat eerst naar geografische coördinaten wordt vertaald, op de kaart weergegeven. De koppeling met de bestaande klantinformatie gebeurt met aanroep van deze functie, die in de region footer als volgt is geïmplementeerd:

Het resultaat ziet er dan als volgt uit:

Figuur 6

Conclusies en kanttekeningen

Het realiseren van MashUp’s met behulp van Oracle Application Express is zonder meer mogelijk. Bovenstaande scenario’s laten bovendien zien dat het niet eens zo gek ingewikkeld is. Toch zijn er ook kanttekeningen. Zo moet er goed worden nagedacht over de inrichting. Denk vooral aan zaken als beschikbaarheid, integriteit en vertrouwelijkheid. Deze zijn ook wel bekend als de BIV-triade en beschrijven de drie aspecten van informatiebeveiliging. Wanneer een aanleverende partij de gewenste content (tijdelijk) niet meer kan leveren door een wijziging in de API, een verandering in de structuur van de content of de bron zelf bestaat niet meer dan valt het hele idee van de mashup dus weg. Maak daarom op voorhand afspraken met de leverancier van de data. Dit is sowieso aan te raden want het is hun content en wellicht zijn ze er niet van gediend dat de informatie op deze manier wordt gebruikt. Waarmee we op het volgende aspect uit komen: vertrouwelijkheid.

Wordt de MashUp client-side samengesteld, dan zal de gebruiker tot alle bronnen toegang moeten hebben. Het kan server-side, door de server bijvoorbeeld als proxy te gebruiken. Maar dan moet de server wel de credentials weten van de gebruiker op de diverse bronnen. Het makkelijkst zou zijn om voor de server dan accounts aan te maken, maar dan is het risico dat een gebruiker informatie voor zich krijgt die niet voor hem bestemd is, als deze laag niet goed is afgeschermd. Wie mag wat met welke informatie en in welke stap van het proces zal dus moeten worden meegenomen in de oplossing. En dan de integriteit. De huidige browsers hebben een beveilingsmaatregel in zich die de Same Origin Policy (SOP) wordt genoemd. Dit houdt in dat documenten binnen de browser met elkaar kunnen interacteren zolang ze van dezelfde bron komen, dat wil zeggen dat de host, de port en het protocol hetzelfde moet zijn.

De uitzondering hierop zijn de resources die worden geladen als extensie voor een pagina, zoals scripts of images. Door het includen van externe content wordt de SOP omzeild en kan deze externe content dus delen van de pagina uitlezen of aanpassen. Maar ook de cookies kunnen worden uit gelezen waardoor autorisatiegevens kunnen worden ontvreemd. Daarom moet de externe input altijd worden wantrouwt, er wordt immers een trustboundary overschreden. Vulnerabilities als Cross Site Request Forgery (CSRF) en Cross Site Scripting (XSS) kunnen, door dit in het achterhoofd te houden, makkelijk voorkomen worden. Dit zal echter wel invloed hebben op de functionaliteit. In de volgende versie van html zullen tags als <Sandbox> en de Verifiable-Origin Policy (VOP) het al een stuk makkelijker maken om zowel security als functionaliteit te bieden.

Over de auteurs

Simon Boorsma is Oracle-specialist en presentator van “ApEx & MashUp’s” op Oracle Open World 2008
Marinus Kuivenhoven is Oracle- en Security-specialist
Sander Bosma is Unitmanager Oracle.

Allen zijn werkbaar bij Sogeti Nederland B.V.

Lees meer over Sogeti Nederland B.V.

Ga terug naar We Love IT uitgave 5 - 2008

Advertentie