Välittäjä-arkkitehtuurin toteutuksista

Sisällysluettelo

1 Johdanto

2 Välittäjä-palvelu

5 Lähteet

6 Liite : Välittäjäarkkitehtuurin osa-alueiden määrittelijöitä
 
 

1. Johdanto

Välittäjä-arkkitehtuuri on eräs sähköisten kaupankäynnin muoto. Tässä esityksessä tarkastellaan eräitä tämän arkkitehtuuriin peruskysymyksiä, arkkitehtuurien mukaan tehtyjä toteutuksia ja ongelmia, joiden ratkaiseminen mahdollistaa nykyisen ajattelun mukaisen välittäjä-kaupankäynnin yleistymisen.

Tässä esityksessä käytämme sanaa palvelu tarkoittamaan sähköisen kaupankäynnin kohteita, jollaisia ovat esimerkiksi tavara, tieto, elektroninen lehti, vakuutus, lomamatka tai jokin ostettu palvelu sanan normaalissa merkityksessä.

Kaupallinen transaktio tarkoittaa palvelun valintaa, sen ostamisen ja ostetun palvelun sekä siitä maksettavien vastikkeiden vaihdon tapahtuman eri osapuolten kesken. Kaupallisen transaktion vaiheet voidaan jakaa eri tavoilla, mutta yksinkertaistettuna kaupallinen transaktio muodostuu seuraavan kuvan esittämistä kaupallisen transaktion vaiheista.
 


 
 



Kuva 1. Kaupallinen transaktio [Mer 99].




Informaatiovaiheessa (Information) ostajat etsivät tarvitsemiaan palveluja markkinoilla olemassa olevien palvelujen joukosta sekä vertailevat niiden ominaisuuksia ja hintoja. Myyjät puolestaan tarjoavat palvelujaan mainosten tai muiden markkinointikanavien kautta. Tämän vaiheen toimintoja tukee verkossa esimerkiksi katalogit, hakukoneet ja mainospainikkeet eli bannerit.

Neuvotteluvaihe (Negotiation) seuraa informaatiovaihetta, jos ostaja kiinnostuu tarjolla olevasta palvelusta. Tällöin ostaja- ja myyjäosapuolet pyrkivät sopimaan kaupan ehdoista. Tätä vaihetta tukee verkossa yhteistyöohjelmistot ja neuvotteluprotokollat.

Kaupan toteuttamisvaihe (Service Execution) seuraa neuvotteluvaihetta, jos se päättyy sopimuksen solmimiseen eli sopimuksen allekirjoittamiseen. Kaupan toteuttamisvaihe saattaa ajallisesti kestää muutamasta sekunnista useaan vuoteen. Toteuttamisvaiheen aikana verkossa tulee käyttöön asiankäsittelyohjelmistot, osallistujien yritysprosessien yhteistoiminta, verkkomaksaminen ja OVT- järjestelmät.

Kaupalliseen transaktion toteuttamisen yksinkertaistamiseksi siihen voi liittyä myös kolmansien osapuolten tarjoamaa lisäpalvelua, joista eräs on käsittelemämme välittäjä-palvelu eli brokerage-toiminta. Informaatiovaiheessa välittäjä auttaa löytämään oston kohteena olevat palvelut edullisesti ja toisaalta palvelujen tarjoajat löytävät välittäjäjien avulla luotettavia kauppakumppaneita. Sopimuksen allekirjoituksen yhteydessä voidaan tarvita luotettua kolmatta osapuolta varmistamaan allekirjoittajien henkilöllisyys ja se, että kaikki tarpeelliset osapuolet allekirjoittavat sopimuksen. Välittäjäjän tehtävä voi olla myös säilyttää allekirjoitettu sopimus ja taata sen muuttamattomuus ja häviämättömyys. Välittäjänä voi toimia myös sähköistä maksupalvelua tarjoava yhtiö ja maksu voi tapahtua joko elektronisen rahan muodossa tai maksu voi tapahtua sähköisesti pankkien kautta.

Tämä esitys on tehty verkosta löytyvien lähteiden pohjalta ja lisäksi on käytetty Mäkelinin kirjaa [Mäk98] suomenkielisen termistön ja eräiden määrittelyjen lähteenä. yhteenliittymistä

Välittäjä-arkkitehtuurin kehittämisessä on mukana useita eri tahoja ja organisaatioita, joista vain osa on esiintyy tässä seminaarityössä. Liitteessä 1 on tehty yhteenveto eräistä yhteenliittymistä, jotka kehittävät ja kokeilevat arkkitehtuurimalleja sekä tekevät standardien määrittelytyötä.
 

Seuraavassa tarkastelemme sähköisen kaupankäynnin tarpeita kaupallisen transaktion eri vaiheissa ja tutustumme joihinkin kirjallisuudessa esiintyviin ratkaisumalleihin.

