Infrastruktur for elektronisk handel

Transkript

1 Prosjekt i regi av Norsk EDIPRO Bruk av Registry og Repository i en åpen infrastruktur for elektronisk samhandling Versjon oktober 2002 Norsk EDIPRO Tel Postboks 2526 Solli Fax Oslo Internett:

2 i en åpen infrastruktur for elektronisk samhandling 30.oktober 2002 Copyright Norsk EDIPRO, All Rights Reserved. Dette dokumentet er utarbeidet som en del av dokumentasjonen fra prosjektet Infrastruktur for elektronisk handel i regi av Norsk EDIPRO. Dette dokumentet, og oversettelser av det, kan fritt kopieres og distribueres. Dokumentet kan fritt brukes som grunnlag for arbeid som forklarer og/eller kommenterer på innholdet i dokumentet eller på annen måte bidrar til at spesifikasjonen blir tatt i bruk. Slikt avledet arbeid kan fritt utarbeides, kopieres, publiseres og distribueres forutsatt at det gis behørig referanse til dette dokumentet og at det ikke legges begrensninger arbeidet utover det som er definert i denne teksten. Dette dokumentet i seg selv kan imidlertid ikke endres på noen måte med unntak av det som måtte være nødvendig i forbindelse med oversettelse. Dette dokumentet reflekterer de synspunkter og konklusjoner som har fremkommet gjennom arbeid i prosjektet og ikke nødvendigvis synspunktene til de enkelte deltakerne eller deres arbeidsgivere. 2

3 i en åpen infrastruktur for elektronisk samhandling 30.oktober 2002 Forord Prosjektet Infrastruktur for elektronisk handel ble initiert av Norsk EDIPRO i samarbeid med leverandører og brukere våren I kartleggingsfasen, som ble gjennomført våren/sommeren 2000, ble det blant annet gjennomført en serie intervjuer for å kartlegge brukerbehov og avklare problemstillinger knyttet til en felles åpen infrastruktur for elektronisk handel. Det videre arbeidet i prosjektet bygger på resultatene fra kartleggingsfasen og har tatt sikte på å utarbeide spesifikasjoner som skal legge til rette for etablering av en åpen infrastruktur for elektronisk samhandling. Infrastrukturen vil blant annet bestå av et sett av samvirkende informasjonsbanker (Repository) og tilhørende indeks (Registry) som er åpent tilgjengelig og inneholder informasjon om de konkrete e-handelsløsninger som benyttes i markedet. Ved at detaljerte beskrivelser av en virksomhets samhandlingsprosesser og tilhørende datainnhold (dvs samhandlingsmodellene) gjøres åpent tilgjengelig sammen med en beskrivelse av de tekniske e-handelsløsninger (dvs realiseringene), legges grunnlaget for en åpen infrastruktur av samhandlende applikasjoner, hvor også små og mellomstore virksomheter skal kunne delta. Dette dokumentet, Bruk av Registry og Repository i en åpen infrastruktur for elektronisk samhandling, beskriver hovedelementene i en Registry/Repository-løsning. I del 1 tar vi for oss den forretningsmessige anvendelsen av en Registry/Repository-løsning mens vi i del 2 ser nærmere på ulike teknologiske realiseringer. Hovedfokus er lagt på å beskrive innhold og bruk av en Registry/Repository-løsning uten tanke på konkrete løsningsteknologier. De øvrige delene av infrastrukturen er behandlet i andre dokumenter utgitt av prosjektet: Strategi og arkitektur for en åpen infrastruktur for elektronisk samhandling Krav til beskrivelsesteknikk for harmonisering av samhandlingsprosesser Beskrivelse av samhandlingsmodeller i en åpen infrastruktur Kravspesifikasjon for etablering og drift av Registry og Repository Application Readable Models in an open infrastructure Et tidlig utkast til dette dokumentet ble publisert i desember Foreliggende versjon er en vesentlig omarbeidning av dette arbeidet. Dette dokumentet er utarbeidet av en arbeidsgruppe under ledelse av Jostein Frømyr, EdiSys. Arbeidsgruppen har hatt følgende sammensetning: Arne-Jørgen Berre, SINTEF Jostein Frømyr, EdiSys Jørn Berg Nordlund, IBM Arild Nybakk, Skandinavisk Transport System Geir Ottersen, student ved UiO/SINTEF Christoffer Daae-Qvale, student ved UiO/SINTEF Hans Stubberud, student ved UiO/SINTEF Petter Sandvik, Antares Øyvind Aassve, Telenor Jan Mærøe, Tybring Gjedde Hans Petter Christiansen, Norsk Hydro Bjørn Aasheim, Norsk EDIPRO Dokumentet er editert av Arild Nybakk med utgangspunkt i bidrag fra en rekke av arbeidsgruppens deltakere. En åpen infrastruktur for elektronisk samhandling må etter prosjektets oppfatning tuftes på brukernes og aktørenes egen vilje og interesse for løsningene. Det er vårt håp at markedet finner de valgene/anbefalingene vi har gjort og de kravene vi har stilt både fornuftige og realistiske og anser samsvar med disse som et kvalitetsstempel. Oslo, 31 oktober 2002 Jostein Frømyr Prosjektleder 3

4 Innholdsfortegnelse TERMINOLOGI INNLEDNING BAKGRUNN MÅLSETNING MED BRUK AV REGISTRY/REPOSITORY MÅLGRUPPE FOR DETTE DOKUMENTET ORGANISERING AV DOKUMENTET I. FUNKSJONELLE KRAV TIL EN REGISTRY/REPOSITORY-LØSNING SCENARIER FOR BRUK AV REGISTRY/REPOSITORY INNLEDNING BRUKSSCENARIER FOR FOLK OG FOR APPLIKASJONER BRUKSSCENARIER FOR FOLK Hvem bruker hvilke løsninger? Hvem kan jeg handle med? Hva må jeg gjøre for å kunne handle med...? Nødvendige funksjoner BRUKSSCENARIER FOR APPLIKASJONER Innledning Grensesnittsoftware: Business Service Interface Grensesnittsoftwatens bruk av informasjon i RR-basen Eksempel: Harry Potter uttak av ransler fra lagerhotell FUNKSJONELLE KRAV TIL INNHOLD I REGISTRY/REPOSITORY INNHOLD I EN RR-BASE EHANDELSOBJEKTER OG HVORDAN DE ER RELATERT TIL HVERANDRE TILGANGSPUNKTER TIL INNHOLD I EN RR-BASE Plattformuavhengig modell Plattformspesifikk realisering Realiseringsdokumenter + semantisk mapping Realisering, mapping og modell Brukermetadata Gjennbrukbare informasjonskomponenter (BIE) SUBSETT AV SAMHANDLINGSMODELLER SEMANTIKKEN TIL INNHOLDET I EN RR-BASE STRUKTURERING AV INNHOLDET I EN RR-BASE XML-baserte lagringsstrukturer Grafiske lagringsstrukturer NAVNEKONVENSJONER KLASSIFISERING AV EHA NDELSOBJEKTER Geografi Bransje Forretningsområde Prosess Produktkategori Offesielle/legale rammebetingelser Rolle Klassifisfisering av de enkelte ehandelsobjektene HVA GÅR I REGISTRY OG HVA GÅR I REPOSITORY TYPER RR-BASER VERSJONSHÅNDTERING II. REGISTRY/REPOSITORY-TEKNOLOGIER

