출처 : http://wtkim.egloos.com/4548885
미들웨어
· 미들웨어란?
①미들웨어는 클라이언트 프로그램과 서버 프로그램 사이에 존재하면서
클라이언트와 서버간에 연결을 유지/관리하면서, 클라이언트의 작업 처리
요구를 서버에 전달하는 일을 하는 소프트웨어이다.
②미들웨어에는 기본 기능만을 수행하는 더미 미들웨어(예를들면, 2계층
시스템에서 클라이언트와 서버간에 데이타 통로만 제공하는 소프트웨어와
같은 프로그램)와 더미 미들웨어가 가진 기능 이외에 해당 서비스를
찾아준다든가, 큐잉 기능 등의 고급 기능을 수행하는 미들웨어가 있다.
③미들웨어가 정상적으로 수행되기 위해서는 클라이언트측과 서버측
미들웨어가 별도로 존재한다.
④클라이언트와 서버간에 자료의 교환은 각각의 미들웨어를 반드시 통하며,
클라이언트와 서버를 개발하는 개발자는 미들웨어 인터페이스를 통하여
개발한다.
· 미들웨어의 기능
1)기본기능
①클라이언트와 서버간에 통신이 가능하도록 데이타 통로를 제공하는
기능.
②클라이언트와 서버간에 연결 세션을 유지/관리하는 기능.
③클라이언트의 작업 처리에 필요한 서비스를 찾아주는 기능.
2)확장기능
①여러 서버에 흩어진 프로그램에 클라이언트 요청을 라우팅하는 기능.
②서버 프로그램이 작어중이면 클라이언트 요청을 기다리게 하는 기능.
③서버 프로그램을 감시하는 기능.
④데이타베이스 트랜잭션을 관리하고, 데이타베이스와 공조하는 기능.
· 3계층 시스템 구현용 미들웨어
1)비 TP-Monitor 계열의 미들웨어
①Entera, Forte등과 같은 소프트웨어가 TP-Monitor 계열이 아닌
미들웨어이다.
②이들 프로그램을 이용하여 3계층 시스템의 구축이 가능하지만, 대규모
트랜잭션 처리를 요구하는 어플리케이션에는 적합하지가 않다.
2)TP-Monitor 계열의 미들웨어
①Tuxedo, Top-End, Encina, CICS등과 같은 소프트웨어가 TP-Monitor
계열의 미들웨어이다.
②이들 프로그램을 이용하여 3계층 시스템의 구축이 가능할 뿐만 아니라,
대규모 트랜잭션 처리가 가능한 미들웨어이다.
TUXEDO의 기원
턱시도 시스템은 발전된 전화교환 시스템을 위한 고성능 통신과 트랜잭션을
추적하는 중추로서 원래 AT&T사에 의해 개발되었다.
유닉스가 일반 컴퓨터 시장에서 침입하기 시작한 것처럼 시장의 반대 끝에서
유닉스를 후원하기 위해 턱시도를 상업용 OLTP로 제공하기로 결정했다.
턱시도 시스템은 비지니스맨에 의해 비즈니스용으로 설계되었고, 오픈 시스템
상에서 트랜잭션 처리를 위한 시장에서 가장 적당한 제품이다.
데이터베이스 회사는 곧 오픈 시스템 특히 유닉스쪽으로 옮겨 갔다.
인포믹스와 같은 회사는 유닉스 플랫폼상의 데이터베이스 엔진을 생산하게
되었고, 오라클과 같은 판매자는 그들의 기동력을 유닉스에 맞추었다.
TUXEDO 정의
·클라이언트/서버 환경에서의 온라인시스템(OLTP)을 원활하게 지원하여 주는
S/W
·다수의 사용자들이 자기가 요청한 작업들을 실시간내에 처리되어 응답받기를
원하는 시스템
·유닉스 중심의 분산환경에서 메인프레임상의 온라인 트랜잭션 관리 소프트
웨어인 CICS등과 같은 역할을 해주는 S/W
·Tuxedo는 클라이언트와 서버 양쪽에 탑재되어 RDBMS의 Access 및 전송을
지원하여 주는 중간다리 역할을 하는 S/W
TUXEDO의 기능(1)
1. 부하 분산
-특정 시스템으로만 부하가 편중 되는 것을 막아 시스템 전체 성능을
최적화 함.
2. 처리 시간 보장
-Peak-Time시나 대용량 트랜잭션 발생시 안정적이고, 빠른 처리능력을
보장함.
3. 데이타 의존형 라우팅
-서비스 이름과 입력된 데이터 값에 따라 해당 Machine의 DataBase를
액세스함.
4. 분산자원의 중앙관리
-C/S 환경에서 가장 어려운 부분인 자원 관리를 중앙에서 일괄적으로
관리함.
-GUI(Motif) Administration Tool 제공함.
5. 개발의 생산성
-Program 작성상의 용이성 및 확장성을 보장함.
6. 표준기술 지원
-지원 H/W Platform의 종류, 개방성 및 표준을 지원하여 향후 시스템 및
자원의 확장시 용이함.
7. 장애극복 및 복구
-장애 발생시 사용자가 계속해서 서비스를 받을 수 있게 하는 장애관리 및
복구 기능을 지원함.
8. 데이타 무결성
-분산된 DBMS, Network, System, OS등의 처리과정 중 전체에 대한 데이터
및 트랜잭션 무결성을 보장하여, 시스템 신뢰도 확보함.(2 Phase Commit)
TUXEDO의 기능(2)
· RPC (Remote Procedure Call) 기능
:다른 머신상에 있는 Procedure(프로그램)를 불러내는 기능으로,
프로그래머는 통신을 의식하지 않고 보통의 Sub_Routine을 불러내는 식으로
코딩이 가능함.
· Multi-Thread 기능
:유닉스 프로세스로 여러 Application을 실행할 수 있으며, TP_Monitor
내부의 오버헤드를 줄일 수 있으므로 트랜잭션 처리를 고속화할 수 있다.
· Directory 관리 기능.
:Directory 서비스는 프로그램등 시스템 자원의 소재지 관리 기능.
· Data 의존형 Routing 기능
:Request의 데이터 내용을 보고 수신처의 서버를 판단하는 기능.
· 여러서버 사이의 Load-Balancing
:분산처리 환경에서 여러 서버 사이의 Request를 배분하는 기능.
· 클라이언트 프로그램 관리
:서버나 클라이언트를 프로그램 추가할때에는 반드시 시스템 구성
(Configuration) File을 변경해야 한다.
이때, 시스템을 정지시키지 않고 온라인으로 변경할 수 있는 기능.
· 시스템 리포팅 기능
:장애 발생시 트랜잭션 로그나 에러 로그의 분석을 위해서 이들 로그를
편집해서 출력하는 기능.
TUXEDO 용어
·BBL Bulletin Board Liaison process
Shared Memory를 관리 해 주는 프로세스
·DBBL Distinguished Bulletin Board Liaison process
네트워크 환경에서 Master Site에 떠서 BBL을 관리하는 프로세스
·ATMI Application Transaction Manager Process
클라이언트와 서버를 지원하기 위한 /T에서 제공하는 함수들
·RM Resource Manager
데이터베이스, 프린터 서버 등의 자원을 관리하는 부분
·System /T 턱시도 시스템 OLTP Component
턱시도 시스템의 핵심 요소이며, 트랜잭션을 관리해 줌
·TM Transaction Manager 트랜잭션 관리자 (시스템 /T)
·XA X/Open defined TM ↔ RM Interface
X/Open에서 정의한 표준화 된 인터페이스로 이기종 데이터베이스를
투과적으로 다룰 수 있으며, 2단계 갱신 (2 Parse Commit)으로
무결성이 보장 됨
·TMS Transaction Manager Server
이기종 데이터베이스를 지원하는 XA interface를 사용 할 경우 필요함
·FML Field Manipulation Language
Field Buffer라는 데이터 구조를 정의하고 처리할 수 있는 C 언어
함수이며 named field를 사용하여 클라이언트와 서버 사이의
커뮤니케이션을 제공
·MSSQ Multiple Server, Single Queue
같은 서비스를 제공하는 다수의 서버에 한 개의 큐를 공유하도록 하여
특정한 서버 만 작업량이 많아지는 것을 방지함
named field를 사용하여 클라이언트와 서버 사이의 커뮤니케이션을
제공
·WSC Workstation Client (서비스를 요청한 클라이언트)
·WSL Workstation Listener
서비스 요청을 받아 WSH로 연결시켜 주는 데몬 프로세스
·WSH Workstation Header
서비스 요청한 buffer data를 서버로 연결시키고 정보를 주고받음
TUXEDO Security
※TUXEDO SYSTEM은 전체 4단계의 Security를 제공한다.
1단계 : 시스템제공의 UID , GID 와 Password
2단계 : Application 접근에 대한 authentication
3단계 : user의 authorization level에 대한 security
4단계 : 1992년 이후 제공되는 Kerberos machanism security
TUXEDO Magration
1. Migration DBBL
master machine에 장애가 발생하였을 경우 tmboot, tmshutdown등의 관리
명령어를 사용할 수 없으므로 DBBL을 backup master로 이동하여 이를 수행
할 수 있도록 한다.
1) 처리순서
$ tmadmin
> m
2) 세부사항
① RESOURCES의 MASTER에 backup machine이 선언되어 있어야 한다.
② OPTIONS에 MIGRATE를 선언
③ 위의 명령은 backup machine에서 실행시킨다.
2. Migration Servers
특정 Group내에 있는 Server들을 migrate
1) 처리 순서
$ tmadmin
> stop -R -g groupname
> migg groupname
2) 세부사항
① migrate될 server들을 shutdown시킬 때는 반드시 "-R" option을
사용한다.
② migrate될 server들은 LMID변수에 옮겨갈 machine을 미리 선언해
놓는다.
③ group내의 server들은 RESTART=Y로 설정되어 있어야 한다.
3. Migrating Machines
LMID를 이용하여 그 machine내의 server들을 migrate시킨다.
1) 처리 순서
$ tmadmin
> stop -R -l lmid
> migm machine
2) 세부사항
① 이 역시 마찬가지로 shutdown시에 "-R" option을 사용
② migm은 argument로 하나의 LMID를 갖는데 이 LMID는 migrate하려는
server들이 수행되던 machine의 이름이다.
③ 이 LMID를 갖는 machine내의 모든 server는 RESTART=Y로 선언되어
있어야 한다.
< 참고>
- "stop -R" 명령을 수행시킨 후에 migration을 취소할 수도 있는데,
이는 "-cancel" option을 사용하면 된다.
> migg -cancel groupname
> migm -cancel lmid
- "-cancel" option을 "-R" option없이 shutdown한 것과 똑같은 효과를 지닌다.
TUXEDO Concurrent User
1. Tuxedo의 Concurrent User 개념은 Tuxedo Client에서 Server 상의 Service를
호출하여 Service Program이 기동(Tpinit)에서부터 완료(Tpreturn)까지의
기간동안 Server상에서 수행되는 동시 Service Program의 수치를 말함.
2. 일반적으로 H/W의 초당처리속도(TPC)는 Tuxedo의 Concurrent User수에 비해
훨씬 높은 처리속도를 가지며, 순수하게 TP 환경에서 H/W의 최대
Performance를 내기 위해서는 Tuxedo의 Concurrent User수를 H/W의 TPC
수치와 동일하게 설정 해야만 한다.
3. Tuxedo 6.2 Version 이후 부터는 각각의 Server별로 Concurrent User수를
보유하고 있어야만 서버별로 동일한 성능을 기대할 수 있게 된다.
4. 개발용 모듈(SDK)와 RunTime 모듈(RDK)는 동일한 서버상에 동시에 Porting이
가능.
5. 어떤 금융업무의 Concurrent User 산정
① 시스템이 월간 1,800 만건의 Transaction이 발생한다고 가정.
② 월간 1,800만건을 25일 근무/8시간 운영으로 가정하고 초당 평균
Transaction 발생 수치를 계산했을 때 약 40 Transaction이 산정됨
③ 초당 40 Transaction은 Tuxedo 상에서 1초에 40 service Program이 기동 및
수행완료가 되어야 하는 경우임.
④ Tuxedo 상에서 Service Program이 2초내에 처리가 완료되도록 Target Time을
설정한다면 각각의 Transaction이 Waiting Time 없이 바로 처리 되기
위해서는 Tuxedo Concurrent User수는 80이 되어야 함.
(Transaction당 Target Time이 3초이면 Tuxedo Concurrent User수는 120이
되어야 함)
⑤ Network Server 2대로 운영하며 한 서버를 StandBy 상태로 가져갈 때는
Tuxedo User수를 다른 서버의 100% 수준으로 가지 않을수도 있음.
TP-Monitor정의
① 클라이언트/서버 환경에서의 온라인 시스템(OLTP)을 원활하게 지원하여 주는
Software.
※온라인 시스템(OLTP)
한 시스템에 접속된 다수의 사용자들은 일정한 작업에 대한 요청들을
동시에 요구하고 각 사용자들은 자기가 요청한 작업들을 실시간내에
처리되어 응답받기를 원하는 시스템.
② 유닉스 중심의 분산환경에서 Mainframe상의 온라인 트랜잭션 관리 S/W인
CICS등과 같은 역할을 하여 주는 Software.
③ TP-Monitor는 클라이언트와 서버 양쪽에 탑재되어 RDBMS의 Access 및 전송을
지원하여 주는 중간다리 역할을 하여 줌.
TP-Monitor장점
①처리 시간 보장 : Peak-Time시나 대용량 트랜잭션 발생시 안정적이고, 빠른
처리능력을 보장함.
②개발의 생산성 : Program 작성상의 용이성 및 확장성을 보장함.
③장애극복및 복구 : 장애 발생시 사용자가 계속해서 서비스를 받을 수 있게
하는 장애관리 및 복구 기능을 지원함.
④데이타 무결성 : 분산된 DBMS, Network, System등의 처리과정 중 전체에 대한
데이터 및 트랜잭션 무결성을 보장하여, 시스템 신뢰도
확보함. (2 Phase Commit)
⑤부하 분산 : 특정 시스템으로만 부하가 편중 되는 것을 막아 시스템 전체
성능을 최적화 함.
⑥자원의 중앙관리 : C/S 환경에서 가장 어려운 부분인 자원 관리를 중앙에서
일괄적으로 관리함.
⑦표준기술 지원 : 개방성 및 표준을 지원하여 향후 시스템 및 자원의 확장시
용이함.
TP-Monitor기능
①RPC(Remote Procedure Call) 기능
-다른 머신상에 있는 Procedure(프로그램)를 불러내는 기능으로
프로그래머는 통신을 의식하지 않고 보통의 Sub_Routine을 불러내는 식으로
코딩이 가능함
-RPC는 2단계 갱신(2 Phase-Commit)에도 대응하고 있어 분산환경에서의
데이터나 트랜잭션의 무결성을 보장한다. 즉 트랜잭션 처리중에 어떤 장애가
발생하면 DB에 대한 갱신을 모두 Rollback 할 수 있다
-현재 X/Open은 RPC에 대해 세가지 사양의 표준화를 추진하고 있으며 TUXEDO
기반의 XATMI와 TxRPC, 그리고 동배간 통신의 표준이다
②Multi-Thread 기능
-유닉스 프로세스로 여러 Application을 실행할 수 있으며, TP_Monitor
내부의 오버헤드를 줄일 수 있으므로 트랜잭션 처리를 고속화할 수 있다
③Directory 관리 기능
-Directory 서비스는 프로그램등 시스템 자원의 소재지 관리 기능
-클라이언트가 RPC로 서버 프로그램을 불러낼 때 네트웍 어드레스를 의식하지
않고 프로그램명(서비스명)만 지정하면 되는 방식이다.
④Data 의존형 Routing 기능
-Request의 데이터 내용을 보고 수신처의 서버를 판단하는 기능
-예를 들면 동일한 특성의 데이타를 여러 서버로 분산한 경우 고객의
우편번호를 보고 처리할 서버로 배분할 수 있는 기능이다
⑤여러 서버 사이의 Load Balancing
-분산처리 환경에서 여러 서버 사이의 Request를 배분하는 기능
-균등하게 배분하는 라운드로빙방식, 서버의 처리능력에 따라 일정비율로
배분하는 방식, 서버의 부하상황을 보고 동적으로 배분하는 방식등이 있다.
⑥클라이언트 프로그램 관리
-서버나 클라이언트를 추가할때에는 반드시 시스템 구성(Configuration)
File을 변경해야 한다
이때 시스템을 정지시키지 않고 온라인으로 변경할 수 있는 기능
-분산처리 환경에서는 클라이언트측 Application Program의 Version 관리
기능이 중요하다
즉, 새로운 버젼의 프로그램을 미리 클라이언트에 전송해 두고 어떤
시점에서 일제히 변경할 수 있는 기능
⑦시스템 리포트 기능
-장애 발생시 트랜잭션 로그나 에러 로그의 분석을 위해서 이들 로그를
편집해서 출력하는 기능
TP_Monitor의 구성
TP_Monitor 각 제품들은 UNIX용 Application 환경 표준화 단체인 X/Open이 정한 DTP
(분산 트랜잭션 처리) 모델에 준거하고 있으며, 여기에는 OLTP 시스템에 필요한
구성요소를 정의하고 각 구성요소간의 인터페이스를 규정하고 있다
▶Transaction Manager : 트랜잭션라우팅, 전역 트랜잭션 관리, 오류회복등의 관리기능
▶Resource Manager : DBMS 또는 프린터서버등과 같은 공유자원 관리기능
▶Communication Resource Manager : 클라이언트/서버사이 및 서버간의 통신전반을
제어하는 기능
▶XA : XA를 채택한 TP_Monitor는 XA에 대응한 모든 RDBMS와 자유롭게 연결 가능함
▶RPC(Remote Procedure Call) : 다른 머신상에 있는 Procedure를 불러내는 기능
(TxRPC, XATMI,동배간통신등의 3종류의 표준이 있음)
TUXEDO 시스템의 통합 방안
턱시도는 여러 시스템 중에서 master node를 선정하여 전체 시스템을 관리한다.
턱시도의 시스템 관리기능(tmadmin)은 각 시스템의 상태 즉 데몬 process 및
AP server process의 이상 유무를 감시할 수 있다.
또한 네트워크의 partition 여부도 감시가 된다.
턱시도는 master node의 down을 대비하여 backup master를 두고 운용한다.
서버가 많을 경우는 System/Domain을 이용하여 시스템을 효율적으로 운용할
수도 있다. 턱시도는 Client의 요청 횟수 등의 감시도 가능하다.
TUXEDO 시스템의 안정화 방안
· BB(Bulletin Board) : Tuxedo 의 제반정보가 등록되는 공유메모리 구조체.
· BBL(Bulletin Board Liaison) : BB 를 관리해주는 Process.
· DBBL(Distributed Bluetin Board Liaison) : BBL 들의 상태를 감시하는
Process.
· Bridge Process : 다른 System 과 정보 및 메세지를 교환하는 Process.
· AP Server : 어플리케이션 서버
턱시도는 위에 언급된 시스템 데몬 Process 나 AP Server Process 들이
이상이 생겼을 때, 자동으로 Restart 시켜줌으로써 시스템의 안정성 및
가용성을 높여준다.
TUXEDO 시스템의 백업 방안
. 턱시도는 System /Q 모듈을 사용하여 일괄처리 뿐만아니라 On-Line처리가
가능하다.
그 기능으로는 일정시간이나 조건을 만족시키면 자동적으로 주어진 업무를
실행시킬 수가 있다.
Oracle로 구축된 데이타베이스를 일정시간마다 혹은 지정된 시간에 또는
어떤 조건을 만족시키면 자동적으로 mirrored database로 복사시킬 수 있다.
TUXEDO 시스템의 확장 방안
·턱시도는 기본적으로 On-line 트랜잭션을 처리하므로 시스템을 down 시킬 수
없다.
따라서 턱시도는 새로운 machine 을 추가하여 기존 시스템과 통합시킬 때도
down 없이 동적으로 재구성이 가능한 확장성을 갖고 있다.
새로운 machine 뿐만 아니라 application server 나 group, 서비스 등을
추가 할 때도 동적으로 재구성이 가능하다.
새로 추가되는 시스템이 이기종 시스템, 이기종 데이타베이스 등과 무관하게
통합이 가능한 우수한 기능을 갖고 있다.
TUXEDO 활용효과
· 처리시간 보장
:Peak-Time시나 대용량 트랜잭션 발생시 안정적이고, 빠른 처리능력을
보장함
· 개발의 생산성
:Program 작성상의 용이성 및 확장성을 보장함
· 장애극복 및 복구
:장애 발생시 사용자가 계속해서 서비스를 받을 수 있게 하는 장애관리 및
복구 기능을 지원함
· 데이터 무결성
:분산된 DBMS, Network, System등의 처리과정 중 전체에 대한 데이터 및
트랜잭션 무결성을 보장하여, 시스템 신뢰도 확보함. (2 Phase Commit)
· 부하분산
:특정 시스템으로만 부하가 편중 되는 것을 막아 시스템 전체 성능을 최적화
함
· 이기종 데이터베이스의 활용
:단일 Application에서 이기종 데이터베이스를 연결시키는 능력이 용이함
(Resource Manager)
· 표준기술지원
:개방성 및 표준을 지원하여 향후 시스템 및 자원의 확장시 용이함
FML함수
● Finit()
- 기능 : buffer을 초기화하기 위하여 사용한다.
- Syntax
Finit(FBFR *transf , int len);
① FBFR *transf : buffer의 포인터명
② int len : buffer의 길이
● Fchg()
- 기능 : 프로그램 변수의 값을 지정된 Buffer의 Field에 Move
- Tuxedo Buffer -> 프로그램 buffer
- Syntax
Fchg(FBFR *transf,FLEID fieldid,FLDOCC occ,char *buf,FLDLEN len);
① FBFR *transf : buffer의 포인터명
② FLDID fieldid : FML Buffer Header에 정의된 Field명
③ FLDOCC occ : field의 occurrence number 0부터시작
multi row data를 사용하는 경우 지정
④ char *buf : FML buffer에 move할 데이타 변수
buf의 pointer를 move해야 한다.
⑤ FLDLEN len : carray buffer를 사용하는 경우 buf 의 크기
carray buffer외에 사용하는 경우 0을 지정
- Return Type : int형
- 예)
strcpy(H_juminid,"780209-2574411");
Fchg(transf,JUMIN_ID,0,H_juminid,0);
● Fget()
- 기능 : 지정된 field의 내용을 프로그램 변수의 buffer에 move한다.
- 프로그램 buffer -> Tuxedo Buffer
- Syntax
Fget(FBFR *fbfr,FLEID,fieldid,FLDOCC oc,char *buf,FLDLEN *len);
① FBFR *transf : buffer의 포인터명
② Fldid fieldid : fml header table에 정의 field명
③ FLDOCC oc : field의 occurrence number 0부터시작
multi row data를 사용하는 경우 지정
④ char *buf : fieldid의 buffer를 프로그램 buffer에 move하기
위한 char pointer 변수
⑤ FLDLEN *len : 프로그램 buffer에 저장할 수 있는 최대크기
- Return Type : int형
- 예) Fget(transf,JUMIN_ID,0,H_juminid,&len);
● Foccur()
- 기능 : 지정된 field occurrence 조사
즉 지정한 field가 multi row이면 지정한 field의 갯수를 return
- Syntax
FLDOCC FLDcnt;
FLDcnt = Foccur(FBFR *fbfr, FLDID fieldid);
① FLDcnt : occurrence의 결과를 얻기위한 변수
② FBFR *fbfr : fml buffer의 data buffer의 포인터
③ FLDID fldided : fml buffer에 정의된 Field명
- Return Type : FLDOCC형
- 예) FLDcnt = Foccur(fbfr,JUMIN_ID);
● Fldid()
- 기능 : Field name에 대한 id값을 return.
- Syntax
FLDID fldvar
Fldvar = Fldid(char *name);
① FLDID fldvar : fml buffer에서 지정한 field의 id 얻기위한 변수.
② char *name : Field table에 정의된 field명
- Return Type : FIELDID 형
- 예) fldvar = FIELD("jumin_id");
● Fconcat()
- 기능 : Field buffer를 다른 field buffer에 추가.
- Syntax
Fconcat(FBFR *dest, FBFR *src);
① *dest, *src : src의 내용을 dest에 추가
dest의 크기가 src를 포함할 만큼 충분하지 않으면
error 발생
- Return type : int형
● Fvals()/Fvall()
- 기능 : Fget()과 동일한 기능(Error가 발생한 경우 return값이 없다)
- Syntax
Fvals(FBFR *fbfr,field,oc);
FvalL(FBFR *fbfr,field,oc);
① Fvals는 문자열에 대한 pointer field에 대한 buffer내용을 얻는다.
② Fvll는 숫자형에 대한 pointer field에 대한 buffer내용을 얻는다.
- Return type : Fvals : char형 pointer , Fvall : long 형
예) variable = Fvals(transf,JUMIN_ID,0);
pay = Fvall(transf,PAY_ID,0);
ATMI함수
● tpinit()
- 기능 : Client와 Tuxedo System/T Application과의 접속
- syntax
tpinit(TPINIT *tpinfo)
① TPINIT *tpinfo : TPINIT구조체형 포인터 변수 지정
Tuxedo에 접속한 Client의 정보를 등록한다.
TPINIT 구조체
struct tpinfo_t {
char usrname[MAXTIDENT+2]; /* client user name */
char cltname[MAXTIDENT+2]; /* application client name */
char passwd[MAXTIDENT+2]; /* application password */
char grpname[MAXTIDENT+2]; /* client group name */
long flags; /* initialization flags */
long datalen; /* length of app specific data */
long data; /* placeholder for app data */
};
typedef struct tpinfo_t TPINIT;
- Return Type : int 형
● tpterm()
- 기능 : Tuxedo System/T Application종료
Tuxedo에 접속한 Clinet의 정보 삭제
- Syntax : tpterm();
- Return Type : int 형
● tpalloc()
- 기능 : Data를 저장할 Buffer의 할당 및 초기화
- syntax
FBFR *transf;
pfbr = (FBFR *)tpalloc(char *type, char *subtype, long size)
① FBFR *transf : Client에서 전송된 부분중에서 data부분을 저장
하기 위한 pointer, 다수의 부분을 할당하는 경우
transf1, transf2,... 순차적으로 지정
② char *type : 할당받을 buffer의 type지정(FML buffer로 고정)
③ char *subtype : FML buffer사용시 NULL로 지정
④ longsize : 할당받을 Buffer의 크기지정
- Return Type : Character형 포인터
- 예) FBFR *transf;
transf = (FBFR *)tpalloc("FML",NULL,(long)(5*1024));
주의사항) 반드시 tpalloc은 tpfree를 꼭 해 주어서 할당된
Buffer를 풀어 주어야 한다.
● tprealloc()
- 기능 : tpalloc에의해서 할당된 메모리가 적을 경우 Buffer size를
크게 하기 위하여 사용.
- syntax
transf = (FBFR *)tprealloc((char *)transf,long size);
① FBFR * : realloc에 의해서 return받은 메모리를 FBFR *로 형변환
② (char *)transf : size를 크게 조정하는 buffer를 char포인터로 형변환
③ long size : buffer의 크기를 지정한다.
- tprealloc은 tpalloc과 달리 tpfree가 필요 없다.
- Return Type : Character형 포인터
- 예) transf = (FBFR *)tprealloc((char *)transf,(long)(7*1024));
● tpfree()
- 기능 : 사용이 완료된 Buffer해제
- syntax
tpfree((char *)transf);
① (char *)transf : 사용 완료된 버퍼의 Type을 Character형 포인터로
변환한후 메모리를 해제한다.
- 예) tpfree((char *)transf);
● tpcall()
- 기능 : 동기 방식으로 Service를 요구하고 응답이 올때까지 기다린다.
- syntax
tpcall(char *service, char *sendbuf, long sendlen,
char **rcvbuf, long *rcvlen,long flags);
① char *service : 요청할 서비스명을 지정한다.
② char *sendbuf : Service에 보내어질 data buffer의 pointer
③ long sendlen : 서비스에 보내어질 버퍼의 길이(보통 0으로 고정)
④ char **rcvbuf : 서비스에서 응답되어진 버퍼를 위한 pointer
⑤ long *rcvlen : return된 데이타 버퍼 길이의 포인터
⑥ long flags : 서비스 요청시의 option(보통 0으로 지정)
- Return Type : int형
- 예)
tpcall("SVC_1",(char *)transf,0,(char **)&transf,&rcvlen,0);
● tpacall()
- 기능 : 비동기 방식으로 service를 호출한다, 서비스만 요청한후
결과가 필요한 경우 tpgetrply()이용하여 응답을 받는다.
- syntax
handle = tpacall(char *service,char *sendbuf,long length,long flags);
① handle : tpacall()의 값을 return받기위한 Descriptor
handle수 많다면 handle1,handle2,..를 위한 순차적처리.
② char *service : 요청할 서비스명
③ char *sendbuf : 서비스에 전송하는 데이타 버퍼의 포인터
④ long length : 서비스에 보내어지는 데이타 버퍼의 길이(0)
⑤ long flag : 서비스 요청시 사용하는 option(0)
- Return Type : int형
- 예) handle1 = tpacall("SVC_1",(char *)transf,0,0);
● tpgetrply()
- 기능 : tpacall로 요청한 서비스의 응답을 받기 위하여 사용
- syntax
tpgetrply(int *handle1, char **buf, long *length, long flags);
① handle1 : tpacall()시 받은 service에 대한 handle
② buf : 응답시 받을 Buffer의 포인터
③ length : 응답시 받을 Buffer의 길이
④ flag : tpgetrply()시 주는 option
주의 사항) 동시에 여러 서비스에 대해 tpacall을 사용했을 경우에는
tpgetrply의 flag 부분에 TPGETANY로 설정하여 사용한다.
● tpcancel()
- 기능 : tpacall함수의 응답출력을 취소
- syntax
tpcancel(int handle);
- return type : int 형
- 예) tpcancel(handle1);
● tpbegin()
- 기능 : Transfaction을 시작한다.
- Syntax
tpbegin(unsigned long timeout, long flags);
① timeout : Transfaction timeout(초)지정, 0지정시 무제한
주의사항) 반드시 timeout을 지정해 주어야 합니다. (권장시간 30초)
② flag : 반드시 0으로 setting
- Return Type : int형
- 예) tpbegin(30,0);
● tpcommit()
- 기능 : Transaction을 완료한다.
- Syntax
tpcommit (long flags);
① flags : 반드시 0으로 setting
- Return Type : int형
- 예) tpcommit(0);
미들웨어
· 미들웨어란?
①미들웨어는 클라이언트 프로그램과 서버 프로그램 사이에 존재하면서
클라이언트와 서버간에 연결을 유지/관리하면서, 클라이언트의 작업 처리
요구를 서버에 전달하는 일을 하는 소프트웨어이다.
②미들웨어에는 기본 기능만을 수행하는 더미 미들웨어(예를들면, 2계층
시스템에서 클라이언트와 서버간에 데이타 통로만 제공하는 소프트웨어와
같은 프로그램)와 더미 미들웨어가 가진 기능 이외에 해당 서비스를
찾아준다든가, 큐잉 기능 등의 고급 기능을 수행하는 미들웨어가 있다.
③미들웨어가 정상적으로 수행되기 위해서는 클라이언트측과 서버측
미들웨어가 별도로 존재한다.
④클라이언트와 서버간에 자료의 교환은 각각의 미들웨어를 반드시 통하며,
클라이언트와 서버를 개발하는 개발자는 미들웨어 인터페이스를 통하여
개발한다.
· 미들웨어의 기능
1)기본기능
①클라이언트와 서버간에 통신이 가능하도록 데이타 통로를 제공하는
기능.
②클라이언트와 서버간에 연결 세션을 유지/관리하는 기능.
③클라이언트의 작업 처리에 필요한 서비스를 찾아주는 기능.
2)확장기능
①여러 서버에 흩어진 프로그램에 클라이언트 요청을 라우팅하는 기능.
②서버 프로그램이 작어중이면 클라이언트 요청을 기다리게 하는 기능.
③서버 프로그램을 감시하는 기능.
④데이타베이스 트랜잭션을 관리하고, 데이타베이스와 공조하는 기능.
· 3계층 시스템 구현용 미들웨어
1)비 TP-Monitor 계열의 미들웨어
①Entera, Forte등과 같은 소프트웨어가 TP-Monitor 계열이 아닌
미들웨어이다.
②이들 프로그램을 이용하여 3계층 시스템의 구축이 가능하지만, 대규모
트랜잭션 처리를 요구하는 어플리케이션에는 적합하지가 않다.
2)TP-Monitor 계열의 미들웨어
①Tuxedo, Top-End, Encina, CICS등과 같은 소프트웨어가 TP-Monitor
계열의 미들웨어이다.
②이들 프로그램을 이용하여 3계층 시스템의 구축이 가능할 뿐만 아니라,
대규모 트랜잭션 처리가 가능한 미들웨어이다.
TUXEDO의 기원
턱시도 시스템은 발전된 전화교환 시스템을 위한 고성능 통신과 트랜잭션을
추적하는 중추로서 원래 AT&T사에 의해 개발되었다.
유닉스가 일반 컴퓨터 시장에서 침입하기 시작한 것처럼 시장의 반대 끝에서
유닉스를 후원하기 위해 턱시도를 상업용 OLTP로 제공하기로 결정했다.
턱시도 시스템은 비지니스맨에 의해 비즈니스용으로 설계되었고, 오픈 시스템
상에서 트랜잭션 처리를 위한 시장에서 가장 적당한 제품이다.
데이터베이스 회사는 곧 오픈 시스템 특히 유닉스쪽으로 옮겨 갔다.
인포믹스와 같은 회사는 유닉스 플랫폼상의 데이터베이스 엔진을 생산하게
되었고, 오라클과 같은 판매자는 그들의 기동력을 유닉스에 맞추었다.
TUXEDO 정의
·클라이언트/서버 환경에서의 온라인시스템(OLTP)을 원활하게 지원하여 주는
S/W
·다수의 사용자들이 자기가 요청한 작업들을 실시간내에 처리되어 응답받기를
원하는 시스템
·유닉스 중심의 분산환경에서 메인프레임상의 온라인 트랜잭션 관리 소프트
웨어인 CICS등과 같은 역할을 해주는 S/W
·Tuxedo는 클라이언트와 서버 양쪽에 탑재되어 RDBMS의 Access 및 전송을
지원하여 주는 중간다리 역할을 하는 S/W
TUXEDO의 기능(1)
1. 부하 분산
-특정 시스템으로만 부하가 편중 되는 것을 막아 시스템 전체 성능을
최적화 함.
2. 처리 시간 보장
-Peak-Time시나 대용량 트랜잭션 발생시 안정적이고, 빠른 처리능력을
보장함.
3. 데이타 의존형 라우팅
-서비스 이름과 입력된 데이터 값에 따라 해당 Machine의 DataBase를
액세스함.
4. 분산자원의 중앙관리
-C/S 환경에서 가장 어려운 부분인 자원 관리를 중앙에서 일괄적으로
관리함.
-GUI(Motif) Administration Tool 제공함.
5. 개발의 생산성
-Program 작성상의 용이성 및 확장성을 보장함.
6. 표준기술 지원
-지원 H/W Platform의 종류, 개방성 및 표준을 지원하여 향후 시스템 및
자원의 확장시 용이함.
7. 장애극복 및 복구
-장애 발생시 사용자가 계속해서 서비스를 받을 수 있게 하는 장애관리 및
복구 기능을 지원함.
8. 데이타 무결성
-분산된 DBMS, Network, System, OS등의 처리과정 중 전체에 대한 데이터
및 트랜잭션 무결성을 보장하여, 시스템 신뢰도 확보함.(2 Phase Commit)
TUXEDO의 기능(2)
· RPC (Remote Procedure Call) 기능
:다른 머신상에 있는 Procedure(프로그램)를 불러내는 기능으로,
프로그래머는 통신을 의식하지 않고 보통의 Sub_Routine을 불러내는 식으로
코딩이 가능함.
· Multi-Thread 기능
:유닉스 프로세스로 여러 Application을 실행할 수 있으며, TP_Monitor
내부의 오버헤드를 줄일 수 있으므로 트랜잭션 처리를 고속화할 수 있다.
· Directory 관리 기능.
:Directory 서비스는 프로그램등 시스템 자원의 소재지 관리 기능.
· Data 의존형 Routing 기능
:Request의 데이터 내용을 보고 수신처의 서버를 판단하는 기능.
· 여러서버 사이의 Load-Balancing
:분산처리 환경에서 여러 서버 사이의 Request를 배분하는 기능.
· 클라이언트 프로그램 관리
:서버나 클라이언트를 프로그램 추가할때에는 반드시 시스템 구성
(Configuration) File을 변경해야 한다.
이때, 시스템을 정지시키지 않고 온라인으로 변경할 수 있는 기능.
· 시스템 리포팅 기능
:장애 발생시 트랜잭션 로그나 에러 로그의 분석을 위해서 이들 로그를
편집해서 출력하는 기능.
TUXEDO 용어
·BBL Bulletin Board Liaison process
Shared Memory를 관리 해 주는 프로세스
·DBBL Distinguished Bulletin Board Liaison process
네트워크 환경에서 Master Site에 떠서 BBL을 관리하는 프로세스
·ATMI Application Transaction Manager Process
클라이언트와 서버를 지원하기 위한 /T에서 제공하는 함수들
·RM Resource Manager
데이터베이스, 프린터 서버 등의 자원을 관리하는 부분
·System /T 턱시도 시스템 OLTP Component
턱시도 시스템의 핵심 요소이며, 트랜잭션을 관리해 줌
·TM Transaction Manager 트랜잭션 관리자 (시스템 /T)
·XA X/Open defined TM ↔ RM Interface
X/Open에서 정의한 표준화 된 인터페이스로 이기종 데이터베이스를
투과적으로 다룰 수 있으며, 2단계 갱신 (2 Parse Commit)으로
무결성이 보장 됨
·TMS Transaction Manager Server
이기종 데이터베이스를 지원하는 XA interface를 사용 할 경우 필요함
·FML Field Manipulation Language
Field Buffer라는 데이터 구조를 정의하고 처리할 수 있는 C 언어
함수이며 named field를 사용하여 클라이언트와 서버 사이의
커뮤니케이션을 제공
·MSSQ Multiple Server, Single Queue
같은 서비스를 제공하는 다수의 서버에 한 개의 큐를 공유하도록 하여
특정한 서버 만 작업량이 많아지는 것을 방지함
named field를 사용하여 클라이언트와 서버 사이의 커뮤니케이션을
제공
·WSC Workstation Client (서비스를 요청한 클라이언트)
·WSL Workstation Listener
서비스 요청을 받아 WSH로 연결시켜 주는 데몬 프로세스
·WSH Workstation Header
서비스 요청한 buffer data를 서버로 연결시키고 정보를 주고받음
TUXEDO Security
※TUXEDO SYSTEM은 전체 4단계의 Security를 제공한다.
1단계 : 시스템제공의 UID , GID 와 Password
2단계 : Application 접근에 대한 authentication
3단계 : user의 authorization level에 대한 security
4단계 : 1992년 이후 제공되는 Kerberos machanism security
TUXEDO Magration
1. Migration DBBL
master machine에 장애가 발생하였을 경우 tmboot, tmshutdown등의 관리
명령어를 사용할 수 없으므로 DBBL을 backup master로 이동하여 이를 수행
할 수 있도록 한다.
1) 처리순서
$ tmadmin
> m
2) 세부사항
① RESOURCES의 MASTER에 backup machine이 선언되어 있어야 한다.
② OPTIONS에 MIGRATE를 선언
③ 위의 명령은 backup machine에서 실행시킨다.
2. Migration Servers
특정 Group내에 있는 Server들을 migrate
1) 처리 순서
$ tmadmin
> stop -R -g groupname
> migg groupname
2) 세부사항
① migrate될 server들을 shutdown시킬 때는 반드시 "-R" option을
사용한다.
② migrate될 server들은 LMID변수에 옮겨갈 machine을 미리 선언해
놓는다.
③ group내의 server들은 RESTART=Y로 설정되어 있어야 한다.
3. Migrating Machines
LMID를 이용하여 그 machine내의 server들을 migrate시킨다.
1) 처리 순서
$ tmadmin
> stop -R -l lmid
> migm machine
2) 세부사항
① 이 역시 마찬가지로 shutdown시에 "-R" option을 사용
② migm은 argument로 하나의 LMID를 갖는데 이 LMID는 migrate하려는
server들이 수행되던 machine의 이름이다.
③ 이 LMID를 갖는 machine내의 모든 server는 RESTART=Y로 선언되어
있어야 한다.
< 참고>
- "stop -R" 명령을 수행시킨 후에 migration을 취소할 수도 있는데,
이는 "-cancel" option을 사용하면 된다.
> migg -cancel groupname
> migm -cancel lmid
- "-cancel" option을 "-R" option없이 shutdown한 것과 똑같은 효과를 지닌다.
TUXEDO Concurrent User
1. Tuxedo의 Concurrent User 개념은 Tuxedo Client에서 Server 상의 Service를
호출하여 Service Program이 기동(Tpinit)에서부터 완료(Tpreturn)까지의
기간동안 Server상에서 수행되는 동시 Service Program의 수치를 말함.
2. 일반적으로 H/W의 초당처리속도(TPC)는 Tuxedo의 Concurrent User수에 비해
훨씬 높은 처리속도를 가지며, 순수하게 TP 환경에서 H/W의 최대
Performance를 내기 위해서는 Tuxedo의 Concurrent User수를 H/W의 TPC
수치와 동일하게 설정 해야만 한다.
3. Tuxedo 6.2 Version 이후 부터는 각각의 Server별로 Concurrent User수를
보유하고 있어야만 서버별로 동일한 성능을 기대할 수 있게 된다.
4. 개발용 모듈(SDK)와 RunTime 모듈(RDK)는 동일한 서버상에 동시에 Porting이
가능.
5. 어떤 금융업무의 Concurrent User 산정
① 시스템이 월간 1,800 만건의 Transaction이 발생한다고 가정.
② 월간 1,800만건을 25일 근무/8시간 운영으로 가정하고 초당 평균
Transaction 발생 수치를 계산했을 때 약 40 Transaction이 산정됨
③ 초당 40 Transaction은 Tuxedo 상에서 1초에 40 service Program이 기동 및
수행완료가 되어야 하는 경우임.
④ Tuxedo 상에서 Service Program이 2초내에 처리가 완료되도록 Target Time을
설정한다면 각각의 Transaction이 Waiting Time 없이 바로 처리 되기
위해서는 Tuxedo Concurrent User수는 80이 되어야 함.
(Transaction당 Target Time이 3초이면 Tuxedo Concurrent User수는 120이
되어야 함)
⑤ Network Server 2대로 운영하며 한 서버를 StandBy 상태로 가져갈 때는
Tuxedo User수를 다른 서버의 100% 수준으로 가지 않을수도 있음.
TP-Monitor정의
① 클라이언트/서버 환경에서의 온라인 시스템(OLTP)을 원활하게 지원하여 주는
Software.
※온라인 시스템(OLTP)
한 시스템에 접속된 다수의 사용자들은 일정한 작업에 대한 요청들을
동시에 요구하고 각 사용자들은 자기가 요청한 작업들을 실시간내에
처리되어 응답받기를 원하는 시스템.
② 유닉스 중심의 분산환경에서 Mainframe상의 온라인 트랜잭션 관리 S/W인
CICS등과 같은 역할을 하여 주는 Software.
③ TP-Monitor는 클라이언트와 서버 양쪽에 탑재되어 RDBMS의 Access 및 전송을
지원하여 주는 중간다리 역할을 하여 줌.
TP-Monitor장점
①처리 시간 보장 : Peak-Time시나 대용량 트랜잭션 발생시 안정적이고, 빠른
처리능력을 보장함.
②개발의 생산성 : Program 작성상의 용이성 및 확장성을 보장함.
③장애극복및 복구 : 장애 발생시 사용자가 계속해서 서비스를 받을 수 있게
하는 장애관리 및 복구 기능을 지원함.
④데이타 무결성 : 분산된 DBMS, Network, System등의 처리과정 중 전체에 대한
데이터 및 트랜잭션 무결성을 보장하여, 시스템 신뢰도
확보함. (2 Phase Commit)
⑤부하 분산 : 특정 시스템으로만 부하가 편중 되는 것을 막아 시스템 전체
성능을 최적화 함.
⑥자원의 중앙관리 : C/S 환경에서 가장 어려운 부분인 자원 관리를 중앙에서
일괄적으로 관리함.
⑦표준기술 지원 : 개방성 및 표준을 지원하여 향후 시스템 및 자원의 확장시
용이함.
TP-Monitor기능
①RPC(Remote Procedure Call) 기능
-다른 머신상에 있는 Procedure(프로그램)를 불러내는 기능으로
프로그래머는 통신을 의식하지 않고 보통의 Sub_Routine을 불러내는 식으로
코딩이 가능함
-RPC는 2단계 갱신(2 Phase-Commit)에도 대응하고 있어 분산환경에서의
데이터나 트랜잭션의 무결성을 보장한다. 즉 트랜잭션 처리중에 어떤 장애가
발생하면 DB에 대한 갱신을 모두 Rollback 할 수 있다
-현재 X/Open은 RPC에 대해 세가지 사양의 표준화를 추진하고 있으며 TUXEDO
기반의 XATMI와 TxRPC, 그리고 동배간 통신의 표준이다
②Multi-Thread 기능
-유닉스 프로세스로 여러 Application을 실행할 수 있으며, TP_Monitor
내부의 오버헤드를 줄일 수 있으므로 트랜잭션 처리를 고속화할 수 있다
③Directory 관리 기능
-Directory 서비스는 프로그램등 시스템 자원의 소재지 관리 기능
-클라이언트가 RPC로 서버 프로그램을 불러낼 때 네트웍 어드레스를 의식하지
않고 프로그램명(서비스명)만 지정하면 되는 방식이다.
④Data 의존형 Routing 기능
-Request의 데이터 내용을 보고 수신처의 서버를 판단하는 기능
-예를 들면 동일한 특성의 데이타를 여러 서버로 분산한 경우 고객의
우편번호를 보고 처리할 서버로 배분할 수 있는 기능이다
⑤여러 서버 사이의 Load Balancing
-분산처리 환경에서 여러 서버 사이의 Request를 배분하는 기능
-균등하게 배분하는 라운드로빙방식, 서버의 처리능력에 따라 일정비율로
배분하는 방식, 서버의 부하상황을 보고 동적으로 배분하는 방식등이 있다.
⑥클라이언트 프로그램 관리
-서버나 클라이언트를 추가할때에는 반드시 시스템 구성(Configuration)
File을 변경해야 한다
이때 시스템을 정지시키지 않고 온라인으로 변경할 수 있는 기능
-분산처리 환경에서는 클라이언트측 Application Program의 Version 관리
기능이 중요하다
즉, 새로운 버젼의 프로그램을 미리 클라이언트에 전송해 두고 어떤
시점에서 일제히 변경할 수 있는 기능
⑦시스템 리포트 기능
-장애 발생시 트랜잭션 로그나 에러 로그의 분석을 위해서 이들 로그를
편집해서 출력하는 기능
TP_Monitor의 구성
TP_Monitor 각 제품들은 UNIX용 Application 환경 표준화 단체인 X/Open이 정한 DTP
(분산 트랜잭션 처리) 모델에 준거하고 있으며, 여기에는 OLTP 시스템에 필요한
구성요소를 정의하고 각 구성요소간의 인터페이스를 규정하고 있다
▶Transaction Manager : 트랜잭션라우팅, 전역 트랜잭션 관리, 오류회복등의 관리기능
▶Resource Manager : DBMS 또는 프린터서버등과 같은 공유자원 관리기능
▶Communication Resource Manager : 클라이언트/서버사이 및 서버간의 통신전반을
제어하는 기능
▶XA : XA를 채택한 TP_Monitor는 XA에 대응한 모든 RDBMS와 자유롭게 연결 가능함
▶RPC(Remote Procedure Call) : 다른 머신상에 있는 Procedure를 불러내는 기능
(TxRPC, XATMI,동배간통신등의 3종류의 표준이 있음)
TUXEDO 시스템의 통합 방안
턱시도는 여러 시스템 중에서 master node를 선정하여 전체 시스템을 관리한다.
턱시도의 시스템 관리기능(tmadmin)은 각 시스템의 상태 즉 데몬 process 및
AP server process의 이상 유무를 감시할 수 있다.
또한 네트워크의 partition 여부도 감시가 된다.
턱시도는 master node의 down을 대비하여 backup master를 두고 운용한다.
서버가 많을 경우는 System/Domain을 이용하여 시스템을 효율적으로 운용할
수도 있다. 턱시도는 Client의 요청 횟수 등의 감시도 가능하다.
TUXEDO 시스템의 안정화 방안
· BB(Bulletin Board) : Tuxedo 의 제반정보가 등록되는 공유메모리 구조체.
· BBL(Bulletin Board Liaison) : BB 를 관리해주는 Process.
· DBBL(Distributed Bluetin Board Liaison) : BBL 들의 상태를 감시하는
Process.
· Bridge Process : 다른 System 과 정보 및 메세지를 교환하는 Process.
· AP Server : 어플리케이션 서버
턱시도는 위에 언급된 시스템 데몬 Process 나 AP Server Process 들이
이상이 생겼을 때, 자동으로 Restart 시켜줌으로써 시스템의 안정성 및
가용성을 높여준다.
TUXEDO 시스템의 백업 방안
. 턱시도는 System /Q 모듈을 사용하여 일괄처리 뿐만아니라 On-Line처리가
가능하다.
그 기능으로는 일정시간이나 조건을 만족시키면 자동적으로 주어진 업무를
실행시킬 수가 있다.
Oracle로 구축된 데이타베이스를 일정시간마다 혹은 지정된 시간에 또는
어떤 조건을 만족시키면 자동적으로 mirrored database로 복사시킬 수 있다.
TUXEDO 시스템의 확장 방안
·턱시도는 기본적으로 On-line 트랜잭션을 처리하므로 시스템을 down 시킬 수
없다.
따라서 턱시도는 새로운 machine 을 추가하여 기존 시스템과 통합시킬 때도
down 없이 동적으로 재구성이 가능한 확장성을 갖고 있다.
새로운 machine 뿐만 아니라 application server 나 group, 서비스 등을
추가 할 때도 동적으로 재구성이 가능하다.
새로 추가되는 시스템이 이기종 시스템, 이기종 데이타베이스 등과 무관하게
통합이 가능한 우수한 기능을 갖고 있다.
TUXEDO 활용효과
· 처리시간 보장
:Peak-Time시나 대용량 트랜잭션 발생시 안정적이고, 빠른 처리능력을
보장함
· 개발의 생산성
:Program 작성상의 용이성 및 확장성을 보장함
· 장애극복 및 복구
:장애 발생시 사용자가 계속해서 서비스를 받을 수 있게 하는 장애관리 및
복구 기능을 지원함
· 데이터 무결성
:분산된 DBMS, Network, System등의 처리과정 중 전체에 대한 데이터 및
트랜잭션 무결성을 보장하여, 시스템 신뢰도 확보함. (2 Phase Commit)
· 부하분산
:특정 시스템으로만 부하가 편중 되는 것을 막아 시스템 전체 성능을 최적화
함
· 이기종 데이터베이스의 활용
:단일 Application에서 이기종 데이터베이스를 연결시키는 능력이 용이함
(Resource Manager)
· 표준기술지원
:개방성 및 표준을 지원하여 향후 시스템 및 자원의 확장시 용이함
FML함수
● Finit()
- 기능 : buffer을 초기화하기 위하여 사용한다.
- Syntax
Finit(FBFR *transf , int len);
① FBFR *transf : buffer의 포인터명
② int len : buffer의 길이
● Fchg()
- 기능 : 프로그램 변수의 값을 지정된 Buffer의 Field에 Move
- Tuxedo Buffer -> 프로그램 buffer
- Syntax
Fchg(FBFR *transf,FLEID fieldid,FLDOCC occ,char *buf,FLDLEN len);
① FBFR *transf : buffer의 포인터명
② FLDID fieldid : FML Buffer Header에 정의된 Field명
③ FLDOCC occ : field의 occurrence number 0부터시작
multi row data를 사용하는 경우 지정
④ char *buf : FML buffer에 move할 데이타 변수
buf의 pointer를 move해야 한다.
⑤ FLDLEN len : carray buffer를 사용하는 경우 buf 의 크기
carray buffer외에 사용하는 경우 0을 지정
- Return Type : int형
- 예)
strcpy(H_juminid,"780209-2574411");
Fchg(transf,JUMIN_ID,0,H_juminid,0);
● Fget()
- 기능 : 지정된 field의 내용을 프로그램 변수의 buffer에 move한다.
- 프로그램 buffer -> Tuxedo Buffer
- Syntax
Fget(FBFR *fbfr,FLEID,fieldid,FLDOCC oc,char *buf,FLDLEN *len);
① FBFR *transf : buffer의 포인터명
② Fldid fieldid : fml header table에 정의 field명
③ FLDOCC oc : field의 occurrence number 0부터시작
multi row data를 사용하는 경우 지정
④ char *buf : fieldid의 buffer를 프로그램 buffer에 move하기
위한 char pointer 변수
⑤ FLDLEN *len : 프로그램 buffer에 저장할 수 있는 최대크기
- Return Type : int형
- 예) Fget(transf,JUMIN_ID,0,H_juminid,&len);
● Foccur()
- 기능 : 지정된 field occurrence 조사
즉 지정한 field가 multi row이면 지정한 field의 갯수를 return
- Syntax
FLDOCC FLDcnt;
FLDcnt = Foccur(FBFR *fbfr, FLDID fieldid);
① FLDcnt : occurrence의 결과를 얻기위한 변수
② FBFR *fbfr : fml buffer의 data buffer의 포인터
③ FLDID fldided : fml buffer에 정의된 Field명
- Return Type : FLDOCC형
- 예) FLDcnt = Foccur(fbfr,JUMIN_ID);
● Fldid()
- 기능 : Field name에 대한 id값을 return.
- Syntax
FLDID fldvar
Fldvar = Fldid(char *name);
① FLDID fldvar : fml buffer에서 지정한 field의 id 얻기위한 변수.
② char *name : Field table에 정의된 field명
- Return Type : FIELDID 형
- 예) fldvar = FIELD("jumin_id");
● Fconcat()
- 기능 : Field buffer를 다른 field buffer에 추가.
- Syntax
Fconcat(FBFR *dest, FBFR *src);
① *dest, *src : src의 내용을 dest에 추가
dest의 크기가 src를 포함할 만큼 충분하지 않으면
error 발생
- Return type : int형
● Fvals()/Fvall()
- 기능 : Fget()과 동일한 기능(Error가 발생한 경우 return값이 없다)
- Syntax
Fvals(FBFR *fbfr,field,oc);
FvalL(FBFR *fbfr,field,oc);
① Fvals는 문자열에 대한 pointer field에 대한 buffer내용을 얻는다.
② Fvll는 숫자형에 대한 pointer field에 대한 buffer내용을 얻는다.
- Return type : Fvals : char형 pointer , Fvall : long 형
예) variable = Fvals(transf,JUMIN_ID,0);
pay = Fvall(transf,PAY_ID,0);
ATMI함수
● tpinit()
- 기능 : Client와 Tuxedo System/T Application과의 접속
- syntax
tpinit(TPINIT *tpinfo)
① TPINIT *tpinfo : TPINIT구조체형 포인터 변수 지정
Tuxedo에 접속한 Client의 정보를 등록한다.
TPINIT 구조체
struct tpinfo_t {
char usrname[MAXTIDENT+2]; /* client user name */
char cltname[MAXTIDENT+2]; /* application client name */
char passwd[MAXTIDENT+2]; /* application password */
char grpname[MAXTIDENT+2]; /* client group name */
long flags; /* initialization flags */
long datalen; /* length of app specific data */
long data; /* placeholder for app data */
};
typedef struct tpinfo_t TPINIT;
- Return Type : int 형
● tpterm()
- 기능 : Tuxedo System/T Application종료
Tuxedo에 접속한 Clinet의 정보 삭제
- Syntax : tpterm();
- Return Type : int 형
● tpalloc()
- 기능 : Data를 저장할 Buffer의 할당 및 초기화
- syntax
FBFR *transf;
pfbr = (FBFR *)tpalloc(char *type, char *subtype, long size)
① FBFR *transf : Client에서 전송된 부분중에서 data부분을 저장
하기 위한 pointer, 다수의 부분을 할당하는 경우
transf1, transf2,... 순차적으로 지정
② char *type : 할당받을 buffer의 type지정(FML buffer로 고정)
③ char *subtype : FML buffer사용시 NULL로 지정
④ longsize : 할당받을 Buffer의 크기지정
- Return Type : Character형 포인터
- 예) FBFR *transf;
transf = (FBFR *)tpalloc("FML",NULL,(long)(5*1024));
주의사항) 반드시 tpalloc은 tpfree를 꼭 해 주어서 할당된
Buffer를 풀어 주어야 한다.
● tprealloc()
- 기능 : tpalloc에의해서 할당된 메모리가 적을 경우 Buffer size를
크게 하기 위하여 사용.
- syntax
transf = (FBFR *)tprealloc((char *)transf,long size);
① FBFR * : realloc에 의해서 return받은 메모리를 FBFR *로 형변환
② (char *)transf : size를 크게 조정하는 buffer를 char포인터로 형변환
③ long size : buffer의 크기를 지정한다.
- tprealloc은 tpalloc과 달리 tpfree가 필요 없다.
- Return Type : Character형 포인터
- 예) transf = (FBFR *)tprealloc((char *)transf,(long)(7*1024));
● tpfree()
- 기능 : 사용이 완료된 Buffer해제
- syntax
tpfree((char *)transf);
① (char *)transf : 사용 완료된 버퍼의 Type을 Character형 포인터로
변환한후 메모리를 해제한다.
- 예) tpfree((char *)transf);
● tpcall()
- 기능 : 동기 방식으로 Service를 요구하고 응답이 올때까지 기다린다.
- syntax
tpcall(char *service, char *sendbuf, long sendlen,
char **rcvbuf, long *rcvlen,long flags);
① char *service : 요청할 서비스명을 지정한다.
② char *sendbuf : Service에 보내어질 data buffer의 pointer
③ long sendlen : 서비스에 보내어질 버퍼의 길이(보통 0으로 고정)
④ char **rcvbuf : 서비스에서 응답되어진 버퍼를 위한 pointer
⑤ long *rcvlen : return된 데이타 버퍼 길이의 포인터
⑥ long flags : 서비스 요청시의 option(보통 0으로 지정)
- Return Type : int형
- 예)
tpcall("SVC_1",(char *)transf,0,(char **)&transf,&rcvlen,0);
● tpacall()
- 기능 : 비동기 방식으로 service를 호출한다, 서비스만 요청한후
결과가 필요한 경우 tpgetrply()이용하여 응답을 받는다.
- syntax
handle = tpacall(char *service,char *sendbuf,long length,long flags);
① handle : tpacall()의 값을 return받기위한 Descriptor
handle수 많다면 handle1,handle2,..를 위한 순차적처리.
② char *service : 요청할 서비스명
③ char *sendbuf : 서비스에 전송하는 데이타 버퍼의 포인터
④ long length : 서비스에 보내어지는 데이타 버퍼의 길이(0)
⑤ long flag : 서비스 요청시 사용하는 option(0)
- Return Type : int형
- 예) handle1 = tpacall("SVC_1",(char *)transf,0,0);
● tpgetrply()
- 기능 : tpacall로 요청한 서비스의 응답을 받기 위하여 사용
- syntax
tpgetrply(int *handle1, char **buf, long *length, long flags);
① handle1 : tpacall()시 받은 service에 대한 handle
② buf : 응답시 받을 Buffer의 포인터
③ length : 응답시 받을 Buffer의 길이
④ flag : tpgetrply()시 주는 option
주의 사항) 동시에 여러 서비스에 대해 tpacall을 사용했을 경우에는
tpgetrply의 flag 부분에 TPGETANY로 설정하여 사용한다.
● tpcancel()
- 기능 : tpacall함수의 응답출력을 취소
- syntax
tpcancel(int handle);
- return type : int 형
- 예) tpcancel(handle1);
● tpbegin()
- 기능 : Transfaction을 시작한다.
- Syntax
tpbegin(unsigned long timeout, long flags);
① timeout : Transfaction timeout(초)지정, 0지정시 무제한
주의사항) 반드시 timeout을 지정해 주어야 합니다. (권장시간 30초)
② flag : 반드시 0으로 setting
- Return Type : int형
- 예) tpbegin(30,0);
● tpcommit()
- 기능 : Transaction을 완료한다.
- Syntax
tpcommit (long flags);
① flags : 반드시 0으로 setting
- Return Type : int형
- 예) tpcommit(0);
반응형
'아이티 > 리눅스&유닉스' 카테고리의 다른 글
| [리눅스]디렉토리 목록만 보자 (0) | 2012.07.30 |
|---|---|
| FTP에서 아스키와 바이너리의 차이점.. (0) | 2010.01.13 |
| 레드햇 패키징 하우투 RPM HOWTO (0) | 2009.09.30 |
| aptitude 명령의 사용법 (0) | 2009.05.12 |
