KR101120788B1 - 최종 사용자 규칙 논리의 정의 및 실행을 위한 규칙프레임워크 - Google Patents

Abstract

최종 사용자 규칙 논리의 정의 및 실행을 위한 기반구조를 제공하는 규칙 기반 소프트웨어 아키텍쳐가 개시된다. 이것은 간단한 IF-THEN 규칙을 사용하여 단일화된 저장 플랫폼 내에서의 최종 사용자 데이터 자동화를 가능하게 한다. 아키텍쳐는 데이터에 연관된 항목들을 추적하는 모니터링 컴포넌트, 및 추적된 항목들에 연관된 메타데이터를 이용하여, 항목들의 서브세트의 자동화된 핸들링을 제공하는 규칙 컴포넌트를 포함한다. 시스템은 컨텐츠 기반 논리를 사용하여 시스템 내에 가상 컬렉션들 및 항목들을 정의하는 것을 더 제공한다. 또한, 시스템은 트리거 논리의 함수로서 항목들 및 항목들의 컬렉션을 동적으로 활성으로 설정하는 하나 이상의 트리거 컴포넌트를 더 포함한다. 추가의 컴포넌트들은 항목들에 제약 논리를 부과하는 것을 용이하게 하는 제약 컴포넌트, 및 하나 이상의 결정 포인트에서 어플리케이션 커스텀화 논리의 인에이블을 용이하게 하는 결정 컴포넌트를 포함할 수 있다.

최종 사용자 규칙 논리, 규칙 기반 소프트웨어 아키텍쳐, IF-THEN 규칙, 모니터링 컴포넌트, 규칙 컴포넌트

Description

최종 사용자 규칙 논리의 정의 및 실행을 위한 규칙 프레임워크{RULES FRAMEWORK FOR DEFINITION AND EXECUTION OF END-USER RULES LOGIC}

<관련 출원에 대한 상호 참조>

본 출원은 2004년 7월 30일자 미국 특허 출원 "RULES FRAMEWORK FOR DEFINITION AND EXECUTION OF END-USER RULES LOGIC"(출원번호 미지정), 2004년 4월 30일자 미국 특허 가출원 제60/567,165호 "RULES FRAMEWORK FOR DEFINITION AND EXECUTION OF END-USER RULES LOGIC", 2004년 4월 30일자 미국 특허 가출원 제60/567,149호 "DERIVED SET-A RULES-BASED QUERY LIKE MECHANISM THAT DEFINES CONTENTS OF A COLLECTION", 및 2004년 4월 30일자 미국 특허 가출원 제60/567,153호 "END-USER APPLICATION CUSTOMIZATION USING RULES"의 우선권을 주장한다. 본 출원은 2004년 7월 30일자 출원되어 공동 계류중인 "END-USER APPLICATION CUSTOMIZATION USING RULES"(출원번호 미지정, 대리인 관리번호 MSFTP669USA)와도 관련된다. 상기 언급된 출원서의 전체 내용은 본 명세서에 참조로서 포함된다.

본 발명은 최종 사용자의 데이터 자동화를 용이하게 하는 규칙 기반 소프트웨어 아키텍쳐에 관한 것이다.

컴퓨터 및 컴퓨팅은 사용자들의 세계를 항상 2가지의 부류, 즉 컴퓨터를 다 양한 방식으로 사용하고 또한 프로그램을 작성하며 풍부하고 가치있는 거동을 가능하게 할 줄 아는 지식있는 "권위자"들과, 그러한 권위자들에 좌우되며 컴퓨터가 자신의 요구를 제대로 충족시키게 하기 위한 지식이나 정보에 대한 쉽고 저렴한 액세스 또는 교육을 거부당하는 초보 사용자로 분류해왔다. 그러나, 컴퓨팅에 있어서의 주된 발전은, 이러한 액세스에 대한 장벽의 일부가 기술에 의해 파괴된 때에 이루어졌다.

메인프레임의 세계에서, 컴퓨터는 대기업을 제외하고는 그 누구도 가질 수 없을 정도로 고가였다. 미니컴퓨터, 그리고 그 이후의 퍼스널 컴퓨터(PC)의 출현으로 인해 비용 장벽이 파괴되었고, 중소 기업 및 개인들도 컴퓨터를 사용할 수 있게 되었다.

1980년대에, 프로그래머들은 그래픽 사용자 인터페이스(GUI) 어플리케이션을 구축하려고 애썼으며, 풍부하고 일관된 GUI없이는 PC 사용자에게 유용한 어플리케이션을 구축할 수 없었다. 비주얼 베이직 혁명과, 컨트롤 및 이벤트 기반 GUI 구성의 사용으로 인해, 모든 어플리케이션 개발자들이 풍부한 어플리케이션을 쉽게 구축할 수 있게 되었다. 그 결과, 보다 더 많은 최종 사용자들이 그러한 어플리케이션을 활용할 수 있게 되는 고결한 시대가 확립되었다.

1990년대에, 최종 사용자들은 정보에 대한 액세스의 부족을 극복하려고 애썼다. 인터넷 및 웹의 성장은 이러한 공간을 변화시켰고, 그에 의해 누구라도 브라우저를 이용하여 거의 모든 가치있는 정보에 액세스할 수 있게 되었다. 그러나, 극복해야 할 장벽은 여전히 많이 있다.

컴퓨팅은 개인적이지 않다. PC에 관하여 진정으로 "개인적"인 것은 거의 없다. 로컬 디스크 상의 데이터는 개인적이다. 그러나, 머신의 거동(머신이 사용자를 대신하여 수행하는 것)은 수백만명의 사용자 간에서 거의 동일하다. 놀라울 정도로 강력한 범용 컴퓨터를 소유하고 있음에도 불구하고, 평균적인 사용자들은 그 컴퓨터를 통신 엔드포인트로서 유용하고 검색 입력 포인트로서 유용하고 또한 소정의 기성화된 대중 판매용 어플리케이션에는 유용하지만, 그 외에 단어의 진정한 의미대로의 "개인적 컴퓨팅"은 전혀 수행할 수 없는 정적인 도구로 취급한다. 현재의 어플리케이션에서 이용가능한 개인화 능력은 가능하고 바람직한 것의 표면에만 간신히 도달한 정도이다.

컴퓨팅은 수동적이다. 가장 전형적인 컴퓨터 최종 사용자의 일상적인 루틴을 생각해 보자. PC는 정보를 수집하고, 통신에 대응하고, 결정을 행하여 그에 따른 액션, 즉 통신을 시작하거나 통신에 응답하고, 정보를 조직화하고, 물건을 판매 및 구입하고, 여행하는 것 등을 행한다. 컴퓨터는 사람들 간의 통신을 개선해 왔고, 또한 정보에 대한 액세스를 개선해 왔다. 그러나, PC는 적절한 시간에 결정을 내리고 그에 따른 행동을 해야 하는 의무로부터 사용자를 해방시켜 주는 것은 거의 이루지 못했다. 비지니스 세계에서, 주요한 조직적 결정을 위한 결정 지원 시스템이 존재한다. 여전히, 소프트웨어는 일상적이지만 중요하고 개인적인 많은 결정에 있어서 평균적인 PC 사용자들을 돕지 않는다.

컴퓨팅은 컨텍스트적이지 않다. 일반적으로, 컴퓨터 소프트웨어는 다소 정적이며, 사용자의 실제 컨텍스트에 무관한 옵션 설정들을 제공한다 (예를 들어, " 왜 직장과 집에서 동일한 메시징 버디 세트를 가져야 하는가?").

따라서, 사용자들은 수동적인 정보 처리의 압제의 함정에 점점 더 깊게 빠져들어, 이메일, 문서 및 기타 개인적 데이터의 감별, 소팅, 검색 및 대응에 매일 수시간씩을 소요하게 됨으로써, 여전히 소프트웨어의 "산업시대 이전 시대"에 머물러 있다.

최종 사용자 소프트웨어는 개인화되고, 최종 사용자의 요구 및 프리퍼런스를 인식하고, 특히 그러한 요구 및 사용자 컨텍스트에 의해 좌우되는 방식으로 동작해야 한다. 또한, 컴퓨터 시스템 및 소프트웨어는 모든 최종 사용자에게, 하루 24시간 근무하면서 그 최종 사용자가 관심있어 하는 정보를 수집하여 감별하고 또한 그 정보에 대응하는 개인적인 실행 보조자를 제공해야 한다.

가장 가치있는 클래스의 최종 사용자 컴퓨팅 활동은, 최종 사용자가 관련성있는 정보를 볼 것을 보장하는 것(예를 들어, "기상 악화로 인해 휴교령이 내려지면 알려주세요"), 개인화된 거동으로 개인-대-개인의 통신을 개선하는 것(예를 들어, "내가 사무실 밖에 있는 동안 아내에게 전화가 오면, 내가 돌아올 거라고 아내에게 알려주세요"), 중요한 정보가 상실되지 않을 것을 보장하는 것(예를 들어, "긴급한 이메일이 있으면, 반드시 내 모바일 디바이스로 포워드해 주세요"), 정보의 관리를 자동화하는 것(예를 들어, "새로운 사진이 도착하면, 그 사진의 타임스탬프, GPS 위치 및 임의의 관련 캘린더 엔트리에 기초하여 올바른 폴더 및 공유에 위치시켜 주세요")과 같이, 정보 흐름 및 검색을 다룬다.

이를 달성하기 위한 방법은 최종 사용자가 자신의 컴퓨터의 거동을 "프로그 래밍"할 수 있게 하는 것이다. 그러나, 최종 사용자가 트레이닝된 개발자가 아니라는 점(또한, 트레이닝될 수도 없다는 점)에서, 종래의 프로그래밍 언어는 분명히 그 해답이 아니다.

따라서, 이러한 수동 프로세스를 자동화함으로써, 사용자가 컴퓨터 및 소프트웨어가 자신을 대신하여 자동으로 동작하도록 개인화할 수 있게 하는 개선된 프로그래밍 플랫폼에 대한 요구는 아직 충족되지 않았다.

<발명의 요약>

이하에서는, 본 발명의 소정 양태에 대한 기본적인 이해를 제공하기 위하여, 본 발명의 간략한 개요를 제공한다. 본 개요는 본 발명의 광범위한 개관은 아니다. 이것은 본 발명의 핵심적인/중요한 구성요소를 식별하거나, 본 발명의 범위를 정하려고 의도된 것이 아니다. 본 개요의 유일한 목적은, 이하에 제공될 상세한 설명에 대한 서론으로서, 본 발명의 소정의 개념을 간략한 형태로 제공하는 것이다.

본 발명은 저장 및 통신에서 중심적인 가치를 갖는 데이터 및 정보와, 일반적으로 경험이 없는 비개발자(소비자, 지식 근로자 및 비지니스 사용자)임에도 자신의 PC 및 어플리케이션이 커스텀화되고 자동화된 방식으로 거동하기를 원하는 최종 사용자에 초점을 맞춘다.

본 명세서에 개시되고 청구되는 본 발명은, 한 양태에 있어서, 데이터를 자동화하는 최종 사용자 정의 규칙 논리의 정의 및 실행을 위한 기반구조를 제공하는 규칙 기반 소프트웨어 아키텍쳐를 포함한다.

규칙 생성 프레임워크는 규칙을 생성할 때와 규칙을 사용하는 어플리케이션을 구축할 때에 사용되는 항목 및 관계를 포함한다. 이러한 항목 및 관계는 규칙 프레임워크의 규칙 엔진에 의해, 컴퓨터가 특정 이벤트에 응답하여 무엇을 행해야하는지를 결정하는 데에 사용된다. 최종 사용자 규칙에 기초하여 어플리케이션 거동을 커스텀화하기 위하여, 프로그래머는 소프트웨어의 기능들을 규칙-인에이블(rules-enabling)하고, 최종 사용자는 그러한 기능들에 대하여 규칙을 생성한다.

본 발명은, 최종 사용자가 적어도 4가지 방식 -데이터 유도(data derivation), 트리거된 활성화(triggered activation), 데이터 제약(data constraints) 및 결정 포인트(decision points)- 으로 최종 사용자 데이터를 "자동화"하는 논리를 정의하는 것을 허용한다. 데이터 유도 규칙은 입력 항목 범위(scope)에 첨부된다. 트리거된 활성화 규칙은 컬렉션 내에서 변화하는 항목들에 첨부된다. 데이터 제약 규칙은 컬렉션 내에서 변화하는 항목들에 첨부된다. 데이터 구동(data-driven) 결정 규칙은 어플리케이션에 의해 항목들에 명시적으로 적용된다. 통합된 규칙 저장 플랫폼은, 공통 저장소 내의 스키마화된 데이터의 테마를 중심으로, 모든 지식 근로자 어플리케이션을 한데 모은다.

규칙은 복잡한 논리를 위한 단일의 선언적인 IF-THEN 프로그래밍 구성이다. 모든 최종 사용자 논리 컴포넌트는 규칙으로서 정의된다. 모든 다른 구성은 단순한 이진 대수 연산자이다. 규칙은 특정 항목 유형의 입력 인수에 대하여, 부작용없는 선언적 함수를 정의한다.

규칙 생성 프레임워크는 규칙 생성을 지원하기 위하여, 항목 유형들 -결정 포인트 항목, 규칙 항목 및 규칙 세트 첨부 항목- 을 사용한다. 이것은 RuleSetAttachment로 표시되어, 결정 포인트(DecisionPoint로 표시됨) 항목과 규칙(Rule로 표시됨) 항목 간의 연결을 표현한다. 이러한 연결은 물리적으로 저장된 "링크" 또는 계산된 "공통값 연관"으로서 모델링된다. 어느 경우에서든, 그 기능은 동일하게 '그것이 생성된 대상인 Rule로부터 DesicionPoint로의 연결'이다. 어플리케이션의 각각의 규칙 인에이블 특징(rule-enabled feature)은 결정 포인트 항목에 의해 정의된다. 최종 사용자는 특정 결정 포인트에 대한 규칙을 생성하고, 어플리케이션은 결정 포인트 객체를 사용하여 규칙 엔진에 데이터를 제출한다. 각각의 조건/결과 문장이 규칙 항목이다. 규칙은 실행을 위한 논리 단위이다. 규칙은 다중문장(multistatement)일 수 있다. 사용자는 규칙을 생성한다. 규칙 조직화(rule organization)는 사용자에 의해 제어될 수 있지만, 어플리케이션, 또는 사용자에게 제공된 시각적 브라우징 메타포(visual browsing metaphor)에 의해서도 제어될 수 있다. 어플리케이션도 규칙을 생성할 수 있다. 규칙은 규칙 세트 첨부(rule set attachment, RSA) 항목을 통해서 결정 포인트와 연관된다. 이러한 첨부는 규칙 엔진에 의해, 주어진 입력에 대해 어떤 규칙이 실행되어야 하는지를 결정하기 위해 사용된다.

규칙 플랫폼은 데이터베이스 쿼리 프로세서를 사용하여 최종 사용자 규칙을 평가한다. 이로 인해, 의미론이 플랫폼의 나머지 부분에 대하여 일관성을 유지하면서도, 효율적인 평가가 이루어진다.

일반적으로, 최종 사용자는 트레이닝된 개발자가 아니기 때문에, 전형적인 프로그래밍 언어로 프로그래밍할 것을 기대하는 것은 정당하지 않다. 오히려, 스키마화된 논리 빌딩 블럭들 제공되어, 최종 사용자가 간단하지만 풍부한 조합으로 그 블럭들을 모아서 스티치함으로써 프로그래밍할 수 있게 할 수 있다. 기존 어플리케이션들로부터의 경험적인 증거에 따르면, 최종 사용자들은 IF-THEN 규칙을 사용하여 결정 논리를 정의하는 것을 편안하게 생각할 수 있다. 따라서, 본 발명의 규칙 기반 플랫폼은 단순한 IF-THEN 규칙을 사용하여, 통합된 저장 플랫폼 내에서의 최종 사용자의 데이터 자동화를 가능하게 한다. 이것은 또한 부울 조건을 포함하는 쿼리 구축자를 채용하는 어플리케이션들의 호스트도 지원한다.

상기에 언급된 것과 그에 관련된 목적들을 달성하기 위하여, 본 발명의 일부 양태들이 이하의 상세한 설명 및 첨부 도면과 관련하여 설명된다. 그러나, 이러한 양태들은 본 발명의 원리가 채용될 수 있는 다양한 방식들 중의 극히 일부만을 나타낼 뿐이며, 본 발명은 그러한 양태들과 그 등가물을 모두 포함하는 것으로 의도된다. 이하의 본 발명의 상세한 설명을 첨부 도면들을 참조하여 읽으면, 본 발명의 다른 이점들 및 신규한 특징들도 분명하게 알 수 있을 것이다.

도 1은 본 발명의 규칙 아키텍쳐에 따른 최종 사용자 데이터 자동화 및 관리를 용이하게 하는 시스템을 나타낸 도면.

도 2는 본 발명의 규칙 아키텍쳐에 따른 스키마화의 한 방법론을 나타낸 도면.

도 3은 본 발명의 규칙 아키텍쳐에 따른 데이터 유도의 한 방법론을 나타낸 도면.

도 4는 본 발명의 규칙 아키텍쳐에 따른 부작용 논리의 트리거된 활성화의 한 방법론을 나타낸 도면.

도 5는 본 발명의 규칙 아키텍쳐에 따른 데이터 제약의 한 방법론을 나타낸 도면.

도 6은 본 발명의 규칙 아키텍쳐에 따라 결정 포인트에서 어플리케이션 커스텀화를 제공하는 한 방법론을 나타낸 도면.

도 7은 본 발명의 규칙 아키텍쳐의 항목 유형들 및 그들의 관계의 도면.

도 8은 본 발명의 규칙 아키텍쳐에 따른 조건 및 결과 처리의 도면.

도 9A는 본 발명에 따른 규칙의 일반적인 포맷을 나타낸 도면.

도 9B는 본 발명에 따른 활성 규칙의 일반적인 규칙 포맷을 나타낸 도면.

도 9C는 본 발명에 따른 어플리케이션 커스텀화 규칙을 위한 일반적인 규칙 포맷을 나타낸 도면.

도 9D는 본 발명에 따른 데이터 유도 규칙을 위한 일반적인 규칙 포맷을 나타낸 도면.

도 9E는 본 발명에 따른 데이터 제약 규칙을 위한 일반적인 규칙 포맷을 나타낸 도면.

도 10은 본 발명의 규칙 아키텍쳐에 따라 규칙들을 입력 항목들의 컬렉션에 첨부함으로써 규칙들을 적용하는 한 방법론을 나타낸 도면.

도 11은 본 발명의 규칙 아키텍쳐에 따라 규칙들을 결정 포인트에 첨부함으 로써 규칙들을 적용하는 다른 방법론을 나타낸 도면.

도 12는 본 발명의 규칙 아키텍쳐에 따라 규칙들을 직접 인보크함으로써 규칙들을 적용하는 다른 방법론을 나타낸 도면.

도 13은 본 발명의 규칙 아키텍쳐에 따라 규칙을 적용하는 다른 방법론을 나타낸 도면.

도 14는 본 발명에 따른 규칙 충돌 해결을 위한 한 방법론을 나타낸 도면.

도 15는 본 발명의 규칙 아키텍쳐에 따른 항목 유형들 및 연관 관계를 나타낸 도면.

도 16A는 본 발명의 EvaluationResultElement 네스트 유형을 나타낸 도면.

도 16B는 본 발명의 InputScope 네스트 유형 및 그 유도를 나타낸 도면.

도 16C는 RuleLogic(및 그 자식)과 DecisionPoints 둘다에 의해 사용되는 본 발명의 LogicConstraint 네스트 유형을 나타낸 도면.

도 16D는 조건 트리 및 결과(액션 또는 부울) 세트를 인코딩하는 LogicStatement 네스트 유형을 나타낸 도면.

도 16E는 본 발명의 LogicResult 네스트 유형 및 그 유도를 나타낸 도면.

도 16F는 본 발명의 Condition 네스트 유형 및 그 유도를 나타낸 도면.

도 16G는 본 발명의 ArgumentValue 네스트 유형과 그 유도를 나타낸 도면.

도 16H는 본 발명의 FunctionInfo 네스트 유형과 그 유도를 나타낸 도면.

도 17은 본 발명에 따른 규칙 엔진을 나타낸 도면.

도 18은 본 발명의 규칙 아키텍쳐에서의 풍부성의 차원을 나타낸 블럭도.

도 19는 본 발명의 규칙 아키텍쳐의 입력을 나타낸 도면.

