KR20100081305A - 이벤트들에 의해 결정되는 작업들의 실행 스케줄링을 위한 방법, 시스템 및 컴퓨터프로그램 - Google Patents

Abstract

데이터 처리 시스템의 스테줄링 실체 제어 하에 데이터 처리 시스템의 타겟 실체들(예를 들어, 워크스테이션들) 상에서의 작업들의 실행 스케줄링을 위한 솔루션이 제공된다. 대응 방법(400)으로 플랜을 제공하는 단계(406 내지 409)로 시작하는데, 플랜은 작업들 세트의 실행 흐름을 정의한다. 방법은 플랜에 따라 선택된 타겟 실체 상에서의 작업 실행을 위해 각각의 작업을 제출하는 단계(466 내지 475)를 계속한다. 또한 한 세트의 규칙이 제공되는데(412 내지 415); 각각의 규칙은 이벤트 타겟 실체에서의 이벤트에 반응하여 동작 타겟 실체에서 실행될 동작을 정의한다. 그 다음, 방법은 규칙들에 각각의 이벤트 타겟 실체에 대해서 정의된 이벤트들을 결정하는 단계(421)를 포함한다. 다음으로, 각각의 이벤트 타겟 실체가 인에이블되어(enabled) 대응 이벤트들을 검출한다. 이제 대응 이벤트의 검출에 반응하여 대응 동작 타겟 실체 상에서의 각각의 동작의 실행이 트리거된다(triggered).

Description

이벤트들에 의해 결정되는 작업들의 실행 스케줄링을 위한 방법, 시스템 및 컴퓨터프로그램{METHOD, SYSTEM AND COMPUTER PROGRAM FOR SCHEDULING EXECUTION OF JOBS DRIVEN BY EVENTS}

본 발명은 데이터 처리 분야에 관한 것이다. 더 자세하게는, 본 발명은 데이터 처리 시스템에 있는 작업들의 실행 스케줄링에 관한 것이다.

워크로드 스케줄러들(workload schedulers)(또는 간단히 스케줄러들)은, 통상, 데이터 처리 시스템에서 방대한 양의 작업들(jobs)의 실행을 제어하기 위해 사용된다. 상업적 스케줄러의 예시로는 IBM 사의 "IBM Tivoli Workload Schedulers (TWS)"가 있다.

상기 작업들(jobs)은 상기 시스템에서 실행될 수 있는 어떤 종류의 워크 유닛들(work units)로도 구성될 수 있다. 상기 스케줄러는, 예를 들어, US-A-7,150,037에 설명된 바와 같이, (네트워크 구성 매니지먼트 시스템에서) 네트워크 장치들에 구성파일들(configuration files)의 다운로딩(downloading)을 제어하기 위해서 사용된다. 여기서 각각의 구성파일은 대응 정책들(corresponding policies)을 조사하여(by evaluating) 동적으로 생성되며, 상기 정책들은 하나 또는 그 이상의 규칙들(rules)로 구성된다; 각 규칙(each rule)은 조건들(conditions)(인프라구조 데이터베이스에서 대응 네트워크 장치들을 확인하는(identify) 방법을 결정하기 위한), 동작들(actions)(바람직한 구성 파라미터들을 세트(set)하는 방법을 결정하기 위한), 검증들(verifications)(네트워크 구성을 검증하는 동안, 이에 대응 네트워크 장치들의 규칙들 및 실제 구성들 간의 어떤 불일치점(any discrepancy)을 판단하는 방법을 결정하기 위한)을 포함한다.

스케줄러(scheduler)는, 통상, 중앙스케줄링서버로부터 다수의 워크스테이션들(multiple workstations)에서의 작업들의 실행을 제어한다; 각 작업(job)에 대한 워크스테이션은 상기 작업이 실행을 위해 제출된 때, 정적으로(statically) 정의되거나 혹은 동적으로(dynamically) 선택될 수 있다(요구한 특징들을 갖춘 모든 이용가능한 것들 중에서 선택됨). 후자의(latter) 솔루션이 쉽게 확장가능하고(easily scaleable) 신뢰도가 높은 시스템들을 구현할 수 있게 한다; 또한 워크스테이션들에서 작업들의 분산(distribution)을 최적화하기 위해 워크로드 밸런싱(workload balancing) 기술들이 사용될 수 있다.

작업들의 제출(submission)은 미리 정의된 워크로드 플랜(workload plan)(또는 간단히 플랜(plan))에 따라 제어된다. 상기 플랜은, 시간적 제한들(temporal constraints)(즉, 날짜 및/또는 시간)에 기초한, 작업들의 실행의 흐름을 정한다(establishes); 여기서, 상기 작업들의 실행은 또한 선행 조건들(dependencies)(예들 들어, 선행하는 작업들의 완료와 같은)을 조건으로 할 수도 있다.

그러나, 상기 스케줄러들은 플랜 상에 정의되지 않은 작업들의 실행을 제어하는 데에는 전혀 유효하지 않다(completely ineffective). 이는 작업을 실행할 필요가 미리 알려져 있지 않은 경우에는 문제가 된다(왜냐하면, 예를 들어, 특정한 이벤트의 발생으로 작업이 트리거되는(triggered) 경우도 있기 때문이다).

스케줄에 기초하여 혹은 특정 이벤트들(events)의 발생에 반응하여 태스크들(tasks)의 실행을 제어하는 것에 관한 일반적인 아이디어는, US-A-7,146,350에 기재된 특정 응용프로그램에서 이미 제안되었다. 특히 상기 문헌에는 기업의 정보통신기술(IT) 인프라구조를 감사하기(auditing) 위한 시스템이 개시되어 있다. 이 목적으로, 상기 시스템의 서버는 상기 IT 인프라구조의 특정 자원들에 대한 정적 또는 동적 어세스먼트들(assessments)(대응 정책들에 정의된 스텝들의 시퀀스들을 포함)의 실행을 제어한다. 상기 어세스먼트들(assessments)은 통상, 날짜 정보, 즉 년(year), 일(date), 및 시(time) 정보를 제공하기 위해서 스케줄러를 사용함으로써(by exploiting) 트리거될 수 있다(triggered); 또한 다른 실시예로서, 상기 시스템의 노드들(nodes)에서 검출된 미리 정의된 이벤트들(events)에 의해 동일 어세스먼트들이 트리거될 수도 있다(be triggered). 이를 위해 노드 각각은 관심의 대상이 되는(interest) 모든 가능한 이벤트들을 모니터해야만한다. 다음으로, 모니터를 통해서 획득된 정보가 여러(different) 노드들로부터 서버에 수집된다. 그러나, 이 경우에는 노드들에서 오버헤드(이벤트들을 검출하기 위해)를 초래하거나 혹은 상기 서버에서 오버헤드(검출된 이벤트들을 수집하기 위해)를 초래할 수 있다; 또한, 이벤트들을 수집하기 위해서 노드들에서 서버로 전송되는 방대한 정보량은 심각한 네트워크 트래픽의 증가를 수반한다.

