Migrationsprojekt mit CORBA. Andres Koch dipl. El. Ing. HTL / M. Math Object Engineering GmbH, Zürich akoch@objeng.ch.

Transkript

1 Migrationsprojekt mit CORBA Projekt im Raffer Migration Technische Bestandteile Fazit Andres Koch dipl El Ing HTL / M Math Object Engineering GmbH, Zürich akoch@objengch Inhalt Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland /3 Projekt im Raffer: Ausgangslage S/ seriell S/ seriell Zentraler Mainframe HW: IBM 30xx OS: MVS / IMS Sprache: PL/ Applikation: Abonnenten-Verwaltung SNA LU0 SNA LU0 ~2500 Endgeräte ~ 50 dezentrale Systeme seriell seriell PC Generation seriell seriell SNA LU0 Subsysteme mit CTOS/BTOS SNA LU0 max 32 Terminals pro Subsystem Borroughs ET00 7 Aussenstellen regional verteilt (Telefondirektionen) HW: IBM S/ OS: RPS Sprache: PL/, S/ Assembler Appl: Dezentraler Teil der Applikation Spezial Systemsoftware Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 2/3

2 Projekt im Raffer: Organisation Telecom PTT Schweiz Traditionelles staatliches Telecom-Unternehmen auf dem Weg zum Privatunternehmen Traditionelle Verarbeitung wird auf Kundenzentriertheit umgestellt Unternehmen hat bereits mehrere Technologie- Epochen mitgemacht Über das Land verteilte, regionale, teils recht autonome Organisations- Einheiten Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 3/3 Projekt im Raffer: Applikation zentrales System Verwaltungssoftware für Telefon-Anschluss- und Abonnenten- Informationen (Adress-Stamm Privatkunden) Radio/TV-Konzessions-Daten-Verwaltung Verwaltung anderer Zusatzdienste Verbund mit mehreren anderen Systemen innerhalb der Organisation Massenverarbeitungs-Funktionen (Umnummerierung, Umtaxierung ) Onlinebetrieb (jährlich ~0 Mio Transaktionen, ~5 Mio Tx tägl) Periodenabhängige Lastaufkommen (zb Umzugstermine) Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 4/3

3 Projekt im Raffer: Applikation dezentrales System Senden/Empfangen der Hostmeldungen Signon-Behandlung des Benutzers Beimischen der Bildschirmmasken (je ~300 Masken für 3 Sprachen) Schutz gemäss Zugriffsprofil des angemeldeten Benutzers Plausibilisierung der Eingaben Komfort-Funktionen (zb 3 zusätzliche virtuelle Bildschirmseiten) Verwaltung der Terminal-Kanäle und Host-Kanäle (ua) Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 5/3 Projekt im Raffer: Problemstellung Proprietäre dezentrale Hardware mit Spezialkomponenten (RPS, Schnittstellen) Programmierung in Assembler, PL/ auf dezentralen Systemen Beschränkte Bildschirm-Anschlussmenge System wurde nach Jahren nicht mehr hergestellt Wartung wurde Jahre darauf eingestellt Akutes Problem und Risiko, den Betrieb aufrecht erhalten zu können Ablösung der Hardware war vordringliches Problem Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 6/3

4 Projekt im Raffer: Migration Phase SNA/LU0 (9600B) asynchron, seriell Mainframe (MVS/IMS) Dezentraler Server (S/, RPS) asynchron Terminal-Subsystem seriell (CTOS/BTOS) asynchron seriell Einschränkung auf 32 Bildschirme pro dezentralem Server wurde in dieser Phase gelöst Zusätzliche Applikationsfunktionen konnten auf den Terminal- Subsystemen bereitgestellt werden (zb Unterstützung zur Offerten- Erstellung) Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 7/3 Projekt im Raffer: Migration Phase 2 PCs mit VT220 Emulation WAN TCP/IP SNA/LU0 (tunneled) Virtuelle S/ Maschine LAN TCP/IP asynchron,telnet Terminal-Subsystem (CTOS/BTOS) Mainframe (MVS/IMS) Dezentraler Server (RS6000 RISC, UNIX) asynchron seriell Dezentraler Server wurde durch ein ausbaubares, modernes System mit RISC-Technologie und UNIX ersetzt Mittels einer Emulation der S/-Hardware konnte die bestehende Spezialsoftware und dezentrale Applikationssoftware (Assembler, PL/) unverändert übernommen werden Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 8/3

