KR101323073B1 - 선언형 관리 프레임워크 - Google Patents

Abstract

상위 레벨 의도와 이 의도를 달성하도록 구성되어야만 하는 하위 레벨 설정 간의 인터페이스를 제공함으로써 사용자 생산성이 증진될 수 있다. 이 의도는 선언형 언어로 표현될 수 있다. 이 의도는 목표, 정책 또는 둘다에 부합하는지를 판정하기 위해 검증될 수 있다. 정책 연계(policy binding)는 목표와 정책 간의 관계를 제공할 수 있다. 사용자가 하나 이상의 데이터베이스를 갖는 서버를 볼 수 있게 해주는 애플리케이션 뷰(application view)가 제공될 수 있다.

선언형 관리, 정책 연계, 제약조건, 패싯, 대상 집합

Description

선언형 관리 프레임워크{DECLARATIVE MANAGEMENT FRAMEWORK}

시스템 관리자는 매일같이 데이터베이스 또는 많은 수의 설치된 애플리케이션을 갖는 기타 서버를 관리할 수 있다. 시스템 관리자는, 시스템 고장에 대비하여 복구가능한 형식으로 데이터를 제공하는 것과 같은, 다양한 관리 목적 또는 관리 정책을 만족시키도록 데이터베이스 또는 서버를 구성한다. 그에 부가하여, 시스템 관리자는 업데이트를 위한 정책들을 모니터링하고, 시스템의 상태 또는 건강(예를 들어, 원하는 정책에 부합하고 있는지)에 관하여 보고하며, 시스템이 더 이상 원하는 정책에 부합하지 않을 때 대응을 하고, 더불어 기타 동작들을 수행해야만 한다.

이러한 동작들을 수행하기 위해, 시스템 관리자는 정책들을 시스템을 구성하는 데 이용되는 일련의 상세한 하위 레벨 동작들로 변환한다. 이렇게 하려면 설치된 애플리케이션에 의해 노출되는 옵션들 및 배포된 애플리케이션의 상세 및 의미(semantics)에 대한 상당한 지식을 필요로 하는데, 그 이유는 시스템 관리가 일반적으로 쉽지 않고 또 직관적이지 않기 때문이다. 시스템 관리자는 별도의 모니터링 및 보고 메카니즘을 구축할 수 있으며, 자동화가 요망되는 경우, 이 자동화는 수작업으로 구축되어야만 한다. 시스템 관리자는 관리되는 모든 대상에 대해 이 프로세스를 개별적으로 반복하며, 따라서 관리에 있어서 규모 효율성이 없다. 이 결과, 각각의 관리되는 대상에 대해 소요되는 시간 및 노력이 중복된다.

다양한 설정을 인에이블, 디스에이블 또는 변경하는 것과 관련하여, 이러한 기능을 수행하는 구문이 난해하게 되고 사용자에게 친숙하지 않게 될 수 있다. 그에 부가하여, 다양한 설정들의 장소에서 일관성이 없다. 예를 들어, 어떤 설정들은 디스플레이 상에 나타나는 반면, 다른 것들은 디스플레이되지 않는다. 이들은 물론 다른 요인들은 각각의 설정을 찾아내어 변경하는 데 걸리는 시간의 양을 증가시킨다.

상기한 결점은 물론 다른 결점들을 극복하기 위해, 시스템 관리자의 의도와 그 의도를 달성하는 데 필요한 하위 레벨 설정 간의 동적 중재(dynamic mediation)가 필요하다. 또한, 디스플레이와 같은, 다양한 설정에 대한 보다 중앙집중화된 장소가 필요하다.

이하는 기술된 실시예들의 어떤 측면들에 대한 기본적인 이해를 제공하기 위해 간략화된 요약을 제시한다. 이 요약은 전반적인 개요가 아니며 이러한 실시예의 주요 구성요소 또는 필수적인 구성요소를 확인하거나 그 범위를 정하기 위한 것도 아니다. 그의 유일한 목적은, 나중에 제공되는 보다 상세한 설명에 대한 서문으로서, 기술된 실시예들의 어떤 개념들을 간략화된 형태로 제공하기 위한 것이다.

하나 이상의 실시예 및 그의 대응하는 설명에 따르면, 데이터 관리 제품에 관하여 사용자 생산성을 향상시키는 것과 관련하여 다양한 측면들이 기술되어 있다. 사용자 상호작용(예를 들어, 복잡한 명령의 대부분을 숙지하여 적용하는 것)을 경감시키기 위해 관리자의 의도와 그 의도를 달성하기 위해 수정되어야만 하는 하위 레벨 설정 간의 중재가 제공된다.

실시예들은 사용자의 의도와 그 의도를 달성하는 데 필요한 하위 레벨 설정 간의 중재를 제공함으로써 사용자를 복잡한 명령의 대부분을 숙지하여 적용하는 부담으로부터 해방시켜 줄 수 있다. 동일한 패싯(facet)이 서로 다른 방식으로 구성되는 객체들에 의해 제공될 수 있으며, 따라서 사용자는 개개의 객체를 구성하기 위해 특수화된 의미를 배울 필요가 없다. 어떤 패싯에 대해 정책이 적용될 수 있고, 사용자는 단 하나의 정책을 사용하여 이 패싯을 제공하는 다수의 객체 모두를 구성할 수 있다. 패싯은, 예를 들어, 서로 다른 대상으로부터 서로 다른 설정을 추상화할 수 있다(예를 들어, 리소스 소비 패싯은 OS 파일 시스템 및 데이터베이스 서버의 나머지 비어있는 페이지 둘다를 함께 모니터링하고 구성할 수 있다). 정책들이 "복합 관리 정책(composite management policy)"으로 통합될 수 있다.

어떤 실시예들에 따르면, 사용자는 임시적으로 선언형 관리 프레임워크(declarative management, DMF) 시스템에 주어진 대상이 주어진 정책과 부합하는지를 검사하도록 지시할 수 있다. DMF는 강제적으로 정책에 부합하도록 하기 위해 부합하지 않는 대상을 재구성하는 기능을 포함할 수 있다. 관리 패싯(management facet)의 개개의 속성들에 기초하여, DMF는, 단순하든 복합적이든 간에, "구성가능한" 정책(configurable policy) 및/또는 "시행가능한" 정책(enforceable policy)을 인식한다. 부합하지 않는 대상 집합을 구성하거나 구성하지 않고서, 일정표에 따라 정책 검사를 자동화하는 기능이 제공되어 있다. 또한, 부합하지 않는 대상 집합을 구성하거나 구성하지 않고서, 변경에 대한 정책 검사를 자동화하는 기능도 제공되어 있으며, 이는 어떤 이탈이라도 있으면 즉각적인 경고를 제공할 수 있다.

자동적인 정책 검사는 정책 평가를 모의하기 위해 하나의 동작 또는 일련의 동작들과 결합될 수 있다(예를 들어, 보안 정책이 실패하는 경우 이메일이 전송될 수 있다). 동작들이 정책 평가 성공 또는 실패와 연관될 수 있다. 가능한 경우, 패싯을 부합하지 않게 하려는 시도를 검출하여 이들을 방지하는 메카니즘들이 포함될 수 있다(예를 들어, 자동 정책 시행). 정책들은 서버 상의 단 하나의 객체로부터 기업에 이르는 계층구조에서의 어느 레벨이라도 대상으로 할 수 있다. 애플리케이션을 대상으로 하는 정책은 그 애플리케이션에 속하는 서버 상에 있는 객체들에게만 적용될 수 있다. 사용자는 정책의 대상을 많은 객체들을 포함하는 계층구조의 루트로 함으로써 그 객체들이 그 정책의 적용을 받게 할 수 있다. 단 하나의 동작으로, 사용자는 신뢰성있게 설정을 변경할 수 있거나 많은 기계들에서의 정책 시행을 검사, 구성 또는 자동화할 수 있다. 성능 또는 다른 동적으로 변하는 데이터를 샘플링 및 집계하고 이를 관리 패싯에서 이용할 수 있게 해주기 위해 수집기(collector)가 포함될 수 있다.

어떤 실시예들은 통합 보안 모델(integrated security model)을 사용하여 구현될 수 있다. 상위 레벨에서 수행되는 정책이 하위 레벨 정책을 대체할 수 있다(예를 들어, 서버 그룹 정책은 데이터베이스 정책보다 우선순위를 갖는다). 사용자들은 사용자들이 볼 권한이 있는 대상 집합 또는 정책의 그 부분만을 볼 수 있다. DMF는 사용자가 "애플리케이션"을 이루고 있는 대상 요소들을 나타낼 수 있게 해준다. DMF 애플리케이션은 다수의 서버에 걸쳐 확장될 수 있으며, 아마도 다수의 제품(예를 들어, 판매업자)에 걸쳐 확장될 수 있다. 애플리케이션들이 하나의 대상으로부터 가져오기되어 저장되고 나중에 새로운 대상들에 한 단위로 설치될 수 있다. 개시된 실시예들은 서로 다른 정책 및 정책 버전의 이력 및 이들의 관리 대상과의 연관관계를 보기 위해 이용될 수 있다. 사용자는 임의의 대상에 대한 효과적인 정책(예를 들어, 이 대상을 직접 제약하는 정책의 그 부분)을 볼 수 있다. 보관 및 배포를 위한 정책 및 연계를 스크립팅, 가져오기 및 내보내기하는 방법들도 제공된다.

실시예들은 시스템이 기업 정책과 부합하도록 구성되기 전에 사용자들에게 발표될 가능성을 감소시키기 위해 소프트웨어 설치 또는 애플리케이션 배포에 포함될 수 있다. 관리 패싯을 한 구조로서 확장가능 API에 포함시키는 것은 사용자가 그 자신의 관리 패싯을 생성하여 그의 관리 목적을 파악 및 수행할 수 있게 해준다. 관리 대상을 한 구조로서 확장가능 API에 포함시키는 것은 새로운 DMF 대상을 구현하는 사용자 또는 소프트웨어 판매업자에 의해 부가의 관리 대상이 선언형 관리를 받게 될 수 있다는 것을 의미한다. DMF는 배포에 관한 자동 구성, 자동 모니터링, 자동 부합성 보고, 및 자동 유지/조정을 비롯한 전체 관리 라이프사이클의 자동화를 가능하게 해준다. 많은 경우에, 이것에 의해 완전한 자체-관리 시스템이 얻어진다.

이상의 목적 및 관련 목적을 달성하기 위해, 하나 이상의 실시예들은 이후에 상세히 기술되고 청구항들에 특별히 지적되고 있는 특징들을 포함한다. 이하의 설명 및 첨부 도면은 어떤 예시적인 측면들을 상세히 기술하고 있으며 실시예들의 원리들이 이용될 수 있는 다양한 방식들 중 단지 몇개만 나타낸 것이다. 다른 이점들 및 새로운 특징들이 도면과 관련하여 살펴볼 때 이하의 상세한 설명으로부터 명백하게 될 것이며, 개시된 실시예들은 이러한 측면 및 그의 등가물 전부를 포함하는 것으로 보아야 한다.

도 1은 시스템 아키텍처의 상위 레벨 블록도.

도 2는 데이터베이스 서버의 관리성(manageability)을 제공하는 시스템을 나타낸 도면.

도 3은 사용자 의도를 데이터 관리 제품에 동적으로 적용하는 시스템을 나타낸 도면.

도 4는 상위 레벨 의도를 하위 레벨 설정에 자동적으로 적용하는 시스템을 나타낸 도면.

도 5는 개시된 실시예들을 이용하는 이벤트 디스패치 메카니즘(event dispatch mechanism)을 나타낸 도면.

도 6은 하나 이상의 실시예에 따른, 하나 이상의 기능들을 자동화하는 것을 용이하게 해주는 기계 학습을 이용하는 시스템을 나타낸 도면.

도 7은 사용자 생산성의 향상을 용이하게 해주는 방법을 나타낸 도면.

도 8은 데이터 관리 제품을 구성하는 방법을 나타낸 도면.

도 9는 사용자 인터페이스의 예시적인 스크린 샷을 나타낸 도면.

도 10은 정책을 적용하기 위한 예시적인 사용자 인터페이스를 나타낸 도면.

도 11은 정책 속성에 대한 예시적인 사용자 인터페이스를 나타낸 도면.

도 12는 제약조건 속성에 대한 예시적인 사용자 인터페이스를 나타낸 도면.

도 13은 제약조건 속성에 대한 사용자 인터페이스의 다른 예시적인 스크린 샷을 나타낸 도면.

도 14는 원자적 제약조건(atomic constraint) 속성에 대한 예시적인 사용자 인터페이스를 나타낸 도면.

도 15는 정책 속성에 대한 사용자 인터페이스의 예시적인 스크린 샷을 나타낸 도면.

도 16은 정책 실행 보고서를 디스플레이(또는 인쇄)하는 예시적인 사용자 인터페이스를 나타낸 도면.

도 17은 예시적인 정책 사례 관리(policy instance management) 사용자 인터페이스를 나타낸 도면.

도 18은 배포된 정책 속성에 대한 예시적인 사용자 인터페이스를 나타낸 도면.

도 19는 정책 사례를 적용하는 예시적인 사용자 인터페이스를 나타낸 도면.

도 20은 서버 속성에 대한 예시적인 사용자 인터페이스를 나타낸 도면.

도 21은 서버 속성에 대한 다른 예시적인 사용자 인터페이스를 나타낸 도면.

도 22는 예시적인 시스템 라이프사이클을 나타낸 도면.

도 23은 예시적인 시스템을 나타낸 도면.

도 24는 예시적인 관리 도구를 나타낸 도면.

도 25는 임시적으로 동작하는 데이터 서비스를 제공하는 시스템을 나타낸 도면.

도 26은 데이터 플랫폼을 나타낸 도면.

도 27은 다른 데이터 플랫폼을 나타낸 도면.

도 28은 데이터 플랫폼의 다양한 데이터 서비스를 나타낸 도면.

도 29은 데이터 플랫폼 아키텍처를 나타낸 도면.

도 30은 예시적인 어댑터 다이어그램을 나타낸 도면.

도 31은 개시된 실시예들을 실행하는 동작을 하는 컴퓨터의 블록도.

도 32는 개시된 실시예들을 실행하는 동작을 하는 예시적인 컴퓨팅 환경의 개략 블록도.

이제부터, 다양한 실시예들에 대해 도면을 참조하여 기술하며, 도면 전체에 걸쳐 유사한 참조 번호가 유사한 구성요소를 말하는 데 사용된다. 이하의 설명에서, 설명을 위해, 하나 이상의 측면들에 대한 철저한 이해를 제공하기 위해 많은 구체적인 상세가 기술된다. 그렇지만, 다양한 실시예들이 이들 구체적인 상세 없이도 실시될 수 있다는 것이 명백할지도 모른다. 다른 경우에, 이들 실시예의 설명을 용이하게 해주기 위해 공지의 구조 및 장치가 블록도 형태로 도시되어 있다.

본 출원에서 사용되는 바와 같이, 용어 "컴포넌트", "모듈", "시스템", 기타 등등은 컴퓨터 관련 개체, 즉 하드웨어, 하드웨어와 소프트웨어의 조합, 소프트웨 어, 또는 실행 중인 소프트웨어를 말하기 위한 것이다. 예를 들어, 컴포넌트는 프로세서 상에서 실행 중인 프로세스, 프로세서, 객체, 실행 파일, 실행 쓰레드, 프로그램, 및/또는 컴퓨터일 수 있지만, 이에 한정되지 않는다. 예시로서, 서버 상에서 실행 중인 애플리케이션 및 서버 둘다가 컴포넌트일 수 있다. 프로세스 및/또는 실행 쓰레드 내에 하나 이상의 컴포넌트가 존재할 수 있으며, 컴포넌트는 하나의 컴퓨터 상에 로컬화되어 있고 및/또는 2개 이상의 컴퓨터 간에 분산되어 있을 수 있다.

단어 "예시적인"은 본 명세서에서 일례, 사례 또는 예시로서 역할하는 것을 의미하는 것으로 사용된다. 본 명세서에 "예시적인"것으로 기술된 측면 또는 설계가 반드시 다른 측면 또는 설계보다 선호되거나 유익한 것으로 해석될 필요는 없다.

본 명세서에서 사용되는 바와 같이 메모리, 저장 장치, 데이터베이스, 또는 기타 매체라고 하는 것은 비휘발성 및/또는 휘발성 메모리를 포함할 수 있다. 적당한 비휘발성 메모리는 ROM(read only memory), PROM(programmable ROM), EPROM(electrically programmable ROM), EEPROM(electrically erasable programmable ROM), 또는 플래쉬 메모리를 포함할 수 있다. 휘발성 메모리는 외부 캐쉬 메모리로서 기능하는 RAM(random access memory)을 포함할 수 있다. 제한이 아닌 예시로서, RAM은 SRAM(static RAM), DRAM(dynamic RAM), SDRAM(synchronous DRAM), DDR SDRAM(double data rate SDRAM), ESDRAM(enhanced SDRAM), SLDRAM(Synchlink DRAM), RDRAM(Rambus direct RAM), DRDRAM(direct Rambus dynamic RAM), 및 RDRAM(Rambus dynamic RAM) 등의 많은 형태로 이용가능하다.

본 명세서에서 사용되는 바와 같이, 용어 "추론한다" 또는 "추론"은 일반적으로 이벤트 및/또는 데이터를 통해 포착된 일련의 관찰 결과들로부터 시스템, 환경, 및/또는 사용자의 상태에 관해 추리를 하거나 이를 추론하는 프로세스를 말한다. 추론은 특정의 컨텍스트 또는 동작을 식별하는 데 이용될 수 있거나, 예를 들어, 상태들에 대한 확률 분포를 생성할 수 있다. 추론은 확률적일 수 있다, 즉 관심의 상태들에 걸친 확률 분포의 계산이 데이터 및 이벤트의 고려에 기초할 수 있다. 추론은 또한 일련의 이벤트 및/또는 데이터로부터 상위 레벨 이벤트를 작성하는 데 이용되는 기법들을 말할 수 있다. 이러한 추론의 결과, 이벤트가 시간상으로 근접하여 상관되어 있든 또한 이벤트 및 데이터가 하나 또는 몇개의 이벤트 및 데이터 소스로부터 나온 것이든 간에, 일련의 관찰된 이벤트 및/또는 저장된 이벤트 데이터로부터 새로운 이벤트 또는 동작이 구성된다.

