T-86.5161 Special Course in Information Systems Integration

HELSINKI UNIVERISITY OF TECHNOLOGY Department of Computer Science and Engineering Software Business and Engineering Institute T-86.5161 Special Course in Information Systems Integration The messaging choreographies for B2B integration Yritystenvälisten sanomanvälitysstandardien vertailua Project Report January 16th, 2007 Mommo, Esa Pihlaja, Markus Vesterinen, Pauli

Tiivistelmä Yritysten väliseen integraatioon on kehitetty useita standardeja. Nämä standardit määrittelevät erilaisia asioita hyvin eri tavoilla. Yleisesti ottaen standardit määrittelevät kuljetuskerroksen, kuljetettavien viestien rakenteen ( kirjekuoren ) sekä mahdollisesti kokoelman yritystenvälisiä prosesseja, jotka käyttävät välitettäviä viestejä. Jotta tietoa kuitenkin voidaan välittää yritysten välillä, täytyy yritysten sopia keskenään mitä standardeja käytetään ja millä tavalla. Tämän työn tarkoituksena on esitellä ja verrata erilaisia ratkaisuja, jotta suomalaiset pienet ja keskisuuret yritykset saavat tietoa eroista ja voivat valita itselleen parhaiten sopivan. Tutkimuksessa verrattiin kolmea yleistä vaihtoehtoa HTTP-pohjaiseen viestinvälitykseen: ebxml-perheeseen liittyvää ebms-standardia (electronic business Messaging System), RosettaNetin RNIF-standardia (RosettaNet Implementation Framework) ja lähinnä EDIsanomien välittämiseen käytettyä AS2-standardia (Applicability Statement 2). Vertailussa keskityttiin standardien tekniseen toteutukseen, välitettyihin otsikkotietoihin, tarjottuun toiminnallisuuteen sekä signalointitapoihin. Lisäksi tehtiin nopea katsaus standardien ohjelmistotukeen. Vertailussa huomattiin selkeästi se että jokainen standardi on tehty eri lähtökohdista käsin. AS2 on suunniteltu EDI-viestien siirtämiseen HTTP-yhteyden yli, mutta myös muuta dataa voidaan kuljettaa. RNIF kytkeytyy tiukasti muuhun RosettaNet -standardiin ja muiden kuin RosettaNet-viestien kuljettamiseen on hankalaa. EbMS on luonteeltaan yleisempi vaikka sekin on suunniteltu käytettäväksi ebxml -viestien kanssa. Käytettävän standardin valinta on monitahoinen, strateginen päätös johon vaikuttavat yrityksen toimiala, yhteistyökumppanit sekä olemassa olevat tietojärjestelmät. ii

Abstract Many standards have been developed for business-to-business integration. Different standards define various aspects in very different ways. In general, the standards define a transport layer, structure of transported messages (envelope) and possibly a collection of inter-company processes that use the transported messages. To be able to transport information between companies they must agree between themselves what standards are to used and in what ways. The purpose of this work is to introduce and compare different solutions so that Finnish small and medium sized companies could compare them and choose the best one for them. Three common alternative standards for HTTP-based integration were compared : ebms (eb Messaging System) that is part of the ebxml-family, RNIF (RosettaNet Implementation Framework) of RosettaNet suite, and AS2-standard (Applicability Statement 2) that is mainly used to transport EDI-messages. The comparison concentrated on the technical choices of the standards, message headers delivered, supported functionality and signalling methods supported. In addition, a short overview of the software support for each standards was made. The basis of each standard is different. AS2 has been designed to transport EDI-messages over HTTP connection, but other data can be transported as well. RNIF is tightly integrated with the rest of the RosettaNet and transporting other than RosettaNet messages is cumbersome. ebms is a more general standard in nature, even though it is designed to be used with ebxml-messages. The choice of which standard to use is a complicated one, with strategic implications. The main factors to consider are the line of business, collaboration partners and the existing data systems in use. iii

Sisällysluettelo Tiivistelmä... ii Abstract... iii Kuvaluettelo... vii Taulukkoluettelo... viii 1 Johdanto... 1 1.1 Taustaa... 1 1.2 Tavoitteet...1 1.3 Tutkimuskysymykset... 2 1.4 Tutkimuksen laajuus... 2 1.5 Tutkimusmenetelmät... 3 1.6 Sanasto... 3 1.7 Raportin rakenne... 4 1.8 Aikataulu...5 2 Yleisesittely... 7 2.1 RosettaNet Implementation Framework... 8 2.2 ebms (ebxml Messaging Service)... 9 2.3 AS2... 10 3 Tekninen vertailu... 12 3.1 RNIF... 12 3.2 EbMS... 13 3.3 AS2... 14 3.4 Yhteenveto... 14 iv

4 Tietosisältöjen vertailu... 16 4.1 RNIF... 16 4.2 EbMS... 18 4.3 AS2... 23 4.4 Yhteenveto... 25 5 Toiminnallisuus... 27 5.1 RNIF... 27 5.2 EbMS... 31 5.3 AS2... 32 5.4 Yhteenveto... 35 6 Signalointi... 38 6.1 RNIF... 38 6.2 EbMS... 42 6.3 AS2... 43 6.4 Yhteenveto... 44 7 Ohjelmistotuki... 45 7.1 RNIF... 45 7.2 EBMS... 46 7.3 AS2... 48 7.4 Yhteenveto... 50 8 Johtopäätökset ja pohdinnat... 51 8.1 Yleistä... 51 8.2 Yhteensopivuudesta... 51 8.3 Operaattorimalli... 52 v

8.4 Lopuksi... 53 9 Yhteenveto... 55 10 Lähdeluettelo... 57 vi

Kuvaluettelo Kuva 2.1 Esimerkki - tyypillinen B2B -tapahtuma... 8 Kuva 4.1 RNIF-viestin rakenne (RosettaNet 2002)... 17 Kuva 4.2 RNIF-viestin allekirjoitus (RosettaNet 2002)... 17 Kuva 4.3 EbMS-viestin rakenne (OASIS 2002)... 19 Kuva 4.4 EbXML otsikko (OASIS 2002)... 20 Kuva 4.5 MIME-otsikko (OASIS 2002)... 20 Kuva 4.6 Lähetettävän sanoman MIME-otsikko (OASIS 2002)... 21 Kuva 5.1 RNIF viestin allekirjoitus (RosettaNet 2002)... 29 Kuva 5.2 RNIF viestin salaus, luodaan Encrypted Payload Container (RosettaNet 2002)... 30 Kuva 5.3 RNIF-viestin salaus, salaamattomat otsikkotiedot paketoidaan salatun osion kanssa (RosettaNet 2002)... 30 Kuva 5.4 AS2 koreografia ja orkestrointi (Seeburger 2005)... 34 Kuva 6.1 Yksitapahtumainen asynkroninen prosessi jossa lähetetään yksi liiketoimintaviesti ja sen kuittaus (RosettaNet 2002)... 40 Kuva 6.2 Kaksitapahtumainen asynkroninen prosessi jossa ensimmäinen liiketoimintaviesti kuitataan ja lähetetään vastausviesti joka myös kuitataan (RosettaNet 2002)... 41 vii

Taulukkoluettelo Taulukko 3.1 B2B sanomanvälitysstandardien tekninen vertailu... 15 Taulukko 4.1 Yhteenveto tietosisällöistä... 26 Taulukko 5.1 Yhteenveto eri standardien tukemista toiminnallisuuksista... 37 Taulukko 6.1 Yhteenveto signalointiominaisuuksista... 44 Taulukko 7.1 EbMS-ohjelmistojen tarjoajia (EbXML Forum 2004)... 47 Taulukko 7.2 Standardeja tukevien ohjelmistojen lukumääriä... 50 viii

