Xpmetodik inom Enterpriseutveckling
Sida 1 (10)
2005-02-22
Xpmetodik inom Enterpriseutveckling
1
2
3
4
5
6
7
8
9
2005-02-22
.............................................................................................. 1
........................................................................................................... 1
................................................................................................................. 1
Abstract .............................................................................................................................. 2
Introduktion ........................................................................................................................ 3
2.1
Enterprisesystem generellt ......................................................................................... 3
2.2
Trelagersarkitektur ..................................................................................................... 3
J2EE ................................................................................................................................... 4
3.1
Fördelar med J2EE. .................................................................................................... 4
3.1.1
Distribuerbart ..................................................................................................... 4
3.1.2
Skalbart............................................................................................................... 4
3.1.3
Möjlighet till RPC (Remote Procedure Calls).................................................... 4
3.2
Komplexitet hos EJB.................................................................................................. 5
3.3
Mer om containers...................................................................................................... 5
3.3.1
Utvecklingsroller ................................................................................................ 5
EJB ur ett eXtremt perspektiv ............................................................................................ 5
4.1
Collective code ownership ......................................................................................... 5
4.2
Contineous Integration ............................................................................................... 6
4.3
Simple Design ............................................................................................................ 6
4.4
Test First..................................................................................................................... 6
Varianter för lösningar ....................................................................................................... 6
5.1
Testning på applikationsservern................................................................................. 6
5.2
Mockobjekt................................................................................................................. 6
5.3
Strunta i att skriva explicita containers för affärslogik .............................................. 7
Lättviktiga containers ......................................................................................................... 7
6.1
Spring ......................................................................................................................... 7
6.1.1
Färdiga abstraktioner.......................................................................................... 8
6.2
Inversion of Control ................................................................................................... 8
Testbar kod ......................................................................................................................... 8
7.1
Singletons ................................................................................................................... 9
7.2
Statiska metoder ......................................................................................................... 9
7.3
Interface...................................................................................................................... 9
7.4
Verktyg för att förbättra testning................................................................................ 9
Fortsätta arbeta med Test First ........................................................................................... 9
Referenser: ....................................................................................................................... 10
Sida 2 (10)
Xpmetodik inom Enterpriseutveckling
2005-02-22
1 Sammanfattning
När webapplikationer utvecklas används en annan typ av arkitektur än vid lokala
applikationer. Webapplikationer tenderar att vara uppbrutna i flera mindre komponenter
som kommunicerar sinsemellan. För denna typ av system har en teknik speciellt utvecklats
vid namn J2EE (Java 2 Enterprise Edition)som låter kod skrivas generellt och därför kan
köras oberoende av maskinvara och andra systemkomponenter. För att realisera tekniken
används idag EJB (Enterprise Java Beans). Detta blir dock i längden mycket tungdrivet och
den arkitektur som följer av detta leder till att bland annat testning försvåras och särskilt
metodiken Test First.
Det här dokumentet presenterar olika tänkbara lösningar till problemet, bland annat The
Spring Framework som avhjälper de flesta svagheterna med EJB och samtidigt förenklar
utvecklingen och tillåter Test First.
2
Introduktion
XP är lämpligt att använda också för Internetbaserade system och miljöer, där
komponenter sätts ihop för att leverera tjänster som ska vara tillgängliga utåt.
Komponentbaserad utveckling kan lätt utföras med XP’s olika metoder eftersom
grundtankar kring arkitektur och uppbyggnad stämmer väl överrens. Exempelvis är
uppmaningarna inom Simple Design att hålla klasser och metoder på en hanterbar
storleksnivå lätta att anamma med de javabönor (javaobjekt i en webserver) som används
inom den här typen av utveckling. Det finns dock de tekniker som inte lika lätt följer med
till enterprisemiljöer (stora miljöer som ofta har flera servrar med programvaran
distribuerad mellan sig). Den här studien försöker klargöra krockar mellan metodiken och
arkitekturen samt eventuella lösningar till dessa
2.1 Enterprisesystem generellt
Det som utmärker ett system i enterprisemiljö är mycket det stora antal användare som
ska kunna ansluta till en eller flera datakällor. Detta ställer en hel del krav på systemet
som skiljer sig från andra typer av system. Därför blir också arkitekturen byggd på ett
helt annat sätt.
2.2 Trelagersarkitektur
När
en
webbaserad
applikation
utvecklas, bör den delas upp i tre lager.
Det första lagret är datalagret, ofta
bestående
av
en
eller
flera
relationsdatabaser. Ovanför detta ligger
lagret med affärslogik för att hantera
operationer och transaktioner.
Överst finns presentationslagret, detta är
ett användargränssnitt och bör endast
innehålla logik för att presentera
information
för
användaren
och
vidarebefordra kommandon ner till
affärslogikslagret.
Sida 3 (10)
Figur 1 De tre lagren i en Enterprisemiljö ska
kunna fungera oberoende av varandra
Xpmetodik inom Enterpriseutveckling
3
2005-02-22
J2EE
När större Internetbaserade system ska byggas, används ofta Java 2 Enterprise Edition
(J2EE) [2]. Detta på grund av arkitekturlösningen som tillåter återanvändning av
komponenter oavsett vilken typ av datakälla eller klient som används.
Lagren i J2EE är noggrant åtskilda logiskt och ofta också fysiskt.
Idén med J2EE är i grunden att kod ska kunna återanvändas. För att realisera det skapas
varje objekt tillsammans med interface för att systemet inte ska påverkas av att en del
byts ut. Alla anrop sker ändå mot interface. Vidare deklareras alla beroenden och
anslutningar till objekt i en XML-fil som kallas deployment descriptor. När detta är gjort
läggs alla objekt in i en container som hanterar beroenden, anslutningar och instansiering
av objekten. Denna container hanteras av J2EE-servern. Resultatet blir att objekten blir
oberoende av den miljö de körs i och de kan lätt användas i en annan arkitektur så länge
den stöder J2EE. Än så länge är standarden för att göra dessa containers och objekt
Enterprise Java Beans (EJB). En teknik som av de flesta utvecklare uppfattas som
omständlig och onödigt komplicerad.
Figur 2 [2] Arkitekturen i J2EE är baserad på containers. För att säkra oberoenden mellan lager i
EJB hanteras alla komponenter i containers där anknytningar till de andra lagen finns specificerade.
3.1 Fördelar med J2EE.
3.1.1 Distribuerbart
Systemet kan med lätthet läggas ut på flera datorer som kommunicerar sinsemellan
istället för att köra allting på samma maskin. Kommunikationen internt sköts av en
transaktionsserver som kan hantera anrop från gränssnittet hela vägen ner till datakällan
för att garantera dataintegritet.
3.1.2 Skalbart
I och med att lagren är så åtskilda kan de administreras var för sig, något som hjälper till
att eliminera flaskhalsar. Om till exempel applikationsservern skulle bli överbelastad sätts
bara en till dator in med samma data och efter en liten ändring i konfigurationen kommer
hela systemet använda sig av båda maskinerna, utan att ändra något i koden för
affärslogiken.
3.1.3 Möjlighet till RPC (Remote Procedure Calls)
Hela systemet kan kommunicera med olika klienter och andra system [2]. Det enda som
behövs är ett definierat interface utåt som skrivs för varje komponent. Dessa interface kan
sedan anropas från en web-klient, ett program lokalt på en användares dator eller ett
Sida 4 (10)
Xpmetodik inom Enterpriseutveckling
2005-02-22
annat system som är tillgängligt via Internet. Allt utan att skriva om någon kod i
affärslogiken.
Allt detta gör J2EE till ett otroligt kraftfullt verktyg vid utveckling av serverbaserade
applikationer. Den första arkitektur som lanserats för att realisera denna teknik är EJB
(Enterprise Java Beans). EJB har ett mycket utökat stöd för alla funktioner inom J2EE.
3.2 Komplexitet hos EJB
EJB kräver en mycket specifik arkitektur där alla komponenter måste användas i en
Container som specificerar olika typer av anslutningar till systemspecifika komponenter
och användningsområden.
Denna container läggs upp på en applikationsserver som låter de objekt som används
köras i ett lager mellan exempelvis en databas och ett webinterface, det så kallade
affärslogikslagret.
3.3 Mer om containers
En container är den miljö varje objekt körs i. En container definierar omvärlden för
objekten och låter dessa ansluta till datakällor och andra objekt utan att de behöver känna
till dessa direkt. Detta sparar mycket kodskrivande och tilllåter dessutom klasser, som är
skrivna för ett visst system, med en uppgift att köras på ett annat system där de kan utföra
samma uppgift i en helt annan miljö när de sätts i en ny container.
Dessa containrar kan dock vara ett problem då objekten blir beroende av dessa. Klasserna
kommer då inte att gå att köra utan sin container alls och det försvårar bland annat
testning.
3.3.1 Utvecklingsroller
Det faktum att EJB har så komplicerad integrationsprocess leder till att utvecklare inom
projektet tilldelas olika roller för att kunna sätta ihop alla komponenter till ett körbart
system. [2]
Enterprise Beanutvecklare
Utvecklar affärslogiken i små komponenter och packar dem i en .jar-fil.
Webkomponentsutvecklare
Skriver html och jsp/servlets och packar dem i en webkomponentsfil.
Klientapplikationsutvecklare
Utvecklar en eventuell klient till systemet och packar i .jar-fil
Applikationsassembler
Sätter ihop hela systemet i en .EAR fil som kan köras i applikationsservern
Applikationsadministratör
Kör systemet och specificerar anslutningar till databaser, filssystem och dylikt.
Detta är en komplex struktur för att sjösätta en applikation och leder till krockar med
en del XPmetodiker.
4 EJB ur ett eXtremt perspektiv
Vissa praktiker inom XP äventyras av det här sättet att utveckla. I texten nedan tas några
av de som kan vara i farozonen upp.
4.1 Collective code ownership
Det första en läsare som är insatt i XP kan tänkas reagera på är de specifika rollerna. Hur
går det ihop med collective code ownership till exempel?
Sida 5 (10)
Xpmetodik inom Enterpriseutveckling
2005-02-22
Eftersom de olika rollerna tar vid i olika stadier av utvecklingen och inte arbetar
tillsammans kommer inte samma kod skrivas av alla som är med i ett team.
Detta går dock att lösa genom att i större projekt se varje roll som ett mindre projekt med
ett XP-team i varje. I ett mindre projekt, som visserligen är mycket ovanligt med denna
typ av utveckling, kan det tänkas att utvecklarna får skifta roller under projektets lopp.
4.2 Continuos Integration
Vad gäller kontinuerlig integration kan det bli stora problem. Det är en omständlig
process att lägga till nyskriven kod till arkitekturen J2EE tillhandahåller. Därför drar sig
utvecklare för att lägga till kod de har skrivit i den gemensamma miljön i små omgångar.
Med rätt rutiner bör det dock gå, men det är viktigt att det finns arkitektur på plats under
utvecklingen. Utan en befintlig arkitektur som finns körbar kommer inte kod kunna
integreras alls eftersom komponenter inte går att köra enskilt.
4.3 Simple Design
En av huvudprinciperna inom simple design säger att man inte ska designa hela systemet
från start. Detta går inte så bra ihop med arkitekturen för EJB där all miljö måste kodas
först i anslutning till containers.
Lösningen på detta problem kan ligga i iteration 0. Eftersom iteration 0 innebär att
utveckla ett fungerande skelett för resten av programmet passar plötsligt de två
metoderna varandra mycket väl. Om de containers som behövs för att få systemet att
fungera görs först blir det en smal sak att designa metoder och klasser för varje enskild
story.
4.4 Test First
Ett större problem gäller testningen av applikationen. XP förespråkar Test First för att
minimera fel vid sammansättningen av systemet. I EJB-arkitekturen är dock varje
komponent så starkt knuten till sin container och sin applikationsserver att det ofta inte är
möjligt utan att skriva många mock-objekt, något som inom EJB är väldigt tidsödande
och dessutom inte går ihop med EJBs arkitektur. Dessutom kan aldrig systemet testas
som helhet från en arbetsstation eftersom varje komponent är beroende av hela systemet
för att kunna köras vilket verkligen försvårar eller omöjliggör test first.
Detta är alltså ett problem och texten hädanefter är i huvudsak inriktad på att lösa detta.
5 Varianter på lösningar
5.1 Testning på applikationsservern
Det finns olika verktyg (som Cactus) som tillåter skapandet av tester som körs på
applikationsservern. På så sätt kan vi skriva tester för varje böna och köra dem när vi väl
har lagt upp allting på servern. Problemet med denna approach är att det är omständligt
att sätta upp din just skrivna kod så att den körs (se avsnitt 3.3.1, utvecklingsroller).
5.2 Mockobjekt
Det finns sätt att skriva bra mockobjekt för EJB[6]. Detta är dock som nämnt ovan ett
omfattande arbete. Dessutom går det inte att testa många aspekter som beror på hur
objekt är relaterade till varandra och hittar varandra i EJBarkitekturen. Alltså skulle ett
objekt som kan hittas som mockobjekt i ett test kanske inte hittas i skarpt läge.
Sida 6 (10)
Xpmetodik inom Enterpriseutveckling
2005-02-22
Figur3 [3] En traditionell arkitektur som körs på en J2EEserver. Implementation och
presentationslager är här lagt i samma container, något som förenklar arkitekturen men tar bort
mycket fuynktionalitet. Notera att det fortfarande rör sig om en trelagersarkitektur där
implementationen har ett interface mot gränssnittslagret.
5.3 Strunta i att skriva explicita containers för affärslogik
En metod kan vara att strunta i de containers som EJB är så beroende av. Detta leder till
att vi måste använda vanliga javaobjekt (Pojos) och vi förlorar då många fördelar med
arkitekturen i EJB som automatisk transaktionshantering och miljökonfiguration. Vi är i
stort tillbaka på nivån som vi var på innan vi införde J2EE överhuvudtaget.
I Figur 3 syns arkitekturen för ett system utan EJB. Som läsaren ser är nu logik och
presentationslogik inbyggda i samma container och kan därför komma åt varandra lättare.
Fortfarande är dock de två lagren logiskt åtskilda och vi behöver inte ändra i affärslogik
för att byta presentationsmiljö.
Denna metod gör dock att vi förlorar många fördelar med J2EE och vi får en mängd nya
nackdelar. Det blir nu komplicerat att lägga till nya gränssnitt och datakällor igen.
För att kunna dra nytta av EJBs fördelar, som transaktionshantering, behöver vi någon
form av containers. Dessa får dock inte vara ett krav för att systemet ska gå att köra eller
testa.
6 Lättviktiga containers
6.1 Spring
Spring framework [4] är ett ramverk som har byggts för Enterpriselösningar för att
förenkla utvecklingen av dessa.
I Spring finns också containers som i EJB men de containers som används här, sk.
Lightweight containers, har stöd för Pojos (Plain Old Java Objects), dessa klasser skulle
Sida 7 (10)
Xpmetodik inom Enterpriseutveckling
2005-02-22
alltså kunna skrivas och testas i en vanlig miljö för att sedan placeras i servermiljön och
köras skarpt i sin container.
Anledningen till att detta fungerar är just att helt vanliga javaklasser kan köras i dessa
containers samtidigt som de får de fördelar som EJB-containrar ger. Det blir alltså lätt att
skriva enhetstest och i vissa fall även inkludera en hel container i ett JUnit-test för att
göra integrationstester.
Dock är det fortfarande väldigt annorlunda att testa mot ett ramverk än fria klasser.
Figur 4 [3]Lightweight. Här syns implementationen med lightweight contatiners. Ovanför datakällan
läggs ett lager för att mappa objekt mot relationsdatabasens entiteter. Allt körs på samma Virtual Java
Machine och vanliga javaobjekt (pojos) med tillhörande interface används mot gränssnittet (UI)
6.1.1 Färdiga abstraktioner
Spring innehåller abstraktioner av olika API:er och ger flera olika interfaces som det är
lätt att bygga mockobjekt till och därför testa mot.
Andra funktioner, som transaktionsstatus, kan också lätt fås med hjälp av Spring. Det
finns speciella regler satta i spring för att sköta detta och det går lätt att kontrollera
reglerna genom olika delar i API:t. Anropen till dessa regelkontroller går lätt att överlagra
eller lägga i interface och på så sätt behöver de inte påverka testningen till skillnad från
EJB där ständigt olika regler måste kontrolleras och ställas in.
6.2 Inversion of Control
Ett mycket kraftfullt mönster för att göra implementationen oberoende av de interface
och containers som används kallas Inversion of Control.
Om utvecklare använder mönstret IoC, eller Dependency Injection [5], kan objekten
göras fullt testbara trots att de i skarpt läge körs inuti sina containers.
7 Testbar kod
För att göra koden mer testbar kan det vara lämpligt att hålla på några principer. [3]
Sida 8 (10)
Xpmetodik inom Enterpriseutveckling
2005-02-22
7.1 Singletons
Singletonklasser är klasser som endast tillåts i en instans i hela systemet. Det kan vara en
fördel när information ska hållas centralt och tillgängligt för alla andra objekt.
Singletons är därför populära inom Enterpriseutveckling eftersom de kan användas som
en tjänst för att leta upp rätt objekt åt ett annat objekt. Dessa blir dock mycket svårare att
testa eftersom det krävs att ditt test känner till singeltonklassen och därför en stor del av
systemet.
7.2 Statiska metoder
En annan metod för att göra metoder och attribut tillgängliga i hela systemet är att
deklarera dem statiska. Detta leder dock också till problem eftersom alla klasser måste
vara relaterade till de statiska metoderna och det försvårar testning ytterligare.
7.3 Interface
Att använda interface istället för statiska metoder är att tillråda. Det är lätt att
programmera mot ett existerande interface och när vi testar det kan vi enkelt sätta in
något mockobjekt som implementerar ett interface i testsyfte och sedan byta detta objekt
mot ett riktigt i skarpt läge.
7.4 Verktyg för att förbättra testning
Det finns olika verktyg för att underlätta testning. De som automatiskt genererar test kan
vara bekväma att använda men bör inte användas i syftet att undgå att skriva egna tester.
Det går helt enkelt inte att få tillräckligt bra tester helt automatiskt, utan utvecklaren
måste själv arbeta med detta kontinuerligt.
Däremot finns det verktyg för att kontrollera hur väl testningen faktiskt täcker systemet.
Ett riktigt bra verktyg kan hitta otestad kod ner till enskilda try-catchblock.
Ett exempel på ett sådant verktyg finns på http://www.thecortex.net som täcker upp tester
med JUnit.
8 Fortsätta arbeta med Test First
Om vi använder oss av dessa förhållandevis enkla metoder och ramverk så visar det sig
att det faktiskt är möjligt att göra riktigt avancerade enterpriseapplikationer och
fortfarande använda sig av XPs metodiker, inklusive Test First. Spring med flera kan
därför anses vara svaret på hur denna metodik ska kunna förenas med
Enterpriseutveckling.
Att kunna ha testdriven utveckling leder ofta till säkrare och stabilare applikationer och
spridning av den här metodiken blir därför allt större. Troligen kommer fler tekniker som
Spring dyka upp då det blir lättare och billigare att utveckla i det och dessutom ger
utvecklarna mindre begränsningar. Faktum är att många av de som förespråkar
Springramverket också förespråkar många av de praktiker som används inom XP, något
som kan anses som ett bevis för att de fungerar bra tillsammans.
Sida 9 (10)
Xpmetodik inom Enterpriseutveckling
2005-02-22
9 Referenser:
1) J2EE – Java 2 Enterprise Edition (http://java.sun.com/j2ee/)
2) The J2EE™ 1.4 tutorial
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html
3) Rod Johnson - Expert One on One J2EE Development Without EJB - Wiley
Publishing 2004 (bilder och material)
4) http://www.springframework.org/
5) (http://www.martinfowler.com/articles/injection.html
6) (www.mockejb.org/).
Sida 10 (10)
