XML als Integrationstechnologie bei Informationsanbietern im Internet; XML-based integration for Internet publishers — the case of BertelsmannSpringer;

XML als Integrationstechnologiebei Informationsanbieternim InternetFallstudie bei BertelsmannSpringer

1 Einleitung

Die Komplexitat beim Bereitstellen von In-ternet-Angeboten wachst in der Medien-industrie bereits seit Jahren u. a. durch diezunehmende Menge der Inhalte (bei gleich-zeitiger Zunahme der inhaltlichen Ver-knupfungen) sowie Tendenzen zu einerverstarkten Individualisierung. Nicht zu-letzt fuhren auch haufige �nderungen amLayout und an den Navigationsstrukturenzu hohen Aufwanden. In der Medien-industrie (und nicht nur dort) ist daher einmassiver Trend zum Einsatz sog. Content-Management-Systeme zu beobachten[ScHe99; RaHe01b], die ihren funktionalenSchwerpunkt auf die arbeitsteilige Planung,Erzeugung, Gestaltung sowie das Publizie-ren von digitalen Inhalten im Internet le-gen. Der Begriff der Inhalte (engl. Con-tents) umfasst die Menge aller redaktionellerzeugten bzw. ausgewahlten Informati-onselemente (meist Texte und Bilder, aberauch Animationen sowie Video- und Au-diosequenzen), die gebundelt und an dieRezipienten abgegeben werden.

Der alleinige Fokus auf die umfassendeVerwaltung von Inhalten greift aber zukurz, da die Web-Angebote durch einewachsende Anzahl interaktiver Applika-tionen erganzt werden [RaHe01a]. Alsweitverbreitete Beispiele seien Diskussi-onsforen, Chat, Suchmaschinen undShops genannt. Aus Sicht der Medien-industrie stellt daher die Bereitstellungdieser Anwendungen und deren Integrati-on in vorhandene Content-Management-Systeme eine aktuelle Problemstellungdar.

Als weiterer Trend im Zusammenhang mitden Internet-Angeboten der Medienindus-trie ist die Zunahme des zwischenbetriebli-chen Handels mit digitalen Inhalten, dassog. Content Syndication, zu beobachten[Hess01]. Hierbei ist es eine besondere He-rausforderung, Contents moglichst auto-matisiert bereitzustellen und in unter-schiedliche Angebote zu integrieren.

Hersteller von Content-Management-Sys-temen bieten zum Zwecke der Einbindungvon Fremdprogrammen diverse Mechanis-men, die z. B. auf APIs oder speziellenKonnektoren beruhen. Konnektoren sindSchnittstellen, welche die Komplexitat derAnbindung eines definierten Fremdpro-gramms vor dem Anwendungsentwicklerverbergen [RuMB01]. Viele Content-Man-agement-System-Anbieter verfugen u. a.uber Konnektoren zu verbreiteten Shop-Systemen wie beispielsweise Intershop. Ei-ne derartige Integration ist aus der tech-nischen Perspektive immer dann besondersunproblematisch, wenn die zu integrieren-den Systeme auf einer gemeinsamen Basis-technologie beruhen (z. B. der Java 2Enterprise Edition). In praktischen An-wendungsfallen (wie im vorliegendem Fall-beispiel) sehen sich Systemintegratorenjedoch haufig mit einer großeren Hetero-genitat konfrontiert.

In der jungsten Zeit ist die Integration vonApplikationen mithilfe der eXtensible Mar-kup Language (XML) in den unterschied-lichsten Anwendungsdomanen verstarkt inden Mittelpunkt der Diskussion geruckt[Hass00; Morg00; MoFo01]. XML ist einevom W3C standardisierte Metasprache zurDefinition von Auszeichnungsgrammati-

WIRTSCHAFTSINFORMATIK 44 (2002) 1, S. 19–28

Die Autoren

Joachim RawolleJochen AdeMatthias Schumann

Dipl.-Wirtsch.-Inf. Joachim Rawolle,Institut fur Wirtschaftsinformatik,Abt. II, Georg-August-UniversitatGottingen, Platz der GottingerSieben 5, 37073 Gottingen,Tel. (05 51) 39-73 31,E-Mail: [email protected];Dipl.-Kfm. Jochen Ade,BertelsmannSpringer Science & Busi-ness Media, Schluterstr. 42,10707 Berlin, Tel. (0 30) 8 87 26-1 60,E-Mail: [email protected];Prof. Dr. Matthias Schumann,Institut fur Wirtschaftsinformatik,Abt. II, Georg-August-UniversitatGottingen, Platz der GottingerSieben 5, 37073 Gottingen,Tel. (05 51) 39-44 42,E-Mail: [email protected]

WI – Aufsatz

ken [BPSM00; BoEn99; Tolk99]. Anwen-dungsentwickler und Integratoren wer-den bei der Verwendung von XMLdurch erganzende Standards (z. B. Trans-formationssprachen, Abfragesprachenund Programmierschnittstellen) sowiefrei verfugbare Werkzeuge (z. B. Parser)unterstutzt.

Vor diesem Hintergrund ist es Ziel des vor-liegenden Beitrags, die Unterstutzungsleis-tung von XML als Integrationstechnologieim Rahmen des Content-Managements inder Medienindustrie anhand eines Fallbei-spiels zu untersuchen, welches in Koope-ration zwischen der BertelsmannSpringerGmbH in Berlin und der Universitat Got-tingen, Abt. Wirtschaftsinformatik II,durchgefuhrt wurde. Dazu beschreibt Ab-schnitt 2 die Rahmenbedingungen des Pro-jektes. Anschließend geht Abschnitt 3 aufdie vorliegende Integrationsproblematikein, bevor Abschnitt 4 die auf XML basie-renden Integrationsmechanismen vorstellt.In Abschnitt 5 wird diese Problemlosungkritisch gewurdigt. Den Abschluss des Bei-trags bildet Abschnitt 6 mit einer Zusam-menfassung der wesentlichen Erkenntnisse.

2 Rahmenbedingungen

2.1 BertelsmannSpringerScience&Business Media(BSSBM)

Die BertelsmannSpringer-Gruppe umfasstmehrere Fachverlage und Online-Dienstesowohl aus dem wissenschaftlichen alsauch aus dem Business-to-Business-Be-reich und ist Teil des Bertelsmann-Kon-zerns. Zu den bekanntesten Verlagen derGruppe zahlen der Springer Verlag (Hei-delberg/Berlin), die GWV Fachverlage (da-zu gehoren u. a. Gabler, Vieweg und West-deutscher Verlag in Wiesbaden), der VerlagHeinrich Vogel (Munchen), die HeinzeGmbH (Celle) sowie der Verlag Bertels-mann Fachzeitschriften (Gutersloh).

Außerdem betreibt BertelsmannSpringermehrere Online-Dienste, die u. a. Inhalteder Verlage zielgruppenspezifisch bundelnund daher als Aggregatoren aufzufassensind [Hess99; HeSc99]. Hierzu gehorendas BauNetz (www.baunetz.de), Lifeline(www.lifeline.de), Multimedica (www.mul-timedica.de), LINK (link.springer.de) unddas TransportWeb (www.transportweb.de).

Zusatzlich zu den Inhalten aus den zu Ber-telsmannSpringer gehorenden Verlagenwurden weitere Inhaltezulieferer als Part-ner gewonnen. Insgesamt liegt die Anzahlder internen und externen Kooperations-partner zwischen 5 und 25 pro Online-Dienst. Zudem generieren die Online-Dienste einen signifikanten Anteil eigenerInhalte. Insgesamt erreicht die Gruppe ca.15 Millionen Page-Impressions pro Monat(Stand: Fruhjahr 2001).