5 4 PLATTFORMER FOR REALISERING AV RR-BASER: EBXML OG UDDI INNLEDNING EBXMLS REGISTRY/REPOSITORY-LØSNING ebxml Registry Services (ebrs) ebxml Registry-informasjonsmodell (ebrim) UDDIS REGISTRY-LØSNING Innledning Beskrivelse av UDDI-arkitekturen Registrering av et firma og dets tjenester Best practices JAXR FELLES JAVA-GRENSESNITT FOR EBXML OG UDDI REALISERING AV VÅR RR-SPESIFIKASJON ebxml -løsning UDDI-løsning

6 Terminologi Listen inneholder definisjoner av sentrale begreper som beskriver hovedelementer i en framtidig infrastruktur for elektronisk handel, slik den er beskrevet i prosjektdokumentasjonen til Norsk EDIPROs prosjekt Infrastruktur for elektronisk handel. Listen er ikke endelig, men vil bli holdt løpende oppdatert i takt med utviklingen av prosjektet, både med hensyn til hvilke begreper som inngår i listen og med hensyn til den aktuelle definisjonen av hvert begrep. Listen er basert på innspill fra prosjektgruppen, Norsk EDIPRO, SINTEF Tele og Data, Norsk Regnesentral, samt annet åpent tilgjengelig kildemateriale. Term Definisjon Engelsk Aktivitet Handling som utføres av den enkelte rolle (aktør) som ledd i en samhandling. Beskrives i UML aktivitetsdiagram. Aktivitetsmodell UML aktivitetsdiagram som beskriver aktiviteter i en samhandling samt flyt av kontroll og informasjon mellom disse. Beskrivelsesteknikk Detaljert anvisning på hvordan man beskriver og presenterer samhandlingsmodeller (både prosess og informasjon) for å oppnå effektiv integrasjon av applikasjoner = definisjon av den måten innholdet i et Registry og Repository skal dokumenteres og presenteres på. Binding (Web Services) Interaksjon som innebærer at en tjenestebruker bruker en lokaliseringsoperasjon å binde seg til en Business Process Specification (BPS) Business Process Specification Schema (BPSS) Domene Domenekomponent Domenemodell ebxml Ehandelsobjekt Flerpartssamhandling (ebxml). Forgreningspunkt tjenestetilbyder og interagere med denne. XML-dokument (del av ebxml spesifikasjonen) som beskriver hvordan en samhandlingsprosess formelt skal defineres. Dokumentet spesifiserer alle sett av elementer som er nødvendige for å konfigurere et ebxml runtime system som kan gjennomføre ebxml forretningstransaksjoner. ebxml-dokument som inneholder den fulle definisjonen av beskrivelsen i BPS-dokumentet. Forretningskontekst (f.eks. transport, betaling, kjøp, salg) Et gjenbrukbart informasjonsobjekt til bruk i en spesiell sammenheng og forretningskontekst. Den totale informasjonsmodellen som er beskrevet for et domene. Den vil normalt være et supersett av flere informasjonsmodeller for samhandlingsmodeller innen domenet. Plattformspesifikk realisering for beskrivelse og realisering av samhandlingsprosesser. Utviklet av UN/CEFACT og OASIS i perioden november 1999 mai Et objekt som er tilgjengelig via et Registry og som er beskrevet i henhold til infrastrukturprosjektets beskrivelsesteknikk. En samhandling mellom flere enn to parter Punkt (hjelpetilstand) i et aktivitetsdiagram uttrykt ved en tykk vannrett strek der prosessen deler seg i to eller flere parallelle prosesser som ikke er gjensidig avhengige av hverandre (ikke-alternative). Det kan om ønskelig knyttes betingelser til forgreningstilstanden. 6 Business Information Entity (BIE) Fork

7 Term Definisjon Engelsk Forretningsaktivitet Basiskomponent i en topartssamhandling. Forretningsdokument Et dokument som utveksles mellom forretningspartnere i en forretningstransaksjon. Dokumentene har en veldefinert semantikk, og som regel også syntaks. Forretningsobjekt Bærer av forretningsinformasjon i en samhandlingsmodell, i form av klasser, attributter, relasjoner, eller lignende. Forretningspartner Forretningsprosessmodell Forretningstransaksjon Grensesnittsoftware Informasjonsmodell Interaksjonsmodell Kjernekomponent Koreografi (ebxml) Lokalisering (Web-services) Mapping Meldingsmodell OASIS Orkestrering (Webservices) Plattformspesifikkrealisering Plattformuavhengigmodell En bedrift eller næringsdrivende som inngår i forretningstransaksjoner med andre forretningspartnere. Detaljerte beskrivelser av de enkelte forretningsprosessene i en virksomhet Basiskomponent i en samhandling; utveksling av dokumenter eller meldinger mellom en eller flere forretningspartnere. Programvare som gjør en forretningstransaksjon i stand til å utføre (transaksjoner i) en elektronisk samhandling med en ekstern partners forretningsapplikasjon ved å anvende spesifikasjoner i en spesifikk realiseringsplattform (Web Services, ebxml, etc.) og prosessere innholdet i disse spesifikasjonene basert på innholdet og semantikken i en felles eksternt tilgjengelig samhandlingsmodell. UML klassediagram som beskriver forretningsobjekter (klasser, attributter og relasjoner) i domenet og relasjoner mellom disse. UML komponentdiagram som viser hvilke roller som samhandler over hvilke grensesnitt. Et gjenbrukbart, generisk informasjonsobjekt (ebxml) til bruk i forretningstransaksjoner. Lovlig rekkefølge på de meldinger som sendes mellom ulike roller (aktører) i en samhandling Interaksjon som innebærer at en tjenestebruker bruker en lokaliseringsoperasjon for å hente en tjenestebeskrivelse av en web-tjeneste (enten lokalt eller fra tjenesteregisteret). Oversettelse fra et objekt i en samhandlingsmodell til tilsvarende objekt i en annen samhandlingsmodell eller en intern applikasjons modell Et subsett av en samhandlingsmodells informasjonsmodell som spesifiserer innholdet av og strukturen i et objekt som overføres mellom to aktiviteter tilhørende to forskjellige roller i en aktivitetsmodell. Objektet som overføres kalles et flytobjekt. Organization for the Advancement of Structured Information Standards Samme som koreografi Modell som beskriver hvordan den plattformuavhengige modellen kan realiseres i ulike tekniske plattformer, for eksempel tekniske plattformer for ebxml, Web Services, EDI/EDIFACT, CORBA etc., gjennom blant annet bruk av transformasjonsregler. Beskrivelse av samhandlingen uavhengig av hvilken teknisk plattform som benyttes for realiseringen. Finnes i to versjoner: en for folk -versjon beskrevet med modelleringsspråket UML og en for 7 Business Object Type (BOT) Business Service Interface (BSI) Core Component

