Alexander-Jung.NET
 Home  Veröffentlichungen Downloads Historie Site Site-Map

XML – Schlüsseltechnologie für moderne Softwarearchitekturen

(Alexander Jung, Veröffentlicht in OBJEKTspektrum 1/2001)

Die "eXtensible Markup Language" (XML) hat sich in relativ kurzer Zeit einen festen Platz in der Softwareentwicklung erobert. Aufgrund ihrer Eigenschaften findet man XML heute insbesondere dort, wo Technologiegrenzen zu überwinden sind. Als Grundlagentechnologie innerhalb der Middleware ist XML jedoch noch (zu) wenig verbreitet. Mit dem .NET Framework und der zunehmenden Konkretisierung des WebService-Konzepts tut sich aber bereits einiges auf diesem Gebiet.

Betrachten wir zunächst kurz wie XML heute eingesetzt wird. Zum einen gibt es einen Grundstock an sehr allgemeinen Technologien die auf XML basieren sowie XML erweitern, z.B. XSL Transformations, XML Schema und XPath ("XML Path Language"). In vielen spezifischen Problembereichen halten darüber hinaus zunehmend XML-basierte Standards Einzug; als Beispiel sei hier nur SOAP ("Simple Object Access Protocol") genannt. Aus Sicht einer Drei-Schichten-Architektur ist da zunächst der Client-Bereich, in dem XML aufgrund seiner Verwandtschaft zur "HyperText Markup Language" (HTML) sehr früh eingesetzt wurde. Dort werden in der Regel XML-Daten nach HTML, WML ("Wireless Markup Language") oder zukünftig XHTML aufbereitet; XSL ("Extensible Stylesheet Language") geht für die Präsentation der Daten noch erheblich weiter.

Daneben gibt es den Datenbankbereich, in dem die Hersteller zunehmend dazu übergehen, XML-basierte Schnittstellen zur Verfügung stellen. Beim "World Wide Web Consortium" (W3C) existiert eine Arbeitsgruppe, die sich nur mit dem Thema Abfragesprachen in XML befaßt. XPath ist ein Ableger von XQL ("XML Query Language"), einem frühen Ansatz einer solchen Abfragesprache.

Als drittes wäre der Bereich Datenaustausch mit fremden Systemen zu nennen - der Bereich also, der für B2B-Lösungen eine besondere Bedeutung hat. Hier spielen Ansätze, wie sie "BizTalk", "WebMethods" oder der "SAP Business Connector" verfolgen, eine wichtige Rolle. Allerdings wird XML oft nur punktuell eingesetzt, und der Bereich der Middleware fehlt vollständig. XML spielt nur an den Schnittstellen eine Rolle - im Inneren des Middle-Tiers einer Internet-Anwendung dagegen nicht. Da bedeutet, an den Grenzen liegt jeweils ein Technologiebruch vor. XML-Daten müssen ausgepackt und auf die Funktionen des jeweiligen Systems umgesetzt werden, die Ergebnisse werden wieder in XML verpackt. Die Verarbeitung selbst wird nach wie vor mit den herkömmlichen Mechanismen der Middleware bewerkstelligt (siehe Abb. 1). Die grundsätzlichen Fragen in diesem Zusammenhang lauten: Muß das so sein? Ist es wirklich notwendig, XML auf Objekte und Komponenten abzubilden, indem dort der Zustand (Status) gesetzt, Funktion aufgerufen und Parameter übergeben werden? Nur, um hinterher das Ergebnis wieder aus dem Zustand und den Funktionswerten herauszulesen und zurück nach XML zur transformieren?


Abb. 1: Die verbreitete Arbeitsweise bei der Softwarearchitektur: geprägt von monolithischem Aufbau innerhalb des Middle-Tiers und unterschiedlichsten Programmierschnittstellen, die direkt bedient werden müssen.

XML als Schlüsseltechnologie in der Middleware

