JavaBeans ja ActiveX
Tiivistelmä
Tässä seminaariesitelmässä tutustutaan WWW-sivuilla käytettäviin komponentteihin ja niiden pohjana oleviin komponenttiluokkiin. Tarkemmin perehdytään JavaBeans- ja ActiveX-luokkiin, joita tutkitaan teorian ja esimerkkien avulla. Lisäksi vertaillaan niiden vahvuuksia ja heikkouksia eri käyttöympäristöissä.
Avainsanat: komponentti, komponenttiluokka, ActiveX, JavaBeans, internet ja WWW.
Sisällysluettelo
World Wide Webin eli WWW:n suosio on viime vuosina kasvanut räjähdysmäisesti, ja samalla WWW-sivujen määrä on kasvanut. Myös sivujen muoto ja niiden sisältö ovat saaneet monia uusia ominaisuuksia, grafiikan ja animaatioiden määrä on lisääntynyt ja sivuille on tullut ripaus interaktiivisuutta. Tähän kehitykseen ovat auttaneet osaltaan WWW-selainten ominaisuuksien lisääntyminen, Java-ohjelmointikielen käyttö JavaScriptin ja applettien muodossa, sekä erilaiset interaktiiviset komponentit. Näiden komponenttien pohjana voidaan käyttää monia luokkia, kuten CORBA:a, ActiveX:ä ja JavaBeansejä. Tässä seminaariesitelmässä perehdytään kahteen viimeisimpänä mainittuun.
JavaBeans on Sun Microsystemsin Java-kieleen pohjautuva komponenttiluokka. Sen suurin etu on riippumattomuus alla toimivasta käyttöjärjestelmästä, mutta Beansit on kirjoitettava aina Java-kielellä. Microsoftin kehittämä ActiveX on puolestaan käyttöympäristönsä puolesta rajoittuneempi, sillä se vaatii käytännössä Windows-käyttöliittymän. Etuna on puolestaan se, että ActiveX-komponentteja voidaan kirjoittaa lähes kaikilla ohjelmointikielillä.
Toisessa luvussa tutustutaan komponentteihin ja komponenttiluokkiin yleisellä tasolla. Kolmannessa luvussa perehdytään ActiveX-komponentteihin, erityisesti niiden käyttöön WWW-sovelluksissa. Neljännen luvun sisältö käsittelee JavaBeans-komponentteja ja ActiveX:n tavoin tutustutaan esimerkkeihin lähinnä WWW-ympäristössä. Viidennessä luvussa vertaillaan näiden kahden kilpailevan komponentiluokan heikkouksia ja vahvuuksia. Lisäksi kuudennessa luvussa luodaan silmäys komponenttiohjelmoinnin tulevaisuuteen.
Tässä luvussa tutustutaan komponentteihin ja komponenttiluokkiin yleisesti. Lisäksi luodaan lyhyt katsaus niiden historiaan ja käyttöön.
Komponenteilla (engl. component) tarkoitetaan uudelleenkäytettäviä "rakennuspalikoita", joita voidaan hyödyntää luotaessa ohjelmaa tai WWW-sovellusta. Nykyisissä graafisissa sovelluskehittimissä on suuri joukko valmiita komponentteja ohjelmoijien käyttöön, mutta myös omien komponenttien kehittäminen on mahdollista. Lisäksi saatavissa on paljon erilaisia valmiita komponentteja, ilmaiseksi tai maksua vastaan.
Ohjelmoijan näkökulmasta tärkeintä on ehkäpä mahdollisuus kehittää juuri halutunlainen komponentti, jos tarvittavat ominaisuudet sisältävää ei vielä löydy. Komponentin on kuitenkin täytettävä tietyt ominaisuudet. Tähän tarvitaan komponenttiluokkaa, jonka määrittelemien rajojen puitteissa komponentit käyttäytyvät ja kommunikoivat toistensa kanssa.
Jotta komponenttiluokka olisi toimiva, on jokaisen siihen kuuluvan komponentin sisällettävä tiettyjä ominaisuuksia:
- Komponentin on osattava kuvailla itsensä, eli sen pitää pystyä yksilöimään kaikki ominaisuudet (engl. properties), joita voidaan muokata sitä määriteltäessä. Lisäksi kaikki sen luomat tapahtumat (engl. events) ja käyttämät metodit (engl. methods) on oltava yksilöitävissä.
- Komponentin ominaisuuksia on voitava muokata sekä suoraan ohjelmointikielellä että graafisesti.
- Komponentin on luotava tapahtumia tai tarjottava joku muu mekanismi, joilla ohjelmoija saa sen kytketyksi muihin komponentteihin.
Se, miten nämä ominaisuudet on määritelty ja ne on ohjelmoitava, riippuu käytettävästä komponenttiluokasta.
Jos keskimmäinen kohta unohdetaan, voidaan esimerkiksi tavallinen lyijykynä katsoa kuuluvaksi ns. lyijykynäluokkaan. Lyijykynällä on ominaisuuksia, kuten pituus ja terävyys, ja tapahtumia, mm. kynän tylsyminen tai terän katkeaminen. Lisäksi on olemassa esim. teroitus-metodi. Lyijykynä-komponentti saadaan myös kytkettyä muihin komponentteihin, kuten paperi-, pyyhekumi- tai kirjoittajakomponenttiin.
Ohjelmistoteollisuudella on ollut jokaisella kolmella viimeisimmällä vuosikymmenellä yksi asia ylitse muiden. Seitsemänkymmentäluvulla tuo jokin oli rakenteiset ohjelmointikielet ja kahdeksankymmentäluvulla olio-ohjelmointi. Yhdeksänkymmentäluvulla ns. suureksi jutuksi ovat nousseet uudelleenkäytettävät komponentit. Tällä vuosikymmenellä onkin esitelty suuri joukko komponenttiluokkia, kuten OpenDoc, CORBA, ActiveX ja JavaBeans, joten usko komponentteihin on suuri.
Komponenttiajattelu alkoi tulla ohjelmointiin graafisten sovelluskehittimien mukana. Näiden myötä suurienkin (graafisten) ohjelmakokonaisuuksien koodaus muuttui helpommaksi, koska käyttöliittymän rakentamisesta tuli erilaisten komponenttien, kuten nappuloiden ja tekstikenttien, sijoittelua lomakkeille. Myös komponenttien ominaisuudet saatiin suuressa määrin määriteltyä ilman koodin kirjoittamista, ainoastaan komponentteihin liittyvien tapahtumien käsittely vaati koodaustaitoa.
Sauraavaksi ilmeni tarvetta hieman monimutkaisemmille komponenteille, joita ei ohjelmien valmiissa komponenttikirjastoissa ollut. Aluksi nämä itsetehdyt komponentit olivat käytettävissä vain siinä ohjelmassa ja käyttöympäristössä missä ne oli kehitetty. Tämän jälkeen ryhdyttiinkin luomaan määrityksiä yleiskäyttöisille komponenteille. Komponenttien ja komponenttiluokkien suosiota on lisäksi kasvattanut niiden käyttö myös internet-sovelluksissa.
Komponenttien käytön yleistyminen avaa mahdollisuuksia myös uudenlaiselle yritystoiminnalle. Suuntaus ohjelmistotuotannossa tullee siirtymään ohjelmakomponenttien tuottamiseen ja markkinointiin. Tämä on mahdollista myös pienille ja hyvinkin tarkkaan erikoistuneille ohjelmistoyrityksille, sillä komponenttien levittäminen verkon välityksellä ei tuo kovin suuria lisäkustannuksia verrattuna tavalliseen kaupankäyntiin. Ohjelmistokomponenttien kaupasta odotetaankin yhtä nopeimmin kasvavaa Internet-kaupan osaa.
Komponenttien käyttö sovelluksen kehityksessä perustuu oikeastaan jo ikivanhaan ajatukseen pyörän keksimisestä. Jos pyörä on kerran jo keksitty, miksi se pitäisi keksiä uudestaan? Voidaankin sanoa, että ohjelmakomponenttien käyttö muistuttaa suuresti Lego-palikoiden kanssa puuhastelua. Suuret kokonaisuudet pyritään rakentamaan mahdollisimman suurista ja valmiista palasista, eikä aivan pienimmistä paloista. Tämä paitsi nopeuttaa kehitystyötä säästäen aikaa ja rahaa, se myös edesauttaa luotettavampien sovellusten tuottamista. Jos on kerran luonut ja määritellyt sisäisesti hyvin toimivan komponentin, on sen toiminta ja luotettavuus suuremman kokonaisuuden osana helpompaa saada kuntoon. Lisäksi markkinoilla on jo suuri määrä valmiita komponentteja, ja määrä kasvaa koko ajan.
Tässä luvussa tutustutaan Microsoftin kehittämän ActiveX:n käyttöön lähinnä verkkokäytössä. ActiveX-komponenttien ohjelmointia tarkastellaan niin teoriassa kuin esimerkkien avulla.
ActiveX on Microsoftin vastaus verkko-ohjelmoinnin tarpeisiin. Se on oikeastaan sarja teknologioita, joilla eri ohjelmointikielillä tehdyt ohjelmat saadaan yhdistettyä samalla WWW-sivulla. ActiveX on kuitenkin vain osa Microsoftin Active -Platform konseptia, joka puolestaan on merkittävä osa Microsoftin internet-strategiassa.
ActiveX:n juuret ovat Microsoftin aiemmin kehittämässä Object Linking and Embedding-komponenttimallissa (OLE). Tämä puolestaan perustuu saman yhtiön Component Object Modeliin (COM), joten ActiveX ei siis ole mikään uusi ja ihmeellinen verkkoteknologia. Se on oikeastaan OLEsta kehitetty uusi versio, johon on lisätty uusia ominaisuuksia, lähinnä verkkotoimintoihin liittyviä. Rakenteellisiltaan perusperiaatteiltaan ActiveX ei kuitenkaan eroa suuresti OLE:sta.
Microsoft suunnitteli ActiveX:n edeltäjän, OLE-teknologian, alunperin linkitettyjen tiedostojen suoraan editointiin kohdesovelluksessa. Komponentit tulivat mukaan vasta myöhemmin. Nykyään ActiveX voidaan jaotella viiteen erilliseen osakokonaisuuteen: ActiveX-kontrollit, ActiveX-skriptit, ActiveX-dokumentit, Java Virtual Machine ja Active Server Framework.
ActiveX-kontrollit tai -komponentit toimivat samaan tapaan kuin Java-appletit. Niiden avulla voidaan lisätä WWW-sivuille painikkeita ja muita käyttöliittymäobjekteja. ActiveX-komponentit ovat kuitenkin käyttöjärjestelmäkohtaisia, koska ne yleensä käännetään konekielisiksi. Lisäksi monet niiden ominaisuuksista vaativat OLEa tukevan käyttöjärjestelmän toimiakseen.
ActiveX-skriptit ovat WWW-sivuille lisättäviä skriptejä, joiden ohjelmointiin voidaan käytää joko VBScriptiä tai JavaScriptiä. Ne mahdollistavat WWW-sivuilla olevien lomakkeiden, ActiveX-komponenttien ja Java-applettien ohjauksen.
ActiveX-dokumentit ovat lähinnä OLEn alkuperäistä käyttötarkoitusta. Niiden avulla voidaan internet-selaimen kautta muokata muilla ohjelmilla tehtyjä dokumentteja avaamatta ollenkaan kyseisiin dokumentteihin liittyvää ohjelmaa. Lisäksi dokumenttien suoraa muokkausta helpottaa se, että esimerkiksi tekstinkäsittelyohjelman valikot ja työkalupalkit tulevat näkyviin selaimen ikkunaan.
ActiveX:n JavaVirtual Machine mahdollistaa puolestaan Java-applettien käytön. Active Server Framework taas tukee WWW-palvelimen ohjelmointia.
ActiveX-komponenttien ohjelmointi ei ole rajoitettu mihinkään tiettyihin ohjelmointikieliin tai -työkaluihin. Vain komponenttien rakenne ja rajapinnat ovat komponenttiluokan määräämiä. Tämä tarjoaa ohjelmoijalle paljon valinnan varaa pakottamatta häntä opettelemaan uutta kieltä komponenttien kehitystä varten. Lisäksi monissa sovelluskehittimissä on nykyään hyvä tuki ActiveX-komponenttien kehittämiselle.Yleisimpiä työkaluja ActiveX-kehityksessä lienevät tällä hetkellä Borlandin Delphi sekä Microsoftin Visual C++ ja Visual Basic.
Ongelmaksi ActiveX-komponenttien kehityksessä tulee kuitenkin niiden hallinta varsinkin, jos komponentti muodostuu kovin monimutkaiseksi. Ohjelmointi uhkaa myös jäädä hyvin pintapuoliseksi ohjelmointityökalujen kehittyneisyyden takia. Lähes jokaisessa ActiveX-komponenttien kehitystä tukevassa ohjelmassa on jonkinlainen "ekspertti", jonka avulla saa helposti luotua omia komponentteja. Tähän apu siten yleensä tyssääkin. Jos haluaa tutustua ActiveX-komponenttien ohjelmointiin hieman syvemmältä, on tarvittavaa dokumentaatiota vaikea saada. Komponenttien luonti olisikin vähemmän ohjelmointia harrastaneelle vaikeaa ilman Windows-ympäristön kehittyneitä työkaluja.
ActiveX-komponentteja voidaan käyttää paitsi WWW-sivuilla, myös aivan tavallisissa graafisissa sovelluksissa. Yleisin ja käytännössä ainoa käyttöympäristö on Windows, mutta ActiveX-arkkitehtuuri on käännetty myös UNIX- ja MacIntosh-ympäristöihin. Jokaiseen käyttöympäristöön pitää kuitenkin kääntää omat komponenttiversiot ja ne pitää myös päivittää jokaisen muutoksen jälkeen.
Sovelluksissa ActiveX-komponenttien käyttö on samanlaista kuin sovelluskehittimen omien komponenttien. Aivan samoin kuin muut komponentit, ActiveX-kontrolli lisätään sovellukseen. Myös tapahtumien käsittely ja ominaisuuksien muokkaus tapahtuu samalla tavalla kuin muilla komponenteilla.
ActiveX-komponentit saadaan liitettyä WWW-sivulle ns. ActiveX-skriptin avulla. VBScriptillä tai JavaScriptillä koodatut ActiveX-skriptit mahdollistavat erilaiset komponenttien tapahtumien käsittelyt ja ominaisuuksien muokkaukset.
Komponenttien toimiminen WWW-sivuilla on kuitenkin hieman rajoittunutta. Ainoa ActiveX:n kaikkia ominaisuuksia ymmärtävä selain on Internet Explorer, jonka versiot 3.0:sta eteenpäin sisältävät hyvän tuen. Toiseen suosittuun selaimeen, Netscape Navigatoriin, on puolestaan saatavilla lisäpalikka (plug-in) jolla ActiveX-komponentit saadaan toimimaan.
ActiveX-komponenttien käyttöä esitellään tarkemmin autolaskuri-esimerkin avulla.
Esimerkkinä toimii tuttu ja turvallinen autolaskuri. Siinä nappeja painamalla voi lisätä henkilö- ja kuorma-autojen määrää niiden omissa kentissään. Myös kenttien nollaus on mahdollista.
ActiveX-autolaskuri on toteutettu kolmen button- ja kahden label-komponentin avulla. Lisäksi näiden yksinkertaisten ActiveX-komponenttien tapahtumia ohjaamaan on tehty VBScriptillä tapahtumankäsittelijät.
Kuva 1. ActiveX:llä tehty autolaskuri
Esimerkissä tapahtumia on kolme, eli jokaisen nappulan painaminen muodostaa oman tapahtumansa. Jokaisella lapahtumalla on myös oma tapahtuman käsittelevä aliohjelma. Esimerkiksi painettaessa nollausnappulaa ButtonNollaa suoritetaan tätä tapahtumaa vastaava aliohjelma Sub ButtonNollaa_Click(). Tämä aliohjelma yksinkertaisesti asettaa molempien tekstikenttien tekstiksi nollan. Molempien lisäysnappuloiden tapahtumankäsittelijät puolestaan kasvattavat vastaavien tekstikenttien lukuarvoa yhdellä.
ActiveX-autolaskurin tiedostolistaus löytyy liitteestä 1.
Seuraavassa tutustutaan Java-kielen omaan komponenttiluokkaan, nimeltä JavaBeans. JavaBeans-komponenttien ohjelmointia tutkitaan teoriassa ja käytännön esimerkkien avulla.
JavaBeans on siis Java-kielen tarpeita varten kehitetty komponentiluokka. Sun Microsystems on kehittänyt komponenttimalliaan yhdessä lukuisten ohjelmistotalojen kanssa. Tällä on pyritty saamaan heti alkuun mahdollisimman laaja tuki komponenttien käyttöönotolle.
Koska itse Java-kielikin on uusi keksintö, on myös JavaBeans-komponenttimalli hyvin tuore. Ensimmäinen JavaBeans API-määritys ilmestyi alkuvuonna 1997 ja siitä hieman paranneltu versio 1.01 saman vuoden heinäkuussa. JavaBeans-määritykset ovat jatkuvasti erilaisten pienten muutoksien ja lisäysten kourissa, mutta periaatteet pysyvät samoina. Tähän pysyvyyteen on pyritty, jotta komponenttien kehittäjät eivät epäröisi siirtyä JavaBeansien pariin.
Komponenttimallin nimi JavaBeans juontaa itse Java-kielen nimen historiasta. Java sai nimensä saman nimisen kahvilaadun mukaan. Koska kahvi jauhetaan pavuista, oli JavaBeans looginen nimitys.
JavaBeans-komponenttimalli eroaa lähtökohdiltaan suuresti ActiveX:stä. Suurin ero on siinä, että JavaBeansilla ei ole mitään varsinaista edeltäjää, vaan sen kehitystyö on päästy aloittamaan puhtaalta pöydältä. Tämä on tietenkin kasvattanut työmäärää, mutta samalla on voitu ottaa oppia muista komponenttimalleista, niiden vahvuuksista ja heikkouksista.
Yksi suuri syy siihen, että Sun halusi kehittää Java-kielelleen kokonaan uuden komponenttimallin oli jo olemassaolevien teknologioiden monimutkaisuus. Tämä taas soti Javan perusperiaattetta, helppokäyttöisyyttä vastaan. Kehittämällä JavaBeansit yhteistyökumppaneidensa kanssa Sun pystyi luomaan juuri Java-kielen ominaisuuksia parhaiten hyödyntävän komponenttiluokan, joka pysyy yhtiön "keep it simple" -filosofian mukaisena.
JavaBeans-komponentit tulee, kuten nimestä voi päätellä, ohjelmoida Java-kielellä. Tämä voi olla monille ohjelmoijille hieman rajoittavaa. Jos ei ole aiemmin tutustunut Javaan, voi jälleen uuden ohjelmointikielen opettelu tuntua hieman turhalta. Java-kielen suosio on kuitenkin kovassa kasvussa, joten tämä kehitys vaikuttanee myös JavaBeansien suosioon. JavaBeans-komponenttien kehitystä tukevia ohjelmointityökaluja alkaa myös löytymään useita. Näitä ovat mm. Borland JBuilder, Symantec Visual Café sekä Sunin oma Beans Development Kit.
Beansien ohjelmointi on tavalliseen ohjelmointiin verrattuna rajoitettua. Rajoitetuksi ohjelmoinnin tekee vaatimus tiettyjen nimeämis- ja suunnittelusääntöjen noudattamisesta. Tämä toisaalta tukee Java-kielen omien hyvien ohjelmointitapojen toteuttamista.
JavaBeanin tulee julkaista omat ominaisuutensa (engl. properties), metodinsa (engl. methods) ja tapahtumansa (engl. events). Tähän JavaBeans-määritykset tarjoavat kuitenkin elegantin ratkaisun, kaksi eri tapaa tutkia komponentin sisältöä. Reflection- ja introspection-prosessien välityksellä pääsovellus voi lukea komponentin sisällön.
Helpoimmalla tasolla JavaBeans-komponentti käyttää mahdollisuuksiensa julkaisemiseen reflection-prosessia ja rakennekaavioiksi (engl. design patters) kutsuttuja nimeämissääntöjä, joita Beansien kehittäjien tulisi noudattaa. Yleiskäyttöiset menetelmät voidaan siis julkaista rakennekaavioiden avulla antamalla niiden tyypiksi public. Vastaavasti protected- tai private-määrityksellä saadaan halutut komponentin osat piilotetuksi ulkomaailmalta.
Jos komponentti sisältää getLabel- ja setLabel-metodit, tästä pääsovellus saa selville komponentin sisältävän Label-ominaisuuden. Myös tapahtumat saadaan selville reflection-prosessin kautta. Jos nimeät tapahtumat alkamaan sanoilla add ja remove, pääsovellus voi päätellä vastaavien tapahtumien toiminnan. Tämän ansiosta mikä tahansa JavaBean-sovellus voi lukea minkä tahansa JavaBeans-komponentin sisältöä, mikäli nimeämiskäytäntöjä on noudatettu.
Joidenkin ohjelmoijien mielestä tapahtumien ja vastaavien nimeämisen pitäisi olla vapaata. Tätä varten on olemassa introspection-prosessi. JavaBeans-komponentti voi sisältää täsmällistä tietoa itsestään BeanInfo-luokassa, joka sisältää kaikki komponentissa käytetyt ominaisuudet, menetelmät ja tapahtumat. Haluttaessa tietoa tietystä komponentista, etsitään sen BeanInfo-luokkaa introspection-prosessilla ja käytetään tästä paketista löytyneitä ominaisuuksien, metodien ja tapahtumien nimiä. Jos vastaavaa BeanInfo-luokkaa ei löydy, käytetään reflection-prosessia.
JavaBeans-komponentteja voi ActiveX-komponenttien tapaan käyttää sekä internet-sivuilla että sovellusohjelmissa. JavaBeansit vaativat siis aina jonkin alustan toimiakseen.
Tässä JavaBeans-komponentit eivät eroa ActiveX-komponenteista. Niitä pystytään lisäämään sovellukseen aivan samoin kuin ohjelman omia komponentteja. Lisäksi ominaisuuksien ja tapahtumien käsittely ei juurikaan eroa muiden komponenttien vastaavista.
WWW-sivulle JavaBeans-komponentin saa puolestaan näkyviin Java-appletin avulla. Appletin tarvitsemat luokkatiedostot, kuten myös mahdollisesti tarvittavat kuvat ja muut lisätiedostot, saadaan pakattua ns. jar-tiedostoon. Tämän oikeastaan tavallisen zip-pakattu tiedoston ansiosta komponenttien lataus verkon yli nopeutuu. Tästä tiedostosta appletti sitten etsii tarvittavan komponentin ja muut sen käyttämät tiedostot.
Molemmat suuret WWW-selainkehittäjät, Microsoft ja Netscape, ovat ilmoittaneet tukensa JavaBeans-määritykselle. Lisäksi Sunin oma selain, kokonaan Javalla ohjelmoitu HotJava Browser tukee JavaBeans-komponentteja.
JavaBeansien käyttöä WWW-sivuilla käydään tarkemmin läpi autolaskuri-esimerkin avulla.
JavaBeans-autolaskuri koostuu kahdesta LaskuriBean-komponentista, jotka puolestaan sisältävät label-tyyppisen tekstikentän arvoLabel ja lisaaButton-nappulan. Lisäksi nollaustoimintoa varten on oma nappulansa.
Kuva 2. JavaBeans-komponenteilla osittain toteutettu autolaskuri
LaskuriBean-komponentti on luotu JBuilderilla asettamalla tekstikenttä ja nappula suoraan lomakkeelle. Tämän jälkeen komponenttien ominaisuuksia on muokattu ja lisäksi on luotu uusi buttonLabel-ominaisuus. Vastaavien setButtonLabel- ja setButtonLabel-metodien avulla ominaisuutta saadaan muokattua. Tämän ominaisuuden avulla lisäysnappulan tekstin voi valita lisättäessä LaskuriBean-komponentti uuteen sovellukseen. Lisäksi komponentille on luotu Nollaa-metodi, jota pääsovelluksesta kutsumalla saadaan arvoLabel-kentän arvo nollattua. Tämän jälkeen LaskuriBean-komponentti on lisätty JBuilderin muiden komponenttien joukkoon erityisen "ekspertin" avulla.
Varsinaisen autolaskurin tässä tapauksessa muodostaa WWW-sivulle lisättävä AutoLaskuri-appletti. Tähän applettiin tuli kaksi kappaletta LaskuriBean-komponenttia, laskuriBeanHA ja laskuriBeanKA, joiden buttonLabel-ominaisuudet asetettiin oikeiksi. Lisäksi nollausta varten lisättiin vielä yksi nappula. Koska molemmat LaskuriBean-komponentit sisäisesti hoitavat autojen lukumäärän kasvattamisen nappia painettaessa, tarvitaan ainoastaan nollauksen saaminen toimintaan. Tämä saadaan toimimaan kutsumalla nollausnappulaa painettaessa molempien LaskuriBean-komponenttien Nollaa-metodia.
LaskuriBean-komponentin ja AutoLaskuri-appletin ohjelmalistaukset löytyvät liiteestä 2.
Tässä luvussa vertaillaan kahden kilpailevan komponenttiluokan vahvuuksia ja heikkouksia verkkokäytössä. Niiden perusteella esitetään sitten molemmille komponenttiluokille sopivat toimintaympäristöt.
Yleisen käsityksen mukaan JavaBeans ja ActiveX käyvät keskenään sotaa sovelluskehittäjien suosiosta. Kieltämättä käynnissä on kova kisa, vaikka näin ei kuitenkaan välttämättä tarvitsisi olla. Tarkempi tarkastelu osoittaa komponenttiluokkien olevan oikeastaan toisiaan täydentäviä, ei siis keskenään kilpailevia. Molemmilla on tiettyjä ominaisuuksia, jotka tekevät ne tietyissä tapauksissa paremmaksi kuin "kilpailijan." Suurimmat erot löytyvät käyttöympäristön laajuudesta ja turvallisuusnäkökohdista.
Valittaessa omaan tarpeeseen sopivaa komponenttiluokkaa, on pohdittava ainakin viittä seuraavissa kappaleissa esitettyä valintakriteeriä ja niiden tärkeysjärjestystä juuri omassa tapauksessa.
Kehitystyökalujen saatavuudessa on ActiveX tällä hetkellä selkeä johtaja. Monet ohjelmistotyökalut, kuten Microsoftin Visual Basic ja Visual C++ sekä Borlandin Delphi tukevat ActiveX-komponenttien kehitystä. Lisäksi valmiita ActiveX-komponentteja on olemassa jo lähes joka tarpeeseen ja uusia ilmestyy koko ajan. JavaBeans-komponenttien rynnistystä on hidastanut työkalujen puute. JDK 1.1:n ilmestymisen myötä tuki on kuitenkin ilmestynyt jo lähes kaikkiin Java-sovelluskehittimiin. Esimerkkeinä mainittakoon Borlandin JBuilder ja Symantecin Visual Café. Myös Sun Microsystemsin oma Beans Development Kit on tullut lisäämään työkalujen määrää, ja se on kaiken lisäksi ilmainen. Microsoft on myös luvannut, että Visual J++:n seuraava versio tukee sekä JavaBeans- että ActiveX-määrityksiä.
Suorituskyvyssäkin ActiveX vetää pidemmän korren. Koska sillä on kaikki aidon sovelluksen ominaisuudet, se pystyy ottamaan täyden hyödyn käyttöjärjestelmän (Windows) API-rajapinnan kautta tarjoamista resursseista. Tähän Java ja JavaBeans eivät ainakaan vielä pysty. Tulevat Java-määritykset tarjonnevat tähän kuitenkin mahdollisuuden, mutta silloin häviää yksi Javan vahvuuksista: käyttöjärjestelmäriippumattomuus, josta tarkemmin myöhemmin tekstissä. Yksi syy JavaBeansien huonompaan suorituskykyyn on kuitenkin juuri Java-määrityksissä.
Turvallisuus on yksi keskeinen näkökohta puhuttaessa komponenttien käytöstä internetissä. Koska Java-kieli kehitettiin nimenomaan verkkoympäristöön, on siinä erilaiset turvallisuusnäkökohdat otettu hyvin huomioon. Tämän ansiosta myös JavaBeans-komponenttien turvallisuus on hyvällä pohjalla. Koska JavaBeans-komponentteja ei ladata omalle koneelle, ei suurta vaaraa ole. ActiveX:n ongelmana on puolestaan juuri se, että komponentit ajetaan "omalla" koneella. Koska ActiveX-komponenteilla on laajat oikeudet esim. levy- ja keskusmuisteihin, voivat ne aiheuttaa suurta tuhoa. Lisäksi verkosta ladattavat ActiveX-komponentit jäävät koneen levymuistiin ja tarpeettomien komponenttien poisto on kokonaan käyttäjän omalla vastuulla.
Molemmissa komponenttiluokissa on luotu mahdollisuus luokitella komponentit luotettavista ja epäluotettavista lähteistä tuleviksi. ActiveX:n tapauksessa käyttäjältä kysytään, haluaako hän ladata tarjolla olevan komponentin koneelleen ja kerrotaan samalla komponentin alkuperästä. Tätä varten on kehitetty erityinen sertifikointijärjestelmä, authenticode, joka luetteloi luotettavaksi rekisteröidyt komponentit. Tämä ei kuitenkaan suojaa konettasi, vaikka luotettavaksi luokiteltu komponentti tekisikin tuhojaan. JavaBeansit puolestaan saavat oikeuksia sen mukaan ovatko ne luotettavia vai epäluotettavia. Luotettava komponentti saa samat oikeudet kuin Java-sovellus, mutta epäluotettava joutuu tyytymään tavallisen Java-appletin oikeuksiin.
Komponenttiluokkien yhteiskäyttössä ActiveX:n suuret oikeudet käyttöjärjestelmän kautta muihin sen tarjoamiin palveluihin tarjoaa sille myös mahdollisuuden eri komponenttien yhteistyöhön. JavaBeans on puolestaan riippuvainen eri komponenttiluokkien välisistä silloista. Näistä odotetuin ja kovimman kehitystyön alla on juuri JavaBeansin ja ActiveX:n välinen silta. Tämän avulla näitä komponentteja voidaan käyttää yhdessä, mutta sillan toiminnassa on vielä paljonkin toivomisen varaa.
Käyttöjärjestelmäriippumattomuudessa JavaBeans vie selkeästi voiton. Koska Java Virtual Machine on jo olemassa jo lähes jokaiselle käyttöjärjestelmälle, voidaan myös JavaBeansejä käyttää kaikissa näissä. ActiveX-komponentti on taas riippuvainen siitä käyttöjärjestelmästä, mille se on kirjoitettu. Jokaiselle ActiveX:ää tukevalle käyttöjärjestelmälle voidaan toki luoda omat versionsa, mutta jos komponentissa hyödynnetään Windows-ominaisuuksia, jää niiden hyöty puuttumaan muissa.
Mikä olisi sitten hyvä perussääntö komponenttiluokan valinnalle? Yksi esimerkkijako voisi olla seuraavanlainen. Jos sovellus sopii 100-prosenttisesti Java-maailmaan, kannattaa käyttää JavaBeansiä. Windows-maailmassa puolestaanvalinta olisi ActiveX, ja käytettävä ohjelmointikieli oman valinnan mukaan.
Toinen tapa valita komponenttiluokka on valinta käyttöympäristön mukaan. Jos sovellusta levitetään ympäri internetiä, on JavaBeans oikeastaan ainoa järkevä valinta, sillä siinä turvallisuusnäkohtiin on kiinnitetty suurta huomiota. Intranet-verkossa puolestaan ActiveX voi olla sopiva valinta, varsinkin jos kaikissa verkon koneissa on sopiva käyttöjärjestelmä.
Tulevaisuutta on yleensä vaikea ennustaa ja ATK-alalla se on aivan erityisen vaikeaa johtuen alan nopeasta kehityksestä. Sama pätee myös komponentteihin ja niiden suosioon. Tällä hetkellä Java-kielen suosion nopea kasvu viittaisi siihen, että JavaBeans-komponenttien suosio olisi samalla nousussa. Myös lähes kaikki Java-sovelluskehittimet alkavat jo sisältää JavaBeans-tuen. Tärkeä osa kehityksessä on myös Sunin ja Microsoftin Java-riitojen ratkaisulla. Jos Microsoft saadaan mukaan, alkaa Javan ja samalla JavaBeansien tilanne näyttää yhä valoisammalta.
ActiveX-komponenteilla puolestaan on vielä markkinajohtajan asema ja paljon vakiintuneita käyttäjiä. Syynä tähän on varmasti se, että ActiveX on valmis ja toimiva komponenttiluokka, päinvastoin kuin vielä osittain työn alla olevat JavaBeansit.
Tärkeä osa tulevaisuutta tulee olemaan myös eri komponenttiluokkien väliset sillat, joilla luokat pystyvät keskustelemaan ja toimimaan toistensa kanssa. Näitä on jo olemassa useita, mutta niiden toimivuudessa on vielä kehitettävää. Erityisesti sovelluskehittäjien toivomuslistalla on JavaBeansin ja ActiveX:n välisen sillan saaminen varmemmaksi.
Microsoft, "ActiveX", http://www.microsoft.com/activex, 1997.
Chappel David ja Linthicum David S., "ActiveX Demystified", http://www.byte.com/art/9709/sec5/art1.htm, 1997.
Cnet, "ActiveX.com", http://www.activex.com, 1997.
JavaSoft, "JavaBeans: The Only Component Architecture for Java", http://java.sun.com/beans, 1997.
Hansen Janne ja Harmanen Repe, "ActiveX Presentation", http://www.cs.jyu.fi/~janhanse/ActiveX/activexShow/, 16.10.1996.
DeSoto Allan, "Using the Beans Development Kit 1.0", http://java.sun.com/beans/docs/Tutorial-Nov97.pdf, 1997.
JavaShareware Group Inc., "JavaShareware.com", http://www.JavaShareware.com, 1997.
Kiuttu Petri, "Java-ohjelmointi, Pro-kurssi", Suomen ATK-kustannus, Espoo, 1997.
Dragan Richard V., "JavaBeans 1.0", http://www8.zdnet.com/pcmag/features/beans/_open.htm, 4.2.1997.
Dragan Rich, "With JavaBeans, there are components for all", http://www.zdnet.com/cshopper/content/9704/cshp0045.html, 1997.
VanderVeer Emily A., "Picking the Newest Crop of Beans", http://www.sigs.com/publications/objm/9711/vanderveer.html, 1997.
K&A Software, "What are Beans?", http://www.kasoftware.com/resources/beans.html, 1997.
Hughes Merlin, "JavaBeans and ActiveX go head to head", http://www.javaworld.com/jw-03-1997/jw-03-avb-tech.html, 15.9.1997.
Johnson Mark, "A walking tour of JavaBeans", http://www.javaworld.com/jw-08-1997/jw-08-beans.html, 14.7.1997.
Hughes Meerlin, "Building a bevy of beans", http://www.javaworld.com/jw-08-1997/jw-08-step.html, 2.9.1997.
Dragan Richard V. "JavaBeans haastaa ActiveX:n" Tietokone-lehti, 3/1997, s. 115-116.
Jääskeläinen Kari, "Lisää interaktiivisuutta - Javalla vai ActiveX:llä?", http://www.espoo.com/jutut/activex.html, 29.10.1996.
Liite 1. ActiveX-autolaskuri
<HTML>
<HEAD><TITLE>ActiveX-esimerkki</TITLE></HEAD>
<SCRIPT LANGUAGE="VBScript">
<!--
Sub ButtonHA_Click()
labelHA.caption=CStr(CInt(labelHA.caption)+1)
end sub
Sub ButtonKA_Click()
labelKA.caption=CStr(CInt(labelKA.caption)+1)
end sub
Sub ButtonNollaa_Click()
labelHA.caption="0"
labelKA.caption="0"
end sub
-->
</SCRIPT>
<BODY BGCOLOR="#00BBA9" TEXT="#000000">
<H1> Autolaskuri </H1>
<HR WIDTH=204 ALIGN=LEFT>
<BR>
<! Henkilöautojen lukumäärä ->
<OBJECT ID="LabelHA" WIDTH=100 HEIGHT=30 BORDER=1
CLASSID="CLSID:978C9E23-D4B0-11CE-BF2D-00AA003F40D0">
<PARAM NAME="BackColor" VALUE="11123456">
<PARAM NAME="Caption" VALUE="0">
<PARAM NAME="Size" VALUE="8858;635">
<PARAM NAME="BorderStyle" VALUE="1">
<PARAM NAME="BorderColor" VALUE="23456789">
<PARAM NAME="FontHeight" VALUE="240">
<PARAM NAME="FontCharSet" VALUE="0">
<PARAM NAME="FontPitchAndFamily" VALUE="2">
<PARAM NAME="ParagraphAlign" VALUE="2">
<PARAM NAME="FontWeight" VALUE="0">
</OBJECT>
<! Kuorma-autojen lukumäärä ->
<OBJECT ID="LabelKA" WIDTH=100 HEIGHT=30 BORDER=1
CLASSID="CLSID:978C9E23-D4B0-11CE-BF2D-00AA003F40D0">
<PARAM NAME="BackColor" VALUE="11123456">
<PARAM NAME="Caption" VALUE="0">
<PARAM NAME="Size" VALUE="8858;635">
<PARAM NAME="BorderStyle" VALUE="1">
<PARAM NAME="BorderColor" VALUE="23456789">
<PARAM NAME="FontHeight" VALUE="240">
<PARAM NAME="FontCharSet" VALUE="0">
<PARAM NAME="FontPitchAndFamily" VALUE="2">
<PARAM NAME="ParagraphAlign" VALUE="2">
<PARAM NAME="FontWeight" VALUE="10">
</OBJECT>
<BR><BR>
<! Nappula henkilöautojen lisäämiseen ->
<OBJECT ID="ButtonHA" WIDTH=102 HEIGHT=30
CLASSID="CLSID:D7053240-CE69-11CD-A777-00DD01143C57">
</OBJECT>
<! Nappula kuorma-autojen lisäämiseen ->
<OBJECT ID="ButtonKA" WIDTH=102 HEIGHT=30
CLASSID="CLSID:D7053240-CE69-11CD-A777-00DD01143C57">
<PARAM NAME="Caption" VALUE="Kuorma-autoja">
<PARAM NAME="Size" VALUE="2540;846">
<PARAM NAME="FontCharSet" VALUE="0">
<PARAM NAME="FontPitchAndFamily" VALUE="2">
<PARAM NAME="ParagraphAlign" VALUE="3">
<PARAM NAME="FontWeight" VALUE="0">
</OBJECT>
<BR><BR>
<! Nappula arvojen nollaukseen ->
<OBJECT ID="ButtonNollaa" WIDTH=204 HEIGHT=30
CLASSID="CLSID:D7053240-CE69-11CD-A777-00DD01143C57">
<PARAM NAME="Caption" VALUE="Nollaa">
<PARAM NAME="Size" VALUE="2540;846">
<PARAM NAME="ParagraphAlign" VALUE="3">
</OBJECT>
<BR><BR>
<HR WIDTH=204 ALIGN=LEFT>
<H5>
(C) 1997 Jarno Mynttinen
</H5>
</BODY></HTML>
Liite 2. LaskuriBean.java ja Autolaskuri.java
/*******************************************************************/
// LaskuriBean.java
//
// Jarno Mynttinen
// 4.12.1997
import java.awt.*;
import java.awt.event.*;
import borland.jbcl.layout.*;
import borland.jbcl.control.*;
import borland.jbcl.view.*;
import borland.jbcl.util.BlackBox;
public class LaskuriBean extends BeanPanel implements BlackBox{
BevelPanel PohjaLayOut = new BevelPanel();
BorderLayout borderLayout1 = new BorderLayout();
XYLayout xYLayout1 = new XYLayout();
public LaskuriBean() {
try {
jbInit();
}
catch (Exception e) {
e.printStackTrace();
}
}
public void jbInit() throws Exception{
this.setSize(new Dimension(150, 150));
arvoLabel.setBackground(SystemColor.controlHighlight);
arvoLabel.setFont(new Font("Dialog", 1, 16));
arvoLabel.setText("0");
lisaaButton.setLabel("Lisää");
lisaaButton.addActionListener(new LaskuriBean_lisaaButton_actionAdapter(this));
arvoLabel.setAlignment(Label.RIGHT);
PohjaLayOut.setLayout(xYLayout1);
this.setLayout(borderLayout1);
this.add(PohjaLayOut, BorderLayout.CENTER);
PohjaLayOut.add(arvoLabel, new XYConstraints(9, 19, 127, 47));
PohjaLayOut.add(lisaaButton, new XYConstraints(9, 84, 127, 47));
}
// Lisätään buttonLabel-ominaisuus, jolla saadaan haluttu
// teksti nappulaan
private String buttonLabel = "Lisää";
// Metodit buttonLabel-ominaisuuden säätämiseen
public void setButtonLabel(String s) {
lisaaButton.setLabel(s);
buttonLabel=s;
}
public String getButtonLabel(){
return buttonLabel;
}
// Luodaan Nollaa-metodi, jota kutsumalla arvoLabel-kentän
// arvo nollataan
public void Nollaa(){
arvoLabel.setText("0");
}
// LaskuriBean-komponentin sisältämät komponentit
LabelControl arvoLabel = new LabelControl();
ButtonControl lisaaButton = new ButtonControl();
// Määritellään mitä tehdään, kun lisaaButton-nappulaa on painettu
void lisaaButton_actionPerformed(ActionEvent e) {
arvoLabel.setText(""+(Integer.parseInt(arvoLabel.getText())+1));
}
}
class LaskuriBean_lisaaButton_actionAdapter implements java.awt.event.ActionListener {
LaskuriBean adaptee;
LaskuriBean_lisaaButton_actionAdapter(LaskuriBean adaptee) {
this.adaptee = adaptee;
}
public void actionPerformed(ActionEvent e) {
adaptee.lisaaButton_actionPerformed(e);
}
}
/*******************************************************************/
// Autolaskuri.java
//
// Jarno Mynttinen
// 4.12.1997
import java.awt.*;
import java.awt.event.*;
import java.applet.*;
import borland.jbcl.layout.*;
import borland.jbcl.control.*;
import LaskuriBeans.*;
public class AutoLaskuri extends Applet {
XYLayout xYLayout1 = new XYLayout();
boolean isStandalone = false;
LaskuriBean laskuriBeanHA = new LaskuriBean();
LaskuriBean laskuriBeanKA = new LaskuriBean();
ButtonControl nollaaButton = new ButtonControl();
public String getParameter(String key, String def) {
return isStandalone ? System.getProperty(key, def) :
(getParameter(key) != null ? getParameter(key) : def);
}
public AutoLaskuri() {
}
public void init() {
try { jbInit(); } catch (Exception e) { e.printStackTrace(); }
}
// Autolaskuri-appletin yleiset määritykset
public void jbInit() throws Exception{
xYLayout1.setWidth(330);
xYLayout1.setHeight(200);
// Kaksi kappaletta omia laskuriBean-komponentteja
laskuriBeanHA.setButtonLabel("Henkiläautoja");
laskuriBeanKA.setButtonLabel("Kuorma-autoja");
// Tavallinen Button-komponentti
nollaaButton.setLabel("Nollaa");
nollaaButton.addActionListener(new AutoLaskuri_nollaaButton_actionAdapter(this));
this.setLayout(xYLayout1);
this.add(laskuriBeanHA, new XYConstraints(12, 11, 148, 136));
this.add(laskuriBeanKA, new XYConstraints(171, 11, 148, 136));
this.add(nollaaButton, new XYConstraints(122, 157, 87, 32));
}
public String getAppletInfo() {
return "Applet Information";
}
public String[][] getParameterInfo() {
return null;
}
// Määrätään nollaaButton-nappulan painamisen aiheuttamat kutsut
public void nollaaButton_actionPerformed(ActionEvent e) {
laskuriBeanHA.Nollaa();
laskuriBeanKA.Nollaa();
}
}
class AutoLaskuri_nollaaButton_actionAdapter implements java.awt.event.ActionListener {
AutoLaskuri adaptee;
AutoLaskuri_nollaaButton_actionAdapter(AutoLaskuri adaptee) {
this.adaptee = adaptee;
}
public void actionPerformed(ActionEvent e) {
adaptee.nollaaButton_actionPerformed(e);
}
}