1 Johdanto 1.1 Taustaa B2B (yritysten välinen kaupankäynti) -integrointi perustuu tiedon toimittamiseen yritykseltä toiselle. Ennen kuin voidaan edes ajatella sanomien semantiikkaa tai prosessikoreografioita täytyy olla olemassa tapa lähettää sanomia yhdeltä osapuolelta toiselle sovitussa formaatissa. Useimmat B2B-integrointistandardit määrittävät omat kuljetusmekanisminsa ja sanomaformaattinsa. Nämä mekanismit voivat olla mitä tahansa perinteisen puhelinlankaa pitkin välitettävän datasiirron ja vaikka JMS:n (Java Message Service) päällä olevan SOAP-kirjekuoren (Simple Object Access Protocol) välillä. Saatavilla on monia erilaisia B2B-integrointistandardeja ja tällä hetkellä yksikään niistä ei ole saavuttanut niin merkittävää asemaa ja markkinaosuutta, että sitä voitaisiin sanoa johtavaksi standardiksi. Monillakaan pienillä tai keskisuurilla yrityksillä ei ole yksinkertaisesti resursseja ottaa käyttöön useampia kuin korkeintaan yksi näistä standardeista. Tämän takia monet pienet ja keskisuuret yritykset odottavat kuinka markkinat kehittyvät ennen kuin tekevät päätöksiä standardien valinnan suhteen. Tämän työn tarkoituksena on vertailla useita erilaisia standardeja keskenään pyrkimyksenä selvittää miten ne eroavat toisistaan ja mitä yhteistä niillä on. Lisäksi on tarkoitus selvittää mitä piirteitä eri standardit pitävät sisällään ja minkälaisia mahdollisuuksia on olemassa eri standardien yhteensopivuuden kannalta. 1.2 Tavoitteet Tämän työn tavoitteena on auttaa suomalaisia pieniä ja keskisuuria yrityksiä valitsemaan B2B -integrointi standardinsa niin että se sopii mahdollisimman hyvin heidän tarpeisiinsa tällä hetkellä ja että valinta ei myöskään tulevaisuudessa rajoita toimintaa. 1

Tavoite pyritään saavuttamaan vertailemalla useita tunnettuja sanoma -viestintäkehyksiä, kuten RNIF (RosettaNet Implementation Framework), ebms (Electronic Business Messaging service) ja AS2 (Applicability Statement 2), useista eri näkökulmista. Tässä työssä vertailuun käytettyjä näkökulmia ovat tekninen, tietosisältö, toiminnallisuus, signalointi ja ohjelmistotuki. 1.3 Tutkimuskysymykset Työn onnistumisen kannalta on tärkeää olla selkeä ja ymmärrettävä ongelman asettelu ja hyvin rajatut kysymykset joihin pyritään vastaamaan. Epämääräinen aihe voi johtaa huonoihin tuloksiin, joista ei ole hyötyä kenellekään. Tutkimuksen apuna ovat tutkimuskysymykset, joihin työssä pyritään vastaamaan. Näiden kysymysten avulla tutkimustyön tavoitteiden saavuttaminen on helpompaa. Tämän tutkimuksen apuna ovat seuraavat tutkimuskysymykset: Mitkä ovat tarkasteltujen standardien tekniset, toiminnalliset sekä sisällölliset eroavaisuudet? Jos yritys harkitsee ottavansa käyttöön jonkin näistä standardeista, millaisia asioita kannattaa ottaa huomioon valintaa tehdessä? Millaisia standardeja toteuttavia tuotteita on markkinoilla? 1.4 Tutkimuksen laajuus Tämä tutkimus keskittyy tarkastelemaan B2B-standardeja RNIF, ebms sekä AS2 asiakkaan, TIEKE:n (Tietoyhteiskunnan kehittämiskeskus ry.), toiveiden mukaisesti, kuitenkin rajoittuen HTTP-protokollaan. Nämä kolme standardia on valittu vertailuun asiakkaan toivomuksesta. Muita siirtoprotokollia, kuten SMTP tai FTP, ei tarkastella standardien yhteydessä. Tutkimus esittelee näistä standardeista lyhyen yleisesittelyn, toiminnallisuusvertailun, teknisten ominaisuuksien vertailun ja tietosisältöjen sekä signalointien vertailun. Myös tuotteita, jotka toteuttavat näitä standardeja, esitellään lyhyesti. 2

1.5 Tutkimusmenetelmät Tutkimus toteutetaan kirjallisuuskatsauksena Kirjallisuuskatsaus pyrkii vastaamaan esitettyihin tutkimuskysymyksiin sekä esittelemään standardit eri näkökulmista katsottuna. Kirjallisuuskatsauksen luonne on väkisinkin jossain määrin pinnallinen ja kevyt, koska tutkimuksen laajuus on niin suuri asiakkaan toivomusten mukaisesti. Tutkimuksen lähtökohdista johtuen lähteinä kirjallisuuskatsaukseen ovat ensisijaisesti standardien spesifikaatiot ja näiden määrittelijätahojen dokumentit. Näiden lisäksi on pyritty käymään läpi erilaisia akateemisia julkaisuja. 1.6 Sanasto Jotta ymmärtäisi B2B liiketoimintaa ja tätä raporttia, on tärkeää että keskeisimmät termit ylipäätään ymmärretään ja ymmärretään samalla tavalla. Tällöin estetään mahdolliset väärinkäsitykset tai epäselvyydet aihepiiriä tarkasteltaessa. Tähän kappaleeseen on kerätty eräitä tärkeimpiä raportissa esiintyviä termejä ja lyhenteitä. AS2 Applicability Statement 2, spesifikaatio datan siirtämiseen turvallisesti ja luotettavasti Internetin kautta. (RFC 4130) B2B Business to business, yritysten tai organisaatioiden välinen kaupankäynti. (Wikipedia 2006b) CMS Cryptographic Message Syntax. (Wikipedia 2006c) De Facto Kyseisellä toimialalla käytetty, vakiintunut menettelytapa tai standardi. (Wikipedia 2006d) DTD Document Type Definition, määrittelee XML -dokumentin rakenteen ja sallitut elementit dokumentissa. (W3Schools 2006). EbMS EbXML Messaging Service, sähköisen kaupankäynnin standardi, joka määrittelee XML-viestejä käyttävän sanomanvälityspalvelun (OASIS 2002) EbXML Electronic Business Extensible Markup Language. (OASIS 2002) EDI Electronic Data Interchange, sähköinen tiedonsiirtotapa. (Tieke 2006) EDIINT EDI over the Internet, EDI käyttäen Internetiä. (Wikipedia 2006e) HTTP Hypertext Transfer Protocol. Hypertekstin siirtoprotokolla, jota selaimet ja WWW-palvelimet käyttävät tiedonsiirtoon (Wikipedia 2006f) HTTPS HTTP:n suojattu versio. (Wikipedia 2006g) JMS Java Message Service, Java-pohjainen sanomanvälitys standardi. (Wikipedia 2006h) Koreografia Organisaatioiden välisten liiketoimintaprosessin 3

tapahtumien keskinäinen järjestys ja kuvaus. (O Reilly 2006) MD5 Hash-algoritmi. Viestitiivistealgoritmi (Wikipedia 2006i) MDN Message Disposition Notification, vahvistus lähettäjälle. (RFC 4130) MIME Multi-Purpose Mail Extension, sähköpostin liitetiedostomäärittely. (Wikipedia 2006j) MSH Message Service Handler, toteutetun ebms:n viestikäsittelijä, vastaanottaa viestejä. (OASIS 2002) Orkestrointi Organisaation sisäisten liiketoimintaprosessien tapahtumien keskinäinen järjestys ja kuvaus. (O Reilly 2006) PIP Partner Interface Process. (RosettaNet 2002) PKCS Public-Key Cryptography Standards, salausmenetelmiä julkiseen avaimeen perustuen. (Wikipedia 2006k) RFC Request For Comments, asiakirjoja, jotka kuvaavat Internetin erilaisia teknisiä käytäntöjä. (Wikipedia 2006l) RNIF Rosettanet Implementation Framework, B2B -integrointi standardi. (RosettaNet 2002) S/MIME Secure MIME, määrittelee suojatun MIME:n.(Wikipedia 2006m) SHA-1 Tiivistealgoritmi. (Wikipedia 2006n) SMTP Simple Mail Transfer Protocol, sähköpostiprotokolla. (Wikipedia 2006o) SOAP Simple Object Access Protocol, protokolla tiedonsiirtoon, käyttää XML:ää. (Wikipedia 2006p) UN/EDIFACT United Nations/Electronic Data Interchange For Administration, Commerce, and Transport, YK:n määrittelemä EDI standardi. (Wikipedia 2006e) X.509 Standardi määrittelemään digitaalinen sertifikaatti. (Wikipedia 2006q) XML Extensible Markup Language. XML-kieli on metakieli, eli kieli jolla voidaan kuvata toisia kieliä. (Wikipedia 2006r) XML Signature XML dokumentin allekirjoitusmenetelmä. (Wikipedia 2006s) 1.7 Raportin rakenne Tämä tutkimusraportti jakautuu seuraavasti eri kappaleisiin: 1. Johdanto. Tämä kappale sisältää taustatietoa tutkimuksesta, tavoitteet, tutkimusta ohjaavat tutkimuskysymykset, laajuuden, käytetyt menetelmät, sanaston, raportin rakenteen kuvauksen sekä tutkimuksen aikataulun. 2. Yleisesittely. RNIF, ebms sekä AS2 standardien yleisesittelyt. 3. Tekninen vertailu. Teknisten ominaisuuksien vertailu sekä erilaisten 4

