Web service baseret integration mellem CICS og Windows

DTU Danmarks Tekniske Universitet IMM Institut for matematisk modulering Kandidatspeciale Web service baseret integration mellem CICS og Windows Kongens Lyngby 29. marts 2010 Vejleder: Hubert Baumister Udarbejdet af: Studie nr. Navn Underskrift S012252 Bobbi B. Nielsen

Resumé Denne rapport belyser implementeringen af Web services i et testmiljø hos KMD. Hvor KMD har et ønske om, måske, at anvende Webservices i fremtiden. Der bliver i dette projekt kigget på implementeringen af en CICS Web-service baseret løsning. Denne løsning kan kun i nogen grad erstatte den allerede eksisterende løsning (ZSRØR). Endvidere har jeg beskæftiget mig med konvertering af gamle servicebeskrivelser, således de kunne anvendes i Web Service løsningen Executive summary This report highlights the implementation of Web services in a test environment at KMD. KMD might have the desire, perhaps, to use Web services in the future. It is in this project, I had worked with the implementation, of a CICS Web service based solution. This solution, can only partially, replaces the existing solution (ZSRØR). Furthermore, I have been dealing with conversion of old service descriptions, so they could be used in Web Services solution. 2/41

Forord Dette projekt er lavet i sammenarbejde KMD, som et kandidatspeciale. Arbejdet er udført blandt andet fordi KMD A/S ønskede at få belyst netop brugen af Web services i deres system. På dette projekt har Hubert Baumister været vejleder fra DTU side. På KMD har jeg hele CICS gruppen anno 2009/2010 at takke for hjælpen med dette projekt. 3/41

Indholdsfortegnelse Resumé... 2 Forord... 3 Indholdsfortegnelse... 4 1 Rapportopbygning... 6 1.1 Overordnet struktur... 6 1.1.1 Problemområde... 6 1.1.2 Teori... 6 1.1.3 Analyse... 6 1.1.4 Implementering... 6 1.1.5 Konklusion... 6 1.1.6 Perspektivering... 7 2 Problemområde... 8 2.1 Problemidentifikation... 8 2.2 Problemer med at skifte til Web-service... 9 2.3 Generelle afgrænsninger... 10 3 Teori... 11 3.1 Webservices generelt... 11 3.1.1 Teknologien bag webservices... 11 3.1.2 Opsætning og design webservices... 12 3.2 CICS og CICS webservices... 13 3.2.1 Valg af mapping level... 14 3.3 ZSRØR... 14 3.3.1 ZSRØR servicebeskrivelse... 15 4 Analyse... 16 4.1 Fremgangsmodel... 17 4.1.1 Opsætning af CICS webservice... 17 4.1.2 Simpel socket forbindelse... 17 4.1.3 Anvend.net 3.5 framework... 17 4.1.4 Medtag brugernavn fra Windows... 18 4.1.5 Logning... 18 4.2 Afvejninger... 18 4.3 Andres implementering af Web-services... 19 4.3.1 DSB... 19 4.3.2 Autotaks... 19 5 Test-setup... 20 5.1 Mainframe-side... 20 5.2 Windows computer side... 20 6 Implementering... 21 6.1 Dataopsamling og tests... 22 6.1.1 Opsætning af testmiljø... 22 6.1.2 Simpel kommunikation... 22 6.1.3 Send og modtag data.... 23 6.1.4 Eget framework vs.net Framework... 24 6.1.5 Mapping level... 24 6.1.6 CICS som service provider og service requester... 27 7 Konklusion... 29 8 Perspektivering... 30 8.1 Offload til zaap... 30 8.2 PL/1 til WSDL... 30 8.3 En applikation skifter fra ZSRØR til webservices... 30 9 Litteraturliste... 31 10 Bilagsoversigt... 32 4/41

