Per Myrseth + GEM ansatte Norsk Regnesentral

Presentasjon om: "Per Myrseth + GEM ansatte Norsk Regnesentral"— Utskrift av presentasjonen:

1 Per Myrseth + GEM ansatte Norsk Regnesentral
XML og ehandel Per Myrseth + GEM ansatte Norsk Regnesentral Slide 1

2 Hva er XML eXstensible Markup Language (meta)-markeringsspråk
tekstbasert format (Unicode, ISO-10646) recommendation fra W3C; produsentuavhengig XML 1.0 i februar 1998 SGML XML XHTML HTML meta-markeringsspråk markeringsspråk delmengde applikasjon av meta-markeringsspråket Slide 2

3 XML-relaterte standarder
XML eXtensible Markup Language DTD Document Type Definitions HTML Hypertext Markup Language Namespace A way to ensure that names used in XML DTDs are unique, so that names from different DTDs can be combined in a single document when need be. XSL Extensible Stylesheet Language XSLT Transformations (XSLT) RDF Resource Description Framework DOM Document Object Model MathML Mathematical Markup Language SMIL Synchronized Multimedia Integration Language SVG Scalable Vector Graphics XML Schema En utvidelse av DTD men i XML syntax Slide 3

4 Fra data til presentasjon (3 skjema arkitekut)
Modell transformasjon Layout + instruksj. WEB <Navn>Ole Olsen</navn> <Gate>Liveien 1</Gate> <Tlf> </Tlf> Modell transformasjon Layout + instruksj. Papir Modell transformasjon Layout + instruksj. Person Gate Tlf. Navn Modell transformasjon Layout + instruksj. WAP PDA Modell transformasjon Layout + instruksj. Slide 4

5 Prosessering Klient side prosessering Server side prosessering Slide 5

6 + Informasjonssystem ®©™ GEMSOFT Java og XML Java = XML =
Strukturerte data Java = Prosessering og presentasjon + ®©™ GEMSOFT Slide 6

7 XML/EDI og litt historie
2000 # Handelspartnere som kan nås XML/EDI XML 1995 Browser Internett ”åpnes” 1990 CPU- kostnad Objektorienterte databaser EDIFACT ISO standard 1985 X.400 Lagrings- kostnad Relasjons databaser 1980 Båndbredde- kostnad Ura Hierarkiske databaser Slide 7

8 Egenskaper ved handel som påvirker handelsløsninger
Komplekse ehandelsløsninger Lav Høy Vare verdi Kompleksitet av varer/tjenester Hyppighetsfrekvens på kjøp Antall forskjellige varer Aktivitetsnivå hos aktørene i handelsprosessen Varens holdbarhet Lang Kort Andre akser som kan nevnes er : Et land versus mange land (juridiske domener) Et språk versus flere språk Monopolbedrift? Konsesjonsbelagte varer Noen typer handelsløsninger er letter å lage enn andre. Dette fordi kommunikasjonsbehovet og kompleksiteten i løsningene som skal støtte handelen øker når en beveger seg fra venstre til høyre på aksene. Ved fysisk varelevering ligger selve overleveringen av varen utenfor den teknologiske løsningen, derfor er fysiskvare satt opp som enklere å håndtere enn digital. En digital vare må håndteres integrert med handelsløsningen. Prisdanneles og aktørens aktivitetsnivå henger gjerne sammen. Eksempler på produkter: STRØM (ekstrem ferskvare) BOK Bruktbil Frukt Prisdannelse Fastpris “Børs/auksjon” Overleveringsformat for varen, fysisk eller immateriell Slide 8

9 Endres alt like raskt? Hva er stabilt? Hva endres raskt? Hva er layout? Hva er struktur? Hva er forretningspraksisen Regning fra Sætre kjeks- fabrikk A/S, 9. oktober 1917 Kan en separere deler av kompleksiteten i et IT system og behandle informasjonselementene i en faktura som noe stabilt, mens teknologien som benytter informasjonen viderutvikles? En 80 år gammel regning benytter de samme informasjonselementene finnes som i dagens elektroniske regninger. Det burde være en tankevekker. For 80 år siden hadde vi i Norge en veletablert jus, utveksling av handelsdokumenter står sentralt i denne handelsjus. Like så innen revisjon. Dagens IOS må selvfølgelig ta hensyn til både jus og revisjonsregler. Slide 9

