Enterprise Computing

Enterprise Computing Prof. Dr.-Ing. Wilhelm G. Spruth Teil 13 Java Connection Architecture

Web-Application Server Schnitstellen zur Außenwelt Not shown is the HTTP Server (Web Server).

Java Archive (jar) The jar tool combines multiple Java files into a single JAR archive file. jar is a general-purpose archiving and compression tool, based on ZIP and the ZLIB compression format. Compression reduces bandwidth when downloading an applet. However, jar was designed mainly to facilitate the packaging of java applications into a single archive.

ejb jar Datei Eine ejb jar Datei ist das standardmäßige Verpackungsformat für Enterprise JavaBeans. Dabei handelt es sich um eine normale Java ARchivdatei (JAR), die mit Hilfe des Hilfsprogramms jar erzeugt werden kann. Sie enthält aber spezielle Dateien, die alle jene Informationen zur Verfügung stellen, die ein EJB Container zur Inbetriebnahme der in der JAR Datei enthaltenen Beans benötigt. In einer ejb jar Datei gibt es zwei Arten von Inhalten: Die kompilierten Klassendateien aller Beans einschließlich ihrer Home und Client Interfaces sowie die Bean Implementationen. Darüber hinaus können auch containergenerierte Klassen enthalten sein.(beispielsweise konkrete Implementierungen der Home und Client Interfaces ). die Deployment Deskriptor Dateien. Als Minimum muss eine ejb jar Datei, eine standardmäßige ejb jar.xml Datei enthalten sein.

Web Archiv (WAR) The war file contains the web application that can be deployed on the any servlet/jsp container. The.war file contains jsp, html, javascript and other files for necessary for the development of web applications. Eine WAR Datei (Web ARchiv) dient standardmäßig dazu, Web Anwendungen zu verpacken. In einer WAR Datei gibt es drei Arten von Inhalten: Die Klassendateien aller Servlets, die Bestandteil der Webanwendung sind. Die statischen HTML Seiten, welche für das Ausführen der Webanwendung nötig sind. Es ist aber auch möglich, JSP Seiten, als dynamische Generierung von Response Seiten zu verwenden. Die Deployment Deskriptor Dateien. Der Deployment Deskriptor eines Web Archives ist, wie auch schon der ejb jar Deskriptor, eine XML Datei, welche eine Beschreibung der Anwendung, die Namen und die Parameter der Servlets zur Laufzeit, sowie sessionrelevante Einstellungen enthält. Außerdem werden auch Sicherheitsaspekte, wie zum Beispiel der Loginmechanismus einer Anwendung definiert.

web.xml Der Deployment Deskriptor eines Web Archives ist, wie auch schon der ejb jar Deskriptor, eine XML Datei, welche eine Beschreibung der Anwendung, die Namen und die Parameter der Servlets zur Laufzeit, sowie sessionrelevante Einstellungen enthält. Außerdem werden auch Sicherheitsaspekte, wie zum Beispiel der Log-in-Mechanismus einer Anwendung definiert.

EAR Archive Zusammenspiel von WAR, JAR und EAR Eine J2EE Anwendung besteht aus Web und EJB Komponenten. Beide Arten von Komponenten sind in Archiven verpackt, Verhalten und Eigenschaften sind in Deployment Deskriptoren (DD) definiert. Alle Komponenten einer Anwendung sind in einem EAR (Enterprise Application Ressource) zusammengestellt. Eine vollständige Anwendung kann durch Installation eines EAR Files auf einen anderen Application Server verteilt werden und sollte sich dort wie erforderlich konfigurieren lassen.

DD Deployment Descriptor Die Application.xml Datei ist eine XML Datei, welche nur die Namen der Enterprise Anwendung und deren Bestandteile enthält.

Tag Library : see below

