Toimittaja – Looginen väylärakenne + kirjastot

1. Toimittaja – Looginen väylärakenne + kirjastot Kalle Launiala, ProtonIT Oy kalle.launiala@protonit.net +358445575665

2. Nykyiset integraatiot teknisiä, eivät informaatiota kontrolloivia

3. Integraation toteutus nykyisin • Suunnitellaan ja päätetään, mitä pitää siirtää • Dokumentoidaan asia määrittelyksi • Suunnitellaan tekniset kutsut siirrolle • Palvelun suunta, Kuka kutsuu, kuka palvelee • Palveluiden tarkat nimet, parametrit, paluuarvot • Päätetään yhteiset tekniset protokollat • Dokumentoidaan asia määrittelyksi • Toteutetaan joko koodaamalla, tai konfiguroimalla • Konfigurointi aktivoi protokollia, toimii paremmin lupauksena kuin käytännössä • Ylläpidetään muutokset molempiin päihin yhtaikaa • Jos on säästetty työssä integroimalla samalla useampi taho laajemman tarpeen puitteissa, ylläpidettävä yhtaikaa • Koodataan käsin customoinnit, kun käyttäjätunnistus, tiedon omistajuus tai joku muu ero järjestelmien välillä ilmenee • Ei yhtenäistä ylläpidettävyyttä, täysin tapauskohtaista, usein myös toteuttajakohtaista • Erikoistuneet järjestelmät katsovat AINA asioita eri perspektiivistä, jolloin eroja on AINA – siksi ne järjestelmät on alun perin hankittukin • Integrointi menee aina dataan ja sääntöihin asti • (Dokumentoidaan asia päivittäen määrittelyä – ei käytännössä ihan aina tapahdu)

4. Nyt integraatiot ovat uniikkeja, dataan ja sen sääntöihin asti meneviä

5. SEIS!

6. Kokonaisuuden automatisointia, kokonaisuuden hallintaa..?

7. Teknisesti integraatio tapahtuu järjestelmien rajapinnoissa

8. Integraation määritys loogisesti • Suunnitellaan ja päätetään, mitä pitää siirtää • Dokumentoidaan asia määrittelyksi Kuvataan loogisella tasolla => sisältää myös dokumentaation • Suunnitellaan tekniset loogiset kutsut siirrolle • Palvelun suunta, Kuka kutsuu, kuka palvelee • Palveluiden tarkat nimet, parametrit, paluuarvot • Päätetään yhteiset tekniset protokollat • Dokumentoidaan asia määrittelyksi Kuvataan loogisella tasolla => sisältää myös dokumentaation • Toteutetaan joko koodaamalla, tai konfiguroimalla • Konfigurointi aktivoi protokollia, toimii paremmin lupauksena kuin käytännössä • Ylläpidetään muutokset molempiin päihin yhtaikaa • Jos on säästetty työssä integroimalla samalla useampi taho laajemman tarpeen puitteissa, ylläpidettävä yhtaikaa • Koodataan käsin customoinnit, kun käyttäjätunnistus, tiedon omistajuus tai joku muu ero järjestelmien välillä ilmenee • Ei yhtenäistä ylläpidettävyyttä, täysin tapauskohtaista, usein myös toteuttajakohtaista • Erikoistuneet järjestelmät katsovat AINA asioita eri perspektiivistä, jolloin eroja on AINA – siksi ne järjestelmät on alun perin hankittukin • Integrointi menee aina dataan ja sääntöihin asti • (Dokumentoidaan asia päivittäen määrittelyä – ei käytännössä ihan aina tapahdu) • Määritellään loogiset tarpeet viite-arkkitehtuurin kontrolloimiin paikkoihin • Yhteisten tarpeiden ja yhtenäistämis-kandidaattien tunnistaminen • Tunnistetaan myös jatkossa loogisesti yhtenevät tarpeet

9. Loogisen määrittelyn realisointi ADM-automaatiolla • Suunnitellaan ja päätetään, mitä pitää siirtää • Kuvataan loogisella tasolla => tuottaa myös dokumentaation • Suunnitellaan loogiset kutsut siirrolle • Palvelun suunta, Kuka kutsuu, kuka palvelee • Palveluiden tarkat nimet, parametrit, paluuarvot • Kuvataan loogisella tasolla => tuottaa myös dokumentaation • Mikäli toteutusta tarvittuun teknologiapinoon ei vielä ole • Tehdään referenssitoteutus tavanomaiseen tyyliin käsin • Tehdään ADM-automaatti siirtämällä referenssi generaattoreiksi • Julkaistaan oma lisäys/muutos/päivitys verkoston repositorioon • Toteutetaan customoinnit viite-arkkitehtuurin kontrolloimiin paikkoihin • Yhtenäinen ylläpidettävyys koko verkoston yli, ei henkilöitymistä • Tunnistetaan jatkossa edelleen automatisoitavissa olevat toistuvat patternit => toteutetaan verkostoon

