JavaBeans Components

Transkriptio

1 JavaBeans Components OULUN YLIOPISTO Tietojenkäsittelytieteiden laitos Software Architectures 6. helmikuuta 2004 Mikael Kujanpää LuTK / TOL -03

2 Tiivistelmä Ohjelmistokomponentit ovat looginen jatke 80-luvulla kehitetylle olio-ohjelmoinnille. Komponentit ovat erilaisia pieniä keskenään eri tavoin kommunikoivia ohjelmapalasia, joiden tehtävänä on auttaa luomaan suurempia järjestelmiä ikäänkuin legopalikoista. Sun Microsystems kehitti JavaBeans-nimisen komponenttipohjaisen teknologian. Sen toteutus on niin sanotusti kieliriippuvainen, mutta toisaalta Javan alustariippumattomuus mahdollistaa beansien ajamisen mitä lukuisimmissa ympäristöissä. Itse JavaBeansit eivät käytännössä saavuttaneet juuri minkäänlaista jalansijaa johtuen niiden hyvin rajoittuneesta toteutuksesta, jonka tähden beansien koodaaminen oli liian työlästä. Sun Microsystems kehittikin myöhemmin niin sanotun Enterprise JavaBeansin, joka mahdollisti sovelluskehittäjien keskittymisen itse sovelluksessa käsillä olevaan ongelmaan. EJB:t saavuttivatkin sitten jo paremmin suosiota. Ohjelmistokomponentteja käytetään varsin paljon käyttöliittymäelementteinä, mutta muuten niitä hyödynnetään varsin vähän. Organisaatiot jonkin verran hyödyntävät eri tekniikoin toteutettuja komponentteja omissa projekteissaan, mutta komponenteilla tapahtuva kauppa on jäänyt ainakin toistaiseksi odotettua pienemmäksi.

3 Sisältö Tiivistelmä Sisältö 1 Johdanto 2 2 Aiheen kartoitus Ohjelmistokomponenteista yleisesti sekä niiden historiaa Java-pavut Java-pavun toiminta Analyysi Ohjelmistokomponenttien hyviä ja huonoja puolia Esimerkkiohjelma Lähdekoodit PikkuPapu.java makefile Pavun käyttöönottaminen Yhteenveto 10 Viitteet

4 1 Johdanto 90-luvulla lupaavimmaksi ohjelmistotuotannon apukeinoksi muodostui ajatus ohjelmistojen komponenttipohjaisuudesta. Tällöin muodostui monia uusia tekniikoita tavoitteen saavuttamiksi luvulla kuohunta on hiukan laantunut, eikä uusia komponenttitekniikoita olekaan enää syntynyt. Sen sijaan olemassaolevat tekniikat ovat kypsyneet. JavaBeans 1 on Sun Microsystemsin[3] kehittämä komponettipohjainen tekniikka, joka omalta osaltaan yrittää edesauttaa ohjelmistokehityksen muuttumista komponettimaisemmaksi. Käsittelen tässä kirjoituksessani Java-papujen historiaa, nykytilaa sekä papujen hyviä ja huonoja puolia. Kerron myös hiukan vastaavia asioita Java-papujen kilpailijoista. Luvussa neljä esittelen erittäin yksinkertaisen esimerkkiohjelman, jonka tehtävänä on demonstroida pientä Java-papua, sekä miten sitä voidaan hyödyntää toisen ohjelman käyttöliittymän rakentamisessa. Esimerkkiohjelma sinänsä ei ole millään tavoin käyttökelpoinen, mutta se ei ole sen tarkoituskaan. 1 Jatkossa puhuessani Java-pavuista tai pelkistä pavuista, tarkoitan JavaBeans-tekniikkaa 2