2.2 Projektanstoß

BertelsmannSpringer erwartete zum Zeit-punkt des Projektstarts im Fruhling 1999erhebliche Veranderungen der Wett-bewerbsbedingungen fur Fachinformati-onsanbieter im Internet. Zu den wichtigs-ten Herausforderungen gehorten nachAuffassung der Verantwortlichen folgendeAspekte:

– Zunehmende Wettbewerbsintensitat (so-wohl durch neue Konkurrenten als auchdurch eine aggressive Erweiterung undVermarktung bestehender Konkurrenz-angebote)

– Entwicklung neuer Vertriebskanale(z. B. Content und Application Syndica-tion [Hess01] und mobile Endgerate[RaHe00])

– Ausbau der bestehenden, uberwiegendinhalteorientierten Angebotsformen(z. B. Zunahme der Inhalte, Zunahmeder inhaltlichen Verknupfungen und zu-nehmende Individualisierung der Inhal-te)

– Entwicklung neuer Angebotsformen(z. B. kommunikationsorientierte Ange-bote, transaktionsorientierte Angeboteund applikationsorientierte Angebote)

– Wirtschaftliche Nutzung neuer Tech-nologien (z. B. Zahlungssysteme undStreaming) und wachsende Leistungs-fahigkeit bestehender Technologien(z. B. Netzwerkinfrastruktur, Hard-ware, Systemsoftware, Programmier-sprachen etc.)

Eine im Herbst 1999 durchgefuhrte Ist-Analyse der BSSBM enthullte, dass dieOnline-Dienste DV-technisch nicht ausrei-chend auf die neuen Herausforderungenvorbereitet waren. Als wesentlicherSchwachpunkt wurde identifiziert, dass einGroßteil der Inhalte in statischen HTML-oder PDF-Dokumenten vorlag. Eine wirt-schaftliche Mehrfachverwendung der In-halte z. B. uber Syndication oder neue

Endgerate sowie der Einsatz von Indivi-dualisierungsmechanismen war daher sehrstark eingeschrankt. Auch der Schnelllebig-keit des Mediums in Bezug auf eine zeitge-maße Darstellung konnte aufgrund derSchwerfalligkeit der herkommlichenHTML-Programmierung nicht Rechnunggetragen werden. Als zweiter Problem-bereich wurde die Applikationsentwick-lung erkannt, die von den Diensten mitden verschiedensten Werkzeugen vor-genommen wurde. Als Programmierspra-chen kamen uberwiegend Perl, PHP undLivewire zum Einsatz, die Verwendungvon Servlets und anderen Java-basiertenTechnologien befand sich lediglich im Pla-nungsstadium. Die Integration der beste-henden Anwendungen untereinander warnur schwach ausgepragt. Auch die Wieder-verwendung von Applikationen in mehre-ren Diensten wurde kaum praktiziert.

Insgesamt waren die DV-technischen Rah-menbedingungen also durch Insellosungenund mangelnde Automatisierungsmoglich-keiten in der Bereitstellung gekennzeich-net. Der hohe Anteil manueller Tatigkeitenin den operativen Prozessen verursachteQualitatseinbußen sowie hohe Aufwandein Bezug auf Kosten und Zeit. Daruber hi-naus wurden teure personelle Ressourcenin der Technikabteilung gebunden.

Um die Online-Dienste technologisch aufdie oben angefuhrten Aufgaben vorzube-reiten, wurde daher ein Projekt aufgesetzt,das die Schaffung einer flexiblen, modula-ren Plattform fur alle Online-Dienste derBertelsmannSpringer-Gruppe zum Zielhatte. Ausgangspunkt war die Auswahl,Beschaffung und Implementierung einesgemeinsamen Content-Management-Sys-tems, an das zusatzliche Applikationen(z. B. Shop-Systeme, Diskussionsforenetc.) uber unkomplizierte Schnittstellen an-gebunden und von mehreren Diensten ge-nutzt werden sollten.

Innerhalb der BertelsmannSpringer-Grup-pe wurde Lifeline als Pilotprojekt aus-gewahlt, da der Dienst vor Projektbeginnnoch uber keinerlei DV-technische Unter-stutzung fur das Content-Managementverfugte und ein relativ gut strukturierterBestand an Inhalten vorlag. Auch dieAnzahl und Komplexitat der externen Ap-plikationen bewegte sich in einem be-herrschbaren Rahmen. Lifeline ist ein end-kundenorientierter Online-Dienst imBereich Gesundheit und Wellness. Im Wei-teren beschreibt der Beitrag die bei Lifeline


20 Joachim Rawolle, Jochen Ade, Matthias Schumann

vorliegende Integrationsproblematik undskizziert die im Projekt realisierten Lo-sungsvarianten in Auszugen. Das Gesamt-system ist seit November 2000 produktiv,im Marz 2001 wurden ca. 4,5 Millionen Pa-ge-Impressions erreicht.

3 Integrationsproblematik

3.1 Ziele und Anforderungen

Die Integrationsproblematik bei Lifelineumfasste zwei wichtige Bereiche: einerseitsdie Integration von bestehenden Anwen-dungen und andererseits die zwischen-betriebliche Anbindung von Content-Lie-feranten und Abnehmern. Ziel derIntegrationsbemuhungen war es, stabil lau-fende Applikationen und Schnittstellen(auch in mehreren Diensten) in moglichsthohem Maße wieder zu verwenden und soEntwicklungskosten, -zeit und -risiken zusenken. Eine derartige Wiederverwendungerforderte eine klare Trennung zwischenPrasentation, Inhalt und Anwendungslogik[KeKi01] im Sinne des „Separation of Con-cerns“ [Dijk76]. Zusatzlich sollte einemoglichst lose Kopplung der Anwendun-gen [RuMB01] eine hohe Flexibilitat ge-wahrleisten und es beispielsweise gestatten,einzelne Komponenten wie etwa das Fo-rensystem oder die Suchmaschine im Be-darfsfall durch neuere Standardsoftware-produkte auszutauschen. Die verwendetenMechanismen sollten weiterhin eine hohePlattformunabhangigkeit aufweisen (z. B.im Hinblick auf Betriebssystem, Program-miersprache und Middleware) und mog-lichst geringe Anforderungen an die zu in-tegrierenden Applikationen stellen. Derletztgenannte Aspekt war insbesondere vordem Hintergrund zu sehen, dass eine Reihevon bestehenden Anwendungen in Skript-sprachen wie Perl und PHP vorlagen, furdie eine Moglichkeit zur Integration ge-schaffen werden musste. Schließlich solltenInhalte und langfristig auch Funktionenuber das Internet fur Partner verfugbar ge-macht werden (Stichwort Syndication).

Aus der Entwicklerperspektive war dieVerwendung einer weit verbreiteten undweitgehend standardisierten Schnittstellen-technologie mit ausreichender Werk-zeugunterstutzung erwunscht, um dieBeherrschbarkeit zu gewahrleisten, beste-hendes Know-how bei den Entwicklernund Dienstleistern verwerten und Lernkur-

veneffekte ausnutzen zu konnen. Weiterge-hende Anforderungen, wie sie in modernenMiddleware-Architekturen weit verbreitetsind und zu denen u. a. Ortstransparenzvon Funktionalitaten, Transaktionalitat,komplexe Kommunikationsmechanismen(wie z. B. Broadcasting oder Publish& Sub-scribe) sowie Security-Mechanismen geho-ren [Bern96; RiVo96; Tres96; Sera99],waren lediglich von untergeordneter Be-deutung.