Tabeloversigt Tabel 1 Data til sammenligning af ZSRØR,.NET og min egen løsning... 24 Tabel 2 Data fra afvikling test med mapping level... 26 Figuroversigt Figur 1: Overordnet rapportstruktur... 6 Figur 2 Beskrivelse af systemet... 8 Figur 3 Eksampel på adgang til 3 parts systemer via et Web Service... 9 Figur 4 Web Service struktur... 11 Figur 5 CICS som requester... 13 Figur 6 CICS data flow... 14 Figur 7 ZSRØR opbygning... 16 Figur 8 viser det flow WSDL et skal igennem for at blive til en proxy i klient programmet... 17 Figur 9 Tegning over den løsning der er blevet implementeret i et test miljø hos KMD... 21 Figur 10 Graf med transaktioner per sekund... 25 Figur 11 Graf med CPU forbrug per transaktion... 26 Figur 12 Procentvis graf med CPU forbrug fordelt... 27 5/41

1 Rapportopbygning Dette afsnit beskriver rapportens opbygning, samt giver en afklaring på centrale begreber anvendt gennem rapporten. 1.1 Overordnet struktur Formålet med dette afsnit er at give læseren et overblik over hvorledes rapporten er struktureret, samt hvilket indhold, der findes i rapportens forskellige dele. Rapportens overordnede struktur er illustreret i nedenstående Figur 1, og uddybet i de følgende afsnit. Teori Analyse Problemområde Implamentering og databehandling Konklusion Perspektivering Figur 1: Overordnet rapportstruktur 1.1.1 Problemområde Denne del af rapporten beskriver den problemstilling, der ligger til grund for rapporten og projektet med KMD A/S. Det er i dette afsnit at projektet bliver defineret. 1.1.2 Teori Teoriafsnittet vil give læseren indblik i de teorier, der bliver anvendt til implementeringen. Her under også en grundig beskrivelse af teorierne. 1.1.3 Analyse I denne del af rapporten vil jeg analyserer mig frem til hvordan, de forskellige problemstillinger kan løses. Endvidere vil jeg præsentere den fremgangsmåde jeg vil følge. 1.1.4 Implementering I dette afsnit fokus på implementeringen, af løsningerne. Dette afsnit indeholder også data opsamling og diskussion heraf. 1.1.5 Konklusion Rapportens konklusionsdel vil indeholde en opsummering af de delkonklusioner, der er fremkommet gennem rapporten. 6/41

1.1.6 Perspektivering Som afslutning på rapporten, vil jeg i perspektiveringsafsnittet diskutere diverse aspekter, der ligger i forlængelse af, eller udover, rapportens rammer. 7/41

2 Problemområde 2.1 Problemidentifikation I dag anvendes på KMD et egenudviklet stykke software (ZSRØR) til at Windows platforme kan forbinde og hente data fra CICS (Customer Information Control System). Der ønskes udarbejdet et design og en prototype til en løsning, som er baseret på Web-services og åbne standarder og hvis funktionaliteter ligner ZSRØRs funktionaliteter. ZSRØR anvender i dag er repository som indeholder alle servicebeskrivelser. Det er ønsket et også CICS WS skal anvende det samme repository. Ved netop at anvende det samme repository, undgår man, at skrive de ca. 10.000 servicebeskrivelser om manuelt. For at CICS WS kan anvende samme service repository som ZSRØR, skal der udvikles et værktøj, der kan konverterer den struktur, som servicebeskrivelserne ligger i, til WSDL. Det er derfor vigtigt, at servicebeskrivelserne kommer til, at eksistere, som WSDL, som er standard der bliver anvendt i Web-service UDDI et. Endvidere skal der findes/udvikles et værktøj, som kan konvertere fra WSDL til PL/1 struktur, således at de Windows applikationer der bruger ZSRØR stadig kan anvendes. Figur 2 Beskrivelse af systemet På Figur 2 ses en tegning over den eksisterende ZRRØR-løsning, kombineret med den nye Webservice-løsning. Det fremgår af, den del af tegningen markeret ønsket at der bliver brugt CICS Web-service (CICS WS) til kommunikations i stedet for den kommunikationslogik, som i dag bliver anvendt til ZSRØR. ZSRØR bruger et helt sæt af dll-filer som skal installeres på klienten for at ZSRØR kan fungere. Dette er en ting man også gerne vil ud over, ved at anvende et.net Framework. Ved at bruge.net Framework bruges udelukkende filer der er supporteret af Microsoft. 8/41

