KR101365840B1

KR101365840B1 - 이벤트 모니터의 동작의 방법, 컴퓨터 판독가능 매체 및 작업 아이템 이벤트 모니터

Info

Publication number: KR101365840B1
Application number: KR1020087027144A
Authority: KR
Inventors: 존 에프. 마토우세크; 라제쉬 카마쓰
Original assignee: 마이크로소프트 코포레이션
Priority date: 2006-05-05
Filing date: 2007-05-04
Publication date: 2014-02-21
Also published as: EP2021948A2; EP2021948A4; WO2007130621A3; CL2007001254A1; US20070261063A1; US7877757B2; WO2007130621A2; CN101438275A; JP2009536403A; TW200821863A; CN101438275B; KR20090005367A

Abstract

여기에는, 특히, 프런트 엔드 애플리케이션과 백 엔드 서버 사이의 이벤트들의 흐름을 모니터링하는 기술이 상세히 설명된다. 본 기술의 한 접근법에서, 새로운 이벤트는 백 엔드 서버에서 수신된다. 이 새로운 이벤트는 이벤트 유형이 있으며, 이는 그러한 유형의 새로운 이벤트가 수신되었음을 나타내는 새로운 이벤트 플래그를 설정하는 데 사용된다. 새로운 이벤트는 큐 테이블에 추가된다. 큐 테이블로부터 하나 이상의 이벤트들이 선택되고, 선택된 이벤트들이 프로세스되는 중에 장애 조치 메커니즘이 유지된다.

이벤트, 큐 테이블, 장애 조치 이벤트, 만료 시간

Description

이벤트 모니터의 동작의 방법, 컴퓨터 판독가능 매체 및 작업 아이템 이벤트 모니터{WORK ITEM EVENT PROCESSION}

특히 네트워크화된 환경에 있는 많은 소프트웨어 애플리케이션에서, 하나 이상의 상태 비보존형(stateless) 프런트 엔드(front-end) 애플리케이션은 단일의 상태유지(state-full) 백 엔드(backend)와 연결된다. 다양한 객체들을 액세스하고, 변경하고, 제거하기 위한 요청들과 같은 이벤트들이 프런트 엔드 애플리케이션에서 수신되고, 백 엔드로 전달된다. 종종, 동일한 객체에 대한 액세스를 얻으려고 하는 복수의 요청들은 동시에 또는 거의 동시에 수신된다. 대부분의 애플리케이션에서, 임의의 이러한 충돌하는(conflicting) 요청들은 객체가 액세스되고 있는 동안 객체를 로크 다운(lock down)함으로써 처리된다(addressed).

상태유지 백 엔드에 있는 객체가 로크 다운되면, 현재 처리되고 있는 요청의 애플리케이션만이 객체를 액세스하도록 허락된다. 이러한 방식으로, 잠재적으로 충돌하는 액세스 및 변경 요청들이 객체에 대해 동시에 수행되지 않으므로 객체 무결성이 보존되고, 손상(corruption)을 피할 수 있다.

이 접근법에는 다수의 문제들이 존재한다. 예를 들어, 객체 핸들러(object handler)는 언제 새로운 이벤트가 수신되는지를 결정하기 위한 수단이 없다. 이벤트 배정 메커니즘(event dispatching mechanism)은 이미 프로세스되고 있는 이벤트 와 프로세싱을 대기하는 이벤트를 구별하지 못한다. 또한, 대부분의 컴퓨터 애플리케이션에서와 같이, 어떤 이벤트들이 프로세스되었고, 어떤 이벤트들이 현재 프로세스되고 있고, 어떤 이벤트들이 여전히 프로세스되어야 하는지에 대한 기록이 유지되지 않기 때문에, 시스템 오류(system failure)는 상당한 시간의 낭비를 가져온다.

<발명의 요약>

여기에는, 특히, 프런트 엔드 애플리케이션과 백 엔드 서버 사이의 이벤트들의 흐름을 모니터링하는 기술이 상세히 설명된다. 복수의 프런트 엔드 애플리케이션이 백 엔드 서버의 동일한 객체를 액세스하려고 하는 경우, 요청들은 큐 테이블에서 대기열에 넣어진다(queued up in a queuing table). 동일한 배치(batch) 내에서 프로세스되는 객체들의 유형에 따라 큐 테이블을 정렬함으로써, 프로세스는 더욱 효율적이 된다. 새로운 이벤트가 수신될 때 설정되는 플래그(flag)를 통합함으로써, 이벤트 배정 메커니즘은 큐 테이블을 폴링(poll)하지 않고서도 새로운 이벤트들을 인식할 수 있다. 큐 테이블 내의 이벤트들을 플래깅(flagging)하는 것 자체가, 여전히 프로세스되어야 하는 이벤트들과 대립하는 것으로서, 어느 이벤트들이 이미 프로세스되고 있는지를 식별한다. 장애 조치(failover) "이벤트", 및 관련된 모니터(monitor)의 구현은 백 엔드가 "프로세스 중(in process)"인 선택된 이벤트들에 대해 시스템 오류들을 검출할 수 있도록 하며, 큐 테이블의 "좋은(good)" 버전(version)을 저장하고 이후의 업데이트들에서 장애 조치 "이벤트"를 유지함으로써 시스템은 최소 손실로 실패(failure)로부터 복구할 수 있다.

본 기술의 한 접근법에서, 새로운 이벤트는 백 엔드로 전송된다. 새로운 이벤트는 관련된 이벤트 유형을 갖는다. 새로운 이벤트가 수신되면, 관련된 이벤트 유형에 기초하여 새로운 이벤트 플래그가 설정되어, 그 특정 이벤트 유형의 새로운 이벤트가 수신되었음을 표시한다. 새로운 이벤트는 큐 테이블에 추가된다. 이벤트들은 프로세싱을 위해, 때때로 이벤트 유형에 기초하여, 그리고 과거의 시간으로 설정된 만료 시간을 갖는 것에 기초하여, 그룹들로서 큐 테이블로부터 선택된다. 다른 비즈니스 애플리케이션이 동시에 동일한 이벤트들을 프로세스하는 것을 시스템이 막도록, 프로세싱 그룹 내의 각 이벤트는 마킹된다(marked). 프로세싱이 완료되면, 이벤트들은 삭제되거나 업데이트되고, 삭제되지 않는 경우 프로세싱 마크가 제거된다.

본 기술의 또 다른 접근법에서, 예를 들어 프로세싱을 위해 하나 이상의 이벤트들이 선택되는 경우, 장애 조치 이벤트가 큐 테이블에 추가된다. 장애 조치 보호 이벤트(failover guard event)는 만료 타이머를 갖는다. 장애 조치 이벤트는 모니터링되고, 만료 타이머가 끝나면(lapses), 시스템 오류가 발생하고 시스템은 복원될 필요가 있다. 예를 들어 프로세싱 중에 큐 테이블을 성공적으로 액세스함으로써, 만료 타이머는 리셋(reset)될 수 있다. 만료 타이머가 끝나면 큐 테이블이 알려진 좋은 버전으로 복원될 수 있도록, 큐 테이블의 "좋은" 상태가 저장된다. 예를 들어, 만료 타이머가 생성될 때 큐 테이블의 좋은 버전이 저장될 수 있다.

