T Special Course in Information Systems Integration

Koko: px
Aloita esitys sivulta:

Download "T-86.5161 Special Course in Information Systems Integration"

Transkriptio

1 HELSINKI UNIVERISITY OF TECHNOLOGY Department of Computer Science and Engineering Software Business and Engineering Institute T 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

2 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

3 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

4 Sisällysluettelo Tiivistelmä... ii Abstract... iii Kuvaluettelo... vii Taulukkoluettelo... viii 1 Johdanto Taustaa Tavoitteet Tutkimuskysymykset Tutkimuksen laajuus Tutkimusmenetelmät Sanasto Raportin rakenne Aikataulu Yleisesittely RosettaNet Implementation Framework ebms (ebxml Messaging Service) AS Tekninen vertailu RNIF EbMS AS Yhteenveto iv

5 4 Tietosisältöjen vertailu RNIF EbMS AS Yhteenveto Toiminnallisuus RNIF EbMS AS Yhteenveto Signalointi RNIF EbMS AS Yhteenveto Ohjelmistotuki RNIF EBMS AS Yhteenveto Johtopäätökset ja pohdinnat Yleistä Yhteensopivuudesta Operaattorimalli v

6 8.4 Lopuksi Yhteenveto Lähdeluettelo vi

7 Kuvaluettelo Kuva 2.1 Esimerkki - tyypillinen B2B -tapahtuma... 8 Kuva 4.1 RNIF-viestin rakenne (RosettaNet 2002) Kuva 4.2 RNIF-viestin allekirjoitus (RosettaNet 2002) Kuva 4.3 EbMS-viestin rakenne (OASIS 2002) Kuva 4.4 EbXML otsikko (OASIS 2002) Kuva 4.5 MIME-otsikko (OASIS 2002) Kuva 4.6 Lähetettävän sanoman MIME-otsikko (OASIS 2002) Kuva 5.1 RNIF viestin allekirjoitus (RosettaNet 2002) 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) Kuva 5.4 AS2 koreografia ja orkestrointi (Seeburger 2005) Kuva 6.1 Yksitapahtumainen asynkroninen prosessi jossa lähetetään yksi liiketoimintaviesti ja sen kuittaus (RosettaNet 2002) Kuva 6.2 Kaksitapahtumainen asynkroninen prosessi jossa ensimmäinen liiketoimintaviesti kuitataan ja lähetetään vastausviesti joka myös kuitataan (RosettaNet 2002) vii

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

9 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

10 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

11 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 suojattu versio. (Wikipedia 2006g) JMS Java Message Service, Java-pohjainen sanomanvälitys standardi. (Wikipedia 2006h) Koreografia Organisaatioiden välisten liiketoimintaprosessin 3

12 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

13 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 Tietojärjestelmien integroinnin erikoiskurssi syksyllä 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 Projektisuunnitelma valmis Taustatutkimusta ja kirjallisuuskatsaus Yleiskatsaukset standardeihin Tekniset katsaukset 6.11 Toiminnalliset katsaukset 8.11 Teknisen vertailun koonti ja kappaleen kirjoitus 8.11 Signalointikatsaukset Yleiskatsausten koonti ja kappaleen kirjoitus 5

14 10.11 Toiminnallisen vertailun koonti ja kappaleen kirjoitus Ohjelmistotukikatsaukset Signalointivertailun koonti ja kappaleen kirjoitus Ohjelmistotukivertailun koonti ja kappaleen kirjoitus Raportin kokoaminen ja asettelu Ensimmäinen versio valmis Ensimmäisen version katselmointi 7.12 Raportti 95 % valmis Raportin katselmointi Tutkimuksen esittely seminaarissa 6

15 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

16 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

17 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 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

18 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) 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

19 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

20 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ää 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

21 välinen autentikointi. (RosettaNet, 2002,s ) 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

22 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

23 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

24 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

25 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

26 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

27 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

28 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

29 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

30 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> </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> t12: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

31 /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: :80 User-Agent: AS2 Company Server Date: Wed, 31 Jul :34:50 GMT From: AS2-Version: 1.1 AS2-From: "\" as2name \"" AS2-To: Subject: Test Case 23

32 Message-Id: Disposition-Notification-To: 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: 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

33 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

34 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

35 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

36 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

37 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

38 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 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

39 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

40 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

41 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

42 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

43 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

UBL sanomien käyttö sähköisessä kaupankäynnissä. Heikki Laaksamo, TIEKE ry

UBL sanomien käyttö sähköisessä kaupankäynnissä. Heikki Laaksamo, TIEKE ry UBL sanomien käyttö sähköisessä kaupankäynnissä Heikki Laaksamo, TIEKE ry Sähköisen, standardimuotoisen tiedonsiirron kehitys Suomessa Suomalainen standardi / Positiosidonnaiset tietueet KOTVA 1980-luvun

Lisätiedot

vakuutuslaitosten ja TAMLAn välillä

vakuutuslaitosten ja TAMLAn välillä Asioiden välittämien työeläkealan toimijoiden ja TELKin sekä vakuutuslaitosten ja TAMLAn välillä Työeläkealan XML-käytäntöjen soveltaminen Taustaa, tämän dokumentin tarkoitus Asioiden välittäminen tapahtuu

Lisätiedot

Pikaviestinnän tietoturva

Pikaviestinnän tietoturva Ongelmat, vaihtoehdot ja ratkaisut 4.5.2009 Kandidaatintyö, TKK, tietotekniikka, kevät 2009 Varsinainen työ löytyy osoitteesta http://olli.jarva.fi/kandidaatintyo_ pikaviestinnan_tietoturva.pdf Mitä? Mitä?

Lisätiedot

Case VYVI-Turvaposti miten huolehditaan turvallisesta viestinnästä eri sidosryhmien kesken? Tommi Simula Tietoturvapäällikkö Valtori

Case VYVI-Turvaposti miten huolehditaan turvallisesta viestinnästä eri sidosryhmien kesken? Tommi Simula Tietoturvapäällikkö Valtori Case VYVI-Turvaposti miten huolehditaan turvallisesta viestinnästä eri sidosryhmien kesken? Tommi Simula Tietoturvapäällikkö Valtori Agenda Sähköpostin turvallisuus Yleiset käyttötapaukset VYVI Turvaposti

Lisätiedot

Julkinen. Suomen Pankin ja Finanssivalvonnan suojattu sähköposti: ulkoisen käyttäjän ohje

