"the E-business framework" "the E-business framework"
Inhaltsverzeichnis
1. Einführung in XML/EDI *
1.1. XML/EDI "Das EC–Framework" *
1.2. Über diesen Artikel *
1.3. Wie funktioniert XML/EDI? *
1.4. Was macht XML/EDI? *
1.5. Warum ein Framework? *
1.6. Was macht XML/EDI anders? *
1.7. Dokumentenzentrierte Umgebung ? *
1.8. Wird XML nur für Web basierte Dokumente benutzt? *
1.9. Worin liegt der Mehrwert von XML/EDI? *
1.10. Nutzung von XML-Strukturen für XML/EDI ? *
1.11. Dynamisch verknüfte Objekte? *
1.12. Wie werden Regeln auf Objekte angewendet? *
1.13. Software Agenten *
1.14. Wie sieht es aus mit Such- und Routingtransaktionen? *
1.15. Wie sieht es aus mit der Anzeige der Transaktion? *
1.16. Beispiel *
1.17. XML/EDI für bestehendes EDI *
1.18. XML/EDI für Leistungshungrige *
1.19. Was ist die bestehende Alternative? *
1.20. Zusammenfassung *
1.21. Copyright *
Der nachfolgende Beitrag basiert auf einer Abhandlung der Autoren Bruce Peat & David Webber zum Thema XML/EDI. Der Orginaltext in englischer Sprache wurde im Sommer 1997 am Websitz der XML/EDI group veröffentlicht und unterliegt dem Copyright © The XML/EDI Group, August 1997
XML/EDI ist eine der erfolgsversprechendsten Entwicklungen im Bereich des elektronischen Datenaustausches. Erstmals werden unterschiedlichste neue Technologien kombiniert ohne dabei auf die Kompatibilität zu bestehenden Systemen zu verzichten. Von Beginn an wurde auf Standards gesetzt und so werden nicht nur die bereits bekannten Normierungen aus der EDI-Sicht, sondern auch die neuen Standardisierungen durch die W3C.
Der Anspruch von XML/EDI als "Framework" (vgl. auch Endbericht WP2700, Abschnitt "Basistechnologien") bewertet zu werden, geht weit über die Konvertierung von Daten hinaus und entspricht damit in weit höheren Maß den Anforderungen an ein modernes System zum Datenaustausch in einer elektronischen Welt von morgen.
Von großer Bedeutung ist auch die Strategie die bei der Verbreitung von XML/EDI angewendet wird. Der Weg führt eindeutig über das "Web" (Internet/Intranet). Wenn man den Ankündigungen der XML/EDI group glauben darf, so wird Microsoft und Netscape in den jeweils nächsten Browserversion diese Technologie integrieren und damit wesentlich zur Verbreitung beitragen.
Das XML/EDI–Framework öffnet die Tür zu einem neuen Paradigma für die Verarbeitung von Dokumenten und den Austausch von Transaktionen. In diesem Beitrag wird beschrieben, wie XML/EDI "Smart"–Dokumente verwendet werden können, um einige sehr wichtige sowohl organisationsinterne als auch –externe Kommunikationsthemen anzusprechen.
Durch die Verwendung von Standards für den Zugriff auf Komponenten eines XML–Dokuments und das Hinzufügen von Stilinformation zu XML–Dokumenten, können XML–Dokumente und die in ihnen enthaltenen Objekte ausgetauscht, angesehen, gesucht, katalogisiert und weitergeleitet ("gepusht") werden. Das XML/EDI–Framework bietet alle grundlegenden Bausteine des Electronic Commerce (EC).
Auf den Punkt gebracht, hat XML/EDI das Potential, die Art und Weise zu verändern, wie Organisationen ihre "Geschäfts"information verwalten und übermitteln. Obwohl die Verwendung von XML im Internet gerade erst beginnt, könnte XML/EDI schon 1998 eine der dominierenden Kräfte im EC sein.
Dieser Artikel wurde für diejenigen geschrieben, die wissen wollen, wie XML (eXtensible Markup Language) und EDI (Electronic Data Interchange) einen Katalysator für die Erstellung von EC–Lösungen zur Verfügung stellt. Es wird ein wenig technisches Wissen über das Internet, EC und EDI vorausgesetzt. Querverweise zu diesen Themen können auf der Website der XML/EDI Group gefunden werden:
Der Artikel beschreibt die wichtigsten Konzepte von XML/EDI und wie man einfache, dauerhafte und effektive Geschäftstransaktionen mit elektronischen Mitteln übermitteln und verarbeiten kann.
Um diese Ziele zu erreichen, braucht man eine Methode, die nicht nur zukünftig Bestand haben wird, sondern auch anpaßbar ist, um neue Technologien und Anforderungen einbinden zu können. Um eine möglichst große Akzeptanz sicherzustellen, muß die ausgewählte Technologie als offener Standard überall frei verfügbar sein.
Durch die Auswahl eines Paradigmas, das aus sich heraus bereits dynamisch definiert, erweiterbar und einfach ist, wird diesen Zielen von vornherein Rechnung getragen.
XML/EDI beinhaltet viel mehr, als nur EDI in eine XML–Verpackung zu stecken.
Ein XML/EDI–Framework beinhaltet die Nutzung einer Reihe von komplementären und wirksamen Technologien. Dieser Artikel bietet eine Einführung in diese Konzepte von XML/EDI und was damit erreicht werden kann.
Wenn nach der Lektüre dieses Artikels noch Fragen offen sind, können sie an die Mailing list der XML/EDI Group geschickt werden ().
XML/EDI ist die Verschmelzung aus fünf Technologien (Abbildung 1). Es ist diese Kombination, die XML/EDI so wirksam macht. Die fünf Technologien sind:
Jede Komponente fügt einzigartige Tools hinzu, die auf die anderen Teile einwirken. In der Vergangenheit war EDI sehr statisch, heute ist das XML/EDI–Framework ein interessanter dynamischer Prozeß, der unbegrenzt erweitert werden kann. Hier wird nun ein Überblick über jede Technologie gegeben, während spätere Abschnitte einen tiefergehenden Blick auf die Technologien werfen.
Abbildung 1 : XML/EDI, die Verschmelzung von Technologien
XML selbst stellt die Grundmauern dar. Das Web wurde auf den Fähigkeiten der HTML–Sprache aufgebaut, die selbst eine sehr beschränktes Untermenge (subset) der ursprünglichen und hoch komplizierten SGML–Dokumentsyntax ist. Nun wurde XML erdacht, das sich zwischen den beiden befindet; es ist nicht so kompliziert wie SGML aber um einiges leistungsfähiger als HTML. XML–Tokens und –Frameworks bilden die Syntax, die die anderen Komponenten durch das Netzwerk transportiert.
XML–Tokens ersetzen oder ergänzen bestehende EDI–Segmentbezeichner.
XML bringt auch ganz allgemein alle wertvollen Fähigkeiten und Transportschichten des Webs und des Internet mit sich.
EDI ist der Urvater des electronic commerce (EC). Die Fähigkeit, Daten in einem simplen Format auszudrücken, und sie zu jemandem zu schicken, der die Information interpretieren kann, die er gerade erhalten hat. XML/EDI bietet zu 100% Rückwärtskompatibilität für existierende EDI–Transaktionen, während EDI in Richtung nächste Generation weiterentwickelt wird. Dies bedeutet, daß man die Investitionen in existierende EDI–Systeme und EDI–Wissen nicht aufgeben muß.
Templates. Diese Regeln stellen den "Klebstoff" dar, der den ganzen Prozeß zusammenhält. Ohne sie kann man im XML allein nicht alle Details der Arbeit ausdrücken, die ausgeführt werden müssen. Auf Templates werden referenziert oder sie werden innerhalb des XML als spezielle Section und als Set von Tokens transportiert. Sie können leicht gelesen und interpretiert werden. Sie sehen vom Layout und Inhalt her eher wie eine Kalkulationstabelle aus und werden von etwas ergänzt, das XML die Document Type Definitions (DTDs) nennt. DTDs ermöglichen Interoperabilität von Transaktionen, Regeln ermöglichen die Verarbeitung von Transaktionen (was die Präsentation beinhalten kann). Durch DTDs können zwei Organisationen die Daten der jeweils anderen verstehen. Regeln definieren, was mit diesen Daten passiert.
Agenten interpretieren die Templates, um die benötigte Arbeit zu verrichten und interagieren auch mit der Transaktion und dem Anwender, um neue Templates für jede neue spezielle Aufgabe zu erstellen, oder suchen und teilen den existierenden Aufträgen die richtigen Schablonen zu. Sie können auch DTDs referenzieren, um Displaycharakteristika für Formulare zu bestimmen. Hier passen Java und ActiveX hinein. Zur Zeit bieten sie das beste Medium, um Agenten zu erstellen und eine XML–Struktur, die diese Teile enthält, kann natürlich referenziert werden und sie kann überall hin transportiert werden, wo sie gerade gebraucht wird. Anfangs werden diese Agenten einfach von den Templates gesteuert werden, die zu erwartenden zusätzlichen Fähigkeiten folgen später.
Repository – Shared Internet Dictionaries (gemeinschaftlich nutzbare Dictionaries im Internet) werden schon von Hybriden der traditionellen EDI–Systeme, wie dem BSI, verwendet, das ein Wörterbuch verwendet, das es den Anwendern ermöglicht, händisch die Bedeutung und Definition von EDI–Elementen nachzuschlagen. Das Shared Internet Dictionaries–Konzept führt dies auf die nächste Ebene weiter und bietet automatisches Nachschlagen an, ähnlich wie es die fortschrittlicheren Internet–Suchmaschinen zur Zeit tun. Diese Komponente bietet die semantische Grundlage für Geschäftstransaktionen und den Unterbau, den die Software–Agenten brauchen, um korrekte Querverweise zu Entitäten herstellen zu können. (Dieses Konzept wird in diesem Artikel auch "Repositories" genannt und beinhaltet auch das Hinzufügen von DTDs zum Repository).
Die Kombination dieser Komponenten stellt ein System zur Verfügung, das Information liefert, nicht nur Daten, und die Verarbeitungslogik, die gebraucht wird.
XML/EDI bietet vier Kernmodelle zur Verwendung an. Diese beinhalten traditionelle EDI–Verbreitungsmethoden zusammen mit neuen dokumentenzentrierten Fähigkeiten. Abbildung 2 zeigt auf einen Blick die vier Kernmodelle. Weiter unten werden einige Beispiele für Interaktionen gebracht.
Abbildung 2: XML/EDI Transaktionsmodelle
Der nächste Abschnitt behandelt Frameworks, die diese Modelle möglich machen. Das gezeigte "Sternmodell" ist das klassische EDI–Modell, wo ein großer Geschäftspartner oder Organisation die Standards für seine Handelspartner setzt. Das "Ad hoc"–Modell ist das neue netzbasierte Modell. Kleinere Geschäftspartner richten ihre eigenen Ad hoc–Interaktionen ein, diese können sich mit der Zeit zu formaleren Methoden entwickeln oder auch nicht. Das "Hybridmodell" ist eine Kombination der ersten zwei. Hier wird ein "Sternmodell" durch Handelspartner erweitert, indem sie neue Framework–Versionen erstellen und ihre eigenen Ad hoc–Interaktionen einbinden. Das "Webmodell" ist ein dokumentenzentriertes Modell, bei dem Inhalte die wichtigsten Informationen sind, die ausgetauscht werden. Inhalte können entweder angestoßen durch voreingestellte Regeln ankommen oder angefordert oder (ggf. breit gestreut) versendet werden. Das klassische Beispiel dafür ist ein elektronischer Katalog und die damit verbundenen Dialoge der Preisanfrage ("Request for Quotations" – RFQ).
XML/EDI sorgt für die Infrastruktur einer großen Anzahl von EC–Systemen; von durchsuchbaren Online–Katalogen bis zu robusten Transaktionssubsystemen von Computer zu Computer. Die XML/EDI–Initiative zielt darauf ab, offene Lösungen für die Implementierung von EC–Systemen bereitzustellen. Das wichtige Wort hier ist "Lösungen". Es gibt nicht nur eine Lösung für alle EC–Szenarien. Jedes Szenario hat seine eigenen Anforderungen und Ziele. Deshalb braucht man ein Framework und keine Applikation oder Module.
Das Ziel des Frameworks ist es, formale Schnittstellen für kommerzielle EC–Komponenten, die interoperieren sollen, bereitzustellen. Damit XML/EDI erfolgreich ist, müssen diese Schnittstellen offen sein und dennoch standardisiert. Das Geschäftsmodell besteht entweder aus Ad hoc–Interaktionen zwischen kleinen Gruppen oder aus vereinbarten nationalen oder internationalen Frameworks, wie die von Wirtschaftsverbänden oder Industriegruppen.
Abbildung 3 zeigt die technischen Schichten, mit denen ein grundlegendes XML/EDI–System errichtet werden kann. Nicht alle Schichten sind notwendig, um Resultate mit XML/EDI zu erzielen. Das Framework ist auf den XML/EDI–Standards errichtet und vergrößert sie und definiert den Entwurf der EC–Komponenten–Interaktion. Kataloganbieter, zum Beispiel, wollen vielleicht nur das XML–Tagging implementieren. Die "Tags" sind in Standard–Repositories definiert. Die verschiedenen Schichten unterstützen verschieden ausgerichtete EC–Systeme. Allgemein bietet jede nachfolgende Schicht fortschreitend ausgeklügeltere Fähigkeiten, damit immer anspruchsvollere Bedürfnisse behandelt werden können.
Abbildung 3: XML/EDI Schichtmodell
Endanwender interagieren mit diesen technischen Schichten durch stark visuell orientierte Desktop–Tools. Entwickler verwenden EC–Komponenten, um diese Tools zu bauen. Anwender bedienen die Schnittstelle zu ihren Dokumenten, wie sie jedes beliebige Tool in ihrem Office-Anwendung verwenden würden – Textverarbeitung, Tabellenkalkulation, Datenbanken oder welche Metapher auch immer am besten zu der Applikation paßt.
Der Hauptunterschied zwischen XML/EDI und anderen Mechanismen besteht darin, daß ein System die Dokumenteninformation viel exakter und in reichhaltigerer Gliederung umschlüsseln kann, als mit früheren Formaten möglich war. Mit Hilfe von XML Tags und DTDs sind XML/EDI Transaktionen selbstbeschreibend; Anwendungen, die XML/EDI Dokumente bearbeiten, können eine Transaktion alleinig durch den Zugang zum Inhalt der Transaktion "verstehen".
Es gibt verschiedene Gründe, warum wir XML/EDI als Technologie der Zukunft sehen. Einige dieser Gründe sind unten aufgelistet -
XML/EDI...
Ein weiterer Aspekt von XML/EDI, der erwähnt werden sollte - erst wenige Male in der Geschichte des Computers hat sich die Aufmerksamkeit so auf gesammelte Technologien und die mögliche Lösung der heutigen Geschäftsprobleme durch sie konzentriert - freudige Erregung und ein Gefühl des Erreichbaren liegen in der Luft.
Dokumentenzentrierte Umgebung?
In den letzten dreißig Jahren hat sich die Welt verändert und verlangt jetzt nach einem dynamischen und kraftvollen Tool, das zu der organisierten aber doch einzelfallorientierten Natur paßt, die sowohl von der modernen Geschäftspraxis als auch von ihren Manifestationen im Internet selbst dargestellt wird. Das Internet schreibt die Regeln neu, wie Menschen aufeinander wirken, kaufen und verkaufen und Waren und Serviceleistungen austauschen.
Heute werden dokumentenbasierte Managementsysteme, zunehmen mit den relationalen Datenbank-Managementsystemen (RDBMS) integriert. Wenn man sich die verschiedenen Angebote von "universal servers" ansieht: Oracle, DB2, Informix und "Nachrichtenspeicher" (message stores) wie Notes und MS-Exchange, zeigen uns diese den Weg zu möglichen Typen von kommerziell orientierten Computersystemen. Diese Systeme kombinieren (bzw. werden kombinieren) feldorientiert geführte Daten mit vollständig textbasierten Subsystemen – Datenbanksysteme und dokumentenzentrierte Tools ergänzen einander und schaffen für den Endbenutzer neue Paradigmen für die Arbeit mit Dokumenten.
Diese Integration von datenzentrierten und dokumentenzentrierten Tools entsteht für einen größeren Kreis von Anwendern als den von XML/EDI. So heißt es beispielsweise, daß Microsoft überlegt, XML als zugrundeliegendes Dateiformat für MS-Exchange® zu verwenden, um den Zugriff auf den Nachrichtenspeicher zu beschleunigen. Dieser Schritt ist notwendig, wenn MS-Exchange® – in etwa 2 bis 3 Jahren – in der Lage sein soll, 5 Millionen Benutzer über NT-Cluster zu bedienen. Indem es auf diese Typen von XML-Mechanismen aufbaut, kann XML/EDI diese Tools, wie Workflow, Katalogisierung, Weiterleitung und Suchen in der Anwendung fördern und in ihrer Wirkung verstärken. Bezogen auf XML/EDI wird das oft betitelt mit "all dies ist gratis" oder "alles Teil der sich entwickelnden XML-Technologie".
Wenn die Annahme richtig ist, werden Anwendungen sich dahingehend entwickeln, die eingebauten Browser-Funktionen als ihre Front-ends zu benutzen. Die Entwickler werden keine einzelnen Bildschirmmasken programmieren, um Transaktionen zu visualisieren, d.h. eine Rechnung oder einen Krankenbericht, sondern statt dessen den integrierten Browser benutzen, der "wissen" wird, wie er sich an den Geschäftsfall anpaßt. Die dokumentenorientierten Tools werden in den Arbeitsplatz mehr und mehr eindringen, XML/EDI baut nur auf diese Tools auf und verstärkt ihre Wirkung.
XML/EDI Dokumente werden als Struktur, die Daten enthält, dienen und sie werden Anweisungen beinhalten, wie eine Transaktion verarbeitet oder (an der Benutzeroberfläche) dargestellt werden soll. Basierend auf anwender-definierten Regeln wird das Dokument in seinem eigenen Workflow-Prozess weitergeleitet, wobei es selbst Ereignisse auslöst. Im einfachen Fall wird das Dokument – durch Einsatz von Such-, Klassifizierungs- und Weiterleitungsmechanismen – in der Lage sein, die Applikation (oder den Anwender) zu finden, anstatt daß die Applikationen (oder die Anwender) das Dokument finden müssen. Das Dokument wird in sich den Transaktionsstatus enthalten, damit Applikationen (oder Anwender) diesen setzen oder abfragen können, und es wird selbst "wissen", daß es eines in einer miteinander verbundenen Menge von Dokumenten ist, die im Workflow benutzt werden.
Um das alles zu verdeutlichen, stelle man sich die Frage noch einmal :
Was wäre, wenn man die Tools hätten, um eine Geschäftstransaktion als ein Dokument zu bearbeiten?
Das ist das mächtige Konzept hinter den "Universalservern" von heute, das die Stärke der RDBMS mit dem Dokumentenmanagement verbindet. Mit einer Variation der heutigen Tools, d.h. SGML, EDI–mappers, kann man diese Technologie einsetzen, daß sie Dokumente speichert, sucht und handhabt. Man kann dokumentenorientierte Tools dazu benutzen, diejenigen Tools zu ergänzen, die den EDI–Administratoren heute zur Verfügung stehen (RDMBS).
Wird XML nur für Web basierte Dokumente benutzt?
Nein. XML findet im Internet und in einem weiten Feld von browserabhängigen Intranet-Anwendungen gerade erstmalig Akzeptanz.. Aber im Maße, in dem sich diese Anwendungen entwickeln, werden sie die Tools, die für den Gebrauch von XML/EDI notwendig sind, versorgen. XML/EDI ist nicht an den Browser, und somit an den Client-Teil einer Anwendung gebunden. XML/EDI liefert genauso auch echte, server-orientierte Batch-Verarbeitung. Und natürlich über jeden Transportweg – XML/EDI-Dokumente können per Floppy, LAN, WAN, Wählmodem, Internet usw. ausgetauscht werden.
Worin liegt der Mehrwert von XML/EDI?
Eines der XML/EDI-Ziele ist es, den Dokumententransport zwischen Organisationen so einfach wie möglich zu gestalten, und zwar soweit, daß er für den Anwender transparent ist. Das wird Workflows oder "Pipelines" gestatten, sich über Organisationsgrenzen zu erstrecken. Das schließt Software-Agenten als Untermenge ein, die ins Internet hinausgreifen sollen, um aus Online-Katalogen zu lesen und sie sinnvoll zu nutzen. Der Workflow von Dokumenten sollte in der Lage sein, einen Handelspartner ebenso leicht zu erreichen wie einen Kollegen im Nebenraum. Diese Transparenz ist mit XML/EDI erreichbar.
Studien haben gezeigt, daß nur wenige Unternehmen, die EDI implementiert haben, alle bei der Automatisierung des Datenaustauschprozesses entstehenden Vorteile ausnützen. Die meisten Firmen benutzen EDI nur als Transportmechanismus um fest strukturierte Daten von und zu Handelspartnern zu schicken. Einige Unternehmen erfassen sogar die per EDI erhaltenen Daten manuell in ihren anderen Systemen ! EDI wird üblicherweise den Unternehmen von ihren Partnern aufgedrängt, und EDI wird nur als Pflicht gesehen, um den Kundenstock bei Laune zu halten. Sehr wenige Unternehmen sind der Meinung, daß "EDI eine gute Sache ist und daß es dem Unternehmen Geld sparen wird, indem es die Prozeßkosten senkt", wenn sie mit EDI in Kontakt kommen. Normalerweise "passiert" EDI in einer Firma, weil ein Partner die Verwendung diktiert hat, deshalb ist es kein Wunder, daß EDI vor der Tür des Unternehmens bleibt.
Der Unterschied zwischen den obengenannten EDI-Versuchen der Vergangenheit und XML/EDI ist primär in Änderungen am Arbeitsplatz begründet. Diese Änderungen werden die Integration von Daten und Prozessen zwischen Unternehmen unterstützen. Es wird die Zeit kommen, in der Benutzer von XML-Dokumenten von ihren Systemen erwarten, daß sie einen Geschäftsfall einem Handelspartner genauso einfach transparent weitergeben, wie sie die Dokumente ausdrucken können. Kurz gesagt, mit XML/EDI bleibt die Transaktion nicht an den Toren des Unternehmens stehen, sondern erstreckt sich in ein anderes Unternehmen mit Unterstützung aller Facetten des Geschäftsfalls.
Nutzung von XML-Strukturen für XML/EDI ?
Eine EDI-Anwendung für XML stellt die strukturelle Komplexität zur Verfügung, die die heute in EDI üblichen Geschäftsfälle unterstützt und ihnen gleichwertig ist. XML stellt eine reiche Dokumentenstruktur zur Verfügung, die beliebig komplex verschachtelt sein kann. Mit XML verhalten sich Dokumente wie Chamäleons, fähig, von verschiedenen Komponenten, die von verschiedenen Mechanismen geliefert werden und sich dem Benutzer auf verschiedene Arten auf seiner Oberfläche darstellen, bearbeitet zu werden.
Mit der Verwendung des ausbaufähigen XML–Tag–Set können EDI "Objekte" entweder an in Repositories gespeicherte Objekte weitergegeben oder dynamisch von diesen referenziert werden. Die XML/EDI-Gruppe schlägt vor, XML als "Träger" für die Dokumenteninformation zu verwenden, sodaß die Transaktion nicht nur Daten (wie herkömmliches EDI), sondern auch Programmcode enthalten kann (auf jeder Ebene innerhalb des Transaktionsbaumes). Bei einem Element, das sowohl die Eigenschaft von Daten hat als auch den Code von Methoden enthält, können betriebswirtschaftliche Elemente als "Objekte" behandelt werden. (Anmerkung: es ist vorgesehen, Vererbung in eine spätere Version von XML zu integrieren).
In XML ist jedes Dokument ein Objekt und jedes Element eines Dokuments ist (auch) ein Objekt.
Der logische Aufbau des Dokuments und des Tag–Set können in einer Document Type Definition oder DTD spezifiziert werden (Das bekannteste Beispiel für ein DTD ist HTML, das durch ein DTD, das die Struktur von HTML-Dokumenten beschreibt, definiert ist.) In einem DTD werden Elementgruppen und ihre Attribute definiert; die Namen, die als Tags verwendet werden, werden zugewiesen; und die Beziehungen zwischen den Elementen oder die mit dem Element verbundene Transaktion wird definiert. Wenn ein DTD verwendet wird, können Programme die Struktur einer Transaktion validieren. Man kann die Struktur von XML/EDI-Dokumenten automatisch validieren. Wenn das auch kompliziert klingen mag, es ist es nicht. Es ist sogar überraschend einfach, mit XML seine eigene markup-Sprache (DTD) zu definieren.
Die meisten heutigen Workflow-Systeme, wie Lotus Notes®, können nicht einmal davon träumen, eine X12– oder EDIFACT-Transaktion adäquat in relationaler Form (geeignet "view") zu speichern. Heutzutage müssen diese Systeme die Datenbank "verflachen" oder die Sache auf eine andere Art erklären. Die typischen Workflow-Dokumente können nur eine einzige eindimensionale Ansicht einer Transaktion speichern. Die XML/EDI-Struktur wird Produkten wie Lotus Notes® die Möglichkeit geben, EDI-Transaktionen auf relational zu speichern und zu verarbeiten.
Wenn die Regeln einmal definiert sind, können sie auf die Objekte in der Transaktion angewendet werden. Darauf wird später noch eingegangen (Kapitel 1.12).
Eine wichtige Anmerkung: die Daten und der Code müssen nicht in der gleichen Transaktion enthalten sein ! Wie kann das sein?
Code und Daten können extern – mittels Verknüpfungen zu dynamischen Referenzen, d.h. URLs - referenziert werden. XML-Links können zwischen zwei oder mehreren Ressourcen bestehen; diese können entweder Dateien sein (nicht notwendigerweise XML oder HTML Files) oder Elemente in Dateien. Links können zwischen mehr als einer Ressource bestehen, sie können außerhalb der aktuellen Dokumente selbst und mit dem verbundenen Element innerhalb der Ressource spezifiert werden. Die Verknüpfung kann auf sehr wirksame Arten spezifiziert werden. Das Element kann mit einem Attribut identifiziert werden, einer Position in der Elementstruktur, oder man kann sogar bestimmen, daß der Link zu Dingen wie einer Versandadresse für den dritten Posten auf der Bestellung geht. Diese XML-Verknüpfung macht XML/EDI sehr flexibel.
Die "Standards" oder "Wörterbücher" (vgl. Fußnote ) werden in (einem oder mehreren) Repositories gespeichert, um dynamischeReferenzierung zu ermöglichen. Kein gewaltsames Zuordnen von Daten auf eigentlich unzulässige Codes oder kein Wildwuchs von ZZ-Codes mehr (das sind frei verwendbare Codes, die nicht mit einer festen Definition im Wörterbuch stehen) – man muß nur mehr den neuen Code und seine Bedeutung in das Repository ein! Das XML/EDI Framework beschreibt die Anrwendung von Repositories, Schnittstelle und Replikation. XML ist eine Sprache; die Repositories machen gemeinsame EC Definitionen zwischen Organisationen auf eine dynamische Art und Weise möglich. Damit stellen Repositories eine reichhaltigere Sprache zur Verfügung.
Wie werden Regeln auf Objekte angewendet?
Die Antwort liegt im Document Object Model (DOM), wie es von der W3C DOM Workinggroup definiert wurde. (Anmerkung: Microsoft hat kürzlich DOM oder Dynamic HTML im Internet Explorer 4.0 eingeführt). Das Document Object Model ermöglicht es, alle Elemente eines HTML Dokuments zu adressieren. Eigentlich ist jedes Element ein programmierbares Objekt. Mit Verwendung des Document Object Model sind XML/EDI-Dokumente in der Lage, den Inhalt, die Regeln die die Transaktion steuern, und die View in einer Datei /einer Transaktion zu kombinieren. XAPI-J bietet die Standards an, damit Java Komponenten die Objekte im DOM-Baum adressieren können und um im Baum zu navigieren. Diese Objekte sind unsere Geschäftsobjekte, wie sie im DTD definiert sind. Auf Anwenderebene werden die Regeln graphisch präsentiert, ähnlich wie wenn man die Hilfdialoge für ein E-Mail Programm erstellt, wo man Messages vom einem Dateiverzeichnis auf ein anderes – abhängig vom "Absender" oder "Betreff" – verschiebt.
In diesem Kapitel wird die Frage beantwortet "sind Software Agenten nicht nur ein Forschungsobjekt und von rein akademischem Interesse ohne reale Produkte dahinter?"
Zuerst einmal muß man sich bewußt werden, daß es eine ganze Palette von Software Agenten gibt. Der Begriff umfaßt alle von den ganz einfachen bis zu den sehr komplexen. Im ursprünglichen XML/EDI-Framework, das hier beschrieben wird, ist der Gebrauch von Agenten entweder einfach, oder es werden schon erprobte Agentenmethoden und -technologien verwendet. Einige Beispiele sollen das illustrieren. Eine Agenten–Komponente wird benötigt, um Anwendern den Zugang zu den existierenden Datenbanken zu verschaffen oder bei entsprechendem Auftrag selbst Datenbanken zu erstellen. Java hat diese Fähigkeiten bereits sowohl in der JDBC Datenbankkomponente, als auch im ODBC Äquivalent von Microsoft. Somit schließt ein einzelner Agent eigentlich nur bestehenden Fähigkeiten ein. Ein anderer einzelner Agent hat vielleicht nur die Fähigkeit, dem Endbenutzer zu helfen, eine spezielle Komponente bei der ersten Benutzung zu konfigurieren. Das ist der übliche in "Wizard"-Stil zur Eingabe auffordernde Agent, der eine einfache Menge von Regeln und Benutzer-Abfragen hat, die er verarbeitet und eine Ergebnismenge erstellt.
Auf lange Sicht werden die komplizierteren Agenten also nicht auf dem Web Browser (der client-Seite) laufen, sondern auf Servern im Internet. Komponenten auf dem Web Browser werden dann diese entfernten Agenten (remote agents) befragen, um Resultate zu erhalten. Ein Beispiel dafür ist die globale Dictionarysuche (Global Dictionary Lookup). Ein lokaler Agent erhält einen EDI-Datensegmenttyp, den er nicht kennt. Deshalb fragt der Agent bei einem Agenten auf der Serverseite an, klassifiziert das Datensegment und sendet die Ergebnisse zurück.
Ein anderer Einwand gegen den Gebrauch von Agenten betrifft das Sicherheitsrisiko. "Diese Agenten sind Java-basiert und wie weiß ich, daß sie sicher sind?" Es liegt auf der Hand, daß in jeder EDI-Interaktion die Handelspartner vorher definieren müssen, wem sie erlauben, mit ihrem System an den Schnittstellen zusammenzuarbeiten. Sie sollten befähigt sein, festzulegen, von wem sie Agenten akzeptieren. Das wird in Zukunft die Sicherheit erhöhen, da ein bösartiger Agent, der in ein globales Netzwerk einsteigt, sich weit ausbreiten würde. Das sind allerdings Probleme, die nicht nur bei XML/EDI auftauchen, deshalb sollten sie in einem größeren Rahmen gelöst werden. XML/EDI sollte trotzdem sicherstellen, daß entsprechende Mechanismen in das System eingebaut werden, um solche Sicherheitsvorkehrungen zu nutzen.
Natürlich liegt der Vorteil der Verwendung von Agenten darin, daß das System fehlertolerant und viel einfacher zu bedienen ist. In vielen Fällen können Agenten Probleme lösen, ohne daß sich der Anwender überhaupt bewußt wird, daß es zu Beginn ein Problem gegeben hat. Das gerade gebrachte Beispiel vom Nachschlagen im Global Dictionary ist ein solcher Fall. Sobald der Agent die Information über das neu aufgetauchte Datensegment erhält, ist er schon in der Lage, dieses neue Element richtig zu verarbeiten. Vielleicht steht das neue Segment in Zusammenhang mit einer geänderten Regel für die Verarbeitung eines schon existierenden Segments. Dieser existierende Wert in einem Segment kann nun korrekt unter Verwendung des neuen Segments validiert werden usw.
Wie sieht es aus mit Such- und Routingtransaktionen?
XML/EDI wird in der Lage sein, viele Suchtools zu verwenden, die für XML adaptiert werden. Die Infrastruktur wird in Zukunft das Suchen von Geschäftsobjekten zusätzlich zur Suche nach Stichworten ermöglichen. Die Geschäftsobjekte in XML-Dokumenten werden ein intelligenteres Suchen ermöglichen, als die heutigen Full-text Suchmaschinen. Es gibt bereits SGML Abfragesprachen, die in ihrer Mächtigkeit SQL entsprechen. Man kann erwarten, daß diese mit den feldorientierten Suchverfahren relationaler Datenbanken integriert werden; diesbezüglich seine ConText von Oracle und das Monarch-Projekt von Microsoft, das OLEDB verwendet, erwähnt. Mit standardisierten DTDs für verschiedene Anwendungen könnte man eine Information viel exakter wiedergewinnen als heutzutage. Die Verbindungen (relationships) innerhalb der Strukturen können genauso wie die Objekte selbst in der Abfrage benutzt werden. Das DTD erlaubt die präzise relationale Suche von XML/EDI-Dokumenten entweder in der eigenen Nachrichtenablage, im Web (d.h. Katalogen), E-Mail Subsystemen usw.
Nach der Suche können die Transaktionen basierend auf der Information über den Anwendungstyp klassifiziert und geroutet werden,. Auf diesem Gebiet der Produktentwicklungwurde bereits und wird noch immer sehr intensiv gearbeitet (z.B. Intelliserv von Verity). Routing- und Statusinformation sind im Dokument selbst gespeichert. Das Routing kann im einfachsten Fall bedeuten, ein Dokument auf einen URL zu leiten. So arbeitet das Web heutzutage - man holt HTML-Seiten von Servern und schiebt sie dorthin; alles mittels eines Mausklicks. Das heißt, verteilte Applikationen sind dadurch möglich, daß man einfach die bestehende Infrastruktur im heutigen Internet benutzt. Diese verteilte Architektur hilft beim Abbildungsprozeß (mapping) auf bereits vorhande Anwendungen in herkömmlicher Technologie (legacy applications), wie später in diesem Artikel noch besprochen wird. Außerdem hat sich Agenten–Software parallel zum Internet explosionsartig entwickelt. Das XML/EDI Framework benutzt diese Agentenkomponenten, um die Aufgaben des Anwenders zu vereinfachen.
Wie sieht es aus mit der Anzeige der Transaktion?
Wie war das mit der Mensch-an-Applikation-Technologie im Web ? Ach ja, als zusätzlichen Vorteil werden die führenden Browser XML unterstützen, was es ermöglicht, Dokumente / Transaktionen genau auf die Art zu zeigen, wie der Benutzer es will, in welcher Form auch immer. Wenn die Benutzer wollen, daß die Transaktion genauso aussieht wie ihr Papierformular, dann wird sie auch so aussehen. Weil die Präsentation im Dokument gespeichert werden kann, bestimmen die Autoren während der Seitengestaltung völlig über Aussehen und Darstellung.
Es kommt noch besser: um die Transaktion zu betrachten,muß man keinen Dialo, Bildschirmmaske oder Formular erstellen. Während das Dokument von Abteilung zu Abteilung wandert oder vom Handelspartner in eine Abteilung, stellt es sich passend dar – und das automatisch. Es gibt keine endlosen Mannjahre Programmieraufwand mehr, um die Dialog(mask)e(n) für bestimmte Transaktionen zu warten. Ein XML API mit JAVA (XAPI-J) wird von allen XML Prozessoren (Browser und andere XML/EDI Tools) unterstützt werden. Mit diesem API werden Java Applets ermöglicht, mittels derer die Darstellung XML/EDI-codierter Information im Web Browser verändert werden kann. Die Art, wie die Transaktion gezeigt wird, ist dynamisch; einfach erstellt von ihrem Verfasser, der einmal einen XML/EDI Editor für die Transaktion benutzt. Jeder Knoten im Dokumenten-Workflow oder der Pipeline zeigt das Dokument wieder so, wie es vom Verfasser spezifiziert wurde.
Es gibt noch andere Vorteile, die strukturierte Präsentation mit den strukturierten Daten zu speichern:
Als Gesamtergebnis ergibt sich, daß XML/EDI Dokumente einfacher zu benutzen sind. Sogar einen "gelben Post-it Zettel" zu einem Dokument zu geben, ist mit XML/EDI kein Problem.
Schnittstellen mit einem Altsystem (legacy system) ?
oder der Informationsaustausch zwischen völlig verschiedenen Systemen
Heutzutage benutzen Unternehmen EDI nur, um fixe Daten von hier nach dort zu transportieren; die Daten werden aus ihren Datenbankfeldern herausgelöst, formatiert, gesendet, und wenn der Handelspartner sie erhält, nimmt er die Daten wieder auseinander und versucht herauszufinden, wo er sie in seine Datenbankfelder einfügen kann. Das ist ein verbreitetes Beispiel für die Arbeitsweise eines Legacy–Systems: angenommen, man will Daten von einer Applikation in den eigenen Workflow übergeben, oder man hat gerade das Dokument an den URL der Applikation geroutet, und man muß nun die Information von der/zur Applikation exportieren/importieren. Das XML/EDI Dokument muß aus/in das eigene RDBMS übersetzt werden. Welche Tools gibt es bei XML/EDI, um diese Aufgabe zu bewältigen?
Da die Daten selbstbeschreibend sind ist das Problem, die zu sendenden Daten zu extrahieren etwas einfacher, als nach Empfang einer ankommenden Transaktion eine Entschlüsselung vorzunehmen. Regelbasierte Templates unter XML sind sehr gut und unterscheiden sich nicht wesentlich von denen der heute üblichen Mechanismen. Weil ein DTD ein Standardformat für Information, die mit einem spezifischen Thema verbunden ist, vorgibt, kann es dazu verwendet werden, den Informationsaustausch zwischen verschiedenen Quellen zu vereinfachen. Viele Anwendungsarten haben Standard DTDs oder werden sie haben. Das bedeutet, daß Systeme diese gemeinsamen Basis–DTDs benutzen können, um miteinander Informationen auszutauschen, unabhängig von ihrem internen Format. DTDs auf diese Art zu verwenden, ist einer der wichtigsten Gründe, warum XML/EDI allen Organisationen, ob groß, mittel oder klein, ermöglichen wird, Daten auszutauschen.
Wo XML/EDI glänzt, ist bei der Handhabung der schwierigeren einlangenden Dokumenten. Bei herkömmlichem EDI erhält man von den Handelspartnern nur die Daten. Man halte sich vor Augen, daß man mit XML/EDI nicht nur Daten, sondern auch alle Regeln geliefert bekommt; nämlich die Applikationslogik, die dasjenige System benötigt, mit dem man zusammenarbeitet. Der Vorteil von XML/EDI ergibt sich daraus, daß nicht nur Datenelemente sondern Geschäftsobjekte weitergegeben werden. Wenn diese Objekte und ihre EC Mechanismen auf das Übersetzungsproblem angewendet werden, löst man sich von auschließlich datenbezogenen Schlußfolgerungen, was es ermöglicht, die Technologie der Software-Agenten unterstützend bei der doch herausfordernden Aufgabe des "mapping" einzusetzen.
Wie oben erwähnt, kann das Mapping in einer, durch die Verwendung von URLs gekennzeichneten, verteilten Architektur in den verschiedenen Anwendungen stattfinden, anstatt eine Vorgehensweise mit einem zentralisiertem Server zu erzwingen. Verteilte Architektur hilft beim Mapping auf alte Anwendungen (legacy applications), weil man das in der Applikation gespeicherte Wissen nützen kann. Validierung, Nachschlageverzeichnisse für Querverweise, und vor allem Applikationslogik können während des Mapping-Prozesses verwendet werden. Jeder Anwender wird tatsächlich zum Handelspartner, der interne und externe Transaktionen des Unternehmens sendet und empfängt.
Um die abgeschlossene Menge an Interaktionen hier zu verstehen, nehmen wir ein einfaches Beispiel an von zwei Geschäftspartnern, die sich gegenseitig Informationen schicken müssen. Partner A startet die XML/EDI Software, wählt die Datenbanken seiner Geschäftsapplikation aus, überprüft die Liste der angebotenen Informationen und wählt aus, welche Daten gesendet werden sollen. Die XML/EDI Software nimmt Bezug auf das Global Dictionary, sie sucht nach einem bestehenden Template mit signifikanter Übereinstimmung und auch nach dem Auftreten der gleichen betriebswirtschaftlichen Elemente im Dictionary. Übereinstimmungen von Datenelementen werden für offensichtlich zusammengehörende Datenelemente, wie Postleitzahl oder Rechnungsdatum gefunden, für den Rest aber werden die Definitionen von den Datenbankfeldformaten genommen. Falls kein passendes Template gefunden wird, erzeugt das System eines, das die zu sendende Information inklusive ihrer Datensatzstruktur beschreibt.
Das System erzeugt auch ein XML Dokument, zeigt es in einem Web Browser an und ermöglicht Partner A, sowohl diese Datenansicht zu modifizieren, als auch die zu sendende Information auszuwählen. Jetzt kann die Information zu Partner B gesendet werden.
Partner B erhält die Information, und er wiederholt den Prozess. Da er zum ersten Mal dieses Template und Datenformat erhalten hat, fragt deshalb die empfangende XML/EDI Software nach, welche Aktion zu setzen ist. Die Software benutzt das hereinkommende Template als Hilfestellung, um die Information mit den empfangenden Datenbanken der Geschäftsapplikationen von Partner B abzugleichen. Partner B erhält nun die Daten, und bildet sie auf die gleichen Orte und Datenelemente in den empfangenden Datenbanken an. Die Softwareagenten leiten diesen Prozeß, indem sie die offensichtlichen Übereinstimmungen finden. Die XML/EDI Software Agenten erzeugen nun ein zweites Template und Regeln, die diesem Satz von Datentransformationen entsprechen. Die Softwareagenten können auch automatisch Datenstrukturtransfers auflösen und die notwendigen Datensätze im empfangenden System erstellen. Partner B sieht sich die erhaltenen Daten in seinem Web Browser an und paßt die Darstellung (datentechnisch: view) an. Partner B kann nun sein Template benutzen, um auch Information aus seinem System zu extrahieren und sie zu zurück zu Partner A zu schicken. Partner A hat jetzt das Originaltemplate und das neue Template, das ermöglicht, den Prozeß umzukehren, um diese neue Information zu erhalten. In diesem Beispiel haben wir jetzt einen einfachen Transfer erklärt. Klarerweise können Java Applets oder ActiveX Komponenten ausgetauscht werden, um komplexe Interaktionen und Datenelemente zu berechnen. Ein Beispiel dafür wären die Zinszahlungen auf in der Vergangenheit fällige Beträge; vorausgesetzt sind dafür fünf Felder: der geschuldete Betrag, das Fälligkeitsdatum, das Zahlungseingangsdatum, der eingezahlte Betrag und der Zinsfuß.
Noch eine Anmerkung: in diesem Beispiel wurde die Interaktion vom Web Browser als Schnittstelle getrieben. Wenn allerdings einmal die Templates und Formate erzeugt sind, können diese auch leicht für einen Datenaustausch im Batch-Betrieb verwendet werden. In diesem Fall bestimmt die Stapelverarbeitung, welche Datenrecords wann gesendet werden und erzeugt die XML/EDI Dokumente, welche sie sofort entweder an einen Batchprozeß auf Empfängerseite, oder zu einer Web Browser Schnittstelle, oder sogar an ein E-Mail System für Lieferung und Weiterverarbeitung sendet. Dieses Beispiel soll vorerst Mächtigkeit und Flexibilität des XML/EDI Systems illustrieren.
Die Autoren diese Beitrags haben viele Jahre nach einer endgültigen Lösung für den Informationsaustausch zwischen völlig unterschiedlichen Systemen gesucht – XML/EDI kommt der idealen Lösung am nächsten.
Eine der mächtigsten Fähigkeiten, über die die Regelwerkskomponente (Rule Template Component) von XML/EDI verfügt, ist die Fähigkeit, Templates zu definieren, die Daten auf und von traditionellen EDI Nachrichten ( wie X.12, EDIFACT, oder HL7) abbilden. Das heißt, daß XML/EDI sich nahtlos in bestehende EDI Systeme einfügen und 100 % Rückwärtskompatibilität erzielen kann. Das Template enthält die Struktur von ankommenden und abgehenden EDI Nachrichten–Formaten, was XML/EDI ermöglicht, sie ohne Hilfe eines externen Übersetzungsprozesses exakt wiederzuerstellen. Dazu kommt noch die Fähigkeit von XML, eine Definition der Präsentation in den DTD's und der XML Struktur festzuschreiben, die den Web Browser anweist, wie er den Dateninhalt anzeigen und redigieren soll (wenn diese Funktion gebraucht wird). Deshalb kann eine bestehende EDI Nachricht eingelesen werden und die Details dem Benutzer direkt angezeigt werden. Das wird den traditionellen EDI Systemen die Möglichkeit geben, Anwender zu erreichen, die sie bis dato nicht erreichen konnten, da Einsatz und Wartung von traditionellen EDI-Konvertersystemen auf entfernten Standorten zu teuer waren.
Kritiker bemängeln das Anwachsen der Transaktionsgröße wegen der erhöhten (Byte)Anzahl von Tags. Eine verbreitete Behauptung ist, daß XML-EDI viel Verarbeitungsleistung und Bandbreite kosten dürfte. Die Kritik ist berechtigt, es wird zusätzlichen Overhead bei der Transaktionsgröße geben. Die erforderliche Anzahl Bytes könnte 50 % mehr als heute bei einer traditionellen EDI–Transaktion betragen. Nach Meinung der Autoren stellt die Bandbreite der Kommunikationsinfrastruktur heutzutage keine Beschränkung für den elektronischen Handel dar. Das Ansteigen der Byteanzahl bei Tags ist ein kleiner Preis, den man für die vielen Vorteile bezahlt.
Man stelle sich ein aktuell übliches EDI System vor, wo alles manuell abgestimmt wird, um die Nachrichtengröße zu minimieren und das auch 200.000 Nachrichten pro Tag überträgt. Kann ein Web-basiertes XML/EDI System damit und all dem Overhead an Steuerinformation fertigwerden ?
Hier muß man sich der Flexibilität der Methode bewußt werden. Vorzugsweise fügt man einfach alle benötigten Details und die Struktur hinzu, weil das bei Web–Interaktionen von geringem Umfang der beste Weg ist und sicherstellt, daß der Empfänger die übermittelte Information vollständig verarbeiten kann.
Man kann allerdings, da Template– und XML–Strukturinformation getrennte Komponenten sind, auch leicht den umgekehrten Zugang nehmen. Statt extensiv sprechende Steuerinformation (token) zu verwenden, kann man stattdessen zwei Byte lange Deskriptoren als "Token" auswählen, die nur maschinenlesbar sind, und dazu nur den Datenausschnitt der XML Message senden. Jetzt ist der semantische Overhead mit dem herkömmlichen EDI vergleichbar.
Die Templates und Java Applets werden nur einmal als getrennter Datenaustausch gesendet. Wenn sie einmal aufgerufen wurden, enthalten die Templates die Logik, um die codierten Tokens in Langtext umzusetzen, entweder unter Bezugnahme auf das globale Wörterbuch, oder indem man das expandierte Format einfach in den Templates selbst hält. So entspricht z.B. sedezimal "D7BD" dem "Letzten Rechnungsdatum" usw. Ähnlich könnte man sogar den Nachrichteninhalt selbst komprimieren und dann ein Java Applet mit der Expansionsroutine verwenden, um die tatsächlichen Daten zurückzuholen. Das ist XML/EDI für Leistungshungrige.
Was ist die bestehende Alternative?
Vergleichen sie XML/EDI wie oben beschrieben mit Ihren jetzigen Prozessen. Sogar das einfachere HTML Web Interface, das heute Tausende von Firmen entwickeln, erscheint archaisch im Vergleich zu den Vorteilen von XML/EDI.
Um die Unterschiede zu verdeutlichen: ein HTML Formular wird mit Text, drop-down Eingabefeldern etc., entweder statisch erstellt oder dynamisch generiert um diejenige Information aufzunehmen, die von einem Benutzer erlangt werden soll. Hartkodierte JavaScript– oder Java–Objekte sind mit der Seite verbunden (jedoch nicht gebunden an ein Geschäftsobjekt) und reagieren auf diese allgemeinen Ereignisse, um sie zu validieren. Nach Übergabe an einen Server vermittels hartkodierter Syntac gemäß CGI, NSAPI, ISAPI, oder ASP ( Active Server Pages), können diese dann in einer proprietären Datenbank gespeichert oder auf X.12 oder EDIFACT Transaktionen abgebildet werden. Und wenn die Web Seite an eine externe Firma geht... nein, dieser Artikel kann die empfangsseitigen Probleme eines bereits bestehenden Systems nicht behandeln. Es genügt zu sagen, daß man dann das gleiche Abbildungsproblem zwischen Firmen hat. Funktioniert die eben angerissene HTML–basierte Methode für einige Anwendungen? Ja, aber sehr beschränkt im Vergleich zu den Wahlmöglichkeiten, die sich mit XML/EDI bieten.
XML/EDI bietet ein ausbaufähiges Tool, das weniger konventionelle Programmierung für Entwicklung und Einsatz benötigt.
Das Framework läßt sich am besten in den folgenden Feststellungen zusammenfassen:
XML/EDI in Kürze...
XML/EDI im Detail...
"... mit XML/EDI endet der Prozeß nicht an den Toren des Unternehmens, sondern erstreckt sich in eine Organisation hinein und wird dadurch in allen seinen Aspekten wirksam."
DOCUMENT NOTICE
Copyright © 1997 World Wide Web Consortium, (Massachusetts Institute of Technology, Institut National de Recherche en Informatique et en Automatique, Keio University). All Rights Reserved.
This W3C document is being provided by the copyright holders under the following license. By obtaining, using and/or copying this document, you agree that you have read, understood, and will comply with the following terms and conditions:
Permission to use, copy, and distribute the contents of this document in any medium for any purpose and without fee or royalty is hereby granted, provided that the full text of this NOTICE appears on ALL copies of the document, or portions thereof, that you make. In addition, credit shall be attributed to the copyright holders for any software, documents, or other items or products that you create pursuant to the implementation of the contents of this document, or any portion thereof.
No right to create modifications or derivatives is granted pursuant to this license.
THIS DOCUMENT IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE DOCUMENT ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE DOCUMENT OR THE PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS THEREOF.
The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to this document or its contents without specific, written prior permission. Title to copyright in this document will at all times remain with copyright holders.