도 20은 개시된 아키텍쳐를 실행하도록 동작할 수 있는 컴퓨터의 블럭도.

도 21은 본 발명에 따른 예시적인 컴퓨팅 환경의 개략적인 블럭도.

이하에서는, 본 발명이 첨부 도면들을 참조하여 설명되며, 그러한 첨부 도면들 전체에서 유사한 참조번호들은 유사한 구성요소를 나타낸다. 이하의 명세서에서는, 설명의 목적으로 본 발명에 대한 완전한 이해를 제공하기 위하여, 구체적인 세부사항들이 많이 제시된다. 그러나, 본 발명이 그러한 구체적인 세부사항없이도 구현될 수 있다는 것은 명백할 것이다. 한편, 본 발명을 용이하게 설명하기 위하여, 공지된 구조 및 디바이스들은 블럭도의 형태로 제시된다.

본 명세서에서, "컴포넌트" 및 "시스템"은 하드웨어, 하드웨어와 소프트웨어의 조합, 소프트웨어, 또는 실행중인 소프트웨어인 컴퓨터 관련 엔터티를 지칭하도록 의도된 것이다. 예를 들어, 컴포넌트는 프로세서 상에서 실행 중인 프로세스, 프로세서, 객체, 실행 파일, 실행 스레드, 프로그램 및/또는 컴퓨터일 수 있지만, 이에 한정되는 것은 아니다. 예를 들면, 서버 상에서 실행 중인 어플리케이션과 그 서버 둘다 컴포넌트일 수 있다. 하나 이상의 컴포넌트가 프로세스 및/또는 실행 스레드 내에 상주할 수 있으며, 컴포넌트는 하나의 컴퓨터 상에 국부화될 수도 있고 2개 이상의 컴퓨터 간에 분산될 수도 있다.

규칙 플랫폼

파일 시스템은 최종 사용자 데이터를 위한 레포지토리이다. 본 발명은, 최종 사용자가 적어도 4가지 방식 -데이터 유도, 트리거된 활성화, 데이터 제약 및 결정 포인트- 으로 최종 사용자 데이터를 "자동화"하는 논리를 정의하는 것을 허용한다. 통합된 규칙 저장 플랫폼은 공통 저장소 내의 스키마화된 데이터의 테마를 중심으로, 모든 지식 근로자 어플리케이션들을 한데 모은다. 그것은 데이터를 찾고 조직화하며, 데이터에 대응하는 것에 관한 것이다. 풍부한 쿼리와 풍부한 규칙은 동전의 양면과 같다. 풍부한 쿼리 및 뷰는 최종 사용자에게 데이터를 찾을 때의 증가된 컨트롤을 제공한다. 풍부한 규칙은 데이터 조직화의 자동화를 증가시키는 것은 물론, 능동적/반응적 거동들을 시스템 내에 구축하는 능력을 제공한다. 이러한 것들은, 현재의 PC 사용자가 개별 어플리케이션에 대해 기대하기 시작한 것들이다. 한가지 특징은 모든 데이터 및 어플리케이션들에 걸쳐 이러한 능력들을 표준화하는 것이다.

본 발명의 규칙 기반 아키텍쳐는 스키마화, 데이터 공유 및 정보 관리를 용이하게 한다. 데이터의 유비쿼터스적인 공통 스키마화는 최종 사용자 "프로그램"의 개발에 있어서 중심을 차지한다. 데이터 공유는 최종 사용자 프로그램에 있어서 흔하면서 당연한 것이다. 도착한 이메일 메시지, 그날의 캘린더 엔트리, 동참하려고 하는 사람들 및 그룹, 사용자의 현재 위치를 우선순위화하기로 결정하는 경우, 상이한 어플리케이션들에 의해 생성된 모든 스키마화된 데이터는 결정 수행을 위하여 당연히 한데 모아진다. 개시된 아키텍쳐는 어플리케이션들 간에서의 데이터 공유를 가능하게 한다. 본 발명의 중요한 양태는 조직화(폴더/리스트) 및 관계 전반에서의 정보 오버로드를 관리하는 능력이다. 대부분의 정보 오버로드 상황에서, 문제는 단순히 풍부한 폴더 및 카테고리를 갖는 것만이 아니라, 데이터를 수동으로 조직화/카테고리화하기 위한 시간을 갖는 것이다. 시스템이 풍부한 조직화 구성의 사용을 자동화한다면, 그 시스템은 최종 사용자에게 진정으로 가치있게 될 것이다.

규칙 생성 프레임워크는 규칙을 생성할 때와 규칙을 이용하여 어플리케이션을 구축할 때에 사용되는 항목 및 관계를 포함한다. 이러한 항목 및 관계는 규칙 플랫폼의 규칙 엔진에 의하여, 컴퓨터가 구체적인 이벤트에 응답하여 무엇을 행해야 하는지를 결정하기 위해 사용된다.

최종 사용자 규칙에 기초하여 어플리케이션 거동을 커스텀화하기 위해서는, 2가지 일이 발생한다. 프로그래머는 소프트웨어의 기능을 규칙-인에이블하고, 최종 사용자는 그러한 기능을 위한 규칙들을 생성한다. 예를 들어, 규칙 인에이블 오퍼레이팅 시스템 특징은, 사용자가 폴더 및 문서와 같은 항목에 대한 규칙을 정의할 수 있도록 포함된다. 이것은, 자신이 컴퓨터에게 원하는 거동을 표현하도록 최종 사용자에 의해 작성된 규칙 "프로그램"을 지원한다. 또한, 이러한 거동은 최종 사용자들이 이동할 때 함께 이주(migration)해야 한다. 개시된 규칙 아키텍쳐는 규칙들을 데이터로서 모델링하기 때문에, 데이터는 동기화 및 이주될 수 있다.

규칙은 복잡한 논리를 위한 단일의 선언적인 프로그래밍 구성이다. 모든 최종 사용자 논리 컴포넌트는 규칙으로서 정의된다. 모든 다른 구성은 단순한 2진 대수 연산자이다. 규칙은 특정 항목 유형의 입력 인수에 대하여 부작용없는 선언적인 함수를 정의한다. 규칙은 (입력 항목 유형과 출력 유형을 정의하는) 서명과 정의의 두 부분을 갖는다. 일반적으로, 출력 유형은 단순한 스칼라 유형, 항목 유형 또는 (결과 세트의 기대를 반영하는) 컬렉션 유형일 수 있다.

규칙은 단일 입력에 작용하는 것으로서 논리적으로 표현되지만, 평가 동안에는 종종 실제 입력들의 세트에 적용되는 경우가 있다. 흔한 예로서, Message 항목 유형에 대하여 정의된 규칙을 살펴보자. Message 유형은 Contact 항목 유형을 타겟으로 하는 관계 유형인 Recipient의 소스이다. 이것은 메일 메시지의 "To" 필드 내의 정보를 캡쳐한다. 본 예를 설명하기 위하여, 영어와 유사한 의사 언어가 규칙을 기술하는 데에 사용된다. 이것이 실제의 규칙 언어를 나타내는 것으로 오해되어서는 안되며, 오히려 규칙은 API 구성을 이용하여, 또한 의미있는 사용자 친화적 디스크립션을 갖는 친숙한 UI 조작을 이용하는 최종 사용자에 의해 코드로 표현된다.

규칙 정의는 0개 이상의 IF-THEN 문장의 순서화된 리스트이다. 규칙 내의 각각의 IF-THEN 문장은 조건 표현식(IF 부분) 및 결과 표현식 리스트(THEN 부분)를 갖는다. 조건 표현식은 부울 표현식 트리이며, 그 트리의 리프(leaf)들은 최종 사용자가 추리할 수 있는 기본 조건 연산자이다. 결과는 최종 사용자가 추리할 수 있는 상수 또는 간단한 표현식인 표현식들의 리스트이다.

다수의 IF-THEN 문장을 갖는 규칙의 의미론은 특정 입력 항목을 위한 출력과 관련하여 정의된다. 입력 항목 상에서 참인 것으로 평가되는 조건을 갖는 문장이 존재하지 않는 경우, 결과는 NULL이다. 참인 것으로 평가되는 조건을 갖는 문장이 단 하나만 존재하는 경우, 출력은 그 문장의 결과에 의해 정의된다. 참인 것으로 평가되는 조건을 갖는 복수의 문장이 존재하는 경우, 결과는 그러한 문장들 전부의 결과들에 대하여 충돌 해결 정책을 적용하는 것에 따라 달라진다. 흔한 충돌 해결 정책은 규칙 내에서의 문장들의 순위에 기초한다. 즉, 가장 높은 우선순위가 승리하는 것이다.

규칙 생성 프레임워크는 규칙 생성을 지원하기 위하여 항목 유형들 -결정 포인트 항목, 규칙 항목 및 규칙 세트 첨부 항목(RuleSetAttachment 또는 RSA로도 칭해짐)- 을 이용한다. 어플리케이션의 규칙 인에이블 특징들 각각은 결정 포인트 항목에 의해 정의된다. 최종 사용자는 특정 결정 포인트에 대하여 규칙을 생성하고, 어플리케이션은 결정 포인트 객체를 사용하여 규칙 엔진에 데이터를 제출한다. 각각의 조건/결과 문장은 Rule 문장 항목이다. 규칙은 실행을 위한 논리의 단위이다. 어플리케이션도 규칙을 생성할 수 있다. 어플리케이션은 디폴트 규칙을 시작 포인트로서 제공할 수 있다. 이러한 디폴트 규칙은 최종 사용자가 대안적인 규칙을 제공하거나 수정하기로 선택할 때까지 결정 포인트로서 사용될 것이다. 규칙은 RSA 항목을 통해 결정 포인트와 연관된다. 이러한 첨부는 규칙 엔진에 의하여, 주어진 입력에 대해 어느 규칙이 실행될지를 결정하기 위하여 사용된다.

다른 데이터 컬렉션들과 결합/조합되는 조건들을 정의하는 것도 가능할 수 있다. 또한, 다른 규칙들에서 사용될 수 있는 가상 컬렉션들을 포함하는 컴포넌트화된 논리를 지정하는 것도 가능하다.

비동기적인 거동 규칙들에 대하여, 결과들은 파일 시스템 유형 및 임의의 CLR 유형 상의 메소드, 또는 임의의 정적 메소드인 액션들을 기술한다. 동기적인 거동 규칙들에 대하여, 결과는 어플리케이션 특정 유형, 예를 들어 파일명, 스트링, 평가될 객체, 열거된 색상 리스트 중의 한 색상의 값들의 세트이다.