5 2 Aiheen kartoitus Tässä luvussa käsittelen aiheen taustoja. 2.1 Ohjelmistokomponenteista yleisesti sekä niiden historiaa 70-luvulla ohjelmistoteollisuus havaitsi rakenteisen ohjelmoinnin edut, ja tänä ajanjaksona ohjelmistotuotannosta tuli tarkemmin määriteltyä, hallittua ja suunniteltua toimintaa. Ohjelmat jaettiin alkeellisella tasolla tiettyihin kokonaisuuksiin. 80-luvulla rakenteellisen ohjelmoinnin ajatus jalostui: ongelmalähtöisesti tapahtunut ohjelman osittaminen erilaisiin tehtäviin havaittiin riittämättömäksi tavaksi tuottaa ohjelmistoja, joten kehittyi olio-ohjelmointi. Tällöin ohjelmistot pyrkivät mallintamaan ympäristöä mahdollisimman luontevasti jakamalla sen olioihin sekä antamalla näille tiettyjä ominaisuuksia jotka sitten määrittelivät olion. 90-luvulla Internet alkoi levitä etenkin WWW:n ansiosta, jolloin jälleen havaittiin olio-ohjelmoinnin tarjoavan riittämättömät välineet ajan haasteille. Syntyi ajatus ohjelmistojen jakamisesta komponentteihin, jotka sitten suorittavat tiettyjä tehtäviä. Osittain komponentteja hyödynnettiin jo tätäkin ennen, mutta voitaneen silti perustellusti katsoa Internetin antaneen komponenttipohjaiselle ohjelmistotuotannolle varsinaisen alkusysäyksen. Komponenttien avulla saatiin mahdolliseksi esimerkiksi tietyn toiminnon suorittaminen fyysisesti eri tietokoneella; riittää että asiakasohjelmisto ottaa yhteyttä etätietokoneeseen ja antaa sille tietyt parametrit. Etätietokone puolestaan käsittelee parametreja haluamallaan tavalla ja palauttaa asiakkaalle sitten jotain. Huomattavaa on, että etätietokoneen ei tarvitse kuitenkaan olla toinen kone: asiakasohjelmisto voi kutsua myös paikallisella tietokoneella olevaa komponenttia, esimerkiksi käyttöliittymän piirtämiseen liittyvissä asioissa. Microsoft[2] Windows on eräs ensimmäisiä suurempia ohjelmistoja, jossa komponenttiajattelua on hyödynnetty. Alunperin Windows tarjosi sovellusohjelmille niin sanotun COM-rajapinnan 2, jonka avulla muun muassa käyttöliittymäelementtien rakentaminen Windows-ohjelmiin onnistui varsin helposti. Tätä täydennettiin myöhemmin OLE-tekniikalla 3, joka mahdollisti toisen sovellusohjelman vaikkapa tekstinkäsittelyohjelman dokumentin upottamisen toiseen ohjelmaan. Tietokoneiden verkottumisen myötä Microsoft laajensi COM-malliaan kehittämällä Distributed Component Object Modelin sekä ActiveX-tekniikan, joka mahdollisti etätietokoneelta koodin ajamisen paikallisella tietokoneella. Vielä 90-luvun lopulla näytti, että ActiveX-tekniikasta tulee hyvinkin suosittu, mutta toisin kävi: etenkin lä- 2 Component Object Model 3 Object Linking and Embedding 3

