Persistensramverk mer än bara ett databasgränssnitt

Persistensramverk mer än bara ett databasgränssnitt Utvärdering av olika lösningar för ett databasgränssnitt med hjälp av ett persistensramverk A R V I D N I L S S O N Examensarbete Stockholm, Sverige 2006

Persistensramverk mer än bara ett databasgränssnitt Utvärdering av olika lösningar för ett databasgränssnitt med hjälp av ett persistensramverk A R V I D N I L S S O N Examensarbete i datalogi om 20 poäng vid Programmet för datateknik Kungliga Tekniska Högskolan år 2006 Handledare på CSC var Mikael Goldmann Examinator var Stefan Arnborg TRITA-CSC-E 2006:031 ISRN-KTH/CSC/E--06/031--SE ISSN-1653-5715 Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC 100 44 Stockholm URL: www.csc.kth.se

Persistensramverk Mer än bara ett databasgränssnitt Utvärdering av olika lösningar för ett databasgränssnitt med hjälp av ett persistensramverk. Sammanfattning Problem Ett återkommande problem vid framtagande av programvara som använder sig av data som måste lagras mellan användning, är utformningen av dess databasgränssnitt. Glappet mellan affärsutvecklarens objektorienterade tänkande och databasutvecklarens relationstänkande visar sig och orsakar snabbt problem, även kallat the impedance mismatch. Idag finns det flertalet olika sätt att bemöta problemet med databasgränssnitt. Den enklaste lösningen är att använda SQL-kod direkt i den objektorienterade applikationen, men för mer komplex mjukvara krävs ett mer avancerat gränssnitt som separerar databasen från applikationen, så att inte applikationen behövs skrivas om vid en ändring i databasstrukturen. En av de kraftfullare lösningarna på marknaden idag är persistensramverk, där SQL-koden genereras dynamiskt och kan bäddas in i en flerskiktsarkitekturlösning. Uppgift Examensarbetets uppgift bestod i att undersöka marknaden av persistensramverk och välja ut ett par kommersiella produkter för en djupare utvärdering. Utvärderingen skulle ge svar på om Sign On AB skulle välja att börja använda ett persistensramverk i deras applikation FormPipe. Om det skulle visa sig att slutsatsen av utvärderingen var att Sign On AB inte bör använda sig av ett persistensramverk, skall rekommendationer ges om hur Sign On AB skulle kunna vidareutveckla det egenutvecklade databasgränssnittet de använder idag. Ramverken TopLink samt Enterprise Java Beans valdes ut för att ligga till grund för byggandet av två prototyper för att underlätta en utvärdering. Prototyperna täckte upp två av de centrala områdena av FormPipe: mottagning av dokument samt hanteringen av de två aktörerna Användare och Kund med deras grupptillhörighet.

Slutsatser Varken TopLink eller Enterprise Java Beans medförde någon större positiv effekt för FormPipe. TopLink gav antingen ingen lösning på de i det befintliga databasgränssnittet identifierade problemen, eller så lyfte det upp problemen från databasgränssnittet till en objektorienterad nivå. Att införa Enterprise Java Beans skulle underlätta delar av utvecklingen mot FormPipes databas, men skulle innebära att större delar av koden i FormPipe måste skrivas om helt. Baserat på detta, rekommenderas Sign On AB att inte införa ett Persistensramverk i deras applikation FormPipe. Istället togs rekommendationer fram med regler och riktlinjer att använda vid en vidareutveckling av FormPipe. Dessa rekommendationer presenteras i slutet av denna rapport.

Persistensy framework More than just a database interface An evaluation of different solutions for database interfaces with the help of a persistency framework. Abstract Problem description A recurring problem in developing systems which use persistent data, i.e. data that must be saved between uses of the system, is how to define the database interface. The difference between the business developers object oriented thinking and the database developers relational thinking becomes apparent and quickly causes problems, also called the Impedance mismatch. Today there are many different ways of meeting these problems. The simplest solution for this problem is to use SQL-code inside the object oriented application, but for more complex software systems a more sophisticated interface is needed, to allow changes in the database structure without having to change parts of the rest of the application. One of the more powerful solutions on the market today is a Persistency framework, which generates SQL-code dynamically and is embedded in a multi-tier architecture. Task The assignment was to evaluate the market of Persistency frameworks and to choose a couple of commercial products for deeper evaluation. The evaluation should answer if Sign On AB should start to use a persistency framework in their application FormPipe. If the result of the evaluation would show that Sign On AB should not start to use a persistency framework, the assignment was to give some recommendations on what Sign On AB could do to improve their own developed database interface that they use today. The two frameworks TopLink and Enterprise Java Beans were choosen as bases for prototypes in the evaluation. The prototypes covered two central functionalities of FormPipe: receiving documents and the management of Users and Customers with their Group access. Conclusions Neither TopLink nor Enterprise Java Beans brought any real advantage for FormPipe. TopLink either didn t give any solution to the problems, or brought them up from the database interface to an object oriented level.

Using Enterprise Java Beans would make it easier to develop a better interface to the database of FormPipe, but it would also mean that a major part of FormPipe would have to be rewritten. Based on that, the recommendations for Sign On AB were not to implement a Persistency framework into their application FormPipe. Instead recommendations with rules and guidelines on how to improve the database interface were developed and they were presented at the end of this thesis.

Förord Detta är ett examensarbete i ämnet datalogi vid Nada, Kungliga Tekniska Högskolan. Handledare på Nada var Mikael Goldman och examinator var professor Stefan Arnborg. Examensarbetet utfördes på uppdrag av Sign On AB och handledarepå uppdragsgivarens sida var Henrik Olsson. Först vill jag tacka min mor, far och bror som givit mig stöd under arbetets gång. Jag vill även tacka min vän och studiekamrat Martina Gustavsson som i två omgångar korrekturläst rapporten och kommit med förslag på förbättringar. Sedan examensarbetet genomfördes och att denna rapport avslutats, har persistensravmerket TopLink bytt ägare från WebGain, Inc. till Oracle. Information om TopLink finns i skrivande stund (2005-08-25) på webbsidan: http://www.oracle.com/technology/products/ias/toplink/index.html

