Implementations vy
Innehåll:
Innehållsförteckning |
---|
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å:
Foldrarna innehåller följande projekt:
applications
mule-backend-app
Applikation avsedd att driftsättas på en Mule instansskltp-ei-application
Spring Boot-applikation för att köra front- och backend som en kombinerad tjänstskltp-ei-backend
Spring Boot-applikation med alla komponenter förutom update-service och notification-service som som ligger i frontend app'enmule-frontend-app
Applikation avsedd att driftsättas på en Mule instansskltp-ei-common
Innehålller kod som delas mellan frontend och backendskltp-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.webskltp-
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.composites
schema
ei-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:
Integrationslager
TBD, beskrivs implemetnation av centrala mekanismer såsom transaktionshantering, omsändning, loggning, felhantering
Verksamhetslager
TBD
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
Kolumnnamn | Null | Primär- nyckel | Del av logisk- nyckel | Typ och Längd |
---|---|---|---|---|
id | Nej | X |
Varchar(64) | ||
registered_resident_ |
id | Nej |
X | Varchar(32) | |
service_domain | Nej |
X | Varchar(255) | ||
categorization | Nej |
X | Varchar(255) | ||
logical_address | Nej |
X | Varchar(64) | ||
business_object_instance_ |
id | Nej |
X | Varchar(128) | ||
source_system | Nej |
X | Varchar(64) | ||
data_controller | Nej |
X | Varchar(64) | ||
owner | Nej |
X | Varchar(64) | |
clinical_process_interest_id | Nej |
X | Varchar(128) | |
creation_time | Nej |
Timestamp | ||
update_time | Ja |
Timestamp | |||
most_recent_content | Ja |
Timestamp |
Förutom primärnyckeln som är id så finns ett sökindex med namnet engagement_search_index.
...
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
...