6 hes täydellinen turvallisuusnäkökohtien ohittaminen loi ActiveX-tekniikasta oikean tietoturvapainajaisen, jonka seurauksena tekniikkaa hyödynnetään varsin harvoissa yhteyksissä. ActiveX on kuitenkin hyvin joustava ohjelmoijan kannalta, koska se ei ota kantaa käytettyyn ohjelmointikieleen. Sun Microsystemsin kehitti JavaBeans-tekniikan varsin myöhään, ja vasta 1997 JDK 1.1-version myötä tekniikkaa päästiin testaamaan laajemmalti käytännössä. Koska suunnittelu aloitettiin puhtaalta pöydältä, ei mallin tarvinnut kantaa historian painolastia ja näin ollen Java-pavuista kyettiinkin kehittämään varsin joustavia komponentteja. Sunin ensimmäinen versio oli kuitenkin varsin rajoittunut, eikä sen aikaisilla pavuilla voinut tehdä kovinkaan paljon mitään hyödyllistä. Sun tiedosti ongelman, ja myöhemmin ilmestyikin Enterprise JavaBeans, johon oli sisällytetty monia alkeistason toimintoja joiden ansiosta varsinaisessa sovelluksessa voitiin keskittyä käsillä olevaan ongelmaan. Keskityn tässä tekstissäni kuitenkin ainoastaan alkuperäisiin papuihin. Nimitys JavaBeans tulee johdannaisena sanasta Java. Käytetäänhän Java-papujen kanssa nimenomaisesti ohjelmointikielenä Javaa. Java-kieli puolestaan sai nimensä samannimisestä kahvista, joten loogisesti Javaan perustuva komponenttipohjainen ajattelu sai nimekseen kahvin raaka-ainekomponentin, pavun. Ohjelmistokomponentti voi toki olla myöskin paljon pienenpi palanen kuin toimiva sovellusohjelma. Pienimmillään kyse on pienen pienestä rakennuspalikasta. Sanan ohjelmistokomponentti määrittely on kuitenkin vaikeaa: esimerkiksi tunnettu komponenttitutkija Clemens Szyperski on onnistunut kokoamaan kirjallisuudesta peräti yhdeksän toisistaan huomattavasti poikkeavaa määritelmää. [6]. 2.2 Java-pavut Sun Microsystems toteutti idean Java-pavuista käytännössä ensimmäisen kerran vuonna 1997 Java Development Kitin versiossa 1.1[1]. Java-pavut perustuvat yhteen kieleen Javaan mikä on täysin päinvastainen lähestymisnäkökulma kuin Microsoftin COM-tekniikassa. Toisaalta Javan laitteistoriippumattomuus mahdollistaa papujen ajamisen missä vain Javaa tukevassa ympäristössä, COM-tekniikan rajoittuessa ainoastaan Microsoft Windowsiin. Javan ja sitä myöten myös Javapapujen etuja on sen toimivuus korkealla abstraktiotasolla. Toisaalta tämä johtaa myös suorituskykyongelmiin. JavaBeans-spesifikaatio[5] määrittelee Beanin seuraavalla tavalla: Uudelleenkäytettävä ohjelmistokomponentti, jota voidaan käsitellä visuaalisella sovelluskehittimellä 4

7 2.2.1 Java-pavun toiminta Java-pavut toimivat kahdella tasolla: [1] 1. sovelluksen kokoamisvaiheessa pavulle voidaan käyttää niin sanottuja introspektiomekanismeja sekä asettaa pavulle ominaisuuksia. 2. suoritusvaiheessa papu toimii osana sovellusta reagoiden tiettyihin tapahtumiin. JavaBeans-teknologia sisältää seuraavat pääosat: [1] Tapahtumankäsittely: Papu ilmoittaa olevansa tiettyjen tapahtumien tuottaja tai tarkkailija. Tapahtumien avulla pavut kommunikoivat keskenään. Ominaisuudet: Pavulla on ominaisuuksia, attribuutteja, joita voidaan muuttaa ohjelmallisesti tai erityisen papujensuunnitteluun tarkoitetun työkalun avulla. Itsekuvaavuus: Papu kuvailee itse itsensä, jolloin papuja voidaan käsitellä ohjelmallisesti. Räätälöitävyys: Pavun ominaisuuksien arvoja muuttamalla voidaan pavun ilmentymää muuttaa tarpeen mukaan hyvinkin radikaalisti. Muuttaminen voidaan hoitaa ohjelmallisesti tai käyttämällä erityistä työkalua. Pysyvyys: Pavun tila voidaan ladata ja tallentaa. 5

