Åpen EDI
en åpen elektronisk arena.
Av Per Myrseth, Norsk Regnesentral
Hensikten med Åpen EDI referansemodell er å kunne utvikle og ta i bruk systemer for elektronisk handel / informasjonsutveksling. Systemene er åpne, skalerbare og uavhengig av teknologi og meldingssyntaks. For sluttbrukere vil systemene opptre som brukervennlige og de teknologisk komplekse deler av et system vil være innkapslet. Åpen EDI referansemodell koordinerer og stiller krav til eksisterende og kommende standarder knyttet til InterOrganisatoriske Systemer (IOS). Kort sagt benyttes et IOS som et verktøy for å utføre forretningstransaksjoner hvor flere virksomheter er involvert, og det vil bli utvekslet informasjon mellom de enkelte virksomheter involvert i transaksjonsutførelsen. Utbredelsen av internett er kanskje den kraftigste pådriver for IOS som baserer seg på Åpen EDI.
I denne artikkelen vil jeg beskrive:
Jeg vil gjøre oppmerksom på at beskrivelsene av punktene 3-4 baserer seg på en mulig realiseringsform for bruk av Åpen EDI referansemodell. Andre vil kunne tolke og implementere deler av Åpen-edi standarden på andre måter, men likevel vil de ende opp med et IOS som er i henhold til referansemodellen.
Christopher M. Stone, president i OMG (Object Management Group Inc) uttaler følgende om fremtidens nettverk:
(ref artikkler og foredrag fra http://www.omg.org). Dette passer godt inn med filosofien i Åpen EDI referansemodellen som er at en skal oppnå interoperabilitet både teknologisk og virksomhetsmessig.
Arbeidet med Åpen EDI referansemodellen ble påbegynt i 1989. Standarden utgjør et rammeverk som skal sikre interoperabilitet mellom de standarder som benyttes ved beskrivelse av bruksområde for et IOS, implementasjon og bruk av IOS. Det er skissert en del målsettinger som skal oppnås ved bruk av Åpen EDI referansemodell, disse er blant annet:
Åpen EDI referansemodell utvikles av ISO/IEC JTC1 SC30 Open EDI hvor Norge er aktivt med. Asbjørn Hovstø, Norsk EDIPRO, leder den norske referansegruppen for Open EDI. Per idag har standarden status som DIS (Draft Internasjonal Standard) nummer 14662.
Åpen EDI referansemodell baserer seg på bruk av generiske internasjonale standarder. En skal dermed være i stand til å ta steget fra meldingsutveksling mellom kjente EDI-aktører som opererer innenfor et gitt avtaleverk, til informasjonsutveksling på tvers av bransjer og landegrenser. Åpen EDI referansemodell introduserer standardiserte scenarier og standardiserte teknologiske tjenester til bruk.
Når et IOS basert på Åpen EDI referansemodell tas i bruk, skal det ikke lenger være nødvendig med bilaterale avtaler mellom EDI-aktørene. Når en EDI-aktør melder seg på som rolleutøver i et scenario aksepterer han samtidig de lover og regler som er knyttet til utøvelse av den aktuelle rolle. Alt som er relevant for gjennomføringen av en aktuell forretningstransaksjon vil være formelt beskrevet i scenariet.
Åpen EDI referansemodell fokuserer på forretningstransaksjoner sett fra to angrepsvinkler. Disse angrepsvinklene er operativt virksomhetsperspektiv (Business Operational View: BOV) og teknologisk tjenesteperspektiv (Functional Service View: FSV).
Operativt virksomhetsperspektiv fokuserer på og skal resultere i beskrivelser av:
Formelle beskrivelsesteknikker skal brukes til å beskrive scenarier. Åpen EDI referansemodell har definert at scenarier skal beskrives ved hjelp av roller, informasjonspakker og scenarioattributter. Aktuelle formelle beskrivelsesteknikker må kunne håndtere denne beskrivelsesoppdelingen.
Operativt virksomhetsperspektiv ser på alt som er relevant for å kunne ta riktige forretningsmessige beslutninger, og hva som må til for å kunne akseptere forpliktelser i forhold til andre EDI-aktører i et scenario. En vil skille mellom intern og ekstern oppførsel, hvor den eksterne oppførselen er av betydning for grensesnittet mot andre EDI-aktører. Intern oppførsel vil ikke modelleres som en del av operativt virksomhetsperspektiv, men anses som et internt anliggende hos den enkelte aktør.
Et scenario er en formell spesifikasjon av en klasse forretningstransaksjoner som har et felles forretningsmessig mål. Forskjellige brukergrupper vil med utgangspunkt i Åpen EDI referansemodellen utvikle scenarier. Scenariene skal være mest mulig generiske. Anbefalte og godkjente scenarier legges i et elektronisk scenariokatalog.
En rolle er en entitet som modellerer en EDI-aktørs eksternt tilsiktede adferd (adferd som er tillatt i henhold til aktuelt Åpen EDI scenaro).
Informasjonspakke:
En informasjonspakke er en semantisk beskrivelse av den informasjonen som utveksles mellom roller i et scenario.
Angir formell spesifikasjon av informasjon, relevant for scenariet som helhet. Informasjonen er ikke spesifikk til hverken roller eller informasjonspakker. Eksempler på scenarioattributter er:(i) relasjoner mellom roller. (ii) lover og regler som angår scenariet som helhet.
Figurer viser på en forenklet måte hvordan Åpen EDI referansemodellen deler opp i virksomhets perspektiv og teknologisk perspektiv. Videre viser figuren og hvordan det inne hver av perspektivene skal benyttes metoder og notasjoner for å lage de relevante beskrivelsene. De metoder og notasjoner som er nevnt i figuren er kun ment som eksempler.
Teknologisk tjenesteperspektiv ser på hvilke teknologiske tjenester som må til får å kunne utføre forretningstransaksjoner, det vil si:
Teknologisk tjenesteperspektiv ser på det teknologiske samspillet mellom interne interorganisatoriske systemer. Det vil si de teknologiske tjenester som benyttes for å implementere et IOS og som gjør det mulig å utføre forretningstransaksjoner ved hjelp av et IOS.
De teknologiske tjenestene skal gjøre det mulig å initiere og operere forretningstransaksjoner. Eksempler på teknologisk tjeneste er følgende:
Forenklet kan en dele teknologisk tjenesteperspektiv opp i tre hovedlag. Disse lagene er: automatisert rolleutøver, utvekslings- og sikkerhetstjenester og nett-tjenester.
Hovedhensikten med interorganisatoriske systemer er at forskjellige EDI-aktører skal kunne utføre forretningstransaksjoner elektronisk. For at interorganisatoriske systemer skal gi interoperabilitet både teknologisk og virksomhetsmessig, må grensesnittene mellom de interne interorganisatoriske systemene være veldefinert. Et internt interorganisatorisk system skal ha et eksternt grensesnitt definert av den eller de rollene EDI-aktøren utøver. Informasjonspakkene som utveksles må være veldefinerte og entydige, ellers vet ikke rollene hva slags informasjon andre roller forventer å få, og rollen selv vet ikke hva den vil motta. For å kunne plassere ansvar og funksjonalitet er det helt sentralt å vite hva slags ekstern adferd en rolle har. Hvilken informasjon som skal utveksles må være definert, og det må beskrives hvilke informasjonspakker som skal utveksles mellom hvilke roller.
Beskrivelse av bruksområde for et IOS er delt i to faser. (i) Først må en beskrive aktuelle scenarier generisk ved å benytte formelle beskrivelsesteknikker, (ii) deretter vil en enkelt EDI-aktør velge hvilke roller i hvilke scenarier han ønsker å kunne utøve. Det som skal beskrives i fase (i) er bl.a:
Kravene Åpen EDI referansemodell stiller til formelle beskrivelsesteknikker, benyttes av brukergrupper til å velge formelle beskrivelsesteknikker. Brukergruppen kan være en bransjeorganisasjon, en gruppe virksomheter, representanter for offentlig virksomhet, standardiseringsorgan (f.eks Norsk EDIPRO) m.m. Brukergruppen benytter de valgte formelle beskrivelsesteknikkene til å beskrive et scenario. Scenariobeskrivelsen bør være mest mulig generell for å unngå at en får mange nesten like scenarier. Denne scenariobeskrivelsen er ikke en beskrivelse av et konkret system, men i hovedsak en beskrivelse av grensesnitt mellom interne IOS, og krav til denne type system. De ferdige beskrivelsene sendes til en registreringsmyndighet som etter godkjenning legger beskrivelsen inn i operativt virksomhetsperspektiv sin scenariokatalog. Denne beskrivelsen vil senere bli brukt som bakgrunn for å utvikle teknologiske tjenester og til å automatisk/semi automatisk generere interne IOS. Den enkelte EDI-aktør som skal bruke et interorganisatorisk system vil vanligvis bli involvert først i neste fase.
Følgende skisse beskriver hvordan enkele scenarier blir etter behov satt sammen til sammensatte scenarier.
Figuren viser hvordan en ved bruk av syntese setter sammen små enkle scenarier som om de skulle vært byggeklosser. Bruk av syntese vil gjøre det mulig å sette sammen roller fra forskjellige scenarier slik at en EDI-aktør kan utøve de rollene han er interessert i.
De teknologiske tjenestene vil også bli formelt spesifisert og lagt i en katalog. Dette skjer f.eks ved at en arbeidsgrupper av teknologer tar tak i kravene scenariene stiller til teknologiske tjenester, og på denne bakgrunn beskriver i detalj kravene til de teknologiske tjenestene.
Denne fasen skal ta for seg selve implementeringen av et internt interorganisatorisk system som baserer seg på Åpen EDI referansemodellen. Resultatene fra forrige fase var formelle beskrivelser av scenarier, og formelle beskrivelser av teknologiske tjenester. Det interne IOS blir implementert på basis av resultatene fra forrige fase. I denne fasen er den enkelte EDI-aktør i fokus. Det interne IOS som den enkelte EDI-aktør skal benytte blir nå satt sammen ut fra godkjente scenariobeskrivelser.
Åpen EDI referansemodellen sier at en skal legge de formelle scenariobeskrivelsene i en katalog. Videre skal disse formelle beskrivelsene ved hjelp av f.eks. CASE verktøy, og i kraft av at de er formelle beskrivelser, kunne resultere i systemer som kan utøve roller. Evt. skal systemene kunne interpretere scenariobeskrivelsene på en slik måte at de utøver roller. Noe forenklet kan en si at scenariobeskrivelsene skal automatisk, ved hjelp av en CASE type verktøy, kunne bli til et internt IOS. Viktige steg i denne fasen vil være som følger:
Forutsetningen for at et scenario skal kunne instansieres er at det finnes EDI-aktører som har implementert interne IOS basert på Åpen EDI referansemodellen. EDI-aktører må være registrert i rolle katalogen som utøvere av rollene som inngår i det aktuelle scenariet. Det første en EDI-aktør bør gjøre er å melde seg som rolleutøver i rolle katalogen, med hvilke roller og hvilke informasjonspakker med tilleggspakker han støtter utøvelsen av. Rolle katalogen er tilgjengelig via teknologiske tjenester. Noen rolleutøvere vil i kraft av den rollen de ønsker å utøve kunne instansiere et scenario. Først må den rolleutøveren som skal instansiere scenariet få tak i de andre rolleutøverne i scenariet. Denne søkingen etter rolleutøvere vil sannsynligvis være nyttig å legge i et eget scenario, kalt pre-scenario. Dette overfører resultatet av søkingen til den EDI-aktøren som initierer scenariet. Når kandidater til utøverne er funnet starter forhandlingene som avgjør hvem som får tilslag til å utøve de forskjellige rollene. I denne pre-scenario fasen kan en gjerne se for seg en form for børsing av rolleutøvere, hvor en forhandler om rabatter og andre leveringsbetingelser. Det er viktig å merke seg at EDI-aktørene kan delegere funksjonalitet og ansvar til andre aktører.
Figuren viser to EDI-aktører som begge har implementert de nødvendige delene av et interne IOS. En TTP (tiltrodd tredjepart) er tilknyttet nettet, og en rekke ressurser som er nødvendig for at Åpen EDI infrastrukturen skal kunne fungere er gjort tilgjengelig. Til sammen utgjør de et eksempel på et helhetlig IOS. Realisering ved bruk av f.eks. Konkrete teknologi eksempler for å realisere denne topologien vil kunne være WEB-klienter med Java/ActiveX og utstrakt bruk av CORBA eller tilsvarende.