Erstellung von Services mit SOA Express

Services und Komponenten

Auch die Idee des „Service“; ist nicht vom Himmel gefallen. Schon immer wurden bestimmte Programmteile modular angelegt, damit sie zur Übernahme von abgrenzbaren Funktionen – zum Beispiel Konvertierung eines Werts – von anderen aufgerufen werden können. Diese Unterprogramme oder Komponenten sind jedoch immer unter technischen Gesichtspunkten erstellt worden, nicht jedoch im Hinblick auf die Kapselung von Schritten in einem Geschäftsprozess. Auch das Corba-Modell erlaubt eine Verknüpfung von Komponenten zur Laufzeit, was beispielsweise die Möglichkeit bietet, aktuelle Versionen einer DLL nachträglich bereitzustellen. Allerdings geht die Verwendung von Programm-Modulen in einem ganz neuen, also bei der Entwicklung noch nicht verfügbaren oder noch gar nicht bekannten Kontext, über das Komponenten-Konzept hinaus. Diese Flexibilität bietet erst eine Architektur, die ihre funktionellen Bestandteile als Service zur Verfügung stellt. Die Konsumenten oder Clients dieser Services müssen dann nur bestimmten Anforderungen genügen, sich also beispielsweise identifizieren und die Schnittstellen richtig bedienen können. Dabei sorgt die Standardisierung dieser Schnittstellen für eine Vereinfachung der Kommunikation, die in Komponenten-Architekturen wie DCOM oder Corba nicht nur reichlich kompliziert, sondern außerdem auch nicht interoperabel war. Wer DCOM einsetzte, war so auf Windows beschränkt, und bei Corba war der Anwender auf den jeweiligen Hersteller angewiesen. Das SOA-Konzept geht hier ein Stück weiter.

Services generieren

Mit SOA Express stellt nun Micro Focus eine Lösung zur Verfügung, mit der Unternehmen, die als Host-System einen IBM-Mainframe (System z) verwenden, die Erstellung von Services aus bestehenden COBOL-Programmen sehr weitgehend automatisieren können. Die betreffenden Applikationen verwenden für die Dialoganwendungen die Transaktionssysteme CICS oder IMS. SOA Express ist in der Lage, aus diesen Host-Transaktionen Services zu generieren, ohne dabei Veränderungen an der Host-Applikation selbst durchführen zu müssen. Unternehmen können damit genau das vermeiden, was sie – aus gutem Grund – am meisten fürchten: Eingriffe in bestehende und funktionierende Applikationen. Im Grunde ist die Erzeugung eines Services aus einer Transaktion ganz einfach. Ausgangspunkt für die Definition eines Service ist dabei immer die Host-Applikation. Ein Service kann generiert werden auf Basis:

  • einer Bildschirmmaske der Host-Anwendung (BMS für CICS, MFS für IMS)
  • einer Datenstruktur, die jedem Transaktionsprogramm zur Verfügung gestellt wird und den Ablauf des Programms steuert (COMMAREA bei CICS, Scratch Pad Area bei IMS)
  • einem protokollierten Anwender-Dialog, der sich über mehrere Masken und auch mehrere Transaktionen erstrecken kann.

Damit lassen sich zunächst die Funktionalität und der Umfang des zu erstellenden Service auf dem Mainframe definieren. Der Service besteht aus einer oder mehreren Transaktionen, die ihre Eingabedaten aus der entsprechenden Maske oder dem betreffenden Datenbereich erhalten. Diese Eingabedaten und die von der Transaktion zurückgelieferten Ausgabedaten stellen die Basis für die Service-Schnittstelle dar, die nach außen exponiert wird. Dabei ist es durchaus möglich, den Umfang der Datenübernahme flexibel an die Anforderungen des zu erstellenden Service anzupassen. So können zum Beispiel bestimmte Felder der Maske an der Service-Schnittstelle oder einzelne Felder, die konstante Informationen enthalten, ausgenommen werden, sodass die Daten im Service-Interface nicht auftauchen. Dieses Vorgehen ermöglicht es, die Funktionalität der Transaktion für die Verwendung als Service einzuschränken, ohne die Transaktion selbst zu verändern.

Die Modellierung des Service-Interfaces erfolgt bei SOA Express mithilfe eines grafischen Tools. Wurde zur Erstellung des Service ein ganzer Dialog mit mehreren Bildschirmen aufgezeichnet, so muss man mit diesem Tool nicht nur das Service-Interface definieren, sondern auch festlegen, welche Informationen von einer Transaktion zur anderen weitergegeben werden, ohne dass sie an der Service-Schnittstelle nach außen sichtbar sind. Dadurch entsteht eine interne Verarbeitungslogik innerhalb des Service, mit der man auch Feldinhalte abfragen und auf einen bestimmten Inhalt überprüfen kann. Die gesamte auf diese Weise erstellte Logik innerhalb des Service, inklusive der Service-Schnittstelle, wird anschließend zur Generierung der Service-Module benutzt. Dabei werden immer zwei Module generiert, ein Host-Modul in COBOL und ein Modul in der entsprechenden Sprache des Application Servers, auf dem der Service läuft, entweder Java oder C# für die .NET-Welt. Die generierten Java- beziehungsweise C#-Module enthalten die Funktionen des Service als Methoden, die mit der entsprechenden Service-Schnittstelle von außen aufgerufen werden können. Bei Bedarf können diese Module als Web Service deployed werden. Im Innern der Service-Methoden gibt es Aufrufe an eine Middleware, die die an der Service-Schnittstelle entgegengenommenen Daten zum Mainframe überträgt. Bezüglich der Middleware kann der Anwender zwischen MQ-Series und ECI (External Call Interface) wählen. Als Partner-Applikation steht auf der Mainframe-Seite das generierte COBOL-Modul zur Verfügung, welches auf dem Host kompiliert und in das Transaktionssystem geladen werden muss.

Abb. 2: Die Transaktionen kommunizieren zur Laufzeit über einen Host-basierten Service mit dem Applikationsserver
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.