Nykyisin ostetaan verkossa palveluja käyttäen katalogi- eli kauppapaikkaohjelmistoja. Niissä on perustoimintoina nykyisin katalogin tekeminen ja hallinta, tietokanta, ostoskärrytoiminnot, tilausten käsittely ja raportointitoiminnot. Kehittyneempiin muotoihin kuuluu yksilölliset, asiakaskohtaiset näytöt ja hinnoittelu, sekä tuki erilaisille markkinointi- ja palvelukonsepteille [Mäk98].
 
 

2.1 Informaatiovaihe
 

Nykyisin välittäjän palvelujen avulla voidaan löytää eräissä tapauksissa maailmanlaajuisesti "paras mahdollinen" palvelu. Tieteellisen materiaalin hallintaan on olemassa Open digital library projekti, jonka puitteissa voidaan etsiä ja hankkia tieteellistä kirjallisuutta ja erilaisia artikkeleita. Esimerkkinä tarkastelemme MeDoC-projektia [MEDa99], jossa nimenomaan välittäjä-palvelun avulla etsitään sopivinta materiaalin tarjoajaa. Medoc-projekti lopetettiin heinäkuun lopussa 1999, mutta sen luoman arkkitehtuuria ryhdytään kokeilemaan projektissa nimeltä InterDoc [IND99]. Uudessa projektissa laajennetaan kokeilua käsittämään usean eri tieteenalan kirjallisuuden hakupalvelua.

MeDoC käyttäjä lähettää välittäjälle materiaalin hakupyynnön ja välittäjä päättelee tapauskohtaisesti parhaat tulokset antavat materiaalin tarjoajat. Arvioinnissa käytetään perusteina palvelujen tarjoajien materiaalin hintaa ja laatua. On huomattava, että välittäjä tuottaa tässä tapauksessa lisäarvoa ostajalle, koska materiaalin tarjoaja voi ilmoittaa ostajalle, kuinka monta osumaa materiaaleihin tuli (hit rate) ja mutta välittäjän tehtävä on arvioida löytyneen materiaalin todellista hyötyä ostajalle ( request count).





Kuva 2. MeDoc välittäjä-palvelu [MEDb99].


 



Tiedon tarvitsijat ottavat yhteyden jonkin käyvän selaimen avulla käyttäjän agenttiohjelmaan (Nutzeragent), joka on yhteydessä välittäjiin. Yhteydenotto voidaan tehdä haluttaessa myös sähköpostin välityksellä. Selain ja käyttäjän agentti ovat asennetut käyttäjän organisaatiossa (installiert bei Nutzerinstitutionen). Kuvassa yhtenäinen viiva kuvaa yleisiä tietoliikenneyhteyksiä ja harva katkoviiva materiaalin etsintää ja dokumenttien hakua (Recherche & Dokumentenabruf). Välittäjän tehtävä on löytää etsintätehtävään soveltuvat aineiston tarjoajien hakuagentit (Anbieteragent) ja toimia niiden kanssa yhteistyössä, jota kaaviossa kuvaa tiheä katkoviiva. Tarjoajaorganisaatiossa (MeDoc-Anbietern), joita ovat esimerkiksi kustantamot ja yliopistot, on oltava tarpeelliset ohjelmistot, jotka tarjoavat liittymät käyttäjän agenttien ja välittäjän käytettäviksi.

Kuvan yhteenvetona voidaan esittää seuraavaa: Käyttäjä tekee selaimellaan kyselyn, joka ohjautuu välittäjille. Tämä suosittelee käyttäjälle joukkoa tarjoajia, ja käyttäjä voi sen jälkeen samanaikaisesti etsiä ja noutaa tarvitsemiansa tekstidokumentteja useasta eri paikasta.
 

 

2.2 Neuvotteluvaihe
 

Neuvotteluvaihetta kuvataan COMOS-projektissa [COS99] seuraavasti. Neuvotteluvaiheessa pyritään löytämään ehdot kaupan toteuttamiseksi. Mikäli kauppa neuvotellaan Internetin kautta, käytetään apuna siihen soveltuvia ohjelmistoja.

Yhteistyöohjelmat (collaboration tools) ovat yksinkertaisia neuvottelun apuvälineitä. Osapuolten edustajat voivat käydä neuvottelua kirjoittamalla samaa dokumenttia hallitusti ja muotovapaasti siten, että eri osapuolet näkevät välittömästi yhteiseen dokumenttiin tehdyt muutokset.

Neuvotteluosapuolet voivat hyödyntää neuvotteluprotokollia (negotiation protocols), jolloin joko ihmiset tai ohjelmistokomponentit osallistuvat neuvotteluun. Neuvottelun aihe näissä tapauksissa on strukturoimaton eli osallistujat tietävät itse, mitä kaikkia asioita neuvotteluissa tulee käsitellä ja mistä asioista on sovittava. Neuvotteludokumenttien käsittely ja rakenne on etukäteen määrätty ja protokolla määrää, kuka osapuolista kulloinkin toimittaa ennalta määritellyn tiedon ja kenelle tieto toimitetaan. Neuvottelu voidaan nähdä ennalta määriteltynä asiankäsittelyprosessina.

