E-Business stellt eine wichtige Gelegenheit für die Unternehmen dar, die die Verwaltung ihrer Operationen durch die Automatisierung des Datenaustauschs zwischen Unternehmen/Kunden und Unternehmen/Unternehmen verbessern wollen. Es wurden verschiedene Protokolle für die gemeinsame Nutzung von Daten, den externen Aufruf von Objekten und das XML-Messaging entwickelt, aber sie alle befinden sich noch in frühen Entwicklungsphasen. Endgültige und formale Standards müssen erst noch entwickelt werden, aber es wurde bereits sehr viel Arbeit in Hinblick auf die Entwicklung von Methoden geleistet. Heute lernen Sie die folgenden Dinge kennen:
In Kapitel 19 haben Sie Applikationen kennen gelernt, die vor allem für Unternehmen viele Vorteile bringen können. Jedes Szenario beschrieb ein System, das XML verwendet und Nutzen daraus zieht, sodass typische Unternehmen verbesserte interne Operationen daraus ableiten können. Heute werden Sie Vorteile kennen lernen, die die Unternehmen, welche Produkte und Dienstleistungen über das Web verkaufen, durch die Anwendung von XML-Technologien erzielen. Der Trend, fast jedem normalen Wort das Präfix E- voranzustellen, hat zu einer gewissen Verwirrung dahingehend gesorgt, was E-Commerce und E-Business eigentlich sind. Sie können sich E-Business und E-Commerce wie fast jede andere normale Geschäftstransaktion zwischen Unternehmen und Einzelpersonen (Business-to-Consumer, B2C) oder zwischen verschiedenen Unternehmen (Business-to- Business, B2B) vorstellen. Vielleicht haben Sie auch schon von B2G (Business-to- Government) gehört, es gibt aber auch noch andere Akronyme. Heute werden wir uns darauf konzentrieren, wie XML Vorteile für B2C-Systeme bieten kann, und dann verschiedene interessante neue Technologien im B2B-Bereich vorstellen.
Laut IBM (Quelle: http://www-7.ibm.com/nz/e-business/overview.html) ist zu erwarten, dass die Verbraucher im Jahr 2001 mehr als 130 Milliarden Dollar über Online- Transaktionen ausgeben. Andere Industrieanalysten sagen das größte Umsatzwachstum innerhalb des B2B-Sektors voraus. Für den E-Commerce zwischen einzelnen Unternehmen geht man von einer Steigerung auf 1,3 Billionen Dollar im Jahr 2003 aus, das ist der zehnfache Betrag des für den Verbraucher-E-Commerce vorhergesagten Umsatzes. Dieser Betrag entspricht etwa 9% des Gesamthandels der USA und ist höher als das Bruttosozialprodukt von Großbritannien oder Italien, das Doppelte des BSP von Kanada und ein Drittel des BSP von Japan (Quelle: http://www.oecd.org/std/dgp.htm). Für das Jahr 2004 erwartet man laut einer Analyse der Gartner Group einen Umsatz von 7,3 Billionen Dollar, wie das Business Technology Network (http://content.techweb.com/ wire/story/TWB20000217S0002) berichtet. Um sicherzustellen, dass diese Investitionen sinnvolle Gewinne erzielen, braucht man die besten technischen Lösungen. Und es ist nicht überraschend, dass XML eine signifikante Rolle in vielen dieser Lösungen spielt.
E-Business und E-Commerce sind keine Technologien der Zukunft mehr. Die meisten Unternehmen investieren bereits heute in die Integration von Geschäftsprozessen in das Web. Verkäufe im Web begannen mit Verbrauchsgütern und wuchsen schnell an auf Vorgänge wie beispielsweise die Verwaltung von Lieferantenketten, der Handel auf elektronischen Marktplätzen sowie unmittelbare elektronische Produkt- und Dienstleistungsbeschaffungs-Modelle. Diese Initiativen führen zu enormen Netzwerkerweiterungen auf der gesamten Welt, fördern die Wirtschaft und beeinflussen sogar nationale Wahlen. Gemäß den Studien von PricewaterhouseCoopers (PWC) (http:// www.pwcmoneytree.com/) werden »Unternehmen, die E-Business [-Technologien] einsetzen, die Konkurrenz überholen und dauerhafte Konkurrenzvorteile genießen. Die E-Manager von heute und morgen müssen wissen, wie sie ähnliche Ergebnisse erzielen können«.
E-Business ist die Verknüpfung von Kern-Geschäftssystemen und Web-Technologie. Allgemein ausgedrückt, bedeutet E-Business, Geschäfte über Intranets, Extranets oder das Internet zu machen. E-Commerce bezieht sich normalerweise auf Kauf und Verkauf über das Internet.
Eine der primären Komponenten jeder E-Business-Strategie ist die Integration der Lieferantenkette: B2B. Bald schon wird sich eine Konzentration auf dieses E-Segment mit machbaren, auf XML basierenden technischen Lösungen, die Schlüsselplattformen für den kleinen bis mittleren Geschäftsbereich bieten, abzeichnen. B2B ist der Bereich, der innerhalb der nächsten Jahre sehr wahrscheinlich den größten finanziellen Einfluss auf die meisten E-Business-Unternehmen hat. Gemäß PricewaterhouseCoopers ist »die B2B- Komponente genau das, was die Manager des 21. Jahrhunderts verstehen müssen, um auf lange Sicht erfolgreich zu sein«.
Das B2C-Modell beinhaltet die Online-Automatisierung von Transaktions-basierten Applikationen. Viele davon eignen sich für den Einsatz von XML-Technologien, die erweiterte Funktionalität und verbesserte Effizienz bieten können. Im nächsten Abschnitt lernen Sie zwei Beispiele für diese Applikationen kennen und wie XML dafür eingesetzt werden kann. Ähnlich dem Ansatz für die Vorstellung der Unternehmens- Applikationsszenarien in Kapitel 19 werden Sie heute die folgenden Informationen erhalten:
Vielleicht haben Sie schon einmal ein Webportal besucht und Ihre Adresse, die Postleitzahl oder einen Bereichscode eingegeben, um den Wetterbericht für Ihre Region zu erhalten. Zusammen mit dem lokalen Wetterbericht haben Sie vielleicht auch Lokalnachrichten, aber auf alle Fälle auch auf Sie persönlich abgestimmte Werbung erhalten. Und genau diese Werbung trägt die Kosten für die Informationen, die Ihnen scheinbar kostenlos zur Verfügung gestellt werden. Warum sollte Ihnen schließlich ein Portal-Provider kostenlose Nachrichten, Sportergebnisse, Wetterberichte und andere Dienste bereitstellen, wenn er keinen Gewinn daraus zieht? Normalerweise brauchen Sie nichts dafür zu bezahlen, um diese Dinge einsehen zu können. Möglicherweise sieht aber ein Werbeträger Nutzen darin, Ihnen Banner-Werbung oder Popup-Fenster anzuzeigen, während Sie die Fußballtabelle oder die Lokalnachrichten lesen.
Diese Art der Personalisierung ist nur der Anfang dessen, was im Web unter Verwendung von XML in Kombination mit anderen Technologien möglich ist. Einige Online- Buchhandlungen beispielsweise stellen für ihre Stammkunden eine genau auf diese abgestimmte Buchempfehlung bereit. Eine Online-Buchhandlung könnte ein Cookie auf Ihrer Maschine ablegen, wenn Sie sie besuchen. Bei dem Cookie handelt es sich, wenn es effizient programmiert ist, um nichts weiter als eine Nummer, die einen Schlüssel zu einem Datensatz auf einer serverseitigen Datenbank darstellt. Der Datensatz könnte Informationen wie beispielsweise Ihren Namen, Details zu bereits getätigten Einkäufen, die Themen Ihrer Einkäufe und deren Häufigkeit enthalten. Ein in XML gespeichertes Profildokument könnte wie in Listing 20.1 gezeigt aussehen.
Listing 20.1: Personalisierungsprofil - profil.xml
1: <?xml version="1.0"?>
2: <!-- Listing 20.1 - profil.xml -->
3:
4: <profil>
5: <cookie id="6233265454"/>
6: <vorname>Devan</vorname>
7: <nachname>Shepherd</nachname>
8: <zuletzt_eingekauft date="07-01-01" frequency="6"/>
9: <interessen>
10: <kategorie>Technik</kategorie >
11: <unterkategorie>Computer</unterkategorie>
12: <thema>XML</thema>
13: <thema>Web-Entwicklung</thema>
14: <thema>C#</thema>
15: <thema>E-Commerce</thema>
16: </interessen>
17: </profil>
Andere Unternehmen bieten auf den Benutzer ausgelegten Inhalt an. Dieser angepasste Inhalt wurde zu einem allgemeinen Modell, um Werbe-Einnahmen zu erzielen, indem den Besuchern Informationsdienste angeboten werden. Die Anpassung erhöht den Verkehr, insbesondere für Sites, die wollen, dass ihre Besucher länger bleiben oder wiederkommen.
HTML-basierte Anpassungstechniken sind begrenzt und im besten Fall dazu geeignet, nur ein paar statische Inhaltsseiten anzuzeigen oder dynamischen Inhalt, der aus zuvor spezifizierten Modellen erzeugt wurde. Schwieriger ist es, mit diesen Techniken dynamischen Inhalt zu erzeugen. Wenn die Komplexität der Site-Verwaltung zunimmt, steigen normalerweise auch die Kosten, einen benutzerdefinierten Inhalt unter Verwendung von HTML-Werkzeugen auszuliefern.
XML unterstützt eine reibungslose Integration unterschiedlicher Inhalte sowie eine höhere Flexibilität, einzelnen Besuchern auf sie abgestimmte Informationen bereitzustellen. XML ist nämlich in der Lage, Textdaten zu strukturieren. Einzelne Strukturen können nach Bedarf erzeugt werden. Normalerweise werden sie aus bereits vorhandenen Datenquellen abgerufen, wozu Technologien ähnlich der gestern vorgestellten verwendet werden.
Normalerweise identifiziert eine Website, die diese Art benutzerdefinierter Inhaltsbereitstellungen verwendet, den Kunden und übergibt die ID einer Datenbank. Die Datenbank enthält Datensätze, die von einer entsprechenden Engine analysiert werden, um Muster zu erkennen und so die Informationen auszuwählen, die dem Besucher angezeigt werden sollen. Eine solche Engine könnte ein Schema auswählen, um die Datenstrukturen zu definieren und ein XSL-Stylesheet zuzuordnen, mit dem die Daten nach Bedarf vor der Darstellung umzuwandeln sind. Das Schema hilft, zu entscheiden, welche Datenelemente aus dem Informationsspeicher abgerufen werden sollen. Die XSL- Stile wandeln die Ausgaben nach den speziellen Bedürfnissen des Benutzers um. Diese Schritte können dynamisiert werden, sodass jede Bereitstellung von Daten ganz speziell für genau diesen Besucher ist. Auf diese Weise können bei jedem Starten der Applikation benutzerdefinierte Daten bereitgestellt werden.
Der Entwurf eines Profils mit einem solchen System ist eine der wichtigsten Forderungen für den Erfolg. Die Analyse der Benutzeranforderungen und der Inhaltswünsche schließlich erbringt den Lohn für den Aufwand, diese Informationen zu speichern und auszuliefern.
Einige Portalsysteme sind in der Lage, ihre Profilsammlungen in einem Pool bereitzustellen, sodass eine Applikation, die als B2C-Auslieferungssystem angefangen hat, Komponenten enthalten kann, die B2B-Transaktionen charakterisieren. Je mehr Sie über einen Besucher Ihrer Portal-Website wissen, desto besser sind Sie in der Lage, ihm interessanten Inhalt anzubieten. Durch den Austausch von Profildaten mit kompatiblen Inhalts-Providern kann die Anpassung auf immer mehr Informationen über den Besucher basieren. Wenn Ihre Partner dasselbe XML-Vokabular für ihre Profile verwenden, wird die Aufgabe noch einfacher und effektiver.
Einige interessante Aspekte dieser Art Webdaten haben mit der Dokument-Persistenz zu tun. Sie helfen, diese Sites von solchen zu unterscheiden, die statische Informationen enthalten. Die Datendokumente, aus denen sich die Profile zusammensetzen, sollten so gespeichert werden, dass mit der Zeit Präferenzinformationen zur Verfügung stehen. Andererseits ist der durch eine Personalisierungs-Engine erzeugte Inhalt »flüchtig«. Der Inhalt gilt nur solange, bis der Besucher der Site ihn verbraucht hat. Statische Webseiten enthalten Informationen, die immer wieder angezeigt und nicht dynamisch erzeugt werden. Die Verbraucher von Daten auf Portalsites fordern dynamisch erstellte Daten. Die Beibehaltung einzelner Dokumente ist unnötig, wenn sie jederzeit benutzerdefiniert wieder erzeugt werden können. Nachdem die Daten erzeugt und verbraucht wurden, werden sie wieder freigegeben. Werden sie erneut benötigt, können sie immer wieder hergestellt werden.
Ein weiterer Grund für die Freigabe der erzeugten Informationen ist, dass diese Art Daten normalerweise regelmäßig aktualisiert werden. Wenn Ihre Site beispielsweise Wettervorhersagen oder Aktienwerte anbietet, wollen Sie aktuelle Daten erhalten. Nachdem die Daten verbraucht sind, sind sie veraltet und können freigegeben werden. Ein neuer Abruf der Aktienwerte oder der Wettervorhersage zeigt dann die jeweils aktuellsten Werte an.
Applikationen für die Sammlung von Informationen im Web sind ideal für XML geeignet. Diese Applikationen sammeln Informationen aus unterschiedlichen Quellen, um sie zu einer einzigen Darstellung zu kombinieren. Auf dieselbe Weise wie Distributoren materielle Güter transportieren und dazu Auftragsverarbeitung, Verpackung und Auslieferung übernehmen, bieten die Aggregatoren eine Konsolidierung über das Web. Manchmal erfolgt die Konsolidierung, um materielle Güter und Produkte über elektronische Vertriebskanäle zu transportieren. In anderen Fällen stellt die Konsolidierung digitale Informationen bereit.
Angenommen, Sie verkaufen Heimkinos auf einer Website, die den Kunden hilft, einzelne Komponenten dafür auszuwählen, indem sie Vergleiche, Statistiken zur Audioqualität und Preise vorstellt. Die Aggregation der Daten für die einzelnen Komponenten könnte als Dienst angeboten werden. Die Verbraucher wollen vielleicht nicht die gesamte Beschreibung für jede einzelne Komponente lesen, und die einzelnen Komponenten ändern sich schnell. Die Aggregations-Applikation kann sicherstellen, dass die endgültige Zusammenstellung des Systems kompatibel ist. Die Preisgestaltung kann als Variable für die Auswahl vorgegeben werden. Mit anderen Worten, es kann für einen bestimmten Maximalbetrag eine optimale Lösung zusammengestellt werden, abhängig davon, ob der Verbraucher mehr an Sound- oder mehr an Videoqualität interessiert ist oder ob er Wert auf ein bestimmtes Medium legt, beispielsweise CD, MP3 oder Video-Disc. Ein Distributor kann diese Art von Informations-Aggregation unterstützen, sodass große Vertriebsketten, spezialisierte Video-Läden oder Kaufhäuser wie auch die Kunden davon profitieren können. Die Aggregation kann als Teil der Kette angeboten werden, sodass die beim Distributor platzierten Aufträge vor der Auslieferung gemäß den angepassten Paketanforderungen zusammengebaut werden.
Die Informations-Aggregation im großen Stil ist schwierig, weil es an allen Punkten der Informationskette inkompatible Systeme geben kann. So können die Spezifikationen, Details und Auftrags-Transaktions-Daten der Komponentenhersteller des Heimkino- Beispiels auf unterschiedlichen Plattformen und in den verschiedensten Formaten vorliegen. Es kann sich recht schwierig gestalten, nur die wichtigsten Fakten aus all diesen Quellen in einer maschinell lesbaren Struktur zu extrahieren. Noch schwieriger ist es, wenn die Daten nicht nur von den Maschinen, sondern auch von intelligenten Menschen gelesen werden sollen. Die bei jedem Lieferanten verwendeten proprietären Formate machen es schwierig, Daten zu aggregieren. Nach der Aggregation muss der Aggregator sicherstellen, dass die Informationen in einem Format präsentiert werden, das für Wiederverkäufer und Verbraucher im Web sinnvoll und nutzbar ist. Vielleicht ist es sogar erforderlich, mehrere Ausgabeformate für die aggregierten Informationen zu erzeugen.
Die Verwendung von XML zur Sammlung von Informationen aus unterschiedlichen Quellen zur Konsolidierung in einer einzelnen Quelle und ihre Bereitstellung in mehreren Formaten ist sinnvoll. Wie Sie wissen, kann XML sowohl von Maschinen als auch von Menschen gelesen werden. Eingaben können einfach in einer intelligenten Datenmenge mit einem Markup versehen werden, das die Struktur der Information beibehält. Durch die Verwendung von XSLT in Kombination mit Schemata können Sie aggregierte Informationen in den unterschiedlichsten Formaten anbieten, ohne die Integrität der Daten zu gefährden oder eine Quelle mehrfach berücksichtigen zu müssen. Die Schemata sind extrem wichtig für die Aggregation und können einem Unternehmen durch die Kombination mit Marketing-Daten einen wesentlichen Konkurrenzvorteil verschaffen. Die Aufzeichnung der Informationsanforderungen von Kunden, Lösungsanbietern oder sogar solchen Besuchern, die selbst Heim-Stereo-Lösungen anbieten, können die Gewinne eines Unternehmens steigern, indem genau solche Kombinationen und Optionen angeboten werden, die am häufigsten nachgefragt werden. Über die Zeit betrachtet, können diese Muster interessante Informationen für den Wiederverkäufer auf der Ausgabeseite der Aggregation und die Hersteller auf der Eingabeseite darstellen.
Durch den Zugriff auf die Daten, die von einer Vielzahl von Providern zur Verfügung stehen, kann ein Aggegator Gewinn ziehen, indem er verschiedene Kombinationen der Informationen erzeugt. In einigen Fällen können die Daten von Providern stammen, die in der Lage sind, sie im XML-Format anzubieten. In diesen Fällen erhält der Provider ein Schema. Erhält er es aus einem industriespezifischen Repository, so erzeugt er damit Ausgaben in der vorgegebenen Struktur. Andere Provider von Daten können jedoch andere Formate verwenden, die der Aggregator entgegennehmen und vor der Aggregation manipulieren muss. Die Verarbeitungs- und Aggregationsschritte stellen einen eindeutigen Wert dar und führen letztlich zu Verkäufen. Nachdem das Repository aufgebaut ist, kann eine auf dem Web basierende elektronische Abfrage entweder durch einen Kunden oder durch einen Wiederverkäufer die Applikation veranlassen, auf die erforderlichen Dokumente zuzugreifen, eine dynamische Datenmenge zu erzeugen und ein XSL- Stylesheet darauf anzuwenden, das genau auf die Bedürfnisse des Anforderers abgestimmt ist.
Weitere Beispiele für Informations-Aggregatoren im Web sind:
In all diesen Fällen besteht der Schlüssel zum Erfolg darin, einen zuverlässigen und extrem automatisierten Datenstrom aufzubauen, der von einem Informations-Provider über einen Aggregator zu einem Informationsverbraucher führt. Bei jedem Schritt in dem Prozess macht der Informations-Aggregator die bereitgestellte Information noch interessanter. Auf der Eingabeseite sammelt der Aggregator nur die wertvollen Daten, die benötigt werden, um bestimmte Bedürfnisse abzudecken. Durch das Ausschließen unwichtiger Marketing- und Spezifikationsdetails kann sich der Aggregator auf eine Antwortmenge der Daten konzentrieren, die genau den Bedürfnissen des Informationsverbrauchers entspricht.
Die Entwicklung dieser Art von Applikationen bedingt, dass Sie die Daten verschiedener Informations-Provider analysieren und auf die Bedürfnisse der Informationsverbraucher abbilden. Nachdem Sie festgestellt haben, was alles zur Verfügung steht und wie Sie es für die Verbraucher verpacken können, können Sie Schemata entwerfen, um die beteiligten Strukturen zu definieren und sie den Informations-Providern zur Verfügung stellen, die Ihre Dienste in Anspruch nehmen wollen. Im Fall von Shopping-Robotern für Verbrauchsgüter im Web abonnieren die Hersteller, die daran teilnehmen wollen, den Dienst. Ganze Industriezweige bieten manchmal eine eigene, konzentrierte Aggregation. Im Juni 2001 beispielsweise wurde ein Vertrag zwischen United Delta, Continental, Northwest und American Airlines unterschrieben, um http://www.orbitz.com ins Leben zu rufen, bei dem die Sitze im Flugzeug direkt an die Kunden verkauft werden, in direkter Konkurrenz zu den unabhängigen Reise-Aggregations-Sites, wie beispielsweise http://www.travelocity.com oder http://www.expedia.com/. Gemäß einer CNN-Story über den Vertrag (http:// www.cnn.com/2001/TECH/internet/06/05/orbitz.travel.idg/index.html) werden die 50 Millionen Doller Anfangskosten für den Betrieb von den Fluglinien aufgebracht, die eine verteilte Architektur verwenden und erstklassigen Inhalt versprechen.
Verwandt mit der Aggregation ist ein relativ neuer Trend zur XML-basierten Integration von Lieferketten. Die elektronische Verbindung von Marktplätzen macht es den Unternehmen einfacher, miteinander zu kommunizieren, um geschäftliche Transaktionen auszutauschen. Angenommen, Sie verkaufen Computer an große Elektronik-Kaufhäuser, Computer-Ketten und Discount-Warenhäuser. Sie haben eine Lieferkette, die Sie mit Komponenten versorgt wie beispielsweise Platinen, Bildschirme, Tastaturen, Drucker, Gehäuse usw. Diese Lieferkette ist ein Marktplatz für Sie. Sie sind ein Provider von Computern auf einem Marktplatz, der die Warenhäuser bedient, die Ihre Güter verkaufen. In diesem Szenario kann eine Information über Preisänderungen von jedem Lieferanten an zahlreiche Wiederverkäufer weitergegeben werden und jeder Wiederverkäufer wiederum kann Aufträge für Artikel mit dem neuen Preis absetzen. XML erlaubt den Entwicklern, Dokumente zu erstellen, die genau diese Transaktionen beschreiben.
Angenommen, Sie wollen Speicherchips kaufen, um sie in Ihre Computer einzubauen. Sie wenden sich an Ihre Lieferantenkette und stellen eine Preisnachfrage für die Menge der benötigten Speicherkarten. Anschließend machen Sie das Geschäft mit dem Lieferanten, der Ihre Anforderungen in Hinblick auf Menge, Qualität und Preis abdecken kann.
Die Automation soll am Ursprung der Daten, egal ob bei Wiederverkäufer oder Lieferant, helfen, Dokumente in Formaten zu kodieren, die ganz einfach über das Web übertragen werden können. Die Lösungen müssen das Senden und Empfangen von Transaktionen mit höchster Genauigkeit nachbilden. Im Idealfall sollten alle Nachrichten nach dem Empfang elektronisch bestätigt werden, sodass die Auslieferung garantiert ist, auch wenn technische Probleme bei der Internetverbindung auftreten. Wird keine Bestätigung zurückgemeldet, sollen die automatisierten Systeme kritische Transaktionen solange wiederholt übertragen, bis sie erfolgreich angenommen wurden. Darüber hinaus sollen die Lösungen Authentifizierung, Sicherheit und Datenintegrität in allen Punkten des Austauschs unterstützen.
Als die Entwickler anfingen, die Probleme bei der gemeinsamen Nutzung von Geschäftsdaten über das Web für einen elektronischen Handel zu betrachten, konzentrierte sich der Entwurf häufig auf Vokabulare und Dialekte. Die Analyse zeigte normalerweise genau, welche Informationen auszutauschen warer und führte zu einem Format oder Schema für diesen Austausch. Viele der frühen Aggregations-Bemühungen folgten diesem Modell. Es funktionierte bei der Auslieferung der verschiedensten Lösungen, litt aber darunter, dass es extrem angepasst war, um ein spezielles Bedürfnis abzudecken. Wenn sich die Geschäftsdatenstruktur mit der Zeit weiterentwickelte, mussten die Transaktionen neu erstellt werden, um diesen ständig abgeänderten Schemata zu entsprechen. Man brauchte einen Wechsel von den Problemen der Datenklassifizierung zu der grundlegenden Frage, wie XML zwischen Parteien als Teil eines sinnvollen, zuverlässigen Austauschs übertragen werden kann. In diesem Abschnitt lernen Sie die führenden Protokolle für den XML-Datenaustausch kennen und welche Probleme sie lösen sollen. Es wird vorausgesetzt, dass Sie als Programmierer mit Scripting- Sprachen und den Grundlagen von HTTP und Web-Protokollen vertraut sind. Diese Beschreibung konzentriert sich auf die eigentlichen Protokolle und nicht auf die zu Grunde liegenden Konstrukte.
Das W3C bietet einen Überblick über verschiedene XML-Datenaustausch-Protokolle unter http://www.w3.org/2000/03/29-XML-protocol-matrix. Obwohl dem W3C Dutzende von Protokollen vorgelegt wurden, haben sich XML-RPC, SOAP, WDDX und ebXML als diejenigen herauskristallisiert, die am wahrscheinlichsten zu einer endgültigen Lösung für die XML-Übertragung übernommen oder kombiniert werden.
Viele der Geschäfts-Transaktionen, die am E-Business beteiligt sind, werden durch das HTTP-Protokoll über das Internet übertragen. Es ist relativ einfach, eine solche Transaktion über die Verwendung eines XML HTTP-Objekts zu simulieren, um ein externes XML-Quelldokument zu finden. Angenommen, Sie wollen eine Webseite schreiben, die ein XML-Dokument von einem Webserver abrufen kann, indem sie seinen URI bereitstellt. Sie können das von Microsoft unterstützte XML HTTP-Objekt verwenden und dazu ein bisschen JavaScript, um das ganz einfach zu erledigen. In der Praxis würden Sie diese von Microsoft abhängige Technologie vielleicht nicht verwenden, es sei denn, Sie könnten garantieren, dass sie von allen genutzt werden kann, die auf diese Weise auf die Webseiten zugreifen müssen. Sie ist nur der Demonstration halber beschrieben, um einen Ansatz zu zeigen, wie diese Form der Verbindung erzielt werden kann.
Unter Verwendung von JavaScript soll dieses Objekt als neues ActiveX-Objekt instanziert werden, wie Sie das DOM-Objekt Microsoft.XMLDOM in Kapitel 12 aufgerufen haben. Die Syntax sieht folgendermaßen aus:
var meineVariable = new ActiveXObject("Microsoft.XMLHTTP")
Nachdem das Objekt instanziiert ist, können Sie Methodenaufrufe für Ihre Variable verwenden, um Standard-HTTP-Methoden auszuführen, wie beispielsweise GET oder POST. Eine GET-Methode könnte genutzt werden, um ein XML-Dokument von einem externen Server abzurufen oder irgendeinen anderen Inhalt und POST könnte genutzt werden, um ein XML-Dokument zur Verarbeitung an ein serverseitiges Script zu senden. Das GET würde etwa so aussehen:
meineVariable.open("GET", (URL), false)
meineVariable.send()
meineAntwortVariable = meineVariable.responseText
Die Methode open richtet eine HTTP-GET-Methode für den angegebenen URL ein. Der Parameter false zeigt an, dass die Methode synchron ist; sie muss also die Ausführung beenden, bevor eine andere Methode ausgeführt werden kann. Die send()-Methode übergibt die GET-Methode über HTTP und die Antwort des Aufrufs ist in der Variablen gespeichert, die Sie als meineAntwortVariable angegeben haben.
Nachdem Sie die Antwort erhalten haben, in diesem Fall den vollständigen Text der abgerufenen XML-Datei, können Sie sie auf dem Bildschirm ausgeben, indem Sie sie an das Standard-Ausgabegerät senden. Um ein einfaches Beispiel dieses Ansatzes zu vervollständigen, schließen Sie es in HTML-Tags ein, die verhindern, dass das Markup geparst wird, wie beispielsweise <XMP>. Der Wrapper könnte folgendermaßen aussehen:
document.write("<XMP>" + meineAntwortVariable + "</XMP>");
Listing 20.2 zeigt ein vollständiges HTML-Programm, das diesen Ansatz demonstriert. Geben Sie dieses Beispiel ein und speichern Sie es unter dem Namen httpGetXML.html.
Listing 20.2: Eine Programm zum Abruf von Dateien, das das XMLHTTP-Objekt verwendet - httpGetXML.html
1: <!DOCTYPE XHTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
2: "http://www.w3.org/TR/html4/loose.dtd">
3: <!-- Listing 20.2 httpGetXML.html -->
4:
5: <HTML>
6: <BODY>
7: <SCRIPT language="JavaScript">
8:
9: var URL=prompt("Geben Sie bitte den URL der abzurufenden Datei ein",
10: "URL der XML-Datei eingeben");
11:
12: var xmlHttp = new ActiveXObject("Microsoft.XMLHTTP")
13: xmlHttp.open("GET", (URL), false)
14: xmlHttp.send()
15: xmlDok=xmlHttp.responseText
16:
17: document.write("<XMP>" + xmlDok + "</XMP>");
18: </SCRIPT>
19: </BODY>
20: </HTML>
Die Zeilen 9-10 erstellen eine einfache JavaScript-Eingabeaufforderung, die den Benutzer auffordert, einen URL für die abzurufende Seite einzugeben. Die Zeilen 12-15 instanzieren ein XML-HTTP-Objekt (Zeile 12) und erstellen einen synchronen GET-Methoden-String (Zeile 13), der über HTTP gesendet wird (Zeile 14). In Zeile 15 wird die Antwort in einer Variablen (xmlDok) abgelegt. Der Inhalt dieser Variablen wird in Zeile 17 auf dem Bildschirm ausgegeben.
Versuchen Sie, diese Seite in einen Browser zu laden und den URL für eine XML-Seite auf einem externen Webserver einzugeben. Beispielsweise können Sie das XML-Schema- Dokument abrufen, das W3C-Namensräume definiert: http://www.w3.org/XML/1998/ namespace. Wenn Sie den IIS Webserver auf Ihrem Computer einsetzen, können Sie auch eines der in den letzten Kapiteln erstellten und lokal gespeicherten Dokumente abrufen, vorausgesetzt, Sie haben es in einem virtuellen Webverzeichnis gespeichert.
XML-RPC ist ein Protokoll für externe Prozeduraufrufe, deren Kommunikation über TCP Port 80 (HTTP) in XML kodiert wird. XML-RCP-Implementierungen wurden in den unterschiedlichsten Sprachen für viele Plattformen geschrieben. Jedes XML-RPC-Element besteht aus zwei Teilen. Der erste Teil nimmt eine XML-RPC-Anforderung für einen Webdienst vor und wird deshalb auch als Client-Aufruf bezeichnet. Wenn Ihr Script XML- RPC-Anfragen beantwortet, wird es auch als Listener bezeichnet. Heute gibt es mehrere Implementierungen von XML-RPC. Diese Implementierungen - die auf Technologien wie Perl, Tcl, Python, PHP und AppleScript basieren - liefern den Beweis, dass der Mechanismus so plattform- und sprachunabhängig ist, wie seine Entwickler dies geplant haben. Programmiersprachen wie etwa Java, C++, C und VB bieten ebenfalls eine Möglichkeit, dies zu bewerkstelligen.
Der direkte Nachfolger von XML-RPC ist SOAP (Simple Object Access Protocol), das die Möglichkeit bietet, ein externes Objekt durch die Übergabe einfacher Parameter über HTTP in XML-Wrappern aufzurufen. SOAP ist wie XML-RPC eine auf dem Web basierte Abstraktion verteilter Client-/Server-Objektkommunikation. Die vollständige SOAP 1.1- Empfehlung wird momentan von der W3C bewertet, nachdem es ihr zur Überprüfung und Diskussion vorgelegt wurde. Den entsprechenden Text finden Sie unter http:// www.w3.org/TR/SOAP/. SOAP ist ein XML-Dialekt, der ein »schlankes« Protokoll für den Austausch von Daten darstellen soll, die benötigt werden, um ein externes Objekt aufzurufen und die Ergebnisse dieses Aufrufs an den ursprünglichen Anforderer zurückzugeben. Die W3C definiert SOAP als »XML-basiertes Protokoll, das aus drei Teilen besteht: einer Hülle, die ein Gerüst dafür anbietet, um zu beschreiben, was sich in einer Nachricht befindet und wie sie verarbeitet werden soll, einer Menge von Kodierungsregeln für den Ausdruck von Instanzen applikationsdefinierter Datentypen sowie einer Konvention für die Darstellung externer Prozeduraufrufe und -antworten«.
SOAP befindet sich in bester Position, komplexe Applikationen für externe Objektaufrufe anzubieten. Die Unterstützung wichtiger führender Industrien wird dazu beitragen, die Entwicklung plattformunabhängiger Lösungen voranzutreiben. Zum Zeitpunkt der Drucklegung dieses Buches ist die Technologie noch nicht ausgereift und es werden Werkzeuge benötigt, sie weiterzuentwickeln, damit sie künftig allgemein eingesetzt werden kann.
SOAP bietet eine Möglichkeit, externe Aufrufe für Objektmethoden oder Funktionen vorzunehmen. In herkömmlichen benutzerdefinierten XML-Applikationen müssen die client- und die serverseitige Applikation wissen, welches Nachrichtenformat für den Austausch von Daten verwendet werden soll. SOAP stellt Folgendes bereit:
SOAP kann also die expliziten XML-Kommunikationen ersetzen, die in benutzerdefinierten XML-Implementierungen auftreten. Damit dieser Prozess wirklich nahtlos ist, müssen Dienste oder Werkzeuge zur Verfügung stehen, die das Verpacken und Auspacken von SOAP XML unterstützen und die Datenaustauschoperationen durchführen.
SOAP bewerkstelligt dieses generische Parsen von Objektaufruf-Parametern, indem es die Aufrufe in eine standardisierte elektronische Hüllstruktur (Envelope) verpackt. Sie können sich die SOAP-Envelope wie einen Briefumschlag vorstellen. Sie platzieren die Information, die dem Objekt übergeben werden soll, im Umschlag und mailen ihn mit HTTP über das Internet. Es wird auch als SOAP-Anforderungsdokument bezeichnet. Am empfangenden Ende öffnet der SOAP-Server den Umschlag, packt den Inhalt aus und gibt ihn in Form eines Objektaufrufs an das externe Objekt weiter. Die vom Objekt erhaltene Antwort wird wieder im Umschlag platziert und über das Internet mit HTTP an den ursprünglichen Client weitergegeben. Sie wird auch als SOAP-Antwortdokument bezeichnet. Ein SOAP-Anforderungsdokument ist ein XML-Instanzdokument, das ein SOAP-Envelope, einen optionalen SOAP-Header und einen zwingend erforderlichen SOAP-Rumpf enthält. Der Rumpf des SOAP-Dokuments enthält die Aufruf-Parameter für das externe Objekt. Eine SOAP-Nachricht gehorcht den folgenden Syntaxregeln:
Die Syntax eines SOAP-Anforderungsdokuments sieht wie folgt aus:
<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/>
<SOAP-ENV:Header>
...optionale Header-Information
</SOAP-ENV:Header>
<SOAP-ENV:Body>
...Objektaufrufparameter
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Dieses SOAP-Anforderungsdokument enthält ein SOAP-ENV:Envelope-Wurzelelement, das zum Namensraum http://schemas.xmlsoap.org/soap/envelope/ gebunden ist. Der SOAP-ENV:Header ist ein optionales Element. Der SOAP-ENV:Body ist zwingend erforderlich und enthält die Parameter, die an das externe Objekt weitergegeben werden.
Die Syntax des SOAP-Antwortdokuments sieht so aus:
<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/>
<SOAP-ENV:Header>
... optionale Header-Information
</SOAP-ENV:Header>
<SOAP-ENV:Body>
... Objektaufrufparameter
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Dieses SOAP-Antwortdokument enthält ein SOAP-ENV:Envelope-Wurzelelement, das zum Namensraum http://schemas.xmlsoap.org/soap/envelope/ gebunden ist. Der SOAP-ENV: Header ist ein optionales Element. Der SOAP-ENV:Body ist zwingend erforderlich und enthält die Antwort des externen Objekts.
Stellen Sie sich vor, Sie haben Zugriff auf ein externes Objekt, das den aktuellen Handelswert für eine Aktie als Preisangabe zurückgibt. Sie können dazu beispielsweise dem Objekt einfach das Symbol für die betreffende Aktie übergeben. Das Objekt würde Ihnen den aktuellen oder zuletzt gehandelten Preis zurückgeben. Listing 20.3 zeigt das vollständige SOAP-Anforderungsdokument, das an ein imaginäres Aktieninformationsobjekt gesendet wird.
Listing 20.3: SOAP-Anforderungsdokument für eine Preisabfrage - SOAP_req.xml
1: <?xml version="1.0"?>
2: <!-- Listing 20.3 SOAP_req.xml -->
3:
4: <SOAP-ENV:Envelope
5: xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
6: xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">
7:
8: <SOAP-ENV:Header>
9: <SOAPsrvr>123</SOAPsrvr>
10: </SOAP-ENV:Header>
11:
12: <SOAP-ENV:Body>
13: <q:getQuote xmlns:q="urn:Devans-verspaetete-Meldungen">
14: <symbol>ssefx</symbol>
15: </q:getQuote>
16: </SOAP-ENV:Body>
17:
18: </SOAP-ENV:Envelope>
In diesem Beispiel enthält das SOAP-ENV:Envelope-Wurzelelement (Zeilen 4-18) ein SOAP-ENV:Header-Element (Zeilen 8-10) sowie ein SOAP-ENV:Body-Element (Zeilen 12-16). Die angeforderten Namensräume für den Umschlag sowie für die gesamte SOAP-Kodierung sind in den Zeilen 5 und 6 angegeben. Der Header dieses SOAP-Dokuments enthält einen SOAPsrvr, dessen Inhalt vom SOAP-Server verwendet wird, um das übergebene Paket zu verwalten. Der Rumpf enthält ein q:getQuote-Element, das an den Namensraum urn: Devans-verspaetete-Meldungen gebunden ist. Das Element symbol enthält den Namen eines Wechselfonds, ssefx (The Shepherd Street Equity Fund), für den das externe Objekt den zuletzt gehandelten Preis zurückgibt.
Das Listing 20.4 zeigt das vollständige SOAP-Antwortdokument, das vom SOAP-Server nach der Verarbeitung des Objektaufrufs gesendet wird. Die SOAP-Antwort umschließt die Ausgabe des Objekts.
Listing 20.4: SOAP-Antwortdokument für eine Preisabfrage - SOAP_resp.xml
1: <?xml version="1.0"?>
2: <!-- Listing 20.4 SOAP_resp.xml -->
3:
4: <SOAP-ENV:Envelope
5: xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
6: xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">
7:
8: <SOAP-ENV:Header>
9: <ProcessID mustUnderstand="0">0</ProcessID>
10: </SOAP-ENV:Header>
11:
12: <SOAP-ENV:Body>
13: <q_resp:getQuoteResponse xmlns:q_resp="urn:Devans-verspaetete-Meldungen">
14: <return>14.59</return>
15: </q_resp:getQuoteResponse>
16: </SOAP-ENV:Body>
17:
18: </SOAP-ENV:Envelope>
In diesem Beispiel enthält das SOAP-ENV:Envelope-Wurzelelement (Zeilen 4-18) ein SOAP-ENV:Header-Element (Zeilen 8-10) und ein SOAP-ENV:Body-Element (Zeilen 12-16). Die erforderlichen Namensräume für den Umschlag und die gesamte SOAP-Kodierung sind in den Zeilen 5 und 6 angegeben. Der Header dieses SOAP-Dokuments enthält einen SOAPsrvr, dessen Inhalt vom SOAP-Server verwendet wird, um das übergebene Paket zu verwalten. Der Rumpf enthält ein q_resp:getQuoteResponse-Element, das an den Namensraum urn:Devans-verspaetete-Meldungen gebunden ist. Das Element return gibt den Preis zurück, zu dem der Wechselfond, ssefx (The Shepherd Street Equity Fund), zuletzt gehandelt wurde.
Damit diese SOAP-Nachrichten gesendet und empfangen werden können, erzeugen Sie eine SOAP-Client-Applikation. Auf der Server-Seite interpretiert ein SOAP-Server die Nachrichten und übergibt die Parameter dem externen Objekt. Der SOAP-Server würde auch die Ergebnisse vom Objekt entgegennehmen und sie im SOAP-Antwortdokument platzieren, um sie zurück an die SOAP-Client-Applikation geben zu können. Abbildung 20.1 zeigt einen einfachen SOAP-Client, der mit der Entwicklungsumgebung IBM Sash Weblications erstellt wurde. Der Client, der mit xmethods.com erzeugt wurde, stellt mehrere kleine Applikationen bereit, die SOAP-Nachrichten verwenden, um externe Objekte aufzurufen.
Abbildung 20.1: xmethods.com - IBM Sash SOAP-Client
IBM Sash ist ein extrem konfigurierbares Entwicklungssystem, mit dem Netzwerk-Applikationen erstellt werden. Einige Entwickler verwenden Sash, um E-Business-Applikationen zu erstellen und sie mit Backend-Systemen und HTTP-Servern unter Verwendung existierender Ressourcen und Infrastruktur zu verbinden. Sie können Sash nutzen, um aus Ihren Webseiten voll funktionale Windows-Applikationen zu machen, deren Inhalt aus dem Web heruntergeladen wird.
Sie können Ihren eigenen SOAP-Client und -Server erstellen, um auf Objekte zuzugreifen, indem Sie einen der vielen im Web verfügbaren SOAP-Entwicklungs-Kits verwenden. Diese Distributionen beinhalten client- und serverseitige Werkzeuge sowie Beispiele. Einige davon finden Sie unter:
SOAP unterstützt alle Datentypen aus dem Abschnitt »Built-in Datatypes« des W3C- Arbeitsentwurfs XML Schema Part 2: Datatypes. Außerdem unterstützt es viele Struktur- und Array-basierte zusammengesetzte Typen (http://www.w3.org/TR/2001/REC-xmlschema- 2-20010502/).
WDDX, das von Allaire (http://www.allaire.com/handlers/index.cfm?ID=5624&Method= full) entwickelt wurde, stellt einen Mechanismus für den Austausch komplexer Datenstrukturen über HTTP zur Verfügung - als Alternative zu SOAP. Gemäß der Allaire- Dokumentation soll WDDX eine eher webtypische Möglichkeit anbieten, um strukturierte Datentypen zwischen Netzwerkeinheiten zu übertragen, ohne den programmtechnischen Ansatz für die Entwicklung von Web-Applikationen von seitenbasiert auf objektbasiert ändern zu müssen.
WDDX unterscheidet sich in zwei grundlegenden Aspekten von XML_RPC und SOAP. Erstens ist sein Ansatz für die Serialisierung auf Strukturen und nicht auf Objekten basiert. Darüber hinaus basiert WDDX nicht grundsätzlich auf RPC-Semantik. Die WDDX DTD und ein Serialisierungs-Modul, das die Umwandlung von nativen Sprach-Datenstrukturen in XML und umgekehrt vornimmt, charakterisieren WDDX. Listing 20.5 zeigt ein einfaches WDDX-Dokument, das aus einem einzelnen Paket besteht, das ähnlich dem SOAP-Beispiel gesendet wird, um den Preis eines Wechselfonds zu ermitteln.
Listing 20.5: WDDX XML-Paket, das einen Wechselfonds-Preis ermittelt - WDDX_stock.xml
1: <?xml version='1.0'?>
2: <!-- Listing 20.5 WDDX_stock.xml -->
3:
4: <!DOCTYPE wddxPacket SYSTEM 'Stock_check.dtd'>
5: <wddxPacket version='0.9'>
6: <data>
7: <struct>
8: <var name='getQuote'>
9: <value>SSEFX</value>
10: </var>
11: </struct>
12: </data>
13: </wddxPacket>
Das wddxPacket-Wurzelelement (Zeilen 5-13) enthält ein untergeordnetes data-Element. Das data-Element (Zeilen 6-12) enthält ein struct-Element (Zeilen 7-11). Das struct-Element wiederum enthält ein var-Element (Zeilen 8-10), das Parameter an eine Host-basierte Applikation weitergibt.
Allaire hat die WDDX-Spezifikation für die allgemeine Entwicklergemeinde freigegeben. WDDX wurde in ColdFusion und einem SDK mit Unterstützung von Java, JavaScript, Perl und COM/ASP angeboten.
Das Akronym ebXML steht für »electronic business XML«, eine gemeinsame Initiative der UN/CEFACT (United Nations/Trade Facilitation and Electronic Business) und OASIS (Organisation for the Advancement of Structured Information Standards). Die ebXML- Initiative soll »eine offene, XML-basierte Infrastruktur bereitstellen, welche die globale Verwendung von E-Business-Informationen auf interoperable, sichere und konsistente Weise durch alle Parteien ermöglicht« (Quelle: http://www.ebxml.org/).
Die Entwicklung von ebXML ist auf Teams verteilt, die für verschiedene Aspekte von E-Business verantwortlich sind, die XML-Technologien einsetzen. Das Team für Transport, Routing und Verpackung hat Empfehlungen für eine Nachrichtenumschlags- Spezifikation entwickelt, für ein allgemeines Anforderungsdokument sowie für eine Nachrichten-Header-Spezifikation.
Die Nachrichten-Envelope ist ein XML-Dokument, das aus einem Header-Envelope und einem Nutzlast-Envelope besteht. Der Header-Envelope besteht aus dem Nachrichten- Header und Routing-Informationen. Listing 20.6 zeigt ein Beispiel für einen Header- Envelope.
Listing 20.6: ebXML Header-Umschlag - ebXML_header.xml
1: <?xml version="1.0" encoding="UTF-8"?>
2: <!-- Listing 20.6, ebXML_header.xml -->
3:
4: <ebXMLMessageHeader>
5: <Version>1.0</Version>
6: <MessageType>Anforderung</MessageType>
7: <ServiceType>Aktienabfrage</ServiceType>
8: <Intent>Zuletzt gehandelter Preis</Intent>
9: </ebXMLMessageHeader>
Das ebXMLMessageHeader-Wurzelelement (Zeilen 4-9) enthält untergeordnete Version-, MessageType-, ServiceType- und Intent-Elemente. Sie stellen Routing-Informationen, Anweisungen und digitale Signaturen für die empfangenden Applikationen bereit.
Der Nutzlast-Envelope könnte ein oder mehrere Rumpfsegmente enthalten. Listing 20.7 zeigt ein Beispiel für ein Nachrichtenrumpf-Fragment. Das Dokument ist nicht vollständig, aber ausreichend, um ein Modell für eine Nutzlast darzustellen.
Listing 20.7: Beispiel für ein ebXML-Dokument - ebXML_payload.xml
1: <!-- Listing 20.7, ebXML_payload.xml -->
2:
3: <Control>
4: <Session Identity="Quote">
5: <Value>SSEFX</Value>
6: </Session>
7: </Control>
Dieser Codeausschnitt stellt ein Beispiel für einen Nachrichtenrumpf dar. Das Control-Element (Zeilen 3-7) enthält ein Session- (Zeilen 4-6) und ein Value-Element (Zeile 5), die Informationen an eine Applikation weitergeben, die Aktienpreise zurückgibt.
Zum Zeitpunkt der Drucklegung dieses Buches ist ebXML fast zwei Jahre alt, obwohl die erste Spezifikation vom Mai 2001 stammt. Eine Zeit lang hatte es den Anschein, als ob ebXML vollständig von den SOAP-Ansätzen abweichen würde, weil SOAP 1.0 keine Verarbeitung binärer Daten unterstützt, ein Anliegen, das von den ebXML-Arbeitsgruppen formuliert wurde. Der ebXML-Ansatz wurde verfolgt, um die globale Verwendung von E-Business-Informationen durch alle Parteien auf interoperable, sichere und konsistente Weise zu ermöglichen.
Obwohl ebXML und SOAP viele Eigenschaften gemeinsam haben, ist das Standardkomitee, das für ebXML verantwortlich ist, der Meinung, dass SOAP nicht wirklich offen und nicht proprietär war. Deshalb konnte ebXML SOAP nicht implementieren und behält seinen eigenen interoperablen Entwurf bei. Nichtsdestotrotz sind die Ähnlichkeiten unverkennbar. Beide Ansätze stellen ein Transportnetzwerk vor, innerhalb dessen Geschäftsdokumente sicher und zuverlässig übertragen werden können. Beide bauen auf Industriestandard- MIME-Technologien auf und verwenden XML-Header und Routing-Funktionalität. Diese beiden Standards sind so ähnlich, dass sich die Entwickler häufig fragen, warum es überhaupt zwei Standards gibt. Die ebXML-Komitees haben deshalb zugestimmt, einen Teil der SOAP-Spezifikation zu übernehmen, um der Industrie die Verwirrung durch zwei konkurrierende Standards zu ersparen. Das bedeutet, dass sich ebXML mit der Zeit eher zu einer komplementären und nicht zu einer konkurrierenden Technologie entwickeln wird. Es beinhaltet SOAP-Nachrichten als Nutzlast für den Dokumentenaustausch.
Heute haben Sie verschiedene E-Business-Metaphern kennen gelernt, die XML- Technologien verwenden. Die meisten davon stellen eine Möglichkeit für Kommerz- Transaktionen dar, sie zu verpacken und über das Internet durch das HTTP-Protokoll zu übertragen. Es wurden verschiedene Szenarien für B2C- und B2B-Applikationen vorgestellt, ebenso wie die zu Grunde liegenden Motivationen. Man erwartet, dass Unternehmen in der Zukunft wesentliche Investitionen in XML-Technologien für die Verwendung in E-Commerce tätigen werden.
Frage:
Wie kann XML für Daten-Aggregations-Sites verwendet werden?
Antwort:
XML unterstützt strukturierte Steuerelemente und intelligenten Datenspeicher.
XML ist für Umgebungen geeignet, in denen sich die Formate von Quelldaten
unterscheiden, aber zu einer strukturierten Ausgabe kombiniert werden, die in
variablen Formaten für Benutzer-Agenten und Informationskonsumenten
dargestellt werden muss.
Frage:
Wie kann XML-basierte Lieferkettenverwaltung Geschäftsmodelle verbessern?
Antwort:
Elektronische Steuerelemente auf einem Marktplatz für die Verwaltung einer
Lieferkette erhöht die Geschwindigkeit und die Genauigkeit des relevanten
Geschäfts. Der Fluss der Geschäfts-Transaktionen kann durch die
Automatisierung überwacht und verbessert werden.
Frage:
Wo finde ich weitere Informationen über SOAP-Implementierungen für B2B-
Transaktionsverarbeitung?
Antwort:
Sie finden viele gute Informationsquellen im Web wie beispielsweise bei:
Frage:
Auf welchen Standards basiert SOAP?
Antwort:
SOAP basiert auf HTTP 1.0 und höher und kann das HTTP Extension
Framework (http://www.w3.org/Protocols/HTTP/ietf-http-ext) nutzen. SOAP
basiert außerdem auf der XML-Empfehlung (http://www.w3.org/TR/1998/REC-
xml-19980210). SOAP unterstützt die W3C XML-Namensraum-Empfehlung
(http://www.w3.org/TR/REC-xml-names). SOAP-Nutzlasten müssen korrektes XML
darstellen, aber es ist keine Überprüfung (über DTDs oder anderweitig)
erforderlich. Die Verwendung von XML-Schemata (http://www.w3.org/TR/
xmlschema-1/), um SOAP-Endpunkte zu beschreiben, wird im Moment in
Betracht gezogen, ist aber noch nicht formaler Teil der SOAP/1.0-Spezifikation.
Frage:
Warum sollte ein Entwickler SOAP statt einer benutzerdefinierten XML/HTTP-Lösung
verwenden?
Antwort:
SOAP bietet wesentliche Vorteile gegenüber einem benutzerdefinierten
proprietären XML-Vokabular. Die zunehmende Unterstützung der Hersteller von
SOAP durch vollständige Lösungen verbessert die allgemeine Implementierung
dieser Technologien. Bald werden Client- und Server-Applikationen für die
meisten Industriezweige bereitstehen und es werden Modelle entwickelt, die
technische und Effizienzvorteile bieten.
Frage:
Welche Einschränkungen weist SOAP auf?
Antwort:
SOAP sagt nichts zur bidirektionalen Kommunikation, obwohl es möglich ist,
diese Semantik auf der SOAP-Implementierung aufzusetzen. Die aktuelle SOAP-
Spezifikation beschreibt, wie die SOAP-Nutzlast über HTTP übertragen wird, sagt
aber nichts über andere Protokolle.
Frage:
Weil SOAP über HTTP übertragen wird, passiert es die meisten Firewalls. Stellt dies eine
neue Sicherheitsbedrohung dar?
Antwort:
SOAP ist nur eine Nutzlast, die über HTTP übertragen werden kann. Sie ist also
nicht weniger sicher als jede andere HTTP-Übertragung. Darüber hinaus haben
die Entwickler von SOAP die Einbindung von Programmieranweisungen in das
SOAP-Protokoll verboten, um mögliche Sicherheitsprobleme zu unterbinden.
Weil SOAP-Pakete HTTP-Header-Daten beinhalten, können die zukünftigen
Firewalls so erweitert werden, dass sie die Übertragungen aufgrund der Header-
Daten zu filtern in der Lage sind. Wie alle anderen HTTP-Übertragungen
unterstützt SOAP die Verwendung von SSL (Secure Socket Layers) und
ähnlichen Authentifizierungsschemata.