Innehållsförteckning 1 Inledning... 1 1.1 Bakgrund... 1 1.2 Sign On AB... 2 1.3 Problembeskrivning... 2 1.4 Uppgiftslydelse... 2 1.5 Syfte... 3 1.6 Begränsningar... 3 1.7 Utförande... 4 1.8 Resultat... 4 2 Relations kontra Objektorienterat tänkande... 6 2.1 Relationstänkande... 6 2.2 Objektorienterat tänkande...9 2.3 Impedance mismatch... 11 3 Traditionella databaslager... 13 3.1 Mappa Attribut... 13 3.2 Mappa Arv... 13 3.3 Mappa Relationer... 16 4 Flerskiktsarkitektur... 18 4.1 Klient/Server-arkitektur...18 4.2 Treskiktslager... 20 5 Persistensramverk... 22 5.1 Vad är ett persistensramverk... 22 5.2 14 krav på persistensramverk... 24 6 Java 2 Enterprise Edition... 27 6.1 Programspråket Java... 27 6.2 Java Naming and Directory Interface (JNDI)... 27 6.3 Java Transaction API & Java Transaction Service... 28 6.4 Java Database Connectivity... 28 6.5 Java Server Pages... 28 6.6 Enterprise Java Beans 1.1 tekniska data... 28 6.7 Enterprise Java Beans 2.0 skillnader från 1.1... 36 7 FormPipe... 38 7.1 FormPipe Notariatserver... 38 8 Utförande... 41 8.1 Sign On ABs syn på Amblers persistensramverk... 41 8.2 Identifierade befintliga problem... 43 8.3 Urvalsprocess persistensramverk - Övergripande... 45 8.4 Urvalsprocess persistensramverk första urvalet... 45 8.5 Urvalsprocess persistensramverk Andra urvalet... 48 8.6 Prototyp - Generellt... 49 8.7 Prototyp Frågeställningar... 50 9 Prototyp byggd med persistensramverket Toplink... 51 9.1 Byggandet... 51 9.2 Löser TopLink problemen i FormPipe?... 52

9.3 Identifierade problem med TopLink... 54 9.4 Allmän analys... 54 9.5 Slutsats... 56 10 Prototyp byggd med EJB...57 10.1 Byggandet... 57 10.2 Löser EJB problemen i FormPipe?... 57 10.3 Identifierade problem med EJB... 59 10.4 Allmän analys CMP - BMP... 60 10.5 Slutsats... 60 11 Resultat... 61 11.1 Resultatet i stort... 61 11.2 Jämförelsetabell... 62 12 Slutsats... 63 12.1 TopLink och EJB... 63 12.2 Bygga eget... 63 13 Rekommendation... 64 13.1 Identifierade problem Lösningar... 64 Källförteckning... 67

1 Inledning Denna examensrapport är indelad i två delar, den börjar med en sammanfattande del följt av en mer ingående beskrivande del. Inledningen är tänkt att ge en kort övergripande bild över bakgrunden, genomförandet och resultatet av examensarbetet. Den därefter följande delen innehåller en beskrivning av tekniker som används och senare beskrivs genomförande, resultat och slutsatser mer ingående. 1.1 Bakgrund I dagens applikationer blir lagring av information allt viktigare. Lagrad information förekommer i applikationer i allt ifrån ett enkelt digitalt CD arkiv till avancerade system som ett stort E-handelsföretags webbshop. Krav på prestanda, tillförlitlighet, förmåga att lätt kunna anpassas till nya krav, m.m. blir allt högre, men även t.ex. att kunna dela upp system i moduler för att underlätta för utveckling och underhåll av systemen, gör att nya krav på metoder för programmering för hanteringen av persistenta 1 objekt ställs. I dag används främst flerskiktsarkitekturer 2 vid utvecklandet av webbaserade system. Flerskiktsarkitekturer är ett försök till att dela upp ett system i moduler som interagerar med varandra, men trotts detta måste moduler idag överträda varandras gränser. Detta innebär problem vid utvecklandet men framförallt vid underhåll av system byggda med de konventionella utvecklingsmetoderna. Olika tekniker för att underlätta utvecklingen utav system som använder sig av persistent data har därför tagits fram, Objektorienterade databaser (OODB), Enterprise Java Beans 3 (EJB) och persistensramverk är några i raden som tagits fram för att lösa hanteringen utav persistenta objekt. OODB är ett sätt att lösa lagringen utav persistent data på ett rent objektorienterat sätt, medan EJB är ett sätt där lagringen av persistenta data försöks lösas genom att bygga ett objektorienterat gränssnitt för hanteringen av persistent data, men där även flertalet andra problem försöks lösas utöver hanteringen av lagringen av persistent data. Ett rent persistensramverk däremot blir som ett eget skikt i en flerskiktsarkitektur som sammanlänkar den del av systemet som hanterar persistent data, s.k. databaslagret med den delen av systemet som bearbetar data, s.k. affärslagret och erbjuder ett helt objektorienterat gränssnitt mot persistent data. Dessa tekniker har alla sina för och nackdelar och vilket alternativ 1 Persistens betyder beständig eller lagrande. Begreppet Persistens förklaras mer ingående längre fram i rapporten. 2 Flerskiktsarkitektur beskrivs mer ingående i kapitel 4. I rapporten blandas skikt och lager, då de båda används som termer i litteratur. 3 Enterprise Java Beans beskrivs mer i kapitel 6 1

som passar bäst vid utvecklingen av ett system beror till stor del på ett systems storlek och tänkta framtid. 1.2 Sign On AB Sign On AB grundades 1991 och är ett företag som idag har sitt kontor i Mörby, strax norr om Stockholm och har cirka 65 anställda. Sign On AB har sedan 1995 arbetat med lösningar för Internet. Deras affärsområden består dels av skapande och underhåll av elektroniska blanketter genom tjänsten Sign On Blankettarkivet och dels av ett system för att hantera elektroniska blanketter och signaturer via Internet i form av deras egenutvecklade produkt FormPipe. 1.2.1 FormPipe FormPipe är byggt enligt en klient/server-arkitektur. FormPipe består av en klientdel som ligger på användarnas datorer (Denna del av FormPipe kommer inte tas upp i denna rapport) och en serverdel (Notariatserver) som tar emot filer, dekrypterar data, tidstämplar samt verifierar signaturer och certifikat. Denna Notariatserver behandlar inkomna data, sparar undan en originalhandling och kan även skicka data vidare till ett verksamhetssystem hos en mottagare om så önskas. Exempelvis skulle användaren kunna vara en person som fyller i en deklarationsblankett. Denna blankett skickas sedan in via Internet till mottagaren, d.v.s. skatteverket och deras Notariatserver, som efter att ha behandlat blanketten, för informationen vidare in i deras verksamhetssystem. (Olsson, 2001a) 1.3 Problembeskrivning I det befintliga databasgränssnittet som används av FormPipes Notariatserver idag finns inte några enhetliga regler eller riktlinjer för hur relationer 4 skall hanteras. Det är t.ex. inte självklart i vilken typ (klass) som en en-till-många relation hamnar. Inte heller åtkomsten av objekt från databasen sker på ett enhetligt sett. Detta innebär att utbyggnad och underhåll av systemet försvåras. En annan försvårande faktor är att SQL-koden 5 idag ligger hårdkodad i de klasser som representerar de typer som finns i systemet idag. Detta innebär att vid tillägg av nya typer behövs delar av kod för hantering av annat persistent data skrivas om. 1.4 Uppgiftslydelse Uppgiften bestod i att utreda vilka problem som fanns i det befintliga FormPipe-systemet idag, samt se hur ett ramverk för hanteringen utav persistent data skulle kunna byggas upp med olika tekniker för att se om de passar de krav som Sign On AB har på systemet. Detta skulle t.ex. kunna göras med hjälp av EJB eller flertalet persistensramverk som finns på 4 Databasterm, beskrivs mer i kapitel 3.3. 5 SQL Språk som används för hantering av persistent data i relationsdatabaser. 2

