Mainframes sind aus langjährig gewachsenen IT-Landschaften, zum Beispiel in Banken und Versicherungen, nicht wegzudenken. Es gilt jedoch zunehmend, eine Brücke zwischen modernen Architekturen und den Anwendungen und Daten der Großrechner zu schlagen, so zum Beispiel für den Vertrieb im Außendienst. Verkäufer haben von unterwegs oft keinen direkten Zugang zum System. Zudem haben sie andere Anforderungen bezüglich der Systemhandhabung als Sachbearbeiter im Büro. Deswegen haben sich Web-Applikationen etabliert, über die beispielsweise Makler und Vermittler mit auf ihren Zweck zugeschnittenen Benutzungs-Schnittstellen von beliebigen Orten aus Daten im zentralen System abfragen und ändern können.

Die Aufgabe dabei ist, den zentralen Host an Frontend-Systeme anzubinden.

Folgende Konzepte für die Host-Integration sind gängig:

- Oberflächenintegration (Screenscraping),

- Vorsysteme,

- Messaging (Nachrichtenaustausch)

- Service-orientierte Architekturen (SOA).

Je höher die Nutzungsintensität und je langfristiger die Integration angelegt ist, umso höher wird der Integrationsgrad sein müssen. Weitere Einflussfaktoren sind:

- Müssen neben den Online- auch Batch-Prozesse integriert werden?

- Gibt es eine Hersteller- oder Produktaffinität?

- Sind Migrationsaspekte zu berücksichtigen, und was lässt das Geschäft zu?

Oberflächenintegration

Diese Integrationsart ist auch als "Screenscraping" bekannt. Hier werden die Host-Masken einer Cics- oder IMS-Transaktion (Cics = Customer Information Control System, IMS = Information Management System) ausgelesen und weiterverarbeitet. Diese Integrationsform ist recht einfach, da hier weder der Funktionsumfang noch der ursprüngliche Workflow der Host-Anwendung verändert wird. Dazu werden 3270- und 5250-Datenströme in einem speziellen Client emuliert. Das Konzept ist nicht neu; eine Vielzahl von Produkten ist unter der Bezeichnung der "Terminalemulatoren" bekannt und verbreitet.

Mit der zunehmenden Verbreitung von Thin Clients und Browser-basierenden Frontends sowie Portalen wollen Firmen aber nicht nur eine Emulationsfunktion. Vielmehr wünschen sie eine aufgewertete Darstellung von Transaktionen in einer HTML-Seite beziehungsweise einem Portalmodul (Portlet) innerhalb einer Portalanwendung.

Diese Anbindung ist ebenfalls einfach und schnell zu bewerkstelligen, erfordert aber andere Mechanismen. Neben dem bekanntesten Produkt von IBM aus dem Websphere-Umfeld ("HATS") gibt es ein kostenloses Open-Source-Programm für die automatische Umwandlung von 3270-Daten für Web-Oberflächen.

Dieser Lösungsansatz bietet sich für eine lose Anbindung des Hosts an moderne Umgebungen an, bleibt allerdings auf Online-Transaktionen basierend auf Cics und IMS beschränkt.

Vorsysteme

Zur Host-Integration über ein Vorsystem wird dem Mainframe eine in der Zielsprache entwickelte Umgebung (zum Beispiel Java/J2EE) vorgeschaltet. Auf das Host-Backend greift dieser Server über APIs zu und kapselt dessen Funktionnen für neue Anwendungen.

Für die Verbindung zwischen Vorsystems und Host stehen unterschiedliche Methoden bereit, wobei aus praktischen Erwägungen oft die Connectivity-Software des Transaktionsmonitorherstellers eingesetzt wird. Bei IBM sind das "Cics Transaction Gateway" sowie "IMS Connect".

Nachstehend wird ein Szenario beschrieben, in dem Cics-Transaktionen über das Cics Transaction Gateway (CTG) auf einem Application-Server verfügbar gemacht und über die Java Connector Architecture (JCA) an neue Anwendungen angebunden werden.

Java-Connectivity

