본 발명의 실시 형태에 대해서, 도면을 이용하여 설명한다. 본 실시 형태는, 증권(주식)의 거래를 예로 설명하지만, 본 발명은 이것에 한정되는 것은 아니다.
우선, 도 6을 이용하여 본 실시 형태의 기본적인 내용에 대해서 설명한다. 도 6에 도시한 바와 같이 트랜잭션을, 서브 업무 단위로 분할하고, 이것을 도 6 하방에 도시한 바와 같이, 파이프라인 처리와 같은(의사적인) 병행 처리를 실현한다. 또한, 각 서브 업무에 관해서는, 도 6 상방에 도시된 것이, 그 일례이다.
다음으로, 도 12∼도 14를 이용하여, 본 실시 형태의 개요(사고 방식)에 대해서 설명한다. 본 실시 형태의 처리의 전제로서, 이하의 항목이 있다. 거래는 종목마다 순서성을 보증할 필요, 주문 접수나 접수/약정 통지는 단말기마다 관리할 필요. 이는, 도 12에 도시한 바와 같음. 상기 요건으로부터, 도 13과 같이 각 처리의 처리 단위로 하기로 하였다.
또한, 상기 사고 방식에서, 프로세스 대기가 발생하는 요인에 대해서는 이하가 있다고 생각하고 있다. 처리 단위가 상이한 처리 간(예:주문 접수∼거래 처리 제어 1 등). 다음으로, 도 13을 이용하여, 처리 단위가 상이한 처리 간에서의 대기의 사고 방식을 설명한다. 처리 단위가 상이한 처리로서, 예로서 주문 접수로부터 거래 처리 제어 1을 들어, 설명한다. 주문 접수 처리는 단말기 단위, 거래 처리 제어 1은 종목 단위의 처리일 필요가 있기 때문에, 이하의 처리 내용을 생각하였다.
주문 접수:복수의 프로세스가 동시에 동일 단말기로부터의 처리를 하는 경우가 없도록, 그 단말기가 주문 접수 중인지를 체크한다.
각 단말기 그룹마다의 프로세스 수(처리 다중도)를 설정 가능으로 한다.
거래 처리 제어 1:종목 그룹마다의 프로세스 수를 1로 하고, 종목 그룹마다 시리얼 처리를 행한다.
이 제어에 의해, 주문 접수는 단말기마다, 거래 처리 제어 1은 종목마다 순서성을 보증하고 있다.
도 13과 같이, 주문 접수와 거래 처리 제어 1은 각각 단말기, 종목과 처리 단위가 상이하다. 따라서, 이하의 경우에 대기가 발생하게 된다.
도 14에 도시한 바와 같이, 단말기 A와 단말기 B로부터, 동일 종목 C(종목 그룹 1)에 대하여 주문을 행한 경우를 생각한다. 거래 처리 제어 1은 종목마다 시리얼 처리할 필요가 있기 때문에, 예를 들면, 거래 처리 제어 1에 대하여, 단말기 A의 주문이 빨리 도착하고, 단말기 B의 주문이 나중에 도착한 경우, 단말기 A로부터의 주문의 거래 처리 제어 1이 종료할 때까지, 단말기 B로부터의 주문의 처리는 기다리게 된다. 이와 같이 거래 처리 제어 1의 MQ로부터의 취출 시에 대기가 발생한다.
상기 대기 시간은, 단말기로부터의 주문의 도착이 푸아송 분포에 따르는 것으로 하고, 거래 처리 제어 1의 처리 시간, 프로세스 이용률, 및 창구수(상기 예에서는 1)로부터, 대기 행렬 이론을 이용하여 산출한다. 리스판스 시간 산출 시에는 이 대기 시간을 고려하여, 평가하고 있다. 이 내용에 관해서는, 도 8∼도 11을 이 용하여 제2 실시 형태로서 설명한다.
다음으로, 본 실시 형태에서의 시스템 구성도를 도 1에 도시한다. 각 컴퓨터는, 네트워크를 통하여 상호 접속되어 있다. 또한, 각 컴퓨터는, 메모리, 하드디스크를 포함하는 기억 장치, CPU 등의 처리 장치를 갖고, 기억 장치에 저장된 프로그램에 따라서, 처리 장치가 정보 처리를 실행하는 것이다. 도 1에 도시한 바와 같이, 본 실시 형태에서의 시스템은, 거래 단말기(1), 접수 장치(2), 거래 처리 장치(3), 약정 처리 장치(4)와, 거래에 관한 정보가 저장된 기억 장치군(5)으로 구성된다. 이들 구성 요건의 각각은, 복수로 구성되는 것이지만, (1) 거래 단말기(1)는 그룹으로서 복수의 거래 단말기를 통합하여 두어도 되고, (2) 또한, 접수 장치(2), 거래 처리 장치(3), 약정 처리 장치(4)는, 하드웨어로서 일체의 서버 장치로서 구성되고, 각각은 그 기능을 갖는 소프트웨어로서 구성하여도 된다. 또한, (2)의 경우, 접수 장치(2), 거래 처리 장치(3)를 일체, 거래 처리 장치(3), 약정 처리 장치(4)를 일체 등으로 하여도 된다. 본 실시 형태에서는, 도 2에 도시한 바와 같이 약정 처리 장치(4)와 거래 처리 장치(3)를 일체로 한 예로 설명한다. 이 도 1, 도 2의 구성에서는, 각 접수 장치(2(21,22))는, 거래 단말기의 그룹마다(증권 회사 등) 대응지어져 있다. 또한, 각 거래 처리 장치(3), 각 약정 처리 장치(4)(혹은 이들이 일체화된 처리 장치(31, 32))는, 처리할 종목마다 대응지어져 있고, 이 대응 관계의 거래 요구에 관한 처리를 실행한다. 이 대응 관계는, 장치 즉 하드웨어가 아니라, 소프트웨어가 갖도록 하여도 된다. 또한, 이 대응 관계는, 거래량 등의 조건에 기초하여 동적으로 변경하여도 된다. 즉, 임의의 그룹으로부 터의 거래 요구나 임의의 종목의 거래 요구가(증가하여) 소정 수(양)로 된 경우, 소정의 장치(예를 들면, 거래 요구가 가장 적은 동일한 종류의 장치, 컴퓨터 자원)를 그 그룹(혹은 종목)의 처리를 실행하도록 하여도 된다. 또한, 동일한 종류의 장치에서, 거래 요구(혹은 그것에 수반하는 계산량)의 관계가 일정한 관계(차분이 임계값 이상이나 1:10 등의 소정의 관계)를 충족시키는지를 검지하여, 이 내용에 따라서 대응 관계를 변경하는(적은 거래 요구의 장치를 많은 거래 요구의 장치로 바꾸는) 것도, 본 실시 형태에 포함된다.
이하, 본 실시 형태의 처리 내용에 대해서, 설명한다.
우선, 도 3을 이용하여, 본 실시 형태의 기본 처리를 설명한다. 스텝 101에서, 접수 장치(21, 22)가 대응하는 거래 장치로부터 주문 접수 처리를 한다. 여기 서는, 거래 장치로부터 지정 종목, 매매별, 희망 금액, 주수, 요구자(거래 단말기(그룹))를 식별하는 정보를 포함하는 거래 요구를, 접수 장치(21)가 수신한다. 대응하는 거래 요구를 수신하기 위해서, 도시한 바와 같이 물리적으로 상호 대응하는 거래 단말기(그룹)를 접속하여도 되고, 거래 단말기로부터 대응하는 접수 장치를 특정하여, 특정된 접수 장치 앞으로, 거래 요구를 송신하도록 하여도 된다. 또한, 접수 장치측에서, 대응하는 거래 단말기(그룹)만을 수신하도록 필터링 처리를 실시하여도 된다.
그리고, 동일한 스텝 101에서, 입력 전문 즉 거래 요구의 체크를 행한다. 이 체크는, 통신 경로 상에서의 장애 발생 상황에 의해, 정상적으로 수신할 수 있었는지를 판단하는 것이다.
또한, 접수 장치(2)는, 스텝 101에서, 이하의 처리를 행하는 것도 본 실시 형태에 포함된다. 우선, 전제로서 거래 요구에 포함되는 요구자를 식별하는 정보는, 거래 단말기를 특정하는 정보이다. 여기서, 접수 장치(2)는, 이 정보를 키에 대응하는 단말기 그룹을 특정하는 정보를 단말기-단말기 그룹 특정 테이블로부터 검색한다. 그리고, 검색된 정보를 거래 요구에 포함시켜, 그 후의 처리를 실행한다. 또한, 각 거래 장치 중 어느 하나에서, 지정 종목을 키로, 도 7에 도시한 종목-종목 그룹 특정 테이블로부터 종목 그룹을 특정하는 정보를 검색하고, 거래 요구에 검색된 정보를 포함시키는 것도 본 실시 형태에 포함된다. 또한, 이와 같이 하여 새롭게 추가된 정보는, 각 처리 등에서 그룹(혹은 종목, 단말기)을 특정할 때에 사용된다.
그리고, 스텝 102로 진행하고, 접수 장치의 각각은 스텝 101의 체크 결과를, 거래 요구를 송신한 거래 단말기에 송신한다. 정상적으로 수신할 수 있었다고 판단한 경우에는, 정상 접수 응답을 거래 단말기에 송신한다. 그리고, 수신한 거래 요구를 요건 DB(51)에 저장한다. 이 경우, 각 거래 요구에 거래 상황을 대응지어서 기억해 둔다. 여기서, 「접수」를 나타내는 정보를 기억해 둔다. 또한, 거래 요구에 포함되는 「거래 종목」마다 대응하는 요건 DB에 저장하여도 된다. 예를 들면, 「a」 종목의 거래 요구는 요건 DB(51-a)에 저장된다. 또한, 요건 DB는, 기억 장치군(51)에 저장되어 있다. 또한, 각 요건 DB(51(51-a, 51-b))는 물리적으로 동일한 매체에 저장하여도 된다.
다음으로, 스텝 103에서, 거래 장치(31, 32)의 각각은(거래 처리 프로그램을 이용하여), 요건 DB(51)로부터 거래 상황이 「접수」이고, 자신에 대응하는 「종목」의 거래 요구를 추출한다. 이 추출은, 접수 장치측이, 요건 DB(51)에의 등록에 더불어서(포함하는 동일 종목이 일정 수 이상 등록한 경우), 「거래 종목」마다 대응하는 처리 장치(31, 32)에 전송 큐 송신함으로써 실현하여도 된다. 또한, 처리 장치(31, 32)가 일정 시간마다를 포함하는 소정 타이밍으로 자신에 대응하는 요건 DB(51)에 대하여 「접수」의 거래 요구가 없는지 검색하여 행해도 되고, 접수 장치로부터 등록한 것을 나타내는 정보를 수신하는 것을 트리거로 요건 DB를 검색하여도 된다. 또한, 이 트리거는, 동일 「종목」의 거래 요구가 일정 수 이상으로 된 것을 검지하여, 실행하여도 된다. 또한, 요건 DB에의 등록은 「종목」마다의 요건 DB에 등록하여도 된다(이하 마찬가지).
그리고, 추출한 거래 요구를 소위 판에 올리는, 처리를 실행한다. 즉, 거래 가능한 상태로 천이시킨다. 이 처리의 상세에 대해서는, 도 4, 도 5를 이용하여 후술한다. 이 처리를 실행한 경우, 요건 DB 거래 상황을 「접수」로부터 「거래」로 변경하도록 등록한다.
다음으로, 스텝 104에서, 거래 장치(31, 32)의 각각은, 거래 요구를 식별하는 주문 접수 번호를 부가하여, 요건 DB에 저장한다. 그리고, 이 등록 혹은 시간, 등록의 수 등을 트리거로, 각 접수 장치는, 요건 DB로부터 자신에 대응하는 「거래 단말기(그룹)」로서 「거래」의 거래 요구에 대해서, 그 거래 요구를 송신한 거래 단말기에 이 주문 접수 번호를 통지한다.
다음으로, 스텝 105에서, 거래 장치(31, 32)의 각각은, (약정 처리 프로그램 을 이용하여), 요건 DB(51)로부터 거래 상황이 「거래」이고, 자신에 대응하는 「종목」의 거래 요구를 추출한다. 이 추출은, 스텝 103과 마찬가지의 처리에 의해 실행하여도 된다. 그리고, 추출한 거래 요구에 대해서, 「약정 처리」를 실행한다. 즉, 추출한 거래 요구에 대응하는(매매가 반대인 것을 나타내고, 가격, 주수가 대응하는) 거래 요구가 없는지를 검출한다. 이 처리는, 통상 행해지고 있는 것이므로, 그 상세한 설명은 생략한다.
다음으로, 스텝 106으로 진행하여, 스텝 105에서의 약정 처리에서 약정이 성립하는지(대응하는 거래 요구를 검출할 수 있었는지)를, 거래 처리 장치(31, 32)의 각각은, (약정 처리 프로그램을 이용하여) 실행한다. 그 결과를, 대응하는 거래 요구에 관련 지어서 요건 DB에 저장한다. 그리고, 약정이 성립한 경우에는, 스텝 107로 진행하고, 약정이 성립하지 않은 경우에는, 스텝 108로 진행한다. 또한, 스텝 106에서, 약정이 성립한 경우에는, 요건 DB의 「거래」를 「약정」으로 변경한다. 또한, 약정이 성립하지 않은 경우에는, 「거래」를 「미약정」으로 변경한다.
다음으로, 스텝 107에서는, 이 등록 혹은 시간, 등록의 수 등을 트리거로, 각 접수 장치는, 요건 DB로부터 자신에 대응하는 「거래 단말기(그룹)」로서 「약정」의 거래 요구에 대해서, 그 거래 요구를 송신한 거래 단말기에 약정을 특정하는 약정 번호를 포함하는 약정 통지를 송신한다. 그리고, 스텝107로 진행한다.
다음으로, 스텝 108에서는, 거래 장치(31, 32)의 각각은 (거래 처리 프로그램을 이용하여), 도시하지 않은 시세 시스템 등에 송신하는 외부 출력 정보를 작성하여 송신한다. 여기서는, 전술한 바와 같이, 자신에 대응하는 「종목」의 거래 요구로서 「약정」 혹은 「미약정」인 것을 추출하여, 이들에 대해서 이 처리를 실행한다.
다음으로, 도 4 및 도 5를 이용하여, 스텝 101∼103(특히 103)의 상세에 대해서 설명한다. 우선, 도 4를 이용하여, 정상적으로 처리할 수 있었던 경우의 예를 설명한다.
우선, 스텝 101과 102의 상세에 대해서 설명한다. 또한, 스텝 101, 102(즉 하기의 상세 처리)는, 「그룹」 단위로 실행하는 것이다. 이는, 앞에 기술한 바와 같다.
스텝 1011에서는, 송신된 거래 요구를 수신하고, 스텝 1012에서는 앞에 설명한 바와 같이, 입력 전문 즉 거래 요구의 체크를 행한다. 이 체크는, 통신 경로 상에서의 장애 발생 상황에 의해, 정상적으로 수신할 수 있었는지를 판단하는 것이다. 정상이 아니라고 판정된 경우에는 스텝 1021로 진행하고, 정상이라고 판정된 경우에는 스텝 1022로 진행한다.
스텝 1021에서는, 송신한 거래 단말기에 에러(정상적으로 수신할 수 없었다는 취지)의 통지를 행한다. 그리고, 스텝 1022에서는, 수신한 거래 요구, 「종목」 마다 설치된 요건 DB에 대하여, 등록을 행한다. 즉, 수신한 거래 요구의 「종목」에 대응하는 요건 DB에 등록한다. 이 때, 「접수」를 「거래」로 변경하여 등록한다.
다음으로, 스텝 1023에서는, 수신이 정상으로 행해진 것을, 거래 단말기에 송신한다. 그리고, 스텝 1024에서, 전송 큐(MQ)를 발생시켜, 거래 장치(31) 등에 서의 처리 트리거로 한다. 여기서는, 「종목」마다 발생하도록 하여도 된다. 이 전송 큐의 발생(혹은 처리 장치에 통지)은 전술한 바와 같고, 일정 시간마다를 포함하는 소정 타이밍, 접수 장치에서의 요건 DB에의 등록(포함하는 동일 「종목」의 거래 요구가 일정수 이상)으로 된 것을 검지하여, 실행하여도 된다.
다음으로, 스텝 103의 상세에 대해서 설명한다. 또한, 스텝 103(즉 하기의 상세 처리)은, 「종목」 단위로 실행하는 것이다. 이는, 전술한 바와 같다. 스텝 1031에서, 자신에 대응하는 「종목」의 거래 정보를 요건 DB로부터 추출한다. 그리고, 스텝 1032에서, 추출된 거래 요구의 각 항목에 누락이 없는지, 수량에 대해서 발행수와 대응이 취해져 있지 않은지 등의 확인 처리를 실행한다.
그리고, 스텝 1033에서, 에러인(즉 올바르지 않다고 판단된) 경우, 스텝 1034로 진행하여 에러 처리를 행한다. 즉, 거래 단말기에 에러의 취지의 통지를 실행한다.
또한, 정상이라고 판정된 경우, 스텝 1035로 진행한다. 그리고, 스텝 1035에서, 「판 등록 처리」를 행한다. 판 등록 처리의 양태로서는, 요건 DB에서, 거래 가능하다는 플래그를 세우는 것이 포함된다. 또한, 주문 접수·판 DB에 등록하는 것도 본 실시 형태의 일 양태에 포함된다. 또한, 이들의 조합이어도 된다.
다음으로, 스텝 1036에서, 판 등록 처리를 실행한 것을, 대응하는 「종목」의 요건 DB에 등록한다. 그리고, 스텝 1037로 진행하여 거래 단말기에 대하여 주문이 정상으로 접수된 취지의 통지를 실행한다. 그리고, 스텝 1039에서, 스텝 1024와 마찬가지로, 전송 큐(MQ)를 발생시켜, 거래 장치(31) 등에서의 처리 트리거 로 한다. 여기서는, 「종목」마다 발생하도록 하여도 된다. 이 전송 큐의 발생(혹은 처리 장치에 통지)은 전술한 바와 같이, 일정 시간마다를 포함하는 소정 타이밍, 접수 장치로의 요건 DB에의 등록(포함하는 동일 「종목」의 거래 요구가 일정 수 이상)으로 된 것을 검지하여, 실행하여도 된다.
다음으로, 도 5를 이용하여, 이상 종료한 경우의 처리에 대해서 설명한다(스텝 103의 도중에 이상 종료한 경우). 기본적으로는, 도 4와 마찬가지의 처리를 실행한다. 이상 종료를 검지한 경우, 그 처리 요구를 재실행한다. 구체적으로는, 이상 종료한 거래 요구와 동일한 데이터를 요건 DB로부터 판독함으로써 실현한다.
또한, 요건 DB는 전술한 바와 같이, 종목마다, 그룹마다 등 복수 종류 준비하여도 된다. 이 경우, 처리 상황이 변하는 것(임의의 요건 DB의 「접수」로부터 「거래」에 등)을 트리거로, 서로의 정보의 정합이 얻어지도록, 다른 요건 DB의 거래 상황을 변경하도록 제어한다.
또한, 데이터베이스군으로서는, 도 4, 도 5에서의 각 처리의 제휴를 행하기 위한 데이터베이스를 설치하여도 된다. 요건 DB나 이들에는, 이하의 것이 포함된다.
요건 DB:기반 APP의 트랜잭션 제휴용으로 데이터를 저장하는 데이터베이스
요건 DB(접수→거래):「접수 처리→거래 처리」 사이에서의 데이터 제휴용 DB
요건 DB(거래→약정):「거래 처리→약정 처리」 사이에서의 데이터 제휴용 DB
요건 DB(약정→거래):「약정 처리→거래 처리」 사이에서의 데이터 제휴용 DB
요건 DB(거래→접수):「거래 처리→접수 처리」 사이에서의 데이터 제휴용 DB
업무 DB:업무에서 필요로 되는 데이터베이스.
주문 접수·판 DB:거래 처리 장치의 결과를 저장
주문 이력 DB:약정 처리 장치의 결과를 저장
또한, 이상의 본 발명의 실시 형태에 의해, 파이프라인 처리와 같은(의사적인) 병행 처리에 의해 스루풋 향상하는 것도 가능하게 된다.
또한, 이상과 같은 실시 형태(그루핑화에 의한 분산 처리)를 원용함으로써, 각 처리 장치(거래 처리 장치(3), 약정 처리 장치(4))를 증설하는 수직 확장에 의해, 거래(연산)량의 증대에도 대응이 가능하게 된다. 또한, 접수 장치(2)는 처리 장치(CPU)의 추가(증강)에 의한 수평 확장에 의해, 거래(연산)량의 증대에도 대응이 가능하게 된다. 또한, 본 발명에서는, 이와 같은 확장에 한정되지 않고, 예를 들면, 각 거래 장치를 소위 수직 확장으로 하고, 접수 장치를 수평 확장으로 하여도 된다. 또한, 각각 모두 수직 확장, 수평 확장으로 하여도 된다.
다음으로, 본 발명의 제2 실시 형태에 대해서, 도 8∼도 11을 이용하여 설명한다.
본 제2 실시 형태에서는, 상기한 실시 형태에서의 분산 처리를 행한 경우의 리스판스 시간의 산출을 행한다. 즉, 상기한 실시 형태와 같이, 분산 처리를 행한 경우, 각 거래 요구에 관한 리스판스 시간은 곧 바로는 알 수 없다. 이는, 도 10, 도 11에 도시한 바와 같이, 각 서브 업무 처리가 1개의 장치로 실시하는 것은 아니기 때문에, 시간의 산출이 어려워지기 때문이다. 또한, 리스판스 시간이란, 도 8에 도시한 바와 같이 주문 접수로부터 수신 통지나 약정 통지까지의 시간을 가리킨다.
따라서, 본 실시 형태에서는, 복수의 처리 장치에서, 분산 실행하고 있는 서브 업무를 1개의 주문 수신 통지 업무로서 서로 연결하고, 업무 리스판스 정보로서 작성하도록 제어하는 것이다. 즉, 각 서브 업무 중, 최초의 서브 업무의 개시 시간과 최후의 서브 업무의 종료 시간을 기록하고, 이것의 차분을 리스판스 시간으로서 산출한다. 또한, 시간의 기록 시에는, 거래를 식별하는 정보(접수 NO)를 대응지어서 기록해 둔다.
또한, 도 8에 도시한 바와 같이, 각 서브 업무의 개시 시간과, 최후의 서브 업무에서는 종료 시간을 기록하여 구성하여도 된다. 이 경우, 필요한 서브 업무를 지정에 기초하여 추출하여, 서브 업무(포함하는 복수의 서브 업무로 이루어지는 것)의 리스판스 시간을 산출하는 것이 가능하게 된다. 보다 구체적으로는, 이하의 처리를 실행한다. 주문 접수의 서브 업무 개시 시각과 접수 번호를, DB에 등록한다. 이후의 처리에서도, 서브 업무 개시 시각과 접수 번호를 DB에 등록한다. 1개의 주문 수신 통지 업무의 최후에 해당하는 서브 업무 「수신 통지 처리」에서는, 서브 업무 개시 시각과 접수 번호 외에, 거래 단말기로의 응답 후인 서브 업무 종료 시각을 DB에 등록한다. 1개의 주문 수신 통지 업무에 대응한 접수 번호를 키로 하여, 선두의 서브 업무 「주문 접수」의 개시 시각과, 최후의 서브 업무 「수신 통지 처리」의 종료 시각의 차분으로부터, 주문 수신 통지 업무의 리스판스를 산출한다.
본 발명의 제3 실시 형태에 대해서, 도면을 이용하여 설명한다. 본 실시 형태는, 증권(주식)의 거래를 예로 설명하지만, 본 발명은 이것에 한정되는 것은 아니다(타 업무 등에 적용하는 것도 본 발명에 포함됨).
우선, 본 실시 형태의 기본적인 내용에 대해서 설명한다.
(1) 통상은, 연락원 프로세스(예를 들면, 도 1이나 도 2의 접수 장치(2))로부터 연락처 프로세스(예를 들면, 도 1, 도 2의 거래 처리 장치(3))도에 대하여, 처리 의뢰(예:MQ 「전송 큐」)를 송신한다. 여기서는, 보낼 곳을 장치 즉 하드웨어로 하였지만, 본 실시 형태에서는, 하드는 상이한 경우도 있고 동일한 경우도 포함한다. 어디까지나, 임의의 프로세스(처리 프로그램)로부터, 처리 의뢰처의 프로세스에, 요건 데이터베이스의 등록과 처리 의뢰(MQ)를 송신할 수 있으면 된다. 예를 들면, 「주문 접수」라고 하는 프로세스는 단말기 그룹수분 있고, 「거래 처리 제어 1」이라고 하는 프로세스는 종목 그룹수분 동작하고 있다. 「거래 처리 제어 1」은 복수의 종목 키의 집합인 「종목 그룹」으로 묶고 있다. 「거래 처리 제어 1」이라고 하는 기능 명칭과, 종목 그룹의 조합으로 1개의 프로세스가 특정된다. 서버와 그룹이 1대1이어도 되고, 서버에 복수의 그룹이 배치되어 있어도 된다.
(2) 연락처 프로세스에서는, MQ를 수신하면, 그 MQ에 대응하는 요건 DB로부터 요건 정보(레코드)를 1건 취득(SELECT)한다. 여기서, 이 취득의 방법으로서는, (a) 자신의 「그룹」(혹은 자신)을 식별하는 식별자(예를 들면, 그룹 코드)를 이용하여 행하고(MQ와 요건 정보에는, 각각 그룹 코드를 포함시키도록 하고), (b) 거래 대상의 종목를 식별하는 식별자를 이용하여 행한다(MQ와 요건 정보에는, 각각 종목을 식별하는 식별자를 포함시키도록 한다). 또한, 요건 정보에는, 연락원 프로세스가 처리 의뢰를 발행(혹은 송신 등 소정의 처리이고, 요건 정보에 대한 처리이어도 된다)을 실행한 시간의 시간 정보를, 타임 스탬프 기능을 이용하여 포함시켜 둔다. 그리고, 이 시간 정보의 순에 따라서, 취득하는 순서를 결정한다. 예를 들면, 오래된 순으로 취득하도록 한다.
여기서, MQ가 무효(타임아웃)로 되는 등 하여 무효화한 경우(혹은 무효화를 검출한 경우), 연락처 프로세스에서는, 요건 데이터베이스를 검색하여, 미처리의 안건(예를 들면, 요건 정보)이 없는지를 검지한다. 이 검지는, 상기 (2)에 기재한 방법과 마찬가지로 검색 등을 행한다. 보다 상세하게는, 이하와 같다. 요건 데이터베이스와 처리 의뢰(MQ) 쌍방에, 처리 의뢰처의 「그룹 코드」 및 「큐」를 부여하고 있다. 연락처 프로세스는, MQGET에서 메시지(MQ)를 취득하면, 자 프로세스용의 메시지인 것을 체크하고 나서 「그룹 코드」 또는 「키」가 동일, 또한 미처리인 것을 검색 조건으로 하여, 등록 시각이 가장 오래된 요건 레코드를 요건 데이터베이스로부터 검색한다.
또한, MQ는 요건 데이터베이스를 검색하기 위한 트리거이다. 즉, MQ에는 「무엇을 행할 것인가」라고 하는 정보가 나타나 있지 않아도 된다. 「무엇을 행할 것인가」는, 요건 데이터베이스(의 요건 정보)에 등록되어 있다. 요건 데이터베이 스에는, 「무엇을 행할 것인가」로서 예를 들면 대응하는 주문 데이터(주문 수신 데이터베이스 등에 기록) 등을 특정하는 정보가 설정되어 있기 때문에, 요건 데이터베이스를 취득하는 순서로 주문 수신 데이터베이스의 처리를 행하는 것이 가능하게 된다(예;거래처에서 필요한 동일 종목 내에서의 주문의 처리 순서성을 확보하고 있다).
(3) 다음으로, 연락처 프로세스에서는, 취득한 요건 정보에 대응하는 처리를 실행하는 프로그램을 기동하고, 처리를 실행한다. 그리고, 다음 프로세스(예를 들면, 약정 처리 장치)에의 통지를 행한다.
본 실시 형태에서의 시스템 구성은, 도 1, 도 2와 마찬가지이다. 또한, 본 실시 형태에 대해서, 분산화 처리와 조합함으로써 이하의 효과를 달성하는 것이 가능하게 된다.
(1) 업무 요건인 「처리 순서성 보증」을 하는 것이 가능하게 된다. 「단말기 그룹:n→종목 그룹:m→단말기 그룹:n」과 같은 흐름으로, 서브 업무를 분할하고 있기 때문에, 처리 순서성 확보가 문제로 되지만, 요건 DB 내의 가장 오래된 미처리의 것부터 차례로 처리하기 때문에, 처리 순서성 보증(종목 그룹 단위)이 가능하게 된다(종목 그룹 1의 요건 DB에 대하여, n개의 단말기 그룹으로부터 처리 요구가 발생한다).
(2) 장애 복구 대상 리소스를 DBMS만으로 하는 것이 가능하게 된다. 트랜잭션과, DBMS의 양방에서, 회복 대상 리소스를 갖는 XA 제휴(2상 코미트)에서는, Commit 처리 성능이 길어지기 때문에, 회복 대상 리소스를 DBMS만으로 하고, 비XA 제휴로 하여 commit 성능을 확보하는 것이 가능하게 된다. 또한, 본 발명은, XA 제휴한 경우라도 적용 가능한 것은 물론이다.
(3) 회복 시의 순서성 확보가 가능하게 된다. (1)의 기능(요건 데이터베이스 내의 가장 오래된 미처리의 것부터 차례로 처리한다)에 의해, 장애 회복 후에도, 순서성을 확보하는 것이 가능하게 된다.
또한, 서브 업무 단위로 분산화하지 않은 것도 본 발명에 포함된다.
다음으로, 도 15를 이용하여 본 실시 형태의 처리 플로우에 대해서, 설명한다. 우선, 초기 처리로서, 스텝 200에서, 프로세스를 기동한다. 이하의 스텝도 포함하며 여기서는, 거래 처리 장치(3)에서의 처리를 예로 설명한다. 예를 들면, 본 장치에서 이용하는 프로그램을 기동시킨다.
다음으로, 스텝 201에서, MQGET, 즉, 처리 의뢰를 취득한다. MQ는, 접수 장치(2)로부터 송신된 것으로, 소정의 기억 장치에 저장되어 있다. 그리고, MQ 기억 장치에 존재하지 않는 경우에는, MQGET의 동작이 타임아웃으로 된다. 여기서, MQ는 미리 정한 시간으로 되면 타임아웃이라고 칭하여 무효화하도록 제어하여도 된다. 이 미리 정한 시간으로서는, 프로세스의 기동 시에는, 그 이외의 경우와 비교하여 짧은 시간으로 타임아웃으로 되도록 설정하여도 된다. 이와 같이 설정함으로써, 계 전환 등에 의해 저장되어 있는 MQ가 소멸하는 것을 방지하는 것이 가능하게 된다. 또한, 기동 시란, 기동하고 나서 최초로 기억 장치에 액세스하는 것을 포함한다.
다음으로, 스텝 202에서, MQGET(혹은 MQ)가 타임아웃으로 되었는지를 검지한 다. 타임아웃으로 된 경우(검지한 경우)는, 스텝 103으로 진행하고, 자신에 대한 MQ 송신을 행한다. 또한, 여기서, MQ는, 요건 데이터베이스를 검색하기 위한 트리거이면 되고, 「무엇을 행할 것인가」라고 하는 정보가 나타나 있지 않아도 된다. 「무엇을 행할 것인가」는, 요건 데이터베이스(의 요건 정보)에 등록되어 있다. 요건 데이터베이스에는 「무엇을 행할 것인가」로서 예를 들면 대응하는 주문 데이터(주문 수신 데이터베이스 등에 기록) 등을 특정하는 정보가 설정되어 있다. 이와 같이, 트리거로 되는 것(또한 소정의 조건으로 무효화되는 것이라면 더 바람직하다)이면 되고, MQ 이외의 것이어도 상관없다.
여기서, 스텝 203의 상세에 대해서, 도 16을 이용하여 설명한다.
우선, 스텝 2031에서, 도 17에 도시한 요건 데이터베이스로부터 미처리의 안건(즉 요건 정보)의 수를 계수한다. 즉, 각 요건 정보 중, 처리 완료 플래그가 미처리를 나타내는 것을 추출하고, 그 중 그 거래 처리 장치가 처리할 것을 나타내는 정보(그 거래 처리 장치의 식별 정보이어도 됨)의 요건 정보의 수를 계수한다. 또한, 우선, 상기 거래 처리 장치가 처리할 것을 나타내는 정보(그 거래 처리 장치의 식별 정보이어도 됨)의 요건 정보를 추출하고, 그 중으로부터 처리 완료 플래그가 미처리를 나타내는 것을 검지하여도 된다.
다음으로 스텝 2032에서, 스텝 2031에서 미처리의 안건이 있는지의 여부를 판단한다. 그 결과, 없는 경우에는 그대로 스텝 215로 진행하고, 본 스텝 203을 종료한다. 있는 경우에는, 스텝 2033으로 진행한다.
스텝 2033에서, 자신에게 송신하는 즉 재송의 MQ를 편집(생성)한다. 전술한 바와 같이, MQ는 트리거로 되면 되기 때문에, 자신(거래 처리 장치)인 것을 식별하는 정보가 포함되면 된다. 단, 보다 바람직하게는, MQ에는 상기 거래 처리 장치가 속하는 그룹(혹은 거래 처리 장치 자신)을 식별하는 그룹 코드 혹은 대응하는 요건 정보의 등록 등의 처리 시간 등의 키 정보를 포함시켜도 된다. 또한, 여기서는, 스텝 2031에서 계수된 미처리의 건수 이하의 수의 MQ를 생성한다. 보다 바람직하게는, 미처리의 건수 미만으로 하면 된다. 이는, 이 재송 MQ에 의해 트랜잭션의 증가나 큐 넘침을 방지하기 위한 것으로, 그 수는 이들을 고려하여 적당하게 정해도 된다.
그리고, 스텝 2034로 진행하고, 재송 MQ를 자 프로세스(거래 처리 장치)를 향하여 송신한다. 그리고, 본 처리를 종료하고(스텝 2035), 스텝 115로 진행한다.
다음으로, 스텝 215로 진행하고, 본 트랜잭션에 결착이 지어진 것으로 되고, 스텝 204로 진행한다. 스텝 204에서, 스텝 201과 마찬가지로, 처리 의뢰를 취득한다. 그리고, 스텝 205에서는, 스텝 202와 마찬가지로 타임아웃하였는지의 여부를 검지한다. 여기서의 타임아웃 값은, 스텝 202에서의 그것과 비교하여 길게 하여도 된다. 그 결과, 타임아웃으로 된 경우에는, 스텝 206으로 진행하여 스텝 203과 마찬가지의 처리를 실행한다.
다음으로, 스텝 202나 스텝 205에서, 타임아웃이 없다고 판단된 경우에 대해서, 설명한다. 이와 같이 판단된 경우, 스텝 207로 진행한다. 스텝 207에서는, 스텝 203이나 206에서 재송된 MQ를 포함하여 자신에게 송신된 MQ를 기억 장치로부터 취득한다. 여기서, 취득된 MQ를 저장하고 있던 기억 장치로부터 삭제한다.
다음으로, 스텝 208에서, MQ의 취득에 대응하여, 요건 데이터베이스(요건 DB)로부터 1건의 요건 정보를 취득한다. 여기서, 1건의 요건 정보의 취득의 방법은, MQ에 포함되는 키 정보와, 도 17에 도시한 요건 데이터베이스의 내용(키 정보, 시간 정보(도시 생략))을 이용하여 행한다. 즉, 요건 정보에 포함되는 요건 정보 중, 처리 완료 플래그가 미처리이고, 상기 거래 처리 장치에서 등록이 가장 오래된 요건 정보를 선택한다(키 정보나 UAP 정보에 이들 정보를 포함시켜서 구성하는 것이 가능하다). 이와 같이 하여, 요건 정보를 선택할 수 없는 경우에는 스텝 215로 진행하고, 선택한 경우에는 스텝 210으로 진행한다.
다음으로, 스텝 210에서, 선택된 요건 정보에 대응하는 거래 처리를, 그 요건 정보를 이용하여 어플리케이션 프로그램에 따라서 실행한다.
이 스텝 210의 종료 후 혹은 스텝 210과 병행하여, 스텝 211∼스텝 214의 처리를 실행한다. 스텝 211에서, 스텝 200 이후의 재송 MQ의 수를 계수한다. 이는, MQ 내에 건수를 포함시키고, 그것을 카운트함으로써 실현한다. 또한, 발행할 때마다 카운트하고, 기록함으로써 행하여도 실현 가능하다. 그 결과, 재송 MQ가 0건인 경우, 스텝 215로 진행한다. 0건이 아닌 경우에는, 스텝 212로 진행한다.
스텝 212에서는, 재송 MQ의 건수가 저장된 기억 장치로부터 재송 건수를 1 감산하도록 연산한다. 그리고, 일정 시간을 경과했는지를 검지하여(스텝 213), 그 결과 한 경우에는 스텝 214로 진행하고, 스텝 203 등와 마찬가지로 재송 처리를 실행한다. 또한, 스텝 213에서 일정 시간을 경과했다고 검지하지 않은 경우에는, 스텝 215로 진행한다. 여기서, 일정 시간이 경과했는지의 여부의 확인은, 일부 장치 의 장애나 큐 넘침에 대응하기 때문에 감시를 행하기 위해서 실행한다. 여기서는, 재송 건수를 기억 장치에 저장하도록 하였지만, 이하와 같이 구성하여도 된다. 메모리 등에의 일시적인 저장은 하지만, 재송하는 MQ에 재송 건수를 포함시킨다. 즉, 스텝 212에서는, 스텝 211에서 계수한 재송 건수로부터 1 감산한 재송 건수를 포함하는 MQ를 재송한다.
이상의 제3 실시 형태의 처리에 따르면, 도 18 및 이하에 기재되는 효과를 달성하는 것이 가능하게 된다. 요건 DB를 등록할 수만 있으면, 요건 등록 순으로의 업무 처리 속행이 가능하다. 또한, MQ 재송 처리에 의해 대폭적인 지연 없이 처리가 가능하게 된다. 특히, 이하와 같은 경우에 대응이 가능하게 된다. (1) 일부의 참가자(증권 회사 등)로부터의 다량 주문 입력 등에 의해, 처리 의뢰처 서버의 MQ의 큐 넘침이 발생한 케이스, (2) 특정의 종목에 주문이 집중하는 등에 의해, 처리 의뢰처의 MQ의 큐 넘침이 발생한 케이스, (3) 처리 의뢰처 서버의 다운 등에 의해, MQ가 소실한 케이스, (4) 처리 의뢰처 프로세스의 다운 등에 의해 MQ가 삭제되지 않고, 결과적으로 MQ의 큐 넘침이 발생한 케이스.
본 제3 실시 형태와 같이, MQ를 트리거로서 취급함으로써, 데이터베이스에 축적된 주문을 시간 우선순의 원칙에 따라서 처리하는 리스판스의 고속화와 단위 시간 처리 건수의 향상이 가능하게 된다.
그리고, 본 제3 실시 형태에 따른 회복 처리에서는, 특정 종목에의 주문 집중 등에 의해, MQ가 부분적으로 소실한 경우라도, 극력 지체 없이 주문의 처리를 행하는 것이 가능하게 된다. 또한, 본 제3 실시 형태에서는, MQ(장애 시에 회복 대상으로 되지 않음)를 포함하는(영속 MQ가 혼재하여도 상관없는) 경우에 유효하다. 예를 들면 주문 접수 프로세스는 복수의 통신 서버에 배치된다. 이 경우, 임의의 서버에서 MQ의 전송 지연이나, 전송 도중에의 장애가 발생했을 때, 해당하는 주문의 발주원 거래 참가자는, 다른 거래 참가자보다 뒤지는 형태로 되거나, 종목의 거래 상태가 변화함으로써 불리함을 입거나 할 우려가 있는 것을 해소할 수 있다.