Wenn XML schon an allen Schnittstellen verwendet wird, dann ist es nur konsequent, XML auch durchgängig innerhalb der Middleware einzusetzen. Anstatt die XML-Daten an den Grenzen zu transformieren, werden sie einfach an die Komponenten weitergereicht. Die Logik in Form von Komponenten bearbeitet nicht mehr Daten, die in ihren eigenen - z.B. als COM-Properties abgelegten - Zustandsinformationen bereit stehen. Stattdessen beläßt sie die Zustandsverwaltung im XML-Dokument und führt auch dort ihre Manipulationen durch. Darüber hinaus wird die so erzielte Kapselung des Zustands verwendet, um diesen als das XML-Dokument en bloc verwalten zu lassen. Zustandslose Komponenten werden dadurch sehr einfach realisierbar.

Hinzu kommt: Die (über eine 3-Tier-Architektur hinausgehende) Schichtenbildung innerhalb des Middle-Tiers wird deutlich herausgebildet und klar nach Zuständigkeiten und Verantwortlichkeiten gegliedert (siehe Abb. 2). Diese Vorgehensweise ist prinzipiell auf alle komponentenorientierten Middleware-Technologien anwendbar. Im Folgenden wird jedoch ausschließlich auf Microsoft-Technologien Bezug genommen.


Abb. 2: XML wird durchgängig eingesetzt und bildet so das Rückgrat der Architektur. Das Schichtenmodell kann nach Bedarf weiter ausgebaut werden.

Vereinfachung der Zustandsverwaltung

Eine unmittelbare praktische Auswirkung: Die XML-Daten fließen vom Frontend durch die Middleware bis hin zum Zugriff auf die Datenhaltung – und zwar ohne Unterbrechung. Auch wenn das XML-Dokument auf diesem Weg diversen Veränderungen unterliegen kann, erhält man dadurch einen durchgängigen Fluß von XML-Daten: XML übernimmt also die Rolle eines Datenbusses. Neben Auswirkungen auf das Anwendungsdesign führt dies zu einer radikalen Vereinfachung der Zustandsverwaltung. Gerade die Forderung nach Zustandslosigkeit ist ein heikles Thema, wenn es um mehrschichtige Anwendungen geht, die auf Skalierbarkeit, Durchsatz und Transaktionssicherheit hin entwickelt werden. Wo bleibt also der Zustand? Ist der Client in der Lage, die XML-Daten zu verwalten, so kann er den Server von dieser Aufgabe komplett entlasten.
Ist dies aufgrund der Randbedingungen nicht möglich, so kann der Zustand ohne weitere Verarbeitung an die Datenhaltung übergeben und ebenso einfach wieder hergestellt werden. Vergleicht man dies mit der üblichen Abbildung der Daten auf (oft genug redundante) Datenstrukturen in Form verschiedener Datenbanktabellen, so ergibt sich hier quasi von selbst eine sehr elegante – Lösung.

Es gibt noch weitere unmittelbare Auswirkungen, die sicher nicht ohne Bedeutung sind, aber hier nur kurz angedeutet werden sollen: Ein wichtiger Punkt ist die Tatsache, daß sich die Parameterlisten der funktionalen Schnittstellen im wesentlichen auf die Übergabe eines XML-Dokumentes reduzieren. Außerdem sollte erwähnt werden, daß der durchgängige Einsatz von XML auch dem Übergang in andere Systeme zugute kommt, weil sich XML dort nicht mehr als aufgesetzte Lösung darstellt. Das ist ein Umstand, den sich Ansätze wie BizTalk bereits zu Nutze machen.

XML als „Generalschlüssel“

Die bisher angesprochene Vereinfachung der Zustandsverwaltung mag kein ausreichendes Argument sein, eine ganze Softwarearchitektur auf völlig neue Beine zu stellen. XML stellt jedoch einen Schlüssel für unterschiedlichste Bereiche des kompletten Softwareentwicklungsprozesses dar. Einige Beispiel werden im Folgenden vorgestellt.

