Järjestelmäkehitys EJB komponenttien avulla Eeva-Liisa Lehto Helsinki 8.11.2000 Seminaariesitelmä Ohjelmistotuotantovälineet Tietojenkäsittelytieteen laitos Helsingin yliopisto
2 SISÄLTÖ: 1. Johdanto...3 2. Sovelluskehitys käytettäessä Enterprise Java Beans (EJB) pohjaista komponenttikehystä...3 2.2 EJB spesifikaation määrittelemät sovelluskehityksen ja käytön roolit...4 2.3 EJB-palvelualusta (EJB Container) ja komponentit...6 3. EJB implementointiesimerkki: EBO Java Maestro - Java Framework for EJB server...7 4. BEA Weblogic Server...8 5. Case: EU:n tukijärjestelmien toteutus...8 5.1 Sovelluskehityskokemuksia Maestrolla...9 5.2 Komponenttikirjaston tarve ja komponenttipohjaisten järjestelmien ylläpito...10 5.3 Yleisiä johtopäätöksiä...11 6 Lähteet...11
3 1. Johdanto Ohjelmistotekniikassa komponenttipohjaisuus on nostettu esiin 1970-luvulta lähtien. Toistaiseksi tulokset ovat olleet vaatimattomia. Ohjelmistoteollisuus ei ole kyennyt hyödyntämään komponenttipohjaisia ratkaisuja lähestulkoonkaan samassa lajuudessa kuin muut teollisuudenalat. Nyt kuitenkin ohjelmistoteollisuuden raju kasvu ja verkottuminen luo voimakkaita paineita ojelmistokomponenttien uudelleenkäyttöön ja erilaisiin komponentteja tukeviin standardeihin. 1990-luvun loppupuolelta uudet teknologiat ovat parantaneet komponenttien käytön mahdollisuuksia. [Kos00]. Tässä esityksessä keskitytään esittelemään SUNin Enterprise JavaBeans (EJB) komponenttiteknologiaan perustuvaa mallia ja sen käytännön toteutusta EBO Java Maestrolla, joka on Entra Business Objects Oy:n kehittämä Enterprise JavaBeans sovelluskehys. Sovelluskehys käyttää esimerkkitapauksessa palvelimena Bea Weblogic sovelluspalvelinta. Tietokannan hallintajärjestelmänä on Oracle 8. Käyttöliittymän kehitystyö tehdään Oracle JDeveloper sovelluskehittimellä. 2. Sovelluskehitys käytettäessä Enterprise Java Beans (EJB) pohjaista komponenttikehystä 2.1 EJB EJB perustuu Broker eli välittäjä arkkitehtuurimalliin, joka on keskeinen malli hajautettujen järjestelmien yhteydessä. EJB on palvelinpohjainen komponenttimalli, joka on kehitetty uudelleenkäytettävien, hajautettujen komponenttien kehittämisen, jakelun ja hallinnan tarpeisiin. EJB tarjoaa kommunikaatioarkkitehtuurin sekä jakelu- ja suoritusympäristön, jonka toiminnallisuuden toteutuksesta sovelluskehittäjän ei tarvitse itse huolehtia. Esimerkiksi tietokantatransaktioita, kuormantasausta, virhetilanteista toipumista ja hajautettujen komponenttien alemman tason keskustelua ei tarvitse kerta toisensa jälkeen toteuttaa itse. Uudelleenkäyttöä helpottaa se, että liiketoimintalogiikka on erillään muusta toteutuksesta. EJB arkkitehtuuri perustuu palvelualustaan (container), joka toimii Javalla toteutettavien EJB-komponenttien ajoympäristönä ja tarjoaa näille hallinnollisia palveluja. Palvelualustaa ylläpitää middleware-ohjelmiston osa, jota kutsutaan EJB-palvelimeksi. EJB on SUN:n komponenttiarkkitehtuuri spesifikaatio, joka määrittelee beanien rakenteen, niiden palvelualustan rakenteen, jonka sisällä ne operoivat sekä interaktiometodit asiakasohjelmistojen kanssa. EJB standardoi Javalla rakennettujen palvelinkomponenttien kehityksen ja sidonnan (deployment).
4 EJB spesifikaatio määrittelee rajapinnat: - EJB:n ja sen palvelualustan (container) välillä - Palvelualustan ja sovelluspalvelimen välillä - Palvelualustan ja asiakasohjelmiston välillä Infrastruktuuripalvelut, sovelluspalvelimen implementaation ja asiakaspään implementaation toteuttaminen on jätetty kehittäjille. Beanit on jaettu kahteen tyyppiin: - Entity Beanit edustavat liiketoimintadataa - Session Beanit edustavat liiketoimintalogiikkaa 2.2 EJB spesifikaation määrittelemät sovelluskehityksen ja käytön roolit Enterprise JavaBeans arkkitehtuuri määrittelee kuusi erilaista sovelluskehityksen ja käytön (deployment) roolia. Kussakin roolissa voi olla eri toimija. Yksi toimija voi luonnollisesti toimia myös useassa roolissa [MaH99] Periaatteena on, että EJB arkkitehtuuri määrittelee rajapinnat eri roolien välille siten, että kukin EJB rooli on yhteensopiva toiseen rooliin perustuvan tuotteen kanssa. Spesifikaatiossa keskitytään niihin sopimuksiin, jotka ovat keskeisiä enterprise beanien kehitystyössä ja jakelussa. EJB-komponentin tuottaja (Enterprise Bean Provider) Bean provider on enterprise bean-komponenttien tuottaja. Tuotteena on jar-tiedosto, joka sisältää yhden tai useamman beanin. Tuottaja on tyypillisesti sovellusalueen asiantuntija, joka tuottaa uudelleenkäytettäviä beaneja, jotka toteuttavat tietyn sovellusalueen liiketoimintalogiikan tehtäviä. Beanien tuottajan ei tarvitse olla systeemitason ohjelmoinnin asiantuntija. Tämän roolin tuottaa EJB-alustan toimittaja (EJB Container Provider). Komponentin tuottaja liittää komponenttiin asennuskuvauksen, jossa kuvaa komponentin rakenteen ja ulkoiset riippuvuudet. Sovelluksen kokoaja (Application Assembler) Usein beanien tuottajalla on myös sovellus kokoonpanijan rooli. Sovelluksen kokoonpanija yhdistää enterprise beanit suuremmiksi asennuskelpoisiksi kokonaisuuksiksi. Kokoajalla on asiakkaan näkemys EJB-sovellukseen. Kokoaja tuntee komponenttien toiminnallisuuden EJB-rajapintojen kautta. Työn lopputulos on esimerkiksi uusi EJB-komponentti tai sovellus, appletti tai servletti. Kokoaja voi yhdistää EJB-komponentin myös muunlaisiin sovelluksen osiin kuten JSP-sivuihin (Java ServerPages). Tuotteena on jar-tiedosto, joka sisältää tarvittavat komponentit ja kokoonpano-ohjeen.
5 Käyttöönottaja (Deployer) Käyttöönottajan tehtävänä on asentaa em. tiedosto käyttöympäristöön, joka tarkoittaa EJB palvelinta ja EJB alustaa (Container). Käyttöönottoprosessi on tyypillisesti kaksiosainen: - käyttöönottaja generoi lisäluokat ja rajapinnat, jotka mahdollistavat alustalle enterprise beanien ajonaikaisen hallinnan. Nämä ovat alustaspesifejä. - käyttöönottaja tuottaa enterprise beanien käytännön installoinnin sekä lisäluokat ja rajapinnat alustaan. Asentaessaan komponentteja käyttöönottaja käyttää EJB-palvelualustan toimittajan työkaluja. EJB-palvelimen toimittaja (EJB Server Provider) Sovelluspalvelinohjelmiston tehtävänä on hallita käyttäjäistuntoja, jonottaa työasemilta tulevat palvelupyynnöt tietokantapalvelimelle, tasata palvelimen kuormaa, huolehtia käyttövaltuuksista, lokeista jne. EJB arkkitehtuuri olettaa, että palvelimen ja alustan tuottajan roolit ovat samassa tuotteessa, joten rajapintaa niiden välillä ei ole määritelty. Työnjako serverin ja alustan välillä on tästä syystä jätetty tuottajan huoleksi. Tyypillinen palvelintoimittaja on käyttöjärjestelmän, middleware-tason tai tietokantaohjelmiston toimittaja. EJB-alustan toimittaja (EJB Container Provider) Alustan tuottaja vastaa niistä jakeluvälineistä, jotka tarvitaan enterprise beanien julkaisussa. Niiden tehtävänä on antaa ajonaikainen tuki enterprise beanien instanssien käyttöön. Alustan tuottajan roolin ydin on tuottaa skaalautuva, turvallinen, transaktiot mahdollistava alusta, joka on integroitu sovelluspalvelimeen. Alustan tarjoaja tarjoaa yksinkertaisen API rajapinnan enterprise beanille, joka samalla on beanin sopimusrajapinta. Alustan mukana tulevat työkalut, joilla voidaan asentaa EJBkomponentteja alustaan sekä hallinnoida niitä. Järjestelmän hoitaja (System Administrator) Järjestelmän hoitaja on vastuussa yrityksen tietojenkäsittelyn ja verkkojen konfiguraatiosta ja hallinnasta mukaan lukien EJB palvelimen ja alustan. Administraattori vastaa myös käytössä olevien sovellusten ajonaikaisesta toimivuudesta.
6 2.3 EJB-palvelualusta (EJB Container) ja komponentit EJB-komponentit elävät ja toimivat EJB palvelualustan sisällä. Palvelualusta tarjoaa EJB komponenteille systeemitason palvelut. Komponenttien kehittäjät ja toteuttajat voivat keskittyä liiketoimintatason ongelmien ratkaisuun. Palvelualusta huolehtii: - EJB komponenttien rekisteröinnin nimipalveluun - EJB komponenttien luonnin ja tuhoamisen - EJB komponenttien elinkaaren hallinnan - Tietoturvapalvelut - Transaktioiden hallinnan - Tietokantayhteyksien säilyttämisen - EJB komponentin ja asiakkaan välisen matalan tason kommunikoinnin EJB komponentit Session bean komponentit Session bean komponentit esittävät toimintoja, jotka suoritetaan asiakasohjelman kutsusta. Ne toteuttavat liiketoimintalogiikkaa ja sääntöjä sekä työnkulkuja. Esimerkkinä tilauksen tekemislogiikka, hinnan laskeminen, pankkitapahtumien tekeminen. Asiakasohjelma luo Session bean komponentin ja sen elinkaari kestää asiakkaan istunnon ajan. Session bean komponentilla voi olla vain yksi asiakas. Kun asiakasohjelman viittaus Session beaniin katoaa, Session bean kuolee. Asiakasohjelma ei luo suoraan Session bean komponenttia, vaan sen tekee palvelualusta (Container) Session bean voi olla tilaton (stateless) tai tilansa säilyttävä (stateful) Entity bean komponentit Entity bean komponentit esittävät sovelluksen pysyvää, tietovarastossa säilytettävää tietoa esimerkkinä asiakas-, tuote-, tilaus- ja pankkitiedot. Tietojen säilytyspaikka voi olla relaatiotietokanta, oliotietokanta, tiedosto tai jokin muu varastointimekanismi. Entity bean komponentin tietojen pysyvyyden hallinnan (persistence management) voi suorittaa komponentti itse tai palvelualusta (Bean managed/ Container managed). Komponentin itsensä hallitsemassa tapauksessa komponentissa täytyy olla SQLlauseet, joilla hoidetaaan relaatiotietokannan käsittely JDBC:n kautta. Palvelualustan hallitsemassa tapauksessa se hoitaa tietojen tallentamisen ja hakemisen automaattisesti. [Hel00]
7 EJB komponenttien kutsurajapinnat Home ja Remote rajapinnat/luokat kontrolloivat pääsyä EJB luokkaan Asiakas näkee EJB komponentin Home- ja Remote rajapinnat ja keskustelee EJB:n kanssa näiden rajapintojen kautta Home rajapinta EJB komponentin Home rajapinta johdetaan EJBHome luokasta. Home rajapintaa käytetään luomaan uusia olioita. Home rajapinnassa määritellään create() metodeja, joita asiakasohjelmat kutsuvat ja joilla luodaan uusia komponentteja Remote rajapinta Remote rajapinnat johdetaan EJBObject luokasta. Remote rajapinnassa määritellään liiketoimintasääntöjä kuvaavat metodit, joita asiakasohjelmat kutsuvat. [Hel00] 3. EJB implementointiesimerkki: EBO Java Maestro - Java Framework for EJB server EBO Java Maestro perustuu MVC (Model-View-Controller) arkkitehtuurimalliin. Javamaestro-sovelluskehys tarjoaa työkaluja ja valmiin arkkitehtuurirungon EJBsovellusten rakentamiseen. EBO Java Framework koostuu kolmesta osasta, jotka ovat: - client framework - hajautus framework - persistenssi framework Perustana on loogisen kolmitasoarkkitehtuurin implementointi käyttämällä Enterprise Java Beans (EJB) spesifikaation mukaista toteutusta. [Ent99] Teknisesti kyse on nelitasoarkkitehtuurista: Em Entity Model tietokantataulujen oliointiin, Dm Domain Model serveriolioihin, Pm Presentation Model on kontrolleriluokka ja Am Application Model käyttöliittymäolioiden luokka. Olioita kutsutaan beaneiksi eli Em_bean, Dm_bean jne. Em ja Dm_beanit sijaitsevat palvelimella ja Am ja Pm_beanit asiakasohjelmistossa.. Mallit vastaavat EJB määrityksiä siten, että: Em Entity Model Dm Domain Model Pm Presentation Model Am Application Model EJB objekti, relaatiokannan riviä esittävä Entity Object EJB objekti, businesslogiikan sisältävä Session Object client ympäristön älykäs välitin (Smart Proxy), joka peittää näkyvistä EJB toteutuksen näyttökomponentti, joko paneeli tai frame
8 Automaattisesti tuotetut bean-ketjut ovat vakioituja ja hyvin määriteltyjä tietorakenteita, joiden tiedonvälitys eri arkkitehtuurikerrosten välillä toimii luotettavasti. Tavoitteena on yhtenäistää ohjelman osia ja abstrahoida tiedonvälitys eri kerrosten välillä MVC-mallin mukaisesti businesslogiikkaan, tietokantaan ja käyttöliittymänäkymiin. Maestrossa EJB:n toteutus on tietokantatoteutusta, toisin sanoen kehys palvelee datan tallennusta. Tietokantayhteydet hoidetaan sovelluspalvelimen kautta. Kehys generoi tietokannan tauluista automaattisesti kaikkien neljän kerroksen beanit aina käyttöliittymän generointiin asti. Generointi on kuitenkin hyvin raskas prosessi mikäli käsittelyssä on useamman kuin yhden taulun rivit. Tämä raskas lähestysmistapa voidaan kiertää käyttämällä näissä tapauksissa suoraan JDBC:tä. Maestro ei ota kantaa siihen missä dataa käsitellään. Maestro hajauttaa tietokantakäsittelyn, osa tehdään käyttöliittymässä osa palvelimessa. Maestro auttaa hallinnoimaan hajautusta ja itse asiassa peittää hajautuksen Kehys tarjoaa esimerkiksi palvelut dynaamisiin SQL-kyselyihin tietokannasta. Myös yksinkertaisten taulunäkymien esittäminen ja käsittely on mahdollista. Sovelluskehys on edelleen kehitysvaiheessa esimerkiksi transaktioiden hallinnan osalta. 4. BEA Weblogic Server BEA Weblogic Server toimii sovelluspalvelimena, joka tukee EJB spesifikaatiota Palvelin huolehtii tarvittavista infrastruktuuripalveluista, joita ovat: - hakemistopalvelu - hajautettujen transaktioiden hallinta - salauksen hallinta (security management) - rinnakkainen pääsyn hallinta - persistenssin hallinta - resurssipoolaus, esimerkiksi tietokantayhteydet 5. Case: EU:n tukijärjestelmien toteutus Seuraava toteutusesimerkki perustuu Maa- ja metsätalousministeriön tietopalvelukeskuksen (TIKE) järjestelmäkehityshankkeeseen, jonka tavoitteena on toteuttaa uusi IACS järjestelmä (integroitu hallinto ja valvontajärjestelmä) EU:n viljelijätukien hallintaan. Tukihakemusten tarkastaminen ja tallentaminen sekä maksatusten valmistelu tapahtuu kunnissa (420 toimipistettä) ja tukien valvonta TEkeskuksissa (15 kpl). Maksatukset ja raportointi suoritetaan TIKEssä. Tavoitteena on hankkeen toisessa vaiheessa toteuttaa viljelijöille mahdollisuus tehdä hakemuksensa sähköistä asiointia käyttäen (viljelijöitä on noin 80 000 kpl). Nyt toteutettavan tukijärjestelmän ratkaisumallin on tarkoituksena olla
9 arkkitehtuuriratkaisu valtaosaan EMOTR:n (Euroopan maatalouden tuki- ja ohjausosaston tukirahasto) Suomessa hallinnoitaviin tukijärjestelmiin. Tavoitteena on myös päästä organisaatioriippumattomaan järjestelmään. Tästä syystä toteutettava järjestelmä päätettiin rakentaa hyödyntäen kolmitasoarkkitehtuuria: tietokanta, sovelluslogiikka ja käyttöliittymä omille tasoilleen. Aluksi sovellus pyrittiin toteuttamaan selaimen kautta käynnistyväksi. Siitä jouduttiin kuitenkin luopumaan tehokkuussyistä ja asiakasohjelmiston toteutus on tehty Java-sovelluksena. Toteutettavan järjestelmän tietokantana on Oracle8, sillä myös nyt käytössä olevan sovelluksen keskitetty kannan osuus rakentuu Oraclen tietokannan päälle. Itse kannan rakennetta ei juurikaan muuteta. Tarjouskilpailun perusteella sovelluspalvelimeksi valittiin BEA Weblogic Server. Weblogic tarjoaa ajoalustan palvelinpään komponenteille. Peruspalvelut on toteutettu käyttäen sovelluskehyksenä Entran JavaMaestroa, jolla on toteutettu vastaavanlaisia sovelluksia eri laitteisto- ja varusohjelmistoympäristöihin. Käyttöliittymä toteutetaan Oraclen Jdeveloper Java-kehittimellä. Versionhallinnassa käytetään PVCS versionhallintaohjelmistoa. Muita sovelluskehityksen apuvälineitä ovat Withclass oliomallinnusväline sekä Javadoc sovellusdokumentointiin. Optimize It ohjelmistoa käytetään sovelluskoodin tehokkuuden tutkimiseen. Kannan kuvausta ylläpidetään Oraclen Designerissa. 5.1 Sovelluskehityskokemuksia Maestrolla Valmiin sovellusrungon käyttö mahdollisti sovelluskomponenttien koodauksen aloittamisen nopealla aikataululla. Kehitystyötä on tehty sykystä 1999. Varsinainen sovelluskoodaus alkoi keväällä 2000. Maestro kytkeytyy hyvin tiiviisti Weblogiciin ja tarjoaa valmiit välineet tietokantakäsittelyyn. Tietokantayhteyksiä ei tarvitse itse rakentaa vaan ne hoidetaan EJB speksauksen mukaisesti kaikille yhteisen tietokantapoolin kautta. Kaikki käyttävät samaa yhteyttä. Yksi metodi riittää. Beanit (kehysluokat) generoidaan kannan tauluista. Beaneja on saman verran kuin tauluja, joihin lisätään tai päivitetään tietoa eli noin 50-60. Jokaisesta beanista generoituu neljä tasoa. Esimerkiksi asiakasbean on asiakastaulun sarakkeiden kuvaaminen javakielellä, attribuuttien luku ja haku pääavaimella beanin sisällä. Koko toteutusprojektin ajan ongelmana on ollut kuitenkin Maestro sovelluskehyksen keskeneräisyys. Tuotekehitystyötä on tehty rinnan IACS:n sovelluskehityksen kanssa. Uusia versioita on tullut käyttöön ja niiden ominaisuudet eivät kaikilta osin ole vastanneet lupauksia ja määrityksiä. Sovelluskehystä kehitetään osin kaupallisena komponenttina, eivätkä MMM:n tarpeet ole kuin osin sanelemassa ratkaisuja.
10 Osa ongelmista johtuu siitä, että kehys on toteutettu täysin oliomallin mukaisesti. Isoissa sovelluksissa se merkitsee tehokkuus- ja toimivuusongelmia. Hakujen hitautta Optimize It ohjelmiston avulla analysoitaessa selvisi muun muassa, että tarkistuksen kohteeksi joutui paitsi kantaan vietävä data, myös sieltä tuotava data. Mitä enemmän kontrolleja, sen hitaampaa. Ongelmana on edelleen myös transaktioiden perumisen hallinta, joka tulee esille sisäkkäisten transaktioiden tapauksessa. Jos esimerkiksi peruslohkon jako tai yhdistäminen puretaan ja pitäisi palata alkutilaan tulee ongelmia. Osin ratkaisua voidaan hakea tietokantatoteutuksesta. Maestro on tarjonnut kehittäjille ohjelmointiohjeen. Käytäntö on sanellut loput. Varsinaisessa koodaustyössä on vain pari ohjelmoijaa sekä pääarkkitehti, joten ohjelmoinnin yhdenmukaisuus on pysynyt tätä kautta hallinnassa. Tapa tehdä koodia on jo siirtynyt kansanperinteenä projektista toiseen. Tikessä on jo aloitettu toinenkin hanke käyttäen hyväksi Maestroa ja siihen itse tehtyjä komponentteja. Iso osa käytännön työstä on ollutkin se, että komponentit saadaan keskustelemaan oikealla tavalla toistensa kanssa. Näytöt ovat samantyyppisiä, jolloin rakenteita voidaan monistaa. Toistaiseksi on päädytty siihen, että valtaosa hakulogiikasta on tehty käyttöliittymään eli Am_beaniin sillä toistaiseksi käyttäjiä on vain yhdenlaisia. Siinä vaiheessa kun viljelijät tulevat kuvaan mukaan on saatetaan sovelluslogiikka joutua siirretämään palvelimeen eli Dm_beaniin. Tällöin on huolehdittava siitä, että mikäli kytkentöjä käyttöliittymäkomponentteihin on, niin ne on riisuttava. Näitä on pyritty välttämään. 5.2 Komponenttikirjaston tarve ja komponenttipohjaisten järjestelmien ylläpito Komponenttikirjasto on olemassa, mutta hallintaväline puuttuu. Komponentit on rakennettu olemassaolevan tietokannan päälle. Kun tietokantaa muutetaan on komponentin muututtava. Tietokannan hoidon tulisi jatkossa sisältää sen päällä olevien komponenttien ylläpidon. Käytännössä komponenttikirjasto on komponenttien hakemisto ja versiohistoria. Kehitysvaiheessa ongelma näkyy sellaisena, että tehty muutos saattaa aiheuttaa pitkiä muutosketjuja ja jos tulee ongelmia niin sovelluspalvelin ei käynnisty. Komponenttikirjaston ja hallinnan tarve korostuu kun tullaan lähemmäs tuotantoa ja käsitellään valmiita komponentteja. Ennen kaikkiea ongelma on hallinnollinen. Selkeitä ylläpidon rooleja ei ole kyetty vielä hahmottamaan. Komponenttikirjaston kehittyneempi versio saattaisi olla kuvauskanta eli repository, joka sisältäisi objektihallinnan, versiohallinnan, konfiguraatiohallinnan ja ympäristöhallinnan.
11 5.3 Yleisiä johtopäätöksiä Kehitystyön aikana on tullut selvästi esille uudelleenkäytettävyyden edut. Useat aikaisemmin vaikeasti toteutettavat asiat saadaan EJB teknologialla toteutettua lyhyessä ajassa ja helposti käyttäen kerran rakennettuja komponentteja. Esimerkiksi aikaisemmin uuden näytön rakentaminen on ollut työlästä. Uusi toteutustapa vaatii kuitenkin, että uudelleenkäytettävyyttä mietitään jo hyvin aikaisessa vaiheessa projektia ja jos yleiskäyttöisyyttä halutaan niin joudutaan toimimaan sen ehdoilla. JavaMaestro on tarkoitettu kevyempään client pään käsittelyyn kuin mihin sitä nyt käytetään. Sovelluskehyksen rakenteessa painopiste on keskitasolla, kun taas IACSsovelluksessa kyse on enemmänkin fat clientista. JavaMaestron kehittäminen MMM:n näkökulmasta olisi kannattanut painottaa palvelinpuolen kehittämiseen. Tuotantoon siirryttäessä kokonaisuuden hallinta tulee olemaan melkoinen haaste, jossa on vielä paljon ratkaisemattomia kysymyksiä. [Iac00] 6 Lähteet [Ent99] [Iac00] [Hel00] Entra Business Objects Oy, Java Maestro, Java Framework for EJB server, version 0.42 IACS2000 projektin projektipäällikön ja projektiryhmän jäsenten haastattelut 2.10.2000, Sauli Sonkkila, Kyösti Könönen, Juha Mäkinen ja Ilkka Seppä http://myy.helia.fi/ comptech/ejb/ejb.htm [Kos00] Kai Koskimies, Oliokirja, Satku.fi, 2000 [Lai00] [MaH99] [Nik00] Harri Laine, Ohjelmistoarkkitehtuurit, luentomoniste, Helsingin yliopiston tietojenkäsittelytieteen laitos, 2000 Vlada Matena & Mark Hapner, May 7 1999, Sun Microsystems Enterprise JavaBeans specification, Version 1.1 Public Draft Sami Nikander, Voiko lehmästä tehdä komponentin eli komponentit Maa- ja metsätalousministeriön tietojärjestelmissä, seminaariesitelmä seminaarissa Komponenttiperustainen ohjelmistotuotanto, kevät 2000
12