Aus der Perspektive des Betriebs standenPerformanz, Robustheit und Skalierbarkeitals wichtigste Anforderungen im Vorder-grund. Mit Blick auf die Skalierbarkeit warunter anderem das Verhalten der Schnitt-stellen bei hohen Benutzerzahlen und beivariablen Dokumentenlangen von beson-derem Interesse.

3.2 Architektur

Bild 1 gibt einen idealisierten �berblickuber die Systemarchitektur bei Lifeline

und soll nachfolgend genauer beschriebenwerden. Den Kern des Gesamtsystems bil-det ein Content-Management-System(CMS) auf Basis des Vignette Content-Management-Servers (www.vignette.com),dessen Teilkomponenten in der Abbildungdunkelgrau gekennzeichnet sind. Der Vig-nette Content-Management-Server ist einContent-Management-spezifischer Appli-kationsserver und bietet daher Entwick-lungs- und Laufzeitumgebungen furContent-Management-Anwendungen. AlsSkriptsprache kommt bei Lifeline die ToolCommand Language (TCL) zum Einsatz,in neueren Versionen des Vignette CMSwerden aber alternativ auch Java Server Pa-ges (JSP) und Active Server Pages (ASP)unterstutzt.

Alle Inhalte werden uber das Browser-ge-stutzte Redaktionssystem erfasst und imContent Repository (basierend auf Oracle8i) in Form von XML-Fragmenten abge-legt. Da beim Entwurf der XML-DTDsauf Layout-orientierte Elemente und Attri-bute weitgehend verzichtet wurde, bleibtdie Trennung von Inhalt und Prasentation


Kernpunkte fur das Management

Der Beitrag untersucht die Unterstutzungsleistung von XML fur die Integration von Inhaltenund Anwendungen bei Informationsanbietern im Internet anhand eines Fallbeispiels aus derMedienindustrie.

& XML zeigt seine Starken insbesondere im Hinblick auf die Systemarchitektur (z. B. Platt-formunabhangigkeit, Internetfahigkeit, Flexibilitat usw.).

& Schwachen von XML wurden im Projekt u. a. in den Bereichen Performanz, Robustheitund Realisierungsaufwand deutlich.

Stichworte: XML, Integration, Internet, Content-Management, Medienindustrie

Tabelle 1 Anforderungen an die Integrationslosung

Systemarchitektur Separation of Concernslose KopplungPlattformunabhangigkeitgeringe Anforderungen an zu integrierende AnwendungenInternet-Fahigkeit

Entwicklung weite Verbreitungausreichende Werkzeugunterstutzungwirtschaftliche und zeitnahe Realisierbarkeit

Betrieb PerformanzRobustheitSkalierbarkeit

XML als Integrationstechnologie 21

gewahrt. Die Contents sind daher mehr-fach verwertbar: Sie werden einerseits uberdie Prasentationsschicht fur die Rezipien-ten bereitgestellt und lassen sich anderer-seits flexibel fur Content-Abnehmer ausdem System exportieren. Auch die Verwer-tung uber alternative Endgerate ist zukunf-tig denkbar, wurde bislang allerdings nichtrealisiert.

Neben dem Content-Management-Systemverfugt Lifeline uber eine Reihe von inter-aktiven Internet-Applikationen, die z. T.Eigenentwicklungen darstellen (wie z. B.eine �rztesuche) oder auf Standardsoftwa-re basieren (wie z. B. die Suchmaschine,der Ad-Server sowie das Chat- und Foren-system). Gemaß der Vorgaben waren dieseuber generische Schnittstellen in das Con-tent-Management-System einzubinden.Auf den Import von Fremdinhalten unddie Integration eines Werkzeugs zur Nut-zeranalyse, die ebenfalls Teil des Projektswaren, soll nachfolgend nicht weiter einge-gangen werden.

3.3 Schnittstellen

Im Rahmen des Projektes mussten unter-schiedliche Schnittstellen realisiert werden,auf die an dieser Stelle kurz eingegangensei. Mit Blick auf die technischen Aspekteder Integration wird in der Literatur be-reits seit langem zwischen daten- undfunktionsorientierter Integration sowie ei-ner Integration an der Benutzeroberflacheunterschieden [Heil89; Krcm91]. Die Da-tenintegration ermoglicht die Kopplungvon Anwendungssystemen uber den Aus-tausch oder die gemeinsame Nutzung von

Datenbestanden. Technische Grundlagedafur sind gemeinsame Dateiformate undin jungerer Zeit einheitliche Datenbank-schnittstellen. Neben der technischenKompatibilitat ist auch die semantischeKompatibilitat der Datenstrukturen vongroßer Bedeutung, um eine konsistenteVerarbeitung zu gewahrleisten.

Ziel der Funktionsintegration ist es dage-gen, verschiedene Applikationen auch ubergegenseitige Funktionsaufrufe miteinanderzu koppeln. Die neuesten Entwicklungengehen dabei in Richtung verteilter Objekt-und Komponentenmodelle [Wesk99;Hopk00; Ortn00].

Die Integration an der Benutzerschnittstel-le verbirgt unterschiedliche Systeme hintereiner einheitlichen Benutzeroberflache,wobei eine darunter liegende Kommunika-tion der betroffenen Anwendungen nichterforderlich ist.

Bei Lifeline mussten alle drei Varianten derIntegration realisiert werden. In Web-ba-sierten Angeboten ist die Integration ander Benutzerschnittstelle am einfachsten zurealisieren, z. B. uber Referenzen auf ver-teilte Ressourcen innerhalb eines HTML-Dokumentes (im Projekt zur Einbindungder Banner eingesetzt) oder uber Framesets(im Projekt zur Einbindung des Chats).Bei dieser Integrationsform bietet XMLkeine Unterstutzungsleistung, weshalbnicht weiter darauf eingegangen werdensoll.

Zu den datenorientierten Schnittstellen, dieinnerhalb des Projektes realisiert wurden,gehoren z. B. die Schnittstellen zwischenContent Repository und Suchmaschine,

Foren und Suchmaschine, der Export furSyndication-Kunden sowie der Import derFremdinhalte. Beispielhaft sei die Schnitt-stelle zwischen Suchmaschine und ContentRepository erlautert (vgl. Bild 1). DieSuchmaschine indexiert die Inhalte des ge-samten Angebotes in festgelegten Interval-len [MaVo98; Tura98]. Dazu greift sie nicht– wie bei Internet-Suchmaschinen all-gemein ublich – uber die Prasentations-schicht auf die Inhalte zu, sondern auf Da-teien, die uber eine Schnittstelle aus demCMS exportiert werden und durch weiter-gehende Metadaten angereichert sind. Die-se Metadaten konnen spater im Rahmender erweiterten Suchfunktionalitat als Fil-terkriterien verwendet werden, ohne aufder Prasentationsseite sichtbar zu werden.Ein weiterer Vorteil ist in der besserenKontrollierbarkeit der zu indexierendenInhalte zu sehen. Bestimmte Bereiche kon-nen z. B. vor der Suchmaschine verborgenwerden oder es konnen zusatzliche Inhaltemit aufgenommen werden, die uber dienormale Navigation nicht erreichbar sind(z. B. Archive oder formulargestutzte Da-tenbankabfragen). Ferner lassen sich dieContents von Schmuckelementen (z. B.Logos), Navigationsleisten, Bannern undTeasern trennen, sodass die Qualitat derTreffer bei Suchanfragen tendenziell erhohtwird.

