4. VAATIMUKSET HINTAPALVELIMELLE
4.4. Tehokas tiedonvälitys
Ohjelman olisi kyettävä vastaamaan toisista koneista verkon yli tuleviin kyselyihin aivan samoin kuin ne tulisivat samasta koneesta eli toisin sanoen kyselyihin vastaava ohjelmanosa on samanlainen riippumatta siitä, mistä kyselyt tulevat. Tähän ehkä käyttökelpoisin ja laajimmin eri ympäristöihin saatava ratkaisu on etäproseduurikutsu {Remote Procedure Call, RPC), joka tarjoaa työkalut funktiokutsujen suorittamiseen verkon yli ja piilottaa verkkoliikenteeseen liittyvät yksityiskohdat sovellusohjelmoijalta. Samalla RPC huolehtii muunnoksista tiedon eri esitysmuotojen välillä. Myös tiedon tilaamiseen ja ohjelman hallintaan liittyvät transaktiot olisi helppo toteuttaa käyttäen RPC:tä.
Tavallinen tilaus/kuuntelu-tilanne voisi asiakasohjelman kannalta edetä seuraavasti:
1. ota yhteys hintapalvelimeen ja vastaanota yhteystunniste, 2. tilaa hintamuutoksia käyttäen saatua yhteystunnistetta, 2. kuuntele syntynyttä yhteyttä ja vastaanota hintamuutoksia, 3. lopeta hintamuutosten tilaukset käyttäen saatua yhteystunnistetta, 4. katkaise yhteys hintapalvelimeen.
Pelkkä tiedon kysely ei vaadi sen tilaamista, vaan haluttu tieto vastaanotetaan itse kyselytapahtumassa.
Kyselyissä käytetään yhteydenotossa saatua yhteystunnistetta. Yhteystunnistetta käytetään siitä syystä, että asiakasohjelmalla voi olla yhteyksiä auki useamman eri hintapalvelimen kanssa riippuen siitä, mitä palveluja kyseiset hintapalvelimet tarjoavat.
Ohjelmaan on rakennettava tehokas ja helppokäyttöinen tiedonvälitysmekanismi, jolla muuttuneet hintanoteeraukset välitetään niistä kiinnostuneille. Sopiva tapa sen toteuttamiseen on erillinen
multicast-kirjasto, jolla ohjelma voi lähettää yhdellä kutsulla muuttuneet tiedot kaikille halukkaille.
Lähetystoiminnon olisi myös hyvä olla asynkroninen, jolloin ohjelman muut toiminnot eivät joutuisi odottamaan hitaiden I/O-toimintojen suorittamista. Toisaalta myöskään eri asiakasohjelmille lähetykset eivät saisi olla häiriöksi toisilleen. Kirjaston pitäisi tarjota ohjelmalle toiminnot Init, Send ja Close.
Toimintojen sisällön tulee olla seuraava:
Init : ohjelma alustaa kirjaston antamalla osoitteen, johon asiakasohjelmien on otettava yhteys käynnistyessään. Samalla annetaan tiedot kirjastolle siitä, mitä tehdään asiakasohjelman ottaessa yhteyttä tai virhetilanteen sattuessa. Nämä toiminnot voidaan hoitaa ns. ca/tøacÅ-funktioilla; asiakkaan ottaessa yhteyttä siirrytään suorittamaan init-kutsussa annettua funktiota, jossa tehdään tapahtumaan liittyviä toimenpiteitä. Init-kutsun jälkeen ohjelma kuuntelee ja on valmis vastaanottamaan yhteyspyyntöjä asiakasohjelmilta.
Send : ohjelma lähettää tietoyksikön kaikille kiinnostuneille asiakasohjelmille.
Close : tietojen lähetys lopetetaan ja kaikki yhteydet asiakasohjelmiin katkaistaan.
Kirjaston avulla on saatava tieto siitä, mitä asiakasohjelmia ohjelmaan on yhteydessä ja mahdollisesti kyettävä katkaisemaan halutut yhteydet antamalla kirjastolle katkaisukomento.
Multicast-kirjaston sisään olisi myös sijoitettava jokaista yhteyttä valvova heartbeat-toiminto, joka auttaisi havaitsemaan hintapalvelimen ja asiakasohjelmien välisiä yhteyshäiriöitä. Toiminto voidaan toteuttaa niin, että kirjasto lähettää automaattisesti jokaiselle palvelemalleen asiakasohjelmalle tasaisin väliajoin viestiä, jolle se odottaa vastausta tietyn ajan kuluessa. Jos palvelin ei saa vastausta viestiinsä asetetun ajan kuluessa, olettaa se yhteyden vikaantuneeksi ja katkaisee yhteyden asiakasohjelmaan. Jos asiakasohjelma ei saa vastaan viestejä sovituin väliajoin, voi sekin olettaa yhteyden vikaantuneen ja katkaista yhteyden palvelimeen. Näin asiakasohjelma voi myös havaita tilanteet, joissa palvelin on joutunut virheillään ja estynyt itse lähettämästä viestejä ja havaitsemasta yhteyden vikaantumista.
Asiakasohjelman puolella tämä toiminnallisuus tulee piilottaa hintapalvelin-API:n sisään.
Tässä tapauksessa ehkä käytännöllisin tapa toteuttaa muuttuneiden tietojen lähetys asiakasohjelmille on simuloida eräänlaista mzz/izcczsi-toimintoa käyttäen jokaiselle asiakasyhteydelle omaa loogista kahdenkeskistä yhteyttä, jolloin olemassa olevien yhteyksien hallinta on yksinkertaista. Tähän yhteyteen voidaan käyttää socketteja. Socketit [14, s. 292-293] ovat BSD-Unixin (Berkeley Software Distribution) [8] mukana yleistynyt tapa esittää tietoliikenneyhteyksiä. Sockettien saatavuus eri käyttöjärjestelmille helpottaa niiden valintaa tähän tehtävään. Niiden tarjoamista yhteystavoista käyttökelpoisin on kahdenkeskiseen tiedonsiirtoon sopiva yhteyspohjainen socket, jonka kanssa käytetään TCP-protokollaa. Yhteyspohjaisia socketteja käytettäessä tiedon lukeminen ja kirjoittaminen muistuttaa paljon tavallisten tiedostojen käsittelyä. Toisaalta toiminnon pitää näyttää lähettäjälle yhdeltä I/O-operaatiolta. Eri yhteyksille lähetykset on piilotettu znzz/fzcasf-kirjaston sisälle, joten sen yksityiskohtia ei tarvitse ottaa huomioon suunniteltaessa hintapalvelimen muita toimintoja. Tämä
yhteyspohjainen ratkaisu on myös sellaisenaan sopiva eri lähiverkkojen välillä, kun palvelin ja asiakasohjelma sijaitsevat eri verkoissa. Riittää, kun palvelimen ja asiakasohjelman välillä on toimiva reititinyhteys.
Hintapalvelimen on kyettävä lähettämään tietoa muodossa, jossa sitä voidaan lukea useissa erilaisissa järjestelmissä ja laitteistoissa. Tämän takia hintapalvelimen on muutettava lähettämänsä hintatieto ns.
verkko-muotoon, josta se voidaan helposti muuttaa takaisin eri järjestelmien ymmärtämään muotoon, (kuva 4.1.) Tähän tarkoitukseen on useita eri työkaluja, joista ehkä käyttökelpoisin on ONC RPC:n (Remote Procedure Call, SUN Microsystems) yhteydessä käytetty XDR-muunnos (external data representation), jolla voidaan muuntaa tietoa järjestelmän sisäisestä muodosta verkkomuotoon ja takaisin vastaanottavan järjestelmän ymmärtämään muotoon. Muunnos perustuu suunnittelijan luomasta tietorakennekuvauksesta generoituihin järjestelmäkohtaisiin kuvaustiedostoihin ja muunnosproseduureihin. Suunnittelijan tarvitsee vain suunnitella siirrossa käytetyt tietorakenteet ja generoida Rpcgen-ohjelmalla kuvaustiedostot ja muunnosproseduurit kaikkiin vastaanottaviin järjestelmiin. Vastaanottavien järjestelmien sisäisestä tiedon esitystavasta suunnittelijan ei tarvitse huolehtia. Muunnoksen aiheuttamiin vaikutuksiin tiedonsiirron nopeudessa puututaan tarkemmin hintapalvelimen toteutusta esiteltäessä.
.Muunnos Muunnos Muunnos
Muunnos
Laitearkkitehtuuri 1 Muunnos
Muunnos
Asiakas
Asiakas Asiakas Asiakas
Hintapalvelin
Laitearkkitehtuuri 2 Muunnos
Kuva 4.1. Tiedon yleinen esitysmuoto
4.5. Palvelujen sijalntlläpinäkyvyys
Kun asiakasohjelma haluaa käyttää hintapalvelimen palveluja sen ei tarvitse olla tietoinen palvelimen fyysisestä sijainnista, vaan se ottaa yhteyden palveluhakemisto-prosessiin, jonka tehtävänä on pitää kirjaa, mitkä hintapalvelimet tarjoavat palveluja mille hyödykkeille. Tämä palvelu ohjaa kaikki kyselyt automaattisesti oikealle palvelimelle. Hintapalvelimet vastaavasti käynnistyessään kertovat kaikille palveluhakemisto-prosesseille, mitä palveluja ne tarjoavat ja missä osoitteessa. Näin palveluhakemiston tehtäväksi jää huolehtia siitä, että kyselyt ohjataan oikeisiin osoitteisiin. Palveluja pyydetään nimien perusteella. Kappaleessa 4.1 mainituissa saatavissa palveluissa käytetyt termit Item ja Topic voisivat olla näitä nimiä ja tarkoittaa seuraavaa:
Item : hyödykkeen virallinen kaupankäyntitunnus, esim. ”NOKAV” = Nokia A osake.
Topic : mitä tietoa halutaan, esim. ”LAST” = Viimeinen kauppahinta.
Jos samaa palvelua tarjoavat useat hintapalvelimet, jää palveluhakemiston tehtäväksi valita kulloinkin käytettävä palvelin (kuva 4.2). Tämä ominaisuus tarjoaa mahdollisuuden myöskin tasata kuormaa eri palvelimien välillä käyttäen erilaisia kuormantasausmenetelmiä. Myös palvelujen varmistaminen kahdentamalla olisi näin melko helposti toteutettavissa. Näiden lisäominaisuuksien lisääminen myöhemmin palveluhakemistoon ei myöskään vaatisi muutoksia asiakasohjelmiin.
Yksinkertaisimmillaan palvelu muistuttaisi hyvin paljon ONCRPCin käyttämää portmapper-palvelua [3], jota nimitystä palvelusta myöhemmässä tekstissä tullaan käyttämään. Portmapper on palvelu, joka ohjaa kyselyitä asiakasohjelmien antamien palvelunumeroiden mukaan oikeille palvelimille, edellyttäen, että nämä palvelimet ovat rekisteröityneet palveluun kyseisillä palvelunumeroilla.
Palveluhakemisto
Asiakasohjelma
Hintapalvelin (johdannaiset) Asiakasohjelma
Hintapalvelin (obligaatiot) Hintapalvelin
(osakkeet)
Kuva 4.2. Palveluhakemisto
5. HINTAPALVELIMEN TOTEUTUS
Hintapalvelimen määrittelyistä päätettiin toteuttaa ne osat, jotka tarvitaan edellisen luvun alussa esitettyjen palveluiden toteuttamiseen. Nämä toteutettavat palvelut ovat tilaus, tilauksen lopetus, kysely ja julkistus. Näin ollen tulevaisuuden parannukset eivät merkittävästi vaikuta hintapalvelinta jo käyttävien asiakasohjelmien toteutukseen muuten kuin lisättyjen palvelujen osalta. Toisin sanoen asiakasohjelmat eivät näe tulevaisuuden parannuksia muuten kuin parantuvan palvelun muodossa.
Toteuttamatta jätettiin:
Puskurointi, sillä käytännön ratkaisussa tiedon määrä on sen verran pieni, että sen pitäminen jokaisen palvelimen muistissa ei tuota ongelmia. Jos käytännön toteutus olisi vaatinut esimerkiksi yhtä suurta tiedon määrää kuin Reuters in katselusovelluksilla on mahdollista seurata, olisi puskuroinnin toteuttamisesta saatava hyöty ollut siihen uhratun työn arvoista.
Palvelun sijaintiläpinäkyvyys. Edellisessä luvussa esitetty portmapper-tyyppinen palveluhakemisto jätettiin toteuttamatta ja asiakasohjelmat käyttävät suoraan halutun palvelimen osoitetta tehdessään yhteydenoton istunnon alkaessa. Kaikki samaa yhteystunnistetta käyttävät kyselyt ja tilaukset menevät samalle palvelimelle. Toisaalta asiakasohjelmalla voi olla useita yhteyksiä eri palvelimille, jotka kaikki käyttävät eri yhteystunnistetta, eli asiakasohjelma voi käyttää useita eri hintapalvelimia halutessaan.
5.1. Hintapalvelimen toiminta
Hintapalvelimen suunnittelu perustuu Multicast-kirjaston, RPC:n ja useiden säikeiden käyttöön.
Säikeet [14, s. 507-523] ovat saman prosessin sisäisiä erillisiä ja rinnakkaisia suorituspolkuja. Ne toimivat aivan kuin erilliset prosessit, mutta jakavat saman osoiteavaruuden. Ohjelma toimii ns.
julkaisijana eli se lähettää yhteyden ottaneille asiakasohjelmille niiden haluamia hinnanmuutoksia.
Samalla ohjelma toimii RPC-palvelimena vastaten tuleviin RPC-kyselyihin. Nämä kyselyt voivat olla joko todellisia kyselyitä, joihin vastataan palauttamalla kyselijälle haluttu hintatieto, tai ohjauskomentoja, joilla asiakasohjelma kertoo hintapalvelimelle, mitä hintamuutoksia hän haluaa tilata tai perua (kuva 5.1).
tilauksen
Ensimmäiseksi käynnistyttyään hintapalvelin alustaa itsensä kyselemällä kaupankäyntijärjestelmästä kaikki mahdollisesti tarvittavat hintatiedot. Vain alimpana ketjussa oleva hintapalvelin kysyy kaupankäyntijärjestelmästä kaikki tarvittavat hintatiedot etukäteen. Muut kysyvät alempana ketjussa olevalta hintapalvelimelta hinnat tarvittaessa. Seuraavaksi käynnistetään Mzv//zca.?i-kirjasto kuuntelemaan verkosta tulevia yhteyspyyntöjä. Aina saatuaan uuden yhteyden Multicast-kirjasto käynnistää tätä yhteyttä varten uuden lähettäjäsäikeen ja palauttaa asiakasohjelmalle yksiselitteisen yhteystunnisteen. Tämän saman tunnisteen se antaa samalla hintapalvelimelle mahdollisia tulevia ohjauskomentoja varten. Aina saatuaan hintamuutoksen kaupankäyntijärjestelmästä hintapalvelin lähettää sen yleiseen verkkomuotoon muunnettuna Мм/í/'casí-kirjastolle eteenpäin lähetettäväksi.
Multicast-knjasto kutsuu jokaiselle asiakasyhteydelle erikseen ns. tarkistusfunktiota, jossa tarkistetaan hintapalvelimen ylläpitämästä kaikille säikeille yhteisestä muistialueesta, onko kyseinen yhteys tilannut tämän hintamuutoksen itselleen. Tämä tieto palautetaan Мм/í/'casí-kirjastolle ja hintamuutos lähetetään tarvittaessa eteenpäin. Aina tätä yhteistä muistialuetta luettaessa tai kirjoittaessa se on lukittuna kyseiselle ohjelman säikeelle. M ui tic as Z- k i rj as to n käynnistettyään ohjelma asettuu kuuntelemaan tulevia RPC-kyselyjä. Näissä kyselyissä asiakasohjelmat joko tekevät hintakyselyjä tai antavat ohjauskomentoja. Hintakyselyihin hintapalvelin vastaa välittömästi joko antamalla kysytyn hintatiedon tai vastaamalla virhepalautteen, jos kysely epäonnistui tai haluttua hintatietoa ei ole saatavilla.
Ohjauskomennoissa asiakasohjelmat lähettävät kyseisen yhteyden yhteystunnisteen ja komennon, joka kertoo, mikä hintamuutos tilataan tai tilaus lopetetaan. Tämän saadun yhteystunnisteen perusteella sijoitetaan yhteiseen muistialueeseen tieto halutusta hintamuutostilauksesta. Tätä tietoa käytetään edellä mainitussa tarkistusfunktiossa.
5 . 2 . Multicasting
5.2.1. Yleistä
Mzz/íz'cosí-kirjaston toteutus perustuu rinnakkaisohjelmoinnin yleisten tutkittujen menetelmien ja periaatteiden käyttöön. Rinnakkaisuudella on saavutettu huomattava suorituskykyetu. Yksikään hidas I/O-operaatio ei estä muille linjoille tapahtuvien I/O-operaatioiden samanaikaista toimintaa. Yhteisen muistin käsittely on suojattu lukoilla, mikä estää eri säikeitten keskinäisen häirinnän.
RinnakkaismeneteImien käyttö on myös selvästi yksinkertaistanut ohjelmien toteutusta, koska on voitu käyttää yksinkertaisia blokkaavia I/O-kutsuja. Vaihtoehtoinen toteutustapa olisi käyttää asynkronisia I/O-kutsuja, jolloin /им/í/casí-toiminnon toteuttaminen olisi huomattavasti monimutkaisempaa.
5.2.2. Toiminnot
Multicast-kir]asto tarjoaa käyttäjälle rajapinnan, johon kuuluvat seuraavat funktiot:
l.McInit
Mc/nzi-toiminto käynnistää säikeen, joka vastaanottaa yhteyspyyntöjä, ja käynnistää hyväksytyille yhteyksille lähettäjäsäikeet, jotka ovat vastuussa viestien lähettämisestä linjalle (tässä yhteydessä
”linja” tarkoittaa lähetyksessä käytettyä sockettid). Kukin lähettäjäsäie lukee lähetettäviä viestejä yhteisestä lähetettävien viestien puskurista ja lähettää niitä omalle linjalleen. Lähettäjäsäie voi olla kolmessa eri tilassa: (kuva 5.2.)
1. Se nukkuu odottaen, että lähetyspuskuriin tulee viestejä lähetettäväksi. McSend toiminto herättää lähettäjäsäikeen lukemaan.
2. Se on lukemassa, jolloin se lukitsee lähetyspuskurin ja tutkii, onko lähetyspuskurissa sille lähetettäviä viestejä. Jos viestejä ei löydy, se palaa nukkumaan vapauttaen lähetyspuskurin muille luettavaksi. Jos lähetettävää on, se lukee lähetyspuskurista yhden lähetettävän viestin. Tämän jälkeen se merkitsee lukemansa viestin lähetetyksi. Jos kaikki lähettäjäsäikeet ovat lukeneet kyseisen viestin sen varaama tila samalla vapautetaan. Lopuksi se vapauttaa lähetyspuskurin muille lähettäjäsäikeille luettavaksi.
3. Se kirjoittaa lähetyspuskurista lukemaansa viestiä omalle linjalleen. Tällöin lähetyspuskuri on vapautettuna muille lähetyssäikeille luettavaksi. Kirjoitettuaan viestin linjalle se palaa lukemaan, siis tutkimaan, onko kirjoitettavia viestejä vielä jäljellä.
Herätetään lukemaan (lukitsee lähetyspuskurin)
Ei enää lähetettävää, palaa odottamaan (vapauttaa lähetyspuskurin)
Siirtyy lähettämään viestiä
(vapauttaa lähetyspuskurin)
Palaa hakemaan lisää lähetettävää (lukitsee lähetyspuskurin) Odottaa viestejä
luettavaksi
Lukee viestin lähetyspuskurista
Lähettää viestin
Kuva 5.2. Lähettäjäsäie
2.McSend
McSend-toiminto kirjoittaa kutsujan antaman viestin lähettäjäsäikeitten yhteiseen lähetyspuskuriin.
Viestin kirjoituksen ajan toiminto pitää lähetyspuskurin lukittuna itselleen. Kun kirjoitus on suoritettu toiminto vapauttaa lähetyspuskurin muille luettavaksi ja herättää mahdollisesti nukkuvat
lähettäjäsäikeet lukemaan lähetyspuskuria.
3.McClose
McClose-toiminto lopettaa lähettäjä- ja yhteyspyyntösäikeitten toiminnan. Se odottaa, että lähettäjäsäikeet ovat kirjoittaneet kaikki lopetushetkeen mennessä lähetyspuskuriin kirjoitetut viestit ja sen jälkeen lähettää kaikille lähettäjä-ja yhteyspyyntösäikeille lopetussignaalin.
5.2.3. Lähetyspuskuri
Lähetyspuskurin käsittelyn ongelma on muunnos tuottajien ja kuluttajien ongelmasta. Ratkaisu on hyvin samankaltainen kirjallisuudessa esitettyjen kanssa [14, s. 39-56]. Ratkaisun sisältöä havainnollistetaan monitorina liitteessä A.
5.2.4. Heartbeat-toiminto
Hartbeat-toiminto on toteutettu käynnistämällä jokaiselle asiakasyhteydelle valvontasäie, jonka tehtävänä on lähettää säännöllisin väliajoin asiakasohjelmalle viesti, jolle se jää odottamaan vastausta.
Jos vastausta viestiin ei saada asetetun ajan kuluessa, lopetetaan kyseinen lähettäjäsäie, joka katkaisee yhteyden asiakasohjelmaan. Jos valvottavalle yhteydelle on tarpeeksi usein menossa myös varsinaisia hintaviestejä, ei kyseiselle yhteydelle lähetetä erikseen valvontaviestejä runsaan liikenteen aikana. Näin vältytään hidastamasta varsinaista viestiliikennettä. Liikaa hidastuneet yhteydet havaitaan erillisellä valvonnalla. Tämä valvonta on toteutettu tutkimalla aina kirjoitettaessa viestejä lähetyspuskuriin, kuinka vanha on vanhin lähetyspuskurissa oleva viesti. Jos se on asetettua aikaa vanhempi, ne yhteydet katkaistaan, joihin kyseistä viestiä ei ole lähetetty.
5.3. Hintapalvelin API
Hintapalvelin API on C-kielinen rajapinta hintapalvelimen ja asiakasohjelman välillä. Sen avulla on pyritty yksinkertaistamaan hintapalvelimen käyttöä. Esimerkiksi XDR-kirjaston avulla tehtävät tiedon muunnokset yleiseen verkkomuotoon ja takaisin sekä heartbeat- toiminnon vaatima heartbeats lestien lähetys ja kuuntelu on piilotettu sen sisään.
Tiedon muunnokset on toteutettu määrittelytiedostosta rpcgen- ohjelmalla generoiduilla muunnosproseduureilla. Asiakasohjelma ei havaitse muunnosta muuten kuin mahdollisena aikaviiveenä palvelussa. Käytännössä tämä muunnoksen itsensä aiheuttama viive on merkityksettömän pieni verrattuna laitteistojen välisen tiedonsiirron aiheuttamaan viiveeseen. Toisaalta, jos laitteistot ovat tiedon esitystavaltaan samanlaisia, verkkomuotoon ja takaisin muuttaminen saattaa tuntua turhalta saavutettuun etuun nähden. Haittaa saattaa syntyä varsinkin siinä tapauksessa, jos tiedon verkkomuotoon muuttaminen kasvattaa viestin kokoa runsaasti. Jos ohjelmien väliset tietoliikenneyhteydet ovat hitaita, kasvanut tiedon määrä saattaa hidastaa sen siirtymistä selvästikin. Jos siirrettävä tieto sisältää esimerkiksi paljon merkkijonoja, saattavat viestit näiden osalta kasvaa kooltaan jopa nelinkertaisiksi. Käytännön toteutuksessa ensimmäiset hintapalvelinta käyttävät ohjelmat ovat kuitenkin nopeiden verkkoyhteyksien takana, joten viestien koon kasvulla ei ole niiden kannalta käytännössä mitään merkitystä.
Heartbeatsiestien avulla toteutettu yhteyden valvontatoiminto katkaisee yhteyden automaattisesti, jos se havaitsee, että kyseisen yhteyden kautta ei ole vastaanotettu yhtään viestiä asetetun ajan kuluessa.
Kaikki vastaanottamansa valvontaviestit se kuittaa lähettämällä hintapalvelimelle samanlaisen viestin.
Runsaan liikenteen aikana se ei saa lainkaan valvontaviestejä, jolloin raskaasti kuormitettua yhteyttä ei turhaan rasiteta lisäliikenteellä.
Hintapalvelin API esitellään tarkemmin liitteessä B.
6.OMAN RATKAISUN ARVIOINTIA
Jos kutsumme hintapalvelimelle luvussa 5 esitettyjä vaatimuksia hintapalvelimen määrittelyksi, voimme arvioida, kuinka hyvin nämä määrittelyt toteuttavat aikaisemmin esitetyt perusvaatimukset.
Ensimmäisen vaatimuksen tuottaja-rajapinnasta, jonka avulla järjestelmään voidaan liittää ulkoisia tietolähteitä, määritelmä toteuttaa publish-toiminnollaan. Järjestelmässä on myöskin kuluttaja-rajapinta, jonka avulla järjestelmästä voidaan vastaanottaa tietoa. Kappaleessa 5.5 esitetyn palveluhakemisto- prosessin avulla voidaan toteuttaa vaatimus palvelun sijaintiläpinäkyvyydestä. Luvun 5 alussa esitetyt hintapalvelimelta saatavat palvelut ja myöhemmin samassa luvussa esitetty simuloitu multicast- toiminto mahdollistavat seuraavassa vaatimuksessa esitetyn tilaaja/julkaisija mallin toteutumisen.
Samassa kohdassa esitetty heartbeat-toiminnon avulla voidaan toteuttaa vaatimus siirtotien vikaantumisen havaitsemisesta. Kohdassa 5.2 esitetyllä puskuroinnilla voidaan toteuttaa seuraava vaatimus tiedon puskurointimahdollisuudesta järjestelmän suorituskyvyn lisäämiseksi. Jos tiedonvälitys toteutetaan määrittelyssä esitetyllä asiakaskohtaisilla socAei-yhteyksillä, riittää järjestelmän osien välille toimiva reititinyhteys. Näin ollen järjestelmän osat voivat sijaita eri
lähiverkoissa.
Kun tarkastelemme hintapalvelimen määrittelyä esitettyjen kriteerien valossa, havaitsemme heti, että määrittelyissä ei ole kiinnitetty suuremmin huomiota vikasietoisuuteen. Ehkä ainoa vikasietoisuuteen vaikuttava merkittävämpi tekijä on palveluhakemisto, jonka avulla voitaisiin toteuttaa palvelimien rinnakkaisuutta. Jotta jonkun palvelun vikaantuminen ei näkyisi lainkaan asiakaspäässä, olisi kaiken tiedon kuljettava palveluhakemiston kautta tai asiakaspään rajapinnan olisi kyettävä havaitsemaan vikaantuminen ja ottamaan yhteys uudestaan palveluhakemiston kautta mahdollisesti toimivaan hintapalvelimeen. Suurin merkitys suorituskyvylle on hyvin toteutetulla puskuroinnilla ja multicast- toiminnolla. Ehkä suurempi vaikutus saavutettaviin vasteaikoihin on puskuroinnin toteutuksella varsinkin hitaiden tietoliikenneyhteyksien tapauksessa. Jos saamme /и и/п'сауМо ¡ m i n no 11 a aikaan käytännössä samanaikaisen lähetyksen eri tilaajille, ovat eri tilaajat samanarvoisia yhtä nopeiden tietoliikenneyhteyksien tapauksessa. Laitteistojen välillä liikkuva tieto ei sisällä merkittävästi otsikkotietoa, jolloin sekään ei hidasta oleellisesti tiedon siirtymistä. Määrittelyissä ei ole mainittu asiakasohjelmien tahallista tai tahatonta häirintää estäviä ominaisuuksia.
Edellisestä huomaamme, että järjestelmän määrittely toteuttaa kaikki sille asetetut perusvaatimukset.
Järjestelmän määrittelyistä voimme havaita, että kaikkien edellä mainittujen vaatimusten toteuttamiseen olisi varsin hyviä valmiita algoritmeja ja työkaluja. Mikään niistä ei siis vaadi merkittävien uusien menetelmien tai ratkaisujen löytämistä. Toteutusta suunniteltaessa lähes ainoa kriteeri eri osien toteutukselle oli eri osien vaatima työmäärä. Tietyt vaatimukset saatettiin siis jättää
toteuttamatta, jos työmäärä saatavaan hyötyyn nähden oli liian suuri tai ominaisuutta ei vielä tarvittu.
Tämän periaatteen noudattamiseen yllytti usein ajanpuute. Yhtään sellaisia suunnitteluperiaatteita, joita käyttämällä estettäisiin tai tehtäisiin hankalaksi näiden ominaisuuksien myöhempi toteutus, ei kuitenkaan missään vaiheessa hyväksytty.
6.1. Hintapalvelimen toteutuksen arviointi
Jos hintapalvelimen toteutusta arvioidaan samoilla mainituilla vaatimuksilla ja kriteereillä kuin aikaisemmin, saamme seuraavanlaisia tuloksia:
Ensimmäistä vaatimusta tuottaja-rajapinnasta, jolla järjestelmään voidaan syöttää tietoa, ei toteutettu.
Toisin sanoen määrittelyissä esitetty publish-toiminto jätettiin toteuttamatta. Järjestelmä liitettiin suoraan SOM:n kaupankäyntijärjestelmään käyttämättä hintapalvelin-API:a. Jälkeenpäin ajatellen ratkaisu ei ollut viisas, sillä uusien tiedontuottajien liittäminen hintapalvelimeen olisi ollut helppoa käyttäen publish-toimintoa. Publish-toiminnolla mikä tahansa hintapalvelimeen liittynyt ohjelma olisi voinut julkaista järjestelmään tietoa.
Toisen vaatimuksen kuluttaja-rajapinnasta hintapalvelimen toteutus täyttää. Hintapalvelin-API:n toiminnoilla asiakasohjelma voi liittyä järjestelmään ja vastaanottaa siitä tietoa.
Kolmatta vaatimusta palvelun sijaintiläpinäkyvyydestä ei täytetty. Määrittelyissä esitettyä palveluhakemisto-ohjelmaa ei toteutettu, vaan asiakasohjelmien pitää tietää palveluja halutessaan, miltä palvelimelta kyseisen palvelun saa. Palveluhakemisto-ohjelman toteutus olisi työmäärältään ollut senhetkiseen saavutettuun hyötyyn nähden liian suuri. Toisaalta järjestelmän yleiskäyttöisyyden kannalta palveluhakemiston toteutus olisi tärkeää. Sen toteutus mahdollistaisi helpomman palvelujen lisäämisen järjestelmää sammuttamatta.
Neljäs vaatimus tilaaja/julkaisija-mallista toteutettiin osittain. Tilaajatoiminto toteutettiin hintapalvelin- API:iin käyttäen hyväksi ww/ttcas/-kirjaston palveluita. Kun publish-toiminto jätettiin toteuttamatta, jouduttiin tinkimään täydellisestä tilaaja/julkaisija-mallista.
Viides vaatimus tiedon ajantasaisuudesta tai sen puutteen havaitsemisesta toteutettiin hintapalvelin- API:n /ieart6eczHoiminnolla. Jos toinen yhteyden osapuolista ei saa heartbeatsiestiä sovitun ajan kuluessa, tulkitaan yhteys vikaantuneeksi ja yhteys pyritään luomaan uudestaan.
Kuudetta vaatimusta tiedon puskuroinnista ei toteutettu. Ensimmäisessä vaiheessa kaikki asiakasohjelmat sijaitsivat nopean lähiverkkoyhteyden päässä ja tiedon puskurointia ketjuttamalla hintapalvelimia ei siis tarvittu.
Seitsemäs vaatimus järjestelmän osien mahdollisuudesta sijaita eri lähiverkossa toteutettiin multicast- kirjaston avulla. Siinä käytetyt kahdenväliset socket-yhteydet toimivat, jos hintapalvelimen ja asiakasohjelman välillä on toimiva reititinyhteys. Tämä mahdollistaa esimerkiksi hintapalvelimen käytön Internetin välityksellä.
Toteutusta tarkastellessa havaitsemme myös, että käytännössä kaikki määrittelyissä esitetyt vikasietoisuuteen ja suorituskykyyn parantavasti vaikuttavat ominaisuudet on jätetty toistaiseksi toteuttamatta. Tästä ehkä poikkeuksena /ии/íí'casí-toiminnon aikaansaama samanaikaisuus.
Hintapalvelimen ensimmäisestä versiosta rakennettiinkin yksinkertainen normaalitilanteissa toimiva versio, jolla päästiin nopeasti testaamaan asiakasrajapinnan toimivuutta.
6.2. Parannusehdotuksia
Jos haluaisimme hintapalvelimen toteutuksenkin täyttävän kaikki mainitut seitsemän peruskriteeriä, pitäisi myös puuttuvat tiedon puskurointi ja palveluhakemisto toteuttaa. Näistä puskuroinnin merkitys kasvaisi, jos järjestelmä siirrettäisiin ympäristöön, joka sisältää hitaita tietoliikenneyhteyksiä. Jos puskuroinnissa käytettäisiin esimerkiksi LRU-sivunkorvausalgoritmia harvoin käytettyjen tietojen korvaamiseen muistin täyttymistapauksissa, olisi puskurimuistin toteuttaminen hyvinkin yksinkertaista.
Itse asiassa hintapalvelimen tapauksessa puskurimuistin täyttyminen olisi hyvinkin harvinaista johtuen noteerattavien instrumenttien kohtuullisen pienestä määrästä. Näin ollen jokainen kysytty tieto löytyisi hyvin todennäköisesti aina puskurimuistista, jos sitä on kysytty tai tilattu kerrankin aikaisemmin.
Toisaalta puskurimuistin toteuttamiseen on myöskin tarjolla useita valmiita ratkaisuja tai työkaluja, jolloin vaatimuksen täyttäminen kävisi entistäkin helpommaksi.
Palveluhakemiston toteuttaminenkaan ei vaatisi erityisen vaikeiden ongelmien ratkaisemista.
Palvelujen sijaintiläpinäkymättömyys voitaisiin toteuttaa rakentamalla palvelin, johon hintapalvelin- API ottaisi yhteyttä RPC-kutsulla aina tilausta aloitettaessa tai kyselyä tehtäessä. Palvelin palauttaisi niiden hintapalvelimien osoitteet, joita tarvittaisiin tämän kyselyn tai tilauksen toteuttamiseen. Tämän tiedon palveluhakemisto saisi hintapalvelimilta Publish-toiminnossa. Tiedon saatuaan hintapalvelin- API suorittaisi tilaukset tai kyselyt näiltä osoitteiden tarkoittamilta hintapalvelimilta. Tämän jälkeen kaikki kyseiseen tilaukseen tai kyselyyn liittyvä tapahtuisi hintapalvelimen ja hintapalvelin-API:n (siis asiakasohjelman) välillä. Kaikki tämä toiminnallisuus olisi piilotettu hintapalvelin-API:n ja palveluhakemiston sisälle, jolloin sijaintiläpinäkyvyys asiakasohjelman kannalta toteutuisi. Ainoastaan siinä tapauksessa, jolloin rinnakkaiset hintapalvelimet palvelisivat osittain samoja tietoja, saattaisi
palveluhakemistolla olla useita mahdollisia vastauksia samaan kysymykseen. Silloin palveluhakemisto voisi palauttaa niiden palvelimien osoitteet, jotka ovat vähiten kuormitettuja. Näin palveluhakemisto voisi tasata kuormaa eri palvelimien välillä. Jos jonkin palvelimen ja asiakasohjelman välinen yhteys vikaantuisi, voisi hintapalvelin-API kysyä automaattisesti uudestaan palveluhakemistolta haluttua hyödykettä palvelevan palvelimen osoitteen ja jatkaa yhteyttä sen kanssa. Vain siinä tapauksessa, että kyseistä palvelua ei löydy miltään toimivalta palvelimelta, välitetään asiakasohjelmalle tieto palvelun vikaantumisesta. Näin vikasietoisuuta voitaisiin lisätä monimutkaistamatta asiakasohjelmien toimintaa.
palveluhakemistolla olla useita mahdollisia vastauksia samaan kysymykseen. Silloin palveluhakemisto voisi palauttaa niiden palvelimien osoitteet, jotka ovat vähiten kuormitettuja. Näin palveluhakemisto voisi tasata kuormaa eri palvelimien välillä. Jos jonkin palvelimen ja asiakasohjelman välinen yhteys vikaantuisi, voisi hintapalvelin-API kysyä automaattisesti uudestaan palveluhakemistolta haluttua hyödykettä palvelevan palvelimen osoitteen ja jatkaa yhteyttä sen kanssa. Vain siinä tapauksessa, että kyseistä palvelua ei löydy miltään toimivalta palvelimelta, välitetään asiakasohjelmalle tieto palvelun vikaantumisesta. Näin vikasietoisuuta voitaisiin lisätä monimutkaistamatta asiakasohjelmien toimintaa.