Käytettäessä formaalista keskusteluja (formalized conversations) on neuvottelun muoto tiukemmin määritelty kuin neuvotteluprotokollan tapauksessa. Esimerkki formaaleista keskusteluista on Knowledge Query and Manipulation Language (KQML), agenttien yhteistyön mahdollistava tiedon ja tietämyksen siirtoon tarkoitettu yhteyskieli. Tämä mahdollistaa kielellisen mahdollisuuden määritellä formaalisti neuvotteluja ja neuvottelussa voidaan käyttää määriteltyjä termejä kuten "tarjous", "hylätä", "ehdottaa", "hyväksyä" jne. Kielen avulla voidaan räätälöidä järjestelmiä eri kaupankäyntialojen neuvottelujen tukemiseen. Neuvottelun osapuolten järjestelmät ymmärtävät myös tarjouksen ja ehdotuksen välisen eron, tarjous sitoo sen esittäjää ja hyväksyessään vastapuoli saa aikaiseksi pätevän sopimuksen, ehdotus sen sijaan ei ole sitova. Neuvotteluprosessi voidaan kokonaisuudessaan automatisoida, jolloin sen hoitaa itsenäiset agentit. Tämä edellyttää sen, että tapa esittää tietoa neuvottelun kohteesta (ontologia) on myös standardoitu. Tällaisessa tapauksessa "puhuminen" ja "hinta" ovat tekijöitä, joista agentti voi tehdä johtopäätöksiä. Nykypäivän todellisuudessa ei käytetä automaattista neuvottelua, koska mitä monimutkaisemmista asioista neuvotellaan ja pyritään sopimaan, sitä monimutkaisemmaksi puhe muuttuu. Jos kaupan kohteena on yksinkertaiset tuotteet kuten monet kulutustavaroista, nousee niiden tarjoajien lukumäärä suureksi ja tällaisten hyödykkeiden hankinnassa neuvottelukustannukset kasvaisivat liian suuriksi.
 

2.3 Palvelun määrittely
 

Avoimessa heterogeenisessa ympäristössä palvelujen tarjoaminen voi olla menestyksellistä vain, jos tarjous voidaan esittää sellaisessa muodossa, jota voi hyödyntää laaja joukko erilaisia käyttäjiä ja käytössä olevat eri tekniikat. Tällöin välittäjä voi palvella osapuolia tarjoamalla tekniikkaa, joka voi muuntaa esitetyt tarjouksen dynaamisesti ostajan haluamaan esitysmuotoon. Palvelun määrittelyvaiheen aikana järjestelmien tulee tarjota useita erilaisia vaihtoehtoja tietojen vaihtoon ja kussakin neuvotteluyhteydessä valitaan paras yhteinen käytettävä menettelytapa. Uusia menettelytapoja pitää voida lisätä automaattisesti ajoaikana muutamalla vain parametrejä. Ohjelmisto tulee voidaan konfiguroida helposti ja liittää osaksi muuta järjestelmää. Jos joustava järjestelmä saadaan aikaiseksi, on helppo käydä sähköistä kauppaa. Toistaiseksi on vielä ratkaistavana monia ongelmia ennen kuvatunlaisen järjestelmän syntymistä [COS99].
 

2.4 Sähköinen sopiminen
 

Suullinen sopimus on pätevä sopimusmuoto ja sähköisen kaupankäynnin yhteydessä sitä vastaa "OSTA" painikkeen klikkaaminen ruudulla. Usein suullinen sopimus ei ole osapuolten kannalta riittävä, koska tällöin riitatilanteessa on "sana vastaan sana", vaan on olemassa tarve tehdä sopimus vahvemmaksi ja pitävämmäksi.
 

Kirjallista sopimusta ei voida jälkeenpäin muuttaa ja tällöin riitatilanteessa ratkaisee sopimuksen tulkinta. Sähköisen kaupankäynnin yhteydessä kirjalliseen sopimukseen tarvitaan allekirjoittaneiden osapuolten lisäksi luotettu kolmas osapuoli, jonka hallussa on alkuperäiset sopimustiedot. Näiden pohjalta viime kädessä ratkaistaan, mitä on sovittu, ja erimielisyydet osapuolten välillä ratkaistaan tulkitsemalla aitoa sopimusta. Lainkäyttäjien kannalta sähköiset allekirjoitukset on osapuolten mahdollista hyväksyä eräissä maissa, mutta sopimuksien säilytys kolmansien osapuolten hallussa ei ole lainsäädännöllisesti vahvalla pohjalla. Jos erimielisyydet ratkaistaan oikeudessa, joutuu oikeusistuin viimekädessä päättämään dokumenttien ja allekirjoitusten oikeellisuuden [COS99].
 

2.5 Sopimusten toteuttaminen
 