Skalierbarkeit Leistungsverhalten eines Windows XP Web Servers 600 statische Zugriffe pro Sekunde 100 Java Zugriffe pro Sekunde für einfache Anwendungen Anforderungen eines größeren Unternehmens in 1999: Spitzenbelastung mehrere tausend dynamische Zugriffe pro Sekunde Verhältnis 5 : 1 Spitzen- zu Durchschnittsbelastung. Verhältnis 10 : 1 nicht selten. Beispiel: Fernsehwerbung für ein e-commerce Unternehmen kann Belastung dramatisch anwachsen lassen. Faktor 10 Wachstum erwartet in wenigen Jahren

Shared Database Shared Files Shared Sessions HTTP Engine HTTP Engine HTTP Engine Ausprägung 1 Ausprägung 2 Ausprägung n Interactive Network Dispatcher (IND) Optimiert für hohen Durchsatz Der HTTP Server behandelt Anforderungen für (meistens) statische Ressourcen: HTML Seiten, GIF Dateien und CGI Aufrufe Hohes Verkehrsaufkommen, kurzlebige Anforderungen Skalierung durch mehrfache Web Server Engines Der Interactive Network Dispatcher (auch als Sprayer oder Load Balancer bezeichnet) verteilt die Anforderungen auf die einzelnen Web Engines HTTP Server

www.google.com Google unterhält 2009 mehr als einem Dutzend Rechenzentren weltweit verteilt. Etwa 450 000 Rechner insgesamt. Mehrere Cluster in jedem Rechenzentrum. Jeder Cluster hat etwa 8 000 Prozessoren und dupliziert den ganzen Google Datenbestand. Rechner Sprayer Cluster Cluster Cluster Sprayer verteilt Anfragen auf die einzelnen Cluster. Jeder Cluster ist in der Lage, jede Art von Anfrage zu bearbeiten. Einfacher Workload Algorithmus, z.b. Round Robin Algorithmus verteilt Anfragen der Reihe nach auf die einzelnen Cluster und Server. Die Google Datenbank ist inerhalb der, und zwischen den Clusters dupliziert. Die Kopien sind nicht notwendigerweise auf dem gleichen Änderungsstand. Die allermeisten Abfragen sind read-only. The global IT industry uses about 2% of global electrical energy.

Google Server Farm It is estimated that Google maintains over 450,000 servers, arranged in racks located in clusters in cities around the world. In a 2000 estimate, Google's server farm consisted of 6000 processors. Servers are commodity-class x86 PCs running customized versions of Linux. At least 12 significant Google data center installations are located in the United States. In Europe, the largest known centers are in Eemshaven and Groningen in the Netherlands and Saint-Ghislain, Belgium. When an attempt to connect to Google is made, DNS servers resolve www.google.com to multiple IP addresses, which acts as a first level of load balancing by directing clients to different Google clusters. When a domain name resolves to multiple IP addresses, typical implementation of clients is to use the first IP address for communication. The order of IP addresses provided by DNS servers for a domain name is typically done using Round Robin policy. Each Google cluster has thousands of servers, and upon connection to a cluster further load balancing is performed by hardware in the cluster, in order to send the queries to the least loaded web server. This makes Google one of the biggest and most complex content delivery networks Most operations are read-only. When an update is required, queries are redirected to other servers, so as to simplify consistency issues. Queries are divided into sub-queries, where those subqueries may be sent to different ducts in parallel, thus reducing the latency time.

Google Infrastructure Google's server infrastructure is divided in several types, each assigned to a different purpose: Google load balancers take the client request and forward it to one of the Google Web Servers via Squid proxy servers. Squid proxy servers take the client request from load balancers and return the result if present in local cache otherwise forward it to Google Web Server. Squid is a proxy server and web cache daemon. It is used for speeding up a web server by caching repeated requests. Google web servers coordinate the execution of queries sent by users, then format the result into an HTML page. The execution consists of sending queries to index servers, merging the results, computing their rank, retrieving a summary for each hit (using the document server), asking for suggestions from the spelling servers, and finally getting a list of advertisements from the ad server. Data-gathering servers are permanently dedicated to spidering the Web. Google's web crawler is known as GoogleBot. They update the index and document databases and apply Google's algorithms to assign ranks to pages. Each index server contains a set of indexes. They return a list of document IDs, such that documents corresponding to a certain ID contain the query word. Document servers store documents. Each document is stored on dozens of document servers. When performing a search, a document server returns a summary for the document based on query words. They can also fetch the complete document when asked. Ad servers manage advertisements. Spelling servers make suggestions about the spelling of queries.