8 Term Definisjon Engelsk applikasjon -versjon beskrevet i XML. Publisering (Web-services) Interaksjon som innebærer at en tjenestetilbyder gjør en tjenestebeskrivelse av en web-tjeneste tilgjengelig for en tjenestebruker eller et tjenesteregister. Registry En indeks over den informasjon som er tilgjengelig i en eller flere andre Registries og/eller informasjonsbanker (Repository) om løsninger og tjenester for elektronisk handel med pekere til hvor i informasjonsbanken(e) (Repositoriene) opplysningene er tilgjengelige. Registry Information Model (ebxml) Registry Services (ebxml) Repository RPC Samhandling Samhandlingsavtale Samhandlingsmodell Samhandlingsprofil Samhandlingsprosess Samhandlingsspesifikasjon Sekvens Semantisk definisjon Semantisk mapping Sluttilstand SOAP Beskrivelse av hvordan innholdet i R&R-baser skal struktureres for å gjøre det tilgjengelig i et sett Registries/Repositories. Finnes i ebxmldokumentene ebxml Registry Information Model [ebrim] Beskrivelse av hvordan man får tilgang til innholdet i R&R-baser. Finnes i ebxml-dokumentet ebxml Registry Services Specification [ebrss]. En informasjonsbank hvor beskrivelsen av samhandlingsmodellen er lagret. Beskrivelse av innhold i Repository foreligger i to versjoner, en for mennesker (et subsett av UML) og en for applikasjoner (XML) Metodekall blant annet benyttet i SOAP som kjennetegnes ved at mottakende applikasjon forventes å sende et svar som tilfredsstiller den sendte forespørselen. Et sett med faktiske interaksjoner mellom forretningspartnere. Beskrivelse av hvilke regler og forpliktelser som gjelder for hver av forretningspartnerne i forbindelse med en konkret samhandling. Beskrivelse av hvordan den konkrete samhandlingen mellom to eller flere virksomheter innenfor samme eller forskjellige domener, skal gjennomføres Beskrivelse av hvordan en bedrift/bransje eller lignende. gjennomfører en konkret samhandling Måten ting gjøres på når to forretningspartnere utfører forretninger. Beskriver også hvordan roller, relasjoner og ansvar er fordelt mellom forretningspartnere som inngår i en slik prosess og hvordan den er inndelt i samhandlinger. Beskrivelse av rekkefølgen av og regelverket for forretningstransaksjoner i en samhandling. Samme som koreografi (ebxml) og orkestrering (Web Services) Rekkefølge på aktiviteter og operasjoner i en samhandlingsprosess. En entydig og presis forklaring av det meningsinnhold som tillegges et element i en samhandlingsmodell. Kobling til XML-beskrivelser av samhandlingsmodellen fra andre (plattformspesifikke) XML-beskrivelser. Tilstanden til en samhandling ved slutten av samhandlingsprosessen. Sluttilstanden kan ha verdiene Success eller Failure. Meldingsprotokoll basert på XML og RPC (Remote Procedure Call) som spesifiserer hvordan tjenester kan snakke sammen i en web-service-infrastruktur 8 Remote Procedure Call Collaboration Collaboration process Simple Object Access Protocol

9 Term Definisjon Engelsk ved å definere regler for hvordan en melding ser ut og hvordan data skal kodes. Starttilstand Tilstanden til en samhandling ved starten av en Start samhandlingsprosess. Synkroniseringspunkt Punkt (hjelpetilstand) i et aktivitetsdiagram uttrykt Join ved en tykk vannrett strek der to eller flere parallelle prosesser løper sammen i én prosess. Det kan om ønskelig knyttes betingelser til synkroniseringstilstanden. Tilgangspunkt Et subsett av mengden ehandelsobjekter i et Registry som kan identifiseres og aksesseres i en og samme operasjon Tilstand Betegnelse for hvilket stadium i prosessen en samhandling befinner seg i Tilstandsovergang Endring av tilstanden til en samhandling i forbindelse Transition med overføring av kontroll fra en aktør til en annen. Tilstandsvokter Betingelse som må være oppfylt for at en Guard tilstandsovergang kan skje. Kan blant annet benyttes for å spesifisere koreografien til en samhandling. Topartssamhandling En samhandling mellom to parter (ebxml) Transformasjonsregler UDDI UML UMM UN/CEFACT Web Services WSDL XML Regler for omformattering fra f.eks. XML-formatet i den plattformuavhengige modellen til XML-formatet i den valgte realiseringen. Spesifikasjon for web-baserte informasjonsregistere for Web Services som gjør det mulig for utviklere og administratorer på en enkel måte å dele informasjon om interne og offentlige web-tjenester hhv. på tvers av foretaket og over Internett. Modelleringsspråk utarbeidet av Object Management Group bestående i alt tolv standard diagramtyper for beskrivelse av samhandlingsprosesser. De facto standard for objektorientert modellering. En modelleringsmetode utarbeidet av FN-organet UN/CEFACT basert på blant annet UML med tanke på å beskrive elektroniske samhandlingsprosesser FNs senter for prosedyreforenkling og elektronisk forretningsdrift Tjenesteinfrastruktur basert på å dynamisk oppdage og bruke tjenester over Internett. XML-basert språk for å beskrive grensesnitt til webservices grensesnitt på et XML-format. Brukes til å spesifisere abstrakte operasjoner som deretter bindes til konkrete protokoller, f.eks. SOAP. Et språk for å beskrive innholdet av dokumenter. XML-dokumentet beskrives syntaktisk som et sett informasjonsobjekter (elementer i XML-terminologi), der hvert objekt identifiseres med en startelementtag og en tilhørende avslutningselementtag. Universal Description Discovery and Integration Unified Modeling Language Unified Modeling Methodology United Nations Centre for Trade Facilitation and Electronic Business Web Service Description Language extensible Markup Language 9

