TAMPEREEN TEKNILLINEN YLIOPISTO Tietotekniikan osasto

HENRI BRAGGE SHDSL-PTELAITTEEN WEB-HALLINTASOVELLUS

Aihe hyvksytty osastoneuvoston kokouksessa 12.2.2007 Tarkastaja: Professori Pekka Loula (TTY)

Alkulause
Olen tehnyt diplomityn toimiessani ohjelmistokehittjn Design Combus Oy:n palveluksessa Tampereella. Ty ksittelee graafisen kyttliittymn luomista yrityksen tuoteprojektiin ja sen tarkoitus on helpottaa tuotteen kytt. Kiitn esimiestni Markku Lindelli projektin toimeksiannosta, tyn ohjaajaa Petri Ahosta asiantuntevasta opastuksesta ja tyn tarkastajaa professori Pekka Loulaa arvokkaista neuvoista.

Tampereella 1.4.2007

Henri Bragge

Itsenisyydenkatu 7-9 A 25 33100 Tampere Puh: +358 50 3086784 E-mail: henri.bragge@gmail.com

Sisllysluettelo
Alkulause.......................................................................................................................... i Sisllysluettelo ................................................................................................................ ii Tiivistelm...................................................................................................................... iv Abstract........................................................................................................................... v Kytetyt lyhenteet ......................................................................................................... vi 1 2 Johdanto.................................................................................................................. 1 HTTP-palvelinsovellus........................................................................................... 3 2.1 World Wide Web ............................................................................................. 3 HTTP-protokolla ...................................................................................... 3 Dynaaminen web...................................................................................... 5 Palvelimen toiminta ......................................................................................... 6 Prosessien vlinen kommunikaatio .......................................................... 7 Unix-soketit.............................................................................................. 8 Pyyntn vastaaminen ............................................................................. 9

2.1.1 2.1.2 2.2 2.2.1 2.2.2 2.2.3 2.3 2.4

Prosessimallit ................................................................................................. 10 Palvelimen tietoturva ..................................................................................... 13 HTTP-autentikointi ................................................................................ 13 SSL/TLS................................................................................................. 15 MVC-sovellusarkkitehtuuri ........................................................................... 18

2.4.1 2.4.2 2.5 3

Kohdeymprist ................................................................................................... 22 3.1 3.2 Laitteisto......................................................................................................... 22 Sovellusymprist .......................................................................................... 24 Kyttjrjestelm ................................................................................... 25 Config API ............................................................................................. 26 CLI-hallintasovellus............................................................................... 28 Knnsymprist.................................................................................. 30 Versionhallinta ....................................................................................... 31

3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 4

Palvelinsovelluksen valinta ja vaatimukset ....................................................... 35 4.1 4.2 4.3 Jaotteluperusteet............................................................................................. 35 Palvelinratkaisujen kartoitus .......................................................................... 38 Tarkoitukseen parhaiten sopivat ratkaisut...................................................... 40
ii

4.3.1 4.3.2 4.3.3 5

GoAhead WebServer ............................................................................. 40 Klone ...................................................................................................... 43 Seminole................................................................................................. 46

Suunnittelu ja toteutus......................................................................................... 51 5.1 Kyttliittym ................................................................................................ 51 Suunnitteluperiaatteet............................................................................. 52 Nkymien suunnittelu ............................................................................ 53 Navigointivalikko................................................................................... 56 Painikkeiden toiminnot .......................................................................... 57 Kytettvyystesti .................................................................................... 58 Verkko-ohjelmiston arkkitehtuuri.................................................................. 60 Tietorakenteet......................................................................................... 60 Luokat ja metodit ................................................................................... 62 Integrointi kohdeympristn ................................................................ 69 Vasteen muodostaminen ........................................................................ 70

5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.2 5.2.1 5.2.2 5.2.3 5.2.4 6

Tyn tulokset ........................................................................................................ 74 6.1 6.2 Soveltuvuus loppukyttn............................................................................ 74 Jatkokehitys.................................................................................................... 76

Yhteenveto ............................................................................................................ 78

Lhdeluettelo ................................................................................................................ 80

iii

Tiivistelm
TAMPEREEN TEKNILLINEN YLIOPISTO Tietotekniikan koulutusohjelma Tietotekniikka (Pori) BRAGGE, HENRI: SHDSL-ptelaitteen web-hallintasovellus Diplomity, 82 sivua, 18 liitett Tarkastaja: Professori Pekka Loula Rahoittaja: Design Combus Oy Huhtikuu 2007 Avainsanat: HTTP, palvelin, SHDSL, web UDK: 004.455.2 Verkon ptelaitteet, kuten reitittimet, kytkimet ja modeemit ovat tietoverkkoja yhdistvi laitteita, joiden ominaisuuksiin kuuluu pasiallisesti verkkoliikenteen ohjaaminen, sovittaminen verkosta toiseen ja kommunikointi muiden ptelaitteiden kanssa. Ptelaitteet vaativat kyttnoton yhteydess laitteen haltijalta tai yllpitjlt yleens omaan kyttn sopivien asetusten syttmist. Mys ulkoisten olosuhteiden muutos voi luoda tarpeen laitteen asetusten muuttamiseen tai esimerkiksi laitteen ohjelmiston pivittmiseen. Ptelaitteen tarjoamat mahdollisuudet sen asetusten hallintaan riippuvat sen sovellusympristst, mutta yleisimmin kytetn komentorivipohjaista tai web-pohjaista hallintasovellusta tai nit kahta rinnakkain. Diplomityss ksitelln SHDSL (Symmetric High-speed Digital Subscriber Line) ptelaitteeseen toteutettavan web-pohjaisen hallintasovelluksen kehityst ja kehityksess esiintyneit haasteita. Tyss keskitytn erityisesti suunnittelussa esiintyneiden ongelmien taustateorioiden selvittmiseen, joista trkeimmt ovat HTTPpalvelinsovelluksen toiminta sek kohdeympristn laitteiston ja sovellusympristn ominaisuudet. Tyss ksitelln mys kehitetyn hallintasovelluksen rakennetta, toimintaa ja jatkokehitysmahdollisuuksia. Ennen sovelluksen toteutusta on syyt kyd lpi palvelinta koskeva taustateoria, toteutuksen kohdeymprist ja tutkia jo toteutettuja sovelluskehyksi, hallintasovelluksia ja web-palvelimia. Nin voidaan hydynt jo olemassa olevaa tietmyst ja varmistaa sovelluksen ajanmukaisuus ja soveltuvuus kohdeympristn. Sovelluksen laatiminen osoittautui haastavaksi, koska sille asetetut vaatimukset monipuolisuuden ja yleiskyttisen rakenteen suhteen ja samalla kohdeympristn asettamat suorituskykyvaatimukset vaativat sovelluksen rakenteen huolellista suunnittelua. Kytnnss lopullista sovellusta edelsi useita prototyyppej, joista muotoutui hiljalleen halutun kaltainen ohjelmisto.

iv

Abstract
TAMPERE UNIVERSITY OF TECHNOLOGY Department of Information Technology Information Technology (Pori) BRAGGE, HENRI: Web management software for an SHDSL terminal device Master of Science Thesis, 82 pages, 18 enclosure pages Examiner: Professor Pekka Loula Funding: Design Combus Ltd April 2007 Keywords: HTTP, server, SHDSL, web UDK: 004.455.2 Network terminal devices, like routers, switches and modems are devices that interconnect computer networks. Their main features include controlling and adapting the network traffic and communication to other network devices. Terminal devices often require management from the owner or the administrator of the device. Management includes tasks like configuring the initial settings, configuring settings to adapt to changes in the environment or upgrading the devices software. Terminal devices offer different management possibilities, depending on the application environment of the device. Most devices offer terminal or Web-based management applications or both of them. This thesis describes the developing of Web-based management software for an SHDSL (Symmetric High-speed Digital Subscriber Line) terminal device. The main emphasis is on the theory behind the problems confronted, the most important of which are the operation of HTTP server software and the software and hardware environments of the target device. The thesis also describes the structure, operation and further concerns of the management software. Before the implementation it is essential to study Web server theory and the features of the target environment and to consider frameworks, management software and Web servers created before. Thus it is possible to utilize existing knowledge and to ensure that the implemented application is modern and appropriate. The implementation phase was challenging and demanded careful planning because of the requirements for versatile and general-purpose software and the limitations of the target environment. The final product was preceded by numerous different prototypes, from which the application slowly took its final shape.

Kytetyt lyhenteet
ADSL AMPED API ASP BSD CGI CLI CPU CSS CVS DDR DES DMA DNS DSLAM DoS EEPROM FIFO FPGA GPL HTML HTTP I2C I/O IETF IP IPC ISAPI J2EE JTAG LED MD5 MFC MII MIPS MIT MVC PCI PHP PKI RAM RC2 RC4 RFC RJ45 RJ6/6 Asymmetric Digital Subscriber Line Asymmetric Multi-process Event-driven Application Programming Interface Active Server Pages Berkeley Software Distribution Common Gateway Interface Command Line Interface Central Processing Unit Cascading Style Sheets Concurrent Versions System Double Data Rate Data Encryption Standard Direct Memory Access Domain Name System Digital Subscriber Line Access Multiplexer Denial-of-Service Electrically Erasable Programmable Read Only Memory First In, First Out Field-programmable gate Array GNU Public License Hypertext Markup Language Hypertext Transfer Protocol Inter-Integrated Circuit Input/Output Internet Engineering Task Force Internet Protocol Inter-process Communication Internet Server Application Programming Interface Java 2 Platform Enterprise Edition Joint Test Action Group Light-emitting Diode Message-Digest algorithm 5 Microsoft Foundation Classes Media-independent Interface Microprocessor without Interlocked Pipeline Stages Massachusetts Institute of Technology Model-View-Control Peripheral Component Interconnect PHP: Hypertext Preprocessor Public Key Infrastructure Random Access Memory Rivest Cipher 2 Rivest Cipher 4 Request for Comments Registered Jack 45 Registered Jack 6/6
vi

ROM RSA RSS SAPI SHA SHDSL SNMP SPED SPI SQL SSL STDIN STL SVN TCP TLS UART UDP URI URL VLAN W3C WWW XSL

Read-only Memory Rivest, Shamir, Adleman algorithm Really Simple Syndication Server Application Programming Interface Secure Hash Algorithm Symmetric High-speed Digital Subscriber Line Simple Network Management Protocol Single-process Event-driven Serial Peripheral Interface Structured Query Language Secure Sockets Layer Standard Input Standard Template Library Subversion Transfer Control Protocol Transport Layer Security Universal Asynchronous Receiver/Transmitter User Datagram Protocol Uniform Resource Identifier Uniform Resource Locator Virtual Local Area Network World Wide Web Consortium World Wide Web Extensible Stylesheet Language

vii

1 Johdanto
Verkon ptelaitteen hallintamahdollisuus ovat vlttmtn osa laitetta, koska laitteet toimivat vain harvoin niihin valmiiksi tallennetuilla oletusasetuksilla. Yrityksille suunnitellut ptelaitteet, kuten tmn projektin kohdeympristn oleva SHDSLptelaite, eroavat esimerkiksi yksityisasiakkaille suunnatuista ADSL (Asymmetric Digital Subscriber Line) modeemeista siten, ett niiden hallinnasta vastaava kohderyhm voidaan yleens olettaa olevan yksityisasiakasta teknisesti valveutuneempi. Tllin niin kutsuttujen velho-ominaisuuksien lisminen ja ylimristen teknisten tietojen piilottaminen voidaan jtt vhemmlle huomiolle. Se ei kuitenkaan vhenn hyvn kytettvyyden merkityst. Pinvastoin, alansa asiantuntijaa kytettvyysongelmat saattavat hirit enemmn kuin satunnaista, vain harvoin laitteen ominaisuuksia ksittelev kyttj. Lisksi opittavuus ja muistettavuus ovat trkeit ominaisuuksia kyttjn tasosta riippumatta. Kytettvyyden lisksi sulautetun laitteen verkko-ohjelmiston suunnitelussa on otettava huomioon kaksi trke seikkaa: kohdeympristn kriittisyys ja sovelluksen joustava suunnittelu. Sulautetun laitteen muistikapasiteetti ja laskentateho on rajoittunut, joten ohjelman on oltava kevyt ja huomioitava mys laitteella olevat muut, ehkp sit trkemmt prosessit. Se ei saa myskn virheen sattuessa lopettaa toimintaansa eik missn tilanteessa olla vaaraksi laitteen toimintakyvylle. Ohjelman on syyt olla joustava, koska tulevaisuuden tuoteprojektien tullessa ajankohtaiseksi on todennkist, ett vastaavan kaltaista sovellusta tarvitaan mys niiss. Tyss perehdytn edell mainittuihin suunnitteluperusteisiin ja niiden taustalla olevaan teoriaan, joiden perusteella luodaan tyss esiteltv web-hallintasovellus. Sovelluksen lopullisena tavoitteena on olla helppokyttinen, uudelleenkytettv ja hyvin kohdeympristns sulautuva. Sovelluksesta ei tule Iris 440 SHDSLptelaitteen hallintamahdollisuuksista ainoa, vaan sen rinnalla toimii mys aikaisemmin toteutettu komentorivipohjainen CLI (Command Line Interface) hallintasovellus. Lisksi laitteen ominaisuuksia voidaan tarkastella SNMP (Simple Network Management Protocol) managerin avulla. Web-hallintasovelluksen on tarkoitus toimia niden rinnalla, tarjoten kyttjlle graafisen ja helppokyttisen vaihtoehdon laitteen hallintaan. Luku kaksi ksittelee HTTP-palvelimeen liittyv teoriaa: itse protokollaa, prosessien vlist kommunikaatiota, dynaamisen sislln luomista, prosessimalleja, tietoturvaa ja sovellusarkkitehtuureja. Luku kattaa projektissa tarvittavan palvelinsovelluksia koskevan taustateorian. Luvussa ksiteltv teoria on trke, jotta voidaan ymmrt toteutettavan sovelluksen toimintaperiaatteet ja sen kommunikointimenetelmt kyttjn ja muun ympristn kanssa. Luvussa kolme tarkastellaan projektin kohdeymprist, joka on yrityskyttn suunniteltu Iris 440 SHDSL-ptelaite. Laitteisto- ja suorituskykyseikkojen lisksi paneudutaan laitteen kyttjrjestelmn ja sovellusympristn sek jo toteutettuun, web-hallintasovelluksen rinnalla toimivaan CLI-hallintasovellukseen. Uutta sovellusta toteutettaessa on syyt tarkastella edellisen ratkaisun heikkouksia ja vahvuuksia ja

mahdollisuuksien mukaan uudelleenkytt sille luotua ohjelmakoodia. Sovelluksen kehitysymprist koskien tutustutaan kytettviin knnstykaluihin ja versionhallintamenetelmiin. Luku nelj esittelee projektin esitutkimusvaiheessa suoritetun palvelinkartoituksen. Siin tarkastellaan joukkoa HTTP-palvelinsovelluksia, jotka voisivat soveltua hallintasovelluksen ytimen toimivan palvelimen tehtvn. Palvelinsovellukset jaotellaan mrttyjen jaotteluperusteiden mukaisesti, ja niiden joukosta valitaan thn tarkoitukseen parhaiten sopivin vaihtoehto. Jaotteluperusteiden pohjalla hydynnetn edeltviss luvuissa muodostunutta ksityst palvelinsovelluksen vaatimuksista sen tarjoamien ominaisuuksien ja toimintatavan suhteen. Luku viisi ksittelee hallintasovelluksen suunnittelua ja toteutusta. Luvun ppaino on sovelluksen nkymien suunnittelussa ja sisisess toiminnassa. Sovelluksen toteutusta ei ksitell vaihe vaiheelta, vaan keskitytn lhinn lopputuloksen tarkasteluun sopivasti rajattuna. Luku etenee tyjrjestyst vastaavalla tavalla ksitellen ensin kyttliittymn ja sen toimintojen suunnittelua, sen jlkeen verkko-ohjelmiston luokka-arkkitehtuuria ja luokkien sisist toimintaa, ja lopuksi palvelimen vasteen muodostusta kytnnss. Luvut kuusi ja seitsemn sisltvt lopputuloksen arviointia sen loppukyttn soveltuvuuden ja jatkokehitysmahdollisuuksien kannalta. Erityisesti pohditaan lopputuloksen siirrettvyytt mahdollisia tulevia tuoteprojekteja ajatellen.

2 HTTP-palvelinsovellus
HTTP-palvelinsovellus on sovellus, joka kuuntelee palvelimen HTTP-porttia (yleens portti 80) ja vastaa siihen tuleviin pyyntihin. Ennen vasteen lhettmist tapahtuu pyynnn vastaanottamisen jlkeen useita eri vaiheita, joita ovat pyynnn jsentminen, ksittely, tarvittavan datan haku palvelimelta ja vasteen muodostaminen. Tss luvussa ksitelln nit vaiheita ja muita palvelinsovelluksen toimintaan liittyvi seikkoja. Luvussa kerrotaan ensin kommunikointiin kytettvst HTTP-protokollasta ja sen jlkeen palvelimen toiminnasta kyttjrjestelmn nkkulmasta. Lisksi ksitelln palvelinsovelluksen tietoturvaa ja lopuksi verkko-ohjelmiston suunnittelussa kytettvi sovellusarkkitehtuureita.

2.1 World Wide Web

World Wide Web nki pivnvalon kevll 1989, jolloin Tim Berners-Lee julkaisi ehdotuksensa uudesta tavasta esitt ja yhdist tietoa. Tm aloitti digitaalisessa tiedonsiirrossa uuden aikakauden, joka resurssien yhtenisen tunnistamisen ja jakamisen sek hypertekstin avulla mahdollisti nen, kuvan, tekstin ja muun tiedon jakamisen graafisilla selaimilla. Vlitettvn tiedon monipuolisuus loi nopeasti tarpeen mys tiedon dynaamista luomista ja ksittely varten. Nykyn se mahdollistaa interaktiiviset sovellukset WWW-palvelimilla, joiden kytt selaimella internetin yli on yht helppoa ja nopeaa kuin perinteisill sovelluksilla paikallisesti.

2.1.1 HTTP-protokolla
HTTP on WWW:ss kytetty tiedonsiirtoprotokolla, jonka avulla asiakas ja palvelin neuvottelevat keskenn. HTTP:n kehitti W3C (World Wide Web Consortium) ja IETF (Internet Engineering Task Force), ja siit kytetn tll hetkell yleisimmin versiota HTTP/1.1, jonka mrittelee RFC 2616 [Ber99]. Eri versiot ovat taaksepin yhteensopivia, ja versio 1.1 sislt parannuksia, jotka tehostavat HTTP-liikennett ja tarjoavat paremman kontrollin WWW-sivujen ulkonkn [Pus01, s. 127]. HTTP toimii sovelluskerroksella, ja sen alapuolella kytetn yleens TCP-protokollaa, joka tarjoaa HTTP:lle luotettavan ja yhteydellisen tiedonsiirron. Tm alikohta perustuu lhteisiin [Ber99] ja [Pel98, s. 19-21]. Pyynt HTTP mrittelee joukon metodeja ja niden vastauskoodeja, joita kytetn kyttjn ja palvelimen vliseen kommunikointiin. Metodien avulla kyttj ilmaisee palvelimelle mit halutaan tehd ja sen yhteydess annetaan yleens mys kohteen URI. Palvelimen lhettmn vastaukseen puolestaan liittyy aina vastauskoodi, joka kertoo vasteen tilan. Yksi yleisimpi HTTP-metodeja on GET, jota kytetn datan noutamiseen mritellyst URI:sta. URI:n lisksi pyyntn liitty yleens otsikkokentti, jotka voivat sisltv tietoa protokollaversiosta tai asiakasohjelmistosta. Esimerkki GET-pyynnn muodosta on esitelty kuvassa 2-1. Kuvan ensimmisell rivill on ensin haluttu metodi, sitten pyydettv URI ja lopuksi kytetty HTTP-versio. Toisella rivill on pyynnn

kohde, jonka tarkoitus on erottaa toisistaan samaan IP-osoitteeseen viittaavat DNSnimet. Vastaavassa muodossa olevia nimi-arvo-pareja voi olla otsikossa mys enemmn.
GET /rfc/rfc2616.txt HTTP/1.1 Host: www.ietf.org

Kuva 2-1. GET-pyynt.

GETmetodin lisksi muita yleisi metodeja ovat POST ja HEAD. RFC 2616:n mrittelemt metodit nkyvt selitteineen taulukossa 2-1. Selitteest selvi metodin mahdollisesti tarvitsema lismre, joka on tyypillisesti kohteen URI.

Taulukko 2-1. HTTP-metodit.

Metodi OPTIONS GET HEAD POST PUT DELETE TRACE CONNECT Selite Mritetyn URI:in kommunikaatioasetusten haku. URI:lla identifioidun tiedon haku. Sama kuin GET, mutta haetaan vain otsikkokentt. Tiedon lhetys URI:lla identifioituun kohteeseen. Tiedon tallentaminen URI:lla identifioituun kohteeseen. Poista URI:lla identifioitu kohde. Pyynnn heijastaminen takaisin lhettjlle. Dynaamisen tunneloinnin kyttn varattu metodi

Vaste Kun HTTP-palvelin vastaanottaa pyynnn, se palauttaa kyttjlle pyydetyn URIosoitteen ilmoittaman objektin, eli kuvan 2-1 esimerkiss rfc2616.txt-tiedoston. Koska HTTP ei mrittele lhetettv sislt, se voi olla mit tahansa digitaalisessa muodossa esitetty selkokielist tai binrimuotoista dataa. Kuvassa 2-2 on esimerkki palvelimen lhettmst vasteesta. Ensimminen rivi kertoo pyynnn tapaan kytettvn protokollaversion, jonka jlkeen on vastauskoodi eli tss tapauksessa 200. Lisksi vasteessa nkyy pivmr- ja palvelintietoja, sek tietoa sislln muodosta ja koosta.

HTTP/1.1 200 OK Date: Tue, 07 Nov 2006 17:31:44 GMT Server: Apache/2.0.52 (Red Hat) Last-Modified: Fri, 28 Jul 2006 14:17:09 GMT Etag: "a963bb-27a-f7c42340" Accept-Ranges: bytes Content-Length: 634 Connection: close Content-Type: text/plain; charset=UTF-8

Kuva 2-2. GET-vaste.

Vastauskoodit ovat lajiteltu merkityksens mukaan samoihin satalukuihin kuuluviin tilaperheisiin. Informatiiviset tilat kuuluvat ryhmn 100, onnistumista ilmaisevat ryhmn 200, uudelleenohjausta ryhmn 300, kyttjn virhett ryhmn 400 ja palvelimen virhett ilmaisevat tilat ryhmn 500. Yleisimpi vastauskoodeja ovat muun muassa 404 Not Found, 500 Internal Server Error ja 503 Service Unavailable.

2.1.2 Dynaaminen web

Pelkstn staattisen tiedon esittminen WWW-sivuilla voi olla sellaisenaan informatiivista, mutta usein tarvitaan jonkinlaisen interaktiivisuuden tarjoamista kyttjlle. Se voi tarkoittaa erilaisia painikkeita, lomakkeita ja muita toimintoja, joiden avulla kyttj voi vaikuttaa sivun tarjoamaan sisltn muutoinkin kuin vain yksiselitteisten tilasiirtymien avulla. Tmn toteuttamiseksi tarvitaan jokin logiikka, joka vastaanottaa kyttjn antamat sytteet ja luo tmn perusteella sille vasteen. Tm alikohta ksittelee muutamia keinoja palvelimen logiikan toteuttamiseen, ja perustuu lhteisiin [Pel98, s. 478 ja 660-661]. Common Gateway Interface (CGI) CGI [CoRo99] on palvelimen ja palvelimella suoritettavien ohjelmien vlille mritelty tiedonsiirtorajapinta. CGI mahdollistaa dynaamisen sislln muodostamisen palvelimen kyttn rajapinnan kautta palvelimella ajettavien sovellusten avulla. Kyttjlle lhetettvlle sivulle voidaan koota tietoa esimerkiksi skriptikieli apuna kytten. CGI:n etuja ovat yksinkertaisuus, erilliset prosessit ja riippumattomuus palvelimen ohjelmointikielest ja arkkitehtuurista. Kytnnss tiedon vlittminen CGI-rajapinnan kautta onnistuu erilaisilla ympristmuuttujilla ja standard-IO-datavirralla. Vaikka erilliset prosessit voidaan toisaalta laskea eduksi, on niill mys haittapuolensa. CGI kynnist jokaiselle sille tarkoitetulle pyynnlle oman prosessinsa, joka vastaa pyynnn ksittelyst ja joka suljetaan ksittelyn ptytty. Tm menettely kuluttaa palvelimen muistia ja vaikuttaa mys suorituskykyyn johtuen jokaiseen pyyntn liittyvst prosessin kynnistmisest ja sulkemisesta. Monta samanaikaista prosessia voi aiheuttaa mys poissulkemis- ja synkronointiongelmia, jos eri prosessit ksittelevt saman muistialueen muuttujia tai yhteist tietolhdett. Koska CGI on riippumaton ohjelmointikielest, voidaan CGI-sovelluksia toteuttaa mill tahansa kielell, kunhan palvelimen jrjestelmalusta sit vain tukee. Tavallisimmin CGI-sovellus on toteutettu jollakin tulkattavalla kielell, kuten Perl, Python tai Ruby.
5

Mys knnettvill kielill toteuttaminen onnistuu, jolloin voidaan kytt esimerkiksi kieli C, C++ tai Java. FastCGI CGI:n korvaajaksi kehitetty FastCGI pyrkii vastaamaan edeltjns ongelmiin etenkin muistinkytn suhteen. Se silytt kuitenkin CGI:n hyvt puolet eli yksinkertaisuuden ja riippumattomuuden ohjelmointikielest. Toisin kuin CGI:ss, FastCGI:ss prosessit ovat pysyvi, joten yhden pyynnn ksiteltyn ne jvt odottamaan seuraavaa [OM96]. FastCGI pyrkii mys vhentmn pyyntjen ksittelyyn tarvittavien prosessien mr suorittamalla aikaa vaativat I/O-operaatiot palvelinsovelluksella. FastCGI yhdist tiedon vlittmiseen tarvittavat ympristmuuttujat ja standard-IOdatavirran yhdeksi datavirraksi, jota voidaan vlitt paikallisille prosesseille Unixsoketeilla ja etkoneilla toimiville prosesseille TCP-protokollalla. API (Application Programming Interface) rajapinnat Korjatakseen muiden sovellusrajapintojen ongelmia, monet palvelimet tarjoavat mys omia rajapintojaan sovelluksien toteuttamiseseen. Tunnetuimpia ovat Microsoftin ISAPI (Internet Server API) [MS95] ja Apache API [ASF05]. Mys luvussa nelj esiteltvt GoAhead WebServer [GA00], Klone [KL07] ja Seminole [GS06a] tarjoavat sovellusohjelmointiin omat rajapintansa. API-sovellusten trkein etu on nopeus, sill palvelinsovellukseen linkitetyt ohjelmat toimivat huomattavasti nopeammin kuin esimerkiksi CGI-ohjelmat, koska ohjelma toimii palvelinprosessin yhteydess ja sit ei kynnistet ja suljeta jokaiselle pyynnlle erikseen. Palvelin-API:t tarjoavat usein mys laajemman toiminnallisuuden kuin CGIrajapinta, koska pyynnn ksittelyn aikana on mahdollista vaikuttaa mys itse palvelimen toimintaan. Palvelimien tarjoamien API:en haittapuolina on usein ohjelmointirajapinnan monimutkaisuus ja sen rajoittuneisuus tietylle ohjelmointikielelle ja arkkitehtuurille. Koska rajapinnat noudattavat tyypillisesti itse palvelimen toteutuskielt, on ne useimmin toteutettu C- tai C++-kielell. Tllin sovellusohjelmoijalla ei ole toteutuskielen suhteen paljoa valinnanvaraa. Monimutkaisuutta lis mys APItoteutusten epyhteensopivuus, koska toteutukset poikkeavat usein laajalti toisistaan. Tm voi aiheuttaa verkko-ohjelmiston siirrettvyysongelmia, mikli sen toteutus on vahvasti sidoksissa kytettvn palvelinsovelluksen rajapintaan. Lisksi ohjelmointirajapinnat ovat vain harvoin avoimia tai edes ilmaisia, kun taas CGImaailmassa avoimien vaihtoehtojen mr on lukematon.

2.2 Palvelimen toiminta

Erilaiset HTTP-palvelimet kyttvt palvelun tarjoamiseen erilaisia menetelmi, mutta eri vaiheiden perusperiaatteet pyynnn vastaanottamisesta vasteen lhettmiseen ovat yleens samankaltaisia. Unix-pohjaiset HTTP-palvelimet kyttvt psntisesti hydykseen Unixin tarjoamia perusmenetelmi prosessien vliseen kommunikaatioon sek verkon yli tapahtuvaan kommunikaatioon. Nit menetelmi voivat kytt toiminnot kuten tiedoston luku ja kirjoitus tai verkkokommunikaatio sokettiyhteyden

avulla. Tss kohdassa ksitelln prosessien vlist kommunikaatiota ja soketteja sek niiden merkityst HTTP-palvelimissa. Lisksi esitelln lyhyesti HTTP-pyyntn vastaaminen Unixin jrjestelmkutsujen avulla.

2.2.1 Prosessien vlinen kommunikaatio

Prosessien yleisin menetelm keskiniseen kommunikaatioon on putkien kyttminen. Putki tarkoittaa yksisuuntaista kommunikointikanavaa, joka mahdollistaa tavuvirran vlittmisen kahden prosessin vlill. Putket toimivat FIFO-periaatteella, eli ulos tuleva data luetaan samassa jrjestyksess kuin se on lhetetty. Putken lpi lhetettv datavirta ei noudata mitn protokollaa, vaan kommunikointiin kytettv protokolla on mriteltv itse. Jrjestelm huolehti datan vlittmisen luotettavuudesta, eli siit ett dataa ei hvi siirrettess. [Ker02a] Putki luodaan kyttmll Unixin pipe()-jrjestelmkutsua. Tmn avulla saadaan kaksi tiedostokuvainta, joista toista voidaan kytt putken lukemiseen ja toista kirjoittamiseen. Nist voidaan kuitenkin kytt kerrallaan vain toista, jolloin yhden prosessin on tarkoitus kytt putken lukemiseen ja toisen siihen kirjoittamiseen tarkoitettua kuvainta. Koska putket ovat yksisuuntaisia, tarvitaan kaksisuuntaiseen kommunikointiin kaksi putkea. Tm tarkoittaa kytnnss sit, ett kahden prosessin vlisess kommunikaatiossa yksi prosessi hydynt kahta putkea, joista yht se kytt tiedon lhettmiseen ja toista vastaanottamiseen. Siirtosuunnan mrittminen tapahtuu siis suuntaa vastaavaa tiedostokuvainta kyttmll. Kun vastapuolena oleva prosessi kytt putkia vastaavalla tavalla, voidaan niill mahdollistaa kaksisuuntainen kommunikaatio prosessien vlill. Kaksisuuntaisen kommunikaation toteuttaminen putkien avulla vaatii erityist tarkkuutta, koska ne joutuvat helposti lukitustilaan (deadlock). Tm tarkoittaa tilannetta, jossa yksi tai useampi prosessi lukittuu odottaessaan jotakin tapahtumaa toiselta prosessilta tai jonkin resurssin vapautumista. Esimerkki lukittumisesta on tilanne, jossa kahden prosessin vlill on kaksisuuntainen yhteys, ja molemmat prosessit asettuvat lukemaan lukemista vastaavan putken tiedostokuvainta. Tllin dataa ei milloinkaan saavu, vaan prosessit yrittvt lukea toistensa lhettm dataa ikuisesti. Yleisimmin lukittumista tapahtuu estvi (blocking) operaatioita kytettess, koska ne palaavat yleens vasta kun operaatio onnistuu tai tapahtuu virhe. Prosessien lukittumisen mahdollisuus voidaan kuitenkin minimoida suunnittelemalla ohjelmat siten, ettei lukitustilanteita pse tapahtumaan. Unix tarjoaa mys joitakin jrjestelmkutsuja tmn ongelman ehkisemiseen. Esimerkiksi select()-kutsulla voi valita aktiivisen tiedostokuvaimen siten, ett kutsulle sytetn ryhm valvottavia lukutai kirjoituskuvaimia ja aika, jonka jlkeen niiden valvonta lopetetaan. Sen avulla prosessi voi esimerkiksi valvoa ryhm verkkoyhteyksi, ja arvioida milloin se voi lukea jostakin niist ilman estmist [RuCo01, s. 154].