Julkinen. Suomen Pankin ja Finanssivalvonnan suojattu sähköposti: ulkoisen käyttäjän ohje Ohje 1 (10) Suomen Pankin ja Finanssivalvonnan suojattu sähköposti: ulkoisen käyttäjän ohje Sisällys 1 Johdanto... 1 2 Suojatun viestin vastaanottaminen... 1 3 Suojatun viestin lukeminen... 2 4 Vastaanotetun

Lisätiedot

OSI ja Protokollapino

OSI ja Protokollapino TCP/IP OSI ja Protokollapino OSI: Open Systems Interconnection OSI Malli TCP/IP hierarkia Protokollat 7 Sovelluskerros 6 Esitystapakerros Sovellus 5 Istuntokerros 4 Kuljetuskerros 3 Verkkokerros Linkkikerros

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702)

Järjestelmäarkkitehtuuri (TK081702) Järjestelmäarkkitehtuuri (TK081702) yleistyvät verkkopalveluissa Youtube Google... Avaavat pääsyn verkkopalvelun sisältöön. Rajapintojen tarjoamia tietolähteitä yhdistelemällä luodaan uusia palveluja,

Lisätiedot

WEB SERVICES RAJAPINTA SAMLINKIN TEKNINEN RAJAPINTAKUVAUS OHJELMISTOTALOILLE

WEB SERVICES RAJAPINTA SAMLINKIN TEKNINEN RAJAPINTAKUVAUS OHJELMISTOTALOILLE WEB SERVICES RAJAPINTA 02.05.2014 Sisällysluettelo Sisällysluettelo 02.05.2014 2 (13) 1 SOAP-kehys... 4 2 Aineiston pakkaus... 4 3 Aineiston salaus... 4 4 Tuetut operaatiot... 4 5 Application Request Header...

Lisätiedot

T2V2 Vaaratilanneilmoitussanomakuvaus

T2V2 Vaaratilanneilmoitussanomakuvaus Versio: 0.3 Muokattu: 23.6.2008 2(10) SISÄLLYS 1 Tarkoitus...3 1.1 Rajaus...3 1.2 Dokumentaatio...3 2 Tietojen esitystavat...3 2.1 Numeerinen tieto...3 2.2 Päivämäärät ja kellonajat...3 2.3 Totuusarvot...4

Lisätiedot

Menetelmäraportti - Konfiguraationhallinta

Menetelmäraportti - Konfiguraationhallinta Menetelmäraportti - Konfiguraationhallinta Päiväys Tekijä 22.03.02 Ville Vaittinen Sisällysluettelo 1. Johdanto... 3 1.1 Tärkeimmät lyhenteet... 3 2. Konfiguraationhallinnan tärkeimmät välineet... 4 2.1

Lisätiedot

Green Growth Sessio - Millaisilla kansainvälistymismalleilla kasvumarkkinoille?

Green Growth Sessio - Millaisilla kansainvälistymismalleilla kasvumarkkinoille? Green Growth Sessio - Millaisilla kansainvälistymismalleilla kasvumarkkinoille? 10.10.01 Tuomo Suortti Ohjelman päällikkö Riina Antikainen Ohjelman koordinaattori 10/11/01 Tilaisuuden teema Kansainvälistymiseen

Lisätiedot

Muutokset suoran sanoma-asioinnin webservicepalvelun

Muutokset suoran sanoma-asioinnin webservicepalvelun SANOMALIIKENNE Tullihallitus Suora sanoma-asiointi 16.6.2012 Muutokset suoran sanoma-asioinnin webservicepalvelun XML-schemoihin v.1.8 muutos 16.6.2012 SISÄLLYSLUETTELO 1 Johdanto... 3 2 Aikataulu ja yhteensopivuus...

Lisätiedot

Group 2 - Dentego PTH Korvake. Peer Testing Report

Group 2 - Dentego PTH Korvake. Peer Testing Report Group 2 - Dentego PTH Korvake Peer Testing Report Revisions Version Date Author Description 1.0 Henrik Klinkmann First version Table of Contents Contents Revisions... 2 Table of Contents... 2 Testing...

Lisätiedot

Internet Protocol version 6. IPv6

Internet Protocol version 6. IPv6 Internet Protocol version 6 IPv6 IPv6 Osoiteavaruus 32-bittisestä 128-bittiseksi Otsikkokentässä vähemmän kenttiä Lisäominaisuuksien määritteleminen mahdollista Pakettien salaus ja autentikointi mahdollista

Lisätiedot

Interfacing Product Data Management System

Interfacing Product Data Management System Interfacing Product Data Management System Tekijä: Työn valvoja: Mats Kuivalainen Timo Korhonen Esitelmän sisältö Työn suorituspaikka - Ideal Product Data Oy Käsitteitä Työn tavoitteet Työn tulokset 1/5

Lisätiedot

Liiketoimintajärjestelmien integrointi

Liiketoimintajärjestelmien integrointi Liiketoimintajärjestelmien integrointi Vierailuluento 12.12.2016 Esa Heikkinen Mystes Oy Agenda Liiketoimintajärjestelmien integrointi EAI: Enterprise Application Integration EAS: Enterprise Application

Lisätiedot

W3C-teknologiat ja yhteensopivuus

W3C-teknologiat ja yhteensopivuus W3C-teknologiat ja yhteensopivuus Ossi Nykänen Tampereen teknillinen yliopisto (TTY), Digitaalisen median instituutti (DMI), Hypermedialaboratorio W3C Suomen toimisto Esitelmä Hyvin lyhyt versio: W3C asettaa

Lisätiedot

Collaborative & Co-Creative Design in the Semogen -projects

Collaborative & Co-Creative Design in the Semogen -projects 1 Collaborative & Co-Creative Design in the Semogen -projects Pekka Ranta Project Manager -research group, Intelligent Information Systems Laboratory 2 Semogen -project Supporting design of a machine system

Lisätiedot

Security server v6 installation requirements

Security server v6 installation requirements CSC Security server v6 installation requirements Security server version 6.x. Version 0.2 Pekka Muhonen 2/10/2015 Date Version Description 18.12.2014 0.1 Initial version 10.02.2015 0.2 Major changes Contents

Lisätiedot

Hammastankohissin modernisointi. Heikki Laitasalmi