standardien, kuten SOAP tai XML, käyttö tarkasteltavissa standardeissa. 4. Tietosisältöjen vertailu. Standardien kuljetuskehyksessä olevien tietojen, kuten otsikkosisältöjen sekä viestien perusrakenteiden vertailu. 5. Toiminnallisuus. Standardien toiminnallisuus, kuten virheraportointi ja turvallisuus sekä standardin soveltuvuus koreografian vai orkestroinnin määrittelyyn. 6. Signalointi. Standardien signalointimenettelyjä, kuten kuittausviestikäytännöt. 7. Ohjelmistotuki. Standardeja tukevia ohjelmistoja on listattu tässä kappaleessa. 8. Johtopäätökset ja pohdinnat. Tutkimuksen johtopäätösten esittely. 9. Yhteenveto. 1.8 Aikataulu Tutkimus tehtiin TKK:n Ohjelmistotuotannon ja -liiketoiminnan laboratorion kurssilla T- 86.5161 Tietojärjestelmien integroinnin erikoiskurssi syksyllä 2006. Tutkimuksen tekemisessä noudatettiin kurssin asettamia aikarajoja. Nämä kurssin asettamat aikarajat on alla lihavoitu. TIEKE:n (Tietoyhteiskunnan kehittämiskeskus ry.) edustajan kanssa yhteisiä tapaamisia on pidetty noin kerran viikossa. 5.10 Projektisuunnitelma valmis 5-20.10 Taustatutkimusta ja kirjallisuuskatsaus 24.10 Yleiskatsaukset standardeihin 31.10 Tekniset katsaukset 6.11 Toiminnalliset katsaukset 8.11 Teknisen vertailun koonti ja kappaleen kirjoitus 8.11 Signalointikatsaukset 10.11 Yleiskatsausten koonti ja kappaleen kirjoitus 5

10.11 Toiminnallisen vertailun koonti ja kappaleen kirjoitus 10.11 Ohjelmistotukikatsaukset 12.11 Signalointivertailun koonti ja kappaleen kirjoitus 13.11 Ohjelmistotukivertailun koonti ja kappaleen kirjoitus 14-15.11 Raportin kokoaminen ja asettelu 16.11 Ensimmäinen versio valmis 21.11 Ensimmäisen version katselmointi 7.12 Raportti 95 % valmis 12.12 Raportin katselmointi 16.1.2007 Tutkimuksen esittely seminaarissa 6

2 Yleisesittely Jotta pystyisi tekemään valintoja eri standardien välillä, on myös ymmärrettävä ainakin yleisellä tasolla mistä missäkin standardissa on kyse. On hyvä tietää kenen julkaisijan toimesta ko. standardi on tehty ja mitä se pääpiirteissään tarkoittaa. Esimerkkinä tyypillisestä B2B-integrointitapahtumasta voidaan nähdä tilaus, joka on esitetty kuvassa 2.1. Ensin taustajärjestelmä lähettää sanoman BPM-ohjelmistolle (Business Process Management), joka muodostaa siitä standardin toteuttavan sanoman (salaus, allekirjoitus, yms.). Seuraavaksi sanoma lähetetään vastaanottajalle internetin (HTTP(S)) yli. Vastaanottajan BPM-ohjelmisto varmentaa sanoman ja muodostaa vastaanottajan taustajärjestelmän ymmärtämän sanoman, joka lähetetään vastaanottajan taustajärjestelmälle. Seuraavaksi muodostetaan kuittaussanoma ja se lähetetään alkuperäiselle lähettäjälle internetiä käyttäen. Lopuksi alkuperäinen lähettäjä varmentaa sanoman perillemenon kuittaussanomasta. Vertaillut standardit toteuttavat kuvassa esiintyvistä toiminnoista viestin lähetyksen ja tarkistuksen sekä kuittauksen muodostamisen, lähetyksen ja vastaanoton. 7

Kuva 2.1 Esimerkki - tyypillinen B2B -tapahtuma 2.1 RosettaNet Implementation Framework RosettaNet on voittoa tuottamaton järjestö, jonka tehtävänä on ohjata liiketoimintaprosessien standardointia. RosettaNet-standardi käsittää yritystenväliset standardiprosessit (Partner Interface Process, PIP), näihin liittyvät viestit, sana- ja koodikirjat yhteisen termistön ja koodiston luomiseksi sekä RNIF (RosettaNet Implementation Framework) sanomavälityspalvelustandardin (RosettaNet, 2006). Standardin osista vain RNIF käsitellään tässä vertailussa. 8

RNIF määrittelee sekä prosesseihin liittyvien liiketoimintaviestien että signalointiviestien lähettämiseen. Eri liiketoimintaviestit on määritelty omassa standardissaan. Signalointiviestejä on kahta päätyyppiä, positiivisia ja negatiivisia. Nämä vastaavat sitä että vastaanottaja ymmärsi tai ei ymmärtänyt vastaanotettua sanomaa. RNIF tukee sekä viestinvälitystä suoraan osapuolelta toiselle tai keskitettyä mallia jossa kaikki viestit lähetetään operaattorille joka reitittää viestin sen lopulliseen määränpäähän. (RosettaNet, 2002, s. 11 ja 58) Viestien luottamuksellisuus voidaan varmistaa salakirjoittamalla ne. Myös osapuolten välinen autentikointi ja kiistämättömyys ovat tuettuja. 2.2 ebms (ebxml Messaging Service) OASIS -organisaation määrittelemä ebms, (Electronic Business extensible Markup Language (XML) Messaging service), on sähköisen kaupankäynnin standardi, joka määrittelee XML-viestejä käyttävän sanomanvälityspalvelun. EbMS on yksi OASISorganisaation spesifikaatioista, jotka yhdessä pyrkivät luomaan yhtenäisen, keskitetyn ja sähköisen kauppapaikan yrityksille, käyttäen XML -viestejä. Yksi ebms:n eduista on, että se on lähes riippumaton kommunikointiin käytettävästä siirtoprotokollasta, jolloin ebms- viestit voidaan lähettää esimerkiksi HTTP:tä käyttäen. Ainoana rajoituksena on, että siirtoprotokolla tukee SOAP-viestien lähetystä. EbMS spesifikaatio määrittelee viestien kuljetuksessa käytetyn "kirjekuoren", joka sisältää lähetettävän viestin. EbMS:n käyttämän kirjekuori on tarkoitettu toimimaan käyttäen SOAP:ia (Simple Object Access Protocol), josta johtuen myös liitynnät alempiin kuljetuskerroksiin on toteutettu käyttäen SOAP-liityntöjä. Lisäksi ebms-määritelmään kuuluvat käytetyt toiminnot sanomanvälitykseen sekä itse protokolla. Turvallisuus sanomanvälityksessä on määritelty viestien salauksella, tunnistamisella sekä viestien yhtenäisyydellä. Tunnistamiseen käytetään apuna digitaalisia sertifikaatteja, 9