marknaden idag, men även aspekten att bygga ett eget ramverk beaktades. Uppgiften gick också ut på att bygga ett par prototyper av en delmängd av FormPipe för att kunna jämföra teknikerna med varandra, samt att lokalisera problem och svårigheter med de olika teknikerna och se hur de skulle kunna lösa de befintliga problemen i FormPipe idag. Problem med ramverken beskrivs senare i rapporten och ett försök till att även ta fram allmänna riktlinjer gjordes. Uppgiften bestod också i att sammanställa resultatet och tillsammans med ett förslag till val av teknik för hur hanteringen av persistent data bör utformas i en examensrapport. 1.5 Syfte Sign On ville ha utrett vilka problem som fanns i det befintliga systemet med avseende på hantering av persistent data, samt hur olika tekniker för hantering av persistent data står sig mot varandra och hur dessa skulle passa att användas vid en vidareutveckling utav FormPipe. Det Sign On AB ville göra var att försöka få en enhetlig hantering av olika relationer m.m. i FormPipe. En annan önskan var att undersöka om det skulle kunna gå att frikoppla databasaccessen från typerna, allra helst på ett generiskt sätt så att man kan addera nytt persistent data till en typ utan att behöva programmera om andra delar utav systemet. 1.6 Begränsningar Först och främst behandlas frågorna om hur hanteringen av persistenta objekt samt hur frikopplingen av databasaccessen från typerna kan utformas. Ett eget persistensramverk var inte aktuellt att bygga då det var ett för stort projekt för detta examensarbete. Sign On AB håller också på att utreda om det är möjligt att distribuera systemet. Ett sätt att lösa detta är att skilja på databaslagret och affärslagret i den flerskiktsarkitektur som används i FormPipe och lägga dem på olika servrar, för att på så sätt möjliggöra en lösning där lasterna kan spridas på ett bättre sätt. Detta tas i beaktning i detta examensarbete, men ingick inte som krav från Sign On AB. Därför tas distributionen endast upp i mindre omfattning och diskuteras enbart vid de olika lösningsförslagen, då den bara berör ramverket indirekt vid exempelvis en EJB-lösning. Objektorienterade databaser tas inte heller i beaktning i denna rapport då Sign On AB i dagsläget anser att de bör satsa på tekniker som deras kunder redan använder och därför enbart beakta de tekniker som bygger på relationsdatabaser. 3

1.7 Utförande Initialt genomfördes en snabb utredning av olika tekniker för hantering av persistenta objekt. Då bestämdes att en satsning på ett rent persistensramverk samt EJB skulle utvärderas och ställas mot det befintliga systemet. Dessutom genomfördes en undersökning för att få en överblick över de befintliga problemen med avseende på hanteringen utav persistenta objekt i FormPipe-systemet. Dessa problem sammanställdes och definierades till i 7 punkter. När problemen i det befintliga systemet definierats gjordes ett urval av de olika teknikerna, baserat främst på information från de olika tillverkarna. Ett 15-tal rena persistensramverk utvärderades i två steg, och från andra urvalet som stod mellan 4 olika persistensramverk valdes Toplink 6 ut för att senare utvärderas och jämföras mot EJB och det befintliga FormPipe-systemet. Utvärderingen gjordes genom att prototyper av en delmängd av FormPipe-systemet byggdes. Den del som bäst representerade de identifierade problemen med det befintliga FormPipe-systemet användes som grund för de prototyper som byggdes. Dessa prototyper utvärderades sedan och jämfördes på de definierade befintliga problempunkterna och ett förslag till rekommendationer togs fram. 1.8 Resultat Prototyperna visade att en övergång till att använda ett rent persistensramverk eller EJB i FormPipe inte kommer att innebära några större förbättringar, utan istället kommer att införa nya problem. Toplink erbjöd en enkel utvecklingsmiljö och frikopplade databasaccessen från typerna på ett önskvärt sätt, men erbjöd på de andra punkterna inga större förbättringar. EJB frikopplade databasaccessen från typerna även det på ett önskvärt sätt och erbjöd också lösningar på ett par av problempunkterna i det befintliga systemet. En annan fördel med en övergång till EJB är att det kan göras i två steg. Dock medförde EJB ett par större problem i hur viss funktionalitet i FormPipe-systemet skulle implementeras samt att en större del av systemet måste byggas om vid ett införande av EJB än vid ett persistensramverk. FormPipe är ett för litet system för att det skall dra full nytta av Toplinks alla egenskaper då det riktar sig främst till större system med många olika persistenta objekt. Värt att notera dock är att hur TopLink skulle påverka prestanda inte har tagits upp i denna rapport och därmed inte heller värderats i detta resultat. EJB är ett alternativ som skulle underlätta utvecklingen av hanteringen utav persistenta objekt, men det också innebär 6 TopLink är ett persistensramverk som utvecklas av WebGain, Inc. www.webgain.com 4

ett stort steg att ta, och är därför heller inte aktuellt i nuläget. Att istället bygga om det redan befintliga ramverket och ta fram riktlinjer för hur de skulle kunna få bukt med problemen verkar vara det alternativ att föredra för Sign On AB. Därför avslutas den nu kommande och mer beskrivande delen utav denna rapport med ett antal regler och riktlinjer för att Sign On AB i fortsättningen skall kunna undvika de i denna rapport identifierade problem som finns i FormPipe idag i avseende på hanteringen utav persistenta objekt. 5

