SlideShare a Scribd company logo

sonera_live_sisallonhallinta_diplomityo

•
•
Antti Leinonen
Antti Leinonen
1 of 121
Download to read offline
TAMPEREEN TEKNILLINEN KORKEAKOULU Tietotekniikan osasto TIMUR KÄRKI, ANTTI LEINONEN, TOMMI TARKIAINEN HAJAUTETTU SISÄLLÖNHALLINTAJÄRJESTELMÄ INTERNET-VERKOSSA Aihe hyväksytty osastoneuvoston kokouksessa 12.11.1997. Tarkastajat: professori Ilkka Haikala, Tampereen teknillinen korkeakoulu tekn.lis. Jukka Helin, Sonera Oy
ii Alkulause Diplomityössä kuvattu sisällönhallintajärjestelmä toteutettiin ohjelmistoprojektina Soneran Medialaboratoriossa. Projekti alkoi kesäkuussa 1997. Haluamme kiittää laboratorion silloista johtajaa Arto Urataipaletta sekä nykyistä johtajaa Jukka Heliniä tuesta ja luottamuksesta projektia kohtaan. Loppuvuodesta 1997 sisällönhallintajärjestelmästä päätettiin tehdä tämä diplomityö. Diplomityön syntymiseen ovat vaikuttaneet useat henkilöt. Kiitokset kaikille niille, jotka lukivat tämän diplomityön ja antoivat arvokasta palautetta. Erityisesti haluamme kiittää työmme tarkastajia, professori Ilkka Haikalaa ja tekniikan lisensiaatti Jukka Heliniä. Tampereella 24.2.1999 Timur Kärki Pajakatu 11 as 5 33100 TAMPERE puh. 040-5369677 Antti Leinonen Arkkitehdinkatu 34 D 32 33720 TAMPERE puh. 040-5369688 Tommi Tarkiainen Opiskelijankatu 4 F 336 33720 TAMPERE puh. 040-5369686
iii Tiivistelmä TAMPEREEN TEKNILLINEN KORKEAKOULU Tietotekniikan osasto, Ohjelmistotekniikka KÄRKI, TIMUR - LEINONEN, ANTTI - TARKIAINEN, TOMMI: HAJAUTETTU SISÄLLÖNHALLINTAJÄRJESTELMÄ INTERNET- VERKOSSA Diplomityö, 103 sivua, 5 liitesivua Tarkastajat: prof. Ilkka Haikala, tekn. lis. Jukka Helin Rahoittaja: Sonera Oy Maaliskuu 1999 Avainsanat: CORBA, hajautettu ohjelmisto, Internet, Java, multimedia, sisällönhallinta Soneran multimediapalvelun pilottivaihe käynnistettiin vuonna 1995. Palvelun tarkoituksena on helpottaa multimediamateriaalin jakelua Internetissä. Pilottivaiheesta saatujen kokemusten pohjalta käynnistettiin kesällä 1997 Soneran Medialaboratoriossa ohjelmistoprojekti, jonka tavoitteena oli luoda uusi järjestelmä, joka korjaisi vanhan järjestelmän ongelmat ja helpottaisi uusien palveluiden kehitystä. Projektin edetessä ohjelmisto muotoutui sisällönhallintajärjestelmäksi, joka esitellään tässä työssä. Sisällönhallintajärjestelmä on hajautettu ohjelmisto, joka koostuu sisällöntuottajan ja ylläpitäjän työkaluista sekä palvelinohjelmistosta. Ohjelmisto on toteutettu Javalla ja CORBAlla. Lisäksi järjestelmässä käytetään ulkopuolisten ohjelmatoimittajien ohjelmia, kuten RealNetworksin ja Xing Technologiesin striimaavia1 multimediapalvelimia. Sisällönhallintajärjestelmä on tällä hetkellä käytössä Tampere Media Cityssä (www.tmc.tampere.fi), joka on ensimmäinen järjestelmän avulla rakennettu sovellus. Järjestelmä otetaan käyttöön myös muissa Soneran Internet-multimediapalveluissa. 1 Engl. termille streaming ei ole olemassa vakiintunutta suomennosta. Tässä työssä käytetään koeluontoisesti suomennosta "striimaus".
iv Abstract TAMPERE UNIVERSITY OF TECHNOLOGY Department of Information Technology, Software Systems Laboratory KÄRKI, TIMUR - LEINONEN, ANTTI - TARKIAINEN, TOMMI: DISTRIBUTED CONTENT MANAGEMENT SYSTEM IN THE INTERNET Master of Science Thesis, 103 pages, 5 enclosure pages Supervisors: Prof. Ilkka Haikala and Tech. Lic. Jukka Helin Funding: Sonera Ltd March 1999 Keywords: content management, CORBA, distributed computing, Internet, Java, multimedia, streaming Sonera Ltd started a multimedia pilot service in 1995. The purpose of this pilot was to make it easier for the content providers to use streaming multimedia on the Internet. Based on the experiences of the pilot it was decided that a new system was needed to better address the needs of the content providers. In the summer of 1997 Sonera Medialab started a software project the goal of which was to create a new system that would not have the shortcomings of the old service and would enable Sonera to create new kind of multimedia services. This thesis describes the content management system which is the result of the project. The content management system is a distributed system that consists of three parts. These parts are content provider tools, administrator tools and server software. The system was developed using Java and CORBA. The system also makes extensive use of 3rd party software e.g. RealNetworks and Xing Technologies streaming media servers. The content management system is currently being used in Tampere Media City (www.tmc.tampere.fi), which is the first application built on top of this system. The content management system will also be used in other Sonera’s Internet multimedia services.
v Sisällysluettelo Alkulause .............................................................................................................................ii Tiivistelmä ..........................................................................................................................iii Abstract ..............................................................................................................................iv Sisällysluettelo.....................................................................................................................v Termejä.............................................................................................................................viii Lyhenteitä............................................................................................................................x 1 Johdanto........................................................................................................................1 2 Sonera MediaNet -tuotteet ..........................................................................................3 2.1 SISÄLTÖPALVELUT INTERNETISSÄ................................................................................3 2.2 MULTIMEDIA INTERNETISSÄ ........................................................................................5 2.3 SONERA MEDIANET -TUOTERYHMÄ.............................................................................7 3 Toisen sukupolven MediaNet....................................................................................10 3.1 YLEISKÄYTTÖINEN ALUSTA........................................................................................10 3.2 SISÄLLÖNHALLINTAJÄRJESTELMÄN LIITTYMINEN YMPÄRISTÖÖNSÄ ..........................11 3.3 TOIMINNALLISET TAVOITTEET....................................................................................12 3.3.1 Helppokäyttöisyys ...............................................................................................12 3.3.2 Materiaalin jakelu...............................................................................................14 3.3.3 Loppukäyttäjäryhmät ..........................................................................................14 3.3.4 Raportointi ja laskutus........................................................................................15 3.3.5 Tietojen säilytys...................................................................................................15 3.4 TEKNISET TAVOITTEET ...............................................................................................16 3.4.1 Ympäristöriippumattomuus.................................................................................16 3.4.2 Hajautettavuus ja skaalautuvuus ........................................................................17 3.4.3 Toimintavarmuus ja turvallisuus ........................................................................19 3.4.4 Ylläpidettävyys ja käytettävyys............................................................................21 3.4.5 Versionhallinta....................................................................................................21 4 Toteutusteknologiat ...................................................................................................23 4.1 HAJAUTUS ..................................................................................................................23 4.1.1 Remote Method Invocation .................................................................................24
Sisällysluettelo vi 4.1.2 Common Object Request Broker Architecture....................................................24 4.1.3 Distributed Component Object Model ................................................................28 4.1.4 Menetelmän valinta.............................................................................................28 4.2 OHJELMOINTIKIELI .....................................................................................................30 4.3 KÄYTTÖLIITTYMÄT ....................................................................................................31 4.3.1 Ympäristöriippumattomuuden toteutustavat.......................................................31 4.3.2 Javan käyttöliittymäkirjastot...............................................................................32 4.3.3 Yhteenveto ja kirjastojen tulevaisuus..................................................................37 4.4 MUUT VALITUT TEKNOLOGIAT ...................................................................................38 5 Sisällönhallintaydin....................................................................................................40 5.1 RAKENNE ...................................................................................................................41 5.1.1 Palvelut ...............................................................................................................42 5.1.2 Palvelu-sovelluskehys .........................................................................................47 5.1.3 Palvelin ...............................................................................................................49 5.2 TOIMINNOT.................................................................................................................51 5.2.1 Tiedostojen käsittely............................................................................................51 5.2.2 Käyttäjien hallinta ..............................................................................................53 5.2.3 Töiden hallinta....................................................................................................56 5.2.4 Live-Update.........................................................................................................63 5.2.5 Sisältöjen hallinta ...............................................................................................65 5.3 SISÄLTÖPALVELIMET..................................................................................................67 5.3.1 Sisältöpalvelimen rakenne ..................................................................................67 5.3.2 Sisältöpalvelinten hallinta ..................................................................................68 5.3.3 Yksittäisiä tiedostoja jakavat sisältöpalvelimet ..................................................69 5.3.4 Striimattavien materiaalien sisältöpalvelimet ....................................................69 5.3.5 TMC-sisältöpalvelin............................................................................................70 5.3.6 Ryhmäsisältöpalvelin ..........................................................................................71 6 Käyttöliittymät ...........................................................................................................72 6.1 ASIAKASOHJELMA......................................................................................................72 6.2 YLLÄPITO-OHJELMA...................................................................................................76 6.2.1 Rakenne...............................................................................................................76 6.2.2 Käyttöliittymä......................................................................................................78
Sisällysluettelo vii 6.2.3 ServerManagerAgent ..........................................................................................79 6.2.4 ServerConfigAgent..............................................................................................80 6.2.5 PropertyEditorAgent...........................................................................................81 6.2.6 QueueManagerAgent ..........................................................................................81 7 Sisällönhallintajärjestelmä ja Sonera MediaNet -sovellukset................................82 7.1 SISÄLLÖNHALLINTAYDIN TUOTANTOKÄYTÖSSÄ ........................................................82 7.1.1 On-Demand.........................................................................................................84 7.1.2 Live......................................................................................................................86 7.1.3 TMC ....................................................................................................................86 7.2 ASIAKASOHJELMA......................................................................................................87 7.2.1 On-Demand.........................................................................................................88 7.2.2 Live......................................................................................................................92 7.2.3 Tampere Media City............................................................................................93 8 Sisällönhallintajärjestelmän jatkokehitys................................................................97 8.1 JÄRJESTELMÄN RAKENTEEN JA PALVELUIDEN JATKOKEHITYS....................................97 8.2 MEDIANET-SOVELLUSTEN JATKOKEHITYS .................................................................99 9 Yhteenveto ................................................................................................................101 Lähdeluettelo...................................................................................................................104 Liite I - Portaalit .............................................................................................................106 Liite II - Käyttöliittymäesimerkit..................................................................................108
viii Termejä Asiakasohjelma Sisällöntuottajan työkalu, jolla käytetään sisällönhallintaytimen toimintoja. Enkooderi Laite tai ohjelma, joka muuntaa lähdemateriaalin muotoon, josta se voidaan palauttaa alkuperäisen kaltaiseksi. (engl. encoder) Erityispalvelu Sisällönhallintaytimen palvelu, joka suorittaa MediaNet- sovelluskohtaisia toimintoja. Liityntäpalvelu Liityntäpalvelut toimivat sisällönhallintaytimen rajapintana ulkopuolisiin ohjelmiin. Liityntäpalvelut ovat erityispalveluita. Loppukäyttäjä Selailee ja katselee sisältöjä loppukäyttäjäohjelman avulla. Loppukäyttäjäohjelma Sisällön katsomiseen tarkoitettu ohjelma. Tällaisia ohjelmia ovat mm. selaimet sekä erilaiset mediasoittimet. MediaNet-sovellus MediaNet-tuote, joka on toteutettu sisällönhallintajärjestelmän avulla. MediaNet-tuote MediaNet-tuoteperheen jäsen. Soneran medialaboratoriossa kehitetty palvelukonsepti. Medianimike Medianimike koostuu yhdestä tai useammasta mediatiedostosta. Mediasoitin Multimediamateriaalin toisto-ohjelma. (engl. media player) Mediatiedosto Medianimikkeeseen liittyvä yksittäinen fyysinen tiedosto. Muunnosohjelma Ohjelma, joka muuntaa materiaalin muodosta toiseen. (engl. converter) Muuntaminen Materiaalin muuntaminen muodosta toiseen. Muuntamiseen liittyy usein materiaalin pakkaaminen. (engl. convert) Palvelu Sisällönhallintaytimeen kuuluva ohjelma, joka toteuttaa TFService-rajapinnan.
Termejä ix Peruspalvelu Sisällönhallintaytimen palvelu, joka on tarkoitettu muiden sisällönhallintaytimen palveluiden käyttöön. Peruspalveluita ei voi käyttää sisällönhallintaytimen ulkopuolisista ohjelmista. Serialisointi Javan toiminto, jonka avulla olioiden sisältämät tiedot voidaan muuttaa tietovirraksi ja tietovirrasta takaisin olioksi. (engl. serialize) Sisällönhallintajärjestelmä Asiakasohjelman, ylläpito-ohjelman ja sisällönhallintaytimen muodostama kokonaisuus. Sisällönhallintaydin Sisällönhallintaydin sisältää sisällönhallintajärjestelmän palvelut, tiedonhallinnan ja sisältöpalvelimet. Sisällöntuottaja MediaNet-tuotteen asiakas, joka välittää sisällönhallintajärjestelmän avulla sisältöä loppukäyttäjälle. Sisältö Sisältöpalvelimella sijaitseva materiaali, joka on loppukäyttäjän katsottavissa. Sisältöpalvelin Sisällönhallintaytimeen liitetty palvelin, jonka tehtävänä on varastoida ja jakaa sisältöä. Sovelluskehys Osittain toteutettu järjestelmäarkkitehtuuri, johon voidaan liittää uusia toimintoja. (engl. framework) Striimata Materiaalin välittäminen tietoverkon avulla siten, että materiaalia voidaan käyttää sitä mukaa, kun se siirtyy loppukäyttäjän tietokoneelle. (engl. streaming) Ylläpito-ohjelma Ylläpito-ohjelman avulla ylläpitäjä voi hallita ja valvoa sisällönhallintaytimen toimintaa.
x Lyhenteitä ACL Access Control List AFC Application Foundation Classes API Application Programming Interface AWT Abstract Windowing Toolkit CGI Common Gateway Interface CORBA Common Object Request Broker Architecture CUG Closed User Group DCOM Distributed Component Object Model FIFO First-In-First-Out FTP File Transfer Protocol HTML HyperText Markup Language HTTP HyperText Transfer Protocol IDL Interface Definition Language IFC Internet Foundation Classes IIOP Internet Inter-ORB Protocol IOR Interoperable Object Reference IP Internet Protocol ISP Internet Service Provider JAR Java Archive JDBC Java Database Connectivity JDK Java Development Kit JFC Java Foundation Classes OMA Object Management Architecture OMG Object Management Group ORB Object Request Broker OSP Online Service Provider RMI Remote Method Invocation SMTP Simple Mail Transfer Protocol SQL Standard Query Language
Lyhenteitä xi SSL Secure Socket Layer TMC Tampere Media City URL Uniform Resource Locator WWW World Wide Web
1 1 Johdanto Loppuvuodesta 1995 Soneran Medialaboratorio aloitti MediaNet1 -kokeilun, jonka tavoitteena oli luoda multimedian jakelujärjestelmä Internetiin. Sisällöntuottajille tarjottiin ohjelmistot, joiden avulla voitiin siirtää digitoitua mediamateriaalia Soneran palvelimelle. Palvelimella materiaali muunnettiin sopivaan muotoon ja asetettiin loppukäyttäjän saataville. Kokeilua käynnistettäessä tavoitteena oli löytää uusia käyttötarkoituksia Soneran tietoverkoille ja saada tietoa multimedian levittämisen teknisistä vaatimuksista. Haluttiin myös saada tietoa siitä, kuinka sisällöntuottajat ja loppukäyttäjät suhtautuvat näihin uusiin teknologioihin. Sonera toteutti tällaisen palvelun ensimmäisenä maailmassa ja saavutti paljon mainetta. Soneraa kehuttiin nopeasta teknologioiden omaksumiskyvystä, ja MediaNet sai vuonna 1996 Data Communications International -lehden arvostetun Hot Products -palkinnon. Kokeilussa luotu palvelu kaupallistettiin keväällä 1997. Kesäkuussa 1997 todettiin, että puolitoista vuotta aikaisemmin luotu järjestelmä oli hankala ylläpitää ja laajentaa. Päätettiin tehdä järjestelmä kokonaan uudelleen, painottaen ohjelmistoteknisiä ratkaisuja. 1 MediaNet on Soneran käytössä ollut tuotenimi, jonka Helsinki Media on sittemmin rekisteröinyt itselleen. Tekstissä käytetään vanhaa MediaNet-nimeä, koska uusi tuotenimi ei ollut työtä kirjoitettaessa vielä selvillä.
1 Johdanto 2 Haluttiin saada järjestelmä, joka olisi helposti laajennettavissa ja soveltuisi monenlaisen materiaalin levittämiseen. Järjestelmän tuli myös mukautua erilaisiin ympäristöihin ja tehovaatimuksiin. Alkoi kolmen hengen ohjelmistoprojekti, jonka toteutukseen Medialaboratorio antoi varsin vapaat kädet. Työ alkoi uuden järjestelmän tarpeiden selvittämisellä ja ominaisuuksien määrittelemisellä. Tärkeä osa työtä oli selvittää eri ohjelmistotekniset toteutusvaihtoehdot. Näiden vaiheiden jälkeen syksyllä 1997 alkoi toteutus. Loppuvuodesta 1997 päätimme kirjoittaa diplomityömme tästä varsin laajaksi kasvaneesta ohjelmistoprojektista. Työn aiheena olevaa ohjelmistokokonaisuuden osaa ryhdyttiin kutsumaan sisällönhallintajärjestelmäksi. Diplomityön luvussa 2 luodaan pikainen katsaus multimedian käyttöön Internet- tietoverkossa ja esitellään lyhyesti MediaNet-tuotteita. Luvun tarkoituksena on perehdyttää lukija ympäristöön, jossa sisällönhallintajärjestelmää tullaan käyttämään. Luvussa 3 esitellään sisällönhallintajärjestelmä siihen kohdistuvien tarpeiden ja vaatimusten muodossa. Luvussa 4 käsitellään vaihtoehtoisia menetelmiä sisällönhallintajärjestelmän totettamiseksi. Tässä luvussa käydään läpi lyhyesti järjestelmän hajautuksessa käytetyt työkalut ja menetelmät. Lisäksi käsitellään järjestelmän käyttöliittymien toteutuksessa käytettyjä välineitä. Luvussa 5 esitellään toteutetun sisällönhallintajärjestelmän rakenne ja toiminnot. Rakenteen kuvauksessa esitetään toteutukseen vaikuttaneet keskeiset suunnitteluperiaatteet. Tässä luvussa esitellään myös muita teknologiaratkaisuja. Luvussa 6 esitellään järjestelmään liittyviä käyttöliittymiä. Luvussa 7 kuvataan kuinka sisällönhallintajärjestelmää hyödynnetään MediaNet-tuotteissa. Lopuksi luvussa 8 arvioidaan järjestelmän jatkokehitystarpeita ja -mahdollisuuksia.
3 2 Sonera MediaNet -tuotteet Internetin käyttäjämäärät jatkavat edelleen kasvuaan. Loka-marraskuussa vuonna 1998 540 000 suomalaista käytti Internetiä päivittäin. Vuotta aikaisemmin vastaava luku oli 313 000. Mahdollisia käyttäjiä onnistuneelle sisältöpalvelulle tulee siis koko ajan lisää. [Ta99a] 2.1 Sisältöpalvelut Internetissä Useat Internet-yhteyden tarjoajat eli ISP:t (Internet Service Provider) haluavat nykyään tarjota asiakkaalle kokonaisvaltaista palvelua. Internet-yhteyden ja sen peruspalveluiden lisäksi tarvitaan lisäarvopalveluita. Tällaisia palveluita voivat olla esimerkiksi erilaiset uutispalvelut, hakemistopalvelut, keskustelupalstat, virtuaaliset yhteisöt ja multimediapalvelut. Tarkoitus on, että käyttäjät eivät samoilisi satunnaisesti Internetissä, vaan mahdollisimman moni käyttäisi juuri tämän ISP:n tuottamia, ylläpitämiä tai valitsemia palveluita. ISP-käsitteen rinnalle on noussut OSP (Online Service Provider), joka pitää sisällään niin perinteisen ISP-toiminnan, kuin myös sisältöpalveluiden tarjoamisen. Tarjoamalla houkuttelevia palveluita ja laadukasta sisältöä saadaan palveluille käyttäjiä. Käyttäjien määrä taas innostaa mainostajia ostamaan mainospaikkoja palveluista. Näin saadaan taloudelliset edellytykset luoda yhä parempia palveluita ja ostaa yhä laadukkaampaa ja kattavampaa sisältöä.
2 Sonera MediaNet -tuotteet 4 OSP:n koostama sisältö ei välttämättä ole tarjolla ainoastaan kyseisen OSP:n kautta Internetiin yhteydessä oleville, vaan myös muille Internetin käyttäjille. Tällöin mahdollinen yleisö sisällölle on huomattavasti suurempi. Tavoitteena on, että käyttäjät aloittaisivat WWW-selailunsa juuri kyseisen OSP:n koostamista sivuista. Tällaista WWW-kokonaisuutta, josta käyttäjä aloittaa selailun ja jonne hän palaa aina uudelleen kutsutaan portaaliksi (engl. portal). Sisältö portaaliin hankitaan yleensä muualta. Tyypillisesti portaaleissa on jäsenneltynä tietoa tekstilinkeillä aihealueittain. Tällaisesta hyvä esimerkki on America Onlinen (www.aol.com) etusivu, josta löytyy kuva liitteestä I. Lisäksi tarjolla on ajankohtaista tietoa kuten uutisia, säätiedotuksia ja pörssikursseja. Portaaleissa on usein myös muita sovelluksia, kuten WWW-pohjainen sähköposti, kauppapaikka, keskustelupalstoja, ilmoitustauluja ja yhteisöjä. Sisältöpalveluiden käyttäjiltä voidaan vaatia rekisteröitymistä, jolloin käyttäjien seuranta on varsin helppoa. Näin saadaan tarkat tilastot siitä millaiset käyttäjät käyttävät mitäkin palvelua. Tämä on mainostajien kannalta mielenkiintoista tietoa, koska mainosten kohdentaminen oikeille ihmisille on täten varsin helppoa. Myös palveluita voidaan muokata asiakaskohtaisesti rekisterin perusteella. Käyttäjälle tarjotaan usein mahdollisuus muokata aloitussivua. Sivulle voidaan valita esimerkiksi pörssikursseja, tietyn kaupungin säätiedotus tai vaikka tietyn uutistoimiston uutisia. Eräs tällainen on Exciten (www.excite.com) asiakaskohtainen aloitussivu, josta on kuva liitteessä I. Tulevaisuudessa yhä useammat käyttäjät omistavat nopean Internet-yhteyden, ja niinpä multimedian välittämisen tekniset vaikeudet helpottuvat. Tammikuussa 1999 muutamat suuret yhdysvaltalaiset portaalit ilmoittivat julkaisevansa oman version nopeille yhteyksille [Ka99]. Nopeat yhteydet mahdollistavat huomattavasti monimuotoisemman sisällön tarjoamisen.
2 Sonera MediaNet -tuotteet 5 Sonera on Suomen johtava Internet-yhteyksien tarjoaja. Soneran iNET Keskuskatu (www.inet.fi) on Suomen suosituin WWW-palvelu [Ta99b]. Johtavan aseman säilyminen ei kuitenkaan ole selviö, vaan asiakkaille tarjottavia palveluja ja sisältöä on jatkuvasti parannettava. 2.2 Multimedia Internetissä Multimedian välittäminen Internetissä voidaan katsoa tietokone-, tietoliikenne- ja medialiiketoiminnan yhdistelmäksi. Multimedian välittäminen verkossa vaatii kaikkien näiden osa-alueiden yhteistyötä. Tämä yhdistelmä on mielenkiintoinen, sillä tällä uudella liiketoiminnalla on mahdollisuus olla varsin merkittävä taloudellisesti. Tätä asiaa on havainnollistettu kuvassa 2-1. [He98] Multimedian välittäminen Internetissä on hankalaa, sillä multimediaa sisältävät tiedostot ovat isoja. Tämä aiheuttaa muutamia teknisiä vaatimuksia. Multimediamateriaali tulee muuntaa sellaiseen muotoon, että se pystytään välittämään käytössä olevan verkkokapasiteetin puitteissa parhaalla mahdollisella laadulla. Loppukäyttäjällä on Kuva 2-1 Tietoliikennetoiminnan siirtyminen kohden multimediaa luo liiketoiminnalle lisäarvoa [He98]. Tietokone 13 miljardia mk 1996 Media 16 miljardia mk 1996 Multimedia Tietoliikenne 10 miljardia mk 1996
2 Sonera MediaNet -tuotteet 6 mahdollisesti käytössään hidas modeemiyhteys tai hänellä voi olla käytössään nopea lähiverkko. Samaa sisältöä pitäisi pystyä katsomaan yhteyden nopeudesta riippumatta. Tähän kehitetään jatkuvasti uusia pakkausmenetelmiä, joiden oikea valinta vaatii asiantuntemusta. Multimediamateriaalin tulee myös sijaita sellaisella palvelimella, jonka resurssit kykenevät palvelemaan lukuisia yhtäaikaisia käyttäjiä. Samoin palvelimen tulisi olla ympäri vuorokauden käytettävissä. Multimediamateriaali vaatii myös paljon tallennuskapasiteettia. Multimediaa välitetään Internetissä kahdella toisistaan selvästi poikkeavalla tavalla. Perinteinen tapa on siirtää multimediaa sisältävä tiedosto kokonaisuudessaan ensin palvelimelta loppukäyttäjän tietokoneen kovalevylle. Tämän jälkeen tiedosto voidaan soittaa mediasoittimella. Toinen tapa on käyttää striimaavaa tekniikkaa. Tämä tarkoittaa sitä, että multimediamateriaali soitetaan mediasoittimella sitä mukaa kun se siirtyy palvelimelta. Striimauksesta on se hyöty, että soittaminen voidaan aloittaa välittömästi loppukäyttäjän esitettyä pyynnön palvelimelle. Haittapuolena on se, että varsinkin modeemiyhteyksillä multimediamateriaalin toiston taso laskee melko alhaiseksi, koska toistossa voidaan käyttää vain yhteyden sallimia bittinopeuksia. Ei-striimaavaa teknologiaa käytettäessä soiton alkamiseen tulee viive materiaalin siirtyessä kovalevylle. Tätä teknologiaa kannattaa kuitenkin käyttää, mikäli laatu on ehdottoman tärkeää, tai tilanteessa, jossa käyttäjällä on nopea, mutta aikaperusteisesti laskutettu yhteys. Multimediamateriaalista syntyy kopio loppukäyttäjän kovalevylle. Niinpä käyttäjä voi halutessaan katsella ja kuunnella materiaalia useaan kertaan. Ei- striimaavaa teknologiaa käytettäessä tekijänoikeuskysymykset ovat hankalampia kuin striimauksessa.
2 Sonera MediaNet -tuotteet 7 2.3 Sonera MediaNet -tuoteryhmä Sonera MediaNet -tuoteryhmän tuotteet on suunnattu sisällöntuottajille. Ne mahdollistavat multimediasisällön hallinnan, muokkaamisen, jakelun ja käyttötilastoinnin Internetissä. Sisällöntuottajat voivat tarjota sekä tallenteita että reaaliaikaisia tapahtumia. Mahdollisia loppukäyttäjiä ovat kaikki Internetin käyttäjät. Tuotteita tällä hetkellä ovat Sonera MediaNet On-Demand ja Sonera MediaNet Live. Pilottivaiheessa ovat Tampere Media City, Sonera MediaNet Community ja Sonera Voice Hotel. Sonera MediaNet On-Demand Sonera MediaNet On-Demand helpottaa multimediatallenteiden levittämistä tietoverkossa. Kuvassa 2-2 on esitetty sisällöntuottajan ja loppukäyttäjän roolit palvelussa. Sisällöntuottaja toimittaa materiaalin Soneran mediatuotantoon joko analogisessa muodossa tai valmiiksi digitoituna verkon välityksellä suoraan MediaNet-järjestelmään. MediaNet-palvelimella lähdemateriaali muunnetaan sopivaan muotoon ja siirretään sisältöpalvelimelle, josta loppukäyttäjä katsoo sitä loppukäyttäjäohjelman avulla. MediaNet-järjestelmä tarjoaa sisällöntuottajalle työkalut materiaalin siirtämiseen järjestelmään ja jo järjestelmässä olevan materiaalin seurantaan ja hallintaan. Sisällöntuottajan näkökulmasta digitoitu lähdemateriaali muuntuu MediaNet- järjestelmässä muutamaksi URL-osoitteeksi, joista materiaali on katsottavissa. Tämän jälkeen sisällöntuottaja voi sisällyttää linkin omille HTML-sivuillensa. Loppukäyttäjä ei välttämättä havaitse ollenkaan, että materiaali tuleekin MediaNet-sisältöpalvelimelta. Tätä ominaisuutta kutsutaan palvelun läpinäkyvyydeksi. Sisällöntuottaja saa myös käyttöönsä tilastoja katsotusta materiaalista. On-Demand -palvelun hyöty sisällöntuottajalle on se, että sisällöntuottajan ei itse tarvitse hankkia ohjelmistoja, joilla materiaali muunnetaan sopivaan muotoon. Sisällöntuottajalla ei tarvitse olla myöskään tietämystä siitä, mihin muotoon materiaali kannattaa muuntaa.
2 Sonera MediaNet -tuotteet 8 Valmis materiaali sijaitsee suorituskykyisellä palvelimella, jolta on riittävä tietoliikenneyhteys Internetiin. Näin mediamateriaali siirtyy loppukäyttäjälle mahdollisimman nopeasti kaikkina vuorokaudenaikoina. Sonera MediaNet Live Sonera MediaNet Live -palvelun avulla voidaan audio- ja videomateriaalia toimittaa reaaliaikaisesti Internetiin. Sovelluskohteet jakautuvat kahteen luokkaan, jatkuvat lähetykset sekä tapahtumat. Jatkuvat lähetykset soveltuvat esimerkiksi radio- ja TV- kanaville. Tapahtuma voi taas olla vaikkapa konsertti tai lehdistötilaisuus. Sisällöntuottaja saa URL-osoitteen, josta lähetystä voi seurata. Loppukäyttäjän kannalta Live-lähetyksen seuraaminen on täysin samanlaista kuin On-Demand -sisällön katsominen. Tampere Media City ja MediaNet Community Tampere Media City (TMC) on digitaalinen yhteisö, joka esittelee Pirkanmaan alueen digitaalisen median osaajia Internetissä. Yhteisön jäsenet luovat palveluun kuuluvalla asiakasohjelmalla itselleen WWW-sivuston. Luoduista sivustoista muodostuu yhtenäinen Kuva 2-2 On-Demand -tuote yksinkertaistettuna. Sisällöntuottaja - Yritys -Yhteisö - Yksityinen henkilö Loppukäyttäjä - Internetin käyttäjä Käyttäjäpalaute Pyyntö MediaNet- palvelimet Käyttötilastot Hyperlinkit Käsittelemätön sisältö Käsitelty sisältö
2 Sonera MediaNet -tuotteet 9 kokonaisuus, joka löytyy yhdestä osoitteesta. Näin yrityksillä ja oppilaitoksilla on mahdollisuus markkinoida tuotteitaan ja osaamistaan. TMC:n tarkoitus on luoda kaupallisia yhteyksiä myös ulkomaisten sidosryhmien ja pirkanmaalaisten digitaalista mediaa tuottavien yritysten sekä yhteisöjen välille. Teknisessä toteutuksessa on yritetty saada järjestelmä mahdollisimman helppokäyttöiseksi. Asiakasohjelmalla luodaan rakenteinen dokumentti, johon valitaan erikseen jokin taittomalleista. Näin siis sivuston asiasisältö ja ulkoasu on erotettu toisistaan. Sivustot voivat sisältää tekstiä, kuvaa, ääntä ja videota. TMC on rakennettu sisällönhallintajärjestelmän päälle. TMC-palvelun koordinaattori on Tampereen seudun osaamiskeskus ja tekninen toteuttaja Sonera Oy. Osa toteutuksesta teetettiin alihankintana Mediayhtiö Sansibar Oy:ssä. Tampere Media Cityä luotaessa syntyi myös runko yleiselle digitaalisen yhteisön palvelukonseptille, jota kutsutaan MediaNet Communityksi. Ideana on tehdä tuote, jonka avulla uuden digitaalisen yhteisön perustaminen olisi mahdollisimman helppoa. MediaNet Communityn toiminta on esitetty kuvassa 2-3. Kuva 2-3 Community-tuote yksinkertaistettuna. Sisällöntuottaja - Yhteisön jäsen Loppukäyttäjä - Internetin käyttäjä Käyttäjäpalaute Pyyntö MediaNet- palvelimet Käyttötilastot - Teksti - Kuvat - Audio - Video Generoidut WWW-sivut
10 3 Toisen sukupolven MediaNet Ensimmäinen MediaNet-toteutus syntyi vähitellen tutkimustyön ja pilottivaiheen kautta kaupalliseksi tuotteeksi. Ohjelmakokonaisuus koostui monista eri aikoina tehdyistä ohjelman osista. Syntymistavasta johtuen ohjelmiston ylläpidettävyys ja laajennettavuus olivat huonoja. Järjestelmä oli myös liian sidottu tietyntyyppisen multimediamateriaalin käsittelyyn. Laitteistojen ja ulkopuolisten ohjelmistojen kehittyessä oli tullut mahdolliseksi käsitellä monimuotoisempia materiaalikokonaisuuksia, mitä mahdollisuutta haluttiin hyödyntää. Sisällöistä ei myöskään ollut olemassa keskitettyä tietokantaa, vaan jokaisen medianimikkeen ominaisuuksia ja sisältöä kuvaavat lisätiedot olivat omassa ASCII-tiedostossaan. Tämä tiedosto sijaitsi järjestelmän WWW-palvelimella. Edellä mainittujen puutteellisuuksien ja tarpeiden seurauksena alettiin suunnitella toisen sukupolven MediaNet-järjestelmää. 3.1 Yleiskäyttöinen alusta MediaNet-tuoteperheen tuotteet liittyvät siis yleensä tavalla tai toisella multimedian jakeluun Internetissä. Niinpä oleellinen osa niitä on mediamateriaalia hoitava järjestelmä. Toisen sukupolven MediaNetin toteutus päätettiinkin aloittaa järjestelmästä, joka huolehtii mediamateriaalin hallinnasta. Toteutettava järjestelmä nimettiin sisällönhallintajärjestelmäksi. Jo projektin alkuvaiheessa oli nähtävissä, että sisällönhallinnan tarpeet tulevat kasvamaan ajan kuluessa. Uusia ideoita, vaatimuksia ja toiveita tuli esiin tasaisin väliajoin. Tästä syystä erääksi keskeisistä tavoitteista nousi modulaarisuus. Ideana oli pyrkiä erottamaan
3 Toisen sukupolven MediaNet 11 yleisesti sisällönhallintaan liittyvät tarpeet ja toisaalta haluttavat tuotteet toisistaan. Näin uudet tuotteet voidaan tulevaisuudessa rakentaa olemassa olevan perustan päälle. Perustaan tulevaisuudessa mahdollisesti vaadittavat muutokset yritettiin pitää mahdollisimman vähäisinä. Myös syntyvät tuotteet pyrittiin rakentamaan niin, että niitä voidaan tarvittaessa käyttää perustana korkeammille tasoille. Tässä vaiheessa päädyttiin kuvan 3-1 mukaiseen järjestelyyn. Siinä on esitetty tuotteiden ja sisällönhallintajärjestelmän suhde. Alimmalla tasolla on itse sisällönhallintajärjestelmä, joka toteutetaan siten, että se voidaan jakaa selkeisiin osiin. Näitä osia sopivasti yhdistelemällä voidaan rakentaa erilaisia sovelluksia. Kuvassa 3-1 näkyvät tällä hetkellä sisällönhallintajärjestelmän avulla toteutetut tuotteet. Näistä MediaNet On-Demand, Live ja Community on toteutettu suoraan sisällönhallintajärjestelmän päälle. Sen sijaan TMC noudattaa edellä mainittua tuotteen päälle rakennettua tuotetta eli se siis pohjautuu MediaNet Communityyn. 3.2 Sisällönhallintajärjestelmän liittyminen ympäristöönsä MediaNetin välityksellä tapahtuvassa multimedian jakelussa on osallisena kolme osapuolta, sisällöntuottaja, ylläpitäjä ja loppukäyttäjä (kuva 3-2). Sisällönhallintajärjestelmä tarjoaa sisällöntuottajalle työkalun, jolla hän voi hallita omia Kuva 3-1 Tuotteiden liittyminen sisällönhallintajärjestelmään. Community On-Demand Live ... TMC Sisällönhallintajärjestelmä ...
3 Toisen sukupolven MediaNet 12 sisältöjään. Samoin ylläpitäjällä on ohjelma, jolla järjestelmää valvotaan ja hallitaan. Loppukäyttäjä käyttää sisällönhallintajärjestelmää aina jonkin loppukäyttäjäohjelman kautta. Nämä ohjelmat ovat yleensä kolmansien osapuolien valmistamia. Tällaisia voivat olla esimerkiksi selaimet tai erilliset mediasoittimet. 3.3 Toiminnalliset tavoitteet MediaNet-tuotteiden yksi päätavoitteista on madaltaa kynnystä liittää multimediamateriaalia erilaisiin verkkoon tuotettaviin kokonaisuuksiin. Tarkoituksena on luoda kokonaisvaltainen ratkaisu, jossa sisällöntuottajan huoleksi jää yksinkertaisimmillaan ainoastaan materiaalin siirtäminen sisällönhallintajärjestelmään sekä sisällönhallintajärjestelmän käsittelemän materiaalin käyttäminen osana omia kokonaisuuksiaan. 3.3.1 Helppokäyttöisyys Sisällöntuottajan tulee voida mahdollisimman helposti siirtää materiaaliansa sisällönhallintajärjestelmän käsiteltäväksi. Halutessaan tietyn materiaalin katseltavaksi Internetiin sisällöntuottaja toimittaa sen aluksi digitaalisessa muodossa Kuva 3-2 Sisällönhallintajärjestelmän liittyminen ympäristöönsä. LoppukäyttäjäSisällöntuottaja Ylläpitäjä Loppukäyttäjä- ohjelma Sisällönhallintajärjestelmä
3 Toisen sukupolven MediaNet 13 sisällönhallintajärjestelmään. Tämän jälkeen tapahtuvasta materiaalin käsittelystä sisällöntuottajan ei välttämättä tarvitse välittää, mutta kuitenkin pyritään siihen, että käsittelyn kulkua voidaan haluttaessa myös seurata. Käsittelyn jälkeen sisällöntuottajalle lähetetään sähköpostin välityksellä tieto siitä, että materiaali on valmista verkossa jaettavaksi sekä ne URL-osoitteet, joista materiaali on katseltavissa. Näitä URL-osoitteita sisällöntuottaja voi sitten käyttää osana omia kokonaisuuksiaan. Uuden materiaalin siirtämistä ja järjestelmään jo siirretyn materiaalin käsittelemistä varten sisällöntuottajalle luodaan erillinen asiakasohjelma. Järjestelmää käyttävät hyvin erilaiset sisällöntuottajat, joiden tarpeissa on suuria eroavaisuuksia. Tämän lisäksi eri sisällöntuottajat ovat mahdollisesti myös eri sovellusten käyttäjiä. Asiakasohjelman tulee pystyä tarjoamaan erilaisille sisällöntuottajaryhmille erikseen valitut toiminnot ja käyttömahdollisuudet. Asiakasohjelma pyritään toteuttamaan siten, että kaikille sisällöntuottajille voidaan jakaa tämä sama ohjelma, joka sitten mukautetaan käyttäjätietojen avulla halutun kaltaiseksi. Sisällöntuottajalle näytetään vain ne ominaisuudet, joiden käytöstä on sovittu. Näin voidaan esimerkiksi antaa sisällöntuottajalle mahdollisuus ostaa asiakasohjelmaan uusia lisäominaisuuksia vain kulloisenkin tarpeen mukaisesti. Asetukset haetaan palvelimelta järjestelmään sisäänkirjoittautumisen yhteydessä. Näin myös mahdollistetaan erilaisten toimintojen ja ominaisuuksien dynaaminen lisääminen sisällöntuottajan asiakasohjelmaan. Käytännössä tämän kaltaista käyttäjään perustuvaa dynaamista asiakasohjelman muokkausta ei kuitenkaan aluksi suunnitella erityisen yksityiskohtaisesti, vaan siihen ainoastaan varataan mahdollisuus mikäli käyttökokemukset osoittavat sen tarpeelliseksi. Asiakasohjelman mukautuvuuden avulla pyritään myös siihen, että eri MediaNet- sovellukset voivat käyttää samaa ohjelmaa. Esimerkiksi On-Demand- ja TMC- sisällöntuottajille voidaan jakaa samaa asiakasohjelmaa, jonka toiminnot mukautetaan kulloinkin käytettävän sovelluksen mukaisiksi.
3 Toisen sukupolven MediaNet 14 3.3.2 Materiaalin jakelu Järjestelmän tehtävänä on hoitaa materiaalin muuntaminen Internetissä helposti levitettävissä olevaan muotoon, kulloinkin käytössä olevan tietoliikenneyhteyden mukaan skaalautuvaksi. Käytännössä tämä tarkoittaa sitä, että materiaalista tehdään valmiiksi tietyille kiinteille nopeuksille sovitettuja versioita, joista voidaan valita sopivin. Käsiteltyään tiedostoja sisällönhallintajärjestelmä siirtää mediamateriaalin palvelimille odottamaan loppukäyttäjää. Järjestelmä tarjoaa myös säilytystilan materiaalille ja loppukäyttäjän ohjelmille rajapinnan, jonka avulla tätä materiaalia voidaan katsella. Sisältöpalvelimet voidaan helposti sijoittaa riittävän nopeiden verkkoyhteyksien taakse, mikä ei yleensä ole yksittäiselle sisällöntuottajalle taloudellisesti kannattavaa. Koska sisällöntuottajan materiaalin toimitus sisällönhallintajärjestelmään on kertaluontoinen toimenpide, sisällöntuottajalle riittävät suhteellisen hitaat yhteydet. Tämä säästää kustannuksia. 3.3.3 Loppukäyttäjäryhmät Materiaalille tulee voida määrittää myös erilaisia katselurajoituksia. Näiden avulla voidaan määrittää erillisiä ryhmiä, joilla on katseluoikeus materiaaliin. Nämä rajoitukset palvelevat useita erillisiä tarkoituksia. Rajoitusten avulla voidaan toteuttaa myös maksullinen materiaali. Haluttuun materiaaliin voidaan antaa katseluoikeus ainoastaan maksaville loppukäyttäjille. Katselurajoitusten valvomisesta vastaavat materiaalin jakelujärjestelmät eli käytännössä sisältöpalvelimet. Katselurajoitusten ansiosta yritykset voivat käyttää sisällönhallintajärjestelmää yrityksen sisäisen tai muutoin salaisen materiaalin säilyttämiseen. Materiaalille voidaan antaa käyttöoikeus ainoastaan kyseisen yrityksen työntekijöille. Tästä on se etu, että samaa fyysistä sisällönhallintajärjestelmää voidaan käyttää sekä yleisessä jakelussa olevan materiaalin jakeluun että täydentämään yritysten intranet-ratkaisuja. Näin fyysistä sisällönhallintajärjestelmää ei tarvitse asentaa yritysten omiin tiloihin. Katselurajoitusten avulla voidaan toteuttaa myös suljetut käyttäjäryhmät.
3 Toisen sukupolven MediaNet 15 3.3.4 Raportointi ja laskutus Raportointi on tärkeä osa verkossa tapahtuvaa multimedian jakelua. Sisällöntuottajat haluavat luonnollisesti palautetta siitä, kuinka paljon mitäkin heidän materiaaleistaan on katseltu. Tämän tiedon avulla he voivat kehittää omia sisältöjään kiinnostavammiksi loppukäyttäjille. Laskutusmahdollisuus kuuluu oleellisena osana multimediamateriaalin välittämiseen Internetissä. Laskutus jakautuu kahteen eri osa-alueeseen eli loppukäyttäjän ja sisällöntuottajan laskuttamiseen. Sisällöntuottajia pitää tarvittaessa voida laskuttaa heidän käyttämästään kapasiteetista, joten järjestelmästä tulee saada tietoa jokaisen sisällöntuottajan sisällön määrästä sisällönhallintajärjestelmässä. Edellisen lisäksi sisällöntuottajille tulee mahdollistaa heidän asiakkaidensa eli loppukäyttäjien laskutus. Sisällönhallintajärjestelmän avulla pitää siis voida asettaa materiaalille hintaparametreja. Hinnoittelumahdollisuudesta puolestaan seuraa se, että järjestelmän tulee mahdollistaa loppukäyttäjien sisällön katselumahdollisuuden rajaaminen, jolloin ainoastaan maksavat asiakkaat saavat oikeuden tietyn materiaalin katsomiseen. 3.3.5 Tietojen säilytys Varsinaista sisältöä säilytetään ainoastaan sitä jakelevilla palvelimilla eli sen säilytys on hajautettu eri puolille sisällönhallintajärjestelmää. Kaikki muu tieto pyritään säilyttämään keskitetysti yhdessä tai useammassa tietokannassa. Järjestelmän tietokantoja voivat tarvittaessa käyttää myös sellaiset MediaNet-tuotteet, joiden ei itse tarvitse käsitellä varsinaisia mediatiedostoja. Tämä on otettava huomioon tietokannan rakennetta suunniteltaessa. Esimerkiksi asiakastietokannasta voidaan etsiä tietoa asiakkaista ilman, että ollaan kiinnostuneita kyseisen asiakkaan mediatiedostoista. Tietokannan avulla huolehditaan myös sisällöntuottajien tunnistamisesta, todentamisesta ja käyttäjäkohtaisten tietojen hallinnasta.
3 Toisen sukupolven MediaNet 16 3.4 Tekniset tavoitteet Keskeisimpänä teknisenä tavoitteena uudelle järjestelmälle on yhtenäisen ohjelmiston aikaansaaminen. Järjestelmä toteutetaan ohjelmistoprojektina, jonka tarkoituksena on tuottaa dokumentoitu ja helposti ylläpidettävä kokonaisuus. Keskeisenä tavoitteena on myös tietokantaan perustuva keskitetty tiedonhallinta. 3.4.1 Ympäristöriippumattomuus Sisällönhallintajärjestelmän tulee toimia mahdollisimman monissa erityyppisissä ympäristöissä. Tämä tarkoittaa sitä, että järjestelmän eri osien suunnittelussa ei nojauduta minkään laite- tai käyttöjärjestelmäympäristön omiin erityispiirteisiin. Edellä mainitusta joudutaan kuitenkin poikkeamaan joidenkin järjestelmän apuna käytettävien kolmansien osapuolten valmistamien ohjelmistojen ja ohjelmakirjastojen osalta. Näitä ei luonnollisesti aina ole saatavissa kaikkiin haluttuihin ympäristöihin. Erityisesti erilaisten tiedostoformaattien välisten muunnosten kohdalla joudutaan tukeutumaan ulkopuolisiin tuotteisiin. Varsinaisessa toteutuksessa eri järjestelmien erityispiirteitä pyritään toki mahdollisuuksien rajoissa ottamaan huomioon. Näin voidaan helpottaa toteutusta ja parantaa suorituskykyä. Järjestelmän sisältämien palvelimien osalta pyritään käytännössä ottamaan huomioon Windows NT-, Linux- ja Solaris-käyttöjärjestelmien piirteitä. Teoriassa jokainen yksittäinen sisällönhallintajärjestelmän osa voi sijaita eri laite- ja käyttöjärjestelmäympäristössä. Ympäristöriippumattomuudesta seuraa useita etuja. Kun sisällönhallintajärjestelmästä asennetaan uusi kopio, voidaan tarvittaessa hyödyntää jo olemassa olevaa laite- ja käyttöjärjestelmäympäristöä. Tämä tietysti vaatii, että tietyt tehokkuuskriteerit saavutetaan. Järjestelmä voidaan siirtää uusille tehokkaammille tai halvemmille laitealustoille näiden ilmestyessä markkinoille. Selkeä ympäristöriippumattomuudella saavutettu etu on myös mahdollisuus tarvittaessa hyödyntää monia hyvin erilaisia kolmansien osapuolten toimittamia ohjelmia ja ohjelmakirjastoja järjestelmän apuna. Tavoitteena on tukea mahdollisimman monia
3 Toisen sukupolven MediaNet 17 tiedostoformaatteja. Ideaalisessa tilanteessa sisällöntuottajan ei tarvitse lainkaan ajatella, minkä tyyppistä materiaalia hän sisällönhallintajärjestelmään syöttää, vaan kaikki osataan muuntaa haluttuihin kohdeformaatteihin. Uusien tiedostoformaattien ilmestyttyä niitä voidaan alkaa tukea välittömästi ensimmäisten kaupallisten muunnosohjelmien ilmestyttyä markkinoille riippumatta siitä, mille alustoille muunnosohjelmat ensimmäisenä julkaistaan. Samoin uusia ja tehokkaampia muunnosohjelmia voidaan ottaa tarvittaessa heti käyttöön osaksi järjestelmää. Olemassa oleva laitekanta voidaan myös näin haluttaessa lähes kokonaisuudessaan hyödyntää, mikäli tehokkuuskriteerit sen sallivat. 3.4.2 Hajautettavuus ja skaalautuvuus Sisällönhallintajärjestelmän suunnittelun eräänä peruslähtökohtana on voimakas hajautettavuus. Järjestelmä pyritään suunnittelemaan siten, että se koostuu useista erillisistä osasista, joista jokainen hoitaa ainoastaan yhtä juuri sille ominaista tehtävää. Järjestelmän jaossa tulee kuitenkin huomioida se, ettei näiden osien välisen keskinäisen kommunikaation tuottaman ylimääräisen verkkoliikenteen osuus kasva kohtuuttomaksi suoritusrasitteeksi. Järjestelmä on tarvittaessa voitava hajauttaa maailmanlaajuiseksi. Sisällöntuottajalla pitää olla mahdollisuus siirtää materiaaliaan samanaikaisesti eri maissa sijaitseville sisältöpalvelimille. Järjestelmän pienintä yksikköä kutsutaan palveluksi. Jokaisen palvelun tulee voida sijaita omalla tietokoneella. Eri koneilla sijaitsevien palveluiden on kyettävä vaihtamaan tietoa toistensa kanssa ainakin IP-protokollan välityksellä. Tämän lisäksi voidaan tehokkuuden parantamiseksi käyttää myös muita mahdollisia tiedonvälitysmenetelmiä, kuten esimerkiksi jaettuja levyjä. Sisällönhallintajärjestelmä sopii luonteeltaan hyvin hajautettavaksi. Järjestelmä suorittaa ylemmällä tasolla useita toisiinsa nähden rinnakkaisia toimintaketjuja. Esimerkkinä voidaan mainita tilanne, jossa moni eri sisällöntuottaja siirtää samanaikaisesti tiedostojaan sisällönhallintajärjestelmään käsiteltäväksi ja siirrettäväksi sisältöpalvelimille. Eri
3 Toisen sukupolven MediaNet 18 sisällöntuottajilta tulevat tiedostojen siirrot ja muunnokset eivät riipu toisistaan mitenkään. Tarkasteltaessa yhtä yksittäistä siirtoprosessia voidaan havaita, että sekin jakautuu selkeisiin osiin. Tällaisen ketjun voi muodostaa vaikka siirto sisällönhallintajärjestelmän tiedostopuskuriin odottamaan toimenpiteitä, toimenpideketjun muodostaminen, muunnos ja siirto sisältöpalvelimelle. Nämä osat tulee luonnollisesti suorittaa ajallisesti oikeassa järjestyksessä, mutta osien suoritusajankohdalla ei itsessään ole merkitystä. Järjestelmä voidaan siis rakentaa siten, että tapahtumat seuraavat toisiaan selkeinä osina. Jokaisen toteutuneen osan jälkeen tutkitaan, mitä seuraavaksi tulee tehdä ja etsitään tämän toiminnan toteuttava palvelu. Mikäli sopivaa palvelua ei ole vapaana, voidaan jäädä odottamaan sellaisen vapautumista. Sisällönhallintajärjestelmän ei tarvitse tässä vaiheessa toteuttaa mitään erikoista täydellisen reiluuden takaavaa jonotusmenetelmää. Järjestelmä luottaa siihen, että pyynnöt tulevat toisiinsa nähden siinä määrin satunnaisesti, että jokainen pyytäjä saa jossain vaiheessa vuoron. Järjestelmän ylläpitäjälle jätetään vastuu siitä, että järjestelmässä on toisiinsa nähden sopiva määrä eri tyyppisiä palveluita, jotta suuresti hidastavia osia ei pääse syntymään. Teoriassa olisi mahdollista tehdä järjestelmä myös siten, että jos yksikään järjestelmän palveluista ei pysty toteuttamaan haluttua palvelua, jäädään odottamaan tällaisen ilmestymistä. Asiasta voitaisiin periaatteessa myös ilmoittaa samalla järjestelmän ylläpitäjälle. Esimerkkinä voidaan mainita tiedoston muuntaminen muotoon, jota yksikään järjestelmän palveluista ei tunne. Tämän kaltaisia ominaisuuksia ei kuitenkaan toteuteta ainakaan järjestelmän tähän versioon. Sisällönhallintajärjestelmän hajautettavuudella pyritään osaltaan parantamaan järjestelmän skaalautuvuutta. Kuten jo aiemmin on tullut ilmi, voidaan järjestelmän suorituskykyä parantaa kasvattamalla laitteiston tehoa. Suorituskykyä voidaan kasvattaa myös hajautettavuutta hyväksikäyttäen. Olemassa olevien palveluiden rinnalle käynnistetään uusia palveluita suorittamaan samoja tehtäviä. Tästä on etuna myös se, ettei järjestelmää tarvitse ajaa alas päivitystä varten, vaan päivitys voidaan suorittaa järjestelmän toimiessa muilta osin normaalisti. Lisättäessä uusia palveluita on kuitenkin aina muistettava pitää
3 Toisen sukupolven MediaNet 19 järjestelmän tarjoamien palveluiden suhteet järkevinä toisiinsa nähden, jotta voidaan välttää eri palveluiden ruuhkaantumista. Hajauttaminen pyritään toteuttamaan myös siten, että järjestelmään saadaan mahdollisimman selkeät ja laajat rajapinnat erilaisiin kolmansien osapuolien toimittamiin muunnos- ja palvelinohjelmistoihin. Tavoitteena on, että järjestelmä pystyy tarvittaessa hyödyntämään kaikkia olemassa olevia komentorivipohjaisia muunnosohjelmia. 3.4.3 Toimintavarmuus ja turvallisuus Sisällönhallintajärjestelmä ei ole niin kriittinen ohjelmisto, että sille pitäisi määritellä kiinteä suurin sallittu käyttökatkosaika tai muu tarkka toimintavarmuusehto. Sisällönhallintajärjestelmän hetkellisestä toimimattomuudesta johtuvat menetykset ovat lähinnä taloudellisia. Tämä on kuitenkin luonnollisesti riittävä syy pyrkiä mahdollisimman lyhyisiin käyttökatkosaikoihin. Pääsääntöisesti pyritään siihen, että järjestelmä yrittää toipua virheistä itse. Järjestelmä pyritään toteuttamaan siten, ettei yksikään yksittäinen palvelu itsessään ole korvaamaton. Tämä on mahdollista käynnistämällä samoja toimintoja varten useita erillisiä palveluita. Tällöin saavutetaan tilanne, jossa yhden yksittäisen palvelun ajautuminen toimintakyvyttömään tilaan ei lamauta koko järjestelmää, vaan sille löytyy aina jokin toimintakuntoinen korvaava palvelu. Yksittäisen palvelun ei yleensä tarvitse pystyä toipumaan virhetilanteista. Toipumisasioita on toki syytä harkita vielä palvelukohtaisestikin. Sisältöpalvelimet muodostavat toimintavarmuuden osalta oman erityisryhmänsä, koska ne näkyvät loppukäyttäjille. Varmatoimiset sisältöpalvelimet ovat tärkeä edellytys sisällöntuottajien saamiseksi järjestelmän piiriin. Tähän voidaan vaikuttaa lähinnä arvioimalla erilaisia saatavilla olevia palvelimia ja valitsemalla saatujen tulosten perusteella käyttöön otettavat.
3 Toisen sukupolven MediaNet 20 Sisällönhallintajärjestelmään ei toteuteta erillisiä varmuuskopiointimekanismeja. Tarvittaessa varmuuskopiointi hoidetaan ulkoisia järjestelmiä hyväksikäyttäen. Järjestelmä suunnitellaan siten, että ulkoinen varmuuskopiointi on mahdollista. Minimivaatimuksena tulee kyetä varmuuskopioimaan sisältöpalvelinten sisältö ja tietokanta. Sisällönhallintajärjestelmän toteutuksessa pitää ottaa huomioon useita erilaisia ja eritasoisia turvallisuusseikkoja. Sisällöntuottajille tulee voida antaa riittävät takeet siitä, että asiattomat tahot eivät pääse tutkimaan järjestelmän sisältämää materiaalia. Tämä on erityisen tärkeää silloin, kun järjestelmää käytetään yrityksen sisäisen materiaalin säilyttämiseen. Myös maksullista aineistoa voidaan yrittää käyttää ilmaiseksi. Joidenkin sisältötyyppien osalta on myös määritelty, että niitä voi katsella vain striimattuina eli suoraan reaaliajassa verkosta. Loppukäyttäjällä ei ole oikeutta tallentaa näitä tiedostoja omalle kovalevylleen. Ehkä todennäköisin kohta, josta mahdollisia murtautumisyrityksiä järjestelmään tullaan tekemään, ovat erilaiset sisältöpalvelimet. Näille palvelimille on luonnollisesti oltava yhteys Internetistä, joten niitä vastaan on erityisen helppo tehdä hyökkäyksiä. Erityisesti loppukäyttäjäohjelmille näkyvät rajapinnat on toteutettava huolellisesti. Nämä rajapinnat muodostuvat suurimmaksi osaksi kolmansilta osapuolilta tulevista ohjelmistoista, joten sisältöpalvelimien toteutusvaiheessa potentiaaliseksi ongelmaksi muodostuu lähinnä näiden ohjelmistojen tarkoituksenmukainen asentaminen. Sisällönhallintajärjestelmä sisältää Internetiin useita liityntäkohtia, joihin kohdistuu potentiaalisia uhkia. Sisällönhallintajärjestelmän palvelut muodostavat hyvin kiinteän kokonaisuuden, joiden ei tarvitse kommunikoida muiden osien kanssa muutoin kuin muutamien rajapintojen kautta. Näitä ovat asiakasohjelma-, ylläpitäjä- ja sisältöpalvelinrajapinnat. Tästä johtuen voidaan luottaa siihen, että nämä palvelut voidaan sijoittaa suojattujen verkkoyhteyksien taakse. Tulevaisuutta varten järjestelmä toteutetaan kuitenkin niin, että tarvittaessa kaikki tiedonsiirto voidaan helposti muuttaa salatuksi. Edellä mainituista rajapinnoista haavoittuvin on asiakasohjelmarajapinta. Tämän rajapinnan kautta on mahdollisuus käsitellä kaikkea järjestelmään siirrettyä sisältöä.
3 Toisen sukupolven MediaNet 21 Käyttäjän autentikointi on siis tehtävä huolella. Autentikoinnissa tulee käyttää kryptaavaa eli salaavaa protokollaa. 3.4.4 Ylläpidettävyys ja käytettävyys Järjestelmästä pyritään tekemään mahdollisimman ylläpidettävä. Ylläpidettävyyden parantaminen oli yksi niistä perussyistä, joiden takia olemassa olevia järjestelmiä haluttiin kehittää. Ylläpidettävyyttä varten järjestelmästä kirjoitetaan kattava dokumentointi. Sisällöntuottajan kannalta järjestelmän tulee olla mahdollisimman helppokäyttöinen ja toimintavarma. Järjestelmän käytettävyyden kannalta tämä tarkoittaa sitä, että suurin huomio kohdistuu asiakasohjelmaan. Sisällönhallintajärjestelmän palvelimille ja ylläpito- ohjelmalle ei aseteta erityisiä käytettävyysvaatimuksia. Multimedian levittäminen verkossa on tällä hetkellä voimakkaasti kehittyvä tietotekniikan osa-alue. Tästä johtuen sisällönhallintajärjestelmä pyritään toteuttamaan niin, että päivittäminen on tulevaisuudessa helppoa. Modulaarinen rakenne tukee selvästi tätä pyrkimystä. Yksittäinen palvelu voidaan tarvittaessa vaihtaa toiseen saman rajapinnan toteuttavaan versioon. Järjestelmässä voidaan samanaikaisesti käyttää myös useita erilaisia toteutuksia samasta palvelusta. 3.4.5 Versionhallinta Sisällönhallintajärjestelmää joudutaan todennäköisesti päivittämään suhteellisen paljon. Tästä syystä versionhallinnan järkevä toteuttaminen on tärkeätä. Perusperiaatteena pyritään siihen, että erilaisia versioita olisi käytössä mahdollisimman vähän. Versionhallinnan yksinkertaistamiseksi toteutetaan sekä asiakasohjelmaan että ylläpito- ohjelmaan automaattinen päivitysmekanismi. Kun sisällöntuottaja ottaa yhteyden sisällönhallintaytimeen, tarkistetaan, onko asiakasohjelmasta uudempaa versiota. Mikäli näin on, voidaan suorittaa asiakasohjelman automaattinen päivittäminen.
3 Toisen sukupolven MediaNet 22 Asiakasohjelman päivitysmekanismin ansiosta myös palvelinta voidaan tarvittaessa helpommin uudistaa. Kaikkia vanhoja käytössä olevia asiakasohjelman versioita varten ei tarvitse erikseen pitää näiden kanssa yhteensopivia palvelimen osia.
23 4 Toteutusteknologiat Sisällönhallintajärjestelmä on laaja ohjelmisto. Laajuudesta johtuen ohjelmiston suunnittelussa pyrittiin siihen, että toteutuksessa hyödynnettäisiin mahdollisimman paljon valmiita ohjelmakirjastoja, apuohjelmia ja kehitystyökaluja. Kolmannessa luvussa käsitellyt ohjelmistolle asetetut vaatimukset rajoittavat työkalujen ja toteutusvaihtoehtojen valintaa. Lisäksi ohjelmointikielen valinta vaikuttaa oleellisesti tehtäviin ratkaisuihin. Ohjelmiston toteutuksesta voidaan erottaa osia, joihin löytyy useita valmiita ratkaisuja. Nämä osat ovat ohjelmiston hajautus, käyttöliittymät ja tietokantaliittymä. Järjestelmässä käytetään myös muita ulkopuolisia ohjelmistoja, jotka eivät varsinaisesti vaikuta ohjelmiston rakenteeseen. 4.1 Hajautus Ohjelmiston hajautuksen toteutusta varten tutustuimme kolmeen eri ratkaisuun. Nämä ovat Sun Microsystemsin Remote Method Invocation (RMI), Object Management Groupin (OMG) Common Object Request Broker Architecture (CORBA) ja Microsoftin Distributed Component Object Model (DCOM). Näistä kaksi jälkimmäistä ovat ohjelmointikielistä riippumattomia ratkaisuja ja RMI puolestaan on rajoittunut vain ja ainoastaan Java-ohjelmointikieleen. Kaikki ratkaisut ovat ainakin periaatteessa ympäristöriippumattomia malleja. Niiden käyttö ei esimerkiksi edellytä mitään tiettyä käyttöjärjestelmää.
4 Toteutusteknologiat 24 4.1.1 Remote Method Invocation RMI-luokat lisättiin Javan perusluokkiin JDK:n (Java Development Kit) versiossa 1.1. RMI on saatavissa myös JDK:n versiolle 1.0.2 erillisenä kirjastona. RMI on riippuvainen useista Javan muista ominaisuuksista, kuten olioiden serialisoinnista, Java-luokkien binääriyhteensopivuudesta virtuaalikoneiden välillä ja liityntärajapinnoista. RMI:n avulla Java-ohjelman on mahdollista kutsua eri virtuaalikoneessa sijaitsevien olioiden metodeja ja muuttaa edellä mainittujen olioiden muuttujia. Virtuaalikoneet voivat sijaita joko samalla fyysisellä koneella tai eri koneilla, jotka ovat yhteydessä toisiinsa IP-protokollaa käyttävän tietoverkon avulla. Sovellusohjelmoijalle metodikutsut näyttävät käytännössä samalta riippumatta siitä, sijaitseeko kutsuttava olio samalla vai eri koneella. [Cu97] RMI:ssä on suppea URL-pohjainen rekisterijärjestelmä, johon olioviitteitä voidaan tallentaa. Kullakin oliolla on oma symbolinen nimensä. Olioviitteet tallennetaan rekisteriin symbolisten nimien kanssa, joten oliot kykenevät löytämään toisensa käyttämällä edellä mainittuja symbolisia nimiä. Rekisteriä voidaan verrata Internetissä käytettävään nimipalvelujärjestelmään (Domain Name System, DNS). DNS:ssä käsitellään koneen nimiä, kun taas RMI:n rekisterissä käsitellään olioiden nimiä. Sunin pyrkimyksenä on ollut lähentää Javaa ja CORBAa. Tästä on osoituksena se, että Sunilla on oma toteutus CORBA yhteensopivasta Object Request Brokerista (ORB), joka tulee JDK:n versiossa 1.2 perusluokkien mukana. Lisäksi tällä hetkellä on jo olemassa esiversio RMI-IIOP -toteutuksesta, jossa RMI:n oman protokollan asemesta käytetään OMG:n määrittelemää Internet Inter-ORB Protocol -protokollaa (IIOP). RMI-IIOP:n ansiosta RMI:tä käyttävät ohjelmat kykenevät kommunikoimaan muilla ohjelmointikielillä tehtyjen CORBA-olioiden kanssa [Su99]. 4.1.2 Common Object Request Broker Architecture Object Management Group (OMG) on 1989 perustettu kansainvälinen järjestö, jonka tavoitteena on kehittää oliopohjaisiin hajautettuihin järjestelmiin liittyvää teoriaa ja käytäntöä. OMG:n toiminnassa on nykyään mukana yli 800 yritystä ja organisaatiota.
4 Toteutusteknologiat 25 OMG:n tavoitteena on vähentää ohjelmistokehityksen monimutkaisuutta ja alentaa kehityskustannuksia sekä nopeuttaa uusien ohjelmistojen kehitysprosessia. OMG pyrkii standardoimaan hajautettujen ohjelmistojen kehityksessä käytettäviä menetelmiä. Object Management Architecture (OMA) on OMG:n määrittelemä viitemalli. OMA on OMG:n näkemys kokonaisesta hajautetusta järjestelmästä. OMA jakautuu sovellus-, järjestelmä- ja vertikaalisovellussuuntautuneisiin segmentteihin. Sovellussegmentti koostuu yleisistä sovellustoiminnoista (engl. Common Facilities), kuten tulostus-, tietokanta- ja sähköpostitoiminnot. Näiden sovellustoimintojen standardoinnin tavoitteena on luoda yleiskäyttöisiä ohjelmakomponentteja, joiden toiminnot ovat käyttäjien muokattavissa tarpeitansa vastaaviksi. Järjestelmäsegmentti sisältää hajautetun järjestelmän infrastruktuurin muodostavat komponentit. Näitä ovat ORB ja oliopalvelut (engl. Object Services). Vertikaalisovellukset ovat jonkin tietyn sovellusalueen käyttöön tarkoitettuja rajapintoja. Esimerkiksi lääketiede muodostaa oman vertikaalisovellusalueensa. [OMG99] OMA koostuu viidestä komponentista, jotka ovat Object Request Broker (ORB), Object Services, Common Facilities, Domain Interfaces ja Application Objects. Kuvassa 4-1 on esitetty OMG-viitemalli. Viitemallista on nähtävissä OMAn komponentit ja niiden suhteet toisiinsa. OMAn selkärankana toimii Object Request Broker (ORB). ORB toimii välittäjänä hajautetun järjestelmän eri olioiden välillä. Object Services -komponentti sisältää olioiden elinkaaren hallintaan tarvittavia toimintoja. Kuten edellä todettiin, Common Facilities -komponentti sisältää rajapintamäärittelyt yleisille sovellustoiminnoille. Domain Interfaces -komponentti koostuu vertikaalisovellusten rajapintamäärittelyistä. Application Objects -komponentti koostuu sovellusmäärittelyistä. Tyypillisesti nämä sovellusmäärittelyt hyödyntävät muiden OMAn komponenttien rajapintoja. [OMG99] Common Object Request Broker Architecture (CORBA) on OMAn määrittelemä ORB. CORBA, jota kutsutaan myös nimellä Object Bus, on OMAn määrittelemä komponentti, joka mahdollistaa olioiden välisen kommunikoinnin. CORBA on määrittelynä riippumaton ohjelman ajoympäristöstä ja kehitysvälineistä. CORBA
4 Toteutusteknologiat 26 määrittelee järjestelmän, joka mahdollistaa olioiden välisen vuorovaikutuksen heterogeenisessa, hajautetussa ympäristössä. OMG Object Model määrittelee käsitteistön, jolla voidaan kuvata toteutusriippumattomalla tavalla olioiden ulospäin näkyvät piirteet. Object Model perustuu muutamiin peruskäsitteisiin. Nämä käsitteet ovat olio, operaatio, tyyppi ja johdettu tyyppi. Olio voi mallintaa mitä tahansa käsitettä, kuten ihmistä, eläintä, dokumenttia, konetta yms. Oliot edustavat aina määrättyä tyyppiä. Tyypin voi käsittää eräänlaisena muottina, josta uusi olio luodaan. Tyyppi määrittelee siitä luotujen olioiden käyttäytymisen kuvaamalla operaatiot, jotka oliot toteuttavat. Tyyppien välillä voi olla erilaisia suhteita. Tyypit voivat olla perittyjä yhdestä tai useammasta muusta tyypistä. Perittyjä tyyppejä kutsutaan alityypeiksi. Kuva 4-1 OMG-viitemalli [OMG99]. Object Request Broker (ORB) Object Services Domain Interfaces Common FacilitiesApplication Objects
4 Toteutusteknologiat 27 Interface Definition Language (IDL) on OMG Object Modelin mukaisten olioiden rajapintojen määrittelyyn tarkoitettu kieli. IDL-kielisistä rajapintakuvauksista käännetään IDL-kääntäjän avulla kohdekielelle tyngät (engl. stub) ja rungot (engl. skeleton). Kohdekieli voi olla esimerkiksi C++ tai Java. Kohdekieli riippuu käytetystä IDL- kääntäjästä. Tynkä on ohjelma, jonka tehtävä on toimia asiakasolion rajapintana palvelinolioon. C++:n ja Javan tapauksessa tynkä on luokka, jolla on sama rajapinta kuin palvelinoliolla. Tynkä huolehtii kutsujen välittämisestä palvelinoliolle yhteistyössä ORBin ja rungon kanssa. Runko yksinkertaistaa palvelinolion toteutusta, koska se sisältää ORBin kanssa kommunikoimiseen tarvittavat toiminnot. ORB toimii eräänlaisena välittäjänä olioiden välillä näiden kutsuessa toisten olioiden metodeja. Kuvassa 4-2 on havainnollistettu tyngän, rungon ja ORBin rooli hajautetussa ohjelmassa. Kuvassa asiakasolio kutsuu CORBAn avulla palvelinolion metodia. Vasemman puoleinen kuva esittää tilannetta, jossa sekä asiakasolio että palvelinolio käyttävät samaa ORBia. Oikean puoleinen kuva on tilanteesta, jossa asiakasolio ja palvelinolio ovat kiinnittyneet eri ORBeihin. Tällöin asiakasolion ORB välittää kutsun tietoverkon kautta IIOP-protokollan avulla palvelinolion ORBille. Kuva 4-2 Kutsun välittäminen asiakasoliolta palvelinoliolle CORBAn avulla [Si96 luku 2]. Runko Palvelinolio Tynkä ORB Asiakasolio Runko Palvelinolio Tynkä ORB Asiakasolio ORB IIOP Kutsu Kutsu
4 Toteutusteknologiat 28 4.1.3 Distributed Component Object Model Tämä kohta perustuu Developer.com-nimisessä WWW-palvelussa (www.developer.com) julkaistuun artikkeliin [Al98]. Microsoftin ratkaisu hajautettujen ohjelmistojen tekemiseen on DCOM. DCOM on laajennus Microsoftin Component Object Modeliin (COM), joka muodostaa Windows-käyttöjärjestelmien perusarkkitehtuurin. DCOM mahdollistaa eri ohjelmointikielillä tehtyjen ohjelmakomponenttien välisen kommunikaation tietoverkon välityksellä. DCOMin käytöstä seuraavat edut johtuvat sen tiiviistä sitomisesta itse Windows- käyttöjärjestelmään. DCOMin avulla omissa sovelluksissa voi hyödyntää useita Windows- alustan palveluita, kuten Microsoft Transaction Serveriä tai Microsoftin Internet Information Serveriä. Lisäksi DCOM toimii Windowsin turvallisuusmallin alaisuudessa, joten turvallisuusnäkökohdat on myös otettu huomioon. Jokaiselle DCOM-komponentille voidaan määrittää oma Access Control List (ACL), jolla määrätään ketkä käyttäjät ja mitkä ohjelmat saavat kyseistä komponenttia käyttää. DCOMin ongelmana on, että se on teknologiana vielä kohtuullisen uusi. Työkalut eivät olleet vielä kesällä 1997 kovinkaan kehittyneitä. DCOM ei myöskään ole ympäristöriippumaton ratkaisu. Sisällönhallintajärjestelmän suunnitteluvaiheessa DCOMia ei ollut saatavilla muille alustoille kuin Intel-pohjaisille PC -koneille, joiden käyttöjärjestelmänä oli Windows. Nykyään DCOM löytyy jo useammille laitealustoille kuten Sunin Solarikselle ja Linuxille. 4.1.4 Menetelmän valinta CORBAn etuna on vahva yritysten tuki. Myös CORBAn avoimuus on positiivinen asia. CORBA-työkaluja valmistavia yrityksiä on useita, joten työkaluja löytyy useille laitealustoille, käyttöjärjestelmille ja ohjelmointikielille. Nämä työkalut ovat kuitenkin olleet perinteisesti hyvin kalliita, mutta nykyään on saatavilla edullisia jopa ilmaisia ratkaisuja. CORBAn ongelmana on ollut muun muassa se, että eri valmistajien ORBit
4 Toteutusteknologiat 29 eivät välttämättä ole kyenneet kommunikoimaan keskenään. Tähän on pyritty saamaan parannus CORBA-määrittelyä [OMG98] tarkentamalla. Microsoftin DCOM on piirteidensä puolesta vertailukelpoinen CORBAan nähden. DCOM oli vielä vuoden 1997 kesällä suhteellisen uusi teknologia, joten DCOMin käyttöön tarvittavat työkalut eivät olleet kovinkaan kehittyneitä. Lisäksi DCOMin Windows- sidonnaisuus oli eräs suurimmista ongelmista. DCOMin valinta olisi myös käytännössä sulkenut pois mahdollisuuden käyttää Javaa toteutuskielenä. Ainoa keino hyödyntää DCOMia Javasta olisi ollut käyttää Microsoftin tekemää virtuaalikonetta. Sisällönhallintajärjestelmälle asetettu vaatimus ympäristöriippumattomuudesta olisi tällöin jäänyt saavuttamatta, koska kyseistä virtuaalikonetta ei ole saatavilla kuin Windows- ympäristöön. Java RMI on huomattavasti yksinkertaisempi ratkaisu kuin Microsoftin DCOM ja OMG:n CORBA. RMI on lähinnä lisäys Javaan, kun taas DCOM ja CORBA pyrkivät määrittelemään kokonaisen hajautetun järjestelmän palveluineen. RMI soveltuu lähinnä pienimuotoisiin hajautettuihin järjestelmiin, koska se ei tarjoa kovin monipuolisia palveluita. RMI:n suurin vahvuus on käytön helppous. Tämä on seurausta siitä, että RMI on suunniteltu ainoastaan Javan kanssa käytettäväksi. RMI:n käyttö on lähes läpinäkyvää sovellusohjelmoijalle. RMI:n suurin vahvuus on myös sen suurin heikkous. RMI:n valinta hajautuksen toteutukseen olisi sitonut projektin tiukasti Javan ympärille ja muiden ohjelmointikielten käyttäminen olisi ollut hyvin hankalaa, ellei peräti joissain tapauksissa mahdotonta. Ohjelmistojen välinen kommunikaatio päätettiin toteuttaa CORBA-yhteensopivan ORBin avulla [OMG98]. Koska tässä projektissa ohjelmistot toteutetaan Javalla, CORBA- työkaluna käytetään Ionan OrbixWeb 3:a. Koska käytössä on vain yhden valmistajan ORB, ei ORBien välinen kommunikaatio muodostu ongelmaksi. Toteutuksessa pyritään nojautumaan mahdollisimman paljon IDL to Java Mapping -määrittelyn mukaisiin rajapintoihin [OMG97]. Tällöin on ainakin periaatteessa mahdollista vaihtaa käytettävä ORB toisen valmistajan ORBiin, jos tämä tulee tarpeelliseksi.
4 Toteutusteknologiat 30 4.2 Ohjelmointikieli Sisällönhallintajärjestelmän toteutusta varten valittiin ohjelmointikieleksi Java. Toteutuksen aloitushetkellä uusin versio JDK:sta oli 1.1.3, joten sisällönhallintajärjestelmän toteutuksessa päätettiin tukeutua JDK 1.1:een. Järjestelmää tultaisiin käyttämään monissa erilaisissa laitteistoympäristöissä, joten järjestelmästä oli saatava mahdollisimman ympäristöriippumaton. Järjestelmän suunnitteluhetkellä käytössä olivat Windows NT-, Linux- ja Sun Solaris- käyttöjärjestelmät. Kaikille näille oli saatavissa Java-virtuaalikone. Käytettäessä Javaa voidaan käyttää samoja ohjelmabinäärejä kaikissa koneissa, joihin löytyy yhteensopiva Java-virtuaalikone. Javan eduksi voidaan laskea myös se, että sille oli olemassa kohtuullisen hintaisia tai jopa ilmaisia CORBA ORBeja. Projektin alussa käytimme Sun Microsystemsin ilmaista esiversiota heidän tekemästään Java IDL -ORBista. Myöhemmin siirryimme kuitenkin käyttämään Ionan OrbixWebia, koska tämä oli oleellisesti vakaampi ohjelma ja toteutti OMG:n IDL to Java Mapping -määrittelyn [OMG97] toisin kuin Sunin toteutus. Javan ongelmana on tehottomuus verrattuna muihin ohjelmointikieliin. Alusta alkaen oli kuitenkin selvää, että järjestelmän pullonkaulana ei tulisi olemaan varsinainen sisältöjen hallinta vaan sisältöjen muuntaminen. Koska muuntaminen suoritetaan kolmannen osapuolen toimittamilla ohjelmistoilla, ei Javan valitseminen ohjelmointikieleksi vaikuta oleellisesti järjestelmän suorituskykyyn. Javan valintaan vaikutti myös omalta osaltaan se, että projektiryhmällä oli jo kokemusta ohjelmoinnista kyseisellä kielellä. Tietyt Javan piirteet kuten serialisointi ja kattavat perusluokkakirjastot houkuttelivat myös valitsemaan Javan toteutuskieleksi. Vaikka ohjelmointikieleksi valittiinkin Java, ei tämä suinkaan tarkoita sitä, että kaikki järjestelmään liittyvät ohjelmat olisi tehtävä Javalla. Koska sovelluksen toteutuksessa käytetään CORBAa, voidaan Javan rinnalla käyttää tarpeen vaatiessa myös muita kieliä.
4 Toteutusteknologiat 31 Esimerkiksi paljon laskentaa suorittavat ohjelmat voidaan toteuttaa muun muassa C++:lla ja liittää ne järjestelmään CORBAn avulla. Käytännössä kaikki sellaiset kielet, joille löytyy CORBA-määrittelyn [OMG98] mukainen ORB, joka kykenee toimimaan yhdessä Ionan OrbixWebin kanssa, ovat käytettävissä sellaisenaan. Voidaan myös toimia siten, että tehdään halutulla ohjelmointikielellä erillinen ohjelma, joka suoritetaan Java- virtuaalikoneen avulla. Tämä suoritettava ohjelma voi tietysti olla myös kolmannen osapuolen valmistama. Näin voidaan liittää melkein mitä tahansa ulkopuolisia ohjelmia järjestelmään käyttäen Javaa ja CORBAa. Muun muassa järjestelmään liittyvät muunnosohjelmat on toteutettu edellä mainitulla tavalla. 4.3 Käyttöliittymät Sisällönhallintajärjestelmän käyttöliittymistä haluttiin tehdä ympäristöriippumattomia. Sun Microsystemsin kehittämä ohjelmointikieli Java tarjoaa tähän mahdollisuuden, koska se on alusta alkaen suunniteltu laitteisto- ja käyttöjärjestelmäriippumattomaksi. 4.3.1 Ympäristöriippumattomuuden toteutustavat Ympäristöriippumattomuus käyttöliittymäkirjastoon Javassa voidaan saada aikaan ainakin kahdella toisistaan selvästi poikkeavalla tavalla. Yleinen ratkaisu tähän on rakentaa rajapinta ympäristökohtaisten käyttöliittymäkomponenttien päälle. Tällöin ohjelma kutsuu aina samaa rajapintaa riippumatta ympäristöstä. Toinen vaihtoehto on suorittaa komponenttien piirto käyttöliittymäkirjaston sisäisesti, jolloin ympäristökohtaisia komponentteja ei käytetä lainkaan. Ympäristökohtaisten komponenttien päälle rakennettu rajapinta käyttää siis kunkin ympäristön omia komponentteja. Niinpä käyttäjä saa aina eteensä tutun näköisen ja oloisen käyttöliittymän. Useat tietokoneen käyttäjät ovat erittäin tarkkoja siitä, että sovellus näyttää sellaiselta, johon on tottunut. Myös ohjelmistoalan ihmiset ovat usein varsin tarkkoja siitä, että esim. Unix-käyttöjärjestelmässä ajettu ohjelma käyttäytyy Unix- ohjelman tavoin, eikä esimerkiksi Macintosh- tai Windows-ohjelman tavoin. Nykyään on
4 Toteutusteknologiat 32 markkinoilla ohjelmia, esimerkiksi selaimia, jotka ovat samanlaisia kaikissa ympäristöissä. Vielä muutama vuosi sitten tämä oli erittäin harvinaista. Saman rajapinnan kautta kutsuttu ympäristökohtainen komponentti saattaa olla täysin eri näköinen eri ympäristöissä. Myös niiden looginen toiminta saattaa vaihdella. Ohjelmoijan tuleekin tällöin olla tarkkana ja testata ohjelmansa kaikissa mahdollisissa ympäristöissä. Käytännössä tämä on osoittautunut erittäin hankalaksi. Itse käyttöliittymäkirjastosta tulee helposti rajoittunut komponenttivalikoimaltaan. Mukaan voidaan ottaa ainoastaan komponentit, joita löytyy jokaisesta kohdeympäristöstä, ja joiden toiminta on jokseenkin samankaltaista. Jotta rajapinnan kirjoittaminen olisi mahdollista, joudutaan siis toimimaan “pienimmän yhteisen nimittäjän” -periaatteella. Tämä rajaa pois kaikki vähänkään monimutkaisemmat ja omintakeisemmat komponentit. Yhtenäisen ulkonäön aikaansaamiseksi komponenttien piirto kirjaston sisäisesti lienee ainoa vaihtoehto. Kun komponentteja ei lainatakaan systeemiltä, vaan hoidetaan piirtäminen itse, voidaan määritellä tarkalleen komponenttien ulkonäkö ja toiminta. Tällöin ohjelmoija voi rauhassa kirjoittaa käyttöliittymän luottaen siihen, että käyttäjä näkee ja kokee käyttöliittymän halutulla tavalla. Kirjaston suunnittelijalle tämä antaa myös vapauksia, koska näin liikutaan korkeammalla abstraktiotasolla kuin käyttöjärjestelmän rajapinta normaalisti tarjoaa. Näin ei olla rajoittuneita minkään systeemin tarjoamiin komponentteihin. 4.3.2 Javan käyttöliittymäkirjastot Kun käyttöliittymäkirjaston valintaa vuoden 1997 kesällä ryhdyttiin miettimään, oli ainoastaan kaksi varteenotettavaa kirjastovaihtoehtoa valittavana. Sun Microsystemsin Abstract Windowing Toolkit (AWT) ja esiversiossaan ollut Microsoftin Application Foundation Classes (AFC). Myöhemmin törmättyämme vaikeuksiin valitsemamme AFC:n kanssa tutustuimme myös tuolloin vasta suunnitteilla olleeseen Sun Microsystemsin Java Foundation Classes (JFC) -kirjastoon.
4 Toteutusteknologiat 33 Abstract Windowing Toolkit AWT on Sunin alkuperäinen graafisten Java-käyttöliittymien toteutukseen tarkoitettu kirjasto. Näihin päiviin asti pääosa Javalla tehdyistä käyttöliittymistä on tehty AWT:llä. AWT sisältyy kaikkiin jo julkaistuihin JDK:hin. JDK 1.1 uudisti AWT:ta varsin paljon. Tärkein muutos oli täysin uudenlainen tapahtumienkäsittely. Java esiteltiin vuonna 1995, ja sen käyttöliittymäkirjasto AWT olisi varmasti tullut hylätyksi, mikäli ihmisten konservatiivisuutta käyttöliittymien suhteen ei olisi otettu huomioon. Niinpä AWT toimiikin ympäristökohtaisten komponenttien ympäristöriippumattomana rajapintana. Aluksi tätä pidettiin varsin onnistuneena ratkaisuna. Olihan ennenkuulumatonta, että sama tavukoodi ajettuna eri ympäristöissä tarjosi käyttäjille aina kuitenkin ympäristökohtaisen käyttöliittymän. Ongelmia ilmeni kuitenkin varsin nopeasti. Ohjelmoijat olivat tyytymättömiä niin komponenttivalikoimaan kuin komponenttien toimivuuteenkin. Kuten kuvasta 4-3 voidaan Kuva 4-3 Vasemmalla on kuva on SunOS 5.4 -käyttöjärjestelmään tehdyn Java-virtuaalikoneen tuottamasta ikkunasta, kun taas oikealla oleva on Windows 95 -käyttöjärjestelmään tehdyn virtuaalikoneen näkemys samasta ikkunasta (X-server ensimmäisen kuvan ikkunassa on Windows- koneessa). Käyttöliittymäkirjastona on AWT.
4 Toteutusteknologiat 34 havaita, täysin sama tavukoodi näyttää jo näinkin yksinkertaisessa esimerkissä melko erinäköiseltä. Ohjelmoija saattaa tehdä ohjelmoidessaan oletuksen, että radiopainikkeen otsikko on aina kiinni painikkeessa, vaikka todellisuudessa sitä ei ole määritelty, vaan se riippuu ympäristökohtaisesta toteutuksesta. Java Foundation Classes JFC syntyi Sunin, Netscapen ja IBM:n päätöksestä tehdä uusi AWT:n korvaava käyttöliittymäkirjasto. Jo pitkään ollaan oltu sitä mieltä, että AWT ei ole riittävä ratkaisu Java-käyttöliittymiin. Netscape olikin kehitellyt omaa Internet Foundation Classes (IFC) -kirjastoa. Tämän kirjaston tarkoitus oli olla selaimessa mukana, ja niinpä sovelmissa (engl. applet) olisi voitu käyttää näitä uusia käyttöliittymäkomponentteja ilman, että niitä tarvitsisi ladata palvelimelta. Ideana oli nimenomaan tehdä kaikki komponenttien piirtäminen kirjaston sisäisesti, jolloin kirjaston kehittäjillä olisi vapaat kädet komponenttien suunnitteluun. Kirjaston kehittely alkoi loppuvuodesta 1996. Idea oli hyvä, mutta IFC ei milloinkaan saanut suurta suosiota lukuisten teknisten ongelmien vuoksi. Kun Sun sitten vihdoin uskoi itsekin, että AWT ei riitä kovin pitkälle, se alkoi kehitellä omaa kirjastoaan IFC:n pohjalta. Ilmoitus tästä annettiin Java-maailmalle huhtikuussa 1997. JFC:n ensimmäinen versio valmistui helmikuussa 1998. JFC:n eräs hieno piirre on sen vaihdettavissa oleva ulkonäkö ja tuntu (engl. pluggable look and feel). Ohjelmoija voi siis päättää, haluaako hän ohjelmansa näyttävän esimerkiksi Windows-ohjelmalta vai joltakin muulta. Tällä hetkellä valittavissa on Windows-, Motif- ja Metal-tyylit. Näistä Metal on Sunin oma tätä tarkoitusta varten kehittämä tyyli. Ohjelmoija voi myös jättää käyttäjälle sopivan tyylin valitsemisen annetuista vaihtoehdoista. Myös oman tyylin luominen on mahdollista. Tämä oli siis Sunin varsin elegantti ratkaisu käyttäjien konservatiivisuusongelmaan. Eri tyyleistä on esimerkkejä liitteessä II. Tällaisen muita järjestelmiä matkivan kirjaston pitäminen ajan tasalla saattaa muodostua ongelmaksi. Hyvänä esimerkkinä tästä on Windowsin tiedoston avaus- ja talletusdialogi.
4 Toteutusteknologiat 35 JFC:n sisältämän komponentin Windows - look and feel -toteutus on valitettavan eri näköinen kuin Windows NT 5:n esiversion vastaava. JFC on oikeastaan AWT:n laajennus. Kaikki JFC:n uudet komponentit, kuten myös AWT:n komponentit, perivät AWT:n Component-luokan. Tästä seuraa täydellinen AWT- yhteensopivuus. JFC-komponentteja voikin näin asettaa monien AWT-komponenttien päälle. JFC:n ohjelmointimalli on tietokeskeinen. Tämä tarkoittaa sitä, että jokainen JFC- komponentti osoittaa johonkin tietomallirajapintaan. Ohjelmoija voi käyttää komponentin oletustietomallia tai laajentaa sitä haluamallaan tavalla. Hän voi myös vaihtaa sen kokonaan, kunhan uusi luokka toteuttaa kyseisen komponentin tietomallille määrätyn rajapinnan. Vaihtaminen voidaan tehdä myös ajon aikana. Tällä tavoin komponentit ovat dynaamisempia kuin perinteiset kiinteällä tietomallilla toimivat komponentit. Tietokeskeinen lähestymistapa on monille käyttöliittymäohjelmoijille uusi. JFC:ssä on esitelty myös muita uusia konsepteja. JFC:n toteuttajat eivät ole kunnioittaneet vanhoja käsityksiä käyttöliittymäkirjastoista, vaan ovat luoneet uusia lähestymistapoja. Tämä voi aiheuttaa monille kokeneillekin ohjelmoijille ylimääräistä päänvaivaa. JFC:n edistykselliset komponentit eivät ole kaikkein helpoimpia käyttää. Esimerkiksi puukomponentti omaa monia eri luokkia ja rajapintoja, joiden avulla puu luodaan ja sitä käsitellään. Perinteisesti käyttöliittymäkirjasto tarjoaisi yhden luokan, joka sisältäisi tarvittavat tietorakenteet, mutta JFC tarjoaa eräänlaisen sovelluskehyksen (engl. framework) näihin kehittyneisiin komponentteihin. Tämä ominaisuus tuo monipuolisuutta, mutta myös hankaloittaa yksinkertaisten käyttöliittymien tekoa. Pienissä ja yksinkertaisissa sovelluksissa koodin määrä tulee usein suuremmaksi, kuin perinteisiä kirjastoja käyttämällä.
4 Toteutusteknologiat 36 Application Foundation Classes AFC on Microsoftin ratkaisu Javan käyttöliittymäkirjastoksi. Kyllästyneenä AWT:n heikkouksiin Microsoft ilmoitti tammikuussa 1997 kehittelevänsä AFC:tä. Microsoft olisi halunnut Sunin ottavan AFC:n käyttöönsä, mutta huhtikuussa Sun ilmoittikin aloittavansa JFC:n kehityksen. Tästä alkoi katkera kilpailu Javan käyttöliittymien tulevaisuudesta. Microsoft sai kuitenkin noin kuuden kuukauden etumatkan kirjastonsa kehittämisessä. Ensimmäinen näytösversio AFC:stä oli valmis huhtikuussa ja lopullinen versio oli valmis lokakuussa 1997. AFC korvaa täysin AWT:n. AFC-komponentit eivät siis peri AWT:n Component-luokkaa. AFC:n suunnittelijat perustelivat tätä AWT:n Component -luokan raskaudella. AFC pohjautuu UIComponent-luokkaan, jonka on tarkoitus käyttää vähemmän muistia kuin Component-luokka. Tämän seurauksena AFC-komponentteja ei voi suoraan asettaa AWT- komponentteihin. Tätä tarkoitusta varten AFC sisältää erityiset AWT-yhteensopivat luokat, jotka toimivat siltana AFC:n ja AWT:n välillä. AFC:n ohjelmointimalli on komponenttikeskeinen ja hyvin samankaltainen AWT:n kanssa. Ohjelmoiminen on hyvin suoraviivaista ja helppoa tottuneelle AWT-ohjelmoijalle. Useimmat komponenteista perivät UIContainer-luokan, jonka päälle saa asettaa UIComponent-luokan. Niinpä komponenttien päällekkäin asettelu on melko vapaata. Esimerkiksi List-komponentti on vain paneeli, johon on lisätty komponentteja allekkain ja asetettu pohjaväriksi valkoinen. AFC:n komponenttien ulkonäkö on tuttu Windows-käyttöliittymästä. Myös komponenttien toiminnallisuus on samanlaista. AFC:llä pystyykin tekemään varsin vaikuttavia Windows-ohjelmalta näyttäviä ja tuntuvia Java-käyttöliittymiä. AFC:stä on kaksi versiota: JDK 1.0.2 sekä JDK 1.1 -yhteensopiva. Ensin mainittu on tarkoitettu käytettäväksi sovelmissa, ja se on pyritty saamaan toimimaan kaikissa JDK 1.0.2 -yhteensopivissa virtuaalikoneissa. Jälkimmäinen on JDK 1.1 -yhteensopiva, mutta toimii vain Microsoftin omalla virtuaalikoneella.
4 Toteutusteknologiat 37 4.3.3 Yhteenveto ja kirjastojen tulevaisuus Javan käyttöliittymäkirjastot ovat muutaman vuoden aikana kehittyneet todella huimasti. Komponenttivalikoima uusissa kirjastoissa on hyvin laaja. Varsinkin JFC tarjoaa jo peruskirjastossaan sellaisia ominaisuuksia, joita on yleensä totuttu saamaan vain erillisillä kirjastoilla. Tämä ei ole kaikkien mielestä hyvä asia, koska näin myös luokkakirjaston koko kasvaa, ja yleensä koko kirjasto toimitetaan sovellusten mukana. Microsoft toimittaa AFC-kirjastoa Internet Explorer 4:n mukana, niinpä uudet Windows- käyttöjärjestelmät pitävät kirjaston sisällään. AFC:n JDK 1.1 -yhteensopiva versio vaikuttikin voittajalta aina sen viimeiseen esiversioon saakka. Silloin vielä AFC toimi myös Sunin virtuaalikoneella. Varsinaisen version ilmestyttyä lokakuussa 1997 ilmeni, ettei kirjastoa voikaan enää käyttää muilla kuin Microsoftin virtuaalikoneilla. Se oli estetty kirjastossa joillakin ympäristökohtaisilla kutsuilla. Microsoft julkaisi erikseen JDK 1.0.2 -yhteensopivan version, joka sitten toimi myös Sunin virtuaalikoneella. Niinpä JDK 1.1 -yhteensopivaa sovellusta ei voitu tehdä ympäristöriippumattomaksi käyttäen Microsoftin AFC:tä. AFC:n suurin vihollinen taitaakin olla Microsoft itse estämällä erinomaisen kirjaston käyttämisen muulta Java-maailmalta. Vaikuttaisi siltä, että jossain vaiheessa kun kirjasto oli jo melkein valmis, Microsoft päättikin, ettei AFC:stä tehdäkään yleiseen käyttöön käyttöliittymäkirjastoa kun kerran Sun ei sitä hyväksynytkään. Microsoft on muutoinkin alkanut tehdä omista Java-kirjastoistaan yhä enemmän ja enemmän ympäristöriippuvaisia huomioiden ainoastaan Windows-käyttäjät. JFC on täysin JDK 1.1 -yhteensopiva. Niinpä myös Microsoftin virtuaalikone suorittaa JFC-sovelluksia ongelmitta. JFC on tällä hetkellä ainoa järkevä vaihtoehto JDK 1.1 -pohjaisiin sovelluksiin. Sitä vastoin sovelmissa JFC:tä ei kannata käyttää, koska käyttäjillä ei yleensä ole tuota kirjastoa koneillansa. Microsoft on ilmoittanut, ettei se aio laittaakaan sitä selaintensa tai käyttöjärjestelmiensä Java-luokkiin mukaan. JDK 1.1 -yhteensopivassa selaimessa sitä ei tarvitse ollakaan, sillä JFC ei kuulu varsinaiseen Javan luokkakirjastoon. Juuri valmistunut Sun Microsystemsin JDK 1.2 pitää sisällään JFC:n. Niinpä selaimien, jotka väittävät olevansa JDK 1.2 –yhteensopivia, tulisi sisältää myös tämä upea käyttöliittymäkirjasto.
4 Toteutusteknologiat 38 Asiakasohjelma toteutettiin aluksi Microsoftin AFC-kirjaston esiversioita käyttäen. Kun AFC:n varsinainen versio ei sitten toiminutkaan muilla kuin Microsoftin virtuaalikoneella, päätettiin asiakasohjelma ohjelmoida uudelleen Sun Microsystemsin JFC-kirjastoa käyttäen. JFC-kirjaston kehitys oli jatkossa varsin myönteistä, joten kirjaston vaihtaminen kohtuullisen aikaisessa vaiheessa osoittautui järkeväksi päätökseksi. 4.4 Muut valitut teknologiat Järjestelmässä käytetään myös sellaisia ulkopuolisia ohjelmia, jotka eivät oleellisesti vaikuta ohjelmiston rakenteeseen suunnittelu- ja toteutusvaiheessa. Nämä ohjelmat ovat kuitenkin tarpeellisia sisällönhallintajärjestelmän käyttöönotossa ja käytössä. Tällaisia ohjelmia ovat esimerkiksi InstallShield for Java ja SourceGuard. Järjestelmän ohjelmat, jotka vaativat asennusta, asennetaan InstallShield-ohjelman avulla. Asiakasohjelma, ylläpito-ohjelma ja sisällönhallintaydin ovat kaikki asennettavissa InstallShieldin avulla. SourceGuard on ohjelma, jonka avulla voidaan muuttaa Java- luokkatiedostojen rakennetta siten, että niitä ei enää ole mahdollista saada takaisin lähdekoodimuotoon. Tätä prosessia kutsutaan obfuskoinniksi (engl. obfuscate). SourceGuardia tarvitaan suojaamaan ohjelmistossa syntyneitä Java-luokkatiedostoja, joita jaetaan ulkopuolisille tahoille kuten asiakkaille. Sisällönhallintajärjestelmä käyttää tietojen tallentamiseen tietokantaa. Koska järjestelmän palvelut toteutetaan Javalla, on luontevaa käyttää Java Database Connectivity (JDBC) -rajapintaa tietokannan liittämiseksi sisällönhallintajärjestelmään. JDBC:n avulla Java- ohjelmat kykenevät suorittamaan SQL-kielisiä kyselyitä ja päivityksiä tietokantaan. Järjestelmän tietokantana toimii Solid WebEngine 2.3. Koska järjestelmän toteutuksessa käytetään JDBC-rajapintaa ja SQL-kieltä, voidaan siirtyä käyttämään jotain toista tietokantaa tarvittaessa. JDBC-kirjaston mukana toimitetaan myös JDBC-ODBC -silta, joka mahdollistaa sellaisten tietokantojen käytön, joille ei löydy JDBC-tukea.
4 Toteutusteknologiat 39 Järjestelmän kehitysympäristö koostuu Linux ja Windows NT -pohjaisista tietokoneista. Ohjelmiston kehitys tehdään XEmacs-tekstieditorilla. Versionhallinta toteutetaan RCS- ohjelman avulla.
40 5 Sisällönhallintaydin Tässä ja seuraavassa luvussa sisällönhallintajärjestelmään viitataan sanalla järjestelmä. Järjestelmä koostuu kolmesta osasta: asiakasohjelmasta, sisällönhallintaytimestä ja ylläpito-ohjelmasta. Sisältöpalvelimet ovat osa sisällönhallintaydintä. Kuvassa 5-1 on havainnollistettu järjestelmän osia ja niiden suhteita toisiinsa. Asiakasohjelman avulla sisällöntuottaja voi hallita järjestelmässä olevia sisältöjään ja näihin liittyviä tietoja. Sekä ylläpito- että asiakasohjelma on pyritty pitämään mahdollisimman yksinkertaisina. Ohjelman varsinainen toiminnallisuus pyritään pitämään Kuva 5-1 Sisällönhallintajärjestelmän rakenne. Sisältöpalvelin Sisältöpalvelin Sisältöpalvelin Sisältöpalvelin Ylläpito-ohjelma Asiakasohjelma Loppukäyttäjä Sisällöntuottaja Ylläpitäjä Loppukäyttäjä- ohjelma Loppukäyttäjä- ohjelma Loppukäyttäjä- ohjelma Sisällönhallintajärjestelmä Sisällönhallintaydin
5 Sisällönhallintaydin 41 mahdollisimman pitkälle palvelinohjelmiston, tässä tapauksessa sisällönhallintaytimen, sisällä. Tällöin ylläpito- ja asiakasohjelmat toimivat lähinnä käyttöliittyminä sisällönhallintaytimen eri toiminnoille. Tehokkuussyistä tästä periaatteesta on tosin jouduttu joissain kohdissa tinkimään. Sisällönhallintaydin sisältää järjestelmän tarvitsemat tiedot sekä toiminnot, jotka mahdollistavat sisältöjen hallinnan keskitetysti asiakasohjelmalla. Sisällönhallintaytimen tehtävänä on pitää kirjaa kaikista järjestelmän sisällöistä, käyttäjistä sekä näihin liittyvistä tiedoista. Sisällönhallintaytimessä on tarvittavat ohjelmat järjestelmään siirretyn materiaalin käsittelyyn ja siirtämiseen halutuille sisältöpalvelimille. Sisältöpalvelimien tehtävänä on toimia järjestelmässä varastoina, joihin sisällöt tallennetaan. Sisältöpalvelimet huolehtivat myös sisältöjen levittämisestä loppukäyttäjäohjelmille. 5.1 Rakenne Sisällönhallintaydin on hajautettu ohjelmisto, jonka pienin itsenäinen ohjelmayksikkö on palvelu. Palvelut voidaan jakaa perus- ja erityispalveluihin. Peruspalvelut ovat yleishyödyllisiä palveluita, joita muut sisällönhallintaytimen palvelut käyttävät. Peruspalveluita ei käytetä suoraan järjestelmän ulkopuolelta. Erityispalveluita ovat kaikki muut kuin peruspalvelut. Käytännössä erityispalveluita käytetään vain joidenkin tiettyjen MediaNet-sovellusten yhteydessä. Liityntäpalvelut ovat erityispalveluita, jotka toimivat sisällönhallintaytimen ja ytimen ulkopuolisten ohjelmien välisinä rajapintoina. Palvelut muodostavat järjestelmän toimintoja suorittavan osan. Palveluiden suorittamisen ja hallinnan apuna käytetään palvelimia. Palvelin on alusta, jonka avulla voidaan tehostaa palveluiden suoritusta ja yksinkertaistaa niiden hallintaa.
5 Sisällönhallintaydin 42 5.1.1 Palvelut Palveluksi kutsutaan sellaista ohjelmaa tai ohjelman osaa, joka toteuttaa TFService- nimisen CORBA-rajapinnan ja jonkin palvelukohtaisen rajapinnan. Palvelu koostuu yhdestä tai useammasta CORBA-oliosta. Koska rajapinta määritellään IDL:n avulla, voidaan palvelu toteuttaa periaatteessa millä tahansa ohjelmointikielellä, jolle on olemassa IDL-kääntäjä ja CORBA-määrittelyn [OMG98] mukainen ORB. Kommunikointi palveluiden kanssa tapahtuu CORBA-määrittelyssä esitetyn IIOP-protokollan mukaisesti. Kaikki järjestelmän tähän mennessä toteutetut palvelut on tehty Javalla. Kuvassa 5-2 on kuvattu palveluiden ja CORBAn välistä suhdetta. CORBA toimii välittäjänä palveluiden välisessä kommunikaatiossa. Kuvassa ClientC-niminen palvelu käyttää muita sisällönhallintaytimen palveluita (UserManager, FileManager ja Kuva 5-2 Palvelut kommunikoivat CORBAn avulla. CORBA User Manager Code Repository File Manager ClientC
5 Sisällönhallintaydin 43 CodeRepository). Koska CORBA huolehtii kutsujen välittämisestä palvelulta toiselle, ei palveluiden toteutuksessa tarvitse huolehtia siitä, miten kutsu käytännössä välitetään. TFService-rajapinta sisältää palveluiden hallintaan sekä niiden tilan seurantaan liittyviä metodeja. Hallintaan kuuluvia asioita ovat palvelun tilan muuttamiseen liittyvät metodit, palvelupyyntö, viestien vastaanotto ja palveluiden ominaisuudet. Palveluiden toteutuksen helpottamiseksi on luotu palvelu-sovelluskehys. Uudet palvelut voivat periä TFServiceServant-nimisen luokan, joka sisältää suurimman osan palveluille tarpeellisista toiminnoista. TFService-rajapinnan lisäksi jokaisella palvelulla on oma palvelukohtainen rajapinta, joka määrittelee palvelun toteuttamat metodit ja attribuutit. Palveluihin liittyy tilakäsite. Palvelut ovat kullakin hetkellä jossain ennalta määritellyssä tilassa. Palvelu voi olla ajossa, pysäytetty, käynnistymässä tai lopettamassa toimintaansa. Suurin osa palveluiden toiminnoista on käytettävissä vain silloin, kun ne ovat ajossa- tilassa. Palvelupyynnön avulla voidaan kysyä palvelukohtaisilla parametreilla, voiko palvelu suorittaa halutun toimenpiteen. Esimerkiksi tiedostojen hallinta -palvelulle (FileManager) voidaan lähettää palvelupyyntö, jonka avulla voidaan selvittää, mahtuuko halutun kokoinen tiedosto FileManagerin levylle. Sisällönhallintaytimen Locator-palvelu käyttää palvelupyyntöä hakiessaan sopivaa palvelua. Locator on eräänlainen hakukone, jonka avulla palvelut voivat etsiä muita sisällönhallintaytimen palveluita, jotka täyttävät halutut ehdot. Ominaisuuksien (engl. property) avulla voidaan määritellä palvelun toimintaan vaikuttavia parametreja. Ominaisuudet ovat merkkijonopareja. Parin merkkijonoista ensimmäinen on tunniste ja toinen on ominaisuuden arvo. Ominaisuuksia voidaan verrata esimerkiksi useissa käyttöjärjestelmissä käytettyihin ympäristömuuttujiin. Ominaisuuksien arvot otetaan käyttöön aina palvelun käynnistymisen yhteydessä. Tästä syystä ominaisuuksia muutettaessa ajon aikana täytyy palvelu käynnistää uudestaan, jotta uudet asetukset tulevat voimaan. Palveluiden kantaluokka TFServiceServant määrittelee kaikille
5 Sisällönhallintaydin 44 palveluille yhteisiä ominaisuuksia, minkä lisäksi kukin palvelu voi määritellä itselleen tarpeellisia ominaisuuksia. Peruspalvelut Peruspalvelut tuottavat yleishyödyllisiä palveluita sisällönhallintaytimen muille palveluille. Peruspalvelut toimivat eräänlaisena pohjana, jonka päälle varsinaisten sovellusten vaatima toiminnallisuus perustuu. Peruspalveluihin kuuluvat muun muassa tiedostojen hallintaa, käyttäjien hallintaa, tietokannan käsittelyä ja palveluiden hallintaa suorittavat palvelut. Taulukossa 5-1 on lueteltu sisällönhallintaytimen peruspalvelut ja annettu lyhyt kuvaus niiden toiminnasta. Peruspalveluille on tyypillistä, että ne käyttävät apunaan jotain ulkopuolista ohjelmaa tai että ne tarjoavat muille sisällönhallintaytimen palveluille mahdollisuuden käyttää suoraan ulkopuolista ohjelmaa. Esimerkiksi sisällönhallintaytimen tietokantapalveluista huolehtiva DBC-palvelu tarjoaa mahdollisuuden suorittaa SQL-kielisiä hakuja ja päivityksiä tietokantaan. Mailer-palvelu puolestaan mahdollistaa sähköpostin lähettämisen palveluista. Kaikki palvelut ovat tasa-arvoisia keskenään, mikä tarkoittaa sitä, että mikä tahansa palvelu voi käyttää toista palvelua apunaan. Palvelut voivat olla niin riippuvaisia toisten palveluiden tarjoamista toiminnoista, että ne eivät pysty suorittamaan omia toimintojaan ilman toisen palvelun apua. Locator-palvelu on hyvä esimerkki sellaisesta palvelusta, jota ilman muut palvelut eivät voi suorittaa omia toimintojaan. Locatorin avulla palvelut hakevat viitteitä haluamiinsa muihin palveluihin. Jos sisällönhallintaytimessä ei ole käynnissä Locator-palvelua, eivät palvelut löydä toisiaan. Tilanne on hieman saman tapainen, jos sisällönhallintaytimessä ei ole DBC-palvelua. Tämä johtuu siitä, että monet palveluista on toteutettu siten, että ne käyttävät tietokantaa omien palvelukohtaisten tietojensa säilyttämiseen. Esimerkiksi nykyiset Log-, ProcessQueue- ja ErrorHandler- palveluiden toteutukset käyttävät tietokantaa.
5 Sisällönhallintaydin 45 Erityispalvelut Erityispalveluiden tehtävänä on suorittaa MediaNet-sovellusten tarvitsemia toimintoja. Nämä toiminnot ovat luonteeltaan lähempänä käyttäjää kuin peruspalveluiden tuottamat palvelut. Erityispalveluita ovat muun muassa yksittäiset muunnosohjelmat ja transaktiopalvelut. Taulukossa 5-2 ovat nähtävissä sisällönhallintaytimen erityispalvelut. Taulukko 5-1 Peruspalvelut Palvelu Kuvaus ServiceManager Palveluiden hallinta yksittäisellä palvelimella tapahtuu tämän palvelun avulla. Locator Locatorin avulla voidaan hakea viitteitä muihin palveluihin. Mailer SMTP-palvelu, jonka avulla sisällönhallintaydin voi lähettää sähköpostia. DBC Tietokantapalvelu, jonka avulla voidaan käyttää tietokantaa SQL:llä. UserManager Käyttäjien hallinta järjestelmässä. FileManager Tiedostopalvelu, jolla hallitaan sisällönhallintaytimen tiedostoja. Activator Locatorin apupalvelu, joka voi tarvittaessa käynnistää järjestelmän tarvitsemia palveluita. EventManager Mahdollistaa sen, että palvelut voivat lähettää toisilleen viestejä. Log Tämän avulla palvelut voivat kirjoittaa lokiin tietoja toiminnastaan. ProcessQueue Jonopalvelu, jonka avulla käsittelyä tarvitsevat sisällöt kirjataan jonoon. ErrorHandler Palvelut voivat ilmoittaa sattuneista virhetilanteista ErrorHandlerille.
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo
sonera_live_sisallonhallinta_diplomityo

