채권 매매 시스템

채권 거래 시스템.
채권 거래 시스템의 작동 방식.
전자 거래 입문서.
전자 거래는 기본적으로 채권 거래에 대한 정보를 공유하는 기술 시스템 모음입니다. 이를 뒷받침 할 기술 시스템을 설계하려면이 정보를 이해해야합니다.
이 정보는 7 가지 기능 영역으로 나눌 수 있습니다. 각 도메인은 전자 거래와 관련된 특정 유형의 기능 및 정보에 중점을 둡니다. 모든 도메인의 정보는 전자 거래에 필요합니다. 아래 다이어그램은 전자 거래 정보의 7 개 도메인을 보여줍니다.
이러한 정보의 논리적 분리는 정보 기술의 기능적 책임 경계를 정의하고 조직이 정보 기술 관리를 어떻게 조정할 수 있는지에 대한 지침을 제공합니다. 일반적으로 각 도메인 (때로는 여러 도메인)을 지원하기 위해 팀이 구성됩니다.
도메인의 데이터 및 기능은 도메인 내에 존재하는 하나 이상의 시스템에 의해 제공됩니다. 시스템 자체는 대개 하나 이상의 서비스로 구성됩니다. 따라서 가장 낮은 수준에서 전자 거래는 기능 도메인 중 하나에 각각 정렬되는 시스템으로 함께 그룹화 할 수있는 대규모 서비스 모음입니다. 아래 다이어그램은이 진술을 나타내는 데 도움이됩니다.
간단하게하기 위해 각 도메인에는 하나의 시스템 만 있고 각 시스템은 몇 가지 서비스로 구성되어 있다고 가정합니다. 그러나 실제로는 도메인에 여러 시스템이있을 수 있습니다. 예를 들어 가격 책정 도메인에는 국채 및 회사 채권에 대한 가격 체계가 다를 수 있습니다. 모든 딜러는 서로 다른 시스템 디자인을 가지지 만 7 개 도메인은 각 딜러 환경에 존재합니다.
기능적 도메인.
기능 영역은 전자 거래 정보를 논리적 그룹으로 분리합니다. 즉, 각 도메인에는 고유 한 정보 데이터 세트가 있습니다. 데이터 세트는 아래 표에 설명 된대로 일반화 할 수 있습니다. 이 표와이 기사에서 사용 된 용어의 정의는 용어를 참조하는 것이 도움이 될 수 있습니다.
이것은 본질적으로 전자 거래 내 존재하는 모든 데이터 유형을 요약합니다. 서로 다른 딜러 시스템은 각 도메인 내의 데이터 유형에 대한 다양한 세부 조정을 할 수 있지만 근본적으로 시스템간에 흐르는 데이터는 이러한 도메인 데이터 유형 중 하나로 분류 될 수 있습니다.
도메인 간의 데이터 관계.
각 기능 도메인 내의 시스템은 제대로 작동하려면 다른 도메인의 데이터가 필요합니다. 아래 다이어그램은 도메인 간의 논리적 데이터 관계를 보여줍니다. 이것은 단순화 된보기이지만 일반적으로 여기에 표시된 흐름은 모든 전자 거래 시스템에 보편적입니다.
참조 데이터 및 시장 데이터는 모든 도메인의 기본 요소입니다. 참조 데이터는 채권 가격 책정을위한 분석 데이터를 제공하며 채권 ID 스키마와 예약을위한 거래 상대방 정보 데이터 간의 변환을 제공합니다. 시장 데이터는 핵심 가격, 견적 및 주문에 대한 비교 및 ​​제어 메커니즘으로 사용되는 외부 가격을 제공합니다.
가격 결정 시스템은 핵심 채권 가격 데이터를 계산하기 위해 채권의 참조 데이터가 필요합니다. 보다 정교한 가격 계산은 핵심 채권 가격을 계산할 때 시장 데이터를 추가 입력으로 사용할 수 있습니다.
견적 시스템은 핵심 채권 가격을 취해 ECN에 대한 견적 산정의 기초로 사용합니다. 견적은 일반적으로 ECN 고유의 입찰가 스프레드를 핵심 채권 가격 (가격 확대)에 적용하고 견적이 좋은 수량을 설정하여 계산됩니다. 예약 도메인의 위치 데이터는 채권에 보유 된 현재 위치를 평가하고 견적 금액을 수정하는 데 사용됩니다. 위치는 또한 적절한면을 축 방향으로 표시하는 데 사용될 수 있습니다. 시장 데이터 (시장 최적 가격)는 ECN 견적 가격에 대한 제한을 제공하거나 판매 업체의 ECN 견적 가격 (즉, 시장 가격을 견적 가격 자체로 사용)을 대체하기 위해 견적 시스템에 의해 사용됩니다.
D2C 협상 시스템은 고객과 딜러 간의 전자 협상 작업 흐름을 처리합니다. 고객이 협상을 시작하면, 딜러는 고객이 거래를 제안한 채권의 가격에 대한 가격을 제공해야합니다. 협상이 시작된 ECN의 현재 채권 견적은 일반적으로 가격의 출발점입니다. 그런 다음 다른 요소가 고려되어 가격을 추가로 변경합니다. 고객의 품질, 고객이 요구하는 수량, 현재 시장 최고의 가격 및 딜러가 채권에 보유하고있는 현재 위치는 모두 일반적으로 견적 시스템에서 채권 견적 가격을 수정하고 고객.
D2D 거래 시스템은 D2D ECN의 견적 및 주문 관리에 사용됩니다. 일반적으로 이러한 시스템은 인용 시스템과 시장 데이터 가격의 견적을 비교하여 가격과 수량을 지속적으로 조정하는 알고리즘을 사용합니다. 예약 도메인 시스템의 위치 정보는 견적 및 주문 수량을 제어하는 ​​데 사용됩니다. D2D 거래 시스템은 고액 거래를 수행하는 고주파 거래 시스템입니다. 그들은 시장 상황의 변화에 ​​따라 주문 가격이 최신 상태를 유지할 수 있도록 매우 효율적이고 가능한 최저 대기 시간으로 운영되어야합니다.
도메인의 서비스.
이 기사의 앞부분에서 도메인은 하나 이상의 시스템을 가지고 있다고 기술되었으며 각 시스템에는 하나 이상의 서비스가 있습니다. 도메인 용 데이터를 생성하는 것은 서비스입니다. 일반적으로 각 유형의 데이터에 대한 서비스가 있으며, 이는 비즈니스 서비스입니다. 아래 다이어그램은 이전 섹션에서 정의한 데이터를 생성하기 위해 각 도메인에 있어야하는 핵심 비즈니스 서비스를 보여줍니다. 이 다이어그램은 이전 다이어그램을 확장하여 도메인 간의 데이터 관계도 포함합니다. 여기에는 비즈니스 서비스와 관련된 인프라 서비스 (예 : 데이터베이스, ECN 연결 서비스, 메시징 서비스 및 기타)는 포함되지 않습니다.
딜러 시스템 설계에 따라 도메인의 모든 서비스가 하나의 시스템 또는 개별 시스템에 소유 될 수 있습니다. 그러나 상수는 여기에 표시된 각 서비스의 기능이 도메인의 일부 시스템에 의해 수행된다는 것입니다. 각 서비스의 기능은 아래 표에 설명되어 있습니다.
환경.
존재할 필요가있는 모든 서비스에 대해 알게 된 지금 우리는 전자 거래 환경의 개념을 논의하기 위해 계속 나아갈 수 있습니다. 전자 거래 환경은 일련의 서비스입니다. 동일한 서비스의 중복을 배치하면 두 번째 전자 거래 환경이 생성됩니다. 대부분의 채권 거래 기관은 여러 용도로 사용하기 위해 여러 환경을 동시에 운영합니다. 아래 표는 배포 된 일반적인 환경을 설명합니다.
환경 세트는 이것에 국한되지 않습니다. 예를 들어 일부 조직은 여러 테스트 환경을 갖습니다. 채권 전자 거래의 성공적인 운영을 위해서는 서로 다른 환경을 유지하는 것이 필수적입니다. 이 기능이 없으면 생산 채권 전자 거래 환경이 변화가 없어 정체되거나 새로운 기능이 테스트됨에 따라 극도로 불안정해질 것입니다. & # 8216; 개발 및 테스트 환경의 통제 된 조건보다
환경 교차점.
환경 크로스 오버는 한 환경의 시스템이 다른 환경의 시스템에 연결될 때를 설명하는 개념입니다. 일반적으로 이것은 일부 서비스가 환경에 존재하지 않고이를 보완하기 위해 발생하며 다른 환경의 서비스가 사용됩니다. 고전적인 예는 ECN 거래입니다. ECN은 일반적으로 테스트 환경과 생산 환경 만있는 개발 환경이 없기 때문에 일반적으로 딜러의 개발 환경이 ECN 테스트 환경으로 넘어갑니다. 아래 다이어그램은 환경 교차를 보여줍니다.
탄력성을 위해 일반적으로 딜러 및 ECN의 프로덕션 라이브 환경과 백업 환경간에 크로스 오버가 있습니다. 그러나 어느 한 시점에서 어느 한 사이트에서만 하나의 환경 만 활성화됩니다.
환경은 지리적 위치에 배치됩니다. 전 세계적으로 거래하는 딜러는 일반적으로 여러 지역에 위치한 생산 환경이 필요합니다. 프로덕션 환경이있는 각 지역마다 백업, 테스트 및 개발 환경에 대한 요구 사항도 있습니다. 따라서 딜러가 3 개의 글로벌 거래 지역을 보유하고있는 경우 딜러는 전자 거래 서비스의 총 3 x 4 = 12 배포를 보유합니다. 따라서 필요한 배치 수는 필요한 환경과 거래 위치의 함수입니다. 여러 위치에서 여러 환경을 관리하면 시간이 많이 걸리고 복잡해질 수 있습니다. 배포 기술을 사용하기가 쉽지 않은 경우 환경에 새 서비스를 추가하는 간단한 개념은 모든 위치의 모든 환경에 추가해야하므로 지루한 프로세스가 될 수 있습니다.
닫는 중 & # 8230;
이 기사에서는 모든 전자 거래 환경에 보편적 인 개념을 도입했습니다. 이들을 이해하는 것은 전자 거래에서 일하는 정보 기술 전문가 또는 비즈니스 분석가에게 필수적입니다. 이 정보는 다음 기사에서 서비스 및 인프라를 더 자세히 조사하기 위해 필요한 기초의 일부입니다.