Zu den funktionsorientierten Schnittstellengehoren die Verbindungen der Prasentati-onsschicht zum Forensystem, zur Such-maschine und zu einigen Individualent-wicklungen. So stellt das Forensystembeispielsweise eine Reihe von Funktions-aufrufen zu Verfugung, die von anderen,ggf. entfernten Programmen aus nutzbarsind und von denen das Anlegen, Anzei-gen, Loschen und Bearbeiten von Foren-beitragen genannt seien. Alle funktionsori-entierten Schnittstellen arbeiten beiLifeline synchron, d. h. das aufrufendeProgramm wartet mit der Weiterverarbei-tung so lange, bis eine Antwort des auf-gerufenen Systems vorliegt. Es gelten da-her insbesondere bei den interaktivenAnwendungen, die zu Spitzenzeiten untersehr starker Last stehen, hohe Anforde-rungen an die Performanz und Skalierbar-keit der Schnittstellen. Als weiteres Cha-rakteristikum der Schnittstellen seiangefuhrt, dass es sich jeweils um relativeinfache Client/Server-Anfragen handelt(Request/Reply), die mit Ausnahme desForensystems zustandslos sind. Broad-cast- oder Publish & Subscribe-Mechanis-men waren nicht Teil des Projektes.


Fremd-

inhalte

Ad-

Server

Chat Foren Individual-

software

Nutzer-

analyse

Such-

maschine

Präsentationsschicht für EndkundenExportschnittstelle für

Syndication-Kunden

Redaktions-

system

Content- und

System DB

Bild 1 Komponenten und Schnittstellen im Pilotprojekt Lifeline


4 Einsatz von XML

4.1 Funktionsweiseder Schnittstellen

Zur Realisierung der relevanten Schnitt-stellen wurden verschiedene Integrations-technologien untersucht und unter Beruck-sichtigung der in Abschnitt 3.1 definiertenZiele und Anforderungen evaluiert. Zu denbetrachteten Ansatzen gehorten u. a.CORBA, RMI, RPC, Message-oriented-Middleware sowie XML-gestutzte Mecha-nismen. Plattformabhangige Ansatze wieMicrosoft DCOM wurden von vornhereinausgeschlossen. Vor dem Hintergrund,dass bei den BertelsmannSpringer Online-Diensten uberwiegend Skriptsprachen zumEinsatz kamen und weiterhin mit einembreiten Einsatz von Perl, PHP, TCL undsogar CFML zu rechnen ist (auch wennkomplexe Anwendungen zukunftig in Javarealisiert werden sollen) wurde XML alsuniverselles Austauschformat festgelegt.Als wesentliche Vorteile von XML wurdendie Einfachheit, die Flexibilitat und dieweitreichende Unterstutzung in Skript-sprachen angesehen. Weitere Aspekte, diefur den Einsatz von XML in der vorliegen-den Problemstellung sprachen, waren diePlattformunabhangigkeit und eine nochimmer zunehmende Verbreitung. Fernerverfugten die Entwickler des Content-Ma-nagement-Systems, welches die zentrale,integrative Komponente des Gesamtsys-tems darstellt, uber eine reichen Erfah-rungshintergrund bei der Behandlung vonXML, welcher nicht zuletzt aus der Imple-mentierung des XML-basierten ContentRepository stammte.

Da XML uber keinen eigenen Transport-mechanismus verfugt, mussten diesbezug-lich erganzende, schnittstellenspezifischeFestlegungen getroffen werden. Im Hin-blick auf das Anwendungsprotokoll fiel dieWahl fur die meisten Schnittstellen aufHTTP, da die anzubindenden Applikatio-nen bereits ausnahmslos uber eine nativeHTTP-Schnittstelle verfugten – bei Web-basierten Anwendungen ist eine solcheSchnittstelle auch zukunftig als selbstver-standlich anzusehen. Ein weiterer Grund,der zum Einsatz von HTTP gegenuber al-ternativen Protokollen fuhrte, war die Ab-sicht, Funktionen und Inhalte auch alsDienstleistung an Partner uber das Internetanzubieten (z. B. im Falle des ContentSyndication oder der Suchmaschine). Fa-vorisiert wurde daher die HTTP-gestutzte

Losung, die mit bestehenden Firewall-Sys-temen ohne Konfigurationsanderungen ar-beitet und deshalb kundenseitig keine Si-cherheitsbedenken auslost. Die mit HTTPverbundenen Nachteile wie z. B. Zustands-losigkeit, mangelnde Sicherheit (insbeson-dere im Sinne der Verlasslichkeit) oder diefehlende Unterstutzung von Transaktionenwurden dabei bewusst in Kauf genommen.

Weiterhin verfugt XML als Metasprachezur Definition von Dokumentstrukturenuber keinerlei Semantik in spezifischenAnwendungsdomanen. Daher ist es furXML-gestutzte Integrationsvorhaben not-wendig, die Menge der in der gegebenenProblemstellung benotigten Elemente undAttribute, ihre hierarchische Anordnungsowie ihre Bedeutung festzulegen. Zumin-dest im Hinblick auf die Anordnung vonElementen und Attributen bietet XML inForm von so genannten Document TypeDefinitions (DTDs) Unterstutzung. ImProjekt wurden daher alle auszutauschen-den Dokumenttypen als DTD modelliert,wahrend die zugehorige Semantik der Ele-mente und Attribute separat dokumentiertwurde (zu neueren Ansatzen vgl. auch Ab-schnitt 5.2).

Wie in Abschnitt 3.3 erlautert, ist mit Blickauf die Implementierung zwischen daten-und funktionsorientierten Schnittstellen zuunterscheiden. Die datenorientiertenSchnittstellen beruhen bei Lifeline uber-wiegend darauf, dass die Daten bzw. Inhal-te von den anbietenden Anwendungen inForm von XML-Dokumenten unter defi-nierten URLs verfugbar gemacht werdenund uber HTTP-GET von den empfangen-den Applikationen abgerufen werden kon-nen. Im Falle eines zwischenbetrieblichenInhalteaustauschs steht hierbei die Verstan-digung uber eine gemeinsame XML-Gram-matik in Form einer DTD und die damitverbundene Semantik im Vordergrund.

Fur die Ausgestaltung von funktionsorien-tierten Schnittstellen mit XML uber HTTPist prinzipiell zwischen rein XML-basier-ten Funktionsaufrufen und Antworten so-wie Hybridlosungen zu differenzieren, beidenen der Aufruf uber HTTP-POST bzw.HTTP-GET erfolgt und nur die Antwortdie Form eines XML-Dokumentes an-nimmt. Beide Ansatze sind in der Praxisbereits etabliert: Der erstgenannte Ansatzwird u. a. von XML-Protokollen wie etwaSOAP [BEKþ00] oder XML-RPC [Wi-ne99] verfolgt, wahrend die hybride Lo-sung u. a. im Rahmen des eCo-Frame-

works des CommerceNet favorisiert wird[Comm99].

Als wesentlicher Vorteil von reinen XML-Protokollen ist zu sehen, dass die Kom-munikation grundsatzlich unabhangig vomAnwendungsprotokoll bleibt und auchuber SMTP, FTP oder sogar physische Da-tentrager erfolgen kann. Als Nachteil er-weist sich allerdings die Tatsache, dassserverseitig ein spezieller Dispatcher imple-mentiert werden muss, der den XML-ko-dierten Aufruf entgegennimmt, interpre-tiert und an die Anwendung weiterreicht.Da die Unabhangigkeit vom Anwendungs-protokoll in der vorliegenden Problemstel-lung keine Anforderung war und der mitder Verarbeitung eines XML-gestutztenAufrufs verbundene Overhead zu unnoti-gem Ressourcenverbrauch gefuhrt hatte,wurde auf die hybride Losung zuruck-gegriffen.