2 Relations kontra Objektorienterat tänkande Relations- och Objektorienterat tänkande är två olika sätt att för människan lättare kunna illustrera och förklara olika hanterande av data och databehandling. 2.1 Relationstänkande Relationstänkandet introducerades i början av 70-talet av E. F. Codd (Elmasri, Navathe, 1994). Det bygger på att information kan lagras i form av relationer. Dessa relationer lagras som tabeller i en databas. Det är bara information som lagras i databasen, med andra ord skiljs information ut från funktionalitet. Dock går det numera att till viss del bygga in även funktionalitet i databasen med hjälp av s.k. stored procedures och triggers 7. 2.1.1 Tabeller En databas består av tabeller som representerar olika relationstyper. Dessa tabeller består i sin tur av rader och kolumner. Kolumnerna står för värden på en egenskap hos en relation, och raderna representerar en specifik relation. Ta t.ex. en relation Person, den skapas då som en tabell Person. Tabellen kan ha kolumnerna Personnummer och Namn, som representerar olika egenskaper som finns hos Person-relationen. Dessa kolumner är statiska och bestäms av ett fixt databasschema. 2.1.2 Tupler Rader (i relationsteorin kallade tupler) i Person-tabellen innehåller värden i de olika kolumnerna och representerar den information som lagras i databasen. Ordningen på raderna är ingen informationskälla i sig, men tuplerna ordnas med fördel på lämpligt vis för att passa olika sökstrategier. 2.1.3 Primärnyckel En tabells primärnyckel är en minimal delmängd av dess kolumner som kan användas för att unikt identifiera en tupel. Det kan finnas flera delmängder som kan identifiera unika tupler, dessa kallas för surrogatnycklar. Primärnycklar kan användas för att representera relationer mellan två tabeller, t.ex. mellan tabellerna Person som har en Adress eller mellan samma tabell, t.ex. relationen mellan personerna far och son. Till exempel som Figur 2-1 visar, skulle Person-tabell kunna innehålla kolumner med namnen personnummer, adress_id, far m m. Där kolumnen personnummer är tabellens primärnyckel och kolumnen adress_id innehåller Adress-tabellens primärnyckel. Då är det lätt kan koppla ihop personen med dess adress från Adress-tabellen. Kolumnen far skulle då kunna innehålla personnumret till personens far. På så sätt fås en koppling mellan 7 För en mer ingående beskrivning av stored procedures och triggers se 4.1.2. 6

son och far, men också mellan far och son, då det är lätt att titta igenom alla tupler och se om det finns någon som har faderns personnummer i far-kolumnen. Figur 2-1 Figuren beskriver hur tabeller kan kopplas ihop med hjälp av primärnycklar 2.1.4 Relationsdatabas På detta vis kan en informationsstruktur byggas upp i form av relationer i en s.k. relationsdatabas (RDB). I en sådan struktur behövs det ibland att normalisera tabellerna, d.v.s. strukturera dem så att redundans och anomalitet kan undvikas. Vid försök att få bort redundans skapas ofta nya tabeller med den redundanta informationen, så att den samlas på ett ställe. Detta medför i allmänhet att databasens komplexitet ökar ju mer den normaliseras. Det finns 6 stycken olika grader av normalisering, och det som normalt rekommenderas är tredje normalform (3NF). En allt för hög normalisering kan innebära prestandaförluster då det ofta innebär att det krävs många tidskrävande operationer för att läsa upp information (join-operationer). (McClure, 1997) 7

Person Person_id Namn Adress Postnummer Postadress 12 Bertil Svensson Avsidesgatan 23678 Malmö 13 Sven Nilsson Hemvägen 67890 Stockholm 15 Svea Karlsson Långabacken 12345 Göteborg 12 Bertil Svenson Bortaplan 34567 Malmö 15 Svea Karlsson Hemvägen 67890 Stockholm Tabell 2-1 Tabellen visar en onormaliserad enkel tabell Exempel på en normaliseringsåtgärd; En person kan knytas till mer än en adress, t.ex. hemadress, jobbadress mm. Det kan även vara flera personer knutna till en adress, de kan t.ex. bo ihop, eller jobba på samma jobb. I en onormaliserad databas kan tabellen se ut som i Tabell 2-1. Där ser vi att en person finns med flera gånger då personen är knuten till flera adresser. Person_Ny Person_id Namn 12 Bertil Svensson 13 Sven Nilsson 15 Svea Karlsson Person_Adress_Ny Person_ID Adress_ID 12 1 12 4 13 2 15 3 15 2 Adress_Ny Adress_ID Adress Postnummer Postadress 1 Avsidesgatan 23678 Malmö 2 Hemvägen 67890 Stockholm 3 Långabacken 12345 Göteborg 4 Bortaplan 34567 Malmö Tabell 2-2 Visar hur en enkel förändring av en tabell i en relationsdatabas kan göras till tre för att förenkla databasstrukturen och minska ner redundanser m.m. En normaliseringsåtgärd kan vara att lägga adresser i en egen tabell med en associationstabell 8 som sammanbinder dem som Tabell 2-2 visar. 8 Beskrivs mer ingående i kapitel 3.3.1 8

