Peppi-projekti (SOA Metropolia) Ammattikorkeakoulujen opetuksen suunnittelun viitearkkitehtuurin käytännön esimerkki.

Esitys aiheesta: "Peppi-projekti (SOA Metropolia) Ammattikorkeakoulujen opetuksen suunnittelun viitearkkitehtuurin käytännön esimerkki."— Esityksen transkriptio:

1 Peppi-projekti (SOA Metropolia) Ammattikorkeakoulujen opetuksen suunnittelun viitearkkitehtuurin käytännön esimerkki

2 Metropolia Ammattikorkeakoulu
Tietojärjestelmät Palveluiden uudelleen käytettävyys Legacy-järjestelmien hallittu saattohoito Integraatiot n(n-1)/2 vs.???? Tieto Omistajuus hyödyntäminen 4/9/2017 Metropolia Ammattikorkeakoulu

3 Integraatioiden nykytila
4/9/2017 Metropolia Ammattikorkeakoulu

4 Integraatioden tavoitetila
Mahdollistaa tuottamisen monitoimittajaympäristössä ja sisäisen kehityksen - uudellenkäytettävyys!!! Muuttuvan tiedon monistuminen loppuu Legacy järjestelmien saattohoito 4/9/2017 Metropolia Ammattikorkeakoulu

5 Metropolia Ammattikorkeakoulu
Palvelurajapinnat 4/9/2017 Metropolia Ammattikorkeakoulu

6 Mistä Peppi kokonaisuus rakentuu?

7 Kuka ja kenelle? Mitä tietoa Pepissä käsitellään?
Opettaja Peppi Opiskelija TIPTOP? Koulutuksen suunnittelija Peppi Koulutuksen suunnittelija: Koulutuspäällikkö, Virkailija, Suunnittelija. Tuottaa tietoa korkeakoulun koulutustarjonnasta, sen järjestelyistä ja siihen käytetyistä resursseista. Opettaja: Hyödyntää koulutuksen suunnittelijan tallentamaa tietoa ja täydentää sitä omalta osaltaan Opiskelija: Hyödyntää koulutuksen suunnittelijan ja opettajan tallentamia tietoja koulutuksen sisällöstä. Tallentaa tietoa omasta opintosuunnitelmastaan, antaa palautetta ja tekee valintoja opintojen aikana. Tämä tieto täytyy palautua koulutuksen suunnittelijoille ja opettajalle. 4/9/2017 Metropolia Ammattikorkeakoulu

8 Millä palvelukokonaisuuksilla em. tietojen käsittely mahdollistetaan?
Koulutuksen suunnittelijan sähköinen työpöytä Opetussuunnittelu Vuosisuunnittelu / Opetusohjelman laatiminen Työ- ja lukujärjestyssuunnittelu / Resurssiensuunnittelu ja –varausväline Opettajan sähköinen työpöytä Toteutustenhallinta (sis. Toteutussuunnittelu) Oman työjärjestyksen hallinta, työaikasuunnitelmat Omien ja yhteisten sähköisten oppimateriaalien hallinta Ilmoittautumisiin ja arviointiin liittyvät palvelut Opetuksen toteutukseen liittyvät sähköiset palvelut Viestintäpalvelut 4/9/2017 Metropolia Ammattikorkeakoulu 8