10 1 Innledning 1.1 Bakgrunn Utgangspunktet for Infrastrukturprosjektet var behovet for en felles (åpen) infrastruktur av verdiøkende tredjeparter som kan tilby tjenester som knytter ulike løsninger og teknologier sammen. Dette vil gjøre det enklere for bedrifter som ønsker å ta i bruk elektronisk handel å knytte seg opp mot ulike handelspartnere. En slik infrastruktur vil føre til færre mellomledd og sterkere integrasjon i hele verdikjeden. Følgende grunnleggende forutsetninger må være til stede før en felles infrastruktur kan realiseres: 1. Bedriftene må beskrive sine prosesser knyttet til utveksling av data (meldinger) med ulike handelspartnere på en entydig og strukturert måte 2. Beskrivelsene må gjøres åpent tilgjengelig for alle aktører i form av samhandlingsmodeller som beskriver funksjonalitet og informasjonsflyt i tilknytning til en handelstransaksjoner mellom partene 3. Det må beskrives hvordan den åpent tilgjengelige informasjonen kan lagres og aksesseres via tredjeparter på en måte som gjør det for bedriftene, særlig små og mellomstore bedrifter, å koble seg opp til eksisterende og potensielle handelspartnere. 4. Det må sikres samtrafikk og interoperabilitet mellom de ulike tredjepartsløsningene, slik at man får fri flyt av informasjon mellom de forskjellige løsningene. I tillegg kommer at de handlende bedriftene må se en reell eller potensiell verdiøkning i å benytte de tjenester som tredjepartene tilbyr. Punkt 1 - og delvis 2 - er beskrevet i tidligere leveranser i prosjektet - jf. Beskrivelse av samhandlingsmodeller i en åpen infrastruktur, versjon 2.0 datert 30. mai 2002 og Application Readable Models in an open infrastructure, versjon 1.0 datert juni Elementer i tilknytning til punkt 3 prinsipper for lagring av informasjonsmodellene i et Repository samt hvordan denne informasjonen kan aksesseres via et Registry vil beskrives i herværende dokument. Ideen om en felles, åpen infrastruktur er i stor grad knyttet til spørsmålet om hvilken rolle tredjepartene skal ha og hva slags tjenester / funksjonalitet de skal tilby. Selv om en infrastruktur for elektronisk handel teoretisk - kan eksistere uten tredjeparter, er tanken om Registry og Repository nært knyttet til bruken av slike aktører. Det er enighet om at verdiøkende tredjepartstjenester må drives fram av kjøper og selger eller de handlende parter i fellesskap. Handelspartnerne må gå sammen om å utvikle og tilgjengeliggjøre forretningsmodeller som omfatter hele samhandlingsprosessen dem i mellom knyttet til en bestemt forretningsfunksjon (kjøp, fakturabehandling, fortolling, etc.). Slike beskrivelser er en forutsetning for at ulike tredjeparter skal være i stand til å utvikle og tilby tjenester som gir en reell verdiøkning i form av sterkere integrasjon mellom partene. Manglende modenhet i markedet med få løsninger etablert samt begrensede ressurser i prosjektet, har gjort at man har valgt å legge seg på rent tekstlige beskrivelser av RRløsninger, med vekt på å vise overordnet funksjonalitet samt få fram hovedprinsippene som må ligge til grunn for fremtidige løsninger. 10

11 Mangelen på løsninger av den type som skisseres i dokumentet skyldes blant annet at mange bedrifter er tilbakeholdne med hensyn til å gjøre sine forretningsmodeller åpent tilgjengelig for konkurrenter / partnere og øvrige aktører i markeder. Enighet om hvilke samhandlingsmodeller som skal benyttes, er første skritt i retning av å få på plass gode tredjepartsløsninger. Infrastrukturprosjektet fokuserer på nettopp disse problemstillingene gjennom å legge til rette for standardiserte beskrivelser av samhandlingsmodeller samt åpne informasjonsbanker og tilhørende indeks som grunnlag for å utvikle og ta i bruk løsninger og som kan komme alle parter til gode. Det er imidlertid bare bedriftene selv som kan sørge for betingelsene for at dette kan skje er til stede. De etterfølgende beskrivelser av funksjonalitet, etc. i forhold til Registry/Repository tar utgangspunkt i slike beskrivelser. 1.2 Målsetning med bruk av Registry/Repository Den overordnede målsetningen med bruk av Registry/Repository er å gjøre det lettere - særlig for små og mellomstore bedrifter - å ta i bruk løsninger for elektronisk handel. Dette kan oppnås ved at Registry/ Repository-løsningene utformes slik at de både tar vare på og gir tilgang til for så vel applikasjoner som folk (dvs. brukere, forretningsutviklere, etc.) samhandlingsmodeller beskrevet og dokumentert i henhold til Infrastrukturprosjektets beskrivelsesteknikk. Registry er en indeks over hvilke samhandlingsmodeller og tekniske realiseringer som er tilgjengelig. I tillegg finnes en oversikt over hvem som benytter de ulike løsningene. Repository er en informasjonsbank med detaljerte beskrivelser av samhandlingsmodellene og de forskjellige tekniske realiseringene. I et marked med et mangfold av ulike tekniske og funksjonelle løsninger vil det være behov for å skape system og struktur blant de løsninger som finnes og å gjøre informasjonen om de ulike løsningene åpent tilgjengelig. En informasjonsbank og tilhørende indeks (Repository og Registry) vil være et sentralt element for å spre kunnskap om de løsninger som finnes. Informasjon om ulike løsninger, etc. tas vare på i Repository - en informasjonsbank som inneholder detaljerte beskrivelser av samhandlingsmodellene og de forskjellige tekniske realiseringene), mens tilgang til informasjonen skjer via Registry, som er en indeks over hvilke samhandlingsmodeller og tekniske realiseringer som er tilgjengelig. Registry inneholder også informasjon om hvem som benytter de ulike løsningene. Begge disse funksjonene dvs. 1) ta vare på og 2) gi tilgang til informasjon vil utføres av tredjeparter. Ansvaret for vedlikehold og oppdatering av informasjonen vil imidlertid ligge hos bedriftene selv. Mens det antakelig vil etableres mange Repositoryer for eksempel i tilknytning til bransjer vil det kun finnes en eller et fåtall aktører (tredjeparter) som ivaretar Registry-funksjonen. Den siste vil ivaretas av portalløsninger som gjør oppslag i eller leder brukerne dit hvor informasjonen finnes. Dette dokumentet beskriver hovedelementene i en Registry/Repository-løsning, herunder hvordan innholdet i Repository må struktureres i form av e-handelsobjekter for å kunne aksesseres via et Registry ved hjelp av nærmere definerte tilgangspunkter. Hovedfunksjonalitet i en Registry/Repository-løsning vil være å 11