Hammastankohissin modernisointi. Heikki Laitasalmi Hammastankohissin modernisointi Heikki Laitasalmi Loppudemossa Mitä oltiinkaan tekemässä V-malli Modbus viestintä (PLC VFD) Esitellään laitteet Lopuksi Modbusia käytännössä Hammastankohissi Arkkitehtuuri

Lisätiedot

Rakenteisen oppimateriaalin tuottaminen verkossa esimerkki Rhaptos. Antti Auer Koordinaattori, HT Jyväskylän yliopisto Virtuaaliyliopistohanke

Rakenteisen oppimateriaalin tuottaminen verkossa esimerkki Rhaptos. Antti Auer Koordinaattori, HT Jyväskylän yliopisto Virtuaaliyliopistohanke Rakenteisen oppimateriaalin tuottaminen verkossa esimerkki Rhaptos Antti Auer Koordinaattori, HT Jyväskylän yliopisto Virtuaaliyliopistohanke Rakenteisuus kahdella tasolla Oppimisaihiot ( Learning Objects

Lisätiedot

Cover letter and responses to reviewers

Cover letter and responses to reviewers Cover letter and responses to reviewers David E. Laaksonen, MD, PhD, MPH Department of Medicine Kuopio University Hospital Kuopio, Finland Luennon sisältö Peer review Vinkit vastineiden kirjoittamista

Lisätiedot

FinFamily PostgreSQL installation ( ) FinFamily PostgreSQL

FinFamily PostgreSQL installation ( ) FinFamily PostgreSQL FinFamily PostgreSQL 1 Sisällys / Contents FinFamily PostgreSQL... 1 1. Asenna PostgreSQL tietokanta / Install PostgreSQL database... 3 1.1. PostgreSQL tietokannasta / About the PostgreSQL database...

Lisätiedot

Järjestelmän kriittisimmille toiminnallisuuksille (listattu alla), toteutetaan 1

Järjestelmän kriittisimmille toiminnallisuuksille (listattu alla), toteutetaan 1 1. Testattavat asiat Järjestelmän kriittisimmille toiminnallisuuksille (listattu alla), toteutetaan 1 selainyhteensopivuustesti käyttäen Suomessa eniten käytössä olevia selaimia. Uuden keräyksen lisääminen

Lisätiedot

Palvelun rekisteröinti Virtu - luottamusverkostoon / testipalveluun

Palvelun rekisteröinti Virtu - luottamusverkostoon / testipalveluun 1 Resurssirekisteri :: Käyttöohje Palvelun rekisteröinti Virtu - luottamusverkostoon / testipalveluun Tässä ohjeessa kerrotaan, miten lisäät uuden Service Provider (SP) palvelun Virtu - luottamusverkostoon

Lisätiedot

S-ryhmän Verkkolaskuportaali Pikaohje

S-ryhmän Verkkolaskuportaali Pikaohje S-ryhmän Verkkolaskuportaali Pikaohje 1 Yleistä Verkkolaskuportaali on internetissä toimiva sovellus, jonka kautta voi lähettää verkkolaskuja Verkkolaskuportaali soveltuu toimittajille, joilla ei ole sopimusta

Lisätiedot

83450 Internetin verkkotekniikat, kevät 2002 Tutkielma

83450 Internetin verkkotekniikat, kevät 2002 Tutkielma <Aihe> 83450 Internetin verkkotekniikat, kevät 2002 Tutkielma TTKK 83450 Internetin verkkotekniikat Tekijät: Ryhmän nro:

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) SOA, Service-oriented architecture SOA,

Järjestelmäarkkitehtuuri (TK081702) SOA, Service-oriented architecture SOA, Järjestelmäarkkitehtuuri (TK081702) SOA SOA-arkkitehtuuri perustuu xml:ään ja Web Services teknologioihin Mahdollistaa joustavan mukautumisen tuleviin muutoksiin Kustannustehokas Toteutukset perustuvat

Lisätiedot

MUSEOT KULTTUURIPALVELUINA

MUSEOT KULTTUURIPALVELUINA Elina Arola MUSEOT KULTTUURIPALVELUINA Tutkimuskohteena Mikkelin museot Opinnäytetyö Kulttuuripalvelujen koulutusohjelma Marraskuu 2005 KUVAILULEHTI Opinnäytetyön päivämäärä 25.11.2005 Tekijä(t) Elina

Lisätiedot

Turvallinen etäkäyttö Aaltoyliopistossa

Turvallinen etäkäyttö Aaltoyliopistossa Turvallinen etäkäyttö Aaltoyliopistossa Diplomityöseminaari Ville Pursiainen Aalto-yliopiston tietotekniikkapalvelut Valvoja: Prof Patric Östergård, Ohjaajat: DI Jari Kotomäki, DI Tommi Saranpää 7.10.2016

Lisätiedot

Verkkoliikennettä Java[ssa lla] Jouni Smed

Verkkoliikennettä Java[ssa lla] Jouni Smed Verkkoliikennettä Java[ssa lla] Jouni Smed 9.2.2001 1 Perusteita 1 (2) tarvittavat luokat paketissa MDYDQHW IP-osoitteita käsitellään,qhw$gguhvv-olioina luonti (huom. ei konstruktoria):,qhw$gguhvvdggu,qhw$gguhvvjhw%\1dphdgguhvv

Lisätiedot

Maarit Pirttijärvi Pohjois-Suomen sosiaalialan osaamiskeskus Lapin toimintayksikkö

Maarit Pirttijärvi Pohjois-Suomen sosiaalialan osaamiskeskus Lapin toimintayksikkö Verkkokonsulttipäivä 28.11.2011 Maarit Pirttijärvi j Pohjois-Suomen sosiaalialan osaamiskeskus Lapin toimintayksikkö www.sosiaalijaterveyspalvelut.fi Virtuaalisen sosiaali- ja terveyspalvelukeskuksen käyttäjät

Lisätiedot

Projektin tavoitteet

Projektin tavoitteet VBE II, vaihe 1: 2005-2006 Data yrityksistä ja rakennushankkeista TUT Tekniset ratkaisut RAK (VRLab)+ARK iroom validointi Työpajat Seminaarit Esitelmät Osallistuvat yritykset VTT Käyttöönotto- ja hyötymallit,

Lisätiedot

Työelämäyhteydet uudistuvassa korkeakoulutuksessa seminaari Sessio 3. Kirsti Keltikangas, Aalto-yliopiston Sähkötekniikan korkeakoulu