Når en af KMDs udviklere skal lave en ny Windows applikation, som skal anvende adgang til CICSprogrammer, har udvikleren i dag mulighed for at få ZSRØR til at generere et skelet program, hvilket gøres ud fra servicebeskrivelsen. Systemet er i dag sådan opbygget, at det umiddelbart, er begrænset til, at skelet kode skal gøre i sprogene C, C++ og Visual Basic. Hos KMD ønsker man fremadrettet at Web-services-løsningen skal kunne udvikle skeletkode til C# I servic-repository ligger alle servicebeskrivelser som PL/1 kode. Denne PL/1 kode bliver i dag anvendt af ZSRØR, til at generere skelekoden. Den nye løsning skal anvende WSDL filerne til at generere skeletkode. I dag bruges CICS kun som service provider. Hos KMD ønsker man, at få belyst, muligheden for, om CICS ville kunne anvendes som service requester i KMDs system. Ved at anvende CICS som service requester, til at hente og sende data til et system, som ligger uden for KMD s interne services. Disse serveces ville så kunne præsentere som en service i CICS. Web-servicen k anvendes af KMD s udviklere. KMD udvikler Webservice request CICS Webservices Provider 3 parts system fx dsb.dk CICS kald Webservice request CICS Webservices Requester Webservice request 3 parts system fx krak.dk Figur 3 Eksampel på adgang til 3 parts systemer via et Web Service På Figur 3 ses et eksampel på, hvordan CICS kunne bruges som service requester. I tilfældet på figur 3 hentes data fra både Krak og DSB, som bliver præsenteret for udvikleren i en enkelt service. Udvikleren kan nu bruge sit KMD brugernavn og password til at få data fra DSB og Krak. Samtidig ønskes det, at der føres en log, der kan angive præcist, hvilken bruger, der har requested hvilke data hvornår. Denne log funktion ønskes på CICS siden, således den kan kombineres med det logningssystem, som allerede findes i KMD. 2.2 Problemer med at skifte til Web-service Hos KMD anvender man i dag ZSRØR. Den model ZSRØR er implementeret efter ligner til forveksling Web-service-modellen. Der er dog to store forskelle; den største er UDDI et/ service repository/ service broker, ikke har servicebeskribelserne liggende som WSDL filer. Så her vil der komme en udfordring med at konvertere alle servicebeskrivelserne til WSDL. Det ville være en naturlig fremgangsmåde, at udvikle, et stykke software, til at automatiserer en sådan konvertering, alene fordi UDDI et indeholder mere en 10.000 servicebeskrivelser, samt at en manuel løsning ville være en meget stor og meget tidskrævende løsning. 9/41

Fordi der kommer nye applikationer til en gang i mellem, kunne det være en løsning at nøjes med at lave de nye services efter Web-servicemodellen. Den anden forskel ligger i den måde, hvorpå ZSRØR-klienten kommunikerer med serverne. Dette sker gennem en KMD udviklet tekstprotokol. Dette giver dog ikke noget problem, efter som der bliver brugt SOAP, hvis der skiftes til Web-servicemodellen. En anden udfordring, som der vil opstå, er den måde, hvorpå CICS pipelines bliver vedligeholdt. Normalt er det kun et portnummer til en CICS. Men hvis nogle CICS skal kørerer Web-service sammen med ZSRØR services, kommer der til at være to portnumre til disse CICS regioner, dette vil kunne give en udfordring i den database som holder styr på hvilke portnumre der hører til hvilke CICS. En ting mere, der kommer til at give udfordringer, er alle de programmer, der i dag anvender ZSRØR dll-filer disse programmer vil skal alle sammen kodes om, så de derved kommer til at understøtte Web-service. 2.3 Generelle afgrænsninger Den nye løsning skal opfylde følgende krav: - Medtage credentials fra Windows maskinen til CICS Web-service. - Føre en log, som angiver, præcist hvilken bruger, der har haft adgang til hvilke data og præcist hvornår. - Håndtere minimum 300 transaktioner per sekund (på CICS siden). - Få CICS til at hente data fra tredjeparts databaser og SAP PI/IX. - Være kompatibel med Windows XP, Windows Vista samt Windows 7. - Det skal være nemt at bruge en ZSRØR baseret Windows klient sammen med den nye løsning. - Det skal også undersøges, hvorvidt den nye løsning kan bruges som grundlag for at erstatte ZSRØR i fremtiden. 10/41