다수의 컴포넌트, 모듈, 기타 등등을 포함할 수 있는 시스템과 관련하여 다양한 실시예들이 제공된다. 다양한 시스템들이 도면과 관련하여 설명된 부가적인 컴포넌트, 모듈, 기타 등등을 포함할 수 있다(또는 이들 모두를 포함하는 것은 아니라)는 것을 잘 알 것이다. 이들 방법의 조합도 사용될 수 있다. 본 명세서에 개시된 다양한 실시예들은 터치 스크린 디스플레이 기술 및/또는 마우스-키보드 유형의 인터페이스를 이용하는 장치를 비롯한 전기 장치 상에서 수행될 수 있다. 이러한 장치의 예로는 컴퓨터(데스크톱 및 모바일), 스마트 폰, PDA(personal digital assistant), 및 기타 전자 장치(유선 및 무선 둘다)가 있다.

이하의 상세한 설명에서, 다양한 측면들 및 실시예들이 SQL 서버와 관련하여 기술될 수 있다. 이들 본 발명의 측면들이 개시된 실시예에서 사용하기에 아주 적합할 수 있지만, 당업자라면 이들 본 발명의 측면들이 마찬가지로 다양한 다른 데이터 관리 제품에서 사용하기 위해 적용가능하다는 것을 잘 알 것이다. 그에 따라, SQL 서버라고 한 것은 본 발명의 측면들을 예시하기 위한 것에 불과하며, 이러한 본 발명의 측면들이 광범위한 응용을 갖는다는 것을 잘 알 것이다.

먼저, 도 1을 참조하면, 시스템 아키텍처(100)의 상위 레벨 블록도가 도시되어 있다. 데이터베이스 또는 시스템 관리자(이후부터는 사용자라고 함)는 일반적으로 데이터 관리 제품(예를 들어, SQL 데이터베이스 또는 서버)과 관련하여 다양한 서비스(예를 들어, 관계형 데이터베이스)의 정확한 동작을 계속 제공할 책임이 있다. 관리될 서비스 또는 개체를 본 명세서에서 대상(102)이라고 하며, 시스템(100)은 대상(102)에 관계된 이러한 목적 또는 관리 정책을 달성하도록 구성되어야만 한다.

이러한 정책을 정의할 때, 무엇이 일어날지(예를 들어, "한시간 내에 데이터를 복구할 수 있어야만 한다")를 기술하는 데 논리적 서술문 또는 선언형 서술문이 이용되고 이들이 어떻게 시행되어야 하는지(예를 들어, "시간 단위 스케쥴로 백업 작업 생성하기")를 기술하는 데 물리적 서술문(physical statement)이 이용되는 경우, 더 높은 생산성이 달성될 수 있다. 따라서, 정책이 이러한 목적을 용이하게 해주기 위해 변경되어야만 하는 실제의 구성 설정으로 표현되지 않고 사용자의 의도로 표현되어야만 한다.

정책의 실제 구현은 복잡할 수 있는데, 그 이유는 각각이 서로 다른 의미를 사용하여 처리되는 많은 하위 레벨 설정이 있을 수 있기 때문이다. 그에 부가하여, 사용자가 함께 처리하고자 할 수 있는 설정들이 서로 다른 장소에, 서로 다른 방식으로, 또는 둘다로 노출될 수 있다. 많은 경우에, 사용자는 어쩔 수 없이 다수의 유사한 객체들에 단 하나의 설정을 반복적으로 적용해야 한다(예를 들어, 각각의 데이터베이스가 문자 데이터에 대해 특정의 정렬 순서를 사용한다). 패싯(104)은 사용자의 의도와 하위 레벨 설정 간의 격차를 메우는 데 이용될 수 있다. 패싯(104)은 사용자 의도의 특정의 차원을 모델링하는 일련의 논리적 속성들로 간주될 수 있다. 사용자는 패싯(104)에 의해 노출되는 상위 레벨 구조에 대해 정책을 생성할 수 있으며, 이 패싯(104)은 정책을 기초적인 대상(102)을 질문 또는 구성하는 데 이용될 수 있는 명령으로 변환하도록 구성될 수 있다.

대상(들)(102)은 패싯(들)(104)을 통해 상태 또는 메타데이터를 노출시킬 수 있다. 예를 들어, 테이블은 그의 스키마 메타데이터(예를 들어, 이름, 소유자, 기타)에 대응하는 상태를 가질 수 있다. 그의 물리적 저장(예를 들어, 파티셔닝, 파일 그룹)에 대응하는 상태 및 데이터 내용(예를 들어, 크기, 행의 수)에 대응하는 상태가 있다. 이들은 서로 다른 패싯일 수 있고, 대상 유형의 각각의 패싯은 의도를 명시하는 인터페이스이다.

정책은, 예를 들어, 패싯(104)의 알맞은 상태에 관한 서술문일 수 있다. 고전적인 선언형 스타일에서, 정책은 원하는 상태를 어떻게 달성하느냐가 아니라 대상(102)의 원하는 상태를 명시한다. 예를 들어, 스키마 메타데이터에 관한 정책은 이름이 "xy_"로 시작해야 하는 것으로 명시할지도 모른다. 이들 명세는 (예를 들어, 패싯(104)의 속성들에 대한 간단한 부울식을 통해) 알맞은 상태에 대한 제약조건(들)(106)으로서 정의될 수 있다. 따라서, 제약조건(106)은 단 하나의 패싯 파라미터를 갖는 부울 함수일 수 있으며, 일련의 허용된 상태를 명시할 수 있다.

정책(108)은 제약조건(106) 및 그의 거동(예를 들어, 제약조건(106)이 실행되는 방식)을 명시할 수 있다. 서로 다른 정책들이 복합 정책 또는 정책 그룹(110)으로 통합될 수 있다(예를 들어, 단일의 정책이 기계에 대한 모든 보안 요건을 포함할 수 있거나, 전체적인 서버 정책이 명명 정책, 표면 영역 정책, 데이터 복구성 정책, 공간-관리 정책을 결합할 수 있다). 정책들은 다른 정책들을 참조할 수 있다.

개개의 정책(108)은 대상(102) 또는 일련의 대상에 대해 명시적으로 평가될 수 있다. 정책(108)은 단일의 객체 또는 객체들의 모음에 적용될 수 있다(예를 들어, 정책이 데이터베이스의 모든 객체들에 적용될 수 있다). 정책(108)은 또한 기업에 걸쳐 적용될 수 있다(예를 들어, 정책이 웹 팜(web farm)에 있는 모든 서버들에 적용될 수 있다). 기업 관리는 구성 및 유지 정책이 다수의 이질적인 서버 인스턴스(예를 들어, 서버 팜, 연합 서버)에 걸쳐 있는 기업 시스템 관리의 총 비용을 간단화하고 저감시킬 수 있는 체계이다.

정책(108)의 구속을 받는 객체들의 모음을 대상 집합(112)라고 하며, 여기서 대상 집합(112)은 경로 표현식에 의해 지정된 일련의 관리 대상들이다. 대상 집합(112)은 그 경로에 있는 모든 대상들로 이루어져 있다. 정책(108)과 대상 집 합(112)의 연관 관계를 정책 연계(policy binding)(114)라고 하며, 정책(108)과 관리 대상 집합(112) 간의 M:M 관계이다. 대상 집합(들)(112)을 이용함으로써, 사용자들은 단일의 동작으로 그의 모든 기계들을 검사 또는 구성할 수 있다. 시스템(100)은 정책 연계를 통해 특정의 정책을 일련의 특정 대상에 자동적으로 적용할 수 있다. 이 연계는 또한 원하는 거동의 유형을 명시할 수 있다(예를 들어, 위반이 있는지 검사, 대상을 부합하도록 변경).

선언형 의도로서 표현된 선언형 관리를 이용하여, 사용자는 정책(108)이 주어진 대상 집합(112)과 비교되도록 요청할 수 있고, 이러한 사용자는 대상 집합(112)이 정책(108)과 부합하는지를 통보받을 수 있다. 선언형 관리 사용자는 또한 주어진 대상 집합(112)이 정책과 부합하게 되도록 요청할 수 있다. 시스템은 대상 집합(112)을 구성하여, 하나 이상의 설정이 부합하는 결과를 내도록 할 수 있다. 이것이 가능하지 않은 경우(예를 들어, 정책이 CPU 사용이 80% 미만이도록 요구할지 모르는 경우), 시스템은 패싯(104)을 구성가능으로 플래깅할 수 있고 비구성가능 패싯에 의존하는 정책을 구성하려는 시도를 거부할 수 있다. 이하의 표는 개시된 실시예에서 이용될 수 있는 예시적인 패싯을 나타낸 것이다.

관리 패싯	속성	지원 대상 유형	설명
IDatabaseManagement	bool SupportsIndexedViews	데이터베이스	논리적 데이터베이스 관리 속성
ILoginSettings	bool GuestEabledInUserDatabase string GurrentAuditLevel	서버	논리적 서버 로그인 관련 속성
IMemorySettings	bool AWECapability	서버	논리적 서버 메모리 관리 속성
IOffByDefault	Bool AdHocDistributedQueriesEnabled bool DatabaseMailEnabled bool IsSqlClrEnabled bool OleAutomationProceduresEnabled bool RemoteDacConnectionsEnabled bool SqlMailXPsEnabled bool WebXPsEnabled bool XPCmdShellEnabled	서버	서버의 모델 OffByDefault 구성
IOwnedObject	string Owner	스키마
IStateDbObject	string Name string Schema string Type	테이블 뷰 저장 프로시저 사용자 정의 함수

시스템(100)은 또한 사용자-선택가능한 정책 자동화를 통하는 등 지속적인 모니터링 및 구성을 제공할 수 있다. 자동화가 호출되는 경우, 사용자는 원하는 거동(예를 들어, 위반이 있는지 검사, 대상을 부합하도록 변경, 기타 등등)을 지정할 수 있다. 어떤 실시예에서, 부합하지 않는 대상 집합을 구성하거나 구성하지 않고서, 변경에 대해 자동화된 정책 모니터링이 수행될 수 있다. 이것은 사용자에게 이탈에 대한 즉각적인 경고를 제공할 수 있다.

자동화를 위해, 사용자는 또한 정책이 언제 평가되어야만 하는지(예를 들어, 일정표에 따라, 변경이 일어날 때마다)도 지정할 수 있다. 다른 대안으로서 또는 그에 부가하여, 시스템은 자동적으로 정책을 시행할 수 있다(예를 들어, 정책을 위반하게 될 변경을 허용하지 않는다). 따라서, 시스템(100)은 사용자에게 최소한의 사용자 상호작용으로 구성을 관리하는 수단을 제공할 수 있다.

dmf_policies, drnf_constraints, dmf_bindings, dmf_target_sets, 및 dmf_target_type_to_events 등의 DMF 카탈로그 테이블이 비휘발성 저장 장치(예를 들어, SQL 서버 인스턴스에 있는 시스템 데이터베이스)에 존속될 수 있다. DFM에 의해 생성된 작업들을 검사하기 위해, 이하의 질의가 이용될 수 있다.

도 2는 데이터베이스 서버의 관리성(manageability)을 제공하는 시스템(200)을 나타낸 것이다. 사용자는 데이터베이스 서버를 그의 라이프사이클 전체에 걸쳐 관리할 수 있으며, 데이터베이스 서버에서 호스팅되는 다수의 애플리케이션을 그의 라이프사이클 전체에 걸쳐 관리할 수 있다. 관리성이란 시스템이 사용자 생산성을 얼마나 좋아지게 해줄 수 있는지의 척도이다. 생산성은 다양한 사용자 기능들의 사용의 용이성, 친숙성, 직관성 및/또는 신뢰성에 정비례할 수 있다. 생산성은 또한 관리 기능의 자동화와 다수의 인스턴스 및 배포를 통상적이고 일관된 방식으로 관리할 수 있는 것 중 어느 하나 또는 그 둘다에 정비례할 수 있다. 시스템(200)은 기업 정책에 부합하도록 구성되기 전에 발매되지 않도록 소프트웨어 설치 또는 애플리케이션 배포 동안에 포함될 수 있다.

시스템(200)은 인터페이스 컴포넌트(202), 선언형 관리 컴포넌트(204), 및 렌더링 컴포넌트(206)를 포함한다. 시스템(200)은 사용자가 의도를 입력할 수 있게 해주는 간단하고 관리가능한 수단을 제공하고, 최소한의 사용자 상호작용으로 의도의 달성을 용이하게 해주기 위해 그 의도를 하나 이상의 설정에 자동적으로 적용할 수 있다. 사용자는 인터페이스 컴포넌트(202)를 통해 이러한 의도를 입력할 수 있다.

사용자는 또한 의도와 관련하여 시스템(200)에 의해 수행될 하나 이상의 기능을 지정할 수 있다. 예를 들어, 사용자는 정책이 주어진 대상 집합과 부합하는지를 시스템이 검사하도록 요청할 수 있다. 사용자는 주어진 대상 집합이 정책과 부합하게 되도록 요청할지도 모른다. 다른 대안으로서 또는 그에 부가하여, 사용자는 정책 자동화를 요청할 수 있다. 정책의 예로는 명명 규칙 정책, 이름 제약조건 정책, 보안 로그인 정책, 구성 정책, OffByDefault 정책, 부합 정책, 데이터베이스 관리 정책, 분석 서비스 패치 레벨 정책, 백업 정책, 표면 영역 구성 정책, 서버 CPU 활용 정책, 기타 등등이 있지만, 이에 한정되는 것은 아니다.

대상을 정의하는 동안, 이들 대상이 물리적 단위(예를 들어, 개개의 데이터베이스 또는 파일 그룹)보다는 논리적 단위(예를 들어, 서버 인스턴스에 설치된 개개의 애플리케이션)에 대응하는 경우 사용자 생산성이 향상될 수 있다. 하위 레벨 동작들로의 변환의 상세는 시스템(200)에 의해 수행된다.

선언형 관리 컴포넌트(204)가 정책의 의도를 해석하고 인식 또는 추론할 때(이는 정책이 선언형으로 표현되는 경우일 수 있음), 이 컴포넌트는 모니터링 및 보고 둘다를 자동화할 수 있다. 이는 또한 정책의 부합에 도움을 주기 위해 시스템(200)의 조정 또는 유지를 자동화할 수 있다. 자동 조정(automatic tuning)은 요구 및 사용에 기초한 자동 인덱스 생성/삭제를 포함할 수 있다. 자동 조정은 활성화 또는 비활성화(온 또는 오프)될 수 있고 공격성(aggressiveness)에 대해 구성될 수 있다(예를 들어, 보다 공격적으로부터 덜 공격적으로). 자동 조정은 또한, 예를 들어, OLAP에 대한 자동 집계 설계(automatic aggregation design)를 포함할 수 있다. 이러한 설계는 큐브를 구축하는 것을 포함할 수 있다(SQL 서버 분석 서비스가 학습한 대로 집계를 가산할 수 있게 해줌). 이러한 방식으로, 시스템(200)은 적당한 성능으로 시작하여 사용을 통해 더 나아질 수 있다.

예를 들어, 의도가 "한 시간 내에 데이터를 복구할 수 있어야만 한다"라고 표현될 수 있다. 선언형 관리 컴포넌트(204)는 데이터를 복구하는 것(예를 들어, 손실된 데이터를 복구하는 것)이 요망되는 것으로 추론할 수 있고, 시스템이 정지되는 경우(예를 들어, 의식적으로 또는 무의식적으로), 정지와 거의 동시에 백업 사본을 생성하는 것이 사용자 의도를 달성하는 것이라고 추론될 수 있다. 이 백업은 마지막 백업이 행해진 것이 한시간도 채 되지 않은 경우에도 행해질 수 있다. 따라서, 사용자 의도에 구체적으로 언급되지 않은 상황이 일어난 때에도 사용자 의도가 만족된다. 그렇지만, 의도가 "시간 단위 스케쥴로 백업 작업 생성하기"와 같이 표현된 경우, 사용자 의도가 분명하지 않다. 사용자는 다양한 이유로 백업을 원할 수 있으며, 그 중 하나가 손실된 데이터를 복구하는 것일 수 있지만, 많은 다른 이유들이 있을 수 있다. 그에 부가하여, 용어 "시간 단위 스케쥴"은 시스템 고장 또는 손실된 데이터를 복구할 수 있는 것을 고려하고 있지 않다. 따라서, 의도가 선언형 언어로 작성된 경우, 시스템(200)은 그 의도로부터 조금 벗어나는 것이(예를 들어, 한명 이상의 사용자에 의해 많은 양의 데이터가 처리되고 있는 경우 시간 단위 스케쥴보다는 더 자주 백업을 생성하는 것) 사용자 의도와 잘 일치하게 될 상황에서 사용자 의도를 더 잘 추론할 수 있다.

선언형으로 표현된 의도를 이해하기 위해 다양한 실시예들이 이용될 수 있다. 이러한 실시예들은 키워드를 인식하는 단계 및 이들 키워드에 관한 통상적인 동작을 포함하는 룩업 테이블에 이들 키워드를 적용하는 단계를 포함할 수 있다. 다른 실시예들은 입력된 의도(예를 들어, 단어 문자열)를 그의 서브컴포넌트(예를 들어, 개개의 단어)로 파싱하는 단계 및 각각의 서브컴포넌트에 하나 이상의 기능을 수행하는 단계를 포함할 수 있다. 업계에서 또는 이 특정의 사용자 또는 사용자 그룹에 의해 일반적으로 사용되는 유사한 단어 또는 기타 단어를 결정하기 위해 각각의 서브컴포넌트 또는 키워드가 분석될 수 있다. 이러한 방식으로, 반복되는 동작들 또는 유사한 동작들이 식별될 수 있고, 그 동작들에 대해 동일한 또는 유사한 설정 또는 파라미터가 구성될 수 있다. 다른 실시예들은 사용자 요청 의도를 결정 또는 추론하고 이러한 의도를 다수의 애플리케이션에 걸쳐 다양한 하위 레벨 설정에 동적으로 적용하기 위해 구문 엔진, 기계 학습, 규칙 기반 논리, 인공 지능, 추론 엔진, 기타 등등을 이용할 수 있다.