salaus hoidetaan julkisten ja yksityisten avainten avulla. Viestien välityksessä käytetään saanti-ilmoituksia, joilla varmistetaan että viestit menevät perille. Yksi tärkeimmistä eduista ebms sanomanvälitysmenetelmää käytettäessä on älykkäiden ebxml -otsakkeiden tuki, mistä on suuri hyöty yrityksille jotka käyttävät jo ebxml:ää. Myös yritykset, jotka eivät käytä ebxml:ää, voivat käyttää ebms:ää, sillä ebms luo tarvittavat otsakkeet viesteihin. Eduiksi voidaan myös mainita useiden liitteiden lähettäminen yhdellä kertaa, sillä liitteet pakataan hyötykuormaksi viesteihin. 2.3 AS2 "Applicability Statement 2", lyhennettynä AS2, on spesifikaatio datan siirtämiseen turvallisesti ja luotettavasti Internetin kautta. Se on kuvattu yksityiskohtaisesti RFC:ssä (The Requests for Comments) 4130. AS2:een viitataan usein EDIINT:nä ("EDI over the Internet") tai AS2 EDIINT. Pääideana AS2:ssa on laittaa EDI tiedosto AS2 kirjekuoreen ja sitten lähettää se Internetin yli käyttäen HTTP POST pyyntöä. Turvallisuus saavutetaan käyttämällä digitaalisia sertifikaatteja ja kryptausta. AS2 määrittää miten otetaan yhteys, toimitetaan ja kuitataan data. Yleensä lähetetään EDI-sanomia (Electronic Data Interchange), mutta sanomat voivat olla myös esimerkiksi XML:ää. AS2 siis yleensä tarkoittaa EDItiedostojen lukemista ja kirjoittamista AS2 sanomista, mutta myös AS2 sanomien validitointa ja kuittaamista. AS2 toteutus on siis asiakas-palvelin ratkaisu ja asiakas ja palvelin keskustelevat toistensa kanssa Internetin välityksellä. Käyttöjärjestelmätasolla AS2 asiakas voi olla palvelin jollekin sovellus ohjelmistolle. Asiakas lähettää dataa palvelimelle, esimerkiksi jollekin kauppakumppanille. Kuittauksena sanomasta vastaanottava sovellus lähettää vahvistuksen, MDN:n (Message Disposition Notification), takaisin lähettäjälle. AS2 kehitettiin vuonna 1999 EDI standardi -yhteisön jäsenien toimesta tarkoituksena 10

käyttää internetiä toimitusväylänä (EDIINT). AS2 standardi perustuu voimakkaasti aikaisempiin EDI toimintatapoihin ja EDI-tyyppisten sanomien toimittamiseen. Useat toimittajat ovat tehneet yhteensopivia tuotteita, jotka käyttävä AS2:sta sanomanvälitykseen ja ne ovat tarkoitettuja käytettäväksi EDI -järjestelmien kanssa. USA:ssa AS2 on yleisesti käytetty standardi e-bisneksessä, erityisesti vähittäismyyjien toimesta ja niiden yhtiöiden jotka tarvitsevat turvallisia standardeja. Suuri vähittäismyyntiketju Wal-Mart's on aloittanut AS2:n käytön vuonna 2002 (Computerworld 2002), myös monet muut suuret USA:laiset yhtiöt käyttävät AS2:sta. 11

3 Tekninen vertailu Tekninen vertailu on erityisen tärkeää siksi että yritykset voisivat tehdä järkeviä päätöksiä perustuen siihen mitä standardeja tietyt B2B -integrointi standardit tukevat. Koska ensinnäkin luonnollisesti on tärkeää se mikä on ko. liiketoiminta-alan yleisimmin käytetty (de facto) standardi B2B-integroinnissa, mutta myös se mitä standardeja jo kulloisenkin yrityksen taustajärjestelmät käyttävät. Esimerkkinä voisi ajatella, että jos jonkun yrityksen sisäiset järjestelmät käyttävät keskinäiseen tiedonsiirtoon XML -sanomia niin olisi hyvä jos B2B -integroinnissa käytettävä standardikin tukisi XML -formaattia. Tässä kappaleessa käydään läpi RNIF, ebms ja AS2 standardien käyttämät standardit. Ensin esitellään lyhyesti jokaisen standardin käyttämät standardit ja lopuksi tehdään yhteenveto käytetyistä standardeista vertailun helpottamiseksi. 3.1 RNIF RNIF:ssä lähetettävä viesti kääritään MIME-kuoreen, jonka sisällä viestin eri otsikkokentät ovat omia XML-dokumenttejaan. Myös viestin varsinainen liiketoimintasisältö on yleensä XML-dokumentti, tosin se voi joissain tapauksissa olla myös muussa muodossa mikäli näin prosessikuvauksessa (PIP) määritellään. Viestin mukana lähetettävät liitteet voivat sisältää mitä tahansa dataa missä tahansa muodossa. XML-muotoisten viestien määrittelyt ovat yleensä DTD-muodossa, mutta myös XML Schema -muotoisia kuvauksia voidaan käyttää. Viesteissä käytettävän merkistön tulee olla UTF-8 tai UTF-16. (RosettaNet, 2002, s. 15) Siirtomuotoina RNIF käyttää HTTP:tä tai SMTP:tä. Mikäli viesti halutaan salata tai allekirjoittaa se voidaan tehdä S/MIME ja PKCS protokollia käyttäen. Viesti voidaan salata myös siirron aikana käyttäen HTTPS-siirtomuotoa ja X.509 sertifikaatteja. Sertifikaattien avulla voidaan myös toteuttaa lähettäjän ja vastaanottajan 12

välinen autentikointi. (RosettaNet, 2002,s. 34-37) 3.2 EbMS EbMS on suunniteltu olemaan siirtoprotokollasta riippumaton ja kuljettamaan minkä tyyppisiä viestejä tahansa. Lähetettävät sanomat voivat olla mitä tahansa digitaalisessa muodossa, kuten esimerkiksi XML tiedostoja, tietokannan tauluja tai EDI viestejä. Lähetettävät sanomat pakataan ebxml objektiksi, joka sitten lähetetään. (OASIS 2002) EbMS on rakennettu SOAP-protokollan päälle kerroksittaiseksi. Koska ebms spesifioitiin neutraaliksi siirtoprotokollan suhteen, voidaan käyttää mitä tahansa siirtoprotokollaa. Koska ebms käyttää SOAP:ia ja SOAP Attachments (Liitteet) pohjanaan, tukee ebms kaikkia siirtoprotokollia, joita SOAP tukee. (OASIS 2002) EbXML viesti rakentuu siten, että ulommaisena kirjekuorena on SOAP Attachments, joka käyttää Multipurpose Internet Mail Extensions (MIME):a. Tämän kirjekuoren sisällä on vähintään kaksi MIME osaa, joista toinen on SOAP (version 1.1) yhteensopiva viesti. Seuraavat MIME osat sisältävät varsinaisen lähetettävän sanoman. Ensimmäinen MIME osa, SOAP -viesti, on XML-dokumentti, jossa on SOAP-viestin kirjekuori-osa. (OASIS 2002) EbMS sanomanvälitys käyttää edellä kuvatun mukaisesti siis alustanaan SOAP:ia. Tämän lisäksi XML-dokumenteja käytetään kaikissa viesteissä, kuten myös MIME:a. Siirtoprotokollana voidaan käyttää esimerkiksi HTTP-protokollaa tai SMTP-protokollaa sekä mitä tahansa, jota käyttäen SOAP toimii. Luotettavaan viestien välitykseen voidaan käyttää XML Signature -menetelmää, jolloin ebxml-viesti allekirjoitetaan digitaalisesti. Viestien eheys voidaan varmistaa käyttämällä jotain salausmenetelmää, kuten XML Encryption tai S/MIME. (OASIS 2002) 13