Difference between the Google Infrastructure and a Web Application Server The Google Infrastructure uses standard PCs, but proprietory software. Characteristics are the distributed duplicated data base, with (mostly) read-only queries, and few, if any, data integrity requirements. Amazon and ebay use a similar approach for their query front-ends. For the back-end, (buying a book or submitting a bid), a different approach is required. For back-end processing. Amazon uses a Unix system, ebay a z/os system with CICS. Back-end processing requires transactional integrity of all data being processed. In addition and opposite to the Goggle approach, regular business installations have to cope with a large number of widely different applications, with different runtime requirements and very different execution times. Web application server like WebLogic and WebSphere, and Transaction monitors like Tuxedo, CICS, and IMS/DC address these requirements

www.ebay.com Front End Back End Datenbank MS IIS WebSphere Oracle 44 Mill. Artikel 889 Mill. Aufrufe/Tag, etwa 50 000/s 270 Mill. Suchanfragen/Tag etwa 13 000/s 15 Mill. Gebote/Tag etwa 300/s 4 Data Center in 4 Lokationen, 50 SUN Server / Lokationen Abrechnung auf zseries CICS System Mai 2005

Servlet Engine Servlet Engine Servlet Engine Work Load Mgr. Queue 1 Queue 2 Queue n HTTP Server Zur Verbesserung des Leistungsverhaltens laufen mehrere Servlet Prozesse auf dem Applikations-Server. Anforderungen von dem Web Server gehen (je nach Policy) zu einer von mehreren Queues. Jede Queue wird von mehreren Java Prozessen bedient. Die Queue Policy bestimmt URLs, die von der Queue bedient werden Anzahl der Prozesse für diese Queue Sicherheitsumgebung Der Administrator legt die Anzahl und die Policies jeder Queue fest WebSphere Anwendungs-Queues und mehrfache Prozesse

Aufgaben der Queues In the WebSphere Application Server for z/os environment, the classification of each transaction is managed by a control region. This control region acts as a queuing manager that queues work requests to workload management for execution in multiple server address spaces, called servants. Aufgaben der control region: Availability und Reliability 24 Stunden/Tag, 7Tage/Woche. Verabschiedet sich ein Prozess, läuft der Rest weiter Lastverteilung Schutz der Anwendungen gegeneinander Austesten neuer Anwendungen

WebSphere Application Server for z/os Unter z/os besteht ein WebSphere Application Server (WAS) aus einem Controller und mehreren Servants. Controller und jeder Servant besitzen eine eigene JVM, in der jeweils ein Servlet Container und ein EJB Container laufen. Servant Controller Servant Servant WebSphere Application Server (WAS) Controller und Servant laufen in unterschiedlichen virtuellen Adressenräumen; der Controller läuft mit Speicherschutzschlüssel 2 und im Kernel Status. Die Servants laufen mit Speicherschutzschlüssel 8 im User Status. Normalerweise eine (oder wenige) Anwendungen in einem Servant.

Basic WebSphere Runtime Structure on z/os A WebSpere Application Server (WAS) Servant houses Servlets, EJBs. and other Java classes. Queues managed by the Workload Manager (WLM) are used to distribute incoming messages to multiple Servants. Each servant runs in its own z/os region.

In the WebSphere Application Server for z/os environment, the classification of each transaction is managed by a control region. This is a separate process running in its own virtual address space. The control region acts as a queuing manager that queues work requests to workload management for execution in server address spaces.