상위 레벨 의도를 하위 레벨 설정에 자동적으로 적용하기 위해, 선언형 관리 컴포넌트(204)는 애플리케이션을 구성하는 대상 요소들을 식별하도록 구성될 수 있다. 식별된 대상 요소들은 다양한 개개의 대상 요소들로 이루어진 하나의 대상으로 패키지화될 수 있다. 그 결과 얻어진 애플리케이션이 부가의 시스템들에 설치될 수 있고 정책들이 애플리케이션 내의 그 객체들을 대상으로 할 수 있다. 따라서, 하나의 동작으로, 사용자는 많은 기계 상에서 신뢰성있게 설정을 변경하거나, 정책 시행을 검사, 구성 또는 자동화할 수 있다. 선언형 관리 컴포넌트(204)는 또한 대상 서버 상의 다른 객체들을 방해하지 않고 애플리케이션을 제거할 수 있다.

자동화가 호출되는 경우, 선언형 관리 컴포넌트(204)는 요청된 거동을 자동적으로 수행할 수 있다. 이러한 거동으로는, 위반이 있는지 검사하는 것, 대상을 부합하도록 구성하는 것, 기타 등등이 있을 수 있지만, 이에 한정되는 것은 아니다. 자동화는 또한 사용자가 정책이 언제 평가되어야 하는지, 정책을 언제 시행해야 하는지, 또는 둘다를 할 수 있게 해준다.

선언형 관리 컴포넌트(204)는 선언형으로 표현된 사용자 의도를 분석하고 이러한 의도를 달성하도록 구성되어야 하는 하위 레벨 설정에 이러한 의도를 적용하도록 구성될 수 있다. 이 컴포넌트는 또한 보관 또는 배포를 위해 정책 및 연계를 스크립팅, 가져오기 및 내보내기하도록 구성될 수 있다. 선언형 관리 컴포넌트(204)는 패싯의 속성들에 기초하여, 단순하든 복합적이든 간에, 구성가능한 및/또는 시행가능한 정책을 인식할 수 있다.

패싯들은 속성에 액세스하는 디스패치 메서드들 및 커밋 논리(commit logic)를 포함할 수 있는 BaseFacet 등의 공통의 인터페이스로부터 도출될 수 있다. 각각의 패싯은 읽기 전용 또는 읽기/쓰기 속성일 수 있는 속성들을 정의할 수 있다. 어댑터 클래스는 BaseFacet 인터페이스로부터 상속될 수 있고 기초를 이루는 객체 모델 클래스를 집계할 수 있다. 어댑터는 패싯 속성들을 노출시키기 위해 객체 모델 클래스(및 기타 논리)의 물리적 속성들을 이용할 수 있다.

렌더링 컴포넌트(206)는 선언형 관리 컴포넌트(204)에 의해 수행되는 다양한 기능들에 관해 사용자에게 정보를 제공할 수 있다. 이러한 정보는 보고서 형태로 제시될 수 있고, 이는 디스플레이 화면 상에서 볼 수 있고, 파일로 저장될 수 있으며, 인쇄될 수 있고, 기타 등등이 행해질 수 있다. 자동 정책 검사가 시스템(200)에 의해 자율적으로 수행될 수 있는 동작 또는 일련의 동작과 결합될 수 있다. 동작 및 통지가 정책 평가 성공 또는 실패와 연관될 수 있다. 이러한 통지는, 위반의 심각성 및 요청된 통지 유형(있는 경우)에 따라, 보안 정책이 실패하는 경우 지정된 사람 또는 일련의 사람들에게 이메일을 자동적으로 전송하는 것, 오디오 통지를 생성하는 것, 시각적 통지(예를 들어, 경고문)를 생성하는 것, 또는 다른 동작(하나 이상의 기능을 디스에이블시키는 것)을 수행하는 것을 포함할 수 있다.

사용자는 또한 렌더링 컴포넌트(206)에 액세스함으로써 임의의 대상에 대한 정책을 볼 수 있다. 특정의 대상이 많은 서로 다른 정책 하에 있을 수 있으며, 이들 중 어떤 정책들은 그 대상 자체에 적용될 수 있다. 대상으로 된 애플리케이션에 그 대상이 속해 있을 수 있거나, 그 대상이 자기를 호스팅하는 기계 또는 상위 그룹의 기계들에 연계되어 있을 수 있다. 사용자는 대상을 제약하는 정책들 또는 정책들의 일부분을 볼 수 있다. 이와 같이, 사용자는 대상, 정책 또는 제약조건이 여전히 적용가능한지 또는 하나 이상의 파라미터에 수정이 행해져야만 하는지를 결정할 수 있다.

정책과의 부합성 또는 정책의 위반에 관한 정보가 피드백 루프(208)를 통해 인터페이스 컴포넌트(202) 또는 선언형 관리 컴포넌트(204)로 중계될 수 있다. 이러한 피드백은 대상 또는 정책이 하나 이상의 사용자-정의 파라미터를 위반하고 있는 경우 시스템(200)이 원하는 사용자 의도를 달성하기 위해 대상 또는 정책을 자동적으로 구성할 수 있게 해준다.

사용자가 시스템의 상태(예를 들어, 정책 준수)를 모니터링(예를 들어, 보고 및 분석)하고 경향 또는 문제점을 분석하고자 하는 경우, 선언형 관리 컴포넌트(204)는 (피드백을 통해) 정책 평가의 결과를 포착하고 보고 및 분석을 위해 대상들의 획득된 상태 이력을 동작 데이터 웨어하우스(operational data warehouse)로 컴파일할 수 있다. 이러한 보고는 시스템의 상태를 모니터링하기 위해 사용자에 의해 이용될 수 있고, 사용자는 결함이 있는 경우 이를 수작업으로 정정할 수 있다. 사용자는 또한 (자동적으로 또는 사용자 요청 시에) 그 결함을 정정하도록 시스템(200)에 지시할 수 있다.

시스템(200)은 확장가능하며, 따라서 개별적인 경험(예를 들어, 파티셔닝을 관리하는 정책, 데이터 복구성을 관리하는 정책, 기타 등등)이 시스템(200)의 확장이 된다. 인터페이스 컴포넌트 및 시스템의 기타 서비스 어느 것도 특정의 패싯의 특정의 대상 유형에 의존하지 않는다. 이러한 분리는 사용자가 프로그래밍 모델을 단순히 확장시키는 것으로 새로운 선언형 관리 패싯을 증분적으로 추가할 수 있게 해준다.

시스템(200)은 또한 백업/복원, 인덱스 조정/유지, 물리적 오염으로부터 자동 복구, 백그라운드 유지, 및/또는 파티션 관리 등의 다양한 특징들을 제공할 수 있다. 자동 시스템(200) 유지는 통상적인 유지 작업, 자동 디스크 조각 모음(defragmentation), 자동 축소/압축, 자동 일관성 검사, 및/또는 개선된 자동 통계를 포함할 수 있다. 어떤 실시예들에서, 시스템(200)은 데이터베이스 생성 시에 생성된 기본 백업 유지 계획을 제공할 수 있거나, 기본 계획이 맞춤화될 수 있다. 파티션 관리는 슬라이딩-윈도우 방식(예를 들어, 새 파티션/파티션 기능 생성, 파티션 병합(7일을 1주일, 기타 등등으로), 파티션 아카이빙, 기타 등등)의 자동 유지를 포함할 수 있다.

물리적 오염으로부터의 자동 복구는 시스템(200)에 의해 용이하게 행해질 수 있다. 이것은 자동 일관성 검사에 의해 또는 정상 동작 동안에 오염의 검출에 의해 트리거될 수 있다. 규칙(예를 들어, 규칙-기반 컴포넌트, 기계 학습 컴포넌트, 기타 등등)이 복원 전략(예를 들어, 인덱스 재작성, 페이지 복원, 파일/파일 그룹 복원, 전체 데이터베이스 복원)을 결정할 수 있다.

시스템(200)은 3개의 계층, 즉 프로그래밍 모델, 사용자 인터페이스, 및 관리 서비스에서 지원될 수 있다. 프로그래밍 모델은 동일한 개념이 다수의 도구에서 노출될 수 있게 해주고, 사용자 동작이 스크립트가능(scriptable)일 수 있으며, 사용자는 관리 애플리케이션을 작성할 수 있다. 사용자 인터페이스(예를 들어, 그래픽, 명령줄)가 프로그래밍 모델의 상부에 구축될 수 있다. 관리 서비스는 사용자 동작을 자동화하는 기능을 제공할 수 있으며 런타임 서비스를 위한 호스팅 환경을 제공할 수 있다.

기업 관리는 그룹(예를 들어, CPU, 저장 장치 및 메모리)을 중앙집중식으로 프로비저닝함으로써 시스템(200)에 의해 용이하게 될 수 있다. 시스템(200)은 또한 그룹에 대한 구성 및 유지 계획을 적용 및 시행하고 그룹에 대한 유지 동작들의 상태를 모니터링할 수 있다. 또한, 그룹 구성 및 유지 계획에 대한 재사용가능 템플릿은 물론 백업, 데이터베이스 일관성 검사(dbcc), 및 모니터링 정책에 대한 즉각 사용가능한 템플릿이 제공될 수 있다. 시스템(200)은 그룹 구성 및 유지 계획에 대한 관리를 수정하도록 구성될 수 있다. 어떤 실시예들에서, 시스템(200)은 일군의 서버에 하나의 애플리케이션을 설치하고 그 그룹 내에서 그 애플리케이션을 동적으로 재할당할 수 있다.

그룹 관리를 위한 런치-패드(launch-pad) 또는 건강 및 상태 모니터링의 롤-업(roll-up) 등의 연합 서버들에 대한 하나의 시스템 뷰를 갖는 서버 그룹이라는 정식 개념이 있을 수 있다. 그룹 구성, 유지 및 데이터 수집 정책이 제공될 수 있다. 또한, 일군의 서버에 대한 그룹 정책 부합성 모니터링, 시행, 및 감사는 물론 애플리케이션 설치가 제공될 수 있다.

시스템(200)은 또한 데이터베이스 애플리케이션 및 환경의 선언형 정책-기반 관리를 제공할 수 있다. 성능 요건, 보안 정책, 및 신뢰성 요건 등의 데이터베이스 애플리케이션의 원하는 동작 및 관리 거동을 정의하기 위한 정책-기반 프레임워크가 제공될 수 있다. 개발 동안에 또는 배포 시에 정책들이 정의될 수 있다. 데이터베이스 시스템은 정의된 거동의 부합성을 모니터링하고, 적절한 경우, 이를 시행할 수 있다. 이 프레임워크는 변경이 커밋되기 전에 정책을 검사하거나 DDL이 실행될 때마다 서버 정책을 시행하고자 하는 컴포넌트라면 어느 것에 의해서라도 사용될 수 있다. 이는 또한 제3자 개발자가 동일한 프레임워크를 사용하여 정책을 구현할 수 있게 해준다.

시스템(200)은 선언형 정책을 사용하여 하나의 관계형 데이터베이스를 관리하는 기능 및 선언형 정책을 사용하여 관계형 데이터베이스 그룹들을 관리하는 기능을 제공할 수 있다. 또한, 정책 위주의 데이터베이스 구성 및 정책 위주의 데이터베이스 애플리케이션 배포가 제공된다. 데이터베이스 그룹들의 구성, 유지 및 모니터링을 위한 정책-위주의 엔진은 무엇을 해야 하는지를 데이터베이스 관리자가 지정할 수 있게 해주고, 이 시스템은 다수의 서버에 걸쳐 이러한 동작을 수행할 수 있다. 또한, 일군의 데이터베이스 내의 모든 데이터베이스를 구성, 유지 및 모니터링하기 위해 무엇을 해야 하는지를 지정하는 기능이 제공되며, 이 시스템은 다수의 서버에 걸쳐 이러한 동작을 수행한다.

도 3은 사용자 의도를 데이터 관리 제품에 동적으로 적용하는 시스템(300)을 나타낸 것이다. 시스템(300)은 관리 의도를 시스템(300)이 가로챌 수 있는 논리 레벨에서의 상위-레벨 정책으로서 포착하도록 구성될 수 있다. 시스템(300)은 입력(예를 들어, 대상, 정책, 의도, 목적, 요청, 기타 등등)을 받도록 구성될 수 있는 인터페이스 컴포넌트(302)를 포함한다. 이러한 입력(예를 들어, 텍스트, 오디오, 기타 등등)은 시스템 관리자 등의 사용자로부터 또는 시스템(300)으로부터의 피드백으로서 수신될 수 있다. 선언형 관리 컴포넌트(304)는 입력을 처리하도록 구성될 수 있으며, 처리된 입력의 결과가 렌더링 컴포넌트(308)에 의해 제시(예를 들어, 디스플레이)되거나 포착(예를 들어, 보고)될 수 있다. 예를 들어, 렌더링 컴포넌트(308)는 이 결과를 디스플레이 화면 상에, 오디오 수단을 통해 제공하고, 나중에 보고하기 위해 이 정보를 포착하며, 기타 등등을 할 수 있다.

렌더링 컴포넌트(308)는 다양한 형태의 모니터링 및 보고를 비롯하여 대상의 부합성 또는 비부합성에 관한 정보를 사용자에게 제시할 수 있다. 사용자는 임의의 대상에 대한 효과적인 정책을 제공하고 대상을 직접적으로 제약하는 정책의 그 부분을 제시하도록 렌더링 컴포넌트(308)에 요청할 수 있다.

다른 대안으로서 또는 그에 부가하여, 렌더링 컴포넌트(308)는 피드백 루프(308)를 통해 입력 컴포넌트(302) 또는 선언형 관리 컴포넌트(304)에 피드백을 제공할 수 있다. 이와 같이, 시스템(300)은, 이러한 기능을 자동적으로 수행하도록 구성되어 있는 경우, 의도에 따라 하나 이상의 설정점을 계속하여 모니터링 및 구성할 수 있다. 피드백 루프(308)는 시스템(300)이 자체-관리, 자체-치유 및 자체-조정할 수 있게 해준다(예를 들어, 관계형만이 아니라 전체에 걸쳐 동작함). 정책이 사전에 설정될 수 있어, 일상적인 사용으로부터 다양한 설정 또는 "노브"를 제거하는 등에 의해, 동작 중에 아무 것도 할 것이 없게 해준다(예를 들어, 사용자 상호작용을 최소화함).

파싱 컴포넌트(310) 및 구문 엔진(312)도 역시 시스템(300)에 포함될 수 있다. 이들 컴포넌트(310, 312)는 선언형 관리 컴포넌트(304)의 서브컴포넌트이거나, 도시된 바와 같이, 별도의 컴포넌트일 수 있다. 파싱 컴포넌트(310)는 선언형 언어로 표현될 수 있는 하나 이상의 사용자 의도를 받아서, 이러한 언어를 분석될 수 있는 성분들로 분할할 수 있다. 예를 들어, 사용자는 의도 "I should be able to recover data to within an hour"를 입력할 수 있다. 파싱 컴포넌트(310)는 이 문장을 단어 및 구로 분할한다(예를 들어, I, should, be able to, recover, data, to within an, hour). 이 정보는 구체적인 사용자 의도를 도출하기 위해 각각의 단어 또는 구를 분석하는 구문 엔진(312)에 의해 평가될 수 있다.

"I" 및 "should"와 같은 어떤 단어 또는 구는 무시될 수 있다. "recover"와 같은 다른 단어들은 이 용어가 이 사용자, 다른 시스템 사용자에 의해 표현된 다른 방식이 있는지, 또는 업계 내에서 일반적인 용어가 있는지를 결정하기 위해 평가될 수 있다. 예를 들어, 시스템은 단어 "recover"를 단어 "backup", "failure", "lost", 기타 등등과 관련시킬 수 있다. 이것은 선언형 관리 컴포넌트(304)가 더 넓은 사용자 의도를 추론할 수 있게 해주고, 이 의도를 유사한 단어 또는 구를 사용하는 다수의 애플리케이션에 적용할 수 있게 해준다.

도 4는 상위 레벨 의도를 하위 레벨 설정에 자동적으로 적용하는 것을 용이하게 해주는 시스템(400)을 나타낸 것이다. 시스템(400)은 시스템을 사용자 의도에 부합하게 하기 위해 시스템을 어떻게 구성할 것인지가 아니라 시스템이 어떻게 되어 있어야 하는지(정책)를 사용자가 정의할 수 있게 해줌으로써 사용자 상호작용을 경감시킨다. 정책은 보안 또는 액세스 제어, 성능, 용량, 동작, 설정 또는 패치, 개발, 선언형 관리, 기타 등등의 다양한 서로 다른 카테고리에 관련되어 있을 수 있다. 사용자는 물리적 구현 명세로부터 추상화된 논리적 레벨에서 의도를 한번 정의할 수 있고, 시스템이 이를 여러번 적용한다. 시스템(400)은 데이터 관리 제품(예를 들어, SQL 서버)에 들어갈 수 있다. 게다가, 시스템은 동작을 유발하는 다양한 모드를 가질 수 있다. 이러한 모드로는, 부합하는지의 검사, 부합하도록 구성하는 것, 및 부합성을 시행하는 것이 있지만, 이에 한정되는 것은 아니다.