Sopimus tulee toteuttaa sovitussa muodossa ja sen laillinen toteutuminen voidaan seurata ihmisen toimesta. Jos sopimukset talletetaan sähköisessä muodossa, ne voidaan myös toteuttaa ja seurata automaattisesti. Sähköisesti talletetun strukturoidun sopimuksen pohjalta voi asianhallintaohjelma lähettää huomautuksia ja ilmoituksia sovituista tapahtumista osapuolille. Ilmoitukset viittaavat sovittuihin asioihin, kuten maksuihin ja toimituksiin ja niiden toteuttamisaikoihin.

Kehittyneemmällä tasolla voi asianhallintaohjelma olla suoraan yhteydessä osapuolten tietojärjestelmiin. Yhteysjärjestelmiä voidaan luoda käyttäen hyväksi hajautettuja, olioperustaisia ohjelmistokomponentteja. Sopimuksen osapuolien etujen turvaamiseksi tulee käytettyjen komponenttien olla testattuja, yleisesti hyväksyttyjä vakiokomponentteja, jotka voidaan riskittä liittää osaksi olemassa olevia järjestelmiä. Jos tehdyt hankintasopimukset ovat toiminnaltaan monimutkaisia ja osapuolet ovat tehneet sopimukseen erityisehtoja, tulee yhteyden rakentavien komponenttien pystyä niistä selviytymään [COS99].
 

2.6 Välittäjä-toiminta hajautetussa ympäristössä
 

Kun Internet- ympäristössä käydään neuvotteluja ja tehdään sopimuksia, osapuolten ohjelmistojen yhteensovittamisesta tulee erittäin tärkeä kysymys. Koska toistaiseksi tällaiset yhteystapahtumat eivät ole tavanomaisia, tulee ainakin palvelujen tarjonnan alkuvaiheessa tehdä tapahtumista avoimia ja ihmiselle helposti seurattavia ja tarkkailtavia. Tutkielmassa tarkastellaan välittäjä-toimintaa hajautetussa ympäristössä Common Brokerage Architecture eli COBRA-projektissa esitettyjen näkemysten mukaisesti [MDS98].

Sähköiseen välittäjä-toimintaan esitetyt mallit käsittelevät monen osapuolen välisiä tapahtumia, joiden kestoaika voi olla pitkä. Kunkin osapuolen osallistumiseen tapahtuman eri vaiheeseen sisältää joukon ennakko- ja jälkiehtoja, joiden on täytyttävä ennen kuin osapuoli katsoo tapahtuman siltä osin käsitellyksi. Kullekin transaktioon liittyvään tapahtumille voidaan esittää seuraavia ominaisuuksia:
 

• Atomisuus (Atomicity) tarkoittaa sitä, että määritelty tapahtuma suoritetaan vain kerran tai ei lainkaan ja kaikki osapuolet saavat tietoonsa tapahtuman kohtalon.
• Pysyvyys (Persistence) edellyttää, että syntynyttä tietoa ei voida jälkikäteen muuttaa.
• Turvallisuus (Security) ominaisuus täyttyy, mikäli tapahtuma on turvallista suorittaa ja se tapahtuminen voidaan todentaa siitä kiinnostuneiden osapuolten toimesta.


Transaktion tapahtumat voidaan suorittaa kahdella eri periaatteella. Jos käytetään keskitettyä tapahtuman valvontaa, tulee jokaisen osallistujan asioida transaktion valvojan kanssa. Transaktion valvojan ollessa luotettu, ovat loogiset asioinnit tämän kanssa samalla myös osallistujan kannalta tapahtuman kontrollin pisteitä. Mikäli tapahtumalla ei ole keskitettyä hoitajaa eli kyseessä on hajautettu tapahtuma, on kaikilla osapuolilla velvollisuus hoitaa transaktion tapahtumaa ja täten myös tapahtumien looginen koordinointi ja niiden kontrollointipisteet on monistettu ja hajautettu.

Keskitetyssä tapahtuman valvonnassa toiminta perustuu osallistujien toimintaan. Tällöin kaikilla osapuolilla tulee olla ennen transaktiota luotu yhteys sen valvojaan. Jälkimmäisessä hajautetun transaktion tapauksessa jokainen osapuoli on toisistaan riippuvainen ja kaikkien tulee voida seurata ja tulkita toisten suorittamia tekoja.