본 발명의 요약은 아래의 상세한 설명에서 더 상세히 설명되는 개념들의 선택을 간략한 형태로 소개하기 위해 제공된다. 본 발명의 요약은 청구된 본 발명의 주요 특징 또는 본질적 특징들을 식별하기 위한 것이 아니며, 또한 청구된 본 발명의 범위를 제한하는 데 사용되도록 하기 위한 것이 아니다.

본 명세서에 통합되며 그 일부를 형성하는 첨부된 도면은 실시예들을 도시하며, 명세서와 함께 청구된 본 발명의 원리들을 설명한다.

도 1은 실시예들이 구현될 수 있는 예시적인 컴퓨팅 시스템의 블록도이다.

도 2는 일 실시예에 따른, 컴퓨팅 환경의 블록도이다.

도 3은 일 실시예에 따른, 백 엔드의 블록도이다.

도 4는 일 실시예에 따른, 작업 아이템 이벤트 모니터(work item event monitor)의 블록도이다.

도 5는 일 실시예에 따른, 작업 아이템 이벤트 모니터의 사용에 대한 흐름도이다.

도 6은 일 실시예에 따른, 실패 복구 방법에 대한 흐름도이다.

구체적으로 여러 실시예들에 대한 참조가 이루어질 것이다. 본 발명은 대안적인 실시예들과 함께 설명될 것이지만, 이는 청구된 본 발명을 이 실시예들로 제한하기 위한 것이 아니라는 것을 이해해야 한다. 오히려, 청구된 본 발명은 첨부된 청구항들에 의해 정의된 청구된 본 발명의 정신 및 범위 내에 포함될 수 있는 대안적인 변경, 및 동등물들을 포함하기 위한 것이다.

또한, 이어지는 상세한 설명에서, 청구된 본 발명에 대한 완전한 이해를 제 공하기 위해 많은 구체적 세부사항들이 제시된다. 그러나, 당업자들은 실시예들이 이러한 구체적 세부사항 또는 그의 동등물 없이도 실행될 수 있음을 이해할 것이다. 다른 경우에서, 본 발명의 양상 및 특징들을 불필요하게 모호하게 하지 않기 위해, 잘 알려진 방법, 절차, 컴포넌트, 및 회로들은 상세히 설명되지 않는다.

이어지는 상세한 설명의 부분들은 방법과 관련하여 제시되고 논의된다. 그의 단계 및 순서(sequencing)는 본 방법의 동작들을 설명하는 여기의 도면(예를 들어, 도 6)에 개시되지만, 이러한 단계 및 순서는 예시적인 것이다. 실시예들은 다양한 다른 단계들 또는 여기의 도면의 흐름도에 열거된 단계들의 변형을 수행하기에 적합하며, 여기에 도시되거나 설명된 것 이외의 순서로 수행되기에 적합하다.

상세한 설명의 몇몇 부분들은 컴퓨터 메모리에서 수행될 수 있는 데이터 비트들에 대한 동작들의 절차, 단계, 논리 블록(logic block), 프로세싱, 및 다른 기호적 표현(symbolic representation)과 관련하여 제시된다. 이러한 설명 및 표현은 데이터 프로세싱 기술의 숙련된 자들이 그들의 작업의 내용(substance)을 다른 당업자들에게 효과적으로 전달하기 위해 사용하는 수단이다. 절차, 컴퓨터-실행 단계(computer-executed step), 논리 블록, 프로세스 등은, 여기에서 일반적으로, 원하는 결과를 가져오는 단계 또는 명령들의 일관성 있는 시퀀스인 것으로 이해된다. 단계들은 물리량(physical quantity)의 물리적 조작을 요구하는 것들이다. 반드시 그런 것은 아니지만, 보통, 이 양들은 저장되고, 전송되고, 결합되고, 비교되고, 및 달리 컴퓨터 시스템에서 조작될 수 전기적 또는 자기적 신호들의 형태를 갖는다. 주로 공동 사용(common usage)을 이유로, 때때로 이 신호들은 비트, 값, 구성요소(element), 기호(symbol), 문자(character), 용어(term), 숫자, 기타 등등으로 부르는 것이 편리한 것으로 나타났다.

그러나, 이들 모든 용어 및 유사한 용어들은 적절한 물리량과 관련되어야 하며, 용어들은 단지 이들 물리량들에 적용된 편리한 레이블(label)이라는 것을 명심해야 한다. 이어지는 논의에서 명백하게 달리 구체적으로 규정되지 않는 한, 본 발명 전체에 걸쳐, "액세스하는(accessing)", "기입하는(writing)", "포함하는(including)", "저장하는(storing)", "전송하는(transmitting)", "트래버싱하는(traversing)", "관련시키는(associating)", "식별하는(identifying)" 기타 등등과 같은 용어들을 사용하는 논의들은, 컴퓨터 시스템의 레지스터 및 메모리 내에 물리(전자)량으로서 표시된 데이터를, 컴퓨터 시스템 메모리 또는 레지스터 또는 다른 이러한 정보 저장소, 전송 또는 디스플레이 장치 내의 물리량들로서 유사하게 표시된 다른 데이터로 조작하고 변환하는 컴퓨터 시스템, 또는 유사한 전자 컴퓨팅 장치의 동작 및 프로세스를 말한다.

컴퓨팅 시스템 환경(10)과 같은 컴퓨팅 장치들은 통상적으로 적어도 어떤 형태의 컴퓨터 판독가능 매체를 포함한다. 컴퓨터 판독가능 매체는 컴퓨팅 장치에 의해 액세스될 수 있는 임의의 사용가능한 매체일 수 있다. 예로서, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있지만 이에 제한되지는 않는다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터와 같은 정보를 저장하는 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동식 및 비이동식 매체를 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 기타 메모리 기술, CD-ROM, DVD(digital versatile disk) 또는 기타 광 디스크 저장 장치, 자기 카세트, 자기 테이프, 자기 디스크 저장 장치 또는 기타 자기 저장 장치, 또는 컴퓨팅 장치에 의해 액세스되고 원하는 정보를 저장할 수 있는 임의의 기타 매체를 포함하지만 이에 제한되는 것은 아니다. 통신 매체는 통상적으로 반송파(carrier wave) 또는 기타 전송 메커니즘(transport mechanism)과 같은 피변조 데이터 신호(modulated data signal)에 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터 등을 구현하고 모든 정보 전달 매체를 포함한다. "피변조 데이터 신호"라는 용어는, 신호 내에 정보를 인코딩하도록 그 신호의 특성들 중 하나 이상을 설정 또는 변경시킨 신호를 의미한다. 예로서, 통신 매체는 유선 네트워크 또는 직접 배선 접속(direct-wired connection)과 같은 유선 매체, 그리고 음향, RF, 적외선, 기타 무선 매체와 같은 무선 매체를 포함한다. 상술된 매체들의 모든 조합이 또한 컴퓨터 판독가능 매체의 영역 안에 포함되는 것으로 한다.

몇몇 실시예들은 일반적으로 하나 이상의 컴퓨터 또는 다른 장치들에 의해 실행되는 프로그램 모듈과 같은 컴퓨터 실행가능 명령어와 관련하여 기술될 것이다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정 추상 데이터 유형을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 등을 포함한다. 통상적으로 프로그램 모듈의 기능은 다양한 실시예에서 원하는 바에 따라 결합되거나 분산될 수 있다.