시스템(400)은 인터페이스 컴포넌트(402), 선언형 관리 컴포넌트(404), 및 피드백 루프(408)를 통해 시스템 피드백을 제공할 수 있는 렌더링 컴포넌트(406)를 포함한다. 다양한 시스템(400) 컴포넌트는 선언형 관리 컴포넌트(404)의 하나 이상의 기능을 용이하게 해주기 위해 독립적으로 또는 협력하여 동작할 수 있다. 이러한 컴포넌트들로는 보안 컴포넌트(410), 이력 컴포넌트(412), 집계 컴포넌트(414), 구성 컴포넌트(416), 최적화 컴포넌트(418), 및 연계 컴포넌트(420)가 있다. 이들 컴포넌트(410-420)는 도시된 바와 같이 독립적일 수 있거나, 선언형 관리 컴포넌트(404)의 서브컴포넌트일 수 있다.

인터페이스 컴포넌트(402)는 그래픽 사용자 인터페이스(GUI), 명령줄 인터페이스, 기타 등등일 수 있다. 사용자는 선택적으로 인터페이스 컴포넌트(402)와의 상호작용을 통해 선언형 관리 컴포넌트(404)의 결과 출력(예를 들어, 하나 이상의 설정에 대한 변경)을 구성할 수 있다. 인터페이스 컴포넌트(402) 및 예시적인 사용자 인터페이스에 관한 추가적인 상세가 이하에 제공되어 있다.

보안 컴포넌트(410)는 하나 이상의 보안 요소 또는 통합 보안 모델을 제공하도록 구성될 수 있다. 보안 컴포넌트(410)는, 사용자와 연관된 고유 ID(예를 들어, 사용자 이름, 사용자 패스워드) 등을 통해, 사용자에 관한 정보를 수집할 수 있다. 각각의 사용자에 대한 미리 정의된 보안 레벨에 기초하여, 보안 컴포넌트(410)는 사용자가 볼 권한이 있는 대상 집합 또는 정책의 그 부분만을 그 사용자가 볼 수 있도록 선택적으로 렌더링 컴포넌트(406)와 인터페이스할 수 있다. 이와 같이, 시스템(400)은 사용자가 허가되어 있지 않거나 사용자가 충분한 정보를 가지고 있지 않으며 따라서 수정해서는 안되는 설정에 대한 불법적인 수정, 추가, 삭제, 기타 등등을 감소시킬 수 있다.

그에 부가하여 또는 다른 대안으로서, 보안 컴포넌트(410)는, 미리 정의된 구성과 같이, 특정의 방식 또는 순서로 정책들을 배포하도록 구성될 수 있다. 이러한 미리 정의된 구성은 상위 레벨에서 배포된 정책이 하위 레벨 정책을 대체할 수 있게 해주는 것 등의 다양한 작업을 포함할 수 있다. 예를 들어, 서버 그룹 정책은 데이터베이스 정책보다 우선권을 가질 수 있다. 보안 컴포넌트(410)는 또한 패싯을 부합하지 않게 하려는 시도를 검출하고 이러한 시도를 방지할 수 있다(예를 들어, 시스템이 정책을 "시행"할 수 있다). 그렇지만, 다수의 다른 구성이 이용가능하며 적절한 보안 레벨을 갖는 사용자에 의해 구성될 수 있다는 것을 잘 알 것이다.

이력 컴포넌트(412)는 이전의 정책들, 정책 버전, 대상, 패싯, 기타 등등에 관한 정보를 유지할 수 있다. 이것은 하나 이상의 시스템(400) 컴포넌트에 이전의 정책들, 정책 버전, 대상, 기타 등등에 액세스하여 각각의 연관관계 및 관련성을 결정하는 기능을 제공할 수 있다. 이러한 이력 정보는 하나 이상의 시스템(400) 컴포넌트와 연관된 저장 매체에 검색가능한 형식으로 유지될 수 있다. 예를 들어, 시스템(400)은 정보를 저장할 수 있는 메모리 및/또는 어떤 다른 매체를 포함할 수 있다.

이력 정보는 선언형 서술문(예를 들어, 의도)을 하위 레벨 설정으로 변환함으로써 시스템(400) 구성의 자동화를 가능하게 해주기 위해 시스템(400)에 의해 이용될 수 있다. 예를 들어, 사용자는 애플리케이션을 이루고 있는 대상 요소들을 명시할 수 있고, 이러한 애플리케이션이 어떤 대상으로부터 가져오기되어 저장되고, 나중에 한 단위로서 새로운 대상들에 배포될 수 있다. 이 정보는 또한 렌더링 컴포넌트(406)를 통해 사용자에게 제시될 수 있으며, 그에 따라 사용자가 서로 다른 정책 및 정책 버전과 이들의 관리 대상과의 연관관계의 이력을 볼 수 있게 된다. 사용자는 이러한 정보를 사용하여 시스템(400)을 추가적으로 구성하거나, 특정의 시스템(400) 구성을 결정하거나, 시스템(400)의 과거의 상태(들)에 관한 다른 정보를 획득할 수 있다.

물리적 서술문이 물리적 대상들에 적용되는 경우, 사용자는 종종 그의 동작에서 서버-관련 또는 애플리케이션-관련 아티팩트를 사용할 수 밖에 없으며, 이는 의도를 많은 서버 상의 많은 애플리케이션에 걸쳐 널리 적용하는 것을 거의 불가능하게 만든다. 이 문제를 극복하기 위해, 집계 컴포넌트(414)는, 규모에 따른 자동화를 비롯한, 규모에 따른 관리를 가능하게 해주도록 구성될 수 있다. 따라서, 사용자는 동일한 관리 패싯이 서로 다른 방식으로 구성되어 있는 객체들에 의해 표현될 때 개개의 객체들을 구성하기 위한 특수화된 의미를 배우거나 기억할 필요가 없다. 예를 들어, 정책들이 하나의 대상에 대해 또는 일군의 대상에 대해 (명시적으로 또는 자동화를 통해) 적용될 수 있다. 인터페이스 컴포넌트(402)를 사용하여 하나의 정책을 입력하는 것에 의해, 정책이 관리 패싯에 대해 적용될 수 있기 때문에, 사용자는 이 관리 패싯을 표현하는 다수의 객체를 구성할 수 있다. 그렇지만, 애플리케이션을 대상으로 하는 정책은 서버 상의 그 애플리케이션에 속하는 객체에만 적용되어야 한다. 다른 대안으로서 또는 그에 부가하여, 집계 컴포넌트(414)는 서로 다른 관리 대상으로부터의 설정 등의 서로 다른 설정을 추상화할 수 있다. 예를 들어, 자원 소비 패싯은 데이터 서버 상의 운영 체제 파일 시스템 및 나머지 비어있는 페이지의 모니터링 및 구성 둘다를 할 수 있다.

구성 컴포넌트(416)는 사용자가 시스템(400)의 하나 이상의 요소(예를 들어, 정책, 대상)를 자동적으로 구성하도록 이 하나 이상의 요소를 선택적으로 구성할 수 있게 해준다. 예를 들어, 임시적으로, 사용자는 선언형 관리 컴포넌트(404)에 주어진 대상이 주어진 정책에 부합하는지를 검증하도록 지시할 수 있다. 시스템(400)은 강제로 정책에 부합하도록 하기 위해 부합하지 않는 대상에 대한 다른 동작을 재구성 또는 수행할 수 있다.

사용자는 확장가능 API(application program interface) 등의 프로그래밍 모델을 확장함으로써 새로운 패싯 또는 대상을 증분적으로 추가할 수 있다. API는 일련의 루틴, 프로토콜, 및 도구를 통해 소프트웨어 애플리케이션을 작성하는 것을 용이하게 해주며, 여기서 개발자 및/또는 프로그래머는 API를 이용하여 운영 환경 및 사용자(들) 요구에 부합하는 맞춤화된 애플리케이션을 작성할 수 있다. 패싯을 한 구조로서 확장가능 API에 포함시키는 것은 사용자가 그의 관리 목적을 파악하고 수행하기 위해 그 자신의 패싯을 생성할 수 있게 해준다. 대상을 한 구조로서 확장가능 API에 포함시키는 것은 부가의 대상들이 새로운 대상을 구현하는 사용자 또는 소프트웨어 개발자에 의해 시스템(400) 제어 하로 들어올 수 있게 해준다.

최적화 컴포넌트(418)는 시스템(400)의 하나 이상의 파라미터를 최적화하도록 구성될 수 있다. 최적화 컴포넌트(418)는 시스템(400) 애플리케이션이 다수의 서버 및 다수의 제품(예를 들어, 판매업자)에 걸쳐 확장될 수 있게 해줄 수 있다. 사용자는 다수의 객체들을 포함하는 계층구조의 루트를 정책의 대상으로 함으로써 그 객체들에 정책이 적용되게 할 수 있다. 따라서, 한 서버 상의 하나의 객체로부터 기업에 이르는 계층구조의 어느 레벨이라도 정책의 대상으로 될 수 있다.

일군의 유사한 서버(예를 들어, 멀티-서버 구성)에 대해, 시스템(400)은 공통의 구성 옵션들을 설정하고, 그룹 구성에 부합성을 시행하며, 구성 변경을 감사하는 기능을 제공한다. 시스템은 서버 그룹들에 대한 공통의 유지 계획 및 작업을 구성하여 일군의 서버에 대한 유지 작업의 상태를 모니터링할 수 있음으로써 서버 그룹 유지를 간단화하는 것을 용이하게 해줄 수 있다. 서버 그룹 유지를 간단화하는 것은 유지 계획, 작업 및 스크립트에 대한 중앙 저장소는 물론 유지 계획 변경을 감사하는 기능도 갖추고 있을 수 있다.

시스템(400)은 모니터링 컨텍스트(예를 들어, 과소 또는 과잉 서버 이용) 및/또는 성능/동작 데이터 모음에 기초하여 서버들의 서브셋에 집중하기 위해 일군의 서버의 전반적인 건강을 모니터링하는 기능을 제공함으로써 다수의 서버를 모니터링하는 것을 용이하게 해줄 수 있다.

어떤 실시예들에서, 최적화 컴포넌트(418)는 전체 라이프사이클의 자동화를 가능하게 해줌으로써 자체-관리 시스템을 제공하도록 구성될 수 있다. 이것은 배포의 자동 구성, 자동 모니터링, 자동 부합성 보고, 및 시스템(400)의 자동 유지 및 조정을 포함할 수 있다.

연계 컴포넌트(420)는 하나 이상의 정책의 평가를 효율적으로 수행하기 위해 연계 평가(binding evaluation)를 수행하도록 구성될 수 있다. 연계 컴포넌트(420)는 M:M 관계를 갖는 정책과 대상 집합 간의 연관관계를 제공할 수 있다(예를 들어, 대상 집합마다 하나의 정책이 있다). 즉, 연계는 하나의 정책과 하나의 대상 집합으로 이루어져 있다. 정책이 2개 이상의 연계에 의해 참조될 수 있다. 대상 집합이 2개 이상의 연계에 의해 참조될 수 있다. 연계 거동은 데이터 위주로 되어 있을 수 있으며, 그에 의해 유사한 방식으로 관리될 서버 그룹들을 구축하는 데 표준의 데이터 복제 기술(예를 들어, 트랜잭션 복제)이 사용될 수 있게 된다. 어떤 실시예에서, 연계 평가는 대상 집합에 의해 기술된 일련의 객체를 계산하고 모든 제약조건들을 각각의 대상에 적용(예를 들어, 그의 제약조건에 포함된 표현식 트리 내의 코드를 실행)함으로써 클라이언트 코드에서 수행될 수 있다. 정책 연계는, 관리 서비스에 대한 다른 메타데이터와 함께, 데이터베이스 또는 기타 저장 매체 등에 저장될 수 있다.

어떤 실시예들에서, 연계 평가는 서버 컨텍스트에서 실행될 수 있는 질의로 변환될 수 있다. 이러한 질의는 연계에서의 제약조건들 중 임의의 것을 위반하고 있는 객체를 반환할 수 있다. 변환 프로세스가 이용될 수 있으며, 그에 의해 연계에서의 모든 제약조건에 대해, 대상 노드를 기술하는 URN(uniform resource name)부터 시작하여, 그것을 부정하여 제약조건을 만족시키지 않는 행들만을 포함시키기 위해 제약조건 표현식에 포함된 정보가 사용된다. 연계 평가에 대응하는 URN이 획득될 수 있다. 대부분의 경우에, 이 URN은 열거자(enumerator)에 의해 질의로 변환될 수 있고, 연계를 질의로 환산할 수 있다. 제한이 아닌 예로서, 이하는 제약조건의 일례이며, 여기서 데이터베이스 "JM_Account"에서의 모든 사용자 정의 저장 프로시저의 이름은 "JM_"으로 시작한다.

이것은 중간 URN으로 분해될 수 있다.

이어서, 그 다음 변환에 의해 이는 이하의 것과 유사한 것으로 된다.

이제 도 5를 참조하면, 개시된 실시예들을 이용하는 이벤트 디스패치 메카니즘(500)이 도시되어 있다. DDL 트리거 이벤트(502), 추적 이벤트(504), 및 WMI 이벤트(506) 등의 이벤트가 다수의 데이터 소스로부터 수집되어, 이벤트들이 처리되기 전에 이벤트를 저장하는 데 이용되는 임시 테이블일 수 있는 집결지(508)에 둘 수 있다. (시스템(500)에 존재하는) 어느 연계(510)가 이벤트(들)(508)에 관심이 있을 수 있는지를 결정하기 위해 알고리즘, 방법 또는 기타 기법이 이용될 수 있다. 이러한 결정은 연계(510)에 존재하는 제약조건(들)(516)에 의해 사용되는 (등록된) 패싯(들)(514)에 대한 기존의 어댑터(512)(예를 들어, 시스템(500)에 등록된 어댑터들에 관한 정보)에 기초하여 행해질 수 있다. 연계(510), 어댑터(512), 패싯(514) 및 제약조건(526)은 4-블록 테이블 조인(518)을 나타낼 수 있다. 연계는 연계 활성화(binding activation)를 포함하는 이력 테이블인 연계 활성화(520)에 포함될 수 있다. 522로 나타낸 바와 같이, 연계가 활성화 또는 평가될 수 있다. 적어도 부분적으로 정의된 거동 및 결과에 기초하여, 예를 들어, 변경을 방지하는 것 또는 나중의 분석을 위해 변경을 보고하는 것일 수 있는 맞춤 조치가 취해질 수 있다. 연계 평가는 동일한 트랜잭션 컨텍스트를 이벤트를 생성한 동작과 공유할 수 있다. 동작을 방지하는 것은 연계를 평가한 절차에서의 트랜잭션을 롤백하는 것을 포함할 수 있다.

도 6은 개시된 실시예들에 따른, 하나 이상의 특징들을 자동화하는 것을 용이하게 해주는, 기계 학습을 이용하는 시스템(600)을 나타낸 것이다. 시스템(600)은 사용자 인터페이스 컴포넌트(602), 선언형 관리 컴포넌트(604), 렌더링 컴포넌트(606), 피드백 루프(608), 및 기계-학습 컴포넌트(610)를 포함한다. 사용자는 사용자 인터페이스 컴포넌트(602)와의 상호작용을 통해 다양한 정책, 목표, 또는 의도를 입력할 수 있다. 이 정보는 시스템(600)을 동적으로 구성하기 위해 기계 학습 컴포넌트(610)와 인터페이스하는 선언형 관리 컴포넌트(604)에 전달된다.

시스템(600)은 다양한 측면들을 수행하기 위해 다양한 기계 학습 방식을 이용할 수 있다. 어떤 실시예들에 따르면, 인공 지능이 이용될 수 있다. 본 명세서에 기술된 하나 이상의 측면에 따라 추론 및/또는 확률적 결정 및/또는 통계-기반 결정을 수행하는 것과 관련하여, 인공 지능 기반 시스템(예를 들어, 명시적으로 및/또는 암시적으로 훈련된 분류기)가 이용될 수 있다. 본 발명의 실시예들과 관련하여 자동적인 및/또는 추론된 동작을 수행하는 것과 관련하여 다양한 분류 방식 및/또는 시스템(예를 들어, 지원 벡터 기계, 신경망, 전문가 시스템, 베이지안 믿음 네트워크, 퍼지 논리, 데이터 융합 엔진...)이 이용될 수 있다.

예를 들어, 특정의 대상 집합이 정책에 부합하는지를 결정하는 인공적 프로세스는 자동 분류기 시스템 및 프로세스(예를 들어, 인공 지능 컴포넌트)를 통해 용이하게 될 수 있다. 게다가, 다수의 정책이 동일한 또는 유사한 리소스를 가질 것을 요청하고 있는 경우, 특정의 상황에서 어느 정책을 이용할지를 결정하기 위해 분류기가 이용될 수 있다.

분류기는 입력 속성 벡터 x = (xl, x2, x3, x4, xn)를, 입력이 부류(class)에 속하는 신뢰도(confidence)에 매핑하는 함수이다, 즉 f(x) = confidence(class)이다. 이러한 분류는 사용자가 자동적으로 수행되기를 원하는 동작을 진단 또는 추론하기 위해 확률 및/또는 통계-기반 분석(예를 들어, 분석 유틸리티 및 비용을 고려함)을 이용할 수 있다. 예를 들어, 데이터베이스 시스템의 경우에, 속성은 단어 또는 구 또는 단어로부터 도출된 다른 데이터-관련 속성(예를 들어, 데이터베이스 테이블, 키 용어의 존재)일 수 있고, 부류는 관심의 카테고리 또는 영역(예를 들어, 우선순위의 레벨)이다.

지원 벡터 기계(support vector machine, SVM)는 이용될 수 있는 분류기의 일례이다. SVM은 가능한 입력들의 공간에서 초곡면(hypersurface)을 찾는 동작을 하며, 이 초곡면은 트리거링 기준(triggering criteria)을 비트리거링 이벤트(non-triggering event)로부터 분리시키려고 시도한다. 직관적으로, 이것은 분류를 훈련 데이터와 같지는 않지만 그에 가까운 테스트 데이터에 적당하게 만들어 준다. 다른 유향(directed) 및 무향(undirected) 모델 분류 접근방법은, 예를 들어, NB(naive Bayes), 베이지안 네트워크, 결정 트리, 신경망, 퍼지 논리 모델을 포함하며, 다른 독립성 패턴을 제공하는 확률적 분류 모델이 이용될 수 있다. 분류는, 본 명세서에서 사용되는 바와 같이, 우선순위 모델을 개발하는 데 이용되는 통계적 회귀(statistical regression)도 포함한다.