Ausprägung der Schichtenarchitektur

Innerhalb der Middleware liegt normalerweise aus Architektursicht keinen monolithischen Block vor. Stattdessen versucht man auch dort üblicherweise einen Schichtenaufbau zu realisieren. Mögliche Schichten könnten etwa sein:

Im Microsoft-Umfeld findet man oft die Situation, daß der clientseitige Teil sich zum Teil auf Active Server Pages, zum Teil auf COM+-Komponenten verteilt, während auf die Datenbank in der Regel direkt aus der Geschäftslogik via ADO ("ActiveX Data Objects") zugegriffen wird. Das heißt, es kommt zu Vermischungen und verwaschenen Grenzen zwischen logischen und physikalischen Schichten.

Nun könnte man denken, daß der durch XML vereinfachte Übergang an den äußeren Schnittstellen die Schichtenarchitektur weiter aufweicht und die Lage noch verschlechtert. Das genaue Gegenteil ist der Fall. Die Tatsache, daß der Übergang zwischen verschiedenen Schichten durch XML derart vereinfacht wird, macht es sehr viel leichter, zusätzliche Schichten in die Architektur einzuziehen, klare Verantwortlichkeiten zuzuteilen und die Schichten ebenso klar voneinander abzugrenzen.

Auswirkungen auf die Qualität

Durch die klare Ausprägung der Schichtenarchitektur einerseits und XML-basierte Schnittstellen andererseits wird es sehr viel einfacher, abgeschlossene Testumgebungen aufzubauen. Jede Schicht nimmt von der Nachbarschicht ein XML-Dokument entgegen und liefert ein solches als Antwort zurück. Die Schnittstellendefinition reduziert sich fast ganz auf die Definition der Struktur. Man kann also eine Entwicklungs- und Testumgebung schaffen, die XML-Daten an eine Komponente übergibt und hinterher das Ergebnis mit vorgegebenen Ergebnisdaten, ebenfalls XML, vergleicht.

Nimmt diese Komponente die Dienstleistung einer anderen Schicht in Anspruch, so läßt sich das ähnlich leicht mit vorgefertigten XML-Daten simulieren. Konsequent umgesetzt führt das dazu, daß der Black-Box-Test integraler Bestandteil des Entwicklungsprozesses wird. Bei organisatorischen Ansätzen werden die Tests oft nachträglich aufgesetzt, sie veralten nach einer gewissen Zeit oder - noch schlimmer - fallen gleich ganz dem Termindruck zum Opfer. Insofern ist die starke Integration des Black-Box-Testes in den Entwicklungsprozeß ist ein nicht zu verachtender Vorteil und Qualitätsgarant.

Vorteile für Projektteams

Oft ist bei Implementierung einer mehrschichtigen Anwendung ein Entwickler für einen vollständigen Ablauf – quer durch alle Schichten – verantwortlich. Doch Generalisten sind selten, teuer, und es gibt immer Spezialisten, die in ihren Teilbereichen besser sind. Wie im obigen Abschnitt ausgeführt, lassen die klare Ausprägung der Schichtenarchitektur und XML-basierte Schnittstellen es zu, sehr isolierte Entwicklungsumgebungen aufzubauen. Dadurch lassen sich Entwickler gezielter für einzelne Bereiche schulen. Dadurch wird das Problem zwar auch nicht ganz gelöst (irgendwie muß das Know-how ja im eigenen Team aufgebaut werden), aber doch zumindest stark entschärfen.

Einige weitere Bereiche, auf die sich das Verfahren positiv auswirkt, seien an dieser Stelle noch kurz erwähnt, ohne näher darauf einzugehen:

Sicherheit und Performance

Neben all den Vorteilen muß man sicher die Frage stellen, welche Probleme sich durch dieses Vorgehen ergeben. Da XML ein textbasiertes Format ist, sind zwei Punkte besonders zu beachten: Sicherheit und Performance.