5 Projekt im Raffer: Migration Phase 3 Mainframe (MVS/IMS) WAN TCP/IP SNA/LU0 (tunneled) Virtuelle S/ Maschine LAN TCP/IP PCs mit VT220 Emulation asynchron,telnet PCs mit Win 95 GUI-Frontend Dezentraler Server (RS6000 RISC, UNIX) CORBA Middleware (ORBIX) Terminalsubsysteme wurde durch PCs mit der üblichen graphischen Oberfläche abgelöst Die Hostapplikation wurde durch eine CORBA-konforme Schnittstelle für beliebige Applikationen zugänglich gemacht Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 9/3 Migrations-Kriterien: Was ist Migration? Herkunft: lateinisch migratio -> Auswanderung, Wegzug Verwendung: Technische Abwanderung Evaluations-Aktivität (Mining gemäss Mombray) Erhaltenswerte Komponeten bewahren oder verbessern Wertlose und schwer zu wartende Komponenten ablösen und ersetzen Migration betrifft in der Regel die Technologie oder das Umfeld: Umstellung auf neues Paradigma (zzt zb OO, DOC, C/S) Organisatorische Umstellung der Geschäftsstruktur (zb kundenorientiert statt prozessorientiert) Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 0/3

6 Migrations-Kriterien: Komponenten migrieren Es gibt keine generelle Kochbuch -Regel Analyse des bestehenden Systems ist notwendig (s Mobray Mining Process ) Legacy-Datenbestände Daten sind in der Regel zu wahren Präzision bei der Migration von Daten ist vital Legacy-Algorithmen und -Abläufe Können in der Regel ersetzt werden Auch hier ist der Mining -Prozess wichtig Überraschungspotential von Unentdecktem ist gross Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland /3 Migrations-Kriterien: Anforderungen Big-Bang -Ersatz ist unerwünscht Betrieb darf nicht beeinträchtigt werden System-Verfügbarkeit muss gewährleistet werden Parallel-Betrieb von Alt- und Neu-System sollte für beschränkte Zeit aus logistischen Gründen möglich sein (zb 3000 Systeme ersetzen) Benutzer sollten nur positive Veränderungen zu spüren bekommen Migrations-Prozess wird oft zu spät begonnen und muss unter grossem Zeitdruck abgeschlossen werden Performance-Einbussen müssen vermieden werden Kosten im Rahmen halten System sollte wieder oder besser wartbar sein Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 2/3

7 Migrations-Kriterien: Risiko Komplexität nimmt wegen zugefügten Abstraktionsschichten und System-Komponenten in der Regel zu muss abbaubar sein Zugefügte Migrations-Schichten sollten jeweils eine neue logische und allgemeiner verwendbare Abstraktions-Ebene bringen, sonst lohnt sich der Aufwand nicht Start auf der grünen Wiese gilt hier nicht Ideen sind gefragt Ohne Architektur und konsequente Durchsetzung läuft man Gefahr, aus Legacy-Systemen komplexe Legacy-Systeme zu machen Terminierung kurzfristig: Unmittelbare Problemlösung Pragmatik mittelfristig: allgemeinere Lösung suchen Architektur langfristig: Problem an der Wurzel packen Komplexitätsabbau Kunde zahlt ungern für System-Architekturen guter Verkauf nötig Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 3/3 Systemarchitektur: Ausgangssituation SERIES/ Mask* Repository MPP/BIP Borroughs ET00 SNA/LU0 HOST IMS MPP/SNA Communication Manager RPS-Betriebssystem HIM TAM TIM LOG APM APM2 Meldungs* Repository System-Komponenten Dezentrale App-Komponente* Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 4/3