Das hierbei zugrunde liegende Prinzipskizziert Bild 2. Der Benutzer ruft eineURL in der Prasentationsschicht auf, dieeventuell erforderlichen Parameter werdenper HTTP-POST oder -GET ubermittelt.Die Prasentationsschicht analysiert denAufruf und generiert ggf. einen HTTP-Re-quest an eine (oder mehrere) Applikatio-nen. Die aufgerufene Applikation antwor-tet mit einem XML-Dokument, das einervereinbarten Grammatik gehorcht. DiePrasentationsschicht transformiert dasXML in ein HTML-Fragment, erganzt esum weitere Komponenten (z. B. Navigati-onsleisten, Teaser, Banner etc.) und gibt dasvollstandige HTML-Dokument an denClient zuruck. Abschnitt 4.2 beschreibt dieKopplung zwischen der Prasentations-schicht und der Suchmaschine als Beispielfur eine einfache, funktionsorientierteSchnittstelle.


Client

Präsentationsschicht

Applikation

HTTP

GET/POST

HTTP

GET/POST

HTML

XML

Client

Präsentationsschicht

Applikation

HTTP

GET/POST

HTTP

GET/POST

HTML

XML

Bild 2 Einsatz von XML bei der funk-tionsorientierten Integration


4.2 Anbindung der Such-maschine als Beispielfur eine funktionsorientierteSchnittstelle

Lifeline bietet den Rezipienten im Rahmendes Angebotes eine Suchmaschine, mit dersie innerhalb der von Lifeline gepflegtenInhalte nach Stichwortern suchen konnen.Ferner werden bereichsorientierte Ein-schrankungen unterstutzt (Suche in Lexi-ka, Suche in Diskussionsforen) sowie eine„Livesuche“, mit der Benutzer beobachtenkonnen, nach welchen Suchbegriffen ande-re Anwender derzeit suchen. Die Nutzungder Suchmaschine erfolgt im einfachstenFall uber ein Eingabefeld, welches sich aufallen Lifeline-Seiten wieder findet, oderuber ein Formular mit erweiterten Mog-lichkeiten.

Wie in Abschnitt 4.1 erlautert, werden An-fragen uber mehrere Ebenen verteilt. Aufder Prasentationsschicht wird die Anfragevon einem TCL-Skript entgegengenom-

men und analysiert. Wenn alle Such-parameter korrekt sind, ruft das Skript dieSuchmaschine uber eine definierte URLauf, wobei die benotigten Parameter (z. B.der Suchbegriff) uber HTTP mitgegebenwerden. Die Suchmaschine auf Basis desAltavista Search Development Kits ist hin-ter einer stabilen Schnittstelle gekapselt, diein Java Server Pages (JSP) von einem aufSuchmaschinen spezialisierten Dienstleisterrealisiert wurde. Diese zusatzliche Abs-traktion war notwendig, um einen direktenAufruf proprietarer Schnittstellen zu ver-meiden. Die Java Server Page wandelt dieAnfrage in die Altavista-spezifische Syntaxum, aktiviert die Suchmaschine und gibtdie Trefferliste (bzw. den relevanten Aus-schnitt aus der Trefferliste) in Form einerXML-Datei an die Prasentationsschichtzuruck. Bild 3 zeigt einen vereinfachendenAuszug aus einer Beispieldatei, der denprinzipiellen Aufbau illustrieren soll. Imoberen Teil des Dokumentes finden sichabfragebezogene Elemente, z. B. Zeitpunktund Suchparameter. Das Element „Re-sults“ enthalt ausschnittsbezogene Anga-

ben zur Trefferliste (beispielsweise die Sei-tennummer bei langen Trefferlisten mitmehreren Seiten) und die als „Hit“ be-zeichneten Fundstellen. Zu jeder Fundstel-le werden u. a. Angaben zur URL, einAuszug aus dem Text des Dokumentes so-wie eine Reihe von dokumentbezogenenMetadaten (z. B. Titel, Autor, Thema usw.)ubertragen.

Die Prasentationsschicht wandelt dieXML-kodierte Trefferliste mithilfe vonTCL nach HTML um und erganzt die Sei-te um die ublichen Navigations- undSchmuckelemente, Banner und Teaser. Diefur den Nutzer sichtbare Reprasentationzeigt Bild 4.

5 Erfahrungen

5.1 Systemarchitektur

Im Hinblick auf die Systemarchitekturwurde die Trennung von Inhalt, Logik undLayout (Separation of Concerns), einemoglichst lose Kopplung der beteiligtenSysteme, die Plattformunabhangigkeit, ge-ringe Anforderungen an die zu integrieren-den Anwendungen und die Moglichkeitder Kommunikation mit externen Partnernuber das Internet gefordert (vgl. Abschnitt3.1). Die in Abschnitt 4 skizzierte, uber-wiegend auf XML und HTTP basierendeSchnittstellentechnologie soll im Folgen-den diesbezuglich kritisch gewurdigt wer-den.

Separation of Concerns

Eine Trennung von Inhalt, Logik und Lay-out ist mit XML-basierten Schnittstellengrundsatzlich machbar, allerdings kein Au-tomatismus. Um im vorliegenden Fallbei-spiel insbesondere das Layout von den In-halten zu trennen, sind entsprechendeVorkehrungen in den XML-DTDs zu tref-fen, wie etwa der prinzipielle Verzicht aufLayout-orientierte Elemente und Attribu-te. Wie die Erfahrung im Projekt zeigt, istdieses Ideal nicht immer erreichbar. Ins-besondere bei aufwandigerem Layout ist esgelegentlich nicht moglich (bzw. wirt-schaftlich), aus rein strukturellem odersemantischem Markup die gewunschte vi-suelle Reprasentation zu erzeugen. Bei-spielsweise unterscheidet das Lifeline-Layout zwischen unterschiedlichenTabellenvarianten. Die Auswahl einer Va-riante durch den zustandigen Redakteur er-


[...]<Resultpage>

<Timestamp>2001-08-20 16:28:00</Timestamp>[...]<QueryParameters>

<q>+kreislauf</q>[...]

</QueryParameters><Results>

<PageCount>1</PageCount><AccPageCount>1</AccPageCount><MaxHitsPerPage>10</MaxHitsPerPage>[...]<Hit>

<CurrentHitIndex>1</CurrentHitIndex><ID>1347</ID><Relevance>1.0</Relevance><URL>[...]</URL>[...]<Metatags>

<Title>Channel Ernährung</Title><Author/><Publisher>Lifeline</Publisher><Subject>Ernährung</Subject><Description>LIFELINE - Ernährung</Description>[...]

</Metatags><Text>... Special Omega-3-Fettsäuren Wussten Sie, dass es

bei den Eskimos so gut wie keine Herz-<emp>Kreislauf</emp>-Erkrankungen gibt? Der Grund: die Ernährung. Sie ist reichan Omega-3-Fettsäuren. ... </Text>

</Hit><Hit>[...]</Hit>

</Results></Resultpage>

Bild 3 XML-kodierte Trefferliste


folgt dabei nach rein asthetischen Gesichts-punkten und wird innerhalb des XML-Dokumentes als Layout-orientiertes Attri-but mitgefuhrt, sodass die strikte Trennungzwischen Inhalt und Form an dieser Stelleaufgehoben ist. Dennoch bewirkt XMLdurch die flexible Gestaltung von Doku-mentstrukturen und der separierten Defini-tion von Gestaltungsregeln in Stylesheets(beispielsweise XSLT bzw. XSL/FO) oderSkripten eine deutliche Verbesserung derSituation im Vergleich zu Auszeichnungs-sprachen mit festgelegter, Layout-orientier-ter Elementmenge (z. B. HTML).

Kopplung