10 XML Ordre I praksis må meldingen være i overensstemmelse
<?xml version="1.0"?> <?xml-stylesheet href="cenorder.xsl" type="text/xsl"?> <!DOCTYPE Order SYSTEM "cenorder.dtd"> <Order> <MessageID> </MessageID> <Date> </Date> <RefersTo DocType="ContractNo" DocID="652744" Line="112"/> <Buyer><EAN> </EAN></Buyer> <Supplier><EAN> </EAN></Supplier> <Item> <ItemID CodeType="BuyersPartNo"> </ItemID> <Quantity>90</Quantity> <Deliver> </Deliver> </Item> </Order> Meldingen er hentet fra Martin Bryan. Konvolutt nivå evt. som egen tag. Meldingstype ID og kobling til DTD Avsenders blankett ID i message ID Begin End strukturer Datamodellen ligger i DTD’en Layoutstøtte i XSL I praksis må meldingen være i overensstemmelse med en DTD og helst en XSL spesifikasjon Slide 10

11 XML/EDI og relaterte begreper
Referansemodeller: Konsepter: Beskrivelsespråk: Programeringsspråk: Syntakser: Open-EDI OO-EDI Object Orientet-EDI XML/EDI XML familien av standarder ebXML electronic business XML UN/EDIFACT DTD Document Type Definitions XSL eXstensible Style Language UML Unified Modeling Language ECMAScript Java XML eXtensible Markup Language EDIFACT-syntaks (ISO 9735) XML Schema pr okt.13: Recent working drafts have significantly changed the syntax, and somewhat changed the semantics, of XLinks (as well as introduced new co-editors). XPointer has been largely unified with the XSL pattern language, and most of the features of both are now in a joint specification known as XPath Slide 11

12 Hvor passer XML inn? Lagring av data Prosessering av data
Utveksling av data Presentasjon av data Navigering i data Metadata Søking i data Strukturering av data Slide 12

13 Lagring av data Mye overhead, siden strukturinformasjon lagres sammen med nyttedata ugunstig ved feks. store volumer av sanntidstransaksjoner I utgangspunktet en hierarkisk struktur Konvertering f.eks. XML => relasjonsmodell Konverteringsproblematikk kan skjules for utvikler & bruker Hybrid databaser som Oracle 8i Fremhenting av deler av et dokument (DOM) Det er situasjonsavhengig om XML er et bedre lagringsformat enn alternativene Slide 13

14 Behandling/prosessering av data
Enkel å parce Kan enkelt sjekke XML dokumenters konsistens mot DTD og delvis mot semantikk Svak på datatyper og kontroller Type av prosessering vil avgjøre formatet på dataene XML til tider uegnet Slide 14

15 Presentasjon av data XML til stor hjelp ved bruk av brukergrensesnitt i f.eks nettlesere. Ingen umiddelbar gevinst ved applikasjon til applikasjon integrasjon. NB! En har ikke 100% garanti for at det en får presentert på skjermen er en nøyaktig presentasjon av de data avsender ønsket å presentere. Gjelder både ved bruk av XML familien og Java F.eks: ved avtaleinngåelse Slide 15

16 Navigering i data I applikasjoner : I brukergrensesnitt Parcing
Bruk av DOM I brukergrensesnitt Browser og linker Slide 16

17 Meta data Data om data Velegnet til gjenfinning og strukturering
Kataloger om meldinger, segmenter, tagger og deres bruksområde og betydning Konvensjoner for å beskrive semantikk Arkivering og lagring over tid The Resource Description Framework (RDF) integrates a variety of web-based metadata activities including sitemaps, content ratings, stream channel definitions, search engine data collection (web crawling), digital library collections, and distributed authoring, using XML as an interchange syntax. Metadata: Beskrivelse av egenskaper, strukturer, kontekst av tilhørende nyttedata Konvensjoner for å beskrive semantikk RDF, Resource Description Framework XSL, beskriver noe semantikk Arkivering og lagring over tid Bruk av metadata letter arkivering over tid og over generasjoner av IT systemer. Slide 17