3 Teori I dette afsnit præsenteres teorien og koncepterne bag de forskellige bygge sten, der har gjort det muligt at gennemføre projektet. 3.1 Webservices generelt Web-services er en kommunikationsmodel der kan vælges, når der skal udveksles informationer fra applikation til applikation. I modsætning til den kommunikation der forgår mellem en Webserver og en browser, giver Web-service ikke noget grafisk tilbage til brugeren. Web-services er ikke platforms- eller applikations- afhængige, eftersom der bliver anvendt en åben standard til kommunikationen. Her er der tale om HTTP, XML, SOAP og WDSL. WSDL Service Broker (UDDI) WSDL Service Requester SOAP Req. SOAP Res. Service Provider Figur 4 Web Service struktur På venstre side er Service requesteren (PC der køre.net Framework applikationen) til højre er Service provideren (Mainframe med CICS Web-service). Øverst er service brokeren, som indeholder en liste over, hvilke services der findes i systemet, samt tilhørende WSDL filer. Denne liste bliver opdateret, hver gang service provideren har en ny service, som kan tilbydes. Samtidig med at service brokerens liste bliver opdateret, modtages en WSDL fil fra service provideren. Listen samt WDSL filerne bliver så udstillet, så service requesteren kan få fat i den. (F. eks. via en FTP eller HTTP server.) Service requesteren kan nu hente WDSL filen og derved få informationer om, hvorledes der skal kommunikeres med en given service (adresse, input og output). 3.1.1 Teknologien bag webservices Med Web-service teknologien er det muligt at bruge eksisterende forretningslogik og efterfølgende udstille det som en Web-service. Dette gør der ikke er behov for at investere stor summer, for at kunne tilbyde forretningslogik over internettet. Web-service er opbygget af flere kendte teknologier. 11/41

3.1.1.1 XML Extensible Markup Language, som er en åben standard specifikation, lavet af W3C. XML er designet specifikt til webdokumenter. XML tillader, at udvikleren laver sine egne tags, som så kan bære data fra system til system. 3.1.1.2 SOAP Simple Object Access Protocol, er en XML baseret protokol til at pakke requests og respons ind i, inden det bliver sendt ud over et netværk. Det kan sammenlines med en almindelig kuvert som man bruger til at sende breve. SOAP er ikke operativsystem afhængig, det eneste der kæves i den anden ende er en brevåbner. 3.1.1.3 WSDL Web-services Description Language. Er et XML-formateret sprog, som anvendes til beskrivelse af Web-servicen og dens muligheder. Her er tale om den fi,l der indeholder strukturen på input og output, samt adressen på serveren, der udbyder Web-servicen. Basalt set er det denne fil, der indeholder opskriften på, hvordan requester og provider skal snakke sammen. 3.1.1.4 UDDI Universal Description, Discovery and Integration, er den telefonbog, der indeholder alle WSDLfilerne. Der er her, en klient kan se, hvilke Web-service der kan tilbydes. Når en ny Web-service kan tilbydes af en provider, skal provideren selv meddele UDDI et, at der findes en ny service. 3.1.2 Opsætning og design webservices Angående Web-service opsætning af er der tre designmuligheder en Web-service kan designes på. Alt efter hvad der er adgang til, inden man går i gang, er der forskellige løsninger til forskellige scenarier. - Top-down method hvor servicen bliver skabt ud fra en eksisterende WSDL fil. - Bottom-UP method hvor WSDL filen bliver lavet ud fra den applikation, man ønsker at udstille som en service. - Meet in the middle method (MIM) er en løsning, hvor der bliver lavet et WSDL fra en eksisterende applikation. Denne WSDL kan så modificeres for at give requesteren et anderledes data interface end det, der var tiltænkt i applikationen. - For at den modificerede WSDL kan bruges sammen med den applikation, der er udstillet som service, skal der laves en Wrapper. Wrapperen forbinder strukturen i XML et med servicen. Denne løsning kan anvendes, hvis der ikke er mulighed for at lave servicen om. 12/41

