WebSphere에 최적화된 로컬 어댑터

IBM WebSphere OLA(Optimized Local Adapters)는 WAS z/OS로 인바운드 및 z/OS에서 아웃바운드 호출에 효율적인 교차 메모리 메커니즘을 제공하는 IBM의 z/OS용 WebSphere Application Server의 기능 구성요소입니다.다른 통신 메커니즘의 오버헤드를 피하기 위해 대량의 메시지 교환이 가능합니다.WOLA는 WAS z/OS의 기존 교차 메모리 교환 메커니즘의 확장으로, WOLA는 WAS z/OS 서버 외부의 z/OS 주소 공간이 교차 메모리 교환에 참여할 수 있도록 외부 인터페이스를 제공합니다.WOLA는 WAS z/OS 서버와 CICS, IMS, 배치, UNIX 시스템 서비스 및 ALCS 중 하나 이상의 연결을 지원합니다.WOLA는 WAS z/OS 버전 7, Fixpack 4(7.0.0.4)에서 처음 제공되었습니다.이 문서에 기재되어 있는 바와 같이, 이후의 픽스 팩에 기능 향상이 기재되어 있습니다.

역사

WebSphere Optimized Local Adapters for WAS z/OS(WOLA 또는 줄여서 OLA)는 효율적인 인바운드 호출 메커니즘, 즉 Java EE 환경 외부에서 Java EE 자산을 활용하기 위한 메커니즘에서 비롯되었습니다.이러한 요구 사항은 특히 Java EE 및 EJB 기술을 기반으로 한 프로그래밍 자산의 증가하는 기반 사용을 모색하는 기존 배치 프로세싱에서 두드러졌습니다.

다음과 같은 다른 인바운드 솔루션이 존재했습니다.

Websphere MQ 또는 기타 JMS 공급자 등의 메시징.
RMI/IIOP
웹 서비스

각각의 장점이 있지만, 각각의 단점도 있었습니다: 오버헤드와 레이텐시, 시공의 어려움, 또는 보안 또는 트랜잭션 전파 모델의 결함입니다.

이것이 Optimized Local Adapters의 원래 설계 포인트입니다.이 솔루션의 설계자는 외부 주소 공간에서 WAS z/OS로 인바운드, WAS에서 외부 주소 공간으로 아웃바운드 등 양방향 호출을 포함하도록 설계를 확장했습니다.

기술 기반

이 솔루션의 설계자는 동일한 LPAR에 있는 애플리케이션 서버 간의 IOP 트래픽을 최적화한 V4.x일 이후 WebSphere Application Server for z/OS에서 사용된 교차 메모리 메커니즘인 "로컬 통신"이라는 WAS z/OS 설계의 기존 요소를 활용하기로 선택했습니다.OLA는 기본적으로 기존 크로스 메모리 메커니즘을 외부화한 것으로, WAS z/OS 외부의 주소 공간이 공유 메모리 공간을 통해 연결 및 메시지 교환을 할 수 있습니다.

외부 주소 공간 프로그램은 제공된 API 세트를 사용하여 OLA 인터페이스에 액세스합니다.WAS z/OS에서 실행되는 Java 프로그램은 표준 JCA 리소스 어댑터로 패키지된 구현을 통해 OLA 인터페이스에 액세스합니다.

현재 지원

WAS z/OS OLA에서 현재 지원되는 외부 주소 공간은 다음과 같습니다.

IBM CICS
배치 작업
UNIX 시스템 서비스(USS)
항공사 관제 시스템(ALCS)
IMS(유지보수 7.0.0.12부터 지원 시작)

외부 주소 공간에서 지원되는 프로그래밍 언어는 다음과 같습니다.

Java는 WAS z/OS의 Java EE 컨테이너 내부에서 WAS z/OS OLA에 액세스하는 데 사용되는 프로그래밍 언어입니다.

기능 갱신 이력

IBM WebSphere Optimized Adapters 기능 지원은 새 버전 또는 픽스 팩이 출시됨에 따라 업데이트되었습니다.이 기능은 WAS z/OS 버전 7 릴리스 0 픽스팩 4 레벨(7.0.0.4)에서 처음 사용 가능하게 되었습니다.

기능 업데이트, 파트 1