För att komma åt data från en relationsdatabas har ett frågespråk tagits fram, Structured Query Language (SQL). SQL är ett mängdbaserat språk. Eftersom strukturerade programmeringsspråk såsom C och Pascal inte är mängdbaserade, har det också tagits fram något som heter markör (cursor) för att underlätta mängdhanteringen. En markör används för att kunna stega igenom en mängd av data som returneras av en SQL-fråga en tupel i taget. Språket Java har dock egna klasser för att klara av konverteringen mellan mängdbaserade frågespråket SQL och Objektorienterade språket Java. I Javas fall behövs Java Database Connectivity (JDBC) för att komma åt data i en relationsdatabas. JDBC är ett standardiserat gränssnitt mot relationsdatabaser och är databasoberoende. 2.2 Objektorienterat tänkande Objektorienterat tänkande introducerades till stora delar när programmeringsspråket Simula67 (simple universal language) lanserades under slutet av 1960-talet av Ole Johan Dahl och Kristen Nygaard (Sklenar J, 1997). Senare har även språk som Smalltalk, C++ och Java byggts på objektorienterande tänkande. Objektmodellen bygger på att världen modelleras i form av objekt som har attribut och funktionalitet. T.ex. en TV: den har en storlek och det går att växla mellan kanaler som den skall visa. TV:n i sin tur kan bestå av mindre objekt som kanalväljare och bildrör som har egna attribut och egen funktionalitet. Objektorienterat tänkande påminner mer om normalt tänkande än relationstänkandet, vilket gör det lättare att skapa modeller utav applikationer för att kunna förklara för beställaren, som ofta inte behöver vara teknisk kunnig, så att denne förstår. En annan fördel är också att en applikation lättare kan delas upp i moduler. Därmed kan gränssnitt specificeras upp mellan olika delar av applikationen. Moduler som då lätt kan bytas ut utan att behöva skriva om hela applikationen. 2.2.1 Objekt Ett objekt är alltså en abstraktion för begreppen identifierare, funktionalitet och attribut. För att kunna skilja på olika objekt är en objektidentifierare (OID) knuten till varje objekt. Funktionalitet realiseras som metoder hos objekten, och attribut representerar ett objekts tillstånd. Ett objekt är av en speciell typ, en klass. Ur programmerarens synvinkel har en klass ett namn, attribut och metoder. Med metoderna kan ett objekts attribut ändras och därmed dess tillstånd. På så sätt kapslas ett objekts funktionalitet in och programmeraren som använder sig av objektet behöver inte bekymra sig för hur detta är implementerat, utan kan använda sig av objektet som en black box, s.k. inkapsling. Med objektorienterad programmering kommer också vissa begrepp som 9

förenklar tänkandet, såsom arv, polymorphism och dynamisk bindning. Dessa förklaras nedan: Arv: I objektorientering försöker man samla klasser som har samma egenskaper och funktionalitet och ordna upp dem i en arvsstruktur. T.ex. en bil och båt har en hel del egenskaper gemensamt, dessa kan samlas i begreppet fordon. Fordon blir en superklass till bil- och båtklasserna som i sig kallas subklasser till Fordonsklassen. Arv beskrivs ofta som is-a-relation (är-en-relation) i modelleringar. I vissa programmeringsspråk kan även multipla arv förekomma, d.v.s. en klass ärver från mer än en klass 9 (Se Figur 2-2). Figur 2-2 Figuren visar en enkel arvsstruktur Polymorphism: Ett objekt som ärver från en annan klass kan utöka superklassen med funktionalitet. Detta gör att när ett objekt refererar till ett annat objekt, vet man inte om det refererar direkt till objektklassen, eller till en av dess subklasser, då subklasserna per definition också är superklassen. Dynamisk bindning: Klasser som ärver av en annan klass kan även skriva över dess metoder, för att få en annan funktionalitet än superklassens. De kan ha metoder med samma namn, inparametrar och returnera samma typ. Detta gör att det inte heller här går att avgöra vilken metod som skall bindas vid anropet förrän det utförs vid exekvering (runtime). 9 Programmeringsspråket Java stödjer inte multipelt arv. 10

2.2.2 Identifiering av objekt Objekt har ett OID kopplat till sig som nämndes i förra stycket. Detta är något som är helt skilt från objektet i sig, vilket gör att det finns två sätt att säga om två objekt i själva verket är samma objekt, klonat 10 eller skilda objekt. Det ena sättet är att jämföra objekts OID med varandra, då får man ett svar på om objekten är samma eller skilda, men objekten kan fortfarande hålla samma information, t.ex. vara klonade. Det finns alltså en likhet på informationsnivå och en på OID-nivå. Vid distribuering av system kan fler problem uppstå. Där kan objekt ligga i olika adressrymder och då ha olika OID-generatorer m.m., men detta kommer inte tas upp vidare i denna rapport. 2.2.3 Relationer mellan objekt Klasser som anropar varandra på något sätt anses ha en relation mellan sig. Det finns två saker som utmärker relationer mellan klasser. Det ena är typen av relation, association eller aggregat. Där aggregat är en striktare variant av association. Det andra är att relationen alltid har en riktning. Den är antingen enkel- eller dubbelriktad. Dessa förklaras nedan: Association - är grundrelationen mellan två klasser. Det är en lös koppling mellan klasser som anropar varandra. Exempel är Flygplats och Flygplan. En Flygplats behöver inte ha några Flygplan på sig Aggregat - är en starkare relation där den ena klassen är en del av den andra. Ett tydligt exempel är klasserna Flygplan och Vinge. Ett flygplan måste ha en vinge för att existera Enkelriktad relation - existerar när en klass har en association mellan sig och en annan klass, där den ena antingen anropar den andra klassen eller vice versa. Exempelvis kan en Pilot informera en Passagerare (via ett högtalarsystem), medan en Passagerare inte kan tala med en Pilot. Dubbelriktad relation - existerar när en klass har en association mellan sig och en annan klass, där båda anropar varandra. Exempelvis kan en Flygvärdinna servera en Passagerare mat och en Passagerare kan fråga en Flygvärdinna om en Filt. 2.3 Impedance mismatch Relationsmodellen är baserat på att spara data, medan objektmodellen är tänkt att användas för att bygga applikationer av objekt som hanterar både data och funktionalitet. The impedance mismatch visar sig när man ser till hur man använder relationsdata i de olika modellerna. I relationsmodellen låter man tabellerna innehålla redundant information i form av främmande nycklar (Foreign keys) för att kunna använda operationen join att binda ihop relationer, medan man i objektmodellen 10 Ett klonat objekt är exakt lika ett annat objekt, men inte samma objekt. Ibland även kallat kopierat objekt (Sun Microsystems, 2001). 11

traverserar objekt direkt via deras relationer (Ambler, 2000a). Detta gör att när man försöker föra ihop dessa två tekniker så stöter man på vissa problem. 2.3.1 Likheter och skillnader Likheter mellan relationsmodellen och objektmodellen är att: modellerna bygger på en liknande struktur, tabeller förhåller sig till tupler som klasser förhåller sig till objekt tupler innehåller atomära data likt objekt har attribut det finns relationer mellan tupler och relationer mellan objekt Det finns alltså stora drag som liknar varandra mellan de två modellerna, men också skillnader. Dessa skillnader är att: objektmodellen hanterar både data och funktionalitet, medan relationsmodellen bara hanterar data vid arv i objektmodellen ärvs även funktionalitet 11 ett objekt kan förändras att representera något annat under exekvering (runtime), detta är inte möjligt i en relationsmodell i en objektorienterad modell, såsom UML 12, modelleras relationer med en riktning i relationsmodellen är data unikt genom primärnyckelrestriktioner, men så fort data läses upp till ett objekt förloras denna unikhet och risk för inkonsistens uppstår, man kan säga att primärnyckel på databasnivå garanterar datas unikhet, medan OID inte gör det 11 Arv kan beskrivas i en extended entity relationship modell (EER-modell) för relationsmodellen (Elmasri, Navathe 1994) 12 Unified Moddeling Language (Fowler, Scott 1997) 12

