FTL(Faster Then Light) 정의
-낮은 대기 시간의 Message 처리 및 Cloud 환경을 제공하는 고성능 통신 Middleware
-여러 하드웨어와 소프트웨어 플랫폼을 지원함으로써 여러 환경에서 구동이 가능 ( ex) SB, BW )
-Realm Server를 기반으로 송수신 측의 정보를 관리하여 사용함에 있어 편리성을 제공

FTL 구성요소
Realm Server
①송수신 측의 정보 관리 및 통신에 필요한 사항 설정

②Message의 송수신이 이루어지는 Application을 편집하기 위한 인터페이스 제공

③Store를 통한 Message Monitoring

Data Store
①송신 측의 Message를 보관

②저장 된 Message를 연결 된 수신 측에 전송 ( DQ, FT )



Application
①Endpoint : Application의 송수신 측을 Group으로 묶어 개념화

②Transport : Transport를 통신매체로 하여 다양한 형태의 Message 송수신을 지원

③Format : Realm Server에 미리 정의된 Message의 형태

④Store : 송신 측이 전송한 Message를 저장하는 저장소

FTL - 통신 모델
Point-to-Point Message (1:1)



FTL의 Message는 Field의 집합으로 구성
FTL은 Publisher(송신자)와 Subscriber(수신자)로 역할을 구분하여 Message 통신
Publisher는 같은 Application의 Subscriber에 Message를 송신
Subscriber는 같은 Application의 publisher가 송신한 Message를 수신


One-to-Many (1:N)



FTL은 기본적으로 1:N형태의 Message 전송을 지원
Publisher는 같은 Application의 모든 Subscriber에 Message를 송신
모든 Subscriber는 같은 Application의 publisher가 송신한 Message를 수신


Transport



FTL은 Transport를 통신매체로 하여 다양한 형태의 Message 송수신을 지원
Transport의 Parameter
①Group : Transport를 용도에 맞도록 구분 (Default : null)

②Type : Message의 전송 방식을 결정 (Dynamic TCP, Static TCP 등)

③Address : 연결을 설정하기 위한 Host 이름 (Type에 따라 입력 할 필요 없음)

④Port : 연결을 설정하기 위한 Host 포트 (Type에 따라 입력 할 필요 없음)

⑤Mode : Mesh, listen, connect 중 선택할 수 있음 (Type에 따라 용도가 다름, 필요 없음)

각기 다른 Transport는 서로 간에 간섭하지 않음
Pub1에서 전송한 Message는 Sub1, Sub2만 수신
Transport Type




Transport Type 설정으로 다양한 전송방식 지원(Direct Shared Memory, Dynamic TCP, Multicast, RDMA...)
Multicast Transport T2를 추가하는 것으로 좀 더 복잡한 송수신 환경 구성
RV의 Transport와 비교했을 때 통신에 대한 설정이라는 점에서는 유사
Transport Type에 대한 정보는 아래 표 참조
Transport Types
    

Endpoint
                    

송신 측이 동일한 Message를 여러 개의 수신 측에 전송할 때 동일한 전송 설정에 대한 추상화 (ex : rv- Subject)
Server 관리자가 Endpoint의 세부 정보를 입력한다면 Programmer는 Endpoint 정보로 통신이 가능
소켓/플러그 개념과 유사
Content Matchers
    

FTL Message는 명시적인 대상 정보를 전송하지 않음 (RV : subject, JMS : topic, Queue)
Content Matcher는 특정 Field와 Value를 지정하여 Content Matcher를 포함하고 있는 Message를 수신
One-to-One Communication


Inbox를 사용하여 송수신 측의 1:1 Direct 통신
전체 수신 측 중 특정 수신 측 만을 사용한다는 점에서 Transport와 유사
Request-Reply


Inbox를 사용하여 송수신 측의 Request-Reply 구현
Rqst가 Serv에 Request Message를 전송 ( publish(1:N) )
Serv는 수신 후 Reply Message를 Rqst에 전송 (One-to-One(Inbox) )
FTL - 메시지 전송 보장 방식
Store


Store는 송수신 측의 중개자 역할로 Message의 저장을 담당
기본적으로 송신 측에서 전송 한 Message는 Server를 거치지 않고 Direct 전송되며 복구가 불가능
Store는 송신 측에서 보낸 Message를 수신 측과 같이 수신하며 수신 측이 정상적으로 Message를 정상적으로 수신하지 못했을 경우 추후 재전송
Durable을 Store에서 어떤 수신 측이 접근하여 수신 대기 상태인지를 명시
Store - standard


Standard는 Store가 Message Backup의 역할을 하는 옵션
송신 측에서 전송한 Message는 Store와 모든 수신 측에 전송됨
Store는 수신 측이 정상적으로 수신하지 못했을 시 저장된 Message 전송
Store - shared


Shared는 송신 측에서 전송 한 Message는 Store에서 보관하고 수신 측에 분배하는 옵션
송신 측에서 전송한 Message는 수신 측으로 가지 않고 모두 Store에 보관
Store에 보관된 Message는 순서 상관없이 수신 측에 전송되어 처리됨
Store - last-value


Last-value는 송신 측에서 전송 한 Message를 Store에서 지속적으로 보관하는 옵션
송신 측에서 key-value 형태의 Message를 전송하고 Store에서 보관
Store에 보관된 Message는 수신 측이 요청 할 경우 key 값에 해당하는 Message 송신
Store에서 송신된 Message는 사라지지 않고 Store가 종료 될 때 까지 유지
Formats
self-describing message는 metadata를 포함
metadata를 포함한 데이터 전송은 효율이 떨어짐
유사한 메시지 그룹에서 필요한 메타데이터를 추출하여 메시지 value만 전송, 전송효율 증가


송신 측에서 전송하는 Message는 Field의 집합이며 Field는 Field Name, Field Type, Value로 구성
Server에서 송신 측에서 전송하는 Message의 Meta 정보(Field Name, Field Type)를 포함
Format으로 미리 정의하고 사용하는 것으로 metadata를 제외한 value로 이루어진 Message 전송하는 것으로 효율을 증대
FTL - 메시지 처리 방식
Single Process(Default Communication)


Distributed Process(Load-Balancing)


Fault Tolerance (FT : Failover)


'Tibco > FTL' 카테고리의 다른 글

TIBCO FTL  (0) 2021.08.30
FTL 목차  (0) 2021.08.30

+ Recent posts