Yleiset vaatimukset

3.1.1. Yleistä

Ylimmällä tasolla sekä ebXML:n että RosettaNetin määrittelyt käsittelevät liiketoimintaprosessia kahden tai useamman osapuolen välisenä viestikoreografiana.

Alempien tasojen määrittelyt puolestaan pohjautuvat tähän näkökulmaan.

Lähestymistapa on siis hyvin prosessikeskeinen kuten myös itse prosessien suunnitteluvaihe. RosettaNet tarjoaa valmiita standardiprosesseja ja todennäköisesti vastaavia syntyy myös ebXML:ään.

Suunnitteluvaiheessa osapuolet määrittelevät toteutettavat liiketoimintaprosessit, niiden viestikoreografiat ja viestien sisällöt. Suunnitteluvaiheessa prosessien kuvaus on siis tasoa "A lähettää tilausviestin B:lle, joka vastaa siihen hyväksymis- tai hylkäysviestillä kolmen tunnin sisällä."

Toteutusvaiheessa jokainen osapuoli toteuttaa vain osa määritellystä prosessista omasta näkökulmastaan. Eli ym. esimerkkiprosessia käsitelläänkin omasta näkökulmasta:

"Vastaanotetaan tilausviesti, käsitellään se ja lähetetään vastaus." Koska ebFRENDS on yhden osapuolen järjestelmä, on ebFRENDSin lähdettävä tästä näkökulmasta.

3.1.2. Kerrosmalli

Sovellusintegraatio-ohjelmisto yhdistää organisaation erilliset sovellukset yhdeksi kokonaisuudeksi, jossa liiketoimintaprosessit voivat koostua eri sovelluksien suorittamista osista. Valmiin ohjelmiston etu räätälöityyn ratkaisuun verrattuna on valmiiden konnektorien ja jopa prosessimäärittelyiden avulla nopeutettu toteutusaika ja parempi ylläpidettävyys. Sovellusintegraatio-ohjelmiston tulisi tarjota vastaavat hyödyt myös verkkoliiketoimintaprotokollien toteutuksessa. Tämän saavuttamiseksi tulisi protokollien viestinsiirtomallit toteuttaa siten, että ne voidaan ottaa käyttöön mahdollisimman vähällä parametroinnilla. Lisäksi toteutettujen julkisten liiketoimintaprosessien (RosettaNetin PIP:it ja ebXMLrn BPS:it) uudelleenkäytön tulisi olla mahdollista.

Molempien protokollien rakenne voidaan jakaa erillisiin kerroksiin. Alimmalla tasolla, heti tiedonsiirtokerroksen päällä on viestiensiirtokerros. Sen päällä on liiketoimintakerros, joka suorittaa ns. julkista liiketoimintaprosessia.

Liiketoimintakerroksen päälle sijoittuu integraatiokerros, joka käsittelee liiketoimintaprosessia yrityksen näkökulmasta (ns. yksityinen liiketoimintaprosessi) ja integroituu yrityksen muihin järjestelmiin.

z 7 Z _

Integraatiokerros Integraatiokerros

/ /

Liiketoimintakerros Liiketoimintakerros

/ Prosessikohtainen viesti ^/

Viestinsiirtokerros Viestinsiirtokerros

/ <

ebXML/RN -kehys 7

Tiedonsiirtokerros Tiedonsiirtokerros

(HTTP/SMTP/...)

z

z

Kuva 9. ebXML. n ja RosettaNetin abstrakti kerrosmalli.

Kumpikaan protokolla ei määrittelyissään tee ylläolevan kaltaista jakoa vaan jakaa toteutuksen kolmeen osaan: Viestinsiirtopalveluun, viestirajapintaan ja liiketoimintasovellukseen. Tämä malli lähtee räätälöitujen toteutusten näkökulmasta, joissa sovellus on luotu suorittamaan tiettyjä liiketoimintaprosesseja ja käyttää itse

viestinsiirtopalvelua.

Tiedonsiirtokerros

Sekä RosettaNet että ebXML käyttävät tiedonsiirtoon oletusarvoisesti HTTP- protokollaa ja määrittelevät myös SMTP-protokollan käytön. Tiedonsiirtokerrokseen on siis toteutettava ainakin sekä HTTP-palvelin että -asiakas. SMTP-tukea varten tarvitaan SMTP-asiakas viestin lähetystä varten sekä POP- ja/tai IMAP-asiakas viestin vastaanottoon.

Olisi myös mahdollista toteuttaa SMTP-palvelin, mutta siitä ei todennäköisesti olisi lisäarvoa. Oletettavasti jokaisella toimijalla on käytössään joko oma SMTP-palvelin tai jonkun operaattorin ylläpitämä palvelin. Näin ollen SMTP:n käyttö siis muuttaa tiedonsiirtokuviota siten, että toteutuksessa ei ole palvelintoteutusta lainkaan vaan myös viestien vastaanotto tapahtuu clientilla. Tämän toteutus vaatii mekanismin, jonka avulla palvelimelta haetaan saapuneet viestit tasaisin väliajoin käsittelyä varten.

