Sida 1 (10)
... 1... 1... 1 1 Abstract... 2 2 Introduktion... 3 2.1 Enterprisesystem generellt... 3 2.2 Trelagersarkitektur... 3 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 4 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 5 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 6 Lättviktiga containers... 7 6.1 Spring... 7 6.1.1 Färdiga abstraktioner... 8 6.2 Inversion of Control... 8 7 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 8 Fortsätta arbeta med Test First... 9 9 Referenser:... 10 Sida 2 (10)
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. Figur 1 De tre lagren i en Enterprisemiljö ska kunna fungera oberoende av varandra Sida 3 (10)
3 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)
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)
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)
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)
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)
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)
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)