본 발명은, 일반적으로(in its general terms), 플랜을 따라서 혹은 이벤트에 반응하여서 작업들의 스케줄링을 지원하는 것을 목표로 한다.

특히, 본 발명의 다양한 실시예들은 첨부된 특허청구범위의 독립항들에 기재된 하나의 솔루션을 제공한다. 또한 본 발명의 바람직한 실시예들은 종속항들에 기재되어 있다.

더욱 상세하게 설명하면, 본 발명의 한 실시 예는, 데이터 처리 시스템의 스케줄링 실체(예를 들어 스케줄링 서버)의 제어 하에, 상기 시스템의 타겟 실체들(예를 들어 워크스테이션들) 상에서 작업들의 실행을 스케줄링하기 위한 방법을 제공한다. 상기 방법은 플랜을 제공하는 단계로 시작하는데, 상기 플랜은 작업들 세트의 실행 흐름을 정의한다. 상기 방법은, 상기 플랜에 따라, 선택된 타겟 실체에서의 실행을 위한 각각의 작업을 제출함으로써 계속된다. 또한 한 세트의 규칙들(rules)이 제공되는데; 각 규칙은 이벤트 타겟 실체(an event target entity) 상에서의 어떤 이벤트(an event)에 반응하여 동작 타겟 실체(an action target entity) 상에서 실행될 어떤 동작(an action)을 정의한다. 다음으로, 상기 방법은 상기 규칙들에서 각각의 이벤트 타겟 실체에 대해서 정의된 이벤트들을 결정하는 단계를 포함한다. 그 다음, 이벤트 타겟 실체 각각은 대응 이벤트들을 검출할 수 있다. 그 다음, 상기 대응 이벤트의 검출(detection)에 반응하여 그에 대응 동작 타겟 실체에서의 각각의 동작의 실행이 트리거된다(triggered).

예를 들어, 상기 동작들(actions)은 플랜에서 전혀(even) 정의되지 않은 추가적인 작업들로 구성될 수 있다.

일 실시예에서, 각각의 (이벤트) 워크스테이션은 상기 대응 이벤트들을 검출할 수 있는데, 이는 그 곳에서 실행되는 하나 또는 그 이상의 검출 모듈을 위한 구성구조(configuration structure)를 배치함으로써(by deploying) 그렇게 할 수 있다.

이 실시 예에서 추가적인 개선점은, 구성구조가 상기 워크스테이션 상에서 이미 이용가능한 이전 버전(previous versions)과 동일한 경우 상기 구성구조의 배치는 일어나지 않는다(is prevented)는 것이다.

이 목적을 위해, 상기 구성구조의 두 버전에 관한 다이제스트 값(digest values)을 비교할 수 있다..

본 발명의 일 실시예에서, 서버는 각각의 (이벤트) 워크스테이션으로부터 각각의 이벤트에 대한 통지(notification)를 수신하여, 다음으로, 관련된 (동작) 워크스테이션에서의 동작 실행을 위해 그에 대응 동작을 제출한다.

본 발명의 솔루션의 추가적인 장점은 상기 규칙들(rules)을 모니터하여서, 상기 규칙들과 관련한 모든 변경에 응답하여서만 상기 설명한 동작들을 수행한다는 것이다.

또한 본 발명의 추가적인 장점은 이들 동작들이 변경된 규칙들로 인해 임팩트된(impacted) (이벤트) 워크스테이션들로 제한된다는 것이다.

본 발명의 또 다른 실시예로서 상기 설명한 방법을 수행하기 위한 컴퓨터프로그램이 제공된다.

본 발명의 또 다른 실시예로서 대응 시스템이 제공된다.

본 발명의 특징들과 이점들(추가적인 특징들 및 이점들을 포함함)은 첨부된 도면들 및 이와 함께 이하의 상세한 설명(설명을 위한 목적으로 기재된 것임)을 참조하면 쉽게 이해될 수 있을 것이다. 여기서:
도 1은, 본 발명의 일 실시 예에 따른 솔루션이 적용될 수 있는 데이터 처리 시스템의 개략적인 블록도이다,
도 2는, 상기 데이터 처리 시스템의 일 실시예 컴퓨터의 기능적인 블록들(functional blocks)을 도시한다.
도 3은, 본 발명의 일 실시 예에 따른 솔루션을 실행하기 위해서 사용될 수 있는 메인 소프트웨어 컴포넌트들(main software components)을 도시한다.
도 4a 및 도 4b는, 본 발명의 일 실시 예에 따른 솔루션의 구현에 관한 동작들(activities)의 흐름을 도시한다.

도 1을 참조하면, 도 1은 데이터 처리 시스템(100)의 분산된 구조(distributed architecture)를 도시한다. 시스템(100)은 스케줄링 서버(105)(또는 간단히 서버)를 포함하는데, 이는 시스템(100)에서 실행되는 작업들을 제어하기 위해서 사용된다; 통상, 상기 작업들은 배치(batch)(즉, 비쌍방향(non-interactive)) 어플리케이션들 -예를 들어 비용 분석 프로그램들- 을 포함한다. 상기 작업들은 서버(105)의 제어하에 다수의 타겟 워크스테이션들(또는 간단히 워크스테이션들)(110)에서 실행된다. 이를 위해 서버(105) 및 워크스테이션들(110)은 네트워크(예를 들어 LAN)(115)를 통해서 서로 통신한다.

이제 도 2를 참조하면, 도 2는 상기 설명한 시스템의 범용 컴퓨터(generic computer)(200)를 도시한다. 컴퓨터(200)는 몇몇 유닛들로 구성되는데, 여기서 유닛들(units)은 시스템 버스(205)(시스템의 컴퓨터(200)의 실제 기능에 따라 크기가 적절히 조절되는(suitably scaled) 구조를 가짐)에 병렬로(in parallel) 연결되어 있다. 더 상세히 설명하면, 컴퓨터(200)은 다음의 부품을 포함한다. 즉, 컴퓨터(200)의 동작을 제어하는 하나 또는 그 이상의 마이크로프로세서(μP)(210); 마이크로프로세서(210)에 의해 워킹메모리로 직접 사용되는 RAM(215); 및 컴퓨터(200)의 부트스트랩(bootstrap)을 위해 베이직 코드를 저장하는 ROM으로 이루어져 있다. 또한 몇몇 주변장치 유닛들(peripheral units)이 로컬버스(225) 주위에 연결되어 있다(개별 인터페이스 수단들에 의해서 연결됨). 특히, 대량 메모리(a mass memory)는 하나 또는 그 이상의 하드-디스크들(hard-disks)(230) 및 CD-ROM들(240)을 판독하기 위한 드라이브들(drives)(235)로 구성된다. 또한, 컴퓨터(200)은 입력 유닛들(245)(예를 들어, 키보드 혹은 마우스), 및 출력 유닛들(250)(예를 들어, 모니터 혹은 프린터)을 포함한다. 어댑터(adapter)(255)는 컴퓨터(200)을 네트워크(도시되지 않음)에 접속하기 위해서 사용된다. 또한 브릿지(bridge)(260)은 로컬버스(225)를 시스템버스(205)에 인터페이스한다. 각각의 마이크로프로세서(210) 및 브릿지유닛(260)은 정보를 전송하기 위해서 시스템버스(205)로의 접근을 요청하는 마스터 에이전트들(master agents)로 동작할 수 있다(can operate). 또한 아비터(arbiter)(265)는 시스템버스(205)에 대하여 상호 배타성(mutual exclusion)을 갖는 접근의 승인(granting)을 관리한다.