기능 업데이트, 파트 3

7.0.0.4

WOLA는 Fixpack 4와 함께 WAS z/OS 버전 7 릴리스 0 제품에 도입되었습니다.유지보수를 적용하면 제품 파일 시스템에 WOLA 모듈, 공유 객체, JCA 리소스 어댑터 및 개발 클래스 라이브러리를 제공하는 새로운 디렉토리가 생성되었습니다.셸 스크립트(olaInstall).sh)는 런타임 환경에서 제품 설치 파일 시스템에 필요한 UNIX 심볼릭 링크를 만들었습니다.

7.0.0.4 릴리스에서 지원되는 기능은 다음과 같습니다.

CICS, 배치, USS 및 ALCS 지원
발신 WAS의 CICS로의 단상 커밋 (2PC에서 CICS TS 4.1로의 7.0.0.12와 함께 제공)
WAS로의 착신 CICS에 대한 2단계 커밋
네이티브 API
JCA 리소스 어댑터

7.0.0.12

WAS z/OS 버전7 릴리스 0에 대한 Fixpack 12는 WOLA 지원에 대해 다음 두 가지 업데이트를 제공했습니다.

WOLA 및 IMS 지원
WAS 발신에서 CICS TS 4.1로의 2단계 커밋 트랜잭션 처리

8.0.0.0

WebSphere Application Server for z/OS 버전 8 릴리스 0은 WebSphere Optimized 로컬 어댑터를 계속 지원했습니다.WOLA는 제품에 포함되어 출하되었습니다.이것에 의해, 제품 파일에의 UNIX 심볼릭 링크를 작성하기 위해서, olaInstall.sh 를 실행할 필요가 없어졌습니다.또한 다음과 같은 기능 업데이트가 제공되었습니다.

IMS를 사용한 작업을 위한 멀티 세그먼트 대용량 메시지 지원(32,000 이상 크기)
IIOP 콜과는 별도로 WOLA 콜의 착신 트랜잭션 분류 지원
SMF 120.9 레코드 내에서의 WOLA 콜 식별(IIOP가 아닌 WOLA)
자원 장애 식별 및 대체 JNDI 페일오버

리소스 페일오버 및 페일백

이 함수는 JCA 접속 팩토리에 연결된 데이터 자원의 손실을 검출하여 정의된 대체 JNDI에 자동으로 페일오버하는 수단을 제공합니다.프라이머리 데이터 자원의 리커버리와 페일백의 검출도 이 기능 설계의 요소입니다.리소스 페일오버 설계는 JDBC 및 JCA의 모든 플랫폼에 걸쳐 WebSphere Application Server 버전 8에 있습니다.WAS z/OS 버전 8은 JCA 리소스 페일오버에 대한 일반적인 지원의 일부로 WOLA 리소스 페일오버를 지원합니다.설정 가능한 임계값 수의 getConnection() 장애가 발생했을 때 페일오버가 호출됩니다.페일오버가 호출되면 새로운 getConnection() 요구는 모두 대체 연결 팩토리 연결 풀에 라우팅됩니다.페일백은 WAS z/OS가 장애가 발생한 기본 데이터 리소스가 반환되었다고 판단할 때 발생합니다.새로운 getConnection() 요구는 프라이머리 연결 팩토리에 대해 처리됩니다.

이 함수의 일반적인 사용 패턴은 타깃 CICS 영역이 라우팅 영역인 CICS로 발신하는 것입니다.이 페일오버 기능은 단일 라우팅 영역의 손실이 CICS의 전체적인 가용성에 영향을 미치지 않도록 여러 라우팅 영역을 설계하는 기능을 제공합니다.

이 리소스 페일오버 및 페일백 메커니즘을 지원하기 위해 다음과 같은 몇 가지 연결 풀 사용자 지정 속성이 추가되었습니다.

failureThreshold- 자동 페일오버가 호출될 때까지 연속적으로 발생하는 getConnection() 장애 수
alternateResourceJNDIName- 자동 페일오버가 실행될 때 사용하는 대체 연결 팩토리의 JNDI 이름
resourceAvailabilityTestRetryInterval- WAS가 프라이머리 자원의 반환을 테스트하기 위해 사용하는 간격(초)