12 gjøre søk i indeksen (Registry) for å finne informasjon om hvilken løsning en aktør, bruker eller tjenesteyter, benytter gjøre søk i biblioteket (Repository) for å få detaljene om en gitt løsning gi grunnlag for brukere og tjenesteytere å konvertere mellom ulike tekniske løsninger (jf. samtrafikk / interoperabilitet) I tråd med tankegangen i prosjektet er det lagt vekt på å beskrive funksjonalitet i form av bruksscenarier for to hovedkategorier av brukere - mennesker ( folk ) og maskiner ( applikasjoner ). Dette er i tråd med utviklingen innen moderne e-handel, som går mer og mer i retning av å skape en mest mulig sømløs overgang mellom menneskebasert og maskinbasert forståelse av samhandlinger, dvs. beskrive data og prosesser på en slik måte at både mennesker og maskiner intuitivt kan forstå dem. En slik tilnærming vil kunne bidra til å løse det klassiske problemet i all systemutvikling nemlig å bygge bro mellom brukere og teknologer. Åpen tilgang til et sett av samvirkende Registry og Repositoryer blir av stadig flere, også internasjonalt, sett på som selve hjertet i en åpen infrastruktur for elektronisk handel. 1.3 Målgruppe for dette dokumentet Dette dokumentet retter seg i første rekke mot IT-/systemarkitekter; dvs. de som sitter i grensesnittet mellom IT- og forretningsutvikling og Systemutviklere 1.4 Organisering av dokumentet Dette dokumentet er organisert i to hoveddeler: Del 1 beskriver funksjonelle krav til en Registry/Repository-løsning. Denne delen tar opp to hovedtemaer: Scenarier for bruk av en RR-base: Vi deler bruksscenariene inn i to hovedkategorier, dels der mennesker går inn og anvender innholdet i basen, dels der applikasjoner aksesserer RR-basen og bruker innholdet i konfigurasjon av interne systemer Innholdet i et Registry/Repository (en RR-base): Vi fokuserer spesielt på innhold som beskrives i henhold til vår beskrivelsesteknikk-rekommendasjon, dvs. plattformuavhengige modeller, deres realiseringer og mappingen mellom realisering og modell. Vi stiller krav til hvordan disse innholdskomponentene skal kunne nås av brukere av RR-basen og tar også opp hvordan de kan struktureres for lagring. Innholdskapittelet tar også opp temaer som klassifisering av innhold, versjonshåndtering, ulike typer RRbaser og forskjellene mellom et Registry og et Repository. Del 2 beskriver kort ulike teknologiske realiseringer av Registry/Repository-løsninger. Det finnes p.t. to internasjonale standarder for slike realiseringer: ebxml og UDDI. Vi gir en overordnet beskrivelse av disse løsningene og ser litt på hvorvidt og hvordan de kan være realiseringer som kan imøtekomme de krav til RR-baser som framkommer i del 1 av dokumentet. Vi understreker at vår hovedfokus ligger på del 1 av dokumentet vårt: innhold i og bruk av RR-baser uten tanke på konkrete løsningsteknologier. Følgelig er behandlingen av de teknologiske løsningene i del 2 på et overordnet plan for dem som ønsker grundige 12

13 presentasjoner av ebxml- og UDDI-teknologiene viser vi til de respektive spesifikasjonene samt til foreliggende litteratur. Vi gjør videre oppmerksom på at spørsmål relatert til sikkerhet ved aksess til Registry og Repository så vel som sikkerhet relatert til de ehandelsløsninger som er beskrevet i RRbasene, ikke er behandlet i dokumentet. 13

14 I. Funksjonelle krav til en Registry/Repository-løsning 14

15 2 Scenarier for bruk av Registry/Repository 2.1 Innledning Et typisk scenario for bruk av RR-basene vil være at virksomheter publiserer informasjon om sine samhandlingsprosesser og e-handelsløsninger. Andre virksomheter kan da gjøre søk mot denne informasjonen for å finne ut om virksomheten kan delta i en elektronisk samhandling og på hvilken måte dette kan gjøres. I en første fase vil det typisk være forretnings- og systemutviklere som henter ut informasjon fra RR-basene for så å benytte dette som grunnlag for tilpasning og integrasjon. Man kan også tenke seg scenarier der applikasjonene selv initierer søk i RR-basene og utnytter den informasjonen som finnes. Infrastruktur for elektronisk handel Scenario Profil 1 Finn samhandlingsmodeller ebxml Registry 3 Publiser egen bruk 2 Utvikle lokalt system 4 Finn partner profil Last ned scenario og profil 5 Inngå samhandlingsavtale Utveksle forretningstransaksjoner 6 ebxml tilpasset system Figur 2-1: Overordnet bruksscenario. RR-basene vil også bli benyttet av brukergrupper/organisasjoner (globalt som nasjonalt) for å publisere harmoniserte samhandlingsmodeller for ulike forretningsområder, inklusive en definisjon av den funksjonaliteten og innholdet av de meldingstyper eller parametre som spesifiseres for en samhandling. I et slikt scenario vil stegene i prosessen kunne være som illustrert i figur 2-1. Figur 2-1 illustrerer to virksomheter som aktivt utnytter RR-basene i det de skal etablere en samhandling. Følgende steg er illustrert: 15

16 1. Finn relevante samhandlingsmodeller Selskap A søker i RR-basene for å finne ut hvilke harmoniserte samhandlingsmodeller (inklusive meldingsstrukturer og forretningsprosesser etc.) som er tilgjengelige og kan egne seg for deres virksomhet. Den (eller de) aktuelle samhandlingsmodellen(e) lastes ned. 2. Tilpasninger i eget system Basert på den (de) samhandlingsmodellen(e) etableres/tilpasses de lokale systemene hos selskap A. 3. Publiser egen bruk Det faktum at selskap A nå kan gjøre ehandel i henhold til den aktuelle samhandlingsmodellen publiseres i RR-basene. Dette kan for eksempel gjøres ved å publisere en fullstendig samhandlingsprofil som beskriver hva de lokale systemene hos selskap A tilbyr, og på hvilken måte dette gjøres, eller ved å publisere informasjon om den konkrete realiseringen man har lagt til grunn. 4. Finn samhandlingspartnere Et annet selskap, selskap B, aksesserer RR-basene for å lete etter mulige samarbeidspartnere. Etter å ha identifisert en eller flere interessante partnere, laster selskap B ned informasjon om de samhandlingsmodellene og realiseringene som kan benyttes for å gjøre ehandel med de aktuelle partnerne. 5. Inngå samhandlingsavtale Selskap A og B inngår en avtale om å gjøre ehandel (en samhandlingsavtale) i henhold til en gitt samhandlingsmodell/realisering og tilpasser/konfigurerer sine systemer gjensidig for å kunne utføre forretningstransaksjoner i henhold til denne samhandlingsmodellen. 6. Utveksling av forretningstransaksjoner Selskap A og B gjennomfører forretningstransaksjoner basert på den inngåtte avtalen. 2.2 Bruksscenarier For Folk og For Applikasjoner Vi har identifisert to hovedkategorier av bruk av en RR-base disse er relatert til to typer brukere : folk respektive applikasjoner. Innenfor hver av kategoriene kan vi beskrive flere bruksscenarier. Vi kan derfor kalle brukskategoriene for henholdsvis bruksscenarier for folk og bruksscenarier for applikasjoner. Bruksscenarier for folk omfatter de bruksmåter der mennesker forretningsutviklere, softwareutviklere, osv. anvender en RR-base, gjerne gjennom et vanlig web-grensesnitt, for å legge inn, søke fram eller hente ut informasjon om ehandelsløsninger. Informasjonen skal for disse scenariene foreligge på en slik form at de skal kunne behandles av mennesker: som grafiske presentasjoner, identifiserte filer, e.l. Slike bruksscenarier er behandlet i kapittel 2.3 nedenfor. Bruksscenarier for applikasjoner omfatter de bruksmåter der applikasjoner sluttbrukerapplikasjoner, grensesnittsoftware (BSIer) eller annen programvare aksesserer en RR-base via et veldefinert sett av RR-tjenester som er tilgjengelige gjennom applikasjonsgrensesnitt. Applikasjonen foretar automatisk lagring, søking og uthenting av informasjon basert på konfigurerte parametre eller annen input. En vanlig anvendelse av innhentet informasjon vil være konfigurering og semantisk mapping av ehandelsløsninger i interne systemer. 16