Työelämäyhteydet uudistuvassa korkeakoulutuksessa seminaari Sessio 3. Kirsti Keltikangas, Aalto-yliopiston Sähkötekniikan korkeakoulu Automaation ja sähkötekniikan maisteriohjelman Projektityökurssi-case Työelämäyhteydet uudistuvassa korkeakoulutuksessa seminaari 10.10.2016 Sessio 3 Kirsti Keltikangas, Aalto-yliopiston Sähkötekniikan

Lisätiedot

Muutokset suoran sanoma-asioinnin webservicepalvelun

Muutokset suoran sanoma-asioinnin webservicepalvelun 1(6) Sanomaliikenne Suora sanoma-asiointi Muutokset suoran sanoma-asioinnin webservicepalvelun XML-schemoihin v.1.5 muutos 4.12.2010 2(6) SISÄLLYSLUETTELO 1 Johdanto... 3 2 Aikataulu ja yhteensopivuus...

Lisätiedot

Suvi Junes/Pauliina Munter Tampereen yliopisto / tietohallinto 2014

Suvi Junes/Pauliina Munter Tampereen yliopisto / tietohallinto 2014 Keskustelualue Keskustelualue soveltuu eriaikaisen viestinnän välineeksi. Keskustelualueelle voidaan lähettää viestejä toisten luettavaksi, ja sitä voidaan käyttää alueena myös ryhmätöiden tekemiseen,

Lisätiedot

Pitkäaikaistallennus. CSC - Tieteen tietotekniikan keskus IT2008 Ari Lukkarinen

Pitkäaikaistallennus. CSC - Tieteen tietotekniikan keskus IT2008 Ari Lukkarinen Pitkäaikaistallennus CSC - Tieteen tietotekniikan keskus IT2008 Ari Lukkarinen Mitä on pitkäaikaistallennus? Tiedon tallennuksen aikajänne ylittää tallennusjärjestelmän sekä laite-että ohjelmistokomponenttien

Lisätiedot

Ohjelmistoarkkitehtuurit. Kevät 2012-2013

Ohjelmistoarkkitehtuurit. Kevät 2012-2013 Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Viestipohjaisten yritysjärjestelmien suunnittelumallit 1 Viestinvälitykseen perustuvat yritysjärjestelmät Peruselementit:

Lisätiedot

Suvi Junes Tampereen yliopisto / tietohallinto 2013

Suvi Junes Tampereen yliopisto / tietohallinto 2013 Keskustelualue Keskustelualue soveltuu eriaikaisen viestinnän välineeksi. Keskustelualueelle voidaan lähettää viestejä toisten luettavaksi, ja sitä voidaan käyttää alueena myös ryhmätöiden tekemiseen,

Lisätiedot

Salasanan vaihto uuteen / How to change password

Salasanan vaihto uuteen / How to change password Salasanan vaihto uuteen / How to change password Sisällys Salasanakäytäntö / Password policy... 2 Salasanan vaihto verkkosivulla / Change password on website... 3 Salasanan vaihto matkapuhelimella / Change

Lisätiedot

Tuotekehitysverkoston läpimenoajan lyhentäminen tuotemuutostenhallinnalla ja verkoston tietojärjestelmien integroinnilla

Tuotekehitysverkoston läpimenoajan lyhentäminen tuotemuutostenhallinnalla ja verkoston tietojärjestelmien integroinnilla Tuotekehitysverkoston läpimenoajan lyhentäminen tuotemuutostenhallinnalla ja verkoston tietojärjestelmien integroinnilla Yhteenveto NetData-tutkimusprojektin tuloksista http://www.soberit.hut.fi/netdata/

Lisätiedot

Ohjelmointikielet ja -paradigmat 5op. Markus Norrena

Ohjelmointikielet ja -paradigmat 5op. Markus Norrena Ohjelmointikielet ja -paradigmat 5op Markus Norrena Ko#tehtävä 4 Viimeistele "alkeellinen kuvagalleria". Käytännössä kaksi sivua Yksi jolla voi ladata kuvia palvelimelle (file upload) Toinen jolla ladattuja

Lisätiedot

010627000 Tietoturvan Perusteet Yksittäisen tietokoneen turva

010627000 Tietoturvan Perusteet Yksittäisen tietokoneen turva 010627000 Tietoturvan Perusteet Yksittäisen tietokoneen turva Pekka Jäppinen 31. lokakuuta 2007 Pekka Jäppinen, Lappeenranta University of Technology: 31. lokakuuta 2007 Tietokone Koostuu raudasta ja ohjelmista

Lisätiedot

Julkaisun laji Opinnäytetyö. Sivumäärä 43

Julkaisun laji Opinnäytetyö. Sivumäärä 43 OPINNÄYTETYÖN KUVAILULEHTI Tekijä(t) SUKUNIMI, Etunimi ISOVIITA, Ilari LEHTONEN, Joni PELTOKANGAS, Johanna Työn nimi Julkaisun laji Opinnäytetyö Sivumäärä 43 Luottamuksellisuus ( ) saakka Päivämäärä 12.08.2010

Lisätiedot

Langattomien verkkojen tietosuojapalvelut

Langattomien verkkojen tietosuojapalvelut Langattomien verkkojen tietosuojapalvelut Sisältö Työn tausta & tavoitteet Käytetty metodiikka Työn lähtökohdat IEEE 802.11 verkkojen tietoturva Keskeiset tulokset Demonstraatiojärjestelmä Oman työn osuus

Lisätiedot

Trimble Feedback Mobile app ja rajapinnat Kuvaus

Trimble Feedback Mobile app ja rajapinnat Kuvaus Mobile app ja rajapinnat 16.1 Copyright 1992-2016 Trimble Solutions Corporation part of Trimble Navigation Ltd. All rights reserved. Table of Contents ii (13) Table of Contents 1.1 -integraatio Trimble

Lisätiedot

HL7 Clinical Document Architecture. Seminaari: Tiedonhallinta terveydenhuollossa Riku Niittymäki

HL7 Clinical Document Architecture. Seminaari: Tiedonhallinta terveydenhuollossa Riku Niittymäki HL7 Clinical Document Architecture Seminaari: Tiedonhallinta terveydenhuollossa Riku Niittymäki Clinical Document Architecture (CDA) HL7 järjestön standardi Ensimmäinen julkaisu 2000 ja toinen 2005 Kliinisen

Lisätiedot