참고: 이 함수에 대한 다른 연결 풀 사용자 지정 속성이 있습니다.전체 목록을 보려면 WAS z/OS InfoCenter에서 문자열 "cdat_dsfailover"를 검색하십시오.

8.0.0.1 / 8.5.0.0

참고: WAS z/OS 8.5.0.0은 8.0.1과 동일한 기능적 WOLA 지원을 제공합니다.

WebSphere Application Server for z/OS 버전 8의 Fixpack 1은 WOLA에 다음과 같은 기능 업데이트를 제공했습니다.

64비트 모드로 동작하는 C/C++ 프로그램용 64비트 호출 가능한 네이티브 API
WAS로부터의 WOLA 발신 콜의 SMF 120 서브타입 10 레코드(SMF 120 서브타입 9는 착신 콜 정보를 캡처합니다).
Work Distribution - 같은 이름의 여러 외부 등록 간에 발신 콜을 라운드 로빈하는 기능
원격 액세스 프록시 지원 - 인바운드와 아웃바운드 두 가지 형식

64비트 콜 가능 네이티브 API 모듈

8.0.0.1보다 이전 버전에서는 네이티브 API 모듈은 31비트 콜 가능 포맷으로만 제공되었습니다.이러한 모듈에는 4글자 프리픽스 BB가 있습니다.각 모듈명에 관련된 OA*.

8.0.0.1에서는 31비트 및 64비트 양쪽의 콜 가능 API 모듈이 제공됩니다.31비트 모듈에서는 4글자 프리픽스 BB가 유지됩니다.각 모듈명의 OA*.64비트 모듈에서는 각 모듈 이름에4글자 프리픽스 BBGA*가 사용됩니다.

API의 수는 이전과 동일합니다.13개의 특정 API.용도는 이전과 동일합니다.

InfoCenter 검색: cdat_olaapis

WOLA 발신 콜용 SMF 120.10

WAS z/OS V7에서는 SMF에 대한 WOLA 지원은 착신 통화로만 제한되었습니다.WAS z/OS 컨테이너에서 EJB를 대상으로 하는 인바운드 WOLA 콜은 IIOP 콜로 식별되었고 SMF에 의해 다른 IIOP 콜과 구별되지 않는 IIOP 콜로 캡처되었습니다.착신 콜 정보의 취득에는, 통상의 WAS z/OS SMF 120 서브 타입9 레코드(속기 표기에서는 120.9)가 사용되었습니다.

WAS z/OS 8.0.0에서는 착신 IIOP 콜과는 다른 착신 WOLA 콜을 식별하도록 SMF 120.9 레코드 및 캡처 기능이 변경되었습니다.

WAS z/OS 8.0.0.1에서는, SMF 120.10 레코드가 작성되어 WAS z/OS로부터의 발신 콜에 관한 정보가 캡쳐 됩니다.SMF 120.10 레코드에는 다음 8개의 섹션이 있습니다.

플랫폼 중립 서버 정보 섹션
z/OS 서버 정보 섹션
[ Outbound Request Information ]섹션
[ WOLA Outbound Request Type ]섹션
아웃바운드 요청 트랜잭션 컨텍스트 섹션
[ Outbound Request Security context ]섹션
[ Outbound Request CICS context ]섹션
[ OTMA Outbound Request Type ]섹션

발신 요구마다 레코드가 1개씩 생성됩니다.

InfoCenter 검색: rtrb_SMFsubtype10

작업 분배

이 기능 업데이트는 동일한 등록 이름을 사용하여 특정 WAS z/OS 서버에 등록된 여러 외부 주소 공간에 발신 콜을 분산하는 기능을 제공합니다.이에 대한 일반적인 사용 패턴은 동일한 스테이트리스 타깃 프로그램서비스가 전개된 여러 CICS 지역입니다.원하는 작업 분배 유형을 나타내기 위해 새로운 환경 변수가 생성되었습니다.이 기능의 사용법을 다음에 나타냅니다.

InfoCenter 검색: cdat_olacustprop

프록시 지원:착신 및 발신