작업 아이템 이벤트 모니터가 아래에서 설명된다. 몇몇 실시예에서, 작업 아이템 이벤트 모니터는, 웹 서버 또는 포털 서버 환경과 같은, 서버 애플리케이션의 백 엔드에서 동작한다. 모니터는 백 엔드를 통해 사용가능한 상태유지 객체들에 대한, 상태 비보존형 프런트 엔드 애플리케이션으로부터의 복수의 경쟁하는 요청들을 조정(reconcile)한다.

작업 아이템 이벤트 모니터는 아직 백 엔드의 적절한 객체들로 전달되지 못한, 프런트 엔드 애플리케이션으로부터 수신된 이벤트들을 추적하기 위해 큐 테이블을 사용한다. 몇몇 실시예에서, 작업 아이템 이벤트 모니터는 또한 이벤트 배정 메커니즘으로서 동작한다. 여기에 설명된 바와 같이, 다수의 방법으로 큐 테이블을 모니터링하고 변경함으로써, 몇몇 실시예에서, 작업 아이템 이벤트 모니터는 시기적절한 방식(timely manner)으로 객체들에게 새로운 이벤트들에 대해 알릴 수 있고, 특정 이벤트가 전달되었는지 또는 전달되어야 하는지를 추적할 수 있고, 서버 시스템 장애로부터 복구할 수 있고, 큐 테이블을 더 효율적으로 만들 수 있다.

기본 컴퓨팅 장치

도 1을 참조하여, 실시예들을 구현하기 위한 예시적인 시스템은 컴퓨팅 시스템 환경(10)과 같은 범용 컴퓨팅 시스템 환경을 포함한다. 가장 기본적인 구성에서, 컴퓨팅 시스템 환경(10)은 통상적으로 적어도 하나의 처리 장치(12) 및 메모리(14)를 포함한다. 컴퓨팅 시스템 환경의 정확한 구성 및 유형에 따라, 메모리(14)는 (RAM과 같은) 휘발성, (ROM, 플래시 메모리 등과 같은) 비휘발성, 또는 이 둘의 어떤 조합일 수 있다. 이 가장 기본적인 구성은 도 1에서 점선(16)에 의해 도시된다. 또한, 컴퓨팅 시스템 환경(10)은 추가적인 특징/기능도 가질 수 있 다. 예를 들어, 컴퓨팅 시스템 환경(10)은 또한 자기 또는 광학 디스크 또는 테이프를 포함하는 추가적인 저장소(이동식 및/또는 비이동식)를 포함할 수 있지만 이에 제한되지는 않는다. 이러한 추가적인 저장소는 도 1에서 이동식 저장소(18) 및 비이동식 저장소(20)에 의해 도시된다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터와 같은 정보의 저장을 위한 임의의 방법 또는 기술로 구현된 휘발성 및 비휘발성, 이동식 및 비이동식 매체를 포함한다. 메모리(14), 이동식 저장소(18) 및 비이동식 저장소(20) 모두 컴퓨터 저장 매체의 예이다.

컴퓨팅 시스템 환경(10)은 또한 다른 장치들과 통신할 수 있도록 하는 통신 연결(22)을 포함할 수 있다. 통신 연결(22)은 통신 매체의 예이다.

컴퓨팅 시스템 환경(10)은 또한 키보드, 마우스, 펜, 음성 입력 장치, 터치 입력 장치 등과 같은 입력 장치(들)(24)를 가질 수 있다. 디스플레이, 스피커, 프린터 등과 같은 출력 장치(들)(26)도 포함될 수 있다. 이 모든 장치들은 본 기술 분야에서 잘 알려진 것들이며 여기에서 길게 논의될 필요가 없다.

컴퓨팅 환경

이제 도 2를 참조하면, 일 실시예에 따라 시스템(200)이 도시된다. 시스템(200)은 특정 특징들을 포함하는 것으로 도시되지만, 시스템(200)은 단지 예시적인 것임을 이해해야 한다. 다른 실시예에서, 시스템(200)은 추가적인 특징, 더 적은 특징, 또는 도시된 것과 다른 특징들을 포함할 수 있다. 또한, 몇몇 실시예에서, 열거된(listed) 특징들은 복수의 별개의 구성요소들로 분리되거나, 결합되어 더 적은 수의 구성요소들로 될 수 있다.

도시된 바와 같이, 시스템(200)은 단일 상태유지 백 엔드(220)와 인터페이스하는 복수의 상태 비보존형 프런트 엔드 애플리케이션(210, 211, 212)을 도시한다. 몇몇 실시예에서, 프런트 엔드 애플리케이션들 및 백 엔드 모두 컴퓨팅 시스템 환경(10)과 같은 단일 컴퓨터 시스템에 구현될 수 있다. 다른 실시예에서, 예를 들어, 단일 웹 서버를 액세스하는 복수의 웹 클라이언트와 같이, 하나 이상의 프런트 엔드 애플리케이션은 원격으로 실행되며 네트워크 연결을 통해 백 엔드(220)에 액세스할 수 있다. 다른 실시예에서, 프런트 엔드 애플리케이션(210, 211, 및/또는 212)은 다른 방식으로 백 엔드(220)와 통신한다. 도시된 백 엔드(220)는 데이터 저장소(230)와 연결된다. 몇몇 실시예에서, 데이터 저장소(230)는, 예를 들어 SQL 데이터베이스와 같은 데이터베이스이다. 다른 실시예에서, 데이터 저장소(230)는 다른 방식으로 구현된다.

이제 도 3을 참조하면, 일 실시예에 따라, 백 엔드(220)에 대한 상세한 블록도가 제공된다. 백 엔드(220)는 특정 특징들을 포함하는 것으로 도시되지만, 백 엔드(220)는 단지 예시적인 것임을 이해해야 한다. 다른 실시예에서, 백 엔드(220)는 추가적인 특징, 더 적은 특징, 또는 도시된 것과 다른 특징들을 포함할 수 있다. 또한, 몇몇 실시예에서, 열거된 특징들은 복수의 별개의 구성요소들로 분리되거나, 결합되어 더 적은 수의 구성요소들로 될 수 있다.

도시된 바와 같이, 백 엔드(220)는 큐 테이블(221)을 포함한다. 몇몇 실시예에서, 큐 테이블(221)은 프런트 엔드 애플리케이션들로부터 수신된 이벤트들이 데이터 저장소(230)의 객체들에 전달될 수 있을 때까지, 그 이벤트들을 유지(retain)하기 위해 백 엔드(220)에 의해 사용된다. 몇몇 이러한 실시예에서, 큐 테이블(221)은 더 효율적인 프로세싱을 위해 이 요청들을 정렬(order)하는 데에도 사용된다.

백 엔드(220)는 또한 여러 배치 테이블(batch table)(222, 223, 및 224)을 포함하는 것으로 도시된다. 배치 테이블을 포함하는 몇몇 실시예에서, 프런트 엔드 애플리케이션으로부터 수신된 이벤트들뿐 아니라 백 엔드(220)에 의해 생성된 이벤트들은 여러 배치 유형들로 정렬(sorted)된다. 이 배치 유형들 중 몇몇 또는 모두는 백 엔드(220) 내에 관련된 배치 테이블을 가질 수 있다. 이 배치 테이블들은 이벤트를 프로세스하는 데 필요한 추가적인 정보를 저장하는 데 사용될 수 있다. 다른 실시예들은 배치 테이블을 생략한다.