3 Traditionella databaslager Kapitlet beskriver hur traditionella databaslager hanteras och byggs upp. 3.1 Mappa Attribut Som föregående kapitel påvisar finns det en likhet mellan relations- och objektmodellen vilket gör att man lätt kan mappa en klass till en tabell, där tabellnamnet blir samma som klassnamnet och attributens namn hos objektet blir kolumner i tabellen. Ett problem är dock om attributet är av en datatyp som inte det finns stöd för i databasen, då en konvertering av datatypen måste göras. Används en OID för objekten kan denna med fördel bli primära nyckeln för tabellen (Johnson m.fl. 1998). I annat fall kan andra attribut utgöra primärnyckel i tabellen. Dessa bör i dessa fall väljas med omsorg (Elmasri, Navathe 1994). 3.2 Mappa Arv En arvsstruktur kan mappas på tre olika sätt mot databasen: en tabell för hela hierarkin, en tabell för varje konkret klass och en tabell för varje klass. Figur 3-1 Figuren visar en enkel arvsstruktur 13

3.2.1 En tabell för hela hierarkin (Metod I) Detta är det enklaste sättet att mappa en arvsstruktur. Man skapar en tabell med alla attribut som finns i rotklassen och alla dess subklasser (Se Figur 3-1) Fördelarna är att: ad-hoc-frågor lätt kan skrivas det är snabbt, då inga join-operationer måste utföras för att hämta data ur hierarkin viss polymorphism stöds då en tupel kan representera flera saker Nackdelarna är att: tabellen kommer att innehålla många kolumner som inte används beroende på vilken klass i arvshierarkin tupeln representerar och kan därför vara utrymmeskrävande om man använder sig av OID, så måste de vara unika inom hela hierarkin, för att bevara unikheten mellan tupler samla många klasser till samma tabell kommer troligen att göra att mycket av databastrafiken kommer att anropa denna, vilket kan bli en flaskhals om t.ex. databasen implementerar page level locking (Keller, 1997) 3.2.2 En tabell för varje konkret klass (Metod II) Som Figur 3-1 visar blir det i detta fall tre klasser, där subklassernas tabeller även innehåller superklassens attribut. Fördelarna är att: ad-hoc-frågor är relativt lätta att skriva det är snabbt, då inga join-operationer måste utföras för att hämta data ur hierarkin det inte blir några tomma kolumner i någon tabell och utnyttjar inget onödigt minnesutrymme access av ett objekt låser endast en tabell, (jfr nackdelar under kapitel 3.2.3) Nackdelarna är att: man kan inte representera polymorphism lika lätt som i fallet ovan, om ett objekts roll ändras måste tupeln tas bort från ena tabellen och läggas till i den andra, och om objektet har flera roller ingår tupeln i flera klasser och detta gör att behålla dataintegriteten blir därmed svårare om databasstrukturen ändras kan det beröra många tabeller om ändringen ligger högt upp i arvshierarkin då alla subklassers tabeller måste ändras 14

polymorphiska frågor mot databasen blir komplexa då om man söker efter alla som tillhör en klass, måste man traversera igenom dels dess tabell, men även alla subklassers tabeller, vilket i större arvsstrukturer kan påverka prestandan avsevärt 3.2.3 En tabell för varje klass (Metod III) I detta fall gör man på samma sätt som föregående kapitel visar, skillnaden är bara att subklasserna inte innehåller annat än de attribut som de tillför i arvshierarkin. I denna variant har man löst kopplingen mellan ärvande klasser genom att använda en övergripande OID som är samma i alla klasser i hierarkin, och knyter på så sätt ihop ärvda attribut. (Keller, 1997) Fördelarna är att: det inte blir några tomma kolumner i någon tabell och utnyttjar inget onödigt minnesutrymme, mer än den övergripande OID:en det är det mest flexibla sättet att mappa arvsstrukturer, dock påverkar det prestandan negativt, se nackdelar nedan Nackdelarna är att: den är prestandakrävande då vid läsning av data ett antal join-operationer på tabeller måste utföras, beroende på djup i arvshierarkin. Dock är lösningen väldigt flexibel, se fördelar ovan vid transaktioner som uppdaterar en tabell som representerar en klass långt ner i arvshierarkin så måste alla superklassers tabeller också låsas, och problem uppstår vid höga belastningar och orsakar därmed sämre prestanda ad-hoc-frågor är svåra att skriva 3.2.4 Jämförelsetabell Metoderna för att mappa arvshierarkier medför alla både för och nackdelar som måste avvägas mot varandra beroende på hur de skall används. Kriteria Metod I II III Ad-hoc-frågor Lätt Lätt Svårt Lägga till ta bort attribut Svårt Mycket svårt Lätt Ändra ett objekts roll i DB Lätt Svårt Svårt Tillåta multipla roller Lätt Mycket svårt Svårt Antal tabeller som behövs Få Medium Många Nullvärden (platskrävande) Ja Nej Nej Tabell 3-1 Tabellen visar en jämförelse mellan 3 metoder för att mappa arvshierarkier i relationstänkande 15