본 명세서로부터 잘 알 것인 바와 같이, 하나 이상의 실시예들은 (예를 들어, 일반 훈련 데이터를 통해) 명시적으로 훈련되는 것은 물론 (예를 들어, 사용자 거동을 관찰하는 것, 외부 정보를 수신하는 것에 의해) 암시적으로 훈련되는 분류기를 이용할 수 있다. 예를 들어, SVM은 분류기 생성자(classifier constructor) 및 특징 선택 모듈 내에서의 학습 또는 훈련 단계를 통해 구성된다. 따라서, 분류기(들)는 미리 정해진 기준에 따라 정책 또는 대상을 언제 구성할지, 어느 저장된 정책을 실행할지, 기타 등등을 결정하는 것(이에 한정되지 않음)을 비롯하여 다수의 기능을 자동적으로 학습하고 수행하는 데 사용될 수 있다. 이 기준은 수정할 데이터 또는 애플리케이션의 양, 정책 또는 대상의 유형, 정책 또는 대상의 중요성, 기타 등등을 포함할 수 있지만, 이에 한정되지 않는다.

어떤 실시예들에 따르면, 기계-학습 컴포넌트(610)는 규칙-기반 논리 방식을 이용할 수 있다. 이 실시예에 따르면, 데이터베이스 또는 도메인 내에서 정책 또는 하위 레벨 설정을 제어 및/또는 규율하기 위해 구현 방식(예를 들어, 규칙)이 적용될 수 있다. 규칙-기반 구현이 미리 정해진 기준에 기초하여 자동적으로 및/또는 동적으로 정책 또는 대상 집합을 규율할 수 있다는 것을 잘 알 것이다. 그에 응답하여, 규칙-기반 구현은 임의의 원하는 기준(예를 들어, 정책 또는 대상 유형, 정책 또는 대상 크기, 정책 또는 대상 중요성, 데이터베이스 소유자, 사용자 ID ...)에 기초하여 미리 정의된 및/또는 프로그램된 규칙(들)을 이용함으로써 특정의 정책을 허용, 거부, 및/또는 변경할 수 있다.

예로서, 사용자는 미리 정의된 유형의 리소스에 액세스하기 위해 믿을만한 플래그 및/또는 인증서를 필요로 할 수 있는 규칙을 수립할 수 있는 반면, 특정의 데이터베이스 내의 다른 리소스는 이러한 보안 자격증명을 필요로 하지 않을지도 모른다. 규칙의 형태로 사전 정의되거나 사전 프로그램됨으로써 우선순위가 달성될 수 있다는 것을 잘 알 것이다.

이상에서 도시하고 설명한 예시적인 시스템을 고려할 때, 개시된 발명 대상에 따라 구현될 수 있는 방법들은 도 7 및 도 8의 플로우차트를 참조하면 더 잘 이해될 것이다.

설명의 간단함을 위해, 이 방법들이 일련의 블록으로 도시되고 설명되어 있지만, 어떤 블록들이 본 명세서에 도시되고 설명된 것과 다른 순서로 및/또는 다른 블록과 동시에 행해질 수 있기 때문에, 청구된 발명 대상이 블록의 수 또는 순서에 의해 제한되지 않는다는 것을 잘 알 것이다. 게다가, 도시된 블록들 모두가 이후에 설명되는 방법을 구현하는 데 필요한 것은 아니다. 블록들과 연관된 기능이 소프트웨어, 하드웨어, 이들의 조합, 또는 임의의 다른 적당한 수단(예를 들어, 장치, 시스템, 프로세스, 컴포넌트)에 의해 구현될 수 있다는 것을 잘 알 것이다. 그에 부가하여, 이후에 또한 본 명세서 전체에 걸쳐 기술되는 방법들이 이러한 방법들을 다양한 장치로 전달 및 전송하는 것을 용이하게 해주기 위해 제조 물품에 저장될 수 있다는 것을 잘 알 것이다. 당업자라면 방법이 다른 대안으로서, 상태도에서와 같이, 일련의 상호 관련된 상태 또는 이벤트로서 표현될 수 있다는 것을 잘 알 것이다.

도 7은 사용자 생산성의 향상을 용이하게 해주는 방법(700)을 나타낸 것이다. 방법(700)이 시작되고, 702에서, 의도가 수신되는 경우, 이러한 의도가 선언형 언어로 표현될 수 있다. 704에서, 의도를 달성하도록 구성되어야 하는 설정에 관하여 결정이 행해진다. 이러한 설정은 상위 레벨 설정으로부터 하위 레벨 설정까지를 포함할 수 있다. 706에서, 최소한의 사용자 상호작용으로 적절한 설정이 자동적으로 구성된다.

도 8은 데이터 관리 제품을 구성하는 방법(800)을 나타낸 것이다. 방법(800)이 시작되고, 802에서, 정보의 수신에서, 이러한 정보는 대상, 정책, 패싯, 제약조건은 물론 데이터 관리 제품에 관한 기타 정보를 포함할 수 있다. 패싯은 "gets" 및 "sets"을 가질 수 있다. 제약조건은 패싯을, 예를 들어, 부울값으로 평가할 수 있다. 제약조건마다 하나의 패싯이 있을 수 있고 정책마다 하나의 제약조건이 있을 수 있다. 정책은 검사, 구성, 시행, 기타 등등의 거동을 갖는다. 804에서, 설정 및/또는 애플리케이션 간의 유사성이 설정된다.

806에서, 선언형 언어로 표현될 수 있는 의도가 수신된다. 808에서, 정책을 대상 집합에 매핑하는 정책 연계가 수행된다. 정책이 평가될 때, 이메일 또는 이벤트 로그 엔트리 등의 동작이 트리거될 수 있다. 어떤 실시예에서, 정책이 일정표에 따라 평가될 수 있다. 810에서, 제약조건 또는 위반이 평가될 수 있다. 위반이 있는 경우, 812에서, 대상 또는 정책을 수정하는 것 등의 적절한 조치가 취해질 수 있다. 814에서, 모니터링 및 보고 기능이 제공되고, 810에서 위반이 발견되었는지 여부가 보고될 수 있다.

개시된 실시예들을 바탕으로 하여, 다양한 예시적인 사용자 인터페이스 및 기능 시나리오가 제공된다. 인터페이스 컴포넌트에 의해 사용자 인터페이스가 제공될 수 있다. 예를 들어, 인터페이스 컴포넌트는 그래픽 사용자 인터페이스(GUI), 명령줄 인터페이스, 기타 등등을 제공할 수 있다. 예를 들어, 사용자에게 하나 이상의 의도, 정책 또는 대상의 로드, 가져오기, 읽기, 기타 등등을 하는 영역 또는 수단을 제공하는 GUI가 렌더링될 수 있고, 이러한 것들의 결과를 제시하는 영역을 포함할 수 있다. 이들 영역은 대화 상자, 정적 컨트롤, 드롭-다운 메뉴, 리스트 박스, 팝업 메뉴, 편집 컨트롤, 콤보 박스, 라디오 버튼, 체크 박스, 푸시 버튼, 및 그래픽 박스를 포함하는 기지의 텍스트 및/또는 그래픽 영역을 포함할 수 있다. 그에 부가하여, 순회를 위한 수직 및/또는 수평 스크롤바 등의 정보 전달을 용이하게 해주는 유틸리티가 제공될 수 있고, 영역이 보이게 되는지를 결정하는 도구 모음 버튼이 이용될 수 있다. 예를 들어, 사용자는 편집 컨트롤에 정보를 입력하는 것으로 시스템과 상호작용할 수 있다.

사용자는 또한, 예를 들어, 마우스, 롤러 볼, 키패드, 키보드, 펜 및/또는 음성 작동 등의 다양한 장치를 통해 정보를 선택 및 제공하기 위해 영역들과 상호작용할 수 있다. 통상적으로, 푸시 버튼 또는 키보드 상의 엔터 키 등의 메카니즘은 정보를 입력한 후에 정보 전달을 개시하기 위해 이용될 수 있다. 그렇지만, 개시된 실시예들이 그렇게 제한되지 않는다는 것을 잘 알 것이다. 예를 들어, 체크 박스를 단지 하이라이트하는 것만으로 정보 전달을 개시할 수 있다. 다른 예에서, 명령줄 인터페이스가 이용될 수 있다. 예를 들어, 명령줄 인터페이스는 텍스트 메시지를 제공함으로써 (예를 들어, 디스플레이 상의 텍스트 메시지 및 오디오 톤에 의해) 사용자에게 정보를 넣도록 프롬프트할 수 있다. 사용자는 이어서 인터페이스 프롬프트에 제공된 옵션 또는 프롬프트에 제기된 질문에 대한 대답에 대응하는 영숫자 입력 등의 적당한 정보를 제공할 수 있다. GUI 및/또는 API와 관련하여 명령줄 인터페이스가 이용될 수 있다는 것을 잘 알 것이다. 그에 부가하여, 제한된 그래픽 지원 및/또는 낮은 대역폭 통신 채널을 갖는 하드웨어(예를 들어, 비디오 카드) 및/또는 디스플레이(예를 들어, 흑백 및 EGA)와 관련하여 명령줄 인터페이스가 이용될 수 있다.

이제 도 9를 참조하면, 사용자 인터페이스의 예시적인 스크린 샷이 도시되어 있다. 정책 또는 제약조건을 검색 및 선택하는 것을 용이하게 해줄 수 있는 객체 브라우저(object browser)(900)가 도시되어 있다. 객체 브라우저(900)는 사용자가 정책 또는 제약조건의 파라미터를 조작하는 다양한 선택을 제공할 수 있다. Database(s)(904), Security(906), Server Object(s)(908), Replication(910), Management(912), Notification Service(s)(914), Server Agent(916), 및 기타 원하는 서브디렉토리 등의 서브디렉토리를 포함하는 디렉토리(902)가 선택될 수 있다. 각각의 서브디렉토리(904-916)는, 각각의 서브디렉토리(904-916)의 측면에 있는 플러스 "+" 기호(디렉토리가 확장가능함을 나타냄)로 나타낸 바와 같이, 추가의 서브디렉토리를 가질 수 있다. 선택된 디렉토리 옆에 마이너스 "-" 기호(디렉토리가 축소되거나 역확장(unexpand)될 수 있음을 나타냄)로 나타낸 바와 같이, 관리 서브디렉토리(912)가 선택된다.

Management 서브디렉토리(912) 아래에 Policy 1(920), Poilcy 2(922) 및 Policy N(924)(단, N은 0보다 크거나 같은 수임) 등의 다수의 정책들을 포함할 수 있는 Policies 서브디렉토리(918)가 있을 수 있다. Management 서브디렉토리(912)는 또한 Constraint 1(928), Constraint 2(930), 및 Constraint N(932)(단, N은 0보다 크거나 같은 수임) 등의 다수의 제약조건들을 포함할 수 있는 Constraints 서브디렉토리(926)를 포함할 수 있다.

다양한 실시예들에 따라 하나의 서버가 자동화된 방식으로 관리될 수 있다. 정책 연계, 연계, 제약조건, 또는 패싯(예를 들어, 노드)에 대해 다양한 동작(예를 들어, 보기, 생성, 편집, 삭제, 적용, 가져오기, 기타 등등)을 수행하기 위해, 사용자는 객체 브라우저(900)에서의 드롭다운 리스트로부터 원하는 항목을 선택할 수 있다. 노드를 하이라이트하고 마우스 우측 버튼(또는 동등한 기능)을 사용하여 원하는 동작을 선택함으로써 대상 노드가 선택될 수 있다.

예를 들어, 정책 연계에 대해 다양한 동작을 수행하기 위해, 사용자는 노드를 선택할 수 있다(예를 들어, 노드를 하이라이트하고 마우스 우측 버튼을 누를 수 있다). 드롭다운 메뉴 및 링크로부터, "policy binding property"(정책 연계 속성) 창 또는 화면을 호출하기 위해 "policy binding management"(정책 연계 관리) 등이 선택될 수 있다. 정책 연계를 보기 위해, "deployed policies"(배포된 정책) 탭이 선택될 수 있다(예를 들어, 마우스 버튼으로 클릭됨). deployed policies는 사용자가 노드 또는 그의 자손에 배포된 정책 연계를 볼 수 있게 해준다. 노드에 대한 효과적인 정책 연계를 보기 위해, 사용자는 "policy binding management" 드롭다운 메뉴로부터 "effective policies"(효과적인 정책) 탭을 선택할 수 있다.

"policy binding management" 드롭다운 메뉴는 또한 사용자가 정책 연계를 생성, 편집 또는 삭제할 수 있게 해준다. 정책 연계를 생성하기 위해, "Policy Binding Properties"(정책 연계 속성) 창 또는 사용자 화면을 호출할 수 있는 "New" 버튼이 선택된다. 정책이 콤보 박스로부터 선택될 수 있고, 원하는 경우, 스케쥴이 선택될 수 있다. 선택된 정책 연계를 생성하기 위해, 사용자는 변경을 수락할 수 있다(예를 들어, "OK" 버튼을 클릭함).

정책 연계를 편집하기 위해, 편집할 정책 연계가 선택(예를 들어, 하이라이트)될 수 있고, 편집을 위한 "Policy Binding Properties" 창을 열기 위해 "Edit" 버튼이 선택(클릭)될 수 있다. 정책 연계를 삭제하기 위해, 삭제될 정책 연계가 선택(하이라이트)될 수 있다. 선택된 정책 연계를 삭제하기 위해, "Delete" 버튼이 클릭 또는 선택될 수 있다.

도 10은 정책을 적용하기 위한 예시적인 사용자 인터페이스를 나타낸 것이다. 임시 관리에서, 객체 브라우저(900)에서 또는 등록된 서버창에서 대상 노드를 선택함으로써 정책이 적용될 수 있다. 정책 적용 창(1000)을 호출하기 위해, 드롭다운 메뉴로부터 "Apply Policy"(정책 적용)이 선택될 수 있다.

로드된 정책(1002)을 선택할지 또는 정책 파일(1004)을 선택할지의 결정이 행해지고 원하는 동작이 선택될 수 있다. 도시된 바와 같이, 로드된 정책(1002)이 선택된다. 정책들의 리스트(1006)로부터 특정의 정책을 선택하거나 파일(1008)을 지정하기 위한 드롭다운 메뉴가 제공될 수 있다. Apply 또는 OK 버튼(1010)을 선택하거나 클릭하면 정책이 적용될 수 있다. Cancel(1012) 버튼을 선택하면 전체 동작이 취소되고 Apply Policy 창(1000)이 닫힌다.

정책들과 관련하여 동작들(예를 들어, 보기, 생성, 편집, 삭제, 가져오기)을 수행하기 위해, 객체 브라우저(900)로부터 정책이 선택될 수 있고, 마우스 우측 버튼을 클릭함으로써 호출되는 드롭다운 메뉴로부터 적절한 동작이 선택될 수 있다. "New"를 선택하면 "Policy Properties" 창이 호출된다. 정책을 편집하기 위해, 원하는 버튼이 선택될 수 있고, 콤보 박스로부터, 원하는 제약조건이 선택될 수 있거나, 새로운 제약조건이 생성될 수 있다. 변경을 수락하기 위해, Accept 또는 OK 버튼이 선택(예를 들어, 클릭)될 수 있다.

정책을 삭제하기 위해, 정책이 선택(예를 들어, 우측 클릭)되고, 드롭다운 메뉴로부터 "Delete"가 선택된다. 정책을 가져오기 위해, 드롭다운 메뉴로부터 "Import"가 선택되어 "Import Policy" 창을 호출한다. 원하는 정책 파일이 선택되고, "OK" 버튼이 선택된다.

유사한 방식으로 제약들에 대해 동작들이 수행될 수 있다. 객체 브라우저(900)로부터, 제약조건이 선택된다. 제약조건을 생성하기 위해, 드롭다운 메뉴로부터 "New"가 선택되어 "Constraint Properties" 창을 호출한다. 원하는 관리 패싯이 선택되고, 새로운 표현식 행을 추가하기 위해 "New" 버튼이 클릭된다. 표현식 행에 대해, "property operator value"(속성 연산자 값) 표현식이 작성된다. 행을 삭제하기 위해, 표현식 행이 하이라이트되고, "Delete" 버튼이 눌러진다. "OK" 버튼을 클릭하면 창을 닫는다.

"Constraint Properties" 창을 호출함으로써 제약조건이 편집될 수 있다. 다른 관리 패싯이 선택될 수 있다. "New" 버튼을 클릭하면 새로운 표현식 행이 추가된다. 표현식 행이 상기한 바와 같이 유사한 방식으로 삭제될 수 있다. 표현식 행에 대해, 사용자가 속성, 연산자, 및 값을 편집할 수 있다. "OK" 버튼을 선택하면 변경이 전송된다.

도 11은 정책 속성에 대한 예시적인 사용자 인터페이스(1100)를 나타낸 것이며, 이 경우 정책은 "highSecurity"이다. 사용자 구성가능 이름(1102)은 물론 정책에 대한 설명(1104)이 선택되거나 입력될 수 있다. 드롭다운 메뉴(1106)로부터 동작이 선택될 수 있다. 이러한 동작은 새로운 정책을 생성하는 것, 정책을 편집하는 것, 정책을 삭제하는 것, 기타 등등을 포함할 수 있다. 드롭다운 제약조건 리스트(1108)로부터 제약조건이 선택될 수 있다. 상태 인터페이스를 포함하는 드롭다운 리스트(1110)가 각각의 패싯에 대해 이용가능하다. 제약조건(1108) 및 패싯(1110)은 적절한 동작에 대해서만 인에이블되어야 한다. 새로운 제약조건(1108) 또는 패싯(1110)을 추가하기 위해 New 버튼(1112)이 선택될 수 있다.

