Teknisk utvärdering Open ePlatform
- Per Persson
- Jari Koponen (Unlicensed)
Syfte
Syftet med upprättandet av detta dokument är att;
Utvärdera och beskriva möjligheterna att bedriva utveckling i applikationsramverket Open ePlatform för en tredje part
Att förstå förutsättningar för att säkerställa kontinuitet vid en krishändelse hos befintlig leverantör (Nordic Peak) som en uppföljning av tidigare genomförd analys 2019:
Den tekniska utvärderingarna är utförda av en senior Java-utvecklare och återger dennes erfarenheter och åsikter om ramverket och dess potential.
Sammanfattning
Utvärderingen visar att vi står i stort sett i samma läge som analysen 2019 ur ett tekniskt och beroendeperspektiv
Vi bedömer att det inte går för en tredje part att bedriva utveckling av Open ePlatform utan här finns ett totalt beroende till Nordic Peak
Vi bedömer dock att Sundsvalls kommun och eSamverkan-kommunerna, med vår interna drift av Open ePlatform skulle kunna ta över och bedriva utveckling vid en krishändelse hos Nordic Peak under förutsättning att vi har tillgång till senaste version av källkod (se nästa punkt). Detta skulle dock innebära att vi skapar en egen version av Open ePlatform samma tid som vi börjar bedriva utveckling och tappar då möjligheten allt eftersom att dela utveckling med övriga kommuner. Vid krishändelse måste vi dock primärt se till våra egna kommuners perspektiv.
För att öka förutsättningar för kontinuitet vid kris behöver vi upprätta en rutin där vi har ständig information om vilket repo/vilken branch som vår produktionsinstans kör, inkluderat information om varje dependency som finns till tredjepartsbibliotek. Utöver detta behöver vi ha tillgång till all denna källkod i korrekt version för varje produktionsrelease.
Exempelvis genom att varje release till oss medföljs av en överföring av källkod till vår SVN eller i en ZIP-fil
Actions
Upprätta en dialog med Nordic Peak om att säkerställa rutiner och tillgång till källkod för varje release (punkt 4 i sammanfattningen)
Informera eSamverkan om resultatet
Informera användarföreningen för Open ePlatform om resultatet
Bakgrundsinformation
För att visa transparens och ge läsaren en möjlighet att förstå de förutsättningar utvärderaren hade inför denna utvärdering, vill vi understryka att denne helt saknade tidigare erfarenhet av Open ePlatform. Detta var dennes första kontakt med applikationsramverket.
Utvärderaren har däremot ca. 25 års erfarenhet av utveckling i programspråket Java, varav knappt 20 år som yrkesutövande systemutvecklare i detta programspråk.
Genomförande
För att bekanta sig med Open ePlatform och snabbt komma igång med utvärderingen av mjukvaran bestämde utvärderaren sig för att sätta upp det demo-projekt som finns tillgänglig för nedladdning här: svn://svn.sundsvall.se/oep-dev/designs/demo.oeplatform.org.
Detta demo-projekt ser vid en första anblick ut att vara en referensimplementation/instans av Open ePlatform. En beskrivning av hur man kommer igång finns att läsa i dokumentet “Open ePlatform – Dokument för utvecklare”.
I texten nedan återges upplevelser och erfarenheter kring arbetet med att sätta upp demo-projektet. Både vad avser själva miljökonfigurationen, men även intryck av kod, struktur, ramverk, etc. i Open ePlatform.
Det är möjligt att vissa saker som tas upp i texten innehåller felaktigheter, att det finns kod som inte har setts eller att arbetet med att sätta upp demo-projektet inte är helt korrekt utfört. Dokumentet “Open ePlatform – Dokument för utvecklare” har dock följts så långt det bara är möjligt och nedan återges erfarenheterna utifrån det.
Uppsättning av demo-projekt
Källkod
Det första man behöver göra är att installera en Subversion-klient. Detta eftersom alla “repositories” ser ut att ligga i Subversion. Detta är ett avsteg från aktuell industristandard. Idag används nästan uteslutande Git för källkodshantering. Varför man har valt att hålla fast vid Subversion känns oklart?!
Nästa steg är att identifiera koden som skall hämtas ut från Subversion. Vanligtvis klonar/hämtar man ett repository och får all kod som krävs. I detta fall verkar dock kodbasen ligga utspridd på många projekt, repositories och t.o.m. på helt skilda domäner. Bl.a. krävs det att man länkar in “hjälp-projekt” från http://www.unlogic.se.
Denna hemsida har karaktären av en “hobbysida” och verkar drivas av en privatperson. Privata semesterbilder, varvas med hobbyprojekt inom mjukvaruutveckling. På denna domän host:as även de subversion-repon som används av applikationen. Dessa återfinns här: http://www.unlogic.se/projects
Tredjepartsbibliotek
Open ePlatform använder sig av många olika tredjepartsbibliotek. Detta är inget konstigt i sig. Det är t.o.m. något man ofta brukar kunna förvänta sig av system byggda i t.ex. Java.
Det som däremot är anmärkningsvärt är att man inte använder sig av något verktyg för “dependency managment”. Idag är nämligen Maven, Gradle och liknande verktyg att betrakta som industristandard. Verktygen hjälper utvecklare att hämta och hålla reda på såväl direkta som transitiva beroenden, helt automatiskt.
Kombinerar man Maven/Gradle med verktyg som t.ex. Dependabot får man en automatiserad och regelbunden kontroll av sårbarheter i tredjepartsberoenden. Man får även hjälp att hålla dem uppdaterade.
Det kunde inte hittas några sådana inbyggda mekanismer under denna utvärdering av Open ePlatform.
Istället verkar alla beroenden ligga utspridda i subversion-repon som egna projekt (ett projekt per beroende). Dessa beroenden tillhandahålls via subversion-servern på http://unlogic.se (svn://unlogic.se/utils/libraries).
Även om applikationsramverket började byggas innan dessa verktyg fanns (Maven v2 släpptes 2005), ställer vi oss frågande till varför man har valt att inte modernisera denna hantering? Vilka fördelar ser man med att hantera dessa beroenden manuellt (på en subversion-server)?
Servletcontainer
Dokumentationen hänvisar till installation av en separat servletcontainer (t.ex. Tomcat). Detta känns onekligen omodernt. År 2022 brukar man vanligtvis använda Tomcat och liknande servrar i form av en “embedded servletcontainer” vid användning av Java-applikations-ramverk, (som Open ePlatform utger sig för att vara). Ett exempel på en sådan tillämpning av Tomcat finns i t.ex. Spring Boot.
Dokumentationen hänvisar även till en utdaterad version av Servlet-specifikationen som släpptes 2003.
(Den senaste versionen av denna specifikation är 6.0. Mer info: Jakarta Servlet )
Citat från dokumentationen “Open ePlatform – Dokument för utvecklare”:
”Open ePlatform är i grunden en Java webbapplikation baserad på OpenHierarchy
plattformen (http://openhierarchy.org) som i sin baseras på Servlet 2.4
specifikationen”
Vi ställer oss frågande till varför koden inte moderniserats och anpassats till senare versioner?
Konfigurering av utvecklingsmiljö med hjälp av dokumentation
Under uppsättningen av min utvecklingsmiljö följdes dokumentationen “Open ePlatform – Dokument för utvecklare” (2019-11-11). Trots detta stötte utvärderaren på en del problem. Det är möjligt att det finns senare versioner av denna dokumentation? Eftersom utvärderaren inte har tagit del av någon nyare version så baserades miljökonfiguration på dokumentet som är daterad 2019-11-11.
I tabellen nedan är beskrivit de problem som uppstod, samt kommentarer gällande dessa.
Problem | Kommentar |
|---|---|
Dokumentationen refererar till nödvändiga projekt med hjälp av en screenshot på en IDE. Inga hänvisningar till rätt sökväg/repository finns för ingående projekt/beroenden. | Det är tidsödande att leta reda på dessa manuellt. Det vore önskvärt om varje nödvändigt projekt kunde anges med en korrekt hänvisning till aktuellt repository/sökväg. |
Projektet "OpenPDF" krävs av demo-projektet, men anges inte i dokumentationen. | Felsökning och åtgärd bidrar till ökad tidsåtgång.
|
Projektet "ServletAPI" krävs av demo-projektet, men anges inte i dokumentationen. | Felsökning och åtgärd bidrar till ökad tidsåtgång. |
Projektet "EmailUtils" använder javax.activation.DataHandler från projektet "Activation". Detta var ej definierat i utcheckad classpath-fil. Nedan classpath-entry fick läggas till manuellt: | Felsökning och åtgärd bidrar till ökad tidsåtgång. |
Det visade sig vara nödvändigt att editera java.policy för att kunna köra applikationen. Detta nämns ej i dokumentationen. | Med reservation för att detta “problem” inte existerar i äldre Java-versioner, så är det konstigt att man inte nämner detta? Utvärderaren använder trots allt Java 17 som är en LTS-version (och som därmed torde kunna antas användas av många utvecklare). |
Vissa enum-värden i en av klasserna i StandardUtils-projektet kompilerade inte (till synes p.g.a. fel tecken-encoding). | Det var tvunget att ersätta vissa tecken i StandardUtils/src/se/unlogic/standardutils/i18n/Language för att det skulle funka: Norwegian_Bokm�l("nb"), |
MySQL-drivern krävs av demo-projektet, men anges inte i dokumentationen. | Felsökning och åtgärd bidrar till ökad tidsåtgång. Den finns inte heller tillgänglig bland övriga tredjepartsbibliotek. Man tvingas leta reda på den på Internet. (Den driver som anges i demo-projektet är com.mysql.jdbc.Drive. Denna är för övrigt markerad som “deprecated” för flera år sedan) |
När demo-projektet startas körs ett flertal DDL/SQL-script automatiskt. Vissa misslyckades p.g.a. olika constraint-violations. | Trots dokumentationen följts och laddat databasen med det script som finns i demo-projektets db-katalog blir det flera databasfel (constraint-violations) vid uppstart. Utvärderaren var tvungen att ta bort ett par queries i FlowEngine/src/com/nordicpeak/flowengine/dao/'DB script.xml' (query i script:69 samt sista query i script:137) Har man verkligen testat att köra detta demo-projekt? |
Vid uppstart får man följande fel: [ERROR] [2022-11-15] [15:19:44] ForegroundModuleCache.cacheModules Error caching new instance of module Mina favoriter (ID: 170, alias: myfavourites) for section Hem (ID: 1, alias: ) se.unlogic.hierarchy.core.exceptions.ModuleInstasiationException: java.lang.ClassNotFoundException: com.nordicpeak.flowengine.UserFavouriteForegroundModule | Har ej hittat lösning på detta problem då klasserna som orsakar java.lang.ClassNotFoundException mycket riktigt saknas. Oklart var dessa finns? |
Summering
Utvecklingsmiljö
Trots problem vid uppsättningen av applikationen fick utvärderaren till slut igång en webbapplikation som svarade på anrop, enligt exemplet från dokumentationen.
För att få igång detta är man dock varit tvungen att importera följande projekt (bild från utvecklingsmiljö) Bild-3.
Utvärderarenhar aldrig varit med om att en webbapplikation kräver denna mängd av Eclipse-projekt för att fungera. Det känns faktiskt helt bisarrt och man kan inte sluta förundras över valet att inte gå över till Maven, Gradle eller liknande verktyg. Inte ens i utvärderarens dagliga arbete med utveckling av microtjänster (som över tid kan bli många till antalet) har utvecklingsmiljön haft detta utseende.
Det är även tydligt att det är IDE:n Eclipse som skall användas. Alla publicerade projekt är skapade som Eclipse-projekt. Dokumentationen förutsätter även att denna IDE används.
Även om detta inte berör utvärderaren personligen (som använder Eclipse i sitt dagliga arbete) är det en mycket otrevlig inlåsningseffekt. I våra API-team använder t.ex. mer än hälften av medlemmarna andra IDE:er än just Eclipse.
Att konstruera sina projekt och utvecklingsprocess mot en specifik IDE känns som ett tankefel. Det skapar onödiga tredjepartsberoenden och en försvårad utvecklingsprocess. I synnerhet om man (som många gör) använder andra IDE:er.
Kodkvalitet
Under arbetets gång har utvärderaren givetvis öppnat upp koden och tittat igenom delar av den. Dels för att åtgärda problem i “demo-projektet”, men även av ren nyfikenhet.
Överlag känns struktur, kod, ramverk, verktyg, osv. föråldrad och otidsenlig. Enligt utvärderarens personliga åsikt är “bäst-före-datum” passerat för länge sedan. Man får nästan intrycket av att mjukvaran precis plockats fram ur en tidskapsel från 2005. Det kan låta raljant, men uttrycker väldigt väl den spontana känsla som infinner sig.
Ett axplock av de tveksamheter som noterats och som kan betraktas som avsteg från god kodstandard är:
Blandning av presentationslogik och affärslogik. Bilder, HTML-sidor, css-filer, etc. ligger blandat med Javakod (se: bild-1)
SQL (för databas-operationer) ligger inbäddat i javakoden. Det har länge varit praxis att istället använda persistence-API:er, t.ex. JPA. (se: bild-2)
Eftersom det är lätt att låta sig färgas av sina egna bestämda uppfattningar och åsikter när kodkvalitét skall bedömas, valdes att öka objektiviteten genom att låta utföra en kodanalys med verktyget SonarLint. Detta verktyg analyserar koden och rapporterar “code smells”, sårbarheter, buggar och övriga avsteg från god programmeringssed.
Det valdes att endast analysera projektet “OpenHierarchy”. Det har inte analyserat något av de “hjälp-projekt” som också vävts in i produkten.
Resultatet får tala för sig självt och finns att ta del av i bifogad Excel-fil: sonar-issues.xlsx.
Tester
Även om det givetvis går att arbeta med kodstandard av lägre kvalitét upptäcktes saker som är mer besvärande. Den viktigaste av dessa upptäckter är att inbyggda enhets- och applikationstester helt saknas (utifrån vad som går att se). Detta gör att man funderar över följande:
Hur säkerställer man bibehållen funktionalitet vid refaktorering?
Hur förhindrar man regression? D.v.s hur undviker man att introducera buggar vid ny- och vidareutveckling?
Att skriva tester i samband med ny- och vidareutveckling av funktionalitet, hör till en av de saker vi tar för givet idag. Det är någonting man bara gör. En självklarhet!
Att försumma detta anser vi vara en allvarlig avvikelse vilket naturligtvis minskar förtroendet för mjukvaran.
Disclaimer:
Det skulle kunna vara så att tester faktiskt existerar, men att de ligger undangömda någonstans? Det har dock inte setts någonting som tyder på det.
Övrigt
Ytterligare en faktor som känns riskabel är att många “hjälp-projekt” ligger på en tillsynes privat hemsida (av hobbykaraktär). Visserligen är upphovsmannen en frontfigur i företaget bakom Open ePlatform, men det torde oavsett innebära ett ganska hårt beroende mot denna person?
Följande frågor dyker upp:
Vad händer med dessa projekt när upphovsmannen av någon anledning inte längre tillhandahåller denna hemsida?
Omfattas även denna kod av det avtal kommunen har med företaget bakom Open ePlatform? Har Sundsvalls kommun t.ex. möjlighet att anpassa koden vid behov?
Slutsats
Efter att ha bekantats med Open ePlatform under några dagar, ser vi problem med att införliva utveckling av denna produkt av en tredje part, i t ex API-teamen. Problemen bottnar i att följande saknas:
Tester
Acceptabel kodstandard
Verktyg för “dependency management”
Möjligheter att använda andra IDE:er än Eclipse (utan anpassningar)
Förutsättningar till ett modernt arbetssätt. Väldigt få av the “common practices” som nämns här känns möjliga i produktens nuvarande skick: Continuous integration
Att korrigera dessa punkter (som är fundamentala beståndsdelar i modern systemutveckling) är naturligtvis möjligt, men skulle ta mycket tid i anspråk. Även för erfarna systemutvecklare.
Sålunda kan vi inte skala upp utvecklingstakten i Open ePlatform genom att tillsätta externa resurser och är 100% beroende av leverantören (en av leverantören skapad inlåsningseffekt).
Bristerna ovan genererar även signifikanta säkerhets- och stabilitetsrelaterade risker i vidareutvecklingen av Open ePlatform, oavsett vem som utvecklar den.
Bilagor
Open ePlatform - Sonar issues
Open ePlatform – Dokument för utvecklare
Bild-1 (Presentation och logik blandat)
Bild-2 (inbäddad SQL i Java-kod)