JCA dient dazu, Fremdsysteme mit einer J2EE-Umgebung zu verknüpfen. Es handelt sich zunächst nur um eine Spezifikation, die dann (ähnlich wie JDBC im Datenbankumfeld) von den jeweiligen Herstellern des Fremdsystems implementiert wird. JCA-Konnektoren gibt es für Software von SAP, Peoplesoft, Siebel sowie Cics und IMS. Nach der Installation des Cics Transaction Gateway (CTG) auf dem Host und einigen minimalen Anpassungen an den bestehenden Cics-Anwendungen kann bereits per TCP/IP auf das Gateway zugegriffen werden. Auf der Java/J2EE-Seite ist der Java-Konnektor für CTG zu installieren. Danach können die Cics-Umgebung des Hosts und der Java-Server via Common Client Interface (CCI) kommunizieren. Das CCI besteht aus dem "External Call Interface" (ECI) und dem "External Presentation Interface" (EPI). Mit Hilfe des ECI können Commarea- und mit dem EPI 3270-basierende Cics-Programme angesprochen werden. Die Commerea dient als Kommunikationsdrehscheibe zwischen der Business-Logik und der Präsentationslogik einer Cics-Anwendung.

Neben der JCA-Anbindung lassen sich Hosts auch direkt ansprechen, und zwar über das native Datenformat, einem "Cobol-Byte-Strom". Dies lässt sich mit Hilfe eines Parsers für Copy-Strecken von Cobol bewerkstelligen. Dieser erzeugt auf Grundlage der Speicherschablonen von Cobol-Programmen Java-Klassen. Diese Klassen beinhalten die Logik zur Umwandlung von Zeichensätzen (von Unicode in den Mainframe-Zeichensatz EBCDIC) wie auch "getter"- und "setter"-Methoden, um eigene Variablen auslesen und belegen zu können. Danach werden die Daten in den Java-Objekten in flache Datenströme (Byte-Wurst) serialisiert und direkt dem Host übergeben. Der Host verarbeitet die Informationen mit Hilfe der Speicherschablonen.

Diese Lösungsansätze bieten sich für eine recht enge Anbindung des Hosts an moderne Umgebungen an. Die Einschränkungen hier liegen vor allem in der meistens unveränderten Nutzung der bestehenden Host-Transaktionen (im Vergleich zu einem SOA-Konzept) sowie der Eins-zu-eins-Kopplung zwischen Vorsystem und Host-Backend (im Vergleich zu Messaging).

Messaging

Integration auf der Basis von Messaging-Systemen ist als eine Variante der Vorsysteme zu verstehen, die zusätzlich mit dem Host auf der Basis von Nachrichten kommuniziert.

Der Nachrichtenaustausch erfolgt asynchron über Nachrichtenschlangen (Queues). Prinzipiell kann auf diese Queues von verschiedenen Rechnern aus zugegriffen werden. Dieselbe Nachricht kann also von mehreren Adressaten empfangen werden, was für den Absender transparent bleibt. Eine Nachricht enthält neben dem Datenteil auch immer Meta-Informationen wie Absender, Empfänger, Transportweg etc.

Austausch über Queues

Eine zentrale Komponente, der Queue-Manager, kontrolliert die Nachrichtenschlangen. Er kann aufgrund einer bestimmten Nachricht deren Verarbeitung durch ein zu startendes Programm anstoßen (Trigger) und Empfangs-, beziehungsweise Versandbestätigungen verschicken.

Bei Mainframe-Anwendungen dienen eine oder mehrere Queues als zentrale Komponente zum Austausch der Daten oder zum Anstoßen von Transaktionen und Verarbeitungsprogrammen. Dies stellt relativ niedrige Anforderungen an die Beteiligten, da sie nur den Zugriff auf die Message-Queue benötigen. J2EE-konforme Applikations-Server verfügen über Message Driven Beans, die vom Server beim Eingang einer Nachricht in die Queue informiert werden. J2EE erlaubt zudem die Kommunikation über Session Beans. Allerdings ist hierbei ein Mechanismus einzubauen, damit das System eine vorgegebene Zeitspanne auf die Host-Antwort wartet. Der Umgang mit der inhärenten Asynchronität kann sich als kompliziert und fehlerträchtig erweisen.

MQ Series und JMS

Im Host-Umfeld zählt "MQ Series" von IBM zu den Standardprodukten. Es stellt ein einheitliches API namens MQI zur Verfügung. Von diesem gibt es Implementierungen für Java, Cobol und PL/1. Außerdem existieren zahlreiche Messaging-Clients.