채권 거래 시스템.
채권 거래 시스템의 작동 방식.
채권 매매 비즈니스 입문서.
전자 시스템을 사용하는 채권 거래를 전자 거래라고합니다. 이를 위해서는 상당량의 IT 인프라가 필요합니다. 정보 기술을 탐구하기 전에 채권 매매 비즈니스의 기본을 이해해야합니다. 이 기사는 채권 거래 과정을 설명합니다. 이것은 매우 광범위하고 깊은 주제입니다. 이 기사에서 우리는 다음 기사에서 정보 기술을 탐구하는 데 필요한 표면을 훑어보고 이해할 수있을 것입니다.
채권 사업.
채권 사업은 많은 활동을하고 있으며, 단순화를 위해 4 가지 핵심 운영 그룹 중 하나로 분류 할 수 있습니다. 이러한 모든 작업은 정보 기술에 의해 지원되며 각 그룹은 채권 거래의 특정 측면에 중점을 둡니다.
본드 라이프 사이클 기본 사항.
채권은 법적 조직이 부채를 발행하여 자본을 조달하는 수단입니다. 법률 조직은 정부, 기업, 국가 기관 및 기타 기관입니다. 채권은 채권 보유자가되는 투자자가 구매합니다. 채권 보유자는 일정에 의해 정의 된 기간에 채권 발행 기관으로부터이자 지급을받습니다. 채권에는 만기가 설정된 용어 (만기일)가 있고 그 기간이 끝날 때마다 채권의 원래 가치가 채권자에게 반환됩니다. 원래 값은 액면 값이라고도합니다.
아래 다이어그램은이를 설명하는 데 도움이됩니다.
채권에 대한이자 지급은 쿠폰 지급이라고합니다. 이 기간은 채권자가 실제로이자 지불을 받기 위해 채권 발행인에게 제시해야하는 티어 오프 쿠폰을 실제로 가지고있는 경우 역사적입니다.
기본값.
채권 발행자가 채권 매수인에게 만기에이자 지급의 일부 또는 전부를 지불 할 수 없게 될 위험이 있습니다. 이를 신용 위험이라고합니다. 채권 발행자가 채권 일정을 지키지 못하면 채권 발행자는 채권에 채무 불이행을합니다.
채권 발행자가 채무 불이행 (예 : 파산 선고) 한 채권자 인 경우 채권자가 선순위 채무로 분류되면 채권자는 액면가 액의 일정 비율을받을 수 있습니다. 그것이 종속 부채라면 선금이 만기가 된 후에 만 ​​지불금이 발생합니다.
주요 시장.
채권은 1 차 시장에서 발행됩니다. 이것은 채권 발행자가 채권 소유 대신에 채권 매수인의 자본을 수령하는 곳입니다. 채권 매입자는 채권을 만기까지 보유 할 수 있으며 만기일에 액면가를 받고 평생 동안이자 지불을받을 수 있습니다.
2 차 시장.
채권 소유자는 채권을 다른 금융 투자로 전환 할 수 있습니다. 이것은 중매 시장에서 채권을 거래함으로써 쉽게 수행됩니다. 2 차 시장은 채권을 상품으로 사고 팔 수있는 곳입니다.
일반적으로 "채권 매매"라는 용어는 중개 시장 거래를 의미합니다. 아래 다이어그램은 시장 단계에서의 채권 거래 및 채권의 평생을 요약합니다.
2 차 채권 시장.
시장에는 고객과 상인이 있으며, 고객은 현금으로 물건을 얻기 위해 시장으로갑니다. 상인은 수익을 위해 물건을 팔려고 시장에갑니다. 이 점에서 중매도 시장은 다르지 않습니다. 투자 은행은 가맹점이며 연금이나 자산 관리 펀드를 관리하는 투자 회사가 고객입니다. 이것은 시장 참여자의 일반화이지만 진행을 위해 필요한 것만 큼 좋습니다. 2 차 시장에서, 판매 측, 마켓 메이커, 상인 또는 상인이라는 용어는 상인을 식별합니다. 고객은 구매자, 시장 점유자, 고객 또는 고객이라는 용어로 식별됩니다. 이 기사에서는 딜러 / 상인 및 고객이라는 용어를 사용합니다.
가격은 파의 백분율로 표시됩니다. Par는 액면가의 또 다른 용어입니다. 따라서 100.00의 가격은 채권의 액면가의 100.00 %입니다. 아래 다이어그램은 딜러와 거래하는 고객을위한 상황의 예를 보여줍니다. 딜러는 고객이 거래 할 수있는 가격을 책정합니다. 일반적으로 딜러는 낮은 가격에 팔리고 높은 가격으로 판매됩니다. 예제에서 딜러는 99.5에서 구매하고 100.5에서 팔려고합니다. 이것은 본질적으로 채권의 액면가가 100 달러라면 딜러는 99.50 달러에 사게되고 100.50 달러에 팔릴 것을 의미합니다. 딜러가 구매하는 가격은 입찰 가격이며 딜러가 판매하는 가격은 묻는 가격입니다. 질문 가격은 제안 가격이라고도합니다.
입찰가와 가격의 차이를 입찰가 스프레드 (입찰가 스프레드)라고합니다. 스프레드가 넓을수록 디스트리뷰터가 더 좋으며 스프레드가 좁을수록 고객에게 유리하지만 입찰 가격은 항상 묻는 가격보다 낮습니다. 딜러는 항상 더 넓은 스프레드를 원하지만 고객은 항상 좁은 스프레드를 원할 것입니다.
일반적으로 딜러는 만기까지 채권을 보유하는 것에 관심이 없으며 수익을 낮게 책정하고 높은 가격으로 판매하는 데 관심이 있습니다. 이와 대조적으로 고객은 채권을 만기까지 보유하거나 적어도 채권에서이자를 수령하고 일반적으로 채권을 재투자하는 것에 관심이 있습니다.
2 차 시장에 대한 채권 가격 책정.
채권의 가치는 채권의 만기까지의 시간을 기준으로 할인 된 액면가에 쿠폰 지급액을 더한 금액으로 계산할 수 있습니다. 이는 만기 수익률이라고도하며, 채권이 만기가 될 때까지 보유 할 경우 얻을 수있는 수익률을 나타냅니다.
그러나 만기 별 수익은 채권 발행자의 신용 위험을 고려하지 않습니다 (즉 채무 불이행 가능성). 또한 이자율 변동으로 인한 위험 요인도 없습니다. 일반적으로 이자율이 상승하고 채권 가격이 하락하고 그 반대의 경우도 마찬가지입니다. 즉, 만기 수익률은 일반적으로 2 차 시장 가격을 계산할 때 사용되지 않습니다.
실제로, 중매 시장에서 채권 가격을 책정하는 데 사용되는 다양한 기법이 있습니다. 우리는이 소개 수준에서 적절하지 않기 때문에 이러한 기술에 관해 논의하지 않을 것입니다. 그러나 모든 가격 책정 기법에 공통적 인 하나의 기본 개념이 있습니다. 한 채권을 다른 채권 가격으로 책정합니다. 아래 다이어그램은이를 설명하는 데 도움이됩니다. 이것은 회사채 가격이 벤치 마크 채권의 변화에 ​​의해 좌우되는 전형적인 예를 보여줍니다. 일반적으로 벤치 마크 채권은 국채입니다.
일반적으로 회사채 가격은 벤치 마크에서 고정 된 스프레드를 가지고 있습니다. 벤치 마크 가격이 바뀌면 회사 채권 가격도 변하게됩니다. 고급 가격 책정 기법은 여러 벤치 마크의 혼합 가격 또는 채권을 사용하여 채권 가격에 도달 할 수 있습니다. 현재로서는 채권 가격이 다른 채권 가격을 끌어 올릴 수 있다는 인식을 가지고 있으면 충분합니다. 이것은 거래를위한 채권 가격 책정의 중요한 개념입니다. 이와 같은 가격 관계는 대부분의 채권 가격 책정 시스템의 기초입니다.
2 차 시장 유동성.
정부는 정부 부채를 채우기 위해 채권을 발행합니다. 채권의 가치가 유지되고 부채가 정크로 보이지 않도록 정부는 양방향 가격을 지속적으로 인용하여 매매가가 중매 시장에서 유동성을 유지할 의무를집니다. 양방향 가격은 매매 가격의 또 다른 용어입니다. 이는 시장에 대한 정부 채권 가격이 정확한지 확인하기 위해 큰 책임과 가능한 재정적 위험을 상인에게 제기합니다. 이 가격은 이자율 변동에 매우 민감하게 반응하며 그 반대도 마찬가지입니다. 이러한 의무는 정부 채권 가격이 항상 유동적이어서 2 차 채권 거래를 실행 가능하고 안정적으로 유지하도록 보장합니다. 이러한 의무를지는 딜러에게는 정부 부채의 1 차 시장 경매에 참여할 수 있다는 이점이 있습니다. 이 경매에 참여하는 것은 상인에게 재정적 및 평판 이익을 제공합니다.
액체 정부 채권 가격의 중요성.
일반적으로 채권은 정부 채무 또는 기업 채무로 분류됩니다. 국채는 일반적으로 정부가 파산하지 않기 때문에 정부가 발행하고 부도 위험이 낮습니다. 낮은 위험으로 인해, 그들은 또한 낮은 쿠폰 지불합니다. 이것은 낮은 위험, 낮은 보상이라는 개념을 따른다.
반대로 회사채는 채무 불이행 위험이 높습니다. 따라서 쿠폰은 동등한 정부 채권보다 높습니다. 회사채의 가격 결정은 일반적으로 국채에 대한 가격 책정을 통해 이루어집니다. 단일 국채로 인해 여러 회사 채권 가격이 상승 할 수 있습니다. 국채 가격이 변동함에 따라 회사채 가격에 연쇄 적 영향이 있습니다. 유동성있는 정부 가격에 대한 회사채 가격을 책정함으로써 회사채는 본질적으로 유동성을 갖는다.
정부 부채 가격의 유동성 또한 경제 성장에 중요한 요소입니다. 유동성은 정부와 금융 안정에 대한 자신감의 신호입니다.
2 차 시장에서의 수익 창출.
딜러는 낮은 가격으로 구매하고 높은 가격으로 판매 할 수 있지만 판매 및 구매 가격은 딜러가 설정하므로 일반적으로 고객이 사용할 수 없습니다. 일부 거래 기관은 딜러 가격을 조정하려고 시도하지만 이는 일반적으로 매우 어려우므로 어느 정도 결정할 수없는 투자 수익률 (return-on-investment)로 집중적 인 정보 기술 투자가 필요합니다.
채권 매매 스타일.
2 차 시장 거래의 두 가지 스타일이 있습니다. 고객과 거래하는 딜러는 D2C (Deal-To-Customer) 또는 B2C (B2B) 거래라고합니다. 이러한 형태의 거래는 일반적으로 채권 매매에서 발생하며, 거래가 합의되기 전에 고객이 가격을 합의한 가격으로 양측이 가격을 조정합니다.
딜러는 다른 딜러와 직접 거래 할 수도 있습니다. 이를 D2D (Deal-to-dealer), B2B (B2B) 또는 IDB (inter-dealer-broker) 거래라고합니다. 이 거래 형태는 고속이며 무자비하며 무역 가격에 동의하는 인간의 상호 작용이 없습니다. 딜러가 제시 한 가격은 다른 딜러가 즉시 교환 할 수 있습니다. 이러한 이유로 D2D 인용은 경쟁 업체와 계속해서 이어져야합니다. 느린 가격은 딜러가 시장에서 거래되고 손실을 의미 할 수 있습니다.
일반적으로 전자 시장은 D2D 또는 D2C 범주로 구분됩니다. 딜러는 두 가지 거래 패러다임을 처리하기 위해 서로 다른 시스템 설계가 필요합니다. D2C 거래는 고객이 정확한 가격을 제공 할 수 있도록 고객을 파악하는 데 더 중요합니다. D2D 거래는 딜러의 거래 시스템의 원시 마력에 관한 것입니다.
참고로, 정부의 채무 의무는 D2D 시장에만 있습니다.
전자 채권 거래는 고객과 딜러가 거래 할 수있게합니다. 그러나 양측은 한 데 모일 필요가있다. 판매원이 들어오는 곳입니다. 그들은 고객이 딜러와 협상하도록하는 작업을 수행합니다. 무역 업무 흐름의 상당 부분이 전자 방식으로 수행 되더라도 간단한 인간 역학에 의존하는 요소가 여전히 존재합니다. 고객을 & nbsp; 상점 & # 8221; 이 중 하나입니다.
판매 직원은 딜러와 거래를하는 고객을 대표하여 거래 기준으로 커미션을받습니다.
전자 시장.
전자 채권 거래는 ECN (Electronic Communication Networks)이라고하는 전자 시장 제공자가 주최합니다. 이들은 또한 교류라고합니다. D2D 또는 D2C 거래 전문 ECN이 있습니다. 딜러와 고객은 ECN에 직접 연결하고 ECN을 통해 거래 활동을 실행합니다. 딜러는 일반적으로 API를 통해 ECN에 연결합니다. API를 통해 판매자는 ECN에서 사용 가능한 시장 데이터를 수신하거나, 주문 (D2D 시장)을 제출하거나 고객 협상 (D2C 시장)에 응답 할 수 있습니다. 고객은 일반적으로 ECN에서 제공하는 소프트웨어 응용 프로그램을 사용하여 ECN의 현재 가격을보고 협상을 시작합니다. 일반적으로 ECN은 거래 당 실행되는 소액 수수료를받습니다. 일반적으로 딜러는 가능한 한 많은 전자 상거래가 가능하도록 여러 ECN에 연결합니다. 딜러가 액세스 할 수있는 장소가 많을수록 거래 가능성이 높아 지므로 상식입니다.
이들은 오늘날 존재하는 ECN 중 일부입니다. 결코 포괄적 인 것은 아닙니다.
정착.
ECN은 거래가 합의 된 곳이지만 채권에 대한 실제 현금 인도 또는 결제 기관에서 발생하는 결제입니다. 결제는 거래가 실행 된 후 표준 시간대에 수행됩니다. 시간 프레임은 본드에 대한 규칙입니다 (예 : 유로 국채는 T + 2 기준으로 정산됩니다 (즉, 거래가 합의 된 후 2 일). 일부 채권은 현금으로 결제되며 이는 동일한 날 (T + 0)에 거래되고 정산된다는 것을 의미합니다.
거래소는 거래 상대방의 위험을 감수합니다. 본질적으로 무역 (구매자와 판매자)의 각 협동자는 서로 직접적으로 정보 센터와 정착한다. 어느 쪽이든 지불하지 않거나 전달하지 않으면, 거래소의 다른 쪽이 만기가되는 것을 결제소가 보증합니다. 이는 거래 정산 중 각 거래 상대방을 불이행으로부터 보호합니다. 클리어링 하우스는 각 거래 상대방으로부터의 담보 지불을 요구함으로써 발생할 수있는 채무에 대한 보상을 요구합니다.
닫는 중 & # 8230;
이 기사에서는 채권 거래 사업에서 사용되는 기본 프로세스와 개념에 대해 설명했습니다. 이 기본적인 이해로 정보 기술을 탐구 할 수 있고 전자 거래 기술의 각 부분이 어떤 비즈니스 프로세스를 지원하는지 이해할 수 있습니다.

채권 매매 시스템
(조나단 사이먼)
대규모 패턴 모음이나 패턴 언어에서 벗어나기 쉽습니다. 패턴은 아이디어를 재사용 가능한 형태로 추상화 한 것입니다. 흔히 패턴을 매우 유용하게 만드는 매우 일반적인 패턴은 이해하기 어렵게 만듭니다. 때때로 패턴을 이해하는 데 도움이되는 가장 좋은 방법은 실생활의 예입니다. 일어날 수있는 일에 대한 인위적 시나리오가 아닙니다. 그러나 실제로 일어나는 것과 일어날 일은 무엇인가.
이 장에서는 발견 프로세스를 사용하여 문제점을 해결하는 패턴을 적용합니다. 우리가 논의 할 시스템은 초기 설계부터 생산까지 2 년 동안 함께 일한 채권 거래 시스템입니다. 우리는 마주 치게되었던 시나리오와 문제 그리고 패턴으로 그것들을 해결하는 방법을 조사 할 것입니다. 여기에는 패턴을 선택하는 결정 프로세스뿐만 아니라 시스템 요구에 맞게 패턴을 결합하고 조정하는 방법이 포함됩니다. 또한 비즈니스 요구 사항, 고객 결정, 아키텍처 및 기술 요구 사항, 레거시 시스템 통합 등 실제 시스템에서 발생하는 세력을 고려하여이 모든 작업을 수행합니다. 이 접근법의 의도는 실용적인 응용을 통해 패턴 그 자체에 대한 명확한 이해를 제공하는 것입니다.
시스템 구축.
주요 월스트리트 투자 은행은 채권 매매 데스크의 업무 흐름을 간소화하기 위해 채권 가격 책정 시스템을 구축하기 시작했습니다. 현재 채권 거래자들은 다수의 채권 가격을 몇 개의 다른 거래 장소에 보내야하며 각 거래 장소에는 자체 사용자 인터페이스가 있습니다. 이 시스템의 목표는 단일 캡슐화 된 사용자 인터페이스에서 채권 시장에 특화된 고급 분석 기능과 함께 모든 채권 가격 책정의 세부 사항을 최소화하는 것입니다. 이는 다양한 통신 프로토콜을 통한 여러 구성 요소와의 통합 및 통신을 의미합니다. 시스템의 높은 수준의 흐름은 다음과 같습니다.
높은 수준의 흐름.
첫째, 시장 데이터가 시스템에 제공됩니다. 시장 데이터는 사람들이 자유 시장에서 채권을 사거나 팔고 자하는 것을 나타내는 채권의 가격 및 기타 자산과 관련된 데이터입니다. 시장 데이터는 즉시 데이터를 변경하는 분석 엔진으로 전송됩니다. 애널리틱스는 채권의 가격 및 기타 속성을 변경하는 금융 애플리케이션을위한 수학 함수를 말합니다. 이들은 입력 변수를 사용하여 함수의 결과를 특정 본드에 맞추는 일반 함수입니다. 각 상장 데스크톱에서 실행되는 클라이언트 응용 프로그램은 상인 당 가격 책정마다 채권에 대한 분석의 특성을 제어하면서 상장 기준으로 분석 엔진을 구성합니다. 분석이 시장 데이터에 적용되면 수정 된 데이터가 다른 회사의 상인이 채권을 매매 할 수있는 다양한 거래 장소로 보내집니다.
패턴이있는 아키텍처.
시스템의 워크 플로우에 대한이 개요를 통해 우리는 설계 프로세스 중에 발생하는 일부 건축 문제에 접근 할 수 있습니다. Let†™ s는 우리가 지금까지 알고있는 것을 보았습니다. 거래자는 Windows NT 및 Solaris 워크 스테이션 모두에서 응답이 빠른 응용 프로그램이 필요합니다. 따라서 우리는 플랫폼 독립성과 사용자 입력 및 시장 데이터에 신속하게 응답 할 수 있기 때문에 클라이언트 애플리케이션을 Java 씩 클라이언트로 구현하기로 결정했습니다. 서버 측에서는 시스템에서 활용할 레거시 C ++ 구성 요소를 상속합니다. 시장 데이터 구성 요소는 TIBCO 정보 버스 (TIB) 메시징 인프라와 통신합니다.
우리는 다음 구성 요소를 상속 받고 있습니다.
시장 데이터 가격 공급 서버 : 들어오는 시장 데이터를 TIB에 게시합니다. 분석 엔진 : 들어오는 시장 데이터에 대한 분석을 수행하고 수정 된 시장 데이터를 TIB에 브로드 캐스트합니다. Contribution Server : 거래 장소와의 모든 통신을 수행합니다. 거래 장소는 은행이 통제하지 않는 제 3 자 구성 요소입니다.
기존 시장 데이터 하위 시스템.
유산 기여 하위 시스템.
개별 하위 시스템 (Java 씩 클라이언트, 시장 데이터 및 컨트 리뷰 션)이 통신하는 방법을 결정해야합니다. 두꺼운 클라이언트가 기존 서버와 직접 통신 할 수는 있지만 클라이언트에서 너무 많은 비즈니스 논리가 필요합니다. 대신, we†™ ll는 legacy servers†"시장 자료를위한 가격 설정 출입구에 거래 장소에 가격을 보내기를위한 기여금 출입구와 교통하기 위하여 자바 출입구 한 쌍을 건설합니다. 이렇게하면 이러한 영역과 관련된 비즈니스 논리를 멋지게 캡슐화 할 수 있습니다. 시스템의 현재 구성 요소는 다음과 같습니다. †marked로 표시된 연결. ”는 우리가 어떤 구성 요소가 어떻게 의사 소통을하는지 확신 할 수 없다는 것을 나타냅니다.
시스템과 그 구성 요소.
첫 번째 통신 질문은 데이터를 교환하기 위해 Java 씩 (thick) 클라이언트와 두 개의 Java 서버 구성 요소를 통합하는 방법입니다. Let†™ s는이 책에서 제안 된 네 가지 통합 스타일 인 파일 전송, 공유 데이터베이스, 원격 프로 시저 호출 및 메시징을 살펴 봅니다. 우리는 클라이언트와 데이터베이스 사이의 추상화 계층을 만들고 don†™ t가 클라이언트에 데이터베이스 액세스 코드를 갖고 싶어하므로 공유 데이터베이스를 즉시 제외 할 수 있습니다. 파일 전송은 현재 가격이 거래 장소로 보내지는 것을 보장하기 위해 최소한의 대기 시간이 필요하기 때문에 마찬가지로 배제 될 수 있습니다. 이로 인해 원격 프로 시저 호출 또는 메시징 중 하나가 선택됩니다.
Java 플랫폼은 원격 프로 시저 호출 및 메시징에 대한 기본 제공 지원을 제공합니다. RPC 스타일 통합은 RMI (Remote Method Invocation), CORBA 또는 EJB (Enterprise Java Beans)를 사용하여 수행 할 수 있습니다. Java Messaging Service (JMS)는 메시징 스타일 통합을위한 공통 API입니다. 따라서 두 가지 통합 스타일은 Java로 구현하기 쉽습니다.
따라서이 프로젝트, 원격 프로 시저 호출 또는 메시징에서 더 잘 작동합니까? There†™ s 가격 설정 출입구의 단지 1 개의 사례 및 체계에있는 기여금 출입구의 1 개의 인스턴스, 그러나 보통 많은 두꺼운 클라이언트는 동시에이 서비스 (특정 시간에 로그인되는 우연히 일어나는 각 채권 거래자를위한 하나)에 연결합니다. 또한이 은행은 다른 애플리케이션에서 활용할 수있는 일반적인 가격 책정 시스템을 원합니다. 따라서 알 수없는 수의 Think Client 외에도 게이트웨이에서 나오는 가격 데이터를 사용하는 다른 애플리케이션이 알려지지 않은 경우도 있습니다.
씩 클라이언트 (또는 가격 데이터를 사용하는 다른 응용 프로그램)는 RPC를 사용하여 게이트웨이에 전화를 걸면 가격 데이터를 받고 처리를 호출 할 수 있습니다. 그러나 가격 데이터는 지속적으로 게시되며 일부 고객은 특정 데이터에만 관심이 있으므로 적시에 적절한 고객에게 관련 데이터를 제공하는 것이 어려울 수 있습니다. 클라이언트는 게이트웨이를 폴링 할 수 있지만 많은 오버 헤드가 발생합니다. 게이 트웨이는 데이터를 사용할 수있게되는 즉시 클라이언트에서 데이터를 사용할 수 있도록하는 것이 좋습니다. 그러나 이것은 각 게이트웨이가 현재 어떤 클라이언트가 활성 상태이고 어떤 특정 데이터가 필요한지 추적해야합니다. 그런 다음 새 데이터 조각이 사용 가능 해지면 (초당 수없이 발생) 게이트웨이는 각 관심 클라이언트에게 클라이언트에 데이터를 전달하는 RPC를 만들어야합니다. 이상적으로 모든 클라이언트는 동시에 통보되어야하므로 각 RPC는 자체 스레드로 만들어야합니다. 이 작업은 가능하지만 매우 빠르게 복잡해지고 있습니다.
메시징은이 문제를 크게 단순화합니다. 메시징을 통해 다양한 유형의 가격 데이터에 대해 별도의 채널을 정의 할 수 있습니다. 그런 다음 게이트웨이가 새 데이터를 가져 오면 해당 데이터 유형에 대한 게시 - 구독 채널에 해당 데이터가 포함 된 메시지를 추가합니다. 한편 특정 유형의 데이터에 관심이있는 모든 고객은 해당 유형의 채널에서 수신 대기합니다. 이러한 방식으로, 게이트웨이는 청취자 애플리케이션이 얼마나 많은지 또는 그들이 무엇인지 알 필요없이 원하는 누구에게나 새로운 데이터를 쉽게 전송할 수 있습니다.
클라이언트는 여전히 게이트웨이에서 동작을 호출 할 수 있어야합니다. 두 개의 게이트웨이 만 있기 때문에 클라이언트가 메소드를 동 기적으로 호출하는 동안 차단할 수 있으므로 클라이언트 - 게이트웨이 호출은 RPC를 사용하여 쉽게 구현할 수 있습니다. 그러나 이미 게이트웨이 간 통신을 위해 메시징을 사용하고 있으므로 메시지는 클라이언트와 게이트웨이 간의 통신을 구현하는 데에도 유용합니다.
따라서 게이트웨이와 클라이언트 간의 모든 통신은 메시징을 통해 수행됩니다. 모든 구성 요소가 Java로 작성 되었기 때문에 JMS는 메시징 시스템으로 쉽게 선택할 수 있습니다. 이는 메시징 인프라를 거의 변경하지 않고 현재 시스템과 통합 할 수있는 메시지 버스 또는 아키텍처를 효과적으로 만듭니다. This way, the business functionality of the application can be easily used by other application the bank develops.
Java Components Communicating with JMS.
JMS is simply a specification and we need to decide on a JMS-compliant messaging system. We decided to use IBM MQSeries JMS because the bank is an “IBM shop, ” using WebSphere application servers and many other IBM products. As a result, we will use MQSeries since we already have a support infrastructure in place and a site license of the product.
The next question is how to connect the MQSeries messaging system with the standalone C++ Contribution server and the TIBCO based Market Data and Analytics Engine servers. We need a way for the MQSeries consumers to have access to the TIB messages. But how? Perhaps we could use the Message Translator pattern to translate TIB messages into MQSeries messages. Although the C++ client for MQSeries serves as a Message Translator , using it would sacrifice JMS server independence. And although TIBCO does have a Java API, the customer architect and manager have rejected it. As a result, the Message Translator approach has to be abandoned.
The bridge from the TIB server to the MQSeries server requires communication between C++ and Java. We could use CORBA, but then what about the messaging? A closer look at the Message Translator pattern shows it is related to the Channel Adapter in its use of communication protocols. The heart of a Channel Adapter is to connect non-messaging systems to messaging systems. A pair of channel adapters that connects two messaging systems is a Messaging Bridge .
The purpose of a Messaging Bridge is to transfer messages from one messaging system to another. This is exactly what we are doing with the added complexity of the intra-language Java to C++ communication. We can implement the cross language Messaging Bridge using a combination of Channel Adapter s and CORBA. We will build two lightweight Channel Adapter servers, one in C++ managing communication with the TIB, and one in Java managing communication with JMS. These two Channel Adapter , which are Message Endpoint s themselves, will communicate with each other via CORBA. Like our choice for MQSeries, we will use CORBA rather than JNI since it is a company standard. The messaging bridge implements the effectively simulated message translation between seemingly incompatible messaging systems and different languages.
Message Translator using Channel Adapters.
The next diagram shows the current system design including the Gateways and other components. This is a good example of pattern application. We combined two Channel Adapter s with a non-messaging protocol to implement the Message Translator pattern, effectively using one pattern to implement another pattern. Additionally, we changed the Channel Adapter s' context to link two messaging systems with a non-messaging cross language translation protocol rather than connecting a messaging system to a non-messaging system.
The current system with the Channel Adapters.
Structuring Channels.
A key to working with patterns is not only knowing when to use which pattern, but also how to most effectively use it. Each pattern implementation has to take into account specifics of the technology platform as well as other design criteria. This section applies the same discovery process to find the most efficient use of the Publish-Subscribe Channel in the context of the market data server communicating with the analytics engine.
Real time market data originates with market data feed, a C++ server that broadcasts market data on the TIB. The market data feed uses a separate Publish-Subscribe Channel for each bond it is publishing prices for. This may seem a little extreme since each new bond needs its own new channel. But this is not so severe since you do not actually need to create channels in TIBCO. Rather, channels are referenced by a hierarchical set of topic names called subjects. The TIBCO server then filters a single message flow by subject, sending each unique subject to a single virtual channel. The result of which is a very lightweight message channel.
We could create a system that publishes on a few channels and subscribers could listen only for prices they are interested in. This would require subscribers to use a Message Filter or Selective Consumer to filter the entire data flow for interesting bond prices, deciding whether each message should be processed as it is received. Given that the market data is published on bond-dedicated channels, subscribers can register for updates on a series of bonds. This effectively allows subscribers to "filter" by selectively subscribing to channels and only receiving updates of interest rather than deciding after the message is received. It is important to note that using multiple channels to avoid filtering is a nonstandard use of messaging channels. In context of the TIBCO technology however, we are really deciding whether to implement or own filters or utilize the channel filtering built into TIBCO -- rather than whether to use so many channels.
The next component we need to design is the analytics engine, another C++/TIB server that will modify the market data and rebroadcast it to the TIB. Although it is out of the scope of our Java/JMS development, we are working closely with the C++ team to design it since we are the analytics engine's primary 'customer'. The problem at hand is to find the channel structure that most efficiently rebroadcast the newly modified market data.
Since we already have one dedicated Message Channel per bond inherited from the market data price feed, it would be logical to modify the market data and rebroadcast the modified market data on the bond dedicated Message Channel . But this will not work since the analytics modifying the bonds prices are trader specific. If we rebroadcast the modified data on the bond Message Channel , we will destroy the data integrity by replacing generic market data with trader specific data. On the other hand, we could have a different message type for trader specific market data that we publish on the same channel allowing subscribers to decide which message they are interested in to avoid destroying the data integrity. But then clients will have to implement their own filters to separate out messages for other traders. Additionally, there will a substantial increase in messages received by subscribers, placing an unnecessary burden on them.
There are two options:
One Channel per Trader: Each trader has a designated channel for the modified market data. This way, the original market data remains intact and each trader application can listen to its specific traders Message Channel for the modified price updates. One Channel per trader per Bond: Create one Message Channel per-trader per-bond solely for the modified market data of that bond. For example, the market data for bond ABC would be published on channel "Bond ABC" while the modified market data for trader A would be published on Message Channel "Trader A, Bond ABC", modified market data for trader B on "Trader B, Bond ABC," and so on.
One channel per trader.
One channel per bond per trader.
There are advantages and disadvantages to each approach. The per-bond approach, for example, uses a lot more Message Channel . In the worst-case scenario, the number of Message Channel will be the number of bonds total multiplied by the number of traders. We can put upper bounds on the number of channels that will be created since we know that there are only around 20 traders and they never price more than a couple hundred bonds. This puts the upper limit below the 10,000 range, which is not so outlandish compared to the nearly 100,000 Message Channel the market data price feed is using. Also, since we are using the TIB and Message Channel are quite inexpensive, the number of Message Channel s is not a severe issue. On the other hand, the sheer number of Message Channel s could be a problem from a management perspective. Every time a bond is added a channel for each trader must be maintained. This could be severe in a very dynamic system. Our system, however, is essentially static. It also has an infrastructure for automatically managing Message Channel s. This combined with the inherited architecture of a legacy component using a similar approach minimizes the downside. This is not to say we should make an unnecessarily excessive number of Message Channel s. Rather, we can implement an architectural approach that uses a large number of Message Channel s when there is a reason.
And there is a reason in this case that comes down to the location of logic. If we implement the per trader approach, the Analytics Engine needs logic to group input and output channels. This is because the input channels from the Analytics Engine are per bond and the output Message Channel s would be per trader, requiring the Analytics Engine to route all analytics input from multiple bonds for a particular trader to a trader specific output Message Channel . This effectively turns the analytics engine into a Content-Based Router to implement custom routing logic for our application.
Following the Message Bus structure, the Analytics Engine is a generic server that could be used by several other systems in the. So we don’t want to cloud it with system specific functionality. On the other hand, the per-bond approach works since the idea of a trader owning the analytics output of bond prices is a company accepted practice. The per-bond approach keeps the Message Channel separation of the market data feed intact, while adding several more Message Channel s. Before we reach the client, we want a Content-Based Router to combine these several channels into a manageable number of channels. We don’t want the client application running on the trader’s desktop to be listening to thousands or tens of thousands of Message Channel s. Now the question becomes where to put the Content-Based Router . We could simply have the C++/TIB Channel Adapter forward all of the messages to the Pricing Gateway on a single Message Channel . This is bad for two reasons; we would be splitting up the business logic between C++ and Java, and we would lose the benefit of the separate Message Channel s on the TIB side allowing us to avoid filtering later in the data flow. Looking at our Java components, we could either place it in the Pricing Gateway or create an intermediary component between the Pricing Gateway and the client.
In theory, if we persisted the bond-based separation of Message Channel s all the way to the client, the Pricing Gateway would rebroadcast pricing information with the same channel structure as the Pricing Gateway and Analytics Engine. This means a duplication of all of the bond dedicated TIB channels in JMS. Even if we create an intermediary component between the Pricing Gateway and the client, the Pricing Gateway will still have to duplicate all of the channels in JMS. On the other hand, implementing logic directly in the Pricing Gateway allows us to avoid duplicating the large number of channels in JMS—allowing us to create a much smaller number of channels in the order of one per trader. The Pricing Gateway registers itself through the C++/TIB Channel Adapter as a consumer for each bond of every trader in the system. Then the Pricing Gateway will forward each specific client only the messages related to that particular trader. This way, we only use a small number of Message Channel s on the JMS end, while maximizing the benefit of the separation on the TIB end.
The complete Market Data Flow to the client.
The Message Channel layout discussion is a good example of how integrating patterns is important. The goal here was to figure out how to effectively use the Message Channel s. Saying you use a pattern isn’t enough. You need to figure out how to best implement it and incorporate into your system to solve the problems at hand. Additionally, this example shows business forces in action. If we could implement business logic in any of our components, we could have gone with the per trader approach and implemented an overall more simple approach with many less channels.
Selecting a Message Channel?
Now that we know the mechanics of the communication between the Java/JMS components and the C++/ TIBCO components, and we have seen some Message Channel structuring, we need to decide which type of JMS Message Channel s the Java components should use to communicate. Before we can choose between the different Message Channels available in JMS, let’s look at the high level message flow of the system. We have two gateways (Pricing and Contribution) communicating with the client. Market data flows to the client from the Pricing Gateway which sends it out to the Contribution Gateway. The client application sends message to the Pricing Gateway to alter the analytics being applied to each bond. The Contribution Gateway also sends messages to the Client application relaying the status of the price updates to the different trading venues.
The system message flow.
The JMS specification describes two Message Channel types, Point-to-Point Channel (JMS Queue ) and Publish-Subscribe Channel (JMS Topic ). Recall that the case for using publish-subscribe is to enable all interested consumers to receive a message while the case for using point-to-point is to ensure that only one eligible consumer receives a particular message.
Many systems would simply broadcast messages to all client applications, leaving each individual client application to decide for itself whether or not to process a particular message. This will not work for our application since there are a large number of market data messages being sent to each client application. If we broadcast market data updates to uninterested trader, we will be unnecessarily wasting client processor cycles deciding whether or not to process a market data update.
Point-to-Point Channel s initially sound like a good choice since the clients are sending messages to unique servers and visa versa. But it was a business requirement that traders may be logged in to multiple machines at the same time. If we have a trader logged in at two workstations simultaneously and a point-to-point price update is sent, only one of the two client applications will get the message. This is because only one consumer on a Point-to-Point Channel can receive a particular message. Notice that only the first of each group of a trader's client applications receives the message.
Point-to-Point Messaging for Price Updates.
We could solve this using the Recipient List pattern, which publishes messages to a list of intended recipients, guaranteeing that only clients in the recipient list will receive messages. Using this pattern, the system could create recipient lists with all client application instances related to each trader. Sending a message related to a particular trader would in turn send the message to each application in the recipient list. This guarantees all client application instances related to a particular trader would receive the message. The downside of this approach is that it requires quite a bit of implementation logic to manage the recipients and dispatch messages.
Recipient List for Price Updates.
Even though point-to-point could be made to work, let’s see if there is a better way. Using Publish-Subscribe Channel s, the system could broadcast messages on trader specific channels rather than client application specific channels. This way, all client applications processing messages for a single trader would receive and process the message.
Publish-Subscribe Messaging for Price Updates.
The downside of using Publish-Subscribe Channel s is that unique message processing is not guaranteed with the server components. It would be possible for multiple instances of a server component to be instantiated and each instance process the same message, possibly sending out invalid prices.
Recalling the system message flow, only a single communication direction is satisfactory with each Message Channel . Server-to-client communication with publish-subscribe is satisfactory while client-to-server communication is not and client-server communication with point-to-point is satisfactory while server-client is not. Since there is no need to use the same Message Channel in both directions, we can use each Message Channel only one direction. Client-to-server communication will be implemented with point-to-point while server-to-client communication will be implemented with publish-subscribe. Using this combination of Message Channel s, the system benefits from direct communication with the server components using point-to-point messaging and the multicast nature of publish-subscribe without either of the drawbacks.
Message flow with Channel Types.
Problem Solving With Patterns.
Patterns are tools and collections of patterns are toolboxes. They help solve problems. Some think that patterns are only useful during design. Following the toolbox analogy, this is like saying that tools are only useful when you build a house, not when you fix it. The fact is that patterns are a useful tool throughout a project when applied well. In the following sections we will use the same pattern exploration process we used in the previous section to solve problems in our now working system.
Flashing Market Data Updates.
Traders want table cells to flash when new market data is received for a bond, clearly indicating changes. The Java client receives messages with new data which triggers a client data cache update and eventually flashing in the table. The problem is that updates come quite frequently. The GUI thread stack is becoming overloaded and eventually freezing the client since it can’t respond to user interaction. We will assume that the flashing is optimized and concentrate on the data flow of messages through the updating process. An examination of performance data shows the client application is receiving several updates a second; some updates occurred less than a millisecond apart. Two patterns that seem like they could help slow down the message flow are Aggregator and Message Filter.
A first thought is to implement a Message Filter to control the speed of the message flow by throwing out updates received a small amount of time after the reference message. As an example, lets say that we are going to ignore messages within 5 milliseconds of each other. The Message Filter could cache the time of the last acceptable message and throw out anything received within the next 5 milliseconds. While other applications may not be able to withstand data loss to such an extent, this is perfectly acceptable in our system due to the frequency of price updates.
Time based Message Filter.
The problem with this approach is that not all data fields are updated at the same time. Each bond has approximately 50 data fields displayed to the user including price. We realize that not every field is updated in every message. If the system ignores consecutive messages, it may very well be throwing out important data.
The other pattern of interest is the Aggregator . The Aggregator is used to manage the reconciliation of multiple, related messages into a single message, potentially reducing the message flow. The Aggregator could keep a copy of the bond data from the first aggregated message, then update only new or changed fields successive messages. Eventually the aggregated bond data will be passed in a message to the client. For now, lets assume that the Aggregator will send a message every 5 milliseconds like the Message Filter . Later, we'll explore another alternative.
Aggregator with partial successive updates.
The Aggregator , like any other pattern, is not a silver bullet; it has its pluses and minuses that need to be explored. One potential minus is that implementing an Aggregator would reduce the message traffic by a great amount in our case only if many messages are coming in within a relatively short time regarding the same bond. On the other hand, we would accomplish nothing if the Java client only receives updates for one field across all of the traders bonds. For example, if we receive 1000 messages in a specified timeframe with 4 bonds of interest, we would reduce the message flow from 1000 to 4 messages over that timeframe. Alternatively, if we receive 1000 messages in the same timeframe with 750 bonds of interest, we will have reduced the message flow from 1000 to 750 messages; relatively little gain for the amount of effort. A quick analysis of the message updates proves that the Java client receives many messages updating fields of the same bond, and therefore related messages. So, Aggregator is in fact a good decision.
What's left is to determine how the Aggregator will know when to send a message it has been aggregating. The pattern describes a few algorithms for the Aggregator to know when to send the message. These include algorithms to cause the aggregator to send out its contents after a certain amount of time has elapsed, after all required fields in a data set have been completed, and others. The problem with all of these approaches is that the aggregator is controlling the message flow, not the client. And the client is the major bottleneck in this case, not the message flow.
This is because the Aggregator is assuming the consumers of its purged messages (the client application in this case) are Event-Driven Consumer s, or consumers that rely on events from an external source. We need to turn the client into a Polling Consumer , or a consumer that continuously checks for messages, so the client application can control the message flow. We can do this by creating a background thread that continuously cycles through the set of bonds and updates and flashes any changes that have occurred since the last iteration. This way, the client controls when messages are received and as a result, guarantees that it will never become overloaded with messages during high update periods. We can easily implement this by sending a Command Message to the Aggregator initiating an update. The Aggregator will respond with a Document Message containing the set of updated fields that the client will process.
The choice of Aggregator over Message Filter is clearly a decision based solely on the business requirements of our system. Each could help us solve our performance problems, but using the Message Filter would solve the problem at cost of the system data integrity.
Major Production Crash.
With the performance of the flashing fixed, we are now in production. One day the entire system goes down. MQSeries crashes, bringing several components down with it. We struggle with the problem for a while and finally trace it back to the MQSeries dead letter queue (an implementation of the Dead Letter Channel ). The queue grows so large that it brings down the entire server. After exploring the messages in the dead letter queue we find they are all expired market data messages. This is caused by “slow consumers, ” or consumers that do not process messages fast enough. While messages are waiting to be processed, they time out (see the Message Expiration pattern) and are sent to the Dead Letter Channel . The excessive number of expired market data messages in the dead letter queue is a clear indication that the message flow is too great – messages expire before the target application can consume them. We need to fix the message flow and we turn to patterns for help slowing down the message flow.
A reasonable first step is to explore solving this problem with the Aggregator as we recently used this pattern to solve the similar flashing market data control rate problem. The system design relies on the client application to immediately forward market data update messages to the trading venues. This means the system cannot wait to collect messages and aggregate them. So the Aggregator must be abandoned.
There are two other patterns that deal with the problem of consuming messages concurrently: Competing Consumers and Message Dispatcher . Starting with Competing Consumers , the benefit of this pattern is the parallel processing of incoming messages. This is accomplished using several consumers on the same channel. Only one consumer processes each incoming message leaving the others to process successive messages. Competing Consumers , however, will not work for us since we are using Publish-Subscribe Channel s in server-to-client communication. Competing Consumers on a Publish-Subscribe Channel channel means that all consumers process the same incoming message. This results in more work without any gain and completely misses the goal of the pattern. This approach also has to be abandoned.
On the other hand, the Message Dispatcher describes an approach whereby you add several consumers to a вЂ˜pool’. Each consumer can run its own execution thread. One main Message Consumer listens to the Channel and delegates the message on to an unoccupied Message Consumer in the pool and immediately returns to listening on the Message Channel . This achieves the parallel processing benefit of Competing Consumers , but works on Publish-Subscribe Channel s.
The Message Dispatcher in context.
Implementing this in our system is simple. We create a single JMSListener called the Dispatcher, which contains a collection of other JMSListener s called Performers. When the onMessage method of the Dispatcher is called, it in turn picks a Performer out of the collection to actually process the message. The result of which is a Message Listener (the Dispatcher) that always returns immediately. This guarantees a steady flow of message processing regardless of the message flow rate. Additionally, this works equally well on a Publish-Subscribe Channel s as it does on a Point-to-Point Channel s. With this infrastructure, messages can be received by the client application at almost any rate. If the client application is still slow to process the message after receiving them, the client application can deal with the delayed processing and potentially outdated market data rather than the messages expiring in the JMS Message Channel .
The crash discussed in this section and the fix using the Message Dispatcher is an excellent example of the limits of applying patterns. We encountered a performance problem based on a design flaw not allowing the client to process messages in parallel. This greatly improved the problem, but did not completely fix it. This is because the real problem was the client becoming a bottleneck. This couldn’t be fixed with a thousand patterns. We later addressed this problem by refactoring the message flow architecture to route messages directly from the Pricing Gateway to the Contribution Gateway. So patterns can help design and maintain a system, but don’t necessarily make up for poor upfront design.
Throughout this chapter, we have applied patterns to several different aspects of a bond trading system including solving initial upfront design problems and fixing a nearly job threatening production crash with patterns. We also saw these patterns as they already exist in third party product, legacy components, and our JMS and TIBCO messaging systems. Most importantly, these are real problems with the same types of architectural, technical and business problems we experience as we design and maintain our own systems. Hopefully reading about applying patterns to this system helps give you a better understanding of the patterns as well as how to apply them to your own systems.
Gregor Hohpe and Bobby Woolf.
From Enterprise Integration to Enterprise Transformation:
My new book describes how architects can play a critical role in IT transformation by applying their technical, communication, and organizational skills with 37 episodes from large-scale enterprise IT.

Bond trading system

이자율 선물이 무너질 것입니다!
에서 구입할 수 있습니다.
JB BONDBUSTER 무역 시스템.
우리가 기대하는 것에 관해 이야기하는 것이 우리에게는 하나의 일이지만 사전에 잘 준비하는 것이 훨씬 더 중요합니다. 그러나 우리는 어떻게 준비 할 수 있습니까? 의견은 저렴합니다. 당신이 말하는 사람이나 듣는 사람에 따라 우리는 깊은 우울증, 약간의 경기 침체, 인플레이션, 초 인플레이션, 침체 또는 지금까지 알려지지 않은 경제 상황에 빠지려하고 있습니다.
10 일 안에 나는 금리 선물을위한 나의 가장 좋은 거래 시스템이라고 믿는 것들을 공개 할 것입니다. 시스템의 세부 사항 중 일부는 아래에 설명되어 있습니다.
30 년 Tbond, 10 년,
5 년 및 2 년 TNote 선물.
저의 새로운 JB Bond Buster 거래 시스템은 Genesis Gold 또는 Platinum 소프트웨어에서 운영됩니다. 시장 종결 후 매일, 금리 선물의 광범위한 스펙트럼에 걸쳐 단기, 높은 확률, 100 % 객관적 및 규칙 기반 신호를 생성합니다. 이는 전례없는 기회와 다양한 도구 간의 관계를 창출 할 수있는 수율 (이율 곡선)의 이상 현상으로 인해 매우 중요합니다. Â 제 JB 본드 버스터가 길고 하나의 금리 차량이면서 짧은 또 다른 것일 수도 있습니다. 따라서 수익률 곡선에서 선회를 활용하십시오.
나의 새로운 거래 시스템은 내가 발견 한 가장 신뢰할 수 있고, 일관되며, 정확한 가격 및 시간 패턴을 통합합니다! 새 시스템을 구축하는 데 사용한 개발 프로세스는 지나치게 최적화되지 않은 상태로 신중해야했으며 정확성을 검증하는 데 3 년이 넘는 샘플 데이터가 포함되어 있습니다. 요컨대, 새로운 시스템과 그 잠재력에 대해 매우 기쁘고 흥분됩니다. 나는 JB Bond Buster가 우리를 길 아래로 기다리고있는 피할 수없는 변동성을 통해 시장의 오른쪽에 당신을 유지할 수 있다고 믿습니다.
엄청나게 제한된 수량의 시스템.
나는 그 성능을 희석시키지 않기 위해서 단지 아주 한정된 양의 새로운 시스템을 사용할 수있게 할 것이다. 선착순으로 고객에게 시스템을 제공합니다. 고객은 할인 가격을받을 자격이 있습니다. 그리고 나는 가격을 낮게 유지하고 2fer 카드 가격 (50 % 할인)을받을 자격이 있습니다.
JB BondBuster 시스템에 포함 된 것.
JB Bond Buster Genesis Platinum 및 Gold 용 바구니 및 시스템 비디오 설명서 전체 설치 지침 발행 된 경우 시스템 업데이트 개인적으로 제공되는 기술 지원 거래 규칙 완전 공개 JB Bond Buster 60 분 웹 세미나 100 % 객관적인 거래 및 신호 30 년 T - 채권, 10 년 T 메모, 5 년 T 메모 및 2 년 T 메모 규칙 및 절차 완전 개시 초기 중지 및 후행 중지 모든 거래는 처음부터 끝까지 추적됩니다.
Genesis를 사용하지 않습니까? 에 의해 매일 신호를 얻으십시오.
여러분 중 일부는 Genesis 거래 소프트웨어를 사용하지 않지만 내 시스템을 교환하고 싶습니다.
아래에서 볼 수 있듯이 수수료가 공제 된 금액은 각 금리 미래의 성과 내역입니다. 미래를 보장 할 수는 없지만 JB Bond Buster를 개발하는 데 사용 된 개념과 패턴이 계속해서 잘 수행되어 이러한 시장에서 다가올 엄청난 변동성을 활용할 수 있다고 믿습니다. 이상적으로, 역사적 기록을 복제하기 위해서는 네 가지 시장 모두에서 모든 신호를 취하는 것이 가장 좋습니다. 이 기록에는 이윤 극대화 전략이 표시되지 않습니다. 평균 무역 기간은 7 일입니다. В.
참고 : BondBuster Trading System은에서 구입할 수 있습니다.
당신 거래의 베스트,
아래에서 해당 링크를 선택하십시오.
또는 사무실에 전화하십시오 : Ph 831-430-0600, 800-678-5253.