17 Applikasjonsscenariene er behandlet i kapittel Bruksscenarier For Folk Informasjonsinnholdet i RR-basene kan benyttes av forretnings- og systemutviklere i en rekke ulike situasjoner. Et eksempel kan være en situasjon hvor virksomheten skal inngå rammeavler om leveranse av råvarer. En typisk saksgang vil da kunne være som følger: Innkjøper søker på internett og i andre kilder eller aktuelle leverandører av det produktet virksomheten har behov for. Denne type produktorientert informasjon vil ikke være tilgjengelig i de RR-basene som Infrastrukturprosjektet behandler og må følgelig finnes via andre kilder. Innkjøper innstiller på bestemte leverandører ut i fra de innkjøpsfalglige kriteriene som er definert. Dette kan for eksempel være pris, kvalitet, leveringsevne, etc. Igjen er dette informasjon vil ikke være tilgjengelig i de RR-basene som Infrastrukturprosjektet behandler og må følgelig finnes via andre kilder. Forretnings-/systemutviklere finner frem til de samhandlingsmodellene som eventuelt støttes av de aktuelle leverandørene. Her kan enkle søk i RR-basene gi svar på om de aktuelle leverandørene har implementert ehandelsløsninger og i tilfelle hvilke samhandlingsmodeller disse støtter. Forretnings-/systemutviklere analyserer de aktuelle samhandlingsmodellene for å se hvem som passer best i forhold til egne løsninger. Et av de sentrale spørsmålene i denne analysen er om den samhandlingsmodellen som en aktuell leverandør støtter faktisk passer med de krav virksomheten setter. Dette kan for eksempel være bruk av ordrebekreftelser eller prosesser knyttet til delleveranser og resting. Dersom det er fullt samsvar mellom de samhandlingsmodeller som benyttes av både kjøper og selger vil det være enkelt å etablere en elektronisk samhandling. Tilsvarende vil kostnadene ved å etabler elektronisk samhandling fort kunne bli store dersom det er store avvik mellom de samhandlingsmodellene som støttes av de to partene. På grunnlag av beslutning om bruk av en gitt samhandlingsmodell vil forretnings- /systemutviklere gjøre søk i RR-basene for å finn frem til tilgjengelige realiseringer. Dette er i første rekke relevant dersom virksomheten ikke allerede har en ehandelsløsning eller der hvor der er nødvendig med en ny realisering for å kunne gjøre effektiv elektronisk samhandling med den aktuelle leverandøren. Forretnings-/systemutviklere analyserer de aktuelle realiseringene. Det sentrale spørsmålet i denne analysen er hvilke av de aktuelle realiseringene som passer best i forhold til egne applikasjoner og andre rent IT-tekniske forhold. Implementere ehandelsløsning På grunnlag av den valgte samhandlingsmodelen og den valgte realiseringen spesifiseres og implementeres de nødvendige endringer/tilpasninger i egne applikasjoner. Ovenstående gir et eksempel på hvordan bruk av RR-basene kan inngå i en større forretningsmessig beslutningsprosess. I de påfølgende avsnittene er det skissert en del problemstillinger hvor RR-basene kan bidra med hele eller deler av svarene. 17

18 2.3.1 Hvem bruker hvilke løsninger? Denne problemstillingen kan være interessant i tilknytning til en markeds-/konkurrentanalyse. Hvem benytter samme samhandlingsmodell/realisering som oss? Et søk i RR-basen etter brukere som benytter en identifisert samhandlingsmodell/realisering vil kunne gi svar på dette. Hvilke av våre konkurrenter bruker samme samhandlingsmodell/realisering som oss? Et søk i RR-basen etter brukere som har samme rolle som oss selv i den samhandlingsmodell/realisering vi selv benytter vil kunne gi svar på dette Hvem kan jeg handle med? I en situasjon hvor en virksomhet allerede har implementert en ehandlesløsning basert på en gitt samhandlingsmodell kan det være interessant å finne frem til hvem andre som baserer seg på den samme samhandlingsmodellen. Dette kan for eksempel være for å kunne svare på: Hvilke av våre kunder/leverandører kan vi enkelt implementere ehandel med? I en situasjon hvor både kunde og leverandør benytter samme samhandlingsmodell, og kanskje endog samme realisering, vil det være relativt enkelt for partene å komme i gang med ehandel seg imellom. Et søk i RR-basen etter brukere som har en identifisert rolle i den samhandlingsmodell/realisering vi selv benytter vil kunne gi svar på dette. Hvilke virksomheter har en komplementær rolle i forhold til min egen i den samhandlingsmodellen jeg benytter? Dette kan for eksempel være for å finne frem til partner som jeg kan samarbeide med for å gi et verdiøkende tilbud til mine egne kunder. Et søk i RR-basen etter brukere som har en identifisert rolle i den samhandlingsmodell/realisering vi selv benytter vil kunne gi svar på dette Hva må jeg gjøre for å kunne handle med...? I en situasjon hvor en virksomhet har behov for å gjøre samhandling med en gitt partner kan informasjonen i RR-basene bidra til å gi svar på: Hvilken samhandlingsmodell/realisering den aktuelle partnere benytter. Et søk i RR-basen etter en gitt bruker vil kunne gi svar på hvilke samhandlingsmodeller den aktuelle brukeren benytter. En analyse av den aktuelle samhandlingsmodellen vil så kunne gi svar på hva som eventuelt må gjøres av tilpasninger og endringer i egen løsning. Finnes det en løsning som kan brukes mot både X og Y? Søk i RR-basen på de to brukerne vi kunne gi svar på hvilke samhandlingsmodeller disse benytter. En analyse av den eller de aktuelle samhandlingsmodellen(e) vil så kunne gi svar på om en og samme samhandlingsmodell kan benyttes mot begge, eller eventuelt hva som eventuelt må gjøres av tilpasninger og endringer. 18

