Tillgång till källkoden

Se Instruktioner för utvecklare.

Valet av Mule ESB

För att uppnå robusthet, skalbarhet, möjlighet till framtida utökningar, och utnyttja redan skriven och testad kod nyttjar vi en ESB som grundplattform. Produkten Mule ESB har valts.

...

Strategin för bakom beslutet var att utgå ifrån marknadens mest etablerade öppen-källkod-ESB. Mule ESB intar här en särställning helt utan konkurrens. Mule ESB har sedan utvärderats med avseende på de krav som ställdes på virtualiseringsplattformen. Utvärderingen genomfördes inkrementellt under projektet, där kraven realiserades i prioritetsordning fram tills en eventuell signifikant brist i Mule ESB upptäckts. Även om Mule ESB bedömdes vara marknadens i särklass mest utbredda ESB inom öppen källkod, är stödet för just tjänstevirtualisering relativt nytt. Det kan förmodligen förklara att en defekt kring hanteringen av ömsesidig identifiering med SSL/TLS upptäcktes under lasttest. Efter att ha kontaktat leverantören Mule Source och klargjort betydelsen av detta projekt, prioriterade leverantören den inrapporterade defektrapporten och levererade en uppdatering till projektet inom 24 timmar.

...

Denna tjänst använder ett internt meddelande format enligt bilden nedan.

Utveckling

All källkod för projektet finns upplagt som Open Source på http://code.google.com/p/skltp/

Maven

För att bygga en version av TP används Maven (version 2.0.9). TP innehåller 2 olika parent POM:ar. Dels för att bygga själva TP och dels för att bygga referensapplikationen (tp-journalinfoapoteket-exempel). Kommandot mvn clean install genererar alla artefakter samt kör alla enhetstester.

Eclipse

Projektet har använt Eclipse som utvecklingsmiljö. För att generera eclipse projekt från medföljande kodbas används Maven (mvn eclipse:eclipse).

Exceptions

...

Exceptions

Felsituationer rapporteras av virtualiseringsplattformen enligt VP standariserade felkoder . Om ett fel uppstår loggas det och ett VpSemanticException kastas. Det görs senare om till SoapFaultException vilket är den exception som når klienten.

...

För att styra loggnivåer i virtualiseringsplattformen är det alltså sista raden som ändras till INFO eller DEBUG. Loggningen skapas i en fil som heter vp.log och ligger i foldern logs under MULE_HOME. Man kan också styra hur Mule själv loggar som står beskrivet i Readme under logs i muledistributionen "Application-level logging is configured in the file "conf/log4j.properties" (by default all output is sent to the console). System-level logging is configured in the file "conf/wrapper.conf" (by default all output is sent to the file "logs/mule.log" Note that, unless the application is run in the foreground (i.e., not as a daemon), this means that while the application itself is configured to send its output to the console, the wrapper receives the console output and sends it to the log file. In addition to the application's output, the wrapper also sends any JVM-level or OS-level errors/warnings to the log file. This means that if the JVM crashes and automatically restarts (enabled by default), the time and cause of the crash will remain in the log file after the JVM restarts."

Enhetstester

Varje delkomponent som byggs innehåller enhetstester. Kod och konfigurering för dessa återfinns enligt standard Maven projekt struktur under src/test.

Lasttester

Kapitlet i Tjänsteplattformen_SoftwareArchitecureDocument.pdf (Version A) är inte aktuellt?