2.2.2 Unix-soketit
Unix-jrjestelmiss tietoliikenneprotokollien sovellusrajapintana kytetn useimmiten soketteja, jotka ovat mritelty kytnnss joko Berkeley, System V tai POSIXstandardin mukaisesti. Ne tarjoavat sovellusohjelmoijalle psyn kuljetuskerrokselle TCP- tai UDP-protokollan tai suoraan siirtoyhteyskerrokselle IP-protokollan muodossa. Tss kappaleessa on hydynnetty Unix-jrjestelmkutsujen manuaalisivuja [OG01]. Soketti mritelln muodollisesti sovellusohjelman kommunikaation ptepisteeksi ja sen alla olevaksi protokollapinoksi. Kytnnss tm tarkoittaa sit, ett ohjelma voi soketin avulla lukea ja kirjoittaa tietoa verkon yli ja hallita alla olevaa verkkoprotokollaa asettamalla soketille erilaisia asetuksia. Sovellusohjelmoijan kannalta soketti on yleisimmin kaksisuuntainen kommunikointikavana verkon yli, jolle mritetn kytettv portti ja protokolla. Sokettia voidaan teknisesti verrata levyoperaatioita varten kytettviin tiedostokuvaimiin. [Ker02b] Soketin luomiseen ja kyttmiseen hydynnetn erilaisia jrjestelmkutsuja, joista yleisimmt ovat socket(), bind(), connect(), listen(), accept(), send(), recv() ja close(). Seuraavaksi havainnollistetaan soketin toimintaa niden kutsujen avulla. Unix sislt mys muita sokettien hallintaan liittyvi jrjestelmkutsuja, mutta edell mainitut lienevt oleellisimmat soketin elinkaaren ja toiminnan havainnollistamisen kannalta. Kuva 2-3 selkeytt jrjestelmkutsujen jrjestyst palvelimen nkkulmasta. Kyttjn nkkulmasta lohkokaavio on melko samanlainen, mutta listen()- ja accept()-kutsujen sijaan yhteyden ottamiseen kytetn connect()-kutsua ja tyypillinen tiedonsiirto-operaatiot recv() ja send() tapahtuvat pinvastaisessa jrjestyksess. Kutsuille on yhteist niiden palauttama numeroarvo, jota tarkastelemalla voidaan ptell operaation onnistuminen.

Kuva 2-3. Verkko-operaatio sokettien avulla palvelimen nkkulmasta.

Soketin luominen tapahtuu Unixin socket()-jrjestelmkutsulla, jonka parametreiksi annetaan kytettv osoiteperhe, sokettityyppi ja protokolla. Osoiteperheen kytetn yleens IP-osoitteille tarkoitettua AF_INET-osoiteperhett. Sokettityyppin voidaan kytt esimerkiksi SOCK_STREAM TCP-liikennett ja SOCK_DGRAM UDPliikennett varten. Protokollana kytetn yleens nollaa, joka tarkoittaa kytettvn sokettityypin oletusprotokollaa. Kun soketti on luotu, sit voidaan ksitell kutsun palauttaman kuvaimen avulla. Dataa voidaan ksitell tarvittaessa mys sellaisenaan ilman protokollaa. Kun soketti on luotu, se pit sitoa haluttuun yhteyteen. Tmn avulla mritetn paikallinen osoite ja etosoite, eli ptepisteet, joiden vlill soketilla halutaan kommunikoida. Tm tapahtuu bind()-kutsulla, jonka parametreiksi tulee sidottava soketti, osoite ja osoitteen pituus. Kuuntelevan portin tapauksessa yhteyden etosoite

jtetn yleens avoimeksi. Osoitteen muodon on noudatettava soketin kyttm osoiteperhett, ja IP-osoitteen tapauksessa siin on mritelln kytettv IP-osoite ja portti. Seuraavaksi on valittava, halutaanko ottaa yhteys toiseen ptepisteeseen vai asetetaanko soketti kuuntelutilaan. Yhteys toiseen ptepisteeseen otetaan connect()kutsulla, joka tarvitsee parametreikseen kytettvn soketin, osoitteen ja osoitteen pituuden. Kuuntelutila voidaan asettaa listen()-kutsulla, jonka parametrein on haluttu soketti ja backlog-arvo, joka tarkoittaa yhteyspyyntjonon maksimipituutta. Sitomisen ja yhteyden ottamisen tai yhteyspyynnn jlkeen sokettia voidaan kytt datan lukemiseen ja kirjoittamiseen. Thn kytetn recv()- ja send()-kutsuja, joiden parametreiksi annetaan kytettv soketti, merkkipuskuri, puskurin pituus ja lisasetukset. Luettaessa merkkipuskuriin tallennetaan saatu data ja kirjoittaessa siit luetaan lhetettv data. Kuvassa 2-3 palvelin kytt recv()-kutsua pyynnn lukemiseen ja send()-kutsua vasteen lhettmiseen. On huomattava, ett recv()- ja send()-kutsut ovat tarkoitettu yhteydellisen TCPliikenteen kyttn. Datagrammipohjaisen UPD-liikenteen vlittmiseen kytetn sendto() ja recvfrom()-kutsuja, jotka vaativat lisparametrikseen viel vastaanottajan tai lhettjn osoitteen. UDP:ll liikennitess ei kytet connect()ja listen()-kutsuja, koska lhettminen ja vastaanotto tapahtu ilman erillist yhteydenmuodostusta. Kun yhteys halutaan lopettaa, kutsutaan close()-kutsua. Tmn ainoa parametri on suljettava soketti. Close() on yleiskyttinen tiedostokuvaimen sulkemiseen tarkoitettu kutsu, joten sit voi kytt soketin lisksi esimerkiksi tiedostokuvaimen sulkemiseen.

2.2.3 Pyyntn vastaaminen

Yhteydenmuodostus palvelimelle alkaa kyttjn tekemst komennosta, kun hn kirjoittaa selaimeen haluamansa palvelimen osoitteen. Tmn jlkeen HTTPasiakasohjelma luo palvelinohjelmistoon TCP-yhteyden [Pel98, s. 19]. Yhteyden avauduttua vlitetty HTTP-pyyntotsake mritt pyydetyn sislln alikohdassa 2.1.1 esitetyll tavalla. Jos otsakkeessa pyydetty data on staattista, esimerkiksi HTMLtiedosto, se voidaan hakea palvelimen tiedostojrjestelmst. Muussa tapauksessa palvelin generoi sislln dynaamisesti. Yleens ensimminen palvelinohjelman suorittama vaihe on asettua kuuntelemaan haluttua TCP-sokettia. Kuunteleminen tarkoittaa porttiin tulevien yhteyspyyntjen vastaanottamista, jonka jlkeen pyynt hyvksytn ja luetaan sen pyyntotsake. Sen jlkeen suoritetaan tarvittavat vaiheet vasteen laatimiseksi. Tm voi tarkoittaa esimerkiksi levylt lukemista tai tietokantakutsujen suorittamista. Yksinkertaisimmillaan vasteen laatiminen tarkoittaa levylle tallennetun HTMLtiedoston lhettmist, mutta dynaamiset verkko-ohjelmistot edellyttvt monimutkaisempaa logiikkaa, esimerkiksi jollain kohdassa 2.1.2 ksitellyll tavalla.

Palvelimen toiminnan suunnittelussa on trke ottaa huomioon eri operaatioiden estminen, kuten alikohdassa 2.2.1 mainittiin. Yleisesti ottaen operaatiot, jotka lukevat dataa tai vastaanottavat yhteyksi estvt. Estminen tapahtuu esimerkiksi Unixin accept()-kutsun yhteydess, kun hyvksyttv yhteys ei ole viel saapunut tai luettaessa tietoa read()-kutsulla. Tehokkaan HTTP-palvelimen pit ottaa estminen huomioon siten, ettei se aiheuta koko palvelimen pyshtymist, joka nkyisi kyttjlle heikkona vasteena. Ongelma voidaan ratkaista pyynnille fork()-kutsulla kynnistettvill lapsiprosesseilla, sikeill tai tapahtumapohjaisella suunnittelulla, johon voidaan kytt apuna esimerkiksi aktiivisen tiedostokuvaimen valitsevaa select()-kutsua. Palvelimen eri prosessimalleja ksitelln tarkemmin seuraavassa kohdassa. Kun pyynt on vastaanotettu, sen ksittely voidaan ohjata pyynt vastaavalle lapsiprosessille tai sikeelle, joka suorittaa pyynnn ksittely vastaavat toimenpiteet. Nm voivat olla pyynnn antamien parametrien arvioimista, ja esimerkiksi tietokantakutsujen suorittamista parametrien perusteella. Vaste lhetetn kyttjlle tyypillisesti send()-kutsulla, mink jlkeen soketti voidaan sulkea tai jd odottamaan seuraavaa pyynt.

2.3 Prosessimallit
Tss kohdassa ksitelln erilaisia prosessimalleja HTTP-palvelimen nkkulmasta. Mallien perusperiaatteet ptevt mihin tahansa prosesseihin, mutta tss kohdassa mallien tarkastelun pohjana kytettvt vaiheet tapahtuvat vain ohjelmalla, jolle on ominaista pyynnn vastaanottaminen, prosessointi ja vastauksen lhettminen, aivan kuten HTTP-palvelimella. Tm kohta perustuu lhteeseen [Dru99]. Projektin kannalta palvelinsovelluksen prosessimallilla on merkityst sen muistinkytn ja kohdeympristn integroinnin kannalta. Kyttjrjestelmn nkkulmasta prosessimallit eroavat toisistaan lhinn prosessien mrn suhteen, sill esimerkiksi moniprosessinen sovellus kytt useampaa yhteaikaista prosessia, kun monisikeinen tai SPED-mallinen sovellus prj yleens yhdell. Unix-pohjaisilla kyttjrjestelmill uusien prosessien luomista tehostaa tosin fork()-kutsu ja sen myt datan yhteiskyttn tarkoitettu kirjoituskopiointi (copy on write) [HaJ03, s. 144]. Prosessimallin vaikutus sovelluksen muistikapasiteetin tarpeeseen on siten pieni, koska virtuaalimuistin sivuja varataan muuttujien kytn mukaan, jolloin trkempi muistivaatimukseen vaikuttava tekij on sovelluksen toteutus ja sen todellinen kuormitus. Tst huolimatta pienikin prosessimallin tarjoama muistinsst koettiin projektissa eduksi, mik suosi prosessien mrn minimointia. Erityisen suuri merkitys prosessimallin valinnalla on sen integroinnin helppoudessa projektin kohdeympristn. Kohdeympristss erilaisten sovellusmoduulien aikaa vievien operaatioiden vuorottelu tehdn 3.2.1 esiteltvll tavalla, jossa moduuleja vastaavia tiedostokuvaimia kuuntelemalla. Prosessien mrn lisminen lis prosessikohtaisista resursseista johtuen mys kuunneltavien tiedostokuvaimien mr, joten mys tm seikka tukee kytettvien prosessien mrn minimointia.

10

Moniprosessimalli Moniprosessimallissa kyttjn pyynnlle mritetn prosessi, joka ajaa kuhunkin pyyntn liittyvt perkkiset vaiheet. Prosessi suorittaa kaikki yhteen HTTP-pyyntn liittyvt vaiheet ennen uuden pyynnn hyvksymist. Tm tarkoittaa yleens kytnnss sit, ett yksi prosessi huolehtii pyyntjen vastaanottamisesta ja kynnist nille yksittisest pyynnst huolehtivan aliprosessin (Unix-jrjestelmiss lapsiprosessi). Kun aliprosesseja kynnistetn useita, voidaan palvella useaa HTTPpyynt samanaikaisesti. Jos jokin prosessi asettuu estmn esimerkiksi levy- tai verkkotoiminnon vuoksi, kyttjrjestelm vaihtaa suoritettavaa prosessia, jolloin prosessoriaikaa ei kulu hukkaan. Jokaisella prosessilla on mys oma osoiteavaruutensa, jolloin yhtaikaisten HTTPpyyntjen suorittaminen helpottuu, koska kukin prosessi voi silytt ksiteltvn olevan pyynnn tilatietoa ilman huolta pyyntjen vlisist ristiriidoista. Tosin globaaliin dataan, esimerkiksi vlimuistiin asetettuihin URL:eihin perustuvien optimointien toteuttaminen saattaa olla vaikeaa. Useimmissa HTTP-palvelimissa tarvitaan mys jonkinlaista tietokantaa, jolloin prosessien tekemien pyyntjen, tallennusten ja muiden operaatioiden pit tapahtua tietokannan eheys huomioon ottaen. Tm vaatii yleens poissulkemis- ja synkronointiongelmien ratkaisemisen prosessien vlisen kommunikoinnin avulla. Monisiemalli Monisikeinen palvelin toimii periaatteeltaan samoin kuin moniprosessinen, mutta resurssien sstmiseksi pyyntjen ksittelyst huolehtivat prosessien sijaan sikeet. Kun yksi sie asettuu estmn esimerkiksi I/O-operaation vuoksi, voidaan ohjelman suoritusta jatkaa toisessa sikeess. Prosessin ja sikeen oleellisin ero on resurssien kytss: siekohtaisten resurssien sijaan saman prosessin sikeet jakavat keskenn muun muassa prosessin muistialueen ja tiedostokuvaimet. Tllin tarvittavien resurssien mr pienenee ja kontekstin vaihdot eri sikeiden vlill nopeutuvat. Kunkin sikeen paikalliset muuttujat silyvt omassa pinomuistissaan. Sikeiden ohjaaminen vaatii yleens jaetun tilatiedon hydyntmist ja jaetun dataanpsyn synkronointia. Prosessien tavoin yksi sie suorittaa yhden HTTP-pyynnn vastaanottamisen ja hyvksymisen jlkeen kaikki sen tarvitsemat vaiheet ennen uuden pyynnn hyvksymist. Sikeiden kytt vaatii kyttjrjestelmn tuen, ja sikeistyksest saatu hyty riippuu osaltaan tuen toteutuksesta. Jotkin kyttjrjestelmt tarjoavat mys kyttjalueella toimivia siekirjastoja, jolloin varsinaista kernel-tukea ei tarvita, mutta myskn saadussa hydyss ei pst natiivin sikeistyksen tasolle. Single-process Event-driven (SPED) SPED-malli poikkeaa kahdesta edellisest mallista siten, ett siin jokaiselle HTTPpyynnlle kynnistettvn prosessin tai sikeen sijaan sek pyyntjen vastaaottamisesta ett niiden ksittelyst vastaa yksi prosessi. Tmn palvelinprosessin suoritus pit tapahtua siten, ett se ei missn tilanteessa ajaudu lukitustilaan, jolloin palvelimen

11

toiminta keskeytyisi. Tm edellytt estvien jrjestelmkutsujen kyttmist siten, ett palvelimen tavoitettavuus silyy. Lisksi esimerkiksi estvien I/O-operaatioiden sijaan voidaan kytt niiden asynkronisia vastineita, mikli kyttjrjestelm sellaisia tukee. Unix-jrjestelmiss estvien kutsujen yhteydess on hydyllist kytt select()-kutsua, joka mainittiin alikohdassa 2.2.1. Kutsun periaatteena on, ett muun toiminnan pois sulkevan odottamisen sijaan ne tarkistavat snnllisin vliajoin, ovatko suoritettavat I/O-operaatiot aktiivisia, jolloin prosessoriaikaa ei kulu yhden estvn operaation odottamiseen. Lisksi joillekin estville kutsuille voidaan asettaa lisparametri, joka mr sen palaamaan vlittmsti ja operaation onnistuminen voidaan ptell sen palautearvosta. SPED-palvelimen toiminta perustuu pyyntkohtaisen tilatiedon silyttmiseen, jolloin kukin pyynt voidaan ksitell ositettuna vaihe kerrallaan. Jokaisella iteraatiokierroksella palvelin voi tarkistaa tulevat yhteydet, lhetyspuskurit tai suoritetut tiedosto-operaatiot, ja valita aktiivinen lhde suoritettavaksi. Suorittamisen jlkeen alustetaan kyseisen pyynnn seuraava vaihe, joka voi olla esimerkiksi HTTP-vasteen lhettminen. SPED-palvelimien yksi merkittv ongelma on paljon prosessoriaikaa vievt I/Ooperaatiot, esimerkiksi suuren tiedoston lukeminen. Palvelinprosessi ei saisi yksittist pyynt suoritettaessa asettua estmn, koska tllin uusia pyyntj ei voida vastaanottaa, mik saattaa nky kyttjlle huonona saatavuutena tai vasteaikana. Nykyaikaisissa kyttjrjestelmiss mys monet CPU-, levy- ja verkko-operaatiot voidaan limitt eli suorittaa ositetusti. Tm tehostaa entisestn SPED-palvelimen toimintaa ja etenkin vasteaikaa, mutta ongelmana on vanhemmista kyttjrjestelmist puuttuva tuki. Muun muassa Linuxin kerneli 2.6 kyttviss jrjestelmiss asynkroniset levyoperaatiot ovat vakio-ominaisuutena. Useimmat SPED-palvelimet eivt tuesta huolimatta kyt asynkronisia operaatioita, vaan turvautuvat perinteisiin jrjestelmkutsuihin ja niiden tarjoamaan yhtaikaisuuden hallintaan. Tst johtuen SPED-palvelimia kytetn yleens vain erityissyist niiden tarjoaman muistinsstn vuoksi. Ne soveltuvat erityisen hyvin sulautettuihin jrjestelmiin, joiden muistikapasiteetti on rajoittunut. Asymmetric Multi-process Event-driven (AMPED) AMPED-malli pyrkii hydyntmn tapahtumaohjatun SPED-mallin olennaisia piirteit, eli tilatietoon pohjautuvaa suoritusta ja jaettua muistialuetta, ja tukemaan sit useilla avustavilla prosesseilla tai sikeill. Apuprosesseilla voidaan huolehtia esimerkiksi tarvittavista I/O-operaatioista. Niiden avulla palvelimen vasteaikaa saadaan parannettua, koska estvt levy- ja verkko-operaatiot voidaan hoitaa omissa prosesseissaan sill aikaa, kun tapahtumaohjattu pprosessi hoitaa HTTP-pyynnn ksittelyn muut vaiheet. AMPED-malli pyrkii silyttmn SPED-mallin tehon muissa kuin tiedostonlukuoperaatioissa, mutta vltt sen ongelmat esimerkiksi hitaiden levyoperaatioiden ja asynkronisten levyoperaatioiden jrjestelmtukiongelmien osalta.

12

AMPED-mallia voidaan hydynt kyttjrjestelmien tavanomaisilla menetelmill, joten kyttnoton helppoudesta ja laajasta jrjestelmtuesta ei tarvitse tinki. Unix-jrjestelmiss AMPED kytt standardeja jrjestelmkutsuja kuten read(), write() ja accept() soketteja ja putkia kytettess sek select()- tai poll() kutsua testaamaan I/O-operaation valmistumista. AMPED-mallia kytettess on oleellista mys tiedostojrjestelmn dataanpsyst huolehtiminen, aivan kuten moniprosessi- ja monisiemalleillakin. Vaikka AMPED-malli ei ole yht suosittu kuin muut kohdassa esitellyt prosessimallit, se on vakavasti harkittava palvelinvaihtoehto etenkin sulautetuille jrjestelmille, joissa ohjelmalta vaaditaan hyv suorituskyky pienell kuormituksella.

2.4 Palvelimen tietoturva

Mink tahansa palvelinsovelluksen toteuttamiseen kuuluu usein oleellisena osana tietoturva. WWW-palvelimen tapauksessa se tarkoittaa yleens palvelimen dokumenttien psynvalvontaa ja suurempaa yksityisyytt vaativissa sovelluksissa, kuten pankkipalveluissa, mys siirrettvn tiedon salaamista. Tss kohdassa ksitelln muutamaa projektin aikana yleisimmin esiin tullutta tietoturvamenetelm, jotka liittyvt sek kyttjn autentikointiin ett tiedon salaamiseen. Autentikointimenetelmist kydn lpi HTTP-standardin oma autentikointi ja vahvempaan autentikointiin tarkoitettu SSL (Secure Sockets Layer) ja sen seuraaja TLS (Transport Layer Security). Yleinen tapa vahvan autentikoinnin toteuttamiseen on SSL:n kyttm julkisen avaimen menetelm. SSL- ja TLS-protokollien yhteydess tarkastellaan mys niiden tarjoamia keinoja tiedon salaamiseen. Kohdan ulkopuolelle jvt palvelinkohtaiset tietoturvaratkaisut, joita ovat muun muassa IP-pohjainen kytnvalvonta ja tiedostojrjestelmn avulla toteutettu oikeuksien rajoittaminen. Palvelinsovellukselle voidaan toteuttaa mys oma autentimenetelmns, jolla hallintasovellus voi varmistua kyttjn oikeellisuudesta. Nit seikkoja ksitelln myhemmin palvelimien esittelyn yhteydess luvussa nelj. Lisksi kohdassa ksitelln vain kyttjn ja palvelinsovelluksen vlist tietoturvaa, vaikka turvallista palvelinta toteutettaessa on otettava huomioon mys palvelimen arkkitehtuuri, ohjelmistokoodin turvallisuus ja yrityksen tai organisaation tietoturvallisuus. Kyttjn autentikoinnin perusteella on yleens tarpeen tehd mys jonkinlainen autorisointi, joka mrittelee kyttjn oikeudet palvelimen toimintoihin. SHDSLlaitteen hallintasovelluksessa tm tarkoittaa kyttjkohtaisia laitteen hallintamahdollisuuksia. Autorisointi vaikuttaa tss tapauksessa palvelinohjelmiston sijaan vain toteutettavan verkko-ohjelmiston toteutukseen, joten siihen palataan tarvittavilta osin luvussa viisi.

2.4.1 HTTP-autentikointi
HTTP-standardi esittelee menetelmn yksinkertaiseen psynvalvontaan eli autentikointiin. Standardi sislt kaksi autentikointiskeemaa: yksinkertaisen basicskeeman ja turvallisemman digest-skeeman. IETF on mritellyt nm menetelmt tarkemmin RFC:ss 2617 [Fra99]. Tm alikohta ksittelee HTTP:n tarjoamia
13

autentikointimenetelmi, ja perustuu edell mainitun RFC:n lisksi lhteisiin [Ker98, s. 148-153] ja [Pus01, s. 140-153]. HTTP-autentikointi perustuu kyttjn tunnistamiseen kyttjnimen ja salasanan perusteella, ja sen avulla voidaan suojata palvelimen dokumentteja. Vaikka salasanojen kytt on inhimillisist riskitekijist johtuen heikko autentikointimenetelm, se on riittvn vahva moniin sovelluksiin. Vaativammissa sovelluksissa vasta salasanan kytt jonkin vahvan autentikointimenetelmn, esimerkiksi SSL:n kanssa riitt takaamaan vaaditun tietoturvan. Basic-autentikointi Palvelin voidaan konfiguroida kyttmn basic-autentikointia, joka tehdn yleens palvelimen yleiseen asetustiedostoon, johon mritetn hakemistokohtaisesti kytettv autentikointi ja sallitut kyttjnimet. Kyttjien salasanat voidaan asettaa samaan tiedostoon tai erilliseen salasanatiedostoon, joka yleens niin ikn salataan. Kun kyttj ottaa selainyhteyden suojattuun kansioon palvelimella, palvelin vastaa thn viestill, joka ilmaisee, ett kansioon psy vaatii kyttjn tunnistamisen. Kuva 2-4 esittelee palvelimelta tulevan autentikointipyynnn, kun kytss on basicautentikointi. Siit selvi alikohdasta 2.1.1 tuttujen asioiden lisksi kyttrajoitusta ilmaiseva vastauskoodi 401, kytettv tunnistusmenetelm basic sek realm-alue salainen. Viimeisen avulla voidaan mritt suojausalueita, joiden sisll liikkuessaan kyttjn tarvitsee tunnistautua vain kerran.
HTTP/1.1 401 Unauthorised Date: Sun, 19 Nov 2006 18:06:11 GMT Server: Apache/2.0.52 (Red Hat) WWW-Authenticate: Basic realm="salainen" Content-Length: 487 Content-Type: text/html; charset=iso-8859-1

Kuva 2-4. Palvelimen basic-autentikointipyynt.

Pyynnn perusteella selain avaa ponnahdusikkunan, johon kyttj voi antaa tunnuksensa ja salasanan. Selain lhett GET-pyyntns otsakkeen Authorizationkentss palvelimelle kyttjnimens ja salasanansa, johon palvelin vastaa autentikoinnin onnistuessa tavanomaisella OK-viestill ja sen yhteydess lhetettvll datalla. Basic-autentikoinnin heikkous on se, ett kyttjnimi ja salasana lhetetn GETviestiss selkokielisen, jolloin liikennett kuunteleva hykkj voi helposti saada kyttjtunnuksen haltuunsa. Tm voi kuitenkin olla joillekin sovelluksille edellytyksen, mikli kyttjlt vastaanotettua salasanaa on pystyttv vertailemaan selkokielisen.

14

Digest-autentikointi Basic-autentikoinnin puutteisiin tuo apua digest-menetelm, jonka tarkoituksena on laskea annettujen satunnaisarvojen perusteella verkon yli lhetettvist tiedoista tiiviste. Myskn digest-menetelm ei ota kantaa viestien hytykuorman salaamiseen, mutta autentikointimenetelmn se korjaa basic-menetelmn suurimmat ongelmat. Toiminnaltaan digest-autentikointi on samankaltainen kuin basic, eli kun kyttj pyyt palvelimelta dokumenttia ilman oikeuksia (oikeaa tunnusta ja salasanaa), palvelin vastaa kyttjrajoitusta ilmaisevalla 401-sanomalla. Esimerkki sanomasta nkyy kuvassa 2-5.
HTTP/1.1 401 Unauthorized Date: Sun, 19 Nov 2006 18:06:11 GMT Server: Apache/2.0.52 (Red Hat) WWW-Authenticate: Digest realm="salainen@palvelin.com", qop="auth,auth-int", nonce="5a4ec0e876a987b7b06ce76c0a7e86b3", opaque="fc67cee59a6c9e7cf574a40a8a5a34" Content-Length: 487 Content-Type: text/html; charset=iso-8859-1

Kuva 2-5. Palvelimen digest-autentikointipyynt.

Kuvassa nkyy kytettv realm-alue, suojauksen laatu, satunnaismerkkijono tiivisteen laskentaa varten ja opaque-merkkijono, jonka kyttjn pit palauttaa tiivisteess muuttumattomana palvelimelle. Tiivisteen laskentaan kytetn MD5-funktiota. Kun kyttj on palauttanut laskemansa tiivisteen ja sen sisltmn kyttjnimen ja salasanan palvelimelle, laskee palvelin saman itse ja vertaa kyttjlt saatua tiivistett tulokseen. Tiivisteen ollessa sama, voidaan varmistua kyttjn oikeellisuudesta ja lhett tlle OK-sanoma ja pyydetty data. Tiivistett ei ole en mahdollista purkaa selkokieliseen muotoon, joten digest-menetelmn kytt edellytt, ett palvelin tuntee oikean salasanan alkuperisess muodossaan. Tllin esimerkiksi tiivisteiden vertailu kryptattuihin Unix-salasanoihin ei ole mahdollista, koska niiden muuntaminen vertailukelpoiseen muotoon ei kytnnss onnistu.

2.4.2 SSL/TLS
HTTPS:n toteuttamiseen kytetn yleisimmin SSL-protokollaa, joka mahdollistaa turvallisen tiedonsiirron verkko-ohjelmistojen vlill. SSL on internetin yleisin ja ehkp trkein tietoturvaprotokolla [Ker98, s. 296]. SSL on Netscapen kehittm protokolla, ja siit kytetn nykyisin versiota 3.0 [Fre06]. Mys SSL:n seuraajaa eli TLS-protokollaa tuetaan laajasti, ja lyhennett SSL kytetnkin yleisnimityksen nille kahdelle protokollalle. TLS: kehitt IETF, ja siit kytetn yleisimmin versiota 1.0 [DiAl99], joka julkaistiin vuonna 1999. Kevll 2006 ilmestyi TLS versio 1.1, jossa on paranneltu muun muassa RSA-algoritmin toimintaa.

15

Sek SSL ett TLS takaavat tiedonsiirrolle kolme tietoturvan perusominaisuutta: autenttisuuden, luottamuksellisuuden ja tiedon eheyden. Luottamuksellisuudella tarkoitetaan sit, ett tietojrjestelmss oleva tai siirrettv tieto on vain sen kyttn oikeutettujen saatavilla. Autenttisuudella tarkoitetaan sit, ett kommunikoinnin osapuolet voidaan tunnistaa ja eheydell sit, ett tiedot ovat luotettavia. TLSprotokollan muutokset SSL:n nhden ovat pieni, ja se tukee hyvin SSL 3.0:ssa mriteltyj viestien rakenteita. TLS:ss on mys poistettu tuki Fortezza-salauskortille. [Ker98, s. 93] SSL-protokolla SSL-protokolla toimii kuljetus- ja sovelluskerroksen vliss ja on riippumaton sit kyttvst sovelluksesta. SSL tarvitsee oman TCP/IP-sokettinsa, jolle kytetn yleisesti porttia 443. Esimerkiksi SSL-salausta kyttvll HTTP-palvelimella tm tarkoittaa SSL-portin kyttmist yleisen 80-portin sijaan. SSL: kytettess kaikki sen kautta kulkeva liikenne eli dokumentin URL, sen sislt, lomakkeiden sislt, evsteet ja HTTP-otsakkeet ovat salattuja. Satunnaiselle kuuntelijalle selvi ainoastaan keskustelevien osapuolten IP-osoitteet ja SSL-sanomien tyyppi. SSL mahdollistaa joustavan symmetrisen salaus-, tiiviste- ja autentikointimenetelmn valinnan. SSL voi kytt salaukseen DES-, 3-DES-, RC2- tai RC4-algoritmeja ja autentikointiin MD5- tai SHA-tiivisteit sek RSA-avaimia ja sertifikaatteja. Kommunikointi voi tapahtua mys anonyymisti, jolloin kytetn Diffie-Hellman avaintenvaihtoalgoritmia. [Ker98, s. 297] SSL-tapahtuman vaiheet Seuraavaksi kydn lpi yleisell tasolla SSL-tapahtuman aikana suoritettavat vaiheet palvelimen ja kyttjn vlill. SSL-tapahtuman aluksi tiedonsiirron ptepisteet autentikoidaan ja sovitaan salauksessa kytettv symmetrinen avain. Vaiheet suoritetaan ptepisteiden vlill lhetettvien sanomien avulla, joiden kulkua havainnollistetaan kuvassa 2-6.

16

Kuva 2-6. SSL-yhteyden muodostaminen [Maj05].

Kyttj aloittaa yhteydenoton palvelimeen Client hello sanomalla, joka sislt sessiotiedon, satunnaisdataa salausta varten sek tietoa kyttjn tukemasta protokollasta ja suojausmenetelmist. Se voi olla mys vastaus palvelimelta tulleeseen Hello request sanomaan, jolla palvelin voi ilmaista pyyntns istuntoneuvottelun aloittamiseksi. Palvelin vastaa kyttjn onnistuneeseen yhteydenottoon Server hello sanomalla. Virheen tapahtuessa vastataan virhett ilmaisevalla sanomalla. Server hello sislt tiedot palvelimen mrmist salaus- ja pakkausalgoritmeista, ja palvelimen oman satunnaisdatan salausta varten. Lisksi palvelin tarkastaa kyttjn mahdollisesti antaman sessiotunnuksen, ja palauttaa tarpeen mukaan joko uutta sessiota ilmaisevan arvon tai vanhan, edellist sessiota ilmaisevan arvon.

17

Seuraavaksi palvelin lhett kyttjlle sertifikaattinsa, joka on valittujen salausasetusten mukainen. Yleisesti kytetn X.509.v3-standardin mukaista sertifikaattia [Ker98, s. 150-152]. Kyttj tiet palvelimen tervehdysvaiheen pttyneen Server hello done sanoman perusteella. Mikli palvelin on tehnyt sertifikaattipyynnn, lhett kyttj palvelimelle oman sertifikaattinsa, joka on muodoltaan vastaava kuin palvelimen sertifikaatti. Sertifikaatin avulla palvelin voi varmistua kyttjn oikeellisuudesta samalla tavalla kuin kyttj palvelimen, jolloin saavutetaan molempien ptepisteiden autentikointi. Tmn jlkeen kyttj lhett Client key exchange sanoman, joka sislt avaimen, jolla luodaan lopullinen istuntoavain. Tt avainta kutsutaan premaster-avaimeksi, ja sen muoto ja pituus riippuvat valituista salausalgoritmeista. Lopullista istuntoavainta eli master-avainta kytetn kaiken istunnossa siirrettvn tiedon salaamiseen. Premasteravaimen salaaminen PKI (Public Key Interface) menetelmll ennen sen lhettmist on ensiarvoisen trke, jotta siirrettv tieto voidaan salata hykkjlt. Istuntoavaimen lhettmist seuraa vapaaehtoinen Certificate verify sanoma, jolla varmistetaan kyttjn lhettm sertifikaatti. Yhteydenmuodostus ptetn yhteysosapuolten toisilleen lhettmill Finished-sanomilla. Samalla varmistetaan avaintenvaihto- ja autentikointitapahtumien oikeellisuus sanomien sisltmien tiivisteiden avulla. Tmn jlkeen varsinainen istunto voi alkaa, jonka aikana ptepisteet salaavat niiden vlill kulkevan liikenteen yhteisell, symmetrisell salausavaimella.