3.3 Mappa Relationer Ovan klassades relationer på två sätt, typ av relation och riktning (Se kap 2.2.3). Ur mappningssynpunkt är det mer intressant att titta på relationerna i form av ett-till-ett, ett-till-många eller många-till-många förhållanden. Det finns i huvudsak tre olika sätt att mappa relationer till databas, dessa är associationstabell, främmande nycklar och inbäddade klasser. 3.3.1 Associationstabell (Metod I) Detta är det mest flexibla sättet att mappa relationer mellan objekt på databasnivå. Man skapar en tabell som innehåller de primära nycklarna av de två tabeller man vill skapa en relation emellan. Dock är denna också relativt långsam då den kräver två join-operationer vid hämtande av relationsdata. Detta alternativ innebär att en tredje gemensam klass måste skapas vid objektorienterat tänkande, en s.k. hjälpklass. 3.3.2 Främmande nycklar (Metod II) Detta är ett snabbare alternativ än associationstabell, då det inte krävs några join-operationer. Nackdelen är att den inte klarar av många-till-många-relationer. Man inför kolumner för främmande nyckeln från den ena tabellen i den andra. T.ex. relationen ägs av mellan objekten Bilägare och Bil. En Bil kan endast ägas av en Bilägare, men en Bilägare kan ha flera Bilar. Denna relation kan man representera i databasen genom att i Bil-tabellen skapa en kolumn med Bilägar-tabellens primärnyckel. 3.3.3 Inbäddade klasser (Metod III) Inbäddade klasser innebär att två klasser mappas till samma tabell. Det blir snabbt då det inte kräver några join-operationer. Nackdelen är att inte heller denna metod klarar av många-till-många-relationer. Även ett-till-många-relationer måste begränsas, till ett i förväg bestämt antal. Begränsningen leder också till dåligt minnesutnyttjande. Ett exempel kan vara relationen mellan Person och Adress, där man t.ex. vill lägga relationerna bostadsadress och sommarstugeadress i Person-tabellen, vilket då förutsätter att man bara har en bostadsadress och en sommarstugeadress. Detta tar också upp onödig plats för dem som inte har någon sommarstuga. 16

3.3.4 Jämförelsetabell Metoderna för att mappa relationer är olika snabba beroende på vilken relation som skall mappas. Nedan följer en tabell som jämför tidsåtgången. Relation Metod I II III Ett-till-ett Långsam Snabb Mycket snabb Ett-till-många Långsam Mycket snabb Mycket snabb men begränsad Många-till-många Ja Nej Nej Tabell 3-2 Tabellen visar en jämförelse av relationers snabbhet i olika objektorienterade metoder för mappning av relationer. I fallet många till många visas bara att endast metod I kan användas. 17

4 Flerskiktsarkitektur Kapitlet beskriver övergripande tankarna bakom flerskiktsarkitektur. Stycket är baserat på Roger Jennings Database Workshop Microsoft Transaction Server 2.0 (Gray m.fl., 1997). 4.1 Klient/Server-arkitektur I en klient/server-arkitektur används oftast en tvåskiktslösning. En tvåskiktslösning där klienten utgör ena lagret och som talar direkt med servern, som utgör det andra lagret. Affärslogiken kan antingen ligga på klient eller serversidan. I Figur 4-1 nedan ligger den i klientlagret. Figur 4-1 Figuren beskriver en tvåskiktslösning 4.1.1 Roll: Klient Klientens primära uppgift är att handhålla ett gränssnitt till användaren, vilket via de kan anropa servern. Servern kan då svara på anropet med data som klienten sedan kan visa upp för användaren. Denna typ av kommunikation mellan datorer är vanligt i de flesta nätverksprotokoll. Till exempel används det vid surfning på Internet. Då skickas en förfrågan från din webbläsare (klient) till en webbserver (server) som i sin tur returnerar sidan du vill se (data) tillbaks till webbläsaren som då presenterar den för dig (Se Figur 4-2). 18

Figur 4-2 En Klient- Serverarkitektur Klienten tillhandahåller inte bara ett användargränssnitt utan ofta även kontroller av indata från användaren samt affärslogik, men även trådning och hantering av databasförbindelser. Det innebär att komplexiteten hos en tvåskiktad lösning lätt växer och klientens ansvar blir större och större, när omfattningen och komplexiteten ökar. 4.1.2 Roll: Server En server svarar på klientanrop. En server kan behöva besvara flera anrop samtidigt och utnyttja ett flertal resurser för att tillhandahålla data. Server-baserade resurser kan vara databaser, webbsidor, m.m. Databasservrar hanterar klientförbindelser och anrop. Databasservrar kan även hantera resurser för säkerhet, transaktionhantering samt backup av data. Databasservrar kan även innehålla delar av affärslogik genom att använda stored procedures och triggers. Stored procedures är SQL-frågor som kan ta inparametrar och därmed kan de ses som enkla funktioner på databasnivå (Se Figur 4-3). En trigger är en typ av stored procedure som kan konfigureras att utförs vid en speciell händelse 19

Figur 4-3 Mer komplex Klient- Serverarkitektur där delar av affärslogiken ligger på serversidan 4.2 Treskiktslager Komplexiteten hos tvåskiktslösningar har ofta visat sig bli för stor. Därför har treskiktslösningar utvecklats. I en tvåskiktslösning hanterar klienten alltid datarepresentationen och servern hanterar databassystemet. Problemet med en tvåskiktslösning är att affärslagret måste implementeras i antingen klient eller serverlagret. Låter man servern implementera affärslogiken kan den lätt bli överbelastad, då den måste dels förse klienterna med data, dels utföra beräkningar i affärslogiken genom stored procedures. Låter man däremot klienten implementera affärslogiken växer klientapplikationen och blir lätt oöverskådlig och komplex. En treskiktslösning separerar ut affärslogiken från både databasen och presentationen (Se Figur 4-4). 20

Figur 4-4 Bilden beskriver en treskiktsarkitektur Treskiktslösningar blir större än vanliga tvåskiktslösningar då det blir två gränssnitt istället för ett mellan lagren. En fördel med att utveckla ett flerskiktssystem är att affärslogiksprogrammeraren kan fokusera på just affärslogiken och behöver inte tänka på databaslogiken. Dock innebär treskiktlösningar att man i förväg måste definiera upp båda gränssnitten mellan de tre lagren innan man kan skriva affärslogiken. 21