18 Utveksling av data Data lar seg enkelt sekvensialisere
Data utveksles i klartekst over nettet Mye overhead i forhold til nyttedata Sender både nyttedata og struktur, pluss evt. DTD Får bare utvekslet et begrenset spekter av semantiske restriksjoner ved bruk av XML, DTD og XSL. Større semantisk kontroll får man ved bruk av plattformuavhengige språk som JAVA, sammen med XML (i IOS) Ved bruk av Java i browsere mister mottaker kontroll over de semantiske kontrollene XML og semantikk, Browser: Avsender styrer semantisk opphavs kontekst XML Java og semantikk, Browser: Avsender styrer semantisk opphavs kontekst Slide 18

19 Innføring i XML: agenda
bakgrunn og motivasjon hva er XML og markeringsspråk forholdet til HTML, SGML og XHTML dokumentinnhold i XML syntaks og semantikk vha. DTD presentasjon vha. XSL relatert teknologi: ”XML-familien” anvendelsesområder XML/EDI Slide 19

20 Markeringsspråk (1) brukes til å strukturere og merke innholdselementer i dokumenter kryptiske koder, metainformasjon i naturlig språk, ... #e289 #i4569 juni 1999 #i456 #i777Kjære Anne!#i777 #i896 Det var veldig hyggelig å treffe deg i helgen! Det er helt utrolig... # i896 #i190Hilsen Astrid#i190 <brev> <dato> 9 juni 1999</dato> <til>Kjære Anne!</til> <innhold> Det var veldig hyggelig å treffe deg i helgen! Det er helt utrolig... </innhold> <fra>Hilsen Astrid>/fra> </brev> Slide 20

21 Markeringsspråk (2) SGML Standard Generalized Markup Language ISO 8879
meta-markeringsspråk store dokumentsystemer HTML HyperText Markup Language brukes til å kode dokumentene (nettsidene) i World Wide Web er en SGML-applikasjon fra W3C <html> <head> <title>Min hjemmeside!</title> </head> <body> <h2>HI!</h2> <p>Du har nå kommet til hjemmesiden min!</p> </body> </html> blanding av koder og naturlig språk Slide 21

22 XML og HTML i XML har man XML er
XHTML SGML HTML i XML har man skille mellom logisk struktur/innhold og presentasjon fri definering av elementnavn (tagger) fri definering av elementstruktur XML er produsentuavhengig (W3C recommendation) forståelig for mennesker og maskiner Slide 22

23 XML og SGML ”SGML på Web”
XHTML SGML HTML ”SGML på Web” XML er forenklet: lettere parsing, ingen valgmuligheter (syntaks) XML bygger på mangeårig erfaring med SGML større aktivitet og interesse for XML etter noen få måneder enn etter år med SGML Slide 23

24 Innhold og struktur XML syntaks
<?xml version=“1.0”? encoding=“UTF-8”> <message> <greeting “type=informal”> Hello, World! </greeting> <empty-content/> <farewell> Goodbye, World! </farewell> </message> la oss se et eksempel på informasjon som er kodet i XML-syntaks og hvordan det er i forhold til html: dette er kun et eksempel, Hakeparenteser, slik som i html. Må angi versjon: foreløpig kun en versjon, encoding: Karakterkoding: UTF-8, UTF-16 (Unicode, ISO 10646), ISO (Latin-1) Elementer: tagger og elementinnholdet Må ha både åpnings og avsluttende tagg i XML: tagg som indikerer begynnelse og slutt Et element kan inneholde andre elementer: nøsting av elementer Taggnavnet er forståelig og sier noe om innholdet Til en tagg kan det knyttes en eller flere attributter: type/verdi-par Legg merke til at det kun er informasjon om dokumentets logiske struktur, ingen ting om presentasjon og layout. [Det finnes editorer hvor skrivingen i XML-syntaks forenkles og hvor det fortløpende sjekkes at syntaksen er korrekt.] XML-dokumenter som EDI meldinger: trenger tilleggsinformasjon for å kunne prosessere og tolke meldingene -> Slide 24