Recommended

Presentación1
Presentación1Presentación1
Presentación1barcelona2014
 
Presentación1
Presentación1Presentación1
Presentación1Rodrigo Ortega Valvert
 
Geometry Theorem Review
Geometry Theorem ReviewGeometry Theorem Review
Geometry Theorem Reviewtcheng13
 
実験
実験実験
実験seasharker
 
Maths project brief jan 2015 project - statistics
Maths project brief jan 2015 project - statisticsMaths project brief jan 2015 project - statistics
Maths project brief jan 2015 project - statisticsJamie Lee
 
K10 (1)
K10 (1)K10 (1)
K10 (1)Wattana Sakornsathid
 
Equal access & response alt
Equal access & response altEqual access & response alt
Equal access & response altKarsh Hagan
 
Yamaha
YamahaYamaha
YamahaJeyson Zapata
 

Recommended

Presentación1
Presentación1Presentación1
Presentación1barcelona2014
 
Presentación1
Presentación1Presentación1
Presentación1Rodrigo Ortega Valvert
 
Geometry Theorem Review
Geometry Theorem ReviewGeometry Theorem Review
Geometry Theorem Reviewtcheng13
 
実験
実験実験
実験seasharker
 
Maths project brief jan 2015 project - statistics
Maths project brief jan 2015 project - statisticsMaths project brief jan 2015 project - statistics
Maths project brief jan 2015 project - statisticsJamie Lee
 