정책의 소유자(1114), 생성 일자(1116), 및 마지막 수정된 날짜(1118)을 비롯한 다양한 다른 유형의 정보가 포착될 수 있다. 사용자는 동작을 삭제하기 위해 Cancel(1120)를 선택하고 창(1100)을 닫을 수 있다. OK 버튼(1122)을 선택하면 현재의 변경이 수락되고 창(1100)이 닫혀진다.

도 12는 제약조건 속성에 대한 예시적인 사용자 인터페이스(1200)를 나타낸 것이다. 이 인터페이스는 명명 수단(1202) 또는 제약조건을 선택하는 수단을 제공할 수 있다. 패싯의 리스트를 포함하는 드롭다운 메뉴로부터 관리 패싯(1204)이 선택될 수 있다. 사용자가 각각의 제약조건에 대해 다양한 속성(1206), 연산자(1208) 및 값(1210)을 선택할 수 있게 해주는 테이블 또는 리스트가 제공될 수 있다. 드롭다운 메뉴로부터 또는 테이블에 정보를 직접 입력함으로써 이러한 선택이 행해질 수 있다. 이 테이블은 속성의 편집, 추가 및 삭제를 가능하게 해주어야 한다. 사용자는 동작들을 삭제하고 창(1200)을 닫기 위해 Cancel(1212)을 선택할 수 있다. OK 버튼(1214)을 선택하면 현재의 변경이 수락되고 창(1200)이 닫힌다.

도 13은 제약조건 속성에 대한 사용자 인터페이스(1300)의 다른 예시적인 스크린 샷을 나타낸 것이다. 속성 이름(1302), 소유자 이름(1304), 설명(1306), 생성된 날짜(1308) 및 마지막 수정된 날짜(1310)가 시스템에 의해 제공되거나 정의될 수 있으며, 어떤 실시예들에 따르면, 사용자가 이들 필드를 수정할 수 없다. 제약조건 리스트 테이블(1312)로부터, 사용자는 제약조건 이름(1314), 상태 인터페이스(1316), 및 제약조건 ID(1318)를 선택 및 정의할 수 있다. 사용자는 적절한 동작 버튼(1320, 1322, 1324)을 선택함으로써 새로운 제약조건을 생성하거나, 제약조건을 편집하거나, 제약조건을 삭제할 수 있다.

도 14는 원자적 제약조건 속성(atomic constraint properties)에 대한 예시적인 사용자 인터페이스(1400)를 나타낸 것이다. 제약조건 이름(1402)가 선택될 수 있고, 상태 인터페이스(1404)의 리스트를 포함하는 드롭다운 메뉴로부터 상태 인터페이스가 선택될 수 있다. 사용자가 각각의 제약조건에 대해 다양한 속성(1406), 연산자(1408) 및 값(1410)을 선택할 수 있게 해주는 테이블 또는 리스트가 제공될 수 있다. 드롭다운 메뉴로부터 또는 테이블에 정보를 직접 입력함으로써 이러한 선택이 행해질 수 있다.

도 15는 정책 속성에 대한 사용자 인터페이스(1500)의 예시적인 스크린 샷을 나타낸 것이다. 속성 이름(1502), 소유자 이름(1504), 설명(1506), 생성된 날짜(1508), 및 마지막 수정된 날짜(1510) 등의 필드가 시스템에 의해 정의될 수 있고, 어떤 실시예들에 따르면, 사용자가 이들 필드를 수정할 수 없다. 드롭다운 동작 리스트(1512)로부터 동작이 선택될 수 있다. 제약조건 리스트 테이블(1514)로부터, 사용자는 제약조건 이름(들)(1516), 상태 인터페이스(들)(1518) 및 제약조건 ID(들)(1520)를 선택 및 정의할 수 있다. 사용자는 적절한 동작 버튼(1522, 1524, 1526)을 선택함으로써 새로운 정책을 생성하거나, 정책을 편집하거나, 정책을 삭제할 수 있다.

도 16은 정책 실행 보고서를 디스플레이(또는 인쇄)하는 예시적인 사용자 인터페이스(1600)를 나타낸 것이다. 정책 실행 이력을 디스플레이(또는 인쇄)하기 위해 유사한 사용자 인터페이스가 이용될 수 있다. 위반의 날짜 및 시간 등의 날짜(1602)가 포함되어 있다. 또한, 정책의 ID(1604) 및 정책 이름(1606)이 제공된다. 결과(1608)도 디스플레이되고, 위반 등에 대한 결과에 주의를 끌기 위해 다른 컬러(적색 등)로 디스플레이될 수 있다. 다른 결과들로는 정책에의 부합성, 정책에 대한 변경, 기타 등등이 있을 수 있다. 결과에 관련되어 있을 수 있는 메시지(1610)도 제공될 수 있다. 다수의 정책을 서로 다른 정렬 순서로 디스플레이하기 위해 임의의 컬럼(1602-1608) 상의 리스트가 정렬될 수 있다.

이제 도 17을 참조하면, 예시적인 정책 사례 관리의 사용자 인터페이스(1700)이 나타내어져 있다. 이 인터페이스는 "Policy Deployment" 메뉴를 선택함으로서 호출될 수 있다. 사용자 인터페이스(1700)는 동작(들)(1704)(예를 들어, 부합성 검사, 부합성 수정, ...)을 보고 선택하기 위한 테이블(1802)을 포함할 수 있다. 상태(1706)도 수정하거나 볼 수 있다. 각각의 정책(1708)에 대해, 사용자 정의되거나 다른 스케쥴링 기준에 기초할 수 있는 스케쥴(1710)이 선택될 수 있다. 사용자가 주어진 정책(1708)에 대해 다양한 동작을 수행할 수 있게 해주기 위해 스케쥴의 이력(1712)을 볼 수 있다.

도 18은 배포된 정책 속성에 대한 예시적인 사용자 인터페이스(1800)를 나타낸 것이다. 인터페이스(1800)는 정책을 선택하기 위한 드롭다운 메뉴(1802)를 포함할 수 있다. 스케쥴의 드롭다운 리스트(1804)로부터 스케쥴도 선택될 수 있다. 제약조건의 이름(1806), 동작(1808), 대상 집합(1810), ID(1812), 소유자 이름(1814), 설명(1816), 생성된 날짜(1818), 마지막 수정된 날짜(1820), 및 정책이 마지막으로 실행된 날짜(1822) 등의 다양한 다른 필드가 자동적으로 입력될 수 있다.

사용자는 체크 박스(1824)를 선택함으로써 모든 자손들을 재귀적으로 검사할지를 선택할 수 있다. 이러한 선택은 정책의 동작이 일정표에 따라 검사하는 것일 때 보여져야만 한다. 사용자는 또한 정책이 인에이블(1826)되는지 여부를 선택할 수 있다. 이 체크 박스가 체크되어 있지 않은 경우, 정책이 디스에이블된다. 이 화면으로부터 보고 이력(1828)을 볼 수 있으며, 이 보고 이력(1828)은 추가의 분석을 위해 인쇄 또는 저장될 수 있다.

도 19는 정책 사례를 적용하기 위한 예시적인 사용자 인터페이스(1900)를 나타낸 것이다. "apply policy instance" 등의 동작을 선택하면 이 사용자 인터페이스(1900)를 호출할 수 있다. 로드된 정책(1902)을 선택할지 또는 정책 파일(1904)을 선택할지의 결정이 행해지고, 원하는 동작이 선택될 수 있다. 도시된 바와 같이, 로드된 정책(1902)이 선택된다. 동작들의 리스트(1906)로부터의 동작(예를 들어, 검사 또는 시행)을 선택하기 위한 드롭다운 메뉴가 제공될 수 있다. 체크 박스(1908)는 모든 자원에 대한 재귀적 검사를 인에이블시킬 수 있다. 대상 집합 위치(1910)가 시스템에 의해 제공될 수 있다. Apply 또는 OK 버튼(1912)을 선택 또는 클릭하면 정책을 적용할 수 있다. Cancel(1914) 버튼을 선택하면 전체 동작을 취소하고 정책 사례 적용 창(1900)을 닫는다.

도 20은 다중-서버 관리에서 이용될 수 있는 서버 속성들에 대한 예시적인 사용자 인터페이스(2000)를 나타낸 것이다. 대상 노드를 우측 클릭함으로써 관리 패싯을 볼 수 있다. 드롭다운 메뉴에서 "Properties"를 선택하면 "Properties" 창을 호출한다. 관리 패싯이, 예를 들어, 좌측 창(2002)에 열거될 수 있다. 패싯을 클릭하면 사용자가 그의 현재 상태를 볼 수 있고, 관리 패싯은 판독가능 이름에 대한 속성들을 가질 수 있다.

관리 패싯의 상태를 정책 파일로 추출하기 위해, "Properties" 창(2000)이 열리고 패싯이 선택된다. "Extract to policy" 버튼(2004)을 클릭하면 상태를 정책 파일로 내보낸다. 정책 연계를 가져오기 위해 유사한 버튼이 이용될 수 있다. 배포된 정책(2006) 또는 효과적인 정책(2008)을 볼 지의 선택이 행해질 수 있다. Deployed policies(2006) 탭은 사용자가 노드에 또는 그의 자손에 배포된 정책 연계를 볼 수 있게 해준다.

원하는 파일 이름이 대화 상자에 입력될 수 있다. "Save" 버튼은 변경을 저장하고 창을 닫는다. "Properties" 창을 통해 패싯에 대한 정책 연계를 볼 수 있고, "Deployed Policy Bindings" 탭을 클릭하면 노드 및 패싯에 대해 배포된 정책 연계를 볼 수 있다. "Effective Policy Bindings" 탭을 클릭하면 사용자가 노드 및 패싯에 대한 효과적인 정책 연계를 볼 수 있다.

도 21은 다중-서버 관리에서 이용될 수 있는 서버 속성들에 대한 다른 예시적인 사용자 인터페이스(2100)이다. 사용자 인터페이스(2100)는 상기 도면에 나타낸 사용자 인터페이스와 유사하다. 배포된 정책(2102)이 선택되면, 사용자는 동작을 수행하기 위한 다양한 버튼을 제공받는다. 배포된 정책은 내보내기(2104)될 수 있다. 적절한 버튼(2106, 2108, 2110)을 선택함으로써 새로운 정책이 생성될 수 있거나, 기존의 정책이 편집 또는 삭제될 수 있다.

다양한 특징들을 설명하기 위해 여러가지 시나리오가 제공된다. 이하는 관리 패싯을 통합하는 예이다. 관계형 서버에 접속하고 이 서버를 방문하여 OBD 패싯의 상태를 본다. 이 상태가 정책으로서 내보내기될 수 있다. 사용자는 다른 서버로 가서(또는 다른 서버를 열고) 정책을 평가(예를 들어, 위반을 조사)할 수 있다. 서비스에 대해 정책이 시행될 수 있다. SSMS(SQL Server Management Studio)로부터 서버 그룹을 명시적으로 검사하기 위해, 사용자는 등록된 서버 창을 방문하고 그룹에 대해 OBD(Off-By-Default) 정책을 체크할 수 있다. 보고서가 결과와 함께 제시될 수 있고 그룹에 대해 정책이 시행될 수 있다.

OBD 정책을 서버로 가져오기하고 OBD 정책 노드를 방문함으로써 스케쥴링된 검사를 통한 자동화가 제공될 수 있다. 동작이 "Check on schedule"(일정표에 따라 검사)인지를 알아보기 위해 OBD 정책의 속성을 볼 수 있다. 정책이 배포되고, 스케쥴링된 검사와의 연계가 생성된다. 보고서(들)가 검사된다. 서버의 관리 패싯 상태가 변경될 수 있고, 보고서가 검사될 수 있다.

명명 정책은 데이터베이스와 대조하여 검사될 수 있는 이름 프리픽스(name prefix)에 대한 정책을 생성하는 것을 포함할 수 있다. 정책이 배포될 수 있고, "시행" 연계가 생성될 수 있다. 서버에서 변경이 행해질 수 있고, 정책이 이 변경을 방지할 수 있다. BPA 정책은 SSMS에 PBA 규칙(검사)을 포함시킬 수 있다.

확장성 및 성능이 (그룹 정책에 대한) 데이터-위주의 정책 연계로부터의 확장성을 포함할 수 있다. 하나의 서버에 2개의 정책이 배포될 수 있다(예를 들어, 일정표에 따른 검사를 갖는 OBD 정책, 시행을 갖는 명명 정책). 하나의 서버로부터의 정책 및 연계가 다른 서버에 복제될 수 있다. 정책 연계가 제2 서버에서 효과적인지를 알아보기 위해(예를 들어 OBD 설정을 변경하고 위반 보고서를 보기 위해, 서버에서 변경을 하기 위해 및 명명 정책이 변경을 방지하는지를 결정하기 위해) 검사될 수 있다. 제1 서버에 대해 변경된 정책이 제2 서버에 효과가 있는지 관찰될 수 있다.

내보내기/가져오기 연계로부터의 확장성: 일정표에 따른 검사를 갖는 OBD 정책 및 시행을 갖는 명명 정책 등의 하나의 서버에 2개의 정책을 배포한다. 그 다음에, 서버 노드로부터 정책 연계 정보 파일을 내보내기한다. 다른 서버로 가서 정책 연계 파일을 가져오기한다. 정책 연계가 제2 서버에서 효과적인지를 검사한다, 예를 들어, OBD 설정을 변경하고 위반 보고서를 보며 및/또는 서버에서 변경을 하고 명명 정책이 변경을 방지한다는 것을 보여준다.

도 22는 예시적인 시스템 라이프사이클(2200)을 나타낸 것이다. 개시된 기법은 관리 의도를 시스템이 해석할 수 있는 논리 레벨에서 상위-레벨 정책으로서 포착할 수 있다. 확장가능한 관리는 시스템이 많은 애플리케이션, 인스턴스 및/또는 서버에 정책을 적용할 수 있게 해준다. 자체-관리에 의해 문제 검출을 할 수 있으며, 그 결과 자동화된 관리가 얻어진다. 따라서, 이 시스템은 분별있는 기본 정책을 이용가능하게 해줄 수 있다. 일관성있는 통합된 관리 기반구조는 모든 데이터 관리 제품(예를 들어, SQL) 서비스를 일률적으로 관리할 수 있다. 이는 또한 하위 레벨에서 동작할 수 있어, 예를 들어, SQL Server 2000 및 SQL Server 2005 서버들에 대한 관리 기능을 지원한다. 이는 또한 MOM, DSI(Dynamic Systems Initiative), Visual Studio, 기타 등등을 비롯한 다른 기술들과 통합될 수 있다. 이는 또한 빠른 문제 해결을 위한 심도있는 진단 및 도구를 지원할 수 있으며, 따라서 지원성에 맞춰 조정될 수 있다.

상부 부분은 서비스 라이프사이클(2202)을 나타낸 것이고, 하부 부분은 애플리케이션 라이프사이클(2204)을 나타낸 것이다. 이들은, 예를 들어, 운영 체제(2206) 및 서버 인스턴스(2208)를 나타낼 수 있다. 개발 및 배포에 의해 구성에 이른다. 시스템이 모니터링되고, 있는 경우, 문제점들이 발견되며, 시스템이 유지된다. 이것에 의해 보고, 감사 및 부합이 얻어질 수 있다.

데이터 관리 제품(예를 들어, SQL 서버)을 구성하기 위해 정책이 이용될 수 있다. 예를 들어, T-SQL 스크립트를 작성하는 대신에, 초기 구성을 수행하기 위해 정책이 사용될 수 있다. 정책은 특정의 구성과 대조하여 서버 구성을 검사할 수 있다. 그 자체로서, 서버 구성에 대한 모범 사례를 나타내는 정책이 발표될 수 있고, 사용자는 그의 환경을 기준(모범 사례) 정책과 비교할 수 있다. 정책 이벤트의 특별한 처리는 물론 확장된 선언형 관리가 제공될 수 있다.

이하의 예시적인 정책들은 단지 예로서 포함된 것에 불과하다.

종래의 데이터베이스 애플리케이션은, 예를 들어, 데이터베이스 및 클라이언트 API와 인터페이스하는 클라이언트 기계를 포함한다. 이 애플리케이션은 데이터베이스 스키마에 연결되어 있고, 여기서 이 애플리케이션은 행 및 테이블 또는 내장된 SQL로 간주된다. 종래에, 데이터 서비스는 애플리케이션에서의 유효성 확인 및 제약조건 시행으로 제한되었다(예를 들어, get, put, delete, query). 클라이언트-서버 아키텍처에서, 애플리케이션은 보통 데이터베이스와 연결되어 있다. 개시된 실시예들은 다중-계층의 분산되고 분리된 모바일 시스템을 제공할 수 있다. 이는 장치, 데스크톱(컴퓨터), 서버, 클러스터, 클라우드와 관련하여 분산되어 있다. 데이터가 계층을 가로질러 이동될 수 있고 애플리케이션 가까이에서 처리된다. 다수의 데이터 소스로부터의 데이터가 연합될 수 있다. 이는 때때로 애플리케이션에 연결될 수 있다. 개시된 실시예들은 더 풍부한 유형의 데이터 및 더 높은 데이터 추상화를 제공할 수 있다. 이는 또한 동적 데이터(예를 들어, 비지니스 처리 상태, 메시지, 및 비지니스 규칙)를 제공할 수 있다.

이하는 개시된 실시예들의 어떤 요소들을 열거한 것이다. 다중-계층, 분리(때때로 연결), 분산, SOA 기반(예를 들어), 개방, 상호연동, 장치, 테이블, 데스크톱, 서비스, 동적(데이터, 애플리케이션 이동성), 다중 데이터 소스, 정보 기반, 모델 위주, 컴포넌트화, 맞춤화가능 및 적응가능.