19 2.3.4 Nødvendige funksjoner For å kunne gi svar på den type spørsmål som er skissert i det foregående må det finnes et brukergrensesnitt mot RR-basene som har funksjoner for å: Legge informasjon inn i både Registry og Repository Finne en tjeneste gjennom Registry Finne og laste ned beskrivelsen av en tjeneste fra Repository Et overordnet use-casediagram som illustrerer disse funksjonene og de rollene som er involvert er vist i figur 2-2. Innlegging i Registry Informasjonseier (Submitter) Innlegging i Repository Operatør Finn tjeneste gjennom Registry Bruker Finn og last ned Repository innhold Figur 2-2: Overordnet use-casediagram for bruk av Registry og Repository. De følgende avsnittene tar for seg hver av disse funksjonene og belyser disse i mer detalj. Det skal bemerkes at denne presentasjonen ikke er ment å legge føringer på hvordan en tilbyder av Registry/Repository-tjenester skal realisere sitt brukergrensesnitt. Konkret hvordan et slikt brukergrensesnittet kan se ut, det vil si layout, er det ikke tatt stilling til i dette dokumentet. Det stilles heller ikke krav til at de funksjonene som drøftes skal realiseres som selvstendige brukerdialoger. For eksempel kan innlegging av en samhandlingsmodell i Registry/Repository med fordel realiseres som en brukerdialog for å sikre konsistens. De rollene som er delaktige i disse funksjonen er: Informasjonseier (submitter) Den organisatorisk enhet som legger informasjon inn i et Registry med peker til en mer omfattende beskrivelse i Repository. Registreringen kan enten referere til en standardprosess/standardformat, der informasjonseier typisk vil være et standardiseringsorgan, eller en konkret samhandlingsprosess som tilbys. Informasjonseier kan i det siste tilfelle enten være selve forretningspartneren (den som tilbyr tjenesten), eller noen som handler på vegne av denne tilbyderen. 19

20 Informasjonseier er den som er ansvarlig for kvaliteten på innholdet i Registry samt det som blir refereres til fra Registry. Med kvalitet menes her ikke bare at beskrivelsene er korrekt i forhold til beskrivelsesteknikken, men også at de prosessene som beskrives faktisk tilbys, og at beskrevet funksjonalitet er tilstede. Operatør Den organisatorisk enhet som drifter og administrerer Registry (tilbyder av Registry tjenester). Bruker En som har behov for å finne en tjenestebeskrivelse gjennom Registry. Dette kan være søk etter en standardbeskrivelse som grunnlag for å implementere en tjeneste og som deretter kan gjøres tilgjengelig gjennom Registry og Repository. Alternativt er det søk etter beskrivelse av en forretningsfunksjon som tilbys av en mulig forretningspartner. Bruker kan være en person eller en dataapplikasjon. 20

21 Innlegging i Registry De funksjoner som er nødvendig for å kunne legge inn og vedlikeholde ehandlesobjekter og tilhørende klassifiseringer i et Registry er illustrert i figur 2-3. Registry 0.1 Logg inn på registry Informasjonseier (submitter) 1.1 Legg inn registry-beskrivelse av tjeneste 1.2 Oppdater registry-beskrivelse av tjeneste 1.3 Fjern registry-beskrivelse av tjeneste Operatør Figur 2-3: Innlegging i Registry. Logg inn i systemet (Use Case 0.1. ) Informasjonseier og operatør som skal legge inn/endre de tjenester som tilbys gjennom Registry, skal først tvinges til å identifisere seg. Legg inn Registry-beskrivelse av tjeneste (UC 1.1.) En innlegger av en tjeneste kan legge inn dokumentasjon av tjenesten, inkludert peker til den detaljerte beskrivelsen av denne i Repository. Systemet skal validere at beskrivelsen i Registry er i henhold til formatet for denne (det vil si at det er beskrevet i henhold til de konvensjoner som gjelder). Det bør også være mulig å registrere ufullstendig definerte tjenester, og disse skal da markeres som ufullstendige. Det bør videre kunne indikeres når tjenesten skal spesifiseres komplett. Et eksempel på en ufullstendig tjenestebeskrivelse kan være en prosess der man har definert at det skal være fire meldingsutvekslinger, men bare tre av dem er ferdig definert. 21

22 Det skal tilbys to varianter av denne funksjonen: En som kan benyttes ide tilfeller tjenesten allerede er lagt inn i et Repository, og man kun ønsker å oppdatere Registry til å referere til denne og eventuelt klassifisere denne. En som kan benyttes der hvor man ønsker å beskrive en ny tjeneste og legge denne inn i Repository (se UC 1.5), samt at Registry oppdateres til å peke til denne. Grensesnittet for innlegging bør her utformes slik at dette oppfattes som en integrert prosess. Oppdater Registry-beskrivelse av tjeneste (UC 1.2.) Det skal være mulig å oppdatere en Registry beskrivelse for informasjonseieren av tjenestebeskrivelsen. Fjern Registry-beskrivelse av tjeneste (UC 1.3. ) Det skal være mulig å slette en eksisterende tjenestebeskrivelse av dem som har lagt den inn. Også operatøren bør ha mulighet til å fjerne en tjenestebeskrivelse i Registry (for eksempel hvis informasjonseier ikke lenger eksisterer). Hvis operatøren fjerner en tjeneste, skal informasjonseier bli informert. 22

23 Innlegging i Repository De funksjoner som er nødvendig for å kunne legge inn og vedlikeholde ehandlesobjekter i et Repository er illustrert i figur 2-4. Repository 0.2 Logg inn på repository Informasjonseier 1.5 Legg inn repository-beskrivelse av tjeneste 1.6 Oppdater repository-beskrivelse av tjeneste Operatør 1.7 Fjern repository-beskrivelse av tjeneste Figur 2-4: Innlegging i Repository. Logg inn i systemet (UC 0.2.) Informasjonseier og operatør som skal legge inn eller endre de tjenester som er representert i Repository, skal først tvinges til å identifisere seg. Legg inn Repository-beskrivelse av tjeneste (UC 1.5.) En informasjonseier kan legge inn dokumentasjon på tjenesten i Repository. Det bør være mulig å ha en sømløs integrasjon mellom funksjonaliteten for å legge inn en tjenestebeskrivelse i Repository, og å legge inn peker til denne fra Registry. Systemet bør validere at beskrivelsen i Repository er i henhold til formatet for denne (det vil si at det er beskrevet i henhold til de konvensjoner som gjelder). Det bør også være mulig å registrere ufullstendig definerte tjenester, og disse skal da markeres som ufullstendige. Det bør videre kunne indikeres når tjenesten skal 23