25 Dokument type definisjon (1)
definerer en dokumenttype, f.eks. ordre, faktura en DTD kan sees på som et språk eller en grammatikk syntaks som SGML DTD’er, men noe forenklet hvilke elementer skal et dokument inneholde hvordan kan disse elementene kombineres verdiområde og attributter Dette er den rene syntaksen: hva er tillatt og hva er det ikke. For å gjøre fornuftig bruk av XML kan man legge føringer på dokumentet, dvs. definere en dokumenttype. skrive en DTD: identifisere metainformasjonen og dens struktur dette gjøres vha. en slags språk/grammatikk I XML bruker man DTDer slik som i SGML, men det er ikke oblibatorisk, i EDI sammenheng er DTDen imidlertid uunnværlig og årsaken var nettopp å følge opp SGML-tradisjonen. SGML var tross alt en kjent og mye brukt teknologi, og mye av XMLs foreløpige suksess kommer av den nære koplingen til og opprinnelsen i SGML. Slide 25

26 Dokument type definisjon (2)
<!DOCTYPE greeting_message [ <!ELEMENT message (greeting, farewell)> <!ELEMENT greeting (#PCDATA)> <!ATTLIST greeting type (formal|informal)#IMPLIED> <!ELEMENT farewell (#PCDATA)> <!ATTLIST farewell type (formal|informal) #IMPLIED> ]> Si hva som er DTD og hva som er meldingen 1. hvilke elementyper kan forekomme i dokumentet 2. elementinnhold: elementnøsting/rekkefølge, datatyper 3. attributter, verdier og deres datatyper noe forenklet i forhold til DTDer i SGML her MÅ et message-element inneholde et greeting-el og et farewell-el i denne rekkefølgen kan også angi at man kan null eller flere elementer av en type inni et annet, eller om et element kan være der, men ikke nødvendigvis er der The DTD defines 1. the class of documents that share a common informatiuon model 2. permissible elements and attributes, their contents and the order in which they occur, the DTD is the document schema, that makes an instance self-describing empty element: <dette_er_tomt/> jfr. EDIFACT-meldinger: ”meldingstyper” Hittil: 1. XML som dokumentformat 2. dokumenttypedefinisjon, nå skal vi se på presentasjon av et dokument <?xml version=“1.0”? encoding=“UTF-8”> <message> <greeting type=informal>Hello, World!</greeting> <farewell>Goodbye, World!</farewell> </message> Slide 26

27 Presentasjon av dokumenter (1)
Viktig hensikt med XML: skille mellom logisk struktur/innhold og presentasjon Dette skillet tillater: gjenbruk av data én kilde, flere presentasjoner, f.eks. nettside, produktkatalog, brukermanual, teknisk manual én kilde, flere målenheter og brukergrupper endre layout: mange dokumenter, samme utseende brukertilpasning og fleksibilitet automatisk prosessering Slide 27

28 Presentasjon av dokumenter (2)
dette skillet oppnås ved å legge opplysninger om presentasjon i stylesheets slags ”mal” XSL (eXstensible Style Language) XSL W3C Working draft april 1999, recommendation ventes i løpet av sommeren et XSL stilark er deklarative regler i XML-syntaks regler for hvordan XML elementene skal se ut regler for hvilke elementer som skal være med Slide 28

29 Presentasjon av dokumenter (3)
utseende og innhold: Hello, World! Goodbye, World! Hello, World! Goodbye, World! Hello, World! Hvordan ser innholdet ut: layout Hvilken del av innholdet presenteres Slide 29

30 Hva brukes XML til definere markeringsspråk for ulike behov, bransjer og fagområder elektronisk og multi-publisering informasjonssøk vha. metainformasjon dokumentstyring dynamiske nettsider, f.eks. produktkataloger utvekslingsformat XML/EDI, ehandel ... Slide 30

31 Oppsummering standard format uavhengig av systemer og plattformer
langtidslagring automatisk prosessering av informasjon fleksibel presentasjon på tvers av kanaler og medier metainformasjon ikke nødvendig med dyr, proprietær programvare for prosessering Slide 31

32 Interorganisatorisk system I
Interne rutiner Interne rutiner Internt datasystem Trekker ut og laster inn data XML er velegnet, men konseptet kan også realiseres ved bruk av HTML Kjøper må akseptere selgers forretningsmodell Kjøper får ingen kvittering /bevis for transaksjonen som er godt nok for reivisor. Mekanismer for meldingsutveksling Browser Datanett Slide 32

33 Interorganisatorisk system II
Interne rutiner Interne rutiner Internt datasystem Internt datasystem Trekker ut og laster inn data Trekker ut og laster inn data Utveksling av forretningsdata og forretningsdokumenter Velegnet for høy sikekrhet og digitale signaturer Må på forhånd ha standardisert forretnignsscenariet Suntaks er kun en detalj og har ikke noen vesentlig betydning for om en lykkes i å komme til enighet med en felles forretningsmessig modell. Semantiske problemstillinger Behov for standardisering Samhandel Forretningsdokumenter ehandel Jus Roller, meldinger, og avtaler Mekanismer for meldingsutveksling Mekanismer for meldingsutveksling Datanett Slide 33

34 Åpen ad hoc ehandel, en mulig skisse
Tjenester og nettressurser Kjøper Scenario- katalog Semantisk repository Selger Nettverk Programvare / objekt bibliotek Rollekatalog Transportør Bruker mest tid på de vanskeligste problemene inne meldingsbaserte interorganisatoriske systemer dvs, enighet om forretningsmodeller og jus. Åpenhet i et interorganisatorisk system Et åpent interorganisatorisk system vil ha følgende kjennetegn: Nye virksomheter skal ha mulighet for å bli brukere, internasjonale teknologiske standarder skal benyttes, beskrivelse av de scenariene det interorganisatoriske systemet støtter er fritt tilgjengelig og beskrivelse av hvordan administrasjon av det totale interorganisatoriske systemet foregår er fritt tilgjengelig. Med administrasjon mener jeg koordinering av teknologiske eller forretningsmessige endringer og utvikling. Eksempler på slike endringer er endringer i lovverk, nye roller som ønskes tilgjengelig i et scenario, nye virksomheter tar det interorganisatoriske systemet i bruk og disse må muligens bekjentgjøres for andre aktører, eller administrasjon av oppgradering av teknologi og IT-standarder. Interorganisatorisk system er et automatisert system som brukes av to eller flere virksomheter [Hørlück95]. Til bruk i denne oppgaven vil jeg ytterligere presisere begrepet til at hensikten med systemet er å bruke det som et verktøy for å utføre et eller flere scenarier og et interorganisatorisk system benytter en form for EDI til utveksling av informasjon mellom de enkelte virksomhetenes datasystemer. Tiltrodd tredjepart Bank Slide 34

35 Standardisering av meldingsbasert ehandel
Alle tilpasser seg hverandres datastruktur Alle tilpasser seg en felles felles datastruktur Slide 35

36 Eksisterende datasystemer og infrastruktur
Integrasjon mot: Interne systemer Eksterne systemer Ny teknologi må spille sammen med eksisterende teknologi Return of investment Når mange aktører benytter en meldingsstandard er det nesten umulig å endre den This is because XML needs data analysis skills sooner or later, as Simon Phipps, XML evangelist at IBM, agreed after giving his Entropy Death keynote speech. Phipps describes entropy death as a situation where everything is so connected that any change is unmanageable. Consequently, he pleads for the limiting of codependencies between systems, and for independent standards. Slide 36

37 Balansegang Standardisering <=> Frihet og fleksibilitet
Nysatsning <=> Installert base Interne forhold <=> Eksterne forhold Standardisering: Mange overlappende standardiseringsinitiativer Slide 37

38 Interne formatkonverteringer
EDIFACT basert EDI XML basert EDI Dataflyt med konvertering Dataflyt uten konvertering Layoutinstruksjoner Slide 38

39 Fem byggesteiner for XML/EDI
Web Foundation XML Processing Logic Templates Implemen- tation Methods Agents Fusion Global Reference Dictionary Repository Business Methods EDI XML og Internett tjenester + EDIFACT kodeverk + Templates som består av DTD’er XSL + regler kodet i ? Agenter som kan interpretere templates og etabler kommunikasjon mot interne systemer Repositories hvor en kan slå opp i”EDIFACT++” koder DTD’er XSL’er architetual forms ++ Slide 39

40 Fem byggesteiner for XML/EDI
Erfaring og påstått 100% bakoverkompatibilitet XML Meldingssyntaks og Internett utvekslingsprotokoller Maler / Templates Programkode og layoutinstrukser koblet mot DTD’er Repository Kodelister og semantiske definisjoner av dataelementer DTD’er, templates og agentkode Agenter Utfører instruksjoner i malene og foretar integrasjon mot interne systemer ved bruk av bl.a. DTD’er ref ” These components all work together to create an XML framework for business use: The XML tags can actually replace existing EDI segments or data-element identifiers, which produces a somewhat bigger file than an EDI file (before compression), but in which all the labels of the data-elements (in other words the descriptions or explanations) can optionally be used as XML tag names. The XML DTD (Document Type Definition) that works with the XML carries the structural information and attribute information from the original EDI transaction model. The repository is a location where shared Internet directories are stored and where users can manually or automatically look up the meaning and definition of XML/EDI Tags. The repository is in fact the semantic foundation for the business transactions. The templates are essentially rules that determine how the XML files should be interpreted. It can define the layout of the file and is supplemented by DTDs that enable transaction operability. Templates can be stored in repositories for global reference. The agents can interpret the templates to perform whatever job needs to be done (such as accessing local data stores), but they can also interact with the transaction and help the user to create new templates for each specific task. Sikkerhetsmodell for agentene? Slide 40

41 Syntaks og bruksområder
XML/EDI EDIFACT HTML Synse slide. XML/EDI kan spise en stor del av det markedet som allerede har tatt i bruk EDIFACT/X12 løsninger. I ”lukkede” markeder/nett gjerne med høyt transaksjonsvolum vil det kunne eksistere EDIFACT i lang tid fremover. Brukere av EDIFACT løsninger trenger en gulerot for å bytte teknologi. Det de store bruker mot andre store går så det griner. Privat- konsumenter Business to business Slide 41

42 Teknologi og arkitekturer
WEB-basert HTTP(S) & WAP HTML, XML & WML Meldingsbasert SMTP, X.400, ftp EDIFACT, XML, X.12 Distribuerte objektsystemer Corba/RMI/COM/EJB IDL (Interface description language) Lagdelte arkitekturer Slide 42

43 Systemutvikling og ehandel
Interorganisatoriske systemer Korte livsløp Kontinuerlig systemutvikling Store krav til integrasjon hos mange aktører Brukermasse en hetrogen Mange teknologiske platformer Nasjonal handelsjus / Internasjonal handelsjus Slide 43

44 Charles Darwin "It is not the strongest of the species that survives, nor the most intelligent; it is the one that is most adaptable to change." Vi kaster oss lett på nye tekniske løsninger når problemene med eksisterende løsninger synes å være uoverkommelige. Installert masse Den store utfordringen ved åpen ehandel og samhandel ligger ikke i syntaks og meldingshånderingskonvensjoner, men i å modellere og standardisere forretningspraksis og jus, og etablere en avtalepraksis som nyttegjør disse standardene. For tiden standardiserer mange det samme bruksområdet. Dette gir inkompatible løsninger. XML er et interessant innslag, men bidrar ikke med noe som vesentlig endrer hovedproblemet innen ehandel, kompatible løsninger på et høyt semantisk og forretningsmessig nivå. Slide 44

45 WAP og ehandel Positive sider : Begrensende sider Mobil kommunikasjon
Relativt billig => massemarked Begrensende sider Brukergrensesnittet => begrenser massemarkedet? Skjermstørrelse og farger Inputmekanismer Funksjonalitet og tjenestetilbud Båndbredde Egenskapene og kapasitet i klienten (diskløs mm.) Skreddersydd serverside løsninger? Slide 45

46 Blårussfoilen : Grunnmuren til all ebusiness
Å forstå potensielle forretningsmuligheter Å gjøre strategiske vurderinger Å gjennomføre profesjonell konseptutvikling Å forstå mediets egenart Få på plass Strategien Forretningsidéen Organisasjonen Teknologien Måleinstrumentene Slide 46