Juhani Gurney Teknologiajohtaja. Peppi-projekti ja ESP (Eduix SOA Platform)

Transkriptio

1 Juhani Gurney Teknologiajohtaja Peppi-projekti ja ESP (Eduix SOA Platform)

2 Peppi-projekti Projekti aloitettu keväällä 2010 Projektin tehtävänä on määritellä, suunnitella ja toteuttaa uusi koulutuksen suunnittelutyökalujen muodostama palvelupohjainen (SOA) palvelukokonaisuus Projekti toteutetaan Metropolia ammattikorkeakoulun ja Tampereen ammattikorkeakoulun laatiman yhteistyösopimuksen mukaisesti. Toimittajana Eduix Oy. Vaiheet 1. vaiheen tuloksena toiminnallinen- ja tekninen vaatimusmäärittely (valmis) 2. vaiheen tavoitteena on toteuttaa palvelut vaatimusmäärittelyn mukaisesti (aloitettu keväällä 2011) 3. vaihe on käyttöönotto ja koulutus. Tavoiteaikataulu vuoden 2013 loppuun mennessä.

3 Peppi-projekti Projektin kotisivut: Peppi-projektissa toteutettavat kokonaisuudet: opetussuunnittelu vuosisuunnittelu työpöytien yhteiset palvelut opettajapalvelut resurssien suunnittelu- ja varausväline raportointi-, tieto- ja seurantapalvelut sääntömoottori Demo:

4 Miksi Peppi? Lähtökohdat: Nykyinen järjestelmäarkkitehtuuri on syntynyt vuosien saatossa ja johtanut sekavaan tulokseen Järjestelmien ylläpito ja häiriötilanteiden selvittäminen on koettu ongelmalliseksi Arkkitehtuurin monimutkaisuus tekee hankalaksi kustannusten arvioimisen ja jatkokehittämisen Tiedon kopiointi aiheuttaa sen, että tiedon omistajuus järjestelmien välillä hämärtyy ja tiedon eheys voi vääristyä Sekava järjestelmäarkkitehtuuri heikentää tietoturvaa Tiedot on kuvattu eri tavoin, joka hankaloittaa palveluiden ja toimintojen suunnittelua.

5 Nykytila