8 Systemarchitektur: Ausgangssituation RPS: Multitasking-Betriebssystem mit SVC-Call-Ebene Communication-Manager erlaubt Interprozesskommunikation zwischen den Tasks mit Meldungen MPP/SNA Task für SNA-Kommunikation zum Host MPP/BIP Task für Terminal- und Drucker-Kommunikation HIM: Hostinterface Manager verwaltet offene Host-Verbindungen TAM: Terminal Access Manager verwaltet aktuelle Terminal- Verbindungen TIM, LOG: Hilfstasks Timer und Logging APM: Applikations Programm Manager ist dezentraler Teil der Applikation Masken- und Meldungs-Repository: Abhängig von der Transaktion und von der Sprache werden die Bildschirmmasken aufbereitet Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 5/3 Systemarchitektur: Hardwareablösung MFT Mask Repository TCP/IP Sockets TERMINAL ROUTER TCP/IP Sockets UNIX/IPC/Queues TRVC Terminal Emulator TCP/IP PC IMS SNA/LU0 RS6000 SNA Service LUI Virtual Series/+RPS Message Handler HIM TAM TIM LOG APM APM2 Meldungs* Repository Application-Server VS/ (RS6000/AIX) SSW-Komponenten +DezentAppKomp UNIX-Komponenten Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 6/3

9 Systemarchitektur: Hardwareablösung Die S/ Hardware wurde durch einen UNIX-RISC-Rechner und eine Emulation der S/-Hardware mit RPS ersetzt Performance: ~Faktor 5 schneller Neue Integrationsmöglichkeiten mit UNIX-Tasks dank Message Handler über UNIX-IPC-Queues Message Handler ersetzt Communication Manager TRM: Terminal Routing Manager ersetzt MPP/BIP LUI: LU0 Interface ersetzt MPP/SNA TRM: Anbindung für alte Terminal-Subsysteme (MFT) über Sockets/ TCP/IP höherer Durchsatz, bessere Konnektivität TRVC: ET00 Emulator für VT320 simuliert MFT Unix-Tasks wurden objektorientiert entworfen und mit C++ implementiert bessere Wartbarkeit Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 7/3 Systemarchitektur: System-Öffnung Desktop (PC/Windows/95) Applikations Frontend MFC-Framework (MS VC++) DIF/ORB-Client CORBA-Middleware (ORBIX) Logische Schnittstelle nach aussen Fremdapplikation DIF Datainterface-Service Navigation Tables TCP/IP Sockets TERMINAL ROUTER Mask Repository Virtual Series/+RPS Message Handler HIM TAM TIM LOG APM APM2 Meldungs* Repository RS6000/AIX Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 8/3

10 Systemarchitektur: CORBA-Öffnung DIF-Service: Datainterface schliesst sich an die VS/ wie ein TRM an DIF-Service: Der CORBA-konforme Service nach aussen Masken-Repository (~800 Files) werden durch ein Navigations- Repository (2 Files) ersetzt Dezentraler Teil der Applikation und Systemsoftware auf VS/ bleiben unverändert Client-Seite: Auf MFC aufgebaute graphische Benutzerschnittstelle greift über die DIF-Schnittstelle auf die Applikations-Daten zu Client-Abstraktions-Sicht: Das Client- Programm bekommt eher eine Datensicht (wenn auch nicht 00%), statt die bisherige Maskensicht Mit Smart-Proxys und Call-Backs wird die Netzbelastung minimiert Fremdapplikationen erhalten Zugriff über die gleiche Schnittstelle Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 9/3 Leagacy-Daten-Migration Maskenbeschreibungen (Text) Administrator PC *navtbcnf Server (Runtime) DIF HOST Konversion Meldungs- und Listen-Repository Verwaltung Meldungstrukturen (PL/) Repository *h VC++ Client (Compile-Time) Die Erstellung der Navigations-Repository erfolgt weitgehend automatisch Korrespondenz zwischen Client und Server erfolgt mit Id-Nummern Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 20/3