2.5 MVC-sovellusarkkitehtuuri
Samalla kun verkko-ohjelmistojen vaatimukset monipuolisuuden, ulkoasun ja kyttjystvllisyyden suhteen kasvavat tiedonsiirtoyhteyksien ja palvelinkoneiden tehostuessa, mys niiden toteuttaminen muuttuu vuosi vuodelta vaikeammaksi. Lishaasteena verkko-ohjelmiston toteutuksessa on sen kyttmien rajapintojen ja toisinaan mys ohjelmointikielten suuri mr, koska ohjelmisto neuvottelee ulkomaailmaan kyttjille ja kytt usein hydykseen tietokantaohjelmistoja. Kasvanutta monimutkaisuutta helpottavat parantuneet kehitysympristt, jotka tarjoavat virheentarkistusominaisuuksia ja mahdollistavat ohjelmiston eri osien ksittelyn yhtenisell tavalla. Lisksi ohjelmistokehityksess on vallitsevana pyrkimyksen laajojen ohjelmistojen pilkkominen pienempiin, helpommin omaksuttaviin osiin, joita voidaan tarvittaessa kehitt mys toisistaan erilln. Modulaarisen suunnittelun mahdollistaa muun muassa oliokielet Java ja C++, sek proseduraalisilla kielill kutsurakenteen hierarkinen suunnittelu. Etenkn verkko-ohjelmoinnissa pelkstn ohjelmointikielen modulaarisuus ei riit jo siit syyst, ett nykyaikainen verkko-ohjelmisto saattaa kytt hydykseen useita eri ohjelmointikieli: ulkoasuun voidaan kytt HTML-, JavaScript- ja CSS-kieli, logiikkaan Javaa, Perli tai PHP:t ja lisksi voidaan tarvita SQL (Structured Query Language) kutsuja tai muuta rajapintaa tietokannan ksittelyyn. MVC (Model-ViewControl) arkkitehtuuri pyrkii hajauttamaan nm osat toisistaan, jolloin esimerkiksi HTML-lomakkeen parametreiksi ei tarvitse kirjoittaa suoraan SQL-kutsuja, ja toisaalta SQL-tietokannassa ei tarvitse huolehtia kyttjlle lhetettvn vasteen ulkoasusta. MVC-rakenne sopii yleisesti kaikkiin kyttliittymn, logiikan ja tietokannan sisltviin

18

ohjelmistotyyppeihin, mutta tmn projektin puitteissa on tarpeen tarkastella sit verkko-ohjelmiston nkkulmasta. MVC-arkkitehtuuriin perustuvia sovelluskehyksi on toteutettu lukuisia useille eri kielille, ja mys arkkitehtuurista kytettvi nimityksi on useita. Sun kytt MVC:st nimityst Model 2, jota Sunin J2EE (Java 2 Platform Enterprise Edition) sovelluskehys hydynt. Muita tunnettuja MVC-sovelluskehyksi ovat esimerkiksi Apachen Javalle suunnittelema Struts, Rubylle Ruby on Rails, Pythonille Django ja Microsoftin kehittm ASP.NET. Mys PHP:lle lytyy useita MVC-arkkitehtuurilla suunniteltuja sovelluskehyksi. Tss tyss ei ksitell konkreettisia sovelluskehyksi, koska niit ei projektin toteutuksessa hydynnetty. Sen sijaan hydynnettiin HTTP-palvelimen omaa APIrajapintaa ja sivupohjamenetelm, joihin palataan luvuissa nelj ja viisi. Kuten luvun nelj palvelinvaihtoehtojen kartoituksessa huomataan, suurin osa palvelimista tukee CGI- tai FastCGI-rajapintaa, joiden avulla muun muassa tulkittaville kielille luotujen sovelluskehysten kyttnotto onnistuisi helposti. Nihin tekniikoihin suhtauduttiin kuitenkin varauksella, koska sovelluskehykset ovat psntisesti raskaita, eivtk siten sovellu tmn projektin sulautetulle verkon ptelaitteelle. Tst huolimatta tyss haluttiin hydynt MVC-arkkitehtuurin periaatteita sovelluksen eri osa-alueiden jakamiseksi erillisiin, mahdollisimman itsenisiin osiin. Tll saavutetaan ohjelman parempi yllpidettvyys, siirrettvyys ja sen komponenttien uudelleenkytettvyys [HaM98, s. 355]. Muita mainittavia sovellusarkkitehtuureita MVC:n lisksi ovat muun muassa ohjelmaja kyttliittymosaan sovelluksen jakava yksinkertainen jaottelu (Simple Separation), sek Microsoftin MFC (Microsoft Foundation Classes), joka perustuu Document/View jaotteluun. MVC-arkkitehtuuri jaottelee nimens mukaisesti ohjelmiston kolmeen eri osaan: malliin (Model), nkymn (View) ja kontrolliin (Control). Nist mallilla tarkoitetaan ohjelmiston pysyv, sovellusaluekohtaista dataa, nkymll kyttjlle nkyv osaa ja kontrollilla niden kahden osan vlill toimivaa logiikkaa. Kuvan 2-7 yksinkertainen lohkokaavio havainnollistaa eri osien vuorovaikutusta.

Kuva 2-7. MVC-sovellusarkkitehtuuri.

19

Kuvassa yhteninen nuoli esitt osien suoraa ja katkoviiva niiden epsuoraa yhteytt toisiinsa. Tm tarkoittaa kytnnss sit, ett kaikki komennot nkymlt mallille ja toisaalta esitettv tieto mallilta nkymlle kulkevat kontrollin kautta. MVCarkkitehtuuri mahdollistaa ohjelmiston suunnittelun siten, ett muutokset yhdess ohjelmiston osassa eivt vaikuta ohjelman muuhun toimintaan, edellytten ett eri osien vliset rajapinnat pysyvt samana. Malli MVC:n mallilla tarkoitetaan sovellusaluekohtaista, pysyv tosielmn dataa, jolla voidaan tarkoittaa esimerkiksi laskutusjrjestelmn kirjanpitomerkintj tai webin keskustelualueen kyttjtietoja. Malli itsessn voi sislt sen varastoiman tiedon tarvitsemaa logiikkaa, jonka avulla tarjotaan sovelluksen ylemmlle kerrokselle rajapinta tiedon saantia ja manipulointia varten. Lisksi logiikan avulla tieto pysyy jrjestyksess, jolloin ylemmn kerroksen ei tarvitse huolehtia ksiteltvn tiedon jsennyksest ja rajoituksista. Monimutkaisemmissa tietorakenteissa on huolehdittava mys tiedon viite-eheydest ja transaktioiden synkronoinnista. Yleisimmin mallina kytetn SQL-kielist relaatiotietokantaa, kuten MySQL tai PostgreSQL. Mallina voidaan kytt mys esimerkiksi yksinkertaista tallennukseen kytettv tiedostoa tai ohjelmistolla manipuloitavaa fyysist laitetta. Nkym Itse kyttjlle verkko-ohjelmiston tutuin osa on nkym. Nkymn tehtvn kyttjlt saatujen kskyjen vlittminen kontrollille ja huolehtia kontrollin kautta mallilta saadun datan esittmisest kyttjn ymmrtmss muodossa. Alemmalta tasolta saadun tiedon ei vlttmtt tarvitse olla perisin mallilta, vaan nkymi voidaan luoda mys suoraan kontrollilta saatujen vasteiden perusteella. Yleisimmin tapahtumiin liittyy kuitenkin mys mallilla olevan datan ksittely. Tyypillinen web-nkym kytt tietojen esittmiseen HTML-kielt, ja mahdollisesti JavaScripti nkymlogiikkaa ja CSS- tai XSL-kielt ulkoasun hienost varten. Suurin hyty nkymn eristmisest muusta ohjelmasta on siin, ett muita osia suunniteltaessa ei tarvitse ottaa kantaa nkymn liittyviin seikkoihin, kuten tiedon asetteluun tai sivun ulkonkn. Lisksi web-sivun suunnittelijan ei tarvitse hallita nkymn alla toimivan sovelluslogiikan toteutuskielt, vaan vain verkkosivujen luomiseen tarkoitetut kuvaus- ja skriptikielet. Kontrolli Mallin ja nkymn vliin tarvitaan viel ohjelman aivot, joille kytetn MVCarkkitehtuurissa nime kontrolli. Kontrolli vastaanottaa kyttjlt tulevia pyyntj ja tarjoaa niihin mallia apuna kytten asianmukaisen vasteen. Kontrolli tuntee nkymn tarvitsemat ja mallin tarjoamat palvelut, mutta ei ota kantaa niiden toteutustapoihin, vaan toimii tarvittavana logiikkana niden osien vlill. Kontrollin toiminta perustuu yleens tarvittaviin ksittelijihin (handlers) ja takaisinkutsuihin (callbacks), joita nkym voi kytt. Ksittelij vastaanottaa kutsun

20

ja sen tarvitsemat parametrit, joiden perusteella se kytt mallin rajapintaa nkymn tarvitseman datan noutamiseen. Kontrolli voi tarvittaessa manipuloida dataa esimerkiksi poistamalla mrtyt tietokentt, mikli se tiet ettei nkym tule niit tarvitsemaan. Kontrolli mys muotoilee mahdolliset logiikassa tai mallissa tapahtuneet virheet nkymn ymmrtmksi vasteeksi, esimerkiksi ilmaisemalla HTML-lomakkeelle sytetyn virheellisen arvon. Tten alemmalla kerroksella tapahtuneet virheet voidaan esitt kyttjlle halutulla tavalla. Takaisinkutsujen avulla voidaan mritell nkymss esitettv tieto. Takaisinkutsut ovat yleens erilaisia silmukka-, ehto- ja arviointikomentoja, joiden perusteella mallilta saatu tieto tulostetaan nkymn. Siten nkymss voidaan vapaasti mritell kyttjlle esitettv tieto ja sen asettelu.

21

3 Kohdeymprist
Verkon ptelaitteeseen toteutettavan sovelluksen mrittelyss ja suunnittelussa ovat trkeit kohdeympristn asettamat reunaehdot. Sulautettujen jrjestelmien sovelluskehityksess tst tekee erittin trke se, ett laitteisto on yleens suoritusteholtaan rajoittunut ja sovellusymprist ominaisuuksiltaan vaatimaton ja ennaltamrtty. Laitteiston tarjoama laskentateho ja muistikapasiteetti antaa ksityksen sovelluksen vaatimuksista ja rajoittaa esimerkiksi web-hallintasovelluksen ytimen kytettvn HTTP-palvelimen ratkaisuvaihtoehtoja. Mys hallintasovelluksen vasteaikoihin ja kytettvyyteen liittyvi ei-toiminnallisia vaatimuksia on syyt peilata laitteiston ominaisuuksiin. Laitteistoakin trkempi sovelluksen toteutustapaa rajoittava tekij on olemassa oleva sovellusymprist, joka tarjoaa sovelluksen kehittmisess kytettvn kyttjrjestelmn, knnsympristn, ohjelmointirajapinnat ja muut sovellukset ja niiden rajapinnat. Mys sovellusympristn yleisi suunnitteluperiaatteita on syyt pyrki noudattamaan, vaikka poikkeustilanteissa mys periaatteista joustaminen on mahdollista. Suunnitteluperiaatteisiin kuuluu muun muassa kytettvksi suositeltu yksiprosessinen ja sikeetn prosessimalli. Yksi ohjelmiston toteutukseen liittyv seikka, joka ei suoranaisesti liity toteutuksen kohdeympristn, on ohjelmistokoodin tallennukseen, yllpitoon ja muutosten hallintaan kytettv versionhallintamenetelm. Iris 440 laitteen sovellusympristn lhdekoodipuun versionhallintaa ksitelln tmn luvun lopussa.

3.1 Laitteisto
Iris 440 ptelaitteen toiminnallisuus toteutetaan erilaisilla ohjainpiireill ja itse prosessorilla. Laitteen keskeisimmt tehtvt ovat kyttjrjestelmn ajaminen ja dataliikenteen vastaanottaminen ja vlittminen oikealle linjalle sille sopivassa muodossa. Tm kohta perustuu lhteeseen [DC06]. Iris 440 laite on asiakaspn- ja point-to-point yhteyksiin tarkoitettu SHDSLptelaite, joka tarjoaa asiakkaalle internetyhteyden symmetrisen ja nopean SHDSLlinjan avulla. Laite nkyy kuvassa 3-1. Laite sislt nelj ethernet-liitnt ja sarjaporttiliitnnn hallintayhteytt varten. Asiakasyhteyden maksiminopeus on 22,8Mbps ja ethernet-liitntjen 100Mbps.

22

Kuva 3-1. Iris 440 ptelaite.

Laitteen trkeimmt osat ovat prosessori, FPGA-piiri sek ethernet- ja SHDSLliitnnist vastaava kytkin ja linjapiiri. Kuvassa 3-2 on yksinkertaistettu lohkokaavio laitteen eri osista ja niiden vlisist liitnnist.

Kuva 3-2. Iris 440 laitteen HW-arkkitehtuuri.

Laitteen ethernet- ja SHDSL-liitntjen vlill kulkeva liikenne ohjataan aina laitteen prosessorin kautta. Lisksi datapolkuun kuuluu FPGA-piiri, jonka yhten tehtvn on toimia sovittimena prosessorin ja SHDSL-linjapiirin vlill.

23

CPU Laitteen CPU eli keskusprosessori on 32-bittinen ja toimii MIPS-kskykannalla. Se toimii 300MHz kellotaajuudella ja sislt 16 kilotavua vlimuistia. Prosessori sislt mys DMA- ja PCI-ohjaimen sek kaksi kappaletta MII-liitntj. Muita liitntj ovat UART, I2C, SPI ja JTAG. UART-liitnt kytetn laitteessa ohjausvyln ja I2Cvyl EEPROM-muistin ksittelyyn. Muistit Laite sislt DDR-keskusmuistia, jossa ajetaan ohjelmistokoodi ja joka toimii datan vlivarastona. Muistia on yhteens 256 megatavua, ja se on jaettu kahdelle 32-bittisell muistivylll toimivalle piirille. Pysyv muistia varten laite sislt kapasiteeltiltaan 64 megatavun suuruisen flash-muistin. Thn tallennetaan muun muassa bootloader, Linux-levykuva ja asetustiedostot. Lisksi laite sislt pienen EEPROM-muistipiirin, jota kytetn shkisten tunnisteiden tallennuspaikkana. Ethernet-kytkin Laitteessa olevia ethernet-liitntj varten tarvitaan kytkin, joka yhdist liitnnt laitteen prosessorille. Tm piiri toimii siis haaroittimena neljn RJ45-liitnnn ja prosessorin MII-liitnnn vlill. SHDSL-linjapiiri Ethernet-liitntjen lisksi mys SHDSL-linjoja varten tarvitaan oma linjapiirins, joka jakaa FPGA:lta tulevan datavirran omille linjoilleen. Iris 440 sislt nelj SHDSLlinjaa, jotka on yhdistetty yhdeksi nopeaksi kyttjlle nkyvksi modeemilinjaksi. FPGA FPGA-piirin tarkoituksena on vlitt prosessorilta tuleva ethernet-pakettivirta ja kontrollikomennot SHDSL-linjoille sopivaksi datavirraksi ja pinvastoin. Lisksi FPGA toimii LED-ohjaimena muille kuin ethernet-LED:eille.

3.2 Sovellusymprist
Iris 440 laitteen sovellusympristll tarkoitetaan sen kyttjrjestelm ja sill ajettavia prosesseja sek erilaisia tykaluja. Prosesseja ovat muun muassa laitteen ominaisuuksien hallinnasta ja ympristn kanssa kommunikoinnista vastaavat prosessimoduulit. Tykaluja ovat Unixin perustykalut ja erilaiset kntmiseen ja binrien hallintaan kytettvt sovellukset. Tss kohdassa ksitelln sovellusymprist projektin kannalta oleellisista nkkulmista. Erityisesti kytettvien ohjelmointirajapintojen ja prosessimoduulien toimintaperiaatteiden tarkastelu on trke, koska ne vaikuttavat oleellisesti mys web-hallintasovelluksen suunnitteluun ja toteutukseen.

24

3.2.1 Kyttjrjestelm
Iris 440 laitteen kyttjrjestelm koostuu Linux-ytimest ja sulautetuille jrjestelmille tarkoitetun BusyBox-ohjelman [Per96] tarjoamista Unix-tykaluista. Lisksi laitteessa toimii lukuisa mr erilaisia prosessimoduuleja, joista kukin vastaa jostain laitteen hallintaa tai kommunikointia koskevasta tehtvst. Prosessimoduuleja ovat esimerkiksi laitteen siltojen tai verkkoliitntjen hallintarajapinnan tarjoavat moduulit sek komentorivi- tai HTTP-yhteyden kautta kyttjn kanssa neuvottelevat hallintamoduulit. Ydin Iris 440 laitteen kyttjrjestelmn ytimen toimii muokattu versio Linux-kernelin versiosta 2.4.20. Ydin on Linux-jrjestelmn keskeisin ohjelmistokomponentti, ja sen ominaisuudet mrvt pitklti mys koko jrjestelmn mahdollisuudet [Yag03, s. 156]. Ytimen tehtv on kommunikoida jrjestelmn laitteiston kanssa ja tarjota sovelluksille standardi rajapinta erilaisten laitteiden hydyntmiseksi. Ydin huolehtii mys jrjestelmss ajettavien sovellusten muistinhallinnasta ja siit, ett jokainen sovellus saa prosessorilta tarvitsemansa mrn laskenta-aikaa. Erilaisia laiterajapintoja kyttvt laiteajurit voidaan sisllytt ytimeen joko sisnrakennettuna tai erillisin moduuleina. Yksi Linux-ytimen vahvuuksia onkin ytimen modulaarisuus, jolloin moduulit voidaan ladata tai sulkea tarpeen mukaan, ja keskusmuistissa olevan kyttjrjestelmn ytimen koko pysyy pienen. Tm on trke etenkin sulautetulle jrjestelmlle. Koska sulautetun jrjestelmn muistikapasiteetti on rajoittunut, on ytimest mys syyt karsia pois kyttmttmksi jvt osat. Linux-ytimen sisltmt osat selvivt sen kntmiseen kytetyst .configtiedostosta, johon on Iris 440 laitteessa sisllytetty vain vlttmttmimmt osat. Suurin osa laitekohtaisista ajureista knnetn erikseen kernel-moduuleiksi lhinn siit syyst, ett niiden harvinaisuuden tai suljetun koodin vuoksi Linuxin oletusydin ei niit tarjoa. Prosessimoduulit Prosessimoduulit ovat tiettyyn tehtvn suunniteltuja ohjelmia, jotka tarjoavat oman rajapintansa muun sovellusympristn tai ulkomaailman kytettvksi. Sulautetulle jrjestelmlle on ominaista, ett siin toimivat prosessit ovat reaaliaikaisia, jolloin niiden toteutus poikkeaa perinteisist jrjestelmist muun muassa siihen liittyvien ajastusvaatimusten ja rinnakkaisuuden hallinnan osalta [HaM98, s. 306]. Jrjestelmn ksiteltvksi tulevat sytteet ja tietovirrat eivt ole ennustettavissa, mik edellytt tiettyj erityisvaatimusta perinteisiin erpohjaisiin sovelluksiin verrattuna. Mys reaaliaikajrjestelmss voi olla ertyyppisi sytteit ksittelevi osia, ja niit kutsutaan passiivisiksi moduuleiksi. Iris 440 laitteen sovellusympristss reaaliaikaisuuden asettamat haasteet on ratkaistu prosessimoduulien keskinisell kommunikoinnilla ja niiden asynkronisella toimintatavalla. Prosessien vlinen kommunikaatio on toteutettu IPC (Inter-process Communication) rajapinnan avulla, jonka toteuttaa erillinen IPC-moduuli. IPCrajapinnan avulla prosessit voivat vlitt toisilleen dataa ja pyyntj, ja sen avulla
25

voidaan huolehtia prosessien keskinisest synkronoinnista. Asynkroninen toiminta tarkoittaa tss tapauksessa sit, ett kukin moduuli rekisteri itsens jrjestelmn toimintaa ohjaavalle valvontamoduulille, jolle moduuli voi ilmoittaa aktiivisuutensa esimerkiksi I/O-operaation yhteydess. Moduuli voi muuttua aktiiviseksi esimerkiksi kyttjlt tulevan sytteen saapuessa. Moduulien asynkronisuuden tarjoama etu on se, laskentatehoa ei kulu hukkaan yksittisen moduulin odottaessa jonkin toiminnon tapahtumista, vaan laskenta-aika voidaan sill aikaa kytt jossain muualla ja moduuli ilmoittaa aktiivisuudestaan tarpeen mukaan. Moduulien rekisterityminen valvontamoduulille toteutetaan erityisen luokan avulla, josta moduuli periytt itselleen oman kuuntelijaluokkansa. Tmn luokan on toteutettava tietty metodi, jota valvontamoduuli kutsuu, kun moduuli on aktiivinen. Tm metodi kynnist moduulin toteuttaman toiminnon suorittamisen, mik voi sislt esimerkiksi I/O-sytteen lukemisen ja ksittelyn. Kuuntelijaolion rekisterityminen valvontamoduulille tapahtuu sen tarjoamalla register_fd()metodilla, jolle kuuntelija antaa sytteen valvottavan tiedostokuvaimen ja itsens. Valvontamoduulissa kukin moduuli kartoitetaan sit vastaavaan tiedostokuvaimeen, jonka aktiivisuutta voidaan tarkastella select()-jrjestelmkutsun avulla. Tiedostokuvaimen aktiivisuuden perusteella voidaan kynnist sit vastaavan kuuntelijaolion suoritusmetodi ja sit kautta suorittaa moduulin tarjoama toiminto. Kommunikoinnista laitteen resurssien kanssa vastaa valvontamoduulin ohjaaman vuorottelun johdosta vain yksi moduuli kerrallaan. Tllin vltytn esimerkiksi kahdelta eri hallintaprosessilta tulevien samanaikaisten hallintapyyntjen poissulkemisongelmalta, koska tietty hallintaobjektia voi ksitell vain yksi prosessi kerrallaan. Tm vhent prosessien vlisen kommunikaation tarvetta ja ennaltaehkisee monimutkaisia rinnakkaisen ohjelmoinnin ongelmia. Asioiden yksinkertaistamiseksi yksittisten moduulien kyttmksi prosessimalliksi on ohjeistettu yksiprosessinen ja tapahtumapohjainen, ei mielelln sikeill toimiva. Useampaa prosessia tai siett kytettess poissulkemisongelmista olisi huolehdittava mys yksittisen moduulin sisll. Eri prosessimallien etuja ja haittoja ksiteltiin kohdassa 2.3.

3.2.2 Config API

Config API on Design Combus Oy:n alunperin Iris 800 DSLAM (Digital Subscriber Line Access Multiplexer) laitteelle luoma hallintarajapinta, jolla voidaan lukea ja muokata laitteen asetuksia. Rajapinta sislt metodit eri hallintaobjektien lismiseen, pivittmiseen, poistamiseen ja lukemiseen. Nit kutsuja voidaan kytt laitteen hallintaan hallintasovelluksen avulla. Iris 800 laitteen hallinta tapahtuu toistaiseksi ainoastaan CLI-sovelluksella, mutta Iris 440 ptelaitteelle se on tarkoitus mahdollistaa mys web-pohjaisen hallintasovelluksen avulla. CLI- ja web-hallintasovellukset ovat laitteen hallintaan tarkoitettuja rinnakkaisia kyttliittymi, joista kumpikin sislt oman logiikkansa sytteiden ja vasteiden vlittmiseen kyttjn ja Config Managerin vlill. Uudelleenkytn kannalta hallintasovelluksista on jrkevint tehd keskenn mahdollisimman yhtenevt, vaikkakin terminaalipohjaisen ja web-kyttliittymn erilaisesta luonteesta johtuen monet sovelluksen elementit poikkeavat toisistaan jo suunnitteluvaiheessa.
26

Hallintaobjektit ja kutsulogiikka Laitteella sijaitsevat hallittavat asiat nkyvt sovellukselle hallintaobjekteina. Hallintaobjektit ovat laitteen tarkasteltavia tai muokattavia asioita, kuten silta, verkkoliitnt tai kytettvn DNS-palvelimen IP-osoite. Jokaisella objektilla on tietty mr attribuutteja, joista oleellisimpia ovat objektin identifiointiin kytettvt avainattribuutit. Jotkin objektit eivt sisll lainkaan avainattribuutteja, joka tarkoittaa kytnnss sit, ett tllaisia objekteja voi olla enintn yksi. Jokaiselle hallintaobjektille toteutetaan home, jossa mritetn suoritettava tapahtuma kun jotakin objektin metodia kutsutaan. Erilaisia metodeja ovat add, update, get_first, get_next ja delete. Jokainen home rekisteridn Config Manageriin, jota ksitelln API-metodien avulla. Home-rajapintojen ja niit vastaavien manager-sovellusten ksittely Config API-rajapinnan kautta havainnollistetaan kuvassa 3-3. Vaikka rajapinnan metodit ja niiden sytteet ja vasteet ovat psntisesti kaikille objekteille samat, niin niiden toteutustavat vaihtelevat erilaisista laitteisto- ja ajurirajapinnoista johtuen. Tst syyst homet pit rakentaa objektin erityispiirteet huomioonottaen. Home-toteutusten hallinnasta vastaa home factory, joka toimii objektien ernlaisena abstraktina rajapintana, jota hallintasovellus voi kytt datan manipulointiin. Home factory ohjaa saamansa pyynnn oikealle homelle, jolloin hallintaobjekteja voidaan ksitell samoilla metodeilla objektityypist riippumatta.

Kuva 3-3. Manager-sovellusten ksittely hallintasovelluksen avulla.

Edell kuvatusta mekaniikasta johtuen ylemmn tason hallintasovelluksen ei tarvitse olla tietoinen Config Manageriin rekisteridyist homeista, vaan sen lhettmt pyynnt voivat olla mielivaltaisia. Config API:lle kohdistettujen kutsujen vastaanotosta vastaa dispatcher, joka ohjaa ne oikealle home factoryyn rekisteridylle homelle, jolloin kutsu kohdistuu haluttuun objektiin. Tten itse hallintasovelluksen huoleksi j vain vasteen arvioiminen, kun metodien kohdistaminen oikeaan objektiin oikealla tavalla j Config Managerin ja objektia vastaavan homen huoleksi.

27

Objektien parametrisointi Kyttjystvllinen hallintasovellus tarvitsee vaadittavan mrn kyttjlle esitettv metatietoa erilaisista hallintaobjekteista. Hallintaobjektien perusominaisuuksia ja niiden metatietoa on tarpeellista pysty tydentmn yhtenisell tavalla. Tmn ratkaisuna kytetn def-tiedostoja, jotka ovat yksinkertainen lista attribuutteja, joiden mrein ovat nimi, tietotyyppi, oletusarvo, pakollisuus ja rajoitukset. Kuvassa 3-4 nkyy katkelma objektin i24_interface def-tiedostosta, jossa mritelln laitteen verkkoliitnnn hallinta-attribuutit. Esimerkiksi type-attribuutti on tietotyypiltn string, oletusarvoltaan tyhj ja pakollinen. Mahdolliset sytteet ovat ethernet tai shdsl.
name: attr: attr: attr: i24_interface type card unit

string int int

"" 1 0

trueset true true

("ethernet|shdsl") range(1,1) range(1,4)

Kuva 3-4. Mritys i24_interface-objektille.

Def-tiedostoihin mritellyt hallintaobjektit ja niiden avulla luotavat homet tarjoavat mahdollisuuden hallintasovelluksien geneeriselle toteutukselle. Kun jokainen hallintaobjekti on mritelty yhtenisell syntaksilla, voidaan niit mys ksitell yhtenisell tavalla. Hallintasovelluksen nkkulmasta uuden objektin luominen tarkoittaa yksinkertaisimmillaan uuden objektin def-tiedoston luomista, jonka perusteella generoidaan rajapinta sille mritettyjen arvojen ksittelyyn. Lisksi objektien muutosten yllpitminen on helppoa, koska jokainen muutos, esimerkiksi attribuutin lisminen, tehdn vain yhteen paikkaan.

3.2.3 CLI-hallintasovellus
Iris 440 laitteessa toimii Iris 800 DSLAM-laitteen tavoin CLI-hallintasovellus, joka pohjautuu Iris 800:n CLI:n ohjelmakoodiin. Vaikka tmn tyn ksittelem webhallintasovellus poikkeaa toiminnaltaan CLI:st, niin siin voidaan hydynt joitakin samoja suunnitteluperiaatteita. Tst syyst mys CLI:n toiminnan pintapuolinen tarkastelu on paikallaan. Iris 440:n CLI:hin psee ksiksi kirjautumalla laitteeseen admin-tunnuksilla, jolloin CLI-sovellus kynnistyy automaattisesti. CLI:hin voi kirjautua mys monitortunnuksilla, jotka on tarkoitettu laitteen valvontaa varten. CLI-hallintasovellus noudattaa vastaavan tyyppisten sovellusten yleist toimintatapaa, joista yksi esimerkki on Cisco IOS. Sen ominaispiirteit ovat hallintaobjektikohtaiset konfigurointitilat ja kumoavina kskyin toimivat no-komennot, joiden avulla esimerkiksi objektin poistaminen tapahtuu. Jokaista CLI:n komentotyyppi, esimerkiksi objektin lisyst, poistoa tai tarkastelua vastaa oma C++-luokkansa, ja eri CLI-komennot ovat niden luokkien olioita. Komennot luodaan CLI-sovelluksen kynnistyksen yhteydess ja niit voidaan mritell tarvittaessa lis. Komentojen syntaksi mritelln parametrein olion

28

luomisen yhteydess. Kuvassa 3-5 on esimerkki komennosta, jossa luodaan uusi addkomento, jolla voidaan mritt laitteelle uusi silta eli luoda uusi bridge-objekti.
new CCliAddCommand(pList->get_object_type("bridge"), ADMIN, ENABLE_MODE_TREE, BRIDGE_CONFIG_MODE, "bridge!Create a bridge! " "name!Bridge name! " "$brname=STR!Bridge name!")

Kuva 3-5. Esimerkki komentomrittelyst.

Komento luo uuden CCliAddCommand-olion, joka mrittelee komennon, jonka syntaksi on muotoa bridge name [nimi]. Komento toimii admin-tilassa oleville kyttjille, ja sille mritelln mys konfiguraatiotilan indeksi (ENABLE_MODE_TREE) ja konfiguraatiotila komennon antamisen jlkeen (BRIDGE_CONFIG_MODE). Tten komento on kytettviss sovelluksen ptilassa, ja komennon antamisen jlkeen CLI menee listyn sillan konfiguraatiotilaan. Olion luonnin yhteydess mritetn mys kullekin parametrille aputeksti, joka toimii ohjeena kyttjlle. Aputeksti ilmestyy CLI:ss nkyviin TAB-painalluksella tai kysymysmerkill. Koska eri objektityyppej koskevat komennot luodaan samoilla geneerisill luokilla, saadaan vaadittavan ohjelmakoodin mr pienennetty verrattuna siihen, ett jokaisen komennon toteuttava logiikka luotaisiin erikseen. Komentoluokkien toiminnallisuus vastaa vuorovaikutuksesta Config API:n eli laitteen konfiguraatiorajapinnan kanssa. Tm tarkoittaa add-luokan tapauksessa objektin homelle suunnattua add-kutsua mrtyill parametrin arvoilla kuvan 3-6 mukaisesti. Tallennettavan objektin parametrit asetetaan kyttvn antamiksi SetAttrValues()metodin avulla.
SetAttrValues(pTree, pParser, pObj, pModule); pHome->add(ctx, *pObj);

Kuva 3-6. Objektin tallennus Config API:n kautta.

Add- eli lisyskomennon lisksi muita CLI-komentoluokkia ovat muun muassa poisto-, pivitys-, nytt-, resetointi- ja asetustiedoston tallennuskomentoluokka. Mit pienemmll mrll luokkia sovellus toimii, sit vhemmn ohjelmakoodia CLI:n toteuttaminen kytnnss vaatii. Toisaalta komentoluokkien vhentyess objektikohtaisten ominaisuuksien huomioiminen ja siten mys komentojen kyttjystvllisyys vhenee. Tst syyst luokkien mrn oikeanlainen arviointi on tasapainoilua tymrn minimoinnin ja riittvn kytettvyyden vlill. Sama ky ilmi mys web-hallintasovelluksen suunnittelussa. Komentoluokkien, niiden toiminnallisuuden ja komentomrittelyjen lisksi CLI vaatii viel sovelluksen posan, jonka tehtvn on kuunnella CLI:lle tulevia signaaleja
29

ohjata niiden ksittely sovelluslogiikalle. Tm osa huolehtii mys valvontamoduulille rekisteritymisest kohdassa 3.2.1 esitetyll tavalla.

3.2.4 Knnsymprist
Sek perinteisten ett sulautettujen ohjelmistojen suunnittelijat tarvitsevat ohjelmistokoodin kntmiseen erilaisia kntji, linkittji ja tulkkeja. Sulautetun ohjelmiston knnstykalut poikkeavat perinteisist siten, ett ohjelmisto knnetn yleens erilaisessa ympristss kuin miss lopullista binri ajetaan [Yag03, s. 109]. Tmn projektin kohdeymprist toimii MIPS-prosessorilla, joten tuotettavan binrin pit olla MIPS-prosessorin ymmrtm konekielt. Koska kehitykseen kytettvt tyasemat ovat x86-pohjaisia, tarvitaan ristiinkntmist, mik tarkoittaa ohjelmakoodin kntmist kohdeympristlle tarkoitetulla kntjll ja kohdeympristn tukemien binritykalujen ja kirjastojen kyttmist. Iris 440 laitteen sovellusymprist koostuu alikohdassa 3.2.1 esitetyll tavalla kyttjrjestelmst ja erilaisista laitteen ja ympristn kanssa kommunikoivista prosessimoduuleista. Kunkin moduulin tarvitsema ohjelmakoodi sijaitsee sovellusympristn koodipuussa omassa kansiossaan. Esimerkiksi toteutettavan webhallintasovelluksen ohjelmistokoodi sijoitetaan kansioon dslam/src/dcombus/web/. Koodipuu tarkoittaa tss tapauksessa hakemistorakennetta, joka pit sislln kaiken Iris 440 laitteen tarvitseman ohjelmakoodin, knnstiedostot sek valmiiksi knnetyt sovellukset ja kirjastot. Iris 440 laitteen ohjelmistot knnetn GNU-projektin make-komentorivitykalulla [FSF97], jolle voidaan mritt knnettvt ohjelman osat tykalun kyttmn Makefile-tiedostoon. Tiedostoon mritetn kntmisess tarvittavat tykalut, asetukset ja tiedostot, jolloin itse kntminen tapahtuu yksinkertaisilla komentorivikomennoilla, ja kyttjn ei tarvitse huolehtia kntmisen yksityiskohdista. Esimerkiksi kntjn ja linkittjn asetukset voidaan mritt muuttujiin, jolloin asetusten muokkaaminen helpottuu. Makefile-tiedostoja voidaan mys ketjuttaa, eli hakemistorakenteen jokainen hakemisto voi sislt oman knnstiedostonsa, jota kutsutaan automaattisesti juurihakemistosta tehdyn knnskutsun yhteydess, kunhan alihakemisto mritetn juurihakemiston knnstiedostoon. Kntjn toimii mipsellinux-gcc, joka on MIPS-alustalle suunniteltu versio GNU-projektin GCC-kntjst. Jokaisen moduulin juurihakemisto sislt oman Makefile-tiedostonsa, joka on yksinkertainen ja sislt vain kaksi kohdetta: all ja clean. Kohde all tarkoittaa moduulin kntmist ja clean sen poistamista. Esimerkki tiedoston sisllst on esitelty kuvassa 3-7. Kohteella tarkoitetaan make-tykalulle mritettv kohdeparametria.
all: make C .. build-web clean: make C .. clean-web