Gleichsam wird die lose Kopplung durchXML-basierte Schnittstellen nicht auto-matisch erreicht. Daher muss als zusatz-liches Designziel gelten, „generische“Schnittstellendefinitionen vorzunehmen,die neben der Trennung von Layout, Logikund Inhalten eine moglichst hohe Unab-hangigkeit des Gesamtsystems von einzel-nen Komponenten gewahrleisten. Alle imProjekt definierten Schnittstellen erlaubengrundsatzlich die Bedienung weiterer On-line-Dienste ohne Umprogrammierung dereingebundenen Applikationen und verein-fachen daher die Wiederverwendung. Auchist der Austausch von Anwendungen zukalkulierbaren Aufwanden moglich, wurdeim Projekt allerdings noch nicht prakti-ziert.

Plattformunabhangigkeit

Sowohl XML als auch HTTP konnen furden praktischen Einsatz als plattform-unabhangig bezeichnet werden (Plattform-unabhangigkeit stellte ein explizites De-signziel bei der Entwicklung von XML dar[BPSM00]). Im vorliegenden Beispielkonnten Anwendungssysteme, die mit denunterschiedlichsten Technologien und Pro-grammiersprachen entwickelt wurden, er-folgreich integriert werden. Eine Bindungan proprietare Middleware oder Betriebs-systeme wurde ebenso vermieden.

Anforderungen an zu integrierendeAnwendungen

Die Anforderungen an die zu integrieren-den Applikationen bestehen bei den imProjekt realisierten Schnittstellen im We-sentlichen in der Unterstutzung vonHTTP als gemeinsames Anwendungspro-tokoll sowie der Erzeugung von XML-Dokumenten. HTTP wurde von allen An-wendungen standardmaßig unterstutzt und

die Erzeugung von XML-Dokumentenkonnte durch eine einfache Umprogram-mierung der verwendeten Templates vonHTML- auf XML-Tags erreicht werden.Verallgemeinernd sei an dieser Stelle fest-gehalten, dass prinzipiell alle Applikatio-nen, die eine hinreichend flexible Pro-grammierung der Ausgabe-Templateserlauben, an die beschriebenen XML-ba-sierten Schnittstellen angebunden werdenkonnen.

Die Prasentationsschicht als Integrations-punkt musste daruber hinaus auch dieVerarbeitung und Transformation vonXML-Dokumenten unterstutzen. DieseAnforderung wurde durch den in den Vig-nette Content-Management-Server inte-grierten XML-Prozessor in Kombinationmit TCL ebenfalls erfullt.

Internet-Fahigkeit

Ein Problem, welches in der Praxis relativhaufig einer zwischenbetrieblichen Integra-tion im Internet-Bereich entgegensteht, istdie Verwendung von proprietaren Pro-tokollen, die eine Umkonfiguration beste-hender Sicherheitsregeln in Firewalls derbeteiligten Kommunikationsparteien erfor-dert. Ein wesentlicher Vorteil der im Pro-jekt gewahlten Mechanismen ist daher da-rin zu sehen, dass durch den Einsatz vonHTTP als Anwendungsprotokoll ein Ein-griff in bestehende Security-Systeme i. d.

R. nicht notwendig ist. Als weitere Vorteilebeim zwischenbetrieblichen Austausch vonInhalten oder der Nutzung von Web-Diensten kommen zusatzlich die loseKopplung sowie die Trennung von Inhal-ten und Layout zum Tragen, die eine flexi-ble Gestaltung seitens des Abnehmers er-lauben.

Zusammenfassend sei an dieser Stelle fest-gehalten, dass die Anforderungen in Bezugauf die Systemarchitektur mithilfe derXML- und HTTP-basierten Schnittstellen-technologie ausreichend erfullt werdenkonnten. Wie in Folgeprojekten beispiels-weise im Falle der Suchmaschine bereitsnachgewiesen werden konnte, ist insbeson-dere eine unkomplizierte Wiederverwen-dung der Anwendungen uber die be-schriebenen Schnittstellen grundsatzlichmoglich. Die dazu notwendige Trennungvon Layout und Inhalt sowie die loseKopplung der Anwendungen an das Ge-samtsystem mussten allerdings durch zu-satzliche konzeptionelle �berlegungen si-chergestellt werden und waren keinesfallsXML-immanent.

5.2 Entwicklung

Mit Blick auf die Entwicklungstatigkeitenwurde eine Schnittstellentechnologie mit


Von XML nach HTML

transformierte

Trefferliste

Bild 4 Trefferliste im Lifeline-Layout


weiter Verbreitung und ausreichenderWerkzeugunterstutzung sowie eine wirt-schaftliche und zeitnahe Realisierbarkeitgefordert.

Verbreitung

Es kann davon ausgegangen werden, dassXML und HTTP als Basistechnologien furdie Integration von Anwendungen im in-ner- und zwischenbetrieblichen Bereichauch aufgrund der in Abschnitt 5.1 ge-nannten Vorzuge weit verbreitet sind[Morg00; MoFo01]. Bei den Entwicklernwar daher (von Ausnahmen abgesehen)ausreichendes XML-Know-how gegeben,auch wenn aus anderen Projekten relativwenig Erfahrungen vorlagen.

Werkzeugunterstutzung

Zu den im Projekt erforderlichen Werk-zeugen gehorten insbesondere XML-Par-ser, Editoren und Entwicklungsumgebun-gen fur DTDs. Die Erfahrungen mit denverwendeten Tools waren gemischt. Dieverschiedenen am Projekt beteiligtenDienstleister verwendeten z. T. unter-schiedliche Werkzeuge, was in Einzelfallenuberraschenderweise zu Inkompatibilitatenfuhrte, da sich einige Parser nicht hundert-prozentig an die XML-Spezifikation hiel-ten (von ahnlichen Erfahrungen berichtetu. a. auch [Krug01]). Insgesamt ist in die-sem Bereich in absehbarer Zeit mit einerBesserung der Situation zu rechnen.

Realisierungsaufwand

XML verfugt uber einige Eigenschaften,die zu Beginn des Projektes als aufwands-verringernd eingeschatzt wurden. Dazu ge-hort zum einen, dass XML ein Klartext-format ist, welches von Entwicklernunproblematisch gelesen und verstandenwerden kann. Dieses Merkmal vereinfachteu. a. das Debugging der Schnittstellen er-heblich. Durch die zusatzliche Bindung derSchnittstellen an HTTP konnten die Ent-wickler außerdem relativ einfache, browser-gestutzte Testumgebungen aufbauen.

Zum anderen lassen sich die Dokument-strukturen fur die auszutauschendenNachrichten formal im Rahmen einer Do-cument Type Definition (DTD) festlegen.Die Einhaltung der vereinbarten Struktu-ren kann uber validierende Parser unkom-pliziert kontrolliert werden. Einschran-kend sei an dieser Stelle jedoch festgehalten,dass herkommliche DTDs nicht alle Anfor-derungen zur Definition der Dokument-

strukturen im Projekt erfullen konnten.Als Beispiel sei die Festlegung von ein-fachen Typen fur Elemente und Attributegenannt (z. B. Integer, String, Date etc.),die zusatzlich zur Definition der DTD imDV-Konzept vorgenommen werden muss-te. Das W3C hat diesen Mangel bereits seitlangerem erkannt und die weitaus machti-geren XML Schemata kurzlich als Recom-mendation [Fall01] verabschiedet (zu Be-ginn des Projektes war XML Schemaallerdings von einer Standardisierung nochweit entfernt und konnte daher nicht zumEinsatz kommen). Zu den wichtigstenNeuerungen zahlen die Unterstutzung ein-facher Datentypen, Erweiterung der Aus-drucksmoglichkeiten fur Kardinalitaten(z. B. minimale und maximale Anzahl vonKindelementen), Einfuhrung einer XML-basierten Syntax sowie Mechanismen zurWiederwendung und Dokumentation vonXML-Grammatiken.