Ohjelmistoarkkitehtuurit. Kevät

Ohjelmistoarkkitehtuurit. Kevät Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Viestipohjaisten yritysjärjestelmien suunnittelumallit Viestinvälitykseen perustuvat yritysjärjestelmät Peruselementit:

Lisätiedot

Action Request System

Action Request System Action Request System Manu Karjalainen Ohjelmistotuotantovälineet seminaari HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos 25.10.2000 Action Request System (ARS) Manu Karjalainen Ohjelmistotuotantovälineet

Lisätiedot

3 VIESTIT... 7 3.1 UUSI VIESTI... 7 3.2 VIESTIN LUKEMINEN... 9 3.3 SAAPUNEET JA LÄHETETYT... 9 3.4 KANSIOT... 10 3.5 ROSKAKORI...

3 VIESTIT... 7 3.1 UUSI VIESTI... 7 3.2 VIESTIN LUKEMINEN... 9 3.3 SAAPUNEET JA LÄHETETYT... 9 3.4 KANSIOT... 10 3.5 ROSKAKORI... OHJE HUOLTAJALLE 2 / 22 1 YLEISTÄ TIETOA HELMESTÄ... 3 2 ETUSIVU... 4 2.1 YHTEENVETO... 4 2.2 LUKUJÄRJESTYS / KOTITEHTÄVÄT / HUOMAUTUKSET... 4 2.3 VIESTIT... 6 2.4 KOKEET... 6 3 VIESTIT... 7 3.1 UUSI VIESTI...

Lisätiedot

Viestintäviraston EPP-rajapinta

Viestintäviraston EPP-rajapinta Viestintäviraston EPP-rajapinta EPP - Extensible Provisioning Protocol EPP on XML- pohjainen protokolla EPP:llä tarkoitetaan RFC-dokumenteissa määriteltyä tapaa liittyä rekisterin (registry) ylläpitäjän

Lisätiedot

Kela / IT-osasto KanTa-palveluryhmä Sähköisten lääkärintodistusten välitys KanTa-viestinvälitys

Kela / IT-osasto KanTa-palveluryhmä Sähköisten lääkärintodistusten välitys KanTa-viestinvälitys 1 Sähköisten lääkärintodistusten välitys KanTa-viestinvälitys 2 VERSIOHISTORIA Versio Pvm Tekijät Selite 1.0 10.5.2012 TV Ensimmäinen julkinen versio 1.1 6.6.2012 TV Välityssanoman lähetys muutetaan synkroniseksi

Lisätiedot

Lyhyt oppimäärä mistä salauksessa on kyse? Risto Hakala, Kyberturvallisuuskeskus, Viestintävirasto

Lyhyt oppimäärä mistä salauksessa on kyse? Risto Hakala, Kyberturvallisuuskeskus, Viestintävirasto Lyhyt oppimäärä mistä salauksessa on kyse? Risto Hakala, risto.hakala@viestintavirasto.fi Kyberturvallisuuskeskus, Viestintävirasto Sisältö Tiedon suojauksessa käytetyt menetelmät Salausratkaisun arviointi

Lisätiedot

Lyhyt oppimäärä mistä tietojen salauksessa on oikeasti kyse? Risto Hakala, Kyberturvallisuuskeskus, Viestintävirasto

Lyhyt oppimäärä mistä tietojen salauksessa on oikeasti kyse? Risto Hakala, Kyberturvallisuuskeskus, Viestintävirasto Lyhyt oppimäärä mistä tietojen salauksessa on oikeasti kyse? Risto Hakala, risto.hakala@ficora.fi Kyberturvallisuuskeskus, Viestintävirasto Sisältö Miten tietoa voidaan suojata? Mitä yksityiskohtia salausratkaisun

Lisätiedot

Verkkolaskun semanttinen malli

Verkkolaskun semanttinen malli Verkkolaskun semanttinen malli Verkkolaskun eurooppalainen kehitystyö CEN PC 434 Pirkko Vedenpää Integration Consultant Tieto, Value Networks pirkko.vedenpaa@tieto.com DIREKTIIVI 2014/55/EU sähköisestä

Lisätiedot

Portugalin tasavallan aloite neuvoston päätökseksi Schengenin konsultointiverkoston (tekniset eritelmät) osan 1 muuttamisesta

Portugalin tasavallan aloite neuvoston päätökseksi Schengenin konsultointiverkoston (tekniset eritelmät) osan 1 muuttamisesta Conseil UE EUROOPAN UNIONIN NEUVOSTO Bryssel, 26. lokakuuta 2007 (07.11) (OR. en) PUBLIC 14215/07 LIMITE VISA 334 COMIX 924 ILMOITUS Lähettäjä: Vastaanottaja: Asia: Puheenjohtajavaltio Viisumityöryhmä

Lisätiedot

SOA SIG SOA Tuotetoimittajan näkökulma

SOA SIG SOA Tuotetoimittajan näkökulma SOA SIG SOA Tuotetoimittajan näkökulma 12.11.2007 Kimmo Kaskikallio IT Architect Sisältö IBM SOA Palveluiden elinkaarimalli IBM Tuotteet elinkaarimallin tukena Palvelukeskeinen arkkitehtuuri (SOA) Eri

Lisätiedot

Digitaalisen median tekniikat xhtml - jatkuu Harri Laine 1

Digitaalisen median tekniikat xhtml - jatkuu Harri Laine 1 Digitaalisen median tekniikat xhtml - jatkuu 30.4.2004 Harri Laine 1 XHTML lomakkeet Lomakkeet mahdollistavat tiedon välityksen asiakkaalta (selaimesta) tiedon vastaanottajalle Vastaanottaja voi olla sähköpostiosoite

Lisätiedot

PSY181 Psykologisen tutkimuksen perusteet, kirjallinen harjoitustyö ja kirjatentti

PSY181 Psykologisen tutkimuksen perusteet, kirjallinen harjoitustyö ja kirjatentti PSY181 Psykologisen tutkimuksen perusteet, kirjallinen harjoitustyö ja kirjatentti Harjoitustyön ohje Tehtävänäsi on laatia tutkimussuunnitelma. Itse tutkimusta ei toteuteta, mutta suunnitelman tulisi

Lisätiedot

AS2 Applicability Statement 2

AS2 Applicability Statement 2 Toteutettu yhteistyössä Elintarviketeollisuusliitto ry:n ja Päivittäistavarakauppa ry:n kanssa osana maa- ja metsätalousministeriön kansallista elintarviketalouden laatustrategiaa Tiedonsiirtosuositus

