De endelige klasser som de er implementeret, er de samme som er illustreret på ICE-modellen og klasse-diagrammet. Herunder er en mere forklarende beskrivelse af hvordan systemet fungerer.
Hovedklassen er MAOVAdapter, og det er den der er selve interfacet til Portal-to-Go. Alle forespørgelser går gennem dette objekt. MAOVAdapteren gør dog ikke noget ved dem, andet end at distribuere dem videre til de klasser der kan tage sig af dem.
MAOVAdapteren implemenenterer en oracle.panama.adapter.Adapter, så Portal-to-Go kan genkende og bruge den som Adapter. MAOVAdapteren skal derfor implementere følgende fire metoder:
Det er denne metode Portal-to-Go kalder hver gang brugeren beder om en ny side. Den får en "oracle.panama.ServiceRequest" med som argument, og ud fra den udledes hvilken side der er ønsket. Det gøres ved at hente parametrene ud. MAOV-systemet har to grundlæggende parametre: ACTION og SUBACTION. ACTION definerer hvilken klasse der skal tage sig af forspørgselen. Hver klasse har dog forskellige opgaver så SUBACTION fortæller hvilken underopgave det er, klassen skal tage sig af. MAOVAdapteren kigger ikke selv på SUBACTION.
De klasser der får requestene fra MAOVAdapteren er defineret som kontrol-objekter på ICE-modellen. De opfører sig nogenlunde ens, så derfor vil de her blive beskrevet generelt.
De har hver en invoke-metode som MAOVAdapteren kalder. I den undersøges SUBACTION og den dertil hørende metode kaldes. I den opbygges den side der skal præsenteres som XML, med hjælpeklassen "oracle.panama.PAPrimitive". Det færdige XML-dokument returneres til MAOVAdapteren som igen returneres til Portal-to-Go, der endeligt sørger for at siden vises korrekt.
Et menupunkt på en side vil altid være et link til den samme MAOVAdapter, men med forskellige parametre, som så præciserer hvilken side der denne gang ønskes. Der vil typisk være tilføjet flere parametre end ACTION og SUBACTION. Således vil eksempelvis kunde-id også være sat på som en parameter.
De sider der genereres indeholder typisk oplysninger hentet fra Oracles databaser. Hele tilgangen til databaserne er dog adskilt fra den XML-genererende del af systemet, og gemt væk i entitets-objekterne, som de er illustreret på ICE-modellen. Alle disse entitets-objekter er generelt ens ligesom kontrol-objekterne, så de vil også blive beskrevet generelt her.
Entitets-objekterne henter selv deres relevante oplysinger fra databasen når de oprettes. Det sker altså i constructor'en. De deler alle et objekt af klassen DBAccess, der hjælper med at udføre SQL-forespørgsler. Alle data bliver derefter gemt i instans-variabler, som kan tilgås med get-metoder. På den måde er database-tilgangen gemt af vejen, og når først entitets-objektet er oprettet, er der hurtig adgang til alle data'ene.
Når der er mange data i et entitets-objekt gemmes de i array's, da det er den mest direkte måde at gemme data på. Men array's har fast størrelse, og de ResultSet vi får ud af databasen har ukendt størrelse. Derfor tømmes ResultSet'et først ud i en Vector, og udfra Vector'ens længde oprettes arrays'ene og data flyttes fra Vectoren til arrays'ene. Det kan virke omstændigt, men det er smartere end at spørge databasen med "SELECT COUNT(*) FROM ..." om antallet af tupler.
Det er ikke alle oplysninger der kan hentes frem under oprettelsen af entitets-objekterne. Derfor har nogle af dem yderligere metoder der henter oplysninger ud over det der blev hentet i constructoren. I de tilfælde hvor der skal gemmes data i databaserne, er selve database-håndteringen også lagt i entitets-objekterne.
Dette burde give et overblik over systemet. Der er mere detaljerede oplysninger om klasserne og metoderne i javadoc'en (vedlagt på CD).