Wie die Erfahrungen aus dem Projekt zei-gen, muss bei der Abschatzung des Reali-sierungsaufwandes fur XML-basierte Inte-grationsvorhaben berucksichtigt werden,ob es sich bei den einzubindenden An-wendungen um einfache, zustandsloseDienste (z. B. Suchmaschine) oder um zu-standsbehaftete Applikationen handelt, furdie ggf. auch Transaktionen zu unterstut-zen sind (z. B. Forensystem). Da wederXML noch HTTP Zustande oder Trans-aktionen kennen, steigern derartige Anfor-derungen den Realisierungsaufwand in ho-hem Maße.

Insgesamt wurde der Realisierungsauf-wand fur die Integration der Anwendun-gen uber HTTP und XML zu Beginn desProjektes unterschatzt. Neben technischenFaktoren wie etwa den nicht ausgereiftenXML-Werkzeugen sind dafur auch pro-jektspezifische Umstande verantwortlich:So mussten auf der personellen Ebene furjede der Schnittstellen zwei Dienstleisterbeschaftigt werden (ein Dienstleister furdas CMS und ein Dienstleister fur die ein-zubindende Applikation). Diese organisa-torischen Grenzen erschwerten die Kom-munikation zwischen den Entwicklern, diehaufig auch raumlich entfernt arbeiteten.

5.3 Betrieb

Im Zusammenhang mit dem Betrieb warenPerformanz, Robustheit und Skalierbarkeitdie wichtigsten Anforderungen im Projekt.

Performanz

Im Nachhinein muss die Performanz be-sonders der funktionsorientierten Schnitt-stellen als kritischer Punkt betrachtet wer-den. Zwei wichtige Gesichtspunkte sindhierbei zu nennen. Zum einen lagen dieZeiten, die das CMS zur Transformationvon komplexen XML-Dokumenten nachHTML benotigte, im Bereich von Sekun-den, sodass sich bei einigen Anwendungen,insbesondere den Diskussionsforen, unbe-friedigende Antwortzeiten ergaben. Furdie Zukunft soll daher mit alternativenTransformationsmechanismen wie z. B.XSLT [Clar99] experimentiert werden, diedie bislang verfolgte, TCL-gestutzte Lo-sung ersetzen. Zum anderen erwies sichHTTP als Bremse, da es sich hierbeigrundsatzlich um ein synchrones Protokollhandelt. Der aufrufende Prozess muss des-halb mit der Weiterverarbeitung so langewarten, bis eine Antwort des Servers inForm eines vollstandigen XML-Dokumen-tes vorliegt. Erst dann kann das Dokumentgeparst und transformiert werden. Eine Pa-rallelisierung dieses Vorgangs mit anderenAktivitaten zum Zusammensetzen derHTML-Seite ware durch Einsatz einesasynchronen Protokolls in dieser Problem-stellung vorteilhaft gewesen.

Robustheit

Auch die Robustheit der Schnittstellenkann nicht als optimal beurteilt werden.Dies hangt mit der in der XML-Spezifika-tion [BPSM00] festgelegten Eigenschaftvon XML-Parsern zusammen, bei jederArt von Fehler ohne ein Ergebnis abzubre-chen. Es mussten daher in den Anwendun-gen aufwandige Prufungen der Nutzerein-gaben, z. B. in Bezug auf Sonderzeichen,durchgefuhrt werden. Ein Beispiel soll dieProblematik verdeutlichen. Wenn ein An-wender in einem Forenbeitrag die Zeichen-kette „<hallo>“ verwendet, dann wirddieser Ausdruck vom XML-Parser alsStart-Tag eines Elementes interpretiert. Dakein korrespondierender End-Tag existiert,bricht der XML-Parser die Bearbeitung abund auf der Ausgabeseite erscheint ledig-lich eine Fehlermeldung. �hnlich gelagerteSpezialfalle ergeben sich im Zusammenhangmit scheinbaren Entities (z. B. „&hallo;“),die ebenfalls zu Schwierigkeiten beim Par-sen fuhren. Derartige Probleme werdenauch von anderen Projekten in der Litera-tur [IPSI01] berichtet und sind als ein prin-zipieller Schwachpunkt von XML-basier-ten Integrationsansatzen zu identifizieren.



Skalierbarkeit

Die Skalierbarkeit der Schnittstellen mussim Hinblick auf die Nutzer und die Langeder zu verarbeitenden XML-Dokumentesichergestellt sein. Die Anzahl der Zugriffeauf die Schnittstellen wurde von vornehe-rein durch den intensiven Einsatz von Ca-ching-Mechanismen minimiert. Insgesamtzeigt das System auch bei Lasttests keineAuffalligkeiten. Mit Blick auf die Langeder uber die Schnittstelle ubergebenenXML-Dokumente verhalt sich der Ver-brauch von Systemressourcen im relevan-ten Bereich nahezu linear, wie mithilfe vonMessungen nachgewiesen wurde. Die Ska-lierbarkeit kann daher als zufriedenstellendbezeichnet werden.

6 Fazit

Ziel des Beitrags war es, Moglichkeitenund Grenzen des Einsatzes von XML zurIntegration von heterogenen Anwendun-gen bei Informationsanbietern im Internetanhand einer Fallstudie aufzuzeigen. Dazuwurden eingangs wichtige Anforderungenan die zu realisierenden Schnittstellen defi-niert. Diese Anforderungen fuhrten zu derkonzeptionellen Entscheidung, die An-wendungsintegration fur das vorliegendeProjekt auf Basis von HTTP und XML zurealisieren. Die wichtigsten Erfahrungenseien an dieser Stelle noch einmal zusam-mengefasst:

– Erfahrungen im Hinblick auf die Sys-temarchitekturDie Anforderungen an die Systemarchi-tektur (z. B. Plattformunabhangigkeit,Internet-Fahigkeit usw.) konnten durchdie gewahlte Integrationstechnologie aufBasis von XML und HTTP zufrieden-stellend erfullt werden. Einschrankendsei allerdings betont, dass einige Aspekte(wie etwa die Trennung von Layout,Logik und Inhalten sowie eine loseKopplung der Anwendungen) keineXML-immanenten Eigenschaften dar-stellten, sondern nur uber eine sorgfalti-ge Spezifikation der DTDs erreichbarwaren.

– Erfahrungen im Hinblick auf die Ent-wicklungDie Realisierung von XML-basiertenSchnittstellen gestaltete sich aus Sichtder Entwickler als nicht unproblema-tisch. Insbesondere fuhrten inkompati-ble Werkzeuge und notwendige Vorkeh-

rungen zur Gewahrleistung derRobustheit zu erhohten Aufwanden.

– Erfahrungen im Hinblick auf den Be-triebWahrend des Betriebs zeigten sich ins-besondere Schwachen in Bezug auf diePerformanz und die Robustheit derXML- und HTTP-gestutzten Schnitt-stellen. Mit Blick auf die Skalierbarkeitwaren die Ergebnisse dagegen zufrie-denstellend.

Die Starken der vorgestellten Losung inBezug auf die Systemarchitektur belegendas Potenzial, das XML und HTTP im Zu-sammenhang mit inner- und zwischen-betrieblichen Integrationsprojekten bei-gemessen werden kann. Wie dieErfahrungen aber auch gezeigt haben, istder Reifegrad von XML und insbesonderevon XML-Werkzeugen zum jetzigen Zeit-punkt nicht notwendigerweise optimal.Hier ist aus Sicht der Anwenderunterneh-men auf zukunftige Verbesserungen zuhoffen.