5 Persistensramverk På grund av att Objekt-Relationsproblematiken, även kallad Impedance mismatch, som uppstår vid all objektorienterad applikationsutveckling som använder sig av en relationsdatabas, har en idé om ett generellt tänkande för hur man skall kunna lösa denna problematik tagits fram. Denna idé har resulterat i ett ramverk för hantering av persistent data. Detta kapitel beskriver vad ett persistensramverk används till. Längre fram i rapporten beskrivs flera kommersiella produkter inom området persistensramverk (Se kapitel 8.3). 5.1 Vad är ett persistensramverk Vid utveckling av programvara som har en koppling till en databas behöver man integrera databasen med affärslogiken på ett smidigt sätt. Scott W Ambler beskriver tre olika sätt att integrera en databas (Ambler, 2000b). Ett naivt sätt är att använda en tvåskiktslösning som bild Figur 5-1 visar, att implementera persistensen, d.v.s. SQL-koden i relationsdatabasfallet, direkt i de affärslogiska klasserna. Detta är ett enkelt sätt att programmera och lämpar sig bra för prototyper. Man bygger in databasstrukturen i koden och en ändring av databasstrukturen kommer därför att påverka stora delar av koden som då måste skrivas om. Figur 5-1 En applikation utan ett separerat databaslager (visualiseringslagret syns inte i figuren) Ett annat sätt att implementera kopplingen mot databasen är att använda en treskiktlösning som i Figur 5-2. Där har man istället separerat ut databasaccessen och skapat ett gränssnitt som kapslar in dessa delar av affärslogiken. Detta är ett vanligt tillvägagångssätt vid utveckling av applikationer med upp till runt 50 affärslogikklasser. Man har inga generella riktlinjer och det blir svårt att hålla systemet konsekvent. Ändringar i databasschemat påverkar bara databaslagret, men kan ändå innebära större förändringar inom detsamma. Det är väldigt lätt att 22

affärslagret och databaslagret växer ihop, då affärslagret och den persistenta koden oftast hamnar i samma klass. Även problemet med att persistent kod för en klass även kan hamna i andra klasser blir ett problem i detta fall. Ta t.ex. ett scenario med en användare och dennes dokument. Det är lätt att inse i vilken klass koden för att hämta upp ett specifikt dokument eller användare från databasen bör läggas, men om systemet behöver komma åt ett dokument för en viss användare, skall koden (SQLsatserna) för att hämta upp dokumentet då ligga i användar- eller dokumentklassen? Läggs koden i dokumentklassen slipper man problemet med att få koden i flera klasser, men istället fås fler metodanrop som kan påverka prestanda i systemet. Figur 5-2 En applikation med ett separerat databaslager (visualiseringslagret syns inte i figuren) Det tredje sättet som Ambler rekommenderar för större och robustare system är att använda sig av ett persistensramverk, som helt kopplar bort persistensen från affärslogikens objekt (Se Figur 5-3). Med ett persistensramverk kan man ändra i databasschemat utan att det påverkar de affärslogiska klasserna nämnvärt och utvecklaren av affärslogiken behöver inte känna till databasens uppbyggnad, eller ens att objekten är persistenta, utan använda dem som vilka objekt som helst. Detta ger en lättare utveckling av affärslogiken, större system blir mindre komplexa att bygga och man får specificerade regler och en bättre struktur. Nackdelen med detta angreppssätt är att ett persistensramverk kan komma att påverka prestandan negativt, om än i bästa fall marginellt. 23

Figur 5-3 En applikation med ett persistensramverk (visualiseringslagret syns inte i figuren) 5.2 14 krav på persistensramverk Scott W. Ambler har definierat och beskrivit 14 krav på ett persistensramverk och vad det bör klara av för att överbygga relations kontra objektrelationsproblematiken. Dessa utgör en grund för detta arbete, då det sammanfattar begreppet persistensramverk på ett bra sätt. Nedan följer en beskrivning av de 14 punkterna, dessa punkter är inte alla viktiga för Sign On AB. Detta diskuteras i kapitlet 8.1. 5.2.1 Olika typer av persistens Ett persistensramverk skall vara byggt att klara av flera olika tekniker för persistens. De skall utan förändringar i logiken i lagret ovanför klara av tekniker såsom: spara på fil, relationsdatabaser, objektorienterade databaser, eller någon annan teknik man vill använda för persistens. 5.2.2 Total inkapsling av persistensen Det ideala är att gömma undan all kod för persistens för de objekt som skall vara persistenta, så de blir så rena som möjligt. Detta förenklar för programmeraren som skall använda sig av det persistenta objektet. Helst skall det bara finnas tre meddelanden man skickar till objekten, spara, hämta och ta bort, resten skall persistensramverket ta hand om. 5.2.3 Multipla hämtningar av objekt Att hämta fler objekt på samma gång är effektivt då man vill ta fram rapporter m.m. och bör därför stödjas av ett persistensramverk. Även att ta bort multipla objekt på samma gång är något som ett persistensramverk skall klara av. 5.2.4 Transaktioner Att utföra transaktioner mot databasen innebär att man kan göra flera operationer mot databasen på ett atomärt sätt, det vill säga allt eller inget. Antingen lyckas alla operationer, eller så rullas de tillbaka (Roll back) och lämnar data som det var innan transaktionen ägde rum. 24

5.2.5 Utbyggbart Man skall kunna lägga till nya persistenta objekt till applikationen på ett enkelt sätt utan att behöva skriva om persistensramverket, d.v.s. det måste vara flexibelt för ändringar av vad som skall lagras. 5.2.6 OID - Unik identifierare för objekt Unika objektidentifierare gör att hanteringen av objekt förenklas ur databassynpunkt. Detta kan också betyda prestandaskillnader, då t.ex. vissa databaser är optimerade för att använda stora tal som identifierare och inte strängar (Ambler, 2000a). Dock bör man enligt Ambler inte använda något affärsrelaterat som nyckel, då databasen till stor del använder sig av dessa nycklar och det gör att det blir svårare att ändra om det nyckeln bygger på ändras. T.ex. att ha namn på en Person som OID, och sen komma på att namn bör delas upp i för- och efternamn är inte så lyckat. 5.2.7 Markör Vid listningar av objekt i databasen kan det vara dumt att hämta upp alla objekt på en gång. Man kanske bara behöver titta på de tio första för att hitta det man söker. Då görs en massa onödigt arbete. En markör håller reda på vilka objekt man har kvar att visa och på så vis kan man hämta upp t.ex. 50 i taget och vinner på så sätt i prestanda vid hämtning av många objekt. 5.2.8 Proxy En proxy, i databassammanhang, är ett objekt som representerar ett annat objekt, men som bara innehåller det som behövs för att identifiera det andra objektet. Resterande delar av objektet hämtas endast om det skulle behövas. Detta gör att databasaccessen blir i de fall där objektet bara behöver identifieras blir snabbare, då mindre information hämtas upp och det leder i dessa fall till bättre prestanda. 5.2.9 Poster Många rapporteringssystem som finns idag använder sig av databasposter och ett persistensramverk skall därför kunna ge sådana poster på begäran. 5.2.10 Klara av flera arkitekturer Persistensramverket skall inte låsa sig vid en arkitektur, utan vara flexibelt så det kan anpassas t.ex. till en klient/server-arkitektur, flerskiktslösning eller ett distribuerat system. 25