BizTalk Server als SOA-Drehscheibe

Das derzeit viel diskutierte Thema Service Oriented Architecture (SOA) ist weder neu noch repräsentiert es eine radikal andere Technologie. Eine SOA ist vielmehr der nächste Schritt in der Evolution der Systemarchitekturen der letzten 25 Jahre, angefangen bei den monolithischen Applikationen, über Client/Server-, 3-Tier- und N-Tier-Systemen bis hin zu Component-Based-Achitekturen. Unabhängigkeit von Technologien und Herstellern sowie Interoperabilität sind wichtige Merkmale einer SOA.
Im Mittelpunkt einer SOA stehen die Services, also softwarebasierte Dienste und Dienstleistungen. Diese Services werden in einem Service Contract definiert und von Service Providern angeboten. Innerhalb einer SOA-Umgebung können zwei spezielle Arten von Service Providern zum Einsatz kommen. Zum einen gibt es so genannte Service Locators, die beim Auffinden von Diensten anderer Service Provider helfen und deren Contract bereitstellen. Zum anderen gibt es auch Service Broker, der Anforderungen transformieren und an andere Service Provider weiterleiten kann, ohne dass die Service Consumer davon etwas mitbekommen müssen. Der BizTalk Server besetzt innerhalb einer SOA-Umgebung in der Regel die Rolle dieses Service Brokers.

Die erste, auf Microsofts COM-Technologie basierende Version des BizTalk Servers erschien bereits im Jahre 2000. Wesentliche Features wie Messaging und Orchestration waren in dieser Version schon vorhanden, allerdings fehlte die Unterstützung für XSD-Schemas und die Implementierung der Orchestration Engine war unzureichend. Im Jahre 2002 folgte ein kleines Update, das den BizTalk Server um Web-Service-Unterstützung und eine bessere Integration von .NET-Komponenten erweiterte. Die dritte und derzeit aktuelle 2004er Version von BizTalk Server basiert auf einer komplett neu entwickelten und auf .NET ausgerichte-ten Architektur. Diese konsequente Ausrichtung brachte auch XSD-Schema-Unterstützung mit sich. Komplett neu entworfen wurden neben anderem auch die Messaging Engine sowie die wesentlich leistungsfähigere Orchestration Engine.
Mit BizTalk Server 2006 taucht bereits die nächste Version des Integrations- und Orchestrierungsservers am Horizont auf. Der für das nächste Frühjahr angekündigte 2006er Release wird neu auf dem .Net Framework 2.0 aufsetzen. Während die grundlegende Architektur aus BizTalk Server 2004 beibehalten wurde, wird BizTalk vor allem mit zahlreichen Detailverbesserungen ausgestattet sein. Dazu zählen beispielsweise neue Adapter für SharePoint und IBM MQ Series, besseres Business Activity Monitoring (BAM) und eine konsolidierte Administrationskonsole.

Der BizTalk Server dient als Integrations- und Orchestierungs-Drehscheibe, um EnterpriseApplikationen miteinander zu koppeln. Statt Applikationen via Punkt-zu-Punkt-Verbindungen zu integrieren, kann BizTalk Server, gemäss der SOA-Philosophie Anwendungen flexibel miteinander ver-binden und zu Business Prozessen zusammenfassen. Dabei ermöglicht BizTalk, unterschiedliche Applikationen mit völlig verschiedenen Transportprotokollen zu integrieren und kann Nachrichtenformate zwischen unterschiedlichen Systemen konvertieren.
Die Architektur von BizTalk Server ist offen konzipiert und kann flexibel erweitert werden. Sie setzt sich aus den folgenden Komponenten zusammen:

o Adapter - Aufgabe des Adapters ist es, die Kommunikation zwischen einer Applikation und BizTalk Server zu ermöglichen. Im Lieferumfang des BizTalk Servers sind bereits eine ganze Reihe von Adaptern, darunter für EDI, FTP, POP3, SOAP, HTTP, SQL Server uns MSMQT (Microsoft Message Queue) enthalten. Weitere Adapter können entweder von Drittanbietern erworben oder auch selbst erstellt werden. Insbesondere für die SOA-Architektur ist der Adapter für die Windows Communication Foundation (ehemals «Indigo») in-teressant. Dieser erlaubt es, Webservices der zweiten Generation wie WS-Reliable Messaging oder WS-Security zu nutzen und in BizTalk zu integrieren.

o Pipeline - In der Pipeline, die auch um eigene Komponenten erweitert werden kann, werden die ein und ausgehenden Nachrichten bearbeitet. Hier lassen sich beispielsweise Nachrichten validieren, ver- oder entschlüsseln oder konvertieren. BizTalk verfügt sowohl über eine Send- als auch über eine Receive-Pipeline, die in unterschiedliche Stages (z.B. Decode, Dis-assemble, Validate) aufgegliedert sind.

