Optimierte lokale Adapter in Liberty for z/OS
Die Unterstützung für optimierte lokale Adapter in Liberty for z/OS setzt sich aus einer Gruppe aufrufbarer Services und einem JCA 1.5-Ressourcenadapter (Java™ EE Connector Architecture) zusammen. Die Services und der Adapter ermöglichen gemeinsam leistungsfähige Aufrufe zwischen in nativen Sprachen geschriebenen Anwendungen unter z/OS und Geschäftslogik in einer Liberty-Serverumgebung.
Sie können WebSphere Optimized Local Adapters (WOLA, optimierte lokale WebSphere-Adapter) verwenden, um eingehende Aufrufe an Anwendungen abzusetzen, die über einen externen Adressraum in Liberty implementiert wurden. Sie können optimierte lokale Adapter auch verwenden, um abgehende Aufrufe von Liberty-Anwendungen an Anwendungen abzusetzen, die in einem externen Adressraum auf demselben z/OS-System ausgeführt werden.
Mit dieser Unterstützung können vorhandene z/OS-Anwendungen, die in Cobol, PL/I, C, C++ oder einer Assemblersprache geschrieben sind, eine hohe Leistung und eine effiziente Integration mit Java-Anwendungen erreichen, die im Liberty-Server auf demselben z/OS-System implementiert sind.
- Customer Information Control System (CICS)
- Information Management System (IMS)
- UNIX System Services
- Stapelverarbeitung
Für die Unterstützung der optimierten lokalen Adapter unter CICS wird ein taskbezogenes Benutzerexitprogramm (TRUE, Task-Related User Exit) bereitgestellt.
Vorteile der Verwendung optimierter lokaler Adapter
- Leistungsverbesserung
- Sie können erhebliche Leistungsverbesserungen erzielen, wenn Sie die OLA-APIs für den Aufruf von Anwendungen verwenden, die über lokale Stapel- oder UNIX System Services- und CICS-Anwendungen in einem Liberty-Server implementiert werden. Die Möglichkeit, Parameterdaten mit binären Verfahren zu übergeben, ist ein großer Teil der Leistungsverbesserung. Die von den Adaptern bereitgestellte Unterstützung auf Transportebene verwendet speicherübergreifende z/OS-Services, um die Leistung von Aufrufen an Anwendungen zu optimieren, die in einem lokal zugänglichen Liberty-Server implementiert werden.
- Weitergabe des Identitätskontextes
- Bei eingehenden Anforderungen an den Liberty-Server über die OLA-APIs (optimierter lokaler Adapter) wird die Benutzer-ID im vorhandenen z/OS-Thread immer weitergegeben und im Liberty-EJB-Container zugesichert. Für Aufrufe von CICS können Sie diese Weitergabe erweitern, indem Sie eine Registrierungsoption angeben, die die Identität des Benutzers auf CICS-Taskebene weitergibt und zusichert. Für Aufrufe von Liberty-Anwendungen können Sie die Identität unter CICS mit dem CICS-Link-Server der optimierten lokalen Adapter weitergeben und zusichern. Sie können dieses Verhalten steuern, indem Sie ein Flag in der API "Register" setzen.
- Unterstützung lokaler Bindungen
- Optimierte lokale Adapter können eine lokale Bindung mit hoher Leistung für vorhandene Anwendungen, Middleware und Subsysteme auf z/OS-Plattformen ermöglichen. Wenn ein lokaler Liberty-Server verfügbar ist, werden diese lokalen Bindungen für aktuelle Programmierschnittstellen verwendet.
- Gateway oder Proxy für traditionelle Assets auf z/OS-Systemen
Optimierte lokale Adapter sind die Basis für die Verwendung des Liberty-Stacks als einfach zugänglicher Funktionssatz. Diese Funktionen erweitern den Lebenszyklus von Anwendungsassets, die möglicherweise schwer zu ersetzen sind. Wenn Sie eine Enterprise-Bean als Proxy verwenden, kann jede Cobol-Anwendung, C/C++-Anwendung oder Assemblersprachenanwendung, die auf dem z/OS-System implementiert wird, ohne großen Aufwand als Web-Service-Client oder Web 2.0-Anwendungsrequester, der eine Gruppe von Webanwendungen in der Reichweite Ihres lokal ausgeführten Anwendungsservers erreicht, eingesetzt werden.
Mit den Liberty-APIs für abgehende Daten, kann jede Cobol-, Assemblersprachen- oder C/C++-Anwendung dem Liberty-Server als aufrufbarer Service präsentiert werden. Anschließend können Sie eine Provider-Web-Service-Anwendung im lokalen Liberty-Server implementieren, die Anforderungen als Gateway für diesen Back-End-Service akzeptiert. In diesem Szenario sendet das JCA 1.5-Programmiermodell Anforderungen an die Anwendung, empfängt Antworten von dieser und sendet Antworten an den webbasierten Caller zurück.