XML – Schlüsseltechnologie für 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 wenig verbreitet. Die Konsequenzen und Vorteile des Einsatzes von XML auch innerhalb der Middleware sind jedoch sehr weitreichend.

Betrachten wir zunächst kurz wie XML heute eingesetzt wird. Zum einen gibt es einen Grundstock an sehr allgemeinen auf XML basierenden sowie XML erweiternde Technologien. Beispiele hierfür sind

• XSL Transformations
• XML Schema
• 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.
Alles in allem hat XML damit eine sehr weite Verbreitung gefunden. Betrachtet man sich diese Aufzählung aber einmal genauer, so fällt zweierlei auf:

• XML wird nur punktuell eingesetzt, nicht durchgängig.
• Der Bereich der Middleware fehlt vollständig, XML spielt nur an den Schnittstellen eine Rolle.

Mit Schnittstellen sind hier Übergänge zu fremden Systemen gemeint, aber auch Übergänge zwischen den verschiedenen Schichten innerhalb der Architektur. Im Inneren des Middle-Tiers einer Internetanwendung spielt XML somit keine Rolle.
In der Konsequenz bedeutet dies, daß an den Grenzen jeweils ein Technologiebruch vorliegt. 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 *1 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 (wobei hier sowohl Grenzen zwischen den Schichten als auch Übergänge zu anderen Systemen gemeint sind). 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 - wenn möglich durch den Client, andernfalls durch die Datenhaltungsschicht. Zustandslose Komponenten werden dadurch sehr einfach realisierbar.
Dieses Vorgehen wird durch einen dritten Aspekt unterstützt: 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 (Roger Sessions verwendet den Begriff "COMWare"; vgl. http://www.objectwatch.com) angewendet werden. 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 ist folgende: 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. Anders ausgedrückt: XML übernimmt die Rolle eines Datenbusses. Neben Auswirkungen auf das Anwendungsdesign führt dies, wie bereits kurz angedeutet, 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 (z.B. in eine spezielle Datenbanktabelle geschrieben) 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 – man kann fast sagen eine natürliche – 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. Dieser Aspekt wurde ausführlich in [Wes00] behandelt. 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 et al bereits zu Nutze machen und durch den sich etwa COM+-basierte Anwendungen leichter mit EJB- oder auch Host-basierten Systemen integrieren lassen.

XML als „Generalschlüssel“ im Entwicklungsprozeß

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 sollen im Folgenden vorgestellt werden.

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:

• Clientseitige Logik: Prüfung der Eingabedaten des Anwenders, Prüfung der Berechtigung, Aufbereitung für das Frontend
• Geschäftslogik: Prozeßorientierter Teil für den Transaktionskontext, objektorientierter Teil für die Zustandsmanipulation
• Datenzugriff: abstrakte Schnittstelle, um Datenbankunabhängigkeit zu gewährleisten

Im Microsoft-Umfeld findet man oft die Situation, daß der clientseitige Teil sich zum Teil auf ASPs ("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. Ein sauberes Schichtenmodell erfordert unabhängig von der eingesetzten Technologie eine gute Planung, klare Definitionen und viel Disziplin bei der Umsetzung.

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. Die starke Ausprägung der Schichtenarchitektur wird dadurch erst möglich.
Das Ergebnis ist eine Schichtenarchitektur, die vergleichsweise feiner strukturiert ist und die Verantwortlichkeiten und die Rollenverteilung der Schichten deutlicher erkennbar regelt. Insgesamt wird es dadurch auch einfacher, sich bei der Umsetzung an diese Vorgaben zu halten.

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 (sei es als XML Schema oder auch „by Example“, d.h. mit vorgegebenen Referenz- und Testdaten). Man kann also eine Entwicklungs- und Testumgebung schaffen, die XML-Daten an eine Komponente übergibt und hinterher das Ergebnis mit vorgegebenen Ergebnisdaten, natürlich 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. (Der Begriff „Komponente“ kann in diesem Zusammenhang sehr frei interpretiert werden, dieses Verfahren greift auch bei einer ASP-Seite.)
Der Effekt ist, daß eine Komponente völlig frei von Effekten der benachbarten Schichten entwickelt und auch getestet werden kann. Konsequent umgesetzt führt das beschriebene Vorgehen dazu, daß der Black-Box-Test integraler Bestandteil des Entwicklungsprozesses wird (im Gegensatz zu anderen Ansätzen, wie dem "eXtreme Programming" (XP), die das auf rein organisatorischem Weg zu erreichen versuchen). Zusätzlich kann die Ablaufumgebung gesichert und der Test jederzeit – im Idealfall natürlich automatisiert - wiederholt werden. Dies hat natürlich nicht unwesentliche Auswirkungen auf die Qualität der Komponenten selbst. Aber auch die Qualität der Schnittstellendefinition (die ja letztlich durch die Testdaten in Form von XML gegeben ist) profitiert davon, da Unschärfen und die Seiteneffekte nachträglicher Änderungen durch automatisierte Test leichter erkannt und beseitigt werden können.
Bei organisatorischen Ansätzen stellt sich häufig die Situation, daß die Tests nachträglich aufgesetzt werden, nach einer gewissen Zeit veralten oder - noch schlimmer - gleich ganz dem Termindruck zum Opfer fallen. 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

Momentan herrscht bei der Implementierung einer mehrschichtigen Anwendung die Situation vor, daß ein Entwickler für einen vollständigen Ablauf – quer durch alle Schichten – verantwortlich ist. Er muß also, was die eingesetzten Technologien angeht, Generalist sein. Generalisten sind selten, teuer, und es gibt immer Spezialisten, die in ihren Teilbereichen besser sind. Zudem haben Entwicklungsabteilungen, die neu in diese Materie einsteigen müssen, das Problem, daß sie diese Generalisten einkaufen und über lange Zeit im Projekt halten müssen, bis sich die eigene Mannschaft das Know-how in der nötigen Breite und Tiefe erarbeitet hat.
Wie im Abschnitt vorher ausgeführt, lassen die klare Ausprägung der Schichtenarchitektur und XML-basierte Schnittstellen es zu, sehr isolierte Entwicklungsumgebungen aufzubauen. Durch diese Isolierung wird es sehr viel einfacher, Entwickler gezielt für einzelne Bereiche zu schulen, ohne daß sie im gleichen Maß wie im herkömmlichen Szenario die Technologien der angrenzenden Schichten beherrschen müßten. Dadurch läßt sich das Problem zwar auch nicht ganz lösen (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, sollen hier noch kurz aufgezählt werden, ohne sie jedoch näher zu beleuchten:

• Wiederverwendbarkeit der Komponenten
• Abstrahierbarkeit innerhalb der Schichten
• Isolierbarkeit der Schichten und Subsysteme (Seiteneffekte und technische Abhängigkeiten)
• Erweiterbarkeit
• Wartbarkeit
• Versionierbarkeit
• Bessere Planbarkeit und Organisation des Projektes

Sicherheit und Performance mit XML?

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. Ein Beispiel: Der Mechanismus der rollenbasierten und deskriptiven Verwaltung der Zugriffsberechtigungen im COM+-Dienst basiert auf COM-Schnittstellen und -methoden. Verlagert man nun den Arbeitsauftrag in die XML-Daten und verwendet eine generische Schnittstelle, so ist genau zu prüfen, ob bzw. in welcher Schicht die Sicherheitsmechanismen noch greifen können.
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 Mechanismen vergleicht (Properties, Datenelemente, "ADO Record Sets"), die für die jeweiligen Gegebenheiten optimiert sind. 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, da das Dokument nie zerstört wird und folglich auch nicht neu aufgebaut werden muß. 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.

Fazit

XML bietet unbestreitbare Vorteile und hat in vielen Teilbereichen der Softwareentwicklung Einzug gehalten. Dabei steht diese Entwicklung gerade erst am Anfang - wohin sie noch führen wird, ist nicht abzusehen. Mit diesem Artikel sollte aufgezeigt werden, daß XML auch im Bereich der Middleware eine Schlüsseltechnologie mit hohem Potential darstellt. Viele der sich daraus ergebenden Aspekte würden den Rahmen eines einzelnen Artikels sprengen und konnten deshalb nicht angesprochen oder nur angerissen werden.
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.
Ich würde mich über Kommentare, Anmerkungen oder sogar Erfahrungswerte zu diesem Thema sehr freuen.

Literatur

[Wes00] R. Westphal, „Strong tagging“ als Ausweg aus der Interface-Versionshölle, OBJEKTspektrum 4/2000

Weitergehende Informationen - Links

*1 Als Übersetzung der englischen Begriffe "state", "stateless", "state management" etc. findet man häufig auch "Status", "statuslos", "Statusverwaltung" usw.. "Zustand" ist jedoch ebenso gebräuchlich und zudem die korrekte deutsche Übersetzung.

---

Alexander Jung (email: jung@new-line.de infoAlexander-Jung.NET) arbeitet als Principal Consultant bei der NEW LINE Software Develpment GmbH. Er leitet den Bereich OO/COM Development und beschäftigt sich mit dem Einsatz von XML in der Middleware (Windows DNA) und den Auswirkungen auf Architektur und Projektorganisation.