Viestinsiirtokerros

Viestinsiirtokerros huolehtii saapuvien viestien vastaanottamisesta ja lähtevien viestien välittämisestä oikeille vastaanottajille. Lisäksi kerroksen tehtävänä on todeta viestien oikeellisuus, purkaa mahdollinen salaus ja mahdollisesti myös autentikoida lähettäjä.

Viestinsiirtokerros tarjoaa liiketoimintakerrokselle sen tarvitsemat viestin lähetys- ja vastaanottopalvelut. Sen tehtävä on huolehtia oikeasta viestien kehystämisetä, osoitteistuksesta, koodauksesta ja siirtoprotokollasta. Viestinsiirtokerroksen ei ainakaan ideaalitapauksessa tarvitse tietää mitään suoritettavista liiketoimintaprosesseista. Se vain ottaa vastaan viestejä ja antaa ne ylemmälle tasolle käsiteltäviksi. Pystyäkseen toimittamaan viestit muille osapuolille, kerroksen on pystyttävä selvittämään osapuolen saapuvasta viestistä liiketoimintakerroksen ymmärtämä toisen osapuolen tunnus.

Vastaavasti kerroksen on lähtevän viestin tapauksessa sisäisen tunnuksen perusteella pystyttävä selvittämään vastaanottajan osoite, tiedonsiirtoprotokolla, salausavaimet jne.

Koska viestinsiirtokerroksen toteutusten kunnollinen yhteistoimivuus on ehdoton edellytys yhteistoiminnalle, on se myös tarkimmin kuvattu ja spesifioitu kerros molemmissa protokollissa.

Liiketoimintakerros

Liiketoimintakerros suorittaa julkista liiketoimintaprosessia eli toteuttaa osapuolten välille määriteltyä viestikoreografiaa. Sen on siis pidettävä huoli, että oikea viesti lähetetään tai saapuu oikeassa vaiheessa. Lisäksi sen on pystyttävä purkamaan viesteistä niiden sisältämä tieto integraatiokerroksen ymmärtämään muotoon sekä kasaamaan integraatiokerrokselta saatu tieto oikeanmuotoisiksi viesteiksi.

Liiketoimintakerros huolehtii julkisessa liiketoimintaprosessissa määritellyistä virhe-, kuittaus- ja aikarajakäsittelyistä. Koska liiketoimintaprosessien sallittu suoritusaika voi olla jopa vuorokausia, on liiketoimintakerroksen käytännössä toteutettava myös prosessien persistiivisyysominaisuuksia. Laite- tai ohjelmistovirheen vuoksi keskeytynyttä prosessia on mahdollisuuksien mukaan kyettävä jatkamaan automaattisesti.

Integraatiokerros

Integraatiokerros purkaa liiketoimintakerroksen tasolla, julkisessa liiketoimintaprosessissa, määritellyt abstraktit operaatiot Saijaksi sisäisiä toimenpiteitä.

Esimerkiksi "käsittele tilaus" -operaatio voi koostua asiakastietojen ja varastosaldon tarkastuksista ja päivityksistä sekä tilauksen luonnista tilausjärjestelmään.

Kumpikaan protokolla ei ota mitään kantaa integraatiokerrokseen. Räätälöidyissä ratkaisuissa viestinvälityskerroksen yläpuolista osaa ei todennäköisesti edes jaettaisi useampaan osaan. Integraatioalustaa luotaessa kerrokset on kuitenkin pyrittävä erittelemään. Samaa integraatiokerroksen toteutusta voidaan pienin muutoksin käyttää saman julkisen prosessin toteuttamiseen usealle eri osapuolelle. Integraatiokerroksen prosessit puolestaan ovat täysin riippuvaisia kunkin osapuolen sisäisistä järjestelmistä, niiden käyttötavoista ja muista käytännöistä.

Integraatiokerroksen on mahdollistettava päätösten varmistaminen käyttäjältä tarpeen niin vaatiessa. Esimerkiksi automaattisessa tilaustenkäsittelyssä voi olla, että joidenkin asiakkaiden tilaukset halutaan käsitellä manuaalisesti.

3.1.3. Yhteistoimintasopimukset

EbXML määrittelee joukon vaatimuksia yhteistyösopimukselle (EbXML CPA, Collaboration Partner Agreement). RosettaNetin versio 2 ei juurikaan ota kantaa näihin sopimuksiin (TPA, Trading Partner Agreement). RNEF2 mainitsee kuitenkin niiden tarpeellisuuden ja toteaa tämän puutteeksi. Seuraavaan versioon niiden määrittely onkin suunnitteilla.