3.3 AS2 AS2:ssa data pakataan käyttämällä normaaleja MIME-rakenteita. AS2:sta käytetään rakenteellisen bisnes-datan siirtämiseen Internetin välityksellä eri kauppakumppanien välillä. Rakenteellinen liiketoiminta -data voi olla XML:ää, EDI:ä ANSI EDI-X12 formaatissa tai UN/EDIFACT formaatissa tai melkeinpä missä tahansa muussa rakenteellisessa formaatissa. (RFC 4130) Dataa siirretään käyttämällä HTTP-protokollaa tai HTTPS-protokollaa, AS2:n edeltäjässä Applicability Statement 1 (AS1) käytetään taas SMTP-protokollaa. AS2-viesti voi olla tyyppiä MIME Security Multiparts, se voi olla moniosa/kryptattu ja moniosa/allekirjoitettu. AS2:ssa MDN (Message Disposition Notification) on pohja, jonka päälle kuittaukset ja allekirjoitetut kuittaukset määritetään. (RFC 4130) AS2 mahdollistaa turvallisen MIME:n (S/MIME) käytön, eli formaatin ja protokollan kryptatun allekirjoituksen ja/tai kryptaus palvelujen lisäämisen Internetin MIMEsanomiin. CMS (Cryptographic Message Syntax) kapselointi syntaksia käytetään mielivaltaisen sanoman digitaaliseen allekirjoitukseen, tiivistelmään, autentikointiin tai kryptaukseen. (RFC 4130) Digitaalisen allekirjoituksen yhteydessä käytettävä hash-algoritmi SHA-1, jota myös suositellaan käytettävän AS2:n yhteydessä. Tosin myös MD5 hash-algoritmi on sallittu AS2:ssa käytettäväksi digitaalisen allekirjoituksen yhteydessä. (RFC 4130) 3.4 Yhteenveto Kaikki standardit tukevat lähetettävän sanoman tyyppinä XML:ää, mutta myös EDI on hyvin tuettu. Yhteenvetona lähetettävien sanomien tyyppien osalta voisi todeta, että tuettujen sanomaformaattien skaala on hyvin laaja. Siirtoprotokollana tuetuin standardi on luonnollisesti HTTP, johon tämä työkin keskittyy, mutta myös HTTPS- ja SMTP - protokollille löytyy tukea. Salauksessa käytetään tyypillisesti S/MIME:ä ja 14

kirjekuoressa on käytetty kaikissa standardeissa MIME:ä. Vertailu tärkeimpien ominaisuuksien osalta löytyy seuraavasta taulukosta: Taulukko 3.1 B2B sanomanvälitysstandardien tekninen vertailu Lähetettävän sanoman tyyppi Siirtoprotokolla Salaus Allekirjoitus Kirjekuori AS2 ebms 2.0 RNIF 2.0 XML, EDI, ANSI XML, EDI tai XML, voi EDI-X12, mikä tahansa myös olla UN/EDIFACT tai digitaalinen muun muu rakenteellinen formaatti tyyppinen formaatti mikäli määritelty PIP:ssä Mikä tahansa HTTP tai HTTPS, aiempi AS1 käyttää SMTP:tä MIME Security Multiparts, S/MIME, CMS MIME Security Multiparts, S/MIME, CMS sekä allekirjoituspohja MDN. Allekirjoituksissa hash SHA-1 tai MD5 MIME standardit siirtoprotokolla, joka on yhteensopiva SOAP:n kanssa XML Encryption, S/MIME XML Signature, S/MIME MIME yhdessä SOAP:n kanssa HTTP, HTTPS SMTP S/MIME, PKCS, HTTPS yhdessä X.509:n kanssa tai S/MIME, PKCS MIME, jonka sisällä otsikot XMLdokumentteja 15

4 Tietosisältöjen vertailu Eri standardit määrittelevät erilaiset sisällöt ja rakenteet sanomien otsikkoihin sekä itse viesteihin. Näitä tietoja tarvitaan, jotta voidaan tarkemmin ja yksityiskohtaisesti tarkastella eri standardeja, kuten millaisia tietoja sanomien otsikoissa liikkuu. Näitä tietoja hyödyntämällä voidaan arvioida myös kyseisen standardin käyttöönottoon liittyvää työmäärää perustuen tarvittaviin tietoihin sanomissa. Tässä kappaleessa esitellään RNIF, EbMS ja AS2 standardien tietosisällöt, kuten millaisia tietoja otsikoissa ja sanomissa käytetään kyseisissä standardeissa. Kunkin standardin kohdalla on esimerkkejä otsikoista, joita kyseinen standardi käyttää. Kappaleen lopussa on yhteenveto sekä taulukko sanomien otsikkosisällöistä. 4.1 RNIF RNIF-viesti on rakenteellisesti MIME multipart/related -kuori jonka sisällä ovat XMLmuotoiset otsikkokenttätiedostot ja varsinainen viestitiedosto sekä mahdolliset liitetiedostot jotka voivat olla missä tahansa muodossa. Viestitiedosto ja liitteet muodostavat viestin varsinaisen hyötykuorman. Viestin rakenne on esitetty kuvassa 4.1. 16

Kuva 4.1 RNIF-viestin rakenne (RosettaNet 2002) Mikäli viesti halutaan salata tai allekirjoittaa voi osa tiedostoista olla S/MIME -kuoren sisällä tai koko kuori voidaan ympäröidä Multipart/signed kuorella, kuten kuvassa 4.2. Kuva 4.2 RNIF-viestin allekirjoitus (RosettaNet 2002) 17

Otsikot on ryhmitelty kolmeen eri ryhmään: Preamble Delivery Service Header Service Content Jokainen otsikkoryhmä on omassa XML-dokumentissaan. Preamble otsikko sisältää tiedot siitä mikä standardi ja standardin versio on kyseessä. Preamble otsikkoja ei voi salata. Delivery otsikko sisältää viestin yksilöllisen tunnisteen sekä tiedot lähettäjästä, vastaanottajasta ja siitä pitääkö viestiä kuljettaa salattuna. Delivery otsikkoja ei voi salata. Service otsikon alla välitetään tieto viestin prosessiympäristöstä eli siitä minkä prosessin osana viesti on lähetetty ja mikä sen funktio on, missä roolissa organisaatio on viestin lähettänyt (esim. myyjä, ostaja). Lisäksi se sisältää muita tietoja viestistä esimerkiksi onko kyseessä testiviesti ja kuinka monta liitettä viestissä on. Service otsikot on mahdollista salata. Minkä aktiviteetin osana viesti on lähetty (esim. Create Purchase Order) Lähettäjärooli ja -palvelu Vastaanottajarooli ja -palvelu Mihin viestiin tämä viesti on vastaus Viestin liitteet ja niiden tunnisteet Mihin prosessiin (PIP) viesti liittyy Mihin prosessi-instanssiin viesti liittyy Kuka prosessin aloitti 4.2 EbMS Ebms -sanomanvälityspalvelussa lähetetään EbXML tyyppisiä viestejä, jotka rakenteeltaan pohjautuvat MIME/moniosa viesteihin. Ulommaisena kerroksena ebxml viestissä on varsinaisen siirtoprotokollan kirjekuori, esimerkiksi HTTP tai SMTP 18

kirjekuori otsikkoineen (kuvassa 4.3 keltaisella värillä). Kuva 4.3 EbMS-viestin rakenne (OASIS 2002) Sen sisäpuolella on SOAP With Attachments (SOAP ja liitteet) kirjekuori (kuvassa 4.3 vaalean sinisellä). Tämän kuoren sisällä on peräkkäin kaksi tai useampia MIME osaa (kuvassa 4.3 vihreällä), joista ensimmäinen on aina pakollinen. Tämä ensimmäinen MIME osa on versio 1.1 mukainen SOAP viesti (kuvassa vaalean ruskealla), jonka kirjekuoren sisällä on SOAP kirjekuoren otsikko sekä SOAP runko-osa (kuvassa 4.3 harmaalla). Ensimmäisestä MIME osaa seuraavat MIME-osat sisältävät varsinaisen hyötykuorman, eli välitettävän sanoman. Näitä hyötykuormaa sisältävia MIME-osia voi olla useita peräkkäin ebxml-viestissä, kuitenkin aina ensimmäisessä MIME-osassa on pakollisena edellä kuvattu SOAP viesti. Ulommainen ebxml otsikko eli SOAP with Attachments otsikko (kuvassa 4.3 vaalean sinisellä, Message Package ) näyttää esimerkiksi kuten kuvassa 4.4: 19

Kuva 4.4 EbXML otsikko (OASIS 2002) Tämä otsikko pitää sisällään seuraavia tietoja: Content-Type (sisällön tyyppi) type (tyyppi) boundary (rajan signaali) start (viestin alun signaali) Edellisen sisällä oleva ensimmäisen MIME osan otsikko, kuvassa 4.3 vihreällä ( Header Container ) on esimerkiksi kuten kuvassa 4.5: Kuva 4.5 MIME-otsikko (OASIS 2002) Otsikon sisältämät tiedot ovat: Content-Type (sisällön tyyppi) Content-ID (sisällön tunniste) charset (merkistö) Sanomaosan, eli toinen ja siitä eteenpäin ebxml viestissä olevan MIME osan, otsikko 20

voisi olla esimerkiksi kuten kuvassa 4.6 (kuvassa 4.3 esitetty Payload Container(s)): Kuva 4.6 Lähetettävän sanoman MIME-otsikko (OASIS 2002) Tähän otsikkoon kuuluvat tiedot: Content-ID (sisällön tunniste) Content-Type (sisällön tyyppi) Edellisten lisäksi SOAP-kirjekuori sekä SOAP-runko sisältävät attribuutteja: xmlns (XML Namespace) xmlns:xsi (XML Namespace Schema Instance) xsi:schemalocation (XML Schema Instance Schema location) Kaikissa ebxml viesteissä on oltava mukana MessageHeader elementti, joka on SOAPotsikon yhteydessä. Tässä elementissä määritellään seuraavia tietoja: id version SOAP mustunderstand (vastaanottajan tulee ymmärtää SOAP viesti tai hylätä se) From o PartyId o Role To o PartyId o Role CPAId ConversationId Service Action MessageData o MessageId o Timestamp 21

o RefToMessageId o TimeToLive DuplicateElimination Description Esimerkki MessageHeader -elementistä on seuraavanlainen: <eb:messageheader eb:id=" " eb:version="2.0" SOAP:mustUnderstand="1"> <eb:from> <eb:partyid>uri:example.com</eb:partyid> <eb:role>http://rosettanet.org/roles/buyer</eb:role> </eb:from> <eb:to> <eb:partyid eb:type="sometype">qrs543</eb:partyid> <eb:role>http://rosettanet.org/roles/seller</eb:role> </eb:to> <eb:cpaid>http://www.oasis-open.org/cpa/123456</eb:cpaid> <eb:conversationid>987654321</eb:conversationid> <eb:service eb:type="myservicetypes">quotetocollect</eb:service> <eb:action>newpurchaseorder</eb:action> <eb:messagedata> <eb:messageid>uuid-2</eb:messageid> <eb:timestamp>2000-07-25t12:19:05</eb:timestamp> <eb:reftomessageid>uuid-1</eb:reftomessageid> </eb:messagedata> <eb:duplicateelimination/> </eb:messageheader> Kuten esimerkeistä nähdään, viestien otsikot ovat XML muotoisia ja siten myös ihmissilmälle helppoa luettavaa. Näiden otsikoiden lisäksi ebxml viestissä voi olla mukana useita erilaisia elementtejä, kuten esimerkiksi XML Signature, jos käytetään allekirjoitusta. SOAP With Attachments -otsikko MIME -otsikko SOAP -kuori SOAP -otsikko SOAP -viestin runko /SOAP -viestin runko SOAP -otsikko /SOAP -kuori Pakollinen Pakollinen Pakollinen Pakollinen Pakollinen Pakollinen Pakollinen Pakollinen 22

/MIME -otsikko MIME -otsikko Lähetettävä sanoma /Lähetettävä sanoma /MIME -otsikko /SOAP With Attachments -otsikko Pakollinen Vain, jos sanoma Vain, jos sanoma Vain, jos sanoma Vain, jos sanoma Pakollinen 4.3 AS2 AS2 sanoma koostuu MIME-formaatista HTTP sanoman sisällä sekä lisäksi muutamasta erityisestä AS2-otsikosta. Sanoman yksityiskohtainen sisältö riippuu siitä käytetäänkö allekirjoitusta, kryptausta, MDN-kuittausta ja/tai niiden eri kombinaatioita. HTTPprotokollan osalta voidaan huomioida, että pyyntörivi on muotoa "POST Request-URI HTTP/1.1" AS2 spesifisiä (header) otsikkokenttiä ovat AS2-versio, joka voi olla joko 1.0 tai 1.1, ja AS2 järjestelmä tunnisteet, joiden avulla vastaanottava osapuoli voi tunnistaa lähettävän osapuolen. AS2 järjestelmä tunnisteita ovat keneltä sanoma on tullut ja kenelle se lähetetty (AS2-From ja AS2-To). Periaatteessa sanoman sisällön kannalta voidaan katsoa, että on olemassa kahdenlaisia AS2-sanomia. Ensinnäkin on varsinaisen datan sisältäviä sanomia ja toiseksi on kuittaus eli MDN sanomia. Alla olevassa esimerkkisanomassa on kyseessä allekirjoitettu sanoma, johon odotetaan allekirjoitettua synkronoitua kuittausta (RFC 4130): POST /receive HTTP/1.0 Host: 10.234.160.12:80 User-Agent: AS2 Company Server Date: Wed, 31 Jul 2002 13:34:50 GMT From: mras2@example.com AS2-Version: 1.1 AS2-From: "\" as2name \"" AS2-To: 0123456780000 Subject: Test Case 23

Message-Id: <200207310834482A70BF63@\"~~foo~~\"> Disposition-Notification-To: mras2@example.com Disposition-Notification-Options: signed-receipt-protocol=optional, pkcs7-signature; signed-receipt-micalg=optional,sha1 Content-Type: multipart/signed; boundary="as2boundary1as2"; protocol="application/pkcs7-signature"; micalg=sha1 Content-Length: 2464 --as2boundary1as2 Content-Type: application/edi-x12 Content-Disposition: Attachment; filename=rfc1767.dat [ISA...EDI transaction data...iea...] --as2boundary1as2 Content-Type: application/pkcs7-signature [omitted binary pkcs7 signature data] --as2boundary1as2 Koska AS2 on suuniteltu välittämään EDIFACT-sanomia, niin on hyvä käsitellä myös EDIFACT-sanoman sisältöä, koska ne pitävät sisällään datan lisäksi toiminnallisuutta. EDIFACT sanoman segmentit ovat kehystettyjä "header-trailer" -segmenteillä, joita kutsutaan palvelu-segmenteiksi. EDIFACT sanoma koostuu siis seuraavista osista: Service String Advice UNA Ehdollinen Interchange Header UNB Pakollinen Functional Group Header UNG Ehdollinen Message Header UNH Pakollinen User Data Segments Sanoman mukaan Message Trailer UNT Pakollinen Functional Group Trailer UNE Ehdollinen Interchange Trailer UNZ Pakollinen Sanomanvälityksen kannalta olennaisin on UNB -segmentti, joka taas koostuu seuraavista osista: Syntaksitunniste (Syntax identifier) Sanomavaihdon lähettäjä (Interchange sender) Sanomavaihdon vastaanottaja (Interchange recipient) Päiväys (Date/Time of preparation) Sanomavaihdon valvonta referenssi (Interchange control referance) 24