24 spesifiseres komplett. Det kan tilbys mulighet for å definere at bare deler av Repository innholdet er fritt tilgjengelig for alle, mens andre deler er skjult dersom en avtale om samhandling først må tre i kraft. Oppdater Repository beskrivelse av tjeneste (UC 1.6.) Det skal være mulig å oppdatere en Repository beskrivelse for informasjonseier av tjenesten Fjern Repository beskrivelse av tjeneste (UC 1.7.) Det skal være mulig å slette en eksisterende tjenestebeskrivelse fra Repository av dem som har lagt den inn. Operatøren bør ha mulighet til å fjerne en tjenestebeskrivelse i Repository (for eksempel hvis et firma som har definert tjenesten, ikke lenger eksisterer). Hvis operatøren fjerner en tjeneste, skal informasjonseier bli informert. Når en tjeneste fjernes fra Repository skal også registreringen i Registry som peker til denne fjernes Finn tjeneste gjennom Registry De funksjoner som er nødvendig for å gjøre bruk av informasjonen i et Registry er illustrert i figur 2-5. Bruk av Registry for å hente ut informasjon skal ikke kreve brukeridentifikasjon. Registry 2.1 Let etter tjeneste Bruker 2.2 Søk etter tjeneste Figur 2-5: Finn tjeneste gjennom Registry. Let etter tjeneste (UC 2.1.) Det skal tilbys et navigeringsgrensesnitt som muliggjør å lete seg frem til (browse) en type tjeneste i Registry på grunnlag av definerte tilgangspunkter, eventuelt type ehandelsobjekt og klassifisering. Søk etter tjeneste (UC 2.2.) Det bør eksistere søkemotor-funksjonalitet som gjør det mulig å søke etter tjenester i Registry etter gitte kriterier, det vil si type ehandelsobjekt og klassifisering. Søkemotoren skal kunne aksesseres via et menneske-maskin grensesnitt Finn og last ned Repository innhold De funksjoner som er nødvendig for å gjøre bruk av informasjonen i et Repository er illustrert i figur 2-6. Bruk av Repository for å hente ut informasjon skal ikke kreve brukeridentifikasjon. 24

25 Repository 2.5 Slå opp i kjent tjeneste Bruker 2.6 Last ned tjenestebeskrivelse Figur 2-6: Finn tjeneste i Repository. Slå opp i kjent tjeneste (UC 2.5.) Alle tjenestene skal ha en entydig identifikasjon, slik at man enkelt kan finne en tjeneste eller beskrivelse man allerede kjenner til direkte i Repository. Last ned tjenestebeskrivelse (UC 2.6.) Det skal være mulig å laste ned den komplette beskrivelsen av tjenesten fra et Repository, det vil se alle de ehandelsobjektene som er relatert til et tilgangspunkt. Der en komplett beskrivelse ikke er lagt inn enda, skal bruker få melding om dette. En bruker kan laste ned ubegrenset antall tjenestebeskrivelser. 2.4 Bruksscenarier For Applikasjoner Innledning Bruksscenarier for applikasjoner omfatter bruk av RR-baser der applikasjoner sluttbrukerapplikasjoner, grensesnittsoftware (BSIer) eller annen programvare aksesserer en RR-base via et veldefinert sett av RR-tjenester som er tilgjengelige gjennom applikasjonsgrensesnitt. Med applikasjoners bruk av RR-baser mener vi primært de scenarier der applikasjonen automatisk eller delvis automatisk aksesserer RR-basen og finner (eventuelt lagrer) informasjon (hvis ikke, gir vår kategorisering ingen mening: også for folk -scenariene anvender applikasjoner for å nå RR-basen, i det minste en web-browser). Vi legger for disse scenariene videre til grunn at informasjonen brukes til å konfigurere ehandelsløsninger for en eller flere interne forretningsapplikasjoner. Denne konfigureringen der syntaktisk og semantisk mapping er viktige funksjoner kan også helt eller delvis være automatisert. Vi kan skjelne mellom to typer applikasjonsbruk av RR-basen: Konfigurasjonsbasert bruk: Applikasjonen aksesserer RR-basen for å foreta en derpå følgende konfigurasjon av internt system (alternativt for å lagre informasjon om ehandelsløsning slik denne er implementert og konfigurert i forhold til internt system). Applikasjonen vil aksessere RR-basen hver gang den har kunnskap om at slik aksess er nødvendig (basert på eksterne triggere eller konfigurerte parametre) hver aksess vil kunne medføre en (automatisk) rekonfigurasjon i forhold til internsystemet. 25

26 Transaksjonsorientert bruk: Applikasjonen aksesserer RR-basen hver gang en ehandelstransaksjon skal utføres. Applikasjonen vil derfor kontinuerlig fange opp mulige endringer i beskrevne ehandelsløsninger. En slik bruk har mange perspektiver, bl.a. kan den åpne for dynamisk valg av ehandelspartnere. Slike scenarier er muligens mest aktuelle dersom RR-basen er forbundet med tredjepartsleverandør(er) som tar et utvidet ansvar for brukerens ehandelsløsninger. Det er imidlertid store utfordringer forbundet med transaksjonsorientert bruk av RR-basen, ikke minst i forhold til semantisk mapping mot interne systemer. Vi tror slike bruksscenarier ligger forholdsvis langt fram i tid og vil ikke berøre dem mer i det følgende. Bruksscenariene for applikasjoner vil i hovedsak dekke de samme områder som bruksscenarier for folk: lagring av informasjon, søking etter informasjon basert på visse søkekriterier, og innhenting av informasjon. Det er først og fremst graden av automatisk bruk av informasjonen i RR-basen primært i forhold til integrasjonen mot sluttbrukersystemer som skiller de to kategoriene av scenarier Grensesnittsoftware: Business Service Interface Sluttbrukerapplikasjoner vil trolig i fremtiden som i dag - være bygget på egne interne modeller (selv om det er lov å håpe på at programutviklere etter hvert vil anvende iallfall deler av de modeller som finnes tilgjengelige i RR-baser). Derfor vil vi trenge grensesnittapplikasjoner. Arkitekturmessig kan disse sammenlignes med dagens EDI-tolker. De vil imidlertid ha en litt annen funksjon: heller enn å foreta en konkret felt-til-feltoversettelse på meldingsformatnivå, vil de mappe meningsinnholdet i to modeller mot hverandre gjøre samhandlingsmodellens semantikk tilgjengelig slik at den interne applikasjonen forstår den. Vi kaller en slik grensesnittapplikasjon en Business Service Interface (navnet er hentet fra ebxml). Med applikasjoners bruk av RR-baser mener vi derfor først og fremst BSI-softwares bruk av Registry/Repository Grensesnittsoftwatens bruk av informasjon i RR-basen Figur 2.7 illustrerer bruksscenarier der Business Service Interface-software aksesserer RRbasen og bruker informasjonen til å konfigurere og mappe til/fra internapplikasjoner. 26