Keskitetyn tapahtumavalvonnan tapauksessa osallistujien huolenaiheena on epävarma viestien välitys. Tapahtumien atomisuus, informaation pysyvyys ja sanomien autentisuus on käytetyn palvelun ominaisuuksia, välittäjän vastuulla. Hajautetun transaktion tapauksessa on jokainen osallistuja velvollinen kantamaan vastuuta transaktion tapahtumista ja lisäksi kukin osallistuja tarvitsee kyvyn seurata muiden osapuolten tekoja. Järjestelmän tulee tietää varmuudella, milloin jokin osapuoli on suorittanut sopimuksessa osoitetun velvollisuuden. Kaikkien osapuolten tulee voida luottaa niin omassa järjestelmässään käytettävien sovelluskomponenttien laatuun ja myös toisten osapuolten järjestelmien laatuun. Hajautetun tapahtumavalvonnan kohdalla ennalta luotu yhteys tapahtuu järjestelmien infrastruktuurin toimittajien toimesta ja niihin luottaminen mahdollistaa osallistujille kyvyn luoda kontakteja joustavasti. Kun tapahtumavalvonta on hajautettu useaan eri yritykseen, jokaisen tulee voida replikoida järjestelmäänsä kaikki sitä kiinnostavat transaktion seuraamiseen tarvittavat piirteet. Heidän tulee myös voida luottaa infrastruktuurin luomaan ympäristöön ja varmistua siitä, että heidän tietonsa transaktion tilasta on oikea, joten ympäristön toimittajien vastuulle jää tällöin taata tapahtumien atomisuus, pysyvyys ja turvallisuus osapuolten käydessä kauppaa.
 

2.7 Cosmos sopimusmalli
 

Tarkastelemme sopimusmallliarkitehtuuria, joka on julkaistu COSMOS-projektin toimesta, Mertzin teoksen mukaisesti [Mer99 s. 201 - 211]. Sopimusvaiheen malli on tärkeä, koska se muodostaa perustan kaupankäynnin seuraaville vaiheille. COSMOS sopimusta tarkastellaan strukturoituna dokumenttina, joka muodostuu tekstilohkoista. Pk-yritysten kohdalla on taloudellista ajatella, että sopimus tehdään manuaalisesti tekstejä editoimalla eikä sopimusta tehdä ohjelma-agenttien avulla. Riippumatta tavasta, jolla sopimus on tehty, COSMOS- mallissa pyritään tekstistä erottamaan sisällöllisesti tärkeät osat ja muuttamaan sopimus elektronisesti suoritettavaan muotoon. Sopimuksen eri osat voidaan erottaa esimerkiksi otsikoiden perusteella:
 

• Kuka - osa sisältää tiedot sopijaosapuolista, siinä mainitaan henkilöt ja allekirjoittajat, jotka muodostavat sopimuksen osapuolet. Osapuolilla sopimusmallissa määritellyt roolit. Mallin rooleja edustaa luonnolliset tai oikeushenkilöt. Oikeushenkilöllä tulee olla sopimuksessa edustaja ja luonnollinen henkilö voi olla edustettu itsensä tai edustajan kautta. Kun sopimus tehdään, jokainen osapuoli vahvistaa sen allekirjoituksellaan.
• Mitä - osa ilmaisee sopimuksen kohteen. Osa sisältää tiedot kaikista oikeuksista ja velvollisuuksista, joita osapuolilla on. Kaupankäynnissä toisen osapuolen velvollisuus on vastapuolen oikeus. Seuraavassa puhutaan ainoastaan velvollisuuksista. Velvollisuus sisältää tavaran, palvelun rahan tai lisenssin siirron. Velvollisuuksiin liittyy myös Quality of Service (QoS)- attribuutti, joka kuvaa tarkoitetun palvelun laatua. Neuvotteluissa QoS- attribuutti on tarjousten ja vastatarjousten kohde.
• Kuinka - osa määrittelee velvollisuuksien väliset suhteet. Kerrotaan, milloin yksittäinen osuus palvelusta tulee toimittaa ja mitkä ovat sen määräajat ja miten määritellään aikataulussa pysyminen. Kuinka - osa määrittää asianhallinnan, jolla sopimusta voidaan seurata ja saattaa sen toteutus päätökseen.

• Muut osat sisältävät yleislauseita, jotka voivat kuulua sopimukseen. Nämä käsittelevät yleisiä sopimusehtoja ja sitä milloin sopimus on voimassa ja ehdoissa voidaan viitata myös sopimuksen lainsäädännöllisiin edellytyksiin.


COSMOS- mallissa luodaan ensin sopimusrunko, jossa ennalta määritellään kuinka - osa. Lisäksi määritellään sopimuksessa tarvittavat roolit ja kustakin velvollisuudesta tarpeelliset QoS- attribuuttiarvot. Sopimusrunko ei nimeä sopijaosapuolia eikä tarkkoja attribuuttiarvoja kuten "Hinta kilolta = 17,70" tai "Kosteusarvo = 8%", vaan attribuutit ilmaistaan raja-arvoina esimerkiksi "Hinta kilolta < 18,00" tai "Kosteusarvo < 10%"

Välittäjä valmistaa sopimusehdotuksen ja täydentää sopimusrunkoa, mikäli katalogista löytyy palvelulle sopiva toimittaja. Välittäjän tehtävä on muuttaa QoS- attribuuttiarvot tarjouksen arvoiksi. Tätä varten välittäjällä tulee olla tiedot tarjolla olevien palvelujen laadusta ja usein tarvitaan mahdollisuus ajantasaiset tiedot tarjoajilta. Löydettyään sopivan palvelun, välittäjä liittää sopimusehdotukseen osapuolten tiedot. Jos välittäjän toiminnan jälkeen saadaan aikaiseksi periaatteellisella tasolla valmis sopimus, antaa ostaja vastatarjouksen.

