채권 거래 시스템 아키텍처

채권 거래 시스템.
채권 거래 시스템의 작동 방식.
서비스 플랫폼.
전자 거래는 서비스간에 공유되는 데이터에 달려 있습니다. 성공적인 채권 매매 시스템을 구축하려면 데이터 공유 및 서비스 관리를 용이하게하는 서비스 플랫폼이 필수적입니다. 이 기사에서는 서비스 플랫폼의 핵심 기본 요구 사항과 그 이유를 설명합니다.
서비스 액세스 프로토콜.
서비스는 특정 비즈니스 프로세스를 지원하며 비즈니스 프로세스와 관련된 데이터 및 기능에 대한 액세스를 제공합니다. 일반적으로 서비스에서 생성 된 데이터는 원격 시스템의 여러 클라이언트가 액세스해야합니다. 클라이언트는 응용 프로그램 또는 기타 서비스 일 수 있습니다. 서비스는 액세스하는 클라이언트의 유형을 구별해서는 안됩니다. 모든 액세스는 동일한 방식으로 처리됩니다. 서비스가 데이터를 사용 가능하게 만들고 데이터의 형식을 서비스 액세스 프로토콜이라고합니다. 모든 서비스는 동일한 액세스 프로토콜을 사용해야 클라이언트가 동일한 프로토콜을 사용하는 모든 서비스에 연결할 수 있습니다. 일반적인 서비스 액세스 프로토콜은 서비스 플랫폼 개념의 백본입니다. 모든 서비스가 동일한 액세스 프로토콜을 지원하면 공통된 디자인을 공유하고 서비스 플랫폼의 기반을 형성합니다.
아래 다이어그램은 서비스 액세스 프로토콜의 구성 요소를 보여줍니다.
데이터 액세스 패턴.
서비스는 세 가지 패턴 중 하나를 사용하여 데이터에 대한 액세스를 제공합니다.
각각의 경우 데이터는 메시지 형식으로 게시됩니다. 일반적으로 데이터 엔터티에 업데이트가 발생하면 메시지가 게시됩니다. 세 가지 패턴 모두 실시간 데이터 액세스 패턴으로 간주 될 수 있습니다. 이 컨텍스트에서 실시간은 도입 된 지연없이 데이터 응답이 가능한 한 빨리 제공됨을 의미합니다. 서비스 액세스 프로토콜은 이러한 액세스 패턴을 지원해야합니다.
맹인 게시.
이것은 실제로 데이터에 관심이있는 클라이언트가 있는지 여부에 관계없이 서비스가 모든 클라이언트가 수신 할 수 있도록 데이터를 일방적으로 게시하는 패턴을 설명합니다. 블라인드 게시는 매우 비효율적 일 수 있습니다. 특히 데이터를 사용하는 클라이언트가 없으면 네트워크 대역폭이 메시지를 게시하기 때문에 매우 변동이 심한 데이터의 경우 특히 그렇습니다. 이 패턴을 사용하여 게시 된 데이터는 항상 모든 업데이트에 대한 완벽한 이미지입니다. 여러 클라이언트가 동일한 메시지를 수신 할 수 있습니다. 하트 비트 (온라인에 있음을 나타 내기 위해 서비스에 의해 게시 된 신호)는 맹검 게시 데이터 액세스 패턴의 한 예입니다.
구독 - 게시.
이 패턴을 사용하면 하나 이상의 클라이언트가 엔티티에 가입 한 경우에만 특정 엔티티에 대한 데이터를 게시하는 서비스가 필요합니다. 이를 위해서는 데이터가 각 엔티티에 대해 고유 한 ID 형식을 사용해야합니다. 서비스는 어떤 데이터 엔티티에 대해 클라이언트가 가입했는지 추적해야합니다. 심장 박동의 메카니즘은 서비스를 모니터하는 고객에게도 필요합니다. 서비스는 데이터 엔티티에 가입 한 클라이언트가 더 이상 없을 때 엔티티에 대한 데이터 게시를 중지합니다. 이는 클라이언트가 갑자기 데이터 엔티티의 구독을 중지하거나 구독 취소 요청을 보내는 경우에 발생할 수 있습니다. 심장 박동 메커니즘은 클라이언트가 예기치 않게 멈출 때를 감지하기 위해 서비스에서 사용됩니다. 클라이언트가 이런 식으로 데이터를 구독하면 일반적으로 서비스에있는 데이터 엔터티의 초기 버전을 기대할 수 있어야합니다. 이 초기 버전은 데이터의 현재 상태 또는 빈 칸입니다. 상태는 서비스에서 데이터를 사용할 수 없음을 나타낼 수 있습니다.
서비스가 게시 델타를 지원하면 구독시 이미지 기능이 필요합니다. 용어 '델타'(# 8217; 전체 이미지가 아닌 데이터의 변경 사항 만 게시하는 방법에 대해 설명합니다. 일반적으로 엔터티의 모든 특성이 항상 변경되는 것은 아니기 때문에 상당한 네트워크 대역폭 절감 효과를 얻을 수 있습니다. 구독 이미지 개념은 클라이언트가 첫 번째 업데이트로 데이터 엔티티의 초기 이미지를 수신 한 다음 델타 만 수신하는 것을 의미합니다. 델타는 초기 이미지의 맨 위에 적용되어 데이터 엔티티의 현재 상태를 분석 할 수 있습니다. 데이터 엔티티에 대해 게시 된 모든 메시지에는 일련 번호가 필요합니다. 이를 통해 클라이언트는 순서가 잘못된 메시지를 감지 할 수 있으며 수신 된 이미지 위에 델타를 적용 할 수있는 중요한 역할을합니다. 이미지 자체는 엔티티에 대한 델타 메시지 스트림 내에서 식별 될 수있는 시퀀스를 가져야합니다. 동일한 델타 메시지는 여러 클라이언트에서 수신 할 수 있습니다.
구독 - 게시 패턴은 서비스가 잠재적으로 대용량 데이터 유니버스를 가질 수 있고 어떤 시점에서 유니버스의 일부만 클라이언트에서 구독 할 것으로 예상 할 때 필수적입니다. 이렇게하면 네트워크 사용이보다 효율적으로되고 서비스가 리소스를 절약 할 수 있습니다.
요청 - 응답.
요청 - 응답 패턴은 클라이언트가 서비스에 전송 된 요청에 대한 응답을 수신 할 수있는 기능을 제공합니다. 일반적으로 서비스 응답은 요청한 클라이언트에만 전달됩니다. 다른 클라이언트는 응답 메시지를 보지 못합니다. 이 액세스 패턴은 일반적으로 클라이언트가 서비스에서 함수를 호출하는 데 사용됩니다. 요청 메시지는 함수에 대한 인수와 함께 호출 할 함수를 식별합니다. 서비스의 응답에는 함수를 호출 한 결과가 포함됩니다. 그러나이 액세스 패턴을 사용하여 이미지를 요청하거나 클라이언트의 요청에 따라 촬영 데이터를 수신 할 수도 있습니다.
이 패턴은 클라이언트에서 몇 가지 형태의 타임 아웃 로직을 필요로합니다. 클라이언트가 요청을 보내면 일반적으로 응답에 대한 카운트 다운이 시작됩니다. 응답이 카운트 다운 내에 도착하지 않으면 클라이언트는 요청이 실패했다고 판단합니다. 이것은 요청 타이밍을 처리하는 기본 f}입니다. 서비스가 메시지를받을 때 신호를 다시 보내고 메시지를 처리하기 시작할 때 또 다른 신호를 보낸 다음 마지막으로 응답을 보내도록 개선했습니다. 클라이언트가 요청 - 응답에서 이러한 각 단계에 대해 별도의 카운트 다운을 수행하면보다 세분화 된 제어가 가능하며 타임 아웃 상황을 조정할 수 있습니다. 예를 들어 서비스가 메시지를 처리하는 데 0.2 초가 걸리지 만 요청 수가 많기 때문에 각 요청에 처리가 시작되기까지 0.9 초가 걸리면 간단한 1 초 시간 제한을 가진 클라이언트가 각 요청을 실패하게됩니다 요청은 1.1 초 걸리는 것처럼 보입니다.) 그러나 클라이언트가 1 초의 시작 시간 초과 및 0.5 초의 처리 시간 초과를 관찰하면 요청은 성공합니다.
데이터 형식.
서비스 액세스 프로토콜은 데이터의 형식, 형식을 정의합니다. 연결하는 모든 클라이언트가 데이터를 보편적으로 이해할 수 있도록하는 것이 매우 중요합니다. 데이터 형식 간 변환은 개발 및 유지 관리 시간 및 런타임 처리 리소스 측면에서 많은 비용이 듭니다. 따라서 모든 서비스에 대한 중요한 측면은 공통 데이터 형식을 갖는 것입니다.
데이터 형식은 데이터 구조화 방법 및 데이터 값 형식에 대한 규칙을 정의합니다. 구조는 데이터가 나타내는 것을 이해하는 방법을 정의합니다. 구조가 이해된다면, 데이터 값은 정확한 문맥으로 해석 될 수있다. 구조가 이해 되었기 때문에 123.45라는 값은 입찰 가격이 아니라 입찰 가격으로 정확하게 해석 될 수 있습니다. 일반적으로 데이터 구조는 다음 범주 중 하나로 분류됩니다.
사전 & # 8211; 이것은 모든 데이터 값이 고유 한 키로 식별되는 키 - 값 구조입니다. 이러한 유형의 구조는 스파 스 데이터를 읽고 쓰는 데 매우 빠릅니다. 구조가 사전 기반 인 경우 데이터 변경 (델타)을 보내는 것이 가장 효율적입니다. 계층 구조 & # 8211; 데이터는 계층 적 방식으로 표현된다. XML. 일반적으로 매우 장황합니다. hierachy 기반의 데이터 구조는 사전 기반의 데이터 구조를 처리하기가 더 복잡하고 사전 기반의 등가물만큼 빠르지 않습니다.
사전 기반 구조가 키 내에서 계층 구조를 사용하여 중층 솔루션을 구현하는 하이브리드 범주가 있습니다. 예를 들어 키는 & # 8220;입니다. & # 8221; & # 8220; foo. bar.1 & # 8221; & # 8220; foo. bar.2 & # 8221;과 같은 주소 공간을 제공하도록 분리되었습니다.
데이터 구조에 관계없이 데이터 값이 표현할 수있는 유형의 정의 된 범위가 있어야합니다. 유형을 사용하면 데이터를 올바른 형식으로 해석 할 수 있습니다 (예 : 문자열 또는 숫자 또는 이진 스트림. 지원해야하는 기본 데이터 유형은 다음과 같습니다.
텍스트 부동 소수점 정수 이진 스트림 이미지 (얼룩)
이 4 가지 데이터 유형을 지원하면 실제 데이터 값을 정확하게 나타낼 수 있습니다.
서비스 플랫폼 기능.
서비스에 대한 데이터 액세스 프로토콜은 일부 형식의 메시징 기술에서 지원됩니다. 그러나 메시징 기술은 배관을 해결할뿐입니다. 한 엔드 포인트에서 다른 엔드 포인트로 데이터를 얻는 방법의 문제점. 채권 매매를위한 서비스 인프라는 공통 서비스 액세스 프로토콜을위한 메시징 기술 그 이상을 필요로하며 다음과 같은 기능도 필요합니다.
서비스 발견 및 모니터링 & # 8211; 비즈니스 서비스의 가용성에 따라 기능을 제어 할 수 있습니다. 서비스에서 사용할 수있는 데이터를 찾습니다. & # 8211; 특정 데이터가 준비되었을 때 기능이 반응하도록합니다. 클라이언트가 데이터를 구독 할 때 검색합니다. & # 8211; (예 : 클라이언트가 피드 구독을 시작할 때만 데이터 피드 시작) 서비스 상태 검사 & # 8211; 고객 구독을 지원해야하는 경우에만 리소스를 활성화 할 수 있습니다. 지원 팀이 서비스가 곤란한 때를 알 수 있고 서비스에서 데이터보기를 고치는 조치를 취할 수 있습니다. & # 8211; 지원 팀은 데이터의 소스 권한 부여시 데이터를 확인하여 데이터 문제를 진단 할 수 있습니다. 승인되지 않은 고객이 데이터 게시 속도 (조절)를 제어하는 ​​데이터를받지 못하도록하여 데이터 보안 / 요금 요구 사항을 지원합니다. 클라이언트 및 하드웨어 리소스에 과부하가 걸릴 수있는 높은 게시 속도에서 환경을 보호하여 서비스를 원격 제어합니다. 서비스의 서비스 고 가용성을 중단하지 않고도 서비스 상태 및 설정을 변경할 수있는 기능을 제공합니다. 예기치 않게 중지되는 서비스를 백업 서비스로 대체합니다.
이러한 모든 기능은 모든 서비스가 구축되는 공통 프레임 워크에 의해 제공되어야합니다. 이 공통 프레임 워크는 서비스 플랫폼입니다. 이러한 기능을 갖춘 프레임 워크를 설계하고 동일한 메시징 기술을 사용하는 서비스 및 클라이언트를 지원함으로써 채권 거래를 위해 강력하고 확장 가능한 기술 솔루션 플랫폼을 제공합니다.
왜 서비스 플랫폼을 사용해야합니까?
위에서 나열한 모든 기능을 서비스 플랫폼을 사용하지 않아도 가능하지만 기능은 기존 디자인에 역으로 적용되는 경향이 있으며 때로는 특정 서비스에만 적용되는 경우가 있고 다른 서비스에서 동일한 기능에 대해 다른 기술이 사용되는 경우가 있습니다 . 궁극적으로 서비스 플랫폼의 핵심 기능을 제공 할 수 있지만 통합 아키텍처를 희생하고 유지 관리 비용을 증가시키는 서비스 디자인은 궁극적으로 서비스 플랫폼의 핵심 기능을 제공 할 수있는 다양한 디자인 및 기술의 이기종 믹스 앤 매치가됩니다. 채권 거래 시스템을 구축하기 위해 서비스 플랫폼을 사용하면 개발 및 유지 보수 비용과 시간을 줄일 수 있습니다. 개발은 인프라 문제보다는 서비스 / 클라이언트의 비즈니스 논리에 집중할 수 있습니다.
아래 다이어그램은 서비스 플랫폼 아키텍처를 사용하여 서비스에 대한 액세스를 단순화하는 방법을 보여줍니다. 서비스 플랫폼의 경우 클라이언트는 모든 서비스에 액세스하기 위해 단일 인터페이스 만 필요로하는 반면 비 서비스 플랫폼 설계는 클라이언트가 액세스되는 서비스에 따라 다른 인터페이스를 사용해야합니다. 일반적으로 인터페이스는 개발 및 유지 보수에 필요한 리소스를 증가시키는 여러 기술을 사용하기 때문에 서비스 당 개별 인터페이스가 복잡합니다.
서비스 플랫폼은 채권 매매 시스템의 사용자 인터페이스 디자인에도 도움이됩니다. 사용자 인터페이스 (UI)는 일반적으로 다양한 서비스에 대한 다양한 시각적 디스플레이 및 컨트롤을 그룹화 한 것입니다. 모든 서비스가 동일한 메시징 기술 및 데이터 구조를 공유하면 UI 구성 요소가 모든 서비스에서 표준이됩니다. 기술보다는 순수한 비즈니스 목적으로 만 존재하는 특수화 된 버전을 만들 수 있으며 궁극적으로 모든 구성 요소는 비즈니스 서비스에 공통적 인 인터페이스 패턴을 공유합니다.
닫는 중 & # 8230;
이 기사에서는 서비스 플랫폼의 개념을 소개하고 아키텍처의 중요성을 강조했습니다. 서비스 플랫폼을 구축하는 것은 쉬운 일이 아닙니다. 상업적으로 이용 가능한 옵션은 거의없고 오픈 소스 제품도 적습니다. ClearConnect 플랫폼은이 기사에 설명 된 모든 기능을 제공하는 오픈 소스 예제입니다. 이 플랫폼은 추후 기사에서 서비스의 예를 만들기위한 참조 플랫폼으로 사용될 것입니다.

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

거래 시스템 : 시스템 설계 - 제 1 부.
이 튜토리얼의 이전 섹션에서는 거래 시스템을 구성하는 요소를 살펴보고 실시간 거래 환경에서 이러한 시스템을 사용하는 데 따른 장단점에 대해 설명했습니다. 이 섹션에서는 시스템 트레이딩에 특히 적합한 시장을 조사하여 그 지식을 기반으로합니다. 그런 다음 다양한 장르의 거래 시스템을보다 심층적으로 살펴 보겠습니다.
주식 시장은 아마도 초보자들 사이에서 거래되는 가장 일반적인 시장 일 것입니다. 이 분야에서 워렌 버핏 (Warren Buffett)과 메릴린치 (Merrill Lynch)와 같은 거물급 기업이 우세하고 전통적인 가치 및 성장 투자 전략이 가장 보편적입니다. 그럼에도 불구하고 많은 기관들이 거래 시스템의 설계, 개발 및 구현에 상당한 투자를 해왔습니다. 개인 투자자들은 천천히이 경향에 동참하고 있습니다.
대량의 주식을 사용하면 거래자는 매우 다양한 휘발성 장외 주식 (OTC)에서 비 휘발성 파란색 칩에 이르기까지 다양한 유형의 주식에 대해 시스템을 테스트 할 수 있습니다.
거래 시스템의 효과는 일부 주식, 특히 장외 시장 및 분홍색 시트 문제의 유동성 부족으로 제한 될 수 있습니다.
커미션은 성공적인 거래로 인해 이익을 얻을 수 있으며 손실을 증가시킬 수 있습니다. OTC와 핑크 시트 주식은 추가 수수료를 부과하기도합니다.
사용되는 주요 거래 시스템은 가치를 추구하는 시스템입니다. 즉, 보안이 과거 성과, 동급 업체 또는 시장 전반에 비해 저평가되어 있는지를 결정하기 위해 다양한 매개 변수를 사용하는 시스템입니다.
외환 시장 또는 외환 시장은 세계에서 가장 크고 가장 유동적 인 시장입니다. 세계의 정부, 은행 및 기타 대형 기관들은 매일 외환 시장에서 수조 달러를 거래합니다. forex에 기관 무역상의 대다수는 무역 체계에 의지합니다. 외환 거래를하는 개인에게도 동일하지만 경제 보고서 나이자 지불금을 기반으로하는 일부 거래가 있습니다.
이 시장의 유동성은 대량으로 인해 거래 시스템을보다 정확하고 효율적으로 만듭니다.
이 시장에는 커미션이없고 퍼짐 만 있습니다. 따라서 비용을 늘리지 않고도 많은 거래를하는 것이 훨씬 쉽습니다.
이용할 수있는 주식이나 상품의 양과 비교할 때, 거래 할 통화의 수는 제한되어 있습니다. 그러나 소액 국가의 통화 인 '이국적인 통화 쌍'의 가용성으로 인해 변동성의 범위가 반드시 제한되는 것은 아닙니다.
forex에서 사용 된 주요 거래 시스템은 트렌드를 따르는 시스템 (시장에서 인기있는 트렌드는 "트렌드는 당신의 친구"입니다) 또는 브레이크 아웃에서 구매하거나 판매하는 시스템입니다. 이는 경제 지표가 종종 한 번에 큰 물가 움직임을 유발하기 때문입니다.
주식, 외환 및 상품 시장은 모두 선물 거래를 제공합니다. 이 레버리지는 시스템 트레이딩에 널리 사용되는 수단으로 이용 가능한 레버리지가 많아지고 유동성과 변동성이 증가합니다. 그러나 이러한 요소는 두 가지 방법을 모두 줄일 수 있습니다. 이득을 증폭 시키거나 손실을 증폭시킬 수 있습니다. 이러한 이유로 선물의 사용은 일반적으로 고급 개인 및 기관 시스템 거래자를 위해 예약되어 있습니다. 이는 선물 시장을 자본화 할 수있는 트레이딩 시스템이 훨씬 더 많은 커스터마이징을 필요로하기 때문에보다 발전된 지표를 사용하고 개발하는데 더 오래 걸리기 때문입니다.
어떤 시장이 시스템 트레이딩에 가장 적합한 지 결정하는 것은 개인 투자자에게 달려 있습니다. 각 시장은 각각 장단점이 있습니다. 대부분의 사람들은 주식 시장에 대해 더 잘 알고 있으며 이러한 친숙 함으로 인해 거래 시스템을보다 쉽게 ​​개발할 수 있습니다. 그러나 외환은 흔히 경험이 풍부한 거래자들 사이에서 거래 시스템을 운영하기위한 우수한 플랫폼으로 여겨지고 있습니다. 더욱이, 상인이 레버리지와 변동성을 증가 시키기로 결정하면 선물 대안은 항상 열려 있습니다. 궁극적으로 선택은 시스템 개발자의 손에 달려 있습니다.
시스템 트레이딩의 가장 일반적인 방법은 경향 추종 시스템입니다. 가장 근본적인 형태로, 이 시스템은 중요한 가격 움직임을 단순히 기다린 다음 그 방향으로 구매하거나 판매합니다. 이러한 유형의 시스템은 이러한 가격 변동이 추세를 유지할 수 있기를 희망합니다.
이동 평균 시스템.
기술적 분석에서 자주 사용되는 이동 평균은 일정 기간 동안 주식의 평균 가격을 단순히 표시하는 지표입니다. 경향의 본질은이 측정에서 파생됩니다. 진입과 퇴출을 결정하는 가장 일반적인 방법은 크로스 오버입니다. 이러한 논리는 간단합니다. 가격이 과거 가격 평균 (추세)보다 높거나 낮을 경우 새로운 추세가 형성됩니다. 다음은 IBM의 가격 (청색 선)과 20 일 MA (적색 선)를 나타내는 차트입니다.
이러한 유형의 시스템의 기본 개념은 이동 평균 시스템의 개념과 유사합니다. 새로운 최고점 또는 최저점이 설정되면 가격 움직임이 가장 큰 방향으로 이어질 가능성이 높습니다. 브레이크 아웃을 결정하는 데 사용할 수있는 한 가지 지표는 간단한 Bollinger Band & reg입니다. 위에 까는 것. Bollinger Bands & reg; 가격이 고가와 저가의 평균을 보여주고, 가격이 밴드의 가장자리를 만났을 때 브레이크 아웃이 발생합니다. 다음은 가격 (파란색 선)과 Bollinger Bands & reg를 그려주는 차트입니다. (회색 선) Microsoft의 :
Trend-Following 시스템의 단점 :
경험적 의사 결정 필요 - 추세를 결정할 때 항상 고려해야 할 경험 요소가 있습니다 : 역사적 추세의 지속 시간. 예를 들어, 이동 평균은 지난 20 일 동안 또는 지난 5 년 동안이 될 수 있으므로 개발자는 어떤 시스템이 시스템에 가장 적합한 지 결정해야합니다. 결정할 다른 요인은 브레이크 아웃 시스템의 평균 최고 및 최저입니다.
느린 자연 - 이동 평균 및 브레이크 아웃 시스템은 항상 뒤떨어져 있습니다. 다른 말로하면, 그들은 트렌드의 정확한 상단이나 하단을 결코 칠 수 없습니다. 이것은 필연적으로 잠재적 이익의 몰수를 가져 오며 때로는 중요 할 수 있습니다.
Whipsaw Effect - 경향 추종 시스템의 성공에 해로운 시장 세력 중 가장 일반적인 현상 중 하나입니다. Whipsaw 효과는 이동 평균이 거짓 신호를 생성 할 때 발생합니다. 즉 평균이 범위로 떨어지면 방향이 갑자기 바뀝니다. 효과적인 정지 손실 및 위험 관리 기술이 적용되지 않는 한 막대한 손실을 초래할 수 있습니다.
측면 시장 - 추세 추적 시스템은 본질적으로 실제로 경향을 보이는 시장에서만 수익을 창출 할 수 있습니다. 그러나 시장 또한 오랜 기간 동안 특정 범위 내에 머무르면서 옆으로 움직입니다.
극단적 인 변동성이 발생할 수 있음 - 때로는 추세를 따르는 시스템이 극단적 인 변동성을 겪을 수 있지만 상인은 자신의 시스템을 고수해야합니다. 그렇게 할 수 없다는 것은 확실한 실패를 초래할 것입니다.
기본적으로 카운터 트렌드 시스템의 목표는 최저 최저 가격으로 구매하고 최고 최고 가격으로 판매하는 것입니다. 이 추세 추종 시스템과의 주요 차이점은 추돌 시스템이 자체 수정이 아니라는 점입니다. 즉, 포지션을 종료 할 정해진 시간이 없기 때문에 무제한적인 잠재력을 갖게됩니다.
카운터 트렌드 시스템의 유형.
많은 종류의 시스템이 카운터 트렌드 시스템으로 간주됩니다. 한 방향의 운동량이 퇴색하기 시작하면 구매하는 것이 좋습니다. 이것은 오실레이터를 사용하여 가장 자주 계산됩니다. 예를 들어, stochastics 또는 다른 상대 강도 표시기가 특정 지점 아래로 떨어지면 신호가 생성 될 수 있습니다. 카운터 트레드 트레이딩 시스템에는 다른 유형이 있지만, 모두가 낮은 구매와 높은 매도와 같은 기본적 목표를 공유합니다.
예를 들어, 시스템 개발자가 결정해야하는 요소 중 하나는 상대 강도 지표가 희미 해지는 지점입니다.
극단적 인 변동성이 발생할 수 있음 - 이러한 시스템은 극단적 인 변동성을 경험할 수 있으며 이러한 변동성에도 불구하고 시스템을 고수 할 수 없으면 실패가 발생할 수 있습니다.
무제한 단점 - 앞서 언급했듯이 시스템이 자체 수정 기능이 없으므로 무제한적인 잠재력이 있습니다 (위치를 종료 할 시간이 없음).
거래 시스템이 적합한 주요 시장은 주식, 외환 및 선물 시장입니다. 각 시장에는 장점과 단점이 있습니다. 트레이딩 시스템의 두 가지 주요 장르는 트렌드 추종 시스템과 카운터 트렌드 시스템입니다. 이들의 차이점에도 불구하고 개발 단계에서 두 유형의 시스템 모두 개발자 측에서 경험적 의사 결정을 필요로합니다. 또한 이러한 시스템은 극심한 변동성을 겪기 때문에 일부 체력을 요구할 수 있습니다. 시스템 트레이더는이 시간 동안 자신의 시스템을 고수하는 것이 필수적입니다. 다음 연재에서는 거래 시스템을 설계하고 시스템 트레이더가 자신의 삶을 편하게하기 위해 사용하는 소프트웨어에 대해 논의하는 방법에 대해 자세히 살펴볼 것입니다.

채권 매매 시스템 아키텍처
(조나단 사이먼)
대규모 패턴 모음이나 패턴 언어에서 벗어나기 쉽습니다. 패턴은 아이디어를 재사용 가능한 형태로 추상화 한 것입니다. 흔히 패턴을 매우 유용하게 만드는 매우 일반적인 패턴은 이해하기 어렵게 만듭니다. 때때로 패턴을 이해하는 데 도움이되는 가장 좋은 방법은 실생활의 예입니다. 일어날 수있는 일에 대한 인위적 시나리오가 아닙니다. 그러나 실제로 일어나는 것과 일어날 일은 무엇인가.
이 장에서는 발견 프로세스를 사용하여 문제점을 해결하는 패턴을 적용합니다. 우리가 논의 할 시스템은 초기 설계부터 생산까지 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 look at the four integration styles suggested in this book: File Transfer , Shared Database , Remote Procedure Invocation , and Messaging . We can rule out Shared Database immediately because we wanted to create a layer of abstraction between the client and the database and don’t want to have database access code in the client. File Transfer can similarly be ruled out since minimal latency is required to ensure current prices are sent out to the trading venues. This leaves us with a choice between Remote Procedure Invocation or Messaging .
The Java platform provides built-in support for both Remote Procedure Invocation and Messaging . RPC-style integration can be achieved using Remote Method Invocation (RMI), CORBA, or Enterprise Java Beans (EJB). The Java Messaging Service (JMS) is the common API for messaging-style integration. So both integration styles are easy to implement in Java.
So which will work better for this project, Remote Procedure Invocation or Messaging ? There’s only one instance of the Pricing Gateway and one instance of the Contribution Gateway in the system, but usually many Thick Clients simultaneously connect to these services (one for each bond trader that happens to be logged in at a particular time). Furthermore, the bank would like this to be a generic pricing system that can be utilized in other applications. So besides an unknown number of Think Clients, there may be an unknown number of other applications using the pricing data coming out of the Gateways.
A Thick Client (or other application using the pricing data) can fairly easily use RPC to make calls to the Gateways to get pricing data and invoke processing. However, pricing data will constantly be published, and certain clients are only interested in certain data, so getting the relevant data to the proper clients in a timely manner could be difficult. The clients could poll the Gateways, but that will create a lot of overhead. It would be better for the Gateways to make the data available to the clients as soon as it is available. This, however, will require each Gateway to keep track of which clients are currently active, and which want what particular data; then, when a new piece of data becomes available (which will happen numerous times per second), the Gateway will have to make an RPC to each interested client to pass the data to the client. Ideally, all clients should be notified simultaneously, so each RPC needs to be made in its own concurrent thread. This can work, but is getting very complicated very fast.
Messaging greatly simplifies this problem. With Messaging , we can define separate channels for the different types of pricing data. Then, when a Gateway gets a new piece of data, it will add a message containing that data to the Publish-Subscribe Channel for that data type. Meanwhile, all clients interested in a certain type of data will listen on the channel for that type. In this way, the Gateways can easily send out new data to whomever is interested, without needing to know how many listener applications there are or what they are.
The clients still need to be able to invoke behavior in the Gateways as well. Since there are ever only two Gateways, and the client can probably block while the method is invoked synchronously, these client-to-Gateway invocations can fairly easily be implemented using RPC. However, since we are already using messaging for Gateway-to-client communication, messages are probably just as good a way to implement client-to-Gateway communication as well.
Therefore, all communication between the Gateways and the clients will be accomplished through messaging. Because all of the components are written in Java, JMS presents an easy choice for as the messaging system. This is effectively creating a Message Bus or an architecture that will make it possible for future systems to integrate with the current system with little or no changes to the messaging infrastructure. 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.