HTTP Protocol Catcher

HTTP Protocol Catcher In general, an HTTP Protocol Catcher is any program which communicates on the TCP/IP network using requests formatted in HTTP protocol. A protocol catcher understands the HTTP protocol and is capable of interpreting from the request format what the target of the request is. When WebSphere for z/os is active on the same system, a protocol catcher can be used to route appropriate requests to WebSphere for z/os web applications for processing. In WebSphere for z/os, the primary protocol catcher is known as the HTTP Internal Transport, a part of the Controller (CR) address space. The Internal Transport component will listen for incoming protocol requests using selected ports on the TCP/IP stack. When a request is received, the Internal Transport validates that the request can execute in this server. Provided the request is valid, the Internal Transport routes the request for execution to the web container in this server. The other supported HTTP protocol catcher on z/os is the IBM HTTP server, which uses port 80 as a default.. The HTTP server listens for incoming HTTP requests from remote clients on the network. The HTTP Plug-in component in the HTTP server address space filters HTTP requests received by the HTTP server and direct requests to run WebSphere web applications to the Internal Transport function of the appropriate J2EE application server. The plug-in uses HTTP protocol to re-direct the Web request to the WebSphere for z/os Internal Transport. The J2EE Internal Transport validates the incoming request and then schedules the request to run in the web container of the application server.

The HTTP Internal Transport is a component that executes in the CR address space of a z/os J2EE application server. The Internal Transport will bind to two selected TCP/IP port addresses, which are configured by the WebSphere for z/os V administrator, and listen for incoming requests. When an HTTP request is received, the Internal Transport checks the URL of the web container definition in the application server configuration to see if it matches a web application supported by this J2EE server. If this request is supported, the HTTP handler schedules the associated web application in the web container; if not, the request is failed.

Basic WebSphere Runtime Structure on z/os Organization based on concepts: Servers Nodes (and Node Agents): a logical grouping of WebSphere-managed servers Cells: a grouping of Nodes Elements are: The basic execution environment for WebSphere on z/os is a server. A server is a Controller/Servant configuration, In WebSphere z/os, a region is a virtual address space For every Controller there are one or more Servant Regions The Controller is the protocol entry point. Multiple protocols are supported: HTTP(S) and IIOP. The Servant Region is where the J2EE components execute, with a WLM Queue between them There can be multiple servers on a single z/os system (image).

z/os and Work Load Manager To balance work on the system, WebSphere uses the services of the WorkLoad Manager (WLM) provided by z/os and z/os. Three distinct WLM services are employed by WebSphere: 1. Routing The WLM routing service is used to direct clients to servers on a specific z/os server, based on a measurement of current system utilization known as the performance index. 2. Queuing and address space management The WLM queuing service is used to dispatch work requests from the Websphere Application Server for z/os Control Region to one or more Websphere Application Server for z/os Server Regions. It is possible for a Work Manager to register with WLM as a queueing manager (e.g., Websphere Application Server for z/os Control Region is a Queue Manager). This tells WLM that this server would like to use WLM-managed queues to direct work to other servers, which allows WLM to manage server spaces to achieve the specified performance goals established for the work. 3. Prioritizing work to meet performance goals WebSphere delegates the responsibility for starting and stopping Server Regions to the WLM Address Space management service. This allows WLM to manage application server instances in order to achieve the performance goals specified by the business.

WebSphere Scalability under z/os Scalability is a problem with most Unix, Linux and Windows implementations. The following figures represent the results of a WebSpere scalability test under z/os The test was performed with five z990 Systems, with 16 CPUs each, and an additional z990 with 4 CPUs configured as a coupling facility.

Trader Benchmark z/os uses for many tests a standard client/server benchmark called the Trader application. This benchmark has been repeatedly updated over the years and is now available in versiontrade V6.1. Shown above is the Topologie of the Trade V6.1 Benchmark.