Neuvotteluvaiheessa sopimusehdotuksia vaihdetaan osapuolten kesken. Riippuen käytetystä menetelmästä, sopimustarjous voidaan käsittää joko ehdotukseksi, joka ei ole laillisesti sitova, tai tarjoukseksi, joka sitoo tarjoavaa osapuolta. Kun kaikki osapuolet hyväksyvät sopimusehdotuksen, on sopimus valmis allekirjoitettavaksi.

Kun kaikki osapuolet tai heidän edustajansa ovat allekirjoittaneet sopimuksen, vahvistaa sähköinen sopimuspalvelu sen. Tämän jälkeen sopimus toteutetaan ja voidaan siirtää asiankäsittelyohjelmistolle.

 
  Kuva 3. COSMOS- mallin rakenneosat [Mer99 s. 209].

Kuvasta 3 ilmenee COSMOS- arkkitehtuurin viisi rakenneosaa. Sopimuksen toiminnot liittyvät kiinteästi toisiinsa, koska ne kommunikoivat keskenään käyttäen sopimusta tiedonsiirron välineenä. Kaikki COSMOS- mallin mukaiset prototyypit voivat käyttää haluamiansa osia. Mallia hyväksikäyttävä yhteenliittymä saattaa olla muodostettu jo aiemmin ja katalogivaihe sekä siihen liittyvää välittäjä-toimintaa ei tarvita. Toisissa tapauksissa ei neuvotteluvaihetta käytetä, koska se olisi liian kallista verrattuna tapahtumien lukumäärään. Myös asianhallintaosuus ja sopimusten täytäntöönpano voi puuttua. COSMOS- mallin komponenttien dynaamisuus mahdollistaa erilaisten ratkaisujen muodostamisen ja toteutuksessa määritellään siitä käytettävät osat. Mallin abstraktio ei koske ainoastaan ohjelmistokomponentteja vaan myös käytettävää sopimusmallia. Erilaisia toteutustekniikoita on mahdollista hyödyntää eri COSMOS- malliin perustuvissa toteutuksissa. Seuraavassa luetellaan eräitä mahdollisia komponentteja.
 

• Nykyinen WEB- teknologia mahdollistaa tehokkaan tosiaikaisen tietojenkäsittelyn. Tällä alueella syntyy myös jatkuvasti uusia standardeja.

• Object Management Group (OMG) CORBA standardi mahdollistaa toteutuessaan laite- ja käyttöjärjestelmäriippumattomuuden .

• Java- pohjaiset "Plain Java" sovelluskehykset (frameworks), joita on olemassa mm. tietoliikenteeseen (Voyager) ja komponenttien valmistamiseen (IBM San Fransisco Framework).

• Perinteiset teknologiat kuten EDI / OVT ovat käytössä myös tulevaisuudessa ja niitä voidaan hyödyntää COSMOS- mallin mukaisissa ratkaisuissa.
  
  
  
  

Välittäjä-palvelujen pilottikokeiluja on kuvattu COBRA- ryhmän toimesta raportissa [MDS98]. COBRA ryhmällä on seuraavat kolme päätavoitetta.


1. Luoda avoin arkkitehtuuri, jolla toteutetaan verkossa välittäjä-toimintaa.
   
2. Luoda ja valmistella ehdotus eurooppalaiseksi välittäjä-arkkitehtuuri standardiksi.
   
3. Osoittaa pilottihankkeiden avulla arkkitehtuurin ominaisuuksia.
   

Pilotit toteutetaan käyttäen hyväksi olemassa olevaa teknologiaa. COBRA arkkitehtuurin mukaisia pilottitoteutuksia on raportoitu kolme kappaletta, jotka tunnetaan nimillä Milano-pilotti, Durham-pilotti ja Helsinki-pilotti. Pilotit ovat toteutetut erilaisiin ympäristöihin siten, että Milano-pilotti palvelee pk-yritysten informaation hakua, Durham-pilotti on yritysneuvonnan ja pk-yritysten välittäjänä ja Helsinki-pilotti toimii monimutkaisen palveluketjun tuottamisen välittäjänä.
 

3.1 Milano-pilotti
 

Pilotissa on kyseessä Milanon kauppakamarin projekti, jossa välittäjä-toimintona välitetään pk-yrityksille niille suunnattua yritystoiminnan kehittämiseksi ja edistämiseksi tuotettua informaatiota.
 


 
 

Kuva 4. Välittäjä-toiminnon malli Milano-pilotti projektissa raportin [MDS98] mukaan.


 