3.2 CICS og CICS webservices CICS er en transaktions server, som i stor stil bliver anvendt på IBM Mainframes, som kører Z/OS. Det er et system, der er udviklet med det formål at kunne håndtere mange samtidige transaktioner. En transaktion kunne bestå i en opgave såsom, at hente data fra et datasæt /database eller afvikle batch job. Når CICS bliver anvendt i et firma, er der minimum tale om tre CICS: Udvikling. Test. Produktion. Men der kan i princippet være lige så mange man ønsker. Man kunne f. eks. vælge at lægge en CICS ind foran sin produktions CICS, og denne CICS kunne så håndtere al adgangskontrol. Et CICS-kald kommer altså til at se således ud: Pipeline Access CICS(CICS 1) Requester CB1 CB2 CB3 Giv adgang til produktions CICS Pipeline Produktions CICS (CICS 2) CB1 CB2 CB3 Forretnings logik (Hent data) Figur 5 CICS som requester På Figur 5 ses et eksempel hvor to CICS er lagt i forlængelse af hinanden. Som det kan ses rammer requesteren en pipeline. En "pipeline" i CICS er den kommunikationskanal CICS anvender til at ind- og udgående trafik. En CICS kan godt have flere pipelines. F.eks. kan der godt defineres en til Web-service og en til FTP-trafik. CICS Web-service er den del, som gør det muligt at anvende en CICS transaktion via et XML kald. For at kunne udføre denne opgave, skal der løses nogle andre opgaver først. CICS skal vide hvordan inputs / outputs fra XML et skal mappes over til CICS transaktionen. Denne information skrives i en "bind"-fil og samtidig, med den bliver lavet, laves en WSDL fil. Denne WDSL fil indeholder beskrivelse af, hvilke felter der skal sendes, samt hvilke der forventes at komme retur fra CICS. WSDL et sendes nu til service brokeren, så at en klient kan få fat i den. Herefter skal der defineres en pipeline i CICS som afventer requests til Web-servicen. 13/41

TEST CICS Web Services CB1 Pipeline CB2 CB3 Data mapper CICS Applikation HTTP Request Bind file Figur 6 CICS data flow På figur 6 ses det flow, som et reguest via Web-services medfører. Først bliver XML en behandlet, hvorefter "bind"-filen bliver anvendt for at kunne mappe data over til CICS applikationen. Men inden Web-servicen kan tages i brug, skal der som bekendt, laves en WSDL og en "bind"-fil. Til dette formål findes et lille værktøj som IBM har lavet: DFHLS2WS. DFH er det akronym, som IBM har valgt for CICS, LS er for Language structure, 2 er for til og WS er for Web- service. DFHLS2WS skaber så, ud fra en program kode, en WSDL fil samt en "bind"-fil efter "bind" filen er blevet loadet af CICS, er CICS Web-services klar til sit første kald. 3.2.1 Valg af mapping level Når DFHLS2WS skal afvikles, er mapping level et af de parametre der skal sættes. Mapping er det regelsæt, der bestemmer, hvordan der bliver mappet, mellem den datastruktur, der findes i den applikation, der er udstillet som Web-service, og WDSL et. I CICS er der mulighed for at vælge mellem 1.0, 1.1, 1.2, 2.0, 2.1, og 2.2. Desto højere mapping level der vælges, jo mere komplekse datastrukturer kan der anvendes i PL/1 koden. 3.3 ZSRØR ZSRØR er et af KMD udviklet produkt. ZSRØR bruges af Windows-maskiner til at kommunikere med CICS TS. Med andre ord bruges ZSRØR til at flytte outputtet fra et CICS program til en Windows maskine, samt tage inputtet fra Windows maskinen og sende det til CICS programmet. CICS programmet kaldes med en veldefineret input og output struktur. Derfor skal Windowsmaskinen kende denne struktur. Dette kan læses i ZSRØR s servicebeskrivelser. ZSRØR klienten har adgang til et repository med servicebeskrivelser, som alle er i form af PL/1 kode. ZSRØR ligner på mange måder Web-servicemodellen. ZSRØR, anvender dog TCP socket + Tekst + ZSRØR servicebeskrivelser til kommunikation. Hvorimod en Web-service anvender http + XML + WSDL for at kommunikere. 14/41