Literatur

[BEKþ00] Box, D.; Ehnebuske, D.; Kakivaya, G.et al.: Simple Object Access Protocol (SOAP)1.1. W3C Note 2000. http://www.w3.org/TR/SOAP/, Abruf am 2001-04-28.

[Bern96] Bernstein, P.: Middleware: A Model forDistributed System Services. In: Communica-tions of the ACM 39 (1996) 2, S. 86–98.

[BoEn99] Bohnlein, M.; vom Ende, A. U.: XML –Extensible Markup Language. In: Wirtschafts-informatik 41 (1999) 3, S. 274–276.

[BPSM00] Bray, T.; Paoli, J.; Sperberg-McQueen,C. M.; Maler, E.: Extensible Markup Language(XML) 1.0 (Second Edition). W3C Recommen-dation 2000. http://www.w3.org/TR/REC-xml,Abruf am 2001-04-04.

[Clar99] Clark, J.: XSL Transformations (XSLT)Version 1.0. W3C Recommendation 1999.http://www.w3.org/TR/xslt, Abruf am2001-05-02.

[Comm01] CommerceNet, Inc.: The eCo-Specifi-cation. http://eco.commerce.net/specs/in-dex.cfm, Abruf am 2001-04-30.

[Dijk76] Dijkstra, E. W.: A Discipline of Program-ming. Upper Saddle River 1976.

[Fall01] Fallside, D. C.: XML Schema Part 0: Pri-mer. W3C Recommendation 2001. http://www.w3.org/TR/xmlschema-0/, Abruf am2001-05-03.

[Hass00] Hasselbring, W.: Information System In-tegration. In: Communications of the ACM 43(2000) 6, S. 32–38.

[Heil89] Heilmann, H.: Integration: Ein zentralerBegriff der Wirtschaftsinformatik im Wandel derZeit. In: HMD Praxis der Wirtschaftsinformatik26 (1989) 150, S. 46–58.

[HeSc99] Hess, T.; Schumann, M.: Medienunter-nehmen im digitalen Zeitalter – eine erste Be-

standsaufnahme. In: Schumann, M.; Hess, T.(Hrsg.): Medienunternehmen im digitalen Zeit-alter. Wiesbaden 1999, S. 1–18.

[Hess99] Hess, T.: Realization of Internet Servicesin a Media Company – the Case of BertelsmannProfessional Information. In: Electronic Markets9 (1999) 4, S. 278–283.

[Hess01] Hess, T.: Content Syndication. In: Wirt-schaftsinformatik 43 (2001) 1, S. 83–85.

[Hopk00] Hopkins, J.: Component Primer. In:Communications of the ACM 43 (2000) 10,S. 27–30.

[IPSI01] Projektgruppe IPSI: Endbericht der Pro-jektgruppe IPSI (Internet Portal System for In-surances). Universitat Dortmund 2001. http://ls10-www.cs.uni-dortmund.de/PGs/pg351/vor-stellung/ipsi-endbericht.pdf, Abruf am 2001-05-04.

[KeKi01] Kerer, C.; Kirda, E.: Layout, Contentand Logic Separation in Web Engineering. In:Murugesan, S.; Deshpande, Y.: Web Engineering2000. Lecture Notes in Computer Science 2016,Berlin, Heidelberg u. a. 2001, S. 135–147.

[Krug01] Kruger, C.: XML in der Client/Server-Architektur. In: Turowski, K.; Fellner, K.J.(Hrsg.): XML in der betrieblichen Praxis. Hei-delberg 2001, S. 115–133.

[Krcm91] Krcmar, H.: Integration in der Wirt-schaftsinformatik – Aspekte und Tendenzen. In:Jacob, H.; Becker, J.; Krcmar, H. (Hrsg.): Inte-grierte Informationssysteme. Wiesbaden 1991,S. 3–18.

[MaVo98] Masermann, U.; Vossen, G.: Such-maschinen und Anfragen im World Wide Web.In: Informatik Spektrum 21 (1998) 1, S. 9–15.

[MoFo01] Morgenthal, J. P.; la Forge, B.: Enter-prise Application Integration with XML andJava. Upper Saddle River 2001.

[Morg00] Morgenthal, J. P.: XML and the New In-tegration Frontier. In: EAI Journal 2 (2000) 3,S. 26–30.

[Ortn00] Ortner, E.: Komponentenorientierte An-wendungsentwicklung. In: Information Manage-ment & Consulting 15 (2000) 4, S. 62–72.

[RaHe00] Rawolle, J.; Hess, T.: New Digital Mediaand Devices – An Analysis for the Media Indus-try. In: Journal of Media Management 2 (2000) 2,S. 89–99.

[RaHe01a] Rawolle, J.; Hess, T.: Integrierte Me-dienprodukte – Grundlagen, Auspragungen undBeispiele. Arbeitsbericht Nr. 5/2001 der Abt.Wirtschaftsinformatik II der Universitat Gottin-gen, Gottingen 2001.

[RaHe01b] Rawolle, J.; Hess, T.: Content Manage-ment in der Medienindustrie – Grundlagen,Organisation und DV-Unterstutzung. Arbeits-bericht Nr. 6/2001 der Abt. Wirtschaftsinforma-tik II der Universitat Gottingen, Gottingen2001.

[RiVo96] Riehm, R.; Vogler, P.: Middleware: Infra-struktur fur die Integration. In: �sterle, H.;Riehm, R.; Vogler, P.: Middleware. Wiesbaden1996, S. 25–135.

[RuMB01] Ruh, W. A.; Maginnis, F. X.; Brown,W. J.: Enterprise Application Integration. NewYork u. a. 2001.

[ScHe99] Schumann, M.; Hess, T.: Content-Management fur Online-Informationsangebote.In: Schumann, M.; Hess, T. (Hrsg.): Medien-unternehmen im digitalen Zeitalter. Wiesbaden1999, S. 69–87.



[Sera99] Serain, D.: Middleware. 2. Aufl., London,Berlin u. a. 1999.

[Tolk99] Tolksdorf, R.: XML und darauf basieren-de Standards: Die neuen Auszeichnungssprachendes Web. In: Informatik Spektrum 22 (1999) 6,S. 407–421.

[Tres96] Tresch, M.: Middleware: Schlusseltech-nologie zur Entwicklung verteilter Informati-onssysteme. In: Informatik Spektrum 19 (1996)5, S. 249–256.

[Tura98] Turau, V.: Web-Roboter. In: InformatikSpektrum 21 (1998) 3, S. 159–160.

[Wesk99] Weske, M.: Business-Objekte: Konzepte,Architekturen, Standards. In: Wirtschaftsinfor-matik 41 (1999) 1, S. 4–11.

[Wine99] Winer, D.: XML-RPC Specification1999. http://www.xmlrpc.com/spec, Abruf am2001–04-28.


Abstract

XML-based integration for Internet publishers – the case of BertelsmannSpringer

This paper explores the use of XML for integrating content and applications for internet pub-lishers based on a case study from the media industry.After a short introduction into the general conditions of the project the paper describes themost important requirements that were to be met with regard to the interfaces between thecontent management system and a set of external, partly interactive applications (like asearch engine and discussion groups). Subsequently, a mechanism based on XML and HTTPis presented that was implemented as a solution within the scope of the project.Finally, experiences gained during the course of implementation and operation are con-fronted with the requirements as defined earlier in order to asses the strengths and weak-nesses of XML-based integration mechanisms in similar settings.

Keywords: XML, integration, Internet, content management, media industry


Documents

XML als Integrationstechnologie bei Informationsanbietern im Internet; XML-based integration for Internet publishers — the case of BertelsmannSpringer;