11 Design: Interface Modell DIManagerIF newsession( ) closeall( ) howmany( ) DISessionIF getfield( ) putfield( ) close( ) getviewinfo( ) geterror( ) isready( ) getlist( ) getctrllist( ) getinfoline( ) getstatusline( ) cancel( ) accept( ) navigate( ) putconfig( ) getconfig( ) makeclone( ) load( ) update( ) DIListIF first( ) next( ) select( ) discard( ) getitem( ) prev( ) putitem( ) load( ) Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 2/3 Design: Interface Modell Drei Schnittstellen DIManagerIF: Session-Factory, eigentlicher Service DISessionIF: Virtuelle Session für Datenzugriff DIListIF: Auflistung am Bildschirm werden als einfache Datenliste präsentiert (getlist()) Grundsatzmoell: M (Modell) V (View) C (Controller) DIF Modell Abstraktion Datennetz mit Records: navigate(), putfield(), getfield() Steuerung (Host) wird dem Client weitergeleitet getviewinfo() Maskenabhängige Funktionen werden möglichst durch Server betätigt zb SignOn (newsession()) Konfiguration (putconfig(), getconfig()), Statusinfo (getstatusline(), getinfoline()), Fehlerinformation (geterror() als FIFO) Optimierung durch Caching und Smart Proxy (load(), update()) Applikationssteuerung (neue Funktion) getctrllist() Synchronisation durch Call Back (isready()) Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 22/3