Vastaanottajan viite, salasana (Recipients reference, password) Sovellus viite (Application reference) Prosessointi prioriteetti (Processing priority code) Kuittauspyyntö (Acknowledgement request) Kommunikaatio-sopimustunniste (Communication agreement id) Testi-indikaattori (Test indicator) 4.4 Yhteenveto Tämän osion kappaleissa on esitelty RNIF, ebms sekä AS2 standardien sanomissa olevia tietoja. Näistä yhteenvetona on taulukko 4.1, josta selviää hyvin että esimerkiksi lähettävän ja vastaanottavan organisaation tiedot on kaikissa standardeissa melko samanlaiset. Selkeänä eroavaisuutena on sen sijaan prosessitiedot, joita ei ebms standardissa suoraan määritellä. 25

Taulukko 4.1 Yhteenveto tietosisällöistä RNIF ebms AS2 Yleiset tiedot Noudatettava standardi X X UNB Standardin versio X X X Lähettäjän ja vastaanottajan tiedot Lähetäjäorganisaatio X X UNB Lähettäjän rooli X X Vastaanottajaorganisaatio X X UNB Vastaanottajan rooli X X Prosessi- ja kontekstitiedot Sovellettava prosessi X UNB Prosessi-instanssin tunniste X UNB Vastauksena viestiin X Sovellus UNB Muut Viestin uniikki tunniste X X UNB Prioriteetti UNB Kuittauspyyntö X X Testiviesti X X UNB Salasana UNB HUOM! AS2:n kohdalla UNB segmentit ovat luonnollisesti mukana vain EDIFACTsanomissa. 26

5 Toiminnallisuus Keskeinen osa eri standardeja on se miten ne määrittelevät tiettyjen toimintojen toteutuksen. Näitä toimintoja ovat mm. virheraportointi sekä viestinnän koreografiat ja orkestroinnit sekä tietoturvaominaisuuksiin kuuluvat viestin eheyden, luottamuksellisuuden ja kiistämättömyyden vaatimukset. Lisäksi eräs hyvin tärkeä ominaisuus yritystenvälisten integraatioiden yleistyessä on se mahdollistaako standardi niin sanotun viestinnän operaattorimallin, jossa eri osapuolet eivät lähetä viestejä toisilleen vaan operaattorille joka viestin otsikkotietojen perusteella välittää viestin joko seuraavalle operaattorille tai vastaanottajalle. Mikäli tämä ei ole mahdollista joudutaan jokaisen integraation tekniset yksityiskohdat sopimaan erikseen osapuolten välillä mikä integraatioiden lukumäärän kasvaessa lisää työmäärää ja vaikeuttaa ympäristön ylläpitämistä. Operaattorimalli saattaa vaarantaa viestin tietoturvan, mikäli operaattorille joudutaan antamaan avaimet salatun viestin purkua varten. Tämä on tarpeen, mikäli viestin vastaanottaja on määritelty viestin salatussa osassa. Tosin asiakas ja operaattori tekevät aina sopimuksen salassapidosta, joten tietoturvaongelmat ovat sopimusrikkomuksia ja niitä käsitellään sen mukaisesti. 5.1 RNIF Virheraportointi RNIF määrittelee kaksi mekanismia virhetilanteiden raportointiin. Signaaliviestejä käytetään kommunikoimaan sanoman vastaanotosta ja havaituista virheistä prosessi-instanssin sisällä. Signaaleita siis käytetään paitsi virhetilanteiden 27

raportointiin myös kuittaamaan viesti vastaanotetuksi. Prosessiohjausprosesseja (Process Control PIP) käytetään kommunikoimaan prosessin tilaan liittyviä virheitä prosessi-instanssin ulkopuolella. Esimerkkinä voidaan käyttää tilannetta jossa prosessi on poikkeustilanteen takia tilassa "Valmis" toisessa järjestelmässä ja toisessa järjestelmässä tila on "Ajossa" koska vastaanotettua viestiä ei pystytty käsittelemään. Signaalit lähetetään normaaleina RNIF-viesteinä joissa sisältönä (Service Content) on signaalidokumentti. Prosessiohjaus-PIPien viestit ja koreografiat on määritelty omissa määrittelyissään. Koreografia ja orkestrointi RosettaNet-standardi käsittelee pelkästään yritystenvälisiä prosesseja ja siten koreografioita. Sisäiset prosessit ja niiden orkestrointi eivät suoranaisesti kuulu RosettaNetin alueeseen. Yritystenväliset prosessit (RosettaNet-terminologiassa PIP, Partner Interface Process) on määritelty omissa standardeissaan jotka on jaettu alueittain ja aiheittain klustereihin ja segmentteihin. RNIF-standardi on suunniteltu tarkkaan PIPviestien lähetykseen, eikä muiden viestien välittäminen onnistu suoraan standardia laajentamatta. Turvallisuus RNIF-standardissa viestin eheys varmistetaan lähettäjän allekirjoituksella käyttäen S/MIME (RFC 2311) standardia. Vastaanottaja varmentaa allekirjoituksen käyttäen S/MIMEn ja PKCS:n vakiomekanismeja. Samalla varmennetaan myös lähettäjän identiteetti. Se, pitääkö viesti allekirjoittaa, on määritelty erikseen prosessimäärittelyissä. Allekirjoittamattomien viestien eheyden osalta luotetaan TCP/IP-protokollien virheenkorjausmekanismeihin. RNIF-viestin allekirjoitus on esitetty kuvassa 5.1. Viestien kiistämättömyys toteutetaan samalla sähköisellä allekirjoituksella kuin 28

eheydenkin osalla, siten että mukana on MD5 tai SHA-1 muotoinen tiiviste viestistä. Vastaanottajan velvollisuutena on säilyttää vastaanotettu allekirjoitettu viesti yhteisesti sovitun ajan, tyypillisesti 3-7 vuotta. Myös kuittausviestit voidaan allekirjoittaa ja näin varmistaa se ettei vastaanottaja voi kiistää vastaanottaneensa kuitattua viestiä. Kuva 5.1 RNIF viestin allekirjoitus (RosettaNet 2002) Luottamuksellisuus saadaan aikaan käyttämällä asymmetristä salakirjoitusta ja salaamalla lähetettävä viesti. Tällöin vain viestin lopullinen vastaanottaja voi lukea viestin. Viestistä voidaan salata joko pelkästään viesti ilman otsakkeita tai viesti ja Service-otsikkotiedosto, jolloin salaamatta jäävät pelkästään viestin vastaanottaja- ja lähettäjätiedot sekä standardin versiotiedot. Kuvat 5.2 ja 5.3 esittävät tilanteen, jossa salakirjoitetaan sekä viesti että Service-otsikot. 29

Kuva 5.2 RNIF viestin salaus, luodaan Encrypted Payload Container (RosettaNet 2002) Kuva 5.3 RNIF-viestin salaus, salaamattomat otsikkotiedot paketoidaan salatun osion kanssa (RosettaNet 2002) RNIF määrittelee että Service-otsikot voidaan sijoittaa joko viestin salattuun tai salaamattomaan osaan. Vastaanottajaotsikoiden täytyy kuitenkin aina olla salaamattomia. Siirron aikana voidaan käyttää salattua HTTPS-protokollaa selväkielisen HTTP:n sijaan. Tällöin satunnainen salakuuntelijakaan ei pääse lukemaan edes vastaanottajatietoja vaan ne ovat ainoastaan mahdollisen viestiä reitittävän osapuolen luettavissa. Viestitystopologiat RNIFin avulla viestejä voidaan välittää joko suoraan osapuolelta toiselle tai niin 30