규칙 플랫폼은 표준의 풍부한 규칙 사용자 인터페이스(UI)를 포함한다. 준수되는 원칙들을 열거해보면 다음과 같다. 규칙과 뷰/쿼리 둘다를 위한 공통의 UI가 존재한다; 전체 작성 프로세스가 단일 스크린 내에서 발생할 수 있다; 탬플릿들에 대한 균일한 추상화가 지원된다; 값 선택은 풍부한 유형별 컨트롤[예를 들어, 데이터 피커(data picker)]를 지원할 수 있다; 및 UI는 확장될 수 있다(즉, 새로운 항목 유형이 추가되면, 그에 대한 규칙을 자동으로 작성하고 그 조건 및 액션을 포함시키는 것도 자동적으로 가능하게 된다. 오퍼레이팅 시스템 규칙에 대하여, 사용자는 시각적 브라우징 메타포를 갖는 UI 액션을 통해, 결정 포인트에 규칙을 첨부한다. 그러나, 어플리케이션은 사용자를 위한 결정 포인트를 결정하기 때문에, 다른 어플리케이션들은 사용자를 위한 첨부를 생성할 수 있다.

이제 도 1을 보면, 본 발명의 규칙 아키텍쳐에 따라 최종 사용자 데이터 자동화 및 관리를 용이하게 하는 시스템(100)이 도시되어 있다. 규칙 아키텍쳐는 최종 사용자가 다음과 같은 4가지 방식으로 "데이터를 자동화"하는 논리를 정의하는 것을 허용한다. 첫째로, 데이터 유도는 컨텐츠 기반 논리를 사용하여 시스템 내의다른 항목들로부터 "가상" 컬렉션 및 항목들을 정의하는 것을 용이하게 한다. 예를 들어, Contact들의 전체 세트 중 Bellevue에 주소를 갖는 Contact들의 서브세트인 PeopleWhoLiveInBellevue로 칭해지는 컨택트 그룹을 정의한다. 둘째로, 부작용 논리의 트리거된 활성화는, 컬렉션 및 항목들을 트리거 논리로 연관시킴으로써 그들을 활성화시키는 것을 용이하게 한다. 예를 들면, Specifications 컬렉션에 추가되는 임의의 새로운 문서가 이메일에 의한 작성자로의 통지를 유발할 것을 선언하는 것에 의한 것이 있다. 셋째로, 데이터 제약은 항목들에 제약 논리를 부과하는 것을 용이하게 한다. 예를 들면, Indigo 폴더 내의 임의의 이메일은 제목에 "Indigo"를 포함하거나 인디고 메일링 리스트에 보내졌을 것을 요구하는 것에 의한 것이 있다. 마지막으로, 데이터 구동 결정은 어플리케이션 인터셉터 포인트에서 풍부한 어플리케이션 커스텀화 논리를 지원하는 것을 용이하게 한다. 예를 들면, 발송 메일 메시지의 컨텐츠 및 목적지에 기초하여, 그 메일에 어떤 서명이 첨부되어야 하는지를 지정하는 것에 의한 것이 있다.

이들을 지원하기 위하여, 시스템(100)은 데이터에 연관된 항목들을 추적하는 모니터링 컴포넌트(102)를 포함한다. 규칙 평가 컴포넌트(104)는 추적되는 항목에 연관된 메타데이터를 채용하여, 항목들의 서브세트에 대한 자동화된 핸들링을 제공한다. 또한, 시스템은 컨텐츠 기반 논리를 이용하여 시스템 내에 가상 컬렉션 및 항목을 정의하는 것을 용이하게 한다. 시스템은 항목들 및 항목들의 컬렉션들을 트리거 논리의 함수로서 동적으로 활성으로 설정하는 하나 이상의 트리거 컴포넌트(106)를 더 포함한다. 추가 컴포넌트는 항목들에 제약 논리를 부과하기 위한 제약 컴포넌트(106) 및 결정 포인트에서 어플리케이션 커스텀화 논리의 인에이블을 지원하는 결정 컴포넌트(108)를 포함할 수 있다. 결정 컴포넌트(108)는 어플리케이션에 의해 노출될 수 있는 하나 이상의 결정 포인트는 물론, 이벤트 또는 결정 포인트를 제출하는 API도 나타낸다.

이제 도 2를 보면, 본 발명의 규칙 아키텍쳐에 따른 스키마화의 한 방법론이 도시되어 있다. 예를 들어 흐름도의 형태로 여기에 제시된 하나 이상의 방법론은 설명을 간단히 하기 위하여 일련의 동작들로 도시 및 설명되어 있지만, 본 발명에 따르면, 일부 동작들은 다른 순서로 발생할 수도 있고 여기에 도시 및 설명된 다른 동작들과 동시에 발생할 수도 있으므로, 본 발명은 이러한 동작들의 순서로 제한되지 않는다는 점을 명심해야 한다. 예를 들어, 본 기술 분야의 숙련된 기술자라면, 방법론이 상태도에서와 같이 일련의 상호관련된 상태들 또는 이벤트들로서도 표현될 수 있음을 알 것이다. 또한, 본 발명에 따른 방법론을 구현하기 위하여 여기에 개시된 모든 동작들이 반드시 필요한 것은 아니다.

스키마화(schematization)는 데이터 및 논리를, 다수의 어플리케이션이 그 데이터 및 논리를 인식하고 상호작용할 수 있게 하는 잘 알려지고 정의된 패턴으로 구조화하는 것으로서 정의된다. 데이터의 유비쿼터스적인 공통 스키마화는 최종 사용자 "프로그램"의 개발에 있어서 중심을 차지한다. 본 발명에 따르면, 적어도 3가지의 스키마화가 최종 사용자 데이터 자동화를 가능하게 한다. 단계(200)에서, 최종 사용자 데이터 자동화를 용이하게 하는 스키마화를 위해, 데이터 및 논리가 수신된다. 단계(202)에서, 데이터가 스키마화된다. 스키마화된 정보는 최종 사용자 어플리케이션의 기본인 데이터이다 (예를 들어, 이메일, 사람들, 그룹 및 위치). 이것은 어플리케이션들에 의한 데이터의 일관된 해석을 허용한다. 단계(204)에서, 논리 구축 블럭들에 대하여 이벤트들이 스키마화된다. 스키마화된 정보 이벤트는 논리를 첨부하기 위한 후크를 제공하는 이벤트이다. 이러한 이벤트는 하이레벨이며, 최종 사용자에게 의미가 통하는 정보 흐름에 속박된다. 예를 들어, 이메일 메시지의 도착은 그러한 이벤트일 수 있다. 이벤트는 어플리케이션들 내에서의 동기적인 인터셉터 포인트일 수도 있고, 논리가 바인딩될 수 있는 비동기적인 이벤트일 수도 있다. 단계(206)에서, 규칙을 통해 데이터(또는 정보) 및 이벤트를 핸들링하기 위하여 논리 빌딩 블럭들이 스키마화된다. 최종 사용자는 일반적으로 트레이닝된 개발자가 아니기 때문에, 전통적인 프로그래밍 언어를 프로그래밍하기를 기대하는 것은 정당하지 않다. 오히려, 스키마화된 논리 빌딩 블럭들이 제공되어, 최종 사용자들이 그 블럭들을 간단하면서도 풍부한 조합으로 스티치함으로써 프로그래밍할 수 있게 한다.

이제 도 3을 보면, 본 발명의 규칙 아키텍쳐에 따른 데이터 유도의 한 방법론이 도시되어 있다. 단계(300)에서, 처리를 위해 데이터가 수신된다. 단계(302)에서, 컨텐츠 기반 논리를 사용하여 시스템 내의 다른 항목들로부터 "가상" 컬렉션 및 항목을 정의함으로써 데이터를 자동화하기 위하여 규칙 아키텍쳐의 하나 이상의 규칙이 적용된다. 예를 들어, 가상 컬렉션은 Contact들의 전체 집합 중에서 City에 주소를 갖는 Contact들의 부분집합인 PeopleWhoLiveInCity로 칭해지는 컨텍트 그룹을 정의함으로써 생성될 수 있다.

이제 도 4를 보면, 본 발명의 규칙 아키텍쳐에 따른 부작용 논리의 트리거된 활성화를 위한 한 방법론이 도시되어 있다. 단계(400)에서, 처리를 위해 데이터가 수신된다. 단계(402)에서, 트리거 논리를 이용하여 활동을 트리거 이벤트에 연관시킴으로써, 컬렉션 및 항목이 활성으로 된다. 예를 들어, Specification 컬렉션에 추가되는 임의의 새로운 문서가 이메일에 의한 그 작성자로의 통지를 유발할 것을 선언한다.

이제 도 5를 보면, 본 발명의 규칙 아키텍쳐에 따른 데이터 제약의 한 방법론이 도시되어 있다. 단계(500)에서, 처리를 위해 데이터가 수신된다. 단계(502)에서, 제약 논리가 항목에 부과된다. 데이터 제약의 일례로는 Name 폴더 내의 임의의 이메일이 제목에 "Name"을 갖거나 Name 메일링 리스트에 보내졌을 것을 요구하는 것이 있다.

이제 도 6을 보면, 본 발명의 규칙 아키텍쳐에 따라 결정 포인트에서 어플리케이션 커스텀화를 제공하는 한 방법론이 제공된다. 단계(600)에서, 결정 포인트에서의 처리를 위해 데이터가 수신된다. 어플리케이션 인터셉터 (또는 결정) 포인트에서 풍부한 커스텀화 논리가 제공된다. 따라서, 단계(602)에서, 결정 포인트에 첨부된 규칙들이 처리된다. 데이터 구동 결정 포인트의 일례로는, 발송 메일 메시지의 컨텐츠 및 목적지에 기초하여, 그 메시지에 어느 서명 파일이 첨부되어야 하는지를 지정하는 것이 있다. 단계(604)에서, 어플리케이션 결정이 리턴된다.

이제 도 7을 보면, 본 발명의 규칙 아키텍쳐의 항목 유형들 및 그들의 관계에 관한 도면이 도시되어 있다. 입력 범위는 임의의 유형의 임의의 항목이다. 입력 범위는 규칙 평가의 범위를 특정 항목 또는 폴더로 제한하기 위하여 오퍼레이팅 시스템에 의해 사용되지만, 일반적으로 개별 어플리케이션에 의해서는 사용되지 않는다. 이 도면의 라인 상에 있는 레이블들은 항목들 간의 관계의 이름을 보여주고 있다. RuleSetAttachment 항목은 DecisionPoint 항목과 Rule 항목 간의 연결을 나타낸다. 이러한 연결은 물리적으로 저장된 "링크" 또는 계산된 "공통값 연관(common value assciation)"으로서 모델링될 수 있다. 어느 경우에서든, 그 기능은 Rule과 그 Rule이 생성될 때의 대상이었던 DecisionPoint 간의 연결로서 서로 동일하다. 결정 포인트 항목들은 어플리케이션이 규칙 플랫폼을 사용할 수 있게 해 준다. 규칙은 제약, 조건 및 결과를 포함하는 규칙 항목들을 기술한다. 규칙은 규칙 문장들을 포함한다. 규칙은 결정 포인트에 첨부되며, 어플리케이션은 결정 포인트에 입력을 제공하여 결과를 리턴한다.

이제 도 8을 보면, 본 발명의 규칙 아키텍쳐에 따른 조건 및 결과 처리의 도면이 도시되어 있다. 규칙 플랫폼은 최종 사용자 규칙 논리의 정의 및 실행을 위한 기반구조를 제공한다. 규칙 스키마는 항목 유형들에 연관된 파라미터화된 조건 및 결과를 제공한다. 예를 들어, EmailMessage 항목 유형에는 조건 IsFrom, IsTo 등이 연관되어 있을 수 있다. 본 발명에 따른 최종 사용자 프로그래밍을 용이하게 하기 위해 사용될 수 있는 규칙 플랫폼을 위한 항목 유형(800)들의 완전한 세트가 제공된다. 항목 유형(800)은 ITEMTYPE₁: CONDITION₁/RESULT₁, ITEMTYPE₂: CONDITION₂/RESULT₂..., ITEMTYPE_N: CONDITION_N/RESULT_N으로 나타난다. 입력(802)으로서, 보다 더 간단한 조건들의 일부가 항목 유형으로부터 자동으로 유도되는 반면, 다른 조건들(804)은 개발자에 의해 명시적으로 지정될 수 있다. 사용자는 인수값(806)을 항목 유형(800)에 입력한다. 선택된 항목 유형(800)의 이러한 조건 및 결과들은 최종 사용자 논리를 위한 출력 "명령어 세트"(808)로 된다. 규칙 내의 조건 및 결과는 개발자 정의 조건 및 결과의 인스턴스로서, 최종 사용자에 의해 지정된 인수값을 갖는다. 각각의 규칙은 항목의 모든 공유, 보안 및 동기화 능력과 함께, 항목으로서 존속된다.

최종 사용자 논리 "프로그램", 즉 출력 명령어 세트(808)는 규칙들의 세트이며, 이것은 규칙 문장들의 세트이다. 완전한 논리의 단위는 하나 이상의 규칙을 포함한다. 각각의 규칙은 작성의 단위이다. 규칙에 대한 입력은 데이터 항목이라는 점에 주목하자. 규칙은 특정한 항목 유형을 갖는 항목에 관한 선언적인 문장이다. 기본 모델에 대한 확장으로서, 비항목(non-itme) 데이터[트랜션트 데이터(transient data) 또는 XML]가 규칙 입력으로서 제공될 수 있다. 규칙이 적용될 수 있는 항목들은 규칙의 전개(deployment)에 따라 달라진다. 규칙은 전개가능한 사용자 논리의 단위이다. 규칙은 그것을 항목 범위(결정 포인트 또는 항목 입력의 소스)에 첨부함으로써 전개된다. 이러한 연관은 RuleSetAttatchment로서 캡쳐된다. Rule 및 RuleSetAttachment(RSA)는 항목일 수 있다 (나중에 더 설명되는 바와 같이, 항목들 간의 명명된 공통값 관계일 수 있다).

활성 규칙의 경우에서, 항목 범위는 항목 컬렉션이다. 규칙이 어플리케이션을 인터셉트하고 커스텀화하기 위해 사용될 때, 어플리케이션은 그 규칙이 적용되는 항목을 제공한다.

규칙은 최종 사용자 커스텀화 요청을 집합적으로 정의한다. 규칙 내에 있는 각각의 Rule 문장은 최종 사용자 의도의 한 문장에 대응한다. 다수의 규칙이 적용될 수 있는 경우, 충돌 해결자가 액션들에 적용될 수 있다.

이제 도 9A 내지 도 9E를 보면, 본 발명의 규칙 아키텍쳐에 따른 규칙들의 대표적인 포맷이 도시되어 있다. 최종 사용자의 관점에서 볼 때, Rules == Views == Queries이다. 규칙 플랫폼은 다음과 같은 적어도 3가지의 원칙을 따른다. 규칙은 선언적인 IF-THEN 표현식이다. 규칙을 위한 데이터 모델은 데이터 모델이며 따라서 임의의 항목 유형은 규칙에 참여할 수 있다. 그리고, 규칙은 데이터 모델에 대하여 데이터베이스 쿼리 프로세서 내에서 평가된다.

뷰는 존속된 쿼리이지만, 표현력에 있어서는 쿼리와 다르지 않다. 사실, 뷰와 규칙은 공통의 존속 조건을 공유한다.

공통성(commonality)에 관한 이러한 설명은 필터 쿼리에 대해서도 적용되긴 하지만, 보다 더 풍부한 의미론[예를 들어, 집계(aggregation)]을 사용하는 본격적인 SQL 쿼리(full-blown SQL query)에 대해서는 분명히 통하지 않는다. 그러한 쿼리는 개발자가 어플리케이션에서 사용하는 것에 관련성이 있다. 그러한 쿼리는 보다 더 풍부한 규칙 시스템과 공통성을 갖는다.

최종 사용자 쿼리는 일반적으로 단순한 필터이다. 흥미롭게도, 이러한 클래스의 필터 쿼리들은 OPath 언어에 의해서 제공되는 것이기도 하다.

도 9A는 본 발명에 따른 규칙의 일반적인 포맷을 나타내고 있다. 규칙은 단순히 ON(각각의 데이터 항목) IF(조건이 참임) THEN(결론)의 형태를 갖는 문장들의 세트이다. 이것은 결정, 진실, 및 일반적으로는 다양한 선언적 문장을 표현하는 데에 사용될 수 있다. 쿼리는 제한된 형태의 규칙으로서, 그 규칙의 결론은 결과 내에 항목을 포함시키는 것으로 제한된다 (일반적으로, 항목의 배제도 가능한 결론이다). 쿼리의 결과의 컨텐츠를 정의하는 선언적인 문장은 ON(각각의 데이터 항목) IF(조건이 참) THEN(쿼리 결과 내에 항목을 포함)이다. 이것이야말로, 쿼리가 관계형 연산법(relational calculus)에서 어떻게 모델링되는지를 나타내는 것이며, 초기에 SQL 언어는 이에 기초하여 모델링되었다. 활성 규칙의 경우에서, 규칙의 결론은 실행된 부작용 액션으로서 해석된다.

규칙들이 선언적이기 때문에, 상이한 평가 알고리즘들이 가능하다. 레이턴시가 낮은 알고리즘은 클라이언트 머신에 적합한 반면, 처리량이 높은 알고리즘은 서버에 적합하다. 규칙은 항목으로서 존속되어, 보안, 공유 및 동기화의 영역에서 표준적인 거동을 유발한다.

규칙의 조건들은 입력 항목 유형에 의해 정의되는 기본 술어들을 조합하는 부울 표현식이다. 항목 속성들에 대한 공통 비교 조건들은 물론, 스키마 개발자에 의해 정의된 고급의 조건 메소드들도 지원된다. 첫번째 원칙은 최종 사용자 규칙 내의 조건들과 최종 사용자 쿼리 내의 조건들이 표현력과, 표현식의 편의성 및 메타포(metaphor)에 있어서 반드시 동일해야 한다는 것이다. 두번째 원칙은 최종 사용자 뷰가 다른 규칙/쿼리/뷰와 조합가능해야만 한다는 것이다. 이에 의해, 조합가능한 빌딩 블럭들을 통하여 풍부한 최종 사용자 논리가 구축될 수 있게 된다. 관계들 및 데이터 컬렉션들에 걸쳐 조건을 표현하는 것이 가능하다는 점에 유의해야 한다 (데이터베이스 어법으로는 "조인(join)"이지만, 평균적인 최종 사용자에게 의미있게 양식화된 방식으로 제시되었다).

규칙의 결과는 단순히 데이터이다. 규칙이 어플리케이션 커스텀화에 사용되는 경우, 그 규칙들은 소비 어플리케이션에 의해 해석될 필요가 있다. 활성화 규칙(이것은 부작용 액션을 갖는 이벤트 트리거 거동을 제공함)의 경우에서, 결과는 수행될 액션에 대응한다. 규칙 플랫폼은 이러한 액션들이 실행되는 호스팅 서비스를 제공한다.

규칙 항목은 관계들의 세트를 포함하는 항목이다 (예를 들어, 규칙 항목들을 '포함'함). 규칙의 논리적 거동은 특정 유형의 단일 입력 항목 상에서 정의된다. 규칙은 입력 항목들에 적용된다.

데이터베이스 내의 프로그래밍 구성의 주된 종류는 트리거, 저장된 프로시져(sproc), 뷰/쿼리 및 제약이다. 마찬가지로, 본 발명에 따른 최종 사용자 프로그래밍은 활성 규칙(트리거), 커스텀화 규칙(sprocs), 유도 규칙(뷰) 및 제약 규칙(제약)을 갖는다.

도 9B는 본 발명에 따른 활성 규칙을 위한 일반적인 규칙 포맷을 도시하고 있다. 활성 규칙은 컴퓨터가 사용자를 대신하여 액션을 수행해야 할 필요가 있는 임의의 시나리오, 예를 들어 카메라로부터 다운로드되고 있는 사진들을 자동으로 조직화할 때; 수신 이메일, 전화 통화 및 IM을 처리, 필터링 및 포워드할 때; 사용자에게 관련성있는 통보를 알려줄 때; 및 최종 사용자에 의해 정의된 간단한 애드혹 "워크플로우"에서 사용된다.

활성 논리는 ON(항목) IF(조건) THEN(액션)의 형태로 된 규칙에 의해 정의된다. THEN 절 내의 결과는, 저장 스키마 개발자에 의해 정의되거나, 저장 시스템에서 이용할 수 있는 기본 동사들의 세트(예를 들어, Move 및 Add)로부터 선택된 실행가능 액션에 대응한다. 숙련된 개발자는 최종 사용자 규칙을 위한 조건 및 액션을 정의하기 위하여, 특수화된 스키마 또는 스키마 확장을 정의할 수 있다.

활성 규칙이 항목 범위에 첨부될 수 있는 방식에는 2가지가 있다. 첫째로, 활성 규칙은 주기적인 의미론(periodic sementics)으로 항목 컬렉션에 첨부될 수 있다. 규칙은 각각의 항목에 주기적으로 적용되며, (임의의 충돌들이 해결된 후) 적합한 액션이 발생한다. 둘째로, 활성 규칙은 이벤팅 의미론(eventing semantics)으로 항목 컬렉션에 첨부될 수 있다. 항목 컬렉션 내에서 변경이 발생할 때마다, 규칙이 그 변경된 항목에 대하여 실행된다.

도 9C는 본 발명의 어플리케이션 커스텀화 규칙을 위한 일반적인 규칙 포맷을 도시하고 있다. 오늘날의 어플리케이션의 거동은 그다지 커스텀화 가능하지 않다. 전형적으로, 임의의 커스텀화는 단순한 옵션 세팅들에 기초한다. 그 대신에, 규칙들은 최종 사용자가 현재의 어플리케이션 및 사용자 컨텍스트에 기초하는 데이터 구동 논리로, 다양한 인터셉터 포인트에서 어플리케이션들을 커스텀화할 수 있게 해 준다. 커스텀화 규칙은 최종 사용자 컨트롤을 위한 포인트를 제공하려고 하는 임의의 어플리케이션에 의해 사용될 수 있다. 이에 대해 생각해 볼 수 있는 한가지 방식은, 어플리케이션의 Tools->Options 구획(pane)을 통해 설정할 수 있는 모든 값이 상수로서는 물론 결정 논리를 통해서도 정의될 수 있어야 한다는 것이다. 예를 들어, 발송 메일 메시지에 어느 서명 파일이 적용되어야 할지, 사용자를 통보로 인터럽트할지의 여부 등을 결정하는 규칙이 있다.

어플리케이션 커스텀화 규칙은 ON(항목) IF(조건) THEN(결과)의 형태를 갖는다. 어플리케이션은 하나의 항목, 또는 항목들의 세트를 입력으로서 제공한다. 결과들이 실제로 규칙 평가의 일부로서 자동으로 실행되지는 않는다. 오히려, 이 결과들은 단순히 어플리케이션이 적절하게 해석하기 위한 규칙 실행의 결과로서 반환된다.

도 9D는 본 발명에 따른 데이터 유도 규칙을 위한 일반 규칙 포맷을 도시하고 있다. 최종 사용자는 컨텐츠 기반 필터를 이용하여 항목들의 세트를 정의하기 위한 규칙을 정의할 수 있다. 이것은 유도된 항목세트(derived itemset)로 칭해진다. 오퍼레이팅 시스템의 시각적 브라우징 메타포는 밀접하게 관련된 아이디어를 캡쳐하는 동적 세트(Dynamic Set)의 개념을 갖는다. 모든 최종 사용자 쿼리 및 뷰는 이러한 카테고리의 범주 내에 포함된다.

유도 규칙은 ON(항목) IF(조건) THEN(포함/배제)의 형태를 갖는다. 허용되는 유일한 결과가 포함 및 배제임에 주목해야 한다. 규칙은 항목 범위에 첨부됨으로써 전개된다. 결과적으로 유도된 ItemSet는 규칙에 의해 "포함"되는 소스 세트 내의 항목들을 포함한다. 실제로, 이러한 유도 규칙은 항목 범위 상에 풍부한 필터를 정의한다.

유도된 ItemSet의 몇몇 예를 들면, 무효가 아닌 집 전화번호를 갖는 Contacts 및 사업상의 컨택트로서 표시되지 않은 Contacts로서 정의된 MyFriends로 칭해지는 사람들의 그룹; 및 MyFriends 내의 임의의 사람으로부터 온 InBox 내의 임의의 이메일로서 정의되는 InBoxMailFromMyFriends로 칭해지는 이메일 세트가 있다.

유도된 항목세트들의 정의들은 조합될 수 있다는 점에 유의해야 한다. 예를 들어, InBoxMailFromMyFriends는 MyFriends의 정의를 사용한다. 최종 사용자가 모듈러 정의(modular definition)를 구축하기 위하여, 이러한 조합가능성은 매우 중요하다. 또한, 유도된 항목세트의 모듈러 정의는 다른 종류의 규칙들이 보다 더 표현적이게 한다. 예를 들어, InBox 내의 활성 규칙은, 발송자가 MyFriends 내에 있으면, 메일이 "개인용"으로 표시되어야 한다는 것을 나타낼 수 있다.

도 9E는 본 발명에 따른 데이터 제약 규칙의 일반적인 규칙 포맷을 도시하고있다. 최종 사용자는 ON(항목) IF(조건) THEN(허용/불허)의 형태를 갖는 규칙들을 이용하여 항목 컬렉션에 관한 제약을 지정할 수 있다. 제약 규칙은 기존 항목 컬렉션에 적용되며(이것은 규칙에 대한 항목 범위임), 그 항목 컬렉션에 대한 변경(삽입/업데이트/삭제)에 의해 활성화된다. 활성화는 변경에 동기적이다. (규칙 결과가 "불허"인 경우) 실패에 대하여 가능한 거동은 복수개 존재한다. 변경(전형적으로 항목 추가) 자체가 실패할 수도 있다. 다르게는, 컬렉션에 추가되려고 하는 항목이 제약에 순응하도록 수정될 수 있다.

각각의 규칙은 규칙 입력, 허용되는 조건, 및 허용되는 규칙 결과의 유형을 지정하는 규칙 제약에 연관된다. 예를 들면, 유도된 항목 세트를 정의하거나 쿼리를 행할 때에 사용되는 규칙들은, 자신의 결과를 입력 항목의 포함 또는 배제로 제한한다. 최종 사용자는 규칙 제약을 다루지 않는다. 최종 사용자가 특정 결정의 컨텍스트에서 지정할 수 있는 논리를 제약하는 것은 어플리케이션 및 개발자 개념이다. RuleConstraint 유형은 이러한 제약들을 기술하는 데에 사용된다.

제약 규칙과 유도 규칙이 매우 유사하다는 것이 관찰될 수 있다. 그러나, 차이점은, 제약 규칙이 컬렉션 내의 멤버쉽에 대한 필요 조건을 지정할 뿐이라는 것이다. 제약 규칙은 컬렉션이 어떻게 채워져야 하는지에 대해서는 정의하지 않는다 (즉, 규칙 논리가 적용되는 항목들의 도메인이 존재하지 않는다).

최종 사용자 프로그래밍(End-User Programming, EUP) 모델

통상적으로, 파일 시스템을 위한 설계 작업의 대다수는, 예를 들어 시맨틱 복사, 수명 관리 등과 같은 "수동" 상호작용의 영역에서, 최종 사용자 요구조건의 이해에 기초해 왔다. 이러한 요구조건들은 포착되어 코어 파일 시스템 데이터 모델 및 API에 삽입되어 왔다. 그러나, 파일 시스템 데이터와의 최종 사용자 상호작용을 위한 전체 요구조건은, 최종 사용자에 의해 프로그래밍되는 데이터 조작과의 보다 더 풍부하고 동적인 상호작용을 포함시키는 것에 의해, "수동" 상호작용보다 더 광범위하게 된다.

EUP의 설계는 요구조건들의 주된 구동자인 최종 사용자의 생각에 관련된 4가지의 중심 원칙에 기초한다.

조합 논리(compositional logic). 복잡한 논리는 보다 더 단순한 구조를 갖는 보다 더 작은 조합 단위를 이용하여 구성된다. 모든 최종 사용자 프로그램은 선언적이다. 최종 사용자 프로그램은 논리 컴포넌트들의 조합에 의해 구성된다. 논리 컴포넌트들이 어떻게 한데 모아질 수 있는지를 정의하는 EUP 대수(algebra)가 존재한다. 각각의 논리 컴포넌트는 최종 사용자에게 의미가 통할 수 있는 논리의 단편이다. 논리 컴포넌트가 쿼리를 정의하는 데에 사용되는지, 아니면 복합 동사 또는 제약을 정의하는 데에 사용되는지에 상관없이, 그 논리 컴포넌트는 공통의 IF-THEN 규칙 구성을 이용하여 정의된다. 공통 논리 모델에 더하여, 이것은 어플리케이션들 간에서의 규칙 논리의 공통의 시각적 프리젠테이션을 허용한다.

프로그램을 데이터로서 관리. 모든 EUP 프로그램 및 모든 EUP 논리 컴포넌트는 파일 시스템 항목으로서 표현된다. 최종 사용자들의 관점에서 볼 때, 그들이 정의한 복잡한 액션 또는 필터는 그들이 편집한 문서와 다르지 않다. 공유, 동기화, 백업, 보안 등의 관점에서 볼 때, 이것은 한 부분의 데이터이다. 유용한 부작용은 EUP 개념과 상호작용하는 API 표면이 임의의 데이터 항목과 상호작용하는 표준 API 표면이라는 것이다.

최종 사용자 유연성. 이것은 최종 사용자에게 힘과 유연성을 주는 것에 관한 전부이다. 예를 들어, 최종 사용자는 새로운 최종 사용자 유형을 정의하고, 기존 유형을 동적으로 수정하고, 쿼리를 정의하여 존속시키고, 특정 항목에 영향을 미치는 "비지니스 논리"를 정의하는 것 등을 행할 수 있다. 이들은 선언적이고 대수적이며 규칙 기반인 적합한 추상화 레벨에서 기술된다.

어플리케이션들 간의 공통 모델. 한 어플리케이션 또는 사용자에게 제공된 시각적 브라우징 메타포에서 최종 사용자가 행하는 작업은 다른 어플리케이션들에게까지 전파될 수 있다. 예를 들어, 한 메타포 내에서 문서 유형에 대한 최종 사용자 속성이 설정되는 경우, 최종 사용자는 그 메타포의 소정의 다른 부분 또는 다른 파일 시스템 어플리케이션 내의 문서에 대하여 쿼리를 정의할 때 그 속성을 사용할 수 있을 것으로 기대할 수 있다.

데이터의 EUP에는 5가지의 기본적인 양태, 데이터 유형, 논리, 쿼리 및 뷰, 동사 및 자동화, 결정, 및 제약이 존재한다. 데이터 유형은 유형 맵핑 및 속성 맵핑을 포함한다. 유형 맵핑은, 최종 사용자가 볼 수 있으며 또한 그 사용자가 추리할 수 있는 데이터 유형들과, 그 유형들이 파일 시스템에 어떻게 맵핑되는지를 연루시킨다. 속성 맵핑은 최종 사용자 데이터 유형과 관련하여 사용자가 볼 수 있는 속성들과, 그 속성들이 하부의 저장 유형에 어떻게 맵핑되는지를 연루시킨다.

논리는 쿼리, 자동화, 제약 및 어플리케이션 커스텀화를 포함한다. 프로그래밍 모델은 최종 사용자 논리를 정의하고, 작성 모델(authoring model)은 최종 사용자가 복잡한 논리를 어떻게 정의할 수 있는지를 정의한다. 최종 사용자 논리 존속이 제공되며, 관리는 최종 사용자 논리가 어떻게 공유되고 관리되는지, 및 명명, 공유, 동기화 등을 위한 메커니즘을 기술한다.

쿼리 및 뷰는, 예를 들어 최종 사용자에게 제시하기 위한 올바른 필터링 및 쿼리 추상화를 기술하는 표현적 모델을 제공한다. 거동은 최종 사용자가 항목을 오토리스트(autolist)(예를 들어, 리스트와 유사하게 거동하는 오토리스트)로/로부터 드래그할 때에 기대되는 거동이 무엇인지를 고려한다. 프리젠테이션 추상화와 관련하여, 최종 사용자에게 오토리스트를 프리젠테이션하는 것에 관련된 논리적 정보의 세트(예를 들어, 프로젝션 속성, 소트 순서, 페이지 매김), 및 소정의 물리적 정보(페이지 치수 등)가 존재한다.

동사 및 자동화는, 하부 데이터 모델의 용어로 최종 사용자 "동사"가 무엇인지, 새로운 복합 조건 동사가 최종 사용자에 의해 어떻게 구성되는지, 항목에 대한 동사의 적용이 항목들의 세트에, 그리고 보다 더 풍부한 동사에 어떻게 적용될 수 있는지, 동사의 적용이 어떻게 자동화되는지를 기술한다.

결정은, (최종 사용자 커스텀화 규칙에 의해 정의되는) 어플리케이션 커스텀화 결정이 어떻게 모델링되는지를 기술한다.

제약은 최종 사용자가 항목/항목세트의 컨텐츠 및 시행가능한 의미론에 대한 제약을 어떻게 정의할 수 있는지를 기술한다.

최종 사용자 프로그래밍(EUP) 대수 내에는 5개의 기본항이 존재한다.

Property(T) : 이것은 최종 사용자 유형 T의 속성을 기술한다. 사용자는 필터 및 액션을 기술하기 위하여 속성을 사용한다.

Filter(T) : 이것은 유형 T의 항목들에 대한 필터로서 사용될 수 있는 부울 함수를 정의한다. 이것은 반환 유형이 부울인 규칙이다.

Event(T) : 이것은 관심의 대상이 되는 발생을 정의한다. 이것은 전형적으로 유형 T를 갖는 데이터 항목(이벤트 데이터)에 연관된다.

Action(T) : 이것은 항목 유형 T의 부작용 메소드이며, 전형적으로 다른 파라미터들을 요구한다.

Set(T) : 이것은 유형 T의 항목들의 세트이다.

이러한 항들 각각의 인스턴스는 시스템 내에서 개발자에 의해 정의된 항목 스키마들로부터 유도된다. Set(T)의 경우에서, 이러한 항의 인스턴스는 파일 시스템 내의 컬렉션들 중 임의의 것일 수 있다. 그러나, 이러한 항들 각각의 인스턴스는 단순한 대수 구성자를 통해서, 또는 규칙을 통해서 최종 사용자에 의해 구성될 수도 있다. 이하의 기본항들은 규칙들을 사용하여 구성될 수 있다.

Property(T) : 입력 항목 유형이 T이고 출력 유형이 O인 규칙은 유형 T에 대하여 유형 O의 속성을 정의한다.

Filter(T) : 입력 항목 유형이 T이고 출력 유형이 부울인 규칙은 유형 T인 항목들에 대하여 필터를 정의한다.

Action(T) : 입력 항목 유형이 T이고 출력 유형을 갖는 규칙은 유형 T인 항목들에 대하여 액션을 정의한다.

각각의 규칙에서, <property><comparison operator><expression>, <existing filter>, ANY/EVERY<relationship target> MATCHES <filter>, 및 ANY/EVERY <relationship target>IN<set>을 비롯하여 다양한 조건들이 사용될 수 있다. 이러한 조건들은 Rule 내에서 발생할 수 있는 상이한 종류의 조합들을 보여준다. 이것은 또한 세트 내의 항목들의 카운트인 집계를 포함한다. 다음의 항들은 단순한 이진 대수 연산 Event(T) = Event(T) + Filter(T)를 사용하여 구성될 수 있으며, 여기에서 유도된 이벤트는 다른 이벤트의 이벤트 데이터에 필터를 적용하는 것에 의해 정의된다. 예를 들면, NewInterestingItem(Doc) = NewItem(Doc) + IsInteresting(Doc); Filter(T)=Filter1(T_SubType1) Union Filter2(T_SubType2); Set(T) = Set1(T) + Filter(T) (유도된 세트는 다른 세트 내의 항목들 각각에 대하여 필터를 적용하는 것에 의해 정의되고, 유도된 세트 멤버들은 필터가 참으로 평가하는 항목들임); 및 Set(T) = Set1(T) Union Set2(T)이다.

개별적인 EUP 논리 컴포넌트들은 어플리케이션 내에서 직접 평가될 수 있다. 이것이 어플리케이션 커스텀화를 위하여 (예를 들어, Outlook과 같은 어플리케이션에 대하여, 최종 사용자가 최종 사용자 논리를 통하여 어플리케이션의 거동을 커스텀화하는 것을 허용하기 위하여) 사용되는 접근방식이다. EUP의 중심 요소는 환경의 시각적 브라우징 메타포를 통하여 표면화되며, 다음과 같은 3가지 종류의 프로그램을 포함한다.

유도된 세트 : (앞에서 대수적 항으로서 기술된) 유도된 세트는 그 자체가 완전한 최종 사용자 프로그램이다. 이것이 오픈되면, 세트 정의의 논리가 실행되고, 전형적으로 그 결과가 디스플레이된다. 대수 연산 Set(T) = Set1(T) Union Set2(T)는 유도된 세트들을 위하여 지원된다.

배치(Batch) : Batch = Set(T) + Action(T). 배치는 수행하기 위한 세트 지향 태스크를 정의한다. 배치의 의미론은 세트 내의 각 항목에 대하여 액션을 실행하는 것이다. 이것은 수동으로 실행되거나 실행을 위해 스케쥴링될 수 있다.

에이전트(Agent) : Agent = Event(T) + Action(T). 에이전트는 이벤트가 발생한 때에 수행할 액션을 정의한다.

3가지 종류의 EUP 프로그램 전부는 논리 컴포넌트뿐만 아니라 파일 시스템 항목으로서도 정의된다.

또다른 대수 연산들이 포함될 수 있다. 예를 들어, 유도된 세트를 정의하기 위하여, 다양한 세트 조합 연산들(교차, 세트 차이 등)을 고려하는 것이 실용적이다.

RuleLogic 항목은 최종 사용자 논리의 단위를 정의한다. QueryFilter, 복합 동사, 복합 이벤트, 및 계산된 속성은 RuleLogic의 인스턴스이다. 논리적으로, RuleLogic 항목은 입력 항목에 대한 사용자 정의 함수의 정의를 캡쳐한다. 모든 RuleLogic 항목은 함수의 입력 항목 유형 및 출력 유형을 정의하는 RuleConstraint를 포함한다. 0개 이상의 IF-THEN 문장이 존재한다. 각각의 문장은 Condition(문장의 IF 부분에 대응) 및 Result(Then 부분에 대응)를 갖는다. Condition은 네스트된 요소들의 부울 표현식 트리이며, 그 트리의 리프들은 LeafCondition 요소이다. Result는, 각각 이름과 파라미터값들의 세트를 갖는 0개 이상의 ResultElement의 네스트 요소 컬렉션이다. QueryFilter의 경우에서, 문장의 Result는 이름이 True 또는 False이며 파라미터를 갖지 않는 단일의 ResultElement이다.

임의의 RuleLogic 정의(및 QueryFilter)의 의미론이 여기에 간단하게 기술된다. QueryFilter가 문장을 갖지 않는 경우, 출력은 NULL이다. QueryFilter가 한 문장을 갖는 경우, Condition이 참으로 평가되고 Result가 참이면, 출력은 참이다. Condition이 참으로 평가되고 Result가 거짓이면, 출력은 거짓이다. 다르게는, 출력은 NULL이다. QueryFilter가 다수의 문장을 갖는 경우, 참으로 평가된 Condition을 갖는 문장들의 Result에 대하여 집계 함수를 사용하여 출력이 계산된다. 가장 흔한 집계 함수는 문장 순서에 기초하는 것이다 (네스트된 if-then-else 또는 전환 문장 의미론을 제공함).

이제 도 10을 보면, 본 발명의 규칙 아키텍쳐에 따라 규칙을 입력 항목의 컬렉션에 첨부함으로써 적용하는 한 방법론이 도시되어 있다. "컬렉션"이라는 용어는 항목 참조들의 임의의 세트이다 (쉘 용어법에서는 세트로 칭해지고, 규칙 용어법에서는 관계들의 멀티세트로 칭해짐). 단계(1000)에서, 입력 항목 범위를 제공하는 항목 컬렉션이 수신된다. 단계(1002)에서, 규칙은 입력 항목 범위를 제공하는 항목 컬렉션에 첨부될 수 있다. 단계(1004)에서, 규칙이 인보크된다. 규칙이 인보크되면, 단계(1006)에서, 규칙은 항목 범위 내의 항목들 각각에 적용된다.

이제 도 11을 보면, 본 발명의 규칙 아키텍쳐에 따라 규칙을 결정 포인트에 첨부함으로써 적용하는 한 방법론이 도시되어 있다. 단계(1100)에서, 결정 포인트가 노출된다. 단계(1102)에서, 규칙이 결정 포인트에 첨부된다. 규칙은 그 규칙에 의한 평가를 위해 항목들을 공급하는 데에 이용되는 결정 포인트에 첨부될 수 있다.

이제 도 12를 보면, 본 발명의 규칙 아키텍쳐에 따라 규칙을 직접 인보크함으로써 규칙을 적용하는 한 방법론이 도시되어 있다. 단계(1200)에서, 처리를 위해 입력 항목이 수신된다. 단계(1202)에서, 규칙이 그에 대한 입력을 지정하는 파라미터와 함께 직접 인보크된다.

이제 도 13을 보면, 본 발명의 규칙 아키텍쳐에 따라 규칙을 적용하는 다른 방법론이 도시되어 있다. 단계(1300)에서, 처리를 위해 입력 항목 범위가 수신된다. 단계(1302)에서, 규칙은 입력 항목 범위에서 변화하는 항목들에 적용된다. 이 마지막 경우는, 능동적인 거동(종종 이벤팅 능력으로도 칭해짐)을 제공하기 위한 규칙들의 공통적인 사용을 모델링한다. 이러한 규칙의 사용에서, 입력 항목들은 "이벤트의 의해 발생"되고, 규칙 평가의 결과는 "액션"의 실행을 유발할 수 있다. 신규한 규칙 플랫폼은 이러한 능동적인 이벤팅 능력을 규칙 시스템의 최상위의 한 계층으로서 제공한다.

이제 도 14를 보면, 본 발명에 따른 규칙 충돌 해결을 위한 한 방법론이 도시되어 있다. 디폴트에 의해, 최종 사용자 논리의 거동은 개별 규칙들의 누적하는 거동(cumulative behavior)이다. 그러나, 많은 경우에서, 규칙은 "충돌하는" 상호작용들을 가질 수 있다. 단계(1400)에서, 복수의 규칙을 포함하는 사용자 정의 논리가 처리를 위해 수신된다. 몇개의 상이한 충돌 해결 정책들이 지원된다. 예를 들어, 단계(1402)에서, 규칙 충돌은 규칙들에 대한 최종 사용자의 규칙 우선순위화를 용이하게 하는 해결 컴포넌트에 의해 해결될 수 있다. 단계(1404)에서, 해결 컴포넌트의 대안적인 방법은, 그 규칙 충돌이 개발자 정의 해결 정책(예를 들어, 커스텀 집계)에 의해 해결될 수 있게 한다.

규칙 생성 프레임워크는 규칙을 생성할 때와 규칙을 사용하는 어플리케이션을 구축할 때에 사용되는 항목들 및 관계들로 구성된다. 이러한 항목들 및 관계들은 컴퓨터가 특정 이벤트에 응답하여 무엇을 행해야 하는지를 결정하기 위하여, 규칙 플랫폼의 규칙 엔진에 의해 사용된다. 최종 사용자 규칙에 기초하여 어플리케이션 거동을 커스텀화하기 위하여, 2가지 일이 발생한다. 즉, 프로그래머는 소프트웨어의 기능을 규칙-인에이블하고, 최종 사용자는 그러한 기능을 위한 규칙을 생성한다. 규칙-인에이블(rule-enabling)은 사용자가 규칙들로 조합할 수 있도록 어플리케이션 정의 유형 또는 OOTB(out-of-the-box) 유형에 연관된 EUP 컴포넌트들을 정의하는 것을 의미한다. 인에이블은 규칙이 첨부될 수 있는 결정 포인트를 생성하는 것도 의미한다. 예를 들어, 사용자가 폴더 및 문서와 같은 항목들에 대한 변화에 관한 규칙을 정의할 수 있도록, 규칙-인에이블 오퍼레이팅 시스템 특징들이 포함된다.

규칙 API는 규칙 입력을 규칙 평가 엔진에 도입하고, 최종 사용자 규칙을 유지하고, 조건, 액션, 바인딩 등을 비롯한 규칙 아키텍쳐의 다양한 부분들의 등록 및 반영에 사용된다. 규칙 API는 3가지 예외, 즉 규칙 입력, 규칙 입력 컬렉션 및 규칙 예외 유형을 제외한 규칙 유형들에 의해 정의되는 부분적인 클래스들을 완성하는 헬퍼 메소드로서 구현된다. 이것은 규칙을 위한 API가 규칙 유형에 대한 API임을 의미한다. 본 발명의 규칙 API는 다음과 같은 것들을 제공한다.

AppCustomization/Active Rule 유형을 Query 유형들로부터 분리. 분리는 Query 관련 유형과 AppCustomization 유형에 대하여 상이한 헬퍼 메소드들이 구성될 수 있게 한다. 이것은 또한 개발자 관점으로부터 볼 때 간략화이기도 하다. 자신의 어플리케이션 내에서의 어플리케이션 커스텀화를 위하여 규칙 엔진을 이용하는 데에만 관심이 있는 개발자들은 그러한 API만을 학습하면 된다.

조합된 Rule, Rules 개념. 규칙들은 제약 정보(입력 유형 및 출력 유형) 및 하나 이상의 LogicStatement로 이루어진다. 각각의 LogicStatement는 Condition 트리 및 하나 이상의 결과로 구성된다.

(미래의 확장을 위한) LogicResult 유형군. LogicResult는 결과 유형들이 상속하는 기본 유형이다. 2가지의 결과 유형, 즉 엔코딩된 메소드 호출(FunctionInfo)을 포함하는 기존의 "Action"과, (주로 QueryFilters/AutoList에서 사용되는) 부울 반환 유형이 지원된다. 다른 구현예에서, 이것은 스칼라 및 XML(eXtensible Markup Language) 결과를 커버하도록 확장될 수 있다.

EUP 항목들 간의 값 기반 연결(value-based connection). 이것은 항목들 간의 명시적인 관계/링크를 강요하기 보다는, 항목들을 연관시키는 추가의 방식이다. 규칙 API는 규칙 첨부를 엔코딩하는 것 등을 위하여 ItemId를 이용한다. 이러한 메커니즘에서는, 일종의 선언된 값 기반 관계인 Association 개념이 이용된다.

규칙 API(EUP 컴포넌트를 언급하는 다른 방식임)는 System.Storage.Rules 이름공간(namespace) 내의 유형들로 구성된다. 이것은 새로운 이벤트(RuleInput, RuleInputCollection)을 도입하기 위한 수단을 제공한다. 몇가지 예외를 갖고, 이러한 유형들은 앞에서 열거된 EUP 컴포넌트 및 프로그램이다. 이러한 유형들은 스키마화된 유형이며, 이는 그 유형들이 표준의 저장 연산 API를 이용하여 인스턴스화되고 존속되며 발견된다는 것을 의미한다. 유형은 사용자 규칙을 생성 및 유지하기 위한 수단을 제공한다 (유형은 RuleLogic으로부터 유도함). 이러한 규칙들은 활성 규칙, 어플리케이션 커스텀화를 위한 규칙, 또는 구조화된 쿼리 규칙일 수 있다.

이제 도 15를 보면, 본 발명의 규칙 아키텍쳐에 따른 항목 유형들 및 연관 관계가 도시되어 있다. 규칙 플랫폼에 의해 노출되는 공개 API의 대부분은 System.Storage.Rules 스키마 내에 선언되는 유형들로 구성된다. 규칙 스키마는 EUP 컴포넌트 항목 유형을 정의한다. 이것은, 사용자를 대신하여 규칙 논리를 인스턴스화하고, 어플리케이션이 규칙 논리가 첨부될 수 있는 결정 포인트들을 선언할 수 있게 하며, 규칙 평가의 결과들을 보유 및 전달하는 데에 사용된다.

RuleLogic. 사용자 규칙 논리를 보유하는 모든 항목들의 기본 유형. 이것은 모든 규칙들에 공통인 기본 "형상(shape)"을 포함한다.

유도 기원(derives from): (OS file system).item

유형에 추가되는 속성:

● 제약 : 이러한 규칙에 대한 LogicConstraint

● 문장 : LogicStatement의 멀티세트. 각각의 규칙은 하나 이상의 문장(조건/액션 쌍)을 포함한다. 조건이 평가되고, 참이면, 액션이 결과로서 반환된다. 멀티세트 내에서의 순서는 문장들 간에서의 우선순위를 암시한다. 문장[0]이 가장 높은 우선순위를 갖는다. 순서화된 멀티세트들도 구현될 수 있다. 문장을 갖지 않는 RuleLogic 항목은 불법적인 것으로 간주된다. 한 구현예에서, biz 논리가 존재할 때, 런타임 예외가 쓰로우(throw)될 수 있다.

● 인에이블 : 부울은 이러한 부분의 논리가 인에이블 또는 디스에이블임을 표시한다(디폴트: 참).

유형에 추가되는 메소드: 없음

QueryFilter. QueryFilter는 사용자에 의해 작성된 필터링 논리를 나타낸다. QueryFilter 내의 문장은 부울 출력 유형을 지정하는 LogicConstraint를 갖는다.

유도 기원 : RuleLogic

유형에 추가되는 속성 : 없음

유형에 추가되는 메소드 :

● QueryFilter(Type inputItemType) : 입력 항목 유형이 설정될 수 있게 하는 구성자. 부울의 결과 유형이 LogicConstraint 내에 설정될 것이다.

● QueryFilter(Type inputItemType, LogicStatement 1) : (앞에서와같이) 입력 항목 유형을 설정하는 것은 물론, 단일의 LogicStatement를 추가하는 구성자.

● Collection Evaluate(CollectionScope cv) : 주어진 입력 컬렉션에 대하여 쿼리 필터를 평가함. ItemId의 컬렉션으로서 결과를 반환함.

● Collection Evaluate(AutoList a) : 입력 컬렉션으로서 주어진 AutoList에 대하여 쿼리 필터를 평가함.

● Boolean Evaluate(Item i) : 이러한 QuertFilter 내에 보유되는 LogicStatement들에 대하여 단일 항목을 평가하고, 최종 결과를 반환함.

AutoList. AutoList는 AutoList의 윈도우즈 브라우징 메타포 개념을 나타낸다. 이것은 QueryFilter + InputScopes를 참조하며, ItemSearcher를 통해 반환된 결과들로 평가될 수 있다.

유형에 추가되는 속성 :

● InputScopes : InputScope의 멀티세트. AutoList는 평가시에 자신의 필터를 적용할 하나 이상의 입력 범위를 갖는다. 0개의 입력 범위를 갖는 AutoList는 불법이다. biz 논리가 존재하는 경우, 런타임 예외가 쓰로우될 수 있다.

● QueryFilters : 이러한 AutoList를 평가할 때에 이용될 논리 정의를 포함하는 QueryFilter 항목들의 ItemId의 멀티세트.

유형에 추가되는 메소드 :

● AutoList(Type inputItemType, InputScope inputScope) : 입력 항목 유형 및 입력 범위가 설정될 수 있게 하는 구성자. 부울의 결과 유형이 LogicConstraint 내에 설정될 것이다.

● AutoList(Type inputItemType, InputScope inputScope, QueryFilter) : 입력 항목 유형, 하나의 입력 범위를 설정하는 것은 물론, 단일 QueryFilter로의 참조를 추가하는 구성자.

● ItemSearcher GetItemSearcher() : 이러한 AutoList를 평가한 결과들에 대하여 ItemSeacher를 반환함.

● Internal String GetViewName() : 이러한 AutoList를 지원하는 생성된 뷰의 이름을 반환함. ItemSearcher 통합을 위해 이용됨.

AppRule. AppRule은 어플리케이션 커스텀화 시나리오에서 사용된다.

유도 기원 : RuleLogic

유형에 추가되는 속성 :

● DecisionPoint : 이러한 AppRule이 첨부되는 결정 포인트의 ItemId.

유형에 추가되는 메소드 :

● AppRule(LogicConstraint lc) : LogicConstraint가 설정될 수 있게 하는 구성자.

● AppRule(LogicConstraint lc, LogicStatement l) : LogicConstraint가 설정되고 단일의 LogicStatement가 추가될 수 있게 하는 구성자.

● EvaluationResults Evaluate(Item inputItem) : 주어진 입력항목에 대하여 이러한 AppRule을 평가하고, 발생된 결과를 반환함.

● EvaluationResults Evaluate(CollectionValue c) : 지정된 컬렉션 내의 항목들 각각에 대하여 이러한 AppRule을 평가하고, 발생된 결과를 반환함.

ScopedAppRule. ScopedAppRule은 규칙 논리가 적용되어야 하는 입력 범위를 추가하기 위하여 Active Rules 시나리오에서 주로 사용된다. 소정의 어플리케이션 커스텀화 시나리오가 논리를 파일 시스템 내의 위치에 연관시킬 것을 요구하는 것이 가능하다. 이러한 시나리오들은 자기 자신의 결정 포인트를 갖는 이러한 항목들을 이용할 수 있다.

유도 기원 : AppRule

유형에 추가되는 속성 :

● InputScopes : InputScope의 멀티세트(이하 참조). ScopedAppRule들은 그 논리가 적용될 하나 이상의 입력 범위를 갖는다. 0개의 입력 범위를 갖는 ScopedAppRule은 불법이다. biz 논리가 존재하는 경우, 런타임 예외가 쓰로우될 수 있다.

유형에 추가되는 메소드 :

● ScopedAppRule(LogicConstraint lc, InputScope inputScope) : LogicConstraint 및 단일 입력 범위가 설정될 수 있게 하는 구성자.

● ScopedAppRule(LogicConstraint lc, InputScope inputScope, LogicStatement l) : LogicConstraint 및 단일 입력 범위가 설정될 수 있게 하고, 단일의 LogicStatement를 추가하는 구성자.

DecisionPoint. DecisionPoint는 어플리케이션들이 언제 어디서 규칙 엔진에 입력을 제출해야 할지, 및 그들이 어떤 종류의 결과를 수신하기를 기대하는지를 기술하기 위하여 어플리케이션에 의해 생성된다. DecisionPoint는 어플리케이션들이 어플리케이션 커스텀화 시나리오를 위하여 규칙 엔진에 입력을 제출할 수 있게 해 주는 메커니즘이다.

유도 기원 : (OS file system).item

유형에 추가되는 속성 :

● ApplicationName : DecisionPoint를 생성한 어플리케이션 또는 스키마의 이름. 이것은 예를 들어 주어진 어플리케이션에 대한 모든 DecisionPoint를 보여주기 위하여 UI(사용자 인터페이스) 어플리케이션에 의해 사용될 수 있다.

● ScopeRequired : 참이면, 여기에 첨부된 임의의 RuleLogic은 반드시 Input Scope가 정의되게 해야 한다(ScopedAppRule).

● Constraint : 이러한 DecisionPoint를 위해 생성된 규칙에 대한 제약들을 기술하는 LogicConstraint(이하 참고). 이러한 제약은 어플리케이션이 이러한 DecisionPoint에 도달한 때에 그 어플리케이션에 의해 제출될 입력의 종류(OS 파일 시스템 유형 id), 및 그 어플리케이션이 기대하는 출력의 종류를 기술한다.

유형에 추가될 메소드 :

● DecisionPoint(string ApplicationName, LogicConstraint c, bool scopeRequired) : 모든 속성이 설정될 수 있게 하는 구성자.

● EvaluationResults Submit(RuleInput r) : 주어진 RuleInput을 제출하고, 그 처리에 관련된 EvaluataionResults를 검색함.

● EvaluationResults Submit(RuleInputCollection r) : 주어진 RuleInputCollection을 제출함.

EvaluationResults. 제출된 각각의 RuleInput은 단일 EvaluationResult 항목의 생성을 유발한다. 이러한 항목은 제출된 데이터에 기초하는 규칙 평가의 결과를 포함한다. 이와 같이 새롭게 생성된 항목의 itemid는 제출 어플리케이션에 반환되며, 그러면 그 어플리케이션은 어느 액션을 취할지를 결정하기 위하여 항목 데이터를 읽는다.

유도 기원 : (OS file system).item

유형에 추가되는 속성 :

● Results : 단일 규칙 결과(취해질 액션)를 각각 포함하는 EvaluationResultElement들의 멀티세트.

유형에 추가되는 메소드 : 없음

도 16A 내지 도 16H는 본 발명의 규칙 아키텍쳐에 따라 채용되는 네스트된 요소 유형(nested element type)을 도시하고 있다.

도 16A는 본 발명의 EvaluationResultElement 네스트 유형을 도시하고 있다. EvaluationResultElement는 단일 규칙 결과(취해질 ActionResult 또는 반환될 다른 종류의 Result)를 나타낸다.

유도 기원 : (OS file system).NestedType

유형에 추가되는 속성 :

● Result : 규칙으로부터 반환된 결과를 지정하는 LogicResult.

● InputItemId : 이러한 EvaluationResultElement의 발생을 유발한 입력 항목의 ItemId.

● RuleItemId : 이러한 EvaluationResultElement의 발생을 유발한 RuleLogic 항목의 ItemId.

● Statement : 이러한 EvaluationResultElement의 발생을 유발한 논리 항목 내에서 Statement를 지정하는 정수.

유형에 추가되는 메소드 :

● void Execute(ItemContext ic) : 헬퍼 메소드. Result 속성이 ActionResult를 포함하면, 내부에 지정된 메소드를 호출함. 이것은 ItemContext.Update()를 호출하지 않으며, 호출자가 그것을 호출한다. Result가 ActionResult가 아니면, 이 메소드는 RuleException을 쓰로우해야 한다.

파라미터 치환 : Result가 ActionResult를 포함하면, ActionResult 내의 Argument는 LogicStatement에 의해 지정되는 후처리된 Argument를 나타내는 ConstantValue일 것이다.

도 16B는 본 발명의 InputScope 네스트 유형 및 그 유도를 도시하고 있다. 도 15의 AutoList 또는 ScopedAppRule에 대한 InputScope를 나타낸다.

유도 기원 : (OS file system).NestedType

유형에 추가되는 속성 :

● ItemId : 입력 범위의 ItmeId

유형에 추가되는 메소드 :

● InputScope(Guid inputScope)

CollectionScope는 컬렉션인 InputScope이다.

유도 기원 : InputScope

유형에 추가되는 속성

● RelationshipSchema : 컬렉션을 정의하는 관계를 보유하는 스트링 스키마 이름

● RelationshipName : 컬렉션을 정의하는 상기 스키마 내의 관계 유형의 스트링 이름

● ShallowScope : Boolean : 참이면, 입력 범위는 한 레벨의 관계 횡단(relationship traversal)으로 제한되어야 한다. 디폴트로 거짓임.

유형에 추가되는 메소드 :

● CollectionScope(Guid inputScope, string relationshipSchema, string relationshipName)

AutoListScope는 AutoList인 InputScope이다.

유도 기원 : InputScope

유형에 추가되는 속성 : 없음

유형에 추가되는 메소드 :

● AutoListScope(Guid inputScope)

CSIDLScope는 시각적 브라우징 메타포 CSIDL인 InputScope이다. CSIDL값은 어플리케이션에 의해 빈번하게 사용되지만 임의의 주어진 시스템 상에서 동일한 이름 또는 위치를 가질 수 없는 특수한 폴더들을 식별하기 위한 고유의 시스템 의존 방식을 제공한다.

유도 기원 : InputScope

유형에 추가되는 속성 :

● CSIDL : 현재 사용자에 대하여 평가되며 입력 범위로서 사용되는 CSIDL의 값.

도 16C는 본 발명의 LogicConstraint 네스트 유형을 도시하고 있다. LogicConstraint는 RuleLogic(및 자식)과 DecisionPoint 둘다에 의해 사용된다. DecisionPoint에 의해 사용되는 경우, LogicConstraint는 평가를 위해 제출될 입력 항목 유형과, 선언 어플리케이션에 의해 기대되는 출력 유형을 지정한다. RuleLogic에서 사용되는 경우, 제약은 규칙이 어느 입력 유형에 대하여 평가될 수 있는지, 및 규칙이 어떤 종류의 출력을 생성할지를 선언한다.

유도 기원 : (OS file system).NestedType

유형에 추가되는 속성 :

● InputItemTypeId : 입력 항목 유형을 지정하는 OS 파일 시스템 TypeId

● Output : 출력 유형을 지정하는 OutputType enum(이하 참조)으로부터의 값

유형에 추가되는 메소드 :

● LogicConstraint(Type inputItemType, OutputType ot) : typeOf(Item) 및 OutputType(이하 참조)을 취하고, InputItemTypeId 내에 저장하기 위한 적합한 OS 파일 시스템 TypeId를 찾는다.

OutputType(enum)은 Logic/DecisionPoint에 대하여 어떤 유형이 출력되는지(또는 출력 유형에 대한 제약)를 기술한다. LogicConstraint 내에서 사용된다.

값 :

● Boolean

● FunctionInfo

도 16D는 본 발명의 LogicStatement 네스트 유형을 도시하고 있다. LogicStatement는 조건 트리 및 결과(액션 또는 부울)들의 세트를 엔코딩한다.

유도 기원 : (OS file system).NestedType

유형에 추가되는 속성 :

● Condition : 이러한 논리 문장의 조건 트리

● LogicResults : LogicResults 요소들의 멀티세트. 조건이 참으로 평가되면, 결과들을 엔코딩함.

유형에 추가되는 메소드 :

● LogicStatement(Condition c, LogicResult 1) : 조건 트리 및 단일 결과를 설정하는 구성자

도 16E는 본 발명의 LogicResult 네스트 유형 및 그 유도를 도시하고 있다. LogicResult는 모든 결과 유형들을 위한 기본 클래스이다. 이것은 스스로는 결코 사용되지 않고, 그 대신에 LogicResult 항목으로부터의 결과들을 엔코딩하기 위하여 그 자식들이 사용된다.

유도 기원 : (OS file system).NestedType

유형에 추가되는 속성 : 없음

유형에 추가되는 메소드 : 없음

BooleanResult : 하나의 규칙 논리가 부울값을 반환하는 것을 허용함. 주로 QueryFilter/AutoList에 의해 사용된다.

유도 기원 : LogicResult

유형에 추가되는 속성 :

● Result : 결과를 포함하는 부울. 디폴트는 참임.

유형에 추가되는 메소드 :

● BooleanResult(bool result)

ActionResult. 액션은 활성 또는 어플리케이션 커스텀화 규칙의 결과이다.

유도 기원 : LogicResult

유형에 추가되는 속성 :

● FunctionInfo : 호출을 위해 메소드를 엔코딩하는 FunctionInfo.

● Arguments : FunctionInfo를 위해 순위화된 인수들을 포함하는 멀티세트

● Result : 스칼라 결과는 스트링, 및 실제 스칼라 값을 기술하기 위한 enum(예를 들어, int, date, string 등)임

유형에 추가되는 메소드

● Action(LogicResult lr, params object[] arguments) : 논리 결과, 그리고 선택적으로 임의의 인수들을 필요한 것으로 설정하는 구성자

● ScalarResult(String result, enum ScalarType)

ScalarResult.

유형에 추가되는 속성 :

● Result : 스칼라 결과는 스트링, 및 실제 스칼라 값을 기술하기 위한 enum(예를 들어, int, date, string 등)임

유형에 추가되는 메소드 :

● ScalarResult(String result, enum ScalarType)

도 16F는 본 발명의 Condition 네스트 유형 및 그 유도를 도시하고 있다. Condition은 규칙의 조건들을 엔코딩하기 위해 사용되는 기본 유형이다. 이것이 직접 인스턴스화되는 것이 아니라, 그 자식 유형들이 주어진 규칙 인스턴스의 일부로서 사용된다. Condition은 자기 자신의 속성을 포함하지 않는다.

유도 기원 : (OS file system).NestedType

유형에 추가되는 속성 : 없음

유형에 추가되는 메소드 :

● Public Static Condition Operator & (Condition left, Condition right) : 좌측 및 우측 params를 갖는 새로운 AndCondition을 생성하기 위해 "&"를 오버로드함

● Public Static Condition Operator ｜(Condition left, Condition right) : "｜" 연산자를 오버로드함

● Public Static Condition Operator !(Condition c) : Condition c를 갖는 NotCondition을 반환함

ConditionTree는 Condition으로부터 유도되고, 일련의 조건들을 엔코딩한다. ConditionTree는 결코 직접 사용되지 않으며, 그 대신에 그 자식들인 AndCondition 및 OrCondition이 사용된다.

유도 기원 : Condition

유형에 추가되는 속성 :

● Children : Condition들의 멀티세트. 이것은 단일 조건들 또는 다른 트리들일 수 있다.

유형에 추가되는 메소드 :

● 없음

AndCondition은 ConditionTree로부터 유도된다. AndCondition 트리가 규칙에 추가될 때, 이것은 컴포넌트 조건들이 평가되어야 하며, 규칙 평가의 성공을 결정할 때 그 결과들이 논리적으로 AND 연산되어야 함을 의미한다.

유도 기원 : ConditionTree

유형에 추가되는 속성 : 없음

유형에 추가되는 메소드 :

● AndCondition(params Condition[] operands) : 구성 시에 컴포넌트 조건들이 지정될 수 있게 하는 구성자

OrCondition도 ConditionTree로부터 유도된다. OrCondition 트리가 규칙에 추가되면, 이것은 컴포넌트 조건들이 평가되어야 하며, 규칙 평가의 성공을 결정할 때 그 결과들이 논리적으로 OR 연산되어야 함을 의미한다.

유도 기원 : ConditionTree

유형에 추가되는 속성 : 없음

유형에 추가되는 메소드 :

● OrCondition(params Condition[] operands) : 구성 시에 컴포넌트 조건들이 지정될 수 있게 하는 구성자

NotCondition은 Condition으로부터 유도된다. NotCondition이 규칙에 추가되면, 구성 조건이 평가되고, 결과의 부정(negation)이 사용된다.

유도 기원 : Condition

유형에 추가되는 속성 :

● Condition : 단일 Condition(또는 ConditionTree와 같은 임의의 유도된 유형)

유형에 추가되는 메소드 :

● NotCondition(Condition condition) : 구성 시에 컴포넌트 조건들이 지정될 수 있게 하는 구성자

LeafCondition은 실제 조건을 표현하는 데에 사용된다. 이것은 사용할 조건 함수의 이름은 물론, 그 명명된 조건 함수에서 사용할 인수들의 멀티세트를 기술한다.

유도 기원 : Condition

유형에 추가되는 속성 :

● Name : 평가 동안에 사용할 조건 함수의 이름. 현재, 이것은 빌트인(built in) 세트 지향 조건 또는 트리거 항목 유형 상의 임의의 메소드의 지원되는 SQL 비교자들 중의 임의의 것을 명명할 수 있다.

지원되는 SQL 빌트인(및 텍스트적인 등가물)은 "=", "Equals", ">", "GreaterThan", "<", "LessThan", ">=", "GreaterThanEqualTo", "<=", "LessThanEqualTo", "<>", "NotEqual", "Like"이다.

지원되는 세트 지향 조건 :

○ ANY_IN : RelationshipValue 및 CollectionValue와 함께 사용됨. 명명된 컬렉션 내에 정의된 관계들 중 임의의 관계가 RelationshipValue 내에 지정된 유형을 갖는지를 결정함.

○ ALL_IN : RelationshipValue 및 CollectionValue와 함께 사용됨. 명명된 컬렉션 내에 정의된 모든 관계들이 RelationshipValue 내에 지정된 유형을 갖는지를 결정함.

● Arguments : 명명된 조건 함수에 대한 인수들의 멀티세트. 한 구현예에서, MultiSet가 순서화되지 않으므로, LeafCondition1 및 LeafCondition2 속성이 사용된다.

유형에 추가되는 메소드 :

● LeafCondition(string name, params object[] arguments) : 구성 시에 조건 함수 이름 및 인수가 설정될 수 있게 하는 구성자

OPathCondition은 OPath의 복잡한 개발자 정의 블랍(blob)을 표현한다. OPath 표현식은 사용될 부울 반환값을 반드시 평가해야 한다. 예를 들면, ("Count(OutDocumentAuthorRelationships)>1")이다.

유도 기원 : LeafCondition

유형에 추가되는 속성 :

● OPath : OPath 표현식을 포함하는 스트링

● DisplayName : 쿼리 구축자 또는 다른 UI 내에 디스플레이되는 OPath의 이러한 블랍을 위한 스트링 이름

유형에 추가되는 메소드 :

● OPathCondition(string exp) : OPath 표현식을 설정하는 구성자

도 16G는 본 발명에 따른 ArgumentValue 네스트 유형 및 그 유도를 도시하고 있다. ArgumentValue는 조건 및 액션 둘다를 위한 인수들을 엔코딩하는 데에 사용되는 기본 유형이다. 이것이 직접 인스턴스화되지는 않고, 그 대신에 그 자식들(ConstantValue, PropertyValue, RelationshipValue, CollectionValue 등)이 이용된다.

유도 기원 : OS 파일 시스템.NestedType

유형에 추가되는 속성 : 없음

ConstantValue는 ArgumentValue로부터 유도되며, 규칙의 조건 및 액션을 위한 인수들 내의 상수값을 표현하는 데에 사용된다.

유도 기원 : ArgumentValue

유형 내에 포함되는 속성 :

● Value : 이러한 인수에 의해 표현될 단일 스트링을 포함함.

유형에 추가되는 메소드 :

● ConstantValue(string value) : 값이 구성 시에 직접 설정될 수 있게 하는 구성자

PropertyValue는 ArgumentValue로부터 유도되며, OS 파일 시스템 유형의 속성인 조건 및 액션에 대한 인수들을 표현하는 데에 사용된다. 다른 구현예에서는, 규칙 아키텍쳐 내에서 항목 유형을 트리거하는 것과의 일관성을 위하여, 스트링 스키마 및 유형 이름보다는, 유형 GUID가 사용될 수 있음에 유의해야 한다.

유도 기원 : ArgumentValue

유형 내에 포함되는 속성 :

● PropertyName : 파라미터로서 사용될 인바운드 항목 상의 속성의 이름을 포함함

유형에 추가되는 메소드 :

● PropertyValue(string propertyName) : 구성 시에 속성 이름이 지정될 수 있게 하는 구성자

RelationshipValue는 ArgumentValue로부터 유도되고, 세트 지향 조건들 중 임의의 것에 대한 파라미터로서 사용될 관계의 이름을 표현하는 데에 사용된다.

유도 기원 : ArgumentValue

유형 내에 포함되는 속성 :

● RelationshipSchemaName : Relationship 유형이 발견될 수 있는 스키마의 이름을 포함함

● RelationshipName : Relationship 유형의 이름을 포함함

유형에 추가되는 메소드 :

● RelationshipValue(string relationshipSchemaName, string relationshipName) : 구성 시에 스키마 이름 및 유형 이름이 지정될 수 있게 하는 구성자

CollectionValue는 ArgumentValue로부터 유도되고, 세트 지향 조건들 중 임의의 것에 대한 파라미터로서 사용될 컬렉션의 이름을 표현하는 데에 사용됨

유도 기원 : ArgumentValue

유형 내에 포함되는 속성 :

● CollectionItemId : 컬렉션 항목의 Guid 항목 id

● RelationshipSchemaName : 이러한 컬렉션 내의 Relationship이 발견될 수 있는 스키마의 이름

● RelationshipName : 이러한 컬렉션 내에 포함된 Relationship 유형의 이름

유형에 추가되는 메소드 :

● CollectionValue(Guid itemid, string relationshipSchemaName, string relationshipName) : 구성 시에 모든 속성값이 설정될 수 있게 하는 구성자

RuleValue는 ArgumentValue로부터 유도되고, LeafCondition 내의 파라미터로서 평가되고 사용될 소정의 RuleLogic을 표현하는 데에 사용된다. RuleValue가 세트 지향 조건들 중 임의의 것에 대한 파라미터로서 사용되면, 그것은 AutoList를 포인팅할 것으로 기대된다 (그렇지 않으면 예외가 생성되어야 한다). RuleValue가 빌트인 스칼라 조건들("=", "<" 등) 중 임의의 것에 대한 파라미터로서 사용되면, 그것은 임의의 RileLogic을 포인팅할 수 있다. RuleLogic도 Boolean을 반환할 수 있다.

유도 기원 : ArgumentValue

유형 내에 포함되는 속성 :

● RuleId : 규칙 항목의 Guid 항목 id

유형에 추가되는 메소드 :

● RuleValue(Guid ruleItemId) : 구성 시에 모든 속성값이 설정될 수 있게 하는 구성자

OPathValue는 OPath 표현식을 LeafCondition의 LHS 또는 RHS로서 사용할 수 있게 한다.

유도 기원 ; ArgumentValue

유형에 추가되는 속성 :

● OPath : OPath 표현식

● DisplayName : 쿼리 구축자 또는 다른 UI에 디스플레이할 이름

유형에 추가되는 메소드 :

● OPathValue(string exp, string displayName) : 구성 시에 모든 속성값이 설정될 수 있게 하는 구성자

도 16H는 본 발명의 FunctionInfo 네스트 유형 및 그 유도를 도시하고 있다. FunctionInfo는 Action으로서 호출될 메소드들에 관한 정보를 표현하는 데에 사용되는 기본 유형이다. FunctionInfo는 결코 그 자체가 사용되지는 않으며, 그 대신에 그 자식 유형들인 InstanceFunctionInfo 및 StaticFunctionInfo가 사용된다.

유도 기원 : (OS file system).NestedType

유형에 추가되는 속성 :

● MemberName : 호출될 메소드의 이름 또는 호출되어야 할 "set_" 메소드를 갖는 속성의 이름

유형에 추가되는 메소드 :

● FunctionInfo(string memberName) : 구성 시에 멤버의 이름이 설정될 수 있게 하는 구성자

● internal virtual void Execute(ItemContext context, List<ArgumentValue> arguments) : 이 메소드는 명명된 메소드 호출을 수행하기 위하여 자식 클래스에서 오버라이드된다.

InstanceFunctionInfo는 FunctionInfo로부터 유도되고, 특정한 항목 인스턴스 상에서의 메소드 호출을 표현하는 데에 사용된다.

유도 기원 : FunctionInfo

유형에 추가되는 속성 :

● TargetItemId : 메소드가 호출되어야 할 항목의 항목 id. 규칙 생성의 일부로서 ActionResult 요소 내에 메소드 호출을 엔코딩할 때, 그 메소드 호출이 입력 항목 상에서 이루어져야 하는 경우, TargetItemId를 빈 상태로 남겨둘 것임에 유의해야 한다. 특정 항목 상에서 호출이 이루어져야 하는 경우, 그 항목의 ID는 여기에서 설정되어야 한다.

유형에 추가되는 메소드 :

● InstanceFunctionInfo(string memberName) : 구성 시에 멤버의 이름이 설정될 수 있게 하는 구성자

● InstanceFunctionInfo(string memberName, Guid targetItemId) : 구성 시에 멤버의 이름과 타겟 항목 id가 설정될 수 있게 하는 구성자

● internal void Execute(ItemContext context, List<ArgumentValue> arguments) : InstanceFunctionInfo 데이터에 의해 지정되는 메소드를 실행함. 결국 context.Update()가 호출되지 않으며, 호출자가 그것을 다루어야 한다는 점에 유의해야 한다. 이것은 메소드 호출이 메모리 내의 임의의 OS 파일 시스템 데이터에 부작용을 갖는 경우에 중요하다.

StaticFunctionInfo는 FunctionInfo로부터 유도되며, 정적인 메소드 호출을 표현하는 데에 사용된다.

유도 기원 : FunctionInfo

유형에 추가되는 속성 :

● AssemblyName : 메소드가 발견될 수 있는 어셈블리의 이름

● TypeName : 메소드가 정의될 수 있는 어셈블리 내에서의 유형의 이름

유형에 추가되는 메소드 :

● StaticFunctionInfo(string assemblyName, string typeName, string memberName) : 구성 시에 AssemblyName, TypeName, MemberName이 설정될 수 있게 하는 구성자

● Internal void Execute(ItemContext context, List<ArgumentValue> argument) : 이러한 StaticFunctionInfo에 의해 지정되는 메소드를 실행함. 결국 context.Update()가 호출되지 않으며, 호출자가 그것을 다룬다는 점에 유의해야 한다. 이것은 메소드 호출이 메모리 내의 임의의 OS 파일 시스템 데이터에 부작용을 갖는 경우에 중요하다.

수개의 비-File System 유형들은 OS 파일 시스템 규칙 API의 일부이다.

RuleInput은 입력을 정의하여 플랫폼에 제출하는 데에 사용된다. 제출된 입력들은 이벤트가 발생한 범위에 첨부된 Rule의 평가를 트리거할 것이다. 입력을 제출하기 위하여, DecisionPoint 유형 상에서 발견된 제출 메소드를 사용한다.

유형의 속성 :

● Int64 Id : 이러한 RuleInput의 id. RuleInput이 성공적으로 제출된 후, 그것은 플랫폼에 의하여 Id를 할당받을 것이다.

● Guid EventDataItemId : 이벤트가 발생한 WinFS 항목의 itemid.

유형의 메소드 : 없음

RuleInputCollection은 System.Collections.CollectionBase로부터 유도된다. 이것은 다수의 RuleInput으로부터의 동시 제출을 허용한다. 생성된 RuleSetEvaluation 항목은 배치 내의 모든 제출된 이벤트들로부터 조합된 결과를 포함한다. 비어있는 RuleInputCollection의 제출은 유효하다. 반환되는 Guid는 Guid.Empty로 설정될 것이다.

유형의 속성 : 없음

유형의 메소드 :

● RuleInput this[int index] : 어레이 인덱스 액세서를 이용하여 포함된 RuleInput에 액세스하는 것을 허용하는 인덱서

● int Add(RuleInput value) : 지정된 RuleInput을 컬렉션에 추가함. 그 RuleInput이 이미 컬렉션 내에 있는 경우, InvalidOperationException을 쓰로우함.

● bool Contains(RuleInput value) : 컬렉션이 주어진 RuleInput을 포함하는 경우에는 참을 반환하고, 그렇지 않은 경우에는 거짓을 반환함.

● int IndexOf(RuleInput value) : 컬렉션 내의 주어진 RuleInput의 인덱스를 반환함.

● void Insert(int index, RuleInput value) : 값을 지정된 인덱스로 컬렉션 내에 삽입함.

● void Remove(RuleInput value) : 컬렉션으로부터 주어진 파일 시스템 규칙 이벤트를 제거함.

RuleException. 이러한 API들 중 하나가 실패하면, 예외가 쓰로우된다. 표준적인 상황에 대하여 기술된 "정상" 예외가 적용되는 경우, 또는 시스템 예외가 바로 쓰로우되기 원해지는 것인 경우, 표준의 예외가 사용된다. 예를 들면, 다음과 같다.

OS 파일 시스템 규칙 API 인덱서(C# "this" property)는, 키가 컬렉션 내의 엔트리에 일치하지 않는 경우, ArgumentOutOfRangeException을 쓰로우한다. 인덱서는 유효 객체를 반환하거나 예외를 쓰로우하고, System.Collections.Hashtable이 행하는 것처럼 널값을 반환하지는 않을 것이다. OS 파일 시스템 규칙 또는 SQL 클라이언트에 의해 검출되는 다른 에러들은 RuleException으로서 쓰로우된다.

샘플 코드

LeafCondition 내에서의 연산자 발견. 개발자가 어느 연산자가 지원되는지를 알아낼 수 있는 한가지 방법은, 모든 유효한 연산자에 대한 enum을 갖는 것이다. 이것의 이점은, 개발자가 모든 유효 연산자를 신속하게 알아낼 수 있다는 것이다. 그리고, 철자가 잘못된 연산자의 발행도 방지될 수 있다. 다른 방법은, 예를 들어 BetweenOperator(value1, value2, value3), GreaterThanOperator(value1, value2) 등과 같이, 각각의 연산자에 대하여 고유한 클래스를 정의하는 것이다.

다른 최적화에서, QueryFilters 및 AutoList는 자신의 논리 문장 내에 부울 결과만을 가질 수 있다. API는 AppRule에 대해 사용되는 문장들과는 별도로, 특수한 BooleanStatement 유형을 생성함으로써, QueryFilter 및 AutoList 내에 부울 결과만을 가질 것을 보장할 수 있다.

이하는, 최종 사용자 쿼리 및 필터와, 그들을 실행하기 위한 API 메커니즘의 설명이다. 객체 QueryFilter 및 AutoList는 최종 사용자를 대신하여 쿼리를 구성할 때, 또는 최종 사용자가 나중에 보고 사용하고 추리할 쿼리를 구성할 때에 구축된다.

쿼리는 항목들의 범위 및 그 항목들에 적용되는 QueryFilter에 의해 정의된다. 쿼리의 결과는 항목들의 세트이며, 모든 실용적인 목적을 위하여, 최종 사용자는 쿼리와 물리적인 리스트 간에 차이는 거의 보지 못할 것이다. 그러므로, "쿼리"에 관한 사용자의 개념은 데이터의 애드혹 다이내믹 필터링(ad-hoc dynamic filtering)의 프로세스를 의미하며, 이것은 존속될 때 요구에 따라 컨텐츠가 계산되는 List인 AutoList로 된다. List와 AutoList라는 용어는 상호교환가능하게 사용된다.

최종 사용자는 2개의 시각적인 메커니즘을 사용하여 쿼리를 구성한다. 첫째는, 페이지를 오픈하여 List 또는 AutoList의 컨텐츠를 디스플레이하는 것, 항목들을 특정 속성 또는 속성들에 의해 리스트(또는 오토리스트) 내에 스택화 또는 소팅하는 것, 및 특정 스택으로 "드릴링(drilling into)"하는 것과 같은 네비게이션적 태스크 중 임의의 것을 수행함으로써, 최종 사용자가 쿼리를 신속하게 실행할 수 있게 해 주는 네비게이션 UI이다. 둘째로, 최종 사용자에게 제공된 풍부한 쿼리 UI는 리스트 뷰어 페이지 내에 통합된 쿼리 구축자 UI를 사용하여 보다 더 풍부한 쿼리 필터를 용이하게 구성할 수 있게 한다.

쿼리 구성은 일회성 프로세스(one-time process)가 아니며, 오히려 증분적이고 조합적인 프로세스이다. 예를 들어, 조합적인 스택화(compositional stacking)는, 사용자가 제목별로 문서들을 스택화한 후, 한 제목 내로 드릴링할 수 있게 해 준다. 그리고, 나머지 문서들은 날짜별로 스택화되고, 사용자는 1년으로 드릴링한다.

필터들의 조합. 사용자는 ([오늘]-30일)과 ([오늘]-60일) 사이의 modifiedDate를 갖는 문서들로서 "ModifiedLastMonth"와 같은 필터를 정의한다. 이것은 쿼리 구축자 UI 내에서 생성되어 실행되고, 가능하게는 저장될 수 있다.

AutoList들의 조합. 사용자는 키워드 "Important"를 갖는 '모든 항목' 범위 내의 모든 문서로서 "MyInportantDocuments"를 정의하고, 이것을 오토리스트로서 저장한다. 사용자는 뷰를 오픈하여 MyImportantDocuments를 네비게이트함으로써, 새로운 오토리스트에 대한 입력 범위로서 "MyImportantDocuments"에서 시작한다. 사용자는 쿼리 구축 UI를 사용하여 "MyImportantDocuments" 상에 "ModifiedLastMonth" 쿼리 필터를 사용한 후, 그 결과 오토리스트를 "ImportantDocumentsUpdatedLastMonth"로서 저장한다.

다중 문장 필터. 사용자는 'music type IS jazz'와 같은 필터를 생성하기 위하여, 쿼리 구축 UI를 사용한다. 사용자는 부가적인 필터 "OR" 'music artist IS Joni Mitchell'을 추가한다. 사용자는 부가적인 필터 "AND"'music album tile does NOT CONTAIN "original soundtrack"'를 추가한다.

시간이 흐름에 따라, 쿼리는 AutoList로서 저장되고, 검색되고, 다시 편집될 수 있다. 쿼리 내에서 이용되는 필터는 풍부한 액션 및 풍부한 이벤트를 정의하기 위하여, 최종 사용자 프로그래밍의 다른 양태들에 대하여 사용될 수 있다. 마지막으로, AutoList 및 필터들 자체도 쿼리될 수 있다 (예를 들어, MyDocuments 리스트를 삭제할 예정이니, 그 리스트를 이용하는 AutoList를 찾아주세요).

쿼리 결과들은 사용자에 의해 뷰잉된다. 프리젠테이션 정보는 2가지 범주 내에 든다.

쿼리 메타데이터. 선택된 항목에 대한 구체적인 최종 사용자 속성이 제시된다. 최종 사용자는 쿼리 결과의 일부로서 최종 사용자에게 보여진 컬럼들의 리스트에 구체적인 속성을 추가 또는 제거할 수 있다. 이러한 프리젠테이션 세부사항은 집합적으로 View Definition으로 칭해진다. 동일한 쿼리 또는 AutoList는 개념적으로 어플리케이션마다 및/또는 사용자마다 상이한 View Definition들을 가질 수 있다.

어플리케이션 메타데이터. 어플리케이션은 그 어플리케이션 내에서 사용되는 컨텍스트적인 메타데이터(예를 들어, AutoList를 뷰잉할 때의 배경 색상)를 캡쳐하기 위하여, 어플리케이션 특정 데이터를 ViewDefinition과 연관시킬 수 있다.

풍부한 네비게이션적인 UI 내에 AutoList를 프리젠테이션하기 위하여, 유연하고 강력한 커서 모델(cursoring model)이 필요하다. 쿼리 또는 AutoList의 프리젠테이션 요소들은 쿼리 정의(쿼리의 컨텐츠에 관한 논리적이고 선언적인 정의)에는 영향을 주지 않는다.

이하는 최종 사용자 시나리오이다. 첫번째 시나리오에서, 사용자가 자신이 관심있어 하는 항목들을 필터링하여 AutoList로서 저장한 후에 그 세트로 되돌아갈 때, 저장 및 재사용 기능성이 제공된다. 로컬 뷰 존속은, 사용자가 AutoList가 저장되었던 때와 동일한 뷰가 제공되는 저장된 AutoList로 되돌아갈 수 있게 한다. 어플리케이션들 간의 쿼리 존속을 위한 공통 플랫폼이 제공되고, 그에 의하여, 한 어플리케이션 내에서 정의된 "내가 만나고 있는 사람들" AutoList를 보기로 선택한 제2 사용자는, 그러한 쿼리를 브라우징하여 모임에 나올 사람들을 볼 수 있게 된다. 일반적으로, 사용자는 많은 상이한 어플리케이션들에 의해 생성된 AutoList들을 보고 브라우징할 수 있다.

두번째 시나리오에서, 제2 사용자가 모임에 나올 클라이언트들에 대한 모든 레포트를 볼 수 있도록, 쿼리 조합이 제공된다. 제2 사용자는 "내가 만나고 있는 사람들" AutoList 내의 사람들에 의해 작성된 모든 문서들을 보기 위한 쿼리를 생성한다. AutoList들을 배포하기 위하여, 제2 사용자는 (자신의 머신 상의 항목 데이터에 기초하여) 중요한 클라이언트 레포트를 찾기 위한 AutoList를 생성하고, 자신의 팀이 그 AutoList를 사용하기를 원한다. 제2 사용자는 그 AutoList를 자신의 팀에 배포하여, 모든 사람들이 AutoList로서 저장하여 각자가 소유하는 머신 상에서 각각의 개별 머신 상의 데이터에 대하여 실행하게 한다. 뷰 정의를 배포하기 위하여, 제3 사용자가 제2 사용자로부터의 저장된 AutoList를 오픈할 때, 그 제3 사용자는 제2 사용자가 생성했던 필터 아이콘, 소팅 순서 및 그룹핑을 갖는 동일한 칼럼들을 얻게 된다.

세번째 시나리오에서, 로컬 쿼리가 공유될 수 있다. 제3 사용자는, 제2 사용자가 보게 하고 싶은 항목들의 세트를 갖는다. 제3 사용자는 이러한 항목들의 세트에 대하여 (자신의 머신 상에 있는) 저장된 AutoList로의 액세스를 공유한다. 제2 사용자와 제3 사용자가 이러한 AutoList를 오픈할 때, 이들은 둘다 동일한 항목들의 세트를 본다 (보안 제한은 예외임). 제3 사용자가 한 어플리케이션을 포인팅하는 제2 사용자로부터의 AutoList를 획득하는 경우, 적절한 실패가 제공될 수 있다. 제3 사용자는 그 어플리케이션을 갖고 있지 않다. 따라서, AutoList는 대신 All Items로 오픈된다.

새로운 QueryFilter 및 AutoList를 구성하기 위하여, 다수의 QueryFilter 및 AutoList를 조합하는 것이 가능하다. 또한, 쿼리의 범위로서 AutoList를 사용하는 것이 가능하다.

이제 도 17을 보면, 본 발명에 따른 규칙 엔진(1700)이 도시되어 있다. 개시된 규칙 플랫폼은 입력을 수신하고 적절한 규칙을 평가하는 규칙 엔진(1700)으로 구성된다. 규칙 엔진(1700)을 인보크하기 위하여, 어플리케이션들은 규칙 API(규칙 평가 API로도 칭해짐)를 사용하여 결정 포인트 객체를 통해 데이터를 제출한다. API는 규칙 평가 엔진에 데이터를 제출하고, API를 통해 결과를 반환한다. 실행 모델은 동기적이고, 반환되는 결과는 단순히 구조화된 데이터이다. 규칙 엔진(1700)은 쿼리 프로세서를 사용하여 결과를 평가하고, 어느 규칙을 사용할지를 결정하고, 입력에 대하여 규칙을 평가한 후, 결과들을 반환한다. 파일 시스템을 위한 EUP 모델 및 추상화는, 개발자들을 위한 저장 플랫폼인 것에 더하여, 전체 플랫폼의 중요한 부분이기도 하다.

이제 도 18을 보면, 본 발명의 규칙 아키텍쳐에서의 풍부성(richness)의 차원을 나타낸 블럭도(1800)가 도시되어 있다. 제공된 능력들은 3가지 일반적인 카테고리인 Behavior, Structure 및 Control Flow에 포함된다. Behavior와 관련하여, 최종 사용자 규칙은 2가지 기본적인 종류의 커스텀화 -데이터를 정의하는 유도 규칙(저장된 쿼리) 및 거동을 정의하는 활성 규칙- 를 위해 사용된다. 유도 규칙은 데이터에 대하여 풍부한 쿼리를 정의하고, 쿼리 및 규칙을 위하여 물리적인 파일 시스템 컬렉션처럼 거동하는 가상 데이터 컬렉션("유도된 항목 세트")을 정의한다. 예를 들어, 최종 사용자는 유도된 항목 세트로서 PeopleWhoLiveInBellevue로 칭해지는 컨택트들의 그룹을 정의할 수 있다. 나중에, 사용자는 PeopleWhoLiveInBellevue에 의해 발송된 모든 메일을 찾기 위해 이메일을 쿼리할 수 있다.

활성 규칙은 잘 정의된 결정 포인트들에서 어플리케이션의 거동을 정의하기 위하여 최종 사용자에 의해 사용되며, 이 때 어플리케이션은 최종 사용자가 논리를 이용하여 어플리케이션 흐름을 증대시킬 수 있게 해 준다. 2가지 종류의 결정 포인트가 존재한다. 동기적 결정 포인트는, 어플리케이션이 결정 포인트에 도달하여 최종 사용자 규칙을 인보크하는 동기적 이벤트를 발생시키게 되는 곳이다. 규칙 평가 API는 결과들의 세트를 결정한다. 그 다음, 어플리케이션은 그 결과에 따라 동작하고, 가능하게는 자신의 거동을 변화시킨다. 비동기적 결정 포인트는, 어플리케이션이 결정 포인트에 도달하여, 비동기적 이벤트를 발생시키고, "파이어-앤드-포겟(fire-and-forget)" 방식으로 처리를 계속하게 되는 곳이다. 규칙 플랫폼은 임의의 적절한 규칙을 평가한 후, 임의의 관련된 결과가 적용되게 한다.

도 18의 구성 블럭과 관련하여, 규칙들은 항목 유형들, 및 단순 네스트 요소들인 속성, 네스트 요소들의 멀티세트인 속성, 항목들로부터의 관계들의 엔드포인트 및 항목에 대한 확장과 같은 항목 유형들의 양태들을 포함하도록, 파일 시스템 데이터 모델의 모든 양태에 대하여 작성될 수 있다. 규칙들은 관계 유형들과, 단순 네스트 요소들인 속성 및 네스트 요소들의 멀티세트인 속성들을 포함하는 그 관계 유형들의 양태에 대해서도 작성될 수 있다. 확장과 관련하여, 이들은 항목 유형과 근본적으로 동일하게 거동한다.

Available Function 블럭과 관련하여, 규칙 내의 조건 및 액션은 함수 호출과 유사하다. 가장 흔한 함수는 "=" 등과 같은 빌트인 연산자이다. 임의의 T-SQL(Transact-Structured Query Language) 호출가능 함수는 조건에서 지원되며, 임의의 클라이언트 호출가능 함수는 액션에서 지원된다. 지원되는 함수들은, 프리미티브 데이터 유형 상의 SQL 연산자, 빌트인 SQL 함수, 정량화(quantification) ANY_IN 및 ALL_IN을 위한 세트 연산자, (UDF로서 등록된 경우) 조건들에 대하여 저장소측 어셈블리 내에 정의된 CLR 메소드, 액션들에 대하여 클라이언트 어셈블리 내에 정의된 CLR 메소드이다.

Composition 블럭과 관련하여, 파일 시스템 스키마 내에 정의된 "요소들" 이외에, 파일 시스템 규칙 대수가 조합을 지원한다. RuleSetAttachment는 조건 내에서 사용되거나 다른 첨부의 범위로서 사용될 수 있다는 점에서, 제1 클래스 객체이다.

조합의 다른 형태는 강하게 유형화된(strongly-typed) Derived Rule들을 함수로서 사용하는 것을 포함한다. 예를 들어, Document 항목 상에 적용되는 하나 이상의 호출된 "IsInteresting"을 정의하는 것을 고려해보자. 그러면, 조건 함수로서 "IsInteresting"을 사용하는 규칙이 생성될 수 있다.

Control Flow 블럭과 관련하여, 충돌 해결 정책을 사용하여, 제어 흐름이 최종 사용자에게 제공된다. 이것은 복잡한 코드 단편들이므로, 어플리케이션 개발자가 이들을 구성한다. 최종 사용자는 이용가능한 정책들 중에서 선택을 행할 뿐이다.

추가의 제어 흐름이 규칙 플랫폼의 외부에서 절차적으로 이루어질 수 있다. 파일 시스템 규칙 아키텍쳐는 규칙 API에서 사용될 수 있으므로, 개발자는 표준의 C# 제어 흐름 구성을 이용할 수 있다.

규칙의 풍부성

이제 도 19를 보면, 본 발명의 규칙 아키텍쳐의 입력을 나타내는 도면(1900)이 도시되어 있다. 조건 및 액션이 입력으로서 작용하는 데이터가 참조된다. 입력의 풍부성은 2차원을 따른다. 하나는 입력의 위치(예를 들어, 저장소 내에 있음 또는 저장소 내에 없음)이고, 다른 하나는 입력의 카디널리티(cardinality)[예를 들어, 싱글톤(singleton) 또는 입력들의 세트]이다. 표준적인 시나리오는 아래의 테이블에 나타나 있는 것과 같은 조합들을 사용한다.

시나리오	입력의 위치	입력의 카디널리티
활성 규칙	저장소 내에 있음(항목 유형)	세트
어플리케이션 커스텀화	저장소 내에 있음/저장소 내에 없음 (항목, 프리미티브, XML)	싱글톤/세트
지금 적용	저장소 내에 있음(항목)	싱글톤/세트
유도된 항목 세트	저장소 내에 있음(항목)	세트
파라미터화된 항목 세트	저장소 내에 없음(프리미티브)	싱글톤

본 예에서, 입력은 저장소 내의 Message 항목이다. 파일 시스템 항목에 더하여, 규칙 엔진에 대한 입력으로서, XML 문서뿐만 아니라 Relationship을 제출하기 위한 지원이 제공된다. 규칙 자체가 스칼라값에 의해 파라미터화될 수 있고, 이 때 인수들이 규칙 평가 이전에 제공될 것이 요구된다. 이들은 규칙 파라미터로 칭해진다.

조건들 및 액션들 각각은 오퍼랜드를 갖는다. 아래의 예를 참조하기 바란다.

조건 함수에 의존하여, 각각의 오퍼랜드는 스칼라 표현식이거나 세트이다.

스칼라 표현식은 스칼라 유형의 값을 갖는 표현식이다. 지원되는 스칼라 표현식은, 상수(예를 들어, 1, "Hello"); 멀티세트가 아닌 관계 유형 또는 항목 유형의 속성들을 포함하는 입력의 속성(예를 들어, [Document].Title, 그리고 속성이 네스트된 속성들을 가지면, 그 속성들도 당연히 지원됨); 및 세트에 대한 집계 함수이다. (상술한) 규칙 파라미터도 사용될 수 있다.

세트 기반 집계 함수는 항목세트, 관계, 및 네스트된 요소들의 멀티세트(예를 들어, Count, MIN, MAX, SUM 및 AVG)에 연관된다. Count는 그 인수 세트 내의 멤버들의 개수의 카운트를 제공하는 집계 함수이다.

OPath와 동일한 집계 함수들의 세트가 지원되며, 이것은 전체 파일 시스템 플랫폼에 걸쳐서 동일한 레벨의 표현가능성을 갖는다.

개발자 정의된 집계 함수들이 모델 내에서 지원된다. 확장가능성도 구현될 수 있다.

ANY_IN과 같은 일부 연산자들은 오퍼랜드로서 세트를 갖는다. 세트는 표준 컬렉션 또는 유도된 항목 세트로서 구성될 수 있다. 표준 파일 시스템 컬렉션은 관계, 및 그 관계에 대한 소스 항목(예를 들어, GroupMembership 및 MyFriend)을 포함한다. 중요한 특별 케이스로서, 입력 항목은 관계 소스(예를 들어, Message.Recipient) 또는 관계 타겟(예를 들어, Message.AttachmentOf)이다. 입력 항목 내의 네스트된 요소들의 멀티세트로서, 및 입력 항목 상의 확장의 세트로서이다.

유도된 항목세트는 유도 규칙 또는 규칙들을 입력 항목 범위에 연관시킴으로써 정의된다. 이러한 연관은 RuleSetAttachment에 의해 캡쳐된다. 예를 들어, 유도 규칙 FriendlyPerson은, 유도된 항목 세트 MyFriends를 정의하기 위한 입력 항목 범위로서 MyContacts에 첨부된다. 유도된 항목세트는 입력 범위에 완전히 바인딩될 수도 있고, 부분적으로 바인딩될 수도 있다. 완전하게 바인딩된 유도된 항목세트의 컨텐츠는 열거될 수 있다. 부분적으로 바인딩된 항목세트가 평가되기 위해서는, 일부 또는 모든 입력들이 제공되어야 한다. 또한, 모든 유도 규칙은 부분적으로 바인딩된 유도된 항목세트이다. 이것이 평가되기 위해서는 입력 항목 범위가 필요하다. 예를 들어, FriendlyPerson은 부분적으로 바인딩된 항목세트이다. 이러한 유도는 입력 항목에 대해 실행될 필터링 함수로서, 조건들 내에서 참조될 수 있다. 규칙들의 입력을 부분적으로만 정의하는 RuleSetAttachment는 부분적으로 바인딩된 항목세트를 정의한다. 예를 들어, People_By_Location은 Contact 입력 항목과 위치 둘다를 입력으로서 요구한다. 이것이 MyFriends에 그 입력 범위로서 첨부되는 경우, 그것은 부분적으로 바인딩된 유도된 항목세트 Friends_IN으로 된다 (바인딩은 MyFriends 입력 범위와 People_By_Location 유도 항목세트 간의 RuleSetAttachment에 의해 표현된다). 지금 부분적으로 바인딩된 유도된 항목세트 Friend_IN을 평가하기 위하여, 위치가 제공된다.

조건의 풍부성은 조건에 대한 입력, 및 조건 내에서 사용될 수 있는 함수에 의해 정의된다. 조건에 대한 입력은 앞에서 정의되었다. 조건 내에서 허용되는 함수는, 스칼라 표현식 인수를 갖는 표준 비교 조건(비교 조건은 비교 연산자 - =, <>, >,<, <=, >= BETWEEN 및 IN과, LIKE 및 CONTAINS를 지원하는 스트링을 포함함); sqlBoolean을 반환하는 경우에, 입력 유형에 연관된 저장소측 멤버 함수(store side member function); sqlBoolean을 반환하는 경우에, 입력 항목을 파라미터로서 취하는 저장소측 정적 함수(store side static function); 및 세트 기반 조건을 포함한다.

아래의 세트 기반 조건들은 앞에 설명된 ItemSet의 유연한 정의를 위하여 지원된다. 관련 항목세트들의 중요한 카테고리는 입력 항목을 소스로 하거나 타겟으로 하는 관계들에 의해 정의되는 것들이다. 부분적으로 바인딩된 유도된 항목세트는 별도로 고려된다.

In <TargetItemSet>.E.g.<input_item> IN MyDocuments

<ItemSet> ANY_IN <TargetItemSet>. Itemset 내의 임의의 항목이 TargetItemSet 내에도 있으면, 이것은 참을 반환한다. 예를 들어, Recipient ANY_IN MyFriends.

IN 선택 절이 존재하지 않는 경우에, Itemset 내에 적어도 하나의 항목이 존재하면, 이것은 참을 반환한다. 이 조건은 EXIST(<ItemSet>)와 같이 짧은 형태로 표현된다.

<ItemSet> ALL_IN <TargetItemSet>. Itemset 내의 모든 항목이 TargetItemSet 내에도 있으면, 이것은 참을 반환한다. 예를 들어, Recipient ALL_IN MyFriends.

3가지의 세트 기반 조건은 2가지 다른 방식으로 지원된다. 부분적으로 바인딩된 타겟 항목 세트(TargetItemSet는 완전하게 바인딩되지 않음; 완전한 입력 바인딩을 제공하는 것은 이 조건 내의 항목세트의 이용임). 이러한 클래스의 조건들은 입력에 관련된 항목세트 내의 항목들의 속성에 대하여 풍부한 조건을 표현하는 데에 사용될 수 있다. 예를 들면, ISANY Recipient A FriendlyPerson이 있다. 이러한 클래스의 조건들은 파일 시스템 내의 다른 항목세트들에 대하여 풍부한 "조인" 조건들을 표현하는 데에도 사용될 수 있다. 예를 들어, ISANY Recipient IN Freinds_In('Bellevue') 및 EXISTS(Email_By_Subject(Message.Subject)).

두번째 방식인 가상 타겟 관계 세트와 관련하여, 입력이 (항목이 아니라) 관계인 경우, 세트 기반 조건은 관계들에 대하여 동작하는 규칙에 의해 정의된 세트에서도 여전히 사용될 수 있다. Message.Recipient 관계를 입력으로 취하고 이메일 어드레스가 Compant 도메인으로부터 온 것인지를 결정하는 CompanyAccount, 예를 들어 ISANY RecipientRel A CompanyAccount를 고려해보자.

허용되는 결과들의 리스트는 RuleConstraint로부터 알려진다. 이들 각각은 이름 및 공지된 유형의 인수 리스트를 갖는다. 최종 사용자는 각 규칙에 대한 결과들의 세트를 선택한다. 각각의 결과는 이름 및 인수 바인딩에 의해 지정된다. 인수는 임의의 스칼라 표현식에 바인딩될 수 있다. 또한, 최종 사용자는 다음과 같이 데이터 구동 결과들의 세트를 정의할 수 있다.

FOREACH 구성 내부의 Result는 이 규칙에 대해 허용된 종류의 결과들 중 임의의 것일 수 있다. 이러한 결과들에 제공되는 스칼라 인수는 FOREACH절에 의해 지정되는 항목의 속성들, 및 규칙 입력의 속성들을 포함할 수 있다.

규칙은 사용자가 원하는 논리 함수를 집합적으로 정의한다. 이하는, 규칙들이 어떻게 평가되는지, 및 충돌 해결이 제어 흐름 구성에 대한 대안을 최종 사용자에게 어떻게 제공하는지에 관한 설명이다.

규칙 실행은, 특정 입력 항목에 대해서는 모든 규칙의 조건들을 평가하고, 조건이 참인 규칙들에 대해서는 결과들 간의 충돌을 해결한다고 하는 논리적 시맨틱을 이용한다. 입력들의 세트가 존재하는 경우, 평가의 결과는 단순히 그 입력 범위 내의 개별 항목/관계 각각에 대한 규칙 평가의 결과들의 합집합이다. 규칙에 대하여 복수의 항목이 제출될 때는, 특별한 시맨틱이 존재하지 않는다. 논리적으로, 각각의 항목은 독립적으로 평가된다. 상이한 입력들로부터 발생한 결과들은 서로 결코 충돌하지 않는다.

충돌 해결 정책은 규칙의 표현력에 풍부함을 제공한다. 상이한 충돌 정책들이 지원된다. 최종 사용자 정의 정책은 최종 사용자가 처리 중지 옵션(stop-processing option)을 이용하여 용이하게 우선순위를 할당할 수 있게 한다. 최종 사용자는 모든 규칙에 고유의 우선순위를 할당한다. 처리 중지 플래그가 설정되는 경우, 이것은 그 규칙의 조건이 참으로 평가되면, 그보다 낮은 우선순위를 갖는 모든 규칙이 무시되어야 함을 의미한다. 개발자 정의 정책은 결과간(inter-result) 우선순위 할당의 능력을 포함하며, 여기에서 개발자는 모든 결과 유형에 대해 고유의 우선순위를 지정할 수 있다. 잠재적인 결과들 간에서, 가장 높은 우선순위를 갖는 결과만이 보유된다. 또한, 개발자 정의 정책은, 결과내의 집계 기반 충돌 해결(intra-result aggregation-based conflict resolution)을 용이하게 하며, 여기에서 개발자는 동일한 결과 유형을 갖는 결과들의 세트에 적용되는 집계 함수를 지정하여, 그들을 집계할 수 있다.

충돌 해결을 사용할 때, 다음과 같은 규칙 거동들이 지원된다. 규칙 문장들은 처리 중지 옵션과 함께, 각각의 규칙에 고유의 최종 사용자 우선순위를 할당함으로써, 네스트 IF-THEN ELSE (IF THEN ELSE(...)) 표현식처럼 거동할 수 있다; 규칙 문장들은 처리 중지 옵션없이 규칙 우선순위를 사용함으로써, 케이스 문장들에 걸쳐서 실패(fall-through)를 갖는 C++ 스위치 문장처럼 거동할 수 있다; 규칙 문장들은 적절한 결과내 충돌 해결 정책을 이용하여 중복없는 합집합 및 교차 의미론을 제공할 수 있다. 규칙 문장들은 올바른 결과내 충돌 해결 정책에 의하여 투표 기반 의미론(voting-based semantics)을 제공할 수 있다; 그리고, 규칙 문장들은 결과간 우선순위 할당에 의해, 결과 횡단 의미론(cross-result semantics)을 제공할 수 있다.

파일 시스템 비지니스 논리를 통하여, 조건 및 액션에 공급되는 값들에 제약이 추가될 수 있다.

조건들은 LeafCondition 네스트 요소 유형을 사용하여 표현될 수 있다. 함수들은 StaticFunctionInfo 및 InstanceFunctionInfo를 사용하여 표현될 수 있다. 인수는 ConstantValue, PropertyValue, CollectionValue, RuleSetAttachmentValue 중 하나일 수 있다.

결과들은 Action 네스트 요소 유형을 사용하여 표현될 수 있다. Action 요소 내의 함수 및 인수는 상기에서 조건에 관하여 설명된 것과 동일하다. 한 구현예에서, 멀티세트가 저장소 내에서 지원된다. 다른 구현예에서, LeafCondition 및 Action은 최대 5개의 인수를 지원한다.

이제 도 20을 보면, 개시된 아키텍쳐를 실행하도록 동작할 수 있는 컴퓨터의 블럭도가 도시되어 있다. 본 발명의 다양한 양태를 위한 추가의 문맥을 제공하기 위하여, 도 20과 이하의 논의는 본 발명의 다양한 양태들이 구현될 수 있는 적합한 컴퓨팅 환경(2000)의 간단하고 개괄적인 설명을 제공하도록 의도된 것이다. 본 발명이 하나 이상의 컴퓨터 상에서 실행될 수 있는 컴퓨터 실행가능 명령어들의 일반적인 문맥으로 설명되어 있지만, 본 기술분야의 숙련된 기술자라면, 본 발명이 다른 프로그램 모듈들과 조합하여, 및/또는 하드웨어와 소프트웨어의 조합으로서 구현될 수 있음을 알 것이다.

일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정 추상 데이터 유형을 구현하는 루틴, 프로그램, 컴포넌트, 데이터 구조 등을 포함한다. 또한, 본 기술 분야의 숙련된 기술자라면, 본 발명의 방법들이 단일 프로세서 또는 멀티프로세서 컴퓨터 시스템, 미니컴포터, 메인프레임 컴퓨터는 물론, 퍼스널 컴퓨터, 핸드핼드형 컴퓨팅 디바이스, 마이크로프로세서 기반 또는 프로그래밍가능한 소비자 가전기기 등을 포함하는 다른 컴퓨터 시스템 구성들에서도 사용될 수 있으며, 이들 각각은 하나 이상의 관련 디바이스에 동작적으로 연결될 수 있다.

설명되어 있는 본 발명의 양태들은, 통신 링크를 통해 링크된 원격 프로세싱 디바이스들에 의해 소정의 태스크들이 수행되는 분산 컴퓨팅 환경에서도 구현될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 로컬 및 원격 메모리 저장 디바이스 둘다에 위치될 수 있다.

컴퓨터는 전형적으로 다양한 컴퓨터 판독가능 매체를 포함한다. 컴퓨터 판독가능 매체는 컴퓨터에 의해 액세스될 수 있는 임의의 이용가능한 매체를 포함할 수 있으며, 휘발성 및 불휘발성의 분리형 및 비분리형 매체 둘다를 포함한다. 예를 들어, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있지만, 이에 제한되는 것은 아니다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터와 같은 정보의 저장을 위하여 임의의 방법 또는 기술로 구현된 휘발성 및 불휘발성의 분리형 및 비분리형 매체 둘다를 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 기타 메모리 기술, CD-ROM, 디지탈 비디오 디스크(DVD) 또는 기타 광 디스크 저장장치, 자기 카세트, 자기 테이프, 자기 디스크 저장장치 또는 기타 자기 저장 디바이스, 또는 원하는 정보를 저장하는 데에 사용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 기타 매체를 포함하지만, 이에 한정되는 것은 아니다.

통신 매체는 전형적으로, 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 다른 데이터를 반송파 또는 기타 전송 메커니즘과 같은 변조된 데이터 내에 구현하며, 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"라는 용어는, 그 특징들 중 하나 이상의 신호 내에 정보를 인코딩하는 방식으로 설정 또는 변경된 신호를 의미한다. 예를 들어, 통신 매체는 무선 네트워크 또는 직접 배선 접속과 같은 유선 매체, 및 음향, RF, 적외선 및 기타 무선 매체와 같은 무선 매체를 포함한다. 상기 언급한 것들 중 임의의 것들의 조합도 컴퓨터 판독가능 매체의 범주 내에 포함되어야 한다.

도 20을 다시 보면, 본 발명의 다양한 양태를 구현하기 위한 컴퓨터(2002)를 포함하는 예시적인 환경(2000)이 도시되어 있으며, 컴퓨터(2002)는 프로세싱 유닛(2004), 시스템 메모리(2006) 및 시스템 버스(2008)를 포함한다. 시스템 버스(2008)는 시스템 메모리(2006) 등을 비롯한 시스템 컴포넌트들을 프로세싱 유닛(2004)에 결합시킨다. 프로세싱 유닛(2004)은 상업적으로 입수가능한 다양한 프로세서들 중 어느 것이라도 가능하다. 듀얼 마이크로프로세서 및 기타 멀티프로세서 아키텍쳐도 프로세싱 유닛(2004)으로서 이용될 수 있다.

시스템 버스(2008)는 메모리 버스(메모리 컨트롤러를 가질 수도 있고 갖지 않을 수도 있음), 주변 버스, 및 상업적으로 입수가능한 다양한 버스 아키텍쳐들 중 임의의 것을 사용하는 로컬 버스에 상호접속할 수 있는 여러 유형의 버스 구조들 중 임의의 것일 수 있다. 시스템 메모리(2006)는 판독 전용 메모리(ROM)(2010) 및 랜덤 액세스 메모리(RAM)(2012)를 포함한다. 기동 시 등에서 컴퓨터(2002)내의 요소들 간의 정보 전송을 돕는 기본 루틴을 포함하는 기본 입출력 시스템(BIOS)은 ROM, EPROM, EEPROM과 같은 비휘발성 메모리(2010) 내에 저장된다. RAM(2012)은 데이터를 캐싱하기 위하여 스태틱 RAM과 같은 고속 RAM을 포함할 수 있다.

컴퓨터(2002)는 내부 하드 디스크 드라이브(HDD, 2014)(예를 들어, EIDE, SATA), [예를 들어, 분리형 디스켓(2018)에 대한 판독 및 기입을 위한] 자기 플로피 디스크 드라이브(FDD, 2016), 및 [예를 들어, CD-ROM 디스크(2022)를 판독하거나, DVD와 같은 기타 고용량의 광 매체에 대한 판독 및 기입을 위한] 광 디스크 드라이브(2020)를 더 포함한다. 여기에서, 내부 하드 디스크 드라이브(2014)는 외부에서의 사용을 위하여 적절한 샤시(도시되지 않음) 내에 구성될 수 있다. 하드 디스크 드라이브(2014), 자기 디스크 드라이브(2016) 및 광 디스크 드라이브(2020)는 각각 하드 디스크 드라이브 인터페이스(2024), 자기 디스크 드라이브 인터페이스(2026) 및 광 드라이브 인터페이스(2028)를 통해 시스템 버스(2008)에 접속될 수 있다. 외장형 드라이브 구현을 위한 인터페이스(2024)는 유니버설 시리얼 버스(USB)와 IEEE1394 인터페이스 기술 중 적어도 하나 또는 둘다를 포함한다.

드라이브들 및 관련 컴퓨터 판독가능 매체들은 데이터, 데이터 구조, 컴퓨터 실행가능 명령어 등의 비휘발성 저장을 제공한다. 컴퓨터(2002)에 대하여, 드라이브들 및 매체들은 적합한 디지탈 포맷으로 된 임의의 데이터의 저장을 수용한다. 상기의 컴퓨터 판독가능 매체에 관한 설명은, HDD, 분리형 자기 디스켓, 및 CD 또는 DVD와 같은 분리형 광 매체를 언급하고 있지만, 본 기술 분야의 숙련된 기술자라면, 집 드라이브, 자기 카세트, 플래시 메모리 카드, 카트리지 등과 같이 컴퓨터에 의해 판독될 수 있는 다른 종류의 매체들도 예시적인 오퍼레이팅 환경에서 사용될 수 있으며, 또한 그러한 임의의 매체는 본 발명의 방법을 수행하기 위한 컴퓨터 실행가능 명령어들을 포함할 수 있다는 점을 알 것이다.

오퍼레이팅 시스템(2030), 하나 이상의 어플리케이션 프로그램(2032), 기타 프로그램 모듈(2034) 및 프로그램 데이터(2036)를 비롯한 다수의 프로그램 모듈은 드라이브 및 RAM(2012) 내에 저장될 수 있다. 오퍼레이팅 시스템, 어플리케이션, 모듈 및/또는 데이터의 전부 또는 일부는 RAM(2012) 내에 캐시될 수 있다.

본 발명은 상업적으로 이용가능한 다양한 오퍼레이팅 시스템 또는 오퍼레이팅 시스템들의 조합에서 구현될 수 있음을 알 것이다.

사용자는 예를 들어 키보드(2038)와, 마우스(204) 등의 포인팅 디바이스와 같은 하나 이상의 유무선 입력 디바이스를 통해 컴퓨터(2002)에 커맨드 및 정보를 입력할 수 있다. 다른 입력 디바이스(도시되지 않음)들은, 마이크로폰, IR 리모콘, 조이스틱, 게임패드, 스타일러스 펜, 터치스크린 등을 포함할 수 있다. 여기에 개시된 것과 그 이외의 입력 디바이스들은 주로 시스템 버스(2008)에 연결된 입력 디바이스 인터페이스(2042)를 통해 프로세싱 유닛(2004)에 접속되지만, 직렬 포트, IEEE 1394 직렬 포트, 게임 포트, USB 포트, IR 인터페이스 등과 같은 다른 인터페이스들에 의해서도 접속될 수 있다.

모니터(2044) 또는 다른 유형의 디스플레이 디바이스도 비디오 어댑터(2046)와 같은 인터페이스를 통해 시스템 버스(2008)에 접속된다. 컴퓨터는, 전형적으로 모니터(2044) 이외에 스피커, 프린터 등과 같은 다른 주변 출력 디바이스들(도시되지 않음)을 포함한다.

컴퓨터(2002)는 원격 컴퓨터(들)(2048)와 같은 하나 이상의 원격 컴퓨터들로의 유선 및/또는 무선 통신을 통한 논리적 접속을 이용하여 네트워크화된 환경에서 동작할 수 있다. 원격 컴퓨터(들)(2048)는 워크스테이션, 서버 컴퓨터, 라우터, 퍼스널 컴퓨터, 휴대용 컴퓨터, 마이크로프로세서 기반의 엔터테인먼트 장비, 피어 디바이스 또는 기타 공통 네트워크 노드일 수 있으며, 전형적으로 컴퓨터(2002)와 관련하여 설명된 구성요소들 중의 대다수 또는 전부를 포함하지만, 편의상 메모리 저장 디바이스(2050)만이 도시되어 있다. 도시된 논리적 접속은 근거리 네트워크(LAN)(2052), 및/또는 광역 네트워크(WAN)(2054) 등의 보다 큰 네트워크로의 유무선 접속을 포함한다. 이러한 LAN 및 WAN 네트워크 환경은 사무실과 회사에서 흔한 것이며, 인트라넷과 같은 기업 규모 컴퓨터 네트워크를 용이하게 하며, 이들 모두는 인터넷과 같은 글로벌 통신 네트워크에 접속될 수 있다.

LAN 네트워크 환경에서 사용될 때, 컴퓨터(2002)는 유선 및/또는 무선 통신 네트워크 인터페이스 또는 어댑터(2056)를 통해 근거리 네트워크(2052)에 접속된다. 어댑터(2056)는 LAN(2052)으로의 유선 또는 무선 통신을 용이하게 할 수 있으며, 무선 어댑터(2056)와 통신하기 위한 무선 액세스 포인트가 설치되어 있을 수 있다. WAN 네트워크 환경에서 사용될 때, 컴퓨터(2002)는 모뎀(2058)을 포함할 수 있고, 또는 LAN 상의 통신 서버에 접속되거나, 인터넷을 통하는 것과 같이 WAN(2054) 상에서의 통신을 확립하기 위한 다른 수단을 가질 수 있다. 내장형이나 외장형일 수 있고 유선 또는 무선 디바이스일 수 있는 모뎀(2058)은 직렬 포트 인터페이스(2042)를 통해 시스템 버스(2008)에 접속된다. 네트워크 환경에서, 컴퓨터(2002)와 관련하여 도시된 프로그램 모듈 또는 그 일부는 원격 메모리/저장 디바이스(2050)에 저장될 수 있다. 도시된 네트워크 접속은 예시적인 것이며, 컴퓨터들 간의 통신 링크를 확립하기 위한 다른 수단도 이용될 수 있음을 알 것이다.

컴퓨터(2002)는, 예를 들어 프린터, 스캐너, 데스크탑 및/또는 휴대용 컴퓨터, 휴대용 데이터 보조장치, 통신 위성, 무선 검출가능한 태그에 연관된 임의의 장비 또는 위치(예를 들어, 키오스크, 뉴스 스탠드, 화장실) 및 전화와 같이, 무선 통신에 동작적으로 배치된 임의의 무선 디바이스 또는 엔터티와 통신하도록 동작할 수 있다. 이것은 적어도 Wi-Fi 및 블루투스^TM 기술을 포함한다. 따라서, 통신은 통상적인 네트워크에서와 같이 미리 정의된 구조일 수도 있고, 또는 간단하게 적어도 2개의 디바이스 간에서의 애드혹 통신일 수도 있다.

Wi-Fi(Wireless Fidelity)는 가정의 소파, 호텔방의 침대 또는 직장의 회의실에서 무선으로 인터넷에 접속할 수 있게 해 준다. Wi-Fi는, 컴퓨터와 같은 디바이스들이 기지국의 범위 내에 드는 곳 어디에서든, 실내외에서 데이터를 송수신할 수 있게 해 주는 셀폰과 유사한 무선 기술이다. Wi-Fi 네트워크는 IEEE 802.11 (a, b, g 등)로 칭해지는 무선 기술을 사용하여, 안전하고 신뢰할 수 있으며 고속인 무선 접속을 제공한다. Wi-Fi 네트워크는 컴퓨터들을 서로 접속시키고, 또한 인터넷 및 (IEEE 802.3 또는 이더넷을 사용하는) 유선 네트워크에 접속시키는 데에 사용될 수 있다. Wi-Fi 네트워크는 라이센스화되지 않은 2.4 또는 5 GHz 전파 대역에서 11 Mbps (802.11a) 또는 54 Mbps (802.11b)의 데이터레이트로, 또는 양 대역을 모두 포함하는 혼합 대역(듀얼 밴드)에서 동작하므로, 이 네트워크는 많은 사무실에서 사용되는 기본 10BaseT 유선 이더넷 네트워크와 유사한 실세계 성능을 제공할 수 있다.

이제 도 21을 보면, 본 발명에 따른 예시적인 컴퓨팅 환경(2100)의 개략적인 블럭도가 도시되어 있다. 시스템(2100)은 하나 이상의 클라이언트(들)(2102)를 포함한다. 클라이언트(들)(2102)는 하드웨어 및/또는 소프트웨어일 수 있다 (예를 들어, 쓰레드, 프로세스, 컴퓨팅 디바이스). 클라이언트(들)(2102)는 본 발명을 채용함으로써 쿠키(들) 및/또는 관련 컨텍스트 정보를 포함할 수 있다. 시스템(2200)은 또한 하나 이상의 서버(들)(2104)를 포함한다. 서버(들)(2104)도 하드웨어 및/또는 소프트웨어일 수 있다 (예를 들어, 쓰레드, 프로세스, 컴퓨팅 디바이스). 서버(2104)는 예를 들어 본 발명을 채용함으로써 변형을 수행하기 위한 쓰레드를 포함할 수 있다. 클라이언트(2102)와 서버(2104) 간의 한가지 가능한 통신은 2개 이상의 컴퓨터 프로세스 간에서 전송되도록 적응된 데이터 패킷의 형태일 수 있다. 데이터 패킷은 예를 들어 쿠키 및/또는 관련 컨텍스트 정보를 포함할 수 있다. 시스템(2100)은 클라이언트(들)(2102)와 서버(들)(2104) 간의 통신을 용이하게 위해 채용될 수 있는 통신 프레임워크(2106)(예를 들어, 인터넷과 같은 글로벌 통신 네트워크)를 포함한다.

통신은 유선(광섬유 포함) 및/또는 무선 기술에 의해 용이해질 수 있다. 클라이언트(들)(2102)는 클라이언트(들)(2102)에 국부적인 정보[예를 들어, 쿠키(들) 및/또는 관련 컨텍스트 정보]를 저장하는 데에 채용될 수 있는 하나 이상의 클라이언트 데이터 저장소(들)(2108)에 동작적으로 연결된다. 마찬가지로, 서버(들)(2104)는 서버(2104)에 국부적인 정보를 저장하는 데에 채용될 수 있는 하나 이상의 서버 데이터 저장소(들)(2110)에 동작적으로 연결된다.

여기에 기술된 것은 본 발명의 예시들을 포함한다. 물론, 본 발명을 설명하기 위해 예상될 수 있는 모든 컴포넌트 및 방법의 조합을 기술하는 것은 불가능하지만, 본 기술 분야의 숙련된 기술자라면 본 발명의 많은 다른 조합 및 변형이 가능함을 알 것이다. 따라서, 본 발명은 첨부된 특허청구범위의 취지 및 범위 내에 포함되는 모든 변경, 수정 및 변형을 포괄하도록 의도된다. 또한, "포함한다"하는 용어가 상세한 설명 또는 청구범위에서 사용되는 한, 그 용어는 청구항에서 전이 단어로서 사용되는 "포함하는"과 마찬가지로 포괄적으로 해석되도록 의도된다.

Claims (41)

1. 트레이닝된 소프트웨어 개발자가 아닌 최종 사용자에 의한 데이터 관리를 용이하게 하는 규칙 생성 프레임워크가 저장된 컴퓨터 판독가능 저장 매체로서, 상기 규칙 생성 프레임워크는,

   어플리케이션으로부터 결정 포인트 객체를 수신하기 위한 제1 어플리케이션 프로그램 인터페이스 - 상기 결정 포인트 객체는 동기적 및 비동기적 결정 포인트 객체를 모두 포함하며, 각각의 결정 포인트 객체는, 결과 세트를 생성하기 위해 상기 규칙 생성 프레임워크가 실행되고 있는 컴퓨터 시스템 상의 데이터에 적용되는 하나 이상의 규칙을 포함하고, 상기 하나 이상의 규칙은 상기 어플리케이션의 기능성을 커스터마이징하기 위해 사용자에 의해 상기 어플리케이션에 제공되며, 결정 포인트 객체가 동기적인 경우, 상기 어플리케이션은, 상기 결정 포인트에 도달하여 상기 제1 애플리케이션 프로그램 인터페이스에 상기 동기적 결정 포인트 객체를 제출하면 실행 진행 전에 상기 결과 세트를 기다리고, 결정 포인트 객체가 비동기적인 경우, 상기 어플리케이션은, 상기 결정 포인트에 도달하여 상기 제1 어플리케이션 프로그램 인터페이스에 상기 비동기적 결정 포인트 객체를 제출하면 상기 결과 세트를 기다리지 않고 실행 진행함 -;

   규칙 논리 객체를 수신하기 위한 제2 어플리케이션 프로그램 인터페이스 - 각각의 규칙 논리 객체는 상기 컴퓨터 시스템 상의 데이터에 적용되는 하나 이상의 규칙을 포함하고, 각각의 규칙 논리 객체의 상기 하나 이상의 규칙은 상기 컴퓨터 시스템 상에서 실행중인 운영 시스템의 기능성을 커스터마이징함 -; 및

   상기 운영 시스템의 기능성을 커스터마이징하기 위해 사용자가 각각의 규칙 논리 객체 내에 포함되는 상기 하나 이상의 규칙을 특정하는데 이용하는 사용자 인터페이스 컴포넌트

   를 포함하는, 컴퓨터 판독가능 저장 매체.
2. 제1항에 있어서,

   상기 규칙 논리 객체 및 상기 결정 포인트 객체의 상기 하나 이상의 규칙은 상기 규칙 생성 프레임워크에 의해 사용되어 상기 컴퓨터 시스템 내의 상기 데이터의 가상 컬렉션을 정의하는, 컴퓨터 판독가능 저장 매체.
3. 제1항에 있어서,

   항목들 및 항목들의 컬렉션들을 트리거 논리의 함수로서 동적으로 활성으로 설정하는 하나 이상의 트리거 컴포넌트

   를 더 포함하는, 컴퓨터 판독가능 저장 매체.
4. 제1항에 있어서,

   규칙들 간의 충돌을 해결하는 해결 컴포넌트

   를 더 포함하는, 컴퓨터 판독가능 저장 매체.
5. 제4항에 있어서,

   상기 해결 컴포넌트는 최종 사용자 규칙 우선순위 또는 미리 정의된 해결 정책 중 적어도 하나에 의해 상기 규칙의 충돌을 해결하는, 컴퓨터 판독가능 저장 매체.
6. 트레이닝된 소프트웨어 개발자가 아닌 최종 사용자에 의한 파일 시스템 관리를 용이하게 하는 컴퓨터로 구현된 규칙 기반 시스템으로서,

   프로세서; 및

   규칙 생성 프레임워크를 저장하는 메모리를 포함하고, 상기 규칙 생성 프레임워크는,

   어플리케이션으로부터 결정 포인트 객체를 수신하기 위한 제1 어플리케이션 프로그램 인터페이스 - 상기 결정 포인트 객체는 동기적 및 비동기적 결정 포인트 객체를 모두 포함하며, 각각의 결정 포인트 객체는, 결과 세트를 생성하기 위해 상기 규칙 생성 프레임워크가 실행되고 있는 컴퓨터 시스템 상의 데이터에 적용되는 하나 이상의 규칙을 포함하고, 상기 하나 이상의 규칙은 상기 어플리케이션의 기능성을 커스터마이징하기 위해 사용자에 의해 상기 어플리케이션에 제공되며, 결정 포인트 객체가 동기적인 경우, 상기 어플리케이션은, 상기 결정 포인트에 도달하여 상기 제1 어플리케이션 프로그램 인터페이스에 상기 동기적 결정 포인트 객체를 제출하면 실행 진행 전에 상기 결과 세트를 기다리고, 결정 포인트 객체가 비동기적인 경우, 상기 어플리케이션은, 상기 결정 포인트에 도달하여 상기 제1 어플리케이션 프로그램 인터페이스에 상기 비동기적 결정 포인트 객체를 제출하면 상기 결과 세트를 기다리지 않고 실행 진행함 -;

   규칙 논리 객체를 수신하기 위한 제2 어플리케이션 프로그램 인터페이스 - 각각의 규칙 논리 객체는 상기 컴퓨터 시스템 상의 데이터에 적용되는 하나 이상의 규칙을 포함하고, 각각의 규칙 논리 객체의 상기 하나 이상의 규칙은 상기 컴퓨터 시스템 상에서 실행중인 운영 시스템의 기능성을 커스터마이징함 -; 및

   상기 운영 시스템의 기능성을 커스터마이징하기 위해 사용자가 각각의 규칙 논리 객체 내에 포함되는 상기 하나 이상의 규칙을 특정하는데 이용하는 사용자 인터페이스 컴포넌트

   를 포함하는, 컴퓨터로 구현된 규칙 기반 시스템.
7. 제6항에 있어서,

   항목들 및 항목들의 컬렉션들을 트리거 논리의 함수로서 동적으로 활성으로 설정하는 하나 이상의 트리거 컴포넌트

   를 더 포함하는, 컴퓨터로 구현된 규칙 기반 시스템.
8. 제6항에 있어서,

   최종 사용자 규칙 우선순위 및 미리 정의된 해결 정책 중 적어도 하나를 채용함으로써 복수의 규칙 간의 충돌을 해결하는 해결 컴포넌트

   를 더 포함하는, 컴퓨터로 구현된 규칙 기반 시스템
9. 삭제
10. 삭제
11. 삭제
12. 삭제
13. 삭제
14. 삭제
15. 삭제
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제
21. 삭제
22. 삭제
23. 삭제
24. 삭제
25. 삭제
26. 삭제
27. 삭제
28. 삭제
29. 삭제
30. 삭제
31. 삭제
32. 삭제
33. 삭제
34. 삭제
35. 삭제
36. 삭제
37. 삭제
38. 삭제
39. 삭제
40. 삭제
41. 삭제

Images