12 Design: Typischer Ablauf aclient asession : DISessionIF 3: Client sets up views 8: DialogProcessing : isready ( ) 2: getviewinfo (out string, 4: getinfoline (out string) 5: getstatusline (out 6: getfield (in DIFId, out DIField()*) 9: putfield (in DIFId, in DIField()*) 0: accept ( ) 2: isready ( ) * means more than oncel 7: load (out DIFieldBundle) Caching Processing in SmartProxy only : update (in DIField Synchronisation 2 Client bekommt die Information über den geladenen Modellteil 3 Die zugehörige View wird im Client angezeigt 4 Zusätzliche Infos und Infos 5 von der Statuszeile werden abgeholt 6 Die Felder werden zugegriffen 7 und im Userinterface angezeigt 8 Der Benutzer bearbeitet die View 9 Die modifizierten Daten werden aktualisiert 0Der Client löst die nächste Transaktion aus Der Server konvertiert die Daten (EBCDIC) und leitet sie an den Host weiter 2Resynchronisation beginnt Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 23/3 Implementation: Software Architektur MSGCOM SESSION DIFManager DIFSession RWTOOLS U LISTMGR DIIList DIFList DIF ErrItem DIIManager DIISession U KKLib ORBIX MSGNAVIG MsgNavMgr ListNavMgr MsgNavMapper ListNavMapper MSGVIEW MSGFrame LSTFrame global U CONVTABS Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 24/3

13 Implementation: Integration & Wiederverwendung Event Dispatcher (from MSHCOM) Dispatcher ActiveStation MSGManager (from MSHCOM) readcnftoken( ) shutdown( ) InactiveStation DIFManager TRMManager n n MSGChannel (from MSHCOM) DIFSession TRMChannel Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 25/3 Implementation: Integration & Wiederverwendung Das Protokoll zum dezentralen Applikationsteil (VS, via MSH und TAM) wurde belassen Das im Terminal Routing Manager verwendete Miniframework (MSGManager, MSGChannel) mit seinem MSH-Protokoll konnte unverändert übernommen werden Die von diesen beiden Klassen abgeleiteten TRMManager und TRMChannel behandeln die Verbindungen nach aussen über Sockets Für das Datainterface werden analog DIFManager und DIFSession abgeleitet, welche dann das Objekt-Interface (Server-Stubs) für die CORBA-Anbindung bieten Der MSGManager kann über eine externe Datei für die gewünschte Zahl von möglichen Sessions und deren Benennung konfiguriert werden Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 26/3

14 Implementation: Kern des Datenschnittstelle DIManager BOAImpl (from ORBIX) Server- Classes for CORBA Object DISession BOAImpl (from ORBIX) RWCollectable V V DIIManager 0n DIISession ExtInterface MsgNavigator MsgNavMgr (from MSGNAVIG) DIFMgr DIFManager (from SESSION) LstNavigator ASCII_ EBCDICTab (from CONVTABS) ListNavMgr (from MSGNAVIG) ConvTab DIFSess DIFSession (from SESSION) MsgActFrame ErrList ErrItem Text : RWCString FieldId n : unsigned short AliasId : unsigned short CurMsg MSGFrame (from MSGVIEW) SMessage (from SMSG) Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 27/3 Implementation: Kern des Datenschnittstelle Anbindung an die vom IDL-Compiler generierten CORBA-Klassen erfolgt über die Vererbung der BOA-Klassen Die Server-Implementation wird über DIIManager resp DIISession unter Verwendung eines TIE-ähnlichen Ansatzes gemacht, damit das bestehende Framework verwendet werden kann (keine Mehrfachvererbung) Die Navigation erfolgt direkt auf der vom Host gesendeten Meldungen, womit das bisherige Masken-Repository wegfällt Sowohl die Listenklassen (ListNavMgr), wie auch die Meldungsklassen (MsgNavMgr) können von aussen konfiguriert werden, womit ein Release-Wechsel ohne Neuerstellung des Servers geht Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 28/3

15 Implementation: Optimierung Durch den Einsatz von Smart Proxys auf der Client-Seite konnten folgende Eigenschaften integriert werden: Der Client kann für die Synchronisation beliebig isready() abfragen (zb im Windows-Loop), ohne das Netz zu überlasten Die wichtigsten Feld-Daten einer aktuellen View werden beim ersten Zugriff (getfield()) auf den Client geladen (load()) und danach lokal zugegriffen (auch bei Listen) Aktualisierung erfolgt nur für geänderte Felder unabhängig vom Client-Programm Integration für automatisches Signon mit dem Security-System erfolgt vom Client verdeckt im Proxy Das asynchrone Verhalten des Servers (meldungsorientiert) wird mit einem Call-Back-Interface zurück zum Client kommuniziert Zugriffe auf CORBA-Sequences werden durch das Smart Proxy vereinfacht Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 29/3 Schlussfolgerungen: Kompromisse Die Applikationsarchitektur der Mainframe-Seite (hier Bildschirm- Orientierung) liess sich nicht ganz verstecken Die Client-Abhängigkeit (datenmässig) vom Server ist nach wie vor vorhanden (Feld-Identifikationen), was eine Laufzeit-Versionskontrolle notwendig machte Die bestehende Applikation musste möglichst unverändert bleiben Eine erhöhte Komplexität wurde in Kauf genommen, muss bei einem Redesign dann wieder abgebaut werden Einsatz von Visual C++ auf der Client-Seite Visual C++ bewirkte, dass dadurch der Client heavy wurde Für reine Informationszwecke könnte als Alternative JAVA mit Browser eingesetzt werden, um den Client wieder leichtgewichtig zu machen mit OrbixWeb jederzeit möglich Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 30/3

16 Schlussfolgerung: Erkenntnisse aus dem Projekt Der geeignete Migrations-Pfad muss für jedes System individuell angeschaut werden, wenn sich mit der Zeit sicher auch hier bestimmte Muster herauskristallisieren lassen CORBA-Tools sind eine Hilfe und problemlos einsetzbar Es wird in der Regel zuviel über die Werkzeuge diskutiert, statt dass man sich mit dem Design von verteilten Applikationen auseinandersetzen würde Die Definition einer übergeordneten Architektur und der Interface- Frameworks für CORBA-basierte Applikationen innerhalb der IT- Organisation hat sich als sehr positiv erwiesen Kommunikation zwischen Mainframe-, Server- und PC-Client-UI- Entwickler ist ein lebenswichtiger Punkt für den Erfolg des Projektes Der Wartbarkeit und Betreibbarkeit von verteilten Applikationen muss während der Entwicklung Rechnung getragen werden Gute Mischung von Pragmatik und Systematik ist gefragt Copyright 996,97 by Object Engineering GmbH, Zürich, Switzerland und Telecom PTT, IT22, Ostermundigen, Switzerland 3/3