sanottua operaattorimallia käyttäen jossa viestit lähetetään kolmannelle osapuolelle joka reitittää viestit vastaanottajalle. Tämän mahdollistaa se, etteivät vastaanottajaotsikot ole koskaan salattuja, eli myös operaattori pystyy lukemaan ne ja selvittämään kenelle viesti pitää välittää. 5.2 EbMS Virheraportointi EbMS viestikäsittelijä (Message Service Handler, MSH) sisältää erillisen moduulin, joka tarkkailee ebxml viestejä mahdollisten virheiden varalta. Huomattuaan virheen, tämä moduuli ilmoittaa yhteyden toisessa päässä olevalle viestikäsittelijälle virheestä. Mikäli vastaanottavan MSH:n SOAP -viestien käsittelijämoduli ei kykene jäsentämään jotain saamaansa viestiä, voi kyseinen SOAP -prosessori palauttaa SOAP vikaviestin, jolloin myös tällaista SOAP-vikaviestiä tulee MSH:n virhemoduulin tukea. Tällöin vikaviestit ja niissä olevat vikakoodit ovat SOAP -standardin mukaisia. EbMS määrittelee kuitenkin myös omat vikaviestinsä, jotka voivat koskea esimerkiksi turvallisuutta tai luotettavan yhteyden häiriöitä. Vikaviesti sisältää ErrorList -elementin, joka sisältää otsikon tälle elementille sekä yhden tai useampia Error -elementtejä. Nämä Error -elementit sisältävät varsinaiset vikakoodit sekä esimerkiksi id-, location- ja Description -kentät. Location -kenttä määrittelee missä kohdassa viestiä virhe on, ja Description määrittelee sanallisessa muodossa virheen. Virhekoodit on jaoteltu ebxml -viestin elementeissä oleviin sekä ei-xml virheisiin. Koreografia ja orkestrointi EbMS standardi ei määrittele orkestrointia, sillä se on tarkoitettu yritysten väliseen viestintään. Täten ebms kuvaa ainoastaan koreografian, joka toteutuu siten, että lähettäjän lähettämään viestiin vastaanottaja vastaa kuittauksella, mikäli käytetään 31

luotettavaa tiedonsiirtoa. Turvallisuus EbMS käyttää XML Signature -menetelmää, jolla allekirjoitetaan digitaalisesti ebxml viestin osia. Allekirjoitus tapahtuu XML Signature -standardin mukaisesti. Luottamuksellisuus ebms standardissa saavutetaan XML Encryption -menetelmällä. Sitä käyttäen voidaan salata EbXML viestin osia ja sekä SOAP -otsikko. EbXML-viestin lähetettävä sanoma voidaan salata vielä erikseen jollain muulla menetelmällä, jonka yhteyden osapuolet sopivat mahdollisesti erikseen. Kiistämättömyys varmistetaan allekirjoittamalla lähetettävä sanoma digitaalisesti ja liittämällä sanomaan kuittauspyyntö, jolloin vastaanottaja kuittaa sanoman tulleen perille sekä liittää kuittausviestiin koosteen alkuperäisestä sanomasta. Viestintätopologiat Sanomat ebms standardia käyttäen lähetetään joko suoraan vastaanottajalle tai käyttäen operaattorimallia, jossa viesti ensin lähetetään kolmannelle osapuolelle. Tämä kolmas osapuoli voi esimerkiksi olla aikaleimapalveluna vastaanottajalle sekä lähettäjälle tai ainoastaan toimia talleta ja lähetä -palveluna. Digitaalinen allekirjoitus mitätöityy, mikäli välillä oleva kolmas osapuoli muuttaa tietoja sanomassa. 5.3 AS2 Virheraportointi Palautettavat statuskoodit riippuvat myös HTTP operaatioiden statuskoodeista. Esimerkiksi statuskoodia 401 yhdessä WWW-autentikointi otsikon kanssa käytetään kertomaan että asiakkaan pitää toistaa pyyntö autentikointi otsikon kanssa. Muut 32

eksplisiittiset statuskoodit ovat dokumentoituja RFC 2616:ssa. Virheille pyyntö-uri:ssa, kuten 400 ( Bad Request ) tai 404 ( Not Found ) ja vastaaville, ko. status koodit ovat asianmukaisia. Nämä koodit ja niiden selitykset ovat myös dokumentoituja RFC 2616:ssa. Uudelleenlähetyksiä ei ole syytä tehdä jos virhe ei ole ohimenevä tai jos uudelleenlähetys on eksplisiittisesti ei-toivottu. Jos HTTP asiakas ei onnistu lukemaan HTTP-palvelimen vastaustietoa, niin POSTkomento voidaan toistaa identtisellä sisällöllä mukaan lukien sanomatunniste (message- ID), jos tilanne on ohimenevä. Samaa sanomatunnistetta (message-id) voidaan käyttää uudestaan vain ja ainoastaan jos kaikki sisältö, mukaan lukien alkuperäinen päiväys, ovat samoja. Servereiden pitäisi pystyä vastaanottamaan POST komentoja samalla sanomatunnisteella (message-id). MIME vastaus osa pitäisi lähettää uudelleen mukaan lukien MDN ja muut MIME osat. (RFC 4130) Koreografia ja orkestrointi Orkestrointi riippuu suuresti siitä miten yrityksen sisäiset järjestelmät ovat toteutettuja. Mutta koreografia taas on riippumatta yrityksen omasta toimintatavasta yleensä samanlainen, eli AS2:ssa se tarkoittaa, että lähetetään sanoma ja saadaan siihen kuittauksena MDN-sanoma. Seuraavassa esimerkissä, kuva 5.4, on erään toimittajan (Seeburger, 2005) esittämä kuvaus AS2 koreografiasta ja orkestroinnista. Orkestrointi tapahtuu toimittajan (supplier) ja valmistajan (manufacturer) organisaatioiden sisällä, kun taas koreografia tapahtuu heidän välillään. 33

Kuva 5.4 AS2 koreografia ja orkestrointi (Seeburger 2005) Turvallisuus Lähetettävien sanomien eheys, kiistämättömyys ja luottamuksellisuus varmistetaan seuraavalla tavalla. Organisaatio, joka lähettää sanoman, allekirjoittaa ja kryptaa datan käyttämällä S/MIME (RFC 2311) standardia. Lisäksi sanomaan lisätään vaatimus, että lähettäjälle täytyy lähettää vastauksena allekirjoitettu kuittaus. Tukeakseen NRR:ää (Non-repudiation of 34

receipt) alkuperäinen lähettäjä pitää vielä itselleen kirjaa eli lokia lähetetyistä sanomista, sanomatunnisteista (message-id) ja yhteenveto (MIC) arvoista. MIC:iä (Message Integrity Check) kutsutaan sanoman yhteenvedoksi, se on yhteenveto digitaalisen allekirjoituksen käyttämästä hash algoritmista. Käytettävät hash algoritmit ovat SHA-1 tai MD5. Vastaanottava organisaatio purkaa sanoman kryptauksen ja varmentaa allekirjoituksen saavuttaen tällä tavalla datan varmennetun eheyden ja lähettäjän autentikoinnin. Vastaanottava organisaatio sitten lähettää allekirjoitetun kuittauksen lähettävälle organisaatiolle allekirjoitetun MDN -viestin muodossa. Tämä allekirjoitettu kuittaus sisältää tiivistelmän vastaanotetusta sanomasta, antaen alkuperäiselle lähettäjälle mahdollisuuden todentaa että sanoma oli autentikoitu ja kryptaus purettu oikein vastaanottajan päässä. NRR on vahvistus sille tapahtumalle, että alkuperäinen lähettäjä on varmentanut allekirjoitetun kuittauksen saapuneeksi vastaanottajalta. Kuittaus sisältää samat tiedot, joista lähettäjän on täytynyt pitää kirjaa. Lähettäjän velvollisuus on varmentaa, että itselle talletetut tiedot ja kuittauksessa saadut tiedot täsmäävät. Lisäksi on mahdollisuus käyttää HTTPS-protokollaa HTTP-protokollan sijaan. Viestintätopologiat Sanomia voidaan lähettää suoraan kauppakumppanilta toiselle ns. point-to-point ratkaisua käyttäen, mutta on mahdollista myös käyttää operaattoreita, jotka reitittävät, mahdollisesti purkavat kryptauksia, formatoivat sanomia uudelleen jne. Kuinka paljon tietoa operaattorille pitää antaa, riippuu paljon siitä mitä kaikkia toimenpiteitä operaattorin toimenkuvaan kuuluu. Mutta joka tapauksessa jonkin tasoinen turvallinen yhteys täytyy muodostaa operaattorin ja operaattoria käyttävän organisaation väliin. 5.4 Yhteenveto Tämän osion kappaleissa on esitelty eri standardien toiminnallisia ominaisuuksia. 35