PL/SQL till Java – Konvertering med verktyg

PL/SQL till Java – Konvertering med verktyg
PL/SQL to Java – Conversion with tools
Fredrik Sköld Martini
Philip Axell
EXAMENSARBETE 2011
DATATEKNIK
Postadress:
Besöksadress:
Telefon:
Box 1026
Gjuterigatan 5
036-10 10 00 (vx)
551 11 Jönköping
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
Handledare: Christer Thörn
Omfattning: 15 hp (grundnivå)
Datum: 2011-05-31
Postadress:
Besöksadress:
Telefon:
Box 1026
Gjuterigatan 5
036-10 10 00 (vx)
551 11 Jönköping
Abstract
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 “Bestpractices”. 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.
1
Sammanfattning
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 Server
2
Innehållsförteckning
Innehållsförteckning
1
Inledning ................................................................................... 6
1.1
1.2
1.3
1.4
1.5
1.6
2
PROBLEMBESKRIVNING............................................................................................................... 6
SYFTE MED PROJEKT ................................................................................................................... 6
FRÅGESTÄLLNINGAR .................................................................................................................. 7
AVGRÄNSNINGAR ....................................................................................................................... 7
METOD........................................................................................................................................ 7
DISPOSITION ............................................................................................................................... 8
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 ............................................................................................................................. 13
2.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ö ...................................................................................................... 23
3.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
5.2
RESULTATDISKUSSION .............................................................................................................. 31
SLUTSATSER OCH REKOMMENDATIONER .................................................................................. 32
3
Innehållsförteckning
6
Referenser .............................................................................. 33
7
Bilagor..................................................................................... 35
4
Innehållsförteckning
Figurförteckning
FIGUR 1 - ENKELT EXEMPEL PÅ PL/SQL-KOD
FIGUR 2 - ENKEL JAVA-KOD MED TVÅ KLASSER
FIGUR 3 - EXEMPEL PÅ HUR TABELLER I EN DATABAS KAN VARA RELATERADE.
FIGUR 4 - EXEMPEL PÅ EN SQL-QUERY
FIGUR 5 - ÖVERBLICK AV EN ORACLE DATABAS VISAD I SQLDEVELOPER
FIGUR 6 - ÖVERBLICK AV PL/SQL PLACERAD I OLIKA PAKET I EN ORACLEDATABAS, SAMT VISS KOD.
FIGUR 7 - FIGUR ÖVER ORACLE APPLICATION SERVER KOPPLING TILL
DATABASEN
FIGUR 8 - ENKEL FÖRKLARING TILL HUR EN SERVLET FUNGERAR MOT DATABAS
FIGUR 9 - EN APPLIKATIONSSERVER FÖR JAVA UPPKOPPLAD MOT DATABAS
FIGUR 10 - FIGUR ÖVER VAD KONVERTERINGSVERKTYGEN SKALL KLARA AV.
FIGUR 11 - TABELL ÖVER KONVERTERINGSVERKTYG OCH DESS TILLVERKARE
FIGUR 12 - EN SCREENSHOT ÖVER HUR SWISSQL SER UT [15]
FIGUR 13 - EN SCREENSHOT PÅ CIPHERSOFTS EXODUS UNDER ANVÄNDNING
[20]
FIGUR 14 - ÖVERBLICK AV TESTMILJÖN, MED APPLIKATIONER.
FIGUR 15 - INLOGGNINGSVY I VÅRT TESTPROJEKT I JAVA.
FIGUR 16 - PROJEKTLEDARVISNING I VÅRT TESTPROJEKT I JAVA
FIGUR 17 - BILD FRÅN SWISSQLS HEMSIDA FÖR DERAS ORACLE TO JAVA TOOL.
[23]
5
9
10
11
12
13
14
15
16
17
18
18
19
20
24
25
26
30
Teoretisk bakgrund
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
därmed också reglera licenskostnaderna efter funktionalitet och antal användare.
Man vill alltså komma ifrån PL/SQL, vilket är konstruerat av Oracle, för att på detta sätt
undvika att man blir låst till deras produkter.
1.2 Syfte med projekt
Vår uppgift i det här projektet har varit att leta upp och undersöka vilka vägar man kan
gå och vilka som är mest effektiva i tid och kostnad för att konvertera det existerande
systemet hos Logica till ett med samma funktionalitet fast istället byggt med hjälp av Java.
Vår uppgift var att hitta en kostnads- och tidseffektiv lösning till konverteringsproblemet
som de sedan kan använda till att utföra arbetet om det visar sig vara möjligt.
6
Teoretisk bakgrund
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.
7
Teoretisk bakgrund
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.
8
Teoretisk bakgrund
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.
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
END;
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.
9
Teoretisk bakgrund
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();
}
}
Figur 2 – Enkel Java-kod med två klasser
10
Teoretisk bakgrund
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
Bilar
Anvandare_ID
0-∞
PK
Bil_ID
FK1
Bil_Modell
Anvandare_ID
Anvandare_Namn
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
11
Teoretisk bakgrund
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 SQL-fråga. SQLfrå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]
Hierarkin i en Oracle-databas är uppbyggd på olika användare, som vardera kan ha
exempelvis tabeller, PL/SQL-paket och procedurer. Man kan sedan tilldela de olika
databasanvändarna rättigheter och restriktioner, vilket bidrar till att man kan dela
administrationen mellan ett stort antal personer. Beroende på hur administratören
konfigurerar databasservern kan man exempelvis koppla upp sig mot denna så länge man
har en klient installerad på den aktuella datorn. Klienten installerar en listener på datorn
som används för att koppla upp sig mot databasen. Man kan således med hjälp av detta
komma åt databasen från i stort sett vilken dator som helst vilket underlättar interaktion
på distans. I Figur 5 finns en vy över databasens uppbyggnad för Oracle visad i
SQLDeveloper. [3][4]
12
Teoretisk bakgrund
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 scriptfiler 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/SQLkod. 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]
13
Teoretisk bakgrund
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.
Oracle Application Server, som då stödjer PL/SQL efter viss konfiguration, användes för
att kalla på och ta emot data från PL/SQL funktioner i Oracle Databasen.
För att projektets sida skall kunna visas så skickas först en förfrågan från användaren till
applikationsservern, därefter kallar denna på en PL/SQL procedur i databasen som i sin
tur returnerar den data som proceduren genererar. Efter det att applikationsservern
mottagit informationen så bearbetar denna det och skickar vidare till användaren.
I Figur 7 visas en enkel överblick av kopplingen mellan applikationsserver och databas.[5]
14
Teoretisk bakgrund
arbetare.hittaArbetare
Kallar procedur
Oracle AppServer
Http://Hemsida
Använder hemsida
Arbetare:
David Svensson
Oracle Database
Go
Förfrågar sida
Skickar Sida
Klicka
Returnerar HTML data
Arbetare:
David Svensson
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]
15
Teoretisk bakgrund
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 Javaapplikationer 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]
Användare
Login Servlet
Lösenord
Databas
Logga In
Java Webb-App
Figur 8 - Enkel förklaring till hur en servlet fungerar mot databas
16
Teoretisk bakgrund
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]
SELECT kolumn_for_namn, kolumn_efter_namn
FROM tabell_anstallda
WHERE kolumn_for_namn = “David”
Skickar In SQL Sats
Http://Hemsida
Använder hemsida
Arbetare:
David Svensson
TomCat Server
Go
Oracle Database
Förfrågar sida
Skickar Sida
Klicka
Returnerar Data
David
Svensson
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.
17
Teoretisk bakgrund
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.
Oracle
Java
Gränssnittet
Gränssnitt
(HTML)
Funktionalliteten
Funktionalliteten
(Servlets/Beens)
Automatisk Migration
Dataåtkomst
Dataåtkomst
Databas
Databas
(Oracle eller annat)
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.
Namn
Tillverkare
Exodus - PL/SQL to Java conversion tool Ciphersoft
SwisSQL - Oracle to Java
SwisSQL
Orindabuild
Orindasoft
sqlWays
Ispirer
Figur 11 - Tabell över konverteringsverktyg och dess tillverkare
18
Teoretisk bakgrund
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]
19
Teoretisk bakgrund
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]
Figur 13 - En screenshot på Ciphersofts Exodus under användning [20]
20
Teoretisk bakgrund
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.
21
Genomförande
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/SQLkod 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
Projektet var tänkt att kontrollera olika konverteringsverktygs förmåga att konvertera
PL/SQL till Java och behålla dess funktionalitet under processen.
Detta för att en faktisk konvertering av Logicas nuvarande system bör ta så lite tid som
möjligt och att konfiguration av resultatkoden skall vara liten.
I början av projektet var kunskapen om olika konverteringsverktyg låg, förutom de som
företaget hade gett oss tips om. Det första steget var således att försöka hitta olika
verktyg som skulle kunna utföra den uppgift vi önskade. Initialt hittades fem olika
verktyg som såg ut att vara passande för projektet, detta var dock mestadels en snabb
överblick för att få en uppfattning angående vilka möjligheter som fanns. Vi undersökte
även om det fanns några existerande liknande projekt som utförts tidigare och huruvida
dessa varit lyckade eller ej.
22
Genomförande
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
implementationen och valdes därför bort för att spara tid.
23
Genomförande
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.
Application Servers
(TomCat/Oracle App Server)
Database
Internet
(Oracle Database)
Utvecklings applikationer
Virtual Machine
(Windows XP)
(TextHanterare/SQLDeveloper)
Figur 14 - Överblick av testmiljön, med applikationer.
24
Genomförande
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 Javakonverteringen 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å htmlforms 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.
Figur 15 – Inloggningsvy i vårt testprojekt i Java.
25
Genomförande
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.
Några tester med Orindabuild blev aldrig av då detta verktyg skall användas vid
utveckling av Java och man behöver koppla applikationen till en databas innehållandes
PL/SQL kod och liknande, den skapar alltså en JDBC-koppling till databasen utan att
man själv behöver skriva den. De verktyg som till slut har testats fullt ut är då SwisSQL
och Exodus. Dessa verktyg var de som skulle kunna utföra de uppgifter vi behövde.
26
Genomförande
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.
27
Genomförande
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.
28
Resultat
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.
29
Resultat
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 Htmlbaserat.
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.
30
Diskussion och slutsatser
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.
31
Diskussion och slutsatser
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.
32
Referenser
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-fromplsql-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)
[19] OrindaSoft http://www.orindasoft.com/public/features.php4 (Acc. 20011-03-30)
33
Referenser
[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
(Acc. 20011-05-26)
34
Bilagor
7 Bilagor
Bilaga 1 – Lista över SwisSQLs featueres and benefits.
Bilaga 2 – Lista över krav från Ciphersoft på den applikation som skall
konverteras
35