K10 (1)
K10 (1)K10 (1)
K10 (1)Wattana Sakornsathid
 
Equal access & response alt
Equal access & response altEqual access & response alt
Equal access & response altKarsh Hagan
 
Yamaha
YamahaYamaha
YamahaJeyson Zapata
 
Mitä ottaa huomioon modernin CMS:n hankinnassa
Mitä ottaa huomioon modernin CMS:n hankinnassaMitä ottaa huomioon modernin CMS:n hankinnassa
Mitä ottaa huomioon modernin CMS:n hankinnassaNorth Patrol
 
Atk-tuen synty ja toiminnan tavoitteet 5
Atk-tuen synty ja toiminnan tavoitteet 5Atk-tuen synty ja toiminnan tavoitteet 5
Atk-tuen synty ja toiminnan tavoitteet 5Kimmo Yli-Savola
 
Älykkäät koneet klusteriohjelma 2012-2013
Älykkäät koneet klusteriohjelma 2012-2013Älykkäät koneet klusteriohjelma 2012-2013
Älykkäät koneet klusteriohjelma 2012-2013Timo Rainio
 
ElTrio 08 Web
ElTrio 08 WebElTrio 08 Web
ElTrio 08 WebTimo Rainio
 
Fastemschallengegaala20022013 tiivistetty
Fastemschallengegaala20022013 tiivistettyFastemschallengegaala20022013 tiivistetty
Fastemschallengegaala20022013 tiivistettyTimo Rainio
 