도 3은 큐 테이블(221) 및 배치 테이블(222 내지 224)이 백 엔드(220)의 일부인 것으로 도시하지만, 몇몇 실시예에서 이 테이블들은 백 엔드(220)에 의해 액세스될 수 있는 임의의 위치에 저장될 수 있음을 이해해야 한다. 예를 들어, 이 테이블들은 데이터 저장소(230)에 저장될 수 있다.

도 3은 또한 백 엔드(220)와 연결된 데이터 저장소(230)를 도시한다. 데이터 저장소(230)는 워크플로 유형의 객체, 즉, 워크 플로 객체(231)를 포함하는 것으로 도시된다.

이벤트들의 효율적인 정렬

본 시스템의 효율성, 및 특히 요청들의 효율적인 핸들링은, 실질적으로 이벤 트들이 어떤 순서로 큐 테이블로부터 의도된 객체들에게 전달되는지에 좌우된다. 몇몇 실시예에서, 큐 테이블, 또는 튠 테이블(tune table)에 대한 인덱스는 프로세스를 신속하게 하도록 정렬된다(ordered).

큐 테이블에 대한 한 접근법은 이벤트가 프로세스되어야할 시간에 따라 테이블을 정렬하는 것이다. 예를 들어, 이벤트가 프런트 엔드로부터 백 엔드로 전달될 때, 이는 종종 요청된 프로세싱 시간을 첨부하고 있다. 이 프로세싱 시간은 요청에 대한 우선 순위(priority), 또는 긴급함의 레벨(level of urgency)을 나타낼 수 있다. 예를 들어, 백 엔드로부터 데이터를 찾고 있는 실시간 애플리케이션은, 실시간으로, 자신의 이벤트들이 신속히 처리되도록 요청할 수 있고, 한편, 다른 비실시간(non-real-time) 프런트 엔드 애플리케이션으로부터 수신된 이벤트들은 덜 긴급할 수 있고 따라서 이들은 더 긴 가능한 프로세싱 시간을 갖는다.

몇몇 실시예에서, 큐 테이블을 정렬하기 위한 또 다른 접근법이 구현된다. 몇몇 이러한 실시예에서, 큐 테이블 또는 큐 테이블에 대한 인덱스는 배치 유형에 의해 정렬된다. 이러한 방식으로, 특정 배치 유형의 모든 작업들이 함께 그루핑(grouped together)된 후 함께 프로세스된다. 동일한 배치 내에서 프로세스되는 객체들의 유형에 따라 큐 테이블을 정렬함으로써, 이 실시예들은 다른 접근법에는 없는 효율성의 수준을 얻는다.

새로운 이벤트 모니터링

이벤트 관리를 위한 큐 테이블 접근법의 한가지 문제는, 백 엔드는 큐 이벤트들에 대해 인식하고 있지만, 다양한 객체들에 대한 이벤트 핸들러(handler)들은 일반적으로 그렇지 않다는 것이다. 몇몇 접근법에서, 이는 큐 테이블을 폴링함으로써 해결된다. 특정 객체에 대한 이벤트 핸들러에게 큐 테이블에 대한 액세스가 주어지며, 이벤트 핸들러는 자신이 다루는 객체로 향하는(directed to) 이벤트들에 대해 큐 테이블 전체를 주기적으로 검색한다.

몇몇 실시예에서, 이 문제는 이벤트들이 큐 테이블에 추가됨에 따라 이벤트들을 모니터링함으로써 더 잘 해결된다. 예를 들어, 일 실시예에서, 백 엔드에서 실행되는 작업 아이템 이벤트 모니터는 이벤트들이 큐 테이블에 추가됨에 따라 그들을 모니터링한다. 이벤트가 특정 배치 유형(batch type), 예를 들어 워크플로 객체에 대한 이벤트인 경우, 작업 아이템 이벤트 모니터는 신호 또는 플래그를 업데이트하여, 이러한 유형의 새로운 이벤트가 추가되었음을 표시한다. 몇몇 실시예에서, 이 플래그는 그 특정 객체에 대한 이벤트 핸들러가 사용가능하다.

일 실시예에서, 플래그는 간단한 부울 유형(Boolean type)으로, 이러한 유형의 새로운 이벤트가 있는지 없는지를 표시한다. 다른 실시예에서, 더 복잡한 플래그 시스템이 사용된다.

몇몇 실시예에서, 새로운 이벤트 플래그는 적절한 배치 유형(batch type)에 대한 배치 테이블 내에 위치하는데, 예를 들어, 새로운 워크플로 이벤트를 표시하는 새로운 이벤트 플래그는 워크플로 객체 유형에 대한 배치 테이블의 부분이다. 다른 실시예에서, 플래그는 다른 곳에 위치한다.

이벤트 배정( Event dispatching )

큐 테이블 접근법에서의 또 다른 문제는, 이벤트 배정 메커니즘이 이벤트가 적절한 이벤트 핸들러로 전달되었는지를 어떻게 결정하는가 하는 것이다. 몇몇 실시예에서, 이 문제를 해결하기 위해 사용된 접근법은 큐 테이블 자체 내에서 이벤트를 마킹(mark)하는 것이다.

몇몇 실시예에서, 이벤트 배정 메커니즘은 큐 테이블을 통과하며(pass through) 지금 실행되어야할 작업 아이템들을 식별한다. 몇몇 실시예에서, 이는 상술된 방식으로, 만료된 프로세싱 시간 또는 만료되려고 하는 프로세싱 시간을 갖는 특정 배치 유형과 관련된 모든 작업 아이템들을 찾음으로써 이루어진다. 이러한 방식으로 큐 테이블을 통과하는 것은 아직 프로세스되지 않은 이벤트 및 현재 프로세스되고 있는 이벤트들 모두를 식별한다.

서로 다른 프런트 엔드 기계들에서 실행되는 복수의 이벤트 핸들러들에게 중복 이벤트들을 전달하는 것을 피하기 위해, 현재 프로세스되고 있는 이벤트들은 스크린 아웃(screened out)될 필요가 있다. 몇몇 실시예에서, 이는 큐 테이블 내의 작업 아이템들을 태깅(tagging)하여 그 작업 아이템들이 이미 이벤트 핸들러에 전달되었음을 표시함으로써 해결된다. 몇몇 이러한 실시예에서, 이 태깅은 특정 이벤트가 이미 어드레스되었는지(addressed) 어드레스되지 않았는지를 표시하는 간단한 부울 플래그의 형태이다. 다른 실시예에서, 이벤트들은, 예를 들어 GUID(globally unique identifier)와 같은 식별자로 마킹된다. 여러 실시예에서, 이벤트들은 추가적인 정보를 전달하기에 충분한 방식으로 마킹된다. 다른 실시예에서, 적절한 이벤트 핸들러에 이미 전달된 이벤트들을 식별하기 위해 다른 방법들이 사용된다. 몇몇 실시예에서, 이 접근법은 반대로 되어, 태그 또는 마크(mark) 의 부재가 특정 이벤트가 이미 어드레스되었는지를 나타낸다.