Kaupalliset ja julkiset tiedon tuottajat tarjoavat erilaista tietoa monissa eri muodoissa ja eri välineillä. Tarjottujen tietojen vertailu on kokemattomalle vaikeaa ja asiakkaat eivät aina itsekään tiedä, mitä tietoa he tarvitsevat ja mistä tieto on saatavissa. Näistä syistä on tarve kokeneelle välittäjälle, joka osaa opastaa asiakasta. Välittäjän velvollisuus on kerätä ja valita asiakkaan tarvitsema tieto ja hänellä on osavastuu myös siitä tiedosta, jonka asiakas lopulta ostaa. Ostajilla tulee olla vankka luottamus välittäjään ja näin ollen siinä roolissa toimii kauppakamari.
 
 





Kuva 5. Toiminnot ja vastuut Milano-pilotti projektissa raportin [MDS98] mukaan.





Kuvan 5. mukaan välittäjä on vastuussa tiedon julkistamisesta ja levittämisestä ja tarvittavan tiedon välittämisestä asiakkaalle. Asiakas ja välittäjä yhdessä vastaavat valitun tiedon kelpoisuuden arvioinnista ja sen hankkimisesta.
 
 

3.2 Durham-pilotti

Durham-pilotti muistuttaa Milano-pilottia siinä, että välittäjä-toiminto kohdistuu tiedon ja palvelujen välittämiseen pk-yrityksille. Durhamin yrittäjäyhdistys TEC (The County Durham Training and Enterprise Council), toimii ohjelman sponsoreiden eli toimittajien agenttina ja pk-yritysten neuvojana. TEC:n yritysneuvojat ja eri alojen asiantuntijat toimivat varsinaisina välittäjinä. Nämä yhdessä tarjoavat palveluna eri tukiohjelmien ja yrittäjien välillä. Tämä on tärkeää, koska erilaisia ohjelmia käynnistyy ja loppuu ajan kuluessa. Tärkein aspekti tässä kokeilussa on yritysten neuvontatoiminta.
 
 




Kuva 6. Välittäjä-toiminnon malli Durham-pilotti projektissa raportin [MDS98] mukaan.


 


Asiakkaat eivät välttämättä tiedä tarpeitaan eikä tarjolla olevia tukiohjelmia, jolloin välittäjän tehtävä on toimia ohjelmien tietopankkina ja heidän tulee osata valita asiakkaille sopivat ohjelmat. Ohjelmien tiedottamisvastuu ei ole ainoastaan välittäjillä vaan myös ohjelmien sponsoreilla, joiden tulee ylläpitää tietoa ja olla valmiit toteuttamaan ohjelmiaan yksittäisen asiakkaan kanssa. TEC:n tulee seurata ohjelmien toteutumista ja raportoida siitä sponsoreille.
 
 



 

Kuva 7. Toiminnot ja vastuut Durham-pilotti projektissa raportin [MDS98] mukaan.


 


3.3 Helsinki-pilottii
 

Helsinki-pilotti käyttää välittäjä-palveluja multimediapalvelujen markkinointiin. Muista piloteista poiketen välittäjätoiminnon kohteena on monimutkainen tuotteiden ja palveluiden tarjontakokonaisuus. Välittäjä-palvelua voidaan käyttää hyväksi kahdella tapaa, ensinnäkin se mahdollistaa asiakkaille yhden paikan, josta voi ostaa kaikki multimediapalvelut ja toiseksi se tarjoaa näyttelyjen ja tapahtumien järjestelijöille , etenkin Helsinki 2000 juhlien järjestelijöille, tilaisuuden tutkia erilaisten esitysten teknisiä ja taloudellisia tekijöitä. Tapahtumiin voi välittäjän avulla hankkia palveluja useilta eri toimittajilta. Välittäjä huolehtii kokonaistarjouksen teosta ja antaa palvelujen tuottajille mahdollisuuden markkinoida palvelujaan.
 
 




 

Kuva 8. Välittäjä-toiminnon malli Helsinki-pilotti projektissa raportin [MDS98] mukaan.




Koska välittäjä-palvelu antaa mahdollisuuden ostajille yhdistää osia eri tarjoajien palveluista ja näin tukee asiakkaan tiedonkeruu ja valintaprosessia, on kuitenkin vastuu tiedon keruusta, valinnasta ja palvelujen hankinnasta asiakkaalla. Välittäjän vastuulla on tietojen julkistaminen ja hankintatoiminnan tuki ja seuranta.
 
 



 

Kuva 9. Toiminnot ja vastuut Helsinki-pilotti projektissa raportin [MDS98] mukaan.


 




Ero verrattuna aikaisempiin esimerkkeihin on myös siinä, että pilotissa ei seurata pelkästään yksittäistä tapahtumaa vaan pidetään kirjaa asiakkaan kaikista tapahtumista. Välittäjällä on velvollisuus rekisteröidä asiakkaat, tarjota hakupalveluja ja taata asiakkaan pääsy niihin, hoitaa kirjanpito ja laskutus sekä asiakkaiden jälkihoito.
 