개시된 실시예들은 4개의 추상화 레벨, 즉 물리 레벨, 논리 레벨, 개념 레벨, 프로그래밍 또는 프리젠테이션 레벨을 가질 수 있다. 물리 레벨은 기록 형식, 파일 범위, 파일 그룹, 인덱스, 및 파일 파티션을 말한다. 애플리케이션은 물리 레벨을 인식하지 못한다. 논리 레벨은 테이블, 키, PK/FK 제약조건, 정규화, 물리 데이터 독립성, 관계 애플리케이션을 포함한다. 개념 레벨은 개체, 관계, 제약조건, 장래의 애플리케이션에서의 천이, 데이터 플랫폼에 대한 대상 모델을 포함한다. 프로그래밍 또는 프리젠테이션 레벨은 범용 프로그래밍 모드를 갖지 않는다. 이는 개체값, 객체, XML을 포함하며, 대부분의 애플리케이션이 이들 간에 변환을 해야 한다.

사용자가 데이터베이스 애플리케이션을 생성할 때, 사용자는 데이터베이스 내에 객체들을 생성하고 또한 서버 레벨에서 객체를 생성할지도 모른다. 데이터베이스는 테이블(들) 및 다양한 객체를 포함할 수 있으며, 다수의 데이터베이스를 가질 수 있는 서버일 수 있다. 테이블 및 뷰가 데이터베이스에 포함되어 있다. 서버 레벨에서 객체들도 존재할 수 있다. 사용자는 그 자신의 맞춤 서버 에러 메시지를 생성할 수 있거나, 예를 들어, 서버 레벨인 SQL 서버에서 생성할 수 있다. 개시된 실시예들은 사용자에게 서버의 시스템 또는 애플리케이션 뷰를 획득하는 수단을 제공한다. 이 뷰는 서버가 하나의 데이터베이스를 갖는지, 하나의 특정 애플리케이션에 속할지도 모르는 다수의 데이터베이스를 갖는지, 또는 동일한 데이터베이스 내의 객체들을 갖는 다수의 애플리케이션을 갖는지에 상관없이 제공될 수 있다.

사용자는 인터페이스 컴포넌트 등을 통해 (예를 들어, 렌더링 컴포넌트를 사용하여) 애플리케이션 "A"의 서버를 보기 위해 요청을 할 수 있고, (예를 들어, 선언형 관리 컴포넌트를 사용하여) 애플리케이션 "A"에 대해 정책이 생성될 수 있다. 예를 들어, 사용자는 애플리케이션 "A"에 대한 모든 데이터베이스 테이블이 AppA_로 시작하도록 요청을 한다. 새로운 테이블이 생성되는 경우, 테이블이 AppA_로 시작하는 것을 규정하는 정책이 시행되어 새로운 테이블에 적용된다. 시스템은 자동적으로 하나의 데이터베이스든지 2개 이상의 데이터베이스든지 간에 데이터베이스에 배포를 수행한다. 따라서, 사용자 상호작용의 양을 최소화시킨다.

이제 도 23을 참조하면, 예시적인 시스템(2300)이 도시되어 있다. 시스템은 코어 비지니스 논리(2304)를 포함하는 애플리케이션(2302)을 포함한다. 순회/질의(2306)는 데이터 관리 서비스일 수 있다. 데이터 매핑 서비스는 비지니스 객체(2308) 및 오프라인/동기화 지원(2310)일 수 있다. 저장소 인터페이스(2312)도 제공된다. 애플리케이션은 개체로 거래되고, 애플리케이션에 많은 데이터 매핑 솔루셩이 있다. 애플리케이션이 그 자신의 순회/질의/변환 정보를 기입할 수 있는 임피던스 부정합이 제공된다.

이제 도 24를 참조하면, 데이터베이스(2402), 클라이언트 API(2404), BCP(2406) 및 애플리케이션(2408)을 포함하는 예시적인 관리 도구가 도시되어 있다. 데이터 관리 제품은 클라이언트 라이브러리, 데이터 유틸리티(예를 들어, BCP(2406)) 및 관리 도구를 포함하는 코어 관계 엔진일 수 있다. 각각의 서비스는 행 및 테이블을 전달할 수 있다.

도 25는 임시적으로 개체에 동작하는 데이터 서비스(예를 들어, 보고, 병합, 복제)를 제공하는 시스템(2500)을 나타낸 것이다. 저장/데이터 API(2502) 부분, 행/테이블/MDS 부분(2504) 및 개체 부분(2506)이 포함되어 있다. 시스템(2500)은 다양한 암시적인 및 명시적인 매핑 게층 및 매핑 설명을 제공한다.

데이터 플랫폼이 도 26에 도시되어 있다. 애플리케이션(2602)은 코어 비지니스 논리(2604)를 포함한다. 데이터 관리 서비스(예를 들어, 순회/질의)(2606)도 포함되어 있다. 값 데이터 서비스는 병합 복제(2608), SSAS(2610) 및 보고서 작성기(2612)는 물론 다른 컴포넌트도 포함하고 있다. 저장 인터페이스는 데이터베이스(2618)와 상호작용하는 ODBC(2614) 및 ADO.NET(2616)를 포함한다. 애플리케이션은 그의 DAL 계층에서 개체(예를 들어, 고객, 계정, 기타 등등)를 작성할 수 있다. 값 데이터 서비스(2608, 2610, 2612)는 개체에 작용할 수 있다(예를 들어, 독립적인 기술 방법을 가짐).

도 27은 애플리케이션(2701), 데이터 서비스(2704) 및 기타 항목(2706)을 포함하는 데이터 플랫폼(2700)을 나타낸 것이다. 데이터의 구조는 정의된 것(예를 들어, 개체)일 수 있다. 예를 들어, 용어 "Asset", "Customer", 및 "Account"는 정의된 다음에 개체 버스(entity bus) 전체에 걸쳐 사용될 수 있다. "Asset"을 정의하는 것, 공유점 자산 추적 애플리케이션을 빌드하는 것, 자산 상태를 갱신하기 위해 작업 흐름을 이메일 형태로 작성하는 것, 및 자산 상태의 보고서를 작성하는 것을 포함하는 데이터 서비스에서의 악순환이 제공될 수 있다. 회사 또는 기업 내의 또한 에코시스템 내의 다른 것들이 버스에 접속될 수 있다.

도 28은 데이터 플랫폼의 다양한 데이터 서비스를 나타낸 것이다. 이러한 서비스는 논리적(2802) 또는 개념적(2804)일 수 있다. 논리적 서비스(2802)는, 예를 들어, 트랜잭트 SQL일 수 있으며 이하의 형식을 취할 수 있고,

논리적 서비스(2804)는 개체 뷰 관리자일 수 있고 이하의 형식을 갖는 개체 SQL을 포함할 수 있다.

개념적 서비스(2804)는 개체 및 관계를 제공하는 개체 데이터 모델을 포함할 수 있다. 또한, 예를 들어, 확장된 관계 대수에 기초할 수 있는 개체 SQL이 제공된다. 개체 SQL은 개체를 생성 및 소비하여, 관계들에 걸친 양호한 순회를 제공할 수 있다. 개체 뷰 관리자는 개체 런타임을 제공할 수 있고 또 개념-논리 매핑을 제공할 수 있다.

이제 도 29를 참조하면, 데이터 플랫폼 아키텍처(2900)가 도시되어 있다. 이 플랫폼은 데이터베이스 미러링, VLDB는 물론 Native XML 지원을 제공할 수 있다. 또한, 다중-언어 프로그램성 및 확장성, 서버 보고, 기업 ETL, 및 심도있는 데이터 마이닝이 제공될 수 있다.

도 30은 예시적인 어댑터 다이어그램(3000)을 나타낸 것이다. 패싯(3002)이 속성 및 커밋 논리에 액세스하기 위한 디스패치 메서드를 포함할 수 있는 BaseFacet(3004) 등의 공통의 인터페이스로부터 도출될 수 있다. 각각의 패싯은 읽기 전용 또는 읽기/쓰기 속성일 수 있는 속성을 정의할 수 있다. 어댑터 클래스(3005)는 BaseFacet 인터페이스로부터 상속될 수 있고 기초를 이루는 객체 모델 클래스를 집계할 수 있다. 어댑터는 객체 모델 클래스(3008)(및 기타 논리)의 물리적 속성을 이용하여 패싯 속성을 노출시킬 수 있다.

이제 도 31을 참조하면, 개시된 아키텍처를 실행하는 동작을 하는 컴퓨터의 블록도가 도시되어 있다. 본 명세서에 개시된 다양한 측면들에 대한 부가의 상황을 제공하기 위해, 도 31 및 이하의 설명은 다양한 측면들이 구현될 수 있는 적당한 컴퓨팅 환경(3100)의 간략하고 전반적인 설명을 제공하기 위한 것이다. 하나 이상의 실시예가 일반적으로 하나 이상의 컴퓨터 상에서 실행될 수 있는 컴퓨터 실행가능 명령어와 관련하여 전술되어 있지만, 당업자라면 다양한 실시예들이 또한 기타 프로그램 모듈과 관련하여 및/또는 하드웨어와 소프트웨어의 조합으로서 구현될 수 있다는 것을 잘 알 것이다.

일반적으로, 프로그램 모듈은 특정의 태스크를 수행하거나 특정의 추상 데이터 유형을 구현하는 루틴, 프로그램, 컴포넌트, 데이터 구조, 기타 등등을 포함한다. 게다가, 당업자라면 본 발명의 방법이, 단일-프로세서 또는 멀티-프로세서 컴퓨터 시스템, 미니컴퓨터, 메인프레임 컴퓨터는 물론 퍼스널 컴퓨터, 핸드-헬드 컴퓨팅 장치, 마이크로프로세서-기반 또는 프로그램가능 가전 제품, 기타 등등(이들 각각은 하나 이상의 연관된 장치들과 연결되어 동작을 할 수 있음)을 비롯한, 다른 컴퓨터 시스템 구성에서 실시될 수 있다는 것을 잘 알 것이다.

예시된 측면들은 또한 어떤 태스크들이 통신 네트워크를 통해 연결되어 있는 원격 처리 장치들에 의해 수행되는 분산 컴퓨팅 환경에서 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈들은 로컬 및 원격 메모리 저장 장치 둘다에 위치될 수 있다.

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

통신 매체는 통상적으로 반송파(carrier wave) 또는 기타 전송 메커니즘(transport mechanism)과 같은 피변조 데이터 신호(modulated data signal)에 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터 등을 구현하고 모든 정보 전달 매체를 포함한다. "피변조 데이터 신호"는 신호 내에 정보를 인코딩하도록 그 신호의 특성들 중 하나 이상을 설정 또는 변경시킨 신호를 의미한다. 제한이 아닌 예로서, 통신 매체는 유선 네트워크 또는 직접 배선 접속(direct-wired connection)과 같은 유선 매체, 그리고 음향, RF, 적외선, 기타 무선 매체와 같은 무선 매체를 포함한다. 상술된 매체들 중 임의의 것의 조합도 역시 컴퓨터 판독가능 매체의 범위 안에 포함된다.

다시 도 31을 참조하면, 여러가지 측면들을 구현하는 예시적인 환경(3100)은 컴퓨터(3102)하고, 이 컴퓨터(3102)는 처리 장치(3104), 시스템 메모리(3106) 및 시스템 버스(3108)를 포함한다. 시스템 버스(3108)는 시스템 메모리(3106)(이에 한정되지 않음)를 비롯한 시스템 컴포넌트들을 처리 장치(3104)에 연결시킨다. 처리 장치(3104)는 여러가지 상업적으로 이용가능한 프로세서 중 어느 것이라도 될 수 있다. 듀얼 마이크로프로세서 및 기타 멀티프로세서 아키텍처도 역시 처리 장치(3104)로서 이용될 수 있다.

시스템 버스(3108)는 메모리 버스(메모리 컨트롤러를 갖거나 갖지 않음), 주변장치 버스, 및 다양한 상업적으로 이용가능한 버스 아키텍처 중 임의의 것을 사용하는 로컬 버스에 추가적으로 상호접속될 수 있는 몇가지 유형의 버스 구조 중 어느 것이라도 될 수 있다. 시스템 메모리(3106)는 판독 전용 메모리(ROM)(3110) 및 랜덤 액세스 메모리(RAM)(3112)를 포함한다. 기본 입/출력 시스템(BIOS)은 ROM, EPROM, EEPROM 등의 비휘발성 메모리(3110)에 저장되고, 이 BIOS는 시동 중과 같은 때에 컴퓨터(3102) 내의 구성요소들 간의 정보의 전송을 돕는 기본적인 루틴을 포함한다. RAM(3112)은 또한 데이터를 캐싱하기 위한 정적 RAM 등의 고속 RAM을 포함할 수 있다.

컴퓨터(3102)는 또한 내장형 하드 디스크 드라이브(HDD)(3114)(예를 들어, EIDE, SATA)(이 내장형 하드 디스크 드라이브(3114)는 적당한 섀시 내에서 외장용으로도 구성될 수 있음), 자기 플로피 디스크 드라이브(FDD)(3116)(예를 들어, 이동식 디스켓(3118)으로부터 판독을 하거나 그에 기록을 하기 위한 것임), 및 광 디스크 드라이브(3120)(예를 들어, CD-ROM 디스크(3122)를 판독하거나 DVD와 같은 다른 대용량 광 매체로부터 판독을 하거나 그에 기록을 하기 위한 것임)를 포함한다. 하드 디스크 드라이브(3114), 자기 디스크 드라이브(3116), 및 광 디스크 드라이브(3120)는 각각 하드 디스크 드라이브 인터페이스(3124), 자기 디스크 드라이브 인터페이스(3126), 및 광 드라이브 인터페이스(3128)에 의해 시스템 버스(3108)에 접속될 수 있다. 외장형 드라이브 구현에 대한 인터페이스(3124)는 USB(Universal Serial Bus) 및 IEEE 1394 인터페이스 기술 중 적어도 하나 또는 둘다를 포함한다. 다른 외장형 드라이브 접속 기술이 하나 이상의 실시예의 범위 내에 속한다.

이들 드라이브 및 이들과 연관된 컴퓨터 판독가능 매체는 데이터, 데이터 구조, 컴퓨터 실행가능 명령어, 기타 등등의 비휘발성 저장을 제공한다. 컴퓨터(3102)의 경우, 이들 드라이브 및 매체는 임의의 데이터를 적당한 디지털 형식으로 저장하는 것에 대응하고 있다. 컴퓨터 판독가능 매체의 상기 설명이 HDD, 이동식 자기 디스켓, 및 CD 또는 DVD 등의 이동식 광 매체를 언급하고 있지만, 당업자라면 zip 드라이브, 자기 카세트, 플래쉬 메모리 카드, 카트리지, 기타 등등의 컴퓨터에 의해 판독가능한 다른 유형의 매체도 예시적인 운영 환경에서 사용될 수 있으며, 또한 임의의 이러한 매체가 본 명세서에 개시된 방법들을 수행하는 컴퓨터 실행가능 명령어들을 포함할 수 있다는 것을 잘 알 것이다.

운영 체제(3130), 하나 이상의 애플리케이션 프로그램(3132), 기타 프로그램 모듈(3134) 및 프로그램 데이터(3136)를 비롯한 다수의 프로그램 모듈이 드라이브 및 RAM(3112)에 저장될 수 있다. 운영 체제, 애플리케이션, 모듈, 및/또는 데이터 전부 또는 그 일부분은 또한 RAM(3112)에 캐싱될 수 있다. 다양한 실시예들이 다양한 상업적으로 이용가능한 운영 체제 또는 운영 체제들의 조합에서 구현될 수 있다는 것을 잘 알 것이다.

사용자는 하나 이상의 유선/무선 입력 장치(예를 들어, 키보드(3138), 및 마우스(3140) 등의 포인팅 장치)를 통해 컴퓨터(3102)에 명령 및 정보를 입력할 수 있다. 다른 입력 장치(도시 생략)로는 마이크, IR 리모콘, 조이스틱, 게임 패드, 스타일러스 펜, 터치 스크린, 기타 등등이 있을 수 있다. 이들 및 다른 입력 장치들은 종종 시스템 버스(3108)에 연결되어 있는 입력 장치 인터페이스(3142)를 통해 처리 장치(3104)에 접속되지만, 병렬 포트, IEEE 1394 직렬 포트, 게임 포트, USB 포트, IR 인터페이스, 기타 등등의 다른 인터페이스에 의해 접속될 수 있다.

모니터(3144) 또는 기타 유형의 디스플레이 장치도 비디오 어댑터(3146) 등의 인터페이스를 통해 시스템 버스(3108)에 접속된다. 모니터(3144)에 부가하여, 컴퓨터는 통상적으로 스피커, 프린터, 기타 등등의 다른 주변 출력 장치(도시 생략)를 포함한다.

컴퓨터(3102)는 원격 컴퓨터(들)(3148) 등의 하나 이상의 원격 컴퓨터로의 유선 및/또는 무선 통신을 통한 논리적 접속을 사용하여 네트워크화된 환경에서 동작할 수 있다. 원격 컴퓨터(들)(3148)는 워크스테이션, 서버 컴퓨터, 라우터, 퍼스널 컴퓨터, 휴대용 컴퓨터, 마이크로프로세서-기반 오락 기기, 피어 장치, 또는 기타 통상의 네트워크 노드일 수 있으며, 통상적으로 컴퓨터(3102)와 관련하여 기술된 구성요소들 중 다수 또는 그 전부를 포함하지만, 간략함을 위해 메모리/저장 장치(3150)만이 도시되어 있다. 도시된 논리적 접속은 근거리 통신망(LAN)(3152) 및/또는 대규모 네트워크, 예를 들어, 원거리 통신망(WAN)(3154)에의 유선/무선 접속을 포함한다. 이러한 LAN 및 WAN 네트워킹 환경은 사무실 및 회사에서 흔하며, 인트라넷 등의 전사적 컴퓨터 네트워크를 용이하게 해주고, 이들 모두는 전세계적인 통신 네트워크, 예를 들어, 인터넷에 접속될 수 있다.