이제 도 3을 참조하면, 도 3은 본 발명의 일 실시 예에 따른 솔루션을 구현하기 위해 사용될 수 있는 메인 소프트웨어 컴포넌트들을 참조번호(300)으로 하여 전면적으로 도시한다. 정보(프로그램 혹은 데이터)는 통상 하드-디스크 상에 저장되어 있다가, 운영 시스템(operating system) 및 다른 응용 프로그램들(도시되지는 않음)과 함께 프로그램이 실행될 때, 각 컴퓨터의 워킹 메모리에 로드된다(적어도 부분적으로). 프로그램들은 초기에 하드 디스크에 인스톨되는데(installed), 예를 들어 CD-ROM으로부터 인스톨된다.

상세한 설명은 다음과 같다. 서버(105)는 스케줄러(305)(예를 들어, 상기 언급한 TWS)를 실행한다.

스케줄러(305)는 구성기(configurator)(310)(예를 들어, TWS의 "구성자(composer)")를 포함하는데, 이는 워크로드 데이터베이스(315)(적합한 제어 언어 -예를 들어 XML언어- 로 작성된다)를 유지하기(maintain) 위해서 사용된다. 워크로드 데이터베이스(315)는 스케줄러(305)에서 이용가능한 모든 워크스테이션들에 관한 정의(definition)를 포함한다; 예를 들어, 워크스테이션 각각은 그것에 접근하기 위한 정보(예를 들어, 이름, 주소, 및 그와 유사한 것)와 함께 그 워크스테이션의 물리적(physical)/논리적(logical) 특징들(예를 들어 프로세싱 파워(processing power), 메모리 사이즈, 운영 시스템 및 그와 유사한 것)로 정의된다. 또한 워크로드 데이터베이스(315)는 각 작업의 디스크립터(descriptor)를 포함한다. 여기서 작업 디스크립터(job descriptor)는 호출될(to be invoked) 프로그램(프로그램들의 인수들(arguments)과 환경 변수들(environmental variables))을 명시한다(specify). 또한 상기 작업 디스크립터는 그 작업이 실행될 수 있는 워크스테이션을 표시한다. -여기서 작업의 실행은 정적으로(워크스테이션의 이름들에 의해) 혹은 동적으로(워크스테이션의 특징들에 의해) 실행될 수 있다. 그 다음, 상기 작업 디스크립터는 상기 작업의 실행을 위해서 시간적 제한들(temporal constraints)을 규정한다. 이러한 시간적 제한들에는, 예를 들어, 일(every day), 주, 혹은 월 단위의 작업 실행-사이클(run-cycle), 작업을 시작하기 위한 가장 이른 시간(earliest time) 혹은 가장 늦은 시간(latest time), 또는 최대 허용가능한 작업 기간(duration))이 포함될 수 있다. 선택적으로, 상기 작업 디스크립터는 작업의 선행조건들(dependendies)(즉, 작업이 시작되기 전에 반드시 충족되어야만 하는 조건들(conditions))을 명시한다. 여기서 선행조건들의 예에는, 시퀀스 제한들(sequence constraints)(예를 들어, 다른 작업들의 성공적인 완료가 있어야한다는 제한), 혹은 이네이블링 제한들(enabling constraints)(예들 들어, 오퍼레이터(operator)에 의해서 프롬프트에 대한 응답의 엔터링(entering))이 있어야한다는 제한)이 포함될 수 있다. 일반적으로, 상기 작업들은 스트림들(streams)로 이루어진다; 이때 각각의 작업 스트림은 (논리적으로 연관된) 작업들의 순차 시퀀스로 구성되는데, 각각의 작업 스트림은 미리정의된 선행조건들을 존중하면서(respecting predefined defendencies) 단일의 작업 단위로(as a single work unit) 실행된다. 간단히 하기 위해서 이후에는, 상기 “작업(job)”이라는 용어는 단일 작업(single job) 혹은 작업 스트림(job stream)을 표시하기 위해 사용될 것이다. 워크로드 데이터베이스(315)는 이전에 실행한 작업들에 관한 통계 정보(statistic information)를 저장한다(이러한 통계 정보로는 그들의 지속시간(their duration)에 관한 로그(log)가 있으며, 대응 예상 지속시간(a corresponding estimated duration)은 이로부터 추정될 수 있다(inferred))