WOLA 통신의 크로스 메모리 특성은 WAS z/OS 서버를 의미하며 외부 주소 공간은 동일한 z/OS 논리 파티션(LPAR)에 있어야 합니다.WAS z/OS 8.0.0.1은 WOLA 발신자와 WOLA 타깃을 별도로 배치할 수 있는 프록시 기능을 제공합니다.여기에는 z/OS 이외의 운영 체제 인스턴스의 위치가 포함됩니다.이 기능에는 발신 콜에 대한 프록시 지원과 착신 콜에 대한 프록시 지원의 2가지 형식이 있습니다.

발신 콜 프록시 지원

이를 통해 Java 응용 프로그램이 제공된 WOLA JCA 리소스 어댑터를 사용하여 원격 z/OS의 대상 주소 공간에 액세스할 수 있는 메커니즘을 제공합니다.사용 패턴의 예로는 제안된 애플리케이션의 개발 또는 테스트가 있습니다.대상 z/OS 시스템의 교차 메모리 WOLA 연결에 대한 액세스는 WOLA에 대해 활성화된 WAS z/OS 서버에 설치된 제공된 WOLA 프록시 애플리케이션에 의해 제공됩니다.다음 그림은 토폴로지를 나타내고 있습니다.

애플리케이션에서 WAS z/OS 시스템으로의 네트워크 흐름은 IIOP를 통해 이루어집니다.WOLA 접속 팩토리에서는 접속 풀에 대한 몇 가지 새로운 커스텀속성을 통해 프록시에 대한 이 IIOP 플로우가 통지됩니다.WAS z/OS 상의 프록시 애플리케이션은 콜을 수신하여 실제 크로스 메모리 WOLA 접속을 통해 지정된 타깃서비스로 전송합니다.

이 토폴로지는 같은 z/OS LPAR 상의 발신 WOLA 콜과 비교하여 제한이 있습니다.즉, 2단계 커밋이 필요한 글로벌 트랜잭션은 IIOP 접속을 통해 WOLA 프록시로 전파될 수 없으며 WAS 스레드 상의 사용자 ID를 z/OS 상의 타깃서비스로 아사트할 수 없습니다.

착신콜 프록시 지원

이를 통해 외부 주소 공간의 비 Java 애플리케이션이 다른 z/OS LPAR 또는 분산 WAS 플랫폼에서 원격 WAS 인스턴스의 대상 WOLA 지원 EJB에 인바운드 콜을 발신할 수 있는 메커니즘을 제공합니다.로컬 WAS z/OS 인스턴스에 설치되어 있는 것과 동일한 WOLA 프록시 애플리케이션이 첫 번째 크로스 메모리 WOLA 콜을 처리하여 원격 WAS 인스턴스 상의 지정된 타깃EJB로 전송하기 위해 필요합니다.다음 그림은 토폴로지를 나타내고 있습니다.

대상 WOLA 지원 EJB는 프록시가 사용 중임을 인식하지 못합니다.착신 플로우는, 같은 LPAR 상의 크로스 메모리 WOLA 가 사용되고 있는 경우와 같이, IIOP 콜로서 착신합니다.호출 프로그램은 플로우가 프록시 서비스를 사용하는 것을 나타내야 합니다.이것은 BBOA1의 파라미터를 사용하여 이루어집니다.requesttype 파라미터의 INV(또는 BBOA1SRQ)는 2입니다.이는 로컬 프록시 애플리케이션이 대상 EJB의 JNDI 이름으로 지정된 요청된 서비스를 IIOP를 사용하여 EJB를 호출하는 요청으로 처리하도록 지시합니다.이를 위해서는 로컬 및 리모트 WAS 인스턴스에 페더레이션네임스페이스가 있거나 JNDI 룩업이 성공하려면 단일 셀로 동작해야 합니다.

8.0.0.3 및 8.0.0.4 / 8.5.0.1

IBM Integration Designer for BPEL Processes에 포함된 8.0.0.3(및 8.5.0.1) WOLA 지원.

8.0.0.4(및 8.5.0.1)에서는 IMS 의존 영역에서 WAS over WOLA로 RRS 트랜잭션 컨텍스트 어설션을 포함하도록 지원이 업데이트되었습니다.

IMS를 사용하는 응용 프로그램은 레지스터 API에 "트랜잭션 지원" 플래그를 설정합니다.
대상 WAS 환경의 ola_rrs_syslog_syslog = 1 환경 변수가 설정되고 사용되도록 설정되었습니다.
IMS Control Region은 RRS=Y와 함께 실행해야 합니다.