o Intern speichert BizTalk Server alle Nachrichten im XML-Format in der Message Box ab. Zur Steuerung der Nachrichtenverarbeitung ist es notwendig, das Schema (.XSD) der Nachrichten zu beschreiben. BizTalk Server bietet dafür einen Schema Designer, welcher sich in Visual Studio integriert.

o Mapping - Das Konvertieren von Nachrichten zwischen unterschiedlichen Formaten basiert auf BizTalk Maps. Diese werden mit dem in Visual Studio integrierten BizTalk Mapping Designer erstellt und intern in XSLT umgesetzt. Das Einbinden ausserhalb von Visual Studio erstellter XSLT-Dateien ist ebenfalls möglich.

o Messaging - Der Begriff Messaging steht beim BizTalk Server für die Kommuni-kation zwischen Anwendungen. Um die Kommunikation flexibel zu gestalten, wurde im BizTalk Server ein Publish/Subscribe-Modell implementiert. Dieses erlaubt es, Filter zu definieren, die nur die Filterbedingung erfüllenden Nachrichten passieren lässt.

o Orchestrations - Orchestrations werden zum Abbilden von Geschäftsprozessen genutzt, welche über die einfache Kommunikation via Messaging hinausgehen. Die Workflows der Prozesse lassen sich im Orchestration Designer grafisch entwerfen und werden anschliessend in ausführbaren .NET Code kompiliert.

Da BizTalk meistens zur Integration von bereits existierenden Applikationen ein-gesetzt wird, wundert es nicht, dass in der Praxis relativ wenige Implementierungen auf Basis von Webservices der zweiten Generation zu finden sind. Dies würde voraussetzen, dass die anzubindenden Applikationen bereits die aktuellen WS-*-Protokolle unterstützen. Dies ist jedoch noch selten der Fall. Stattdessen kommen in der Praxis bereits etablierte Protokolle wie Filetransfer, HTTP, MSMQ, MQ Series oder Webservices der ersten Generation zum Einsatz. Häufig werden auch spezielle Adapter wie SAP, Siebel, PeopleSoft, Swift eingesetzt. Der damit verbundene Kostenvorteil für eine Integration mehrerer Anwendungen gegenüber einer Individualentwicklung ist normalerweise erheblich. Steht ein geeigneter Adapter bereits zur Verfügung, lassen sich Anwendungen in relativ kurzer Zeit integ-rieren.
Der Produktivitätssteigerung im Integrationsprozess dienen auch so genannte Acce-leratoren. Dies sind Pakete aus einem Adapter und einer Anzahl vorgefertigter Schemata und Transformationen (etwa für SAP, EDI, RosettaNet, Hippa oder HL7). Insbeson-dere bei sehr komplexen Nachrichtenschemata sowie deren Transformation macht sich ein solcher Accelerator gegenüber einer Eigenentwicklung schnell bezahlt.
Ein weiterer Vorteil beim Einsatz von BizTalk Server im Vergleich zu einer Eigenentwicklung sind die umfangreichen Überwachungs- und Berichtswerkzeuge. Mit dem Business Activity Monitoring (BAM) lassen sich Geschäftsprozesse auswerten und mit dem Health and Activity Tracking (HAT) kann der Zustand von BizTalk Server auf der technischen Ebene überwacht werden. Ohne den Einsatz von BizTalk Server müssten solche Funktionen selbst entwickelt werden.
Natürlich gibt es bei allen Vorteilen auch immer eine Schattenseite zu beachten. Vorsicht ist geboten bei der Verarbeitung von sehr grossen Dokumenten, insbesondere wenn diese auch noch transformiert werden sollen. Hier kann es leicht zu Engpässen kommen, da in BizTalk Server grundsätzlich alle Dokumente über die Message Box in der Datenbank geleitet werden. Die Transformation von grossen Dokumenten erfordert eine grosszügige Auslegung des Hauptspeichers. Auch beim Einsatz von Orchestrations sollte man immer ein Auge auf die Performance haben. Orchestrations speichern ihren Zustand nach jedem Verarbeitungsschritt in der Datenbank, was schnell zu hohen Lasten auf den Datenbank-Servern führen kann.

Der BizTalk Server ist innerhalb einer typischen SOA für die zentrale Rolle des Service Brokers prädestiniert. Darüber hinaus gibt es noch ein weiterführendes Konzept, von dem in der SOA-Welt häufig die Rede ist: Enterprise Service Bus (ESB). Hinter diesem Begriff verbirgt sich ein architektonisches Konzept, in dem alle Applikationen über eine einheitliche Infrastruktur, den ESB, miteinander verbunden sind. Der ESB stellt dabei eine Reihe von Diensten zur Verfügung: Datentransformation, Content Based Routing, Business Process Orchestration und die Unterstützung verschiedener Transportprotokolle. Nicht ganz zufällig liest sich diese Liste wie ein Teil der Produktbeschreibung des BizTalk Servers selbst, denn dessen Design zielt auf den Einsatz als ESB ab.