TEKNILLINEN KORKEAKOULU Tietotekniikan osasto
Antti Partti
JOHDANNAISSOPIMUSTEN HINTATIEDON VÄLITTÄMINEN TIETOVERKOSSA
Diplomityö, joka on jätetty opinnäytteenä tarkastettavaksi diplomi-insinöörin tutkintoa varten Espoossa
Työn valvojat Heikki Saikkonen ja Mikko Tiusanen
TEKNILLINEN KORKEAKOULU DIPLOMITYÖN TIIVISTELMÄ
Tekijäja työn nimi : Antti Partti
Johdannaissopimusten hintatiedon välittäminen tietoverkossa
Päivämäärä: 11. Joulukuuta 1997 Sivumäärä: 55
Osasto : Tietotekniikan osasto Professuuri : Tik-76 Tietojenkäsittelyoppi
Työn valvojat : Heikki Saikkonen Mikko Tiusanen
Työn ohjaaja: Ari Kyhälä SOMOy
Johdannaisten ja muiden sijoitusinstrumenttien kaupankäynnissä on elintärkeätä saada ajantasaista tietoa niiden hintakehityksestä. Tarvitaan tietoa esimerkiksi niiden kauppa-, osto- ja myyntihinnoista. Ilman tätä tietoa kaupankäynti on käytännössä mahdotonta.
Perinteisiä välineitä tämän tiedon välittämiseen ovat olleet sanomalehdet, televisio ja tiedontuottajien omat hintojen seurantaan tarkoitetut tietokonelaitteistot ja -ohjelmat. Sijoittajan on ollut käytännössä mahdotonta käyttää tähän olemassaolevaa omaa tietojärjestelmäänsä. Markkinoille on kuitenkin viime aikoina tullut järjestelmiä, joissa liikkuvaa tietoa on mahdollista vastaanottaa käyttäjän omiin tietojärjestelmiin jatkojalostusta varten. Näistä järjestelmistä käytetään usein nimitystä informaation jakelualusta.
Tässä työssä luodaan katsaus viiteen tämäntyyppiseen järjestelmään. Ne pyrkivät ratkaisemaan ongelman, kuinka välittää tietoa sijoitushyödykkeiden hinnanmuutoksista samanaikaisesti useille eri vastaanottajille helposti hyväksi käytettävässä muodossa. Järjestelmää arvioidaan käyttäen apuna seitsemää sille asetettua perusvaatimusta ja kolmeaa vertailukriteeriä.
Perusvaatimukset olivat: tuottaja-rajapinta, kuluttaja-rajapinta, sijaintiläpinäkyvyys, tilaaja/julkaisija-malli, tieto palvelun ajantasaisuudesta, tiedon puskurointi ja tuki yhdistetyille lähiverkoille. Katsauksessa havaitaan, että tarkastelluista järjestelmistä vain kaksi täyttää kaikki asetetut perusvaatimukset. Vertailussa käytettyjä kriteerejä olivat Vikasietoisuus, suoritukyky ja turvallisuus. Valmiiden ratkaisujen arvioinnin jälkeen esitellään oma ratkaisu samaan ongelmaan. Oman ratkaisun määrittelyä ja toteutusta arvioidaan sen jälkeen samoilla vaatimuksilla ja kriteereillä kuin valmiita järjestelmiä.
Arvioinnissa havaitaan, että kaikki perusvaatimukset täyttävä järjestelmä on varsin suoraviivaisesti toteutettavissa.
Toteutusta esiteltäessä kiinnitetään eniten huomiota tiedon julkistuksen toteuttavan Multicast-kirjaston toteutukseen.
Avainsanat : hintatiedon välitys, informaatioalustat, julkistaminen, rinnakkaisuus, lukitseminen
Alkulause
Diplomityö on tehty SOM Oy:n ohjelmistokehitysprojektin yhteydessä.
Haluan kiittää kaikkia työssä avuksi olleita henkilöitä. Erityisesti haluan kiittää työn ohjaajaa Ari Kyhälää ja SOM:ia mahdollisuudesta diplomityön tekemiseen. Lisäksi haluan kiittää Pankkiiriliike Evli Oy:tä työlleni antamasta tuesta.
Haluan myös kiittää Heikki Saikkosta ja Mikko Tiusasta diplomityöni valvomisesta.
Helsingissä 11. Joulukuuta 1997
4
^Antti Partti
LYHENTEET... 2
1. JOHDANTO...3
2. TIEDON JULKISTAMINEN RAHOITUSMARKKINOILLA...4
2.1. Taustaa... 4
2.2. Ongelman kuvaus...10
2.3. Vaatimuksia ja arviointikriteerejä...11
3. INFORMAATION JAKELUALUSTAT... 14
3.1. Reliable Transaction Router (RTR)... 14
3.2. Invision... 16
3.3. OpenTrade Platform... 20
3.4. Reuters Tri arch... 22
3.5. Tibco Rendezvous... 25
3.6. Eri järjestelmien vertailua... 28
4. VAATIMUKSET HINTAPALVELIMELLE... 30
4.1. Saatavat palvelut... 30
4.3. Puskurointi... 31
4.4. Tehokas tiedonvälitys... 33
4.5. Palvelujen sijaintiläpinäkyvyys... 35
5. HINTAPALVELIMEN TOTEUTUS... 37
5.1. Hintapalvelimen toiminta... 37
5.2. Multicasting... 39
5.3. Hintapalvelin API... 41
6.OMAN RATKAISUN ARVIOINTIA... 43
6.1. Hintapalvelimen toteutuksen arviointi...44
6.2. Parannusehdotuksia... 45
7. YHTEENVETO... 47
LÄHDELUETTELO... 49
LIITE A. MONITOR SENDBUFFER... 50
LIITE В. HINTAPALVELIN API... 53
LYHENTEET
API
BSD
DACS
DDE
HSE
LAN
ODS
ONC
RPC
RTR
SSL
SOM
TCP
Triarch
URL
WAN
XDR
Application Programming Interface: ohjelmoijan rajapintakirjasto käytettävään järjestelmään.
Berkeley System Distribution: University of California at Berkeleyn kehittämä Unix-versio [8].
Data Access Control System: Reuters in Triarch-järjestelmän työkalu käyttöoikeuksien hallintaan [12, s.
37-41].
Dynamic Data Exchange: tietoliikenneprotokolla MS Windowsissa eri ohjelmien välillä [10].
Helsinki Stock Exchange: Helsingin arvopaperipörssi.
Local Area Network: lähiverkko.
Object Distribution System: Invisionin rajapinta tiedontuottajien ja muun järjestelmän välillä [7, s. 2-5].
Open Network Computing: Sun Microsystems^ työkalukokoelma hajautettuun laskentaan [3, s.22-24],
Remote Procedure Call: etäproseduurikutsu [14, s.417-445],[3, s.466].
Reliable Transaction Router: Digital Equipment Corporation^ tuote hajautettuun tapahtumankäsittelyyn [13].
Source Sink Library: Reutersin Triarch-järjestelmän ydinosa [12].
SOM Oy, ennen Suomen Optiomeklarit OY: Suomen johtava johdannaispörssi ja johdannaisten selvitysyhtiö, perustettu vuonna 1987.
Transmission Control Protocol: yhteyspohjainen protokolla prosessien väliseen tiedonsiirtoon.
Trading Room Information ARCHitecture: Reuterein informaationjakelualusta [12].
Universal Resource Locator: Yleinen tapa ilmaista objektin sijainti tietoverkossa. Yleensä käytössä internetissä.
Wide Area Network: kaukoverkko.
External Data Representation: ONC:n tiedon esitystapa tiedonsiirtoon eri laiteympäristöjen välillä [3, s.467].
1 .JOHDANTO
Johdannaismarkkinoilla käydään kauppaa sopimuksilla, jotka koskevat arvopaperien luovuttamista tai tuoton jakoa tulevaisuudessa. Näistä sopimuksista tunnetuimpia ovat optiot ja futuurit. Vuonna 1973 Black ja Scholes julkistivat optioiden hinnoittelumallin, jolla pystyttiin laskemaan nopeasti optiosopimukselle teoreettinen arvo [2]. Tämä malli oli ensimmäinen, jolla pystyttiin käytännössä tarpeeksi nopeasti määrittämään optiosopimukselle teoreettinen hinta. Mallin kehittäjistä Myron S.
Scholes vastaanotti yhdessä Robert C. Mertonin kanssa vuoden 1997 taloustieteen Nobel-palkinnon työstään optioiden hinnoittelun tutkimisessa. Mallia hyväksikäyttäen voidaan myös etsiä markkinoilta hinnoitteluvirheitä. Näiden hinnoitteluvirheiden ensimmäinen havaitsija voi usein tehdä niiden avulla käytännössä riskitöntä voittoa. Usein tämä ensimmäinen havaitsija on se, joka saa tietoa markkinoiden hinnanmuutoksista tarpeeksi nopeasti. Kun tietoa on useiden osapuolten saatavissa nopeasti, vähenee näiden hinnoitteluvirheiden määrä ja markkinat toimivat tehokkaasti. Tiedon nopea välitys kaikille markkinaosapuolille on siis yksi johdannaismarkkinoiden tärkeimmistä toimintaedellytyksistä.
Tämän työn aiheena on ohjelmisto nimeltään hintapalvelin, jonka teettäjä SOM Oy, ennen Suomen Optiomeklarit Oy, toimii johdannaismarkkinoilla kauppapaikkana ja selvitysyhtiönä. Työssä etsitään ratkaisuja edellä mainitun tiedon välittämiseen liittyviin ongelmiin. Perusongelma on, kuinka välittää tietoa johdannaisten hinnanmuutoksista samanaikaisesti useille eri vastaanottajille helposti hyväksikäytettävässä muodossa. Eniten kiinnitetään huomiota siihen, miltä ongelman ratkaisun pitäisi näyttää ratkaisua hyväksikäyttävän sovellusohjelmoijan kannalta. Myös valmiiden järjestelmien muihin ominaisuuksiin, kuten Vikasietoisuus ja suorituskyky, luodaan lyhyt katsaus. Työssä ei puututa käytännön ongelmiin kuten hinta, saatavuus, toimittajan luotettavuus ja taloudellinen tila, vaikkakin ne saattavat olla hyvin tärkeitä kriteereitä ongelman ratkaisua etsittäessä. Yksikäsitteisten vastauksien antaminen näihin kysymyksiin on lähes mahdotonta ja vastaukset saattaisivat vaihdella liiankin paljon eri arvioijien kesken. Lisäksi useimmat näistä vastauksista olisivat jo kirjoitushetkellä vanhentuneita.
Luvun 2 alussa luodaan lyhyt katsaus rahoitus- ja arvopaperimarkkinoihin. Myöhemmin esitetään tarkemmin, mitä ongelmia ajantasaisen hintatiedon välittämisessä esiintyy ja esitetään perusvaatimuksia ja kriteerejä, joilla näiden ongelmien mahdollisia ratkaisuja voidaan arvioida.
Luvussa 3 esitetään viisi erilaista ratkaisua näihin ongelmiin ja arvioidaan niitä edellä mainittujen vaatimusten ja kriteerien nojalla. Luvusta 4 eteenpäin esitellään oma ratkaisu näihin ongelmiin. Tästä ratkaisusta käytetään nimeä hintapalvelin. Luvussa 6 arvioidaan hintapalvelimen määrittelyä ja toteutusta kumpaakin erikseen näillä samoilla kriteereillä.
2. TIEDON JULKISTAMINEN RAHOITUSMARKKINOILLA
2.1. Taustaa
Kappaleen 2.1 tarkoituksena on esitellä lyhyesti rahoitusmarkkinoiden käsitteitä ja toimintamekanismeja. Muita markkinapaikkoja tarkemmin tarkastellaan Suomen johtavaa johdannaisten markkinapaikkaa SOM Oy:tä, jonka tarpeita työ pyrki täyttämään. Kappale on eräänlainen johdanto ongelman esittelylle, ja sillä pyritään helpottamaan ongelman asettelun ymmärtämistä. Rahoitusmarkkinoita hyvin tunteville lukijoille sen sisältö saattaa olla hyvinkin tuttua, joten kappaleen voi hypätä yli ja siirtyä suoraan kappaleeseen 2.2, jossa esitetään ongelman kuvaus.
Kappaleessa 2.3 esitetään vaatimuksia ja arviointikriteerejä, joiden avulla seuraavassa luvussa esiteltäviä valmiita ratkaisuja voidaan arvioida.
2.1.1. Rahoitusmarkkinat ja arvopaperimarkkinat [16]
tuottoa Korkoa, osinkoa
sijoituksia Oman tai vieraan
pääoman ehtoisia rahoitusta Pääoman
ylijäämää
Pääoman alijäämää Rahoitusmarkkinat
Kuva 2.1. Rahoitusmarkkinat
Rahoitusmarkkinoiden tärkein tehtävä on ohjata pääomia ylijäämäisiltä yksiköiltä alijäämäisille yksiköille mahdollisimman tehokkaasti, edullisesti ja luotettavasti (kuva 2.1). Lisäksi markkinoilla muodostetaan erilaisten sijoituskohteiden hintoja. Rahoitusmarkkinat määrittävät siten sijoittavan yleisön hallussa olevan omaisuuden arvoa. Rahoitusmarkkinat voidaan jakaa sijoitusten keston mukaan raha- ja pääomaniarkkinoihin. Rahamarkkinoiden sijoitusten kesto on yleensä alle vuosi ja pääomamarkkinoiden vastaavasti yli vuosi. Arvopaperimarkkinoiksi kutsutaan sitä osaa pääomamarkkinoista, jossa käydään kauppaa vaihdantakelpoisilla sijoituskohteilla. Toisin sanoen näillä sijoituskohteilla on tehokkaat jälkimarkkinat. Arvopaperimarkkinat voidaan jakaa myös rahoituksen luonteen mukaan oman ja vieraan pääoman ehtoisen rahoituksen markkinoihin (kuva 2.2).
Rahamarkkinat
< 1 vuosi
Pääomamarkkinat
> 1 vuosi
Arvopaperimarkkinat Oman pääoman ehtoisen rahoituksen markkinat
Vieraan pääoman ehtoisen rahoituksen markkinat
Kuva 2.2. Rahoitusmarkkinat osa-alueineen
Oman pääoman ehtoisassa rahoituksessa sijoittajalla on omistusosuus yhteisön varallisuuteen, mutta yhteisöllä ei ole velvollisuutta toiminta-aikanaan maksaa sijoitusta takaisin sijoittajalle. Sijoittajalle kuuluu sijoituksen mukainen osuus yhteisön varallisuudesta, jos yhteisö puretaan. Oman pääoman ehtoisen sijoituksen tuotto riippuu rahoitusta saavan yhteisön tuloksesta ja sijoitus oikeuttaa sijoittajan osallistumaan yhteisön päätöksentekoon.
Vieraan pääoman ehtoisia sijoituksia yhteisössä ovat erilaiset pitkä- ja lyhytaikaiset velat. Ne on maksettava yhteisön toiminta-aikana takaisin, yleensä joko vaadittaessa tai velan ehdoissa määrätyn ajan kuluttua. Yhteisön purkautuessa oman pääoman ehtoisen sijoituksen tehneet saavat varansa vasta, kun kaikki vieraan pääoman ehtoisen sijoituksen tehneet ovat saaneet sijoituksensa takaisin.
Osakkeet ovat merkittävin sijoituskohde oman pääoman ehtoisen rahoituksen markkinoilla. Samalla osakkeet kuuluvat myös pitkäaikaisen rahoituksen pääomamarkkinoille. Vieraan pääoman markkinoilla käytetään voimassaoloajaltaan vaihtelevia velkakirjoja. Nämä velkakirjat voivat olla kestoltaan kummankin eli raha- tai pääomamarkkinoiden sijoituskohteita. Keskuspankin ja talletuspankkien liikkeeseen laskemat sijoitustodistukset ja valtion liikkeeseen laskemat velkasitoumukset ovat merkittävimmät sijoituskohteet rahamarkkinoilla. Pääomamarkkinoilla sen sijaan kaupataan valtion, luottolaitosten ja yritysten liikkeeseen laskemia joukkovelkakirjalainoja.
Näistä yleensä vaihdetuimpia ovat valtion liikkeelle laskemat joukkovelkakirjalainat eli valtionobligaatiot.
Arvopaperimarkkinat voidaan myös jakaa sijoittajien ja kaupankäyntierien keskimääräisen koon mukaan vähittäis- ja tukkumarkkinoihin. Tukkumarkkinoille osallistuvien toiminta ja tarpeet voivat erota suurestikin vähittäismarkkinoille osallistuvien tarpeista. Yksi merkittävä ero on erilainen
informaation tarve. Arvopaperimarkkinoihin läheisessä yhteydessä ovat arvopapereiden johdannaismarkkinat, jossa käydään kauppaa johdannaissopimuksilla. Nämä sopimukset koskettavat arvopaperien luovuttamista tai tuoton jakoa tulevaisuudessa. Johdannaissopimukset tarjoavat markkinaosapuolille keinon suojautua arvopaperien kurssimuutoksia vastaan. Toisaalta osapuolet voivat myöskin pyrkiä hyötymään muutoksista johdannaisten avulla. Johdannaisista tunnetuimpia ovat optiot ja termiinit. Optiot takaavat ostajalle oikeuden, mutta ei velvollisuutta, ostaa tai myydä sopimuksen kohteena olevaa arvopaperia ennalta sovittuun hintaan ja aikaan. Termiinit ovat kumpaakin osapuolta sitova sopimus arvopaperin kaupasta ennalta sovittuun hintaan ja aikaan.
2.1.2. Markkinapaikka
Arvopapereita
Jälkimarkkkinat Pörssi-ja arvopaperivälittäjät
tai investointipankit järjestelijöini
Ensimarkkinat Koti-ja ulkomaiset
joukkovelkakirja-ja osakeannit
Pörssi ja arvopaperivälittäjät
Sijoittajat
Kuva 2.3. Ensi-ja jälkimarkkinat
Arvopapereita, kuten osakkeita tai velkakirjoja, laskevat liikkeelle valtiot, kunnat, yritykset tai muut osapuolet, jotka tarvitsevat varoja toimintansa rahoittamiseksi. Tätä arvopaperin ensimmäistä myyntitapahtumaa sijoittajalle kutsutaan ensimarkkinoiksi {primary markets). Näillä ensimarkkinoilla varoja siirtyy sijoittajilta vain alkuperäisille arvopaperin liikkeellelaskijoille. Siis kauppaa käydään vain uusilla arvopapereilla. Jo kerran liikkeellelasketuilla arvopapereilla käydään kauppaa jälkimarkkinoilla [9] (kuva 2.3). Kaupankäynnin aktiivisuus jälkimarkkinoilla vaihtelee runsaasti eri arvopaperien kesken. Niillä arvopapereilla, joilla jälkimarkkinat ovat vilkkaat, on markkinapaikkana usein pörssi. Pörssissä useat osapuolet tekevät kauppaa samoilla arvopapereilla ja, kun osapuolia on
paljon, hinnanmuodostus on usein tehokkaampaa kuin tapauksessa, joissa mahdollisia osapuolia on vähemmän. Tehokkaalla hinnanmuodostuksella tarkoitetaan usein sitä, että hinnat ovat aidosti kysynnän ja tarjonnan mukaan määräytyviä ja tehokkaasti kilpailtuja. Esimerkkinä tehottomasta hinnanmuodostuksesta on monopoli, jossa mahdollisia arvopaperia myyviä osapuolia on vain yksi eli myyjän tarjoama hinta ei ole kilpailtu ja hinta määräytyy muilla perusteilla kuin kysynnän ja tarjonnan mukaan.
Pörssit ovat perinteisesti toimineet paikoissa, joissa markkinaosapuolet ovat läsnä fyysisesti edustajiensa välityksellä. Nämä edustajat ovat ilmaisseet kiinnostuksensa arvopaperien ostamiseen tai myymiseen joko sanallisesti, elein tai muilla etukäteen sovituilla merkeillä. Näiden edustajien fyysinen läsnäolo on siis ollut välttämätöntä osapuolten kohtaamiseksi. Markkinaosapuolet ovat ilmaisseet mielenkiintonsa arvopaperin ostamiseen tai myymiseen välittäjälle, joka siirtää toimeksiannot näille markkinapaikalla oleville edustajille. Usein nämä edustajat tekevät kauppaa myös omaan lukuunsa eli ovat siis itse myös markkinaosapuolia. Tämä omaan lukuun toimiminen usein myös tehostaa markkinoiden toimintaa. Useissa maailman johtavissa pörsseissä käydään yhä kauppaa tällä perinteisellä tavalla. Sen muuttaminen on osoittautunut hyvin hankalaksi teknisten apuvälineiden kehityksestä huolimatta.
Monilla arvopapereilla, joilla pörssissä tapahtuva kaupankäynti ei ole kovin aktiivista, käydään kauppaa suoraan markkinaosapuolien välillä puhelimitse. Halusta ostaa tai myydä kerrotaan toisille osapuolille puhelimella, jolla syntyneet kaupat myös vahvistetaan. Esimerkkinä näistä mainittakoon suomalaisten pankkien välinen valtionobligaatio- ja rahamarkkinakauppa, jota käydään lähes kokonaan suoraan osapuolten välillä puhelimitse. Tosin useita hankkeita näiden markkinoiden siirtämisestä keskitetysti yhdelle markkinapaikalle on ollut vireillä.
Elektronisella markkinapaikalla osapuolet ilmaisevat yleensä kiinnostuksensa ostaa tai myydä arvopapereita syöttämällä osto- tai myyntitarjouksia markkinapaikan tietojärjestelmään. Kun eri osapuolet syöttävät järjestelmään samasta arvopaperista vastaavat osto- ja myyntitarjoukset, ne kohtaavat eli niistä syntyy kauppa, jossa nämä tarjouksen syöttäneet osapuolet ovat mukana ostajana ja myyjänä. Ohjelmaa, joka synnyttää kauppoja markkinaosapuolten tarjouksista, nimitetään usein elektroniseksi tarjouskirjaksi. Tätä tarjouskirjaa voisi kutsua markkinapaikan tietojärjestelmän ytimeksi. Tarjouskirja välittää tietoa syntyneistä kaupoista eteenpäin markkinaosapuolille erilaisten informaatiojärjestelmien kautta.
Näistä tiedoista ovat kiinnostuneita lähes kaikki arvopapereilla kauppaa käyvät tai jollain tavalla rahoitusasioiden kanssa tekemisissä olevat. Tulevaisuudessa syntyvien arvopaperikauppojen hintataso perustuu yleensä näihin markkinapaikoilta saatuihin tietoihin. Useimpien markkinaosapuolien on mahdotonta toimia ilman tosiaikaista markkinoilta tulevaa informaatiota. Yleensä kaikilta edellä mainituilta erilaisilta markkinapaikoilta saadaan tosiaikaista tietoa jonkinlaisen elektronisen
informaationjakelujärjestelmän kautta huolimatta siitä, käydäänkö markkinapaikalla kauppaa perinteisesti tai jonkinlaisen tietojärjestelmän kautta.
2.1.3. Suomen arvopaperi-ja johdannaismarkkinat
Suomen arvopaperimarkkinoiden tärkeimmät osa-alueet ovat osake-, raha- ja obligaatiomarkkinat.
Osakemarkkinoiden tärkein markkinapaikka on jo kauan ollut Helsingin Arvopaperipörssi Oy, joka aikaisemmin oli osuuskunta. Helsingin arvopaperipörssissä markkinaosapuolet käyvät kauppaa lähinnä osakkeilla eri arvopaperivälittäjien välityksellä. Välittäjinä voivat toimia joko pankit tai pankkiiriliikkeet; kauppaa käydään lähes kaikkien suurimpien suomalaisten yritysten osakkeilla. Raha- ja obligaatiomarkkinoilla käydään kauppaa lähinnä suurimpien pankkien välisillä interbank- markkinoilla.
Johdannaismarkkinat voidaan jakaa karkeasti kahteen kategoriaan: räätälöityjen sopimusten ja vakioitujen johdannaissopimusten markkinoihin. Räätälöityjä johdannaissopimuksia voivat esimerkiksi yritykset tehdä suoraan eri pankkien kanssa. Jälkimarkkinoiden puuttuessa hinnanmuodostus on usein tehotonta ja markkinoiden kokoa on vaikea arvioida. Vakioiduilla johdannaisilla käydään kauppaa johdannaispörsseissä, joita Suomessa on tällä hetkellä käytännössä kaksi: Suomen Optiopörssi Oy ja
SOM Oy. Näistä SOM pitää hallussaan valtaosaa markkinoista.
2.1.4. SOM
SOM Oy on vuonna 1987 perustettu arvopaperi- ja johdannaispörssi sekä selvitysyhtiö. SOM:n pääomistajia ovat suomalaiset pankit, pankkiiriliikkeet, vakuutusyhtiöt ja ruotsalainen OM Gruppen AB. SOM:n toimintaa valvoo rahoitustarkastus. Optio- ja termiinikaupankäyntiä sekä selvitystä säätelevät mm. laki kaupankäynnistä vakioiduilla optioilla ja termiineillä, arvopaperimarkkinalaki sekä valtiovarainministeriön vahvistamat SOM:n säännöt. SOM:n toiminnan osa-alueita ovat:
• kaupankäynti, selvitys ja hallinto,
• tietojärjestelmät,
• tuotekehitys, markkinointi, koulutus ja sijoitustutkimus.
Sijoittaja
Sijoittaja
Sijoittaja n
Välittäjä
-pankit -pankkiiriliikket
_
SOM
-kauppapaikka
“selvitys
Markkinatakaaj a
Kuva 2.4. SOM
SOM toimii optio- ja termiinikaupan kauppapaikkana eli pörssinä ja kauppojen selvittäjänä eli selvitysyhtiönä. Sijoittajat eivät asioi SOM:n kanssa suoraan, vaan heitä edustaa kaupankäynnissä välittäjä eli pankki tai pankkiiriliike. Välittäjällä on palveluksessaan meklareita eli toimihenkilöitä, jotka vastaanottavat toimeksiantoja sijoittajilta ja toteuttavat ne kauppapaikalla (kuva 2.4).
Käytännössä kauppaa käydään SOM:ssa seuraavasti: Sijoittaja antaa osto- tai myyntitoimeksiantonsa välittäjän meklarille, joka tallentaa osto- tai myyntitarjouksen SOM:n kaupankäyntijärjestelmään.
Järjestelmän tarjousrekisterissä tarjoukset asetetaan oikeaan etuoikeusjärjestykseen hinnan ja saapumisajan mukaan. Kahdesta samanhintaisesta tarjouksesta aikaisemmin saapunut asetetaan etusijalle. Kauppa syntyy, kun ostajan ja myyjän tarjoukset kohtaavat. Syntyneestä kaupasta informoidaan kaupan osapuolia. Kauppojen hinta- ja määrätiedot lähetetään eteenpäin julkisena markkinainformaationa, sen sijaan kauppojen osapuolitiedot eivät ole julkisia.
SOM asettuu jokaisessa kaupassa kaupan osapuolten väliin ostajaksi ja myyjäksi. Näin osapuolten kaikki oikeudet ja velvollisuudet kohdistuvat ainoastaan SOM:iin. Kaupan osapuolten ei tarvitse kiinnittää huomiota vastapuolen luottokelpoisuuteen tai maksuvalmiuteen. Toisaalta SOM:n aiheuttama vastapuoliriski poistetaan käytännössä kokonaan osapuolille asetetuilla vakuusvaatimuksilla. Jokaisen markkinaosapuolen on talletettava SOM:iin tai muulle hyväksytylle vakuudenhaltijalle (lähinnä Suomessa toimivat liikepankit) SOM:n määräämän vakuusvaatimuksen suuruinen summa rahaa. Vakuusvaatimus kuvastaa markkinaosapuolen tiliaseman mahdollista tappiota huonoimmassa mahdollisessa markkinatilanteessa. Tämä vaatimus lasketaan SOM:n vakuuslaskentajärjestelmällä päivittäin kaikille tiliasemille.
Välittäjien lisäksi markkinoilla toimii myös markkinatakaajia, joiden velvollisuutena on asettaa osto- ja myyntitarjouksia sovituille optioille ja termiineille. Markkinatakausjärjestelmällä pyritään
varmistamaan jälkimarkkinoiden hyvä likviditeetti ja tarjotaan markkinaosapuolille mahdollisuus sulkea tiliasemansa halutessaan. Tiliaseman sulkemisella tarkoitetaan kaikkien jo tehtyjen johdannaiskauppojen kumoamista tekemällä vastaavat, mutta päinvastaiset kaupat markkinoilla ja näin realisoida senhetkiset tappiot tai voitot. Markkinatakausjärjestelmä takaa sen, että kaikkia osapuolen tiliasemassa olevia johdannaisinstrumentteja voidaan aina ostaa tai myydä markkinoiden ollessa auki.
Markkinatakaajat tekevät kauppaa omaan lukuunsa. He eivät voi toimia välittäjinä. Markkinatakaajan voitto syntyy tämän takaamien instrumenttien osto- ja myyntihintojen erotuksesta. Markkinatakaajaksi ryhtymiseen houkuttelevat myös huomattavasti pienemmät markkinapaikan kaupankäyntipalkkiot.
2.2. Ongelman kuvaus
Tässä työssä tarkasteltava ongelma on, kuinka välittää tietoa sijoitushyödykkeiden hinnanmuutoksista samanaikaisesti useille eri vastaanottajille helposti hyväksikäytettävässä muodossa. Käytännössä samanaikaisuudesta voidaan puhua silloin, kun kukaan vastaanottajista ei ehdi hyötymään siitä, että hän saa tiedon hinnanmuutoksesta aikaisemmin kuin muut. Samanaikaisuutta pohdittaessa oletetaan, että eri vastaanottajat ovat yhtä nopeiden tietoliikenneyhteyksien kautta yhteydessä tiedon lähettäjään.
Varsinaisesti atomisen julkistuksen (atomic broadcast) [14, s.452-453] ongelmaa ei pyritä ratkaisemaan. Siinä tieto välitetään vastaanottajille vain, jos kaikki oletetut vastaanottajat kykenevät sen saamaan. Syynä tähän on se, että käytännön tilanteissa vastaanottajien määrä on niin suuri, että lähes aina joku vastaanottajista on vikaantuneen yhteyden takana. Ongelman kannalta tarpeeksi vikasietoisena ratkaisuna voidaan pitää sellaista, jossa kaikki vastaanottajat joko saavat tiedon, tai huomaavat yhteyden vikaantuneen. Tieto on helposti hyväksikäytettävässä muodossa silloin, kun se on helposti ymmärrettävää ja tallennettavissa jatkojalostusta varten. Ongelmaan on yritetty kehittää erilaisia ratkaisuja jo yli sadan vuoden ajan.
Perinteisesti markkinaosapuolien informaatiotarpeen tyydyttäjinä ovat toimineet lehdet, televisio tai muut vastaavat mediat. Yhä useammin on kuitenkin käynyt niin, että tiedon julkistamishetkellä tieto on jo vanhentunutta, sillä usein muuttuvan tiedon välittäminen joukkoviestimissä on lähes mahdotonta. Ne soveltuvatkin paremmin uutisluontoisten tapahtumien raportointiin. Tosin nämä tapahtumat ovat yleensä hyödykkeiden hinnanmuutosten syitä, joten niidenkin seuraaminen on usein tärkeätä. Tässä työssä emme kuitenkaan tarkastele tällaisen tiedon levitystä, vaan rajoitumme hyödykkeiden hintatiedon levitykseen. Tiedon ajantasaisuuden ongelmaan ovat ratkaisun tuoneet perinteiset fmanssitiedon välitysjärjestelmät, kuten Reuters, Telerate, Knight Ridder ja Bloomberg. Näissä järjestelmissä on ollut nopea yhteys suoraan tiedontuottajalle ja sen jatkeena katselusovellus, jolla haluttua tietoa voidaan seurata tietokoneen näytöllä reaaliajassa. Ne ovat yleensä olleet suljettuja järjestelmiä, joiden tietoa on voinut katsella vain tiedontuottajan omilla katselusovelluksilla ja muiden tuottajien tiedon seuraaminen toisten sovelluksilla on ollut mahdotonta. Usein tiedon vastaanottajien on ollut välttämätöntä seurata eri tiedontuottajien tietoa, koska eri tuottajat ovat erikoistuneet eri alueille ja
näin jokaista tiedontuottajaa varten on tarpeellista hankkia omat katselusovellukset ja jakelujärjestelmät. Näin on syntynyt turhia kustannuksia siitä, että käytännöllisesti katsoen samanlaiset fyysiset laitteistot ja ohjelmistot on joutunut hankkimaan jokaisen tiedontuottajan tietoa varten erikseen. Kaikkien eri tiedontuottajien samantyyppistä tietoa olisi voitava seurata yhdellä sovelluksella, jos niin halutaan.
Näiden järjestelmien liittäminen käyttäjän omiin tietojärjestelmiin on ollut vaikeata, ellei mahdotonta.
Järjestelmistä olisi voitava vastaanottaa tietoa käyttäjän omiin sovelluksiin, joissa tietoa voidaan jatkojalostaa ja mahdollisesti seurata tavoilla, jotka ovat mahdottomia tiedontuottajan omilla sovelluksilla. Toisaalta käyttäjän tietojärjestelmän olisi voitava syöttää järjestelmään tietoa, jota ei eri tiedontuottajilta ole saatavilla, kuten hintatietoa markkinapaikalta, johon käyttäjän tietojärjestelmästä on yhteys, mutta josta kukaan tiedontuottajista ei ole halukas tietoa välittämään.
Näiden ongelmien ratkaisemiseksi tarvitaan järjestelmä, jolla eri tiedontuottajien ja tiedon vastaanottajien järjestelmät voidaan yhdistää. Järjestelmän olisi hyvä taata tiedon virheetön siirtyminen kaikille tiedon vastaanottajille käyttäen parhaalla mahdollisella tavalla hyväksi käytössä olevat laskenta- ja tiedonsiirtoresurssit. Tiedon tuottajien ja vastaanottajien liittäminen järjestelmään olisi tehtävä niin helpoksi, että sovellusten kirjoittajien ei tarvitsisi tuntea järjestelmän sisäisen tiedonvälityksen mekanismeja. Tämän ongelman ratkaisemiseksi on alan teollisuudessa kehitelty erilaisia käsitteitä, joihin puututaan seuraavassa arviointikriteerejä esiteltäessä.
2.3. Vaatimuksia ja arviointikriteerejä
Jotta tarkasteltavissa oleva järjestelmä yleensä voisi olla ratkaisu ongelmaan, on sen täytettävä tietyt perusvaatimukset. Näinä perusvaatimuksina voidaan pitää seuraavia ominaisuuksia tai järjestelmän osia:
Tuottaja-rajapinta (TuoR).
Järjestelmään voidaan liittää eri tiedontuottajien informaatiolähteitä ja näin vastaanottaa järjestelmään kyseisen tuottajan tietoja. Tätä yhdistämistä varten on rakennettava yhdyskappaleena toimiva ohjelma, jota yleensä kutsutaan nimellä feedhcmdler. Tämän ohjelman rakentamiseksi järjestelmässä on oltava liittymäpinta, jonka avulla järjestelmään voidaan syöttää tietoa.
Kuluttaja-rajapinta (KulR).
Järjestelmään voidaan liittää sovelluksia, jotka vastaanottavat tietoa järjestelmästä. Tätä varten järjestelmässä on oltava liittymäpinta, jonka avulla järjestelmästä voidaan vastaanottaa tietoa.
Sijaintiläpinäkyvyys (SLäp).
Järjestelmässä olevaan tietoon viitataan sen nimellä (.subject-based addressing) eikä sen sijainnilla tai tuottajalla. Jos esimerkiksi haluaa kysyä jonkun tiedon arvon järjestelmältä, kysyjän ei tarvitse tietää, mikä palvelin osaa kyselyyn vastata, vaan kysytään tiedonjakelualustalta tietoa nimellä ja jakelualusta ohjaa kyselyn palvelimelle, joka on kertonut palvelevansa kyseiseen nimeen liittyviä kyselyitä.
Julkaistavan ja tilattavan tiedon yksilöimiseksi annetaan eri tietoalkioille ennalta sovitut tunnisteet eli nimet. Esimerkiksi, jos tilaaja haluaa ‘NOKAV’-arvopaperin tulevat parhaan ostohinnan muutokset itselleen niiden tapahtuessa, hän tilaa nämä muutokset jakelualustalta nimellä ‘NOKAV OSTO l ’.
Julkaisija käyttää samaa nimeä tuottaessaan tämän tiedon järjestelmään. Arvioitaessa ei kuitenkaan oteta kantaa siihen, millä tavalla asiakasohjelma voi arvioida tietyllä nimellä julkaistun tiedon luotettavuutta. Kaikissa järjestelmissä oletetaan siis, että kaikki tiedon julkaisijat ovat luotettavia.
Tilaaja/julkaisija-malli (T/J).
Järjestelmästä tietoa vastaanottava sovellus saa haluamansa tiedon muutokset järjestelmästä automaattisesti tarvitsematta kysellä jatkuvasti tiedon muutoksista. Toisin sanoen tiedon seuraaja voi tilata jakelualustalta jonkun tiedon tulevat muutokset itselleen. Tiedon tuottaja voi julkaista jakelualustalle tietoa sen nimen perusteella ja on siis velvollinen kertomaan kaikki kyseisen tiedon
muutokset jakelualustalle. Jakelualustan tehtävänä on välittää nämä muutokset kaikille tilaajille.
Tieto palvelun ajantasaisuudesta (TAjant).
Tiedon vastaanottaja on jatkuvasti tietoinen siitä, onko hänen seuraamansa tieto ajan tasalla. Toisin sanoen järjestelmä takaa tiedon muutosten saapumisen seuraajalle kohtuullisessa ajassa ja oikeassa järjestyksessä tai ilmoittaa seuraajalle yhteyden vikaantumisesta.
Tiedon puskurointi (Pusk).
Järjestelmä kerää eri osien puskurimuisteihin tietoa siten, että tietoa kysyttäessä vasteajat olisivat mahdollisimman lyhyitä, mutta tiedon turhaa säilyttämistä kumminkin pyrittäisiin estämään. Tämän ongelman ratkaisemiseksi on kehitetty useita tunnettuja algoritmeja, joihin palataan tarkemmin kuvattaessa hintapalvelimen toteutusta.
Tuki yhdistetyille lähiverkoille (TuYL).
Järjestelmän osien on voitava sijaita eri lähiverkoissa. Jotta järjestelmän kahden osan välinen yhteys toimisi, on niiden välillä oltava vähintään toimiva reititinyhteys.
Perusvaatimusten lisäksi voidaan myöskin määrittää erilaisia arviointikriteereitä, joilla eri ratkaisuja voidaan vertailla keskenään. Niitä vertailtaessa käytettiin seuraavia arviointikriteereitä:
Ensisijainen kriteeri oli Vikasietoisuus, koska mahdolliset käyttökatkot tai häiriöt saattavat aiheuttaa suuria kustannuksia järjestelmän käyttäjälle. Vikasietoisuutta tarkasteltaessa kiinnitettiin lähinnä huomiota ongelmiin tietoliikenneyhteyksissä, sillä järjestelmän kyky suojautua tieliikenneongelmilta
on ehkä sen tärkein vikasietoisuuteen vaikuttava ominaisuus. Toinen käytetyistä kriteereistä oli järjestelmän suorituskyky; tarkemmin sanoen arvioitiin, kuinka hyviä menetelmiä hyvän suorituskyvyn saavuttamiseksi oli käytetty. Tässä tapauksessa suorituskyvyn tärkeimpänä mittarina pidettiin järjestelmän vasteaikoja. Kolmantena kriteerinä oli turvallisuus. Lähinnä tutkittiin sitä, miten järjestelmän osat voivat tahallaan tai tahattomasti aiheuttaa häiriötä muille järjestelmän osille. Näistä häiriöistä kiinnitettiin eniten huomiota tilanteeseen, jossa vikaantunut tai vihamielinen asiakasohjelma tekee toistuvia kyselyjä järjestelmälle kuormittaen sitä niin, että muiden asiakasohjelmien palvelu on joko estynyt tai merkittävästi hidastunut.
Näitä kriteerejä arvioitaessa kiinnitettiin lähinnä huomiota siihen, minkälaisia menetelmiä edellä mainittujen ominaisuuksien saavuttamiseksi oli käytetty. Syynä tähän oli se, että vertailu oli luonteeltaan enemmänkin kirjallisuustutkimus kuin järjestelmien kenttätesti todellisessa ympäristössä.
3. INFORMAATION JAKELUALUSTAT
Tämän luvun tarkoituksena on hieman valottaa eri informaatiojakelualustojen toimintaa ja ominaisuuksia käyttäen arviointikriteereinä vikasietoisuutta, suorituskykyä ja turvallisuutta.
Tarkoituksena ei ole ollut vertailla näitä eri tuotteita parhaan löytämiseksi, vaan käyttää vertailun tuloksia lähinnä apuna hintapalvelimen toteutuksessa. Ensin jokaista kuvattaessa kerrotaan järjestelmän tyypillisimmät piirteet ja jokaisen kuvauksen lopussa arvioidaan järjestelmän toteutusta. Seuraavissa luvuissa törmätään usein käsitteisiin broadcasting ja multicasting. Näitä käsitteitä käytetään usein, kun keskustellaan erilaisten ryhmien sisäisestä tiedonvälityksestä, ja lähinnä siitä tapauksesta, kun halutaan lähettää sama viesti kaikille ryhmän muille jäsenille. Itse asiassa eri informaatioalustojen päätehtävänä on välittää tietoa samanaikaisesti järjestelmän muille osille. Käytännön ratkaisuissa lähetykset usein kohdistuvat vain osalle järjestelmän osista, mutta jos tietystä tiedosta kiinnostuneita voidaan pitää yhtenä ryhmänä, jolle halutaan lähettää sama viesti tiedon muuttuessa, ja koko järjestelmää erilaisten ryhmien joukkona, voidaan kirjallisuudessa esitettyjen seikkojen ja käytännön terminologian välillä havaita analogiaa. Kirjallisuudessa [14, s. 447] käsitteitä usein käytetään hieman eri merkityksessä kuin seuraavissa osissa. Tutkittujen järjestelmien dokumentoinnissa ne ovat yleensä seuraavat:
broadcasting - välitetään kaikille samassa verkossa tai aliverkossa oleville kuuntelijoille tieto yhdellä loogisella I/O-toiminnolla.
multicasting - välitetään kaikille samassa verkossa tai aliverkossa oleville kyseisestä tiedosta kiinnostuneille kuuntelijoille tieto yhdellä loogisella I/O-toiminnolla.
3.1. Reliable Transaction Router (RTR)
Digital Equipment Corporationin Reliable Transaction Router (RTR) [13] tarjoaa kehittäjälle sovelluskehitysrajapinnan (API) hajautettujen sovellusten kehitykseen. Sen tärkeimmät palvelut ovat
’kaikki tai ei mitään’ transaktiosemantiikka ja tiedonjulkistus (multicasting). ’Kaikki tai ei m itään’- transaktiosemantiikalla tarkoitetaan sitä, että kun tapahtuman suorittamisessa on mukana useita osapuolia, voidaan niiden lähettämien viestien avulla varmistua koko tapahtuman suorittamisesta loppuun asti tai sopia koko tapahtuman peruuttamisesta. Semantiikan toteutuksessa on käytetty 'two phase commit'-menetelmää. RTR:n suunnittelussa ja ohjelmoinnissa noudatetaan kolmikerroksista asiakas/reitittäjä/palvelin -mallia (Client/Router/Server). Asiakastason ohjelmat kutsuvat asiakastason palveluja API:n kautta. Asiakastason palvelut siirtävät pyynnöt reitittäjäkerrokselle, joka pyynnön sisällön mukaan siirtää ne asianmukaiselle palvelulle palvelinkerroksella. Palvelin tyypillisesti
toteuttaa pyynnön ja palauttaa vastauksen asiakastason ohjelmalle. Yhdessä fyysisessä laitteistossa voi sijaita useampi kuin yksi RTR-kerros. Kukin kerros voi koostua useasta fyysisestä laitteistosta.
Asiakasohjelman ei tarvitse tietää, sijaitseeko hänen haluamaansa palvelua vastaava palvelin samassa tai eri laitteistossa. Pyynnön reitittämisen oikealle palvelimelle hoitaa reitittäjäkerros. Palvelimen sijainti järjestelmässä vaikuttaa lähinnä vain asiakasohjelman havaitsemaan viiveeseen. Tämä lähestymistapa mahdollistaa sen, että asiakasohjelmistot voivat olla riippumattomia laitteistotyypistä, verkon rakenteesta tai käytetystä tiedonsiirtoprotokollasta. RTR:n pääasiallisia käyttökohteita ovat ympäristöt, missä tarvitaan luotettavaa tapahtumankäsittelyä ja viestinvälitystä, kuten pörssien tai pankkien reaaliaikaiset kaupankäyntijärjestelmät.
Arviointi
RTR tarjoaa rajapinnat tiedon syöttämiseen ja vastaanottamiseen järjestelmästä. Rajapintojen käyttö on työläämpää kuin uusimmissa ratkaisuissa johtuen niiden matalasta abstraktiotasosta. RTR on ensimmäisiä järjestelmiä, jossa oli toteutettu aiheeseen perustuva multicasting eli sovellus kertoo järjestelmälle, mitä viestejä hän haluaa kuunnella, ja järjestelmä lähettää sille vain ne. Asiakasohjelman ei tarvitse tietää, mikä palvelin kyseistä palvelua tarjoaa, vaan hän pyytää tietoa sille sovitulla nimellä.
RTR:ssä käytetään kuitenkin nimen sijasta termiä mask. Toisaalta järjestelmä ei takaa multicast- viestien perillemenoa eikä saapumista oikeassa järjestyksessä vastaanottajalle. Viestien perillemenon tai ilmoituksen vikaantumisesta se takaa vain transaktioissa. RTR ei myöskään tarjoa tiedon puskurointia vasteaikojen lyhentämiseksi. Kaikki kyselyt menevät aina tietoa tuottavalle palvelimelle asti ja näin vasteajat saattavat kasvaa huomattavasti, jos kyselyn reitillä on hitaampia tietoliikenneyhteyksiä. Järjestelmän osat voivat sijaita myöskin eri lähiverkoissa. Seitsemästä perusvaatimuksesta RTR täyttää siis vain viisi (TuoR, KulR, SLäp, T/J, Tu YL).
RTR:ssä on käytetty useita menetelmiä hyvän vikasietoisuuden saavuttamiseksi. Nämä ominaisuudet on toteutettu lähinnä RTR:n reitittäjä- ja palvelintasoilla. RTR:ssä reititystehtävää voidaan asettaa suorittamaan useita eri fyysisiä laitteistoja, jolloin yhden tai useamman reititystä hoitavan laitteiston vikaantuminen ei välttämättä estä tapahtumien tai julkistusten reitittämistä oikeille vastaanottajille.
Palvelintason vikasietoisuutta lisää mahdollisuus käyttää useita rinnakkaisia palvelimia saman palvelun aikaansaamiseksi, jolloin vikaantumistapauksissa palvelu voi mahdollisesti jatkua. Samalla voidaan parantaa järjestelmän suorituskykyä myös normaalitapauksissa, jolloin ominaisuutta voidaan käyttää kuormituksen jakamiseen eri laitteistojen tai järjestelmän osien välillä. RTR mahdollistaa myös varjopalvelimien (shadow server) käytön, jolloin palvelimen vikaantuessa sille asetettu varjopalvelin on valmiina jatkamaan palvelua välittömästi. Varjopalvelimen tila on periaatteessa sama kuin vikaantuneen palvelimen, jolloin palvelu voi jatkua ilman merkittävää viivettä. RTR:n vikasietoisuutta parantavat ominaisuudet hyödyttävät eniten tapahtumankäsittelyssä, mutta julkistuksissa yhä suurin ongelma on se, että tiedon perillemenoa tai vikaantumisen havaitsemista ei voida taata. Tällöin
vikasietoisuudesta saatava hyöty osittain menetetään, kun vastaanotettavan tiedon tilasta ei voida olla varmoja.
Edellä mainituilla rinnakkaisuuteen liittyvillä ominaisuuksilla on mahdollista parantaa myös järjestelmän suorituskykyä. Yleensä järjestelmän suorituskykyyn vaikuttaa suuresti palvelimien kyky palvella nopeasti asiakasohjelmia. Rinnakkaisten palvelimien avulla on mahdollista lisätä tätä nopeutta.
Järjestelmän nopeus siirtää tietoa sisällään osoittautuu harvoin pullonkaulaksi, paitsi tilanteissa, joissa järjestelmä sisältää hitaita tietoliikenneyhteyksiä. Näissä tapauksissa liikkuvaan tietoon liittyvä pienehkö määrä otsikkotietoa ei ole järjestelmän toimintaa oleellisesti hidastava tekijä. Tiedon puskuroinnin puute saattaa hitaiden tietoliikenneyhteyksien tapauksessa olla järjestelmää hidastava tekijä.
RTR ei sisällä palvelimien tai asiakasohjelmien tahallista tai tahatonta häiriökäyttäytymistä estäviä ominaisuuksia. Asiakasohjelmat voivat esimerkiksi tukkia järjestelmän lähettämällä palvelimille suuria määriä tapahtumia nopeasti peräkkäin. Normaalisti toimiville asiakasohjelmille ei voida siis taata tiettyä palvelutasoa, jos joku tai jotkut asiakasohjelmat häiritsevät järjestelmää ylikuormittamalla sitä.
3.2. Invision
Invision (Quay Financial Software Limited) [7] on tiedontuottajista ja laitteistotyypistä riippumaton reaaliaikaisen informaation jakelujärjestelmä, joka tarjoaa palvelut muuttuvan fmanssitiedon välittämiseen tiedonsiirtoverkossa. Se on myös tiedon esittämisjärjestelmä, jonka pääasiallisia käyttökohteita ovat reaaliaikaiset kaupankäyntijärjestelmät. Invision mahdollistaa myös tiedon vastaanottamisen useilta tiedontuottajilta yhteen järjestelmään, tiedon käyttäjille jakelun kontrolloimisen, esitystavan muuttamisen halutuksi ja tiedon käsittelyn omilla sovelluksilla. Invision tarjoaa myös suuren joukon asiakaspään sovelluksia välitetyn tiedon seurantaan ja analysointiin, kuten päätöksenteon tukijärjestelmiä.
Järjestelmä perustuu yleisimpien laitteisto-, ohjelmisto- ja verkkostandardien ja ratkaisujen käyttöön.
Tämä lisää järjestelmän riippumattomuutta laitteisto- ja ohjelmistotoimittajista. Myös järjestelmän palveluiden integrointi asiakkaan olemassa olevaan tietojärjestelmään helpottuu. Samalla tarve laiteinvestointeihin vähenee, sillä Invision-järjestelmät voivat toimia samassa tiedonsiirtoverkossa kuin asiakkaan järjestelmät, ja loppukäyttäjän Invision-sovellukset voivat toimia esimerkiksi samassa PC:ssä kuin asiakkaan omat sovellukset.
Avoin järjestelmäarkkitehtuuri mahdollistaa tiedon vastaanottamisen Invision-järjestelmään mahdollisimman monilta tiedontuottajilta ja tiedon syöttämisen useisiin eri toimittajien loppukäyttäjän sovelluksiin useilla eri tavoilla. Kun tieto on vastaanotettu Invision-järjestelmään, pyrkii se siirtämään tietoa loppukäyttäjille tavalla, joka minimoi ulkoisen tiedon vastaanottomäärät ja näin vähentää asiakkaan tiedonsiirtokustannuksia. Tässä erilaiset tiedon puskurointimenetelmät ovat tärkeitä. Samalla tärkeitä ovat käyttäjäystävälliset liittymät järjestelmän palveluihin. Ne tarjoavat useita eri tapoja loppukäyttäjälle ja asiakkaan omille kehittäjille käyttää järjestelmän palveluja jopa ilman perinteistä ohjelmointia.
Ulkoinen tietolähde
Ulkoinen tietolähde
Palvelu- linkki
Palvelu- linkki
Palvelu- linkki
Lähiverkko
Työasema Työasema
Kuva 3.1. Invision arkkitehtuuri
Invision-järjestelmän arkkitehtuuri perustuu työasemista ja palvelulinkeistä (.service gateway) koostuviin lähiverkkoihin (.Local-Area Network, LAN) (kuva 3.1). Palvelulinkit hallitsevat yhteyksiä ulkoisiin tietolähteisiin ja välittävät niiltä saapuvaa tietoa Invision-järjestelmään. Työasemat tarjoavat palvelut tiedon seuraamiseen ja edelleenkäsittelyyn. Useita mainituntyyppisiä verkkoja voi olla järjestelmässä yhdistettynä toisiinsa sillalla ja nämä verkot voivat käyttää toistensa Invision-palveluja
useilla eri tavoilla (kuva 3.2).
Sijaintipaikka 1
Sijaintipaikka 2
Kuva 3.2. Invision-järjestelmät
Invision arkkitehtuuri perustuu asiakas/palvelin-malliin käyttäen hyväksi rinnakkaisen ja hajautetun laskennan menetelmiä. Sovellusten välinen tiedonsiirto on kahdenvälistä ja yhteydellistä. Näin pystytään helpommin havaitsemaan mahdolliset fyysiset häiriöt tiedonsiirtoyhteyksissä ja palvelujen tarjoaminen kaukoverkoilla {Wide-Area Network, WAN) on käytännöllisempää.
Invisionin arkkitehtuurissa on käytetty useita eri menetelmiä vikasietoisuuden ja luotettavuuden takaamiseksi. Kriittisin piste Invision-järjestelmän toiminnan kannalta ovat palvelulinkit. Yhteen palvelulinkkiin voidaan yhdistää useampia yhteyksiä ulkoisesta tietolähteestä, jolloin yhden yhteyden katketessa yhteys tietolähteeseen todennäköisemmin säilyy. Useamman yhteyden toimiessa voidaan kuormaa jakaa useamman linjan kesken ja näin parantaa suorituskykyä. Varsinainen palvelulinkki voidaan myös jakaa useammalle fyysiselle keskusyksikölle, jotka toimivat yhteistyössä lähiverkon sisällä ja muodostavat yhden loogisen palvelun. Näin yhden keskusyksikön vioittuminen ei estä kyseisen palvelulinkin toimintaa. Invision-järjestelmän asiakaspää voidaan asettaa ottamaan yhteys automaattisesti uuteen palvelimeen käytetyn vioituttua. Samalla voidaan jakaa myöskin palvelun aiheuttamaa kuormaa useamman keskusyksikön kesken.
Asiakaspäät lähettävät säännöllisin aikavälein ns. heartbeatsiestiä kaikille palvelulinkeille, joihin ne ovat yhteydessä. Näin ollen palvelulinkin vioittuminen havaitaan aina viimeistään tämän aikajakson kuluttua, jolloin asiakassovelluksen käyttäjiä voidaan informoida menetystä yhteydestä. Järjestelmä yrittää aina havaitun katkoksen jälkeen automaattisesti uutta yhteyttä palvelulinkkiin ja uuden
yhteyden synnyttyä asiakaspään tieto päivitetään ajantasaiseksi ja syntyneestä yhteydestä tiedotetaan asiakassovelluksen käyttäjälle.
Invision toimittaa useita sovelluksia asiakaspäähän tiedon vastaanottamiseen ja analysointiin. Tämän lisäksi tarjotaan useita tapoja käyttää hyväksi järjestelmän välittämää tietoa:
• Dynamic Data Exchange (DDE) sallii kaksisuuntaisen tiedonvälityksen ohjelmille, jotka toimivat joko MS-Windows, MS-Windows NT, MS-Windows 95 tai OS/2 ympäristössä. DDE:tä tukevat ohjelmat voivat vastaanottaa reaaliaikaista tietoa Invision-järjestelmästä. Näistä esimerkkinä mainittakoon reaaliajassa päivittyvät taulukkolaskimen taulukot. Invision-järjestelmälle voidaan myöskin lähettää tietoa DDE:n välityksellä joko näytettäväksi tai edelleen välitettäväksi. DDE- linkkien käyttöä helpottaa mahdollisuus kopioida linkkejä suoraan Invisionin omista näytöistä muihin ohjelmiin leikkaa/liimaa-menetelmällä.
• Sovellusohjelmointirajapinnat (API) tarjoavat mahdollisuuden tiedon lähettämiseen Invision- järjestelmään ja tiedon vastaanottamiseen Invision-järjestelmästä omissa sovelluksissa. Samalla SQL tietokantatuki sallii päivittyvän tiedon siirtämisen automaattisesti haluttuun SQL-tietokantaan Invision-järjestelmästä. Käytännöllinen esimerkki ominaisuudesta on tietyn hyödykkeen historiallisen hintakehityksen keräämisessä tietokantaan.
• Invision makrokieli mahdollistaa Invision-järjestelmän palvelujen muokkaamisen omaan käyttöön sopivaksi. Makroilla voidaan automatisoida järjestelmän toimintoja ja käsitellä järjestelmän välittämää tietoa useilla eri tavoilla. Niitä voidaan käyttää myös tiedon välittämiseen järjestelmän sisällä palvelusta toiseen.
Arviointi
Invision-järjestelmään on valmiiksi saatavana useimpien suurten tiedontuottajien tietoa vastaanottavat palvelulinkit, joita edellisessä luvussa kutsutaan myös nimellä 'feedhandler'. Myöskin omien palvelulinkkien rakentaminen on mahdollista niitä tiedontuottajia varten, joille sitä ei ole valmiiksi kirjoitettu. Näiden palvelulinkkien rakentamista varten Invision-järjestelmässä on API, jonka välityksellä tietoa järjestelmään syötetään. Vastaava API on saatavilla myös niitä varten, jotka haluavat rakentaa ohjelmia, jotka vastaanottavat järjestelmästä tietoa. Invision-järjestelmässä asiakasohjelman on tiedettävä, mikä palvelin haluttua palvelua tarjoaa. Asiakasohjelman pitää ottaa erikseen yhteys kaikkiin palvelimiin, joiden palveluja se haluaa käyttää ja palvelimen on erikseen välitettävä tieto kaikille sitä haluaville asiakasohjelmille. Vaatimus palvelun sijaintiläpinäkyvyydestä jää siis toteutumatta. Invision ei myöskään toteuta aiemmin mainittua tilaaja/julkaisija-mallia. Invision takaa kuitenkin joko tiedon siirtymisen vastaanottajalle tai tiedon siirtotien vikaantumisesta asetetussa ajassa vastaanottajalle ja lähettäjälle. Palvelulinkkien rakentamiseen käytetty API huolehtii tiedon puskuroinnista vastaten useimmiten tuleviin kyselyihin suoraan puskurimuistista. Näin kyetään
lyhentämään useimpien palvelujen vasteaikaa. Myös eri lähiverkossa sijaitsevan palvelun käyttö on mahdollista. Invision täyttää perusvaatimuksista siis viisi (TuoR, KulR, TAjant, Pusk, TuYL).
Invision-järjestelmässä Vikasietoisuus hoidetaan lähinnä palvelulinkeillä. Mahdollisuus ottaa useita yhteyksiä palvelulinkistä tiedontuottajaan mahdollistaa palvelulinkin toiminnan jatkamisen, vaikka osa yhteyksistä tiedontuottajaan vikaantuisi. Samaa ominaisuutta voidaan käyttää myös suorituskyvyn parantamiseksi jakamalla kuormaa eri linjoille. Toisaalta se, että asiakasohjelman on itse havaittava palvelun toimimattomuus ja otettava yhteys etukäteen määriteltyyn vaihtoehtoiseen palvelulinkin laitteistoon, monimutkaistaa asiakasohjelmien hallintaa ja luontia. Järjestelmän suorituskykyä voidaan parantaa jakamalla palvelulinkkejä useammille fyysiselle laitteistolle. Palvelulinkkien jakoa voidaan myös käyttää vikasietoisuuden parantamiseksi. Järjestelmä ei kuitenkaan automaattisesti tasaa kuormaa eri laitteistojen välillä, vaan asiakasohjelmille etukäteen määrätään, mihin laitteistoihin ne ovat yhteydessä. Palvelujen lisääminen dynaamisesti voi siis olla melko hankalaa.
Invision sisältää ominaisuuksia, joilla voidaan jonkin verran estää järjestelmän asiakasohjelmien aiheuttamaa tahatonta tai tahallista häirintää. Palvelulinkit ovat kiinni järjestelmässä ODS-rajapinnan (Object Distribution System) kautta. Sen tehtävänä on tarkistaa asiakasohjelmien oikeuksia palvelun käyttöön ja jakaa palvelua etukäteen määriteltyjen prioriteettien mukaan eri asiakasohjelmille kilpailutilanteissa.
3.3. OpenTrade Platform
OpenTrade Platform (Management Technologies Inc.) [4, 11] on tiedonjakelualusta talousalan sovelluksille. Sen tarkoituksena on jakaa tietoa sovelluksille, joilla seurataan, käsitellään tai tallennetaan finanssi-informaatiota. Järjestelmä toteuttaa sovellusten vaatiman tiedonjakelun hajautetussa ja maantieteellisesti laajassakin ympäristössä. Järjestelmän perusperiaatteena on tilaaja/julkaisija-malli, jossa tiedon julkaisijat tuottavat tietoa järjestelmään ja tiedon tilaajat vastaanottavat haluamansa tiedon järjestelmästä. OpenTrade-järjestelmä huolehtii tiedon siirtämisestä tietolähteiltä eli julkaisijoilta kiinnostuneille osapuolille eli tilaajille mahdollisimman hyvin käytettävissä olevia resursseja hyödyntäen. Jakelualustalta voidaan myös yksinkertaisesti kysyä halutun nimen sen hetken arvo tilaamatta tulevia muutoksia. Kun tietoa kuljettavat tietorakenteet suunnitellaan tarpeeksi yleiskäyttöisiksi, ei tilaaviin ohjelmiin tarvitse tehdä muutoksia tai uudelleenkäynnistyksiä, kun liitetään jakelualustaan uusia tiedon julkaisijoita.
Sovellusohjelman ja Opentrade-järjestelmän välinen ohjelmointirajapinta on nimeltään OpenTrade APL Sen tarkoitus on tehdä sovelluksen liittäminen jakelualustaan käytännölliseksi ja peittää
toteutuksen sovellusohjelmoijan kannalta epäoleelliset yksityiskohdat sisäänsä. Samalla jakelualusta takaa tiedon perille tulemisen tai ilmoituksen vikaantumisesta. API tarjoaa kaksi erityyppistä jakelumallia: OpenTrade Transaction Highway tarjoaa kaksisuuntaisen viestiliikenteen tiedon tuottajien ja julkaisijoiden välillä. Tapahtumat voidaan jakaa yhdeltä lähettäjältä usealle vastaanottajalle ja riippuen tapahtuman kokonaismenestyksestä voivat vastaanottajat suorittaa asiaankuuluvat toimenpiteet, kuten start, end, prepare, commit, rollback, ja recover. Toinen on tilaaja/julkaisija-malli, johon tässä luvussa erityisesti kiinnitetään huomiota.
Sovellukset voivat käyttää kumpaakin jakelumallia samanaikaisesti, mutta tieto, joka on tuotettu yhteen jakelumalliin ei ole käytettävissä toisessa jakelumallissa, ellei sitä tuoteta sinne erikseen. Eri jakelumallit eivät siis jaa tietoa keskenään. Sovellukset voivat API:a hyväksikäyttäen:
• viitata tietoon sille sovitulla nimellä,
• pyytää ja vastaanottaa noteerauksia,
• vastaanottaa muuttuvat noteeraukset automaattisesti,
• vastata kyselyihin,
• lähettää noteerauksia,
• vaihtaa viestejä toisten sovellusten kanssa,
• lähettää paluuvasteita mahdollistaen tapahtumaorientoituneen keskustelun,
• synnyttää järjestelmänhallintaviestejä sekä
• määrittää sovellusmuuttujia ja resursseja, joita voidaan dynaamisesti hallita.
OpenTrade:iin on myös saatavilla suuri joukko valmiita sovelluksia tiedon seuraamiseen. Näitä ovat TradeWizard (tiedon esitys- ja analysointisovellus), FxCalcNet (tiedon jalostus- ja esityssovellus), Extra (tukisovellus sähköiseen kaupankäyntiin sisältäen tarjousten syötön ja hallinnan, päätöksenteon tukitoiminnot, tosiaikaisen position- ja riskinhallinnan). Kaikki mainitut sovellukset on toteutettu käyttäen OpenTrade API:a rajapintana järjestelmään.
Arviointi
OpenTrade-järjestelmään, kuten useimpiin muihin vastaaviin, on saatavissa useimpien tiedontuottajien valmiit liittymät. Oman tiedon syöttämistä varten järjestelmässä on julkaisijan APL Samoin tiedon vastaanottamista varten on vastaava tilaajan API. Näin ollen OpenTrade täyttää kaksi ensimmäistä vaatimusta. Kaikkeen järjestelmästä saatavaan tietoon viitataan nimellä eikä sen sijainnilla. Tiedon julkaisijat kertovat tiedon muutoksista vain kertaalleen järjestelmälle, joka hoitaa tiedon siirtämisen kaikille kyseisen tiedon tilaajille. Tiedon vastaanottaja on myöskin jatkuvasti tietoinen seuraamansa tiedon oikeellisuudesta. Toisin sanoen tilattava tieto vastaanotetaan sovitun ajan kuluessa tai yhteyden vikaantumisesta tiedotetaan vastaanottajalle. Suorituskyvyn parantamiseksi OpenTrade-järjestelmässä
käytetään erilaisia tiedon puskurointialgoritmeja. Näin kyselyiden vasteaikoja on saatu lyhennettyä.
OpenTrade-järjestelmässä järjestelmän osat voivat sijaita eri lähiverkoissa, joten viimeinen vaatimus toteutuu. OpenTrade täyttää siis kaikki perusvaatimukset (TuoR, KulR, SLäp, T/J, TAjant, Pusk, TuYL).
OpenTrade-järjestelmässä voidaan vikasietoisuutta lisätä käynnistämällä useita rinnakkaisia palvelimia saman tiedon julkaisijaksi. Näin palvelimen vikaantuminen ei välttämättä lopeta sen julkaisemien tietojen tilauksia, vaan OpenTrade-järjestelmä vastaanottaa julkaistun tiedon näiltä rinnakkaisilta palvelimilta. Asiakasohjelman ei tarvitse osallistua tähän tapahtumaan, vaan se saa tiedon vikaantumisesta vasta, kun kaikki tiedon julkaisijat ovat vikaantuneet tai tiedon saapuminen on hidastunut niin paljon, että se ei ole enää ajantasaista. Näin ollen palvelimien lisääminen dynaamisesti järjestelmään on helpompaa eikä asiakasohjelmien tarvitse tietää rinnakkaisista palvelimista.
Käytettävyyttä lisää myöskin se, että järjestelmä takaa julkaistun tiedon saapumisen tilaajille tai tiedon vikaantumisesta. Tämä on hoidettu ns. /leartieat-viesteillä, joita järjestelmä lähettää asiakasohjelmille.
Markkinainformaatio-järjestelmille olennainen tieto informaation ajantasaisuudesta on siis taattu.
Tärkein järjestelmän suorituskykyä parantava ominaisuus on tiedon puskurointi. Asiakasohjelmien kyselyt eivät siirry palvelimille asti, mikäli niihin voidaan vastata suoraan puskurimuistista. Toisaalta palvelimien ei tarvitse pitää yllä tietoa, vaan riittää, että ne kertovat aina tiedon muuttuessa järjestelmälle muutoksesta ja järjestelmä pitää yllä siihen julkaistun tiedon ja sen tilan. Puskurimuistin täyttyessä korvattavan tiedon valintaa voidaan ohjata asetettavilla parametreillä. Näitä voivat olla esim.
tiedon tärkeys, ikä tai tilausten määrä. Hitaita tietoliikenneyhteyksiä käytettäessä saattaa järjestelmän suorituskykyä laskea liikkuvan tiedon suuri määrä. Asiakasohjelmille siirtyvä tieto sisältää myöskin kuvauksen sen esitystavasta ja siksi siirtyvän tiedon määrä saattaa olla suuri. Tiedon esitystavan kuvauksen liikkuminen mukana on toisaalta kuitenkin niin hyödyllistä, että siitä aiheutuva hitaus voidaan usein hyväksyä, varsinkin kun tiedon siirtonopeudet kasvavat jatkuvasti.
Asiakasohjelmien aiheuttamaa tahatonta tai tahallista häirintää vähentää se, että kyselyt eivät aina mene palvelimille asti, vaan järjestelmä vastaa niihin puskurimuistista. Puskurimuistin kuormittaminen toistuvilla kyselyillä on siis mahdollista, mutta tämä häiriö ei näy niin voimakkaasti palvelimilla.
3.4. Reuters Triarch
Reuters Triarch (Reuters Ltd) [12] on joukko tuotteita, jotka on suunniteltu käytettäväksi informaation jakeluun, seuraamiseen ja käsittelyyn arvopaperien markkinapaikalla avoimessa järjestelmäympäristössä. Triarchin ydin on SSL {Source Sink Library) infrastruktuuri, joka tarjoaa
järjestelmän tiedonjakelutoiminnot verkkoympäristössä. SSL varmistaa luotettavan tiedonsiirron eri sovellusten välillä tarjoamalla tiedon välittämiseen ohjelmistokomponentit, joilla tiedon siirtyminen kaikille vastaanottajille voidaan varmistaa, tai joilla häiriötilanteesta saadaan tieto asetetun ajan kuluessa. Rajapintana SSL infrastruktuurin ja sovellusten välillä on SSL APL Myöskin Triarch noudattaa tilaaja/julkaisija-mallia, jossa lähdesovellukset voivat julkaista järjestelmään haluamaansa tietoa, joka on eri vastaanottajasovellusten tilattavissa riippuen niiden oikeuksista kyseisen tiedon vastaanottamiseen. Käsiteltävään tietoon viitataan nimellä, joten tilaavat sovellukset eivät tarvitse tietoa siitä, kuka tietoa julkaisee ja päinvastoin. Uusien sovellusten liittäminen järjestelmään ei myöskään vaikuta jo toiminnassa oleviin sovelluksiin muuten kuin, että tilattavien nimien määrä saattaa vaihdella uusien tai poistuvien julkaisijoiden myötä. Samaa tietoa järjestelmään tuottavia julkaisijoita voi olla useita, jolloin yhden julkaisijan vikaantuminen ei välttämättä katkaise sen julkaisemien nimien tilauksia. SSL tarjoaa myös mahdollisuuden tehdä kyselyitä julkaisijoille. Jos samaa tietoa julkaisee useampi kuin yksi julkaisija, SSL ohjaa kyselyn julkaisijalle, jolle ohjattuna kysely tulee tehokkaimmin suoritetuksi. Kyselyn ohjautuminen tietylle julkaisijalle voi johtua esimerkiksi sen sijainnista verkossa, julkaisijan puskurimuistista, kuormituksesta tai etukäteen ohjelmoiduista prioriteettisäännöistä. Julkaisijasovellus voidaan esimerkiksi käynnistää varajärjestelmäksi, jolloin kyseinen julkaisija vastaa kyselyihin vain silloin, kun muut samaa tietoa julkaisevat sovellukset ovat vikaantuneet.
Tiedontuottaja
Lähdesovellus (Source)
SSL Infrastructuuri (Triarch)
SSL API SSL API Vastaanottaja
sovellus (Sink)
Hybridisovellus (Hybrid) Tietokanta
Kuva 3.3 Triarch-arkkitehtuuri
Triarch järjestelmään voidaan liittää kolmentyyppisiä sovelluksia (kuva 3.3) :
Lähdesovellukset (Source) ovat sovelluksia, jotka julkaisevat SSLiään tietoa ja vastaavat järjestelmästä tuleviin kyselyihin. Ne ovat yleensä yhteydessä jonkin tiedontuottajan järjestelmään, josta ne vastaanottavat tietoa ja julkaisevat sitä järjestelmään. Myöskin yhteydet tietokantoihin kyselyitä varten ovat yleisiä. Jos samaa tietoa julkaisevat useat lähdesovellukset voidaan niiden hallintaa varten liittää
järjestelmään myös ns. palvelujakelija {Service Distributor), joka voi osallistua kyselyiden ja tilausten ohjaamiseen sopivalle julkaisijalle. Palvelujakelijat voidaan varmistaa kahdennuksella. Reutersm valikoimissa on valmiit lähdesovellukset useimmille merkittäville tiedontuottajille ja useiden markkinapaikkojen omille tietopalveluille.
Vastaanottajasovellukset {Sink) ovat sovelluksia, jotka tilaavat ja kyselevät tietoa SSL:stä. Yleensä vastaanottajasovelluksilla esitetään järjestelmästä saatua tietoa käyttäjälle helposti ymmärrettävässä muodossa, kuten taulukkoina, graafeina tai uutisteksteinä. Myös vastaanottajasovelluksiksi Reutersilla on useita valmiita vaihtoehtoja eri tarpeisiin.
Hybridisovellukset {Hybrid) toimivat sekä tiedon julkaisijoina ja tilaajina. Näiden sovellusten tehtävänä on vastaanottaa tietoa SSL:stä, jalostaa sitä ja julkaista sitä uudella nimellä. Tämä toiminta voi olla esimerkiksi laskentaa tai Reutersin sivupohjaisen tiedon uudelleenorganisointia. Voidaan esimerkiksi koota toisiinsa liittyviä tietoja yhteen ja julkaista ne yhdellä nimellä takaisin järjestelmään.
Reutersilla on myös tähän ryhmään valmiita sovelluksia, kuten Data Dictionary Server (DDS), joka on samalla valmiiden sivujen paloittelija, omien tietojen julkaisija ja yleinen laskentapalvelin, ja Composite Page Server (CPS), joka on uusien sivuyhdistelmien muokkaaja.
Arviointi
Triarch-järjestelmään on saatavilla lähdesovellukset useimpien tiedontuottajien tiedolle.
Lähdesovellusten kehittämistä varten järjestelmässä on API, jonka avulla omaa tietoa järjestelmään voi syöttää. Myös tiedon vastaanottaminen omaan järjestelmään on mahdollista. Uusimman version mukana tullut palvelujakelija {service distributor) mahdollistaa tietoon viittaamisen nimen avulla.
Triarch-järjestelmä noudattaa tilaaja/julkaisija-mallia, joten lähdesovellusten tarvitsee välittää muuttunut tieto järjestelmään vain kertaalleen. Tietoa vastaanottavat sovellukset saavat tilaamansa tiedon muutokset automaattisesti sovitussa ajassa. Jos tietoa ei voida siirtää, välitetään vastaanottajalle tieto yhteyden vikaantumisesta. Vasteaikojen lyhentämiseksi erilaiset puskurointialgoritmit ovat käytössä. Triarchm BGS-palvelimella {Branch Gateway Server) voidaan eri lähiverkoissa sijaitsevat järjestelmän osat yhdistää, jolloin ne toimivat samoin kuin ne sijaitsisivat samassa lähiverkossa.
Triarch toteuttaa siis kaikki perusvaatimukset (TuoR, KulR, SLäp, T/J, TAjant, Pusk, Tu YL).
Myös Triarch-järjestelmän Vikasietoisuus perustuu rinnakkaisten palvelimien käyttöön. Kun järjestelmän palvelu koostuu useasta rinnakkaisesta palvelimesta, yhden vikaantuessa muut palvelimet korvaavat sen ja jakavat uuden kuorman samalla tasapuolisesti hyvän suorituskyvyn takaamiseksi.
Tästä jakamisesta huolehtii SSL-järjestelmä. Palvelimet voivat myöskin toimia pareittain siten, että toinen palvelin on ns. hot standby-palvelin, joka ei vastaanota kyselyitä tai julkaise uusia tietoja järjestelmään ennen kuin ensisijainen palvelin on vikaantunut. Kun vikaantuminen on tapahtunut,
järjestelmä ohjaa kyselyt automaattisesti tälle varapalvelimelle ja kertoo, että sen tehtävänä on nyt julkistaa kaikki tiedonmuutokset. Hot .ítoittóy-om ¡naisuuden käyttö ei vaikuta asiakasohjelmien tai palvelimien toteutukseen tai käyttöön muuten kuin ehkä parempana vikasietoisuutena. Tärkeä suorituskykyyn vaikuttava ominaisuus Triarch-järjestelmässä on puskurimuistin käyttö. Kyselyihin vastataan suoraan puskurimuistista tiedon löytyessä sieltä. Puskurimuistin täyttyessä korvattavien tietojen valintaa voidaan ohjata järjestelmään asetetuilla parametreillä ja yleisesti tunnetuilla algoritmeilla. Tiettyä tai tiettyjen käyttäjien tarvitsemaa tietoa voidaan pitää etusijalla puskurimuistin käytössä, jolloin se poistuu viimeisenä. Myös tietyn tiedon sulkeminen kokonaan pois puskurimuistista on mahdollista. Asiakasohjelmien aiheuttamaa tahatonta tai tahallista häirintää vähentää se, että kyselyt eivät aina mene palvelimille asti, vaan järjestelmä vastaa niihin puskurimuistista samoin kuin OpenTrade-järjestelmässä. Ottamalla käyttöön ns. DACS-järjestelmän {Data Access Control System) voidaan myöskin säädellä ja valvoa asiakasohjelmien käyttöoikeuksia tietyn tiedon ja käyttömäärän suhteen. Näin voidaan estää järjestelmän ylikuormittuminen jonkun asiakasohjelman jatkuvista kyselyistä.
3.5. Tibco Rendezvous
Rendezvous (Tibco Inc) [15] mahdollistaa kolme erityyppistä interaktiota eri osapuolten välillä. Näitä ovat:
• kysely/palaute-interaktiot, kuten kyselyt ja transaktiot,
• broadcast kysely/palaute-interaktiot, kuten kyselyt, joihin useat palvelimet voivat vastata samanaikaisesti, sekä vastaavasti
• tilaaja/julkaisija-interaktiot, kuten tiedon jakelu monesta eri lähteestä usealle eri vastaanottajalle.
Tilaaja/julkaisija-interaktioissa tilataan ja julkaistaan järjestelmään tietoa sille annetun nimen perusteella. Rendezvous arkkitehtuurin perusosat ovat Rendezvous Daemon, Rendezvous API ja Rendezvous Routing Daemon (kuva 3.4).
kone 1 kone 2
Lähiverkko 1
Rendezvous Daemon Rendezvous Daemor
Rendezvous Routing Daemor Rendezvous API
Sovellus В
Rendezvous API Sovellus C
Rendezvous API Sovellus A
Lähiverkko 2
Kuva 3.4. Rendezvous-arkkitehtuuri
Rendezvous Daemon -osan tehtävänä on taata luotettava viestiliikenne järjestelmään liittyneiden sovellusten välillä. Se huolehtii tiedon siirtämisestä siitä kiinnostuneille osapuolille säästäen sovellusohjelmat tiedon siirtämiseen ja reitittämiseen liittyviltä tehtäviltä. Rendezvous Daemon takaa tietoa julkaistaessa sen saapumisen kaikille tilaajille kohtuullisessa ajassa tai kertoo osapuolille siirtotien vikaantumisesta. Kaikki tieto sovelluksilta Rendezvous Daemon: lie siirtyy Rendezvous API:n välityksellä.
Rendezvous API piilottaa sovellusohjelmalta tiedonsiirron yksityiskohdat. API tarjoaa sovelluksille seuraavat toiminnot:
• aloita tai lopeta istunto Rendezvous Daemonm kanssa,
• kuuntele viestejä,
• lähetä viesti,
• käynnistä event manager -kuuntelusilmukka, jolle voidaan antaa parametrinä funktio, johon siirrytään uuden tiedon saapuessa,
• käsittele saapuneen viestin sisältöä,
• ilmaise kiinnostuksesi ajastimiin, signaaleihin tai I/O-tapahtumiin.
Rendezvous API:n käytettävyyttä lisää sen saatavuus useille eri ohjelmointikielille. Tällä hetkellä ehkä merkittävimpiä niistä ovat Java, C++, Ansi C ja Perl. Rendezvous Routing Daemonm tehtävänä on välittää viestejä Rendezvous Daemon:ien välillä, kun ne sijaitsevat eri verkoissa. Sovelluksille liikenne
Rendezvous Routing Daemon:iin kautta näyttää samalta kuin sovellukset sijaitsisivat samassa verkossa.
Arviointi
Rendezvous-järjestelmään ei ole suoraan saatavissa niin suurta määrää valmiita lähdesovelluksia eri tiedontuottajille kuin muissa informaatioalustoissa. Rendezvous tarjoaa kuitenkin API:n niiden kirjoittamiseen. API:iin sisältyvät myös palvelut asiakassovelluksille tiedon vastaanottoon.
Järjestelmässä viitataan tietoon sen nimen perusteella, eli tiedon sijainnilla ei ole merkitystä asiakassovellusten luonnissa. Myös Rendezvous-järjestelmä noudattaa tilaaja/julkaisija-mallia, jolloin lähdesovellukset siirtävät muuttuneen tiedon vain kertaalleen järjestelmään ja tiedon tilanneet saavat sen automaattisesti. Järjestelmä takaa tiedon saapumisen tilanneille sovelluksille sovitussa ajassa, tai yhteyden vikaantuessa siitä tiedotetaan tilaajille. Rendezvous ei tarjoa puskurimuistipalveluja kyselyiden vasteaikojen lyhentämiseksi, vaan ainoastaan tiedon muutosten historian säilyttämiseen.
Rendezvous Routing Daemon mahdollistaa järjestelmän osien sijainnin eri lähiverkoissa. Rendezvous täyttää siis kuusi seitsemästä perusvaatimuksesta (TuoR, KulR, SLäp, T/J, TAjant, TuYL).
Rendezvous-järjestelmä on vikasietoisuuden suhteen selvästi puutteellisin vertailluista järjestelmistä.
Rendezvous ei tue rinnakkaisia palvelimia vikasietoisuuden parantamiseksi. Jos järjestelmän palvelin vikaantuu saavat asiakasohjelmat kuitenkin siitä tiedon. Toisaalta suorituskyvyn parantamiseksi voidaan asiakasohjelman lähettämä kysely jakaa useammalle palvelimelle ja näin saavuttaa lyhyempiä vasteaikoja. Tästä rinnakkaisuudesta ei kuitenkaan ole hyötyä vikaantumistilanteessa. Samoin kuin OpenTrade-järjestelmässä asiakasohjelmille siirtyvä tieto sisältää myöskin kuvauksen sen esitystavasta.
Siis, jos järjestelmässä on hitaita tietoliikenneyhteyksiä, saattavat tiedon saapumisajat asiakasohjelmille kasvaa. Rendezvous ei sisällä palvelimien tai asiakasohjelmien tahallista tai tahatonta häiriökäyttäytymistä estäviä ominaisuuksia.
Vaikkakin Rendezvous on vikasietoisuudeltaan selvästi heikoin vertailluista järjestelmistä, on se hyvä esimerkki kevyestä ja helppokäyttöisestä järjestelmästä ympäristöihin, missä ei tarvita suurta vikasietoisuutta. Se on helppo ottaa käyttöön ja on monilta ominaisuuksiltaan vertailtavista järjestelmistä edistyksellisin. Tästä hyvä esimerkki on Rendezvous-API:n saatavuus nykyään suosituille ohjelmointikielille, kuten C++ ja Java. Näistä jälkimmäisen käyttö voi helpottaa suuresti Rendezvousm käyttöä muodikkaissa selain-pohjaisissa tiedonseurantasovelluksissa
