Tuxedo Buffer Type 비교

'버퍼 타입' 결정 필요 발생

l  필드 명 별로 'FML' 헤더 파일 작성 할 경우 생성 되는 ‘FML’ 정의 파일의 엔트리가 너무 많을 경우  필드 정보 로드 시 오버 헤드 발생 한다.

l  필드의 데이타 타입 별로 일정 부분을 할당 해서 'FML' 헤더 파일을 구성 할 경우 클라이언트에서 데이타 타입 확인이 어렵고 클라이언트 프로그램 작성시 필드 명 별 코멘트 작성이 필요하다.

'버퍼 타입' 개념 정리

STRING 타입

C 언어에서 사용 하는 스트링 타입과 사용 방법이 동일 하고 'EOS'로 자료의 끝을 인식한다. 따라서 'EOS'에 의해 자료의 크기가 결정된다.

CARRAY 타입

자료의 중간에 바이너리 데이타를 포함 할 수 있고 함수 호출 시 자료의 길이를 기술 한다.

FML 타입

자료의 타입을 파일에 기술하고 TUXEDO DES (Data Entry System)을 사용한다. 자료의 데이터 타입에 독립적으로 가장 높은 유연성을 제공하고 턱시도 시스템이 제공하는 FML 관련 여러 라이브러리 함수를 사용 항 수 있다.

VIEW 타입

C 언어의 스트럭처 사용법과 동일 하고 스트럭처 이름을 subtype에 기술한다.

‘버퍼 타입’의 장단점 비교

STRING 타입

l  C언어의 스트링 자료형에 익숙한 사람은 사용하기 간편하다.

l  클라이언트 개발 도구인 Power-Builder, Visual-Basic, 혹은 Delphi에서 제공하는 스트링 타입과 사용 방법이 동일하다.

l  한 개의 자료 전송에는 편하지만, 두개 이상의 자료를 전송하기 어렵다. (즉, 주민번호 한 개의 자료는 어렵지 않게 전달하지만, 주민번호와 이름을 전달하려면 별도의 가공 과정이 필요하다.)

l  정수형이나 실수형 혹은 구조체와 같은 스트링형이 아닌 다른 자료 타입을 표현하기 어렵다.

CARRAY 타입

l  문자열뿐만 아니라 정수형, 실수형, 그리고 구조체형도 CARRAY형을 이용하여 클라이언트와 서버간에 통신이 가능하다.

l  C 프로그래밍 언어에 익숙하거나 통신 프로그래밍에 익숙한 사람은 프로그래밍을 진행하기 쉽다.

l  거의 모든 자료를 표현할 수 있으며, 최대의 메모리 효율을 높일 수 있다.

l  C 프로그래밍 언어나 메모리 구조에 익숙하지 않은 사람은 프로그래밍을 진행하기 어렵다. 그러므로, CARRAY를 사용하기 위해서는 라이브러리 함수들이 적절하게 제공되어야 한다.

l  성능은 좋지만 입력 되는 데이터로 TUXEDO에서 지원 하는 라우팅 기능(Data dependent routing)을 사용 할 수 없다.

l  클라이언트와 서버간의 통신하는 자료의 모습이 변경되면, 프로그램의 많은 부분을 변경해야 하는 어려움이 따른다.

l  클라이언트 프로그래밍 시에 CARRAY형을 변경 없이 적용하기 어렵다.

FML 타입

l  Data Dependent Routing 기능과  FML전용 함수 등 관리 기능을 사용할 수 있다.

l  FML을 사용하기 위한 환경과 관련 함수를 익혀야 한다.

l  클라이언트와 서버간의 통신하는 자료의 모습이 변경되어도 프로그램의 변경 요소가 적다.

l  TAG나 크기에 관한 정보를 표현하기 위한 메모리와 통신에 어느 정도의Overhead 발생한다.

 

VIEW

l  C프로그래밍 언어의 'struct' 구조체를 그대로 옮겨 놓았으므로, 구조체 사용에 익숙한 사람이 사용하기 편리하다.

l  턱시도의 Data Dependent Routing을 사용할 수 있다.

l  클라이언트와 서버간에 전송되는 자료형의 모양이 미리 정해져 있으므로, 자료형을 모두 채우는 경우에는 메모리의 사용이 매우 효율적이지만, 모두 채우지 못하는 경우에는 메모리가 매우 비효율적으로 낭비된다.

l  View를 사용하기 이전에 사용하기 위한 환경 변수와 준비를 해야 한다.

l  클라이언트 프로그래밍 시 View형을 변경 없이 적용하기 어렵다.

l  턱시도 시스템 개발 시 많이 적용되지 않으므로 관련 솔루션을 찾기 어렵다.

버퍼타입 결정 안 (FML 타입 사용)

사전 검토 사항

l  프로그래머 별로 FML 필드 타입을 관리할 경우 필드 개수가 많아 진다.

l  각 Column 마다 다른 필드 값을 부여할 경우 필드의 개수가 많아 진다.

l  각 Column 에 대한 유연한 통합관리 필요 하다.

l  시스템 인티그레이션 시 발생 될 수 있는 문제점을 검토한다.

l  FML 필드 엔트리의 유연한 통합관리가 안 될 경우 추가 개발 시 필드 값이 부족해지는 문제가 발생 할 수 있다.

l  FML 필드 값의 개수가 5,000 개를 초과할 경우 필드 정보를 로드하는데 시간이 많이 걸린다.

l  FML 필드 값의 사용 가능 범위 (16 비트 FML 을 이용 시 : 101 ~ 8,192, 32 비트 FML 을 이용 시 : 101 ~ 1,600 만)

버퍼 타입 제안 내용

l  모든 '업무 구분' 에서 공통적으로 사용하는 공통 FML 필드 값을 지정한다. (보안용 필드값, 데이터 송수신용, ..)

l  각 업무 구분 에서 FML 필드 값을 공통으로 사용한다.

l  추가 개발에 필요한 필드 값의 확보한다.

l  한번의 통신에 최대 100 개의 필드 값이 초과되지 않는 것으로 가정한다.

통신에 사용되는 필드의 자료형은 'STRING' 및 'LONG', 'DOUBLE' 타입으로 고정한다.