Sicherheit tritt als Problem in erster Linie an Systemgrenzen auf. Hier hat das Verfahren jedoch keine Änderung gegenüber der etablierten Vorgehensweise gebracht. Besondere Aufmerksamkeit ist allerdings dann erforderlich, wenn die XML-Daten zusätzliche Aufgaben übernehmen sollen. Performance könnte als Problem angesehen werden, wenn man den Speicherbedarf eines XML-Dokumentes und den darüber hinaus notwendigen Aufwand des XML-Parsers – Speicher und Rechenzeit – in Rechnung stellt und dies mit herkömmlichen, für die jeweiligen Gegebenheiten optimierten Mechanismen vergleicht. Dem kann man jedoch entgegen halten, daß dieser Ressourcenbedarf auch bei der etablierten Vorgehensweise anfällt - nämlich dann, wenn an den Schichtenübergängen XML produziert oder konsumiert wird. Lediglich die zeitliche Verteilung der Ressourcennutzung ist eine andere. Für den hier vorgeschlagenen Weg sprechen aber zusätzlich zwei Dinge: Zum einen entfällt der relativ rechenintensive Vorgang des Parsens bzw. Erzeugens der XML-Struktur durch den XML-Parser. Zum anderen gibt es eine große Auswahl von Parsern am Markt, so daß man sich dort anhand der Randbedingungen Ressourcenbedarf (Speicher, Rechenzeit) und benötigte Funktionalität für einen geeigneten Parser entscheiden kann.

Erstes Fazit: XML und Middleware

XML bietet unbestreitbare Vorteile und hat in vielen Teilbereichen der Softwareentwicklung Einzug gehalten. Mit diesem Artikel sollte aufgezeigt werden, daß XML auch im Bereich der Middleware eine Schlüsseltechnologie mit hohem Potential darstellt. XML konsequent in dieser Form einzusetzen hat seine Tauglichkeit in unterschiedlichen Projekten bewiesen. XML ist allgemein genug, um an verschiedenste Randbedingungen angepaßt zu werden, und nicht an Technologien gebunden. Die Auseinandersetzung mit diesem Thema ist den Aufwand also durchaus wert. In unserem Haus ist dieses Vorgehen mittlerweile ein etablierter Standard geworden. Sowohl hausinterne als auch externe Projekte, bei denen wir als Softwarearchitekten oder beratend tätig waren, ließen sich damit erfolgreich realisieren.

Zweites Fazit: Die Welt dreht sich

Dieser Artikel ist ein gutes Beispiel für die Schnellebigkeit im Softwaregeschäft. In seineer ersten Fassung Anfang 2001 veröffentlicht, ist zum jetzigen Zeitpunkt (Ende 2001) ein kleines "Update" notwendig - ein kurzer kritischer Rückblick:

Da wäre zunächst die Frage, ob sich das Konzept auch über längere Zeit hinweg als tragfähig erwiesen hat. Dies ist definitiv zu bejahen. Insbesondere die größeren Freiheitsgrade bei der Teamstruktur und Arbeitsorganisation zahlten sich immer wieder aus. Und in einem Extremfall hat uns diese Vorgehensweise geradezu den Hals gerettet, als mitten im Projekt das gesamte Frontend aus fachlichen Gründen vom Kopf auf die Füße gestellt werden mußte. Mit "herkömmlichen" Methoden hätten wir das Projekt an dieser Stelle stoppen müssen. Es zeigte sich aber auch, daß die Fähigkeiten von XML sehr unterschiedlich genutzt wurden. Je komplexer das Projekt, desto mehr verwandte Technologien (XML Schema, Namespaces etc.) werden benötigt, und desto mehr "Grips" mußte auf das Design der XML-Daten verwendet werden. Der "one size fits all"-Ansatz funktioniert hier genausowenig wie in anderen Bereichen.