몇몇 실시예에서, 태깅되지 않은 이벤트들은 프로세싱을 위해 선택될 때 마킹된다. 예를 들어, 워크플로 유형의 이벤트들이 프로세스되어야 하는 경우, 워크플로 유형의 이미 태깅된 임의의 이벤트는 무시되고, 한편 태깅되지 않은 이벤트들은 태깅되고 이벤트 핸들러에 전달된다. 몇몇 실시예에서, 예를 들어 SQL 환경에서, 이는 두 단계 프로세스이다: 먼저 태깅되지 않은 이벤트들이 마킹되고, 다음, 새로이 태깅된 이벤트들이 선택된다. 다른 데이터 저장 환경을 포함하는 다른 실시예에서, 이 프로세스는 더 적은 단계 또는 추가적인 단계들을 필요로 할 수 있다.

몇몇 실시예에서, 프로세싱이 완료되었을 때 이벤트들은 큐 테이블로부터 제거되지 않을 수 있다. 이 상황은 여러 이유 때문에 발생할 수 있는데, 예를 들어, 완전히 완료되기 위해, 이벤트는 이후에 또 다른 프로세싱을 필요로 할 수 있다. 몇몇 이러한 실시예에서, 이벤트에 대한 현재 프로세싱 동작이 완료되면, 이벤트가 현재 프로세스되고 있음을 나타내는 태그는 제거된다.

실패 복구( Failure Recovery )

컴퓨팅 애플리케이션 고유의 한가지 문제점은 실패 복구이다. 여기에 적용되는 바와 같이, 백 엔드 서버가 큐 테이블 내의 이벤트들에 실패할 경우, 복구 프로세스는 큐 테이블을 복원할 수 있는 어떤 수단을 통합하는 것이 바람직하다.

몇몇 실시예에서, 작업 아이템 이벤트 모니터는 이러한 실패 및 복구 메커니즘을 통합한다. 여러 이러한 실시예에서, 작업 아이템 이벤트 모니터는 시스템 오 류를 식별하고, 시스템이 안정된 것으로 알려진 때의 큐 테이블의 이전 버전으로 되돌아갈(revert to) 수 있다.

몇몇 실시예에서, 이는 장애 조치 유형(failover type)의 이벤트를 큐 테이블에 추가함으로써 이루어진다. 몇몇 실시예에서, 이 이벤트는 작업 아이템 이벤트 모니터에 의해 생성된다. 다른 실시예에서, 다른 메커니즘들은 이 이벤트의 생성 전의 응답일 수 있다. 장애 조치 이벤트는 큐 테이블에 추가되고, 미리 정해진 시간, 예를 들어 추가된 시간으로부터 15분 후에 만료되도록 설정될 수 있다. 몇몇 실시예에서, 큐 테이블이 건드려질(touched) 때마다, 예를 들어, 큐 테이블 내의 작업 아이템들이 프로세싱을 위해 선택되고 프로세싱 ID로 태깅될 때마다, 장애 조치 이벤트에 대한 만료 시간이 리셋(reset)된다.

한편, 몇몇 이러한 실시예에서, 장애 조치 보호 모듈(failover guard module)은 종종, 예를 들어, 매 5분마다, 큐 테이블을 검사(examine)하고 장애 조치 이벤트를 찾는다. 만료된 장애 조치 이벤트가 검출되면, 작업 아이템 이벤트 모니터는 어떤 시스템 오류가 발생했음을 안다. 몇몇 실시예에서, 시스템은 장애 조치 보호 모듈이 마지막으로 큐 테이블을 성공적으로 검사했을 때의 상태로 되돌아간다. 다른 실시예에서, 시스템은 장애 복구 이벤트가 마지막으로 리셋되었을 때의 상태로 되돌아간다.

몇몇 실시예에서, 장애 조치 이벤트는 큐 테이블 내의 마지막 배치(batch)가 프로세스되면 삭제된다. 다른 실시예에서, 복수의 장애 조치 이벤트들이 이용되고, 각각은 다른 배치 유형과 관련된다. 이러한 실시예에서, 새로운 배치가 큐 테 이블에 입력될 때 장애 조치 이벤트가 추가되고, 그 장애 조치 이벤트는 그 배치에 대한 프로세싱이 완료되면 삭제된다.

예시적인 목적을 위해 위에서 특정 시간 길이가 제공되었지만, 장애 조치 이벤트에 대한 만료 시간 및 장애 조치 보호 모듈의 동작의 빈도(frequency)는 서로 다른 실시예들에 따라 다르다. 몇몇 실시예에서, 이 시간들은 사용자가 구성가능하여, 시스템 관리자가 이 검사들이 수행되는 빈도를 결정할 수 있다.

작업 아이템 이벤트 모니터

이제 도 4를 참조하면, 일 실시예에 따라 작업 아이템 이벤트 모니터에 대한 블록도가 도시된다. 작업 아이템 이벤트 모니터(400)가 특정한 방식으로 배치된 특정 컴포넌트들을 갖는 것으로 도시되었지만, 작업 아이템 이벤트 모니터(400)는 제한적인 것이 아니라 예시적인 것으로서 의도된 것으로 이해되어야 한다. 다른 실시예에서, 작업 아이템 이벤트 모니터는 다른 컴포넌트들을 갖고/거나 다른 방식으로 배치된 컴포넌트들을 갖는다.

도시된 실시예에서, 작업 아이템 모니터(400)는 백 엔드 서버, 예를 들어, 백 엔드(220)의 일부로서 실행된다. 다른 실시예에서, 작업 아이템 이벤트 모니터(400)는 대안적인 위치에서 실행될 수 있다.

작업 아이템 이벤트 모니터(400)는 입력 모듈(410)을 갖는 것으로 도시된다. 도시된 실시예에서, 입력 모듈(410)은 작업 아이템 이벤트 모니터(400)가 프런트 엔드 애플리케이션, 예를 들어, 프런트 엔드(210)로부터 이벤트들을 수신할 수 있도록 한다. 작업 아이템 이벤트 모니터(400)는 또한 출력 모듈(490)을 갖는데, 이 는 몇몇 실시예에서 이벤트들을 적절한 이벤트 핸들러, 예를 들어, 데이터 저장소(230) 내의 객체에 배정(dispatch)하기 위해 사용된다.

작업 아이템 이벤트 모니터(400)는 또한 큐 테이블(420)을 갖는 것으로 도시된다. 큐 테이블(420)은 프런트 엔드 애플리케이션으로부터 수신된 이벤트들을 대기열에 넣는 데(queue up) 사용된다. 작업 아이템 이벤트 모니터(400)는 또한 다수의 배치 테이블(425a 내지 425n)을 갖는 것으로 도시된다. 이 배치 테이블들을 포함하는 몇몇 실시예에서, 각 배치 테이블은 특정 배치 유형과 관련되고, 그 배치 유형의 이벤트들의 핸들링과 관련된 정보를 저장하는 데 사용된다.

