Postadress: Besöksadress: Telefon:
Box 1026 Gjuterigatan 5 036-10 10 00 (vx)
PL/SQL till Java – Konvertering med verktyg
PL/SQL to Java – Conversion with tools
Fredrik Sköld Martini
Philip Axell
EXAMENSARBETE 2011
DATATEKNIK
Detta examensarbete är utfört vid Tekniska Högskolan i Jönköping inom ämnesområdet Datateknik. Arbetet är ett led i den treåriga
högskoleingenjörsutbildningen.
Författarna svarar själva för framförda åsikter, slutsatser och resultat. Examinator: Inger Palmgren
Abstract
This report is about an assignment gotten from the company Logica as a final thesis at the Computer Engineering education at Jönköping University. The assignment was supposed to investigate whether it is possible to convert a system written in the
programming language PL/SQL to Java. The application in question was a sales ledger. The aim of the project was to make it possible for the company to at a low cost in time and money migrate the existing system. Some of the questions are examining whether it is possible to do this with the help of conversion tools and if so, are there any “Best-practices”. We have investigated this through seeking information about different conversion tools and the different programming languages.
To verify the functionality of the different tools we ran a number of different tests with actual conversion. These tests have shown that a conversion between PL/SQL and Java can work, however under strict standardized forms.
The system we have been assigned to do not fall under these forms and it lost all of its functionality under the process of conversion in one case and the result code was close to useless. We came to the conclusion that a conversion with tools was not profitable in this case.
Sammanfattning
Den här rapporten hanterar ett uppdrag från företaget Logica gjort som ett examensarbete på utbildningen Högskoleingenjör inom Datateknik, programmet Webbutveckling/Programmering och datanät, på Tekniska Högskolan i Jönköping. Uppdraget gick ut på att kontrollera om ett system skrivet i programmeringsspråket PL/SQL går att konvertera till Java. Programmet i fråga var ett reskontrasystem. Syftet med projektet var att företaget skulle kunna konvertera deras system på ett så kostnadseffektivt och tidsbesparande sätt som möjligt. Frågor som rapporten har tagit upp är huruvida det finns konverteringsverktyg som kan göra detta och om i så fall det finns några “Best-practises” angående detta. Vi har undersökt detta genom
informationssökning om olika verktyg samt om de båda språken. För att verifiera de olika verktygens funktionalitet har ett antal olika tester med konvertering utförts. De tester som har genomförts visar på att en konvertering mellan PL/SQL och Java kan fungera, men då under standardiserade former. Till denna kategori hörde dock inte Logicas applikation, som förlorade all sin funktionalitet under processen i ett av testen och genereringen av användbar kod var minimal. Vi kom fram till att i det här fallet var en konvertering ej möjlig att rättfärdiga i ett kostnadsperspektiv.
Nyckelord
Konvertering Undersökning PL/SQL Java Databas Applikations ServerInnehållsförteckning
1
Inledning ... 6
1.1 PROBLEMBESKRIVNING ... 6
1.2 SYFTE MED PROJEKT ... 6
1.3 FRÅGESTÄLLNINGAR ... 7 1.4 AVGRÄNSNINGAR ... 7 1.5 METOD ... 7 1.6 DISPOSITION ... 8
2
Teoretisk bakgrund ... 9
2.1 SPRÅKTYPER ... 9 2.1.1 Procedurbaserade Språk ... 9 2.1.2 Objektorienterade språk ... 9 2.2 DATABAS ... 11 2.2.1 SQL ... 11 2.2.2 Exempel på SQL-query ... 12 2.2.3 Oracle Database ... 12 2.2.4 PL/SQL ... 132.2.5 Oracle Application Server... 14
2.3 JAVA ... 15
2.3.1 Historia ... 15
2.3.2 Grunderna ... 15
2.3.3 Java Runtime Environment (JRE) ... 16
2.3.4 Servlets ... 16 2.3.5 Tomcat ... 17 2.4 KONVERTERINGSVERKTYG ... 17 2.4.1 SwisSQL ... 19 2.4.2 sqlWays ... 20 2.4.3 Orindabuild ... 20
2.4.4 Exodus - PL/SQL to Java conversion tool ... 20
2.4.5 Utvärdering av konverteringsverktyg ... 21
3
Genomförande ... 22
3.1 TEORETISK FÖRSTUDIE ... 22 3.1.1 Informationssökning ... 22 3.2 PRAKTISKT FÖRBEREDANDE ... 23 3.2.1 Installation av testmiljö ... 233.2.2 Redigering av existerande kod... 25
3.2.3 Konstruering av testprojekt ... 25
3.3 KONVERTERINGSVERKTYG ... 26
3.3.1 SwisSQL - Oracle to Java ... 27
3.3.2 Exodus - PL/SQL to Java conversion tool ... 28
4
Resultat ... 29
4.1 SWISSQL-ORACLE TO JAVA ... 29
4.1.1 SwisSQL beslutar att lägga ner Oracle to Java-verktyget ... 30
4.2 EXODUS -PL/SQL TO JAVA CONVERSION TOOL ... 30
5
Diskussion och slutsatser ... 31
5.1 RESULTATDISKUSSION ... 31
6
Referenser ... 33
7
Bilagor ... 35
Figurförteckning
FIGUR 1 - ENKELT EXEMPEL PÅ PL/SQL-KOD 9
FIGUR 2 - ENKEL JAVA-KOD MED TVÅ KLASSER 10
FIGUR 3 - EXEMPEL PÅ HUR TABELLER I EN DATABAS KAN VARA RELATERADE. 11
FIGUR 4 - EXEMPEL PÅ EN SQL-QUERY 12
FIGUR 5 - ÖVERBLICK AV EN ORACLE DATABAS VISAD I SQLDEVELOPER 13
FIGUR 6 - ÖVERBLICK AV PL/SQL PLACERAD I OLIKA PAKET I EN
ORACLE-DATABAS, SAMT VISS KOD. 14
FIGUR 7 - FIGUR ÖVER ORACLE APPLICATION SERVER KOPPLING TILL
DATABASEN 15
FIGUR 8 - ENKEL FÖRKLARING TILL HUR EN SERVLET FUNGERAR MOT DATABAS 16
FIGUR 9 - EN APPLIKATIONSSERVER FÖR JAVA UPPKOPPLAD MOT DATABAS 17
FIGUR 10 - FIGUR ÖVER VAD KONVERTERINGSVERKTYGEN SKALL KLARA AV. 18
FIGUR 11 - TABELL ÖVER KONVERTERINGSVERKTYG OCH DESS TILLVERKARE 18
FIGUR 12 - EN SCREENSHOT ÖVER HUR SWISSQL SER UT [15] 19
FIGUR 13 - EN SCREENSHOT PÅ CIPHERSOFTS EXODUS UNDER ANVÄNDNING
[20] 20
FIGUR 14 - ÖVERBLICK AV TESTMILJÖN, MED APPLIKATIONER. 24
FIGUR 15 - INLOGGNINGSVY I VÅRT TESTPROJEKT I JAVA. 25
FIGUR 16 - PROJEKTLEDARVISNING I VÅRT TESTPROJEKT I JAVA 26
FIGUR 17 - BILD FRÅN SWISSQLS HEMSIDA FÖR DERAS ORACLE TO JAVA TOOL.
1 Inledning
Det här examensarbetet är gjort som slutlig uppgift på utbildningen Högskoleingenjör inom Datateknik, programmet Webbutveckling/Programmering och datanät, på Tekniska Högskolan i Jönköping. Examensarbetets uppgift har varit ett undersöka huruvida det är möjligt och om det är ekonomiskt fördelaktigt att med hjälp av olika verktyg konvertera koden i ett existerande system skrivet i programmeringsspråket PL/SQL och göra om funktionaliteten till att istället vara skriven i Java.
Under utbildningens gång har vi läst omfattande kurser i objektorienterad
programmering, så som C# och C++. Vi har även läst kurser i databashantering och SQL, projektledning och webbdesign. Alla dessa har hjälpt oss att genomföra projektet. Då vi inte tidigare har haft någon djupare kunskap om varken konvertering, PL/SQL eller JAVA var vi tvungna att skaffa oss detta på egen hand.
Uppdragsgivaren är Logica Sverige AB, under kontoret i Jönköping.
Logica är ett IT-tjänstföretag som erbjuder verksamhetsinriktade konsulttjänster, systemintegration och outsourcing till kunderna. De har ca 39000 anställda, varav 5200 finns i Sverige. [1]
1.1 Problembeskrivning
Logica har hos flera stora kunder ett reskontrasystem vid namn EKO, som använder en Oracle-databas för lagring av bland annat information. De funktioner som systemet har är konstruerade med hjälp av PL/SQL som fungerar som ett logiskt
programmeringsspråk, med procedurerna och funktionerna lagrade direkt i databasen. PL/SQLen ligger i olika så kallade paket i databasen och man kan sedan kalla på dessa i webbläsaren om man har installerat och konfigurerat en applikationsserver med
webbserver-funktionalitet. Det grafiska gränssnittet är sedan genererat med hjälp av webbservern i HTML-kod, systemet använder även Java-script och CSS-mallar för presentationen.
Logica har planer på att konvertera systemet till Java för att slippa använda Oracle som databas och applikationsserver, då dess licenser är dyra och man vill kunna leverera ett billigare och mer flexibelt system åt kunderna.
De vill komma ifrån att lagra funktionaliteten i databasen och kan då istället med Java hämta information från i stort sett valfri databas och presentera den. Detta skulle kunna möjliggöra för kunden att i princip bestämma själv vilka produkter denne vill ha och kan
Vi har koncentrerat oss på de delar av det existerande systemet som är mest
fundamentala och de där det är störst chans att det uppstår problem. Tanken var att det skall gå åt så lite tid som möjligt till att faktiskt skriva Java-kod och istället i så stor utsträckning som möjligt använda de olika konverteringsverktyg som existerar för konvertering mellan PL/SQL och Java. Då dessa verktyg stödjer olika funktioner och datatyper sinsemellan har vi även sett över vilket som faktiskt passar bäst till just det här fallet.
1.3 Frågeställningar
En del frågeställningar har påverkat projektets utgång, en av de viktigaste var vilka verktyg finns det för konvertering mellan PL/SQL och Java och vilka passar in på just det här systemet.
En annan fråga var huruvida vilket konverteringsverktyg var bäst i aspekterna: Hur mycket funktionalitet som försvinner vid konverteringen.
Vilket som kräver minst för och efterarbete. Hur kostnadseffektivt verktyget är.
Ännu en frågeställning har varit huruvida liknande projekt har utförts tidigare och hur deras utfall blivit, vilka metoder som använts och vad som anses vara “Best-practices” i just konverteringen från PL/SQL till Java.
1.4 Avgränsningar
Uppgiften innefattar att hitta olika “Best-practices” angående konvertering i större utsträckning än att utforska själva vilka vägar som är enklast att gå.
Vi har tillsammans med företaget valt två delar av systemet, där en av dem behandlar inloggning och den andra en av de olika formulärsidorna, projektledarredigeringen. Vi valde dessa då de anses innehålla en stor del av den funktionalitet som återfinns även i andra delar av systemet och eventuella problem som skulle kunna dyka upp kommer förmodligen att visa sig här.
1.5 Metod
För att lyckas med det här projektet har vi sökt en stor del information om olika tekniker, programmeringsspråk och verktyg. De programmeringsspråk som projektet vidrört hade vi inte någon tidigare erfarenhet av och vi behövde därför söka kunskapen på egen hand genom att hitta lämplig litteratur samt även praktisera ett antal mindre
programmeringsprojekt.
För att hitta den information vi behöver har vi till största del användt relevant litteratur och gjort informationssökning på internet via sökmotorer så som exempelvis Google. En stor del av informationen har vi även funnit med hjälp av Jönköping Högskolas
biblioteksdatabas, där böcker och artiklar rörande ämnet finns.
Vi har även haft regelbunden kontakt med Logica för att stämma av olika steg i projektets gång och vi har då även tagit hjälp av dem om det funnits hinder eller funderingar.
1.6 Disposition
Den här rapporten följer Tekniska högskolan i Jönköpings mall för examensarbeten och dess kapitel finns beskrivna nedan.
I teoretisk bakgrund tar rapporten upp en del av den teori och uttryck som läsaren kan behöva för att förstå och följa med i resterande delar av rapporten, vi förklarar även hur olika verktyg och applikationer fungerar.
I Genomförande tar vi upp hur projektet genomfördes och vad som gjordes för att komma fram till resultatet, vilka val vi gjort och varför.
Resultatkapitlet tar upp det resultat som uppnåddes i projektet, även de eventuella problem som upptäcktes på vägen. Under kapitlet Diskussion och Slutsatser tar vi upp diskussion angående det resultat projektet har gett. Det kommer även ta upp personliga slutsatser om projektet och vilka förhållanden som kunde ha givit en annan utgång.
2 Teoretisk bakgrund
Det här kapitlet går igenom olika tekniker och dess grunder som behövs för att förstå hur det existerande systemet fungerar samt varför företaget vill gå ifrån den nuvarande
uppbyggnaden. Vi behandlar här olika typer av programmeringsspråk, hur dessa är uppbyggda och fungerar, och kopplar dessa till de språk som det här projektet vidrör. Kapitlet går även igenom information som kan behövas för att få förståelse om varför vi har utfört vissa moment och dess resutlat.
Det här kapitlet kommer även att förklara hur en databas är uppbyggd och hur PL/SQL fungerar tillsammans med en sådan. Kapitlet hanterar även grundläggande information om de konverteringsverktyg som senare används i genomförandet.
Vi har under skrivandet av det här kapitlet utgått från att läsaren har en grundläggande kunskap om datorer, servrar och programmering och kommer därför inte gå in på djupet exempelvis i hur en dator hanterar programkod.
2.1 Språktyper
2.1.1 Procedurbaserade språk
Dessa språk låter programmeraren definiera olika procedurer och funktioner som körs i ordning. Ordningen är oftast uppifrån och ner och programmet avslutar när pekaren har gått till slutet av en fil. Exempel på sådana språk är: PL/SQL, C, Visual Basic, Perl, Ada. Procedurer och funktioner måste deklareras för att koden skall kunna kalla på dessa från andra delar av programmet. När man sedan kallar på en funktion eller procedur flyttas pekaren till denna för att sedan genomföra dess funktion. Efter det att funktionen är genomförd så flyttas pekaren tillbaka där den var innan proceduren eller funktionen kallades på för att sedan fortsätta nedåt. [2]
Exemplet i Figur 1 visar hur man enkelt skriver ut ett meddelande med hjälp av PL/SQL. Man börjar med att deklarera variablerna för att sedan starta själva funktionen. Pekaren går nedåt tills dess att den pekar på END då den är klar med funktionen.
Figur 1 – Enkelt exempel på PL/SQL-kod
2.1.2 Objektorienterade språk
Objektorienterade språk är baserade på objekt som är strukturer som har olika attribut och rutiner som kallas metoder. Dessa metoder bestämmer vad objektet kan göra och hur det beter sig, detta gör att det enkelt går att programmera ett objekt som kan återanvändas. Exempel på sådana språk är: C++, Objective-C och Java.
DECLARE
meddelande varchar(100); --Deklarerar en textsträng som heter meddelande
BEGIN
meddelande := “Hejsan Världen, Detta är PL/SQL!”; --meddelande får värde
dbms_output.put_line(meddelande); --Skriver ut meddelandet
Man skapar klasser som är en definition av vad ett objekt innehåller och kan göra, dessa klasser kan sedan inkluderas i ett valfritt projekt, så länge man har tillgång till filerna. Att använda klasser förenklar programmeringen exempelvis genom att man slipper programmera samma funktion varje gång man skall använda denna, man placerar då funktionen i klassen. Man kan då istället med objektets hjälp kalla på dess
medlemsfunktioner och använda dem utan att behöva skriva om dem.
Det som gör objektorientering starkt är arv och polyformism, detta betyder att man exempelvis kan skapa en hierarki med klasser där subklasserna ärver funktioner och attribut av basklassen, man kan sedan skriva över dessa längre ner i hierarkin vilket gör att de fungerar annorlunda för objekt som tillhör de lägre klasserna.
I Figur 2 finns ett exempel på enkel klassuppbyggnad i Java. [2]
class Hejsan{
private String _meddelande; //Deklareraren text sträng
//skapar en konstruktor som skapar objektet, denna sätter även värdet på //_meddelande
public Hejsan(String meddelande){ _meddelande = meddelande; }
//skapar en funktion i klassen som skriver ut _meddelande
public void doMeddelande(){
System.out.println(_meddelande); }
}
class HejsanProgram{
public static void main(){
//skapar objectet med en text som input, kallar sedan på doMeddelande //funktionen
Hejsan hej = Hejsan(“Hejsan, detta är ett Java objekt”); hej.doMeddelande();
} }
2.2 Databaser
Det system som företaget har för nuvarande är uppbyggt på en Oracle-databas. En enkel förklaring av en databas är att den kan samla och organiserar en stor mängd information. Det som är speciellt med den är att all information är uppdelad över olika tabeller, de data som hör ihop finns i samma tabell.
En tabell kan ses som ett vanligt Excel-ark fast det har ett bestämt antal kolumner. Exempelvis kan det finnas en tabell som kallas “Användare”, då finns det ofta en första kolumn som heter “Användar-ID” och minst en kolumn till som innehåller information om den användare som har detta ID, exempelvis namnet på personen.
Det finns rader (rows, tuples) med kolumner där alla kolumner som finns på denna rad hör ihop, detta är vad som definierar en relationsdatabas. Den riktiga översättningen av tabell, och även synonymen på engelska, är “Relation”, därav namnet. Innan den första definitionen av en relationsdatabasen kom (1970) var de databaser som fanns uppbyggda på ett sådant sätt att man endast kunde svara på ett litet antal frågor, så som exempelvis endast vilka butiker en leverantör skulle skicka varor till.[3]
Det finns alltid en kolumn som skall vara unik, alltså innehålla ett unikt värde som ingen annan rad har i den specifika kolumnen. Denna kolumn kallas för nyckel, “key”, och kan även kombineras med andra kolumner för att få fram en ännu starkare nyckel.
Alla kolumner kan man även specificera vilken typ av data den skall innehålla, alltså om det skall vara exempelvis ett tal, datum eller en text. [3]
Databasens tabeller kan ofta, beroende på tillverkare, kopplas ihop med varandra, de tidigaste databaserna som utvecklades hade inte den här möjligheten. I exemplet i Figur 3 finns det en tabell med användare och en tabell med olika bilar, man då med hjälp av en relation definiera vilka användare som äger vilka bilar och vise versa vilka bilar som ägs av vilka användare. [3] Anvandare PK Anvandare_ID Anvandare_Namn Bilar PK Bil_ID Bil_Modell FK1 Anvandare_ID 0-∞
Figur 3 -- Exempel på hur tabeller i en databas kan vara relaterade.
2.2.1 SQL
SQL, Simple Query Language, används för att kommunicera och integrera med en databas genom att skriva så kallade “querys” till databasen.
SQL började med en rapport publicerad av E.F.Codd, vilken han skrev medan han arbetade på IBM’s forskningslaboratorium i San José 1970. Några år senare 1974 definierade D.Vhamberlin ett språk som kallades Structured English Query Language (SEQUEL), som senare skulle bli SQL. [6]
En query (fråga) är uppdelad i olika kommandon som beskriver vad som skall göras eller hämtas. Man kan till exempel välja att hämta all information från en viss tabell med en
SQL-fråga där en viss kolumn stämmer överens med ett krav i frågan. Med hjälp av SQL kan man bland annat uppdatera information och även ta bort rader i olika tabeller. Det går också att skapa, ta bort och uppdatera tabeller med hjälp av en fråga. SQL-frågorna kan spara som “stored procedures” i databasen för att kallas på direkt från ett anrop, istället för att man skriver frågan exempelvis i programkoden.
“Stored procedure” innebär att frågan sparas som ett script placerat i databasen. Nuförtiden går det att med hjälp av exempelvis PL/SQL att utveckla hela program uppbyggda på SQL. [6]
2.2.2 Exempel på SQL-query
SELECT kolumn_for_namn, kolumn_efter_namn FROM tabell_anstallda
WHERE kolumn_for_namn = ”David”
Figur 4 - Exempel på en SQL-query
Queryn i Figur 4 kommer att hämta information från tabellen “tabell_anstallda” och visa kolumnerna “kolumn_for_namn” och “kolumn_efter_namn” och dess värden. De rader som kommer att visas är de som stämmer överens med “WHERE”-kommandot, som i det här fallet skall kontrollera ifall det finns något värde i kolumnen “kolumn_for_namn” som stämmer överens med “David”.
Den text som i figuren står i början av varje rad är några av de standardkommandon som finns definierade i SQL, några fler av dessa är: UPDATE, DELETE FROM, INSERT, GROUP BY och HAVING. Alla dessa har olika innebörd och man använder dem på olika sätt för att exempelvis göra uträkningar, uppdatera information eller gruppera rader med liknande information. [6]
2.2.3 Oracle Database
Oracles databas är uppbyggd som en objektorienterad relationsdatabas. Den första versionen började utvecklas år 1977, då av skaparen Larry Ellison tillsammans med sina vänner Bob Miner och Ed Oates. De hade insett att behovet av en databas med
möjligheten att ha relationer mellan olika tabeller var stort.
Oracles databas är konstruerad som sådan att allt innehåll i databasen delas upp i olika filer på hårddisken och alla tabeller får varsitt “table-space”, alltså ett förutbestämt utrymme där tabellerna kan växa på servern. [3][4]
Figur 5 - Överblick av en Oracle databas visad i SQLDeveloper
2.2.4 PL/SQL
I den här rapporten hanteras en stor del PL/SQL (Procedural Language /SQL) som är det programmeringsspråk Oracle har tagit fram för att bygga ut SQL och som Logica använder i deras reskontrasystem.
Tidigare har SQL enbart varit ett simpelt sätt att kommunicera mot en databas.
Det har dock sedan SQL lanserades utvecklats olika språk för att kunna inkludera logik i den kod som representerar SQL:en. PL/SQL är ett sådant. Språket är ett blockbaserat programmeringsspråk som innehåller funktioner och procedurer.
Blockbaserat innebär att det finns olika stora kodstycken, men att blocken alltid kompileras separat, som ett procedurbaserat språk. Tidigare i det här kapitlet finns en förklaring av procedurbaserade språk.[6][7][8]
PL/SQL kan skrivas direkt i en kompilator som kalla SQL*Plus och då kör man dess funktioner direkt på datorn, men man kan även skriva och köra koden i så kallade script-filer som har filändelsen “.sql”. Dessa kan köras från SQL*Plus men kan även placeras i databasen som stored procedures, det är på detta sätt som Logica använder sin PL/SQL-kod. Detta underlättar för applikationsservern, som är uppkopplad mot databasen, att lätt komma åt dem och bearbeta deras information. Man kan lägga dessa under ett antal kategorier i databasen vid namn “Procedures”,“Functions” och även i större
sammanhang som olika “Packages”. I Figur 6 finns en överblick på hur dessa kan vara placerade i en databas. [6][7][8]
Figur 6 -- Överblick av PL/SQL placerad i olika paket i en Oracle-databas, samt viss kod.
Varje “Package”, från och med nu omnämnt som “paket”, fungerar som en header-fil där alla procedurer och funktioner deklareras och sedan finns det möjlighet till en “body” där man implementerar funktionaliteten. Dessa funktioner och procedurer liknar
högnivåspråk där man kan implementera dessa till att exempelvis hämta, bearbeta eller radera data, men man också skapa funktioner och procedurer som utför beräkningar och liknande. Det finns tillgång till olika standardklasser som hanterar kopplingen till
systemet och man kan med hjälp av dessa exempelvis hämta datum och liknande
information. Skillnaden mellan procedur och funktion är att en funktion alltid returnerar ett värde medans en procedur inte måste göra detta. Man använder därför procedurer när det inte krävs ett returnerat värde. [6][7][8]
2.2.5 Oracle Application Server
En applikationsserver används för att bidra med en miljö där ett program oberoende av funktion skall kunna köras. PL/SQL delen av det här projektet utnyttjar Oracle
Application Server för att hantera den PL/SQL kod som databasen innerhåller.
Kallar procedur
Returnerar HTML data
Oracle AppServer Oracle Database
Förfrågar sida Skickar Sida Http://Hemsida Go Arbetare: David Svensson Klicka Använder hemsida Arbetare: David Svensson arbetare.hittaArbetare
Figur 7 - Figur över Oracle Application server koppling till databasen
2.3 JAVA
2.3.1 Historia
Java är baserat på språket C++ och skapades av Sun Microsystems med ett projekt lett av James Gosling år 1991. James kallade först språket för “Oak” men då detta redan var upptaget så föreslogs namnet Java hos en lokal kaffeförsäljare, som en referens till kaffesorten. Företaget hade planerat att konsumentmarknaden inom datorer skulle växa mer än vad den gjorde under den här tidsperioden och projektet hotades snart att läggas ner. Men tack vare den kraftiga utvecklingen av internet (World Wide Web) 1993, lyckades Javas interaktiva hemsidor att få upp projektet på fötter igen. Sun tillkännagav Java på en presskonferens 1995 som tack vare den utvecklade interaktionen med internet blev en succé. [9][10]
Java används numera för att programmera allt ifrån storskalade applikationer till program för mobiltelefoner. Java utvecklas kontinuerligt med hjälp av JCP ( Java Community Process ), en styrelse som i samarbete med Java-communityn väljer vilka steg och i vilken riktning språket skall gå. Den samling som styr JCP består av flera stora och ledande företag inom branschen, men även mindre aktörer och även ner på användarnivå. Sun Microsystems har nu blivit uppköpta av Oracle, men Java står fortfarande kvar som opensource och JCP finns ännu kvar.[9][10]
2.3.2 Grunderna
Java är som tidigare nämnt baserat på C++ och är därmed ett objektorienterat programmeringsspråk, självklart med vissa skillnader mot C++ och det skall ha en enklare modell av objektorienteringen.
Tanken med Java är att allting skall skapas i klasser, dessa ska vara så enkla som möjligt för andra utvecklare att använda till sena egna projekt, alltså dess funktioner skall vara anpassningsbara för andra tillämpningar än de egna. Dessa klasser innehåller olika metoder som returnerar och behandlar olika värden och objekt. Många av dessa klasser laddas upp till “Java class library” där det ska vara enkelt för utvecklare att komma åt dem. [9]
En stor del med att lära sig Java innebär att kunna hantera dessa klasser och
implementera dem till sina egna projekt, samtidigt som man måste ha god kunskap om hur syntaxen är upplagd för att kunna göra just detta och även konstruera egna klasser. Java är också konstruerat så att det ska kunna köras på så många olika sorters system som möjligt genom att installera en säker körmiljö på de maskiner som skall kunna exekvera Java-program, en så kallad Java Runtime Environment (JRE). [9]
2.3.3 Java Runtime Environment (JRE)
Det är JRE:n som används för vanliga användare som vill kunna köra olika
Java-applikationer och applets på sin dator. Denna miljö innehåller bland annat en JVM (Java Virtual Machine) som då är en virtuell miljö vilket gör att språket blir möjligt att köra på alla system. Den innehåller även grundläggande klasserna samt bibliotek.
En Java Virtual Machine är som det låter en virtuell maskin som installeras på systemet i fråga och agerar då som en fullt fungerande dator med operativsystem inuti ditt egna system. [9][11]
Ett vanligt programmeringsspråk fungerar oftast så att man programmerar för ett speciellt system, med dess specifikationer och egenskaper. Den kod som då skrivs översetts sedan till maskinkod och sedan exekverar kompilatorn denne gentemot systemet. Java använder istället så kallad bytecode. Programmering med Java innebär att man sparar sin kod i ett dokument med ändelsen .java, när man sedan kör kompilatorn hämtar den sedan dessa och sparar dem som bytecode i en .class-fil.
JVM:en hämtar sedan in denna bytecode och kör den då gentemot operativsystemet på som maskinkod. Det är alltså JVM:en som gör det möjligt för Java-kod att fungera på flera olika system utan att man behöver programmera för just dessa. För att kunna utveckla Java-applikationer behöver man däremot Java Developement Kit (JDK) installerat på systemet som innehåller bland annat en kompilator, för att kunna köra koden. JRE:n och JDK:n innehåller dock till viss del samma komponenter. [9][11]
2.3.4 Servlets
Servlets kan beskrivas som en server applikation utan något interface. Dessa är till för att hantera den data som en webbapplikation skickar in och begär ut. Dessa kan vara mycket viktiga då de ger många smidiga möjligheter för webb-applikationer. Figur 8 nedan visar en enkel inloggnings applikation. I den här skriver du in användare och lösenord för att sedan skicka vidare detta till en servlet som jämför detta mot en databas. [13]
2.3.5 Tomcat
Apache Tomcat är en applikationsserver för Java servlets och Java server pages (.jsp). Tomcat är en opensourceprodukt, vilket betyder att all källkod är öppen för allmänheten och man kan på så sätt bygga en egen produkt för att sedan lansera. Dock krävs det att man har tillstånd av Apache Software Foundation (ASF) för att kunna lansera denne med en referens om att den innehåller kod från Tomcat. I och med att den är opensource är den också licensfri för användning, även i produktionsmiljö. [14] Tomcat utvecklades från början från Apaches Webserver, just för att kunna hantera Java, som då inte hade någon riktig representant i stabila webbservrar.
En applikationsserver behövs för att kunna implementera Java funktionalitet på en webbplats, utan en server som hanterar olika funktioner och kod kan man inte generera en sida som är interaktiv. I Figur 9 nedan visas hur Tomcat hanterar en applikations SQL-sats för att hämta information. Applikationsservern hanterar de olika momenten som användaren på webbplatsen gör och kopplar dessa samman med rätt funktion och navigering. I Tomcat går det med hjälp av olika .xml-filer att bestämma vilka url:er som skall leda vart (till vilka servelts, jsp osv.) , det går att ha flera olika applikationer i samma server, vilket kräver att man skall kunna navigera mellan dessa. [14]
Förfrågar sida
Skickar In SQL Sats
Returnerar Data Skickar Sida
TomCat Server Oracle Database
Http://Hemsida Go
Arbetare: David Svensson
Klicka
SELECT kolumn_for_namn, kolumn_efter_namn FROM tabell_anstallda
WHERE kolumn_for_namn = “David”
David Svensson Använder hemsida
Figur 9 - En applikationsserver för Java uppkopplad mot databas
2.4 KONVERTERINGSVERKTYG
Det här projektet är utfört efter inställningen att en ny version av det existerande
systemet inte skall behövas programmeras från grunden i Java, utan att man med hjälp av konverteringsverktyg skall kunna spendera så lite tid som möjligt åt att överföra
funktionaliteten till Java istället.
Ett konverteringsverktyg används för att på ett så smidigt och enkelt sätt som möjligt omvandla från en typ till en annan. Det finns konverteringverktyg för exempelvis
datatyper i olika databaser, det finns konverteringsverktyg för att flytta faktisk data mellan databaser av olika tillverkare och arkitektur. Det finns även konverteringverktyg som gör om kod och syntax i ett programmeringsspråk till ett annat.
Tanken med den här typen av verktyg är att man skall slippa bygga om ett system från början när man exempelvis vill byta det programmeringsspråk applikationen är byggt på. Eller om man endast vill flytta existerande tabeller och data mellan två olika databaser. Skäl för att göra detta kan till exempel vara att man vill kunna implementera nya
funktioner i systemet som det aktuella programmeringsspråket inte stöder, eller att man vill kunna komma ifrån licenser och kostnader för både kund och egen vinning.
För att godkännas som ett gångbart konverteringsverktyg i det här specifika projektet bör det klara av de steg som finns i Figur 10 nedan.
Automatisk Migration
Gränssnittet Funktionalliteten Dataåtkomst Databas Gränssnitt (HTML) Funktionalliteten (Servlets/Beens) Dataåtkomst Databas (Oracle eller annat)Oracle
Java
Figur 10 - Figur över vad konverteringsverktygen skall klara av.
De verktyg som omnämns i den här rapporten har rapportskrivarna med hjälp av företaget letat fram genom att göra sökningar på webben, samt genom att leta efter artiklar berörande liknande projekt. De som initialt hittades beskrivs i kommande stycke, men på grund av djupare efterforskning har några av dem uteslutits som kandidater för just det här projektet. I det här specifika projektet har vi använt konverteringsverktyg för att konvertera kod mellan PL/SQL och Java.
2.4.1 SwisSQL
SwisSQL är en produkt som levererar flera olika konverteringsmöjligheter, bland dessa: migrering av data och stored procedures från SQL Server till en Oracle databas med PL/SQL procedures istället. SwisSQLs konverteringsverktyg för PL/SQL till Java är en applikation som skall ta existerande PL/SQL kod, som finns sparad i en Oracle databas, och konvertera denna till Java-kod, uppbyggd med servlets, klasser och beans.
På så sätt skall den ersätta funktionaliteten i PL/SQLen men undvika att spara de nya filerna i databasen och då komma till ett mer standardiserat sätt att erbjuda en webbtjänst eller applikation. [16][17]
Produkten skall göra om den existerande koden från att vara placerad i databasen som stored procedures till att i Javan använda JDBC för att koppla upp mot databasen och köras som en fristående applikation. Verktyget skall enligt produktbeskrivningen stödja flera olika sorters programmeringsuppbyggnader i PL/SQL, samt även stödja
funktionalitet som erhålls från olika standard paket i den existerande koden.[16][17] En bild på SwisSQLs interface finns i Figur 12.
Figur 12 - En screenshot över hur SwisSQL ser ut [15]
En lista över olika funktioner som SwisSQL säger sig inneha:
Migrera PL/SQL-stored procedures till Java-kod.
Stödjer nästan alla PL/SQL-strukturer.
Stödjer PL/SQL- paket, procedures och funktioner.
Den kompletta listan med SwisSQL:s funktionalitet hämtad från deras hemsida finns i bilaga 1 till den här rapporten.[16][17]
2.4.2 sqlWays
SqlWays är ett verktyg utvecklat av Ispirer för att migrera data och procedurer mellan olika databaser. Om det finns SQL-statements i Java kod kan detta verktyg även konvertera dessa till ett passande format för destinationsdatabasen.
sqlWays används alltså för att flytta data mellan databaser av olika slag och fabrikat. Det gör i själva verket alltså ingen konvertering av funktionell kod, vilket gör verktyget ej användbart för det här projektet. [18]
2.4.3 Orindabuild
Ett verktyg som faktiskt inte konverterar varken data eller kod som vi först trodde, men är ett “plug-in” för exempelvis Eclipse. Det är utvecklat av Orindasoft.
Det här verktyget är till för att integrera Java-kod med PL/SQL, för att exempelvis skapa en funktion som skall koppla till en viss databas istället för att använda den enda databas som PL/SQL stödjer, vilken är Oracles. Det här verktyget faller alltså också bort från listan av gångbara alternativ för konverteringen.[19]
2.4.4 Exodus - PL/SQL to Java conversion tool
Ciphersoft är ett företag som har en produkt kallad Exodus, Exodus har i sin tur ett verktyg som skall konvertera PL/SQL-kod till Java och även kunna anpassa denna till att fungera med en webbtjänst, en bild av programmet finns i Figur 13. Verktyget skall plocka ut PL/SQLens paket och procedurer konvertera dessa till Java, och om man så väljer spara dem återigen i databasen för användning på samma sätt. [21][22]
Verktyget skall stödja funktioner som “Oracle Menus”, triggers och stored procedures. Ciphersoft har en lista med kriterier som anvisar hur det existerande systemet måste se ut för att kunna konverteras med full funktionalitet, denna lista bifogas som bilaga 2.
Exodus är ett alternativ som passar in på det här projektets behov. En del av de saker som Exodus skall klara av att omvandla är följande: [21][22]
Oracle Forms
Detta används som interface mot en Oracle databas och kan modifieras efter de krav man vill ha.
Triggers
Triggers används för att genomföra någon typ utav funktion då kraven för triggern blir uppfylt. Tillexempel lägga till en ny rad i en tabell.
Stored Procedures
Detta är procedurer som är lagrade i databasen istället för tillexempel separata filer.
2.4.5 Utvärdering av konverteringsverktyg
Efter en närmare undersökning som nämnts tidigare visade det sig att inte alla verktyg lämpade sig för det här specifika projektet.
De som bör klara av att konvertera PL/SQL-kod till Java är:
Ciphersofts Exodus
SwisSQLs Oracle to Java
I det kommande avsnittet har vi testat de olika verktygen och utvärderat deras funktionalitet.
3 Genomförande
Det första som ägde rum i projektets gång var ett möte mellan oss och Logica där vi gick igenom vad examensarbetet skulle behandla och på vilket sätt de ville att vi skulle arbeta. Efter det initiala mötet hos företaget påbörjades en lång period med installation och konfigurering av en fungerande testmiljö som skulle kunna både hantera deras existerande system, men även kunna presentera det som skall bli resultatet av konverteringen.
Under projektets gång har flertalet möten ägt rum hos Logica, för att kunna diskutera projektets gång och deras synpunkter på de olika etapperna. Dessa möten har skett mer eller mindre regelbundet, oftast veckovis, beroende på vad som har hänt i projektets väg och huruvida det varit några framsteg de har velat inspektera.
3.1
Teoretisk förstudie
Projektet hanterade språken PL/SQL och Java, PL/SQL i det existerande systemet och Java i det format som slutprodukten skulle vara i. Erfarenheten av dessa var minimal och var tvungen att förbättras, detta gjordes genom att först söka information och teori om de båda språken. Det viktigaste i det här steget var att förstå hur språken fungerade, syntax, logik och uppbyggnad, på vilka olika sätt man kan använda dem samt vilka skillnader som fanns mellan dem.
Efter en kort genomgång av de olika språken gjordes även ett par mindre projekt i dessa, för att skaffa den elementära kunskapen om hur språken används och vad som krävs för att kunna sätta upp en fungerande miljö. För att kunna förstå PL/SQL gjordes även en testsida med olika funktioner som förbättrade kunskaperna om språket.
Genom att skapa ett projekt i Java som hade samma funktionalitet som den PL/SQL-kod vi fått av företaget, kunde vi därmed se hur en fungerande konverteringen skulle kunna se ut. En beskrivning av det projektet kommer under avsnittet “Konstruering av testprojekt”. Med hjälp av detta projekt såg vi hur en konverterad kod skulle kunna se ut och hur den bör vara uppbyggd för att vara användbar och vilka olika delar en
fungerande konvertering skall innehålla.
3.1.1 Informationssökning
För att hitta relevanta artiklar och rapporter berörande ämnet och de olika
programmeringsspråken användes sökmotorn på Högskolans bibliotek, dock användes mestadels en sökmotor för den resterande webben för att hitta de användbara verktygen. Informationssökning har även gjorts på olika bibliotek för att hitta relevanta böcker rörande ämnet och omkringliggande information. De böcker som använts har mestadels berört programmeringsbiten då det projekt vi sysslat med inte är något som är så vanligt förekommande att böcker skrivs om det.
För att kunna sätta upp en fungerande testmiljö var vi även tvungna att hitta information om vilka versioner av Oracles databas samt applikationsserver som skulle användas tillsammans samt med vilket operativsystem. Det fanns dock inga direkta krav från applikationen vilka versioner som skulle användas.
För att kunna sätta upp en applikationsserver för Javan var det även där tvunget att söka information om vilka skillnader det fanns mellan olika serverleverantörerna, samt vilka restriktioner de olika hade och eventuella licenskostnader.
När det gäller applikationsservern för Java finns dock inte samma krav som PL/SQL ställer på databasen, då PL/SQL är utvecklat för Oracle krävs det att man har just en Oracledatabas.
3.2
Praktiskt förberedande
3.2.1 Installation av testmiljö
För att kunna undersöka huruvida de olika verktygen verkligen fungerade var vi tvungna att ha en arbetsmiljö som kunde hantera de olika momenten. Miljön var tvungen att kunna hantera en version av Logicas gamla system samt kunna presentera en webbapplikation baserad på Java.
Testmiljön skulle vara enkel att spara samt återställa om något skulle gå fel. Efter en del testande insågs att en virtuell miljö (en virtuell dator installerad på
testmaskinen) där det var lätt att spara och återställa skulle underlätta för att motverka eventuella snedsteg i projektets gång. I den virtuella miljön så krävdes det en arbetsmiljö för Oracles databas samt att Applikationsservern skulle kunna installeras och fungera felfritt. För att hitta ett operativsystem som detta stöddes av så krävdes det ett antal olika tester där ett flertal inte fungerade eller fyllde de krav som krävdes. Vad som kunde utgöra dessa problem var bland annat arkitekturen på operativsystemet, exempelvis om os:et var baserat på 32-bitars eller 64-bitars. Olika versioner av Oracles databas och applikationsserver krävde olika operativsystem och då företagets existerande system inte hade några direkta krav på vilken exakt version dessa skulle vara i, var det upp till oss att sätta upp en testmiljö som var smidig att installera samt fungerade som det existerande systemet.
Varje test krävde att den virtuella plattformen raderades för att sedan byggas upp igen. Slutligen valdes en virtuell maskin med operativsystemet Windows XP (32-bitars) för att bli den arbetsplattform som projektet skulle använda sig av. Windows XP valdes för att det var det mest kompatibla systemet för Oracles produkter under testernas gång då många av de andra stötte på flera problem med kompabilitet och att använda en faktisk server-version visade sig kräva en stor del konfiguration vid varje steg i
Ytterligare en aspekt av installationen var att få en så kallad “listener” att fungera för databasen, denna krävs bland annat för att kunna använda webbgränssnittet med databasen och behövs även för applikationsservern, så att denna kan komma åt de olika PL/SQL procedurer och liknande man vill kalla på.
När väl testmiljön för oracle-systemet var uppsatt och fungerande var nästa steg att installera ännu en applikationsserver, fast då istället för Java.
Då vi använde samma databas som i det ursprungliga systemet behövdes alltså inte någon installation eller konfiguration av ännu en sådan.
Tanken med Javan var att all information fortfarande skulle finnas i databasen, nödvändigtvis inte samma fabrikat som nu, men att man har .jsp filer och servlets sparade på hårddisk på en server för att generera webbservicen, med hjälp av en applikationsserver anpassad för Java, och att genom denna hämta informationen från databasen. Den applikationsserver vi valde att arbeta med var Apache Tomcat 7, då den är opensource, skall vara stabil och även lätt att konfigurera. Tomcat var kompatibelt med Windows XP, som vi nu valt som testmiljöns plattform, och var därför inte lika krävande att installera som Oracles olika produkter. I Figur 14 visas en grundläggande överblick på hur serverdatorn var installerad med olika applikationer samt hur vi kopplade upp oss mot den.
Efter det att dessa applikationer var installerade krävdes det att den virtuella
arbetsstationen skulle anpassas så att det gick att arbeta flera simultant på den från en remote desktop. Detta uppnåddes genom att ändra ett antal värden i registret då
funktionen är inbyggd men ej aktiv i Windows XP. Efter att detta var gjort installerades den kod som vi erhållits utav företaget. All kontakt med oracles databas har gjorts med hjälp av SQLDeveloper som även det är en oracle-produkt.
Det administrativa med databasen sköts via webbgränssnittet, alltså konfigurering av användare och rättigheter, samt portar och liknande funktionella inställningar.
SQLdeveloper användes dock bland annat för redigering av tabeller i databasen, samt för att konfigurera de olika paketen i PL/SQL:en.
Internet
Application Servers (TomCat/Oracle App Server) Database
(Oracle Database)
3.2.2 Redigering av existerande kod
Efter att testmiljön var installerad och att allt fungerade felfritt var det dags att importera den kod vi fått av Logica som representerade deras ursprungliga system, alltså olika PL/SQL-paket.
För att få koden att fungera utan problem i testmiljön krävdes viss redigering då denna bara var en liten del av det hela systemet och vissa delar var beroende av delar som ej var tillgängliga för oss i nuläget. Den kod vi fick av företaget hade stora delar av
funktionaliteten bortkommenterad för att kunna använda endast de viktigaste delarna utan att faktiskt behöva implementera hela systemet, men det var delar av koden som ändå inte fungerade fullt ut, då vissa procedurer etc. krävde att rätt port och liknande angavs som argument. De funktioner som användes i de elementära paketen men exempelvis inte returnerade rätt värde redigerade vi till att fungera i vår testmiljö. Vi tog alltså bort all den kod som var bortkommenterad och de procedurer och funktioner i andra paket som inte användes för den funktionalitet vi behövde. Detta gjordes för att få så lättöverskådlig kod som möjligt och även för underlätta eventuell felsökning.
3.2.3 Konstruering av testprojekt
Som tidigare nämnt utvecklade vi nu två projekt, ett i vardera språk.
Det projekt som gällde PL/SQL, gjordes mestadels för att få kunskap om syntax och för att kontrollera att Oracles applikationsserver fungerade som tänkt.
Projektet som vi gjorde i Java var dock tänkt att visa hur en fungerande
Java-konverteringen skulle kunna fungera, vilket var nödvändigt för att kunna avgöra huruvida konverteringsverktygen fullföljde uppgiften vi gett dem. Vår Java-applikation var i
slutändan uppbyggd med olika .jsp sidor, där vi använde servlets och klasser för att hantera in och utdata. Applikationen var uppbyggd efter den uppfattning vi fått av företagets inloggningstjänst och projektledarvisning.
Vi byggde alltså en inloggning, visas i Figur 15, med koppling till oracledatabasen för att kontrollera huruvida användaren har tillgång eller ej. Vår lösning var baserad på html-forms och POST-variabler för att skicka informationen och validera direkt på sidan, detta var dock enligt företaget inte det sätt man borde ha byggt tjänsten på och vi tog till oss informationen då vi inte tidigare arbetat med Java och därmed inte var helt säkra på arbetssättet.
Projektledarvisningen byggde vi på liknande sätt, visas i Figur 16, genom att fylla upp en html-form med information hämtad från databasen med hjälp av en variabel skickad med GET eller POST.
Figur 16 – Projektledarvisning i vårt testprojekt i Java
3.3
Konverteringsverktyg
Initialt gick vi igenom de olika verktygen vi funnit för att se vilka som skulle kunna producera bäst resultat samt för att kunna utesluta eventuella kandidater som inte hade rätt funktionalitet. Som tidigare nämnt i kapitlet teoretisk bakgrund så kunde vi tidigt utesluta två av kandidaterna, vilka var Orindabuild och sqlWays då dessa inte besatt rätt egenskaper för att kunna fullfölja våra tester.
Vi testade sqlWays på några av de paket vi fått av företaget och märkte då att det som sqlWays faktiskt gjorde var att flytta innehållet i en databas av en tillverkare till en databas av en annan tillverkare och formaterade datan där efter.
3.3.1 SwisSQL - Oracle to Java
När vi jämförde de olika verktygen mot varandra så verkade SwissSQL vara den med mest features och därmed den som verkade mest trolig till att fungera, vi började därför med att kontrollera just SwisSQL.
Den version som fanns att ladda ner från SwisSQL:s hemsida var en demo-produkt med begränsning i tid och kvantitet. Begränsningen i tid var på 30 dagar från installationen och det fanns bara möjlighet att konvertera 2000 rader kod från PL/SQL till Java. För att testa funktionaliteten konverterade vi först ett antal små program skrivna i PL/SQL. Dessa var procedurer med ytterst lite funktion för att kunna konvertera utan att ta alldeles för mycket av det antal rader kod möjliga att konvertera i demoprodukten. När vi inspekterade dessa kodstycken märkte vi att all den funktionalitet såsom logiska moment och iterationer hade så gott som försvunnit, samt att en del fel såsom dubbla klasser hade uppstått i resultatet.
Vi fortsatte dock med konverteringen av Logicas system för att kontrollera hur mycket av deras funktioner som kunde konverteras utan problem. I och med gränsen på 2000 rader kod i SwisSQL var vi tvungna att ta bort mycket av den kod som fanns i de paket som Logicas system består av. Från början fick vi ca tio olika paket med funktionalitet från företaget, den kod som fanns i dessa räknades upp till ungefär 7000 rader, alltså alldeles för mycket för att gå igenom verktyget. Nu påbörjades ett arbete med att gå igenom vad som kunde tas bort i dessa paket utan att påverka funktionaliteten allt för mycket.
I början fokuserade vi på att få igenom projektledarpaketet i verktyget, då det var detta som innehöll flest funktioner och procedurer. Det skulle därmed snabbt kunde visa på huruvida verktyget var tillförlitligt eller ej.
I och med att vi hade över 7000 rader kod i alla paket och många av dessa innehöll funktioner och procedurer som användes av just projektledarpaketet var vi tvungna att gå igenom alla de olika paketen för att rensa ut den kod som inte var nödvändig.
Det kom dock snart till vår vetskap att det inte skulle räcka med att rensa ut på det här sättet. När vi var klara med detta var vi ännu inte under gränsen på 2000 rader, så nästa steg var att gå igenom även projektledarpaketet efter vad som skulle kunna raderas utan för stor förlust i komplexitet.
Slutligen tog vi bort kopplingarna till alla andra paket och placerad funktionerna och procedurerna som användes där i projektledarpaketet, för att undvika onödig kod i så stor utsträckning som möjligt. Först nu kunde vi konvertera något större med
funktionalitet. Koden gick igenom verktyget och ett stort antal filer skapades för de olika funktionerna och procedurerna. Hur dessa fungerade går vi igenom under resultatdelen av den här rapporten som berör just SwisSQL.
3.3.2 Exodus - PL/SQL to Java conversion tool
Exodus var ett annat lovande verktyg som verkade kunna klara av den uppgift vi hade åt det. Det fanns dock inte mycket information om vad det kunde klara av och vad som krävdes av orginalkoden.
Vi valde att testa SwisSQL innan Exodus eftersom vi inte kunde hitta någon
demoversion av den senare initialt. Vi kontaktade Ciphersoft först via mail och sedan via telefon, företaget är lokaliserat i USA, angående ett demo och fick sedan vår
kontaktinformation vidarebefordrad till en person med rätt tjänst.
Vi fick snart ett mail med svaret att för att kunna använda verktyget, till och med endast för provkörning då verktyget ansågs vara för avancerat, behövdes det en utbildning som de kunde bidra med mot ersättning. De erbjöd sig dock att ta emot en del av koden för att konvertera och sedan skicka tillbaka resultatet till oss. Efter kontakt med Logica fick vi klartecken och skickade då iväg koden som vi hade bearbetat för testerna med SwisSQL.
Så någon faktiskt konvertering av oss har inte skett och efter det att vi skickat koden har vi inte gjort någon förändring eller förbättring av deras resultatkod. Resultatet av deras konvertering samt efterspelet är inkluderat i resultatdelen i den här rapporten under Exoduskapitlet.
4 Resultat
Som rapporten tidigare nämnt var en av huvurfrågorna huruvida det fanns några fungerande konverteringsverktyg som skulle kunna användas för den här typen av arbeten, för att komma ifrån att behöva skriva om systemet på nytt fast då i Java. Ett par andra frågor var också vilket av de alternativ som fanns passade bäst till just det här systemet, samt vilket verktyg som krävde minst för- och efterarbete. Utvärdering av dessa kommer senare i det här kapitlet, där det bland annat nämns vad de olika klarar av och inte.
En annan fråga var också huruvida det fanns några så kallade “Best-practices” i det här sammanhanget, alltså vad man bör tänka på och ifall det har funnits liknande projekt tidigare och vilka lärdomar man kan dra av dessa. För att kunna svara på den frågan har efterforskningar gjorts både med hjälp av sökmotorer och till stor del Högskolan i Jönköpings databas för artikel- och litteratursökning.
Det har dock visat sig vara en uppgift som vi inte funnit någon direkt information om, de projekt som har funnits har skiljt sig till stor del från den uppbyggnad Logica har på sitt system och kan därför inte passas in till dessa. Resultatet av verktygen har också visat att några “Best-practices” inte har varit nödvändiga.
4.1 SwisSQL - Oracle to Java
En fördel med SwisSQL är att det var relativt enkelt att importera paket och tabeller från databasen, det enda som krävdes var att med hjälp av en inställningsguide koppla upp sig mot denne och sedan hade man direkt tillgång till hierarkin i databasen och dess element. Det var därför enkelt att välja ut exakt vilka paket och procedurer som skulle konverteras av verktyget.
Den kod som SwisSQL genererade i Java använde till stor del ett antal klasser som SwisSQL hade utvecklat för exempelvis databaskopplingen.
För att kunna använda den här koden behövde man alltså tillgång till dessa klasser även efter det att man slutat använda verktyget. Den kod som genereras innehöll en klassfil för varje paket som fanns i ursprungskoden, men dessa innehöll även flera klasser i sig, varav vissa var dubbletter.
Det fanns även vissa syntaxfel som gjorde att kompilatorn inte kunde kompilera koden utan att tid lades ner på att rätta till dessa fel. Det största felet med koden var dock att i stort sett all funktionalitet var frånvarande i den slutgiltiga produkten, det som fanns kvar var just den del som hanterade kopplingen till databasen, men någon information
hämtades inte längre ut. Vi besökte även forum, kontrollerade nyheter och uppdateringar angående verktyget, men de nyaste uppgifter och samtalsämnen som fanns var daterade tidigt 2010, vilket gav känslan av att produkten inte längre var up to date.
Det resultat vi fick ut från SwisSQL gjorde att vi efter genomgång med Logica uteslöt produkten som en möjlig kandidat.
4.1.1 SwisSQL beslutar att lägga ner Oracle to Java-verktyget
Efter det att den praktiska delen av projektet var klart upptäckte vi att SwisSQL hade lagt upp ett meddelande på hemsidan för verktyget. Som bilden i Figur 17 nedan beskriver så kommer SwisSQL att avveckla deras Oracle to Java produkt, vilken var den som testades i det här projektet.Figur 17 - Bild från SwisSQLs hemsida för deras Oracle to Java tool. [23]
4.2 Exodus - PL/SQL to Java conversion tool
Då det inte fanns någon tillgång till en demoversion av Exodus (se genomförande), kunde vi inte heller gå igenom vad verktyget klarade av att konvertera.
Det som fanns var dock en lista på olika krav verktyget hade för att kunna garantera en lyckad konvertering (finns bifogad i bilaga 2). Den listan visar dock på att det system som Logica har inte stämmer överens med vad som krävs för att Exodus skall fungera.
Efter mailkonversation med Ciphersoft och efter att vi skickat dem filerna som innehöll de olika paketen kom det ett svar att konverteringen inte var möjlig. För att en
konvertering skulle kunna vara möjlig krävdes det att systemet var uppbyggt med hjälp av så kallade Oracle-forms, som innebär ett interface emot databasen som inte är Html-baserat.
Ciphersoft erbjöd sig dock till att utveckla verktyget till att innehålla rätt funktionalitet till ett pris av 1000$ per arbetsdag och beräknad tid till 20 dagar. Efter konversation med Logica bestämdes dock att en sådan kostnad inte var något att satsa på, då en
uppgradering av verktyget faktiskt inte garanterade att det i slutändan skulle fungera att konvertera felfritt.
5 Diskussion och slutsatser
5.1 Resultatdiskussion
Syftet med det här projektet var att undersöka huruvida det var möjligt att konvertera ett system skrivet i PL/SQL till Java. Tanken var inte att det skulle gå åt någon betydande tid till att skriva och editera Java-kod, utan syftet var att undersöka ifall det fanns några verktyg som skulle kunna hjälpa till med uppgiften.
Av de verktyg vi fann från början var endast två synes passande till projektet.
Efter ett antal tester med det första verktyget vid namn SwisSQL kom vi fram till att den kod som genererades var fri från all den funktionalitet som ursprungligen fanns i
systemet. Det fanns stora brister i resultatkoden, bland annat så var syntaxen felaktig på ett antal ställen och det fanns dubbletter av klasser vilket även det påverkade
kompileringen. För att kunna få konverteringen producerad av SwisSQL att fungera skulle det alltså behövas en ingående editering av koden, där man skulle behöva
programmera om näst intill all funktionalitet igen. Detta är alltså inget gångbart alternativ då att antagligen skulle gå fortare och kosta mindre (på grund av uteblivna
licenskostnader på SwisSQL) att programmera om systemet från början fast då i Java. Vi försökte dock söka information om verktyget, men den som fanns var dåligt
uppdaterad och nu i efterhand har det även kommit fram information om att verktyget inte längre skall säljas, fast supporten skall finnas kvar ett tag till.
Så som nämnt i resultatet har vi inte testat någon konvertering med hjälp av Exodus, då det inte fanns en demoversion tillgänglig som inte krävde utbildning.
Det vi dock har fått fram genom mailkonversation med Ciphersoft pekar på att Logicas system inte skulle kunna gå att konvertera utan att verktyget ytterligare behöver utvecklas med rätt funktionalitet. Kostnaden av detta var relativt stor, då Logica själva får ta på sig den. Om det skulle vara så att förändringen skulle gynna andra kunder av Ciphersoft blir antagligen kostnaden utdelad på dessa, men då Logicas system är unikt uppbyggt, är chansen liten att det skulle vara så. En satsning på detta skulle heller inte garantera att konverteringen fungerar utan problem, vilket kan betyda att Logica får betydligt större kostnader i slutändan.
Till följd av resultaten från verktygen blir frågan om “Best-practices” irrelevant, då systemet i fråga inte kan konverteras utan stor manuell konfigurering.
De “Best-practices” som finns hanterar system som bygger på Oracle-forms och passar därför inte in på Logicas system.
5.2 Slutsatser och rekommendationer
En stor del av varför projektet inte lyckades beror på att Logicas system är uppbyggt så att PL/SQL:en genererar html-kod till applikationsservern. Detta är inte ett standardsätt att bygga PL/SQL på och är därför dåligt representerat bland de konverteringsverktyg vi funnit. Det enda egentliga alternativet som skulle kunna fungera är dock Exodus, då de var villiga att utöka funktionerna på sin produkt. Att göra detta är dock ett riskabelt alternativ då det inte finns någon säkerhet i att de får vad de betalar för.
Generellt sagt har vi inte funnit några tecken på att PL/SQL, utvecklat på ett standardsätt, kan konverteras på korrekt vis och generera färdig Java.
Om ett liknande projekt skall genomföras rekommenderas att man kontrollerar de olika verktygens funktionalitet noggrant och ser över sin egen applikation, för att upptäcka eventuella svårigheter och speciallösningar som kan förhindra en korrekt konvertering Vi har dock fått en känsla av att om man har ett system skrivet i ett språk och vill
konvertera detta till ett annat språk som ej är nära besläktade, så kan det ofta vara värt att undersöka om det inte skulle vara mer lönsamt att utveckla om det från grunden och möjligtvis ta idéer från det gamla systemet.
Även att vårt arbete inte ledde till någon konvertering är vi nöjda med resultatet och företaget fick svar på sina frågeställningar angående den ursprungliga uppgiften.
6 Referenser
[1] Logica http://www.logica.se/we-are-logica/about-logica/ (Acc. 2011-03-25)
[2] Bill Pribyl, Steven Feuerstein. Learning Oracle PL/SQL First Edition December 2001 ISBN: 0-596-00180-0
[3] Iggy Fernandez. Beginning Oracle Database 11g Administration: From Novice to Professional ISBN: 1-59059-968-3 (2009)
[4] Oracle http://www.oracle.com/us/corporate/history/index.html (Acc. 2011-04-19) [5] Oracle http://download.oracle.com/docs/cd/E12840_01/wls/docs103/pdf/intro.pdf (Acc.
2011-04-19)
[6] Thomas M. Connoly , Carolyn E. Begg. DATABASE SYSTEMS: A Practical Approach
to Design, Implementation and Management (FIFTH EDITON) ISBN: 0-321-52306-7 (2005)
[7] Oracle http://www.oracle.com/technetwork/database/features/plsql/overview/doing-sql-from-plsql-129775.pdf (Acc. 2011-05-10)
[8] Josh Juneau, Matt Arena. Oracle and PL/SQL Recipes: A Problem-Solution Approach ISBN: 1-4302-3207-2 (2010)
[9] H.M.Deitel, P.J.Deitel. Java How to Program, 7th Edition ISBN: 9780136085676 (2006) [10] JCP http://jcp.org/en/introduction/faq (Acc. 2011-03-16)
[11] Java http://java.com/en/download/faq/whatis_java.xml (Acc. 2011-03-16) [12] Oraclehttp://www.oracle.com/technetwork/java/javase/readme-142177.html
(Acc. 2011-03-16)
[13] Oracle http://www.oracle.com/technetwork/java/javaee/servlet/index.html
(Acc. 2011-04-10)
[14] Apache http://tomcat.apache.org/ (Acc. 20011-04-30)
[15] SwisSQL http://www.swissql.com/images/pl2jsqlconsole.png (Acc. 20011-04-30) [16] SwisSQL http://www.swissql.com/products/index.html (Acc. 20011-04-30) [17] SwisSQL http://www.swissql.com/products/oracle-to-java/oracle-to-java.html
(Acc. 20011-04-30)
[18] Ispirer http://www.ispirer.com/products (Acc. 20011-03-30)
[20] CiperSoft http://www.ciphersoftinc.com/products/exodus-ve-visual-xml-editor.html
(Acc. 20011-04-30)
[21] CiperSoft http://www.ciphersoftinc.com/products/ (Acc. 20011-04-30)
[22] CiperSoft http://www.ciphersoftinc.com/products/plsql-to-java-conversion-tools.html (Acc. 20011-04-30)
[23] SwisSQLhttp://www.swissql.com/products/oracle-to-java/oracle-to-java.html
7 Bilagor
Bilaga 1 – Lista över SwisSQLs featueres and benefits.
Bilaga 2 – Lista över krav från Ciphersoft på den applikation som skall konverteras
