Implementations vy

Innehåll:

Tillgång till källkoden

Se Instruktioner för utvecklare.

Översikt

Implementationen av engagemangsindex följer en traditionell lagerindelning:

• Integrationslager
  Hanterar all extern och intern kommunikation inklusive hantering av transaktioner, loggning fel och omsändning.
  Detta lager har beroenden till Mule CE som ESB och använder Apache Camel, och ansluter till Apache ActiveMQ som JMS provider.
  
  
• Verksamhetslager
  Innehåller regelverk som följer regler i tjänstekontraktet för engagemangsindex.
  Detta lager är implementerat som rena Java klasser (POJO's) och använder Spring Framework för att hantering av beroenden i runtime (DI).
  
  
• Persistenslager
  Hanterar lagring och sökning av engagemangsindex-information i databasen.
  Detta lager är beroende av JPA 2.0 samt Spring Data. För lokala tester används en HSQL in-memory databas och för externa tester används MySQL.
  Persistenslagret kan konfigureras för att använda andra databaser som MS SQL Server, IBM D2 eller Oracle.

...

Följande bild återger källkostrukturen ner på Maven modul och därmed Eclipse projekt nivåMavenmodulnivå:

Image RemovedImage Added

Foldrarna innehåller följande projekt:

• applicationsmule-backend-app
  Applikation avsedd att driftsättas på en Mule instans skltp-ei-application
  Spring Boot-applikation för att köra front- och backend som en kombinerad tjänst
• skltp-ei-backend
Spring Boot-applikation med alla komponenter förutom update-service och notification-service som som ligger i frontend app'en
  mule-frontend-app
  Applikation avsedd att driftsättas på en Mule instans
• skltp-ei-common
  Innehålller kod som delas mellan frontend och backend
• skltp-ei-data-model
  Innehåller källkoden för persistenslagret.
• skltp-ei-frontend
Spring Boot-applikation med komponenterna update-service och notification-service.
  Not: Så länge frontend -appen är uppe så kan EI ta emot uppdateringar även om backend -appen och dess databas är nere för t ex underhåll.web
• skltp-backend-app
  Motsvarande app som mule-backend-app fast avsedd för att driftsättas på en servlet-kontainer typ Tomcat som en war-fil.
  web-frontend-app
  Motsvarande app som mule-frontend-app fast avsedd för att driftsättas på en servlet-kontainer typ Tomcat som en war-fil.
  compositesschemaei-schemas
Innehåller de tjänstekontrakt som implementationen exponerar och/eller konsumerar.
svc
  Innehåller källkoden för verksamhetslagret samt persistenslagret.
  
• modules
  • intsvc
    Innehåller källkoden för integrationslagret.
• skltp-ei-teststub
  Stubbar för att underlätta testning

Följande modell beskriver de mest centrala källkodsartefakterna samt var de finns placerade i källkodsträdet:

Image Removed

Integrationslager

TBD, beskrivs implemetnation av centrala mekanismer såsom transaktionshantering, omsändning, loggning, felhantering

Verksamhetslager

TBD

Image Added

Persistenslager

Detta lager är baserat på JPA 2.0 samt Spring Data och Hibernate. För lokala tester används en HSQL in-memory databas och för externa tester används MySQL.
Persistenslagret kan konfigureras för att använda andra databaser som MS SQL Server, IBM D2 eller Oracle, men har endast verifierats med MySQL.

...

Tabellen ser ut enligt:

engagement_index_table

Förutom primärnyckeln som är id så finns ett sökindex med namnet engagement_search_index.

...

Observera att användningen av en teknisk primärnyckel inte förändrar det faktum att man inte under några omständigheter kan ändra på någon del av verksamhetsnyckeln, dvs. utifrån detta perspektiv är det exakt samma hantering som om verksamhetsnyckeln hade används som primärnyckel. Därför har varje fält som ingår i verksamhetsnyckeln markerats med en JPA indikator om att fältet ifråga inte ska uppdateras.

Tidstämpel

Det finns som sagt 3 fält av typen tidstämpel, och samtliga förväntas två av dessa creation_time och update_time hanteras till fullo av verksamhetslagret, dvs. persistenslagret sätter eller ändrar för närvarande inte dessa tidstämplar. Däremot säkerställs att creation_time endast sätts första gången en post skapas i databasen, dvs. den uppdateras inte efter detta.   . För att update_time ska ändras måste posten ändras och detta görs endast när värdet på most_recent_content ändras.

Sökningar

För sökningar används springs JPA repository interface, där sökningar definieras antingen med namnkonvention eller med SQL (JPQL) satser. För närvarande krävs fälten registered_resident_id och service_domain för sökningar i enlighet med findContent meddelandet, och detta skiljer sig från den nuvarande specifikationen (RC10).

Om tidstämpel är angiven (most_recent_content) så returneras alla poster som har ett värde som är större eller lika med detta. För samtliga övriga fält måste värdena vara exakt lika.

Transaktioner

Precis som förespråkas i tjänstekontraktsbeskrivningen så krävs ingen särskild transaktionskonsistens när man läser data, dvs. man tillåter så kallade "dirty reads" om nu den underliggande databasen tillåter detta. Självfallet måste alla skrivningar hanteras på ett atomärt och konsistent sätt, även om man tillåter sk. "dirty reads".

...

• Vid sökning av flera poster med hjälp av primärnyckeln används en "IN" sats och vissa databaser kan kan ha begränsningar med avseende på batch-storleken för denna typ av anrop
• Längden på några av kolumnerna kan möjligen överskrida någon begränsning
• Det kan finnas effektivare sätt att lagra informationen på, dvs. sökindex och tabelldata kan mycket väl slås ihop för denna typ av data. I MySQL fallet lagras tabell och index var för sig.
• Det kan finnas effektivare sätt att indexera på då den primära nyckeln passar utmärkt i et för ett "hash" index. MySQL och InnoDB är begränsat till B-Tree

...