4. Yhteenveto

Brokerage toiminto on voimakkaasti kehittymässä eikä vielä ole olemassa laajasti siitä esimerkkejä. Kehittyäkseen käyttökelpoiseksi menetelmäksi se vaatii mielestäni seuraavien yleisten teknologioiden kehittymisen. Ensinnäkin maksamistavan on kehityttävä turvalliseksi ja yleisesti hyväksyttäväksi kaupankäynnin muodoksi. Toiseksi laajasti käytettynä toiminta tarvitsee älykkäiden agenttien olemassaolon käytettäväksi sekä palvelujen hakuvaiheessa että sopimusten neuvotteluvaiheessa. Kolmas tarpeellinen komponentti on tapa liittää yritysten omat tietojärjestelmät yhteen siinä määrin, että sopimukset voidaan toteuttaa mahdollisimman automaattisesti.
 

Teknisten edellytysten lisäksi on eri maiden lainsäädäntöjen kehityttävä siten, että sähköinen kaupankäynti ja sopiminen on luotettavaa ja lisäksi käytäessä globaalia kauppaa, on eri maiden harmonisoitava lainsäädäntöään näiltä osin.
 
 

Mäk98

Mäkelin, M., Sähköinen kauppa ja liiketoiminta Kilpailu ja yhteistyö digitaalitaloudessa. HM&V Research Oy 1998, ISBN 951-98059-0-7, Helsinki

Mer99

Merz, M., Electronic Commerce, Aktualisierung: 12.04.99.  Viitattu 30.9.1999. http://vsys-www.informatik.uni-hamburg.de/papers/buch.ps.gz

COS99

Common Open Service Market for Small and Medium-sized Enterprises.  Viitattu 30.9.1999.  http://vsys-www.informatik.uni-hamburg.de/projects/cosmos/

IND99

Interdisziplinäre Dokumentenverarbeitung auf Basis des MeDoc-Dienstes. Viitattu 30.9.1999.  http://interdoc.offis.uni-oldenburg.de/

MDS98

Martin, M., Dobson, M., Strens, R., COBRA Deliverable 10: The Final Enterprise Models , 14/1/98. Viitattu 30.9.1999.  http://www.onyx.net/proj/cobra/papers/d10v1.zip

Dif99

Computational View of Electronic Brokering Service Components. Viitattu 30.9.1999.  http://www.det.ua.pt/Projects/difference/work/D5/d5chapA.html

MEDa99

Multimedia electronic Documents.  Viitattu 30.9.1999.  http://medoc.informatik.tu-muenchen.de/

MEDb99

Architektur des MeDoc-Dienstes: Geschäftsmodell und System. Viitattu 30.9.1999.  http://medoc.informatik.tu-muenchen.de/deutsch/projdescr/medocarch.html


 
 

Välittäjä-toimintaa on kehittämässä suurehko joukko erilaisia toimijoita. Euroopassa monet ohjelmat ja ryhmät on perustettu Euroopan komission ACTS ohjelman puitteissa.

ACTS ohjelman puitteissa toimivat tai ovat toimineet mm. seuraavat ohjelmat, joista on mainittu lyhenne ja ohjelman kotisivun osoite:

Lyhenne	Ryhmän nimi	verkko-osoite
ACTS	Advanced Communications and TechnologieS	http://www.uk.infowin.org/ACTS/
ABS	Architecture for Information Brokerage Service	http://b5www.deteberkom.de/ABS/
COBRA	Common Brokerage Architecture	http://www.octacon.co.uk/proj/cobra/
DIFFERENCE	Dissemination and Facilitation for European Research in Selected Chains	http://www.uk.infowin.org/ACTS/RUS/PROJECTS/ac207.htm
GAIA	Generic Architecture for Information Availability toimii nykyisin toimii yrityksenä	http:// www.syspace.co.uk/GAIA/
OSM	Open Service Model for Global Information Brokerage and Distribution  ryhmä on käyttänyt myös OMG/ONA (Object Management Group/ Open Network Architecture) standardeja ja ISO ODP (ISO/IEC 13235-1 ODP Trading Function ) standardeja.	http://www.osm.net/




Taulukko 1. ACTS-ohjelmia.

Lisäksi on olemassa muita foorumeita, joista mainitaan seuraavat:

• DAVIC, Digital Audio Visual Council, http://www.davic.org/ on kansainvälisen multimedian ja viihdeteollisuuden muodostama yhteenliittymä Sen tekemiä määrittelyjä ei ole tarkoitettu yleisiin verkkoihin vaan esimerkiksi käytettäviksi kulutuselektroniikan laitteissa. DAVIC on saanut työnsä päätökseen ja hyväksytty standardi on ISO/IEC 16500.
• TINA, Telecommunications Information Networking Architecture, http://www.tinac.com/, on yhteistyöelin, joka määrittelee avointa arkkitehtuuria telekommunikaation, multimedian ja tiedonvälityksen toiminta-alueille.