Kuva 3-7. Web-prosessimoduulin Makefile-knnstiedosto.

30

Kuvassa 3-7 kytetyt build-web- ja clean-web-komennot ovat kohteita kuten all ja clean, ja niiden sislt on mritelty module.mk-tiedostossa. Tm tiedosto on osa Makefile-tiedostoa, joka on eristetty omaksi tiedostokseen kyttjn ja kntjn tarvitsemien kohteiden erottamiseksi toisistaan. Module.mk-tiedosto sislt tiedot knnettvksi haluttavista tiedostoista, alihakemistoista, ulostuloista, riippuvuuksista ja asetuksista. Moduulikohtaisten knnstiedostojen yhteydess on pyrittv minimoimaan kntjn asetusten mrittmist itse, koska mahdollisimman suuri osa asetuksista on pystyttv asettamaan lhdekoodipuun juurihakemistosta. Tllin esimerkiksi lhdekoodin kntminen eri kohdealustoille helpottuu, koska knnsasetusten muutokset on tarpeen mritt vain yhteen Makefile-tiedostoon. Jokainen moduulin lhdekoodia sisltv alihakemisto sislt viel oman module.mktiedostonsa, johon on listattu alihakemiston sisltmt tiedostot. Nm alihakemistojen module.mk-tiedostot, juurihakemiston module.mk-tiedosto ja itse Makefile-tiedosto muodostavat yhdess varsinaisen knnstiedoston, jonka perusteella kyttjn maketykalulle antamat all- ja clean-komennot suoritetaan. Todellisuudessa kyttjn tarvitsee antaa make all ksky vain koko sovellusympristn lhdekoodipuun juurihakemistoon, jolloin jokaisen alihakemiston sisltmt knnstiedostot suoritetaan ketjutetusti.

3.2.5 Versionhallinta
Tss luvussa ksitelln ohjelmistojen versionhallintaa yleisesti [Mas05] ja tss projektissa kytettyjen menetelmien nkkulmasta. Tehokkaaseen ja nykyaikaiseen ohjelmistonkehitykseen kuuluu trken osana versionhallinta. Versionhallintana voidaan pit mit tahansa ohjelmiston kehitysasteesta kertovan metatiedon yllpitmist: yksinkertaisimmillaan se voi olla tekstitiedostosta lytyv tai ohjelman kynnistyess ilmenev versionumero. Pelkk versionumeron yllpitminen ei kuitenkaan useimmiten riit, vaan tarvitaan jokin tapa yllpit mys ohjelmistossa tapahtuvia muutoksia ja niiden ajankohtia, ja mahdollisesti tarjota psy lhdekoodin edellisiin versioihin. Ksin yllpidettv lista muutoksista voi riitt pienelle projektille, mutta ongelmia syntyy jos samaa ohjelmistoa kehitt useampi kuin yksi henkil. Yleens edell mainitut ongelmat ratkeavat keskitetty versionhallintaa kyttmll. Se mahdollistaa versiohistorian yllpitmisen lisksi yleens edellisten versioiden lhdekoodin noutamisen ja muutosten tydentmisen selkokielisell selityksell. Nykyaikaisten tykalujen tarjoamalla keskitetyll versionhallinnalla suurenkin ohjelmiston muutokset on helppo pit koko kehitysryhmn ksiteltviss ilman pelkoa pllekkisist tai toisensa sekoittavista muutoksista. Mys kehityksess kohdattujen ongelmien ratkaiseminen on helpompaa, kun ohjelmistokoodiin tehtyjen muutosten ja niiden ajankohtien tarkka historia on saatavilla. Tss projektissa kytettiin versionhallintaohjelmistoa nimelt Subversion [CN01]. Versionhallinnassa yllpidetn Iris 440 laitteen lhdekoodipuuta useassa eri kehityshaarassa, joita ovat kehitykseen kytettv mainline-haara ja vakaita lhdekoodiversioita yllpitvt release-haarat. Lisksi versionhallinnasta lytyy private-

31

haara, jossa kyttjt voivat yllpit omaa, ei julkaistavaksi tarkoitettua koodia ja erilaisia testej. Tarkoitukseen lytyy mys muita toteutuksia, joista osa on maksullisia ja osa ilmaisia. Toinen suosittu, niin ikn avoin versionhallintasovellus on CVS (Concurrent Versions System) [Gru86]. Tss alikohdassa perehdytn perusksitteiden lisksi lhinn Subversionilla tapahtuvaan versionhallintaan, koska se on tss projektissa pasiallisesti kytss. CVS ja Subversion ovat toiminnaltaan samankaltaisia, ja Subversionia pidetn yleisesti CVS:n jatkokehitettyn versiona. Subversion on edeltjns kehittyneempi esimerkiksi transaktioiden toiminnan suhteen, jolloin tiedostoja tallennettaessa kyttj voi varmistua siit, ett muutosten tallennus ei j keskeneriseksi. CVS: kytettess saattaa kyd niin, ett tallennuksen keskeytyess esimerkiksi tiedonsiirtovirheen vuoksi vain osa halutuista muutoksista j voimaan. Perusksitteet Versionhallinnan keskeisin ksite on tiedon silytyspaikka (repository), joka tarjoaa keskitetyn paikan pkopion (master copy) silyttmiseen projektin tiedostojen eri versioista. Silytyspaikka on palvelinsovellus, jonka on syyt sijaita tarkoitukseen pyhitetyll palvelinkoneella, joka on luotettava, tehokas ja tietoturvaltaan ajan tasalla. Tietoturvan merkitys nousee erityisasemaan etenkin silloin, kun ohjelmistonkehittjille halutaan tarjota psy versionhallintaan mys internetin kautta esimerkiksi kotoaan. Tiedon tallentamiseen voidaan kytt tavallisia tiedostoja tai esimerkiksi tietokantaa. Vaikka silytyspaikkaa voisi teoriassa kytt mys perinteisena tiedostopalvelimena, on sen perimminen tarkoitus nimenomaan tiedostojen versiointi, jolloin edellytyksen on ett sinne tallennetaan vain ohjelmiston lhdekoodia. Mys muu tieto, kuten tekstimuotoiset dokumentit sopivat versioitavaksi, kunhan ne ovat selkokielisi. Binridatan muutoksia ei ole jrkev versioida, koska ne eivt ole johdonmukaisia tai ihmiselle ymmrrettvi. Mys binritiedostoja voidaan kuitenkin tallentaa, mik on tarpeen esimerkiksi kntmisess kytettville tiedostoille tai jos tiedoston lhdekoodia ei ole saatavilla. Ohjelmiston muokkaamista varten kyttj tarvitsee itselleen pkopiosta tehdyn paikallisen tykopion (working copy), jota hn voi vapaasti muokata, knt ja ajaa. Oletuksena pkopiosta haetaan yleens uusin versio, mutta kyttj voi valita mys haluamansa vanhemman version. Paikallinen kopio voi olla kopio koko ohjelmistosta, tai vain sen yksittinen osa. Suurta ohjelmistoa kehitettess on luultavasti helpompaa ottaa kopio vain ksittelyn kohteena olevasta kansiosta tai yksittisest tiedostosta. Ohjelmisto saattaa sislt suuren mrn hakemistoja, mutta hyvin suunniteltu ohjelmisto mahdollistaa sen yksittisten osien kehittmisen muiden osien hiriintymtt, jolloin kyttj voi sst aikaa ja levytilaa ksittelemll vain tietty hakemistoa. Kun kyttj on tehnyt tykopioonsa haluamansa muutokset ja todennut ne kntyviksi ja mielelln mys toimiviksi, hn voi tallentaa muutokset silytyspaikan pkopioon. Versionhallinta kasvattaa versionumeroa automaattisesti tallennuksen yhteydess, ja kunkin version muutokset merkitn nkyviin. Tallennettaessa kyttjlt pyydetn yleens tehdyist muutoksista lyhyt selkokielinen selitys, jonka perusteella yksittisen muutoksen tarkoitus ja ajankohta voidaan myhemmin paikantaa helpommin kuin

32

kooditason muutoksia tarkastelemalla. Versionumeroiden ilmaisukyky voidaan parantaa nimemll niit liitteill (tags). Silytyksess oleva pkopio voidaan mys haarauttaa. Tm voi olla hydyllist esimerkiksi silloin, jos ohjelmistokehittj haluaa tehd ohjelmistoon laajoja muutoksia, jotka voivat vaikuttaa muiden kehittjien tyhn. Design Combus Oy:n versionhallinnassa kytetn kahta kehityshaaraa, joista toinen on tarkoitettu vakaalle tuotantoversiolle ja toinen epvakaalle, kehitysvaiheessa olevalle versiolle. Haarautettua kopiota voidaan kehitt rinnakkain phaaran kanssa ja yhdist siihen tarvittaessa takaisin. Tm helpottaa huomattavasti tilanteita, joissa kyttj haluaa tehd ohjelmistoon epvarmoja tai radikaaleja kokeiluja, ja kytt siit huolimatta versionhallintaa. Subversion Subversion on monipuolinen versionhallintaohjelmisto, joka tukee perusominaisuuksien lisksi muun muassa atomisia tallennuksia, HTTP-protokollaa, BerkeleyDB-tallennusta ja symbolisten linkkien versiointia. Lisksi kopioinnit ja haaroitukset ovat kevyit ja mys binridatan tallennus onnistuu. Perusksitteiden yhteydess mainittujen vaiheiden toteuttamiseen voidaan kytt Subversionin tapauksessa joko komentoriville sytettvi komentoja tai tarkoitukseen luotuja kyttjsovelluksia, joilla sama voidaan tehd helposti graafisen kyttliittymn avulla. Esimerkki hyvst kyttjsovelluksesta on Windowsilla toimiva TortoiseSVN, joka tarjoaa suoraviivaisen kyttliittymn Subversion-palvelimen selaamiseen ja muokkaamiseen. Mys komentorivin kytt on intuitiivista ja hyvien ohjeiden ansioista graafista kyttjsovellusta ei vlttmtt tarvita. Kyttjn useimmin tarvitsemat komennot ovat add, checkout, commit, copy, move, merge ja update. Komentorivin hyvksym syntaksi on muotoa svn komento [asetukset] [argumentit]. Asetukset ovat komennolle annettavia lisoptioita, joita tarvitaan esimerkiksi ksiteltvn version mrittmiseen. Argumentit taas ovat useimmille komennoille vlttmttmt sytteet, ja ne ovat usein pteltviss Unixin perustykalujen argumenteista. Esimerkiksi kansiota siirrettess argumenteiksi tulee kopioitavan kansion lhde- ja kohdesijainti. Kyttj aloittaa ohjelmiston muokkaamisen yleens checkout-komennolla, jolla haetaan haluttu kohde palvelimelta. Komento vaatii sytteekseen kohteen osoitteen. Esimerkiksi komento svn checkout svn://palvelin/home/svn/repository/projekti hakee oletuksena uusimman version pkopiosta, mutta asetuksiksi voidaan antaa mys haluttu versio. Kun kyttj on tehnyt ohjelmistoon haluamansa muutokset, hn voi tallentaa ne commit-komentoa kyttmll. Komennon yleisin kytttapa on kutsua komentoa tallennettavaksi haluttavasta paikallisesta kansiosta tai vaihtoehtoisesti antamalla kansio argumenttina. Copy- ja move-komennot vastaavat saman nimisi Unix-kskyj, eli niill suoritetaan halutun kohteen siirtminen tai kopioiminen. Molemmat tarvitsevat argumenteikseen sek lhde- ett kohdepolun. Copy-komennolla voidaan ktevsti suorittaa ohjelmiston osien haaroittaminen ja move-kskyll kohteiden uudelleennimeminen.

33

Loput mainituista komennoista ja muut Subversionin sisltmt komennot on koottu selityksineen liitteeseen 1.

34

4 Palvelinsovelluksen valinta ja vaatimukset

Jokainen verkko-ohjelmisto tarvitsee tuekseen palvelinsovelluksen ulkomaailman kanssa kommunikointia varten. Tst syyst projektin esitutkimusvaiheen yksi trke osa-alue oli sopivan HTTP-palvelinsovelluksen etsiminen, joka toimisi toteutettavan hallintasovelluksen. Yhten vaihtoehtona olisi ollut palvelimen toteuttaminen itse, mutta jo pelkstn avoimien HTTP-palvelimien mr on suuri, joten sopivan valmiin toteutuksen lytyminen tuntui todennkiselt. Sopivan palvelinsovelluksen lytmist vaikeuttivat projektin kohdeympristn asettamat tekniset rajoitteet ja tietoturvavaatimukset. Lisksi projektille asetettiin tietyt pmrt verkko-ohjelmiston yllpidettvyyden suhteen, joten palvelinsovelluksen tarjoamat sovelluskehityst tukevat rajapinnat tai kehitysympristt olisivat hydyksi. Tm luku ksittelee niden vaatimuksien huomioimista teknisesti ja suunnittelullisesti erilaisin kriteerein. Luvussa tarkastellaan niden kriteerien perusteella valittua palvelimien joukkoa, joista poimitaan sopivimmat ratkaisut. Jljelle jneisiin kolmeen palvelinsovellukseen tutustutaan luvussa tarkemmin ja niiden kesken valitaan kytettv palvelinsovellus.

4.1 Jaotteluperusteet
Alustaviksi HTTP-palvelinsovellusten jaotteluperusteiksi otettiin lisenssiehdot, tuetut ohjelmointikielet, prosessimalli, mahdolliset sivupohjamekanismit, sovelluksen koko ja tietoturva. Nist trkeimpin kriteerein pidettiin lisenssiehtoja, prosessimallia ja tietoturvaa. Erityisen trke on mys sovelluksen pieni koko, koska sovelluksen loppukyttymprist on sulautettu jrjestelm, jolloin kytettviss oleva muistikapasiteetti on rajoittunut. Lisenssiehdot Yksi trke tekij web-palvelimien kartoituksessa on niiden tarjoamat lisenssiehdot. Ilman mahdollisuutta kytt yrityksen liikeideaan soveltuvaa lisenssi ohjelma ei sovellu kyttn, vaikka sen muut ominaisuudet tyttisivt asetetut vaatimukset. Sopiva lisenssi on tss tapauksessa avoin ja maksuton, joka ei vaadi sill luodun sovelluksen lhdekoodin julkaisemista. Mys maksulliset vaihtoehdot soveltuvat kyttn, mikli ne tarjoavat hinnalleen sopivan vastineen. Kytnnss lisenssin perusteella tytyi jtt pois kaikki GPL-lisenssin alaiset palvelimet, koska GPL-lisenssi on tarttuva ja nin ollen kaikki siihen toteutettavat muutoksen on julkaistava niin ikn GPL:n alaisena. Lisksi rajapintojen kautta siihen liittyv ohjelmakoodi on julkaistava. [FSF91] Mys suljetun ohjelmistokoodin palvelimia pidettiin alustavasti poissuljettuina, koska haluttiin mahdollistaa palvelimen koodin muokkaus tarvittaessa. Tllin ohjelmisto on joustava ja kohdeympristn erityispiirteet voidaan ottaa huomioon itse palvelinsovelluksen toteutuksessa. Tm helpottaa sovelluksen integrointia olemassa olevaan sovellusympristn ja voi mahdollistaa mys tehonparannuksia tai helpotusta ohjelmiston siirtmisess kohdeympristst toiseen.
35

Kytttarkoituksiimme parhaat lisenssit ovat BSD- ja MIT-lisenssit tai niiden johdannaiset, jotka sallivat koodin rajoittamattoman kytn. Koodiin voi tehd vapaasti muutoksia ja kyttn otettua koodia ei tarvitse julkaista minkn tietyn lisenssin alaisena, vaan sen voi esimerkiksi halutessaan julkaista suljettuna ja siit voi peri maksun. Suurin osa maksullisten palvelimien tarjoajista antavat kyttn mys ohjelmiston lhdekoodin, ja usein niiden lisenssi mahdollistaa omien ohjelmistojen julkaisemisen ainoastaan suljettuna. Mys tllaiset lisenssit sopivat projektin tarkoituksiin, kunhan lisenssiin ei liity mitn kytt hankaloittavia valvontamekanismeja ja lisenssin hinta on kohtuullinen palvelimen tarjoamiin ominaisuuksiin nhden. Koska palvelinsovellusta on tarkoitus kytt laitteessa, jonka vuosittainen tuotantomr on useita tuhansia kappaleita, on toivottavaa, etteivt lisenssikustannukset kasva jyrksti sovelluksen kohdelaitteiden mrn mukaan. Tuetut ohjelmointikielet Koska erilaisten palvelimien skaala on laaja, on odotettavissa, ett mys tuettuja ohjelmointikieli on lukuisia. Suurin osa palvelimista tukee CGI- tai FastCGIrajapintaa, joiden avulla web-palvelin voi ksitell pyyntj ohjelmointikielest riippumattomien ympristmuuttujien ja standard-IO:n kautta. Tavallisen CGI:n ongelmana on sen raskaus, koska jokaista pyynt ksittelemn luodaan oma prosessinsa, joka ksittelyn ptteeksi tuhotaan. Vaikka FastCGI vhent tt ongelmaa, pidettiin tmn projektin kannalta tarkoituksenmukaisimpana etsi menetelm, joka tukisi verkko-ohjelmiston kirjoittamiseen kytettv ohjelmointikielt suoraan. Koska CGI:n kautta avautuu mahdollisuus muun muassa PHP-, Python-, ja Ruby-kielille kehitettyjen sovelluskehysten kyttnottoon, otettiin kuitenkin mys sille tarjottu tuki huomioon. Koska verkko-ohjelmistolla hallittavan Iris 440 laitteen Config API rajapinta on toteutettu C++-luokilla, suoraviivaisin ohjelmointikieli hallintasovelluksen toteuttamiseen olisi C++ tai C. Useimmissa tapauksissa tuettu toteutuskieli tarkoittaa mys itse palvelimen toteutuskielt, joten muilla kielill, kuten Javalla toteutetut palvelinratkaisut jtettiin kartoituksen ulkopuolelle. Java jtettiin kielivaihtoehtojen ulkopuolelle, koska Java-virtuaalikonetta ei suorituskyky- ja integrointisyist haluttu asentaa kohdeympristn. Prosessimalli Kohdassa 2.3 todettujen seikkojen perusteella kohdeympristn kannalta sopivin prosessimalli palvelinsovellukselle olisi SPED, eli yhden prosessin tapahtumaohjattu sovellus. SPED-tyyppisen palvelimen kytn oletettiin helpottavan sen integrointia olemassa olevaan sovellusympristn ja lisksi se tarjoaisi pienen sstn palvelimen kyttmn muistimrn suhteen. Myskn monisikeisi sovelluksia ei pidetty mahdottomana vaihtoehtona, mutta valinnassa pyrittiin yksinkertaisimpaan mahdolliseen ratkaisuun ja siten SPED-malliin.

36

Ainoastaan yhden, sikeettmn prosessin kytst voi yhtaikaisten pyyntjen ilmaantuessa aiheutua palvelimen vasteaikaan liittyvi ongelmia, vaikka projektin kohdeympristss ei voidakaan odottaa kyttjilt tulevien pyyntjen ruuhkaa. Tm edellytt palvelimen huolellista toteutusta ja olosuhteiden muutosten varalle mys jonkin vaihtoehtoisen prosessimallin tarjoaminen on eduksi. Monet palvelimet mahdollistavatkin muiden asetusten ohella mys prosessimallin valinnan ympristn tarpeille sopivaksi. Sovellusarkkitehtuuri Koska hallintasovellus haluttiin luoda sen yllpidettvyytt ja uudelleenkytt silmll piten, oli sen toteutuksessa kytettvn sovellusarkkitehtuurin syyt tukea jotain ulkoasun ja sislln toisistaan irrallaan pitv arkkitehtuuria. Tllaiseen tarkoitukseen sopisivat monet verkko-ohjelmistojen kehittmiseen tarkoitetut PHP-sovelluskehykset, tai esimerkiksi Ruby on Rails, joka on Ruby-kielelle kehitetty MVC-arkkitehtuuria noudattava avoin sovelluskehys. Sovelluskehyksi ja -arkkitehtuureita ksiteltiin tarkemmin kohdassa 2.5. Jotkin palvelimet, kuten Klone, Seminole ja GoAhead WebServer tarjoavat verkkoohjelmistojen kehittmiseen oman ohjelmointirajapintansa, joka luetaan kartoituksessa eduksi, jos se on hydyksi tmn projektin kohdesovelluksen toteuttamisessa. Palvelinkohtaisen ohjelmointirajapinnan hydyllisyys riippuu paljolti sen tarjoamien toimintojen soveltuvuudesta projektiin. Rajapinnan olisi syyt tarjota joustava menetelm geneeristen nkymien luomiseen ja helppo liitynt HTTP-rajapintaan, jolloin tiedonsiirtoprotokollien toimintaan ei tarvitsisi kiinnitt huomiota. Vaikka rajapinnan on syyt olla tarpeeksi laaja, voi liian monipuolinen rajapinta olla vaikeaselkoinen ja hankala kytt. Erityisen paljon merkityst on ohjelmointirajapinnan toteutuskielell, koska kytnnss vain C- ja C++-rajapinnat ovat tss projektissa kyttkelpoisia. Toivottavaa olisi mys jonkinlaisen sivupohjamekanismin tarjoaminen, jonka avulla voidaan sisllytt HTML-tyyppiseen sivupohjaan dynaamisesti haettua tietoa. Lisksi eri konteksteille, kuten yhteystapahtumille ja pyynnille kuuluvan datan ksitteleminen erilln pitisi olla mahdollisimman yksinkertaista. Tm voi tapahtua esimerkiksi tallentamalla eri kontekstien muuttujien omaan nkyvyysalueeseensa, joiden alustamisesta esimerkiksi uuden istunnon yhteydess huolehtii palvelinohjelma. Tll tavoin esimerkiksi GoAheadin web-palvelimessa erityyppisten muuttujien ksittely tapahtuu erittin suoraviivaisesti. Koko Palvelimen teho- ja muistivaatimuksen on oltava mahdollisimman pieni, koska kohdelaitteen suoritinteho ja muistikapasiteetti on rajoittunut. Palvelinsovellusten karsinnassa huomioitiin sen koko, arvioituna karkeasti tar-paketin koon perusteella. Tll tavoin arviointi on eptarkkaa, joten sit kytettiin vain viitteellisen arviona. Kuitenkin esimerkiksi Apache- ja Litespeed-palvelimet oli helppo karsia pois jo pelkstn asennuspaketin koon perusteella. Palvelimen muistivaatimuksen rajoittamiseen auttaa sen modulaarisuus, jolloin palvelimen ohjelmakoodiin voidaan sisllytt vain tarvittavat osat. Modulaarisuuden ansiosta esimerkiksi alikohdassa 4.3.3

37

esiteltv Seminole-palvelin pysyy kohtalaisen laajasta ohjelmointirajapinnastaan huolimatta kevyen. Tietoturva Yksi trke jaottelukriteeri oli tietoturva, koska SHDSL-laite on kriittinen osa verkkoa, jolloin se on pystyttv suojaamaan mahdollisilta hykkyksilt. Riittvn tietoturvan takaamiseen vaaditaan vhintn jokin autentikointimenetelm, jolla voidaan varmistua siit, ett vain sallitut kyttjt psevt ksiksi hallintasovellukseen. Thn tarkoitukseen voidaan kytt esimerkiksi HTTP-protokollan tarjoamia autentikointiskeemoja, joita ksiteltiin alikohdassa 2.4.1. Varsinkin etyhteyksi varten tarvitaan tuki mys tiedonsiirron suojaavalle salausprotokollalle, joten tuki esimerkiksi SSL- tai TLS-protokollalle lasketaan eduksi. Nm protokollat tarjoavat mahdollisuuden ptepisteiden autentikointiin julkisen avaimen menetelmll ja tiedon salaukseen symmetrisell salausavaimella alikohdassa 2.4.2 esitetyll tavalla. Autentikoinnin ja tiedonsiirron salauksen lisksi hallintasovelluksen toteutuksessa on otettava huomioon autorisointi, eli ohjelman kyttjkohtaiset hallintaominaisuudet. Autorisointimekanismit ovat kuitenkin palvelinsovelluksesta riippumattomia, joten niit ksitelln hallintasovelluksen suunnittelun ja toteutuksen yhteydess luvussa viisi.

4.2 Palvelinratkaisujen kartoitus

Kyttn otettavan web-palvelimen valinta aloitettiin etsimll lupaavilta vaikuttavia vaihtoehtoja internetist. Yksinkertaisimmillaan tm tapahtui Google-hakukoneen avulla, jolla lytyi runsaasti tietoa web-palvelimista erilaisilla hakusanoilla, kuten web server, http daemon ja httpd. Hakutuloksia pyrittiin painottamaan kevyisiin palvelinratkaisuihin erilaisilla lismreill, kuten lightweight ja embedded. Hakukriteerit pyrittiin valitsemaan lyhsti, koska tarkoitus oli lyt mahdollisimman suuri osa tarjolla olevista ohjelmistoista, vaikka ne eivt lopullisten vaihtoehtojen joukkoon ptyisikn. Kaikkien valintaperusteiden ei viel kartoitusta tehdess voitu olettaa olleen selvill, joten karsintaa ei haluttu tehd epvarmojen ominaisuuksien perusteella. Tietyt esikriteerit tyttneet palvelinsovellukset koottiin Excel-tiedostoon, jonka sarakkeet perustuivat kohdassa 4.1 esiteltyihin jaotteluperusteisiin. Taulukko palvelinsovelluksista on esitelty liitteess 2. Kevyill esikriteereill karsittiin pois joitakin kaikkein yksinkertaisimpia, ainoastaan staattisen tiedon nyttmisen mahdollistavia palvelimia sek raskaampia, tehokkaille palvelinkoneille tarkoitettuja palvelimia. Raskaampien palveliminsovellusten mahdollistama yhtaikaisten kyttjien lukumr ja esitettvn tiedon monipuolisuus ylittisivt toteutettavan sovelluksen tarkoituksen, koska tarkoituksena on tehd kevyt, vain muutaman yhtaikaisen kyttjn hallintasovellus. Kaikki tarkasteluun otetut toteutukset eivt olleet kokonaisia palvelimia. Mukana oli mys muutama koodikirjasto, jotka tarjoavat jonkin mahdollisesti projektiin soveltuvan sovelluskehyksen, mutta vaativat tuekseen erillisen palvelinsovelluksen. Toisaalta

38

pinvastainen esimerkki on libwebserver-kirjasto, jonka tarkoituksena on tarjota perinteiselle sovellukselle web-palvelimen toiminnallisuus. Libwebserverin kytt vastaa jossain mrin palvelinkohtaisen API-rajapinnan kytt, joskin palvelinominaisuuksien toteuttaminen kirjastona saattaa parantaa verkko-ohjelmiston itsenisyytt. Lisenssin perusteella karsittiin pois vain pieni joukko palvelimia, sill suurin osa niist oli joko tysin avoimia tai tarjosivat maksullisen lisenssin. Suurin osa GPL-palvelimista oli mys ominaisuuksiltaan vaatimattomia, jolloin oma verkko-ohjelmisto olisi luotava kytnnss CGI-rajapintaa kyttmll. Tntnet-palvelimen [Mk04] lisksi mikn GPL-palvelimista ei tukenut sulautettua tiedostojrjestelm, jolloin niill ei olisi suurta etua myskn sulautettua kohdeymprist ajatellen. Sulautetussa tiedostojrjestelmss verkko-ohjelmiston staattiset tiedostot knnetn samaan binriin palvelinsovelluksen kanssa. Tllin palvelimen ksittely helpottuu ja koko yleens pienenee. Sulautetun tiedostojrjestelmn kytn edellytyksin on, sit tarvitaan vain lukemiseen ja ett staattisessa tiedossa ei tapahtu muutoksia. Suurimmasta osasta palvelimia lytyi mys SSL-tuki, joka oletettiin tarpeelliseksi riittvn tietoturvan takaamiseksi. Suurin osa palvelimista tuki mys HTTPautentikaatiota ja lhes jokainen Unixin oikeudenhallintamenetelmi tiedostojen suojaukseen. Harvinaisempia tietoturvamenetelmi olivat Monkey HTTP-daemonin tukema URL- ja IP-perusteinen esto sek tietoturvaltaan monipuolisimpien Abyss Web Serverin [AT01] ja Zeus Web Serverin [ZT95] tukema epilyttvien pyyntjen esto ja DoS (Denial of Service) hykkysyritysten tunnistaminen. Kaksi jlkimmist palvelinta olivat tosin tarkasteluun psyn rajamailla, koska kumpaankaan ei ole saatavilla lhdekoodia ja etenkin Zeus on projektin tarkoituksiin liian raskas. Palvelinsovellusten suurimmaksi kompastuskiveksi osoittautui tuki SPEDprosessimallille, koska moni palvelin toimi moniprosessisena ja suurin osa monisikeisen. Molempaa mallia pidettiin huonona vaihtoehtona, koska mikli verkkoohjelmisto haluttaisiin tehd palvelimen tarjoamalla ohjelmointirajapinnalla, pitisi mys siin itsessn huomioida usean prosessin tai sikeen kyttn liittyvt ongelmat. Muun kuin CGI-tyyppisen verkko-ohjelmiston toteutuksen kannalta yksinkertaisin vaihtoehto olisi selkesti SPED-tyyppinen palvelin, koska silloin palvelimen integrointi kohdeympristn olisi helpointa. SPED-tyyppisi palvelimia oli tarkasteltavassa ryhmss kuitenkin vain yhdeksn, joista osa oli kaiken lisksi GPL-lisenssin alaisia, joten vaihtoehdot olivat vhisi. Nist vaihtoehdoista lydettiin kuitenkin kaksi ominaisuuksiltaan lupaavaa palvelinta: Klone ja Seminole, joita ksitelln kohdassa 4.3. Samassa kohdassa esiteltv GoAhead WebServer valittiin lhempn tarkasteluun lhinn vakuuttavien tosielmn sovellusesimerkkiens asiosta. Lisksi sen tukemien tekniikoiden mr oli sulautetuille jrjestelmille suunnitellulle palvelinsovellukselle poikkeuksellisen laaja. Tarkasteluun ptyi yhteens 36 HTTP-palvelinta, joista tss luvussa mainittujen kriteerien perusteella varteenotettavia vaihtoehtoja oli lopulta seitsemn kappaletta. Kyseiset palvelimet nkyvt taulukossa 4-1. Taittosyist johtuen osa alkuperisen taulukon sisltmist kriteerisarakkeista on jouduttu karsimaan.

39

Taulukko 4-1. Ominaisuuksiltaan lupaavimmat palvelinsovellukset.

Ohjelma Klone Seminole AppWeb/ Mbedthis GoAhead WebServer Lighttpd thttpd Fusion Lisenssi GPLv2/maksullinen $499-$1999 maksullinen tysin avoin BSD (muokattu) BSD maksullinen CGI ei ei on on on on Templ. on on on on ei ei Prosessimalli SPED SPED single/multithreaded single/multithreaded SPED SPED SPED/multithreaded Koko (kt) 5370 pieni 6860 2590 3680 550 11 Tietoturva TLS/SSL, session SSL Auth, SSL Auth, SSL Auth, SSL permissions, SSL HTTPS server

AppWeb/Mbedthis [Mbe03] on ominaisuuksiltaan lhes vastaava GoAhead WebServerin kanssa, joskin jlkimminen on hivenen kehittyneempi. Lighttpd- ja thttpd-palvelimissa kiinnostavimmat ominaisuudet koskivat PHP-kielisen verkkoohjelmiston integrointia SAPI (Server Application Programming Interface) moduulien avulla. Verkko-ohjelmiston toteuttamista PHP-kielell pidettiin kuitenkin toissijaisena ratkaisuvaihtoehtona, koska sille toteutettujen sovelluskehysten vaatimukset etenkin muistinkytn suhteen ovat yleens tmn projektin vaatimuksia kevyempi. Mys projektin kohdeympristn ennalta mrtyn mallin ja sen rajapinnan ansiosta PHPsovelluskehyksiss usein kytettv SQL-tietokantaa ei voida hydynt.

4.3 Tarkoitukseen parhaiten sopivat ratkaisut