LAN 네트워킹 환경에서 사용될 때, 컴퓨터(3102)는 유선 및/또는 무선 통신 네트워크 인터페이스 또는 어댑터(3156)를 통해 로컬 네트워크(3152)에 접속된다. 어댑터(3156)는 LAN(3152)에의 유선 또는 무선 통신을 용이하게 해줄 수 있으며, 이 LAN에는 또한 무선 어댑터(3156)와 통신하기 위한 무선 액세스 포인트가 배치되어 있다.

WAN 네트워킹 환경에서 사용될 때, 컴퓨터(3102)는 모뎀(3158)을 포함할 수 있거나, WAN(3154) 상의 통신 서버에 연결되어 있거나, 인터넷 등의 WAN(3154)을 통해 통신을 설정하는 기타 수단을 가지고 있다. 내장형 또는 외장형 및 유선 또는 무선 장치일 수 있는 모뎀(3158)은 직렬 포트 인터페이스(3142)를 통해 시스템 버스(3108)에 연결된다. 네트워크화된 환경에서, 컴퓨터(3102) 또는 그의 일부분과 관련하여 기술된 프로그램 모듈은 원격 메모리/저장 장치(3150)에 저장될 수 있다. 도시된 네트워크 접속이 예시적인 것이며 컴퓨터들 간에 통신 링크를 설정하는 기타 수단이 사용될 수 있다는 것을 잘 알 것이다.

컴퓨터(3102)는 무선 통신으로 동작을 하는 임의의 무선 장치 또는 개체(예를 들어, 프린터, 스캐너, 데스크톱 및/또는 휴대용 컴퓨터, PDA, 통신 위성, 무선 검출가능 태그와 연관된 임의의 장비 또는 장소(예를 들어, 키오스크, 신문 가판대, 휴게실), 및 전화)와 통신하는 동작을 한다. 이것은 적어도 Wi-Fi 및 블루투스™ 무선 기술을 포함한다. 따라서, 통신은 종래의 네트워크에서와 같이 사전 정의된 구조이거나 단순히 적어도 2개의 장치 간의 애드혹 통신(ad hoc communication)일 수 있다.

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) 데이터 레이트로 동작하거나, 양 대역을 포함하는 제품이 있으며(듀얼 밴드), 따라서 네트워크는 많은 사무실에서 사용되는 lOBaseT 유선 이더넷 네트워크와 유사한 실세계 성능을 제공할 수 있다.

이제 도 32를 참조하면, 다양한 실시예들에 따른 예시적인 컴퓨팅 환경(3200)의 개략 블록도가 도시되어 있다. 시스템(3200)은 하나 이상의 클라이언트(들)(3202)를 포함한다. 클라이언트(들)(3202)는 하드웨어 및/또는 소프트웨어(예를 들어, 쓰레드, 프로세서, 컴퓨팅 장치)일 수 있다. 클라이언트(들)(3202)는, 예를 들어, 다양한 실시예들을 이용함으로써 쿠키(들) 및/또는 연관된 컨텍스트 정보를 가지고 있을 수 있다.

시스템(3200)은 또한 하나 이상의 서버(들)(3204)를 포함한다. 서버(들)(3204)도 역시 하드웨어 및/또는 소프트웨어(예를 들어, 쓰레드, 프로세스, 컴퓨팅 장치)일 수 있다. 서버(3204)는, 예를 들어, 다양한 실시예들을 이용함으로써 변환을 수행하는 쓰레드를 가지고 있을 수 있다. 클라이언트(3202)와 서버(3204) 간의 한가지 가능한 통신은 2개 이상의 컴퓨터 프로세스 간에 전송되도록 구성된 데이터 패킷의 형태로 되어 있을 수 있다. 데이터 패킷은, 예를 들어, 쿠키 및/또는 관련된 컨텍스트 정보를 포함할 수 있다. 시스템(3200)은 클라이언트(들)(3202)와 서버(들)(3204) 간의 통신을 용이하게 해주는 데 이용될 수 있는 통신 프레임워크(3206)(예를 들어, 인터넷 등의 전세계 통신 네트워크)를 포함한다.

통신이 유선(광 섬유를 포함함) 및/또는 무선 기술을 통해 용이하게 될 수 있다. 클라이언트(들)(3202)는 클라이언트(들)(3202)에 로컬인 정보(예를 들어, 쿠키(들) 및/또는 관련된 컨텍스트 정보)를 저장하는 데 이용될 수 있는 하나 이상의 클라이언트 데이터 저장소(들)(3208)와 연결되어 동작한다. 이와 유사하게, 서버(들)(3204)는 서버(3204)에 로컬인 정보를 저장하는 데 이용될 수 있는 하나 이상의 서버 데이터 저장소(들)(3210)에 연결되어 동작한다.

이상에서 기술된 것은 다양한 실시예들의 예를 포함하고 있다. 물론, 다양한 실시예들을 설명하기 위해 컴포넌트 및 방법의 모든 생각할 수 있는 조합을 기술할 수는 없지만, 당업자라면 많은 추가의 조합 및 치환이 가능하다는 것을 잘 알 것이다. 그에 따라, 본 명세서에서 의도하는 바는 첨부된 청구항의 정신 및 범위 내에 속하는 모든 이러한 변경, 수정 및 변형을 포함하는 것이다.

상세하게는, 상기한 컴포넌트, 장치, 회로, 시스템, 기타 등등에 의해 수행되는 다양한 기능과 관련하여, 이러한 컴퓨터(3102)를 기술하는 데 사용되는 용어("수단"이라고 말하는 것도 포함함)는, 달리 언급하지 않는 한, 기술된 컴포넌트의 지정된 기능(예를 들어, 기능상 등가물)을 수행하는 컴포넌트(구조적으로 개시된 구조와 동등하지는 않지만, 본 명세서에 설명된 예시적인 측면들에서의 기능을 수행함)에 대응하는 것으로 보아야 한다. 이와 관련하여, 또한 다양한 측면들이 시스템은 물론 다양한 방법의 동작 및/또는 이벤트를 수행하는 컴퓨터 실행가능 명령어들을 갖는 컴퓨터 판독가능 매체도 포함한다는 것을 잘 알 것이다.

그에 부가하여, 특정의 특징이 몇개의 구현들 중 단지 하나와 관련하여 기술되어 있을 수 있지만, 이러한 특징은 임의의 주어진 또는 특정의 응용에 요망되고 유익할 수 있기 때문에 다른 구현들의 하나 이상의 다른 특징들과 결합될 수 있다. 게다가, 용어 "포함한다" 및 "포함하는", 그리고 이들의 변형이 상세한 설명 또는 청구항에서 사용되는 한, 이들 용어는 용어 "포함하는"과 유사한 방식으로 포함적인 것으로 보아야 한다.

게다가, 하나 이상의 실시예들이 개시된 실시예들을 구현하기 위해 컴퓨터를 제어하는 소프트웨어, 펌웨어, 하드웨어, 또는 이들의 임의의 조합을 생산하는 표준의 프로그래밍 및/또는 엔지니어링 기법을 사용하여 방법, 장치 또는 제조 물품으로서 구현될 수 있다. 용어 "제조 물품"(또는 다른 대안으로서, "컴퓨터 프로그램 제품")은, 본 명세서에서 사용되는 바와 같이, 임의의 컴퓨터 판독가능 장치, 캐리어, 또는 매체로부터 액세스가능한 컴퓨터 프로그램을 포함하는 것으로 보아야 한다. 예를 들어, 컴퓨터 판독가능 매체는 자기 저장 장치(예를 들어, 하드 디스크, 플로피 디스크, 자기 스트립...), 광 디스크(예를 들어, CD, DVD,...), 스마트 카드, 및 플래쉬 메모리 장치(예를 들어, 카드, 스틱)를 포함할 수 있지만, 이에 한정되는 것은 아니다. 그에 부가하여, 전자 메일을 전송 및 수신하는 데 또는 인터넷이나 근거리 통신망(LAN) 등의 네트워크에 액세스하는 데 사용되는 것과 같은 컴퓨터 판독가능 전자 데이터를 전달하는 데 반송파가 이용될 수 있다는 것을 잘 알 것이다. 물론, 당업자라면 개시된 실시예들의 범위 또는 정신을 벗어나지 않고 이 구성에 많은 수정이 행해질 수 있다는 것을 잘 알 것이다.

Claims (20)

1. 데이터베이스 관리의 생산성을 증진시키는 시스템으로서,

   선언형 언어(declarative language)로 구성된 상위 레벨 의도(high-level intent)를 접수하는 하드웨어를 포함하는 인터페이스 컴포넌트와,

   상기 상위 레벨 의도를 해석하여 하위 레벨 설정을 결정하는 하드웨어를 포함하는 선언형 관리 컴포넌트와,

   상기 선언형 관리 컴포넌트의 적어도 하나의 기능을 자동화하는 하드웨어를 포함하는 기계-학습 컴포넌트를 포함하되,

   상기 의도는 사용자의 의도로 표현되고, 이러한 의도를 용이하게 하기 위해 변경되어야 하는 실제의 구성 설정(actual configuration setting)으로 표현되지 않으며, 대상 집합(target set)이 정책에 부합해야 한다는 요청을 나타내고, 상기 상위 레벨 의도는 상기 의도가 추론되고 동작 또는 설정의 사소한 이탈에 관계없이 이러한 동작 또는 설정이 상기 상위 레벨 의도에 일치하도록 특정 동작 또는 설정이 아닌 결과를 지정하는 문장으로서 선언형으로 표현되며, 상기 상위 레벨 의도는 문장으로 표현되어 서브컴포넌트를 포함하고, 상기 서브컴포넌트 각각은 상기 문장의 단어들에 포함된 단일 단어(word) 또는 어구(phrase)를 포함하며,

   상기 선언형 관리 컴포넌트는 각각의 개별 객체를 위해 특화되고 구별되는 의미(semantic)를 사용하여 개별 객체를 구성하고, 상기 문장의 키워드 서브컴포넌트를 인식하고 상기 문장의 단일 단어 또는 어구를 포함하는 상기 문장의 키워드의 서브컴포넌트에 대해 하나 이상의 기능을 수행함으로써 상기 시스템이 정책에 부합하도록, 사용자로부터의 추가 입력 없이, 적어도 부분적으로, 애플리케이션을 구성하는 대상 요소(target elements)를 식별하고 상기 대상 요소를 대상 집합으로 패키징하며 상기 애플리케이션을 추가적인 시스템에 배포함으로써, 사용자 의도 및 하나 이상의 하위 레벨 설정을 결정하는

   데이터베이스 관리의 생산성을 증진시키는 시스템.
2. 제1항에 있어서,

   상기 의도를 서브컴포넌트로 분해하는 하드웨어를 포함하는 파싱 컴포넌트, 및

   구체적인 의도를 도출하기 위해 각각의 서브컴포넌트를 분석하는 구문 엔진을 더 포함하는,

   데이터베이스 관리의 생산성을 증진시키는 시스템.
3. 제1항에 있어서,

   정책들을 특정의 미리 정의된 구성으로 배포하는 하드웨어를 포함하는 보안 컴포넌트를 더 포함하는

   데이터베이스 관리의 생산성을 증진시키는 시스템.
4. 제1항에 있어서,

   정책, 정책 버전, 대상, 및 패싯(facet) 중 적어도 하나에 관한 이력 정보를 유지하는 하드웨어를 포함하는 이력 컴포넌트를 더 포함하는

   데이터베이스 관리의 생산성을 증진시키는 시스템.
5. 제1항에 있어서,

   규모에 따른 관리 및 규모에 따른 자동화 중 적어도 하나를 제공하는 하드웨어를 포함하는 집계 컴포넌트(aggregation component)를 더 포함하는

   데이터베이스 관리의 생산성을 증진시키는 시스템.
6. 제1항에 있어서,

   프로그래밍 모델을 확장함으로써 패싯 및 대상 중 적어도 하나를 추가하는 하드웨어를 포함하는 구성 컴포넌트를 더 포함하는

   데이터베이스 관리의 생산성을 증진시키는 시스템.
7. 제1항에 있어서,

   다수의 서버 및 다수의 제품 중 적어도 하나에 걸쳐 애플리케이션을 확장시키는 하드웨어를 포함하는 최적화 컴포넌트를 더 포함하는,

   데이터베이스 관리의 생산성을 증진시키는 시스템.
8. 제1항에 있어서,

   정책 및 대상 집합을 포함하는 하드웨어를 포함하는 연계 컴포넌트(binding component)를 더 포함하며,

   상기 정책 및 상기 대상 집합은 2개 이상의 연계에 의해 참조될 수 있는

   데이터베이스 관리의 생산성을 증진시키는 시스템.
9. 제1항에 있어서,

   하드웨어를 포함하는 상기 선언형 관리 컴포넌트는 다수의 애플리케이션을 포함하는 서버의 애플리케이션 뷰를 제공하는

   데이터베이스 관리의 생산성을 증진시키는 시스템.
10. 상위 레벨 의도와 하위 레벨 설정 간의 인터페이스를 제공하는 방법으로서,

    사용자로부터 선언형 의도(declarative intent)를 수신하는 단계와,

    상기 의도를 달성하기 위해 하나 이상의 레벨 설정을 자동으로 결정하는 단계와,

    상기 사용자로부터의 추가 입력 없이, 시스템으로 하여금 정책에 부합하도록상기 하나 이상의 설정을 구성하는 단계

    를 포함하되,

    상기 의도는 대상 집합에 대한 정책의 평가를 요청하고, 상기 의도는 사용자의 의도로 표현되고 이러한 의도를 용이하게 하기 위해 변경되어야 하는 실제의 구성 설정으로 표현되지 않으며, 상기 상위 레벨 의도는 상기 의도가 추론되고 동작 또는 설정의 사소한 이탈에 관계없이 이러한 동작 또는 설정이 상기 상위 레벨 의도에 일치하도록 특정 동작 또는 설정이 아닌 결과를 지정하는 선언형으로 표현되며, 상기 상위 레벨 의도는 문장으로 표현되어 서브컴포넌트를 포함하고, 상기 서브컴포넌트 각각은 상기 문장의 단어들에 포함된 단일 단어 또는 어구를 포함하며,

    상기 하나 이상의 레벨 설정을 자동으로 결정하는 단계는, 각각의 개별 객체를 위해 특화되고 구별되는 의미를 사용하여 개별 객체를 구성하고, 상기 문장의 키워드 서브컴포넌트를 인식하고 상기 문장의 단일 단어 또는 어구를 포함하는 상기 문장의 키워드의 서브컴포넌트에 대해 하나 이상의 기능을 수행함으로써 상기 시스템이 상기 정책에 부합하도록, 적어도 부분적으로, 어느 대상 구성요소가 애플리케이션을 구성하는지 나타내고 상기 대상 요소를 다양한 개별 대상 구성요소로 이루어지는 단일 대상으로 그룹화하며 상기 애플리케이션을 추가적인 시스템에 배포함으로써 사용자 의도 및 하나 이상의 하위 레벨 설정을 결정하는

    인터페이스 제공 방법.
11. 제10항에 있어서,

    상기 수신된 선언형 의도에 부합하는지의 모니터링을 제공하는 단계를 더 포함하는

    인터페이스 제공 방법.
12. 제10항에 있어서,

    정책을 대상 집합에 매핑하기 위해 정책 연계를 수행하는 단계를 더 포함하는

    인터페이스 제공 방법.
13. 제10항에 있어서,

    제약조건 또는 위반이 있는지 검사하는 단계를 더 포함하는

    인터페이스 제공 방법.
14. 제10항에 있어서,

    보고 기능을 제공하는 단계를 더 포함하는

    인터페이스 제공 방법.
15. 제10항에 있어서,

    상기 하나 이상의 설정을 구성하는 단계가 다수의 데이터베이스에 걸쳐 행해지는

    인터페이스 제공 방법.
16. 데이터베이스 관리의 생산성을 증진시키는 시스템으로서,

    선언형 언어로 구성된 상위 레벨 의도를 접수하는 하드웨어를 포함하는 인터페이스 컴포넌트와,

    상기 상위 레벨 의도를 해석하고 이러한 의도를 하위 레벨 설정에 자동으로 적용하는 하드웨어를 포함하는 선언형 관리 컴포넌트

    를 포함하되,

    상기 의도는 사용자의 의도로 표현되고, 이러한 의도를 용이하게 하기 위해 변경되어야 하는 실제의 구성 설정으로 표현되지 않으며, 정책이 대상 집합에 부합한다는 확인 또는 대상 집합이 정책에 부합해야 한다는 요청을 나타내고, 상기 상위 레벨 의도는 상기 의도가 추론되고 동작 또는 설정의 사소한 이탈에 관계없이 이러한 동작 또는 설정이 상기 상위 레벨 의도에 일치하도록 특정 동작 또는 설정이 아닌 결과를 지정하는 선언형으로 표현되며, 상기 상위 레벨 의도는 문장으로 표현되어 서브컴포넌트를 포함하고, 상기 서브컴포넌트 각각은 상기 문장의 단어들에 포함된 단일 단어 또는 어구를 포함하며,

    상기 선언형 관리 컴포넌트는 각각의 개별 객체를 위해 특화되고 구별되는 의미를 사용하여 개별 객체를 구성하고, 상기 문장의 키워드 서브컴포넌트를 인식하고 상기 문장의 단일 단어 또는 어구를 포함하는 상기 문장의 키워드의 서브컴포넌트에 대해 하나 이상의 기능을 수행함으로써 상기 시스템이 상기 정책에 부합하도록, 사용자로부터의 추가 입력 없이, 적어도 부분적으로, 애플리케이션을 구성하는 대상 요소를 식별하고 상기 대상 요소를 대상 집합으로 패키징하며 상기 애플리케이션을 추가적인 시스템에 배포함으로써, 사용자 의도 및 하나 이상의 하위 레벨 설정을 결정하는

    데이터베이스 관리의 생산성을 증진시키는 시스템.
17. 삭제
18. 삭제
19. 삭제
20. 삭제

Images