Hermia&tampere&oske&alykone&oppminen&someteollisuudessa
Hermia&tampere&oske&alykone&oppminen&someteollisuudessaHermia&tampere&oske&alykone&oppminen&someteollisuudessa
Hermia&tampere&oske&alykone&oppminen&someteollisuudessaTimo Rainio
 
Elma eOppimissisältojen liiketoimintamallit
Elma eOppimissisältojen liiketoimintamallitElma eOppimissisältojen liiketoimintamallit
Elma eOppimissisältojen liiketoimintamallitAnne Rongas
 
Digitaalista Sykettä teollisuuteen
Digitaalista Sykettä teollisuuteenDigitaalista Sykettä teollisuuteen
Digitaalista Sykettä teollisuuteenTimo Rainio
 
Hermia, UT, Tampere - Tehokasta tuotekehitysta, uusia tapoja innovoida ja oppia
Hermia, UT, Tampere - Tehokasta tuotekehitysta, uusia tapoja innovoida ja oppiaHermia, UT, Tampere - Tehokasta tuotekehitysta, uusia tapoja innovoida ja oppia
Hermia, UT, Tampere - Tehokasta tuotekehitysta, uusia tapoja innovoida ja oppiaTimo Rainio
 
eOppiminen Teknologiateollisuudessa
eOppiminen TeknologiateollisuudessaeOppiminen Teknologiateollisuudessa
eOppiminen TeknologiateollisuudessaTimo Rainio
 
Verkon palvelut ja VR/360-sisällöt opetuksessa
Verkon palvelut ja VR/360-sisällöt opetuksessaVerkon palvelut ja VR/360-sisällöt opetuksessa
Verkon palvelut ja VR/360-sisällöt opetuksessaMatleena Laakso
 
Sosiaalinen media projektin ohjauksen apuvälineenä
Sosiaalinen media projektin ohjauksen apuvälineenäSosiaalinen media projektin ohjauksen apuvälineenä
Sosiaalinen media projektin ohjauksen apuvälineenäJari Jussila
 
Yrityksen ulkoisen toimintaympäristön analyysi
Yrityksen ulkoisen toimintaympäristön analyysiYrityksen ulkoisen toimintaympäristön analyysi
Yrityksen ulkoisen toimintaympäristön analyysiArho Suominen
 
eng_2015_marttinen_manu
eng_2015_marttinen_manueng_2015_marttinen_manu
eng_2015_marttinen_manuManu Marttinen
 
New biz4finland jukka ahtikari
New biz4finland jukka ahtikariNew biz4finland jukka ahtikari
New biz4finland jukka ahtikariApps4Finland
 
Open mind 2010_workshop_elias_aarnio
Open mind 2010_workshop_elias_aarnioOpen mind 2010_workshop_elias_aarnio
Open mind 2010_workshop_elias_aarnioeliasaarnio
 
Ilo t seminaari-0614 (6)
Ilo t seminaari-0614 (6)Ilo t seminaari-0614 (6)
Ilo t seminaari-0614 (6)Kimmo Haapea
 
IloT -seminaari 160614 ohjelma
IloT -seminaari 160614 ohjelmaIloT -seminaari 160614 ohjelma
IloT -seminaari 160614 ohjelmaKimmo Haapea
 
eduroam ennen, nyt ja tulevaisuudessa
eduroam ennen, nyt ja tulevaisuudessaeduroam ennen, nyt ja tulevaisuudessa
eduroam ennen, nyt ja tulevaisuudessaKarri Huhtanen
 
KPE Opetusteknologiapalkinto 2010 -esitys
KPE Opetusteknologiapalkinto 2010 -esitysKPE Opetusteknologiapalkinto 2010 -esitys
KPE Opetusteknologiapalkinto 2010 -esitysMinna Lakkala
 

More Related Content

Similar to sonera_live_sisallonhallinta_diplomityo

Mitä ottaa huomioon modernin CMS:n hankinnassa
Mitä ottaa huomioon modernin CMS:n hankinnassaMitä ottaa huomioon modernin CMS:n hankinnassa
Mitä ottaa huomioon modernin CMS:n hankinnassaNorth Patrol
 
Atk-tuen synty ja toiminnan tavoitteet 5
Atk-tuen synty ja toiminnan tavoitteet 5Atk-tuen synty ja toiminnan tavoitteet 5
Atk-tuen synty ja toiminnan tavoitteet 5Kimmo Yli-Savola
 
Älykkäät koneet klusteriohjelma 2012-2013
Älykkäät koneet klusteriohjelma 2012-2013Älykkäät koneet klusteriohjelma 2012-2013
Älykkäät koneet klusteriohjelma 2012-2013Timo Rainio
 
Fastemschallengegaala20022013 tiivistetty
Fastemschallengegaala20022013 tiivistettyFastemschallengegaala20022013 tiivistetty
Fastemschallengegaala20022013 tiivistettyTimo Rainio
 
Hermia&tampere&oske&alykone&oppminen&someteollisuudessa
Hermia&tampere&oske&alykone&oppminen&someteollisuudessaHermia&tampere&oske&alykone&oppminen&someteollisuudessa
Hermia&tampere&oske&alykone&oppminen&someteollisuudessaTimo Rainio
 
Elma eOppimissisältojen liiketoimintamallit
Elma eOppimissisältojen liiketoimintamallitElma eOppimissisältojen liiketoimintamallit
Elma eOppimissisältojen liiketoimintamallitAnne Rongas
 