작업 아이템 이벤트 모니터(400)는 입력 모듈(410)로부터 수신된 입력을 모니터링하고 새로운 이벤트들을 식별하는 새로운 이벤트 모니터(430)를 통합한다. 도시된 바와 같이, 작업 아이템 이벤트 모니터(400)는 큐 정렬 모듈(435)을 포함한다. 몇몇 실시예에서, 큐 정렬 모듈(435)은 효율성 증가를 위해 큐 테이블(420) 내에 이벤트들을 배열(arrange)한다. 다른 실시예에서, 큐 정렬 모듈(435)은 큐 테이블(420)에 대해 인덱스 파일을 변경한다.

작업 아이템 이벤트 모니터(400)는 또한 이벤트 배정 모듈(440)을 포함한다. 이벤트 배정 모듈(440)은 큐 테이블(420)을 액세스하고, 핸들링되어야 할 이벤트들을 식별한다. 도시된 바와 같이, 이벤트 배정 모듈(440)은 여러 타이머 작업(441a 내지 441n)을 통합한다. 몇몇 실시예에서, 각 배치 유형은 개별적인 관련된 타이머 작업(441)을 갖는다. 다른 실시예에서, 다른 수의 타이머 작업(441)들이 이용된다.

작업 아이템 모니터(400)는 또한 장애 조치 보호 모듈(450)을 포함한다. 장애 조치 보호 모듈(450)은 큐 테이블(424)의 만료된 장애 조치 이벤트들을 모니터링한다.

작업 아이템 이벤트 모니터의 동작

이제 도 5를 참조하면, 일 실시예에 따라 작업 아이템 이벤트 모니터의 사용의 방법에 대한 흐름도(500)가 도시된다. 구체적 단계들이 흐름도(500)에 개시되지만, 이러한 단계들은 예시적인 것이다. 즉, 본 발명의 실시예들은 다양한 다른 (추가적인) 단계들 또는 흐름도(500)에 명시된 단계들의 변경을 수행하기에 적합하다. 흐름도(500)의 단계들은 제시된 것과 다른 순서로 수행될 수 있으며, 흐름도(500)의 모든 단계들이 수행되지는 않을 수 있음을 이해해야 한다.

이제 단계(510)와 도 2 및 도 4를 참조하면, 작업 아이템 이벤트 모니터는 새로운 이벤트를 수신한다. 예를 들어, 프런트 엔드(210)는 이벤트를 백 엔드(220)에 서브밋(submit)하고, 이는 입력 모듈(410)에 의해 수신된다.

이제 단계(520) 및 도 4를 참조하면, 새로운 이벤트 플래그가 업데이트된다. 몇몇 실시예에서, 새로운 이벤트 플래그는 수신된 작업 아이템 이벤트의 유형에 대응된다. 예를 들어, 수신된 이벤트가 워크플로 유형인 경우, 새로운 이벤트 모니터(430)는 워크플로 유형에 대응하는 배치 테이블(425) 내의 플래그를 업데이트 할 것이다.

이제 단계(530) 및 도 4를 참조하면, 새로운 이벤트가 큐 테이블에 추가된다. 예를 들어, 새로운 이벤트 모니터(430)는 수신된 이벤트를 큐 테이블(420)에 전달한다.

단계(540) 및 도 4를 참조하면, 큐 테이블은 배치 유형에 기초하여 정렬된다. 몇몇 실시예에서, 동일한 배치 유형의 모든 이벤트들 및 동일 또는 유사한 만료 시간을 갖는 이벤트들이 함께 그루핑된다. 예를 들어, 작업 아이템 이벤트 모니터(400)가 만료 시간이 과거인 워크플로 유형의 여러 이벤트들을 수신하면, 이 이벤트들은 함께 프로세스되도록 그루핑된다.

단계(550) 및 도 4를 참조하면, 프로세싱을 위해 이벤트들이 선택된다. 몇몇 실시예에서, 이벤트들은 작업 유형 및 만료 시간에 기초하여 큐 테이블로부터 선택된다. 여러 이러한 실시예에서, 현재 프로세스되고 있지 않은 이벤트들만이, 예를 들어, 이미 프로세스되고 있는 것으로 마킹되지 않은 이벤트들만이 선택된다. 예를 들어, 이벤트 배정 모듈(440)은, 이미 프로세스되고 있는 것으로 마킹되어 있지 않고, 큐 테이블(420)로부터 지금 실행되도록 스케줄링(scheduled)된, 워크플로 유형의 모든 이벤트들을 선택한다.

몇몇 실시예에서, 이벤트 선택은 타이머에 의해 트리거(trigger)된다. 몇몇 이러한 실시예에서, 복수의 타이머들이 사용되고, 특정 이벤트 유형은 자신만의 타이머를 가질 수 있다. 예를 들어, 워크플로 유형과 관련된 타이머 작업(441a)은 리셋되거나 만료될 때마다 워크플로 유형 이벤트들에 대한 선택을 트리거한다. 다른 실시예에서, 단일 타이머가 사용된다. 몇몇 실시예에서, 이벤트 선택은 다른 방법으로 트리거된다.

이제 단계(560) 및 도 4를 참조하면, 선택된 이벤트들은 프로세스되고 있는 것으로 마킹된다. 상술된 바와 같이, 다양한 실시예에서, 이 단계는 다수의 포인트(point)로 구현될 수 있다. 예를 들어, 이벤트 배정 모듈(440)은 큐 테이블(420) 내의 선택된 워크플로 이벤트들을 GUID로 마킹함으로써 식별한다.

이제 단계(570) 및 도 4를 참조하면, 선택된 이벤트들은 적절한 이벤트 핸들러에 전달된다. 예를 들어, 이벤트 배정 모듈(440)에 의해 선택된 이벤트들은 프로세싱을 위해 출력 모듈(490)에 전달된다.

장애 조치 보호의 이용

이제 도 6을 참조하면, 일 실시예에 따라, 장애 조치 보호를 이용한 실패 복구 방법에 대한 흐름도(600)가 제시된다. 흐름도(600)에 구체적 단계들이 개시되지만, 이러한 단계들은 예시적인 것이다. 즉, 본 발명의 실시예들은 다양한 다른 (추가적인) 단계 또는 흐름도(600)에 명시된 단계들의 변경을 수행하기에 적합하다. 흐름도(600)의 단계들은 제시된 것과 다른 순서로 수행될 수 있고, 흐름도(600)의 모든 단계들이 수행되어야 하는 것은 아니라는 것을 이해해야 한다.

이제 단계(610) 및 도 4를 참조하면, 장애 조치 이벤트는 큐 테이블에 추가된다. 상술된 바와 같이, 이 이벤트를 추가하기 위한 메커니즘은 서로 다른 실시예들에 따라 다르다. 몇몇 실시예에서, 장애 조치 이벤트는 새로운 이벤트가 큐 테이블에 추가될 때마다 추가된다. 다른 실시예에서, 장애 조치 이벤트는 프로세싱을 위해 이벤트들의 배치가 선택될 때 추가된다. 예를 들어, 새로운 이벤트가 입력 모듈(410)에 의해 수신되고 새로운 이벤트 모니터(430)에 전달되고 큐 테이블(420)에 추가될 때, 및 배치 테이블(425)에서의 프로세싱을 위해 복수의 이벤트 들이 선택될 때, 장애 조치 이벤트가 큐 테이블(420)에 추가된다.