8 3 Analyysi Yleistin tämän luvun koskemaan ohjelmistokomponentteja yleisesti, koska esittämäni näkökohdat eivät ole mitenkään rajautuneet Java-papuihin. 3.1 Ohjelmistokomponenttien hyviä ja huonoja puolia Ohjelmistokomponenttien eduiksi luetaan muun muassa [1] niillä toteutettujen ohjelmistojen luotettavuus, edullisuus, nopeutunut kehitysprosessi, joustavuus, yhteensopivuus muiden järjestelmien kanssa sekä projektien parempi ennustettavuus. Luotettavuus syntyy lähes itsestään, koska käyttämällä samaa komponenttia monessa eri tilanteessa hioutuu siitä suurin osa virheistä pois. Myöskin suurempia kokonaisuuksia on helpompi suunnitella kun käytössä on tietynlaisia, perustoimintoja toteuttavia palikoita. Mikäli peruskomponentit ovat hyvin suunniteltuja, on niiden avulla erittäin helppoa rakentaa mitä erilaisimpia ohjelmistoja, ja keskittyä näin ollen juuri kyseisen sovelluksen omien ongelmien ratkomiseen. Yhteensopivuutta muiden järjestelmien kanssa saavutetaan sillä, että ohjelmistokomponenttien käyttämät rajapinnat ovat yhdenmukaisia, ja esimerkiksi johonkin tiettyyn tarkoitukseen suunniteltua verkkoprotokollaa voidaan käyttää samanlaisena eri yhteyksissä. Nämä edut yhdistettynä johtavat kokonaisuudessaan edullisempiin ja nopeammin valmistuviin ohjelmistoihin. Ohjelmistokomponentit kuulostavat teoriassa erittäin käyttökelpoisilta, ja onkin oikeastaan pieni ihme etteivät ne ole yleistyneet eri yhteyksissä sen enempää kuin ovat. Tilanteeseen vaikuttavat monet eri tekijät, mutta syyllisiä ovat myös komponentit itse: on vaikeata löytää sopivaa komponenttia suuresta tarjonnasta, komponentit itsessään eivät ole keskenään yhteensopivia, 6

9 komponentti ei välttämättä tee sitä mitä sen pitäisi. Oikean komponentin löytäminen voi olla vaikeata, koska eri ohjelmistoyritykset tarjoavat erilaisia keskenään hiukan erilaisia komponentteja eri tehtäviä hoitamaan. Tästä seuraa myös, että vaikka komponenttien avulla voidaankin luoda optimissa tilanteessa yhteensopivampia järjestelmiä, eivät itse komponentit ole keskenään yhteensopivia: rajapinnat eroavat toisinaan paljonkin. Komponentti ei myöskään välttämättä tee sitä mitä sen haluttaisiin tekevän. Tällaisessa tilanteessa, mitä isommasta komponentista on kyse, ohjelmisto joutuu mukautumaan käytettävään komponenttiin. Hankalassa tapauksessa alkuperäisestä tuotteesta voidaan joutua jättämään jopa jotain toiminnallisuutta pois. Pahimmillaan puolestaan koko projekti voi kaatua komponentin soveltumattomuuteen tällainen tilanne tosin ei liene itse ohjelmistokomponentin vika, vaan äärimmäisen kehnon suunnittelun. Reaalimaailmassa ohjelmistokomponentit eivät ole saavuttaneet kovinkaan merkittävää asemaa. Yksi poikkeus tosin löytyy: graafiset käyttöliittymäkomponentit. Niihin oliomainen ja näin syntyvä komponenttipohjainen ohjelmistokehitys sopii erittäin hyvin. Ohjelmistokomponenttien ongelmiksi luetellut asiat eivät useinkaan ole itse komponenttien vikoja, vaan reaalimaailman tavan niiden hyödyntämisessä. Toki ohjelmistokomponentteja käytetään paljon pienemmässä mittakaavassa, esimerkiksi organisaation sisällä. Tyypillisesti komponentteja hyödynnetäänkin juuri näin. 7