6 Kohti parempaa arkkitehtuuria Esiselvitysvaiheessa Eduix Oy:n asiantuntijat kävivät läpi yhdessä asiakkaan kanssa nykyisen järjestelmäarkkitehtuurin aiheuttamat ongelmat sekä selvittivät, miten nykyiset ongelmat voitaisiin ratkaista. Palvelupohjainen arkkitehtuuri koettiin sopivimmaksi, koska se mahdollistaa palveluiden uudelleenkäytön. Samaan aikaan selvitettiin voitaisiinko ratkaisussa käyttää Kuali-yhteisön ratkaisuja ( Palveluväylätuote (ESB) valittiin PoC-projektien tulosten perusteella Evaluoinnit tehtiin seuraavia skenaarioita vasten:

7 Tavoitetila (Kuva: Metropolia) Huom! Metropolian yleinen tavoitetila. Ei koske vain Peppiä.

8 Miten Peppi on rakennettu?

9 Pepin arkkitehtuurin 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 Resttyyppisinä rajapintoina. Olennaista on, ettei julkaistu rajapinta luo riippuvuutta mihinkään tiettyyn alustaan. Sääntö 3, Palvelurajapintojen erottaminen käyttöliittymistä Käyttöliittymiä ei sidota tiukasti palvelun sisäiseen toteutukseen, jolloin palveluita voidaan uudelleenkäyttää ja käyttöliittymiä voidaan uudistaa moduuli kerrallaan.

10 Eduix SOA Platform (ESP) Peppi on toteutettu ESP-arkkitehtuurin mukaisesti ESP:llä tarkoitetaan Eduixin tapaa tehdä palvelupohjaisia järjestelmiä Kuvaa käytettävät teknologiat ja standardit sekä itse palvelualustalle että sillä ajettaville palveluille ja integraatioille Ottaa lisäksi kantaa palveluiden suunnitteluun ja dokumentointiin, testaamiseen sekä sovelluskehityskäytäntöihin Sisältää EduGUI-kirjaston, jonka avulla käyttöliittymiä voidaan toteuttaa ohjelmointikielestä riippumatta

11 ESP-arkkitehtuuri

12 ESP-palvelualusta ESP-arkkitehtuurin keskeisin komponentti on ESP-palvelualusta, joka koostuu Apache ServiceMix4 -ESB-tuotteesta ja Eduixin siihen tekemistä laajennoksista (ESP Feature). Palvelualusta toimii ajoympäristönä palvelumoduuleille ja integraatioille. ServiceMix4 on avoimen lähdekoodin Enterprise Service Bus (ESB) -tuote, joka perustuu OSGi -teknologiaan. ServiceMix4:n ydin on Apache Karaf, joka on kevyt OSGi runtime -ympäristö. Karaf laajentaa OSGi containeria tarjoamalla toimintoja mm. OSGi-moduulien hallintaan.

13 ServiceMix4 ja ESP ServiceMix4 on käytännössä Karaf + mukaan paketoidut, OSGivalmiit ja standardeihin perustuvat teknologiakomponentit, joita hyödyntämällä palvelut ja integraatiot rakennetaan. Spring, Apache CXF, Apache Camel, Apache ActiveMQ, JBI Teknologiakomponentit ovat valinnaisia ja asennuskohtaisesti voidaan valita, mitä niistä halutaan käyttää. Turhat komponentit kannattaakin jättää aktivoimatta. ESP:ssä ServiceMix4 on paketoitu oletuksena seuraavilla komponenteilla:

14 ServiceMix4 ja ESP, jatkoa... ESP:ssä ei yleensä käytetä JBI:tä, koska Camelin avulla samat asiat voidaan tehdä helpommin ja yksinkertaisemmin. Ratkaisu olla käyttämättä JBI:tä on linjassa SMX:n kehityspolun kanssa, sillä se tulee olemaan lähes varmasti deprecated tulevassa ServiceMix5-versiossa. ESP laajentaa ServiceMix4-perusasennusta ESP Feature -teknologiakomponentin avulla. Tarjoaa valmiita palveluita ja muita laajennoksia, joita tarvitaan tyypillisessä järjestelmätoimituksessa. Näitä ovat mm.: Event-service: Palvelu, jonka avulla muut palvelut voivat tiedottaa tapahtuneista muutoksista palveluväylälle. Unit-service: Geneerinen palvelu hierarkisen tietomallin tallentamiselle. Palvelun avulla voidaan toteuttaa esim. organisaatiorakenne

15 Palvelut Palvelut ovat Javalla ohjelmoituja moduuleita, jotka voivat julkaista rajapintoja myös OSGI-säiliön sisällä. Kutsut palveluiden välillä tehdään OSGI-säiliön sisällä ilman että viestejä täytyy muuttaa eri muotoon lähetyksen ajaksi. Palveluiden koostaminen ei tällöin kuormita järjestelmää yhtä paljon kuin jos koostaminen tehtäisiin eri SOAP-rajapintoja käyttäen. Julkaistu SOAP/Rest-rajapinta toimii ainoastaan fasadina käyttöliittymäkerrokselle sekä ulkopuolisille järjestelmille.

16 Enterprise Integration Patterns (EIP) Integraatiot Palvelut ohjelmoidaan rajapintoja vasten, jotka on erotettu omiin OSGI-bundleihin. On kuitenkin tilanteita joihin sopii paremmin perinteisempi EIP-tyyppisten integraatioiden käyttäminen: Palvelut täytyy kytkeä vanhaan ns. legacy-järjestelmään, johon ei ole olemassa ohjelmallista rajapintaa. Käytännössä integraatio täytyy tehdä joko siirtotiedoston tai tietokantayhteyden avulla. Palveluiden toimintoihin halutaan liittää asiakaskohtaisia laajennuksia, jotka liittyvät ESP-palvelualustan ulkopuolisiin järjestelmiin. Esimerkiksi Pepissä palvelut lähettävät muutoksista viestejä JMS-jonoon. Tapahtuma-palvelu puolestaan kuuntelee jonoon tulevia viestejä ja lähettää niitä eri integraatioille. Esimerkki: Kun opintojaksototeutus julkaistaan, palvelu lähettää siitä viestin tapahtuma-jonoon. Tämän jälkeen tapahtuma-palvelu huomaa viestin ja luo toteutukselle työtilan esimerkiksi Confluenceen, portaaliin tai Moodleen ja siirtää toteutuksen tiedot Winhaan.

17 ServiceMix4 ja EIP ServiceMix 4 sisältää kaikki tarvittavat komponentit palveluiden ajonaikaiseksi ympäristöksi sekä erilaisten EIP-tyyppisten integraatioiden tekemiseen.

18 Käyttöliittymät ESP-palvelualustan käyttäminen ei edellytä sitoutumista mihinkään tiettyyn käyttöliittymäteknologiaan. Peppi-projektissa käyttöliittymät on tehty portletteina ja ajonaikaisena ympäristönä käytetään Liferay 6.x -portaalia. Käyttöliittymien toteuttamista varten on tehty EduGUIkäyttöliittymäkirjasto, joka ei pakota sitoutumaan mihinkään tiettyyn käyttöliittymäsovelluskehykseen tai ohjelmointikieleen. EduGUI-komponentit ovat käytännössä HTML/CSS/JavaScriptkokoelmia Mahdollistaa käyttöliittymäkerroksen ja liiketoimintalogiikan kehitystyön järkevän erottamisen erillisiksi kehitysprosesseiksi Käyttöliittymäkerroksen toteuttava koodi on helposti optimoitavaa ja siten nopeampaa kuin esim. komponenttikirjastojen käyttö.

19 Peppi-kokemuksia Peppi Eduixin suurin SOA-projekti, pitää sisällään kaikki opetuksen suunnittelun, vuosisuunnittelun ja lukujärjestyssuunnittelun toiminnallisuudet Toteutettu ESP-palvelualustan avulla Toteutus aloitettu kesällä OPS-osio jo Tamkilla pilotointikäytössä helmikuussa 2012 Huomiot toteutuksesta Käyttöliittymät keskustelevat palvelukerrokseen ainoastaan SOAP/Restrajapintojen kautta Rajapinnat on lähtökohtaisesti suunniteltu siten että tietoa siirretään vain tarpeellinen määrä, mutta kuitenkin siten että prosessoinnin määrä käyttöliittymäkerroksessa olisi mahdollisimman vähäinen. Rajapintojen käyttäminen ei näy loppukäyttäjälle millään tavoin Rajapinnat toimivat nopeasti Käyttöliittymäsuunnittelijat eivät tarvitse palvelualustaa asennettuna omille kehityskoneilleen

20 ESP ja ServiceMix4-koulutus Eduix tarjoaa koulutusta ESP-arkkitehtuurin mukaiseen kehitykseen ServiceMix4:n avulla. Kaikki Eduixin kouluttajat ovat käyneet FuseSourcen pitämän Eduixille räätälöidyn kurssin: Developer Training for Apache ServiceMix 4.x with Apache Camel Implementing Enterprise Integration Patterns using OSGI. Kurssien sisältö on rakennettu pitkän integraatiokokemuksen sekä Peppi-projektista saatujen käytännön SOA-kokemusten perusteella. Eduix tarjoaa seuraavat valmiit koulutuspaketit: Palveluiden tekeminen Servicemixiin OSGI-teknologian avulla Camel-integraatioiden tekeminen Servicemixiin