18 585 WebSphere Scalability for the Trader benchmark, five Systems A single system with 16 CPUs is able to handle 3 717 Trader transactions/s. The theoretical maximum for 5 systems is 5 x 3717 tx/s = 18 585 tx/s. The actual measured throughput is 15 947 tx/s, or 15 947 / 18 585 = 86 % of the theoretical maximum.

Java Connection Architecture

Browser Neue Dienste WAS Inter- Servlet net EJB Presentation Glue IMS/DB DB2 CICS Tuxedo SAP IMS/DC Client/Server Aufgabenstellung Browser orientierter Web Zugang Datenhaltung in existierenden Datenbanken Dominierender Anteil der Business Logik in existierenden Transaktionsprogrammen und/oder Stored Procedures Neue Software (z.b. EJBs) stellen Querverbindungen zwischen existierenden Komponenten her (Glue) System Management - TCO Unternehmens-Architektur Die Anpassung existierender Transaktionsmonitor- oder Stored Procedure Anwendungen an das Internet erfolgt über einen vorgeschalteten Web Application Server, z.b. WebSphere. EJBs übernehmen nicht die Aufgaben existierender transaktionaler Mainframe Anwendungen, sondern ergänzen diese. Zusätzlich werden mit EJBs neue Dienste implementiert, besonders dann, wenn nur mäßige Anforderungen bezüglich Transaktionssicherheit und Zuverlässigkeit bestehen. Die persistente Datenspeicherung erfolgt beispielsweise über DB2.

z/os Internet Integration Unternehmenskritische Anwendungen und Datenbank-prozesse laufen in der Regel auf einem zentralen Server. In mittleren und großen Unternehmen und Organisationen ist dies in der Regel ein z/os Rechner. Hieran wird sich in der voraussehbaren Zukunft auch nichts ändern. Aufgabenstellung: Die existierende IT-Infrastruktur mit den Möglichkeiten des Internets integrieren. Die existierende IT-Infrastruktur umstrukturieren, so dass sie mit weniger Personal an die sich in immer kürzeren Zeiträumen ändernden Geschäftsbedingungen angepasst werden kann. Hierfür hat sich der Name Service Oriented Architecture (SOA) eingebürgert.

Datenbank- Presen- Business Prozeß tation Logik z.b. Oracle, DB2 Anwendungs- Prozeß PC Registrierkasse Geldausgabeautomat Business- und Präsentationslogik Ein sauber strukturiertes CICS Programm besteht aus zwei Teilen: Business Logik und Präsentations- Logik. Business Logik (Geschäftslogik) ist der Teil, in dem Berechnungen erfolgen und Daten in einer Datenbank gelesen/geschrieben werden. Präsentationslogik (Darstellungslogik) ist der Teil, in dem die Ergebnisse der Berechnungen so aufgearbeitet werden, daß sie dem Benutzer in einer ansprechenden Art auf dem Bildschirm dargestellt werden können. Business Logik wird in Sprachen wie C, C++, COBOL, PL/1, Java usw. geschrieben. Für die Präsentations - Logik gibt es viele Möglichkeiten. Die modernste Alternative benutzt Java Server Pages und einen Web Application Server um den Bildschirminhalt innerhalb eines Web Browsers darzustellen. Die älteste (und einfachste) Alternative verwendet das CICS BMS (Basic Mapping Support) Subsystem. BMS Programme werden in der BMS Sprache geschrieben.

Kundenscenario für eine Versicherung IT Prozessketten Customer Self Service

Scenario Einzelhandel IT Prozesskette Informationsportal für Händler