이제 단계(620) 및 도 4를 참조하면, 장애 조치 이벤트가 업데이트된다. 상술된 바와 같이, 장애 조치 이벤트는 사전 설정된(preset) 만료 시간을 가지고 큐 테이블에 추가된다. 장애 조치 이벤트가 만료되도록 허락되면, 이는 시스템이 어떠한 방식으로 실패하였음을 나타낸다. 시스템이 정상적으로 수행하면, 장애 조치 이벤트는 만료되기 전에 업데이트되고, 만료 시간은 리셋된다. 몇몇 실시예에서, 장애 조치 이벤트는 큐 테이블이 액세스될 때마다 업데이트된다. 다른 실시예에서, 장애 조치 이벤트는 장애 조치 이벤트가 관련된 이벤트 유형에 대해 큐 테이블이 액세스되는 경우에 업데이트된다. 몇몇 다른 실시예에서, 앞서 설명된 바와 같이, 장애 조치 이벤트는 장애 조치 이벤트 보호에 의해 업데이트된다.

이제 단계(630) 및 도 4를 참조하면, 장애 조치 이벤트가 삭제된다. 몇몇 실시예에서, 장애 조치 이벤트는 장애 조치 이벤트와 관련된 배치의 프로세싱이 완료되었을 때 삭제된다. 몇몇 다른 실시예에서, 이는 큐 테이블에 이벤트들이 남아있지 않을 때 발생한다. 예를 들어, 장애 조치 이벤트를 제외하고 큐 테이블(420)이 비어있는 경우, 장애 조치 이벤트는 삭제된다. 몇몇 실시예에서, 이는 장애 조치 보호 모듈(450)에 의해 이루어진다. 다른 실시예에서, 이 태스크는 이벤트 배정 모듈(440)에 의해 수행된다. 다른 실시예에서, 장애 조치 이벤트를 큐 테이블로부터 제거하기 위해 다른 수단들이 사용된다.

각 이벤트 유형이 관련된 장애 조치 이벤트를 갖는 경우를 포함하는 다른 실시예에서, 장애 조치 이벤트는 관련된 이벤트 유형의 이벤트들이 더 이상 큐 테이 블에 남아있지 않은 경우에 제거된다.

흐름도(600)에 도시된 바와 같이, 단계들(650, 660, 및 670)은 루프되어(looped) 있고, 단계(620)와 나란히 실행된다. 다른 실시예에서, 단계들은 다른 시퀀스로 수행될 수 있다.

이제 단계(650) 및 도 4를 참조하면, 만료된 장애 조치 이벤트들에 대해 큐 테이블이 주기적으로 검사된다. 예를 들어, 장애 조치 보호 모듈(450)은 큐 테이블(420)을 모니터링하여, 만료된 장애 조치 이벤트들에 대해 큐 테이블(420)을 매 5분마다 검사한다. 장애 조치 이벤트가 큐 테이블에 존재하고 만료된 경우, 시스템은 이벤트들이 큐 테이블에 남아있지만, 장애 조치 이벤트가 마지막으로 업데이트된 이후로 큐 테이블에 대한 성공적인 액세스가 발생하지 않았음을 안다.

이제 단계(660) 및 도 4를 참조하면, 만료된 장애 조치 이벤트들이 발생하지 않는 경우, 큐 테이블의 현재 상태가 저장된다. 예를 들어, 장애 조치 보호 모듈(450)이 큐 테이블(420)을 검사하여 아무런 만료된 장애 조치 이벤트를 찾지 못하면, 큐 테이블(420)의 현재 상태가 좋은 것으로 알려지고, 저장된다. 몇몇 실시예에서, 장애 조치 이벤트가 성공적으로 업데이트될 때마다 큐 테이블의 상태는 백업되고, 예를 들어, 큐 테이블이 프로세스 중에 액세스될 때마다 장애 조치 이벤트가 업데이트되고, 큐 테이블의 현재 상태가 백업된다.

이제 단계(670) 및 도 4를 참조하면, 만료된 장애 조치 이벤트가 큐 테이블 내에 위치하는 경우, 큐 테이블은 저장된 상태로 되돌아간다. 예를 들어, 만약 장애 조치 보호 모듈(450)이 큐 테이블(420) 내에 만료된 장애 조치 이벤트를 검출하 면, 큐 테이블(420)은 마지막 저장된 "좋은" 상태, 예를 들어, 장애 조치 이벤트가 업데이트된 마지막 상태로 되돌아가야 한다. 몇몇 실시예에서, 만료된 장애 조치 이벤트가 검출되면 작업 아이템 이벤트 모니터는 추가적인 동작들을 수행한다.

본 발명은 구조적 특징 및/또는 방법론적 동작들에 있어 구체적인 언어로 설명되었지만, 첨부된 청구항들에 정의된 본 발명은 반드시 위에서 설명된 구체적 특징 또는 동작들로 제한되지 않음을 이해해야 한다. 오히려, 위에서 설명된 구체적 특징 및 동작들은 청구항들을 구현하기 위한 예시적인 형태로서 개시된 것이다.

Claims

컴퓨팅 환경에서의 이벤트 모니터(event monitor)- 상기 이벤트 모니터는 처리될 큐 이벤트(queued event)를 추적함 -의 동작의 방법으로서,

상기 이벤트 모니터에서 이벤트를 수신하는 단계- 상기 이벤트는 특정 이벤트 유형에 대한 이벤트 유형 속성을 포함함 -;

상기 이벤트의 상기 이벤트 유형 속성에 기초하여 새로운 이벤트 플래그(flag)를 업데이트하는 단계- 상기 새로운 이벤트 플래그는 상기 특정 이벤트 유형에 대응하고, 처리될 상기 특정 이벤트 유형의 새로운 이벤트가 수신되었음을 나타냄 -;

상기 이벤트를 큐 테이블(queuing table)에 추가하는 단계- 상기 큐 테이블은 복수의 이벤트 유형에 대해 처리될 복수의 이벤트를 포함함-;

상기 처리될 특정 이벤트 유형의 새로운 이벤트가 존재함을 나타내는 상기 새로운 이벤트 플래그에 기초하여 상기 큐 테이블을 액세스하지 않고 상기 큐 테이블이 상기 특정 이벤트 유형의 하나 이상의 이벤트를 포함하고 있음을 판정하는 단계;

상기 큐 테이블로부터 상기 특정 이벤트 유형의 처리할 하나 이상의 이벤트를 선택하여, 함께 처리될 상기 특정 이벤트 유형의 상기 선택된 이벤트들의 그룹을 생성하는 단계; 및

상기 큐 테이블 내에서, 상기 선택된 이벤트들의 그룹이 처리되고 있음을 나타내도록 상기 선택된 이벤트들의 그룹을 마킹(marking)하는 단계

를 포함하는 이벤트 모니터의 동작의 방법.
제1항에 있어서,

이벤트 유형에 따라 상기 큐 테이블을 정렬(ordering)하는 단계를 더 포함하는

이벤트 모니터의 동작의 방법.
제2항에 있어서,

상기 특정 이벤트 유형의 상기 하나 이상의 이벤트의 만료 시간(expiration time)에 기초하여 상기 특정 이벤트 유형의 상기 하나 이상의 이벤트를 선택하는 단계를 더 포함하는