Digitaalista Sykettä teollisuuteen
Digitaalista Sykettä teollisuuteenDigitaalista Sykettä teollisuuteen
Digitaalista Sykettä teollisuuteenTimo Rainio
 
Hermia, UT, Tampere - Tehokasta tuotekehitysta, uusia tapoja innovoida ja oppia
Hermia, UT, Tampere - Tehokasta tuotekehitysta, uusia tapoja innovoida ja oppiaHermia, UT, Tampere - Tehokasta tuotekehitysta, uusia tapoja innovoida ja oppia
Hermia, UT, Tampere - Tehokasta tuotekehitysta, uusia tapoja innovoida ja oppiaTimo Rainio
 
eOppiminen Teknologiateollisuudessa
eOppiminen TeknologiateollisuudessaeOppiminen Teknologiateollisuudessa
eOppiminen TeknologiateollisuudessaTimo Rainio
 
Verkon palvelut ja VR/360-sisällöt opetuksessa
Verkon palvelut ja VR/360-sisällöt opetuksessaVerkon palvelut ja VR/360-sisällöt opetuksessa
Verkon palvelut ja VR/360-sisällöt opetuksessaMatleena Laakso
 
Sosiaalinen media projektin ohjauksen apuvälineenä
Sosiaalinen media projektin ohjauksen apuvälineenäSosiaalinen media projektin ohjauksen apuvälineenä
Sosiaalinen media projektin ohjauksen apuvälineenäJari Jussila
 
Yrityksen ulkoisen toimintaympäristön analyysi
Yrityksen ulkoisen toimintaympäristön analyysiYrityksen ulkoisen toimintaympäristön analyysi
Yrityksen ulkoisen toimintaympäristön analyysiArho Suominen
 
eng_2015_marttinen_manu
eng_2015_marttinen_manueng_2015_marttinen_manu
eng_2015_marttinen_manuManu Marttinen
 
New biz4finland jukka ahtikari
New biz4finland jukka ahtikariNew biz4finland jukka ahtikari
New biz4finland jukka ahtikariApps4Finland
 
Open mind 2010_workshop_elias_aarnio
Open mind 2010_workshop_elias_aarnioOpen mind 2010_workshop_elias_aarnio
Open mind 2010_workshop_elias_aarnioeliasaarnio
 
Ilo t seminaari-0614 (6)
Ilo t seminaari-0614 (6)Ilo t seminaari-0614 (6)
Ilo t seminaari-0614 (6)Kimmo Haapea
 
IloT -seminaari 160614 ohjelma
IloT -seminaari 160614 ohjelmaIloT -seminaari 160614 ohjelma
IloT -seminaari 160614 ohjelmaKimmo Haapea
 
eduroam ennen, nyt ja tulevaisuudessa
eduroam ennen, nyt ja tulevaisuudessaeduroam ennen, nyt ja tulevaisuudessa
eduroam ennen, nyt ja tulevaisuudessaKarri Huhtanen
 
KPE Opetusteknologiapalkinto 2010 -esitys
KPE Opetusteknologiapalkinto 2010 -esitysKPE Opetusteknologiapalkinto 2010 -esitys
KPE Opetusteknologiapalkinto 2010 -esitysMinna Lakkala
 

Similar to sonera_live_sisallonhallinta_diplomityo (20)

Mitä ottaa huomioon modernin CMS:n hankinnassa
Mitä ottaa huomioon modernin CMS:n hankinnassaMitä ottaa huomioon modernin CMS:n hankinnassa
Mitä ottaa huomioon modernin CMS:n hankinnassa
 
Atk-tuen synty ja toiminnan tavoitteet 5
Atk-tuen synty ja toiminnan tavoitteet 5Atk-tuen synty ja toiminnan tavoitteet 5
Atk-tuen synty ja toiminnan tavoitteet 5
 
Älykkäät koneet klusteriohjelma 2012-2013
Älykkäät koneet klusteriohjelma 2012-2013Älykkäät koneet klusteriohjelma 2012-2013
Älykkäät koneet klusteriohjelma 2012-2013
 
ElTrio 08 Web
ElTrio 08 WebElTrio 08 Web
ElTrio 08 Web
 
Fastemschallengegaala20022013 tiivistetty
Fastemschallengegaala20022013 tiivistettyFastemschallengegaala20022013 tiivistetty
Fastemschallengegaala20022013 tiivistetty
 
Hermia&tampere&oske&alykone&oppminen&someteollisuudessa
Hermia&tampere&oske&alykone&oppminen&someteollisuudessaHermia&tampere&oske&alykone&oppminen&someteollisuudessa
Hermia&tampere&oske&alykone&oppminen&someteollisuudessa
 
Elma eOppimissisältojen liiketoimintamallit
Elma eOppimissisältojen liiketoimintamallitElma eOppimissisältojen liiketoimintamallit
Elma eOppimissisältojen liiketoimintamallit
 
Digitaalista Sykettä teollisuuteen
Digitaalista Sykettä teollisuuteenDigitaalista Sykettä teollisuuteen
Digitaalista Sykettä teollisuuteen
 
Hermia, UT, Tampere - Tehokasta tuotekehitysta, uusia tapoja innovoida ja oppia
Hermia, UT, Tampere - Tehokasta tuotekehitysta, uusia tapoja innovoida ja oppiaHermia, UT, Tampere - Tehokasta tuotekehitysta, uusia tapoja innovoida ja oppia
Hermia, UT, Tampere - Tehokasta tuotekehitysta, uusia tapoja innovoida ja oppia
 
eOppiminen Teknologiateollisuudessa
eOppiminen TeknologiateollisuudessaeOppiminen Teknologiateollisuudessa
eOppiminen Teknologiateollisuudessa
 
Verkon palvelut ja VR/360-sisällöt opetuksessa
Verkon palvelut ja VR/360-sisällöt opetuksessaVerkon palvelut ja VR/360-sisällöt opetuksessa
Verkon palvelut ja VR/360-sisällöt opetuksessa
 
Sosiaalinen media projektin ohjauksen apuvälineenä
Sosiaalinen media projektin ohjauksen apuvälineenäSosiaalinen media projektin ohjauksen apuvälineenä
Sosiaalinen media projektin ohjauksen apuvälineenä
 
Yrityksen ulkoisen toimintaympäristön analyysi
Yrityksen ulkoisen toimintaympäristön analyysiYrityksen ulkoisen toimintaympäristön analyysi
Yrityksen ulkoisen toimintaympäristön analyysi
 
eng_2015_marttinen_manu
eng_2015_marttinen_manueng_2015_marttinen_manu
eng_2015_marttinen_manu
 
New biz4finland jukka ahtikari
New biz4finland jukka ahtikariNew biz4finland jukka ahtikari
New biz4finland jukka ahtikari
 
Open mind 2010_workshop_elias_aarnio
Open mind 2010_workshop_elias_aarnioOpen mind 2010_workshop_elias_aarnio
Open mind 2010_workshop_elias_aarnio
 
Ilo t seminaari-0614 (6)
Ilo t seminaari-0614 (6)Ilo t seminaari-0614 (6)
Ilo t seminaari-0614 (6)
 
IloT -seminaari 160614 ohjelma
IloT -seminaari 160614 ohjelmaIloT -seminaari 160614 ohjelma
IloT -seminaari 160614 ohjelma
 
eduroam ennen, nyt ja tulevaisuudessa
eduroam ennen, nyt ja tulevaisuudessaeduroam ennen, nyt ja tulevaisuudessa
eduroam ennen, nyt ja tulevaisuudessa
 
KPE Opetusteknologiapalkinto 2010 -esitys
KPE Opetusteknologiapalkinto 2010 -esitysKPE Opetusteknologiapalkinto 2010 -esitys
KPE Opetusteknologiapalkinto 2010 -esitys
 