CICS virtueller andere virtuelle FF..FF Adressenraum Adressenräume 00..00 CICS Anwendungen Terminal Task Program Storage File Control Control Control Control Control TCT PCT PPT FCT Scratchpad COMMAREA CICS Komponenten z/os Kernel CICS Nucleus CICS läuft als lang laufender Stapelverarbeitungsjob in einem einzigen virtuellen Adressenraum (Region in OS/390 Terminologie). CICS Anwendungsprogramme laufen run to completion ; Interaktivität wird programmtechnisch gewährleistet, indem ihre maximale Ausführungszeit eine vorgegebene Grenze nicht überschreitet. Die CICS Nucleus Komponenten (Terminal Control, Task Control, Program Control, Storage Control and File Control) nutzen den gleichen virtuellen Adressenraum wie alle CICS Anwendungen. Jede Nucleus Komponente hat eine zugeordnete Tabelle: TCT, PCT, PPT, FCT. Über COMMAREA werden Sessions eingerichtet: Der State einer Transaktion ist für die Folgetransaktion verfügbar.

CICS Bildschirmausgabe 3270 Protokoll graphische User Interface (uneingeschränkt) TN3270 EPI TCP62 DPL Character graphische ECI User Interface User Interface (eingeschränkt) CUI GUI Alternativen der CICS Bildschirmausgabe Character User Interface Graphical User Interface Die CICS Bildschirmausgabe erfolgt entweder über das 3270 Protokoll unter Nutzung der CICS Terminal Control Komponente und des Basic Mapping Supports (BMS), oder über einen direkten COMMAREA Zugriff. Im ersten Fall erfolgt die Datenübertragung mit Hilfe des TN3270 Protokolls und der EPI Schnittstelle. Es ist zunächst eine Character User Darstellung möglich (green screen). Alternativ kann der 3270 Datenstrom mit Hilfe eines als Screen Scraping bezeichneten Ansatzes grafisch dargestellt werden. Im zweiten Fall erfolgt die Datenübertragung mit Hilfe des TCP62 Protokolls und der ECI Schnittstelle. Es wird die CICS DistributedProgram Link (DPL) Kommuniation eingesetzt. Einschränkungen in den Möglichkeiten der grafischen Darstellung, die im ersten Fall durch das 3270 Protokoll bedingt sind, werden hierbei ausgeschlossen.

ECI oder EXCI Schnittstelle C O M Präsentations- M Business Logik A Logik R E A CICS Anwendung Nr. 1 Präsentations- Business Logik Logik (eng miteinander verzahnt) Bei vielen älteren CICS Anwendungen (und bei manchen modernen Anwendungen) sind Presentation Logik und Business Logik eng miteinander verwoben. Es ist vielfach nicht möglich oder sinnvoll, diese Anwendungen umzuschreiben, um eine saubere Trennung zwischen Business Logik und Presentation Logik zu erreichen. Aufgabe: Ersatz der 3270 Schnittstelle durch eine Web Browser Schnittstelle oder eine andere GUI. CICS Anwendung Nr. 2 3270 Schnittstelle

Klient Server CICS Address Space Java CICS Anwendung Anwendung EPI BMS Puffer BMS 3270 Windows Netzwerk Communication Server Windows XP z/os TN3270 über TCP/IP Ein Nicht-CICS Programm kommuniziert mit einem CICS Programm über die EPI oder die ECI Schnittstelle. Die EPI Schnittstelle benutzt den normalen 3270 Datenstrom. Ein Beispiel ist ein 3270 Klient (Terminal Emulator). Eine Anwendung auf dem Klienten kann über die EPI Schnittstelle eine gefälligere graphische Oberfläche (GUI) erzeugen. Die Anwendung kann 3270- basierte CICS Transaktionen starten und Daten senden und empfangen, die mit dieser Transaktion assoziiert sind. Sie kann in Java, C++, PL/1 oder einer beliebigen anderen Programmiersprache geschrieben sein.