10. Toistuva toteutus vähenee • Toteutus tarvitaan ”ensimmäisen kerran” • Viitearkkitehtuurin mukainen ”best-practice” toteutus • Teknologia-kohtaiset toteutukset tarvitaan kertaalleen • Korvaa käsityötoteutukseen verrattuna 80-90% ajettavasta koodista • Pitää myös ylläpitää, mutta ylläpito ja kehitys kohdistuvat aina kaikkiin samaa moduulia käyttäviin • Yhteisö hyötyy yhteiskäyttöisyydestä aidosti

11. Looginen informaation hallinta mahdollistuu => Pallo-malli

12. Palvelukirjastot Hajautetun palveluketjun tai ”väylän” realisointi

13. Teknisestä minimistä semanttiseen minimiin • Tekninen minimi palvelun kutsumiselle • Palvelun nimi • Palvelun tekniset parametrit • Palvelun tekninen paluuarvo • Semanttinen minimi palvelun määrittelyyn • Palvelun nimi • Semanttisesti MinunApp.HaeHenkilö vs. VRK.HaeHenkilö • Palvelun semanttisesti nimetyt parametrit ja paluuarvo • MinunApp.HenkilöTunnus vs. VRK.HenkilöTunnus • Tekninen + Semanttinen Yhdessä muodostavat palvelun ”sormenjäljen” tai ”signaturen” • VRK.HaeHenkilö – niminen palvelu • Parametri: VRK.HenkilöTunnus • Paluuarvo: VRK.Henkilö

14. ADM:n kiihdytys Pallo-palveluihin • Semanttinen määrittely ja sormenjälki syntyvät ADM:llä automatisoidusta loogisen tason palvelukuvauksesta • Automaation määrämuotoisuus ohjaa luontevasti katalogiin/kirjastoon – dynaamiseen malliin • Myös kirjastoon rekisteröinti voidaan automatisoida • Migraatio nykyisestä • Motivaationa tuottaa palvelu ”väylään” eli kirjastoon • Loogisen tason kuvaus nykyisestä teknisestä tasosta tehdään ADM:llä toteutettuun suunnittelutason abstraktioon • Yhtenäistetään palvelurajapinta ottamalla ADM-automaatio käyttöön (kuten edellä kuvattu) • Uuden tekeminen • Määrittelyt kannattaa tehdä loogisesti joka tapauksessa => työmäärä pienempi • Lopputulos suoraan väylävalmista tuotantoa

15. Kirjasto konkreettisesti on vain palvelu • Yhtälailla hajautettu palvelu kuin muutkin • Kuka tahansa voi julkaista kirjastopalvelun • Kehen tahansa ei tarvitse luottaa – eikä automatiikkakaan luota • Oleellista on voida päättää kenen kirjastoon luottaa • Hakukriteerinä lisäksi mahdollisuus liittää metatietoa tarpeen mukaan • Kriittinen elementti on ”semanttinen sormenjälki” • Yksityisen sektorin vertikaalit määrittävät itse omat metatietonsa • Kirjasto palauttaa haun perusteella vähintään täydellisen semanttisen kuvauksen + URL:n, josta palvelu löytyy • Testi + demokäyttö voidaan mahdollistaa rinnakkaisilla URL:eilla palvelustubeilla, demodatalla jne... • Konkreettinen infra voidaan luoda tukemaan ratkaisua, esim JulkICT lab:n toimesta • Mitään raskasta demorakennetta ei ole pakko tehdä

16. Tekninen kutsu: semanttinen signature + URL, josta palvellaan

17. Kirjastosta poimittavien palveluiden hyödyntäminen ”ketjuna” • MinunApp sisäinen palvelu voi käyttää VRK:n datamalleja ja funktionaalisia palvelulohkoja • Datamallit ovat VRK.Henkilö – avaruuden mallit • Palvelun funktionaalisuus tunnistaa saman avaruuden mallit • VRK:n Pallolla vastuuna on tarjoilla VRK:n hallinnoima data • Funktionaalisuus ko. dataa vastaan ajetaan tarvittaessa myös muualla • Sovellus ajaa valmiiksi tehtyjä sovelluksia omaa datavarantoaan vasten • Semanttinen malli ei ota kantaa siihen, onko data VRK:n dataa. Semanttinen malli kuvaa VRK:n mallin. • Eli VRK:sta luotettavasti tuotu data vaikka VERO:n järjestelmiin jalostetaan eteenpäin, kuten nykyisinkin VERO:n omiin malleihin • Uutta – henkilökohtainen alusta: Yksityisen sektorin tarjottavissa • Ohjelmistotuottajat voivat tehdä funktionaalisuutta, joka käyttää VRK.Henkilö ja VERO.Verotiedot2011 tietorakenteita • Funktionaalisuus ajetaan kansalaisen omaa tietoa vasten, kansalaisen omassa tietosuojatussa, auditoidussa hiekkalaatikossa • Funktionaalisuus = Palvelu, ei tarvitse välttämättä tapahtua verkon/väylän yli

18. Väylätason integraatio Kaupunkitason väyläliitos kansalliseen väylään

19. Kokonaisuuksien integraatio voidaan nähdä tavanomaisesti Keskitetty Integraatio

20. Tai käyttäjän näkökulmasta – väylä yhdistää palvelut