Lisätiedot

Käytettävyys ja käyttäjätutkimus. Yhteisöt ja kommunikaatiosuunnittelu 2012 / Tero Köpsi

Käytettävyys ja käyttäjätutkimus. Yhteisöt ja kommunikaatiosuunnittelu 2012 / Tero Köpsi Käytettävyys ja käyttäjätutkimus Yhteisöt ja kommunikaatiosuunnittelu 2012 / Tero Köpsi Teron luennot Ke 15.2 miniluento Ti 28.2 viikkotehtävän anto (T,M) To 1.3 Tero paikalla (tehtävien tekoa) Ti 6.3

Lisätiedot

Kuljetus/Sovelluskerroksen tietoturvaratkaisut

Kuljetus/Sovelluskerroksen tietoturvaratkaisut Kuljetus/Sovelluskerroksen tietoturvaratkaisut 1 Tämän luennon aiheet Transport Layer Security (TLS) Secure Shell (SSH) 2 Transport Layer Security (TLS) Sopii monenlaisille sovellusprotokollille Toimi

Lisätiedot

Tämän luennon aiheet. Kuljetus/Sovelluskerroksen tietoturvaratkaisut. TLS:n turvaama HTTP. Transport Layer Security (TLS) TLS:n suojaama sähköposti

Tämän luennon aiheet. Kuljetus/Sovelluskerroksen tietoturvaratkaisut. TLS:n turvaama HTTP. Transport Layer Security (TLS) TLS:n suojaama sähköposti Tämän luennon aiheet Kuljetus/Sovelluskerroksen tietoturvaratkaisut Transport Layer Security (TLS) Secure Shell (SSH) 1 2 Transport Layer Security (TLS) Sopii monenlaisille sovellusprotokollille Toimi

Lisätiedot

Tentti erilaiset kysymystyypit

Tentti erilaiset kysymystyypit Tentti erilaiset kysymystyypit Kysymystyyppien kanssa kannatta huomioida, että ne ovat yhteydessä tentin asetuksiin ja erityisesti Kysymysten toimintatapa-kohtaan, jossa määritellään arvioidaanko kysymykset

Lisätiedot

1.3 Lohkorakenne muodostetaan käyttämällä a) puolipistettä b) aaltosulkeita c) BEGIN ja END lausekkeita d) sisennystä

1.3 Lohkorakenne muodostetaan käyttämällä a) puolipistettä b) aaltosulkeita c) BEGIN ja END lausekkeita d) sisennystä OULUN YLIOPISTO Tietojenkäsittelytieteiden laitos Johdatus ohjelmointiin 811122P (5 op.) 12.12.2005 Ohjelmointikieli on Java. Tentissä saa olla materiaali mukana. Tenttitulokset julkaistaan aikaisintaan

Lisätiedot

PARTNERSHIP MONITOR. POTRA-NIS Oy I I

PARTNERSHIP MONITOR. POTRA-NIS Oy I I Partnership Monitor PARTNERSHIP MONITOR Partnership Monitor on menetelmä teollisuusyrityksille tuottavuuden lisäämiseksi ja liiketoiminnan kasvattamiseksi hyvin toimivien asiakas- ja toimittajasuhteiden

Lisätiedot

1.3Lohkorakenne muodostetaan käyttämällä a) puolipistettä b) aaltosulkeita c) BEGIN ja END lausekkeita d) sisennystä

1.3Lohkorakenne muodostetaan käyttämällä a) puolipistettä b) aaltosulkeita c) BEGIN ja END lausekkeita d) sisennystä OULUN YLIOPISTO Tietojenkäsittelytieteiden laitos Johdatus ohjelmointiin 81122P (4 ov.) 30.5.2005 Ohjelmointikieli on Java. Tentissä saa olla materiaali mukana. Tenttitulokset julkaistaan aikaisintaan

Lisätiedot

Information on Finnish Language Courses Spring Semester 2017 Jenni Laine

Information on Finnish Language Courses Spring Semester 2017 Jenni Laine Information on Finnish Language Courses Spring Semester 2017 Jenni Laine 4.1.2017 KIELIKESKUS LANGUAGE CENTRE Puhutko suomea? Do you speak Finnish? -Hei! -Moi! -Mitä kuuluu? -Kiitos, hyvää. -Entä sinulle?

Lisätiedot

Museo 2015 järjestelmä ja Museoiden luettelointiohjeet

Museo 2015 järjestelmä ja Museoiden luettelointiohjeet Museo 2015 järjestelmä ja Museoiden luettelointiohjeet Pilottimuseoiden tapaaminen Leena Furu 14.11.2013 Luetteloinnin kehittäminen Luettelointityöryhmä 16 museoammattilaista ympäri Suomen Päätavoite:

Lisätiedot

Hankkeen toiminnot työsuunnitelman laatiminen

Hankkeen toiminnot työsuunnitelman laatiminen Hankkeen toiminnot työsuunnitelman laatiminen Online-hanketyöpaja innovaatioiden siirto -hanketta valmisteleville 24.11.2011 Työsuunnitelma Vastaa kysymykseen mitä projektissa tehdään, jotta tuotokset

Lisätiedot

Option GlobeSurfer III pikakäyttöopas

Option GlobeSurfer III pikakäyttöopas Option GlobeSurfer III pikakäyttöopas Laitteen ensimmäinen käyttöönotto 1. Aseta SIM-kortti laitteen pohjaan pyötätuen takana olevaan SIM-korttipaikkaan 2. Aseta mukana tullut ethernetkaapeli tietokoneen

Lisätiedot

Tietoturva-asetus ja sen vaikutukset rekisterien ylläpitoon ja tietoluovutuksiin A-P Ollila 1

Tietoturva-asetus ja sen vaikutukset rekisterien ylläpitoon ja tietoluovutuksiin A-P Ollila 1 Tietoturva-asetus ja sen vaikutukset rekisterien ylläpitoon ja tietoluovutuksiin 12.12.2011 A-P Ollila 1 Taustaa Tiedon merkitys yhteiskunnassa ja viranomaisten toiminnassa korostuu kaiken aikaa. Viranomaisten

Lisätiedot

Luonnos eams-rakenteeksi