Ved brug af ZSRØR vil udvikleren af CICS programmer ikke mærke noget til det. I CICS udviklerens øjne er der bare tale om et CICS program; han kan ikke se, om det bliver kaldt fra en 3270 terminal eller fra en Windows-maskine. Udvikleren på Windows siden ser heller ikke, om der er tale om en løsning hvor han snakker med en CICS region. For udvikleren på Windows siden har adgang til en dll-fil, som kan kaldes med en datastruktur, denne dll-fil vil så svare med en anden datastruktur. På den måde er ZSRØR sprogneutralt; eneste krav er, at sproget skal kunne kalde en dll-fil. 3.3.1 ZSRØR servicebeskrivelse En ZSRØR servicebeskrivelse er det dokument, der ligger i ZSRØR s servicerepository, som beskriver, hvordan en given service(cics program) skal kontaktes. Her er tale om et dokument, der blandt andet beskriver, hvilke input og output der er til servicen. Servicebeskrivelse er meget lig med WDSL et i en Web-service-løsning. Servicebeskrivelsen skal være tilgængelig, for at en Windows program, der anvender ZSRØR, kan afvikles. Dette skyldes at ZSRØR selv henter servicebeskrivelsen når ZSRØR s dll-filer bliver kaldt. 15/41

4 Analyse Denne analyse skal danne grundlag for hvorvidt Web-service kan implementere hos KMD. Dette vil jeg gøre ved at kigge på hvordan Web-service kan spille sammen med ZSRØR. ZSRØR er en teknologi man i dag anvender hos KMD. Min analyse består opdeling af Web-service systemet, samt en fremgangsmåde til at nå der. Afsnit 4.2 kan det læses hvilke valg jeg har fortaget samt hvorfor. Endelig kigger jeg på hvordan andre har valgt at implementer Web-service. Windows klient (service requester) Mainframe (Service provider) ZSRØR Servicebeskrivelser Windows applikation Proxy datakonvertering datakonvertering CICS service Kommunikations modul TCP Socket Kommunikations modul Figur 7 ZSRØR opbygning På figur 7 ses en oversigt over hvordan ZSRØR interfacet virker med CICS. Det der skal genbruges fra denne løsning er ZSRØR servicebeskrivelserne. Disse servicebeskrivelser ligger i dag som PL/1 datastrukturer. I løsningen hvor der anvendes Web-service vil disse skulle ligge som WSDL filer. Hos KMD har man i dag ca. 10.000 forskellige CICS transaktioner, som man kan få adgang til enten via en 3270 terminal, eller via et KMD produkt, som hedder ZSRØR. For at kunne anvende ZSRØR skal man installere en klient på den pc, man ønsker at opnå adgang til. Eller der skal sættes en proxy foran ZSRØR, som så udbyder ZSRØR servicen som en Web-service. Denne løsning anvendes i dag til nye applikationer, der bliver udviklet i.net Framework. Derfor vil det være en fordel, hvis disse applikationer kunne bruge Web-service direkte til CICS; på den måde ville ZSRØR-leddet blive sprunget over. I ZSRØR er der dog implementeret både sikkerhedsfunktioner og logningsfunktioner. Disse ville man også komme uden om ved at kalde CICS Web-service direkte, frem for at gå igennem en proxy, der er sat op for an ZSRØR. Jeg vil anvende teorien omkring Web-services, for på den måde kunne få udstillet forskellige CICS services. En af de services, jeg har valgt, er zx23800. Dette er en service, der på baggrund af et brugernavn henter data omkring brugeren, så som navn, kommunenummer samt hvilken CICS servicen er blevet kørt på. På den måde vil vise at Web-service-delen formår at bringe input videre til CICS servicen, som så kan slå op i en database over brugere.. 16/41