8.0.0.5(및 8.5.0.2)

Fixpack 8.0.0.5/8.5.0.2에서는 (1) WAS에서IMS over WOLA/OTMA로의 RRS 트랜잭션콘텍스트 어설션 및 (2) CICS 채널 및 컨테이너의 지원 강화의 2가지 기능이 확장되었습니다.

IMS 트랜잭션의 경우:

IMS Control Region은 RRS=Y와 함께 실행해야 합니다.
대상 WAS 환경의 ola_rrs_syslog_syslog_otma = 1개의 환경 변수가 설정되고 사용되도록 설정됨

CICS 채널 및 컨테이너 지원을 확장하기 위해 8.0.0.5/8.5.0.2 이전 CICS 채널 및 컨테이너 지원은 요구와 응답 모두에 대해 단일 고정 이름 채널 및 BIT 또는 CHAR 유형의 단일 컨테이너로 제한되었습니다.8.0.0.5 / 8.5.0.2의 경우:

대상 CICS 프로그램에서 하나 이상의 컨테이너 송수신
채널명은 setLinkTaskChanID() 메서드를 사용하여 설정합니다.
채널 유형은 setLinkTaskChanType() 메서드를 사용하여 설정합니다.
개별 요청 컨테이너의 이름은 put() 메서드를 사용하여 Mapped Record에 데이터를 추가하여 설정합니다.
Mapped Record의 키는 CICS 컨테이너 이름에 대응하며 대응하는 값은 CICS 컨테이너를 채우기 위해 사용됩니다.
응답 컨테이너명은 CICS 요구가 완료된 후 채널에서 추출되어 새로운 Mapped Record에 입력되며 클라이언트에 반환됩니다.

구성 요소들

최적화된 로컬 어댑터는 다음 컴포넌트로 분류할 수 있습니다.

인터페이스 모듈 - OLA 인터페이스 및 OLA API에 대한 프로그램 액세스를 제공합니다.
CICS 태스크 관련 사용자 종료, 태스크 서버 링크 및 트랜잭션 제어 - CICS의 프로그램 자산에 대한 발신 콜을 지원하기 위한 간단한 메커니즘을 제공합니다.
JCA 리소스 어댑터 - Java 환경과 외부 환경 간의 인터페이스를 제공합니다.
Development Tooling Support - OLA 지원 응용 프로그램 개발을 위한 지원 클래스를 제공합니다.
샘플 - 프로그래밍 모델의 사용을 나타내는 C/C++, COBOL 및 Java 샘플 세트

CICS 지원의 개요

최적화된 로컬 어댑터는 CICS에서 태스크 관련 사용자 종료(TRUE)로 구현됩니다.이는 CICS 크로스 메모리에서 WAS z/OS 주소 공간으로의 필수 연결을 제공합니다.

