idNimiTyöpäiviäKustannusRooli 1TIPTOP-portaali9035 486Vastuu 1.3AHOT: Tiptop-kokonaisuus187 097Osallistuja 2.1 HOPS: Koulutuksen järjestäjän käyttöliittymä8232.

Esitys aiheesta: "idNimiTyöpäiviäKustannusRooli 1TIPTOP-portaali9035 486Vastuu 1.3AHOT: Tiptop-kokonaisuus187 097Osallistuja 2.1 HOPS: Koulutuksen järjestäjän käyttöliittymä8232."— Esityksen transkriptio:

1

2 idNimiTyöpäiviäKustannusRooli 1TIPTOP-portaali9035 486Vastuu 1.3AHOT: Tiptop-kokonaisuus187 097Osallistuja 2.1 HOPS: Koulutuksen järjestäjän käyttöliittymä8232 332Vastuu 2.2 HOPS: Oppijan opintojen suunnittelun väline3011 829Osallistuja 2.3AHOT: Oppijan näkymä3011 829Osallistuja 2.4AHOT: Virkailijan näkymä207 886Osallistuja 3.1Opintojen etenemisen seuranta207 886Osallistuja 3.3Ilmoittautumispalvelu7027 600Vastuu 4.5Henkilö-tietovarantopalvelu5019 715Vastuu 4.6Ryhmä-tietovarantopalvelu7027 600Vastuu 4.7Rooli-tietovarantopalvelu62 366Osallistuja 4.5Oppijan tulokset-tietovarantopalvelu3513 800Osallistuja 6.5Yleinen viestiväylä10039 429Vastuu 6.3Objekti-sääntö -moottori8031 543Vastuu 6.1Viitepalveluiden integrointi5019 715Vastuu 751296 112

3

4

5  SOA-palvelut Arviointipalvelu Opetustarjon- nan esittäminen Ilmoittautumis- palvelu Tietovarastot käsitemalli säännöstö tietovarasto viitteet xxx yyy Looginen -------------- Fyysinen palveluväylä integraatipalvelut lokipalvelut Haku- ja hallintapalvelut KÄSITEVÄYLÄKÄSITEVÄYLÄ

6  Keiden ja millä tasolla pitäisi pystyä sääntöjä ruuvaamaan?  Missä tilanteessa kannattaa säännöstö irrottaa ohjelmakoodista?  Vaikka säännöstön irrottaa, voisiko se olla vaikka pure-javaa. ts. vain joku moduuli joka tarjoaa standardin rajapinnan ja mitä on täten helppo muuttaa yms.  Onko toteutun SOA:n kypsyys sillä tasolla, että saadaan todellista hyötyä.  Sääntömoottori tuo eteen aina uuden kielen, mitä pitää tulkita ja opetella. Tuo ylimääräisen kerroksen ja kuormittaa palvelua ehkä turhaankin.

7  tunnistaa ja eristää sääntömoottorille sopiva palanen ja korvata se aluksi vaikka kovakoodatulla jutulla  kun löytyy todellinen tarve tarjota säännöstö jollekin konfiguroijalle korkeamman tason kielisenä toteutuksena, niin hoidetaan se siinä vaiheessa

8  suunnitteluvaiheessa stepit on hyvä tunnistaa sekä dokumentoida ja toteuttaa ne kun tarve nähdään järkeväksi.  suunnittelun apuväline / koodin jäsennys vs. joku teknologinen ratkaisu (ts. sääntö-kieli yms.)  Säännöstö voitaisiin toteuttaa ensin loogisella tasolla  säännöt ovat usein monimutkaisia ja sisältävät poikkeuksia, mitkä kaikki on mallinnettava sääntökielellä.

9  Käsiteväylää käytetään aina SOA- palveluiden kautta  SOA-palvelun kautta ei ole mahdollista saada mitään sellaista tietoa, johon käyttäjällä ei ole säännöstön mukaan oikeutta.  Käsiteväylän palvelut ovat SOA- palveluita, jotka muodostavat käsiteväylän palvelurajapinnan.

10  Nyrkkisääntö: Integroitavaan sovellukseen on täytynyt luoda jokin rajapinta, että se on ylipäätään integroitavissa mihinkään.  Tästä syystä palvelukeskeisen arkkitehtuurin vaatimukset ovat hyvä pitää mielessä minkä tahansa järjestelmän tekemisessä/teettämmisessä/räätälöinnissä yms.  Mikään integraatioalusta ei ole taikalaatikko, mikäli olemassa olevat järjestelmät eivät ole siihen liitettävissä (esim. Winhassa suurin osa toiminnallisuudesta on vain käyttöliittymässä).

11  Mitkä kaikki legacy järjestelmän palvelut halutaan integroida?  ServiceMixiin integroitu Apache CXF, millä voidaan tehdä ja käyttää Web Service/REST rajapintoja.  Camel’ia käytetään integrtoitaessa erilaisia muita rajapintoja. (esim. CSV, JMS)

12  Viestiväylällä tässä ymmärrettäneen palvelukerrosta, joka › ulospäin tarjoaa rajapinnat keskitetystä paikasta (ts. ei järjestelmäriippuvasti) › Joka tarjoaa mekanismit/teknologiat yhdistää/koostaa olemassas olevia palveluita/rajapintoja uusiksi palveluiksi

13  Onko valinta Servicemix4/FuseESB ?  ServiceMix ei ole selkeästi mikään yhden teknologian totettava integraatioalusta/palveluväylä, vaan eräänlainen sateenvarjoprojekti, johon on integroitu erilaisia teknologioita.  ServiceMix:in ydin on OSGI-säilö (Apache Karaf). Asennetut sovellukset/palvelut ovat olennaisesti tämän Karaf-säilön päällä pyöriviä OSGI-bundleja.

14  ServiceMix voidaan nähdä toteuttavan palvelukeskeistä arkkitehtuuria kahdella tavalla (tai ehkä pikemminkin kaksitasoisesti). › Osgi-kehyksenä, mikä voidaan nähdä SOA:n periaatteet täyttävänä ratkaisuna Java-virtuaalikoneen (JVM) sisällä › Palveluväylänä, mihin ServiceMix tarjoaa olennaisesti kaksi eri lähestymistapaa JBI ja Apache Camel.  Koska JBI standardiudestaan huolimatta, on jäämässä syrjään, lienee järkevää lähteä Camelin polkuja seuraamaan. Camel vaikuttaa olevan yksinkertaisempi ja sovelluskäyttäjälähtöisempi kuin JBI.  Palvelurajapintoina ulospäin (esim. käyttöliittymäkerrokselle) käytetään WebService/Rest-rajapintoja. Esim. Camel- komponenttien hyväksikäyttö mahdollistaa aika monenmoisen protokollan käytön of-the-box.