10 4 Esimerkkiohjelma Esittelen tässä luvussa äärimmäisen yksinkertaisen Java-pavun. Luon pavun, joka esittää visuaalisesti mustan neliön, jonka sivun pituus on 100 pikseliä. Kyseinen papu voidaan ottaa käyttöliittymäelementiksi esimerkiksi Sun Microsystemsin Bean Builderiin[4]. Esimerkkiohjelman pavulla ei tee yhtään mitään, eikä sillä ole edes omia attribuutteja, ainoastaan Canvas-yläluokalta perityt. Tällaisenaan pavulla ei siis tee yhtään mitään, mutta esimerkin tarkoitus onkin vain olla mahdollisimman yksinkertainen, Java-papujen käyttöä esittelevä ohjelmanpätkä. 4.1 Lähdekoodit PikkuPapu.java import java.awt.*; import java.io.serializable; public class PikkuPapu extends Canvas implements Serializable { } // Konstruktori alkuarvoille: public PikkuPapu(){ setsize(100,100); setbackground(color.black); } makefile CLASSFILES= PikkuPapu.class JARFILE= PikkuPapu.jar ALL: $(JARFILE) $(JARFILE): $(CLASSFILES) $(DATAFILES) echo "Name: PikkuPapu.class" >> manifest.tmp echo "Java-Bean: True" >> manifest.tmp jar cfm $(JARFILE) manifest.tmp manifest.tmp %.class: %.java export CLASSPATH; CLASSPATH=. ; \ javac $< clean: /bin/rm -f *.class /bin/rm -f $(JARFILE) 8

11 4.2 Pavun käyttöönottaminen Papu täytyy ensin kääntää. Tekemäni makefilen avulla se onnistuu GNU/Makea käyttämällä kirjoittamalla yksinkertaisesti komennoksi make. Tällöin luodaan tiedostot PikkuPapu.class ja PikkuPapu.jar. Hetkellisenä tilapäistiedostona palvelee manifest.tmp, tämä kuitenkin poistetaan käännöksen lopussa. Java-papu ladataan Bean Builderiin valitsemalla file -valikosta kohta Load Jar File. Sen jälkeen Papu-ilmestyy User-välilehdelle, josta se voidaan tiputtaa osaksi muuta ohjelmaa muiden käyttöliittymäkomponenttien joukkoon. Kuvassa 1 on yleisnäkymä, kun papu on lisätty uuteen projektiin. Kuvassa 2 on korostettu työkaluriviin lisätty uusi papu, ja kuvassa 3 on korostettu lomakkeelle tiputettu uusi papu. Kuva 1: Yleisnäkymä Bean Builderissa Kuva 2: Bean Builderin työkalupakki 9

12 Kuva 3: Bean Builderilla rakennettu lomake 5 Yhteenveto Ohjelmistokomponentit ovat saavuttaneet suosiota etenkin käyttöliittymäteknisissä tehtävissä. Tosin Java-pavut eivät ole saavuttaneet suosiota oikeastaan missään paikoissa niiden rajoittuneesta luonteesta johtuen. Tätä ongelmaa korjaamaan Sun Microsystems suunnittelikin kehittyneemmän version Java-pavuista, Enterprise Java Beans. Java-pavut olivat aikanaan kuitenkin hyvänä suunnannäyttäjä kehitykselle, ja jatkojalostuksen tuloksena Enterprise Java-papuja käytetäänkin jonkin verran etenkin verkon yli toimivissa sovelluksissa. 10

13 Viitteet [1] Kai Koskimies. Oliokirja. Satku Kauppakaari, Gummerus kirjapaino, Jyväskylä, [2] Microsoft. [3] Sun Microsystems. [4] Sun Microsystems. The Bean Builder. Welcome.jsp?StoreId=22&PartDetailId=7262-bean_builder-1.0-beta-oth-JPR &SiteId=JSC&TransactionId=noreg. [5] Sun Microsystems. JavaBeans 1.01 Specification. Ecom/docs/Welcome.jsp?StoreId=22&PartDetailId=7224-javabeans-1.01-fr-s pec-oth-jspec&siteid=jsc&transactionid=noreg. [6] Clemens Szyperski. Component Software Beyond Object-Oriented Programming. Addison-Wesley,