von Thomas Braun
Über den Autor
Thomas Braun ist Director Business Development & Marketing bei der Magic Software Enterprises (Deutschland) GmbH und zu erreichen unter thomas_braun@magicsoftware.com
Java wird oft als Perspektive genannt, um Tools, GUI und Geschäftsprozesse zu erneuern und die proprietäre iSeries Sprache RPG zu ersetzen. Denn RPG wird als Sprache der „alten“ Mainframes oft totgesagt. Lange Zeit wollte sich niemand mehr mit den „Monstern“ beschäftigen, deren Software und Systeme oft mit Hilfe von Java auf eine neue, objektorientierte und plattformunabhängige Basis gestellt wurden.
Bei allem Fortschritt wurden die Vorteile der Großrechner oft leichtfertig über Bord geworfen und im Zuge der Modernisierung Aspekte wie Skalierbarkeit und Datensicherheit, speziell im kritischen Banken- und Versicherungssektor, leichtfertig aufs Spiel gesetzt. Nicht erst seit Großrechner um Internet-Befähigungen erweitert wurden, sind die Monster im Keller wieder aktuell – nur ist bald niemand mehr da, der sie bändigen kann. Die RPG-Programmierer „sterben aus“, die Hochschulen vermitteln ihren Absolventen andere Programmiermethoden.
Also: alles neu – alles besser? Ist am Ende der Modernisierungsstraße noch Platz für RPG? Wie ist der Übergang zu schaffen von RPG zu Java? Ist es sinnvoll, die Middleware zu halten? Macht es Sinn, die postulierten Vorteile der neuen, objektorientierten Technologien, wie z.B. Java, mit der Performance und Stabilität der iSeries Mainframes und „ihrer“ Sprache RPG zu verbinden?
RPG und iSeries – für immer vereint?
RPG ist (und bleibt?) die primäre Sprache der Entwickler, die für die iSeries programmieren. Genau wie die iSeries – ehemals AS/400 -gilt RPG als grundsolide, zuverlässig und besticht durch Skalierbarkeit und Investitionsschutz. Die Vielzahl der noch existierenden RPG-Anwendungen macht es unwahrscheinlich, dass diese in naher Zukunft alle von der Bildfläche verschwinden werden. Milliarden Codezeilen lassen sich nicht einfach ignorieren. RPG als „Arbeitstier“ unter den Programmiersprachen unterstützt einige unternehmensskritische Anwendungen mit sehr geringem Aufwand. „Wenn Sie es im Rennen von Le Mans einsetzen wollen, wird das nicht zum gewünschten Erfolg führen.
Wenn Sie aber Kohle über eine Entfernung von 8000 Kilometern zu transportieren haben, wäre dieses Arbeitstier erste Wahl“, beschreibt Jon Paris, Ko-Autor des Redbooks „Who knew you could do that with RPG IV?“ anschaulich die Leistung von RPG. Und wenn es um die intensive Verarbeitung von Daten und/oder das Erstellen von Reports geht, ist RPG nach wie vor ungeschlagen. Aber: Offene Systeme, Portabilität, Kommunikation, Grafik und Multimedia, das sind alles Dinge, mit denen RPG nichts anfangen kann, denn dafür ist es – als ehemaliger Berichtsgenerator – nicht geschaffen. Auch im Hardware-Bereich wird RPG das Leben erschwert. Mit dem vermehrten Einsatz von Windows und Unix Systemen verändern sich die Paritäten für OS/400 als Betriebssystem zu dessen Ungunsten, was neben der mangelnden Fähigkeit, sich den veränderten Software-Anforderungen anzupassen, den Lebensraum für das proprietäre RPG noch zusätzlich einschränkt. Dagegen tritt eine portable Sprache wie Java an, mit besten, da theoretisch durch die Objektorientierung fundierten Erbanlagen.
Java, ganz stark im Kommen
Java (http://java.sun.com) hat in den letzten Jahren rasante Verbreitung gefunden: Von einer Sprache für eingefleischte Freaks der Objektorientierung zu einer selbstverständlichen Technologie hin und zu einer der am meisten verbreiteten und leistungsfähigsten Programmiersprachen und Technologien der Anwendungsentwicklung. Für Java spricht seine umfassende Einsatzfreudigkeit und Portabilität. Für alle gängigen Betriebssysteme gibt es ein Interface, die Java Virtual Machine, auf der die Java API und die mit Java selbst geschriebenen Anwendungen lauffähig sind. Insbesondere die iSeries, bei der die Implementierung der Java Virtual Machine unterhalb der Maschinenschnittstelle realisiert wurde, hatte von Release zu Release erhebliche Verbesserungen zu vermelden. Viele moderne Programmiersprachen und -technologien, insbesondere die Enterprise-Technologien, basieren auf Java und sind eng damit verbunden. Das betrifft u. a. serverseitige Anwendungskomponenten wie Servlets und EJB’s, XML-Anwendungen, Application Server, Web Services und alle Internet-Anwendungen.
Die iSeries bietet durch ihre Objekt-Basierung einen sehr guten Lebensraum, den IBM durch die intelligente Java-Implementierung noch weiter verbesserte. IBM unterstützt selbstverständlich beide Sprachen, stattet aber OS 400 zunehmend mit Java-Funktionalitäten aus. Diese Vorteile gleichen die der Objekt-Orientierung und Java anhaftenden Performance-Probleme aus. Und Application Server, auf iSeries vorzugsweise WebSphere, profitieren wiederum von der guten Java-Implementierung. Damit liegt der Schluss nahe, dass Java im Laufe der Zeit die Rolle von RPG in der iSeries Anwendungsentwicklung übernehmen wird und dass Java die ideale Programmiersprache für die iSeries Anwendungsmodernisierung ist. Viele Zeichen sprechen aber auch dafür, dass die Zukunft dieser beiden Programmiersprachen gerade in ihrer Koexistenz und damit Kooperation zu sehen ist. So können die Vorteile beider Technologien verbunden werden. Anders gesagt: RPG macht die Arbeit, Java sorgt für den Auftritt. Beide werden in denselben Anwendungen oder Systemen eingesetzt und können wechselseitig voneinander profitieren – während RPG seine Stärken im Back Office und in der Datenhaltung demonstrieren kann, werden Java-basierende Anwendungen überall da zum Einsatz kommen, wo es um Darstellung, Präsentation und Kommunikation geht.
Soviel „Alt“ wie möglich, soviel „Neu“ wie nötig
Dieser vielfach propagierte Tandemeffekt ist auch Grundlage und Philosophie vieler Modernisierungs- und/oder Integrationsprojekte von Magic Software Enterprises. „Im Prinzip geht es darum, beide Sprachen genau da einzusetzen, wo sie stark sind“, erklärt Dirk Timmerman, Geschäftsführer Magic Deutschland, seine Sicht zum parallelen Einsatz von RPG und Java. „Moderne Technologien wie Java benötigen wir zur Darstellung im Web, aber RPG liefert seit jeher saubere Prozesse. Warum soll RPG gewaltsam durch Java ersetzt werden, nur um modern zu sein, wenn die Integration beider Technologien in einem System viel mehr Sinn macht?“ Bei der Modernisierung mit der Integrationsplattform iBOLT bleiben daher Legacy Business-Logik und -Prozesse unverändert, neue moderne C/S- und Web-Funktionalitäten werden einfach „vorgesetzt“ und können sofort mit existierenden Prozessen interagieren. Schnell, transparent und „völlig codefrei“ werden Webanwendungen – oder allgemein neue Technologien wie eben z.B. Java – an Legacy IT, die z.B. auf RPG basiert, angebunden.
Wie einfach lassen sich im Zuge dieser Teil-Migration RPG-Anwendungen modernisieren?
Leider ist der Traum vom RPG- Java-Konverter per Klick in Wahrheit wohl eher ein Albtraum. Ohne auf die technischen Probleme im Einzelnen eingehen zu wollen, ist es vor allem das eigentliche Prinzip hinter Anwendungsmodernisierung, das einen Wechsel „eins zu eins“ unmöglich macht. Eine Webanwendung unterscheidet sich eben nicht nur durch ein Browser-Frontend von einer RPG-Anwendung mit 5250-Screen, sie spricht auch völlig andere Nutzer in einem ganz anderen Rahmen an. Migration von RPG zu Java bedeutet daher für Magic immer, dass Anwendungen mit neuer Business-Logik ausgestattet werden müssen, um ihren Platz vollwertig ausfüllen zu können. Auch die Giga-Group nimmt sich in einer Studie der Problematik an und nennt in diesem Zusammenhang zwei Tools für die Migration hin zu Web-Technologien: Web-Emulation- / Interface-Reengeniering- und EAI-Tools. Erstere bringen schnelle Ergebnisse, allerdings auf Kosten der Funktionalität, das stellt auch Giga fest. Viele EAI-Tools bieten die Funktionalität, verlangen aber hohen Schulungs- und Implementierungsaufwand. Die Integrationsplattform iBOLT basiert auf der codefreien RAD-Technolgie des Magic-Entwicklungstools eDeveloper und ist daher schnell in der Implementierung und bietet die erforderliche Funktionalität, um Web- oder GUI-Interfaces zu erstellen und diese in das Gesamtsystem einzubinden. Wobei dieses Gesamtsystem sich flexibel am Bedarf des Unternehmens ausrichtet. Hier sieht Magic die Stärke der Anwendungsintegration und -modernisierung mit iBOLT. Anwendungen müssen nicht danach ausgewählt oder dahingehend migriert werden, dass sie zusammen passen. Die Auswahl und der Einsatz erfolgt allein nach dem Prinzip der Funktionalität. Wenn also eine RPG-basierte Legacy-Anwendung im Unternehmen gute Dienste leistet, dann wird man diese in jedem Fall beibehalten und nur die Teile des Systems zu Java migrieren oder neu implementieren, bei denen es sinnvoll erscheint. Unter Verwendung existierender Ressourcen wird durch die Integrationsfähigkeit von iBOLT möglich, absolut Anwender-orientierte und -optimierte Gesamtsysteme zu schaffen.
Die Georg Kohl GmbH
1868 als Druckerei einer Regionalzeitung gegründet, beschäftigt das Traditionsunternehmen heute ca. 450 Mitarbeiter und verfügt nicht nur über die weltweit schnellste Endlos-Rotantionsdruckmaschine, sondern ist auch Vorreiter im „Print on Demand“-Geschäft. Sowohl in den Bereichen Umweltschutz als auch Qualitätssicherung hat man früh begonnen, Maßstäbe zu setzen und bereits 1996 ein mehrfach ausgezeichnetes Qualitäts- und Umweltmanagement eingeführt. Da keine Branchenlösung den speziellen Bedarf des Unternehmens erfüllen konnte, setzt man seit 1998 auf ein Magic-basierendes ERP-System, das mittlerweile sämtliche ERP-Prozesse abdeckt. Die zu 100% im Haus entstandene Lösung, die bis 1998 eingesetzt und permanent weiter entwickelt wurde, schaffte eine völlige Unabhängigkeit von externen IT-Dienstleistern und Lieferanten. 1998 stellte die Software einen nicht zu unterschätzenden Wert dar und „bediente“ mittlerweile über 100 Arbeitsplätze in den verschiedenen Fertigungs- (z.B. Endlosdruck, Bogendruck, Elektronischer Druck) und Geschäftsbereichen (Doku, ELP, Mailing, etc.). Auch die Auftragsverwaltung, die Warenwirtschaft und die Buchhaltung deckte die Eigenentwicklung ab. Aber: Mit wachsender Größe und Technisierung musste Kohl eine Entscheidung treffen, vor der viele mittelständische Unternehmen, die auf Eigenentwicklungen setzen, früher oder später stehen. Die Vorteile der 90er-Jahre-Lösung wurden von den Nachteilen und vor allem von wachsenden Ansprüchen, die sich als nicht oder nur schwer realisierbar zeigten, langsam aber sicher überwogen. Steigende Entwicklungskosten und ein unverhältnismäßiger Aufwand für Wartung und Pflege waren die Folge. Funktionalitäten in der Bogenkalkulation und in der Abwicklung der Projektaufträge ließen sich nicht integrieren, ebenso wenig wie einfachste PC-Funktionalitäten (Excel- bzw. HP basierende Auftragsabwicklungen) sowie die Anpassung im Zuge der Euro-Umstellung. Zudem waren fast 50% der Software noch an der alten Hardware IBM/36 orientiert und damit nicht datenbankfähig. Es galt, eine Software zu finden, mit der sich die vorhandene Lösung schnell modernisieren und an die aktuellen Anforderungen anpassen lässt. Ausserdem musste sicher gestellt sein, dass in fünf Jahren nicht wieder die Grenzen der Software erreicht würden. Zukunftssicherheit und die Unabhängigkeit von Datenbanken und Plattformen waren daher wichtige Kriterien, die auch die Anbindung an die verschiedenen EDV-Systeme der Kohl Kunden (HP, Bosch, Deutsche Post AG …) ermöglichen sollten. Nach Prüfung verschiedener Tools stand fest, dass der eDeveloper von Magic diese Anforderungen am besten erfüllte. Interoperabilität und Offenheit des Tools sorgten dafür, dass das Abteilungs- und Modul-übergreifende Modernisierungsprojekt im laufenden Betrieb möglich war. Die Funktionalität der „alten“ Lösung wurde dazu 1:1 in Magic umgesetzt und um die Anforderungen der jeweiligen Fachabteilung erweitert. Während der darauf folgendenTestphase liefen beide Lösungen zunächst parallel; lieferte die Magic-Anwendung im Test identische Ergebnisse wie die Legacy-Lösung, wurde letztere durch die neue, erweiterte Magic-Lösung ersetzt. Inzwischen basieren alle Dialogprogramme auf Magic, was 95% der Gesamtfunktionalität entspricht. Lediglich einige Batch-Prozesse laufen im Altsystem. Diese schrittweise Migration im laufenden Betrieb mit Hilfe parallel laufender Anwendungen ist ein Vorteil, der speziell für mittelständische Unternehmen existenzsichernd sein kann, da sich IT-Projekte auf diese Weise nach Prioritäten und Kosten steuern lassen. Einkaufsabwicklung, Material- und Lagerwirtschaft, Verkaufsservice, Fertigungssteuerung, Versandkoordination und die Qualitätssicherungsmaßnahmen sowie die betriebswirtschaftlichen Auswertungen sind heute komplett Datenbank-basierte Magic-Anwendungen. Auch die Module Kalkulation, Produktion, Leistungserfassung und Fakturierung sind mittlerweile auf Magic umgestellt und laufen auf OS/400 mit einer DB2/400 Datenbank.
Magic und RPG
Die Programmierzyklen des Magic eDeveloper ähneln denen von RPG. Das ist ein Vorteil für die Unternehmen – ihre RPG-Profis können relativ schnell und einfach den Einstieg in die Magic-Technologie finden. Durch die Ähnlichkeit der Sprachen ist der Einsatz der Magic-entwicklungsmethodik auch eine der simpelsten Methoden, RPG-Legacy zu sichern und kostengünstig „in Schwung zu bringen“.
Magic und Java
Magic unterstützt J2EE und IBM WebSphere. Der Magic Application Server ist EJB Container und Client und stellt die direkte Verbindung mit EJBs in der WebSphere-Umgebung her. Durch die volle Unterstützung der J2EE-Architektur bietet der Magic-Server absolute Offenheit und robuste Interoperabilität für alle J2EE- und .NET-Plattformen. Er stellt die Messaging-Funktionen für JMS bereit und schließt den Support für alle Messaging-Server, die diesen Standard unterstützen, automatisch ein.
Ähnliche Artikel:
