CQRS, -ES, PACS, DICOM, WTF?

Transkriptio

1 CQRS, -ES, PACS, DICOM, WTF?

2 Ajankohtaisuuksia harjoitustyöhön liittyen aavan+viiden+vuoden+aikana/a Vähän vanhempia juttuja: esta/

3 Yleisesti: hypestä unohdukseen Ohjelmistoalan muoti-ilmiöt: 1. Uusi idea/tekniikka: rohkeat uudet käyttäjät 2. Isompi huomio, hehkutus yms. (joko koko alalla tai jonkun genren sisällä) 3. Laajempi huomio 1. Yleisesti käytettävissä oleva: arkipäiväistyminen 2. Erikoistapauksiin soveltuva: kritiikki, on anti-jotain 4. Unohdus 5. Paluu kohtaan 1 uudella nimellä hieman muokattuna

4 CQRS Mikä on CQRS:n perusidea? Eriytetään muutospuoli ja näkymäpuoli omiksi osikseen Mitä hyötyjä ja mitä ongelmia tekniikan käytöstä voisi olla? Skaalautuvuus, kaksi yksinkertaista mallia yhden monimutkaisen sijaan, optimointi molemmille osille erikseen, testattavuus, katselmoitavuus, muuttavan puolen tarkempi testaus, kyselypuoli ei voi sotkea dataa, focus on business? Mitkä sovellusalueet sopisivat tekniikan käyttöön? Lippujen myynti, verkkokaupat (iso osa toiminnasta), karttapalvelut, jne. Missä tilanteissa tekniikka taas olisi huono valinta? Jos käyttäjä haluaa nähdä heti muutosten vaikutukset Käyttäjän toimenpiteiden välitön varmentaminen ja palaute olennaista Kahden mallin lähestymistapa ei istu toteutettavan järjestelmän rakenteeseen Työlästä: yksinkertaisen järjestelmän toteuttaminen, lisätään turhaa kompleksisuutta Vaatii asiantuntemusta/opettelua, jos ei ole aikaa/osaamista, ei kannata

5 Päivitä alla olevaa arkkitehtuuria: Missä kohdissa yleisarkkitehtuurissa skaalautuvuus voidaan huomioida? Mitä eri mahdollisuuksia komentopuolen skaalautuvuuden hallinnassa olisi? Minne tulisi käyttäjien seuranta?

6 Haku ja komentopuoli omilla erillisillä palvelimillaan, palvelurajapintojen takana lisää palvelimia kullekin osa-alueelle. Komentopuolella komentojonot, komennot omina erillisinä komponentteinaan (seuranta, komentotasolla kuormituksesta), komennonkäsittelijäkohtainen skaalaaminen Hakupuoli ja cache (näkymämallin välimuisti, joka päivitetään tietokannasta vain tietyin väliajoin. Hakupuolen eri asiakkaat/eri näkymät käyttöliittymissä Omille palvelimilleen.

7 CQRS ja harjoitustyö, miksi/miksei? Optimointimahdollisuuksia: Välimuistien käyttö, tiedon varastointi näytettävässä muodossa Vähemmän muutoksia kuin kyselyitä Sairaalan järjestelmään liityntä, ei päivitystä, vain lukua Käyttäjien seuranta melko yksinkertaista toteuttaa Käyttäjä pyytää analyysin, tulos tulee joskus myöhemmin ilmoituksena Toisaalta peruskäyttöoperaatiot usein raskaita Perustapaukseen sisältyy sekä päivitystä että lukupuolta Vanhentuneella/osittaisella tiedolla toimiminen huono idea mahdollista, mutta pitää olla tarkkana

8 PACS ja DICOM Onko se P, onko A, onko C PACS, mikä se on? Entäpä DICOM? Miten liittyvät toisiinsa? PACSin kanssa kommunikointi Mitä perusoperaatioita on olemassa? Mikä rakenne tiedoilla on?

9 DICOM ja tietojen rakenne erittäin lyhyesti Metatieto tallennettujen tietojen yhteydessä (kaikissa kuvissa jne. Mukana myös potilaan identifiointi-informaatio, mittauksen tiedot jne.) Potilas-series (mittaussarja)-tulos, jonka sisällä esim. Pixeldata, jossa itse kuva

10 Tehtävä: oman järjestelmän liittäminen sairaalan PACS-DICOM -järjestelmään Mitä arkkitehtuuriratkaisuja/päätöksiä jne. liittyy liikutteluun esim. sairaalan järjestelmästä meidän järjestelmään? Entäpä kahden järjestelmän välinen integraatio? Ja taas lainsäädäntöä yms. kuvien säilöminen käsittelyn ajaksi, pysyvämmin (levy/tietokanta). Mitä huomioitava? Mitä formaatteja käytetään omassa järjestelmässä vs. DICOM Tietojen muunnokset, missä tehdään? Miten yhdistetään sairaalan tiedot ja järjestelmän tiedot? (sama potilas) Miten tavaraa haetaan PACSista, tehdäänkö oma PACS ja muunnokset sovelluksessa/muilla palvelimilla vai tehdäänkö oma välipalvelin, joka kommunikoi sairaalan (pää)pacsin kanssa ja muuntaa ne meidän järjestelmän haluamaan muotoon? Kuvien säilöminen ja siirtely ja salaustekniikat Kuvien tilapäiskopiot sovelluksessa, paikalliset kopiot ja salaus