Luonnos eams-rakenteeksi JHS-XXX: eams-rakenne ja xml-skeema Luonnos eams-rakenteeksi 19.4.2013 Tässä dokumentissa kuvataan keskeiset linjaukset tulevan JHS-suosituksen määrittämäksi eamsrakenteeksi. Dokumentti ei ole JHS-suositusluonnos,

Lisätiedot

Tiedostojen jakaminen turvallisesti

Tiedostojen jakaminen turvallisesti Tiedostojen jakaminen turvallisesti Taustaa Tiedostojen jakaminen sähköisesti (File Sharing) on ollut joissakin organisaatioissa ongelmallista hallita. Jaettaviksi halutut viestit ovat liitetiedostoineen

Lisätiedot

OpenVPN LAN to LAN - yhteys kahden laitteen välille

OpenVPN LAN to LAN - yhteys kahden laitteen välille TW- EAV510 / TW- EAV510 AC: OpenVPN LAN to LAN - yhteys kahden laitteen välille Esimerkissä on käytetty kahta TW- EAV510 laitetta OpenVPN LAN to LAN yhteydellä voidaan luoda VPN- yhteys, jossa liikenne

Lisätiedot

Elisa efax. Käyttöohje

Elisa efax. Käyttöohje Elisa efax Käyttöohje 1 Sisällysluettelo 1 Ohjeen käyttötarkoitus... 2 2 efax palvelun käytön aloittaminen... 2 3 Faksin lähettäminen... 3 4 Faksin vastaanottaminen... 4 5 Kuittaukset ja raportit... 4

Lisätiedot

MY KNX, KNX sivu sinua varten Mitä pitää muistaa: Pidä tietosi ajan tasalla

MY KNX, KNX sivu sinua varten Mitä pitää muistaa: Pidä tietosi ajan tasalla MY KNX, KNX sivu sinua varten Mitä pitää muistaa: Pidä tietosi ajan tasalla Tervetuloa mukaan Sisällysluettelo yleistä... 3 MY KNX... 3 Kirjaudu KNX organisaation kotisivulle... 4 Partnerluettelo... 5

Lisätiedot

SÄHKE-hanke. Tekninen mallintamisen Siirtotiedoston metatietokuvaukset

SÄHKE-hanke. Tekninen mallintamisen Siirtotiedoston metatietokuvaukset 04.02.2005 1 (15) SÄHKE-hanke Tekninen mallintamisen Versio ja pvm Laatinut Tarkpvm Tarkastanut Hyvpvm Hyväksynyt 2.0 / 04.02.2005 Anneli Rantanen 15.02.2005 Markus Merenmies 18.02.2005 Ohjausryhmä 04.02.2005

Lisätiedot

MY STANDARD -OHJE. mystandard.hansaworld.com. Standard ERP Pilvipalvelu Sivu 1/6

MY STANDARD -OHJE. mystandard.hansaworld.com. Standard ERP Pilvipalvelu Sivu 1/6 MY STANDARD -OHJE mystandard.hansaworld.com Standard ERP Pilvipalvelu Sivu 1/6 KÄYTTÖÖNOTTO Mikäli Standard ERP -ohjelmistonne on HansaWorldin pilvipalvelimella (hostingissa), teidän on mahdollista hallinnoida

Lisätiedot

Sähke2 Meta+etomalli. Ari Vainio

Sähke2 Meta+etomalli. Ari Vainio Sähke2 Meta+etomalli Ari Vainio 6.8.2012 Yhteenveto Tämä dokumen> kuvaa Sähke2 meta+etomallia ylätasolla. Dokumen+n tavoibeena on selventää keskustelua siitä, mitä Sähke2 vaa+i sitä käybäviltä järjestelmiltä.

Lisätiedot

Salasanojen hallinta. Salasanojen hallintaopas RESTAURANT ENTERPRISE SOLUTION

Salasanojen hallinta. Salasanojen hallintaopas RESTAURANT ENTERPRISE SOLUTION Salasanojen hallinta Salasanojen hallintaopas RESTAURANT ENTERPRISE SOLUTION Restaurant Enterprise Solution Asiakirjan tarkoitus Tämä asiakirja kertoo tarvittavat säännöt kuinka hallinnoida RES salasanoja

Lisätiedot

Tentti erilaiset kysymystyypit

Tentti erilaiset kysymystyypit Tentti erilaiset kysymystyypit Monivalinta Monivalintatehtävässä opiskelija valitsee vastauksen valmiiden vastausvaihtoehtojen joukosta. Tehtävään voi olla yksi tai useampi oikea vastaus. Varmista, että

Lisätiedot

Loppukäyttäjän ohje Asennus- ja käyttöohje Mac

Loppukäyttäjän ohje Asennus- ja käyttöohje Mac Loppukäyttäjän ohje Asennus- ja käyttöohje Mac Fujitsun mpollux DigiSign Client on kortinlukijaohjelmisto, jonka avulla voit kirjautua luotettavasti ja turvallisesti organisaation tietoverkkoon tai sähköiseen

Lisätiedot

7.4 Variability management

7.4 Variability management 7.4 Variability management time... space software product-line should support variability in space (different products) support variability in time (maintenance, evolution) 1 Product variation Product

Lisätiedot

VÄLI- JA LOPPURAPORTOINTI

VÄLI- JA LOPPURAPORTOINTI Tuija Nikkari 2012 VÄLI- JA LOPPURAPORTOINTI Raportointikoulutus 23.8.12 Raportoinnin tarkoitus Raportoinnin tehtävänä on tuottaa tietoa projektin etenemisestä ja tuloksista rahoittajalle, yhteistyökumppaneille

Lisätiedot

1 YLEISTÄ TIETOA HELMESTÄ ETUSIVU YHTEENVETO LUKUJÄRJESTYS / KOTITEHTÄVÄT / MERKINNÄT VIESTIT KOKEET...

1 YLEISTÄ TIETOA HELMESTÄ ETUSIVU YHTEENVETO LUKUJÄRJESTYS / KOTITEHTÄVÄT / MERKINNÄT VIESTIT KOKEET... OHJE OPPILAALLE 2 / 21 1 YLEISTÄ TIETOA HELMESTÄ... 3 2 ETUSIVU... 4 2.1 YHTEENVETO... 4 2.2 LUKUJÄRJESTYS / KOTITEHTÄVÄT / MERKINNÄT... 4 2.3 VIESTIT... 6 2.4 KOKEET... 6 3 VIESTIT... 7 3.1 UUSI VIESTI...