9 Esimerkkejä yksittäisistä palveluista
Opetussuunnittelu Vuosisuunnittelu Työ- ja lukujärjestyssuunnittelu Opetus-suunnitelmien hallinta Opintojaksojen hallinta Ryhmien hallinta Työaikasuunnittelu Työ- ja lukujärjestysten suunniittelu ja hallinta Resurssikustan-nusten arviointi Toteutusten hallinta Osaamiset ja kompetenssit Opintokokonaisuuksien hallinta Opettajapalvelut Raportointi palvelut Työaikasuunnittelmat Opetustapahtumien suunnittelu ja kirjaaminen Arviointi, arvosanat Sähk. työtilojen ja oppimisympäris-töjen hallinta Nykyhetken seuranta Suunnittelutiedon arviointi Toteuman raportointi OJ-toteutusten hallinta OJT - ilmoittautumisten hallinta OJ-palautteiden käsittely Oppimateriaalien hallinta Yleiset tekniset tietojärjestelmäpalvelut Yleiset toiminnalliset tietojärjestelmäpalvelut Yksittäisiä palveluita koostetaan näkymiin prosessien mukaisesti. Palvelukokonaisuuksien kautta pyritään luomaan käyttäjälle saumaton kokonaisuus, jossa ei tarvitse siirtyä tekemään asioita eri järjestelmien välillä. Dokumentinhallinta Taloushallinto Asiakkuuden-hallinta Palautteiden hallinta Tunnistaminen Tapahtumaloki Henkilöstöhallinto Resurssien hallinta Ryhmien hallinta (esim. opetusryhmät) Raportointi Käyttövaltuus-hallinta Organisaation aineistohaku 9 9/4/17 Metropolia Ammattikorkeakoulu

10 Sovellusympäristö ja teknologia?
Periaatteet: Sääntö 1, SOA-metodologia. Tietoa käsitellään palveluiden/palvelurajapintojen kautta. Palveluiden tulee olla autonomisia, toinen palvelu ei kontrolloi niiden toimintaa. Niitä voidaan ajaa hajautetusti. Ne eivät ole sidottuja toisen palvelun sisäiseen toimintaan. Palveluiden tulee olla löyhästi sidottuja toisiinsa, palvelut ovat sidoksissa toisiinsa vain rajapintojen kautta. Tällöin palvelun sisäinen toteutus on vaihdettavissa. Palveluita voidaan uudelleenkäyttää. Sääntö 2, Standardeihin pohjautuvat rajapintaratkaisut Rajapinnat julkaistaan SOAP-pohjaisina Webservice-rajapintoina tai Rest tyyppisinä rajapintoina. Ollennaista on, ettei julkaistu rajapinta luo riippuvuutta mihinkään tiettyyn alustaan. Sääntö 3, Palvelurajapintojen erottaminen käyttöliittymistä Käyttöliittymiä ei ole sidota tiukasti palvelun sisäiseen toteutukseen, jolloin palveluita voidaan uudelleenkäyttää ja käyttöliittymiä voidaan uudistaa moduuli kerrallan. Käyttöliittymät ovat erotettu palvelumoduuleista, jolloin niitä voidaan uudistaa ilman muutoksia liiketoimintalogiikkaan. Samoin voidaan tehdä kokonaan uusia käyttöliittymiä, jotka voivat helposti hyödyntää olemassaolevia palveluita/palveluiden rajapintoja. Palvelurajapinnat julkaistaan SOAP/Webservice ja Rest -teknologioita  käyttäen. Palvelumoduulit asennetaan OSGI-säiliön tarjoavaan Servicemix 4 -alustaan, jonka avulla voidaan tehdä integraatioita ulkopuolisiin järjestelmiin. Palvelun sisäinen tallennusratkaisu/toteutus piilotetaan muilta palveluilta. 4/9/2017 Metropolia Ammattikorkeakoulu

11 Esimerkki tuotantoympäristöstä
Suorituskykyasioihin on kiinnitetty huomiota projektin alusta alkaen. Vastuut (liiketoimintologiikka ja käyttöliittymät) pyritään jakamaan selkeämmin. Kokonaisuudesta tehdään skaalautuva esimerkiksi klusteroinnin avulla. 4/9/2017 Metropolia Ammattikorkeakoulu

12 Metropolia Ammattikorkeakoulu
Kysymykset 4/9/2017 Metropolia Ammattikorkeakoulu

13 Lisätietoja: Projektin sivut Tuomas. Orama@metropolia. fi Jaakko
Lisätietoja: Projektin sivut