이벤트 모니터의 동작의 방법.
제1항에 있어서,

상기 새로운 이벤트는 만료 시간을 포함하는

이벤트 모니터의 동작의 방법.
제4항에 있어서,

상기 선택하는 단계는 상기 만료 시간을 갖는 상기 복수의 이벤트들 중 하나 이상을 식별하는 단계를 포함하는

이벤트 모니터의 동작의 방법.
제1항에 있어서,

상기 선택된 이벤트들의 그룹을 출력하는(outputting) 단계를 더 포함하는

이벤트 모니터의 동작의 방법.
컴퓨팅 장치로 하여금 청구항 제1항의 방법을 수행하게 하는 컴퓨터 실행가능 명령어를 저장하는 컴퓨터 판독가능 저장 매체.
컴퓨팅 환경에서의 이벤트 모니터(event monitor)- 상기 이벤트 모니터는 처리될 큐 이벤트를 추적함 -의 동작의 방법으로서,

상기 이벤트 모니터에서 이벤트를 수신하는 단계- 상기 이벤트는 특정 이벤트 유형에 대한 이벤트 유형 속성을 포함함 -;

상기 이벤트의 상기 이벤트 유형 속성에 기초하여 새로운 이벤트 플래그를 업데이트하는 단계- 상기 새로운 이벤트 플래그는 상기 특정 이벤트 유형에 대응하고, 처리될 상기 특정 이벤트 유형의 새로운 이벤트가 수신되었음을 나타냄 -;

상기 이벤트를 큐 테이블에 추가하는 단계- 상기 큐 테이블은 복수의 이벤트 유형에 대해 처리될 복수의 이벤트를 포함함 -;

상기 큐 테이블로부터 상기 특정 이벤트 유형의 처리할 하나 이상의 이벤트를 선택하여, 함께 처리될 상기 특정 이벤트 유형의 상기 선택된 이벤트들의 그룹을 생성하는 단계; 및

상기 큐 테이블 내에서, 상기 선택된 이벤트들의 그룹이 처리되고 있음을 나타내도록 상기 선택된 이벤트들의 그룹을 마킹하는 단계;

상기 큐 테이블에 장애 조치(failover) 이벤트를 추가하는 단계- 상기 장애 조치 이벤트는 만료 타이머를 포함함 -;

상기 큐 테이블의 정상 상태를 저장하는 단계;

상기 장애 조치 이벤트 및 상기 만료 타이머를 모니터링하는 단계; 및

상기 만료 타이머가 경과한 경우, 상기 큐 테이블을 상기 정상 상태로 복원시키는 단계

를 포함하는 이벤트 모니터의 동작의 방법.
제8항에 있어서,

상기 큐 테이블의 성공적인 액세스 시에 상기 만료 타이머를 리셋하는(resetting) 단계를 더 포함하는

이벤트 모니터의 동작의 방법.
제9항에 있어서,

상기 큐 테이블의 상기 정상 상태를 업데이트하는 단계를 더 포함하는

이벤트 모니터의 동작의 방법.
제10항에 있어서,

상기 정상 상태를 업데이트하는 단계는 상기 만료 타이머를 성공적으로 리셋할 때에 발생하는

이벤트 모니터의 동작의 방법.
제8항에 있어서,

상기 모니터링하는 단계는 상기 큐 테이블을 주기적으로 액세스하는 단계를 포함하는

이벤트 모니터의 동작의 방법.
제8항에 있어서,

상기 장애 조치 이벤트를 추가하는 단계는 상기 큐 테이블로부터 이벤트를 처리하는 것에 대한 응답인,

이벤트 모니터의 동작의 방법.
제13항에 있어서,

상기 처리가 완료되었을 때에 상기 장애 조치 이벤트를 상기 큐 테이블로부터 삭제하는 단계를 더 포함하는

이벤트 모니터의 동작의 방법.
컴퓨팅 장치로 하여금 청구항 제8항의 방법을 수행하게 하는 컴퓨터 실행가능 명령어를 저장하는 컴퓨터 판독가능 저장 매체.
컴퓨팅 환경에서 처리될 큐 이벤트를 추적하는 작업 아이템 이벤트 모니터(work item event monitor)로서,

상기 작업 아이템 이벤트 모니터는 메모리에 저장된 컴퓨터 실행가능 컴포넌트를 실행하는 처리 유닛을 포함하고,

복수의 이벤트 유형에 대해 처리될 복수의 큐 이벤트(queued event)를 저장하기 위한 큐 테이블;

상기 큐 테이블에 연결되고, 상기 큐 테이블로의 큐 이벤트의 추가를 검출하는 새로운 이벤트 모니터- 상기 큐 이벤트는 특정 이벤트 유형에 대한 이벤트 유형 속성을 포함함 -;

상기 특정 이벤트 유형에 대응하고, 상기 새로운 이벤트 모니터에 연결되며, 처리될 상기 특정 이벤트 유형의 새로운 큐 이벤트가 상기 큐 테이블에 추가되었음을 표시하는 새로운 이벤트 플래그; 및

상기 큐 테이블로부터 상기 특정 이벤트 유형의 처리할 하나 이상의 이벤트를 선택하여, 함께 처리될 상기 특정 이벤트 유형의 상기 선택된 이벤트들의 그룹을 생성하고, 상기 큐 테이블 내에서, 상기 선택된 이벤트들의 그룹이 처리되고 있음을 나타내도록 상기 선택된 이벤트들의 그룹을 마킹(marking)하는, 상기 큐 테이블에 연결된 이벤트 배정기(event dispatcher)를 포함하고,

상기 작업 아이템 이벤트 모니터는

상기 큐 테이블에 장애 조치 이벤트를 추가- 상기 장애 조치 이벤트는 만료 타이머를 포함함 -하고,

상기 큐 테이블의 정상 상태를 저장하고,

상기 장애 조치 이벤트 및 상기 만료 타이머를 모니터링하며,

상기 만료 타이머가 경과한 경우, 상기 큐 테이블을 상기 정상 상태로 복원시키는

작업 아이템 이벤트 모니터.
제16항에 있어서,

상기 이벤트 배정기는 상기 특정 이벤트 유형의 상기 하나 이상의 이벤트의 만료 시간에 기초하여 상기 큐 테이블로부터 상기 특정 이벤트 유형의 상기 하나 이상의 이벤트를 선택하는

작업 아이템 이벤트 모니터.
제16항에 있어서,

상기 새로운 이벤트 플래그를 포함하기 위한, 상기 새로운 이벤트 모니터에 연결된 배치 테이블(batch table)을 더 포함하는

작업 아이템 이벤트 모니터.
제16항에 있어서,

상기 이벤트 배정기는 타이머를 더 포함하고, 상기 타이머는 상기 큐 이벤트를 언제 선택해야하는지를 표시하는

작업 아이템 이벤트 모니터.
제16항에 있어서,

상기 큐 테이블의 성공적인 액세스 시에 상기 장애 조치 이벤트를 업데이트하고 상기 만료 타이머를 리셋하기 위한, 상기 큐 테이블에 연결된 장애 조치 보호 모니터(failover guard monitor)를 더 포함하는

작업 아이템 이벤트 모니터.