sonera_live_sisallonhallinta_diplomityo

  • 1. TAMPEREEN TEKNILLINEN KORKEAKOULU Tietotekniikan osasto TIMUR KÄRKI, ANTTI LEINONEN, TOMMI TARKIAINEN HAJAUTETTU SISÄLLÖNHALLINTAJÄRJESTELMÄ INTERNET-VERKOSSA Aihe hyväksytty osastoneuvoston kokouksessa 12.11.1997. Tarkastajat: professori Ilkka Haikala, Tampereen teknillinen korkeakoulu tekn.lis. Jukka Helin, Sonera Oy
  • 2. ii Alkulause Diplomityössä kuvattu sisällönhallintajärjestelmä toteutettiin ohjelmistoprojektina Soneran Medialaboratoriossa. Projekti alkoi kesäkuussa 1997. Haluamme kiittää laboratorion silloista johtajaa Arto Urataipaletta sekä nykyistä johtajaa Jukka Heliniä tuesta ja luottamuksesta projektia kohtaan. Loppuvuodesta 1997 sisällönhallintajärjestelmästä päätettiin tehdä tämä diplomityö. Diplomityön syntymiseen ovat vaikuttaneet useat henkilöt. Kiitokset kaikille niille, jotka lukivat tämän diplomityön ja antoivat arvokasta palautetta. Erityisesti haluamme kiittää työmme tarkastajia, professori Ilkka Haikalaa ja tekniikan lisensiaatti Jukka Heliniä. Tampereella 24.2.1999 Timur Kärki Pajakatu 11 as 5 33100 TAMPERE puh. 040-5369677 Antti Leinonen Arkkitehdinkatu 34 D 32 33720 TAMPERE puh. 040-5369688 Tommi Tarkiainen Opiskelijankatu 4 F 336 33720 TAMPERE puh. 040-5369686
  • 3. iii Tiivistelmä TAMPEREEN TEKNILLINEN KORKEAKOULU Tietotekniikan osasto, Ohjelmistotekniikka KÄRKI, TIMUR - LEINONEN, ANTTI - TARKIAINEN, TOMMI: HAJAUTETTU SISÄLLÖNHALLINTAJÄRJESTELMÄ INTERNET- VERKOSSA Diplomityö, 103 sivua, 5 liitesivua Tarkastajat: prof. Ilkka Haikala, tekn. lis. Jukka Helin Rahoittaja: Sonera Oy Maaliskuu 1999 Avainsanat: CORBA, hajautettu ohjelmisto, Internet, Java, multimedia, sisällönhallinta Soneran multimediapalvelun pilottivaihe käynnistettiin vuonna 1995. Palvelun tarkoituksena on helpottaa multimediamateriaalin jakelua Internetissä. Pilottivaiheesta saatujen kokemusten pohjalta käynnistettiin kesällä 1997 Soneran Medialaboratoriossa ohjelmistoprojekti, jonka tavoitteena oli luoda uusi järjestelmä, joka korjaisi vanhan järjestelmän ongelmat ja helpottaisi uusien palveluiden kehitystä. Projektin edetessä ohjelmisto muotoutui sisällönhallintajärjestelmäksi, joka esitellään tässä työssä. Sisällönhallintajärjestelmä on hajautettu ohjelmisto, joka koostuu sisällöntuottajan ja ylläpitäjän työkaluista sekä palvelinohjelmistosta. Ohjelmisto on toteutettu Javalla ja CORBAlla. Lisäksi järjestelmässä käytetään ulkopuolisten ohjelmatoimittajien ohjelmia, kuten RealNetworksin ja Xing Technologiesin striimaavia1 multimediapalvelimia. Sisällönhallintajärjestelmä on tällä hetkellä käytössä Tampere Media Cityssä (www.tmc.tampere.fi), joka on ensimmäinen järjestelmän avulla rakennettu sovellus. Järjestelmä otetaan käyttöön myös muissa Soneran Internet-multimediapalveluissa. 1 Engl. termille streaming ei ole olemassa vakiintunutta suomennosta. Tässä työssä käytetään koeluontoisesti suomennosta "striimaus".
  • 4. iv Abstract TAMPERE UNIVERSITY OF TECHNOLOGY Department of Information Technology, Software Systems Laboratory KÄRKI, TIMUR - LEINONEN, ANTTI - TARKIAINEN, TOMMI: DISTRIBUTED CONTENT MANAGEMENT SYSTEM IN THE INTERNET Master of Science Thesis, 103 pages, 5 enclosure pages Supervisors: Prof. Ilkka Haikala and Tech. Lic. Jukka Helin Funding: Sonera Ltd March 1999 Keywords: content management, CORBA, distributed computing, Internet, Java, multimedia, streaming Sonera Ltd started a multimedia pilot service in 1995. The purpose of this pilot was to make it easier for the content providers to use streaming multimedia on the Internet. Based on the experiences of the pilot it was decided that a new system was needed to better address the needs of the content providers. In the summer of 1997 Sonera Medialab started a software project the goal of which was to create a new system that would not have the shortcomings of the old service and would enable Sonera to create new kind of multimedia services. This thesis describes the content management system which is the result of the project. The content management system is a distributed system that consists of three parts. These parts are content provider tools, administrator tools and server software. The system was developed using Java and CORBA. The system also makes extensive use of 3rd party software e.g. RealNetworks and Xing Technologies streaming media servers. The content management system is currently being used in Tampere Media City (www.tmc.tampere.fi), which is the first application built on top of this system. The content management system will also be used in other Sonera’s Internet multimedia services.
  • 5. v Sisällysluettelo Alkulause .............................................................................................................................ii Tiivistelmä ..........................................................................................................................iii Abstract ..............................................................................................................................iv Sisällysluettelo.....................................................................................................................v Termejä.............................................................................................................................viii Lyhenteitä............................................................................................................................x 1 Johdanto........................................................................................................................1 2 Sonera MediaNet -tuotteet ..........................................................................................3 2.1 SISÄLTÖPALVELUT INTERNETISSÄ................................................................................3 2.2 MULTIMEDIA INTERNETISSÄ ........................................................................................5 2.3 SONERA MEDIANET -TUOTERYHMÄ.............................................................................7 3 Toisen sukupolven MediaNet....................................................................................10 3.1 YLEISKÄYTTÖINEN ALUSTA........................................................................................10 3.2 SISÄLLÖNHALLINTAJÄRJESTELMÄN LIITTYMINEN YMPÄRISTÖÖNSÄ ..........................11 3.3 TOIMINNALLISET TAVOITTEET....................................................................................12 3.3.1 Helppokäyttöisyys ...............................................................................................12 3.3.2 Materiaalin jakelu...............................................................................................14 3.3.3 Loppukäyttäjäryhmät ..........................................................................................14 3.3.4 Raportointi ja laskutus........................................................................................15 3.3.5 Tietojen säilytys...................................................................................................15 3.4 TEKNISET TAVOITTEET ...............................................................................................16 3.4.1 Ympäristöriippumattomuus.................................................................................16 3.4.2 Hajautettavuus ja skaalautuvuus ........................................................................17 3.4.3 Toimintavarmuus ja turvallisuus ........................................................................19 3.4.4 Ylläpidettävyys ja käytettävyys............................................................................21 3.4.5 Versionhallinta....................................................................................................21 4 Toteutusteknologiat ...................................................................................................23 4.1 HAJAUTUS ..................................................................................................................23 4.1.1 Remote Method Invocation .................................................................................24
  • 6. Sisällysluettelo vi 4.1.2 Common Object Request Broker Architecture....................................................24 4.1.3 Distributed Component Object Model ................................................................28 4.1.4 Menetelmän valinta.............................................................................................28 4.2 OHJELMOINTIKIELI .....................................................................................................30 4.3 KÄYTTÖLIITTYMÄT ....................................................................................................31 4.3.1 Ympäristöriippumattomuuden toteutustavat.......................................................31 4.3.2 Javan käyttöliittymäkirjastot...............................................................................32 4.3.3 Yhteenveto ja kirjastojen tulevaisuus..................................................................37 4.4 MUUT VALITUT TEKNOLOGIAT ...................................................................................38 5 Sisällönhallintaydin....................................................................................................40 5.1 RAKENNE ...................................................................................................................41 5.1.1 Palvelut ...............................................................................................................42 5.1.2 Palvelu-sovelluskehys .........................................................................................47 5.1.3 Palvelin ...............................................................................................................49 5.2 TOIMINNOT.................................................................................................................51 5.2.1 Tiedostojen käsittely............................................................................................51 5.2.2 Käyttäjien hallinta ..............................................................................................53 5.2.3 Töiden hallinta....................................................................................................56 5.2.4 Live-Update.........................................................................................................63 5.2.5 Sisältöjen hallinta ...............................................................................................65 5.3 SISÄLTÖPALVELIMET..................................................................................................67 5.3.1 Sisältöpalvelimen rakenne ..................................................................................67 5.3.2 Sisältöpalvelinten hallinta ..................................................................................68 5.3.3 Yksittäisiä tiedostoja jakavat sisältöpalvelimet ..................................................69 5.3.4 Striimattavien materiaalien sisältöpalvelimet ....................................................69 5.3.5 TMC-sisältöpalvelin............................................................................................70 5.3.6 Ryhmäsisältöpalvelin ..........................................................................................71 6 Käyttöliittymät ...........................................................................................................72 6.1 ASIAKASOHJELMA......................................................................................................72 6.2 YLLÄPITO-OHJELMA...................................................................................................76 6.2.1 Rakenne...............................................................................................................76 6.2.2 Käyttöliittymä......................................................................................................78
  • 7. Sisällysluettelo vii 6.2.3 ServerManagerAgent ..........................................................................................79 6.2.4 ServerConfigAgent..............................................................................................80 6.2.5 PropertyEditorAgent...........................................................................................81 6.2.6 QueueManagerAgent ..........................................................................................81 7 Sisällönhallintajärjestelmä ja Sonera MediaNet -sovellukset................................82 7.1 SISÄLLÖNHALLINTAYDIN TUOTANTOKÄYTÖSSÄ ........................................................82 7.1.1 On-Demand.........................................................................................................84 7.1.2 Live......................................................................................................................86 7.1.3 TMC ....................................................................................................................86 7.2 ASIAKASOHJELMA......................................................................................................87 7.2.1 On-Demand.........................................................................................................88 7.2.2 Live......................................................................................................................92 7.2.3 Tampere Media City............................................................................................93 8 Sisällönhallintajärjestelmän jatkokehitys................................................................97 8.1 JÄRJESTELMÄN RAKENTEEN JA PALVELUIDEN JATKOKEHITYS....................................97 8.2 MEDIANET-SOVELLUSTEN JATKOKEHITYS .................................................................99 9 Yhteenveto ................................................................................................................101 Lähdeluettelo...................................................................................................................104 Liite I - Portaalit .............................................................................................................106 Liite II - Käyttöliittymäesimerkit..................................................................................108
  • 8. viii Termejä Asiakasohjelma Sisällöntuottajan työkalu, jolla käytetään sisällönhallintaytimen toimintoja. Enkooderi Laite tai ohjelma, joka muuntaa lähdemateriaalin muotoon, josta se voidaan palauttaa alkuperäisen kaltaiseksi. (engl. encoder) Erityispalvelu Sisällönhallintaytimen palvelu, joka suorittaa MediaNet- sovelluskohtaisia toimintoja. Liityntäpalvelu Liityntäpalvelut toimivat sisällönhallintaytimen rajapintana ulkopuolisiin ohjelmiin. Liityntäpalvelut ovat erityispalveluita. Loppukäyttäjä Selailee ja katselee sisältöjä loppukäyttäjäohjelman avulla. Loppukäyttäjäohjelma Sisällön katsomiseen tarkoitettu ohjelma. Tällaisia ohjelmia ovat mm. selaimet sekä erilaiset mediasoittimet. MediaNet-sovellus MediaNet-tuote, joka on toteutettu sisällönhallintajärjestelmän avulla. MediaNet-tuote MediaNet-tuoteperheen jäsen. Soneran medialaboratoriossa kehitetty palvelukonsepti. Medianimike Medianimike koostuu yhdestä tai useammasta mediatiedostosta. Mediasoitin Multimediamateriaalin toisto-ohjelma. (engl. media player) Mediatiedosto Medianimikkeeseen liittyvä yksittäinen fyysinen tiedosto. Muunnosohjelma Ohjelma, joka muuntaa materiaalin muodosta toiseen. (engl. converter) Muuntaminen Materiaalin muuntaminen muodosta toiseen. Muuntamiseen liittyy usein materiaalin pakkaaminen. (engl. convert) Palvelu Sisällönhallintaytimeen kuuluva ohjelma, joka toteuttaa TFService-rajapinnan.
  • 9. Termejä ix Peruspalvelu Sisällönhallintaytimen palvelu, joka on tarkoitettu muiden sisällönhallintaytimen palveluiden käyttöön. Peruspalveluita ei voi käyttää sisällönhallintaytimen ulkopuolisista ohjelmista. Serialisointi Javan toiminto, jonka avulla olioiden sisältämät tiedot voidaan muuttaa tietovirraksi ja tietovirrasta takaisin olioksi. (engl. serialize) Sisällönhallintajärjestelmä Asiakasohjelman, ylläpito-ohjelman ja sisällönhallintaytimen muodostama kokonaisuus. Sisällönhallintaydin Sisällönhallintaydin sisältää sisällönhallintajärjestelmän palvelut, tiedonhallinnan ja sisältöpalvelimet. Sisällöntuottaja MediaNet-tuotteen asiakas, joka välittää sisällönhallintajärjestelmän avulla sisältöä loppukäyttäjälle. Sisältö Sisältöpalvelimella sijaitseva materiaali, joka on loppukäyttäjän katsottavissa. Sisältöpalvelin Sisällönhallintaytimeen liitetty palvelin, jonka tehtävänä on varastoida ja jakaa sisältöä. Sovelluskehys Osittain toteutettu järjestelmäarkkitehtuuri, johon voidaan liittää uusia toimintoja. (engl. framework) Striimata Materiaalin välittäminen tietoverkon avulla siten, että materiaalia voidaan käyttää sitä mukaa, kun se siirtyy loppukäyttäjän tietokoneelle. (engl. streaming) Ylläpito-ohjelma Ylläpito-ohjelman avulla ylläpitäjä voi hallita ja valvoa sisällönhallintaytimen toimintaa.
  • 10. x Lyhenteitä ACL Access Control List AFC Application Foundation Classes API Application Programming Interface AWT Abstract Windowing Toolkit CGI Common Gateway Interface CORBA Common Object Request Broker Architecture CUG Closed User Group DCOM Distributed Component Object Model FIFO First-In-First-Out FTP File Transfer Protocol HTML HyperText Markup Language HTTP HyperText Transfer Protocol IDL Interface Definition Language IFC Internet Foundation Classes IIOP Internet Inter-ORB Protocol IOR Interoperable Object Reference IP Internet Protocol ISP Internet Service Provider JAR Java Archive JDBC Java Database Connectivity JDK Java Development Kit JFC Java Foundation Classes OMA Object Management Architecture OMG Object Management Group ORB Object Request Broker OSP Online Service Provider RMI Remote Method Invocation SMTP Simple Mail Transfer Protocol SQL Standard Query Language
  • 11. Lyhenteitä xi SSL Secure Socket Layer TMC Tampere Media City URL Uniform Resource Locator WWW World Wide Web
  • 12. 1 1 Johdanto Loppuvuodesta 1995 Soneran Medialaboratorio aloitti MediaNet1 -kokeilun, jonka tavoitteena oli luoda multimedian jakelujärjestelmä Internetiin. Sisällöntuottajille tarjottiin ohjelmistot, joiden avulla voitiin siirtää digitoitua mediamateriaalia Soneran palvelimelle. Palvelimella materiaali muunnettiin sopivaan muotoon ja asetettiin loppukäyttäjän saataville. Kokeilua käynnistettäessä tavoitteena oli löytää uusia käyttötarkoituksia Soneran tietoverkoille ja saada tietoa multimedian levittämisen teknisistä vaatimuksista. Haluttiin myös saada tietoa siitä, kuinka sisällöntuottajat ja loppukäyttäjät suhtautuvat näihin uusiin teknologioihin. Sonera toteutti tällaisen palvelun ensimmäisenä maailmassa ja saavutti paljon mainetta. Soneraa kehuttiin nopeasta teknologioiden omaksumiskyvystä, ja MediaNet sai vuonna 1996 Data Communications International -lehden arvostetun Hot Products -palkinnon. Kokeilussa luotu palvelu kaupallistettiin keväällä 1997. Kesäkuussa 1997 todettiin, että puolitoista vuotta aikaisemmin luotu järjestelmä oli hankala ylläpitää ja laajentaa. Päätettiin tehdä järjestelmä kokonaan uudelleen, painottaen ohjelmistoteknisiä ratkaisuja. 1 MediaNet on Soneran käytössä ollut tuotenimi, jonka Helsinki Media on sittemmin rekisteröinyt itselleen. Tekstissä käytetään vanhaa MediaNet-nimeä, koska uusi tuotenimi ei ollut työtä kirjoitettaessa vielä selvillä.
  • 13. 1 Johdanto 2 Haluttiin saada järjestelmä, joka olisi helposti laajennettavissa ja soveltuisi monenlaisen materiaalin levittämiseen. Järjestelmän tuli myös mukautua erilaisiin ympäristöihin ja tehovaatimuksiin. Alkoi kolmen hengen ohjelmistoprojekti, jonka toteutukseen Medialaboratorio antoi varsin vapaat kädet. Työ alkoi uuden järjestelmän tarpeiden selvittämisellä ja ominaisuuksien määrittelemisellä. Tärkeä osa työtä oli selvittää eri ohjelmistotekniset toteutusvaihtoehdot. Näiden vaiheiden jälkeen syksyllä 1997 alkoi toteutus. Loppuvuodesta 1997 päätimme kirjoittaa diplomityömme tästä varsin laajaksi kasvaneesta ohjelmistoprojektista. Työn aiheena olevaa ohjelmistokokonaisuuden osaa ryhdyttiin kutsumaan sisällönhallintajärjestelmäksi. Diplomityön luvussa 2 luodaan pikainen katsaus multimedian käyttöön Internet- tietoverkossa ja esitellään lyhyesti MediaNet-tuotteita. Luvun tarkoituksena on perehdyttää lukija ympäristöön, jossa sisällönhallintajärjestelmää tullaan käyttämään. Luvussa 3 esitellään sisällönhallintajärjestelmä siihen kohdistuvien tarpeiden ja vaatimusten muodossa. Luvussa 4 käsitellään vaihtoehtoisia menetelmiä sisällönhallintajärjestelmän totettamiseksi. Tässä luvussa käydään läpi lyhyesti järjestelmän hajautuksessa käytetyt työkalut ja menetelmät. Lisäksi käsitellään järjestelmän käyttöliittymien toteutuksessa käytettyjä välineitä. Luvussa 5 esitellään toteutetun sisällönhallintajärjestelmän rakenne ja toiminnot. Rakenteen kuvauksessa esitetään toteutukseen vaikuttaneet keskeiset suunnitteluperiaatteet. Tässä luvussa esitellään myös muita teknologiaratkaisuja. Luvussa 6 esitellään järjestelmään liittyviä käyttöliittymiä. Luvussa 7 kuvataan kuinka sisällönhallintajärjestelmää hyödynnetään MediaNet-tuotteissa. Lopuksi luvussa 8 arvioidaan järjestelmän jatkokehitystarpeita ja -mahdollisuuksia.
  • 14. 3 2 Sonera MediaNet -tuotteet Internetin käyttäjämäärät jatkavat edelleen kasvuaan. Loka-marraskuussa vuonna 1998 540 000 suomalaista käytti Internetiä päivittäin. Vuotta aikaisemmin vastaava luku oli 313 000. Mahdollisia käyttäjiä onnistuneelle sisältöpalvelulle tulee siis koko ajan lisää. [Ta99a] 2.1 Sisältöpalvelut Internetissä Useat Internet-yhteyden tarjoajat eli ISP:t (Internet Service Provider) haluavat nykyään tarjota asiakkaalle kokonaisvaltaista palvelua. Internet-yhteyden ja sen peruspalveluiden lisäksi tarvitaan lisäarvopalveluita. Tällaisia palveluita voivat olla esimerkiksi erilaiset uutispalvelut, hakemistopalvelut, keskustelupalstat, virtuaaliset yhteisöt ja multimediapalvelut. Tarkoitus on, että käyttäjät eivät samoilisi satunnaisesti Internetissä, vaan mahdollisimman moni käyttäisi juuri tämän ISP:n tuottamia, ylläpitämiä tai valitsemia palveluita. ISP-käsitteen rinnalle on noussut OSP (Online Service Provider), joka pitää sisällään niin perinteisen ISP-toiminnan, kuin myös sisältöpalveluiden tarjoamisen. Tarjoamalla houkuttelevia palveluita ja laadukasta sisältöä saadaan palveluille käyttäjiä. Käyttäjien määrä taas innostaa mainostajia ostamaan mainospaikkoja palveluista. Näin saadaan taloudelliset edellytykset luoda yhä parempia palveluita ja ostaa yhä laadukkaampaa ja kattavampaa sisältöä.
  • 15. 2 Sonera MediaNet -tuotteet 4 OSP:n koostama sisältö ei välttämättä ole tarjolla ainoastaan kyseisen OSP:n kautta Internetiin yhteydessä oleville, vaan myös muille Internetin käyttäjille. Tällöin mahdollinen yleisö sisällölle on huomattavasti suurempi. Tavoitteena on, että käyttäjät aloittaisivat WWW-selailunsa juuri kyseisen OSP:n koostamista sivuista. Tällaista WWW-kokonaisuutta, josta käyttäjä aloittaa selailun ja jonne hän palaa aina uudelleen kutsutaan portaaliksi (engl. portal). Sisältö portaaliin hankitaan yleensä muualta. Tyypillisesti portaaleissa on jäsenneltynä tietoa tekstilinkeillä aihealueittain. Tällaisesta hyvä esimerkki on America Onlinen (www.aol.com) etusivu, josta löytyy kuva liitteestä I. Lisäksi tarjolla on ajankohtaista tietoa kuten uutisia, säätiedotuksia ja pörssikursseja. Portaaleissa on usein myös muita sovelluksia, kuten WWW-pohjainen sähköposti, kauppapaikka, keskustelupalstoja, ilmoitustauluja ja yhteisöjä. Sisältöpalveluiden käyttäjiltä voidaan vaatia rekisteröitymistä, jolloin käyttäjien seuranta on varsin helppoa. Näin saadaan tarkat tilastot siitä millaiset käyttäjät käyttävät mitäkin palvelua. Tämä on mainostajien kannalta mielenkiintoista tietoa, koska mainosten kohdentaminen oikeille ihmisille on täten varsin helppoa. Myös palveluita voidaan muokata asiakaskohtaisesti rekisterin perusteella. Käyttäjälle tarjotaan usein mahdollisuus muokata aloitussivua. Sivulle voidaan valita esimerkiksi pörssikursseja, tietyn kaupungin säätiedotus tai vaikka tietyn uutistoimiston uutisia. Eräs tällainen on Exciten (www.excite.com) asiakaskohtainen aloitussivu, josta on kuva liitteessä I. Tulevaisuudessa yhä useammat käyttäjät omistavat nopean Internet-yhteyden, ja niinpä multimedian välittämisen tekniset vaikeudet helpottuvat. Tammikuussa 1999 muutamat suuret yhdysvaltalaiset portaalit ilmoittivat julkaisevansa oman version nopeille yhteyksille [Ka99]. Nopeat yhteydet mahdollistavat huomattavasti monimuotoisemman sisällön tarjoamisen.
  • 16. 2 Sonera MediaNet -tuotteet 5 Sonera on Suomen johtava Internet-yhteyksien tarjoaja. Soneran iNET Keskuskatu (www.inet.fi) on Suomen suosituin WWW-palvelu [Ta99b]. Johtavan aseman säilyminen ei kuitenkaan ole selviö, vaan asiakkaille tarjottavia palveluja ja sisältöä on jatkuvasti parannettava. 2.2 Multimedia Internetissä Multimedian välittäminen Internetissä voidaan katsoa tietokone-, tietoliikenne- ja medialiiketoiminnan yhdistelmäksi. Multimedian välittäminen verkossa vaatii kaikkien näiden osa-alueiden yhteistyötä. Tämä yhdistelmä on mielenkiintoinen, sillä tällä uudella liiketoiminnalla on mahdollisuus olla varsin merkittävä taloudellisesti. Tätä asiaa on havainnollistettu kuvassa 2-1. [He98] Multimedian välittäminen Internetissä on hankalaa, sillä multimediaa sisältävät tiedostot ovat isoja. Tämä aiheuttaa muutamia teknisiä vaatimuksia. Multimediamateriaali tulee muuntaa sellaiseen muotoon, että se pystytään välittämään käytössä olevan verkkokapasiteetin puitteissa parhaalla mahdollisella laadulla. Loppukäyttäjällä on Kuva 2-1 Tietoliikennetoiminnan siirtyminen kohden multimediaa luo liiketoiminnalle lisäarvoa [He98]. Tietokone 13 miljardia mk 1996 Media 16 miljardia mk 1996 Multimedia Tietoliikenne 10 miljardia mk 1996
  • 17. 2 Sonera MediaNet -tuotteet 6 mahdollisesti käytössään hidas modeemiyhteys tai hänellä voi olla käytössään nopea lähiverkko. Samaa sisältöä pitäisi pystyä katsomaan yhteyden nopeudesta riippumatta. Tähän kehitetään jatkuvasti uusia pakkausmenetelmiä, joiden oikea valinta vaatii asiantuntemusta. Multimediamateriaalin tulee myös sijaita sellaisella palvelimella, jonka resurssit kykenevät palvelemaan lukuisia yhtäaikaisia käyttäjiä. Samoin palvelimen tulisi olla ympäri vuorokauden käytettävissä. Multimediamateriaali vaatii myös paljon tallennuskapasiteettia. Multimediaa välitetään Internetissä kahdella toisistaan selvästi poikkeavalla tavalla. Perinteinen tapa on siirtää multimediaa sisältävä tiedosto kokonaisuudessaan ensin palvelimelta loppukäyttäjän tietokoneen kovalevylle. Tämän jälkeen tiedosto voidaan soittaa mediasoittimella. Toinen tapa on käyttää striimaavaa tekniikkaa. Tämä tarkoittaa sitä, että multimediamateriaali soitetaan mediasoittimella sitä mukaa kun se siirtyy palvelimelta. Striimauksesta on se hyöty, että soittaminen voidaan aloittaa välittömästi loppukäyttäjän esitettyä pyynnön palvelimelle. Haittapuolena on se, että varsinkin modeemiyhteyksillä multimediamateriaalin toiston taso laskee melko alhaiseksi, koska toistossa voidaan käyttää vain yhteyden sallimia bittinopeuksia. Ei-striimaavaa teknologiaa käytettäessä soiton alkamiseen tulee viive materiaalin siirtyessä kovalevylle. Tätä teknologiaa kannattaa kuitenkin käyttää, mikäli laatu on ehdottoman tärkeää, tai tilanteessa, jossa käyttäjällä on nopea, mutta aikaperusteisesti laskutettu yhteys. Multimediamateriaalista syntyy kopio loppukäyttäjän kovalevylle. Niinpä käyttäjä voi halutessaan katsella ja kuunnella materiaalia useaan kertaan. Ei- striimaavaa teknologiaa käytettäessä tekijänoikeuskysymykset ovat hankalampia kuin striimauksessa.
  • 18. 2 Sonera MediaNet -tuotteet 7 2.3 Sonera MediaNet -tuoteryhmä Sonera MediaNet -tuoteryhmän tuotteet on suunnattu sisällöntuottajille. Ne mahdollistavat multimediasisällön hallinnan, muokkaamisen, jakelun ja käyttötilastoinnin Internetissä. Sisällöntuottajat voivat tarjota sekä tallenteita että reaaliaikaisia tapahtumia. Mahdollisia loppukäyttäjiä ovat kaikki Internetin käyttäjät. Tuotteita tällä hetkellä ovat Sonera MediaNet On-Demand ja Sonera MediaNet Live. Pilottivaiheessa ovat Tampere Media City, Sonera MediaNet Community ja Sonera Voice Hotel. Sonera MediaNet On-Demand Sonera MediaNet On-Demand helpottaa multimediatallenteiden levittämistä tietoverkossa. Kuvassa 2-2 on esitetty sisällöntuottajan ja loppukäyttäjän roolit palvelussa. Sisällöntuottaja toimittaa materiaalin Soneran mediatuotantoon joko analogisessa muodossa tai valmiiksi digitoituna verkon välityksellä suoraan MediaNet-järjestelmään. MediaNet-palvelimella lähdemateriaali muunnetaan sopivaan muotoon ja siirretään sisältöpalvelimelle, josta loppukäyttäjä katsoo sitä loppukäyttäjäohjelman avulla. MediaNet-järjestelmä tarjoaa sisällöntuottajalle työkalut materiaalin siirtämiseen järjestelmään ja jo järjestelmässä olevan materiaalin seurantaan ja hallintaan. Sisällöntuottajan näkökulmasta digitoitu lähdemateriaali muuntuu MediaNet- järjestelmässä muutamaksi URL-osoitteeksi, joista materiaali on katsottavissa. Tämän jälkeen sisällöntuottaja voi sisällyttää linkin omille HTML-sivuillensa. Loppukäyttäjä ei välttämättä havaitse ollenkaan, että materiaali tuleekin MediaNet-sisältöpalvelimelta. Tätä ominaisuutta kutsutaan palvelun läpinäkyvyydeksi. Sisällöntuottaja saa myös käyttöönsä tilastoja katsotusta materiaalista. On-Demand -palvelun hyöty sisällöntuottajalle on se, että sisällöntuottajan ei itse tarvitse hankkia ohjelmistoja, joilla materiaali muunnetaan sopivaan muotoon. Sisällöntuottajalla ei tarvitse olla myöskään tietämystä siitä, mihin muotoon materiaali kannattaa muuntaa.
  • 19. 2 Sonera MediaNet -tuotteet 8 Valmis materiaali sijaitsee suorituskykyisellä palvelimella, jolta on riittävä tietoliikenneyhteys Internetiin. Näin mediamateriaali siirtyy loppukäyttäjälle mahdollisimman nopeasti kaikkina vuorokaudenaikoina. Sonera MediaNet Live Sonera MediaNet Live -palvelun avulla voidaan audio- ja videomateriaalia toimittaa reaaliaikaisesti Internetiin. Sovelluskohteet jakautuvat kahteen luokkaan, jatkuvat lähetykset sekä tapahtumat. Jatkuvat lähetykset soveltuvat esimerkiksi radio- ja TV- kanaville. Tapahtuma voi taas olla vaikkapa konsertti tai lehdistötilaisuus. Sisällöntuottaja saa URL-osoitteen, josta lähetystä voi seurata. Loppukäyttäjän kannalta Live-lähetyksen seuraaminen on täysin samanlaista kuin On-Demand -sisällön katsominen. Tampere Media City ja MediaNet Community Tampere Media City (TMC) on digitaalinen yhteisö, joka esittelee Pirkanmaan alueen digitaalisen median osaajia Internetissä. Yhteisön jäsenet luovat palveluun kuuluvalla asiakasohjelmalla itselleen WWW-sivuston. Luoduista sivustoista muodostuu yhtenäinen Kuva 2-2 On-Demand -tuote yksinkertaistettuna. Sisällöntuottaja - Yritys -Yhteisö - Yksityinen henkilö Loppukäyttäjä - Internetin käyttäjä Käyttäjäpalaute Pyyntö MediaNet- palvelimet Käyttötilastot Hyperlinkit Käsittelemätön sisältö Käsitelty sisältö
  • 20. 2 Sonera MediaNet -tuotteet 9 kokonaisuus, joka löytyy yhdestä osoitteesta. Näin yrityksillä ja oppilaitoksilla on mahdollisuus markkinoida tuotteitaan ja osaamistaan. TMC:n tarkoitus on luoda kaupallisia yhteyksiä myös ulkomaisten sidosryhmien ja pirkanmaalaisten digitaalista mediaa tuottavien yritysten sekä yhteisöjen välille. Teknisessä toteutuksessa on yritetty saada järjestelmä mahdollisimman helppokäyttöiseksi. Asiakasohjelmalla luodaan rakenteinen dokumentti, johon valitaan erikseen jokin taittomalleista. Näin siis sivuston asiasisältö ja ulkoasu on erotettu toisistaan. Sivustot voivat sisältää tekstiä, kuvaa, ääntä ja videota. TMC on rakennettu sisällönhallintajärjestelmän päälle. TMC-palvelun koordinaattori on Tampereen seudun osaamiskeskus ja tekninen toteuttaja Sonera Oy. Osa toteutuksesta teetettiin alihankintana Mediayhtiö Sansibar Oy:ssä. Tampere Media Cityä luotaessa syntyi myös runko yleiselle digitaalisen yhteisön palvelukonseptille, jota kutsutaan MediaNet Communityksi. Ideana on tehdä tuote, jonka avulla uuden digitaalisen yhteisön perustaminen olisi mahdollisimman helppoa. MediaNet Communityn toiminta on esitetty kuvassa 2-3. Kuva 2-3 Community-tuote yksinkertaistettuna. Sisällöntuottaja - Yhteisön jäsen Loppukäyttäjä - Internetin käyttäjä Käyttäjäpalaute Pyyntö MediaNet- palvelimet Käyttötilastot - Teksti - Kuvat - Audio - Video Generoidut WWW-sivut
  • 21. 10 3 Toisen sukupolven MediaNet Ensimmäinen MediaNet-toteutus syntyi vähitellen tutkimustyön ja pilottivaiheen kautta kaupalliseksi tuotteeksi. Ohjelmakokonaisuus koostui monista eri aikoina tehdyistä ohjelman osista. Syntymistavasta johtuen ohjelmiston ylläpidettävyys ja laajennettavuus olivat huonoja. Järjestelmä oli myös liian sidottu tietyntyyppisen multimediamateriaalin käsittelyyn. Laitteistojen ja ulkopuolisten ohjelmistojen kehittyessä oli tullut mahdolliseksi käsitellä monimuotoisempia materiaalikokonaisuuksia, mitä mahdollisuutta haluttiin hyödyntää. Sisällöistä ei myöskään ollut olemassa keskitettyä tietokantaa, vaan jokaisen medianimikkeen ominaisuuksia ja sisältöä kuvaavat lisätiedot olivat omassa ASCII-tiedostossaan. Tämä tiedosto sijaitsi järjestelmän WWW-palvelimella. Edellä mainittujen puutteellisuuksien ja tarpeiden seurauksena alettiin suunnitella toisen sukupolven MediaNet-järjestelmää. 3.1 Yleiskäyttöinen alusta MediaNet-tuoteperheen tuotteet liittyvät siis yleensä tavalla tai toisella multimedian jakeluun Internetissä. Niinpä oleellinen osa niitä on mediamateriaalia hoitava järjestelmä. Toisen sukupolven MediaNetin toteutus päätettiinkin aloittaa järjestelmästä, joka huolehtii mediamateriaalin hallinnasta. Toteutettava järjestelmä nimettiin sisällönhallintajärjestelmäksi. Jo projektin alkuvaiheessa oli nähtävissä, että sisällönhallinnan tarpeet tulevat kasvamaan ajan kuluessa. Uusia ideoita, vaatimuksia ja toiveita tuli esiin tasaisin väliajoin. Tästä syystä erääksi keskeisistä tavoitteista nousi modulaarisuus. Ideana oli pyrkiä erottamaan
  • 22. 3 Toisen sukupolven MediaNet 11 yleisesti sisällönhallintaan liittyvät tarpeet ja toisaalta haluttavat tuotteet toisistaan. Näin uudet tuotteet voidaan tulevaisuudessa rakentaa olemassa olevan perustan päälle. Perustaan tulevaisuudessa mahdollisesti vaadittavat muutokset yritettiin pitää mahdollisimman vähäisinä. Myös syntyvät tuotteet pyrittiin rakentamaan niin, että niitä voidaan tarvittaessa käyttää perustana korkeammille tasoille. Tässä vaiheessa päädyttiin kuvan 3-1 mukaiseen järjestelyyn. Siinä on esitetty tuotteiden ja sisällönhallintajärjestelmän suhde. Alimmalla tasolla on itse sisällönhallintajärjestelmä, joka toteutetaan siten, että se voidaan jakaa selkeisiin osiin. Näitä osia sopivasti yhdistelemällä voidaan rakentaa erilaisia sovelluksia. Kuvassa 3-1 näkyvät tällä hetkellä sisällönhallintajärjestelmän avulla toteutetut tuotteet. Näistä MediaNet On-Demand, Live ja Community on toteutettu suoraan sisällönhallintajärjestelmän päälle. Sen sijaan TMC noudattaa edellä mainittua tuotteen päälle rakennettua tuotetta eli se siis pohjautuu MediaNet Communityyn. 3.2 Sisällönhallintajärjestelmän liittyminen ympäristöönsä MediaNetin välityksellä tapahtuvassa multimedian jakelussa on osallisena kolme osapuolta, sisällöntuottaja, ylläpitäjä ja loppukäyttäjä (kuva 3-2). Sisällönhallintajärjestelmä tarjoaa sisällöntuottajalle työkalun, jolla hän voi hallita omia Kuva 3-1 Tuotteiden liittyminen sisällönhallintajärjestelmään. Community On-Demand Live ... TMC Sisällönhallintajärjestelmä ...
  • 23. 3 Toisen sukupolven MediaNet 12 sisältöjään. Samoin ylläpitäjällä on ohjelma, jolla järjestelmää valvotaan ja hallitaan. Loppukäyttäjä käyttää sisällönhallintajärjestelmää aina jonkin loppukäyttäjäohjelman kautta. Nämä ohjelmat ovat yleensä kolmansien osapuolien valmistamia. Tällaisia voivat olla esimerkiksi selaimet tai erilliset mediasoittimet. 3.3 Toiminnalliset tavoitteet MediaNet-tuotteiden yksi päätavoitteista on madaltaa kynnystä liittää multimediamateriaalia erilaisiin verkkoon tuotettaviin kokonaisuuksiin. Tarkoituksena on luoda kokonaisvaltainen ratkaisu, jossa sisällöntuottajan huoleksi jää yksinkertaisimmillaan ainoastaan materiaalin siirtäminen sisällönhallintajärjestelmään sekä sisällönhallintajärjestelmän käsittelemän materiaalin käyttäminen osana omia kokonaisuuksiaan. 3.3.1 Helppokäyttöisyys Sisällöntuottajan tulee voida mahdollisimman helposti siirtää materiaaliansa sisällönhallintajärjestelmän käsiteltäväksi. Halutessaan tietyn materiaalin katseltavaksi Internetiin sisällöntuottaja toimittaa sen aluksi digitaalisessa muodossa Kuva 3-2 Sisällönhallintajärjestelmän liittyminen ympäristöönsä. LoppukäyttäjäSisällöntuottaja Ylläpitäjä Loppukäyttäjä- ohjelma Sisällönhallintajärjestelmä
  • 24. 3 Toisen sukupolven MediaNet 13 sisällönhallintajärjestelmään. Tämän jälkeen tapahtuvasta materiaalin käsittelystä sisällöntuottajan ei välttämättä tarvitse välittää, mutta kuitenkin pyritään siihen, että käsittelyn kulkua voidaan haluttaessa myös seurata. Käsittelyn jälkeen sisällöntuottajalle lähetetään sähköpostin välityksellä tieto siitä, että materiaali on valmista verkossa jaettavaksi sekä ne URL-osoitteet, joista materiaali on katseltavissa. Näitä URL-osoitteita sisällöntuottaja voi sitten käyttää osana omia kokonaisuuksiaan. Uuden materiaalin siirtämistä ja järjestelmään jo siirretyn materiaalin käsittelemistä varten sisällöntuottajalle luodaan erillinen asiakasohjelma. Järjestelmää käyttävät hyvin erilaiset sisällöntuottajat, joiden tarpeissa on suuria eroavaisuuksia. Tämän lisäksi eri sisällöntuottajat ovat mahdollisesti myös eri sovellusten käyttäjiä. Asiakasohjelman tulee pystyä tarjoamaan erilaisille sisällöntuottajaryhmille erikseen valitut toiminnot ja käyttömahdollisuudet. Asiakasohjelma pyritään toteuttamaan siten, että kaikille sisällöntuottajille voidaan jakaa tämä sama ohjelma, joka sitten mukautetaan käyttäjätietojen avulla halutun kaltaiseksi. Sisällöntuottajalle näytetään vain ne ominaisuudet, joiden käytöstä on sovittu. Näin voidaan esimerkiksi antaa sisällöntuottajalle mahdollisuus ostaa asiakasohjelmaan uusia lisäominaisuuksia vain kulloisenkin tarpeen mukaisesti. Asetukset haetaan palvelimelta järjestelmään sisäänkirjoittautumisen yhteydessä. Näin myös mahdollistetaan erilaisten toimintojen ja ominaisuuksien dynaaminen lisääminen sisällöntuottajan asiakasohjelmaan. Käytännössä tämän kaltaista käyttäjään perustuvaa dynaamista asiakasohjelman muokkausta ei kuitenkaan aluksi suunnitella erityisen yksityiskohtaisesti, vaan siihen ainoastaan varataan mahdollisuus mikäli käyttökokemukset osoittavat sen tarpeelliseksi. Asiakasohjelman mukautuvuuden avulla pyritään myös siihen, että eri MediaNet- sovellukset voivat käyttää samaa ohjelmaa. Esimerkiksi On-Demand- ja TMC- sisällöntuottajille voidaan jakaa samaa asiakasohjelmaa, jonka toiminnot mukautetaan kulloinkin käytettävän sovelluksen mukaisiksi.
  • 25. 3 Toisen sukupolven MediaNet 14 3.3.2 Materiaalin jakelu Järjestelmän tehtävänä on hoitaa materiaalin muuntaminen Internetissä helposti levitettävissä olevaan muotoon, kulloinkin käytössä olevan tietoliikenneyhteyden mukaan skaalautuvaksi. Käytännössä tämä tarkoittaa sitä, että materiaalista tehdään valmiiksi tietyille kiinteille nopeuksille sovitettuja versioita, joista voidaan valita sopivin. Käsiteltyään tiedostoja sisällönhallintajärjestelmä siirtää mediamateriaalin palvelimille odottamaan loppukäyttäjää. Järjestelmä tarjoaa myös säilytystilan materiaalille ja loppukäyttäjän ohjelmille rajapinnan, jonka avulla tätä materiaalia voidaan katsella. Sisältöpalvelimet voidaan helposti sijoittaa riittävän nopeiden verkkoyhteyksien taakse, mikä ei yleensä ole yksittäiselle sisällöntuottajalle taloudellisesti kannattavaa. Koska sisällöntuottajan materiaalin toimitus sisällönhallintajärjestelmään on kertaluontoinen toimenpide, sisällöntuottajalle riittävät suhteellisen hitaat yhteydet. Tämä säästää kustannuksia. 3.3.3 Loppukäyttäjäryhmät Materiaalille tulee voida määrittää myös erilaisia katselurajoituksia. Näiden avulla voidaan määrittää erillisiä ryhmiä, joilla on katseluoikeus materiaaliin. Nämä rajoitukset palvelevat useita erillisiä tarkoituksia. Rajoitusten avulla voidaan toteuttaa myös maksullinen materiaali. Haluttuun materiaaliin voidaan antaa katseluoikeus ainoastaan maksaville loppukäyttäjille. Katselurajoitusten valvomisesta vastaavat materiaalin jakelujärjestelmät eli käytännössä sisältöpalvelimet. Katselurajoitusten ansiosta yritykset voivat käyttää sisällönhallintajärjestelmää yrityksen sisäisen tai muutoin salaisen materiaalin säilyttämiseen. Materiaalille voidaan antaa käyttöoikeus ainoastaan kyseisen yrityksen työntekijöille. Tästä on se etu, että samaa fyysistä sisällönhallintajärjestelmää voidaan käyttää sekä yleisessä jakelussa olevan materiaalin jakeluun että täydentämään yritysten intranet-ratkaisuja. Näin fyysistä sisällönhallintajärjestelmää ei tarvitse asentaa yritysten omiin tiloihin. Katselurajoitusten avulla voidaan toteuttaa myös suljetut käyttäjäryhmät.
  • 26. 3 Toisen sukupolven MediaNet 15 3.3.4 Raportointi ja laskutus Raportointi on tärkeä osa verkossa tapahtuvaa multimedian jakelua. Sisällöntuottajat haluavat luonnollisesti palautetta siitä, kuinka paljon mitäkin heidän materiaaleistaan on katseltu. Tämän tiedon avulla he voivat kehittää omia sisältöjään kiinnostavammiksi loppukäyttäjille. Laskutusmahdollisuus kuuluu oleellisena osana multimediamateriaalin välittämiseen Internetissä. Laskutus jakautuu kahteen eri osa-alueeseen eli loppukäyttäjän ja sisällöntuottajan laskuttamiseen. Sisällöntuottajia pitää tarvittaessa voida laskuttaa heidän käyttämästään kapasiteetista, joten järjestelmästä tulee saada tietoa jokaisen sisällöntuottajan sisällön määrästä sisällönhallintajärjestelmässä. Edellisen lisäksi sisällöntuottajille tulee mahdollistaa heidän asiakkaidensa eli loppukäyttäjien laskutus. Sisällönhallintajärjestelmän avulla pitää siis voida asettaa materiaalille hintaparametreja. Hinnoittelumahdollisuudesta puolestaan seuraa se, että järjestelmän tulee mahdollistaa loppukäyttäjien sisällön katselumahdollisuuden rajaaminen, jolloin ainoastaan maksavat asiakkaat saavat oikeuden tietyn materiaalin katsomiseen. 3.3.5 Tietojen säilytys Varsinaista sisältöä säilytetään ainoastaan sitä jakelevilla palvelimilla eli sen säilytys on hajautettu eri puolille sisällönhallintajärjestelmää. Kaikki muu tieto pyritään säilyttämään keskitetysti yhdessä tai useammassa tietokannassa. Järjestelmän tietokantoja voivat tarvittaessa käyttää myös sellaiset MediaNet-tuotteet, joiden ei itse tarvitse käsitellä varsinaisia mediatiedostoja. Tämä on otettava huomioon tietokannan rakennetta suunniteltaessa. Esimerkiksi asiakastietokannasta voidaan etsiä tietoa asiakkaista ilman, että ollaan kiinnostuneita kyseisen asiakkaan mediatiedostoista. Tietokannan avulla huolehditaan myös sisällöntuottajien tunnistamisesta, todentamisesta ja käyttäjäkohtaisten tietojen hallinnasta.
  • 27. 3 Toisen sukupolven MediaNet 16 3.4 Tekniset tavoitteet Keskeisimpänä teknisenä tavoitteena uudelle järjestelmälle on yhtenäisen ohjelmiston aikaansaaminen. Järjestelmä toteutetaan ohjelmistoprojektina, jonka tarkoituksena on tuottaa dokumentoitu ja helposti ylläpidettävä kokonaisuus. Keskeisenä tavoitteena on myös tietokantaan perustuva keskitetty tiedonhallinta. 3.4.1 Ympäristöriippumattomuus Sisällönhallintajärjestelmän tulee toimia mahdollisimman monissa erityyppisissä ympäristöissä. Tämä tarkoittaa sitä, että järjestelmän eri osien suunnittelussa ei nojauduta minkään laite- tai käyttöjärjestelmäympäristön omiin erityispiirteisiin. Edellä mainitusta joudutaan kuitenkin poikkeamaan joidenkin järjestelmän apuna käytettävien kolmansien osapuolten valmistamien ohjelmistojen ja ohjelmakirjastojen osalta. Näitä ei luonnollisesti aina ole saatavissa kaikkiin haluttuihin ympäristöihin. Erityisesti erilaisten tiedostoformaattien välisten muunnosten kohdalla joudutaan tukeutumaan ulkopuolisiin tuotteisiin. Varsinaisessa toteutuksessa eri järjestelmien erityispiirteitä pyritään toki mahdollisuuksien rajoissa ottamaan huomioon. Näin voidaan helpottaa toteutusta ja parantaa suorituskykyä. Järjestelmän sisältämien palvelimien osalta pyritään käytännössä ottamaan huomioon Windows NT-, Linux- ja Solaris-käyttöjärjestelmien piirteitä. Teoriassa jokainen yksittäinen sisällönhallintajärjestelmän osa voi sijaita eri laite- ja käyttöjärjestelmäympäristössä. Ympäristöriippumattomuudesta seuraa useita etuja. Kun sisällönhallintajärjestelmästä asennetaan uusi kopio, voidaan tarvittaessa hyödyntää jo olemassa olevaa laite- ja käyttöjärjestelmäympäristöä. Tämä tietysti vaatii, että tietyt tehokkuuskriteerit saavutetaan. Järjestelmä voidaan siirtää uusille tehokkaammille tai halvemmille laitealustoille näiden ilmestyessä markkinoille. Selkeä ympäristöriippumattomuudella saavutettu etu on myös mahdollisuus tarvittaessa hyödyntää monia hyvin erilaisia kolmansien osapuolten toimittamia ohjelmia ja ohjelmakirjastoja järjestelmän apuna. Tavoitteena on tukea mahdollisimman monia
  • 28. 3 Toisen sukupolven MediaNet 17 tiedostoformaatteja. Ideaalisessa tilanteessa sisällöntuottajan ei tarvitse lainkaan ajatella, minkä tyyppistä materiaalia hän sisällönhallintajärjestelmään syöttää, vaan kaikki osataan muuntaa haluttuihin kohdeformaatteihin. Uusien tiedostoformaattien ilmestyttyä niitä voidaan alkaa tukea välittömästi ensimmäisten kaupallisten muunnosohjelmien ilmestyttyä markkinoille riippumatta siitä, mille alustoille muunnosohjelmat ensimmäisenä julkaistaan. Samoin uusia ja tehokkaampia muunnosohjelmia voidaan ottaa tarvittaessa heti käyttöön osaksi järjestelmää. Olemassa oleva laitekanta voidaan myös näin haluttaessa lähes kokonaisuudessaan hyödyntää, mikäli tehokkuuskriteerit sen sallivat. 3.4.2 Hajautettavuus ja skaalautuvuus Sisällönhallintajärjestelmän suunnittelun eräänä peruslähtökohtana on voimakas hajautettavuus. Järjestelmä pyritään suunnittelemaan siten, että se koostuu useista erillisistä osasista, joista jokainen hoitaa ainoastaan yhtä juuri sille ominaista tehtävää. Järjestelmän jaossa tulee kuitenkin huomioida se, ettei näiden osien välisen keskinäisen kommunikaation tuottaman ylimääräisen verkkoliikenteen osuus kasva kohtuuttomaksi suoritusrasitteeksi. Järjestelmä on tarvittaessa voitava hajauttaa maailmanlaajuiseksi. Sisällöntuottajalla pitää olla mahdollisuus siirtää materiaaliaan samanaikaisesti eri maissa sijaitseville sisältöpalvelimille. Järjestelmän pienintä yksikköä kutsutaan palveluksi. Jokaisen palvelun tulee voida sijaita omalla tietokoneella. Eri koneilla sijaitsevien palveluiden on kyettävä vaihtamaan tietoa toistensa kanssa ainakin IP-protokollan välityksellä. Tämän lisäksi voidaan tehokkuuden parantamiseksi käyttää myös muita mahdollisia tiedonvälitysmenetelmiä, kuten esimerkiksi jaettuja levyjä. Sisällönhallintajärjestelmä sopii luonteeltaan hyvin hajautettavaksi. Järjestelmä suorittaa ylemmällä tasolla useita toisiinsa nähden rinnakkaisia toimintaketjuja. Esimerkkinä voidaan mainita tilanne, jossa moni eri sisällöntuottaja siirtää samanaikaisesti tiedostojaan sisällönhallintajärjestelmään käsiteltäväksi ja siirrettäväksi sisältöpalvelimille. Eri
  • 29. 3 Toisen sukupolven MediaNet 18 sisällöntuottajilta tulevat tiedostojen siirrot ja muunnokset eivät riipu toisistaan mitenkään. Tarkasteltaessa yhtä yksittäistä siirtoprosessia voidaan havaita, että sekin jakautuu selkeisiin osiin. Tällaisen ketjun voi muodostaa vaikka siirto sisällönhallintajärjestelmän tiedostopuskuriin odottamaan toimenpiteitä, toimenpideketjun muodostaminen, muunnos ja siirto sisältöpalvelimelle. Nämä osat tulee luonnollisesti suorittaa ajallisesti oikeassa järjestyksessä, mutta osien suoritusajankohdalla ei itsessään ole merkitystä. Järjestelmä voidaan siis rakentaa siten, että tapahtumat seuraavat toisiaan selkeinä osina. Jokaisen toteutuneen osan jälkeen tutkitaan, mitä seuraavaksi tulee tehdä ja etsitään tämän toiminnan toteuttava palvelu. Mikäli sopivaa palvelua ei ole vapaana, voidaan jäädä odottamaan sellaisen vapautumista. Sisällönhallintajärjestelmän ei tarvitse tässä vaiheessa toteuttaa mitään erikoista täydellisen reiluuden takaavaa jonotusmenetelmää. Järjestelmä luottaa siihen, että pyynnöt tulevat toisiinsa nähden siinä määrin satunnaisesti, että jokainen pyytäjä saa jossain vaiheessa vuoron. Järjestelmän ylläpitäjälle jätetään vastuu siitä, että järjestelmässä on toisiinsa nähden sopiva määrä eri tyyppisiä palveluita, jotta suuresti hidastavia osia ei pääse syntymään. Teoriassa olisi mahdollista tehdä järjestelmä myös siten, että jos yksikään järjestelmän palveluista ei pysty toteuttamaan haluttua palvelua, jäädään odottamaan tällaisen ilmestymistä. Asiasta voitaisiin periaatteessa myös ilmoittaa samalla järjestelmän ylläpitäjälle. Esimerkkinä voidaan mainita tiedoston muuntaminen muotoon, jota yksikään järjestelmän palveluista ei tunne. Tämän kaltaisia ominaisuuksia ei kuitenkaan toteuteta ainakaan järjestelmän tähän versioon. Sisällönhallintajärjestelmän hajautettavuudella pyritään osaltaan parantamaan järjestelmän skaalautuvuutta. Kuten jo aiemmin on tullut ilmi, voidaan järjestelmän suorituskykyä parantaa kasvattamalla laitteiston tehoa. Suorituskykyä voidaan kasvattaa myös hajautettavuutta hyväksikäyttäen. Olemassa olevien palveluiden rinnalle käynnistetään uusia palveluita suorittamaan samoja tehtäviä. Tästä on etuna myös se, ettei järjestelmää tarvitse ajaa alas päivitystä varten, vaan päivitys voidaan suorittaa järjestelmän toimiessa muilta osin normaalisti. Lisättäessä uusia palveluita on kuitenkin aina muistettava pitää
  • 30. 3 Toisen sukupolven MediaNet 19 järjestelmän tarjoamien palveluiden suhteet järkevinä toisiinsa nähden, jotta voidaan välttää eri palveluiden ruuhkaantumista. Hajauttaminen pyritään toteuttamaan myös siten, että järjestelmään saadaan mahdollisimman selkeät ja laajat rajapinnat erilaisiin kolmansien osapuolien toimittamiin muunnos- ja palvelinohjelmistoihin. Tavoitteena on, että järjestelmä pystyy tarvittaessa hyödyntämään kaikkia olemassa olevia komentorivipohjaisia muunnosohjelmia. 3.4.3 Toimintavarmuus ja turvallisuus Sisällönhallintajärjestelmä ei ole niin kriittinen ohjelmisto, että sille pitäisi määritellä kiinteä suurin sallittu käyttökatkosaika tai muu tarkka toimintavarmuusehto. Sisällönhallintajärjestelmän hetkellisestä toimimattomuudesta johtuvat menetykset ovat lähinnä taloudellisia. Tämä on kuitenkin luonnollisesti riittävä syy pyrkiä mahdollisimman lyhyisiin käyttökatkosaikoihin. Pääsääntöisesti pyritään siihen, että järjestelmä yrittää toipua virheistä itse. Järjestelmä pyritään toteuttamaan siten, ettei yksikään yksittäinen palvelu itsessään ole korvaamaton. Tämä on mahdollista käynnistämällä samoja toimintoja varten useita erillisiä palveluita. Tällöin saavutetaan tilanne, jossa yhden yksittäisen palvelun ajautuminen toimintakyvyttömään tilaan ei lamauta koko järjestelmää, vaan sille löytyy aina jokin toimintakuntoinen korvaava palvelu. Yksittäisen palvelun ei yleensä tarvitse pystyä toipumaan virhetilanteista. Toipumisasioita on toki syytä harkita vielä palvelukohtaisestikin. Sisältöpalvelimet muodostavat toimintavarmuuden osalta oman erityisryhmänsä, koska ne näkyvät loppukäyttäjille. Varmatoimiset sisältöpalvelimet ovat tärkeä edellytys sisällöntuottajien saamiseksi järjestelmän piiriin. Tähän voidaan vaikuttaa lähinnä arvioimalla erilaisia saatavilla olevia palvelimia ja valitsemalla saatujen tulosten perusteella käyttöön otettavat.
  • 31. 3 Toisen sukupolven MediaNet 20 Sisällönhallintajärjestelmään ei toteuteta erillisiä varmuuskopiointimekanismeja. Tarvittaessa varmuuskopiointi hoidetaan ulkoisia järjestelmiä hyväksikäyttäen. Järjestelmä suunnitellaan siten, että ulkoinen varmuuskopiointi on mahdollista. Minimivaatimuksena tulee kyetä varmuuskopioimaan sisältöpalvelinten sisältö ja tietokanta. Sisällönhallintajärjestelmän toteutuksessa pitää ottaa huomioon useita erilaisia ja eritasoisia turvallisuusseikkoja. Sisällöntuottajille tulee voida antaa riittävät takeet siitä, että asiattomat tahot eivät pääse tutkimaan järjestelmän sisältämää materiaalia. Tämä on erityisen tärkeää silloin, kun järjestelmää käytetään yrityksen sisäisen materiaalin säilyttämiseen. Myös maksullista aineistoa voidaan yrittää käyttää ilmaiseksi. Joidenkin sisältötyyppien osalta on myös määritelty, että niitä voi katsella vain striimattuina eli suoraan reaaliajassa verkosta. Loppukäyttäjällä ei ole oikeutta tallentaa näitä tiedostoja omalle kovalevylleen. Ehkä todennäköisin kohta, josta mahdollisia murtautumisyrityksiä järjestelmään tullaan tekemään, ovat erilaiset sisältöpalvelimet. Näille palvelimille on luonnollisesti oltava yhteys Internetistä, joten niitä vastaan on erityisen helppo tehdä hyökkäyksiä. Erityisesti loppukäyttäjäohjelmille näkyvät rajapinnat on toteutettava huolellisesti. Nämä rajapinnat muodostuvat suurimmaksi osaksi kolmansilta osapuolilta tulevista ohjelmistoista, joten sisältöpalvelimien toteutusvaiheessa potentiaaliseksi ongelmaksi muodostuu lähinnä näiden ohjelmistojen tarkoituksenmukainen asentaminen. Sisällönhallintajärjestelmä sisältää Internetiin useita liityntäkohtia, joihin kohdistuu potentiaalisia uhkia. Sisällönhallintajärjestelmän palvelut muodostavat hyvin kiinteän kokonaisuuden, joiden ei tarvitse kommunikoida muiden osien kanssa muutoin kuin muutamien rajapintojen kautta. Näitä ovat asiakasohjelma-, ylläpitäjä- ja sisältöpalvelinrajapinnat. Tästä johtuen voidaan luottaa siihen, että nämä palvelut voidaan sijoittaa suojattujen verkkoyhteyksien taakse. Tulevaisuutta varten järjestelmä toteutetaan kuitenkin niin, että tarvittaessa kaikki tiedonsiirto voidaan helposti muuttaa salatuksi. Edellä mainituista rajapinnoista haavoittuvin on asiakasohjelmarajapinta. Tämän rajapinnan kautta on mahdollisuus käsitellä kaikkea järjestelmään siirrettyä sisältöä.
  • 32. 3 Toisen sukupolven MediaNet 21 Käyttäjän autentikointi on siis tehtävä huolella. Autentikoinnissa tulee käyttää kryptaavaa eli salaavaa protokollaa. 3.4.4 Ylläpidettävyys ja käytettävyys Järjestelmästä pyritään tekemään mahdollisimman ylläpidettävä. Ylläpidettävyyden parantaminen oli yksi niistä perussyistä, joiden takia olemassa olevia järjestelmiä haluttiin kehittää. Ylläpidettävyyttä varten järjestelmästä kirjoitetaan kattava dokumentointi. Sisällöntuottajan kannalta järjestelmän tulee olla mahdollisimman helppokäyttöinen ja toimintavarma. Järjestelmän käytettävyyden kannalta tämä tarkoittaa sitä, että suurin huomio kohdistuu asiakasohjelmaan. Sisällönhallintajärjestelmän palvelimille ja ylläpito- ohjelmalle ei aseteta erityisiä käytettävyysvaatimuksia. Multimedian levittäminen verkossa on tällä hetkellä voimakkaasti kehittyvä tietotekniikan osa-alue. Tästä johtuen sisällönhallintajärjestelmä pyritään toteuttamaan niin, että päivittäminen on tulevaisuudessa helppoa. Modulaarinen rakenne tukee selvästi tätä pyrkimystä. Yksittäinen palvelu voidaan tarvittaessa vaihtaa toiseen saman rajapinnan toteuttavaan versioon. Järjestelmässä voidaan samanaikaisesti käyttää myös useita erilaisia toteutuksia samasta palvelusta. 3.4.5 Versionhallinta Sisällönhallintajärjestelmää joudutaan todennäköisesti päivittämään suhteellisen paljon. Tästä syystä versionhallinnan järkevä toteuttaminen on tärkeätä. Perusperiaatteena pyritään siihen, että erilaisia versioita olisi käytössä mahdollisimman vähän. Versionhallinnan yksinkertaistamiseksi toteutetaan sekä asiakasohjelmaan että ylläpito- ohjelmaan automaattinen päivitysmekanismi. Kun sisällöntuottaja ottaa yhteyden sisällönhallintaytimeen, tarkistetaan, onko asiakasohjelmasta uudempaa versiota. Mikäli näin on, voidaan suorittaa asiakasohjelman automaattinen päivittäminen.
  • 33. 3 Toisen sukupolven MediaNet 22 Asiakasohjelman päivitysmekanismin ansiosta myös palvelinta voidaan tarvittaessa helpommin uudistaa. Kaikkia vanhoja käytössä olevia asiakasohjelman versioita varten ei tarvitse erikseen pitää näiden kanssa yhteensopivia palvelimen osia.
  • 34. 23 4 Toteutusteknologiat Sisällönhallintajärjestelmä on laaja ohjelmisto. Laajuudesta johtuen ohjelmiston suunnittelussa pyrittiin siihen, että toteutuksessa hyödynnettäisiin mahdollisimman paljon valmiita ohjelmakirjastoja, apuohjelmia ja kehitystyökaluja. Kolmannessa luvussa käsitellyt ohjelmistolle asetetut vaatimukset rajoittavat työkalujen ja toteutusvaihtoehtojen valintaa. Lisäksi ohjelmointikielen valinta vaikuttaa oleellisesti tehtäviin ratkaisuihin. Ohjelmiston toteutuksesta voidaan erottaa osia, joihin löytyy useita valmiita ratkaisuja. Nämä osat ovat ohjelmiston hajautus, käyttöliittymät ja tietokantaliittymä. Järjestelmässä käytetään myös muita ulkopuolisia ohjelmistoja, jotka eivät varsinaisesti vaikuta ohjelmiston rakenteeseen. 4.1 Hajautus Ohjelmiston hajautuksen toteutusta varten tutustuimme kolmeen eri ratkaisuun. Nämä ovat Sun Microsystemsin Remote Method Invocation (RMI), Object Management Groupin (OMG) Common Object Request Broker Architecture (CORBA) ja Microsoftin Distributed Component Object Model (DCOM). Näistä kaksi jälkimmäistä ovat ohjelmointikielistä riippumattomia ratkaisuja ja RMI puolestaan on rajoittunut vain ja ainoastaan Java-ohjelmointikieleen. Kaikki ratkaisut ovat ainakin periaatteessa ympäristöriippumattomia malleja. Niiden käyttö ei esimerkiksi edellytä mitään tiettyä käyttöjärjestelmää.
  • 35. 4 Toteutusteknologiat 24 4.1.1 Remote Method Invocation RMI-luokat lisättiin Javan perusluokkiin JDK:n (Java Development Kit) versiossa 1.1. RMI on saatavissa myös JDK:n versiolle 1.0.2 erillisenä kirjastona. RMI on riippuvainen useista Javan muista ominaisuuksista, kuten olioiden serialisoinnista, Java-luokkien binääriyhteensopivuudesta virtuaalikoneiden välillä ja liityntärajapinnoista. RMI:n avulla Java-ohjelman on mahdollista kutsua eri virtuaalikoneessa sijaitsevien olioiden metodeja ja muuttaa edellä mainittujen olioiden muuttujia. Virtuaalikoneet voivat sijaita joko samalla fyysisellä koneella tai eri koneilla, jotka ovat yhteydessä toisiinsa IP-protokollaa käyttävän tietoverkon avulla. Sovellusohjelmoijalle metodikutsut näyttävät käytännössä samalta riippumatta siitä, sijaitseeko kutsuttava olio samalla vai eri koneella. [Cu97] RMI:ssä on suppea URL-pohjainen rekisterijärjestelmä, johon olioviitteitä voidaan tallentaa. Kullakin oliolla on oma symbolinen nimensä. Olioviitteet tallennetaan rekisteriin symbolisten nimien kanssa, joten oliot kykenevät löytämään toisensa käyttämällä edellä mainittuja symbolisia nimiä. Rekisteriä voidaan verrata Internetissä käytettävään nimipalvelujärjestelmään (Domain Name System, DNS). DNS:ssä käsitellään koneen nimiä, kun taas RMI:n rekisterissä käsitellään olioiden nimiä. Sunin pyrkimyksenä on ollut lähentää Javaa ja CORBAa. Tästä on osoituksena se, että Sunilla on oma toteutus CORBA yhteensopivasta Object Request Brokerista (ORB), joka tulee JDK:n versiossa 1.2 perusluokkien mukana. Lisäksi tällä hetkellä on jo olemassa esiversio RMI-IIOP -toteutuksesta, jossa RMI:n oman protokollan asemesta käytetään OMG:n määrittelemää Internet Inter-ORB Protocol -protokollaa (IIOP). RMI-IIOP:n ansiosta RMI:tä käyttävät ohjelmat kykenevät kommunikoimaan muilla ohjelmointikielillä tehtyjen CORBA-olioiden kanssa [Su99]. 4.1.2 Common Object Request Broker Architecture Object Management Group (OMG) on 1989 perustettu kansainvälinen järjestö, jonka tavoitteena on kehittää oliopohjaisiin hajautettuihin järjestelmiin liittyvää teoriaa ja käytäntöä. OMG:n toiminnassa on nykyään mukana yli 800 yritystä ja organisaatiota.
  • 36. 4 Toteutusteknologiat 25 OMG:n tavoitteena on vähentää ohjelmistokehityksen monimutkaisuutta ja alentaa kehityskustannuksia sekä nopeuttaa uusien ohjelmistojen kehitysprosessia. OMG pyrkii standardoimaan hajautettujen ohjelmistojen kehityksessä käytettäviä menetelmiä. Object Management Architecture (OMA) on OMG:n määrittelemä viitemalli. OMA on OMG:n näkemys kokonaisesta hajautetusta järjestelmästä. OMA jakautuu sovellus-, järjestelmä- ja vertikaalisovellussuuntautuneisiin segmentteihin. Sovellussegmentti koostuu yleisistä sovellustoiminnoista (engl. Common Facilities), kuten tulostus-, tietokanta- ja sähköpostitoiminnot. Näiden sovellustoimintojen standardoinnin tavoitteena on luoda yleiskäyttöisiä ohjelmakomponentteja, joiden toiminnot ovat käyttäjien muokattavissa tarpeitansa vastaaviksi. Järjestelmäsegmentti sisältää hajautetun järjestelmän infrastruktuurin muodostavat komponentit. Näitä ovat ORB ja oliopalvelut (engl. Object Services). Vertikaalisovellukset ovat jonkin tietyn sovellusalueen käyttöön tarkoitettuja rajapintoja. Esimerkiksi lääketiede muodostaa oman vertikaalisovellusalueensa. [OMG99] OMA koostuu viidestä komponentista, jotka ovat Object Request Broker (ORB), Object Services, Common Facilities, Domain Interfaces ja Application Objects. Kuvassa 4-1 on esitetty OMG-viitemalli. Viitemallista on nähtävissä OMAn komponentit ja niiden suhteet toisiinsa. OMAn selkärankana toimii Object Request Broker (ORB). ORB toimii välittäjänä hajautetun järjestelmän eri olioiden välillä. Object Services -komponentti sisältää olioiden elinkaaren hallintaan tarvittavia toimintoja. Kuten edellä todettiin, Common Facilities -komponentti sisältää rajapintamäärittelyt yleisille sovellustoiminnoille. Domain Interfaces -komponentti koostuu vertikaalisovellusten rajapintamäärittelyistä. Application Objects -komponentti koostuu sovellusmäärittelyistä. Tyypillisesti nämä sovellusmäärittelyt hyödyntävät muiden OMAn komponenttien rajapintoja. [OMG99] Common Object Request Broker Architecture (CORBA) on OMAn määrittelemä ORB. CORBA, jota kutsutaan myös nimellä Object Bus, on OMAn määrittelemä komponentti, joka mahdollistaa olioiden välisen kommunikoinnin. CORBA on määrittelynä riippumaton ohjelman ajoympäristöstä ja kehitysvälineistä. CORBA
  • 37. 4 Toteutusteknologiat 26 määrittelee järjestelmän, joka mahdollistaa olioiden välisen vuorovaikutuksen heterogeenisessa, hajautetussa ympäristössä. OMG Object Model määrittelee käsitteistön, jolla voidaan kuvata toteutusriippumattomalla tavalla olioiden ulospäin näkyvät piirteet. Object Model perustuu muutamiin peruskäsitteisiin. Nämä käsitteet ovat olio, operaatio, tyyppi ja johdettu tyyppi. Olio voi mallintaa mitä tahansa käsitettä, kuten ihmistä, eläintä, dokumenttia, konetta yms. Oliot edustavat aina määrättyä tyyppiä. Tyypin voi käsittää eräänlaisena muottina, josta uusi olio luodaan. Tyyppi määrittelee siitä luotujen olioiden käyttäytymisen kuvaamalla operaatiot, jotka oliot toteuttavat. Tyyppien välillä voi olla erilaisia suhteita. Tyypit voivat olla perittyjä yhdestä tai useammasta muusta tyypistä. Perittyjä tyyppejä kutsutaan alityypeiksi. Kuva 4-1 OMG-viitemalli [OMG99]. Object Request Broker (ORB) Object Services Domain Interfaces Common FacilitiesApplication Objects
  • 38. 4 Toteutusteknologiat 27 Interface Definition Language (IDL) on OMG Object Modelin mukaisten olioiden rajapintojen määrittelyyn tarkoitettu kieli. IDL-kielisistä rajapintakuvauksista käännetään IDL-kääntäjän avulla kohdekielelle tyngät (engl. stub) ja rungot (engl. skeleton). Kohdekieli voi olla esimerkiksi C++ tai Java. Kohdekieli riippuu käytetystä IDL- kääntäjästä. Tynkä on ohjelma, jonka tehtävä on toimia asiakasolion rajapintana palvelinolioon. C++:n ja Javan tapauksessa tynkä on luokka, jolla on sama rajapinta kuin palvelinoliolla. Tynkä huolehtii kutsujen välittämisestä palvelinoliolle yhteistyössä ORBin ja rungon kanssa. Runko yksinkertaistaa palvelinolion toteutusta, koska se sisältää ORBin kanssa kommunikoimiseen tarvittavat toiminnot. ORB toimii eräänlaisena välittäjänä olioiden välillä näiden kutsuessa toisten olioiden metodeja. Kuvassa 4-2 on havainnollistettu tyngän, rungon ja ORBin rooli hajautetussa ohjelmassa. Kuvassa asiakasolio kutsuu CORBAn avulla palvelinolion metodia. Vasemman puoleinen kuva esittää tilannetta, jossa sekä asiakasolio että palvelinolio käyttävät samaa ORBia. Oikean puoleinen kuva on tilanteesta, jossa asiakasolio ja palvelinolio ovat kiinnittyneet eri ORBeihin. Tällöin asiakasolion ORB välittää kutsun tietoverkon kautta IIOP-protokollan avulla palvelinolion ORBille. Kuva 4-2 Kutsun välittäminen asiakasoliolta palvelinoliolle CORBAn avulla [Si96 luku 2]. Runko Palvelinolio Tynkä ORB Asiakasolio Runko Palvelinolio Tynkä ORB Asiakasolio ORB IIOP Kutsu Kutsu
  • 39. 4 Toteutusteknologiat 28 4.1.3 Distributed Component Object Model Tämä kohta perustuu Developer.com-nimisessä WWW-palvelussa (www.developer.com) julkaistuun artikkeliin [Al98]. Microsoftin ratkaisu hajautettujen ohjelmistojen tekemiseen on DCOM. DCOM on laajennus Microsoftin Component Object Modeliin (COM), joka muodostaa Windows-käyttöjärjestelmien perusarkkitehtuurin. DCOM mahdollistaa eri ohjelmointikielillä tehtyjen ohjelmakomponenttien välisen kommunikaation tietoverkon välityksellä. DCOMin käytöstä seuraavat edut johtuvat sen tiiviistä sitomisesta itse Windows- käyttöjärjestelmään. DCOMin avulla omissa sovelluksissa voi hyödyntää useita Windows- alustan palveluita, kuten Microsoft Transaction Serveriä tai Microsoftin Internet Information Serveriä. Lisäksi DCOM toimii Windowsin turvallisuusmallin alaisuudessa, joten turvallisuusnäkökohdat on myös otettu huomioon. Jokaiselle DCOM-komponentille voidaan määrittää oma Access Control List (ACL), jolla määrätään ketkä käyttäjät ja mitkä ohjelmat saavat kyseistä komponenttia käyttää. DCOMin ongelmana on, että se on teknologiana vielä kohtuullisen uusi. Työkalut eivät olleet vielä kesällä 1997 kovinkaan kehittyneitä. DCOM ei myöskään ole ympäristöriippumaton ratkaisu. Sisällönhallintajärjestelmän suunnitteluvaiheessa DCOMia ei ollut saatavilla muille alustoille kuin Intel-pohjaisille PC -koneille, joiden käyttöjärjestelmänä oli Windows. Nykyään DCOM löytyy jo useammille laitealustoille kuten Sunin Solarikselle ja Linuxille. 4.1.4 Menetelmän valinta CORBAn etuna on vahva yritysten tuki. Myös CORBAn avoimuus on positiivinen asia. CORBA-työkaluja valmistavia yrityksiä on useita, joten työkaluja löytyy useille laitealustoille, käyttöjärjestelmille ja ohjelmointikielille. Nämä työkalut ovat kuitenkin olleet perinteisesti hyvin kalliita, mutta nykyään on saatavilla edullisia jopa ilmaisia ratkaisuja. CORBAn ongelmana on ollut muun muassa se, että eri valmistajien ORBit
  • 40. 4 Toteutusteknologiat 29 eivät välttämättä ole kyenneet kommunikoimaan keskenään. Tähän on pyritty saamaan parannus CORBA-määrittelyä [OMG98] tarkentamalla. Microsoftin DCOM on piirteidensä puolesta vertailukelpoinen CORBAan nähden. DCOM oli vielä vuoden 1997 kesällä suhteellisen uusi teknologia, joten DCOMin käyttöön tarvittavat työkalut eivät olleet kovinkaan kehittyneitä. Lisäksi DCOMin Windows- sidonnaisuus oli eräs suurimmista ongelmista. DCOMin valinta olisi myös käytännössä sulkenut pois mahdollisuuden käyttää Javaa toteutuskielenä. Ainoa keino hyödyntää DCOMia Javasta olisi ollut käyttää Microsoftin tekemää virtuaalikonetta. Sisällönhallintajärjestelmälle asetettu vaatimus ympäristöriippumattomuudesta olisi tällöin jäänyt saavuttamatta, koska kyseistä virtuaalikonetta ei ole saatavilla kuin Windows- ympäristöön. Java RMI on huomattavasti yksinkertaisempi ratkaisu kuin Microsoftin DCOM ja OMG:n CORBA. RMI on lähinnä lisäys Javaan, kun taas DCOM ja CORBA pyrkivät määrittelemään kokonaisen hajautetun järjestelmän palveluineen. RMI soveltuu lähinnä pienimuotoisiin hajautettuihin järjestelmiin, koska se ei tarjoa kovin monipuolisia palveluita. RMI:n suurin vahvuus on käytön helppous. Tämä on seurausta siitä, että RMI on suunniteltu ainoastaan Javan kanssa käytettäväksi. RMI:n käyttö on lähes läpinäkyvää sovellusohjelmoijalle. RMI:n suurin vahvuus on myös sen suurin heikkous. RMI:n valinta hajautuksen toteutukseen olisi sitonut projektin tiukasti Javan ympärille ja muiden ohjelmointikielten käyttäminen olisi ollut hyvin hankalaa, ellei peräti joissain tapauksissa mahdotonta. Ohjelmistojen välinen kommunikaatio päätettiin toteuttaa CORBA-yhteensopivan ORBin avulla [OMG98]. Koska tässä projektissa ohjelmistot toteutetaan Javalla, CORBA- työkaluna käytetään Ionan OrbixWeb 3:a. Koska käytössä on vain yhden valmistajan ORB, ei ORBien välinen kommunikaatio muodostu ongelmaksi. Toteutuksessa pyritään nojautumaan mahdollisimman paljon IDL to Java Mapping -määrittelyn mukaisiin rajapintoihin [OMG97]. Tällöin on ainakin periaatteessa mahdollista vaihtaa käytettävä ORB toisen valmistajan ORBiin, jos tämä tulee tarpeelliseksi.
  • 41. 4 Toteutusteknologiat 30 4.2 Ohjelmointikieli Sisällönhallintajärjestelmän toteutusta varten valittiin ohjelmointikieleksi Java. Toteutuksen aloitushetkellä uusin versio JDK:sta oli 1.1.3, joten sisällönhallintajärjestelmän toteutuksessa päätettiin tukeutua JDK 1.1:een. Järjestelmää tultaisiin käyttämään monissa erilaisissa laitteistoympäristöissä, joten järjestelmästä oli saatava mahdollisimman ympäristöriippumaton. Järjestelmän suunnitteluhetkellä käytössä olivat Windows NT-, Linux- ja Sun Solaris- käyttöjärjestelmät. Kaikille näille oli saatavissa Java-virtuaalikone. Käytettäessä Javaa voidaan käyttää samoja ohjelmabinäärejä kaikissa koneissa, joihin löytyy yhteensopiva Java-virtuaalikone. Javan eduksi voidaan laskea myös se, että sille oli olemassa kohtuullisen hintaisia tai jopa ilmaisia CORBA ORBeja. Projektin alussa käytimme Sun Microsystemsin ilmaista esiversiota heidän tekemästään Java IDL -ORBista. Myöhemmin siirryimme kuitenkin käyttämään Ionan OrbixWebia, koska tämä oli oleellisesti vakaampi ohjelma ja toteutti OMG:n IDL to Java Mapping -määrittelyn [OMG97] toisin kuin Sunin toteutus. Javan ongelmana on tehottomuus verrattuna muihin ohjelmointikieliin. Alusta alkaen oli kuitenkin selvää, että järjestelmän pullonkaulana ei tulisi olemaan varsinainen sisältöjen hallinta vaan sisältöjen muuntaminen. Koska muuntaminen suoritetaan kolmannen osapuolen toimittamilla ohjelmistoilla, ei Javan valitseminen ohjelmointikieleksi vaikuta oleellisesti järjestelmän suorituskykyyn. Javan valintaan vaikutti myös omalta osaltaan se, että projektiryhmällä oli jo kokemusta ohjelmoinnista kyseisellä kielellä. Tietyt Javan piirteet kuten serialisointi ja kattavat perusluokkakirjastot houkuttelivat myös valitsemaan Javan toteutuskieleksi. Vaikka ohjelmointikieleksi valittiinkin Java, ei tämä suinkaan tarkoita sitä, että kaikki järjestelmään liittyvät ohjelmat olisi tehtävä Javalla. Koska sovelluksen toteutuksessa käytetään CORBAa, voidaan Javan rinnalla käyttää tarpeen vaatiessa myös muita kieliä.
  • 42. 4 Toteutusteknologiat 31 Esimerkiksi paljon laskentaa suorittavat ohjelmat voidaan toteuttaa muun muassa C++:lla ja liittää ne järjestelmään CORBAn avulla. Käytännössä kaikki sellaiset kielet, joille löytyy CORBA-määrittelyn [OMG98] mukainen ORB, joka kykenee toimimaan yhdessä Ionan OrbixWebin kanssa, ovat käytettävissä sellaisenaan. Voidaan myös toimia siten, että tehdään halutulla ohjelmointikielellä erillinen ohjelma, joka suoritetaan Java- virtuaalikoneen avulla. Tämä suoritettava ohjelma voi tietysti olla myös kolmannen osapuolen valmistama. Näin voidaan liittää melkein mitä tahansa ulkopuolisia ohjelmia järjestelmään käyttäen Javaa ja CORBAa. Muun muassa järjestelmään liittyvät muunnosohjelmat on toteutettu edellä mainitulla tavalla. 4.3 Käyttöliittymät Sisällönhallintajärjestelmän käyttöliittymistä haluttiin tehdä ympäristöriippumattomia. Sun Microsystemsin kehittämä ohjelmointikieli Java tarjoaa tähän mahdollisuuden, koska se on alusta alkaen suunniteltu laitteisto- ja käyttöjärjestelmäriippumattomaksi. 4.3.1 Ympäristöriippumattomuuden toteutustavat Ympäristöriippumattomuus käyttöliittymäkirjastoon Javassa voidaan saada aikaan ainakin kahdella toisistaan selvästi poikkeavalla tavalla. Yleinen ratkaisu tähän on rakentaa rajapinta ympäristökohtaisten käyttöliittymäkomponenttien päälle. Tällöin ohjelma kutsuu aina samaa rajapintaa riippumatta ympäristöstä. Toinen vaihtoehto on suorittaa komponenttien piirto käyttöliittymäkirjaston sisäisesti, jolloin ympäristökohtaisia komponentteja ei käytetä lainkaan. Ympäristökohtaisten komponenttien päälle rakennettu rajapinta käyttää siis kunkin ympäristön omia komponentteja. Niinpä käyttäjä saa aina eteensä tutun näköisen ja oloisen käyttöliittymän. Useat tietokoneen käyttäjät ovat erittäin tarkkoja siitä, että sovellus näyttää sellaiselta, johon on tottunut. Myös ohjelmistoalan ihmiset ovat usein varsin tarkkoja siitä, että esim. Unix-käyttöjärjestelmässä ajettu ohjelma käyttäytyy Unix- ohjelman tavoin, eikä esimerkiksi Macintosh- tai Windows-ohjelman tavoin. Nykyään on
  • 43. 4 Toteutusteknologiat 32 markkinoilla ohjelmia, esimerkiksi selaimia, jotka ovat samanlaisia kaikissa ympäristöissä. Vielä muutama vuosi sitten tämä oli erittäin harvinaista. Saman rajapinnan kautta kutsuttu ympäristökohtainen komponentti saattaa olla täysin eri näköinen eri ympäristöissä. Myös niiden looginen toiminta saattaa vaihdella. Ohjelmoijan tuleekin tällöin olla tarkkana ja testata ohjelmansa kaikissa mahdollisissa ympäristöissä. Käytännössä tämä on osoittautunut erittäin hankalaksi. Itse käyttöliittymäkirjastosta tulee helposti rajoittunut komponenttivalikoimaltaan. Mukaan voidaan ottaa ainoastaan komponentit, joita löytyy jokaisesta kohdeympäristöstä, ja joiden toiminta on jokseenkin samankaltaista. Jotta rajapinnan kirjoittaminen olisi mahdollista, joudutaan siis toimimaan “pienimmän yhteisen nimittäjän” -periaatteella. Tämä rajaa pois kaikki vähänkään monimutkaisemmat ja omintakeisemmat komponentit. Yhtenäisen ulkonäön aikaansaamiseksi komponenttien piirto kirjaston sisäisesti lienee ainoa vaihtoehto. Kun komponentteja ei lainatakaan systeemiltä, vaan hoidetaan piirtäminen itse, voidaan määritellä tarkalleen komponenttien ulkonäkö ja toiminta. Tällöin ohjelmoija voi rauhassa kirjoittaa käyttöliittymän luottaen siihen, että käyttäjä näkee ja kokee käyttöliittymän halutulla tavalla. Kirjaston suunnittelijalle tämä antaa myös vapauksia, koska näin liikutaan korkeammalla abstraktiotasolla kuin käyttöjärjestelmän rajapinta normaalisti tarjoaa. Näin ei olla rajoittuneita minkään systeemin tarjoamiin komponentteihin. 4.3.2 Javan käyttöliittymäkirjastot Kun käyttöliittymäkirjaston valintaa vuoden 1997 kesällä ryhdyttiin miettimään, oli ainoastaan kaksi varteenotettavaa kirjastovaihtoehtoa valittavana. Sun Microsystemsin Abstract Windowing Toolkit (AWT) ja esiversiossaan ollut Microsoftin Application Foundation Classes (AFC). Myöhemmin törmättyämme vaikeuksiin valitsemamme AFC:n kanssa tutustuimme myös tuolloin vasta suunnitteilla olleeseen Sun Microsystemsin Java Foundation Classes (JFC) -kirjastoon.
  • 44. 4 Toteutusteknologiat 33 Abstract Windowing Toolkit AWT on Sunin alkuperäinen graafisten Java-käyttöliittymien toteutukseen tarkoitettu kirjasto. Näihin päiviin asti pääosa Javalla tehdyistä käyttöliittymistä on tehty AWT:llä. AWT sisältyy kaikkiin jo julkaistuihin JDK:hin. JDK 1.1 uudisti AWT:ta varsin paljon. Tärkein muutos oli täysin uudenlainen tapahtumienkäsittely. Java esiteltiin vuonna 1995, ja sen käyttöliittymäkirjasto AWT olisi varmasti tullut hylätyksi, mikäli ihmisten konservatiivisuutta käyttöliittymien suhteen ei olisi otettu huomioon. Niinpä AWT toimiikin ympäristökohtaisten komponenttien ympäristöriippumattomana rajapintana. Aluksi tätä pidettiin varsin onnistuneena ratkaisuna. Olihan ennenkuulumatonta, että sama tavukoodi ajettuna eri ympäristöissä tarjosi käyttäjille aina kuitenkin ympäristökohtaisen käyttöliittymän. Ongelmia ilmeni kuitenkin varsin nopeasti. Ohjelmoijat olivat tyytymättömiä niin komponenttivalikoimaan kuin komponenttien toimivuuteenkin. Kuten kuvasta 4-3 voidaan Kuva 4-3 Vasemmalla on kuva on SunOS 5.4 -käyttöjärjestelmään tehdyn Java-virtuaalikoneen tuottamasta ikkunasta, kun taas oikealla oleva on Windows 95 -käyttöjärjestelmään tehdyn virtuaalikoneen näkemys samasta ikkunasta (X-server ensimmäisen kuvan ikkunassa on Windows- koneessa). Käyttöliittymäkirjastona on AWT.
  • 45. 4 Toteutusteknologiat 34 havaita, täysin sama tavukoodi näyttää jo näinkin yksinkertaisessa esimerkissä melko erinäköiseltä. Ohjelmoija saattaa tehdä ohjelmoidessaan oletuksen, että radiopainikkeen otsikko on aina kiinni painikkeessa, vaikka todellisuudessa sitä ei ole määritelty, vaan se riippuu ympäristökohtaisesta toteutuksesta. Java Foundation Classes JFC syntyi Sunin, Netscapen ja IBM:n päätöksestä tehdä uusi AWT:n korvaava käyttöliittymäkirjasto. Jo pitkään ollaan oltu sitä mieltä, että AWT ei ole riittävä ratkaisu Java-käyttöliittymiin. Netscape olikin kehitellyt omaa Internet Foundation Classes (IFC) -kirjastoa. Tämän kirjaston tarkoitus oli olla selaimessa mukana, ja niinpä sovelmissa (engl. applet) olisi voitu käyttää näitä uusia käyttöliittymäkomponentteja ilman, että niitä tarvitsisi ladata palvelimelta. Ideana oli nimenomaan tehdä kaikki komponenttien piirtäminen kirjaston sisäisesti, jolloin kirjaston kehittäjillä olisi vapaat kädet komponenttien suunnitteluun. Kirjaston kehittely alkoi loppuvuodesta 1996. Idea oli hyvä, mutta IFC ei milloinkaan saanut suurta suosiota lukuisten teknisten ongelmien vuoksi. Kun Sun sitten vihdoin uskoi itsekin, että AWT ei riitä kovin pitkälle, se alkoi kehitellä omaa kirjastoaan IFC:n pohjalta. Ilmoitus tästä annettiin Java-maailmalle huhtikuussa 1997. JFC:n ensimmäinen versio valmistui helmikuussa 1998. JFC:n eräs hieno piirre on sen vaihdettavissa oleva ulkonäkö ja tuntu (engl. pluggable look and feel). Ohjelmoija voi siis päättää, haluaako hän ohjelmansa näyttävän esimerkiksi Windows-ohjelmalta vai joltakin muulta. Tällä hetkellä valittavissa on Windows-, Motif- ja Metal-tyylit. Näistä Metal on Sunin oma tätä tarkoitusta varten kehittämä tyyli. Ohjelmoija voi myös jättää käyttäjälle sopivan tyylin valitsemisen annetuista vaihtoehdoista. Myös oman tyylin luominen on mahdollista. Tämä oli siis Sunin varsin elegantti ratkaisu käyttäjien konservatiivisuusongelmaan. Eri tyyleistä on esimerkkejä liitteessä II. Tällaisen muita järjestelmiä matkivan kirjaston pitäminen ajan tasalla saattaa muodostua ongelmaksi. Hyvänä esimerkkinä tästä on Windowsin tiedoston avaus- ja talletusdialogi.
  • 46. 4 Toteutusteknologiat 35 JFC:n sisältämän komponentin Windows - look and feel -toteutus on valitettavan eri näköinen kuin Windows NT 5:n esiversion vastaava. JFC on oikeastaan AWT:n laajennus. Kaikki JFC:n uudet komponentit, kuten myös AWT:n komponentit, perivät AWT:n Component-luokan. Tästä seuraa täydellinen AWT- yhteensopivuus. JFC-komponentteja voikin näin asettaa monien AWT-komponenttien päälle. JFC:n ohjelmointimalli on tietokeskeinen. Tämä tarkoittaa sitä, että jokainen JFC- komponentti osoittaa johonkin tietomallirajapintaan. Ohjelmoija voi käyttää komponentin oletustietomallia tai laajentaa sitä haluamallaan tavalla. Hän voi myös vaihtaa sen kokonaan, kunhan uusi luokka toteuttaa kyseisen komponentin tietomallille määrätyn rajapinnan. Vaihtaminen voidaan tehdä myös ajon aikana. Tällä tavoin komponentit ovat dynaamisempia kuin perinteiset kiinteällä tietomallilla toimivat komponentit. Tietokeskeinen lähestymistapa on monille käyttöliittymäohjelmoijille uusi. JFC:ssä on esitelty myös muita uusia konsepteja. JFC:n toteuttajat eivät ole kunnioittaneet vanhoja käsityksiä käyttöliittymäkirjastoista, vaan ovat luoneet uusia lähestymistapoja. Tämä voi aiheuttaa monille kokeneillekin ohjelmoijille ylimääräistä päänvaivaa. JFC:n edistykselliset komponentit eivät ole kaikkein helpoimpia käyttää. Esimerkiksi puukomponentti omaa monia eri luokkia ja rajapintoja, joiden avulla puu luodaan ja sitä käsitellään. Perinteisesti käyttöliittymäkirjasto tarjoaisi yhden luokan, joka sisältäisi tarvittavat tietorakenteet, mutta JFC tarjoaa eräänlaisen sovelluskehyksen (engl. framework) näihin kehittyneisiin komponentteihin. Tämä ominaisuus tuo monipuolisuutta, mutta myös hankaloittaa yksinkertaisten käyttöliittymien tekoa. Pienissä ja yksinkertaisissa sovelluksissa koodin määrä tulee usein suuremmaksi, kuin perinteisiä kirjastoja käyttämällä.
  • 47. 4 Toteutusteknologiat 36 Application Foundation Classes AFC on Microsoftin ratkaisu Javan käyttöliittymäkirjastoksi. Kyllästyneenä AWT:n heikkouksiin Microsoft ilmoitti tammikuussa 1997 kehittelevänsä AFC:tä. Microsoft olisi halunnut Sunin ottavan AFC:n käyttöönsä, mutta huhtikuussa Sun ilmoittikin aloittavansa JFC:n kehityksen. Tästä alkoi katkera kilpailu Javan käyttöliittymien tulevaisuudesta. Microsoft sai kuitenkin noin kuuden kuukauden etumatkan kirjastonsa kehittämisessä. Ensimmäinen näytösversio AFC:stä oli valmis huhtikuussa ja lopullinen versio oli valmis lokakuussa 1997. AFC korvaa täysin AWT:n. AFC-komponentit eivät siis peri AWT:n Component-luokkaa. AFC:n suunnittelijat perustelivat tätä AWT:n Component -luokan raskaudella. AFC pohjautuu UIComponent-luokkaan, jonka on tarkoitus käyttää vähemmän muistia kuin Component-luokka. Tämän seurauksena AFC-komponentteja ei voi suoraan asettaa AWT- komponentteihin. Tätä tarkoitusta varten AFC sisältää erityiset AWT-yhteensopivat luokat, jotka toimivat siltana AFC:n ja AWT:n välillä. AFC:n ohjelmointimalli on komponenttikeskeinen ja hyvin samankaltainen AWT:n kanssa. Ohjelmoiminen on hyvin suoraviivaista ja helppoa tottuneelle AWT-ohjelmoijalle. Useimmat komponenteista perivät UIContainer-luokan, jonka päälle saa asettaa UIComponent-luokan. Niinpä komponenttien päällekkäin asettelu on melko vapaata. Esimerkiksi List-komponentti on vain paneeli, johon on lisätty komponentteja allekkain ja asetettu pohjaväriksi valkoinen. AFC:n komponenttien ulkonäkö on tuttu Windows-käyttöliittymästä. Myös komponenttien toiminnallisuus on samanlaista. AFC:llä pystyykin tekemään varsin vaikuttavia Windows-ohjelmalta näyttäviä ja tuntuvia Java-käyttöliittymiä. AFC:stä on kaksi versiota: JDK 1.0.2 sekä JDK 1.1 -yhteensopiva. Ensin mainittu on tarkoitettu käytettäväksi sovelmissa, ja se on pyritty saamaan toimimaan kaikissa JDK 1.0.2 -yhteensopivissa virtuaalikoneissa. Jälkimmäinen on JDK 1.1 -yhteensopiva, mutta toimii vain Microsoftin omalla virtuaalikoneella.
  • 48. 4 Toteutusteknologiat 37 4.3.3 Yhteenveto ja kirjastojen tulevaisuus Javan käyttöliittymäkirjastot ovat muutaman vuoden aikana kehittyneet todella huimasti. Komponenttivalikoima uusissa kirjastoissa on hyvin laaja. Varsinkin JFC tarjoaa jo peruskirjastossaan sellaisia ominaisuuksia, joita on yleensä totuttu saamaan vain erillisillä kirjastoilla. Tämä ei ole kaikkien mielestä hyvä asia, koska näin myös luokkakirjaston koko kasvaa, ja yleensä koko kirjasto toimitetaan sovellusten mukana. Microsoft toimittaa AFC-kirjastoa Internet Explorer 4:n mukana, niinpä uudet Windows- käyttöjärjestelmät pitävät kirjaston sisällään. AFC:n JDK 1.1 -yhteensopiva versio vaikuttikin voittajalta aina sen viimeiseen esiversioon saakka. Silloin vielä AFC toimi myös Sunin virtuaalikoneella. Varsinaisen version ilmestyttyä lokakuussa 1997 ilmeni, ettei kirjastoa voikaan enää käyttää muilla kuin Microsoftin virtuaalikoneilla. Se oli estetty kirjastossa joillakin ympäristökohtaisilla kutsuilla. Microsoft julkaisi erikseen JDK 1.0.2 -yhteensopivan version, joka sitten toimi myös Sunin virtuaalikoneella. Niinpä JDK 1.1 -yhteensopivaa sovellusta ei voitu tehdä ympäristöriippumattomaksi käyttäen Microsoftin AFC:tä. AFC:n suurin vihollinen taitaakin olla Microsoft itse estämällä erinomaisen kirjaston käyttämisen muulta Java-maailmalta. Vaikuttaisi siltä, että jossain vaiheessa kun kirjasto oli jo melkein valmis, Microsoft päättikin, ettei AFC:stä tehdäkään yleiseen käyttöön käyttöliittymäkirjastoa kun kerran Sun ei sitä hyväksynytkään. Microsoft on muutoinkin alkanut tehdä omista Java-kirjastoistaan yhä enemmän ja enemmän ympäristöriippuvaisia huomioiden ainoastaan Windows-käyttäjät. JFC on täysin JDK 1.1 -yhteensopiva. Niinpä myös Microsoftin virtuaalikone suorittaa JFC-sovelluksia ongelmitta. JFC on tällä hetkellä ainoa järkevä vaihtoehto JDK 1.1 -pohjaisiin sovelluksiin. Sitä vastoin sovelmissa JFC:tä ei kannata käyttää, koska käyttäjillä ei yleensä ole tuota kirjastoa koneillansa. Microsoft on ilmoittanut, ettei se aio laittaakaan sitä selaintensa tai käyttöjärjestelmiensä Java-luokkiin mukaan. JDK 1.1 -yhteensopivassa selaimessa sitä ei tarvitse ollakaan, sillä JFC ei kuulu varsinaiseen Javan luokkakirjastoon. Juuri valmistunut Sun Microsystemsin JDK 1.2 pitää sisällään JFC:n. Niinpä selaimien, jotka väittävät olevansa JDK 1.2 –yhteensopivia, tulisi sisältää myös tämä upea käyttöliittymäkirjasto.
  • 49. 4 Toteutusteknologiat 38 Asiakasohjelma toteutettiin aluksi Microsoftin AFC-kirjaston esiversioita käyttäen. Kun AFC:n varsinainen versio ei sitten toiminutkaan muilla kuin Microsoftin virtuaalikoneella, päätettiin asiakasohjelma ohjelmoida uudelleen Sun Microsystemsin JFC-kirjastoa käyttäen. JFC-kirjaston kehitys oli jatkossa varsin myönteistä, joten kirjaston vaihtaminen kohtuullisen aikaisessa vaiheessa osoittautui järkeväksi päätökseksi. 4.4 Muut valitut teknologiat Järjestelmässä käytetään myös sellaisia ulkopuolisia ohjelmia, jotka eivät oleellisesti vaikuta ohjelmiston rakenteeseen suunnittelu- ja toteutusvaiheessa. Nämä ohjelmat ovat kuitenkin tarpeellisia sisällönhallintajärjestelmän käyttöönotossa ja käytössä. Tällaisia ohjelmia ovat esimerkiksi InstallShield for Java ja SourceGuard. Järjestelmän ohjelmat, jotka vaativat asennusta, asennetaan InstallShield-ohjelman avulla. Asiakasohjelma, ylläpito-ohjelma ja sisällönhallintaydin ovat kaikki asennettavissa InstallShieldin avulla. SourceGuard on ohjelma, jonka avulla voidaan muuttaa Java- luokkatiedostojen rakennetta siten, että niitä ei enää ole mahdollista saada takaisin lähdekoodimuotoon. Tätä prosessia kutsutaan obfuskoinniksi (engl. obfuscate). SourceGuardia tarvitaan suojaamaan ohjelmistossa syntyneitä Java-luokkatiedostoja, joita jaetaan ulkopuolisille tahoille kuten asiakkaille. Sisällönhallintajärjestelmä käyttää tietojen tallentamiseen tietokantaa. Koska järjestelmän palvelut toteutetaan Javalla, on luontevaa käyttää Java Database Connectivity (JDBC) -rajapintaa tietokannan liittämiseksi sisällönhallintajärjestelmään. JDBC:n avulla Java- ohjelmat kykenevät suorittamaan SQL-kielisiä kyselyitä ja päivityksiä tietokantaan. Järjestelmän tietokantana toimii Solid WebEngine 2.3. Koska järjestelmän toteutuksessa käytetään JDBC-rajapintaa ja SQL-kieltä, voidaan siirtyä käyttämään jotain toista tietokantaa tarvittaessa. JDBC-kirjaston mukana toimitetaan myös JDBC-ODBC -silta, joka mahdollistaa sellaisten tietokantojen käytön, joille ei löydy JDBC-tukea.
  • 50. 4 Toteutusteknologiat 39 Järjestelmän kehitysympäristö koostuu Linux ja Windows NT -pohjaisista tietokoneista. Ohjelmiston kehitys tehdään XEmacs-tekstieditorilla. Versionhallinta toteutetaan RCS- ohjelman avulla.
  • 51. 40 5 Sisällönhallintaydin Tässä ja seuraavassa luvussa sisällönhallintajärjestelmään viitataan sanalla järjestelmä. Järjestelmä koostuu kolmesta osasta: asiakasohjelmasta, sisällönhallintaytimestä ja ylläpito-ohjelmasta. Sisältöpalvelimet ovat osa sisällönhallintaydintä. Kuvassa 5-1 on havainnollistettu järjestelmän osia ja niiden suhteita toisiinsa. Asiakasohjelman avulla sisällöntuottaja voi hallita järjestelmässä olevia sisältöjään ja näihin liittyviä tietoja. Sekä ylläpito- että asiakasohjelma on pyritty pitämään mahdollisimman yksinkertaisina. Ohjelman varsinainen toiminnallisuus pyritään pitämään Kuva 5-1 Sisällönhallintajärjestelmän rakenne. Sisältöpalvelin Sisältöpalvelin Sisältöpalvelin Sisältöpalvelin Ylläpito-ohjelma Asiakasohjelma Loppukäyttäjä Sisällöntuottaja Ylläpitäjä Loppukäyttäjä- ohjelma Loppukäyttäjä- ohjelma Loppukäyttäjä- ohjelma Sisällönhallintajärjestelmä Sisällönhallintaydin
  • 52. 5 Sisällönhallintaydin 41 mahdollisimman pitkälle palvelinohjelmiston, tässä tapauksessa sisällönhallintaytimen, sisällä. Tällöin ylläpito- ja asiakasohjelmat toimivat lähinnä käyttöliittyminä sisällönhallintaytimen eri toiminnoille. Tehokkuussyistä tästä periaatteesta on tosin jouduttu joissain kohdissa tinkimään. Sisällönhallintaydin sisältää järjestelmän tarvitsemat tiedot sekä toiminnot, jotka mahdollistavat sisältöjen hallinnan keskitetysti asiakasohjelmalla. Sisällönhallintaytimen tehtävänä on pitää kirjaa kaikista järjestelmän sisällöistä, käyttäjistä sekä näihin liittyvistä tiedoista. Sisällönhallintaytimessä on tarvittavat ohjelmat järjestelmään siirretyn materiaalin käsittelyyn ja siirtämiseen halutuille sisältöpalvelimille. Sisältöpalvelimien tehtävänä on toimia järjestelmässä varastoina, joihin sisällöt tallennetaan. Sisältöpalvelimet huolehtivat myös sisältöjen levittämisestä loppukäyttäjäohjelmille. 5.1 Rakenne Sisällönhallintaydin on hajautettu ohjelmisto, jonka pienin itsenäinen ohjelmayksikkö on palvelu. Palvelut voidaan jakaa perus- ja erityispalveluihin. Peruspalvelut ovat yleishyödyllisiä palveluita, joita muut sisällönhallintaytimen palvelut käyttävät. Peruspalveluita ei käytetä suoraan järjestelmän ulkopuolelta. Erityispalveluita ovat kaikki muut kuin peruspalvelut. Käytännössä erityispalveluita käytetään vain joidenkin tiettyjen MediaNet-sovellusten yhteydessä. Liityntäpalvelut ovat erityispalveluita, jotka toimivat sisällönhallintaytimen ja ytimen ulkopuolisten ohjelmien välisinä rajapintoina. Palvelut muodostavat järjestelmän toimintoja suorittavan osan. Palveluiden suorittamisen ja hallinnan apuna käytetään palvelimia. Palvelin on alusta, jonka avulla voidaan tehostaa palveluiden suoritusta ja yksinkertaistaa niiden hallintaa.
  • 53. 5 Sisällönhallintaydin 42 5.1.1 Palvelut Palveluksi kutsutaan sellaista ohjelmaa tai ohjelman osaa, joka toteuttaa TFService- nimisen CORBA-rajapinnan ja jonkin palvelukohtaisen rajapinnan. Palvelu koostuu yhdestä tai useammasta CORBA-oliosta. Koska rajapinta määritellään IDL:n avulla, voidaan palvelu toteuttaa periaatteessa millä tahansa ohjelmointikielellä, jolle on olemassa IDL-kääntäjä ja CORBA-määrittelyn [OMG98] mukainen ORB. Kommunikointi palveluiden kanssa tapahtuu CORBA-määrittelyssä esitetyn IIOP-protokollan mukaisesti. Kaikki järjestelmän tähän mennessä toteutetut palvelut on tehty Javalla. Kuvassa 5-2 on kuvattu palveluiden ja CORBAn välistä suhdetta. CORBA toimii välittäjänä palveluiden välisessä kommunikaatiossa. Kuvassa ClientC-niminen palvelu käyttää muita sisällönhallintaytimen palveluita (UserManager, FileManager ja Kuva 5-2 Palvelut kommunikoivat CORBAn avulla. CORBA User Manager Code Repository File Manager ClientC
  • 54. 5 Sisällönhallintaydin 43 CodeRepository). Koska CORBA huolehtii kutsujen välittämisestä palvelulta toiselle, ei palveluiden toteutuksessa tarvitse huolehtia siitä, miten kutsu käytännössä välitetään. TFService-rajapinta sisältää palveluiden hallintaan sekä niiden tilan seurantaan liittyviä metodeja. Hallintaan kuuluvia asioita ovat palvelun tilan muuttamiseen liittyvät metodit, palvelupyyntö, viestien vastaanotto ja palveluiden ominaisuudet. Palveluiden toteutuksen helpottamiseksi on luotu palvelu-sovelluskehys. Uudet palvelut voivat periä TFServiceServant-nimisen luokan, joka sisältää suurimman osan palveluille tarpeellisista toiminnoista. TFService-rajapinnan lisäksi jokaisella palvelulla on oma palvelukohtainen rajapinta, joka määrittelee palvelun toteuttamat metodit ja attribuutit. Palveluihin liittyy tilakäsite. Palvelut ovat kullakin hetkellä jossain ennalta määritellyssä tilassa. Palvelu voi olla ajossa, pysäytetty, käynnistymässä tai lopettamassa toimintaansa. Suurin osa palveluiden toiminnoista on käytettävissä vain silloin, kun ne ovat ajossa- tilassa. Palvelupyynnön avulla voidaan kysyä palvelukohtaisilla parametreilla, voiko palvelu suorittaa halutun toimenpiteen. Esimerkiksi tiedostojen hallinta -palvelulle (FileManager) voidaan lähettää palvelupyyntö, jonka avulla voidaan selvittää, mahtuuko halutun kokoinen tiedosto FileManagerin levylle. Sisällönhallintaytimen Locator-palvelu käyttää palvelupyyntöä hakiessaan sopivaa palvelua. Locator on eräänlainen hakukone, jonka avulla palvelut voivat etsiä muita sisällönhallintaytimen palveluita, jotka täyttävät halutut ehdot. Ominaisuuksien (engl. property) avulla voidaan määritellä palvelun toimintaan vaikuttavia parametreja. Ominaisuudet ovat merkkijonopareja. Parin merkkijonoista ensimmäinen on tunniste ja toinen on ominaisuuden arvo. Ominaisuuksia voidaan verrata esimerkiksi useissa käyttöjärjestelmissä käytettyihin ympäristömuuttujiin. Ominaisuuksien arvot otetaan käyttöön aina palvelun käynnistymisen yhteydessä. Tästä syystä ominaisuuksia muutettaessa ajon aikana täytyy palvelu käynnistää uudestaan, jotta uudet asetukset tulevat voimaan. Palveluiden kantaluokka TFServiceServant määrittelee kaikille
  • 55. 5 Sisällönhallintaydin 44 palveluille yhteisiä ominaisuuksia, minkä lisäksi kukin palvelu voi määritellä itselleen tarpeellisia ominaisuuksia. Peruspalvelut Peruspalvelut tuottavat yleishyödyllisiä palveluita sisällönhallintaytimen muille palveluille. Peruspalvelut toimivat eräänlaisena pohjana, jonka päälle varsinaisten sovellusten vaatima toiminnallisuus perustuu. Peruspalveluihin kuuluvat muun muassa tiedostojen hallintaa, käyttäjien hallintaa, tietokannan käsittelyä ja palveluiden hallintaa suorittavat palvelut. Taulukossa 5-1 on lueteltu sisällönhallintaytimen peruspalvelut ja annettu lyhyt kuvaus niiden toiminnasta. Peruspalveluille on tyypillistä, että ne käyttävät apunaan jotain ulkopuolista ohjelmaa tai että ne tarjoavat muille sisällönhallintaytimen palveluille mahdollisuuden käyttää suoraan ulkopuolista ohjelmaa. Esimerkiksi sisällönhallintaytimen tietokantapalveluista huolehtiva DBC-palvelu tarjoaa mahdollisuuden suorittaa SQL-kielisiä hakuja ja päivityksiä tietokantaan. Mailer-palvelu puolestaan mahdollistaa sähköpostin lähettämisen palveluista. Kaikki palvelut ovat tasa-arvoisia keskenään, mikä tarkoittaa sitä, että mikä tahansa palvelu voi käyttää toista palvelua apunaan. Palvelut voivat olla niin riippuvaisia toisten palveluiden tarjoamista toiminnoista, että ne eivät pysty suorittamaan omia toimintojaan ilman toisen palvelun apua. Locator-palvelu on hyvä esimerkki sellaisesta palvelusta, jota ilman muut palvelut eivät voi suorittaa omia toimintojaan. Locatorin avulla palvelut hakevat viitteitä haluamiinsa muihin palveluihin. Jos sisällönhallintaytimessä ei ole käynnissä Locator-palvelua, eivät palvelut löydä toisiaan. Tilanne on hieman saman tapainen, jos sisällönhallintaytimessä ei ole DBC-palvelua. Tämä johtuu siitä, että monet palveluista on toteutettu siten, että ne käyttävät tietokantaa omien palvelukohtaisten tietojensa säilyttämiseen. Esimerkiksi nykyiset Log-, ProcessQueue- ja ErrorHandler- palveluiden toteutukset käyttävät tietokantaa.
  • 56. 5 Sisällönhallintaydin 45 Erityispalvelut Erityispalveluiden tehtävänä on suorittaa MediaNet-sovellusten tarvitsemia toimintoja. Nämä toiminnot ovat luonteeltaan lähempänä käyttäjää kuin peruspalveluiden tuottamat palvelut. Erityispalveluita ovat muun muassa yksittäiset muunnosohjelmat ja transaktiopalvelut. Taulukossa 5-2 ovat nähtävissä sisällönhallintaytimen erityispalvelut. Taulukko 5-1 Peruspalvelut Palvelu Kuvaus ServiceManager Palveluiden hallinta yksittäisellä palvelimella tapahtuu tämän palvelun avulla. Locator Locatorin avulla voidaan hakea viitteitä muihin palveluihin. Mailer SMTP-palvelu, jonka avulla sisällönhallintaydin voi lähettää sähköpostia. DBC Tietokantapalvelu, jonka avulla voidaan käyttää tietokantaa SQL:llä. UserManager Käyttäjien hallinta järjestelmässä. FileManager Tiedostopalvelu, jolla hallitaan sisällönhallintaytimen tiedostoja. Activator Locatorin apupalvelu, joka voi tarvittaessa käynnistää järjestelmän tarvitsemia palveluita. EventManager Mahdollistaa sen, että palvelut voivat lähettää toisilleen viestejä. Log Tämän avulla palvelut voivat kirjoittaa lokiin tietoja toiminnastaan. ProcessQueue Jonopalvelu, jonka avulla käsittelyä tarvitsevat sisällöt kirjataan jonoon. ErrorHandler Palvelut voivat ilmoittaa sattuneista virhetilanteista ErrorHandlerille.