4.1 Fremgangsmodel 4.1.1 Opsætning af CICS webservice For at kunne sætte en Web-service op skal der først vælges en applikation, som kan laves til en service. KMD har en masse CICS applikationer, som er udviklet udelukkende til test formål. Bland andet findes der en, som hedder ZX23800. Et simpelt program som ikke tager noget input fra brugeren, men som returnerer oplysninger om den bruger, der har kaldt programmet. I og med at programmet ikke forventer noget input, vil dette også være tilfældet, når det er blevet udstillet som en service. For at lave Web-servicen bruges først DFHLS2WS med en bottom up løsning. Den WSDL, der kommer ud af det, kan så bruges som guide til at kommunikere med Web-servicen (ZX23800). Efter som CICS programmet kræver et argument (et brugernavn) laves et fix i "bind"- filen så den altid sender den samme bruger med til servicen. På den måde, laves en service, der altid henter de samme oplysninger. Nemlig dem der tilhører den bruger der er hardkodet ind i "bind"-filen. Nu skal der sættes en pipeline op, i CICS, så den afventer om der kommer nogle requestes på CICS Web-services delen. 4.1.2 Simpel socket forbindelse At lave et program, der bruger den Web-service, der lige er blevet sat op, kræver, at der bliver åbnet en socket forbindelse til serveren. Når forbindelsen er blevet etableret, skal der sendes en http Post med en SOAP i indholdet. SOAP en kan skrives ved at tage udgangspunkt i WSDL et, som blev genereret af DFHLS2WS. På denne måde bliver det data, der bliver sendt, samt de eventuelle afhængigheder til frameworks reduceret til et minimum. Næste skridt er nu at ændre "bind"-filen og wrapperen således, at det bliver muligt at sende inputs til Web-servicen. Her kan det med fordel vælges at gøre det muligt at ændre bruger id, så at det er det id, der bliver sendt med XML et, der bestemmer, hvilke data der bliver hentet. 4.1.3 Anvend.net 3.5 framework I.NET Framework findes der et værktøj, som hedder WSDL.exe. Dette værktøj kan bruges til at generere blandt andet C# kode. Denne kode kan så kompileres til den dll-fil, som igen kan anvendes i et Visual Studio projekt. Klient program WSDL fra service broker WSDL.exe Visual studio reference Proxy Figur 8 viser det flow WSDL et skal igennem for at blive til en proxy i klient programmet Nå først der er kommet styr på denne proces, er næste skridt at begynde at lave tests. Hertil skal der laves et program, der kan sende og modtage så mange transaktioner per sekund så muligt. 17/41

Samtidigt skal der holdes styr på tiden og på hvor mange transaktioner der er sendt gennem systemet. Der skal også laves en datalogningsfunktion, så data kan gemmes til senere data behandling. En anden applikation der skal laves er en, som gør det muligt, at teste forskellen på mappnings levels, for at kunne afklare, om der er nogen forskel på om DFHLS2WS er blevet kørt med mappnings level 1.0 eller 2.2. 4.1.4 Medtag brugernavn fra Windows Der er et ønske om at medtage brugernavnet fra Windows klienten; dette vil kunne løses ved hjælp af.net Framework. I.NET Framework er der mulighed for at bruge et namespace, der hedder system.security.principal, som er en del af.net Framework class library. Ved at anvende denne funktion vil jeg overføre brugernavnet, så jeg kan sende det videre med SOAP en.. 4.1.5 Logning I ZSRØR findes der mulighed for at logge fejl, data og svartsider. For at opnå de samme lognings parametre i en Web-service-løsning, skal der implementeres et lognings framework. Dette kunne være et allerede kendt framework, eller der kunne udvikles et fra bunden. Kigges der på de krav som KMD har til logning. Så ville der rigtige være at gøre det på klient siden. På den måde vil det blive muligt at logge alt hvad det sker. Samtidig vil der også blive brug for et system på server siden som logger hvem der har adgang til hvad. Klinten skal således kun logge data og fejl. 4.2 Afvejninger Til klient programmet vælges sproget C#. C#er ikke det eneste sprog der kan anvendes i forbindelse med udviklingen af.net Framework applikationer. Til dette formål kunne også bruges Visual Basic, C++ eller Java. C# er valgt, fordi sproget er designet specielt til at udvikle.net Framework applikationer. Eftersom det er et krav fra KMD s side at, applikationen skulle kunne afvikles under Windows XP, Windows Vista og Windows 7, faldt valget på C# med.net Framework. Den første applikation vil dog blive udviklet uden at bruge Web-servicedelen i.net Framework, dette sker for at gøre applikationen så simpel som muligt. Der er her tale om en applikation, der kun har til formål at sende en SOAP besked til serviceprovideren og herefter modtage den SOAP envelope, der kommer tilbage. Som provider er CICS valgt. CICS er valgt fordi der er den transaktionsserver der anvendes hos KMD og netop den version af CICS (v 3.2), som understøtter Web-service. Samtidig er CICS den transaktionsserver, man fra KMD s side valgt at benytte. Derfor er det også den, der er interesse i at teste Web-service af på. Der, hvor CICS er valgt som requester, er det fordi det er den nemmeste måde at gøre det gennemsigtigt for brugeren, således han ikke ved om han får fat i en KMD service eller en service fra en tredjepart. 18/41