ACCOUNTS MENU TO SEARCH BY NAME, ENTER SURNAME AND IF REQUIRED, FIRST NAME SURNAME : (1 TO 18 ALPHABETIC CHRS) FIRST NAME : (1 TO 12 ALPHABETIC CHRS OPTIONAL) TO PROCESS AN ACCOUNT, ENTER REQUEST TYPE AND ACCOUNT NUMBER REQUEST TYPE: (D-DISPLAY, A-ADD, M-MODIFY, X-DELETE, P-PRINT) ACCOUNT : (10000 TO 79999) PRINTER ID : (1 TO 4 CHARACTERS (REQUIRED FOR PRINT REQUEST)) ACCT SURNAME FIRST MI TTL ADDRESS ST LIMIT 26001 Meier Rolf A MR Ritterstr. 13 N 1000.00 26002 Meier Steffie G MRS Wilhelmstr. 24 N 1000.00 26003 Meier Tobias A MR Nikolaistr. 23 N 1000.00 26004 Meier Walter R DR Heilbronnerstr. 91 N 1000.00 ENTER DATA AND PRESS ENTER FOR SEARCH OR ACCOUNT REQUEST OR PRESS CLEAR TO EXIT Beispiel einer CICS 3270 BMS Darstellung.

Java Servlet - JSP Darstellung

C C O O M M Präsentations- M M Business Logik A A Logik R R E E A A ECI oderexci Schnittstelle Eine CICS Anwendung besteht aus der Business Logik und der Presentation Logik. Es ist guter Pogrammierstiel, diese beiden Funktionen voneinander zu trennen und in getrennten Programm Modulen unterzubringen. Für die Kommunikation zwischen den beiden Modulen wird ein Pufferbereich benötigt. Hierfür bietet sich der COMMAREA Puffer an, dar von der Storage Control Komponente des CICS Subsystems bereitgestellt wird. COMMAREA wird u.a. für die Verwaltung von Sessions verwendet, wobei der State einer Transaktion für die Nachfolgetransaktion verfügbar ist. Hierfür existiert eine Schnittstelle, die External Call Interface (ECI). Sie wird die CICS Distributed Program Link (DPL) Interprocess Communication Einrichtung verwendet. DPL ist ein Verfahren ähnlich einem RPC. Ein CICS Programm kann ein anderes CICS Programm mit dem EXEC CICS LINK (Parameter) * Befehl aufrufen. Beide Programme können sich auf dem gleichen Rechner befinden, oder über das Netzwerk miteinander kommunizieren. Befinden sich beide Programme auf dem gleichen z/os Rechner (oder Sysplex), kann eine als EXCI bezeichnete Version der ECI Schnittstelle verwendet werden. Diese verwendet einen Speicherbereich des z/os Kernels und vermeidet den Kommunikations-Overhead.

CICS CICS Program Program CICS CICS TX Server TX Server Client Server DPL CICS Distributed Program Link (DPL) Distributed program link (DPL) enables an application program in a local CICS system to issue an EXEC CICS LINK command to link to a program in a remote CICS system, which returns control to the calling program. EXEC CICS LINK PROGRAM(name) COMMAREA(data-area) Distributed program link allows a CICS programmer to use an LU 6.2 link without needing to know the protocol. A CICS program linked by a program in a remote CICS system cannot issue: Terminal control commands to the initiating CICS system Commands that inquire on terminal attributes BMS commands SIGNON and SIGNOFF

Nicht-CICS CICS Program Program ECI CICS Client CICS TX Server Klient Server DPL ECI Call in C/C++ A non-cics application program can use the CICS Universal Client to access a CICS application program using DPL and TCP62. For this, the non-cics program calls the local CICS Universal Client via the ECI interface. The ECI interface is the means by which a non-cics program can establish a LU 6.2 session with a CICS program: ECI_PARMS EciBlock; cics_ushort_t Response;...... Response = CICS_ExternalCall (&EciBlock); where EciBlock contains the parameters of the call.