또한 WAS에서 CICS로의 콜에는 Link Server Task(BBO$)와 Link Invocation Task(BBO#)가 제공됩니다.BBO$/BBO# 링크서버 태스크는 CICS 프로그램의 프로그래밍 세부사항을 차폐합니다.WAS로부터의 OLA 콜은 이들 지정된 태스크에 의해 처리되며 이름 있는 CICS 프로그램은 표준 EXEC CICS LINK 콜과 함께 호출됩니다.이름이 붙은 CICS 프로그램은 변경되지 않고 OLA를 사용하여 WAS에서 콜이 온 것을 인식하지 않습니다.CICS의 타깃프로그램은 LINK 콜에서 호출할 수 있어야 합니다.COMMAREA와^{[clarification needed]} 채널/컨테이너가 모두 지원됩니다.

BBOC 트랜잭션도 제공되어 TRUE 수동 시작(PLTPI에 없는 경우), TRUE 정지, 링크 서버 시작 및 중지, 기타 제어 및 관리 기능 등의 작업을 수행하기 위한 일련의 제어 명령을 제공합니다.

OLA 프로그래밍 인터페이스 모듈라이브러리 데이터 세트는 CICS 영역의 DFHRPL DD 문에 연결해야 합니다.

다음 그림은 트랜잭션 전파 및 보안 어설션에 대한 WOLA CICS 지원 개요를 보여 줍니다.

IMS 지원의 개요

Optimized 로컬어댑터는 IMS의 외부 서브시스템으로 구현됩니다.메시지 처리 프로그램(MPP), 배치 메시지 처리 프로그램(BMP), IMS Fast Path(IFP) 및 배치 DL/I 응용 프로그램에서 사용이 지원됩니다.

IMS 에서 WAS 에의 콜은, External Subsystem Attach Facility(ESAF; 외부 서브 시스템 접속 기능)를 사용합니다.이것은 DB2나 MQ와 같은 다른 서브시스템에서 사용되는 인터페이스와 동일합니다.

WAS에서 IMS 의존 지역으로의 콜은 OTMA를 사용하여 실행할 수도 있고 직접 실행할 수도 있습니다(즉, IMS의 프로그램은 OLA API를 사용하여 다음과 같이 '서비스를 호스트'합니다).OTMA는 약간의 오버헤드를 들여 IMS 애플리케이션에 OLA 투과성을 제공합니다.IMS 어플리케이션에서 OLA API를 사용하면 오버헤드가 경감되어 퍼포먼스와 throughput이 향상됩니다.

그 프로그래밍 APIIMS을 위한 것이다 똑같은 형식과 구문 원래 소개했다.그러나 그들이 달려 IMS를 파악한 후 확대 구조 조정 금융을 사용하기 위해 업데이트되고 있다.

또한 WAS의 자바 암호 구조 리소스 어댑터를 구현하는ola.rar 파일이 되야 한다 한 Fixpack 7.0.0.12 또는 이후 IMS에 사용할 선적이 발송되었습니다. 중요 메서드 매개 변수는 IMS지원 때문에 업데이트 WAS 이용할 수 있는 7.0.0.12과 함께 오는 ola.rar를 다시 설치함으로써 만들어진다 업데이트되었다.

다음 그림 거래 전파와 보안 어설션의 WOLA IMS지원을 요약하였다.

프로그래밍에 관한 고려 사항

WAS z/OS로 착신

외부의 주소 공간 제공된 인터페이스 모듈을 통해 OLA 메커니즘과 문서화된 API에 액세스 합니다.13개 API현재 시점이 있다.그들은 아래 분류된다.

자바 프로그램들이 WASz/OS 환경에서 달리고 있는 바치는 기도의 외부에서 공격의 표적이 될 기원하는 무국적 회기는 그 OLA 클래스 파일 개발 툴 사용 지원에 공급을 사용하여 bean의 OLA 인터페이스를 구현해야 합니다.

WAS z/OS에서 아웃바운드

한 자바 프로그램을 할당한 OLA 요청에 착수해야 할 경우 서블릿 또는 EJB로 구현될 수 있다.제공된 자바 암호 구조 리소스에 자바 프로그램 코드 어댑터(ola.rar)클래스 파일 개발 툴 사용 지원으로 공급됩니다.

그 발신 호의 목표 외부 주소 공간은 국가 그 요청을 받아들일 준비가 되어에 있어야 합니다.2가지 기본적인 모델 있습니다:

외부 주소 공간은 CICS경우에는 사용자 옵션이 제공된 링크 서버 작업은 받는 요원으로 기존의 CICS프로그램 자산의 편에서 행동해야 하기 위한 가지고 있다.(BBO$ 기본적으로)호출과 이슈들에 대한 EXECCICS링크 프로그램 interactionSpecImpl에라는 이름의 받는 Link서버 작업이다.setServiceName().기존의 CICS프로그램에 아무것도 바뀌지 않았어 다시 COMMAREA 또는 Channels/Containers을 지지하고 필요하고 있다.
외부 주소가 IMS인 경우, 콜은 IMS OTMA 인터페이스(IMS 애플리케이션의 변경을 의미하지 않음) 또는 OLA(IMS 프로그램의 OLA API를 사용해 「서비스를 호스트」하는 것을 의미)를 사용해 직접 발신할 수 있습니다.
외부 주소 공간이 CICS 또는 IMS 이외의 경우 프로그램은 제공된 API 중 하나를 사용하여 서비스를 호스트해야 합니다.이로 인해 프로그램은 WAS z/OS의 Java 프로그램으로부터 호출을 수신할 수 있는 상태가 됩니다.콜이 수신되면 요청을 처리하고 WAS z/OS의 Java 프로그램에 응답을 제공할 수 있습니다.

동기 및 비동기 조작

API는 두 모드를 모두 지원합니다.Synchronous는 응답이 수신될 때까지 프로그램 제어가 호출 프로그램으로 반환되지 않기 때문에 보다 심플한 프로그래밍 모델을 제공합니다.비동기 기능은 장기 실행 중인 타깃 프로세스에서 돌아오는 응답을 기다릴 필요 없이 설계자가 다른 작업을 처리할 수 있는 기회를 제공합니다.

모듈러 설계

OLA 고유의 프로그래밍 아티팩트를 설계하여 OLA 인터페이스와 기존 자산 간의 '브릿지' 역할을 할 수 있습니다.이를 통해 기존 프로그래밍 자산에 대한 영향을 최소화하고 "플랫폼 잠금" 정도를 제한할 수 있습니다.

CICS로의 발신: 제공된 링크서버 실장을 사용합니다.CICS 프로그램은 전혀 변경되지 않습니다.
Inbound to WAS: OLA 콜을 수신한 후 지정된 EJB를 돌려 호출하는 EJB를 구축합니다.대상 EJB가 동일한 JVM에 있다면 매우 효율적일 수 있습니다.대상 EJB가 동일한 LPAR의 동일한 셀에 있는 경우 앞서 언급한 "로컬 통신" 기능이 사용됩니다.

API

13개의 API가 있으며 다음 범주로 분류됩니다.

General Setup and Teardown -- BBOA1REG(레지스터) 및 BBOA1URG(레지스터 취소)
인바운드 기본 -- BBOA1INV(자동 get response를 사용한 호출)
인바운드 고급 -- BBOA1CNG(연결 가져오기), BBOA1SRQ(송신 요청), BBOA1RCL(응답 길이 가져오기), BBOA1GET(메시지 데이터 가져오기), BBOA1CNR(연결 해제)
Outbound Basic -- BBOA1SRV(서비스 호스트), BBOA1SRP(응답 전송)
아웃바운드 고급 -- BBOA1RCA(연결 시 수신), BBOA1RCS(연결 시 수신), BBOA1GET(메시지 데이터 가져오기), BBOA1SRP(전송 응답) 및 BBOA1SRX(전송 예외)

InfoCenter에는 파라미터 목록과 RC(Return Code) 및 RSN(Reason Code)과 함께 각각의 완전한 기입이 있습니다.cdat_olaapis에서 검색합니다.

일반적인 API 패턴의 그림

일반적인 인바운드 API 사용 모델은 다음과 같습니다.

이 경우 BBOA1REG API를 사용하여 WebSphere Application Server for z/OS Daemon 그룹(셀 단축 이름) 및 BBOA1의 여러 호출에 등록합니다.INV는 대상 EJB를 호출하는 데 사용됩니다.BBOA1INV는 동기화되므로 EJB가 응답을 반환할 때까지 프로그램 제어가 유지됩니다.이 API는 호출 프로그램이 응답 메시지의 크기를 미리 알고 있을 때 유용합니다.콜시에 응답 메시지의 사이즈를 알 수 없는 경우는, 보다 원시적인 API(BBOA1SRQ(송신 요구), BBOA1RCL(get response length), BBOA1GET(get message data)가 적합합니다.

호출 프로그램이 작업을 완료했다고 판단하면 BBOA1을 사용합니다.데몬 그룹에서 등록을 취소하는 URG.

대상 Java 프로그램의 응답 간격이 길면 비동기 모델이 더 나을 수 있습니다.다음 그림은 원시 API로 알려진 것을 사용하여 비동기 콜을 실행하는 방법을 보여 줍니다.BBOA1async=1 매개 변수가 설정된 SRQ:

그림에 나타나 있듯이 비동기 모드를 사용하면 Java 이외의 프로그램이 제어 및 기타 처리를 수행할 수 있습니다.이는 향후 어떤 시점에서 응답을 확인하는 것을 의미합니다.이 목적으로 BBOA1RCL이 사용됩니다.이 예에서는 BBOA1RCL이 동기적으로 발행됩니다(파라미터 비동기=0).응답 가능한 경우 BBOA1RCL은 길이와 프로그램 제어를 프로그램으로 반환합니다.응답할 수 없는 경우 BBOA1RCL은 응답할 수 있을 때까지 프로그램 제어를 유지합니다.비동기=1의 BBOA1RCL은 응답할 수 없는 경우 x'FFFF'를 반환하고 프로그램 제어가 즉시 반환됩니다.

아웃바운드용 기타 그림은 IBM Techdocs 웹 사이트에 있는 WP101490 문서에서 찾을 수 있습니다.

주의: WAS에서 CICS로의 발신에는 API 코딩이 필요하지 않습니다.이 경우 제공된 BBO$/BBO# 링크 서버 트랜잭션은 이 처리를 수행합니다.이러한 링크 서버 트랜잭션은 BBOA1SRV API와 유사한 내부 구성을 사용하여 "서비스를 호스트"합니다.배치 프로그램으로 아웃바운드하려면 API를 사용하여 "서비스를 호스팅해야 합니다.

트랜잭션성

Optimized Local Adapters는 CICS에서 WAS로 착신하는 2단계 커밋(2PC) 처리를 지원합니다.

유지 보수 7.0.0.12가 등장함에 따라 Optimized Local 어댑터는 WAS에서 CICS로의 2상 커밋도 지원합니다.7.0.0.12 이전 버전에서는 WAS에서 CICS로의 트랜잭션 지원은 "sync on return"으로 제한되었습니다.

IMS의 경우 IMS 의존 영역에서 WAS로 착신하는 트랜잭션어설션 지원은 fixpack 8.0.0.4 및 8.5.0.1로 제공되었습니다.WOLA/OTMA를 통해 WAS에서 IMS로 발신되는 트랜잭션어설션 8.0.0.5로 제공됩니다.

트랜잭션 전파는 배치, USS 또는 Airlines Line Control에 대한 인바운드 또는 아웃바운드 전파는 지원되지 않습니다.

보안.

Optimized Local Adapter는 다음과 같은 상황에서 ID를 확인할 수 있습니다.

WAS --> CICS : WOLA API 호출에 사용되는WAS 스레드상의 ID를 사용하여 CICS에 ID를 아사트할 수 있습니다.이를 위해서는 WOLA CICS 링크 서버를 사용하고 SEC=Y 매개 변수로 시작해야 하며 CICS 영역이 SEC=와 함께 실행되어야 합니다.YES 및 링크 서버 작업이 실행되는 ID에는 전파된 사용자 ID를 대신하여 트랜잭션을 시작하려면 REMOBLAT SAF 권한이 있어야 합니다.자세한 내용은 IBM InfoCenter를 참조하십시오.
WAS --> Batch, USS 또는 ALCS : ID를 확인하려고 하지 않습니다.대상 프로세스는 시작할 때 사용된 ID로 실행됩니다.
CICS --> WAS : CICS는 지역 ID 또는 응용 프로그램 사용자 ID를 아사트할 수 있습니다.
Batch, USS 또는 ALCS : 외부 프로세스는 ID를 WAS z/OS로 아사트하려고 합니다.

제한 사항

WAS z/OS 최적화 로컬 어댑터는 지정된 LPAR 내에서만 사용할 수 있습니다.이는 크로스 메모리메커니즘으로 LPAR 간 또는 머신 외부로 이동할 수 없습니다.

외부 링크

Redbooks: z/OS 기반 WebSphere - 최적화된 로컬 어댑터
IBM Techdocs: WebSphere z/OS 최적화 로컬 어댑터
IBM InfoCenter: z/OS용으로 최적화된 로컬 어댑터 사용 계획
동영상 시연은 WASOLA1 키워드로 검색하면 YouTube에서 볼 수 있습니다.
YouTube 동영상:
- WP101490 - WOLA - WOLA의 필수 [1]
- WP101490 - WOLA - CICS [ 2 ]
- WP101490 - WOLA - IMS [3]
- WP101490 - WOLA - 네이티브 API Part 1/2 [4]
- WP101490 - WOLA - 네이티브 API Part 2/2 [5]
- WP101490 - WOLA - Java 고려사항 [6]

Search