Hans Hellmann SOA in der Praxis Köln, 18. Mai 2009 Eine Lösung für alle Webservices

Mai 2009 Seite 2 Herausforderung Die bestehenden Mainframe Applikationen sollen mit einem DMS-System im OpenSystem Umfeld interagieren.

Mai 2009 Seite 3 Zeitlicher Rahmen  Integrationstest DMS-Mainframe beginnt im Januar 2009  Bis dahin muss eine Lösung „produktionsreif“ vorhanden sein.

Mai 2009 Seite 4 Zeitachse August 2008  Wir verfügen über Softskills:  Kennen die Schnittstellen unsers künftigen DMS Systems  Kennen unsere eigenentwickelten Mainframe Applikationen  Haben 85 Prozesse identifiziert, die mit dem DMS interagieren sollen  Davon ca. 40 vom Mainframe zum DMS  Der Rest vom DMS zum Mainframe Systemresourcen:  Z-VSE 4.1  CICS TS 1.1  TCP/IP VSE Vers. 1.5E

Mai 2009 Seite 5 Unser Fusionspartner verfügt über  EntireX für die Kommunikation zwischen Eigenentwicklungen auf der Basis von Natural und dem OpenSystem.  Skills zur Erstellung von Webservices auf der Basis von Dotnet.  Erfahrung bei der Interaktion von NaturalProgrammen und der Vorgängerversion unseres künftigen DMS.

Mai 2009 Seite 6 Was wir in Mannheim nicht haben ist  Erfahrung, wie man abgesehen von FTP aus Mainframeapplikation mit dem OpenSystem kommuniziert.

Mai 2009 Seite 7 Erster Lösungsansatz Auch wir setzen für die Kommunikation mit dem DMS auf EntireX „Wir kennen uns damit aus.“ „Es hat sich bei uns bereits bewährt.“ „Es ist ja schon vorhanden.“  Warum ?  Weshalb ?  Weswegen ?

Mai 2009 Seite 8 Rückfragen beim Hersteller ergaben:  Auch im PL/I mit VSE ist die Kommunikation mittels EntireX und einer zentralen Hostkomponente in beide Richtungen möglich.  Benötigt werden:  Eine Testinstallation wird vereinbart  Ein Broker PC,  und nicht unerheblich:  eine Hostkomponente Eine Lizenzvereinbarung

Mai 2009 Seite 9 Zeitachse September 2008  Broker PC und Entire/X Hostkomponente sind eingerichtet.  Zeitdauer ca. 12 Tage  Erster Test:  Zweiter Test:  DMS ruft Hostapplikation  klappt  Hostapplikation ruft DMS  klappt nicht

Mai 2009 Seite 10 Die Analyse beginnt  Die zentrale Komponente funktioniert nicht out of the box. Es ergibt sich nach und nach...  Es wird Eclipse mit Herstellerweiterungen zur Generierung benötigt.  Die Generierung von PL/I Code für VSE funktioniert erst nach einer Vielzahl von „Workarounds“ und massiver „Nachbesserung“ des Werkzeugs durch den Hersteller.

Mai 2009 Seite 11 Die Analyse geht weiter...  Die Verwendung einer zentralen Hostkomponente ist entgegen der mündlichen Herstellerzusagen nicht möglich... die Zeit bis Januar 2009 vergeht zunehmend schneller,... die Frequenz der Hiobsbotschaften steigt. Der Hammer:

Mai 2009 Seite 12 Zeitachse Oktober 2008  und daß die generierten Copybücher für PL/1 manuell zu modifizieren sind  ein eigener XML-RPC Server zu generieren ist,  ein eigenes Stubprogramm zu generieren ist, für jeden anzusprechenden Service in Salamitaktik ergibt sich, daß

Mai 2009 Seite 13 Zeitachse November 2008  Zweiter Test „die Zweite“:  Hostapplikation ruft DMS  klappt endlich  Aber:  Nur für eine kleine Applikation mit wenigen Para- metern.  Der Aufwand für umfangreichere Applikationen mit zahlreichen Parametern ist viel zu groß.  Das Handling in der Breite ist nicht praktikabel.

Mai 2009 Seite 14 Fazit des ersten Lösungsansatzes Diesem Lösungsansatz

Mai 2009 Seite 15 Erkenntnis (1)  eine wirklich zentrale Lösung auf der Hostseite,  die zuverlässig, performant,  für die Interaktion mit allen Webservices,  übersichtlich und praktikabel ist. Wir brauchen

Mai 2009 Seite 16 Erkenntnis (2)  der hält was er verspricht,  der weiß wovon er spricht, und ganz wichtig einen Partner  der kurze Wege hat und  der flexibel und schnell agiert.

Mai 2009 Seite 17 Die Idee

Mai 2009 Seite 18  Kurzfristige Terminabsprache für eine Demo der Firma Lattwein  Die Anforderungen werden kurz umrissen Von nun an geht es Schlag auf Schlag  Telefonat nach Düren  Zum Termin steht ein Prototyp der überzeugt

Mai 2009 Seite 19 Gemeinsam (1)  für die Hostseite mit den Spezialisten der Firma Lattwein werden die Anforderungen konkretisiert  eine Komponente für die Kommunikation aus CICS  eine Komponente zur Kommunikation aus Batch  Jeweils zu beliebigen Webservices

Mai 2009 Seite 20 Gemeinsam (2)  für die OpenSystemseite  eine Listenerkomponente  Als Dienst unter Windows  Alternativ als Linuxvariante  Wichtig: Multisessionfähig

Mai 2009 Seite 21 Für die „CICS-Komponente“  werden vereinbart  Aufruf mit EXEC CICS Link  Datenübergabe über TS-Q und Commarea  TS-Q für die „Arbeitsdaten“ des Webservices  Vereinbarte Länge max Bytes  Commarea für die „Steuerungsdaten“

Mai 2009 Seite 22 Struktur der Commarea Ab StelleLängeFormatInhalt 18char*PL1STUB 9253charUrl des Zielwebservices charAuszuführende Aktion

Mai 2009 Seite 23 Für die „Batchkomponente“  Werden vereinbart  Aufruf mit Call  5 Übergabeparameter  Analog zur „CICSkomponente“

Mai 2009 Seite 24 Übergabeparameter für Batch ParameterLängeFormatInhalt 18char*PL1STUB 2253charUrl des Zielwebservice 3253charauszuführende Aktion charInput „Arbeitsdaten“ charOutput „Responsedaten“

Mai 2009 Seite 25 Zeitachse Dezember 2008  Die Lattwein-Lösung ist bei uns implementiert  Aufwand für die Hostkomponente  max. 2 Stunden  Aufwand für ListenerKomponente  max 30 Minuten  Die ersten Dialogprogramme sind umgestellt Klappt  Die Kommunikation mit dem DMS-System

Mai 2009 Seite 26 Anbindung Mannheim über WebServices HOSTPC WBG200 Listener WBG210 PL/1 Dialog PL/1 Batch PL/1 STUB eigentliche Services

Mai 2009 Seite 27 Vielen Dank für Ihre Aufmerksamkeit!!