Molemmissa protokollissa yhteistyösopimus ymmärretään sopimusoikeudellisesti sitovana. Se määrittelee ainakin osapuolten väliset sallitut liiketoimintaprosessit ja niiden tulkinnan. Myös liiketoimintaprosesseissa tehtyjä operaatiota (esim. tilaukset,

tarjoukset ja tarjouspyynnöt) voidaan, yhteistyösopimuksesta riippuen, rinnastaa paperilla tehtyihin vastaaviin operaatioihin ja pitää sitovina.

Jo puhtaasti laillisista syistä on siis tärkeää, että jokainen kerros pitää kirjaa vastaanotetuista sanomista ja niiden käsittelystä sekä tehdyistä operaatioista. Lisäksi esimeriksi vastaanotetut tilaukset mahdollisine sähköisine allekirjoituksineen on pystyttävä arkistoimaan paperisia tilauksia vastaavasti.

3.1.4. Suorituskykyvaatimukset

Toteutuksen on skaalauduttava siten, että uusien yhteistyökumppaneiden lisääminen olemassaolevien rinnalle on yksinkertaista. Käytössäolevan liiketoimintaprosessin roolin käyttöönotto uuden osapuolen kanssa tulisi parhaimmillaan vaatia vain osapuolikohtaisten tietojen lisäämisen.

Toteutuksen on kyettävä suorittamaan useita liiketoimintaprosesseja rinnakkain. On oltava mahdollista suorittaa useampaa saman liiketoimintaprosessin instanssia yhtäaikaa. Myös saman osapuolen kanssa on kyettävä suorittamaan useampaa liiketoimintaprosessin instanssia rinnakkain.

Verkkoliiketoimintaprotokollien prosessien oletetaan kestävän tunteja taijopa päiviä.

Näin ollen viestinsiirrron ja viestienkäsittelyn nopeudelle ei ole kovinkaan suuria suorituskykyrajoja. Luonnollisesti toteutuksen on kuitenkin pyrittävä olemaan mahdollisimman tehokas näiltäkin osin.

3.1.5. Virhetilanteiden käsittely

Alimmalla tasolla siirtoprotokolla (esim. HTTP) hoitaa havaitsemansa siirtovirheet protokollan määrittelyjen mukaisesti. Liiketoimintaprosessi määrittelee viestien purkamisessa (tiedonsiirtokerroksessa) tapahtuvien virheiden käsittelyn. Käsittely on aina viestin hylkäys sekä mahdollisesti poikkeusviestin lähetys lähettäjälle. Viestejä lähetettäessä on tiedonsiirtokerroksen pystyttävä hoitamaan uudelleenlähetykset sekä ajastetusti että vastaanotettujen poikkeusviestien niin vaatiessa. Mikäli poikkeusviesti ilmoittaa hylkäyksen johtuvan itse viestistä eikä esim. siirtovirheestä, tulisi liiketoimintakerrosta ja käyttäjää pystyä informoimaan asiasta.

Liiketoimintaprosessi voi määritellä sovellustason virhetilanteiden käsittelyn, joka on kyettävä toteuttamaan. Tällainen käsittely on yleensä liiketoimintaprosessin keskeytys ja mahdollisesti virhekoodin palautus toiselle osapuolelle ja/tai virheen raportointi käyttäjälle. Virhetilanne voi myös vaatia jonkun toisen liiketoimintaprosessin käynnistämistä.

Integraatiokerros voi sisältää omaa virheenkäsittelyään mutta sen on myös kerrottava liiketoimintakerrokselle virheistä. Tällaisessa tilanteessa liiketoimintakerros päättää, liiketoimintaprosessista riippuen, kuinka virhe on käsiteltävä.

Yhden liiketoimintaprosessin suoritus voi kestää useita tunteja, varsinkin jos prosessi vaatii toimenpiteitä käyttäjältä. Myös yksittäisistä siirtovirheistä toipuminen voi viedä, jopa täysin automaattisissakin liiketoimintaprosesseissa, pitkiäkin aikoja sillä

esimerkiksi RosettaNetissä viestin uudelleenlähetysaika mitataan tunneissa [2]. Tästä syystä järjestelmän tulisi pystyä jatkamaan sellaisia keskeytyneitä liiketoimintaprosesseja, joiden keskeytyminen johtui itse prosessista riippumattomista syistä, kuten esimerkiksi järjestelmän uudelleenkäynnistyksestä. Tämän toteuttaminen vaatii suoritettavien liiketoimintaprosesien tilan säilyttämistä persistiivisessä tietovarastossa, josta viimeinen tallennettu tila voidaan tarvittaessa palauttaa.