Für Java wurde der Java Messaging Service (JMS) entwickelt. Er abstrahiert das Messaging-System, beispielsweise gibt es eine Implementierung für MQI. JMS unterstützt zwei unterschiedliche Ansätze zum Versenden von Nachrichten: Nachrichtenschlangen (Point-to-Point-Kommunikation) und das Abonnement von Nachrichten (Publish-Subscribe). Bei gerichteten Punkt-zu-Punkt-Verbindungen schickt ein Client eine Nachricht an einen Queue Manager, der die Nachricht in eine Warteschlange einreiht. JMS definiert ein API, mit dem Klienten Messages versenden und aus der Schlange entnehmen können. Beim Abonnement-Verfahren werden Nachrichten von einem Sender über eine Topic (Überschrift beziehungsweise Thema) an beliebig viele Empfänger versendet. Dabei muss sich der Empfänger vorher am Topic anmelden, falls er sich für eben diesen Typ Nachrichten interessiert.

Im Gegensatz zu einem ausschließlich Vorsystem-basierenden Integrationskonzept liegt der Vorteil des Messagings in der verteilten Verarbeitung und der besseren Skalierung.

Serviceorientierung/SOA

Mainframe-Integration mittels einer Serviceorientierten Architektur (SOA) bedeutet, vorhandene Host-Bausteine häufig unter Einbezug neuer Geschäftslogik zu Prozessen zu verbinden. Hierzu ist es jedoch oft notwendig, vorhandene Transaktionen in sinnvolle Einheiten feinerer Granularität aufzubrechen. Sinnvolle Funktionseinheiten sind möglichst in sich geschlossen, unabhängig von konkreten Prozessen und von geringem Umfang. Diese Einheiten stellen die Services in der SOA dar. Services sind - zumindestens der reinen Lehre nach - von einem spezifischen Anwendungskontext (Prozess) losgelöst und werden im Rahmen der fachlichen Zusammenführung zu einem Geschäftsprozess eingebunden ("orchestriert").

Ein Web-Service kapselt einen Softwaredienst, so dass er von außen über verschiedene Plattformen und Programmiersprachen über Protokolle wie HTTPS aufgerufen werden kann. Somit müssen Host-Anwender die aus Host-Transaktionen herausgebrochenen funktionalen Einheiten zusätzlich als Web-Services kapseln. Unter Cics beispielsweise wäre dies in einem transaktionalen Umfeld auf dem Host problemlos möglich. Dabei hilft zum Beispiel der Cics Transaction Server in Verbindung mit dem Erweiterungsmodul "SOAP for Cics".

Alternativ lässt sich - wie beschrieben - Cics über ein Java-Vorsystem anbinden. Eine Java-Applikation könnte dann Web-Services-Schnittstellen für eine SOA zur Verfügung stellen.

Enterprise Service Bus

Die technische Zusammenführung der Services zu dem, was später als Geschäftsprozess sichtbar sein soll, übernimmt ein Enterprise Service Bus (ESB). Diese Komponente sorgt für Konnektivität zwischen Diensten und konvertiert Daten. Letzteres ist erforderlich, da auf dem Bus in der Regel nur ein Nachrichtenformat Verwendung findet.

Die fachliche Zusammenführung (Modellierung) von Services zu einem Geschäftsprozess (Orchestrierung) bewirkt ein Prozess-Manager. Die aus der Orchestrierung resultierenden Prozessinformationen werden an den ESB übergeben. Damit das funktioniert, benötigt man für die Prozessmodellierung Standards wie zum Beispiel die Business Process Execution Language (BPEL).

Der Aufwand für eine Integration nach dem SOA-Modell ist nicht unerheblich. Ein Streitpunkt in der Praxis ist häufig die Frage, wie man die "reine Lehre" ausgewogen einem pragmatischen Projektvorgehen entgegenstellen sollte. Vorteil des SOA-Ansatzes ist eine hohe Flexibilität, Altes mit Neuem beliebig verknüpfen zu können. Die Servicearchitektur kann auch dann von Vorteil sein, wenn das Unternehmen weitere Alt- beziehungsweise Fremdsysteme einbinden muss. SOAs kommen dem Idealbild zukünftiger Architekturen sehr nahe, Anwendungen aus unabhängigen Bausteinen (selbst entwickelte, als Standard dazugekaufte und gemietete) über einen ESB zusammenzusetzen und über eine Prozesssteuerung im Portal anzubieten. Die ehemaligen Host-Transaktionen wären in diesem Bild selbstentwickelte Services. (fn)