CICS Universal Client Server CICS Adressenraum Java CICS Anwendung Anwendung COMMAREA COMMAREA CICS Client ECI DPL Windows Netzwerk Communication Server Ein CICS Client ist eine echte CICS Anwendung, die mit anderen CICS Anwendungen über Distributed Program Link (DPL, einem RPC ähnlichen Mechanismus des CICS trtransaktionsservers) verkehrt. Eine Java Client Anwendung kann über die ECI Schnittstelle auf den CICS Client zugreifen. Dies ermöglicht einen direkten COMMAREA Datenaustausch zwischen Klienten und Server. Die Beschränkungen des BMS/3270 Datenprotokolls (z.b. keine Scroll Bar) werden damit umgangen. Windows XP z/os TCP62 über TCP/ IP

Java Connection Architecture Konnektoren

Konnektoren Bei den Implementierungen von Web Commerce Lösungen spricht man vom Frontend, welches typischerweise mit einem Web Application Server realisiert wird, und einem Backend (Beispiele Auftragseingang, Finanzbuchhaltung), wofür vorhandene Legacy Systeme eingesetzt werden. In vielen Fällen werden 20 % des Projektaufwandes für die Neuentwicklung des Frontends und 80% für dessen Integration in das vorhandene Backend aufgewendet. Konnektoren sind in beliebigen Sprachen geschriebene Software Komponenten, welche eine Schnittstelle zu existierenden Enterprise Information (Legacy) Systemen bilden. Modern ist, die Konnektoren als EJBs zu erstellen. Beispielsweise sind folgende EJB Konnektoren für die IBM WebSphere verfügbar: o JDBC, SQLJ o DB2 o Oracle o Adabas o CICS o IMS o MQSeries o SAP R/3 o Lotus Domino Die Konnektoren der J2EE Connector Architecture (JCA) werden als Resource Adapter bezeichnet.

WDz Entwicklungsumgebung JDBC Connector Java SQLJ z/os Programme Connector DB2 DB2Connect Connector Linux oder Win XP Rechner z/os Rechner Unterschiedliche Konnektor Arten JDBC ist von ODBC abgeleitet, implementiert dynamische Datenbankzugriffe SQLJ implementiert statische Datenbankzugriffe DB2Connect ist ein für die DB2 API optimierter Connector

J2EE Connector Architecture JCA Standard Achitektur für die Integration von existierenden Business Logik Komponenten. Heutige Bezeichnung: Java Platform, Enterprise Edition, abgekürzt Java EE. Nutzung: ERP Systeme, z.. SAP R/3 Mainframe Transaktions Monitore, z.b. CICS, IMS Existierende Non- Java Anwendungen Datenbank Systeme Wichtigste Bestandteile der Architektur sind: JCA Konnektoren, als Resource Adapter (RA) bezeichnet Common Client Interface (CCI) A Resource Adapter is a system level software library that is used by an application server or client to connect to a Resource Manager. A Resource Adapter is typically specific to a Resource Manager. It is used within the address space of the client using it. An example of a resource adapter is the JDBC driver to connect to relational databases.

J2EE Connector Architecture JCA Für CICS existieren: ECI Resource Adapter (für COMMAREA Zugriff) EPI Resource Adapter Das CICS Transaction Gateway (CTG) ist ein Software Paket. Es enthält: ECI Resource Adapter, EPI Resource Adapter, und Common Client Interface (CCI), sowie weitere Zugriffsmechanismen außerhalb der JCA

Die Common Client Interface (CCI) definiert eine Standard Client API Die CCI ist eine EIS unabhängige API. Anwendungen können mit einer identischen API unterschiedliche Resource Adapter verwenden. Ähnlich JDBC Interface CCI EIS J2EE Connector Architecture Common Client Interface Enterprise Information System JCA Common Client Interface CCI CCI und Resource Adapter sind als Java Klassen implementiert. Sie können von einer Java Anwendung alleinstehend benutzt werden ( non-managed environment ). Üblich ist es, CCI und Resource Adapter als Elemente eines Web Application Servers einzusetzen (managed environment). Hierbei kann der Web Application Server das Management von Verbindungen, Transaktionen und Sicherheit direkt übernehmen. Die CCI Entwicklung kann in ein Entwicklungswerkzeug wie Eclipse integriert werden.