Luvussa aiemmin esiteltyjen jaotteluperusteiden mukaisen karsinnan jlkeen alkuperisist palvelinvaihtoehdoista ji jljelle lopulta kolme palvelinsovellusta: GoAhead WebServer, Klone ja Seminole. Tss kohdassa kydn lpi ppiirteittin niden palvelinsovellusten keskeisimmt ominaisuudet ja toimintaperiaatteet sek niiden hyvt ja huonot puolet tmn projektin kannalta. Sovellusten toimintaa havainnollistavat esimerkit ovat yksinkertaistettuja, ja niit kytetn lhinn palvelimen keskeisen idean havainnollistamiseen, ei niiden toiminnan selvittmiseen perinpohjaisesti. Tss kohdassa on hydynnetty Klonen, GoAhead WebServerin ja Seminolen teknisi dokumentteja [KL07], [GA00], [GS06a] ja [GS06b].

4.3.1 GoAhead WebServer

GoAhead WebServer on avoimeen lhdekoodiin perustuva sulautetuille jrjestelmille suunniteltu HTTP-palvelin, jota on sovellettu monissa kaupallisissa ptelaitteissa, kuten Telewellin EA501 ADSL-modeemeissa. Lupaavien sovellusesimerkkiens ansiosta GoAhead WebServer nousi lukuisten muiden palvelimien joukosta yhdeksi varteenotettavimmista palvelinvaihtoehdoista. Sen trkeimpi etuja ovat pieni muistivaatimus, tuetut tietoturvamenetelmt ja niiden kyttn tarjotut rajapinnat sek pohjautuminen yleisiin tekniikoihin kuten ASP (Active Server Pages), CGI ja JavaScript. Niden tekniikoiden lisksi GoAhead tarjoaa suunnittelijalle oman

40

ohjelmointirajapintansa, joka helpottaa dynaamisen sislln esittmist verkkosivuilla. Se kytt tst konseptista nimityst GoForms. Palvelimen asetukset GoAhead WebServer ei sisll varsinaista asetustiedostoa, vaan sen asetukset sijaitsevat kyttjrjestelmkohtaisen pohjelmatiedoston alkuosassa. Esimerkiksi Linuxkyttjrjestelmlle asetukset merkitn tiedostoon LINUX/main.c. Sinne merkitn verkko-ohjelmiston hakemisto, tietoturvasalasana, kuunneltava portti ja uuden kuunteluportin haun yrityskerrat kuvassa 4-1 esitellyll tavalla.
1 2 3 4 static static static static char_t char_t int int *rootWeb = T("web"); *password = T(""); port = 80; retries = 5;

Kuva 4-1. Palvelimen asetukset main.c-tiedostossa.

Palvelimen tietoturvaominaisuuksien kyttnotto ei vaadi erillisi asetuksia, vaan ne ovat verkko-ohjelmiston kytettviss erilaisten rajapintojen kautta. Tarvittavat funktiot lytyvt um.h ja websda.h tiedostoista, joista ensimminen tarjoaa palvelimelle kyttjnhallinnan ja jlkimminen digest-skeeman mukaisen kyttjn autentikoinnin. ASP Active Server Pages (ASP) on Microsoftin kehittm tekniikka, jonka avulla voidaan tarjota verkkosivuilla dynaamista sislt. Tm tapahtuu sulauttamalla tavanomaiseen HTML-koodiin skriptej, jotka generoivat dynaamisen sislln ennen sivun lhettmist kyttjlle. GoAhead kytt skriptikielen JavaScriptin kevennetty variaatiota nimelt Ejscript. ASP ei kuitenkaan sido suunnittelijaa tiettyyn skriptikieleen, vaan se voidaan vapaasti valita script-direktiivin language-parametrilla. Yleisimmin kytetn VBScript-, JScript-, JavaScript- tai Perl-kieli. Skriptit suoritetaan palvelimella, joten selaimen ei tarvitse tukea kytettv skriptikielt. GoAheadin ohjelmointirajapinta tarjoaa mahdollisuuden hydynt ASP-sivujen kautta mys C-funktioita. Thn kytetn websAspDefine()-kutsua, joka vaatii parametreikseen kytettvn C-funktion nimen ja sen kutsumanimen ASP-tiedostosta. GoForms Tmn projektin kannalta GoAheadin merkittvin ominaisuus on GoForms, joka mahdollistaa verkko-ohjelmiston logiikan eli kontrollin tehokkaan eristmisen kyttjn havaitsemasta nkymst. Perinteisen CGI:n tavoin GoForms kytt kommunikointiin ympristmuuttujia, joiden kautta se selvitt esimerkiksi yhteysosapuolen osoitteen ja HTTP-pyynnn parametrit. Toisin kuin CGI, GoForms ksittelee jokaisen kutsun samassa prosessissa, jolloin tarvittava muistimr ei kasva suuresti kutsumrn lisntyess. Haluttua GoFormia voidaan kutsua selaimella esimerkiksi muodossa http://palvelin/goform/omaFormi?nimi=Henri&ika=22, jolloin pyynnn ksittely

41

ohjautuu omaFormi-nimiselle GoFormille. Esimerkki GoFormista nkyy kuvassa 4-2. Ksittelij kirjoittaa yhteyskahvaan wp silt saadut parametrit nimi ja ik, jonka lisksi se kirjoittaa HTML-tiedoston otsakkeen ja ptteen sek vastauskoodin OK. Esimerkin GoForm kytt ainoastaan GoAheadin omia API-kutsuja, mutta vastaanotettuja parametrej voidaan kytt mys monipuolisemmin, esimerkiksi hakemalla henkillle nimen ja in perusteella tietokantaan tallennettuja listietoja.
1 2 3 4 5 6 7 8 void omaFormi(webs_t wp, char_t *path, char_t *query) { websHeader(wp); websWrite(wp, Nimi: %s <BR>, websGetVar(wp, nimi, )); websWrite(wp, Ika: %s, websGetVar(wp, ika, )); websFooter(wp); websDone(wp, 200); }

Kuva 4-2. Esimerkki GoForm-ksittelijst.

Ksittelijlt saatu vaste on esitelty kuvassa 4-3. Palvelimen lhettmi sivun yl- ja alaosaa voidaan muokata haluttuun muotoon websHeader()- ja websFooter()funktioista. Sovellus voi kytt edellisen kuvan rivin 7 websDone()-funktiota mys muiden kuin tss lhetetyn vastauskoodin 200 palauttamiseen.
<HTML> <HEAD> <TITLE>GoAhead WebServer</TITLE> <META HTTP-EQUIV="Content-Type" CONTENT="text/html"> </HEAD> Nimi: Henri <BR> Ika: 22 </BODY> </HTML>

Kuva 4-3. Ksittelijlt saatu vaste.

Teknisist ominaisuuksistaan, avoimuudestaan ja tosielmn sovellusesimerkeist huolimatta GoAhead ei vakuuttanut suunnittelultaan siin mrin, ett se olisi otettu projektissa lopulta kyttn. Suurimpana asiana askarrutti Ejscriptin joustavuus riittvn monipuolisten sivupohjien luomiseen eri nkymille. Lisksi sivupohjan valinta pitisi toteuttaa kytnnss joko suoralla pyynnll, uudelleenohjauksella tai jonkinlaisella include-mekanismilla, joista jokainen on liian kankea tmn projektin tarkoituksiin. Kytettv sivupohjaa olisi syyt pysty vaihtamaan yhdest muuttujasta, jolloin sivupohjan valintaan ei vaikuta ainoastaan saadut parametrit, vaan esimerkiksi datan haussa tapahtunut virhe voi aiheuttaa tietyn sivupohjan latautumisen. Heikkoutena kahteen muuhun kohdassa esiteltyyn palvelinsovellukseen nhden on mys sivupohjien sijainti omassa hakemistossaan, jolloin niiden syntaksi tarkistetaan vasta ajon aikana. Tllin monet yllttvt virhetilanteet saatetaan huomata kntmisen sijaan vasta sovellusta ajettaessa.
42

4.3.2 Klone
Klone on sulautetuille jrjestelmille suunniteltu web-palvelin, joka tarjoaa suunnittelijalle mahdollisuuden hajauttaa palvelimen rakenne nytn, logiikan ja tiedon suhteen erillisiin osiin. Klone tukee SPED-prosessimallia, joka helpottaa ohjelmiston integrointia kohdejrjestelmn ja kevent palvelimen taakkaa muistin kytn suhteen. Ohjelman toimii tarvittaessa mys fork- tai prefork-moodissa, joten se sopii suurellekin yhtaikaiselle pyyntmrlle, jos suorituskyky ei ole ongelma. Fork-asetus tarkoittaa moodia, jossa palvelin voi kytt hydykseen mielivaltaista mr lapsiprosesseja, joita se kynnist uusien pyyntjen saapuessa. Prefork-asetus on moodi, jossa palvelin luo kynnistyessn kyttjn asettaman kiinten mrn lapsiprosesseja. Tyn kohdeympristss yhteyksien mr oletetaan pieneksi, joten nit asetuksia ei kytnnss tarvita. Tulevaisuutta ajatellen ylimristen vaihtoehtojen lytyminen lasketaan kuitenkin eduksi. Klone mrittelee mys oman ohjelmointirajapintansa, joka helpottaa verkkoohjelmiston luomista sen tarjoamien funktioiden avulla. Rajapinta sislt funktiot muun muassa otsikkokenttien, pyyntjen, vasteiden, sessioiden, tulosteiden, sytteiden ja erilaisten muuttujien ksittely varten. Niden avulla voidaan luoda helposti esimerkiksi yksinkertainen sessionhallinta ilman, ett koko mekanismi jouduttaisiin ohjelmoimaan itse. Klonen erikoisominaisuus on verkko-ohjelmiston ja palvelinsovelluksen kntminen yhdeksi binriksi, jolloin ohjelmiston sek dynaaminen ett staattinen sislt sek itse ohjelmisto knnetn yhdeksi ajettavaksi binriksi. Tm binri on ernlainen sulautettu tiedostojrjestelm. Tiedostojrjestelm knnetn kyttjrjestelmn omalla kntjll, jolloin saavutetaan ohjelmiston tehokas suoritus ja pieni muistivaatimus. Klonen minimivaatimuksiksi luvataan noin 140kt ROM-muistia ja 70kt RAM-muistia, jotka soveltuvat tyn kohdeympristlle erittin hyvin. Kytnnss verkko-ohjelmisto muodostuu kl1-muotoon tallennettavista HTMLsivupohjista, joiden sisn voi kirjoittaa C-kielisi skriptej. Skriptin eri osille kytetn nelj erilaista lohkoa, joita ovat liitoslohko, esittelylohko, koodilohko ja tulostuslohko. Kuhunkin lohkoon laitetaan tiettyj koodin osia, jolloin koodin rakenne selkeytyy. Lohkojen kytttarkoitukset ovat kuitenkin vain viitteellisi, joten ohjelmoija voi ottaa niiden kytss vapauksia. Koodissa voi kytt mys ulkoisia funktioita tallentamalla ne C-tiedostoina erilliseen paikkaan ja kutsumalla niit kl1-tiedostosta. Erilaisten koodilohkojen merkitys on seuraava: Liitoslohko: lohkolla voidaan liitt sivuun erillisi staattisia tai dynaamisia osia muista tiedostoista. Liitoslohkon mritykset tulevat <%@ ja %>-sulkeiden sisn. Esittelylohko: varsinaisessa koodissa tarvittavat sisllytykset, funktiot ja globaalit muuttujat esitelln erillisess esittelylohkossa. Esittelylohkon mritykset tulevat <%! ja %>-sulkeiden sisn. Koodilohko: jokaiselle pyynnlle suoritettava koodi, sivun ernlainen "mainmetodi" asetetaan koodilohkoon. Koodilohkossa voidaan esittelylohkossa

43

mriteltyjen ja sen omien muuttujien lisksi kytt Klonen esimriteltyj funktioita. Koodilohkon sislt tulee <% ja %>-sulkeiden sisn. Tulostuslohko: lohkossa voidaan tulostaa muuttujien arvoja. Tulostuslohkon mritykset tulevat <%= ja %>-sulkeiden sisn.

HTML-sivupohjien ja niiden sisltmien koodilohkojen kytt on yleisi web-sivuilla kytettvi skriptikieli hallitsevalle suunnittelijalle suoraviivaista. Menetelmn avulla Klone tuo sulautetun jrjestelmn verkko-ohjelmiston luomisen askeleen lhemms nykyaikaista, suoraviivaista web-ohjelmointia. Palvelimen asetukset Klone-palvelimen asetusten mrittminen tapahtuu helpoiten palvelinohjelmaan sisllytettvst kloned.conf-tiedostosta, joka sijaitsee sulautetun tiedostojrjestelmn etc-kansiossa. Yleisimmt huomioitavat asetukset ovat palvelimen tyyppi, prosessimalli, protokolla, portti ja verkko-ohjelmiston juurihakemisto. Kuvan 4-4 esimerkkikonfiguraatiossa mritelln verkko-ohjelmisto nimell oma_www. Prosessimallina on tss tapauksesa prefork, jolloin ohjelma luo aluksi kolme klonedprosessia, jotka huolehtivat palvelimelle tulevista pyynnist. Sovellus kuuntelee porttia 80, ja etsii nytettvt sivut juurihakemistosta www. Asettamalla konfiguraatioon vastaavalla tavalla useamman eri nimisen verkko-ohjelmiston, voidaan samalla sovelluksella kynnist monta eri sivustoa.
1 2 3 4 5 6 7 8 9 server_list oma_www oma_www { type http model prefork addr.type IPv4 addr.port 80 dir_root /www }

Kuva 4-4. Klone-palvelimen asetustiedosto kloned.conf.

Tiedostoon kloned.conf asetetaan mys palvelimen mahdolliset SSL-asetukset, joissa mritelln kytettvt avaintiedostot ja salauksen asetukset. Kytettv asetustiedosto voidaan mritt mys palvelimen kynnistmisen yhteydess, jolloin kytetn palvelinsovelluksen -f -vipua asetustiedoston osoittamiseen. Yksinkertainen pyynnnksittelij Yksi sivu voi muodostua useasta eri kl1-tiedostosta, joita voidaan liitt mukaan liitoslohkon avulla. Liitosmekanismin avulla voidaan luoda yksinkertainen pyynnnksittelij, joka vastaanottaa HTTP-kutsun halutut parametrit ja valitsee niiden perusteella kyttjlle lhetettvn sivun. Kytnnss tm tarkoittaa sit, ett pyynnn parametreja tarkastellaan ehtolauseilla, ja tietyn ehdon tyttyess sit vastaava kl1sivupohja liitetn mukaan.

44