4.3 Andres implementering af Web-services 4.3.1 DSB DSB har valgt implementering af webservices i DSB's kontor for bilet udskrivning. Her har man blandt andet implementeret en Web-service. Denne service giver mulighed for at både DSB telefonsalg og DSB netbutik kan anvende muligheden for at få billetter printet og sendt til kunden. Så nu er det ikke kun kunder der handler i netbutikken der kan få billetter tilsendt, nu er det også kunder der køber deres billetter via telefonsalget. Det man rent praktisk har gjort hos DSB er: man har taget en allerede kendt applikation, nemlig den der printer billetterne ud fra netbutikken. Denne applikation har man så udstillet som en webservice, på den måde er det muligt, både at bruge applikationen fra netbutikken og fra telefonsalgsafdelingen. 4.3.2 Autotaks Hos Autotaks.dk har man også valgt at implementere webservices. Her har man EJB-baseret serverer. Der snakker sammen Delphi klienter og Windows klienter. Autotaks.dk er et system hvor forsikringsselskaber, taksatorer og værksteder kan ind reportere oplysninger om skader på biler. Her iblandt hvilke dele der skal skiftes ved en given skade, samt en pris på reparationen. I det gamle Autotaks system anvendte man en Mainframe baseret løsning. Hvor man kun kunne få adgang via en 3270 terminal. I deres nye løsning har de valgt at skifte deres Mainframe løsning ud til en EJB-løsning. Dette er valgt for at kunne anvende Web-services. På det tidspunkt hvor autotaks tog beslutningen kunne Web-services ikke anvendes sammen med Mainframe baseret systemer. I dag bruger autotaks så Web-services, som bliver tilbudt til forsikringsselskaberne, taksatorerne og værkstederne. 19/41

5 Test-setup Test-setupet består af to sider; en side som kører på Mainframen og en anden side som kører lokalt på en PC. På KMD s Mainframe findes der en LPAR, som hedder KMDUDV2. Denne er til udvikling og kun udvikling. På denne LPAR kører der så indtil flere CICS regioner. De CICS regioner som er blevet brugt under arbejdet med dette projekt, hedder BCCICSTP og BCCICSTO. I CICS en er der så sat to pipelines op, en så den kan forbindes til via ZSRØR og en så man kan snakke Webservice med den. På PC siden findes en arbejdsstation med ZSRØR, Microsoft Visiual Studio 2008 og.net Framework 3.5 SP1, hertil er der tilføjet en dll-fil som hedder system.web.services.dll. Det sprog, der bliver kodet i, er C#. 5.1 Mainframe-side Består af: - En LPAR der kører z/os - 2 CICS regioner, en der kan bruges som provider, og en der kan anvendes som requester. - Unix system services, med tilhørende FTP server. Til udveksling af WSDL - DFHLS2WS. Værktøj til at, udstille CICS programmer, som en Web-service, samt generere WSDL og "bind" filer. 5.2 Windows computer side Består af: - En PC med Windows XP - Microsoft Visual Studio Express (C#) - ZSRØR klient 20/41