Lisätiedot

Sähköisen liiketoiminnan tason mittaaminen pk-yrityksissä (aihe-esittely)

Sähköisen liiketoiminnan tason mittaaminen pk-yrityksissä (aihe-esittely) Sähköisen liiketoiminnan tason mittaaminen pk-yrityksissä (aihe-esittely) 24.1.2011 Ohjaaja: DI Tommi Kemppainen Valvoja: Prof. Ahti Salo Työn tausta Asiakas on tilannut ohjelmiston, jolla pkyrittäjät

Lisätiedot

Luku 10 Käyttöönoton suunnitteluja toteutusvaihe

Luku 10 Käyttöönoton suunnitteluja toteutusvaihe Luku 10 Käyttöönoton suunnitteluja toteutusvaihe Käyttöönoton Roll-Out Planning suunnittelu- & Preparation ja valmistelu Design Tiedon- Data Conversion muunnos- prosessien Processes suunnittelu Toimipisteiden

Lisätiedot

Verkkosisällön saavutettavuusohjeet 2.0: hyviä ohjeita monimuotoisen sisällön suunnitteluun ja arviointiin

Verkkosisällön saavutettavuusohjeet 2.0: hyviä ohjeita monimuotoisen sisällön suunnitteluun ja arviointiin Verkkosisällön saavutettavuusohjeet 2.0: hyviä ohjeita monimuotoisen sisällön suunnitteluun ja arviointiin Ossi Nykänen Tampereen teknillinen yliopisto, Hypermedialaboratorio, W3C Suomen toimisto Terveyden

Lisätiedot

Metsähallituksen Tarjouspalvelu.fi toimittajaportaalin esittely. Taimikonhoidon ja istutuksen hankinnat

Metsähallituksen Tarjouspalvelu.fi toimittajaportaalin esittely. Taimikonhoidon ja istutuksen hankinnat Metsähallituksen Tarjouspalvelu.fi toimittajaportaalin esittely Taimikonhoidon ja istutuksen hankinnat Tarjouspalvelu.fi -toimittajaportaali https://tarjouspalvelu.fi/metsähallitus Tämän palvelun kautta

Lisätiedot

YH2: Office365 II, verkko-opiskelu

YH2: Office365 II, verkko-opiskelu Aulikki Hyrskykari, Antti Sand, Juhani Linna YH2: Office365 II, verkko-opiskelu Huom. Suosittelemme tämän yksilöharjoituksen 2 tekemistä mikroluokassa, jotta yliopiston mikroluokat tulevat edes hieman

Lisätiedot

Tietoturvatekniikka Ursula Holmström

Tietoturvatekniikka Ursula Holmström Tietoturvatekniikka Ursula Holmström Tietoturvatekniikka Tietoturvan osa-alueet Muutama esimerkki Miten toteutetaan Eheys Luottamuksellisuus Saatavuus Tietoturvaterminologiaa Luottamuksellisuus Eheys Saatavuus

Lisätiedot

Digitaalisen median tekniikat. JSP ja XML Harri Laine 1

Digitaalisen median tekniikat. JSP ja XML Harri Laine 1 Digitaalisen median tekniikat JSP ja XML 28.4.2004 Harri Laine 1 JSP hyvin lyhyesti JSP on Java-pohjainen skriptikieli JSP:llä laadittu sivu käännetään java-servletiksi (sivun toteutus vastaa servlettiluokan

Lisätiedot

Sähköinen, suojattu asiointi kirjaamon ja

Sähköinen, suojattu asiointi kirjaamon ja OHJE 1 (7) Sähköinen, suojattu asiointi kirjaamon ja potilaskertomusarkiston kanssa verkkopankkitunnistautuminen Palveluun kirjautuminen 1. Täytä tarvitsemasi tilaus / pyyntö / hakemus lomake ja tallenna

Lisätiedot

Harri Kaukovuo Senior Sales Consultant Technology Sales Oracle Finland Oy

Harri Kaukovuo Senior Sales Consultant Technology Sales Oracle Finland Oy Harri Kaukovuo Senior Sales Consultant Technology Sales Oracle Finland Oy Oracle10 g Web Services Sisältö Service Oriented Architecture (SOA) Web Services Service Oriented Architecture Service Oriented

Lisätiedot

Terveydenhuollon standardoinnin tilanne tänään, tietohallintopäälli kkö Pekka Ruotsalainen, Stakes

Terveydenhuollon standardoinnin tilanne tänään, tietohallintopäälli kkö Pekka Ruotsalainen, Stakes SUOMEN KUNTAUITTO Sosiaali- ja terveysyksikkö TERVEYDENHUOLLON 27. ATK- PAIVAT 4. - 5.6.2001 Terveydenhuollon standardoinnin tilanne tänään, tietohallintopäälli kkö Pekka Ruotsalainen, Stakes cncydcnhuollon

Lisätiedot

Tehokasta tiedonvälitystä rakennusalalla

Tehokasta tiedonvälitystä rakennusalalla Tehokasta tiedonvälitystä rakennusalalla VERA-seminaari Oulussa 20.2.2002 Lasse Öhman, Lennart Söderström StreamServe Businesskommunikointi on arkipäivän liiketoimintaan liittyvät asiakirjat kuten laskut,

Lisätiedot

SISÄLLYSLUETTELO. Standard Taloushallinto Verkkolaskutus Sivu 1/9

SISÄLLYSLUETTELO. Standard Taloushallinto Verkkolaskutus Sivu 1/9 SISÄLLYSLUETTELO Johdanto... 2 Käyttöönotto... 3 Verkkolaskutuksen aktivointi... 3 Järjestelmän asetukset ja liikekumppanitiedot... 3 Yritystiedot -asetus... 3 Liitteet verkkolaskuille...7 Verkkolaskujen

Lisätiedot

ARKKITEHTUURIMÄÄRITTELY 0.3 Luonnos

ARKKITEHTUURIMÄÄRITTELY 0.3 Luonnos 1.1.2005 ARKKITEHTUURIMÄÄRITTELY 0.3 Luonnos DOKUMENTIN nimi 2 (17) VERSIONHALLINTA Versio Päivä Tekijä Kuvaus 0.1 2.10.2006 Tuomas Tolvanen Ensimmäinen versio 0.2 4.10.2006 Tuomas Tolvanen Lisätty vaatimuksia

Lisätiedot