Seuraava yksinkertainen kl1-tiedosto kuvassa 4-5 sislt vain HTTP-pyynnn ksittelyn, mutta ei vasteen muodostamista kyttjlle. Tss tapauksessa ksittelij siirt vastuun tulostuksesta tysin sisllytettvlle sivupohjalle eli kl1-tiedostolle tpl1 tai tpl2.
1 2 3 4 5 6 7 8 <% vars_t *in_args = request_get_args(request); int tpl = vars_get_value_i(in_args, "tpl"); if (tpl == 1) { include "tpl1.klone" } else if (tpl == 2) { include "tpl2.klone" %> %> %> %>

<%@ <% <%@

Kuva 4-5. Esimerkki yksinkertaisesta dispatcher-skriptist, joka valitsee sisllytettvn sivupohjan.

Toiminta voi liitoslohkojen jlkeen jatkua mys dispatch.kl1-tiedostossa, mutta Klonen tarjoamilla keinoilla tm on tarpeettoman vaivalloista, koska keinot eri kontekstien muuttujien muokkaamiseen eivt ole kovinkaan monipuoliset. Ainoastaan sessiomuuttujille voidaan helposti asettaa nimi-arvo-pareja session_t-tietuetta ksittelevill funktioilla, kun taas esimerkiksi pyyntkohtaisten asetusten muuttaminen ei vastaavalla tavalla onnistu. Tten pyyntjen ketjumainen vlittminen eri kl1tiedostojen vlill ei onnistu halutulla tavalla. Sen sijaan nkymn hallinta pit siirt toiselle sivupohjalle ja suorittaa siell request_get_args-funktiolla pyyntjen haku ja haluttujen tietojen tulostus, kuten kuvan 4-6 tpl1-sivupohjassa on esitelty. Siin HTTPparametri nimell objnm tallennetaan muuttujaan ja tulostetaan nkymn.
1 2 3 4 5 6 7 8 9 10 11 12 13 <html> <head><title>Show</title></head> <body> <% vars_t *args = request_get_args(request); // shortcut char *objnm; objnm = vars_get_value(args, "objnm"); io_printf(out, "<b>Objname:</b> %s<br />", objnm); %> </body> </html>

Kuva 4-6. Sivupohja, jonka dispatcher sisllytt vaadittujen ehtojen tyttyess.

Vaikka Klonen tarjoamat menetelmt sivupohjien kyttn ovat yksinkertaisilla sivuilla suoraviivaisia, eivt jotkin sen piirteet tysin soveltuneet projektin tarkoituksiin. Kuten esimerkist ky ilmi, sivupohjan valinnan suorittava dispatcher luodaan Klonen omalla skriptikielell sen sijaan, ett se voitaisiin toteuttaa standardilla C-koodilla. Vaikka palvelimen oman ohjelmointirajapinnan kyttminen asettaa verkko-ohjelmiston toteutukselle tiettyj rajoituksia, haluttiin toteutettavan sovelluksen palvelinsidonnaisen
45

koodin osuus pit mahdollisimman pienen. Mikli jo pelkk sivupohjan valinta tehdn palvelinkohtaisella skriptikielell, olisi toteutettava sovellus todennkisesti hyvin riippuvainen kytettvst palvelimesta. Toinen hiritsev seikka Klonessa on se, ett se ei tarkalleen mrittele ohjelman logiikan sijaintia verkko-ohjelmiston arkkitehtuurissa. Kun sivupohjan valinta tehdn pyynnn parametrien vastaanottamisen jlkeen skriptikielell selkesti yhdess sivupohjassa, voidaan haettavan tiedon saantitapa mritell muualla, esimerkiksi sisllytettvss sivupohjassa. Tiedonhaku dispatcher-sivupohjassa olisi huono vaihtoehto siit syyst, ett silloin sivupohjan lisksi mys tietoon psyyn kytettv ohjelman osa, esimerkiksi listattavien objektien hausta vastaava funktiokutsu, pitisi suorittaa dispatcher-sivupohjassa, mik monimutkaistaisi sit entisestn. Jlkimminen vaihtoehto, eli tiedonhaku sisllytettvst sivupohjasta, taas olisi huono siit syyst, ett nkymt eivt vlttmtt mene yksi yhteen tiedon saantimenetelmn kanssa, vaan useat eri nkymt saattaisivat hakea tiedon samalla tavalla. Kumpikaan tapa ei noudata MVC-mallia, joka todettiin projektille soveltuvaksi web-arkkitehtuuriksi kohdassa 2.5. Kolmas, ja tss tapauksessa ehkp jrkevin tapa, olisi luoda C-kielell tiedon hakemiselle oma geneerinen funktionsa, joka hakisi nkymien tarvitsemat tiedot yhtenisell tavalla ilman, ett nkymn generoinnista vastaavan logiikan tarvitsee tuntea hakemaansa tietoa tai sen saantimenetelm. Toteutettavassa hallintasovelluksessa tarvittaisiin tiedon hakemisen lisksi omat funktionsa mys hallintaobjektien lisys-, muokkaus- ja muille toiminnoille.

4.3.3 Seminole
Kolmesta lupaavimmasta palvelinsovelluksesta sopivimmaksi osoittautui Seminole. Tss alikohdassa kydn ppiirteittin lpi Seminole-palvelimen tekniikka ja perusperiaatteet. Tmn projektin kannalta Seminolen trkein ominaisuus on nkymn eristminen ohjelman logiikasta HTML-sivupohjien avulla, joten alikohdan yksinkertaistettu esimerkkiohjelma hydynt kyseist tekniikkaa. Seminole on sulautetuille jrjestelmille suunniteltu HTTP-palvelin, jonka etuja ovat erittin pieni koko, monipuolinen ohjelmointirajapinta ja modulaarinen rakenne. Seminolen korkean tason ohjelmointirajapinta erist ohjelmoijan matalan tason protokollien yksityiskohdilta, mutta tarvittaessa mahdollistaa niiden muokkaamisen. Yleisi sovelluskohteita Seminolelle ovat sulautettujen jrjestelmien webkyttliittymt, etproseduurikutsujen ksittely, ympristns mukautuvat aputoiminnot ja perinteiset jrjestelmt, joille halutaan mahdollistaa tiedon vlitys HTTP-protokollalla. Seminolen toteutuskieli on C++, joka mahdollistaa lyhsti yhdistetyn modulaarisen rakenteen, jolloin kyttmttmist ominaisuuksista ei koidu ylimrist kuormaa. Eri kytttarkoituksiin suunniteltuja palvelimia varten voidaan luoda omat pyynnn ksittelijns, joiden avulla palvelimen kyttn saa tsmlleen sen tarvitsemat toiminnot. Seminole sislt joitakin tavanomaisia ksittelijit esimerkiksi uudelleenohjausta ja tiedostopalvelinta varten. Omaa sovellusta varten halutunlaisen ksittelijn voi luoda itse. Lukuisten luokkien avulla verkkoohjelmistossaan voi hydynt muun muassa sivupohjia, pyyntjen ja vasteiden ksittely, SSL-salausta ja -autentikointia sek sessionhallintaa.

46

Klonen tapaan mys Seminole tarjoaa mahdollisuuden knt koko palvelimen hakemistopolku yhdeksi binriksi, jolloin palvelimen ajaminen on nopeaa ja suuri osa virheist tulee esiin jo knnsvaiheessa. Lisksi ohjelmoija voi hienost sovellusta lukuisilla knnsaikaisilla ominaisuuksilla. Kun palvelin ja sille toteutetut verkkoohjelmistot ovat yhdess tiedostossa, on sen siirtminen hakemistosta tai jopa tietokoneesta toiseen vaivatonta. Ympristn muuttuessa on tietysti huolehdittava binrin ja jrjestelmrajapintojen yhteensopivuudesta ja ajon aikana ladattavien kirjastojen saatavuudesta. Yksi Seminolen vahvuus on sen siirrettvyys eri alustoille. Sen alustakohtainen koodi on eristetty niin kutsutulle siirrettvyyskerrokselle, jonka avulla se tarjoaa valmiin tuen monille alustoille, kuten POSIX (Solaris, Linux, BSD jne.), Win32, VxWorks, uC/OS2 ja eCos. Vaikka tmn projektin puitteissa ei ole nkyviss tarvetta muille kuin Linuxalustalle, niin siirrettvyys antaa joustavuutta tulevaisuuteen ja kertoo lisksi ohjelmiston huolellisesta suunnittelusta. Lisksi Seminolen kokonaan avoin lhdekoodi antaa suunnittelijalle mahdollisuuden kohdeympristn ominaispiirteiden huomiointiin. Palvelimen asetukset GoAhead WebServerin tapaan myskn Seminole ei sisll omaa tiedostoa palvelimen asetuksia varten, vaan tavallisesti ne mritelln kytettvn verkko-ohjelmiston globals.cpp-tiedoston c_servername- ja c_serverport-muuttujilla, jotka tarkoittavat palvelimen host-nime ja kuunneltavaa porttia. Palvelimen tietoturva-asetuksia voidaan hallita ports/Seminole-tiedostosta, joka sislt palvelimen kntmiseen liittyvi asetuksia. Tiedostosta voidaan asettaa INC_BASIC_AUTH ja INC_DIGEST_AUTH muuttujat, joiden perusteella basic- tai digest-autentikointiskeeman kyttmahdollisuus sisllytetn palvelimen koodiin. Autentikaation varsinainen kyttnotto tehdn verkko-ohjelmistossa, jonka HttpdHandler-luokalle eli pyynnn ksittelijlle luodaan Authenticator-olio, jolle mritelln sallitut kyttjtunnukset ja salasanat sek ksittelijn kattama realmalue. Autentikoinnin lisksi Seminole mahdollistaa mys SSL-salauksen kytn, joka voidaan ottaa kyttn asettamalla ports/Seminole-tiedoston INC_SSL-muuttuja ja muokkaamalla verkko-ohjelmiston main.cpp-tiedostoa siten, ett se kutsuu Httpd::Start()-metodia haluttuja SSL-asetuksia vastaavilla parametreilla. Lisksi ports/Seminole-tiedoston INC_MULTIPLE_TRANSPORTS-muuttuja pit olla asetettu, jotta palvelin kykenee yllpitmn useita erityyppisi soketteja. Projektissa toteutettu verkko-ohjelmisto kytti kuvassa 4-7 esiteltyj SSL-asetuksia.
pem:web.pem sock:ssl rand-file:4096,/dev/urandom

Kuva 4-7. Httpd::Start()-metodille annettavat SSL-parametrit.

47

Parametreilla asetetaan kytettvksi avaintiedostoksi web.pem-tiedosto, josta lytyy kytettv PKI-sertifikaatti eli palvelimen julkinen ja salainen avain. Soketin tyypiksi annetaan SSL, jotta kuljetettavan tiedon valitsin osaa kytt SSL-protokollaa tavanomaisen TCP-protokollan sijaan. Salauksessa tarvittavat satunnaismerkkijonot saadaan Linuxin satunnaislukugeneraattorilta. Sivupohjat Trkein seikka, jolla Seminole erottui muista tarkastelluista HTTP-palvelimista ei ollut pieni koko, sulautettu tiedostojrjestelm tai tietoturvaominaisuudet, vaan sen tarjoamat menetelmt nkymien luomiseen. Seminolen nkymtyypit voidaan toteuttaa HTMLsivupohjina, joissa esitettvksi haluttu tieto mritetn erilaisten silmukka- ja ehto- ja arviointirakenteiden avulla. Menetelm on hydyllinen dynaamisen tiedon ksittelyyn siten, ett toteutettavasta verkko-ohjelmistosta saadaan jrjevsti yllpidettv. Sivupohjat auttavat yllpidettvyydess siksi, ett niiden avulla sivujen ulkoasun ja asettelun muokkaaminen ei vaadi sovelluslogiikan muokkaamista. Lisksi sivupohja on usein riippumaton sen tietosisllst, jolloin nkymien toteuttamisen vaatima tymr ei kasva tietosislln lisntyess. Seminolessa sivupohjien rakenteiden syntaksi tarkistetaan palvelimella knnn aikana, jolloin vltytn ylimrisilt ajonaikaisilta virheilt. Tiedon nyttminen sivupohjalla tapahtuu HttpdFSTemplateShell::Execute()metodilla. Tm metodi tarvitsee parametreikseen pyynnn tilan ja sytettvksi halutun tietosislln, jota kutsutaan Seminolen termein symbolitauluksi. Symbolitaulu sislt nkymss esitettvn datan, joka voidaan sivupohjassa mritt esitettvksi halutulla tavalla. Symbolitaulun erikoistapaus on symbolikartta, joka helpottaa tietueisiin tallennetun datan esittmist. Kun HttpdFSTemplateShell::Execute()-metodia kutsutaan, se huolehtii kaikesta tulostukseen liittyvist esivalmisteluista ja prosessoi halutun sivupohjan, joka asettelee nkymn Execute():lle mritetyn symbolikartan sislln. Kuvan 4.8 esimerkiss esitelln, miten halutun tiedon tallentaminen symbolikarttaan ja nkymn prosessoinnin aloittaminen tapahtuu.

48

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

/* -- demo.cpp -* luodaan uusi kyttjtili */ UserAccount some_account; /* luodaan symbolikartta sym_map, joka saa sytteenn * user_account_map -structissa mritetty rakenne, * symbolien mr sek some_account-muuttujan muistiosoite */ HttpdSymbolMap sym_map(user_account_map, 2, &some_account); /* asetetaan kyttjtilille nimi ja rooli */ some_account.mpName = "Antti Admin"; some_account.mpRole = "Administrator"; /* asetetaan kytettv sivupohja */ state.mpFilepath = "/nakyma.thtm"; /* prosessoidaan tiedot */ (void)HttpdFSTemplateShell::Execute(state, &sym_map);

Kuva 4-8. Kyttjtilin tietojen ja sivupohjan asettaminen demo.cpp-tiedostossa.

Execute()-metodin ensimmisen argumenttina on tietue state, joka sislt tietoa

vastaanotetusta HTTP-pyynnst ja sen perusteella mritetyst tiedostosta. Kytettv sivupohja mritetn rivill 17 asetetulla state.mpFilePath-muuttujalla. Muuttuja antaa vapauden kytt symbolikartan tietosislt usealla eri sivupohjalla. Tm on erityisen hydyllist silloin, kun halutaan tarjota kyttjlle mahdollisuus tietojen tarkasteluun useassa eri muodossa, esimerkiksi HTML-sivuna tai RSS-sytteen. Kuvassa 4-9 esitelln sivupohja, jossa nkyy miten nytettvksi halutut arvot mritetn eval-komennolla. Komento kertoo sivupohjalla nytettvksi halutun muuttujan nimen. Muuttujien nimet sivupohjissa on mritetty symbolikartan rakenteessa (user_account_map).

49

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

<!-- index.thtm --> <html> <head> <title>Template Demonstration</title> </head> <body> <h1>User Data</h1> <table border="1"> <tr> <td>User name</td> <td>%{eval:name}%</td> </tr> <tr> <td>Role</td> <td>%{eval:role}%</td> </tr> </table> </body> </html>

Kuva 4-9. Sivupohja, joka mr nytettvn tiedon esitystavan.

Muita mahdollisia direktiivej ovat loop-komento silmukoita varten sek if- ja ifnotkomennot ehtolauseita varten. Jokaiselle komennolle voidaan asettaa mys mys attribuutteja, joiden perusteella komennon suorittamisesta vastaava ksittelij voi toteuttaa erilaisia listarkasteluja. Sivupohja muistuttaa hyvin paljon lopullista HTML:, jolloin sen toteutus sommittelun ja ulkoasun suhteen riippuu mahdollisimman vhn alla toimivasta kontrollista ja mallista. Sivupohjan nkkulmasta tiedon saantitavalla tai sen alkuperisell sijainnilla ei ole merkityst, vaan olennaisia ovat ainoastaan sen esitystapaan liittyvt seikat.

50

5 Suunnittelu ja toteutus
Web-hallintasovelluksen suunnittelun ensimminen vaihe oli sovelluksen graafisen kyttliittymn suunnittelu. Tm suunnitteluvaihe oli ensimminen siksi, ett sovelluksen asiakasvaatimukset olivat projektin alkuvaiheessa melko hyvin tiedossa, ja ne eivt olisi paljonkaan riippuvaisia projektin teknisest toteutustavasta. Sovelluksen toiminnallisiin vaatimuksiin perustuva kyttliittymn suunnittelu oli jrkev tehd ennen teknist suunnittelua. Toiminnalliset vaatimukset perustuvat Iris 440 laitteen hallinnan yleisiin kytttapauksiin, jotka selvitetn CLI-hallintasovelluksen ominaisuuksien ja laitteen kyttohjeen perusteella. Kyttliittymn suunnittelun jlkeen seuraava vaihe oli sovelluksen luokkien suunnittelu ja toteuttaminen. Mys luokkien tarvitsemat metodit ja tietorakenteet oli suunniteltava. Luokka-arkkitehtuurin suunnittelu tehtiin ennalta suunniteltujen nkymien pohjalta, joiden perusteella pteltiin tarvittavat luokat. Luokkien tarvitsemat metodit ja tietorakenteet luotiin sovellusmoottorin alapuolella sijaitsevan mallin ja lopullisten nkymien vaatimusten mukaan. Tss luvussa ksitelln mys hallintasovelluksen integrointia laitteen sovellusympristn. Luvun lopussa ksitelln vasteen muodostamisen eri vaiheita verkko-ohjelmiston nkkulmasta.

5.1 Kyttliittym
Kyttliittymn todellisia, konkreettisia nkymi kutsuttiin nkymiksi ja niiden erilaisia luokkia nkymtyypeiksi. Eri hallintaobjekteja vastaavat konkreettiset nkymt voidaan jaotella niiden tyypin mukaan, joista saadaan hallintasovelluksen vaatimat geneeriset nkymtyypit. Tllaisen jaottelun avulla sovelluksen lopullinen toteutus voitaisiin laatia suunniteltujen nkymtyyppien pohjalta, jolloin vaadittava tymr vhenee. Kun jokainen nkym suunnitellaan johonkin nkymtyyppiin pohjautuen, vaatii uuden saman tyyppisen nkymn lisminen hallintasovelluksessa vain nkymn parametrien mrittelyn. Nkymn parametreja ovat esimerkiksi hallintaobjektin piilotettavaksi halutut attribuutit tai viitteet muihin attribuutteihin. Nkymtyyppien suunnittelussa mriteltiin pasiassa niiss esiintyvien attribuuttien tyypit (ennaltamrtty avain fkattr, avain kattr tai tavallinen attribuutti nattr), toiminnot ja eri elementtien asettelu. Nkymtyyppien attribuutit merkittiin attribuutin tyyppi vastaavalla lyhenteell ja toiminnot painikkeita esittvill laatikoilla, joissa lukee toimintoa kuvaava teksti. Muita mriteltvi elementtej ovat esimerkiksi nkymn otsikko tai sen sisltmt linkit muihin nkymiin. Kyttliittymn ulkoasun suunnitelma toteutettiin PowerPoint-esityksen, jossa jokainen nkym sijaitsee omalla sivullaan. Suunnitelmassa pyrittiin mahdollisuuksien mukaan sisllllisesti hyvin lopullista vastaaviin nkymiin, vaikka lopullinen ulkonk mrytyisi kytettvien kuvaus- ja skriptikielten (HTML, CSS ja JavaScript) kytttavan mukaan. Mys teknisiin asioihin, kuten sytekenttien muotoon ja linkkien kyttn pyrittiin vastaamaan mahdollisimman kattavasti.

51

5.1.1 Suunnitteluperiaatteet
Hallintasovelluksen kyttliittymn suunnitteluperusteina kytettiin CLIhallintasovelluksen osoittamia kytttapauksia ja niiden vaatimien ominaisuuksien toteuttamista. Kytttapauksia pidetn yleisesti hyvn ratkaisuna kyttjvaatimusten kartoittamiseen, sill ne osoittavat tehokkaasti ohjelmalta vaadittavat ominaisuudet kyttjn nkkulmasta [HaM98, s. 135]. Graafisen kyttliittymn olisi kyettv tarjoamaan vhintn samat tarkastelu- ja muokkausmahdollisuudet, kuin mitk CLIhallintasovellus tarjoaa. Tm tarkoittaa pasiassa siltojen ja niiden porttien, fyysisten liitntjen ja niiden VLAN (Virtual Local Area Network) asetusten, laitteen verkkoasetusten, hallinta-asetusten sek SNMP-asetusten hallintaa ja asianmukaista esittmist. Samoja kytttapauksia kytettiin myhemmin mys kyttliittymn kytettvyystestiss, jota ksitelln alikohdassa 5.1.5. Kytttapausten selvittmisess hydynnettiin mys Iris 440 laitteelle laaditun kyttohjeen esittelemi konfigurointimahdollisuuksia ja erilaisia kyttliittymlle esitettyj toiveita. Ensisijaisen suunnitteluperusteen valintaan pdyttiin, koska CLI:n vastaanotto asiakkaiden taholta on ollut pasiassa hyv, ja koska se esittelee kattavasti Iris 440:n muokattavaksi tai nytettvksi vaadittavat ominaisuudet. Tst huolimatta suunnittelun aikana on muistettava, ett CLI- ja web-kyttliittymt ovat toiminnaltaan erilaisia, jolloin CLI:ss hyvksi todettu ratkaisu ei vlttmtt toimi graafisessa kyttliittymss. Tten on syyt vltt CLI:n ominaisuuksien orjallista kopiointia ja ottaa web-kyttliittymn suunnittelussa tiettyj vapauksia. Tmn lisksi yleisen suunnitteluperiaatteena pidettiin sovelluksen geneerisyytt, jonka avulla voidaan mahdollistaa sen helppo muokattavuus ja laajennettavuus. Tm heijastuu kyttliittymn suunnitteluun nkymtyyppien geneerisyyten. Nkymtyypit voidaan parametrisoida, ja parametreja muokkaamalla saadaan toteutettua eri objektityyppien vaatimat konkreettiset nkymt. Yksinkertaistettuna kyttliittym voidaan jakaa neljn eri nkymtyyppiin: objektin lisys, muokkaus, nyttminen ja objektien listaus. Nit nelj ptyyppi pyrittiin kyttmn mahdollisimman kattavasti koko hallintasovelluksen laatimiseen, joskin mys muita nkymtyyppej oli toteutettava erikoisempia nkymi ja poikkeustapauksia varten. Varsinaisten suunnittelukriteerien lisksi ohjelmisto ja sen kyttliittym pyrittiin toteuttamaan inkrementiaalisesti, jolloin siihen toteutettaisiin aluksi vain vlttmtn perustoiminnallisuus. Nkymtyyppien kartoituksessa pyrittiin lytmn minimimr tyyppej, joilla hallintasovellus voitaisiin toteuttaa kytettvyyden merkittvsti krsimtt. Nin ohjelmistolle voidaan toteuttaa nopeasti jonkinlainen runko, johon voidaan list ominaisuuksia tarpeen mukaan [HuTh00, s. 48]. Nkymtyyppien mrn minimointi ei saa kuitenkaan vhent laitteen hallintaominaisuuksia. Kun ohjelman perustoiminnallisuus on valmis, siihen voitaisiin helposti list kytettvyytt ja toiminnallisuutta parantavia nkymi ja toimintoja. Tst huolimatta on selv, ett nkymtyyppien mr tulee protektin aikana kasvamaan, ja listaa myhemmin toteutettavista ominaisuuksista ja nkymist on syyt kert tyn edetess. Aluksi luotu nkymtyyppien minimijoukko oli kompromissi nkymien vlisen yhdenmukaisuuden ja sovelluksen riittvn kytettvyyden vlill. Yhdenmukaisuuden kasvaessa eri objektityyppien ominaispiirteiden huomiointi vhenee, jolloin nkymist
52

tulee helposti kankeita ja kytttarkoitukseensa epjohdonmukaisia. Tm kuitenkin aluksi sallittiin, koska nkymtyyppien lukumrn kasvu lis mys niiden toteuttamiseen vaadittavaa tymr.

5.1.2 Nkymien suunnittelu

Kyttliittymsuunnitelman ensimmisiss versioissa pyrittiin luomaan kattava kuva erilaisista nkymist ja niihin liittyvist ominaispiirteist. Vaikka nkymien geneerinen suunnittelutapa pidettiin mieless alusta lhtien, ei ollut johdonmukaista yritt heti sovittaa nkymi joihinkin ennalta suunniteltuihin nkymtyyppeihin. Sen sijaan nkymtyypit haluttiin suunnitella vasta tarvittavien nkymien perusteella, jolloin eri nkymien ominaispiirteet voitaisiin huomioida paremmin. Niden lhtkohtien mukaisesti kyttliittymsuunnitelman ensimmiset versiot sislsivt huomattavasti enemmn nkymtyyppej, kuin mihin lopulta pdyttiin. Nkymtyyppien mr voitiin jatkossa vhent yhdistmll samankaltaisia nkymtyyppej toisiinsa. Ers suunnittelussa ilmaantunut graafisen kyttliittymn ongelma oli tilanne, miss jokin nkym sislsi muokattavia attribuutteja ja samalla siirtymi muihin nkymiin. Silloin kyttjlle voi olla epselv, katoavatko sivulle sytetyt tiedot siirryttess vai jvtk ne muistiin odottamaan kyttjn paluuta. Tst syyst esimerkiksi lomakenkymn ei pitisi samalla sislt siirtymi muihin nykymiin, tallennusta ja peruutusta lukuunottamatta. Rajoittamalla tllaisen nkymn siirtymismahdollisuudet vain nihin kahteen, vltytn silt ongelmalta, joka seuraisi, mikli sivulta siirryttisiin muualle sen jlkeen kun jotakin lomakkeen sytekentt on muokattu. Kytnnss tm tarkoittaa erillist hallintaobjektin attribuuttien nyttmis- ja manipulointinkym. Lisksi attribuuttien manipulointi jaettiin viel erilliseen lisysja muokkausnkymn. Siirtyminen navigointivalikon painikkeilla kesken muokkauksen tosin onnistuu edelleen, mutta silloin kyttjn voidaan olettaa ymmrtvn lomaketietojen hviminen. Yksi luonnollinen ero CLI- ja web-kyttliittymss on se, ett kun komentorivill objektin muokkaaminen ja nyttminen tapahtuu erillisill komennoilla, niin graafisessa kyttliittymss nm kaksi asiaa voidaan osittain yhdist. Liitteess 3 esitellyn sillan muokkausnkymn toteutuksessa pit huomioida tarkasti se, mitk objektin attribuutit ovat muokattavia ja mitk ainoastaan nytettvi. Kuvassa objektin muokattavat attribuutit on merkitty kursiivilla. Sillan muokkausnkymss sen avainattribuutti eli nimi ei voi olla muokattavissa, koska sit muutettaessa mys muokattava silta vaihtuisi. Eri nkymluokat voidaan jaotella neljn pluokkaan, joita ovat lisys (add), muokkaus (edit), lista (list), nyttminen (show). Nist pluokista on lukuisia variaatioita ja lisksi tarvitaan joitakin erikoisnkymi, kuten staattiset nkymt. Nkymtyypit Add-nkymtyyppi on hallintaobjektin lismiseen tarkoitettu nkymtyyppi, joka sislt tallennus- ja peruutuspainikkeet. Nkymn otsikko sislt listtvn objektityypin nimen. Nkymss olevat attribuutit jaotellaan ennaltamrttyihin avainattribuutteihin (fkattr), jotka eivt ole kyttjn muokattavissa, sek avainattribuutteihin (kattr) ja tavallisiin attribuutti (nattr), jotka kyttj voi itse valita. Esimerkki tmn tyyppisest nkymst on sillan lisys liitteess 4.

53

Edit-nkymtyyppi kytetn olemassaolevan hallintaobjektin muokkaamiseen, ja se sislt lisysnkymn tapaan tallennus- ja peruutuspainikkeen. Nkymn otsikko sislt muokattavan objektityypin nimen. Nkymss olevat attribuutit jaotellaan avainattributteihin (kattr), jotka eivt ole kyttjn muokattavissa ja tavallisiin attribuutteihin (nattr), jotka kyttj voi itse valita. Esimerkki tmn tyyppisest nkymst on sillan editointi liitteess 3. List_cut-nkymtyyppi kytetn hallintaobjektien listaamiseen. Listausnkymn ominaispiirtein on, ett objektien mr ei ole erikseen rajoitettu ja nkymtyypin nimen mukaisesti nytettvien attribuuttien mr on katkaistu. Tm tyyppi sislt objektin nyttmiseen, poistamiseen ja lismiseen tarkoitetut painikkeet, ja sen otsikko sislt listan suodatusehdot ja objektityypin nimen. Esimerkki tmn tyyppisest nkymst on siltojen listaus liitteess 5. List_closed-nkymtyyppi on listausnkymn variaatio, jonka ominaispiirre on objektien ennaltamrtty lukumr. Tm tyyppi sislt objektin nyttmiseen, poistamiseen ja lismiseen tarkoitetut painikkeet, ja sen otsikko sislt listan suodatusehdot ja objektityypin nimen. Esimerkki tmn tyyppisest nkymst on ethernet-liitntjen listaus liitteess 6. Iris 440 laite sislt nelj ethernet-liitnt, joten nm liitnnt esitetn nkymss riippumatta siit, ovatko ne kytss vai eivt. Kytss olevaa liitnt voidaan tarkastella show-painikkeella ja se voidaan poistaa disable-painikkeella. Poissa kytst oleva liitnt voidaan aktivoida enablepainikkeella. List_reset-nkymtyyppi on listausnkymn variaatio, jonka ominaispiirre on objektin nollauksen mahdollistava reset-painike. Lisksi tyyppi sislt painikkeen objektin nyttmiseen, ja sen otsikko sislt listan suodatusehdot ja objektityypin nimen. Esimerkki tmn tyyppisest nkymst on liitntjen laskurien listaus liitteess 7. Image_download-nkymtyyppi kytetn laitteen uuden levykuvan lataamista varten. Tm tyyppi on luotu saman nimist nkym varten, joka sislt sytekentn levykuvan osoitetta varten ja painikkeen lataamisen aloittamiseksi. Nkym on esitelty liitteess 8. Image_install-nkymtyyppi kytetn uuden levykuvan asentamiseen laitteen flashmuistille. Tm tyyppi on luotu saman nimist nkym varten, joka sislt tiedot haetusta levykuvasta ja painikkeen asennuksen aloittamista ja levykuvan tuhoamista varten. Nkym on esitelty liitteess 9. Progress-nkymtyyppi on luotu saman nimist nkym varten, jolla ilmaistaan kyttjlle ett jokin toiminto, esimerkiksi levykuvan kopiointi tai asennus on kesken. Esimerkki tyypist on levykuvan kopiointi liitteess 10. Static_config_menu-nkymtyyppi on luotu saman nimist nkym varten, joka on asetustiedoston ksittelyyn tarkoitettu valikkonkym. Se sislt painikkeet asetustiedoston tallentamista ja poistamista varten sek tehdasasetusten lataamista ja uudelleenkynnistyst varten. Nkym on esitelty liitteess 11.

54

Static_confirm-nkymtyyppi on luotu saman nimist nkym varten, joka on tarkoitettu uudelleenkynnistyksen varmistamiseen. Se sislt painikkeet toiminnon vahvistamiseen ja peruuttamiseen. Nkym on esitelty liitteess 12. Static_flash_complete-nkymtyyppi on luotu saman nimist nkym varten, joka on tarkoitettu levykuvan asentamisen valmistumisen ilmoittamisesta kyttjlle. Se sislt valmistumisesta kertovan tekstin ja reboot-painikkeen. Nkym on esitelty liitteess 13. Static_front-nkymtyyppi on tarkoitettu etusivua varten, jossa voi nky esimerkiksi Design Combus logo tai tietoa hallintasovelluksesta tai laitteesta. Etusivunkym on esitelty liitteess 14. Kyttliittymn ensimmisiss nkymsuunnitelmissa kytettiin useissa nkymiss back-painiketta helpottamaan nkymien vlill siirtymist. Esimerkiksi objektin attribuutit nyttv nkym, joka ei sisll lainkaan toimintoja (nkymtyyppi show_noedit, esimerkiksi show SNMP community liitteess 15), olisi kytettvyystestin perusteella kyttjystvllisempi, jos se tarjoaisi helposti havaittavan poispsyn nkymst. Painike koettiin kuitenkin selvsti inkrementiaaliseksi ominaisuudeksi, joten se voitaisiin list tarvittaviin nkymiin myhemmin. Lisksi se tulisi olemaan samankaltainen selaimen oman back-painikkeen kanssa, jota ei vlttmtt ole tarpeen korvata. Back-painike ei myskn ole yht helppo toteuttaa kuin esimerkiksi add- tai edit-nkymiss kytettv cancel, koska toisin kuin cancelin tapauksessa, edellinen nkym ei ole yksiselitteinen. Add-nkymsshn cancel vie aina kyseisen objektin listausnkymn ja edit-nkymss objektin nyttmisnkymn. Ksiteltvn objektin osoittaminen kyttjlle Kun objekti nytetn kyttjlle tai se on listtvn tai muokattavana, pit olla jokin tapa osoittaa kyttjlle mik objekti on kyseess. Tm voidaan tehd esimerkiksi nyttmll objektin avainattribuuttien arvot otsikossa tai listaamalla kaikki tiedot normaalisti allekkain. Eri menetelmien selkeys on tapauskohtaista, sill jollekin objektityypille osoittaminen on selkemp otsikon ja toiselle attribuuttilistan muodossa. Nin monipuolinen objektityyppien erityispiirteiden huomioiminen ei kuitenkaan nkymtyyppien yhtenisyyden vuoksi ollut tarkoituksenmukaista, joten pyrittiin lytmn menetelm, joka toimii parhaiten kaikkien objektityyppien kanssa. Vaikka otsikkossa esiintyvt objektin attribuutit kertovat kyttjlle usein selkesti mit objektia ollaan ksittelemss, voi otsikko muuttua epselvksi, jos siin olevien attribuuttien mr on suuri. Jokin objektityyppi saattaa sislt enemmn avainattribuutteja kuin muita attribuutteja, jolloin otsikon esittm attribuuttimr olisi attribuuttien kokonaismrn nhden suhteettoman suuri. Toisaalta mys otsikon muuttaminen ihmisen luettavaan muotoon voi olla hankalaa verrattuna attribuuttien nimi-arvo-parien listaamiseen allekkain. Otsikon kytt attribuuttien osoittamiseen tukisi se seikka, ett otsikkoa kytetn joka tapauksessa monissa nkymiss objektin identifiointiin objektityypin tai listan suodatinattribuuttien perusteella. Valittu ratkaisu oli attribuuttien listaaminen nimi-arvo-pareiksi siksi, ettei suunnittelussa tarvitsisi huolehtia avainattribuuttien mrst muihin attribuutteihin nhden. Lisksi

55

esitettvn informaation mr kasvaa, koska attribuuteista nkyy siten sek nimi ett arvo pelkn arvon sijaan.

5.1.3 Navigointivalikko
Eri hallintaobjekteja koskevien nkymien vlill navigointia varten sivulle toteutettiin navigointivalikko, josta kyttj voi valita haluamansa hallintaobjektin. Lhes kaikki valikon painikkeet avaavat listan sit vastaavan tyypin objekteista muutamaa objektin nyttmisen avaavaa poikkeusta lukuunottamatta. On huomioitava, ett navigointivalikko ei ole kaikenkattava nkymien vlill siirtymisen suhteen, vaan osa navigoinnista tapahtuu itse nkymiss olevilla painikkeilla ja selaimen back-nappulalla. Valikosta haluttiin tehd niin itseninen kuin mahdollista, mik tarkoittaa sit, ett valikon kulloinenkin tila olisi sen hetkisen nkymn suhteen staattinen, ja eri painikkeista tapahtuvat toiminnot olisivat aina samat. Tmn takia osa objektien listauspainikkeista, kuten VLAN-liitnnt tai siltaan kuuluvat portit, ovat linkkein itse nkymiss sen sijaan ett niihin psisi suoraan navigointivalikosta. Tllin eri objektien vlist viite-eheytt ei tarvitse yllpit navigointivalikossa, vaan riitt ett nkymien objektit tuntevat viitteens muihin objekteihin. Valikon tilan mrmiseen riitt sen hetkinen objektityyppi, jonka perusteella voidaan arvioida miss valikon haarassa ollaan. Esimerkiksi liitteen 15 kuvassa nytetn laitteelle tallennettu SNMPyhteis, jonka perusteella valikolle mrytyy tila, jossa SNMP-haara on avoinna. Suunniteltaessa tiedettiin, ett navigointivalikon toteuttamiseen vaadittavan koodin mr olisi riippuvainen sen toteutustavasta, ja tarkemmin ottaen sen sitouttamisen asteesta projektin kohdeympristn. Yksinkertaisimmillaan valikko voisi olla kovakoodattu valmiiksi, koska kytnnss jokainen tarvittava valikon painike ja sen parametrit tunnetaan etukteen. Tllin valikon jokaisella tilalla voisi olla sit vastaava tunnuksena, joka olisi sitten yhten nkymn parametrina nkym muodostettaessa. Siten jokaista nkym vastaisi yksiksitteinen valikon tila, joka voisi kytnnss olla jokaiseen nkymn sisllytettv valikon HTML-kuvauksen sisltv staattinen tiedosto. Toinen vaihtoehto olisi tehd valikosta lykkmpi, jolloin siihen toteutettaisiin tuotekohtaista dataa ja nkymn kulloistakin tilaa hydyntv logiikkaa. Valikko voisi hakea saatavilla olevat objektityypit ja muodostaa niist viitemerkintj apuna kytten sen hetkist kohdelaitetta vastaava navigointivalikko. Jos valikko tuntisi kulloisenkin nkymn, voisivat kaikki hallintaobjektit olla tavoitettavissa valikosta. Esimerkiksi tietyn ethernet-liitnnn VLAN-mritysten listan saisi nkyviin valikosta kyseisen liitnnn painikkeen alapuolelta. Toteutuksessa pdyttiin kuitenkin yksinkertaisempaan, eksplisiittiseen navigointivalikkoon kiireellisen aikataulun ja ennalta tunnetun kohdeympristn takia. Jos hallittavaksi tulevien laitteiden ominaisuudet vaihtelisivat fyysisesti, niin jonkinlaisen dynaamisen navigointivalikon luominen voisi olla realistisempi vaihtoehto. Kytnnss navigointivalikon eri tiloja esittvt HTML-pohjat tallennettiin omiin tiedostoihinsa, joista kontrolli valitsee nkym koskevan hallintaobjektin perusteella oikean tiedoston. Nkym vastaava valikon tila siis listn nkymn ohjelman suorituksen aikana. Oletuksena kytettiin valikon perustilaa, jotta mikn nkym ei vahingossa jisi kokonaan ilman valikkoa. Huonoa ratkaisussa on sen oletettavasti

56

heikko yhteensopivuus tulevien tuoteprojektien kanssa, mutta toisaalta uudelleenkirjoitettava koodimrkn ei ole suuri.

5.1.4 Painikkeiden toiminnot

Jokainen nkymtyyppi sislt mrtyt toiminnot, jotka kyttj voi suorittaa klikkaamalla toimintoa vastaavaa painiketta. Lopullisessa sovelluksessa painikeet ovat lomakkeiden submit- sytteit, jotka lhettvt lomakkeen parametrit halutulla HTTPmetodilla. Kuhunkin toimintoon liittyy sen tarvitsemat parametrit, joiden muoto on jokaiselle toiminnolle sama. Parametrit muodostuvat toiminnon tyypist, toiminnon kohteena olevasta objektityypist ja lisparametreista. Parametrien lopullinen sislt riippuu sen hetkisen nkymn sisltmst datasta, joiden perusteella painikkeella lhetettv pyynt muodostetaan. Parametrien tiedot voivat olla perisin mallilta, kyttjn tyttmist sytekentist tai ne voivat olla kiintesti mritetty sivupohjaan. Erilaisia toimintotyyppej ovat Show, List, Openadd, Openedit, Add, Update, Delete, Download, Flash, Saveconfig ja Removeconfig. Nm toimintotyypit kartoitetaan palvelinsovelluksessa niit vastaaviin toiminto-olioihin, jotka vastaanotettujen parametrien avulla ksittelevt pyynnn. Kontrollin nkkulmasta vastaanotettuja parametrej tarkastellaan samanarvoisina, ja niiden lopullinen semantiikka riippuu kutsuttavasta toiminnosta. Kontrolli ohjaa HTTP-pyynnn jsentmisen tuloksena saadut parametrit toimintoa ja objektityyppi vastaavalle oliolle. Tm olio tuntee saamiensa parametrien merkityksen ja ksittelee niit vaaditulla tavalla. Kontrollia ja toimintoluokkia ksitelln tarkemmin kohdassa 5.2. Seuraavaksi kydn lpi eri toimintojen rooli sovelluksessa ja niiden tarvitsemat parametrit: Show-toiminto avaa nkymn, jossa nytetn mrtyn objektin attribuutit. Toiminto vaatii parametrikseen objektin yksiselitteisen tunnisteen eli sen tyypin ja avanattribuutit. List-toiminto avaa mrttyjen suodatinattribuuttien perusteella noudetun objektilistan. Toiminto vaatii parametreikseen suodatinattribuuttien arvot. Openadd-toiminto avaa mrtyn objektin lisysnkymn. Toiminto vaatii parametreikseen objektityypin sek ennaltamrtyt avainattribuutit, joita kyttj ei voi nkymss en muuttaa. Openedit-toiminto avaa mrtyn objektin muokkausnkymn. Toiminto vaatii parametreikseen objektityypin ja avainattribuutit. Add-toiminto tallentaa uuden objektin annetuilla arvoilla. Toiminto vaatii parametreikseen objektityypin, avainattribuutit ja muut mritetyt attribuutit. Update-toiminto pivitt mrtyn, olemassaolevan objektin halutuilla arvoilla. Toiminto vaatii parametreikseen objektityypin, sen avainattribuutit ja muut mritetyt attribuutit. Delete-toiminto poistaa mrtyn objektin. Toiminto vaatii parametreikseen poistettavan objektityypin ja avainattribuutit. Download-toiminto kynnist laitteen levykuvan lataamisen ja vaatii parametrikseen ladattavan tiedoston URL-osoitteen.

57

Flash-toiminto kynnist mrtyn levykuvan asentamisen laitteelle, ja tarvitsee parametreikseen objektityypin ja avainattribuutit. Saveconfig-toiminto tallentaa hallintasovelluksen nykyiset asetukset, ja se ei tarvitse parametrej. Removeconfig-toiminto poistaa nykyiset asetukset, ja myskn se ei tarvitse parametrej.

Painikkeet on pyritty sommittelemaan nkymiin siten, ett kyttj mielt jotkin toiminnot samankaltaisiksi niiden lheisyyden perusteella [Kal95, s. 156]. Esimerkiksi liitteen 5 list_cut-nkymss tm nkyy siten, ett new-painike on erilln vierekkisist show- ja delete-painikkeista. Tm johtuu siit, ett new-painikkeella luodaan uusi objekti, kun taas show- ja delete-painikkeilla ksitelln mrtty, jo olemassa olevaa objektia. Toimintojen suorittamisen jlkeist nkym ei voida kertoa yksiselitteisesti, koska se riippuu annettavista parametreista ja voi muuttua ksittelyn kulusta riippuen. Esimerkiksi tietyt objektityypit kyttvt erilaista listausnkym kuin muut, ja ksittelyn johtaessa virhetilanteeseen voidaan antaa eri nkym kuin silloin, jos toiminto onnistuu.

5.1.5 Kytettvyystesti
Kyttliittymn saadessa lopullista muotoaan, sen soveltuvuus loppukyttn kannalta on syyt testata kytettvyystestill. Jo yksinkertaisen pahvimallin avulla tehdyll kytettvyystestill voidaan saada esiin monia kytettvyysongelmia, joita ei suunnitellessa tule ajatelleeksi [HuTh00, s. 53]. Koska kyttliittymn ideoinnissa ja suunnittelussa oli mukana kytnnss vain kaksi henkil, voi siihen helposti jd helposti piirteit, jotka vastaavat liikaa suunnittelijoiden henkilkohtaista nkemyst hyvst kyttliittymst. Lisksi suunnittelijan kokopivinen paneutuminen tyhns voi est hnt nkemst yksinkertaisia virheit tai puutteita. Esimerkkin tst oli nkym, jossa nytettiin selvsti vrn hallintaobjektin attribuutit, ja suunnittelijan sijaan testihenkil huomasi huomasi tmn vlittmsti kytettvyystestin yhteydess. Kytettvyystestauksessa etsitn kyttjlle pnvaivaa tuottavia ohjelman vikoja ja puutteita tarkkailemalla kyttjn toimintaa ohjelman parissa [OvRa98, s. 13]. Testattaviksi toiminnoiksi kannattaa valita useimmiten kytettvi toimintoja, koska niiss kytettvyysparannuksista saavutettu hyty on suurin [Kuu03, s. 72]. Testaus pyrittiin tten toteuttamaan yleisimpien kytttapausten perusteella, joiden oletetaan olevan oleellisia laitteen kyttnoton kannalta. Testausta varten laadittiin kirjallisesti joitakin kytttapauksia, ja testauksen yhteydess esiintyneet ongelmat ja huomiot kirjattiin yls. Kytttapauksia ei noudatettu orjallisesti, vaan testihenkil saattoi halutessaan keksi kytttapauksia mys itse. Tm vapaus annettiin, koska testihenkil oli laitteen asiantuntija ja tiesi mit asetuksia laitteelle tarvitsisi loppukytss asettaa. Mys testihenkiln omat kytttapaukset ja niiss ilmenneet huomiot kirjattiin yls vastaavalla tavalla. Kytnnss testaus tapahtui siten, ett PowerPoint-muodossa oleva kyttliittymsuunnitelma heijastettiin valkokankaalle ja testivalvoja kertoi testihenkillle mit tmn pitisi tehd. Tmn perusteella testihenkil kvi lpi neen,
58

mit nkymien toimintoja hn kyttisi ja mit hn syttisi lomakkeisiin. Testivalvoja selasi nkymi sit mukaa, mihin henkiln kulloinkin suorittama toiminto hnet veisi. Esiintyneiden ongelmien lisksi valvoja kirjasi yls testattavan mainitsemia positiivisiksi havaitsemiaan asioita ja muita sivuhuomioita. Testauksen yhteydess olisi voitu kytt mys videointia, jolloin testitilanne olisi voitu kyd jlkeenpin yksityiskohtaisemmin lpi. Tm koettiin kuitenkin vaikeaksi toteuttaa huonojen teknisten valmiuksien vuoksi ja tarpeettomaksi, koska testivalvoja teki testin aikana huolellisia muistiinpanoja. Esiintyneit huomioita Seuraavat huomiot ovat testauksessa ilmenneit ongelmakohtia esiintymisjrjestyksess. Lisksi on mahdollisesti selvitetty lyhyesti esiin tulleita parannusehdotuksia. Ethernet-liitnnn show-nkymss testattava ei heti hahmottanut modeattribuutin merkityst, jota olisi selkeytettv, jotta kyttj ymmrt sen tarkoittavan linkin nopeutta ja moodia (esimerkiksi 100Mbps full-duplex). Add-nkymn johtava new-painike on merkitykseltn epmrinen. Addpainike voisi nkymn nimen mukaisesti olla testihenkiln mielest johdonmukaisempi. Add-nkymn tallennustoiminnon jlkeen tulevasta nkymst oli epselvyytt. Epselvyys johtui osittain varhaisesta suunnitteluvaiheesta. Add- ja edit-nkymiss virheellisten arvojen ilmaisemista ei ole selvitetty. Latautuuko selaimelle oma virheen ilmaiseva sivunsa vai nytetnk ne sivulla jossa syte on annettu? Miten kyttj tiet add-nkymss syteelle vaaditun muodon? Tekstikentss oleva oletusarvo auttaa, mutta tarpeen lienee list tekstikentn viereen jokin ohjeteksti. Pitisik ainakin joidenkin nkymien sislt back-painike? Painike saattaisi parantaa kytettvyytt, koska testihenkil ei ole tottunut kyttmn selaimen back-painiketta CGI-tyyppisi verkkosovelluksia kytettess. Kun sillalle listn uusi numeroimaton tai VLAN-numeroitu portti, niin linjan oletusarvona oleva 1 voi aiheuttaa epselvyytt ethernet-portin yhteydess. Kun kyttj lis uuden hallinta-IP:n, niin kykeneek hn muistamaan sillalle antamansa nimen, jolle haluaisi IP:n listtvn? Kelvollinen ratkaisu lienee pudotusvalikko luoduista silloista. Onko hallinta-IP:n mrittminen mahdollistettava jokaiselle portille erikseen? Testattavan mielest mahdollistaminen on tarpeen siit huolimatta, ett se saattaisi hmment uutta kyttj. Tallennetun konfiguraation poistomahdollisuus on listtv. Tm ominaisuus ji suunnittelijalta kokonaan huomioimatta, koska ei ollut huomannut kyseist ominaisuutta CLI:ss. Pitisik SNMP-yhteisn add-nkymss nky oletusverkkona 0.0.0.0/0 vai default? Default lienee kuvaavampi, mutta asia voidaan ottaa huomioon vasta toteutusvaiheessa, kun sislln generointimenetelmist on enemmn tietoa. Mit tapahtuu, kun add-nkymn lomakkeeseen sytt tyhjn arvon? Tilanne poikkeaa CLI:st siin mieless, ett siin tyhjn arvon antaminen attribuutille ei ole mahdollista.

59

Pitisik verkkoliitnnn show-nkymss olla linkki kyseisen liitnnn pakettilaskuriin? Testihenkiln mielest laskurin lytminen voisi olla helpompaa liitnnn kautta, mutta suunnitteluperiaatteita noudattaen aluksi kytettneen CLI:n kanssa yhtenist tapaa nytt laskurit statistics-tilan kautta. Show-nkymien linkit voisivat sislt sanan configure (esimerkiksi configure VLAN ports liitnnn VLAN-porttien konfigurointiin pelkn VLAN ports sijaan), jotta kyttjlle selvi, ett siit psee tarkastelun lisksi mys manipuloimaan kyseist objektia.

Testauksessa ilmenneiden ongelmien analysoinnissa oli syyt huomioida, ett testattavana ollut henkil on Iris 440 laitteen ja erityisesti sen CLI-hallintasovelluksen asiantuntija, kuten aiemmin mainittiin. Tmn johdosta etenkn kyttliittymn ja hallintaobjektien esittmistavan informatiivisuuden suhteen ei voida testin perusteella tehd merkittvi positiivisia johtoptksi. Monesti kytettvyystestiss nousee esiin enemmn kysymyksi kuin vastauksia [Kuu03, s. 80]. Testiss tuli esiin paljon asioita, jotka olivat suunnitteluvaiheessa jneet huomiotta. Monille niist saatettiin lyt nopeasti yksinkertainen ratkaisu, mutta useat esiin nousseet seikat jtettiin kyttliittymsuunnitelman ulkopuolelle. Yksi esimerkki tllaisesta asiasta on add-nkymss tallentamisen jlkeen saatava palaute, jos tekstikentn arvo on tyhj. Tlle, kuten monille muillekin vastaavanlaisille seikoille tulee helposti mieleen erilaisia ratkaisuvaihtoehtoja, esimerkiksi objektin mrityksess annetun oletusarvon tallentaminen kyttjn puolesta tai virheilmoitus. Pts lopullisesta ratkaisusta kannattanee kuitenkin tehd vasta toteutusvaiheessa, kun sovelluksen muu rakenne ja ratkaisuvaihtoehdot ovat paremmin selvill. Tst huolimatta esiin tulleet seikat on syyt dokumentoida, jotta ne voidaan projektin myhemmss vaiheessa palauttaa mieleen.

5.2 Verkko-ohjelmiston arkkitehtuuri

Projektissa toteutettu web-hallintasovellus muodostuu kahdesta posasta, joista ensimminen on GladeSoft Inc:n tarjoaman Seminole HTTP-palvelimen toteuttama hallintasovelluksen ydin. Se tarjoaa projektin verkko-ohjelmistolle rajapinnan HTTPpyyntjen vastaanottamiseen ja vasteiden lhettmiseen. Se sislt mys sovelluskehyksen, jota voidaan kytt ohjelmointirajapinnan avulla erilaisten sivupohjien hydyntmiseen nkymien toteuttamisessa. Seminolea ksiteltiin tarkemmin alikohdassa 4.3.3, jossa havainnollistettiin sen toimintaa esimerkin avulla. Tss kohdassa ksitelln hallintasovelluksen toista posaa, joka on tyn kohteena oleva verkko-ohjelmisto. Se sislt omat tietorakenteensa ja luokkansa mallin eli Config Managerin kyttn, jota kytetn Config API rajapinnan avulla. Tietorakenteiden ja luokkien avulla muokataan mallilta saatu data HTML-sivupohjien ymmrtmn muotoon.

5.2.1 Tietorakenteet
Ensimminen web-hallintasovelluksen kyttm tietorakenne, jonka kanssa palvelimelle saapunut HTTP-pyynt joutuu kosketuksiin on pyynnn parametrien tallentamiseen kytettv STL (Standard Template Library) kartta, jonka tyyppi on map<string,
60

string>. Tyypill mritetn kartta, jonka jokaisen tietoalkion nimi ja arvo ovat

tyypiltn string-merkkijonoja. HTTP-pyynnn parametrit tallennetaan thn karttaan, ja siit erotellaan pyydetty toiminto ja objektityypin nimi omiin merkkijonoihinsa. Karttaan siltty pyynnn loppuosa vlitetn toimintoa ja objektityyppi vastaavalle toiminto-oliolle, jossa sen ksittely suoritetaan. STL-kartan etuja tietorakenteena ovat automaattinen muistinhallinta ja joustavat kyttmahdollisuudet, joista tss sovelluksessa kytetyimmt ovat avainperusteinen haku ja iterointi. Automaattinen muistihallinta vhent ohjelmointityhn tarvittavaa aikaa ja auttaa vhentmn koodissa esiintyvien huolimattomuusvirheiden mr. Web-hallintasovelluksen trkeimmt tietorakenteet ovat sovelluksen Config API:n kautta mallilta saatavat hallintaobjektit ja niiden sisltmt attribuutit. Hallintaobjekti tarkoittaa jotain Iris 440 laitteen hallittavaa asiaa, esimerkiksi siltaa tai verkkoliitnt. Attribuutit ovat hallintaobjektin sisltmi hallintaominaisuuksia, joita voidaan mahdollisuuksien mukaan tarkastella tai muokata. Config API:lta saatava objekti on olio, joka sislt joukon julkisia ja yksityisi metodeja ja muuttujia. Webhallintasovelluksen kannalta objektin trkein ominaisuus on sen sisltmt attribuutit, joita se omistaa mielivaltaisen mrn STL-karttaan tallennettuna. Kartan tyyppi on map<const attr *, const value *>, eli se sislt osoittimet attribuutin nimeen ja arvoon. Kartta on objektin yksityinen muuttuja, ja sen sisltmien attribuuttien arvoja voidaan lukea esimerkiksi metodilla construct_attr_value_clone(const attr *at), joka palauttaa parametrina annetun attribuutin arvon. Hallintaobjektin lisksi web-hallintasovellus tarvitsee kyttns mys muuta tietoa, jota vaaditaan nkymn luomiseen objektityypin ja sille suoritettavan toiminnon vaatimalla tavalla. Nm vaatimukset koskevat pasiassa objektin attribuutteja, joiden esitystavan on noudatettava attribuutille mriteltyj nkyvyysasetuksia ja muokkausmahdollisuuksia. Nit vaatimuksia varten jokainen mallilta saatava objekti tallennetaan ViewDatatietueeseen, joka on esitelty kuvassa 5-1. Rakenne sislt objektin osoittimen ja tarvittavat lippukartat, joilla objektin kukin attribuutti voidaan ilmaista olevan ennaltamrtty avain (fkflags), virheellisen arvon sisltv (errflags), piilotettava (hdnflags) tai nytettv (shwflags). Hallintaobjektin muokkauslomakkeessa kukin attribuutti voidaan asettaa ennaltamrtyksi avaimeksi eli ei-muokattavaksi tai virheellisen arvon sisltvksi, jolloin se osoitetaan virheelliseksi. Lomakkeella tallennettavaksi sallitut attribuutit mritelln osoittamalla ne nytettviksi. Objektien listaamisen ja nyttmisen yhteydess attribuutit voidaan asettaa piilottaviksi.
1 2 3 4 5 6 7 8 struct ViewData { ViewData() { object = 0; }; obj *object; AttrFlags fkflags; AttrFlags errflags; AttrFlags shwflags; AttrFlags hdnflags; };

Kuva 5-1. ViewData-tietue hallintaobjektin tallentamiseen.

61

Jos halutaan tallentaa useampi kuin yksi objekti, kuten esimerkiksi listausnkymn luomisessa on tarpeen, tallennetaan objektit ja niit vastaavat ViewData-rakenteet STL-listaan, jonka tyyppi on list<ViewData>.
ViewData-tietueesta lytyvien arvojen avulla nkym voidaan tehd ratkaisuja kunkin attribuutin nyttmisen, lukitsemisen tai virheen ilmaisemisen suhteen. ViewDatarakenteen sisltmt hdnflags- ja shwflags-kartat vaikuttavat ristiriitaisilta, mutta

niiden molempien olemassaolo selittyy eri tyyppisten toimintojen erilaisella ajattelutavalla attribuuttien nyttmisen suhteen. Esimerkiksi tallennustoiminnossa on ensisijaisen trke, ett tallennetaan vain lomakkeessa sytettvksi mritellyt attribuutit ja hyltn loput. Objektin attribuuttien nyttmisess tm ei ole tarpeen, vaan silloin halutaan mritell piilotettavat attribuutit, koska attribuuttien ei-haluttu nyttminen ei ole uhaksi laitteen tietoturvalle. Yksi huomion arvoinen tietorakenne on sovelluksessa kytettv CActionKey-luokka, joka on esitelty kuvassa 5-2. Sit kytetn erilaisten toimintoluokkien identifiointiin ja se sislt tiedot kyseisen toiminnon kyttjmoodista (m_user), toiminnon nimest (m_action_name) ja objektityypist (m_objnm) sek luokan rakentajan ja tuhoajan, vertailumetodin ja erilaisia get-metodeja. CActionKey-luokkaa kytetn sovelluksen toiminto-olioden kartoittamiseen tallentamista ja etsimist varten.
1 2 3 4 5 6 7 8 9 10 11 12 13 class CActionKey { enum WebUser m_user; string m_action_type; string m_objnm; public: CActionKey(enum WebUser user, const string action, const string objnm = ""); ~CActionKey(); int compare_with(const CActionKey &other) const; enum WebUser GetUser() const; string GetActionType() const; const string GetObjnm() const; };

Kuva 5-2. CActionKey-luokka toimintojen identifiointia varten.

Lukuisien toiminto-olioiden tallentaminen tapahtuu omaan STL-karttaansa, jonka tyyppi on map<CActionKey, CAction>, eli toimintojen avaimena toimii sen ominaisuuksien perusteella luotu CActionKey-olio. Kartasta voidaan helposti hakea saatua HTTP-pyynt vastaava toiminto, jolle pyynnn suoritus ohjataan.

5.2.2 Luokat ja metodit

Web-hallintasovellus on jaettu useisiin luokkiin, joiden kesken palvelimen trkein tehtv eli HTTP-pyynnn vastaanottaminen, ksittely ja vasteen lhettminen on jaettu. Luokkakaavio on esitelty kuvassa 5-3. Web-hallintasovelluksen kannalta trkeit pluokkia on viisi, joista periytyy viel joitakin lisluokkia. Lisksi HTTP-palvelimena toimiva Seminole sislt omat luokkansa, joista suurinta osaa ei kuitenkaan tmn tyn

62

puitteissa ole tarpeen ksitell. Projektissa toteutettu verkko-ohjelmisto yhdistyy ytimen toimivaan HTTP-palvelimeen HttpdFileHandler- ja HttpdSymbolTable-luokista periytettyjen CWebHandler- ja CSymbolTableluokkien avulla. Lisksi HTTP-autentikaatio tapahtuu Seminolen tarjoamalla HttpAuthentication-luokalla. Nm kolme luokkaa ovat kytnnss ohjelman ainoat HTTP-palvelimen omaa ohjelmointirajapintaa kyttvt osat, joten ohjelman muita luokkia voidaan pit palvelinsovelluksesta riippumattomina.

Kuva 5-3. Web-hallintasovelluksen luokkakaavio.

Luokkien yhteistoiminta perustuu MVC-sovellusarkkitehtuuriin, jota ksiteltiin kohdassa 2.5. Suurin osa luokista edustaa arkkitehtuurin C-osaa eli kontrollia.
63

CWebHandler huolehtii sovelluksen psyst ulkomaailmaan, mik tarkoittaa HTTP-

pyyntjen parametrien jsentmisest ja vasteen muotoilu- ja lhetysvaiheen kynnistmisest. Kommunikoinnista mallin kanssa vastaa CAction-kantaluokasta periytetyt toimintoluokat Config API -rajapinnan kautta. Mallilta saatu tieto vlitetn lopulta CSymbolTable-luokalle, joka huolehtii tietojen tarjoamisesta nkymlle sivupohjien ymmrtmss muodossa. CWebHandler
HttpdFileHandler-luokasta periytetty CWebHandler-luokka on pyynnn

ksittelij, jonka olioita palvelin luo yhden tai useamman vastaamaan tietyll etuliitteell saapuviin HTTP-pyyntihin. HttpdFileHandler-luokan nimi tulee siit, ett sen avulla palvelinta voidaan kytt tiedostopalvelimena. Luokan rakentaja vaatii sytteekseen ksittelij vastaavan etuliitteen ja kytettvn tiedostojrjestelmn tyypin ja oletushakemiston. CWebHandler-olio luodaan palvelimen pohjelmassa, ja sen elinaika on kytnnss sovelluksen kesto. Erilaisia ksittelijit voidaan luoda useampia, joista kukin vastaa tietyll etuliitteell saapuvien HTTP-pyyntjen ksittelyst, esimerkiksi pyynt osoitteeseen http://www.palvelin.com/webForm1 ohjautuu etuliitteell webForm1 ja osoite http://www.palvelin.com/webForm2 etuliitteell webForm2 rakennettuun ksittelijn. Web-hallintasovelluksessa CWebHandler-ksittelij kytetn ilman etuliitett saapuvien pyyntjen oletusksittelijn.
CWebHandler-oliolle ohjatun pyynnn ksittely tapahtuu useassa eri vaiheessa, joista ensimminen on TranslateUri()-metodissa tapahtuva pyynnn jsennys ja ohjaus

kontrollille. Pyydetty toiminto ja objektityypin nimi tallennetaan omiin merkkijonoihinsa, ja loput pyynnst tallennetaan STL-karttaan, kuten alikohdassa 5.2.1. kerrottiin. Niden tietojen perusteella luodaan pyyntkohtainen CRequest-olio, joka vlitetn kontrollin rajapinnan kautta eteenpin.
TranslateUri()-metodissa tapahtuu mys kyttjn autentikointi, jossa hydynnetn HTTP-autentikointiskeemoja kyttv HttpdAuthenticator-

luokkaa. Luokan avulla mritetn realm-alue, jolle pstkseen kyttjn pit tunnistautua jollakin laitteen passwd-moduulilta saadulla kyttjtunnuksella ja salasanalla. Erilaisia kyttjtiloja ovat admin, monitor ja engineer, joista kullekin on mritelty omat sallitut toimintonsa. Kun kontrolli on ksitellyt pyynnn, CWebHandler-olio hakee pyynt vastaavalta CRequest-oliolta kontrollin mrittmn symbolitaulun ja sivupohjan tiedostonimen, joiden osoittimet se tallentaa yksityisiin muuttujiinsa ja jatkaa suoritusta SendFile()metodiin. SendFile()-metodissa kutsutaan staattista HttpdFSTemplateShell ::Execute()-metodia, jolle annetaan pyynnn tilatietue ja symbolitaulu. Execute()-metodi muodostaa annettujen parametrien perusteella yksiksitteisen nkymn ja lhett sen pyynnn tehneelle kyttjlle. Metodi on vastaava kuin alikohdassa 4.3.3. esitellyss esimerkiss, paitsi ett tss kytetn symbolitauluna HttpdSymbolMap-luokan sijaan HttpdSymbolTable-luokasta periytetty luokkaa, jossa jokainen sivupohjalta tullut komento mritelln itse. HttpdSymbolMap-luokan tarkoitus on helpottaa C-kielen rakenteisiin tallennetun tiedon esittmist nkymss

64

esimritetyill komentoksittelijill, mutta tss projektissa kytettvill tietorakenteilla on helpompaa kirjoittaa komentoksittelijt itse. Komentoksittelijt ovat sivupohjien kyttmi takaisinkutsuja, joiden tehtvn on tulostaa pyydetyt muuttujat nkymn. CRequest
CRequest-luokka on tarkoitettu pyyntkohtaisen tiedon tallennuspaikaksi, ja siten se

sislt mys pyynnn aikana yllpidettvn tilatiedon. Tilatietoja ovat esimerkiksi tiedot edellisest pyynnlle suoritetusta toiminnosta ja pyynnlle mritetty data ja sivupohja. Suorituksen aikana CRequest-olio luodaan pyynnn ksittelijss, jossa sille annetaan alkuarvoksi HTTP-pyynnst jsennetty toiminto, objektityypin nimi ja pyynnn loppuosa. CControl
CControl-luokka sislt sovelluksen kontrolliosan ytimen. Ksittelij kutsuu tuntemaansa CControl-oliota ja vlitt sille pyyntkohtaisen CRequest-olion. CControl ei tied, mink toimintotyypin kanssa on milloinkin tekemisiss, vaan sen

tehtv on ainoastaan toimittaa saamansa parametrit oikeaan paikkaan, eli CDispatcher-oliolta saamalleen toiminto-oliolle. Erityisesti CControl-olio ei tied mitn pyynnn loppuosan sisltmist parametreista tai niiden merkityksest, vaan ne sytetn CDispatcher-oliolta saadulle toiminto-oliolle sellaisenaan. CControl-olio asettaa pyynnlle mys ksiteltv objektityyppi vastaavan navigointivalikon tilan. Vaikka CControl-olion rooli pyynnn ksittelyss ja vasteen muodostamisessa on varsin pieni, on sill trke tehtvv pyynnn kuljettamisessa CDispatcher-oliolle ja silt saadun toiminnon onnistuneessa suorittamisessa.
CControl-olio luodaan palvelimen kynnistyksen yhteydess ja tuhotaan sen sulkeutuessa. Se tarjoaa pyynnn ksittelevlle CWebHandler-luokalle yksinkertaisen rajapinnan ProcessRequest()-metodinsa kautta, joka vaatii sytteekseen pyynnll alustetun CRequest-olion.

CDispatcher
CDispatcher-luokka on tarkoitettu erilaisten toimintoluokkien hallintaan. CWebHandler-olion tapaan mys CDispatcher-olio luodaan palvelimen

kynnistyksen yhteydess ja tuhotaan vasta sen sulkeutuessa.

CDispatcher::Init()-metodi luo toimintojen mrittelyolion (CActionDefinitions) ja pyyt tt luomaan sille mritetyt toiminnot. Kun kontrolli kutsuu CDispatcher::GetAction()-metodia, se ky lpi mrittelyolion

antamat toiminnot ja palauttaa kontrollille sen toiminto-olion osoittimen, joka vastaa saadun pyynnn kyttjmoodia, toimintotyyppi ja objektityyppi. Mikli nill kolmella muuttujalla mritellyn CActionKey-olion perusteella lydetn useampi kuin yksi toiminto, voidaan oikea toiminto tunnistaa pyynnn loppuosan perusteella. Jos objektityyppi ei ole mritelty, voidaan palauttaa osoitin tietylle kyttjmoodille ja toimintotyypille mritellylle oletustoiminnolle. Jos toimintoa ei lydy, palautetaan

65

osoitin CAction-kantaluokan olioon, joka ei tee mitn, mutta jota voidaan ksitell kuin mit tahansa muuta toiminto-oliota. CActionDefinitions
CActionDefinitions-luokassa mritelln kaikki web-hallintasovelluksen

tarvitsemat toiminnot, joita ovat erikoismrittelyt ja oletustoiminnot. Erikoismrittelyt ovat tietylle kyttjmoodi, toiminto ja objektityyppi yhdistelmlle mriteltyj poikkeustoimintoja, joiden avulla voidaan esimerkiksi piilottaa halutut attribuutit jonkin objektityypin nkymst. Esimerkki erikoismritellyst COpenAddActiontoiminnosta nkyy kuvassa 5-4. Toiminnon sivupohjaksi on mritelty add.thtm, kyttjmoodiksi ADMIN, objektityypiksi bridge ja piilotettaviksi attribuuteiksi mac ja stpstate. Viimeisen oleva ennaltamritetyt attribuutit on asetettu tyhjksi, jolloin ainuttakaan attribuuttia ei ole asetettu kyttjn puolesta. Kyttjmoodin avulla toteutetaan kyttjn autorisointi, eli varmistetaan ett jokaisella kyttjll on kytettvissn vain halutut toiminnot. Esimerkiksi monitor-kyttjlle ei haluta mahdollistaa hallintaobjektien lismist, joten kyttjmoodilla MONITOR ei luoda COpenAddAction- tai CAddAction-luokan erikois- tai oletusmrittelyj.

1 2 3 4 5

new COpenAddAction("/add.thtm", ADMIN, pList->get_object_type("bridge"), "mac stpstate", "" )

Kuva 5-4. Erikoismrittely COpenAddAction-toiminnolle.

Erikoismrittelyjen lisksi mritelln halutuille kyttjmoodeille ja toimintotyypeille oletustoiminnot, joiden objektityyppi on avoin. Mikli pyynt vastaavaa toimintoa ei lydy, kytetn CAction-kantaluokan oliota. CActionDefinitions-olio luodaan CDispatcher::Init()-metodin yhteydess, joten olion elinik vastaa kytnnss sovelluksen elinik. Tm tarjoaa tehonsst, koska toiminto-oliot on tllin luotava vain kerran palvelimen kynnistyksen yhdeydess. Tm tarkoittaa mys sit, ett toiminto-olioiden metodien on oltava tilattomia (stateless, re-entrant), jotta vltytn yhteisen datan kytst aiheutuvilta ristiriidoilta yhtaikaisia pyyntj ksitteltess. Toiminto-olion suoritusmetodi ei siis silyt tietoa sen suoritusten tai HTTP-pyyntjen ksittelyn vlill, vaan toimii ainoastaan saamiensa sytteiden ja mallilta saamansa datan perusteella. Kaikki pyyntjen vlinen ja toimintojen suorittamisen vlinen tilatieto silytetn nkymss, CRequest-oliossa ja pysyvn tiedon sisltvss mallissa. CAction
CAction on toimintoluokkien kantaluokka, joka sislt perittvi muuttujia ja

metodeja, jotka ovat suurimmalle osalle toiminnoista tarpeellisia. Perint vhent tarvittavien koodirivien mr ja siten ohjelmointityn mr, koska periytetyille toiminnoille tarvitsee mritt vain kullekin ominaiset toteutustavat ja erityispiirteet. Sovelluksen kontrollin nkkulmasta CAction-luokan trkein metodi on Execute(),
66

joka vaatii sytteekseen CRequest-olion ja palauttaa suorituksen onnistumisesta kertovan boolean-arvon. Execute()-metodin tarkoitus on piilottaa alleen toiminnot oikeasti suorittavien toimintokohtaisten ExecuteAction()-metodien palauttamat virhekoodit, jolloin ylemmn kerroksen ptksenteko suorituksen onnistumisesta helpottuu. Tm rajapinta on kaikille CAction-luokasta periytetyill luokilla sama, vaikka niiden sisinen toteutustapa vaihtelee.
CAction::Execute()-metodi palauttaa boolean-arvon, joka kuvaa sit, onko

pyydetyn toiminnon suoritus saatu loppuun. Jotkin pyynnt vaativat useamman kuin yhden toiminnon suorittamisen, jolloin metodin palauttaman arvon perusteella voidaan ptell, onko uuden toiminnon hakeminen tarpeen vai voidaanko ohjelman suoritusta jatkaa eteenpin. Esimerkiksi tallennustoiminnon jlkeen ei kannata palauttaa kyttjlle tyhj nkym, vaan on jrkevmp suorittaa kyseisen objektin CDisplayAction, jolla kyseinen objekti voidaan nytt. COpenAddAction Hallintaobjektin lisyslomakkeen muodostamisesta vastaa COpenAddAction, joka luo ensin hallintaobjektin olion annetun objektityypin ja sen ennaltamrttyjen avainattribuuttien perusteella. Olion perusteella luodaan nkymn lomake hallintaobjektin attribuutteja vastaavilla sytekentill. Tm luokka ei tarvitse tietoa laitteelta, mutta se tarvitsee Config API-rajapintaa oikeanlaisen hallintaobjektin olion luomiseen. Hallintaobjektin olio tallennetaan ViewData-tietueeseen, jossa on mys muut tarvittavat tiedot lisyslomakkeen esittmiseen, kuten tiedot ennaltamritetyist avainattribuuteista, nytettvt attribuutit ja edellisess lisysyrityksess tapahtuneet virheet. COpenEditAction
COpenEditAction vastaa olemassaolevan hallintaobjektin muokkauslomakkeen muodostamisesta. ExecuteAction()-metodissaan COpenEditAction-olio luo

ensin olion muokattavaksi halutun objektin avainattribuuttien perusteella. Tmn hallintaobjektin olion avulla se hakee mallilta hallintaobjektin arvot, jotka tallennetaan olioon ja ViewData-tietueeseen. ViewData-tietueessa on tarvittava tieto lomakkeen esittmiseen, ja siit selvivt nytettvt attribuutit ja edellisess muokkausyritykss mahdollisesti tapahtuneet virheet. Tietojen hakuun kytetn Config API:n home::get_first()-metodia, joka tarvitsee sytteekseen avainattribuuttien arvot sisltvn hallintaobjektin olion ja osoittimen, jonne haettava objekti tallennetaan. Hallintaobjektin avainattribuutteja kytetn tiedonhaun suodattimena. Kun sen kaikki avainattribuutit on mritelty, palauttaa malli suodattimen perusteella vain yhden objektin. CDisplaySingleAction
CDisplaySingleAction-luokan tehtvn on hallintaobjektin tietojen hakeminen

mallilta avainattribuuttien perusteella. Tietojen hakuun kytetn home::get_first()-metodia. Olion pit tarkistaa mys hallintaobjektille mritetyt piilotettavat attribuutit ja tydent niit vastaavat objektikohtaiset kartat.

67

CDisplaySingeAction-luokan erikoisuus on se, ett sen pit tarkistaa mys

haettavien objektien viitteet muihin objekteihin. Viitteiden perusteella luodaan nkymn tarvitsemat linkit viiteobjekteihin. Toiminnon tarvitsemat viitteet mritelln CActionDefinitions-luokassa sen erikoismrittelyn yhteydess. CDisplayListAction
CDisplayListAction-luokan tehtvn on hallintaobjektien hakeminen mallilta

suodatinattribuuttien perusteella. Ensimmisen objektin hakemiseen kytetn Config API:n home::get_first()-metodia. Seuraavat objektit haetaan home::get_next()-metodilla, joka tarvitsee sytteikseen suodatin- ja kohdeobjektin lisksi viel edellisen saadun objektin osoittimen. Pts seuraavan objektin hakuyrityksest perustuu hakumetodien palauttamiin virhekoodeihin. Hakua jatketaan, mikli metodin palauttama virhekoodi on dc_error_t::OK ja lopetetaan sen ollessa dc_error_t::NO_MORE_OBJECTS. CDisplaySingleAction-luokan tavoin mys listauksessa on huolehdittava piilotettavien attribuuttien asettamisesta mahdollisia erikoismrittelyj vastaaviksi. CAddAction
CAddAction-luokka vastaa hallintaobjektin lismisest annetuilla attribuuttien arvoilla. CAddAction-olio kytt ExecuteAction()-metodissaan Config API:n home::add()-metodia, joka tarvitsee sytteekseen tallennettavan objektin. Ennen

tallennusta olion on tarkistettava kyttjn tallennusoikeus asetettaville attribuuteille. Lisksi tallennettavalle objektille asetetaan sille mahdollisesti ennaltamritetyt attribuuttien arvot. CUpdateAction
CUpdateAction-luokka muistuttaa toiminnaltaan CAddAction-luokkaa, mutta tallentamiseen kytetn nyt home::update()-metodia, joka on olemassa olevan

hallintaobjektin pivittmiseen tarkoitettu metodi. Mikli pivitettv objektia ei tst huolimatta ole, palauttaa kutsu virhett ilmaisevan koodin. Tllainen tilanne voi esiinty esimerkiksi silloin, kun kyttj on avannut hallintaobjektin muokkausnkymn, mutta toinen kyttj ky poistamassa saman objektin ennen kuin ensimminen ehtii tallentaa tekemin muutoksia. CDeleteAction
CDeleteAction on CAction-luokasta periytetyist toimintoluokista yksinkertaisin,

ja sen tehtvn on avainattribuuteilla osoitetun hallintaobjektin poistaminen. Thn kytetn Config API:n home::delete()-metodia, joka vaatii sytteekseen poistettavan objektin. CSymbolTable
CSymbolTable-luokka on periytetty Seminolen tarjoamasta HttpdSymbolTable-

luokasta, ja se vastaa sille annetun tiedon tulkinnasta sivupohjien ymmrtmss

68

muodossa. Se sislt tarvittavan logiikan erilaisten silmukoiden, vertailujen ja arviointien tekemiseen sivupohjalta saatujen komentojen ja kontrollilta vastaanotettujen ViewData-tietueiden tarjoaman datan perusteella. Kuvassa 5-5 esitelln CSymbolTable::HandleCond-metodi, joka vastaa sivupohjalta saatujen ifkomentojen vertailusta. Esimerkiksi jos nkym haluaisi tietoonsa onko sen hetkinen hallinta-attribuutti avain, se voitaisiin selvitt sivupohjakomennolla %{if:key}%. Tllin rivin 3 HttpdConditionalCommand::Name()-metodilla saatu komennon nimi key palauttaa boolean-arvon muuttujalle mCurKey.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 int CSymbolTable::HandleCond(HttpdConditionalCommand *p_cond) { const char *name = p_cond->Name(); if (strcmp(name,"key")==0) { return (ReturnBool(mCurKey)); } else if (strcmp(name,"fkey")==0) { return (ReturnBool(mCurFKey)); } else if (strcmp(name,"notbool")==0) { return (ReturnBool(mCurNotBool)); } else if (strcmp(name,"checked")==0) { return (ReturnBool(mCurError)); } else if (strcmp(name,"hidden")==0) { return (ReturnBool(mCurHidden)); } else if (strcmp(name,"shown")==0) { return (ReturnBool(mCurShown)); } else { return (HTTPD_TEMPLATE_UNKNOWN_NAME); } }

Kuva 5-5. CSymbolTable-luokan konditionaaliksittelij.

Seminolen sivupohjan tulkinnasta vastaava olio kutsuu pyynnlle asetetun symbolitaulun konditionaaliksittelij eli CSymbolTable::HandleCond-metodia. Metodi hakee saadun komennon nimen ja palauttaa sen perusteella valitun muuttujan vertailun tuloksen. Esimerkiksi sivupohjan komento %{if:key}% palauttaa arvon true tai false, riippuen boolean-muuttujan mCurKey totuusarvosta.

5.2.3 Integrointi kohdeympristn

Prosessimoduulin integrointi kohdeympristn vaatii moduulien kantaluokaksi mritellyn mgr_module_base-luokan toteuttamista moduulin ominaisuuksien edellyttmll tavalla. Moduuli periytt kantaluokasta oman moduuliluokkansa, jonka avulla se paikantaa kohdeympristn resurssit, kuten Config API:n ja sit kautta esimerkiksi hallintaobjektien home-rajapinnat. Moduuliluokan monimutkaisuus riippuu siit, paljonko kyseisell moduulilla on I/O-operaatioita vaativia tiedostokuvaimia, jotka vaativat kommunikointia muun jrjestelmn kanssa. Tiedostokuvaimia ovat esimerkiksi tiedostot, soketit ja laitteistokahvat, joille voidaan kohdistaa estvi I/O-kutsuja. Joitakin Unixin I/O-jrjestelmkutsuja esiteltiin kohdassa 2.2.

69

Web-hallintasovelluksen integrointi kohdejrjestelmn oli helppoa, koska sille ei toteutettu jrjestelmn kanssa kommunikoivia tiedostokuvaimia. Tst syyst sovelluksen integroimiseksi riitti moduuliluokassa suoritettava Config API rajapinnan noutaminen, jonka avulla voitaisiin hakea HTTP-pyyntjen kautta konfiguroitavaksi pyydettvien hallintaobjektien home-rajapinnat. Kuvassa 5-6 on esitelty webhallintasovelluksen main()-metodi, jonka tarkoitus on luoda moduuliluokan olio ja alustaa se. Rivill 3 luodaan palvelinolio, joka sislt tarvittavat metodit HTTPpyyntjen vastaanottamiseen ja vasteiden lhettmiseen. Rivill 7 suoritettavassa dc_module_web::init()-metodissa suoritetaan kantaluokan init()-metodin kutsuminen ja Config API rajapinnan noutaminen. Tmn jlkeen rivill 8 alustetaan luotu palvelinolio, mik tarkoittaa sulautetun tiedostojrjestelmn alustamista ja HTTPpyynnn ksittelijiden asettamista palvelinoliolle. Toteutettu web-hallintasovellus kytti yht pyynnnksittelij, jonka tehtvn oli pyynnn parametrien jsentminen ja vlittminen alemman tason sovelluslogiikalle. Lopuksi palvelin kynnistetn Httpd::Start()-metodilla, jolloin se j ikuiseen silmukkaan vastaanottamaan ja ksittelemn HTTP-porttiin saapuvia pyyntj.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 int main(int argc, char *argv[]) { gp_WebServer = new Httpd(c_servername, c_serverport); DC_DEBUG_INIT("web"); dc_module *mod = new dc_module_web(); if(mod) { mod->init(argc, argv); Initialize_The_Web_Server(); if (!gp_WebServer->Start()) { exit(1); } delete mod; } return (0); }

Kuva 5-6. Web-hallintasovelluksen main()-metodi.

Laajemman integroinnin toteuttamiseksi hallintasovellus voisi kytt dc_module_base::run()-metodia, joka rekisteri moduulin jrjestelmn sisiselle valvontamoduulille. Tllin voitaisiin kytt esimerkiksi IPC-viestej hallintasovelluksen asetusten ajonaikaiseen muokkaamiseen. Hallintasovelluksen ensimmiseen versioon riitti kuitenkin perustoiminnallisuuden toteuttaminen.

5.2.4 Vasteen muodostaminen

Edellisess alikohdassa esitellyist luokista luodut oliot suorittavat web-palvelimen trkeimmn tehtvn, joka on HTTP-vasteen muodostaminen saadun pyynnn perusteella. Suorituksen kulku on monivaiheinen, ja siihen liittyvt oliot muodostuvat noin kymmenest luokasta, mikli lasketaan vain toteutetun verkko-ohjelmiston kannalta oleelliset luokat. Tyypillinen yksinkertaistettu tapahtumasekvenssikaavio olioiden vlisist suhteista on esitetty kuvassa 5-7. Siin esiteltyjen olioiden lisksi suoritukseen liittyy lukuisia Seminolen sisisten luokkien olioita, jotka vastaavat
70

palvelimen alemman tason toiminnasta ja sivupohjien prosessointiin liittyvist tehtvist. Seminolen omia luokkia ei kuitenkaan muutamaa poikkeusta lukuunottamatta ksitell.

Kuva 5-7. Tapahtumasekvenssikaavio HTTP-pyynnn ksittelyst.

Kun HTTP-pyynt saapuu palvelimelle CWebHandler-luokalle osoitetulla etuliitteell, pyynt ohjataan siit luodulle oliolle ja tarkemmin sanottuna sen Handle()-metodille. Handle()-metodi ky lpi ksittelijluokalle ominaiset pyynnn prosessoinnin vaiheet, joita kyttmmme HttpdFileHandler-ksittelijluokan Handle()metodilla ovat TranslateUri()- ja ProcessUri()-metodit. Toteutetun verkkoohjelmiston ksittelij toteutti nist TranslateUri()-metodin ja ProcessUri()metodin kautta kutsuttavan SendFile()-metodin. Ensimmisen metodin tehtvn on jsent saadun HTTP-pyynnn parametrit verkko-ohjelmiston ymmrtmn muotoon. Jlkimminen vastaa edellisiss vaiheissa mritetyn tiedoston lhettmisest kyttjlle ja siihen palataan alikohdan lopussa. Kuvassa 5-7 nkyy ainoastaan Handle()-metodi luokan julkisen rajapinnan mukaisesti. Edell esitetty osuus vastaa verkko-ohjelmiston palvelinsidonnaista osaa, joka on tss tapauksessa toteutettu Seminole-palvelimen API-rajapintaa vastaavalla tavalla. Verkkoohjelmiston trkein osuus tapahtuu sen kontrollissa, jossa tapahtuu neuvottelu mallin kanssa pyydetylle toiminnolle osoitetun toiminto-olion avulla. Kytnnss pyynnn suoritus ohjataan CWebHandler-oliolle mritetylle CControl-oliolle, jonka ProcessRequest()-metodia ksittelij kutsuu. Ksittelij antaa ProcessRequest()-metodille jsentmns toiminnon, objektityypin nimen ja pyynnn loppuosan, jotka se tallentaa pyyntkohtaiseen CRequest-olioon. Tehokkuussyist kahdesta viimeisest vlitetn vain osoitin kokonaisen olion sijaan. Metodin suorittamisen jlkeen CRequest-olioon pitisi olla tallennettuna nkymn luomiseen tarvittava sivupohja ja symbolitaulu. Metodin toiminta nkyy kuvassa 5-8.

71

1 2 3 4 5 6 7 8 9 10 11 12 13 14

int CControl::ProcessRequest(CRequest *req) { CAction *acn = 0; bool done = false; while (!done) { acn = m_dp->GetAction(req); done = acn->Execute(req); } req->ProcessSymbols(GetMenuState(req ->GetObjnm(), *req->GetParams())); return (0); }

Kuva 5-8. CControl::ProcessContent()-metodi.

ProcessContent()-metodi luo aluksi tyhjn CAction-osoittimen. Lisksi se luo boolean-muuttujan virheen tarkastelua varten ja alustaa sen false-arvolla, joka osoittaa ett toimintoa ei ole viel suoritettu. Seuraavaksi suoritus siirtyy while-silmukkaan, jossa tapahtuu tarvittavan toiminto-olion osoittimen noutaminen CDispatcher-oliolta acn-muuttujaan rivill 6 ja sen Execute()-metodin kutsuminen rivill 7. Noudettava toiminto-olio mrytyy CRequest-olion parametrien perusteella. Silmukan tehtv on tarkastella Execute()-metodin palauttamaa virheen ilmaisevaa boolean-arvoa done ja virheen tai uuden toimintomrityksen ilmaantuessa hakea uusi toiminto. Execute()metodi piilottaa alleen varsinaisen toiminnon suorittavan ExecuteAction()-metodin ja sen palauttamat monipuolisemmat virhekoodit. Todellisten virhekoodien arviointi on erityisen trke esimerkiksi lomakkeiden sytteiden tallentamisen yhteydess, sill lomakenkymn pit pysty palaamaan, mikli kyttjn antamat sytteet ovat virheellisi. Lisksi jos show-nkymlle ei lydet nytettv objektia, voidaan sen sijasta nytt jokin muu nkym, esimerkiksi objektin lisyslomake.

Kun pyynnn suoritus on saatu ptkseen, palauttaa toiminto-olion Execute()metodi arvon true, jolloin pstn ulos while-silmukasta. Sen jlkeen kutsutaan CRequest-olion ProcessSymbols()-metodia rivill 10, jonka sytteeksi annetaan navigointivalikolle mritetty tila. Metodin avulla CRequest-olio luo itselleen CSymbolTable-olion, jolle se antaa objektityypin nimen, navigointivalikon tilan ja toiminnolta saamansa datan. CSymbolTable-olion tehtvn on mallilta saadun tiedon muuntaminen sivupohjien ymmrtmn muotoon erilaisten virhe- ja nkyvyystietojen sek objektien attribuuttien perusteella. Tmn jlkeen pyynnn ksittely on kontrollin osalta saatu ptkseen ja prosessoinnin onnistumistumista ilmaiseva int-arvo voidaan palauttaa pyynnn ksittelijlle. Prosessointikutsun tehnyt CWebHandler-olio jatkaa suoritustaan ja tallentaa pyynnn perusteella saadun sivupohjan tiedostonimen sille tarkoitettuun muuttujaan. Viimeinen olion suorittama vaihe on sen SendFile()-metodi, jossa suoritetaan ksittelijlle mrtyn tiedoston lhettminen kyttjlle. Koska tiedosto on tss tapauksessa Seminole-nkymkutsuja sisltv HTML-sivupohja, kutsutaan staattista HttpdFSTemplateShell::Execute()-metodia, joka prosessoi ksittelijlle

72

mritetyn sivupohjan ja HttpdSymbolTable-olion osoittaman datan perusteella yksiksitteisen nkymn.

73

6 Tyn tulokset
Tmn diplomityn kannalta hallintasovelluksen riittv valmistumisaste saavutettiin, kun web-hallintasovelluksen toiminnallisuus vastasi laajuudeltaan suurimmalta osin CLI-hallintasovelluksen toiminnallisuutta. Tm edellytt, ett suurin osa nkymien vaatimista sivupohjista ja sovellusmoottorin tarvitsemista ominaisuuksista on toteutettu, vaikka niiden hydyntmisess olisi viel puutteita. Tss luvussa tarkastellaan tll valmistumisasteella saavutettuja tuloksia.

6.1 Soveltuvuus loppukyttn

Web-hallintasovelluksen tavoitteena on tarjota kyttjlle helppokyttinen, selaimella toimiva hallintakyttliittym, joka vastaa monipuolisuudeltaan olemassa olevaa CLIhallintasovellusta mahdollisimman laajasti. Niden seikkojen kannalta sovelluksen toteutus onnistui kattavasti, muutamaa toistaiseksi puuttuvaa ominaisuutta lukuunottamatta. Graafinen kyttliittym tarjoaa kyttjlle helposti opittavan ja muistettavan sek yhdenmukaisen ja selken mahdollisuuden laitteen hallintaan, ja se sopii varsinkin laitteen asetuksia vain harvoin muokkaavalle kyttjlle. Toisaalta CLIhallintasovellus silyy kytss edelleen, joten edistynyt kyttj voi yh hydynt tehokkaita komentorivikskyj. Hallintasovellus takaa verkon ptelaitteelle sen tarvitseman tietoturvan kyttjn autentikoinnin ja mahdollisen SSL-salauksen avulla. Jokaiselle kirjautumisoikeuden omistavalle kyttjlle on mritelty oikeustaso kolmesta eri vaihtoehdosta: ADMIN, MONITOR ja ENGINEER. Kyttjlle nkyvt valvonta- ja hallintaominaisuudet mrytyvt kyttjn tason mukaan, jolloin esimerkiksi monitor-kyttjlle on mahdollista vain laitteen asetusten tarkastelu. SSL-salaus ei ole kytss oletuksena, mutta se voidaan helposti ottaa kyttn palvelimen kynnistyksen yhteydess, mikli ethallinnan kytt tai muulla tavoin epluotettava kyttymprist vaatii tiedon luottamuksellisuuden varmistamisen. Toistaiseksi SSL-salauksen kyttnotto onnistuu vain knnsaikaisilla asetuksilla, mutta tarvittaessa kyttnotto voidaan mahdollistaa mys kynnistysparametrien avulla. Toimintojen autorisointi perustuu autentikoinnin tarjoaman kyttjn tunnistamiseen ja toiminnolle mritettviin oikeustasoihin. Autorisointi perustuu toiminnoille mritettvn oikeustasoon, jonka perusteella toiminnon kytt ohjautuu kyttoikeuden omistavalle kyttjlle. Esimerkiksi sivulla 65 kuvassa 5-4 mritellyss toiminnossa oikeustaso on ADMIN, jolloin toiminnon kytt onnistuu vain laitteen hallintakyttjn tunnuksilla. Autorisoinnin avulla voidaan helposti mritt toiminnon eri oikeustasoille erilaiset nkymt asettamalla kutakin oikeustasoa vastaavalle toiminnolle oma sivupohjansa. Hallintasovellukseen kirjauduttuaan kyttj ptyy etusivulle, jossa on vasemmassa reunassa navigointivalikko ja sivulla nkyy tietoja laitteesta. Navigointivalikon painikkeista kyttj psee muutamaa poikkeusta lukuunottamatta haluamansa hallintaobjektin listausnkymn, josta esimerkkin on siltojen listausnkym kuvassa 6-1. Listausnkym sislt painikkeet olemassa olevien siltojen nyttmiseen ja poistamiseen sek uuden sillan lismiseen. Listassa nkyvien hallinta-attribuuttien
74

lisksi jokainen silta sislt mys muita attribuutteja, joita kyttj voi tarkastella haluamansa sillan show-nkymss, joka on esitelty liitteess 16. Kaikkia attribuutteja kyttj ei kuitenkaan hallintasovelluksen kautta ne, vaan osa niist on asetettu kokonaan piilotettavaksi toimintojen erikoismritysten yhteydess. Show-nkymn edit-painikkella kyttj psee muokkaamaan kyseist siltaa sen edit-nkymn, joka on esitelty liitteess 17. Sillalle muokattavaksi asetetut attribuutit ovat erilaiset kuin nytettvksi asetetut, joten esimerkiksi sen MAC-osoite ei ole kyttjn muokattavissa, vaan se mrytyy laitteelle asetetun laiteosoitteen mukaisesti.

Kuva 6-1. Laitteen siltojen listausnkym.

Nkymien vlisten siirtymien johdonmukaisuus ja suvujuus on hallintaobjektikohtaista, joten erilaiset nkymtyypit toimivat joillekin objekteille paremmin ja toisille huonommin. Keskimrin nkymt ovat kuitenkin selkeit ja intuitiivisia, jolloin navigointi ja kyttjn tarvitsemien toimintojen lytminen tapahtuu nopeasti. Kun hallintasovelluksen perustoiminnallisuus on kunnossa, voidaan sen kytettvyytt ja nkymien monipuolisuutta parantaa luomalla uusia nkymtyyppej, joissa erilaisten hallintaobjektien ominaispiirteet huomioidaan paremmin. Mys hallintasovelluksen suorituskyky ja muistivaatimus vaikuttivat alustavien testien perusteella hyvlt. Verkko-ohjelmiston nopeutta arvioitiin mittaamalla sen kuluttamaa aikaa pyynnn vlittmiseen HTTP-rajapinnan ja laitteen Config Managerin vlill. Mittausten avulla todettiin, ett verkko-ohjelmiston kuluttama aika pyyntjen ksittelyyn oli vain murto-osa Config Managerin kyttmst ajasta, joten se ei missn tapauksessa muodostuisi pullonkaulaksi pyynnn ksittelyss. Liitteess 18 on esitelty yhden sillan sisltvn listausnkymn muodostamiseen kulunut aika. Tuloksista huomataan, ett Config Manager kytti tiedonhakuun IPC-viestien avulla noin 1,5 sekuntia, jolloin itse verkko-ohjelmiston kuluttama aika on noin 0,6 sekuntia. Suurin osa tst ajasta kuluu hallintaobjektien ksittelyyn Config API kutsujen avulla, joiden
75

suoritusnopeuteen verkko-ohjelmisto ei voi vaikuttaa. Jos kokonaissuoritusajasta vhennetn ensimmisen ja viimeisen Config API kutsun vlill kuluva aika, on verkko-ohjelmiston kuluttama aika vain joitakin kymmeni millisekunteja. Mittaustuloksia on syyt arvioida suhteellisina, koska kytetyn laitteen kellotaajuus oli vain 200MHz lopullisen kohdeympristn 300MHz kellotaajuuden sijaan. Laitteen Flash-muistia sovellus vie kokonaisuudessaan noin 800 kilotavua, joista 124 kilotavua muodostuu HTML-painikkeiden kuvatiedostoista. RAM-muistia sovellus kytt noin 12,5 megatavua, josta suurin osa koostuu sen lataamista dynaamisesti linkitetyist kirjastoista.

6.2 Jatkokehitys
Kun hallintasovelluksen viimeistely Iris 440 SHDSL-laitteelle on saatu valmiiksi, on edess sen sovittaminen mys Iris 800 DSLAM-laitteelle. Iris 800 on keskuspn x86pohjainen Linux-kyttjrjestelmll toimiva DSLAM-laite, joka on tehokkaampi ja liitnniltn laajempi kuin asiakaspn Iris 440 laite. Hallintasovelluksen kannalta laitteet ovat hyvin samankaltaiset, sill mys Iris 800 laitteen sovellusymprist perustuu moduuleihin kohdassa 3.2 esitetyll tavalla, ja suurin osa moduuleista toimii samalla tavalla kuin tmn projektin kohdeympristss. Suurin ero laitteiden vlill on liitntjen mrss, sill Iris 440 laite sislt nelj SHDSL-linjaa kytkettyn yhdeksi portiksi, kun taas Iris 800 laite voi sislt niit maksimissaan 32 kappaletta. Lisksi ethernet-liitntj on nykyisess kohdeympristss nelj ja Iris 800 laitteessa vain yksi. Sovelluksen toiminta on lopulta mys testattava huolellisesti molemmissa ympristiss. Testaamisen perustana voidaan kytt kyttliittymn suunnittelussa hydynnettyj kytttapauksia. Hallintasovelluksen siirtminen samankaltaiselle laitteelle pitisi olla helppoa, koska sen kaikki toiminnot ovat muokattavissa mritysten avulla, jolloin esimerkiksi hallittavien SHDSL-linjojen mrn muuttaminen nykyisest yhdest 32:een vaatii ainoastaan linjojen lukumr hydyntvien toimintojen uudelleenmrittmisen. Mikli hallintaobjektien muoto ja niiden ksittelyyn kytettvt rajapinnat pysyvt muuttumattomina, ei verkko-ohjelmiston koodiin tarvitse puuttua. Toimintoluokkien metodit toimivat hallintaobjektien tietosislln ja mrn suhteen tysin annettujen parametrien, saatujen HTTP-pyyntjen ja laitteelta saatujen tietojen perusteella. Hallintasovelluksen suunnittelussa ja toteutuksessa pyrittiin alusta lhtien mahdollisimman alustariippumattomaan ratkaisuun, jolloin ohjelmiston siirtminen laitteelta toiselle ei pitisi olla ongelma, mikli laitteen hallintarajapinta silyy ennallaan. Vaikka lopullinen sovellus sislt objektityyppikohtaisia toimintoja ja nkymi, niin tarvittaessa hallintaobjekteja voidaan ksitell mys geneerisill oletustoiminnoilla ja nkymill ilman erikoismrittelyj. Tm tarkoittaa sit, ett ohjelmistoa ei ole sidottu tiettyihin objektityyppeihin tai niihin liittyviin rajoituksiin, kuten mahdollisten SHDSL- tai ethernet-liitntjen mrn. Teoriassa ohjelmisto voidaan siirt uuteen tuoteprojektiin sellaisenaan ja kytt pelkki oletustoimintoja, ja list objektityyppien toiminnoille erikoismrityksi ja niihin liittyvi sivupohjia vasta myhemmin. Tietoturvasyist hallintaobjektien muokkaamiseen tarkoitetut toiminnot eivt tosin oletuksena ole kytss, joten pelkkien oletustoimintojen avulla onnistuu vain objektien tarkastelu.

76

Lisksi web-hallintasovellus saatetaan tulevaisuudessa siirt mys tysin erilaiselle laitealustalle tai kyttjrjestelmlle. Hallintasovelluksen kyttm palvelinsovellus Seminole tukee siirrettvyytt modulaarisuutensa ja erityisesti tarjoamansa siirrettvyyskerroksen avulla. Siirrettvyyskerros tarkoittaa muusta ohjelmasta eristetty ohjelman osaa, joka sislt kaiken sovellusalustakohtaisen koodin. Tmn koodin kntmisess hydynnetn sovellusalustakohtaisia asetustiedostoja, joiden avulla ohjelma voidaan helposti muuntaa halutulle alustalle yhteensopivaksi. Seminole sislt valmiin tuen Unixin lisksi muun muassa MacOSX-, Windows- ja eCos-jrjestelmille.

77

7 Yhteenveto
Tss diplomityss tutkittiin sulautetun jrjestelmn web-hallintasovelluksen suunnittelun ja toteuttamisen eri vaiheita. Tuloksena syntynyt hallintasovellus sislsi kolmannen osapuolen toteuttaman HTTP-palvelinsovelluksen ja itse toteutetun verkkoohjelmiston. Tyt varten perehdyttiin web-ympristjen keskeisiin tekniikoihin palvelimen toiminnan ja tietoturvan sek verkko-ohjelmiston toteuttamisen kannalta. Erityisen syvllist tutustumista vaadittiin kohdeympristn toimivan Iris 440 laitteen sovellusympristn ja HTTP-palvelimena kytetyn Seminolen ohjelmointirajapintoihin. Web-hallintasovellus tehtiin jo toteutetun CLI-hallintasovelluksen rinnalle tarjoamaan Iris 440 laitteen yllpitjlle mahdollisuus laitteen asetusten tarkasteluun ja hallintaan web-selaimen avulla. Graafisella hallintasovelluksella voitaisiin tarjota kyttjystvllinen vaihtoehto monen vierastaman terminaalikyttliittymn rinnalle. Kyttjystvllisyydest huolimatta hallintamahdollisuuksien monipuolisuudesta ei haluttu tinki, vaan lhtkohtaisesti selaimella piti pysty suorittamaan vhintn kaikki se mit terminaalillakin. Ainoaksi puutteeksi CLI-hallintasovellukseen verrattuna ji valmiiden konfiguraatioasetusten syttminen tai vieminen ulos sovelluksesta. Se jtettiin tss vaiheessa suunnittelun ulkopuolelle teknisten eroavaisuuksien johdosta. Kyttliittymn suunnittelu tehtiin pasiassa CLI-hallintasovelluksen ominaisuuksia tarkastelemalla ja muuntamalla sen tarjoamia komentoja ja hallintamoodeja webkyttliittymlle sopivaksi. Tten esimerkiksi CLI:n bridge configuration moodi voidaan rinnastaa web-sovelluksen bridges-vlilehdeksi ja interface configuration moodi interfaces-vlilehdeksi. Kyttliittymn nkymtyyppej vastaavien HTMLsivupohjien toteuttaminen oli helppoa, koska sivupohjakomentojen kytt oli samankaltaista kuin web-suunnittelussa yleisesti hydynnettvill skriptikielill. Tyn selkesti vaikein osuus oli verkko-ohjelmiston kontrolliosuuden toteuttaminen. Toteuttamisen alkuvaiheessa laadittiin erilaisia prototyyppej, joiden pohjalta ohjelmistoa ryhdyttiin toteuttamaan helpoimmalta vaikuttavaan suuntaan. Lopputuloksena syntynyt sovellusmoottori vastasi lopulta kohtalaisen hyvin sille asetettuja geneerisyyden ja laajennettavuuden vaatimuksia. Erilaiset toiminnot ovat helposti mriteltviss ja kytettvt sivupohjat ovat erilln sovelluslogiikasta, joten hallintaobjektien tai nkymien muutokset eivt vaadi muutoksia sovelluslogiikassa. Toimintomrityksi ksiteltiin sivulla 65 ja Seminole-palvelimen sivupohjia sivulla 49. Mrittelyiss ja nkymiss esiintyv toisto on pyritty minimoimaan, jolloin tarvittavat muutokset voidaan toteuttaa mahdollisimman pienell tymrll. Vaikka mys valmiiden sovelluskehysten kytt harkittiin, niin toteutuksessa pdyttiin lopulta verkko-ohjelmiston toteuttamiseen tyhjst, lukuunottamatta nkymien luomiseen kytetty sivupohjamenetelm. Verkko-ohjelmiston luokkaarkkitehtuuri ja luokkien sisinen toiminta luotiin joitakin Seminolen tarjoamia luokkia lukuunottamatta itse. Kytetty ohjelmointikieli oli sulautetuille jrjestelmille nopeuden kannalta oivallisesti soveltuva C++, joka ei vlttmtt ole verkko-ohjelmiston toteutuskieleksi suoraviivaisin. Ongelmia esiintyi muun muassa sovelluksen kyttmien tietorakenteiden yhteydess, joista monet kirjoitettiin projektin edetess uudelleen. Ohjelmointityt helpottivat muun muassa STL-kirjaston tarjoamat valmiit
78

tietorakenteet. Toteutuksessa olisi saatettu pty johonkin korkeamman tason kieleen, kuten Javaan ja sille toteutettuihin sovelluskehyksiin, mikli Java-virtuaalikoneen kytt kohdeympristss olisi ollut mahdollista.

79

Lhdeluettelo
[ASF05], The Apache Software Foundation (2005), Apache API Notes, http://httpd.apache.org/docs/1.3/misc/API.html. (Haettu 18.3.2007). [AT01], Aprelium Technologies (2001), Abyss Web Server, http://www.aprelium.com/abyssws. (Haettu 19.3.2007). [Ber99], Berners-Lee, T. et al. (1999), Hypertext Transfer Protocol HTTP/1.1. IETF RFC2616, http://www.ietf.org/rfc/rfc2616.txt. (Haettu 7.11.2006). [CN01], CollabNet, Inc. (2001), Subversion, http://subversion.tigris.org. (Haettu 19.3.2007). [CoRo99], Coar, K., Robinson, D., (1999), The WWW Common Gateway Interface 1.1 Revision 3. http://cgi-spec.golux.com/draft-coar-cgi-v11-03.txt. (Haettu 17.2.2007). [DC06], Design Combus Oy (2006), Iris 24 HW-arkkitehtuuri. [DiAl99], Dierks, T., Allen, C., (1999), The TLS Protocol, version 1.0. IETF RFC2246, http://www.ietf.org/rfc/rfc2246.txt (Haettu 18.11.2006). [Dru99], Druschel, Peter et al. (1999), Flash: An Efficient and Portable Web Server. USENIX Annual Technical Conference Monterey, California, USA, June 611, 1999. http://www.usenix.org/events/usenix99/full_papers/pai/pai.pdf. (Haettu 6.1.2007). [Fra99], Franks, J. et al. (1999), Hypertext Transfer Protocol HTTP Authentication: Basic and Digest Access Authentication. IETF RFC2617, http://www.ietf.org/rfc/rfc2617.txt. (Haettu 19.11.2006). [Fre06], Freier, Alan et al. (1996), SSL 3.0 Specification. Netscape Internet Draft, http://wp.netscape.com/eng/ssl3/. (Haettu 18.11.2006). [FSF91], Free Software Foundation, Inc. (1991), GNU General Public License. http://www.gnu.org/licenses/gpl.txt. (Haettu 19.2.2007). [FSF97], Free Software Foundation, Inc. (1997), GNU Make. http://www.gnu.org/software/make. (Haettu 19.3.2007). [GA00], GoAhead Software Inc. (2000), GoAhead WebServer 2.1 datasheet, http://data.goahead.com/webserver/WS-Datasheet5-00.cra.pdf. (Haettu 7.1.2007). [Gru86], Grune, Dick (1986), Concurrent Versions System, http://www.nongnu.org/cvs. (Haettu 19.3.2007). [GS06a], GladeSoft, Inc. (2006), Seminole Datasheet, http://www.gladesoft.com/products/seminole/semdatasheet.pdf. (Haettu 20.11.2006).

80

[GS06b], GladeSoft, Inc. (2006), Seminole Developers Guide, http://www.gladesoft.com/products/seminole/semman.pdf. (Haettu 20.11.2006). [HaJ03], Haikala, Ilkka, Jrvinen, Hannu-Matti (2003), Kyttjrjestelmt. Helsinki: Talentum. 242 s. [HaM98], Haikala, Ilkka, Mrijrvi, Jukka (1998), Ohjelmistotuotanto, 6. painos. Helsinki: Suomen ATK-kustannus Oy. 389 s. [HuTh00], Hunt, Andrew, Thomas, David (2000), The Pragmatic Programmer. Boston: Addison-Wesley. 321 s. [Kal95], Kalimo, Anna (1995), Graafisen kyttliittymn suunnittelu. Helsinki: Tieke RY. 229 s. [Ker02a], Keren, Guy (2002), Unix Multi-Process Programming and Inter-Process Communications (IPC), http://users.actcom.co.il/~choo/lupg/tutorials/multiprocess/multi-process.html. (Haettu 26.11.2006). [Ker02b], Keren, Guy (2002), Network programming under Unix systems, http://users.actcom.co.il/~choo/lupg/tutorials/internetworking/internetprogramming.html#sockets. (Haettu 26.11.2006). [Ker98], Kerttula, Matti (1998), Tietoverkkojen tietoturva. Helsinki: Oy Edita Ab. 510 s. [KL07], KoanLogic (2007), Koanlogic Klone tutorial, http://www.koanlogic.com/kl/cont/gb/html/klone-tute.html. (Haettu 14.1.2007). [Kuu03], Kuutti, Wille (2003), Kytettvyys, suunnittelu ja arviointi. Helsinki: Talentum. 191 s. [Maj05], Maj, Arthur (2005), Apache 2 with SSL/TLS: Step-by-Step, http://www.securityfocus.com/infocus/1818. (Haettu 18.2.2007). [Mas05], Mason, Mike (2005), Pragmatic Version Control using Subversion. Dallas: The Pragmatic Programmers. 207 s. [Mbe03], Mbedthis Software LLC (2003), AppWeb/Mbedthis, http://www.mbedthis.com. (Haettu 19.3.2007). [MS95], Microsoft Corporation (1995), Internet Server API, http://msdn.microsoft.com. (Haettu 19.3.2007). [Mk04], Mkitalo, Tommi (2004), Tntnet Web Server, http://www.tntnet.org. (Haettu 19.3.2007). [OG01], The Open Group (2001), The Single Unix Specification, Version 3, http://www.opengroup.org/unix/online.html. (Haettu 19.3.2007).

81

[OM96], Open Market, Inc. (1996), FastCGI: A High-Performance Web Server Interface, http://www.fastcgi.com/devkit/doc/fastcgi-whitepaper/fastcgi.htm. (Haettu 18.3.2007). [OvRa98], Ovaska, Saila, Rih, Kari-Jouko (1998), Kytettvyystestaus. Sytyke RY, Systeemity 4/98. s. 13-14. [Pel98], Peltomki, Juha (1998), WWW-ohjelmointi. Jyvskyl: Teknolit. 722 s. [Per96], Perens, Bruce (1996), BusyBox, http://www.busybox.net. (Haettu 18.3.2007). [Pus01], Puska, Matti (2001), Linux palvelimena. Helsinki: Satku. 304 s. [RuCo01], Cobert, Jonathan, Rubini, Alessandro (2001), Linux Device Drivers: Second Edition. Sebastopol, CA: O'Reilly & Associates Inc., 564 s. [Yag03], Yaghmour, Karim (2003), Building Embedded Linux Systems. Sebastopol, CA: O'Reilly & Associates, Inc., 391 s. [ZT95], Zeus Technologies Ltd. (1995), Zeus Web Server, http://www.zeus.com/products/zws. (Haettu 19.3.2007).

82

Liitteet
Liite 1. Subversion-komennot selityksineen (suluissa mahdolliset synonyymit). add tallenna kohde versionhallintaan. blame (praise, annotate, ann) tulosta tiedoston tai URL:n sislt ja tekijn merkint. cat tulosta tiedoston tai URL:n sislt. checkout (co) kohteen haku paikalliseen hakemistoon. cleanup putsaa tykansio mm. lukituksista ja tallentamattomista muutoksista. commit (ci) tykansion muutosten tallennus versionhallintaan. copy (cp) tee kohteesta kopio haluttuun sijaintiin. delete (del, remove, rm) poista kohde. diff (di) nyt kahden kohteen vlinen ero. export luo versioimaton kopio pkopiosta. help (?, h) nyt ohje. import tallenna versioimattoman kopion muutokset versionhallintaan. info nyt kohteen tiedot. list (ls) tulosta kansion sislt. lock lukitse haluttu kohde, eli est muiden kyttjien siihen kohdistuvat tallennukset. log nyt halutun kohteen muutosten selitykset. merge yhdist halutut kohteet. mkdir luo uusi kansio. move (mv, rename, ren) siirr kohde haluttuun sijaintiin. propdel (pdel, pd) poista kohteen ominaisuustiedot. propedit (pedit, pe) muokkaa kohteen ominaisuustietoja. propget (pget, pg) hae kohteen halutut ominaisuustiedot. proplist (plist, pl) hae kohteen kaikki ominaisuustiedot. propset (pset, ps) aseta kohteelle haluttu ominaisuustieto. resolved poista kohteen ristiriitamerkinnt. revert peru kohteelle tehdyt muutokset. status (stat, st) nyt tykopiossa olevan kohteen tila. switch (sw) tallenna tykopio uuteen silytyspaikkaan. unlock avaa haluttu tykopio tai URL. update (up) pivit versionhallinnan muutokset tykopioon.

Liite 2. Kartoituksessa mukana olleet HTTP-palvelimet.

Ohjelma Abyss axTLS Embedded SSL Anti-web HTTPD Apache 2.2 AppWeb/Mbedthis Barracuda Bauk Boa Caudium Cherokee Clearsilver CoreHTTP Embedded HTTP server fnord Fusion Hydra Embedded Web Server Hydra Web Server KLone Kritton libwebserver Lighttpd Litespeed mathopd micro_httpd mini_httpd muhttpd Monkey HTTP-daemon Null httpd Seminole shttp thttpd Thy tntnet xs-httpd xweb Lisenssi Freeware/maksullinen ($60) LGPL GPLv2 Apache License maksullinen (~$5/lisenssi 1000kpl) maksullinen "BSD" (VIL) GPL GPL GPLv2 Apache License AFL (Academic Free License) LGPL GPL maksullinen opensource GPL GPLv2/maksullinen (~2e/lisenssi) GPL LGPL BSD (muokattu) 0 - $799 (2CPU) "BSD" BSD BSD MIT GPL GPL $499-$1999 MIT BSD GPL GPL GPL GPL Prosessimalli multi-threaded multi-threaded SPED multi-threaded multi-threaded multi-threaded single-process tai multi-process SPED multi-threaded ? ? SPED ei mritelty multi-threaded SPED/multithreaded ? multi-threaded SPED multi-process ei mritelty SPED ? single-process kernel inetd multi-process ? multi-threaded multi-threaded SPED SPED SPED ? multi-threaded multi-process ? SPED Koko (kt) 840 2030 190 29670 pieni pieni 940 490 18768 Tietoturva Access, Anti-hack protection SSL ? Auth, SSL/TLS, .htaccess Auth, SSL Auth, HTTPS, SSL/TLS (SharkSSL), session Auth, access restriction fs permissions Auth, session

7430 TLS/SSL (GNUTLS, OpenSSL) 2610 190 1480 130 7KB-11KB ROM erittin pieni 1200 5370 740 1010 3680 14700 253 20 170 90 330 120 pieni 152 550 1890 3350 1090 110 ? ? HTTPS ? HTTPS server ? TLS/SSL TLS/SSL, session, encryption tbd SSL Auth, SSL TLS/SSL ? HTTPS mahdollinen (stunnel) Auth, SSL SSL Deny by URL & IP ? SSL SSL permissions TLS/SSL SSL SSL ?

Zeus Web Server maksullinen ($1700/2CPU)

SSL, anti-DoS, request filtering, suuri htaccess

Liite 3. Kyttliittymsuunnitelman sillan editointinkym.

Liite 4. Kyttliittymsuunnitelman sillan lisysnkym.

Liite 5. Kyttliittymsuunnitelman siltojen listausnkym.

Liite 6. Kyttliittymsuunnitelman ethernet-liitntjen listausnkym.

Liite 7. Kyttliittymsuunnitelman nkym pakettilaskurien listauksesta.

Liite 8. Kyttliittymsuunnitelman levykuvan latausnkym.

Liite 9. Kyttliittymsuunnitelman levykuvan asennusnkym.

Liite 10. Kyttliittymsuunnitelman nkym levykuvan keskenerisest asennuksesta.

Liite 11. Kyttliittymsuunnitelman laitteen konfiguraatiovalikko.

Liite 12. Kyttliittymsuunnitelman nkym pyynnn vahvistamiskyselyst.

Liite 13. Kyttliittymsuunnitelman nkym levykuvan asennuksen valmistumisesta.

Liite 14. Kyttliittymsuunnitelman etusivunkym.

Liite 15. Kyttliittymsuunnitelman SNMP-yhteisn nyttminen.

Liite 16. Sillan nyttminen lopullisessa web-hallintasovelluksessa.

Liite 17. Sillan muokkaaminen lopullisessa web-hallintasovelluksessa.

Liite 18. Yhden hallintaobjektin listaamiseen kuluva aika. Mittaus 1:

00:05:56,939 [1024] TRACE <> 00:05:56,989 [1024] TRACE <> 00:05:56,989 [1024] TRACE <> 00:05:56,989 [1024] TRACE <> obj::deserializer() 00:05:56,999 [1024] TRACE <> remote_home::get_first() const 00:05:57,019 [1024] TRACE <> 00:05:57,869 [1024] DEBUG <> 00:05:58,159 [1024] TRACE <> 00:05:58,159 [1024] TRACE <> 00:05:58,189 [1024] TRACE <> obj::deserializer() 00:05:58,209 [1024] TRACE <> remote_home::get_next() const 00:05:58,269 [1024] TRACE <> 00:05:58,899 [1024] DEBUG <> timing: starting process class obj * obj::clone() const class dc_error_t obj::serialize() const static class dc_error_t class dc_error_t <--- send msg >--- recv msg class obj * obj::clone() const class dc_error_t obj::serialize() const static class dc_error_t class dc_error_t <--- send msg >--- recv msg

00:05:58,959 [1024] TRACE <> - class dc_error_t obj::serialize() const 00:05:58,969 [1024] TRACE <> - static class dc_error_t obj::deserializer() 00:05:59,069 [1024] TRACE <> - timing: process done IPC delay: 1,48s total: 2,13s

Mittaus 2:
00:09:42,499 [1024] TRACE <> 00:09:42,499 [1024] TRACE <> 00:09:42,499 [1024] TRACE <> 00:09:42,509 [1024] TRACE <> obj::deserializer() 00:09:42,509 [1024] TRACE <> remote_home::get_first() const 00:09:42,529 [1024] TRACE <> 00:09:43,379 [1024] DEBUG <> 00:09:43,659 [1024] TRACE <> 00:09:43,669 [1024] TRACE <> 00:09:43,699 [1024] TRACE <> obj::deserializer() 00:09:43,709 [1024] TRACE <> remote_home::get_next() const 00:09:43,769 [1024] TRACE <> 00:09:44,409 [1024] DEBUG <> timing: starting process class obj * obj::clone() const class dc_error_t obj::serialize() const static class dc_error_t class dc_error_t <--- send msg >--- recv msg class obj * obj::clone() const class dc_error_t obj::serialize() const static class dc_error_t class dc_error_t <--- send msg >--- recv msg

00:09:44,469 [1024] TRACE <> - class dc_error_t obj::serialize() const 00:09:44,469 [1024] TRACE <> - static class dc_error_t obj::deserializer() 00:09:44,569 [1024] TRACE <> - timing: process done IPC delay: 1,49s total: 2,07s