CICS Web Services Tooling und Runtime - Deutsch - Isabel

CICS Web Service Runtime und Tooling
Dieses Dokument gibt einen Überblick über die Web Service Unterstützung unter CICS.
Betrachtet werden sollen sowohl Werkzeuge für die Generierung der notwendigen Artefakte als
auch die Laufzeitumgebung im CICS.
Es empfiehlt sich, als Machbarkeitsstudie zunächst die mitgelieferte Beispielanwendung CICS
Catalog Manager zu installieren. Dies wird im CICS Web Services Guide beschrieben im Kapitel
"Chapter 15. The CICS catalog manager example application"
http://pic.dhe.ibm.com/infocenter/cicsts/v4r2/topic/com.ibm.cics.ts.webservices.doc/dfhws_pdf.pdf
Hinweis: Die Betrachtung der Nutzung des Axis2 Web Service Support ab CICS TS V4.2 wird in
diesem Dokument weitestgehend ausgeklammert. Die Bereitstellung von Java Programmen als
Web Service Provider oder Requester im CICS ist hier beschrieben:
http://pic.dhe.ibm.com/infocenter/cicsts/v4r2/topic/com.ibm.cics.ts.webservices.doc/tasks/dfhws_
using_java_with_web_services.html
Inhalt
CICS Web Service Laufzeitumgebung.........................................................................................2
Voraussetzungen.....................................................................................................................2
CICS Ressourcendefinitionen ..................................................................................................2
Transport Infrastruktur (Provider) >> TCPIPService ..............................................................2
Message Handler und SOAP Header Verarbeitung >> PIPELINE .........................................3
URIMap................................................................................................................................5
Webservice ..........................................................................................................................6
Generierung der Artefakte ...........................................................................................................6
Konvertierungstypen ................................................................................................................6
Vergleich ..............................................................................................................................6
Verwendete Parser...............................................................................................................6
Entwicklungsszenarien ............................................................................................................7
Werkzeuge..................................................................................................................................8
CICS Web Service Assistant....................................................................................................8
Rational Developer for System z ..............................................................................................8
Start der Konvertierung ........................................................................................................9
Interpretierte Konvertierung mit RDz.....................................................................................9
Kompilierte Konvertierung mit RDz .....................................................................................11
Meet-in-the-Middle im RDz .................................................................................................12
CICS Deployment Unterstützung ........................................................................................13
Zusammenfassung....................................................................................................................14
Anhang .....................................................................................................................................15
Vorbereitung für CICS Deployment Unterstützung ..............................................................15
CICS Web Service Laufzeitumgebung
Voraussetzungen
1. Language Environment® support for PL/I muss aufgesetzt sein (siehe CICS Transaction
Server for z/OS Installation Guide). Der Parser wird für das Parsen der PIPELINE XML
Konfigurationsdatei benötigt.
2. z/OS Unterstützung für Unicode: die z/OS Conversion Services müssen aktiviert und die
Conversion Images installiert sein.
3. Der CICS System Initialization Parameter USSHOME muss gesetzt sein und dem z/OS
UNIX Verzeichnis entsprechen, unter dem CICS via DFHISTAR installiert wurde. Der
Default für CICS TS V4.2 ist /usr/lpp/cicsts/cicsts42, was in diesem Dokument auch als
Annahme getroffen wird.
CICS Ressourcendefinitionen
Folgende Ressourcen sind im CICS notwendig für Web Service Support:
• PIPELINE
• WEBSERVICE
• URIMAP (für Requester optional)
• TCPIPSERVICE (nur Provider und HTTP Transport, für MQ siehe Web Service Guide)
Als Beispiel dienen die Definitionen in der mitgelieferten Gruppe DFH$EXWS.
Transport Infrastruktur (Provider) >> TCPIPService
Um einen Web Service Request annehmen zu können, muss für den entsprechenden Transport
ein Empfänger im CICS bereitstehen. Für HTTP übernimmt diese Aufgabe ein TCPIPService, der
einen Port öffnet. CICS Web Service Support kann alternativ auch über MQ angeboten werden in diesem Fall müssen entsprechend Queues und Trigger Prozesse definiert werden.
Als Beispiel kann der mitgelieferte TCPIPSERVICE EXMPPORT der Gruppe DFH$EXWS
verwendet werden - gegebenenfalls nach Anpassung des Ports - der folgende Eigenschaften
besitzt:
• Urm: DFHWBAAX
• Protocol: HTTP
• Transaction: CWXN
Message Handler und SOAP Header Verarbeitung >> PIPELINE
CICS verwendet zur Verarbeitung der SOAP Nachricht sogenannte PIPELINE Ressourcen. In
deren Konfigurationsdatei werden Programme zur Verarbeitung der Nachricht und ihrer Header
festgelegt. CICS liefert folgende mit:
• SOAP Message Handlers um SOAP 1.1 oder 1.2 Nachrichten zu verarbeiten
•
•
•
MTOM Handler zur Unterstützung des MTOM/XOP Standards
Security Handler für Teile des Web Service Security Rahmenwerkes
Header Verarbeitungsprogramme für den Web Service Atomic Transaction Standard
(WS-AT) für Transaktionalität
Zusätzlich ist es jederzeit möglich, eigene Handler Programme zu schreiben.
Als Beispiel dienen die mitgelieferten PIPELINE Ressourcen der Beispielgruppe DFH$EXWS
EXPIPE01 - für CICS als Web Service Provider
EXPIPE02 - für CICS als Web Service Requester
Eine PIPELINE besitzt u.a. folgende Attribute:
• Configuration File: XML Datei zur Beschreibung der einzubeziehenden Handler
• Shelf: temporäres Verzeichnis der Pipeline zur Ablage von WSBind Files
• WS Directory (pickup): Verzeichnis, aus dem die PIPELINE WSBind Files auflesen kann,
um die zugehörige Webservice und URIMap Ressource daraus automatisch zu
generieren
Beispiele für das Configuration File befinden sich im CICS USSHOME (default
/usr/lpp/cicsts/cicsts42/samples/pipelines)
EXPIPE01 und EXPIPE02 verwenden sehr rudimentäre Konfigurationen:
basicsoap11provider.xml
<?xml version="1.0" encoding="EBCDIC-CP-US"?>
<provider_pipeline
xmlns="http://www.ibm.com/software/htp/cics/pipeline">
<service>
<terminal_handler>
<cics_soap_1.1_handler/>
</terminal_handler>
</service>
<apphandler>DFHPITP</apphandler>
</provider_pipeline>
Ob eine PIPELINE für Requester oder Provider gilt, wird in ihrer Konfiguration durch das oberste
Element festgelegt (<provider_pipeline> oder <requester_pipeline>).
Das Pickup Verzeichnis dient der automatischen Generierung von Webservice Ressourcen und
beim Provider auch URIMaps aus dort befindlichen WSBind Files. Pickup-Scan wird implizit
initiiert bei der Installation der PIPELINE und kann explizit ausgeführt werden durch den Befehl
EXEC CICS PERFORM PIPELINE(<name>) SCAN.
Empfehlung: Die mitgelieferten Beispiele dienen der Machbarkeitsstudie und sollten nicht
bearbeitet werden. Für eigene CICS Web Services sollten deswegen eigene PIPELINE
Ressourcen nach sinnvollen Namenskonventionen erstellt werden mit eigenen Verzeichnissen im
z/OS UNIX für Shelf, Pickup Verzeichnis und Konfigurationsdatei.
URIMap
Die URIMap dient CICS als Web Service Provider, um einen eingehenden Request über einen
Pfad auf weitere CICS Ressourcen zu mappen. Dazu gehört eine PIPELINE zur Verarbeitung
und schließlich eine Webservice Ressource, die das Endprodukt der PIPELINE in eine
Sprachstruktur (Cobol, PL/I, …) umwandelt und die Geschäftslogik aufruft.
Es wird empfohlen, die URIMap für Provider über den Pickup-Scan der PIPELINE zu generieren.
Ist CICS Web Service Requester, so ist die URIMap optional. Sie kann aber verwendet werden,
um die Adresse des aufzurufenden Service (den Endpunkt) aus der Anwendungslogik und der
Webservice Ressource herauszulösen.
>>-INVOKE-SERVICE(data-value)--CHANNEL(data-value)-------------->
>--OPERATION(data-value)--+--------------------+---------------->
+-URI(data-value)----+
'-URIMAP(data-value)-'
>--+---------------------------------------------+-------------><
'-SCOPE(data-value)--+----------------------+-'
'-SCOPELEN(data-value)-'
Wird kein Parameter mitgegeben, so wird der Endpunkt in der aufgerufenen Webservice
Ressource gesucht. Über den URI Parameter kann ein fester Endpunkt gesetzt werden, was
nicht empfohlen wird. Wird der Parameter URIMAP stattdessen verwendet, so wird die
entsprechende URIMap nach den Endpunkt befragt, wo dieser jederzeit flexibel angepasst
werden kann.
Webservice
Eine Webservice Ressource ist über das gleichnamige Attribut mit einem WSBind File verknüpft,
das als "Anleitung" für CICS gesehen werden kann, wie zwischen XML und Sprachstrukturen
(Cobol, PL/I) konvertiert wird. Auf die Erstellung von WSBind Files geht das Kapitel der
Generierung näher ein.
Ist CICS Web Service Provider, so konvertiert der Webservice mittels WSBind File den
eingegangenen Request (nach vorangegangener PIPELINE Prozessierung) und ruft
anschließend das Geschäftsprogramm auf.
Für den Requester dient der Webservice als "Ansprechpartner", der innerhalb CICS den
aufzurufenden Provider repräsentiert und über EXEC CICS INVOKE SERVICE genutzt werden
kann.
In beiden Fällen wird empfohlen, den Webservice über den Pickup-Scan der PIPELINE
generieren zu lassen.
Generierung der Artefakte
Wie im Runtime Kapitel bereits angedeutet, benötigt CICS für den Web Service Support ein
sogenanntes WSBind File, auf dessen Generierung hier näher eingegangen wird.
Hinweis: Das WSBind File wird nicht benötigt für Java Programme, die unter Ausnutzung des
Axis2 Support ab CICS TS V4.2 als Requester oder Provider fungieren sollen. Diese
Funktionalität wird in diesem Dokument nicht näher erläutert.
Konvertierungstypen
Grundsätzlich wird unterschieden zwischen Interpretiert (Interpretive) und Kompiliert (Compiled)
Konvertierung.
Interpretierte Konvertierung bezieht sämtliche benötigten Informationen aus der Interpretation des
WSBind Files zur Laufzeit.
Bei Kompilierter Konvertierung wird ebenfalls ein WSBind File verwendet, das aber auf ein
zusätzliches Cobol Programm (Converter) verweist, das die eigentliche Konvertierung übernimmt.
CICS bietet über den mitgelieferten Web Service Assistant (WSA) diverse Batch Jobs
ausschließlich für die Interpretierte Konvertierung.
Rational Developer for System z (RDz) unterstützt beide.
Vergleich
Die kompilierte Konvertierung unterstützt mehr Datentypen, beispielsweise Cobol OCCURS
DEPENDING ON oder REDEFINE.
Dafür unterstützt die interpretierte Konvertierung mehr Sprachen.
Die Performance beider Varianten weist keine signifikanten Unterschiede auf.
Verwendete Parser
Die Interpretierte Konvertierung verwendet folgende Parser
• XMLSS für Parsen des SOAP Envelopes
• DFHPITP - ein CICS-eigenes Programm für das Parsing von SOAP Bodys
• IBM XML Toolkit für WS-Security
Die kompilierte Konvertierung setzt für das Parsen des SOAP Bodys auf ein Cobol
Konverterprogramm, dass je nach Aktualität des vorhandenen Compilers im COMPAT Modus
oder unter Ausnutzung von XMLSS generiert werden kann.
Hinweis: das Konvertierungsprogramm DFHPITP wird ab CICS TS V4.2 auch als Java Programm
angeboten, das unter Nutzung des Axis2 Rahmenwerkes im CICS JVM Server das Parsen
zAAP-eligibel vornehmen kann.
Entwicklungsszenarien
Abhängig davon, was zum Zeitpunkt der Generierung bereits besteht und was generiert wird,
lassen sich folgende Szenarien benennen:
• Bottom-up: bei dem die Geschäftsprogramme bereits bestehen und die Web Service
Definition "von unten nach oben" generiert wird
• Top-down: bei dem eine Web Service Definition bereits vorliegt und die
Geschäftsprogramme "von oben nach unten" dazu neu erstellt werden
• Meet-in-the-middle: bei dem sowohl die Definition des Web Services als auch die
Geschäftslogik bereits existieren und man sich "in der Mitte treffen muss".
Provider
Interpretiert
x
x
Kompiliert
x
Requester
Interpretiert
Kompiliert
Bottom-up
Top-down
x
Meet-in-the-middle*
x
Bottom-up MTOM **
x
* Die Interpretierte Konvertierung bietet keine direkte Unterstützung für das Meet-in-the-Middle
Szenario. Allerdings ist es möglich, mit Hilfe des Top-down Szenarios manuell ein Wrapper
Programm zu schreiben, das den Request so annimmt wie von der Web Service Definition
gefordert und nach Anpassungen der Daten die bestehende Geschäftslogik aufruft.
** diese Option ist für die Verwendung von IBM Data Power gedacht, die in diesem fall statt CICS
die XML Konvertierung vornimmt und die fertige Sprachstruktur an CICS als MTOM Attachment
einer SOAP Nachricht übermittelt. CICS braucht in diesem Fall lediglich das Attachment vom
eingehenden SOAP Request zu holen. Diese se Option ist nur im RDz verfügbar.
Empfehlung: Ist CICS Web Service Provider, so empfiehlt sich, immer zuerst das Design der
Web Service Definition vorzunehmen. Nur dadurch kann die optimale Granularität und eine
saubere Schnittstellenbeschreibung gewährleistet werden. Wird die Beschreibung im Bottom-up
Modus generiert, so müssen meist unnötige Daten übertragen werden (zu grob granular) oder für
eine Aufgabe mehrere Anfragen gesendet werden (zu fein granular).
Werkzeuge
CICS Web Service Assistant
Der CICS WSA unterstützt ausschließlich Interpretierte Konvertierung (ausgenommen MTOM).
Für den Bottom-up Modus steht der Batch Job DFHLS2WS zur Verfügung, der aus der
Geschäftslogik und weiteren Parametern wie Sprache (COBOL, PLI, C, CPP) und aufzurufendes
Programm das zugehörige WSBind File und die Web Service Beschreibung als WSDL File
erzeugt.
Für den Top-Down Modus wird DFHWS2LS verwendet. Aus einem WSDL File und anderen
Parametern wird ebenfalls ein WSBind File erzeugt sowie Sprachstrukturen. Wird ein Requester
erstellt, so muss dieser diese Strukturen verwenden, um den Request zu formulieren und die
Antwort auszulesen. Wird ein Provider erstellt, so muss er diese verwenden, um den Request zu
empfangen und die Antwort zu formulieren.
Weitere Informationen zum CICS WSA sind im CICS Web Service Guide und im Infocenter zu
finden.
Rational Developer for System z
Sowohl Interpretierte als auch Kompilierte Konvertierung werden durch Wizards unterstützt.
Diese bieten neben der Generierung auch verbesserte Deployment Optionen, um beispielsweise
das WSBind File automatisch in das Pickup Verzeichnis der PIPELINE zu kopieren.
Dadurch kann Entwicklung und Test vollständig im RDz stattfinden, ohne dass ein Medienbruch
durch den Wechsel auf die z/OS Konsole notwendig ist.
Start der Konvertierung
RDz unterstützt den Einstieg in CICS Web Services durch einen View namens "Getting Started",
der - falls noch nicht geöffnet - über die Menüleiste mit Window >> Show View >> Other unter der
Kategorie Help geöffnet werden kann.
Dieser führt Schritt für Schritt durch die Konvertierung
Interpretierte Konvertierung mit RDz
Für die Interpretierte Konvertierung wird der gleiche Generator auf der Workstation aufgerufen,
den auch der CICS WSA auf z/OS verwendet. Der Wizard dient der besseren und intuitiveren
Erfassung der Eingabeparameter.
Ein weiterer Vorteil gegenüber dem CICS WSA ist, dass im Bottom-up Moduls ausgewählt
werden kann, welche Elemente für Request und Response notwendig sind und welche nicht, wie
in folgendem Beispiel.
Außerdem generiert RDz im interpretierten Top-down Modus (sowohl für Requester als auch
Provider) ein Template File als eine Art Programskelett zur Orientierung.
Kompilierte Konvertierung mit RDz
Die Wizards der Kompilierten Konvertierung unterscheiden sich im Wesentlichen durch die
zusätzlichen Optionen für das Cobol Programm. Hier können verschiedene Parsing Optionen
ausgewählt werden, die sich unterschiedlich auf Geschwindigkeit und Verbrauch auswirken.
Meet-in-the-Middle im RDz
Der entsprechende Wizard im RDz importiert die WSDL für den gewünschten Web Service sowie
die Cobol oder PL/I Geschäftslogik, die diesen als Provider zur Verfügung stellen soll.
Über Mapping Files wird festgelegt, welches Feld des Requests wohin in der Struktur des
bestehenden Programms übertragen wird bzw. umgekehrt, welches Feld aus der Antwort des
Programms wohin in die Response Struktur.
Dabei können die Daten direkt übertragen werden wie im folgenden Screenshot (Move) oder
auch transformiert werden.
Im Anschluss wird bei der kompilierten Meet-in-the-middle Konvertierung - ähnlich wie bei der
kompilierten Bottom-Up Konvertierung - ein Cobol Konverterprogramm erzeugt, was die
Umwandlung zwischen XML und den Sprachstrukturen übernimmt.
CICS Deployment Unterstützung
Sowohl Interpretierte als auch Kompilierte Konvertierung benötigen den anschließenden
Transport des WSBind Files in das Pickup Verzeichnis einer PIPELINE. RDz ermöglicht,
angebundene CICS Regions nach installierten PIPELINE Ressourcen zu durchsuchen und
diesen Schritt automatisch durchzuführen.
Hierzu ist die Anbindung von CICS an RDz notwendig, mehr dazu im Anhang unter "Vorbereitung
für CICS Deployment Unterstützung"
Zusammenfassung
CICS bietet Web Service Support, um selbst als Provider einen Web Service anzubieten oder als
Requester andere Web Services aufzurufen. Dabei werden unterschiedliche Szenarien
unterstützt, von denen aber wegen des sauberen Designs der Meet-in-the-Middle Ansatz zu
bevorzugen ist. Als Werkzeuge stehen der batch-basierte CICS Web Service Assistant sowie die
Wizard-getriebene IDE des Rational Developer for System z zur Verfügung.
Beide Werkzeuge ermöglichen die Interpretierte Konvertierung, bei der sämtliche
Konvertierungsinformation in ein WSBind File generiert wird. Alternativ kann im RDz die
Kompilierte Konvertierung verwendet werden, die ein Cobol Pogramm zum Konvertieren
verwendet und damit Cobol-spezifische Optimierungen wie die Verwendung von XML System
Services Parsern nutzen kann.
Zusätzlich erleichtert RDz den Entwicklungszyklus durch CICS Deployment Unterstützung.
Anhang
Vorbereitung für CICS Deployment Unterstützung
Um nahtlos von der Generierung zum Deployment übergehen zu können benötigt RDz
Anbindung an CICS.
Hierzu existieren momentan zwei Optionen:
• CICS Management Interface CMCI - die strategische, vom CICS bereitgestellte RESTful
Schnittstelle, verfügbar ab CICS TS V4.1 und bereits teilweise nutzbar im RDz
• CICS Resource Definition Server - auch Application Deployment Manager (ADM)
genannt und von RDz mitgeliefert, weil RDz die Anbindung damals auch für ältere CICS
Versionen benötigt hat
In der aktuellen Version RDz 8.5 benötigen viele Wizards für das Deployment ins CICS noch die
RDz proprietäre Anbindung über ADM. Diese sollen aber in Zukunft transparent für den
Endbenutzer auf CMCI umgestellt werden.
Für dieses Dokument wird deswegen an dieser Stelle noch eine ADM Verbindung verwendet.
Die Einrichtung von ADM ist im RDz Host Installation Guide beschrieben und beinhaltet
hauptsächlich Folgendes:
• Öffnung eines Ports via TCPIPService
• Installation einer URIMap, damit eingehende Requests vom RDz auf die entsprechenden
Module gemappt werden können
• Einbindung entsprechender Lademodule ins CICS, die den Request verarbeiten
• Für CICS Versionen älter als 4.1 muss zusätzlich eine Web Service Infrastruktur mit
PIPELINE aufgesetzt werden
Anschließend muss über den Host Connections View (Öffnen Via Window >> Show View >>
Other) die Verbindung erstellt werden: mittels "Add" Button den "CICS Resource Definition
Server" hinzufügen (via REST ab CICS 4.1, sonst via Web Services) und auf "Connect" klicken.