플래너(320)(예를 들어, TWS의 “마스터 도메인 매니저(Master Damain Manager)")는 플랜(plan)을 생성하기 위해서 사용되는데, 이에 대한 정의는 컨트롤파일(325)(예를 들어, TWS의 “심포니(Symphony)”)에 저장된다. 또한 상기 플랜(plan)은 특정 처리 기간(in specific production period)(통상, 하루(one day))에 작업들의 배치(batch)의 실행에 관한 흐름(the folw)을, 필요한 워크스테이션들의 정의와 함께, 명시한다. 새로운 플랜(a new plan)은 일반적으로, 매 처리 기간 전에(before every production period)자동적으로 생성된다. 이를 위해서, 플래너(320)는 워크로드 데이터베이스(315)에서 이용가능한 상기 정보를 처리하여(process) 실행될 작업들을 선택하고 그들을 원하는 시퀀스에(in the desired sequence) 배치(arrange)한다(그들의 예상 기간 (expected duration), 시간적 제한들, 및 선행조건들에 따라서). 플래너(320)은 (다음 처리 기간 동안) 실행될 작업들을 추가하고 (이전 처리 기간 동안) 완료된 기존의 작업들을 삭제하여 플랜(plan)을 생성한다; 이에 더하여, 상기 이전 처리 기간 동안의 작업들이 성공적으로 완료되지 못했거나 또는 아직 실행 중(running) 이거나 혹은 실행을 위해 대기 중(waiting)인 경우에는 (다음 처리기간 동안 작업들의 실행을 위해서) 상기 플랜(plan)에 계속 남아있을 수 있다.

핸들러(330)(예를 들어, “TWS”의 “배치맨(Batchman)” 프로세스)는 매 처리 기간의 초기에 상기 플랜을 시작하게한다. 또한 핸들러(330)은 실행을 위한 각각의 작업을 가능한 빨리 제출하게한다. 이를 위해, 핸들러(330)은 필요한 특성들을 갖는 워크스테이션 -이용가능한 것들 중에서- 을 선택한다. (상기 필요한 특성은, 통상, 로드 균형자(load balancer) -도시되지는 않음- 에 의해 제공된 정보에 따른다.)

상기 작업들의 실제 실행은 대응 모듈(335)에 의해서 관리된다(예를 들어, “TWS”의 “잡맨(Jobman)” 프로세스); 이를 위해, 실행기(executor)(335)는 각 워크스테이션(110)(도면에는 워크스테이션이 오직 하나만 도시됨) 상에서 실행되는(running) 실행 에이전트(execution agent)(340)이 인터페이스한다.

에이전트(agent)(340)은 실행기(335)로부터 수신된 대응 명령에 반응하여 각 작업의 실행을 집행하고(enforce), 그 실행 결과에 대한 피드백 정보(예를 들어, 그 작업의 성공적 완료여부, 실제 작업 기간, 및 그와 유사한 것)를 회신한다(return). 실행된 모든 작업들에 관한 상기 피드백 정보는 실행기(335)에 의해서 핸들러(330)로 넘겨지고(pass by), 핸들러는 이를 다시 컨트롤파일(325)에 보내고 여기에 기록된다(enter)(이는 상기 플랜에 있는 모든 작업들의 현재 상태에 관한 실시간 그림(a real-time picture)을 제공하기 위함이다). 처리 기간의 종료 시에, 플래너(planner)(320)는 실행된 작업들과 관련된 통계 정보를 워크로드 데이터베이스(315)에 업데이트하기 위해 컨트롤파일(325)에 접근한다.

본 발명의 일 실시예에 따른 솔루션에서, 스케줄러(305)는 또한 대응 이벤트들(events)에 반응하여 작업들의 실행들(혹은 더 일반적으로, 어떤 다른 동작들(actions))을 지원하며(support), 이하에서 이에 관해 상세하게 설명한다. 이를 위해, 각 스테이션은 오직 관심 대상의(interest) 이벤트들만 검출하도록 인에블된다(enabled)- 여기서 관심 대상의 이벤트들이란, 워크스테이션에서 어떤 이벤트가 발생했을 때 대응 동작(action)의 실행을 트리거하는(trigger) 이벤트들을 말한다(여기서 대응 동작의 실행은, 예를 들어, 커스트마이즈된(customized) 구성파일들을 선택적으로 배치함으로써 달성될 수 있다).

상기 스케줄러는, 이러한 방식으로, 어떤 동작들의 실행도 제어할 수 있는데, 다시 말하면, 동작들의 실행에 관한 필요성이 미리 알려지지 않은 경우까지도 제어할 수 있다; 특히, 상기 플랜에 정의되지 않은 작업들의 제출도 허용한다. 아무튼, 워크스테이션들 및 서버의 오버헤드를 최소로 하면서 원하는 결과가 달성된다. 또한 심각한 네트워크 트래픽의 증가도 초래되지도 않는다.

더욱 상세하게 설명하면, 도면에 도시된 일 실시예에서, 편집기(editor) (345)는 규칙저장소(rule repository)(350)를 유지하기 위해서 사용된다. (규칙저장소에 관한 모든 업데이트(any update)를 제어하려면 인증 (authentication)/ 승인(authorization) 메커니즘에 의해 안전하게 하는 것이 바람직하다.) 저장소(repository)(350)내의 각각의 규칙은 대응 (이벤트) 워크스테이션에서의 이벤트 검출(detection)에 반응하여 대응 워크스테이션 상에서 실행될 동작(action)을 정의한다. 많은 여러(different) 이벤트들이 지원(support)될 수 있는데; 예를 들어, 이러한 이벤트들에는 작업에 대한 오류 상태(error condition)의 엔터링(entering), 워크스테이션의 작업 정지(shutdown), 파일의 생성과 삭제, 및 그와 유사한 것들이 포함될 수 있다. 통상, 상기 동작들(actions)에는 작업의 실행을 위한 작업의 제출(submission)이 포함되며; 여기서(in this respect), 상기 규칙은 모든 작업을 명시할 수 있다는 것, 즉 작입이 플랜에 포함되지 않은 경우에도 그렇게 할 수 있다는 것이 중요하다. 그러나, 다른 동작들 -예를 들어, 사용자에 대한 e-메일 통지, 워크스테이션 켜기(turn-on), 및 그와 유사한 것- 도 지원될 수 있다. 또한 상기 시스템의 어떤 컴퓨터에서라도 이벤트들이 검출되고 동작들이 실행될 수 있다; 예를 들어, 상기 작업들의 상태 변경(change of status)과 관련된 이벤트들(events)은 서버 자체에 의해서 검출된다(이 경우에는 워크스테이션으로 작동함); 또한, 상기 작업들의 제출들을 포함하는 동작들(actions)은 (필요한(required) 특성들에 따라) 정적 혹은 동적으로 정의된 워크스테이션에서 실행될 수 있다.

플러그-인(plug-in) 모듈들 세트(혹은 간단히 플러그-인들이라 한다)는 이벤트들(events)을 검출하고 동작들(actions)을 실행하기 위해서(작업들의 제출과는 다름) 제공된다; 예들 들어, (이벤트) 플러그-인의 예는 파일 스캐너가 될 수 있고, 반면, (동작) 플러그-인 예는 e-메일 발신자(sender)가 될 수 있다. 규칙저장소(rule repository)(350)는 플래너(320)에 의해서 접근된다(이벤트들의 검출 및 그에 대응 동작들의 실행을 위해 필요한 정보를 컨트롤파일(325)에 추가하기 위해서이다).

이벤트 플러그-인 데이터베이스(355)는 이벤트의 검출을 위해서 각각의 이벤트를 대응 이벤트 플러그-인과 연관시킨다(associate). 이때 모니터(360)은 저장소(350)의 규칙들을 처리한다(process)(예를 들어, 어떤 변경(change)이 검출될 때마다 처리한다). 더욱 상세하게 설명하면, 모니터(360)는 상기 규칙들에서 각각의 워크스테이션들에 대해서 정의된 이벤트들(events)을 결정한다. 그 다음, 모니터(360)은 이들 이벤트들과 연관된 각각의 이벤트 플러그-인에 대하여 구성파일(configuration file)을 생성한다 (이벤트 플러그-인 데이터베이스(355)에 표시된 대로); 여기서 상기 구성파일은 상기 이벤트 플러그-인의 구성 파라미터들(parameters)을 세트(set)하는데, 이러한 구성 파라미터들은 원하는(desired) 이벤트(들)을 검출할 수 있게 한다. 다음으로, 각 워크스테이션의 구성파일들은 단일 구성 아카이브(a single configuration archive)와 결합한다(combine into)(예를 들어, 압축된 형태로). 모니터(360)은 그렇게 획득된 모든 구성 아카이브들을 대응 저장소(365)에 저장한다. 그와 동시에, 모니터(360)은 각 구성 아카이브의 순환 잉여 코드(Cyclic Redundancy Code; CRC)를 산출한다(calculate)(16-비트 혹은 32-비트 다항식을 적용하여 산출함). 구성테이블(370)은 각각의 워크스테이션과 그에 대응 구성 아카이브 및 그에 관한 CRC를 연관시키기 위해 사용된다(모니터(360)들의 컨트롤 하에서)

배치기(deployer)(375)는 각각의 CRC를 그에 대응 워크스테이션으로 전송한다(구성 테이블(370)에 표시된 대로); 이를 위해, 배치기(deployer)는 컨트롤 파일(325)에 있는 워크스테이션들의 정의(definition)로부터 필요한 정보를 읽어온다(retrieve), 간단하게 설명하기 위해서 위에서 했던 것처럼 동일 워크스테이션 (110)을 참조하면, 이 정보는 컨트롤러(380)으로 수신된다. 그 다음 컨트롤러(380)은 워크스테이션(100)에 인스톨되어 있는(installed) (이벤트 및/또는 동작) 플러그-인들(390으로 표시됨)의 현재 구성파일들(385로 표시됨)에 접근한다. 상기 수신된 CRC가 구성 파일들(385) 중의 하나와 다른 경우, 컨트롤러(380)은 서버(105)로부터 (새로운) 구성 아카이브를 다운로드하고(배치기(375)를 통해서 다운로드함), 그 다음, 구성파일들(385)을 다운로드받은 구성 아카이브로 업데이트한다; 서버(105)에 의해 제공된 구성 아카이브들(configuration archives)은 기밀성(confidentiality) 및 완결성(integrity)을 유지하도록 암호화되어 보호(secure)되는 것이 바람직하다.

플러그-인들(390)은 서버(105)와 정보를 교환하기 위해서 에이전트(340)가 인터페이스한다. 특히, 에이전트(340)은 워크스테이션(110)에서 검출된 이벤트들을 이벤트수집기(event collector)(391)에 통지하는데; 워크스테이션(110)에 의해 제공된 이벤트들의 통지들(notifications)은 기밀성(confidentiality) 및 완결성(integrity)을 유지하도록 암호화되어 보호되는 것이 바람직하다. 이벤트 수집기(event collector)(391)은 모든 워크스테이션에서 검출된 이벤트들의 통지들을 이벤트 상관기(event correlator)(392)로 보낸다(pass). 이벤트상관기(event correlator)(392)는 이벤트들의 통지들에 반응하여 (대응 워크스테이션들과 함께) 실행될 동작들을 결정하기 위해서 규칙저장소(350)에 접근한다. 특정(specific) 워크스테이션에서 실행될 각 동작을 위해 이벤트 상관기(392)는 핸들러(330)을 호출한다(call)(이 정보를 전달함으로서). 그러면, 핸들러(330)은 동작 플러그-인 데이터이스(393)에 접근하여, 각각의 동작을 그 동작의 실행을 위한 대응 동작 플러그-인과 연관시킨다. 다음으로, 핸들러(330)는 (동작 플러그-인 데이터베이스((394)에 표시된) 실행될 동작들과 연관된(associated with) 동작 플러그-인(전체로서 참조번호 394로 표시됨)을 호출한다(invoke). 각각의 동작 플러그-인(394)는 원하는(desired) 워크스테이션에서 대응 동작의 실제 실행(actual execution)을 관리한다; 이를 위해, 동작 플러그-인(394)는 각각의 관련(relevant) 워크스테이션에서 실행되는(running) 에이전트(340)가 인터페이스한다. 또한, 동작 플러그-인들(394)은 사용자 통지들을 수행하기 위해(예를 들어, e-메일에 의해서) 준비된(adapted) 모듈들(modules)도 포함할 수 있다.

이제 도 4a 및 도4b를 참조하면, 도 4a 및 도4b는 작업들의 실행을 스케줄하기 위한 전술한 시스템에서 구현될 수 있는 예시적인 프로세스의 논리 흐름이 방법(400)으로 도시되어 있다.

상기 방법은 서버의 스윔-레인(swim-lane)에 있는 검은(black) 시작 원(403)에서 시작한다. 블록(block)(406)에서 새로운 플랜이 생성되면, 프로세스는 블록(409)로 넘어간다; 이 단계(phase)에서, 상기 플랜의 정의가 생성되어(generated)(상기 플랜의 정의는 작업들의 실행 흐름에 관한 명세(specification) 및 그 작업들의 실행에 필요한 워크스테이션들에 관한 정의(definition)를 포함한다) 컨트롤파일에 저장된다.

프로세스(activity)의 흐름이 블록(412)으로 넘어가서 모니터는 (대응 저장소에 저장된) 규칙들에서 어떠한 변경이 있는 지를 검출한다. 어떠한 변경의 검출에 반응하여, 블록(415)에서, 상기 플랜은 재생성되고 상기 컨트롤 파일에서 교체된다. 이는 이벤트들이 검출되며 그리고 대응 동작들이 실행되는 워크스테이션들에 관한 정의를 추가하기 위함이다.

그 다음, 변경된(changed) 규칙들에 대한 프로세싱을 위해 루프(loop)가 수행된다; 루프는 블록(418)에서 시작하는데, 여기서 변경된 모든 규칙(every changed rule)이 확인된다(identified)(최초의 규칙에서부터 시작함). 블록(421)로 진행하면, (현재) 변화된 규칙에 명시된 이벤트와 연관된(associated) 이벤트 플러그-인이 이벤트 플러그-인 데이터베이스로부터 추출된다(extracted). 이제 블록(424)에서, 이 이벤트 플러그-인이 호출되며(invoked) (검출될 이벤트의 표시(indication)를 전달함으로써); 이렇게 하여, 상기 이벤트 플러그-인에 관한 구성파일이 생성된다(상기 이벤트 플러그-인이 원하는 이벤트를 검출할 수 있도록 적절히 세트된 대응 구성 파리미터들과 함께). 규칙에서 표시된 이벤트가 검출될 워크스테이션은 블록(430)에서 확인된다(identified). 블록(433)으로 진행하면, 그렇게 획득된 구성파일은 상기 워크스테이션의 구성 아카이브(archive)에 추가된다. 그 다음, 블록(436)에서, 다음(next) 규칙이 변경되었는지를 결정하기 위한 테스트(test)가 행해진다. 규칙이 변경된 경우에는, 상기 방법은 블록(418)로 되돌아와서 다음(next) 변경된 규칙에 대해서 상기 설명한 동일 동작들(same operations)을 반복한다.

바꿔 말하면(conversely), 일단 변경된 규칙들이 모두 처리되면, 상기 획득된 새로운 구성 아카이브들(archives)을 프로세싱하기 위해 또 다른 (further) 루프에 진입한다(enter); 상기 루프는 블록(439)에서 시작하는데, 여기서 모든 (새로운) 구성 아카이브 아카이브 -최초의 구성 아카이브에서 시작하여- 의 (새로운) CRC가 산출된다(calculated). 블록(442)로 진행하여, 상기 새로운 CRC는 대응 워크스테이션으로 전송된다. 이 전송에 반응하여, 상기 워크스테이션은, 블록(445)에서, 현재 그 워크스테이션에 인스톨된 구성파일들에 관한 (기존의(old)) CRC를 산출한다; 그 다음, 상기 새로운 CRC는 기존의 CRC와 비교된다. 비교 결과에 따라, 블록(448)에서 프로세스(activity)의 흐름이 분기된다(branch). 새로운 CRC가 기존의 CRC와 다른 경우, 워크스테이션은, 블록(451)에서, 새로운 구성 아카이브를 서버에 요청한다. 서버의 스윔-레인(swim-lane)으로 돌아가서, 블록(454)에서 상기 요청 받은 새로운 구성 아카이브가 워크스테이션에 전송된다. 블록(457)에서, 일단 상기 새로운 구성 아카이브가 워크스테이션에 수신되면, 그에 관한 구성파일들이 추출되어(extracted) 워크스테이션에 인스톨된다. 그 다음, 상기 방법은 서버의 스윔-레인(swim-lane)의 블록(460)으로 진행하며(descend); 새로운 CRC가 기존의 CRC와 같은 경우에는, 블록(448)에서 직접 상기 동일 포인트로 또한 도달된다. 상기 포인트에서(at this point), 모든 새로운 구성 아카이브들이 처리되었는지를 결정하기 위한 테스트가 이루어진다. 그렇지 않은 경우에는, 상기 방법은 또 다른(another) 새로운 구성 아카이브에 대해서 상기 설명한 동일 동작들을 반복하기 위해서 블록(439)으로 되돌아간다.

반대로(on the contrary), 프로세스(activity)의 흐름이 블록(463)으로 진행하면(descend). 처리 기간(production period)의 초기에 상기 플랜이 시작된다. 상기 플랜의 모든(every) 작업이 (시간적 제한들과 선행 조건들에 따라) 실행될 수 있게 되면, 상기 방법은 블록(466)에서 블록(469)로 진행한다(pass); 이 단계에서, 선택된 워크스테이션(필요한 특성들을 갖춘 이용 가능한 워크스테이션들 중에서 선택됨)에서의 작업 실행을 위해서 상기 작업이 제출된다. 상기 제출에 반응하여, 블록(472)에서, 상기 작업은 (선택된) 워크스테이션에서 실행된다 -간단히 설명하기 위해서 설명하기 위해서 상기 설명한 것과 동일하게 표시함. 블록(475)로 진행하여, 상기 워크스테이션은 서버에 피드백 정보(작업의 실행 결과에 관한 정보)를 회신한다. 이제 서버의 스윔-레인(swim-lane)에 있는 블록(478)에서, 상기 피드백 정보는 컨트롤파일에 기록된다(enter).

범용 (이벤트) 워크스테이션 -간단히 설명하기 위해서, 상기 설명한 것과 동일하게 표시함- 이 자신의 이벤트 플러그-인들의 구성파일들에 표시된 이벤트들 중에서 하나의 이벤트를 검출할 경우에는 항상(whenever), 프로세스의 흐름이 완전히 비동기 방식(completely asynchronous manner)으로 블록(481)로 진행한다. 이에 반응하여, 워크스테이션은 블록(484)에서, 서버에 상기 이벤트를 통지한다. 이제 서버의 스윔-레인(swim-lane)에 있는 블록(485)로 이동하면, 이 이벤트에 반응하여 실행될 모든(any) 동작들(대응 워크스테이션들과 함께)이 규칙저장소로부터 읽힌 규칙들에 따라 결정된다. 이를 위해서, 이벤트 상관기(event correlator)는 상기 규칙들을 간단히 평가(evaluate)할 수 있다(각 규칙은 이벤트에 대해 반응하는 동작의 실행을 정의함); 또한, 이벤트 상관기는 규칙들 간의 관계들(relationships)을 평가할 수도 있다(예를 들어, 서로 다른 이벤트들의 검출에 대해 반응하는 동작의 실행을 정의함). 블록(487)로 진행하면, 서버는 대응 워크스테이션에서 실행될 각 동작을 제출한다(간단히 설명하기 위해서 상기 설명한 것과 동일하게 표시함); 이를 위해, 핸들러는 대응 동작 플러그-인(동작 플러그-인 데이터베이스에 표시됨)을 호출한다(invoke). 이와 동시에, 서버는 대응 통지(notification)를 보낼 수도 있다(예를 들어, 워크스테이션(110)의 사용자에게 e-메일로).

이에 반응하여, 동작이, 블록(490)에서, 워크스테이션 상에서 (실행 에이전트 혹은 대응 동작 플러그-인 수단에 의해) 실행된다. 블록(493)으로 진행하면, 상기 설명한 바와 같이 워크스테이션은 서버에 피드백 정보(동작의 실행 결과에 관한 정보)를 회신한다. 서버의 스윔-레인(swim-lane)에 있는 블록(496)으로 이동하면, 상기 피드백 정보는 상기 설명한 바와 같이 컨트롤파일에 기록된다(enter). 그 다음, 프로세스(activity)의 흐름은 흰색/검은색 정지 동심원(concentric white/black stop circles)에서 종료한다.

특정 요건들을 충족시키기 위해서 당해 기술분야에서 통상의 지식을 가진 자는, 당연히, 다수의 논리적 및/또는 물리적 변형들 및 다른 실시예를 상기 설명한 솔루션에 적용할 수 있다. 더 자세하게는, 비록, 본 발명은 바람직한 실시예(들)를 참조하여 특성들 중 일부에 대해 설명했지만, 다른 실시예들과 함께, 본 명세서에서 설명된 것으로부터 여러가지 생략(omissions), 치환(substotuions), 및 변경(changes)이 가능하다는 것을 이해해야만 한다. 특히, 상기 제안된 솔루션은 보다 철저한 이해를 제공하기 위해서 앞선 설명에서 특정 세부사항들(예를 들어 번호가 표시된 예시들)에 관한 설명 없이도 실행될 수 있다; 반대로, 불필요한 사항들의 기재로 설명이 모호하게 되지 않도록 하기 위해 잘 알려진 특징들(features)은 생략되거나 또는 간략하게 될 수 있다. 또한, 개시된 본 발명의 모든 실시예와 관련하여 설명된 특정 요소들 및/또는 방법 단계들은 일반 설계 선택으로서 어떤 다른 실시예와 결합될 수 있음이 분명히 의도되었다.

특히, 제안된 솔루션은 균등한 방법(an equivalent method)(유사한 단계들을 사용하거나, 필수적이지 않은 몇몇 단계들을 삭제하거나, 또는 선택적인 단계들을 추가하는 것에 의해)으로 구현되기에 적합하다; 또한, 개시된 단계들이 상이한 순서로 수행되거나, 동시에 수행되거나, 또는 삽입되는 방식(적어도 부분적으로)으로 수행될 수도 있다.

또한, 상기 동일 솔루션이 어떤(any) 다른 워크로드 스케줄러(또는 상응하는 응용프로그램)에 적용될 수도 있다. 특히, 비록 앞선 설명에서는 비-쌍방향 작업들에 대해 참조(reference)가 이루어졌지만, 이에 한정한 것으로 의도된 것은 아니다; 실제로, 상기 동일 솔루션은 어떤 종류의 워크 유닛들(예를 들어, 쌍방향 태스크들)의 실행을 스케줄하기 위해서도 사용될 수 있다. 이처럼, 플랜(plan)은 상이한 방식 -예를 들어, 어떤 추가적인 또는 대안적인 시간적 제한들 또는 선행조건들에 기초하여(심지어 워크스테이션들 간의 동적 관계들에 기초하여)- 으로 정의되고 그리고/또는 생성될 수 있다. 또한, 작업들의 제출을 위한 워크스테이션들을 선택하기 위해서 어떤 다른 기준(criteria)(예를 들어, 작업들의 실행을 고르게 분배하기 위해서 통계 방법들(statistic methods)에 따라)이 사용될 수 있다.

제안된 솔루션은 대응 이벤트들에 반응하여 실행될 동작들을 정의하기 위해서 어떤 다른 타입의 규칙들(또는 정책들)로 구현될 수 있다; 이처럼, 상기 설명된 이벤트들 및 동작들은 단지 설명하기 위한 것이며, 이에 제한되는 것으로 해석되어서는 안된다. 예를 들어, (기본) 규칙들이 어떤 논리 연산자(예를 들어, OR, AND, 및 그와 유사한 것)를 사용하여 (복잡한) 규칙들로 결합되어(combined into), 이벤트들(상이한 워크스테이션들에 있는 것 조차도 포함하여)의 모든 결합(combination)에 반응하여 실행될 동작들을 정의하도록 할 수도 있다; 이처럼, 규칙들은 다수의 (기본) 동작들을 포함하는 (복잡한) 동작들의 실행을 정의할 수 있는데, 이때 각각이 다수의 (기본) 워크스테이션들을 포함한 (복잡한) 실체들에서의 동작들까지도 -즉, 동일 이벤트에 기초한 규칙들을 더 집합함으로써(by aggregating)- 정의하도록 할 수 있다. 다른 실시예로는, 이벤트들이 다른 규칙들의 결과(outcome)를 포함할 수 있다; 또한, 동작들은 시간적 제한들 및/또는 선행조건들을 조건으로 할 수도 있다.

비슷한 고려사항들로 통지들(notifications)이 SMS, 및 그와 유사한 것인 경우, 추가로 다른 사용자에게 통지들이 보내지는 경우가 있다. 본 발명의 다른 실시예에서, 상기 동작들은 오로지 작업들, 통지들(notifications), 혹은 어떠한 다른 미리정의된 타입의 연산들(operations)로만 구성될 수 있다; 물론, 규칙들에 관한 정보를 포함하기 위해서 플랜을 재생성하는 것이 반드시 필요한 것은 아니다.

비슷한 고려사항들로 구성파일들(및 구성 아카이브들)이 그와 균등한 구조들 -예를 들어, 이벤트 플러그-인들의 원하는 행동(behavior)을 강제하기(forcing) 위한 명령들을 간단히 포함하도록-로 대체되는 경우가 있다; 이처럼, 상기 구성파일들은 어떤(any) 다른 방법(예를 들어, 소프트웨어 분산 인프라구조(software distribution infrastructure)를 이용함으로써)으로 관련 워크스테이션들에 배치될 수 있다.

또한, 제시된 솔루션의 기본적인 실시예에서, 구성파일들을 모든 워크스테이션들에 대해 무차별적으로 분산시킬 수 있다.

또한, CRC는 다른 타입이 될 수 있는데(예를 들어, CRC-4), 구성 아카이브의 간단한 체크썸(checksum)으로 대체되거나, 해시(hash) 값으로 대체되거나, 또는 더 일반적으로 더 간결한 형태(a far shorter form)의 구성 아카이브를 나타내는 어떤 다른 다이제스트 값으로 대체될 수 있다. 그러나, 구성 아카이브들의 선택적 배치를 서버에서 직접 관리하는 것(예를 들어, 모든 워크스테이션들의 실제 상태에 관한 정보를 중앙에서 유지하도록 함으로써)을 막을 수는 없다.

또한, 제시된 솔루션의 일반적인 변형(variant)은 각각의 (이벤트) 워크스테이션이 각각의 이벤트를 직접 -서버를 통해서 보내지 않고- 대응 (동작) 워크스테이션들에게 통지하도록 하는 것이다. 이런 경우로는, 예를 들어, 매 이벤트가 발생할 때마다, 또는 동일 워크스테이션에서 실행될 동작이 오직 대응 이벤트가 검출되었던 워크스테이션인 경우에만 발생하도록 할 수 있다.

요청대로(규칙들의 어떤 모니터링도 없이) 원하는 구성파일들을 배치하도록 강제하는 것(forcing)은 본 솔루션의 기술적 사상 범위내에 있다.

또한 어떤 예시에서는, 단순한 실시예로 규칙들에 어떤 변경이 있을 경우 모든 워크스테이션들에 대해서 구성파일들을 재생성할 수도 있다.

비슷한 고려사항들로 프로그램(본 발명의 각 실시예를 구현하기 위해서 사용될 수 있음)이 다른 방식의 구조로 되거나, 또는 추가적인 모듈들 혹은 기능들이 제공될 수 있다; 이처럼, 메모리 구조가 다른 타입으로 이루어지거나, 또는 균등한 실체들로 대체될 수 있다(물리적 저장 매체로 구성될 필요가 없음). 어떤 예시에서는, 상기 프로그램이 어떤 데이터 처리 시스템에 의해서 사용되거나 또는 그것과 결합하여 적절하게 사용되기 위한 어떤 형태를 취할 수 있는데, 예를 들어 시스템 외부에 존재하는 또는 시스템에 상주하는 소프트웨어, 펌웨어, 또는 마이크로코드(오브젝트 코드 혹은 소스(source) 코드 -예를 들어, 컴파일되어 해석됨- 중 하나로)가 있다. 또한, 모든(any) 컴퓨터 사용가능 매체에 상기 프로그램을 제공하는 것이 가능하다; 상기 매체는 프로그램을 적절하게 포함, 저장, 통신, 보급, 또는 전송하기 위한 어떤 엘리먼트(element)가 될 수 있다. 예를 들어, 상기 매체는 전기, 자기, 광학, 전자기, 적외선, 혹은 반도체 타입으로 될 수 있다; 그러한 매체의 예시들로는 고정 디스크들(fixed disks)(프로그램이 여기에 미리 로드될 수 있음), 착탈 가능한 디스크들, 테이프들, 카드들, 전선들, 광섬유들, 무선 커넥션들(wireless connections), 네트워크들, 브로드캐스트 파장들(broadcast waves), 및 그와 유사한 것이 있다. 본 발명의 실시예에 따른 솔루션은 어떠한(any) 예시에서, 하드웨어 구조(예를 들어, 반도체 물질의 칩으로 이루어짐) 또는 소프트웨어 및 하드웨어의 결합으로 구현되기에 적합하다. 또한 네트워크(예를 들어 인터넷)를 통해서 접근되는 서비스로써 제안된 솔루션이 배치될 수 있음을 쉽게 이해할 수 있을 것이다.

제안된 방법은 상이한 구조로 된 시스템 혹은 균등한 유닛들을 포함하는 시스템에서 수행될 수 있다(예를 들어, 로컬 네트워크에 기초하여). 또한, 각 컴퓨터는 유사한 엘리먼트들(예를 들어, 실행하는 동안 대량 메모리(mass memory)에 대한 접근들을 줄이기 위해서 프로그램들을 임시로 또는 부분적으로 저장하는 캐시 메모리)을 포함할 수 있다; 어떤 예시에서는, 컴퓨터를 어떠한 코드 실행 실체(code execution entity)(예를 들어, PDA, 모바일 폰, 및 그와 유사한 것)로 교체하거나, 또는 그것의 결합(예를 들어, 멀티-티어(multi-tier) 서버 구조, 그리드(grid) 컴퓨팅 인프라구조, 및 그와 유사한 것)으로 교체할 수 있다.

Claims (10)

1. 데이터 처리 시스템의 스케줄링 실체의 제어 하에 상기 시스템의 타겟 실체들 상에서의 작업들의 실행 스케줄링을 위한 방법(400)에 있어서, 상기 방법은:
   작업들 세트의 실행 흐름을 정의하는 플랜을 제공하는 단계(406 내지409),
   상기 플랜에 따라, 선택된 타겟 실체 상에서의 실행을 위한 각각의 작업을 제출하는 단계(466 내지 475),
   이벤트 타겟 실체 상에서의 이벤트에 반응하여 동작 타겟 실체 상에서 실행될 동작을 정의하는 각각의 규칙(rules)의 세트를 제공하는 단계(412 내지 415),
   상기 규칙들에서 각각의 이벤트 타겟 실체에 대해 정의되는 이벤트들을 결정하는 단계(430),
   상기 각각의 이벤트 타겟 실체를 인에이블하여(enabling) 상기 대응 이벤트들을 검출(detect)하는 단계(418 내지 457), 및
   상기 대응 이벤트의 검출에 반응하여 상기 대응 동작 타겟 실체 상에서의 각각의 동작의 실행을 트리거하는(triggering) 단계(481 내지 493)를 포함하는
   작업들의 실행 스케줄링을 위한 방법(400).
2. 제 1항에 있어서,
   상기 동작들(actions) 중에서 적어도 하나는
   상기 대응 동작 타겟 실체 상에서의 실행을 위해 상기 플랜에서 정의되지 않은 추가 작업을 제출하는 단계를 포함하는
   작업들의 실행 스케줄링을 위한 방법(400).
3. 제 1항 또는 2항에 있어서,
   상기 각각의 이벤트 타겟 실체를 인에이블하여(enabling) 상기 대응 이벤트들을 검출(detect)하는 단계(418 내지 457)는:
   상기 이벤트 타겟 실체 상에서 실행되는(running) 적어도 하나의 검출 모듈을 위해 구성구조(configuration structure) -상기 구성 구조는 상기 이벤트들을 모니터 하기 위해서 적어도 하나의 검출 모듈을 트리거함- 를 생성하는 단계(433), 및
   상기 구성구조를 상기 이벤트 타겟 실체에 배치하는(deploying) 단계(439 내지 457)를 포함하는
   작업들의 실행 스케줄링을 위한 방법(400).
4. 제 3항에 있어서,
   상기 각각의 이벤트 타겟 실체를 인에이블하여(enabling) 상기 대응 이벤트들을 검출(detect)하는 단계(418 내지 457)는:
   상기 구성구조가 상기 이벤트 타겟 실체에 이미 배치되어 있는 이전 버전(previous version)과 동일한(equal) 경우에는, 상기 이벤트 타겟 실체에 대한 상기 구성 구조의 배치를 방지하는(preventing) 단계(439 내지 448)를 더 포함하는
   작업들의 실행 스케줄링을 위한 방법(400).
5. 제 4항에 있어서,
   상기 이벤트 타겟 실체에 대한 상기 구성 구조의 배치를 방지하는 단계(439 내지 448)는:
   상기 구성 구조를 나타내는 다이제스트 값을 생성하는 단계,
   상기 다이제스트 값을 상기 이벤트 타겟 실체로 전송하여(442), 상기 이벤트 타겟 실체가 상기 다이제스트 값을 상기 구성 구조의 이전 버전을 나타내는 이전(previous) 다이제스트 값과 비교하도록 하여(445), 그 비교 결과 다른(negative) 경우에 대해서만 반응하여 상기 스케줄링 실체로부터 상기 구성 구조의 배치를 요청(451)하는 단계를 포함하는
   작업들의 실행 스케줄링을 위한 방법(400).
6. 제 1항 내지 5항 중 어느 한 항에 있어서,
   상기 대응 이벤트의 검출에 반응하여 상기 대응 동작 타겟 실체 상에서의 각각의 동작의 실행을 트리거하는 단계(481 내지 493)는:
   상기 대응 이벤트 타겟 실체로부터 이벤트 통지(notification)를 수신하는 단계(484),
   상기 이벤트에 대하여 규칙들에 정의되어 있는 각각의 동작 및 대응 동작 타겟 실체를 확인하는 단계(485), 및
   상기 대응 동작 타겟 실체 상에서의 동작 실행을 위해 각각 확인된 동작을 제출하는 단계(487)를 포함하는
   작업들의 실행 스케줄링을 위한 방법(400).
7. 제 1항 내지 5항 중 어느 한 항에 있어서,
   상기 규칙들을 모니터링하는 단계(412)를 포함하되, 상기 규칙들에서 각각의 이벤트 타겟 실체에 대하여 정의되는 이벤트들을 결정하는 단계(430) 및 상기 각각의 이벤트 타겟 실체를 인에이블하여(enabling) 상기 대응 이벤트들을 검출(detect)하는 단계(418 내지 457)는 상기 규칙들의 각각의 변경에 반응하여 실행되는
   작업들의 실행 스케줄링을 위한 방법(400).
8. 제 7항에 있어서,
   상기 변경된 규칙들에 대응하는 상기 이벤트 타겟 실체들 중 임팩트된(impacted) 것들을 확인하는 단계를 더 포함하되, 상기 규칙들에서 각각의 이벤트 타겟 실체에 대하여 정의되는 이벤트들을 결정하는 단계(430) 및 상기 각각의 이벤트 타겟 실체를 인에이블하여(enabling) 상기 대응 이벤트들을 검출(detect)하는 단계(418 내지 457)는 상기 임팩트된 이벤트 타겟 실체들에 대하여 제한되는
   작업들의 실행 스케줄링을 위한 방법(400).
9. 제 1항 내지 8항 중 어느 한 항에 있어서,
   컴퓨터 프로그램이 데이터 처리 시스템(105)에서 실행되는 경우, 상기 방법(400)을 수행하기 위한 컴퓨터 프로그램(300).
10. 제 1항 내지 8항 중 어느 한 항에 있어서,
    상기 방법(400)을 수행하기 위한 수단들(300)을 포함하는 시스템(105).

Images