Wenn das also alles so tragfähig ist, würde ich den Artikel heute in genau derselben Form schreiben? Vermutlich nicht. Und schuld an dieser Aussage sind zwei (für Leser dieses Magazins drei, siehe unten) wesentliche neue Entwicklungen des letzten Jahres: Zum einen das Microsoft .NET Framework, zum anderen die zunehmende Konkretisierung von XML WebServices.

Das .NET Framework ist eine sehr stark an XML orientierte neue Entwicklungsplattform. Ein zentraler Bestandteil des Frameworks ist ADO.NET und dessen Kernkomponente, das DataSet. Zwar merkt man dem DataSet seine enge Beziehung zu relationalen Datenbanken an, gleichzeitig bietet es jedoch über XmlDataDocument eine rein XML-basierte Schnittstelle. Aber (ein dickes aber!) der Komfort, der sich aus dieser Mächtigkeit ergibt, kommt nicht ganz umsonst. Bestimmte Dinge, die sich mit reinem XML recht elegant lösen lassen, kann man nicht eins zu eins in das Korsett eines DataSets pressen. So ist dieser Aufbau des DataSets zwar einerseits eine hervorragende Bestätigung des Konzepts, andererseits beschneidet es die Möglichkeiten von XML teilweise recht stark. Diesen Widerspruch aufzulösen ist derzeit bei uns "work in progress".

Und wie beeinflußen XML WebServices das Bild? Abseits von einigen Fehlinterpretationen, die sich oft recht schnell bereinigen lassen (XML WebServices, das ist SOAP, damit habe ich XML... ), wird gerade durch XML WebServices das gängige Bild von einzelnen Applikationen als Insellösungen deutlich erweitert. Klassische Integration, anwendungsübergreifende Geschäftsprozesse, verteilte Anwendungen, peer-to-peer-Networking, Portale usw. - alle diese Dinge bekommen durch XML WebServices mehr Schwung und rücken deutlicher ins Blickfeld. Damit werden Konzepte notwendig, wie diese Dinge in der Architektur zu verankern sind. Und diese gehen über die reine Beschreibung der Daten weit hinaus.

Der versprochene dritte Punkt ist eigentlich (zumindest konzeptionell) ein Spezialfall des zweiten: Der Microsoft SQL Server erhielt eine erste XML-Schnittstelle, das nächste große Release soll sich als reinrassige XML-Datenbank präsentieren. Mit der jetzigen Implementation sind zumindest erste Gehversuche möglich. Die dabei gemachten Erfahrungen über Möglichkeiten und Unzulänglichkeiten - momentane wie prinzipielle - sind nicht nur gültig für den SQL Server selbst, sondern auch Indiz für die Potentiale und Herausforderungen von XML WebServices allgemein.

Alles in allem: Das Bild trägt nach wie vor, aber der Farbton ändern sich ständig. In Zukunft muß womöglich der Rahmen neu gesteckt oder gar ganz ersetzt werden. Im Grunde nichts neues in der Softwareentwicklung, richtig?

Alexander Jung (e-Mail: Alexander.Jung@newline-software.net infoAlexander-Jung.NET) arbeitet als Managing Developer bei der NEW LINE Software Development GmbH. Er hat dort Teamverantwortung und beschäftigt sich mit dem Einsatz von XML in der Middleware (Windows DNA, Microsoft .NET), XML WebServices und den Auswirkungen auf Architektur und Projektorganisation. Herr Jung ist auch Co-c_autor der Buchs „.NET Crashkurs“, erschienen bei Microsoft Press.

Dieser Artikel basiert im Wesentlichen auf einem Beitrag, den Alexander Jung für die Zeitschrift "OBJEKTspektrum" verfaßt hat. Wir danken dem Verlag SIGS-DATACOM (www.sigs-datacom.de) für die freundliche Unterstützung.

Kontakt: infoalexander-jung.net top Letzte Änderung: 27.08.2005 23:31:17