KR101411181B1 - 스키마의 패키징, 배포, 이용가능성 - Google Patents

Abstract

스키마의 패키징, 배포, 이용가능성을 가능하게 하는 시스템 및/또는 방법을 제공한다. 본 발명의 양태들은 스키마 패키지의 보안 정의를 용이하게 하는 서명 기술을 이용한다. 또한, 이 시스템 및/또는 방법은, 스키마 패키지를 클라이언트측 어셈블리 내에 리소스로서 포함할 수 있고 이에 따라 어셈블리를 발견하는 데 사용되는 정확하게 동일한 인프라스트럭처가 스키마 패키지의 발견에 효력을 발휘할 수 있음을 보장한다. 다른 양태들은 스키마 패키지를 위성 어셈블리로서 또는 별도의 파일로서 포함할 수 있다. 이러한 시나리오들에서, 본 발명은, 클라이언트가 미설치 스키마에 대하여 저장소와 상호작용할 수 있게 하는 데 필요한 스키마 패키지 및 정보를 구성하고 배포하는 것을 용이하게 할 수 있다.

스키마 패키지, 배포, 이용가능성, 클라이언트측 어셈블리, 암호 키

Description

스키마의 패키징, 배포, 이용가능성{SCHEMA PACKAGING, DISTRIBUTION AND AVAILABILITY}

컴퓨팅 시스템은 데이터 공통성을 증가시키는 방향으로 기술 발전을 이루어 왔으며 이에 따라 머신들 사이에 공유, 호환성, 상호 운용성을 가능하게 하였다. 예를 들어, 잘 알려져 있듯이, 사용자는 흔히 하나의 장치 상의 데이터를 갖고 그 데이터를 다른 장치 및/또는 애플리케이션과 공유하길 원할 수 있다. 오늘날에는, 시스템이 특정한 데이터 포맷 및 유형을 허용하도록 미리 구성되어 있는 한, 컴퓨터는 애플리케이션 및 사용자 사이에 데이터를 공유할 수 있다. 그러나, 이러한 종래의 시스템은 확장성이 없다. 다시 말하면, 수신 장치에 대하여 정확한 스키마가 이용가능하지 않다면, 데이터를 전달할 수 없다. 게다가, 자유로운 데이터 교환을 유지하려면, 사용자는, 수신 위치(예를 들어, 서버/클라이언트)에서 추가 및/또는 수정이 설치되지 않는 한 발신 위치(예를 들어, 클라이언트/서버)에서 데이터 유형에 대한 동일한 추가나 수정을 행할 수 없다. 다시 말하면, 수신 위치(예를 들어, 서버/클라이언트)는 다른 장치 및/또는 애플리케이션으로부터 입력되는 데이터를 수용하도록 준비되어야 한다(예를 들어, 필요한 스키마 정보를 유지할 수 있어야 한다).

컴퓨팅 시스템은, 데이터베이스 기술의 이점들을 활용하는 플랫폼을 채용하 는 방향으로 개발되어 왔다. 흔히, 이러한 개발은 이러한 이점들을 파일 시스템들 내에 포함시킨다. 그러나, 이러한 시스템들은 전술한 동일한 스키마 호환성을 공유한다는 단점이 있다. 이처럼, 오늘날, 데이터를 효율적으로 전달하고 공유하기 위해서는, 파일 시스템의 데이터를 소정의 공통 스키마에 맞추어야 한다. 물론, 스키마는 데이터의 형태(예를 들어, 구조)를 설명하는 선언 방식으로서 정의될 수 있다.

이러한 신흥 파일 시스템에서, 오브젝트는 데이터베이스(예를 들어, 파일 시스템) 내에 저장될 수 있고, 이에 따라, 적용가능 스키마에 의해 설명될 수 있다. 이러한 파일 시스템의 데이터는 특정 스키마 및 유형의 인스턴스이고, 이 유형은 데이터의 형상(예를 들어, 구조)을 정의하는 스키마 내에 정의된다. 새로운 유형, 예를 들어, 시스템이 이용할 수 있는 오브젝트들의 새로운 한 세트 또는 데이터의 새로운 한 형태를 그 시스템에 추가할 필요가 있는 경우, 개발자는 그 시스템 내에 스키마 및 유형을 생성할 필요가 있다. 다음으로, 그 유형에 속성을 부가한다.

필요한 스키마(들)/유형(들)이 미리 설치되어 있지 않은 파일 시스템 저장소 (또는 다른 데이터베이스)에 데이터가 세이브되어야 하는 다수의 시나리오가 존재한다. 이것은 저장 다운 레벨(store down-level) 문제점으로 알려져 있다. 종래의 시스템에서는, 시스템 관리자 및/또는 특정한 인가를 갖는 사람 만이 스키마 정보를 설치할 수 있다.

다음에 따르는 설명은 본 발명의 일부 양태들의 기본적인 이해를 위해 본 발명의 간략한 개요를 제시한다. 이 개요는 본 발명의 광범위한 개요가 아니다. 이것은 본 발명의 핵심/주요 요소들을 식별하려는 것이 아니며 본 발명의 범위를 제한하려는 것도 아니다. 이 개요의 유일한 목적은 본 발명의 일부 개념들을 후술되는 상세한 설명에 대한 도입부로서 간략한 형태로 제시하는 것이다.

본 명세서에서 설명하는 본 발명은, 그 일 양태에 있어서, 스키마 패키지를 리소스로서 클라이언트측 어셈블리 내에 용이하게 포함할 수 있다. 다른 양태들은 스키마 패키지를 위성 어셈블리 또는 별도의 파일로서 포함할 수 있다. 스키마 정의는 스키마 패키지라 불리는 다큐먼트에 모아질 수 있음을 이해하기 바란다. 예시적인 시나리오에서, 시스템은, 클라이언트가 미설치 스키마에 대하여 저장소와 상호작용할 수 있게 하는 데 필요한 스키마 패키지 및 정보를 용이하게 구성하고 및 배포할 수 있다.

스키마의 적시 설치를 지원하기 위해, 서명된 스키마 패키지를 설치를 위해 저장소에 제시할 수 있다. 스키마 패키지가 많은 이점들을 제공하지만, 이러한 이점들은 스키마 패키지가 설치를 위해 쉽게 이용될 수 없다면 소용이 없다. 본 발명은, 일 양태에 있어서, 보안성과 정기적인 이용가능성을 보장하도록 스키마 패키지를 구성하고 배포하는 시스템 및 방법에 관한 것이다.

일 양태에 따르면, 스키마 패키지의 구성동안, 스키마 패키지의 구성, 스트롱 네임(strong name) 서명 동작을 이용할 수 있다. 추가 양태들은 인증 코드 서명, 스키마 패키지의 압축 및/또는 암호화를 이용할 수 있다. 스키마 패키지는 스키마를 구현하는 클라이언트측 어셈블리의 일부분으로서 포함될 수 있다. 클라이언트측 어셈블리는, 잘 알려져 있는 이름으로 식별될 수 있고, 스키마가 프로그램에 따른 방식으로 이용될 수 있는 모든 위치에 있는 API에 대하여 이용가능할 수 있다. 다시 말하면, 클라이언트 애플리케이션이 저장소 내에서의 지속을 위해 스키마화 유형의 인스턴스를 인스턴싱(instantiate)할 때마다, 클라이언트는 스키마 패키지에 대하여 액세스를 가질 수 있다. 다른 양태에서는, 필요한 스키마가 저장소 내에서 이용가능하지 않은 경우, 데이터를 제시하기 전에 스키마 패키지를 저장소 내에 설치할 수 있다.

전술한 목적 및 관련 목적을 달성하기 위해, 본 발명의 소정의 예시적인 양태들을 다음에 따르는 설명 및 첨부 도면과 함께 본 명세서에 설명한다. 그러나, 이러한 양태들은 본 발명의 원리들을 이용할 수 있는 다양한 방식들 중 일부를 가리키며 본 발명은 이러한 양태들과 그 등가물 모두를 포함하고자 한다. 본 발명의 다른 이점들 및 신규한 특징들은 첨부 도면과 함께 본 발명의 다음에 따르는 상세한 설명으로부터 명백해질 것이다.

도 1은 본 발명의 일 양태에 따라 스키마의 패키징, 배포, 이용가능성을 용이하게 하는 시스템의 블록도를 도시한다.

도 2는 본 발명의 일 양태에 따라 스키마 데이터를 서명하는 데 스트롱 네임 서명 컴포넌트를 이용하는 시스템의 블록도를 도시한다.

도 3은 본 발명의 일 양태에 따라 인증 코드, 압축 및/또는 암호화 컴포넌트를 선택 사항으로 이용하는 시스템의 예시적인 블록도를 도시한다.

도 4는 본 발명의 일 양태에 따라 스키마 패키지와 클라이언트측 어셈블리의 동일한 암호 서명을 이용하는 시스템을 도시한다.

도 5는 본 발명의 일 양태에 따라 스키마의 스트롱 네임 서명에 영향을 끼치는 방법의 예시적인 흐름도를 도시한다.

도 6은 본 발명의 일 양태에 따라 스트롱 네임 서명된 스키마를 해독하는 데 영향을 끼치는 방법의 예시적인 흐름도를 도시한다.

도 7은 본 발명의 일 양태에 따라 스키마의 배포에 영향을 끼치는 발견 컴포넌트 및 로딩 컴포넌트를 이용하는 시스템의 블록도를 도시한다.

도 8은 개시된 아키텍쳐를 실행하도록 동작가능한 컴퓨터의 블록도를 도시한다.

도 9는 본 발명에 따라 예시적인 컴퓨팅 환경의 개략적인 블록도를 도시한다.

이제 도면을 참조하여 본 발명을 설명하되, 명세서 전반에 걸쳐 유사 참조 번호들은 유사 요소들을 가리키는 데 사용된다. 다음의 설명에서는, 설명의 편의상, 본 발명의 완전한 이해를 위해 수많은 특정 상세들을 설명한다. 그러나, 이러한 특정 상세들 없이 본 발명을 실시할 수 있다는 것은 명백할 수 있다. 다른 경우에는, 본 발명의 설명이 용이하도록 잘 알려져 있는 구조 및 장치를 블록도 형태로 도시한다.

본 명세서에서 이용되는 바와 같이, "컴포넌트" 및 "시스템"이라는 용어들은 컴퓨터 관련 엔티티인, 하드웨어, 하드웨어와 소프트웨어의 조합, 소프트웨어, 또는 실행중인 소프트웨어를 가리키고자 한다. 예를 들어, 컴포넌트는, 프로세스 상에서 동작 중인 프로세스, 프로세서, 오브젝트, 실행가능 파일, 실행 스레드, 프로그램, 및/또는 컴퓨터일 수 있지만, 이러한 예로 한정되지는 않는다. 예를 들어, 서버 상에서 동작 중인 애플리케이션 및 서버 둘 다가 하나의 컴포넌트일 수 있다. 하나 이상의 컴포넌트는, 프로세스 및/또는 실행 스레드 내에 상주할 수 있고, 컴포넌트는 하나의 컴퓨터 상에 위치할 수 있으며 그리고/또는 2개 이상의 컴퓨터 사이에 배포될 수 있다.

본 명세서에서 사용될 때, "추론한다" 또는 "추론"이라는 용어는, 일반적으로 이벤트 및/또는 데이터를 통해 캡처된 한 세트의 관찰들로부터 시스템, 환경, 및/또는 사용자의 상태들을 추론하거나 논리적으로 생각하는 프로세스를 가리킨다. 추론은 특정한 문맥이나 액션을 식별하는 데 이용될 수 있고, 예를 들어 상태들에 대하여 확률 배포를 생성할 수 있다. 추론은 확률적일 수 있으며, 즉, 데이터 및 이벤트를 고려하여 관심 대상인 상태들에 대한 확률 배포를 계산하는 것일 수 있다. 또한, 추론은 한 세트의 이벤트들 및/또는 데이터로부터 고 레벨 이벤트들을 합성하는 기술들을 참조할 수 있다. 이러한 추론에 따라, 한 세트의 관찰된 이벤트들 및/또는 저장된 이벤트 데이터로부터, 이러한 이벤트들이 시간적으로 밀접하게 상관되어 있는지 여부에 상관없이 그리고 이벤트들 및 데이터가 하나 또는 여러 개의 이벤트 및 데이터 소스들로부터 온 것인지 여부에 상관없이, 새로운 이벤트 또는 액션이 구성된다.

먼저 도 1을 참조해 보면, 스키마의 패키징, 배포, 이용가능성을 용이하게 하는 시스템(100)이 도시되어 있다. 일반적으로, 이 시스템(100)은 스키마 패키징 컴포넌트(102)와 스키마 배포 컴포넌트(104)를 포함할 수 있다. 전술한 바와 같이, 시스템(100)은 자신의 보안성과 신뢰성을 유지하는 동안 적합한 스키마의 이용가능성에 영향을 끼칠 수 있다.

흔히, 사용자는 컴퓨터 상에 데이터를 갖고서 이 데이터를 애플리케이션과 사용자 사이에 공유하길 원할 것이다. 그러나, 일부 상황에서는, 데이터 공유에 영향을 끼치는 데 필요한 정보(예를 들어, 스키마)가 이용가능하지 않을 수 있다. 종래의 시스템이 데이터 공유에 영향을 끼치는 방식에는 많은 문제점들이 존재한다. 전술한 바와 같이, 종래의 시스템은 확장성이 없다. 예를 들어, 사용 권한 및 액세스 가능 문제점들로 인해 유형들을 추가하는 것은 종종 어렵다. 파일 시스템은 흔히 데이터베이스의 이점들을 취하고 이들을 저장 파일 시스템 내에 구축하는 플랫폼을 이용한다. 이처럼, 파일 시스템의 데이터는 소정의 기설치된 스키마, 즉, 데이터의 유형을 설명하는 선언 방식에 맞춰질 수 있다.

신흥 파일 시스템에서, 오브젝트는 데이터베이스(예를 들어, 파일 시스템)에 저장되고 특정 스키마에 의해 설명된다. 이러한 파일 시스템의 데이터는 이 스키마의 유형의 인스턴스이며, 이 유형은 데이터의 형상을 정의하는 스키마 내에서 정의된다. 본 명세서에서 설명하는 예들 및 양태들은 데이터베이스 스키마 시나리오에 관한 것이지만, 본 명세서에서 설명하는 새로운 기능성의 다른 시나리오 및 구현예가 존재하며 이에 따라 적용가능 스키마가 다른 다큐먼트들을 설명할 수 있다 는 점을 이해하기 바란다. 이러한 다른 양태들은 본 명세서 및 청구범위에 포함된다.

본 발명은, 하나의 머신으로부터 다른 하나의 머신으로 데이터의 방해받지 않는 전달을 가능하게 하는 동안 이 데이터가 그 다른 하나의 머신에 도달할 때마다 이 데이터에 관하여 필요한 메타데이터가 그 다른 하나의 머신에 미리 존재하는 것을 가능하게 한다. 또한, 본 발명은 스키마 정보에 대하여 보안성을 유지하는 동안 컴포넌트들 사이에 그 스키마 정보를 조정할 수 있다.

도 1을 다시 참조해 보면, 본 발명의 양태들은 스키마의 안전한 패키징, 배포 및 이용가능성을 용이하게 하는 시스템(100)(및/또는 방법)에 관한 것이다. 일 양태에서, 스키마 패키징 컴포넌트(102)는 스키마 설치 단위, 예를 들어, 데이터의 구조를 설명하는 스키마 패키지 또는 그냥 패키지(예를 들어, 스키마 다큐먼트)를 정의하도록 제공될 수 있다. 시스템(100)에 의해 다루어질 수 있는 한 가지 이슈는, 2개의 스키마가 독립적으로 개발되는 경우, 스키마들이 우연히 충돌하지 않도록 보장하는 것이 중요하다는 점이다. 다시 말하면, 다큐먼트들의 2가지 유형이 수신 머신에게 우연히 동일한 다큐먼트로서 보이지 않는 것을 보장하는 것이 중요하다.

전술한 응용에서 설명한 바와 같이 스키마의 적시 설치를 지원하기 위해, 스키마 패키징 컴포넌트(102)는, 설치를 위해 저장소에 제시될 수 있는 고유하게 서명된 스키마 패키지를 생성할 수 있다. 스키마 패키지는 많은 이점들을 제공하지만, 이러한 이점들은 패키지가 설치용으로 쉽게 이용가능하지 않다면 소용이 없다. 배포 컴포넌트(104)는 설치를 위한 이용가능성을 용이하게 할 수 있다. 스키마 패키징 컴포넌트(102)와 스키마 배포 컴포넌트(104) 둘 다의 새로운 기능성을 좀더 상세히 후술한다.

일반적으로, 본 발명은, 일 양태에 있어서, 저장소 내에 데이터를 용이하게 저장하도록 비관리자(non-administrator) 또는 비권한(non-authoritative) 에이전트에게 스키마를 저장소 내에 주입하는 기능을 주는 것이다. 특히, 본 발명은, 이 시나리오를, 스키마가 자신의 소유자에 대하여 권한있으며 다른 소유자에 의해 생성된 스키마와 충돌하지 않을 정도로 가능하게 한다.

본 명세서에서 설명하는 새로운 기능성에 따르면, 사용자가 스키마를 생성하면, 다른 사용자는 그 스키마를 이용할 수 있고 그 스키마가 원래의 소유자에 대하여 권한있음을 결정할 수 있다. 게다가, 사용자는, 스키마가 저장소 내로 주입되면, 다른 사용자에 의해 생성된 스키마 또는 기존의 스키마에 부정적인 영향을 끼치지 않음을 보장할 수 있다. 다른 주요한 새로운 개념은 스키마 패키지와 클라이언트측 어셈블리 사이의 관계라는 것을 인식할 것이다. 이 관계는 클라이언트측 어셈블리에 대하여 항상 스키마 패키지를 이용가능하게 할 수 있다.

본 발명은 후술하는 새로운 권한있는 비충돌 기능성을 이루기 위해 다수의 기술들을 조합한다. 본 발명의 양태들은 스키마 패키지의 이용가능성을 보장하도록 스키마 패키지를 구성하고 배포하는 방식을 설명한다. 다음에 따르는 도면들의 설명으로부터 명백하듯이, 암호화 방식으로 서명된 스키마 패키지가 예를 들어 클라이언트측 어셈블리 내에 리소스로서 포함되는 이 클라이언트측 어셈블리에 링크 될 수 있다는 것은, 본 발명의 일 양태의 새로운 특징이다.

이제 도 2를 참조해 보면, 시스템(100)의 다른 아키텍쳐 블록도가 도시되어 있다. 새로운 스키마 패키징, 배포, 및 이용가능성 시스템의 양태들에 따르면, 스키마 패키징 컴포넌트(102)를 통한 스키마 패키지의 구성은 스트롱 네임 서명 컴포넌트(202)를 이용하여 스트롱 네임 서명 동작에 영향을 끼칠 수 있다. 스트롱 네임 서명은, 변조(tampering) 체크를 제공하고 버전 계통(lineage)을 보호하도록, 모든 다른 스키마들로부터 스키마를 고유하게 정의하는 기능을 가리킨다. 이에 따라, 스트롱 네임 서명에 대하여, 각 스키마는 스키마 자체의 정의에 밀접하게 관련되는 고유 이름을 가질 수 있다. 따라서, 스키마는, 임의의 다른 스키마가 다른 정의 및/또는 서명을 갖기 때문에, 고유해야 한다.

스키마를 자신의 원래 형태로 전송하지 않고, 스키마 패키징 컴포넌트(102)에 의해 스키마를 패키징하여 스키마의 콘텐츠를 보존하면서 몇 가지 원하는 특성들을 부여할 수 있다. 일 양태에 따르면, 스키마 패키지는 스트롱 네임을 갖는 스키마 정의 언어(SDL) 다큐먼트(예를 들어, 확장성 마크업 언어(XML))일 수 있다. 게다가, 스키마 패키지가 어떠한 커스텀 코드나 실행가능 코드도 포함하지 않는다는 점을 이해하기 바란다. 이에 따라, 이러한 스키마는 스키마 설치의 유일한 단위이다. 도 2에 도시한 바와 같이, 일 양태에서, 스트롱 네임은 스키마의 애칭, 버전, 컬처(culture), 스키마에 서명하는 데 사용되는 암호 키 쌍의 공중 키 부분을 포함할 수 있다.

이제 도 3을 참조해 보면, 스키마의 패키징, 배포, 이용가능성을 용이하게 하는 다른 시스템(300)이 도시되어 있다. 도시한 바와 같이, 스트롱 네임 서명 컴포넌트(202)에 더하여, 스키마 패키징 컴포넌트(102)는 선택 사항으로 인증코드 컴포넌트(302), 압축 컴포넌트(304), 및/또는 암호화 컴포넌트(306)를 스키마 패키지의 구성의 일부분으로서 이용할 수 있다. 인증코드 서명 컴포넌트(302)는 특별한 스트롱 네임 스키마를 특별한 개인 또는 개인들의 세트에 부착할 수 있다. 따라서, 이 스키마가 자신의 스트롱 네임에 대하여 권한있을 뿐만 아니라 자신의 물리적 실제 사람이나 조직 제작자(author)에 대해서도 권한있을 수 있다. 따라서, 인증코드 제공자는 서명을 통한 스트롱 네임과 스키마의 제작자인 인증코드 엔티티 사이의 매핑을 보장할 수 있다.

압축 컴포넌트(304)는 이송을 보다 쉽고 효율적으로 행할 수 있다. 예를 들어, 압축은, 저장소와 통신할 수 있는 클라이언트와 함께 이송되는 혹은 백업을 위해 또는 임포트/익스포트 동작, 카피 동작 또는 동기화를 위해 데이터가 저장소로부터 독출될 때 이 데이터와 함께 이송되는 코드로 된 스키마 패키지를 포함할 때, 특히 유용할 수 있다. 모든 경우에, 스키마가 데이터에 부착되고 있는 경우, 이 스키마를 압축하여 데이터를 갖는 스키마를 이송하는 오버헤드를 저감시키는 것이 특히 유익할 수 있다. 이러한 압축은 압축 컴포넌트(304)를 통해 선택 사항으로 효력이 나타날 수 있다.

게다가, 암호화 컴포넌트(306)를 통해 암호화를 선택 사항으로 이용할 수 있다. 이 암호화는 스키마가 데이터와 함께 전달될 때 보안성을 용이하게 할 수 있다. 스키마를 독점적으로 유지하는 것이 특히 유용한 경우들이 있기 때문에, 암호 화 메카니즘을 이용할 수 있다. 따라서, 스키마 정의는 감춰질 수 있으며 이동 중 또는 스키마 패키지를 검사할 수 있는 다른 임의의 시간에 보이지 않을 수 있다. 이러한 설명은 일 양태에 따라 스키마 패키지를 정의하며 스키마 패키지의 속성들을 설명하며 여기서 패키지는 전술한 속성들(예를 들어, 인증코드, 압축, 암호화) 중 하나 이상을 포함하는 스트롱 네임 서명된 스키마이다.

일단 구성되면, 스키마 패키지를 스키마의 구현예를 제공하는 클라이언트측 어셈블리의 일부분으로서 포함하는(또는 이에 관련시키는) 것은 본 발명의 새로운 특징이다. 게다가, 스키마는 잘 알려져 있는 이름으로 식별될 수 있고 스키마가 프로그램 방식으로 이용될 수 있는 모든 위치에 있는 애플리케이션 프로그램 인터페이스(API)에 대하여 이용가능할 수 있다.

클라이언트 애플리케이션이 저장소 내에서의 지속을 위해 스키마화 유형의 인스턴스를 인스턴싱할 때마다 클라이언트가 스키마 패키지에 대한 액세스를 갖는 것을 전술한 시스템(300)이 보장한다는 점을 이해할 것이다. 필요한 스키마가 저장소에서 현재 이용가능하지 않다면, 스키마 패키지는 발견될 수 있고 스키마 배포 컴포넌트(104)를 통해 이용가능해질 수 있으며 결국 데이터를 저장소에 제시하기 전에 (전술한 관련 애플리케이션에서 설명한 바와 같이 스키마 설치 컴포넌트를 통해) 저장소 내에 설치될 수 있다.

다시 말하면, 스키마 패키지는, 데이터를 생성하고 그리고/또는 조작하며 저장소와 통신하는 애플리케이션인 클라이언트측 어셈블리 내에 포함(또는 이 클라이언트측 어셈블리에 링크)될 수 있다. 특정한 일 양태에서, 클라이언트측 어셈블리 는 스키마의 정의를 리소스로서 포함할 수 있다. 다른 방안으로, 스키마는 클라이언트측 어셈블리와 다른 고유한 관계를 가질 수 있고 이에 따라 발견가능성 및 이용가능성에 영향을 끼친다.

도 4는 스키마의 패키징, 발견, 이용가능성을 용이하게 하는 또다른 대체 시스템(400)을 도시한다. 특히, 도 4는 동일한 스트롱 네임을 갖는 동일한 스트롱 네임 서명 컴포넌트에 의해 스키마 패키지(402) 및 클라이언트측 어셈블리(404)가 서명될 수 있음을 도시한다. 데이터의 다수의 유형을 조작하는 데 다수의 스키마가 필요한 정도까지, 이러한 추가 스키마가 클라이언트측 어셈블리 내에 포함될 (또는 클라이언트측 어셈블리에 관련될) 수도 있다는 점을 인식하기 바란다. 각 패키지는, 잘 알려져 있는 이름, 즉, 스키마의 서명시 생성되는 스트롱 네임으로 식별될 수 있다. 애플리케이션 자체는 코드가 실행되고 있는 모든 위치에서 실행되도록 그 코드를 가져야 하기 때문에, 저장소와 통신하는 데 필요한 스키마 패키지가 그 위치에 존재해야 하며, 그 이유는 코드가 이용가능할 때마다 패키지가 코드 내에서 리소스로서 존재하기 때문이다.

인스턴스가 파일 시스템 저장소에 세이브될 수 있기 전에, 이 인스턴스의 스키마(및 인스턴스의 오브젝트 트리에 있는 모든 유형의 스키마)가 존재해야 한다. 전술한 바와 같이, 저장소에 스키마가 없는 경우에, 이 스키마를 설치할 필요가 있다. 본 발명의 스키마의 패키징, 배포, 및 이용가능성은 필요한 스키마의 안전한 이용가능성 및/또는 설치에 영향을 끼칠 수 있다.

이제 도 5를 참조해 보면, 본 발명의 일 양태에 따라 스키마를 스트롱 네임 서명하는 방법이 도시되어 있다. 설명의 편의상, 예를 들어 흐름도의 형태로 본 명세서에 예시한 하나 이상의 방법이 일련의 액션들로 도시되고 설명되지만, 본 발명에 따라 일부 액션들이 본 명세서에 도시되고 설명된 다른 액션들과 다른 순서 및/또는 동시에 발생할 수 있듯이 본 발명이 액션들의 순서에 의해 한정되지 않는다는 점을 이해 및 인식하기 바란다. 예를 들어, 다른 방안으로 방법이 상태도에서와 같이 일련의 상관 상태들이나 이벤트들로서 제시될 수 있다는 것을 당업자라면 이해 및 인식할 것이다. 게다가, 본 발명에 따른 방법을 구현하는 데 모든 예시한 액션들이 필요하지 않을 수 있다.

도 5에 도시한 바와 같이, 스키마에 스트롱 네임 서명하기 위해, 블록(502)에서, 스키마의 해시값을 계산한다. 일 예로, 보안 해시 알고리즘(SHA1) 해시를 이용할 수 있다. 이후, 블록(504)에서, 해시값은 비밀 키를 이용하여 비대칭 암호(예를 들어, RSA 비대칭 암호)로 서명된다. 블록(506)에서, 서명된 해시값은 대응하는 RSA 공중 키로 스키마에 저장된다.

이제 도 6을 참조해 보면, 스트롱 네임 서명된 스키마를 검증하는 방법이 도시되어 있다. 스트롱 네임 서명된 스키마를 검증하기 위해, 블록(602)에서, 저장된 해시값은 저장된 키(예를 들어, RSA 키)를 이용하여 해독된다. 다른 해시값은 블록(604)에서 스키마 콘텐츠로부터 독립적으로 생성된다. 블록(606)에서, 2개의 해시값이 일치하는지 여부에 대한 결정을 내린다. 2개의 해시값이 일치하지 않으면, 정지 블록에 도달한다. 반면에, 2개의 해시값이 일치하면, 블록(608)에서 검증을 성공적이라 간주한다.

유효 스키마 패키지는, 클레임(claimed) 스트롱 네임의 유효성, 콘텐츠의 무결성, 공개자 인증성의 정도를 보장할 수 있다. 다시 말하면, 스키마는 원래의 소유자에 대하여 권한있는 것으로 간주될 수 있다. (예를 들어, 도 3의 선택 사항인 컴포넌트들에 따른) 추가 액션들이 패키징 동안 적용되어 간결성과 같은 속성(예를 들어, 압축) 및 추가 보안성(예를 들어, 암호화 및/또는 인증코드 서명)을 얻을 수 있다는 것을 인식할 것이다. 이러한 추가 양태들은 본 명세서 및 청구범위에 속하는 것으로 간주된다.

스키마 정의 언어, 이 예에선 XML인 언어와 함께, 클라이언트측 어셈블리 내로 컴파일링될 수 있는 툴(도시하지 않음)이 있을 수 있다. 이 클라이언트측 어셈블리는 특정 유형으로 정의된 클래스에 대한 링크이다. 다시 말하면, 클라이언트측 어셈블리는 클래스에 프로그램 방식 액세스를 제공한다.

따라서, 클라이언트측 어셈블리와 스키마 패키지 사이에는 매우 밀접한 관계가 존재할 수 있다. 다시 말하면, 스키마 패키지는, (예를 들어 리소스로서) 클라이언트측 어셈블리 내에 포함되지 않으면, 쉽게 이용가능해질 수 있다. 클라이언트측 어셈블리는 데이터 및 스키마 패키지 또는 정의가 저장소와의 계약인지를 보기 위해 프로그램 방식 액세스의 구현을 제공한다. 대체로, 유형을 구현하는 클라이언트측 어셈블리(예를 들어, 코드) 및 저장소 내의 유형을 설명하는 스키마 패키지 사이의 고유의 관계 및/또는 연계를 제공하는 것은 본 발명의 새로운 특징이다. 리소스는 이러한 관계에 영향을 끼치는 하나의 메카니즘이다. 다른 양태에서, 스키마 패키지는 어셈블리 내로 컴파일링되는 정적 변수로 저장될 수 있고 또는 다른 파일 내에 두어 어셈블리와 나란히 배포될 수 있으며 또는 잘 알려져 있는 또다른 위치나 캐시에 둘 수 있다.

이제 도 7을 참조하여 스키마 패키징 컴포넌트(102)를 계속 설명해 보면, 파일 시스템(예를 들어, WinFS 브랜드) 스키마의 개발은 클라이언트측 어셈블리와 스키마 패키지 둘 다의 개발을 포함한다. 호환성에 영향을 끼치려면, 일 양태에서, 클라이언트측 어셈블리(404) 및 스키마 패키지(402) 둘 다가, 개발 전에 동일한 스트롱 네임을 이용함으로써 서명 컴포넌트(202)에 의해 서명될 수 있다. 다른 양태에서, 개발 툴들(예를 들어, 발견 컴포넌트(702) 및 로딩 컴포넌트(704))은 컴파일 시간 및 포스트 컴파일 시간(지연 서명) 둘 다에서 키 쌍들을 발견하고 패키지들에 서명하는 데 이용될 수 있다. 지연 서명 환경이 스킵 리스트 유지 및 쿼리를 위해 인프라스트럭처에 의해 지원될 수 있다는 점을 이해하기 바란다.

다음에 따르는 설명은 스키마 패키지(402) 및 클라이언트측 어셈블리(404)가 특정한 공통 키에 의해 서명된다는 것이다. 스키마 패키지(402) 및 클라이언트측 어셈블리(404) 사이의 관계를 보장하기 위해, 본 발명은 (예를 들어 스트롱 네임 서명 컴포넌트(202)를 통해) 동일한 키를 이용하여 클라이언트측 어셈블리의 서명을 요구함으로써 새로운 관계를 개시한다. 이렇게 동일한 키를 이용함으로써 스키마 패키지(402) 및 클라이언트측 어셈블리(404) 사이의 고유 관계에 영향을 끼칠 수 있다. 이 키는 제작자가 비밀 키에 대한 액세스를 갖고 있었음을 가리키고 이것은 제작자만이 비밀 키에 대한 액세스를 갖기 때문에 스키마 패키지(402)가 클라이언트측 어셈블리(404)에 대하여 권한있음을 확인해 준다.

전술한 바와 같이, 이러한 메카니즘의 새로운 특징은, 스키마 패키지(402)가 클라이언트측 어셈블리(404) 내에 리소스로서 포함될 수 있다는 것이다. 스키마 패키지(402)를 클라이언트측 어셈블리(404) 내에 포함함으로써, 클라이언트측 어셈블리(404)가 서명될 때마다 스키마 패키지가 서명용으로 이용가능해지는 것을 보장할 수 있다. 다른 양태에서, 키 쌍은 하나의 메카니즘을 통해 개발 툴들에게 제시될 수 있다.

컴파일 시간 서명 동안, 어셈블리를 서명하는 데 사용되는 동일한 키 파일을 이용하여 어셈블리 컴파일 동안 스키마 패키지를 서명할 수 있다. 스키마 패키지가 어셈블리 내에서 리소스로서 보이기 때문에, 스키마 패키지가 먼저 서명될 수 있고, 어셈블리 내에 포함될 수 있으며, 이후 어셈블리가 서명된다. 이러한 동작들은 커스텀 빌드 태스크(예를 들어, MSBuild-브랜드 태스크) 내에 포함될 수 있음을 인식할 것이다. 또한, 전술한 다수의 액션들을 자동화함으로써 사용자 경험을 간략화하는 사용자 인터페이스(UI)층을 제공할 수 있다.

비밀 키들은 개발 환경에서 보호되기 때문에, 스킵 리스트를 이용하여 지연 서명에 영향을 끼칠 수 있다. 지연 서명 동안, 스키마 패키징 컴포넌트(102)는 지연 서명된 패키지(즉, 정확한 해시값 없이 구성된 패키지)를 지원할 수 있다. 스킵 리스트는 스키마 패키지 스킵 리스트 엔트리들을 설명하는 데 이용가능할 수 있다. 예를 들어, 스킵 리스트는 다른 유사한 메카니즘의 어셈블리 스킵 리스트일 수 있다. 이 양태에 따르면, 스킵 리스트에 보이는 임의의 스키마 패키지가 설치 동안 유효성 검증되지 않는다.

이 환경에서는, 개발자들이 비밀 키에 대한 액세스를 갖지 않더라도, 비밀 키에 대한 액세스를 갖고 있는 것처럼 시스템으로 여전히 작업할 수 있다. 일단 개발이 완료되면, 최종 서명 프로세스를 수행할 수 있고 이에 따라 클라이언트측 어셈블리 및 스키마 패키지를 그 비밀 키로 서명하게 된다.

스킵 리스트가, 특정 머신 상의 어셈블리, 스키마, 또는 이 둘의 유효성을 검증하는 스트롱 네임 체크를 패스함으로써 활성화되는 메카니즘이라는 것을 인식할 것이다. 다시 말하면, 스킵 리스트는, 사용자가 이 컴포넌트를 보는 경우, 적합한 비밀 키로 서명되지 않았다는 사실을 무시할 수 있는 시나리오를 활성화한다.

지연 서명 환경에서 그리고 어셈블리가 최종적으로 서명되는 경우, 어셈블리를 서명하기 전에 스키마 패키지를 완전히 서명하는 것이 여전히 필요할 수 있다. 별도의 부문(department)이 키를 관리하고 이미 구축되어 있는 어셈블리를 서명하는 완료 단계를 수행하는 개발 환경에서, 스키마 패키지 및 이 패키지의 어셈블리는 종종 2단계 프로세스로 서명된다. 제1 단계에서, 스키마 패키지는 서명을 위해 서명 부문에 제출된다. 이에 따라, 서명된 패키지를 빌드 트리 내로 체크하게 된다. 이렇게 체크인된 서명된 패키지는 스키마 변경이 체크인될 때마다 새로운 서명된 패키지로 갱신될 수 있다.

체크인된 서명된 스키마 패키지는 후속 빌드(build)들에서 사용될 수 있다. 골든 비트(Golden Bits) 빌드는 후속하여 서명된 스키마 패키지를 미리 포함하고 있는 서명 부문에 어셈블리 서명을 위해 전송된다. 다른 양태에서, 이 프로세스는 하나의 단계 프로세스로서 영향을 받을 수 있다. 예를 들어, 서명 부문에 제출된 어셈블리는 지연 서명되었지만 완전히 서명된 스키마 패키지를 리소스로서 미리 포함할 수 있다. 이에 따르면, 서명 부문은 툴을 이용하여 스키마 패키지를 추출하고, 이 패키지를 서명하며, 서명된 패키지를 어셈블리 내로 다시 삽입하고, 어셈블리를 최종적으로 서명할 수 있다.

이제 클라이언트측 어셈블리가 저장되는 위치와 이 어셈블리가 스키마 패키지와 함께 로딩가능한 방식에 대하여 설명해 보면, 도 7은 스키마 배포 컴포넌트(104)의 필수 구성요소들인 발견 컴포넌트(702) 및 로딩 컴포넌트(704)를 구비하는 시스템(700)을 도시하고 있다. 이러한 컴포넌트들의 각각의 새로운 기능성을 보다 상세히 후술한다.

클라이언트 애플리케이션이 저장소 내에 보존을 위해 스키마화 유형의 인스턴스의 인스턴싱을 행할 때마다, 클라이언트는, 예를 들어, 필요한 스키마가 저장소 내에 미리 이용가능하지 않은 경우에, 데이터를 제시하기 전에 저장소에 스키마 패키지를 제시해야 할 수 있다. 스키마 패키지를 제시하려면, 클라이언트는 스키마 패키지를 발견하고 로딩할 수 있어야 한다.

로딩 컴포넌트(704)를 참조해 보면, 이용할 수 있는 메카니즘의 2가지 유형이 가능한데, 정적 바인딩과 동적 바인딩이다. 그러나, 저장소 내에 지속시키기 전에 스키마 패키지의 위치를 먼저 파악(예를 들어, 발견)해야 한다. 이에 따라, 발견 컴포넌트(702)를 이용하여 전역적 액세스 캐시(GAC) 또는 로컬 저장소 또는 로컬 파일 시스템 내의 클라이언트측 어셈블리 및/또는 패키지의 위치를 파악할 수 있다. 다시 말하면, 예시적인 양태들에서, 사용자가 애플리케이션을 배치할 수 있는 2가지 선택이 가능하며, 즉, GAC 또는 로컬이다. 위치 결정 인자는 얼마나 많은 사용자들이 애플리케이션에 노출되는지일 수 있다. 게다가, 특정 유형에 대하여 애플리케이션을 코딩하는 방식에 대한 2가지 선택이 있다. 이러한 시나리오들의 각각을 후술한다.

배치를 위한 제1 선택은 GAC이며, 이것은 어셈블리가 모든 시간에 모든 사용자에게 노출된다는 것을 의미한다. GAC, 즉 전역적 어셈블리 캐시는, 애플리케이션(또는 이 애플리케이션의 일부분)이 배치될 수 있고 이에 따라 모든 사용자가 그 애플리케이션(또는 이 애플리케이션의 일부분)에 액세스하고 사용할 수 있게 하는 전역적 리소스이다. 제2 선택은 로컬이며, 이것은 그 애플리케이션(또는 이 애플리케이션의 일부분)이 특정한 위치에 세이브되며 액세스 및 사용에 대하여 단일 사용자(또는 유한 사용자들의 그룹)에게 한정된다는 것을 의미한다.

코딩에 있어서는, 2가지 선택이 이용가능하며, 즉, 정적 바인딩(static binding) 및 동적 바인딩(dynamic binding)이다. 사용자가 유형에 대하여 알고 있고 알려져 있는 유형에 대하여 코드를 명시적으로 기입하는 경우, 이것을 정적 바인딩이라 칭한다. 반면에, 동적 바인딩은, 사용자가 특정 유형에 대하여 알지 못하지만 코드가 실행중일 때 (예를 들어 발견 컴포넌트(702)를 통해) 특정 유형을 발견하도록 시스템에게 쿼리를 행할 수 있는 상황을 가리킨다. 일단 발견되면, 사용자는 그 유형에 대하여 동적으로 프로그래밍을 행할 수 있다.

다음의 표는, 발견 컴포넌트(702) 및 로딩 컴포넌트(704)의 새로운 기능성이 이러한 2가지 결정 중 임의의 것에 적용가능하다는 것을 예시한다.

	정적 바인딩	동적 바인딩
GAC	관리자에 의해 GAC에 어셈블러가 설치되며 컴파일 시간때 모든 유형들에 정적으로 바인딩하는 애플리케이션	관리자에 의해 GAC에 어셈블리가 설치되며 런타임시 동적으로 또는 프로그램 방식으로 유형들을 발견하는 애플리케이션
로컬	비관리자에 의해 파일 시스템에 어셈블리가 설치되며 컴파일 시간때 모든 유형들에 정적으로 바인딩하는 애플리케이션	비관리자에 의해 파일 시스템에 어셈블리가 설치되며 런타임시 동적으로 또는 프로그램 방식으로 유형들을 발견하는 애플리케이션

공통 언어 런타임(CLR) 플랫폼 상에서 개발된 코드가 컴퓨터에 걸친 여러 애플리케이션에 의해 공유되는 경우 이 코드가 흔히 GAC라 칭하는 머신-와이드(machine-wide) 캐시에 배치될 수 있다는 점을 인식할 것이다. GAC에 상주하는 어셈블리는, 서로 다른 코드 버전들을 나란히 실행(side-by-side execution)할 수 있게 하는 특정 버저닝 스킴(versioning scheme)을 고수해야 한다.

이 양태에서, GAC 설치된 애플리케이션은, 클라이언트측 어셈블리와 스키마 패키지 둘 다를 안전한 머신 전역적 방식으로 배치해야 하는 요구 사항을 갖는다. CLR이 이러한 요구 사항을 충족시키는 서비스를 GAC 및 이 GAC의 설치 서비스의 형태로 제공할 수 있다는 점을 이해하기 바란다. 또한, GAC가 이용되지 않는 경우 이러한 서비스가 스키마 패키지에 대하여 중복되어야 한다는 점을 이해 및 인식하기 바란다.

다른 양태를 참조해 보면, 로컬 애플리케이션은 자신의 어셈블리들을 잘 알려져 있는 위치에 설치한다. 이러한 애플리케이션에 대한 스키마 패키지는 이론적으로 동일한 위치에 배치될 수 있다. 그러나, 실제로는, 애플리케이션이 서로 다른 일련의 컴포넌트들로부터 만들어질 수 있다는 점을 이해할 것이다. 각 컴포넌트 자체는 하나 이상의 잘 알려져 있는 위치에 설치될 수 있다. 이러한 다수의 위 치로부터 이러한 어셈블리들의 발견 및 로딩이 특히 끊김없는 방식으로 용이해지도록 복잡한 바인딩 규칙이 CRL 존재할 수 있다. 기존의 인프라스트럭처가 효력을 발휘할 수 없다면 스키마 패키지에 대하여 이 바인딩 인프라스트럭처가 중복되어야 한다는 점을 이해할 것이다.

정적 바인딩된 애플리케이션들은, 컴파일 시간때 클래스들을 인스턴싱하고, 즉, 특정 클래스의 변수를 선언하고 새로운 연산자를 이용하여 그 클래스의 새로운 인스턴스를 생성하는 명시적 코드 라인을 포함한다. 이러한 클래스들을 위해, 특정 유형의 바인딩은 링크 시간때 충분히 자격있는 스트롱 네임 어셈블리로 변환되고 (퓨전 로딩 정책으로 인해) 추후에 로딩된다. 정적 애플리케이션들은 어셈블리들의 특정 세트에 바인딩되는 때에, 즉, 링크 시간에, 스키마 패키지들의 특정 세트에 바인딩된다.

반면에, 동적 바인딩된 애플리케이션은 런타임때 이 순간의 조건에 기초하여 루틴 또는 오브젝트를 링크한다. 동적 애플리케이션은 사용자 개시 발견의 결과로 유형을 동적으로 로딩한다. 예를 들어, Visual Studio 브랜드 애플리케이션은 폼 설계 단계(form design phase) 동안 제어들을 포함하는 어셈블리들을 사용자가 선택할 수 있게 한다. 이 예에서, 어셈블리들이 로딩된 후 제어들이 제어 툴바를 통해 인스턴싱될 수 있다.

물론, 동적 애플리케이션은 종종 유형을 프로그램 방식으로 로딩할 수 있다. 예를 들어, Word 브랜드 애플리케이션은 등록된 애드인(Add-In)들의 리스트를 유지할 수 있다. 이후, 각 애드인은 리스트로부터 프로그램 방식으로 로딩될 수 있고 이후 인스턴싱될 수 있다.

동작시, 동적 애플리케이션들은 런타임 때에만 스키마 패키지들의 특정 세트에 바인딩된다. 게다가, 이 스키마 패키지들의 세트는 실행시마다 그리고 동일한 실행에서 시간 경과에 따라 항상 유동적일 수 있다. 애플리케이션들의 두 가지 유형, 예를 들어, 정적 유형 또는 동적 유형에서, 한 유형에 대한 스키마 패키지는 클라이언트측 어셈블리가 발견될 수 있는 모든 상황에서 발견가능해야 한다. 이것은 본 발명의 메카니즘의 새로운 특징이다. 다시 말하면, 클라이언트측 어셈블리 내에 스키마 패키지를 포함하는 것은 본 발명의 새로운 특징이며 이에 따라 어셈블리를 발견하는 데 사용되는 정확하게 동일한 인프라스트럭처가 스키마 패키지의 발견에 효력을 발휘할 수 있음을 보장하게 된다.

정확한 동작을 위해, 애플리케이션은, 인스턴싱을 행할 것으로 예상되는 모든 유형에 대하여 클라이언트측 어셈블리 및 스키마 패키지를 배치해야 한다. 설치 및 배치 인프라스트럭처는 어셈블리들을 GAC 및 로컬 방식 둘 다에 배치할 수 있다. 애플리케이션에 대하여 스키마 패키지를 배치하지 못함으로써 애플리케이션의 상호 레벨(cross-level) 버저닝 시나리오, 즉, 필요한 스키마를 갖고 있지 않는 저장소 내로 인스턴스들이 지속되는 시나리오가 실패하게 된다는 점을 이해할 것이다.

순방향으로 보이는 성질 및 관련된 복잡성/비용 때문에, 상호 레벨 버저닝 시나리오들은 때때로 소프트웨어 이송 전에 거의 충분히 테스트되지 않는다. 소프트웨어 개발 프로세스가 설계시 상호 레벨 버저닝 시나리오들에 대한 요구 사항들 을 강화하지 않으면, 이러한 요구 사항들은 테스트 및 배치 동안 간과될 수 있어서 테스트되지 않은 시나리오에 대한 분야에서 소프트웨어가 실패하게 된다. 이처럼, 소프트웨어 개발 프로세스가 설계시 충분한 제약들을 강화해야 하는 것은 설계 요구 사항이서서 본 명세서에서 제공되는 인프라스트럭처를 이용하여 이러한 시나리오들에 대한 배치를 쉽고 에러 없이 행할 수 있다. 클라이언트측 어셈블리 내에 스키마 패키지를 포함함으로써, 어셈블리를 배치를 위한 정확하게 동일한 인프라스트럭처가 스키마 패키지의 배치에 효력을 발휘할 수 있음을 보장하게 된다. 개발자 및 배치 툴이 어셈블리 배치에 의해 제시되는 이슈들에 가장 친숙한다는 점을 인식할 것이다. 개발 시간 체크를 포함함으로써, 스키마 패키지가 클라이언트측 어셈블리 내에 리소스로서 적절히 컴파일링되었음을 보장할 수 있다. 유사한 이유로 런타임 체크도 유익하다.

다른 양태들에서 그리고 전술한 바와 같이, 다수의 스키마 패키지들이 하나의 클라이언트측 어셈블리 내에 포함될 수 있다. 이에 따라, 리소스 네이밍(naming)에 대하여, 임의의 특정 스키마에 대응하는 스키마 패키지는, 그 특정 스키마를 위해 사용되는 스트롱 네임에 기초하는 리소스 네임으로의 일대일 매핑에 의해 식별될 수 있다.

다수의 스키마 시나리오들에 있어서, 클라이언트측 어셈블리와 스키마 패키지 사이의 관계가 효력을 발휘하기 위해 일치 및 서명 속성들이 여전히 충족된다는 점을 인식할 것이다. 다시 말하면, 다수의 스키마 패키지들이 서로 다른 스트롱 네임들로 존재하더라도, 이들은 동일한 키에 의해 모두 서명되어 클라이언트측 어 셈블리와 스키마 패키지 사이의 관계를 유지할 수 있으며, 하나의 키만을 이용하여 어셈블리에 서명을 행할 수 있다.

전술한 바와 같이, 선택 사항으로, 다른 양태들에 대하여 압축, 암호화, 인증코드 서명을 이용할 수 있다. 스키마 파일들의 사이즈가 클 수 있기 때문에, 흔히 압축을 이용하여 파일 크기의 관리가능성을 지원한다. 다른 양태에서 압축은 스키마가 서명되기 전에 또는 후에 적용될 수 있다. 스키마 서명 후에 압축을 적용하는 것은 적어도 2가지 이유로 특히 선호될 수 있다. 첫번째로는, 해싱이 일반적으로 원래의 XML 콘텐츠에 대하여 수행된다. 두번째로는, 타이밍으로 인해 서명 블록이 충분히 압축되기 때문에 일반적으로 보다 양호한 압축을 얻을 수 있다. 스키마 검증 동안, 스키마 패키지를 먼저 압축 해제한 후 검증한다.

다른 양태에 따르면, 스키마 패키지는 위성 어셈블리일 수 있다. 이 방안에서는, 스키마가 클라이언트측 어셈블리 내에 바로 임베딩되지 않는다. 대신에, 스키마는 매니페스트 리소스로서 별도의 위성 어셈블리이다. 서명 프로세스는, 메인 어셈블리와 위성 어셈블리 둘 다가 서명 부문에 제출될 수 있는 것이며, 스키마 파일에 먼저 서명한 후 위성 어셈블리에 대하여 해싱하는 메인 어셈블리에 서명한다.

또다른 양태에서, 스키마 패키지는 별도의 파일로서 유지될 수 있다. 스키마 패키지 자체는, 개발자에 의해 별도의 구축 단계로서 생성될 수 있고, 설치자에 의해 별도의 파일로서 배치될 수 있으며, 로더/바인더에 의해 별도로 발견될 수 있다. 개발 프로세스는, 설명하는 본 발명에서 끊김없이 행해질 수 있는 별도의 단계들이 개발자에 의해 수행될 필요가 있기 때문에 잠재적으로 어려울 수 있다. 게 다가, 이러한 양태의 배치 프로세스는 비동기될 수 있는 추가 단계들을 필요로 하기 때문에 어려울 수 있다. 이러한 스키마 패키지의 적합한 배치의 불일치 또는 무시로 인해 애플리케이션이 흔히 이송 전에 적절히 테스트받지 않을 수 있는 시나리오에서 부분적으로 실패할 수 있다. 발견 프로세스는 전역적 배치 및 동적 발견의 문제점들을 다루도록 추가 인프라스트럭처를 요구한다. 이러한 다른 양태들은 본 발명의 범위 및 본 발명의 청구범위에 속하는 것으로 간주된다.

전술한 바와 같이, 전술한 시스템들에 따라 임의의 공중/비밀 암호 키 쌍을 이용할 수 있다. 일 예에서는, 공중 키 암호화 기술을 이용하여 스키마 패키지를 네이밍 (및 서명)할 수 있다. 공중 키 암호화는, 공중 및 비밀 컴포넌트를 포함하는 2파트 키(예를 들어, 고유 코드)를 사용하는 암호화 방법을 가리킬 수 있다. 메시지를 암호화하기 위해, 전송자에게만 알려진 미공개 비밀 키를 이용한다. 이에 따라, 메시지를 해독하려면, 수신인은 전송자의 공개된 공중 키를 이용한다. 다시 말하면, 공중 키는 2파트 중 공개 파트, 즉, 공중 키 암호화 시스템을 가리킬 수 있다.

키 쌍 중 비밀 키는 소유자에게만 알려져 있다. 이에 따라, 스키마 제작자는 미공개 비밀 키를 이용하여 스키마 패키지에 암호 방식으로 서명할 수 있다. 이 암호 보안성 방법은 스키마 정보의 인증성 및 무결성을 크게 향상시킬 수 있다. 또한, 본 발명의 사상 및 범위 그리고 청구범위로부터 벗어나지 않고서 데이터를 고유하게 네이밍하고 그리고/또는 서명하는 임의의 방법을 이용할 수 있음을 이해해야 한다.

이제 도 8을 참조해 보면, 스키마 패키징, 배포, 이용가능성의 개시된 아키텍처를 실행하도록 동작가능한 컴퓨터의 블록도가 예시되어 있다. 본 발명의 다양한 양태들을 위한 추가 문맥을 제공하기 위해, 도 8 및 다음에 따르는 설명은 본 발명의 다양한 양태들이 구현될 수 있는 적합한 컴퓨팅 환경(800)의 간략하고 일반적인 설명을 제공하고자 한다. 하나 이상의 컴퓨터 상에서 실행될 수 있는 컴퓨터 실행가능 명령어들의 일반적인 문맥으로 본 발명을 전술하였지만, 본 발명이 다른 프로그램 모듈들과 조합되어 그리고/또는 하드웨어와 소프트웨어의 조합으로서 구현될 수도 있다는 점을 당업자라면 인식할 것이다.

일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정 추상 데이터 유형을 구현하는 루틴, 프로그램, 컴포넌트, 데이터 구조 등을 포함한다. 게다가, 당업자라면 본 발명의 방법이 퍼스널 컴퓨터, 핸드-헬드 컴퓨팅 장치, 마이크로프로세서 기반 또는 프로그래밍가능 가전제품 뿐만 아니라 싱글 프로세서 또는 멀티프로세서 컴퓨터 시스템, 미니컴퓨터, 메인프레임 컴퓨터를 포함하는 다른 컴퓨터 구성으로 실시될 수 있고 이러한 장치들의 각각이 하나 이상의 관련 장치들에 동작가능하게 결합될 수 있다는 점을 인식할 것이다.

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

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

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

도 8을 다시 참조해 보면, 본 발명의 다양한 양태들을 구현하기 위한 예시적인 환경(800)은, 컴퓨터(802), 처리 유닛(804)을 포함하는 컴퓨터(802), 시스템 버스(806), 및 시스템 버스(808)를 포함한다. 시스템 버스(808)는 시스템 메모리(806)를 포함한 시스템 컴포넌트들을 처리 유닛(804)에 결합하지만, 이러한 예로 한정되지는 않는다. 처리 유닛(804)은 상업적으로 이용가능한 다양한 프로세스들 중 임의의 것일 수 있다. 듀얼 마이크로프로세서 및 기타 멀티프로세서 아키텍처를 처리 유닛(804)으로서 이용할 수도 있다.

시스템 버스(80)는, 상업적으로 이용가능한 다양한 버스 아키텍처들 중 임의의 것을 이용하여 (메모리 제어기를 갖춘 또는 갖추지 않은) 메모리 버스, 주변 버스, 로컬 버스에 더 상호접속할 수 있는 버스 구조의 여러 유형들 중 임의의 것일 수 있다. 시스템 메모리(806)는 ROM(810) 및 RAM(812)을 포함한다. 기본 입력/출력 시스템(BIOS)은 ROM, EPROM, EEPROM과 같은 비휘발성 메모리(810)에 저장되고, 이 BIOS는 예를 들어 기동 동안 컴퓨터(802) 내의 소자들 사이에 정보 전달을 돕는 기본 루틴들을 포함한다. RAM(812)은 데이터를 캐싱하기 위해 SRAM과 같은 고속 RAM을 포함할 수도 있다.

컴퓨터(802)는 내부 하드 디스크 드라이브(HDD; 814)(예를 들어, EIDE, SATA)를 더 포함하고, 이 내부 하드 디스크 드라이브(814)는, 적절한 샤시(chassis; 도시하지 않음), (예를 들어, 분리식 디스켓(818)에 대한 판독 또는 기입을 위한) 자기 플로피 디스크 드라이브(FDD; 816), (예를 들어, CD-ROM 디스크(822)를 판독하거나 DVD와 같은 기타 대용량 광학 매체에 대한 판독이나 기입을 위한) 광 디스크 드라이브(820)에서의 외부 사용을 위해 구성될 수도 있다. 하드 디스크 드라이브(814), 자기 디스크 드라이브(816), 및 광 디스크 드라이브(820)는, 각각, 하드 디스크 드라이브 인터페이스(824), 자기 디스크 드라이브 인터페이스(826), 광 드라이브 인터페이스(828)에 의해 시스템 버스(808)에 접속될 수 있다. 외부 드라이브 구현을 위한 인터페이스(824)는 USB(Universal Serial Bus) 및 IEEE 1394 인터페이스 기술들 중 적어도 하나 또는 둘 다를 포함한다. 기타 외부 드라이브 접속 기술들은 본 발명의 범위에 속한다.

드라이브들 및 이들과 관련된 컴퓨터 판독가능 매체는, 데이터, 데이터 구조, 컴퓨터 실행가능 명령어 등의 비휘발성 저장소를 제공한다. 컴퓨터(802)를 위해, 드라이브 및 매체는 적합한 디지털 포맷으로 임의의 데이터의 저장소를 수용한다. 전술한 컴퓨터 판독가능 매체의 설명이 HDD, 분리식 자기 디스켓, CD나 DVD와 같은 분리식 광학 매체를 가리키지만, zip 드라이브, 자기 카세트, 플래시 메모리 카드, 카트리지 등과 같이 컴퓨터에 의해 판독가능한 다른 유형의 매체도 예시적인 운영 환경에서 이용될 수 있으며, 또한, 이러한 매체가 본 발명의 방법들을 수행하기 위한 컴퓨터 실행가능 명령어들을 포함할 수 있음을 당업자라면 인식해야 한다.

다수의 프로그램 모듈은, 운영 체제(830), 하나 이상의 애플리케이션(832), 기타 프로그램 모듈(834), 프로그램 데이터(836)를 비롯하여, 드라이브 및 RAM(812)에 저장될 수 있다. 운영 체제, 애플리케이션, 모듈, 및/또는 데이터의 전부 또는 일부는 RAM(812) 내에 캐싱될 수도 있다. 본 발명이 상업적으로 이용가능한 다양한 운영 체제 또는 운영 체제들의 조합으로 구현될 수 있음을 인식할 것 이다.

사용자는 예를 들어 키보드(838) 및 마우스(840)와 같은 포인팅 장치인 하나 이상의 유선/무선 입력 장치를 통해 커맨드 및 정보를 컴퓨터(802)에 입력할 수 있다. 기타 입력 장치들(도시하지 않음)은 마이크로폰, IR 원격 제어, 조이스틱, 게임 패드, 스타일러스 펜, 터치 스트린 등을 포함할 수 있다. 이러한 입력 장치들 및 다른 입력 장치들은, 흔히 시스템 버스(808)에 결합된 입력 장치 인터페이스(842)를 통해 처리 유닛(804)에 접속되지만, 병렬 포트, IEEE 1394 직렬 포트, 게임 포트, USB 포트, IR 인터페이스 등과 같은 기타 인터페이스들에 의해 접속될 수 있다.

또한, 모니터(844) 또는 다른 유형의 디스플레이 장치는 비디오 아답터(846)와 같은 인터페이스를 통해 시스템 버스(808)에 접속된다. 모니터(844) 외에도, 컴퓨터는 통상적으로 스피커, 프린터 등과 같은 기타 주변 출력 장치들(도시하지 않음)을 포함한다.

컴퓨터(802)는 원격 컴퓨터(848)와 같은 하나 이상의 원격 컴퓨터로의 유선 및/또는 무선 통신을 통한 논리적 접속을 사용하여 네트워크화된 환경에서 동작할 수 있다. 원격 컴퓨터(848)는 워크스테이션, 서버 컴퓨터, 라우터, 퍼스널 컴퓨터, 휴대용 컴퓨터, 마이크로프로세서 기반 엔터테인먼트 기기, 피어 장치 또는 기타 통상의 네트워크 노드일 수 있고, 통상적으로 컴퓨터(802)와 관련하여 상술된 구성요소들의 대부분 또는 그 전부를 포함하며, 편의상, 하나의 메모리/저장 장치(850)만이 예시되어 있다. 도시된 논리적 접속으로는 LAN(952) 및/또는 보다 큰 네트워크인 예를 들어 WAN(854)에 대한 유선/무선 접속가능성을 포함한다. 이러한 LAN 및 WAN 네트워킹 환경은, 사무실 및 회사에서 일반적인 것이며, 인트라넷과 같은 전사적 컴퓨터 네트워크(enterprise-wide computer network)를 용이하게 하며, 이들 모두는 전역적 통신 네트워크, 예를 들어, 인터넷에 접속될 수 있다.

LAN 네트워킹 환경에서 사용될 때, 컴퓨터(802)는 유선 및/또는 무선 통신 네트워크 인터페이스 또는 아답터(856를 통해 로컬 네트워크(852)에 접속된다. 아답터(856)는 LAN(852)에 대한 유선 또는 무선 통신을 용이하게 할 수 있으며, 또한 유선 아답터(856)와의 통신을 위해 아답터 상에 배치된 무선 액세스 포인트를 포함할 수 있다.

WAN 네트워킹 환경에서 사용될 때, 컴퓨터(802)는 모뎀(858)을 포함할 수 있고, 또는 WAN(854) 상의 통신 서버에 접속되며, 또는 인터넷과 같은 WAN(854)을 통해 통신을 설정하기 위한 기타 수단을 구비한다. 내장형 또는 외장형일 수 있으며 유선 또는 무선 장치일 수 있는 모뎀(858)은 직렬 포트 인터페이스(842)를 통해 시스템 버스(808)에 접속된다. 네트워크화된 환경에서, 컴퓨터(802) 또는 그의 일부와 관련하여 기술된 프로그램 모듈은 원격 메모리/저장 장치(850)에 저장될 수 있다. 도시된 네트워크 접속은 예시적인 것이며 이 컴퓨터들 사이에 통신 링크를 설정하는 기타 수단이 사용될 수 있다는 것을 이해할 것이다.

컴퓨터(802)는, 예를 들어, 프린터, 스캐너, 데스크탑 및/또는 휴대용 컴퓨터, PDA, 통신 위성, 무선 검출가능 태그에 관련된 위치나 장비(예를 들어, 정자, 신문 가판대, 거실), 전화와 같이 무선 통신에 동작가능하게 배치된 임의의 무선 장치 또는 엔티티와 통신하도록 동작가능하다. 이것은 적어도 Wi-Fi 및 Bluetooth(등록 상표) 무선 기술들을 포함한다. 따라서, 통신은 종래의 네트워크에서처럼 사전 정의된 구조일 수 있고 또는 단순히 적어도 2개의 장치 사이의 애드혹(ad hoc) 통신일 수 있다.

Wi-Fi, 즉, 와이파이(Wireless Fidelity)는, 집의 소파, 호텔 룸의 침대, 또는 집무 중인 회의실에서 인터넷으로의 무선 접속을 가능하게 한다. Wi-Fi는, 이러한 장치들, 실내외에서 예를 들어 기지국의 범위 내라면 어디에서든 컴퓨터들이 데이터를 송수신할 수 있게 하는 셀폰에서 사용되는 기술과 유사한 무선 기술이다. Wi-Fi 네트워크는, 안전하고 신뢰성있으며 빠른 무선 접속성을 제공하는 IEEE 802.11(a, b, g, 등)이라 칭하는 무선 기술이다. 컴퓨터들을 서로, 인터넷에, (IEEE 802.3 또는 이더넷을 사용하는) 유선 네트워크에 접속하는 데 Wi-Fi 네트워크를 이용할 수 있다. Wi-Fi 네트워크는, 라이센싱되지 않은 2.4 및 5Ghz 무선 대역에서 또는 이러한 두 개의 대역을 포함하는 제품을 이용하여 11 Mbps(802.11a) 또는 54Mbps(802.11b)의 데이터 속도로 동작하고, 이에 따라 네트워크는 많은 사무실에서 사용되는 베이직 10BaseT 유선 이더넷 네트워크와 유사한 현실 세계 성능을 제공할 수 있다.

이제 도 9를 참조해 보면, 본 발명의 스키마 패키징, 배포, 이용가능성 시스템에 따른 예시적인 컴퓨팅 환경(900)의 개략적인 블록도가 도시되어 있다. 이 시스템(900)은 하나 이상의 클라이언트(902)를 포함한다. 클라이언트(902)는 하드웨어 및/또는 소프트웨어(예를 들어, 스레드, 프로세스, 컴퓨팅 장치)일 수 있다. 클라이언트(902)는 예를 들어 본 발명을 이용함으로써 쿠키 및/또는 관련 문맥 정보를 수용할 수 있다.

또한, 시스템(900)은 하나 이상의 서버(904)를 포함한다. 서버(904)도 하드웨어 및/또는 소프트웨어(예를 들어, 스레드, 프로세스, 컴퓨팅 장치)일 수 있다. 서버(904)는 예를 들어 본 발명을 이용함으로써 변환을 수행하는 스레드를 수용할 수 있다. 클라이언트(902)와 서버(904) 사이에 한 가지 가능한 통신은, 2개 이상의 컴퓨터 프로세스 사이에 전송되도록 적응되는 데이터 패킷의 형태일 수 있다. 데이터 패킷은 예를 들어 쿠키 및/또는 관련 문맥 정보를 포함할 수 있다. 시스템(900)은, 클라이언트(902)와 서버(904) 사이의 통신을 용이하게 하는 데 이용될 수 있는 통신 프레임워크(906)(예를 들어, 인터넷과 같은 글로벌 통신 네트워크)를 포함한다.

(광섬유를 포함한) 유선 및/또는 무선 기술에 의해 통신이 용이해질 수 있다. 클라이언트(902)는, 클라이언트(902)에 대하여 로컬인 정보(예를 들어, 쿠키 및/또는 관련 문맥 정보)를 저장하는데 이용될 수 있는 하나 이상의 클라이언트 데이터 저장소(908)에 동작가능하게 접속된다. 마찬가지로, 서버(904)는, 서버(904)에 대하여 로컬인 정보를 저장하는 데 이용될 수 있는 하나 이상의 서버 데이터 저장소(910)에 동작가능하게 접속된다.

전술한 것은 본 발명의 예들을 포함한다. 물론, 본 발명을 설명하기 위해 컴포넌트들 또는 방법들의 생각할 수 있는 모든 조합을 설명하지 못할 수 있지만, 본 발명의 많은 추가 조합들 및 순열들이 가능하다는 점을 당업자라면 인식할 수 있다. 이에 따라, 본 발명은 청구범위의 사상 및 범위에 속하는 이러한 모든 변경, 수정, 변동을 포함하는 것이다. 게다가, "포함"(include)이라는 용어가 상세한 설명이나 청구범위에서 사용되는 정도까지, 이러한 용어는, "포함"(comprise)이 이용시 청구항에서 통상적인 단어로 해석되기 때문에 "포함"(comprise)이라는 용어와 유사한 방식으로 포괄적인 것이다.

Claims (20)

1. 컴퓨터 판독가능 저장 매체 상에 구현되어, 스키마(schema)를 이용하게 하는 시스템으로서,

   상기 스키마를 정의하는 스키마 패키지를 생성하는 패키징 컴포넌트 - 상기 패키징 컴포넌트는 클라이언트측 어셈블리(client-side assembly) 및 상기 스키마 패키지를 암호 키(cryptographic key)로 서명하고, 상기 클라이언트측 어셈블리 내의 리소스로서 상기 스키마 패키지를 포함함 - ; 및

   배포 컴포넌트(distribution component) - 상기 배포 컴포넌트는, 상기 클라이언트측 어셈블리를 동작시키는 클라이언트 머신 상에서 실행될 때, 상기 클라이언트측 어셈블리가 상기 스키마에 의해 정의된 스키마화된 유형의 인스턴스를 인스턴싱하면 상기 스키마 패키지를 발견하고 상기 클라이언트측 어셈블리에 의해 상기 스키마가 이용되게 함 -

   를 포함하는, 시스템.
2. 제1항에 있어서,

   상기 패키징 컴포넌트는 상기 암호 키를 이용하여 상기 스키마 패키지 및 상기 클라이언트측 어셈블리 간의 고유 관계(intrinsic relationship)를 생성하고, 상기 고유 관계에 의해 상기 클라이언트측 어셈블리가 상기 스키마 패키지를 발견 및 액세스하도록 하는, 시스템.
3. 제2항에 있어서,

   상기 스키마 패키지는 스키마 정의 언어(schema definition language; SDL) 다큐먼트인, 시스템.
4. 제2항에 있어서,

   상기 패키징 컴포넌트는 상기 서명된 스키마 패키지를 상기 클라이언트측 어셈블리에 대한 위성 어셈블리로서 배치하는, 시스템.
5. 제2항에 있어서,

   상기 패키징 컴포넌트는 상기 서명된 스키마 패키지를 상기 클라이언트측 어셈블리로부터의 별도의 파일로서 배치하는, 시스템.
6. 제2항에 있어서,

   상기 배포 컴포넌트는,

   상기 스키마 패키지 및 상기 클라이언트측 어셈블리 간의 상기 고유 관계에 적어도 부분적으로 기초하여, 상기 클라이언트측 어셈블리에 의해 상기 스키마 패키지의 위치를 파악하게 하는 발견 컴포넌트; 및

   상기 클라이언트측 어셈블리가 상기 스키마 패키지를 액세스하게 하는 로딩 컴포넌트

   를 포함하는, 시스템.
7. 제2항에 있어서,

   상기 패키징 컴포넌트는 공통 암호 키를 이용하여 상기 스키마 패키지 및 상기 클라이언트측 어셈블리에 서명하는, 시스템.
8. 제2항에 있어서,

   상기 서명된 스키마 패키지를 개인 및 조직 중 적어도 하나와 연관시키는 인증코드(authenticode) 컴포넌트를 더 포함하는, 시스템.
9. 제2항에 있어서,

   상기 서명된 스키마 패키지를 압축하고 상기 스키마 패키지의 전송 오버헤드를 감소시키는 압축 컴포넌트를 더 포함하는, 시스템.
10. 제2항에 있어서,

    상기 서명된 스키마 패키지를 암호화하기 위한 암호화 컴포넌트를 더 포함하는, 시스템.
11. 스키마를 배포하기 위해 컴퓨터로 구현된 방법으로서,

    상기 스키마를 정의하는 스키마 패키지를 생성하는 단계;

    상기 스키마 패키지를 암호 키로 서명하는 단계;

    클라이언트측 어셈블리를 상기 암호 키로 서명하는 단계;

    상기 클라이언트측 어셈블리에게 상기 스키마 패키지를 발견할 권한을 부여하는 상기 암호 키를 포함하는 스트롱 네임 서명에 기초하여, 상기 클라이언트측 어셈블리 및 상기 스키마 패키지 간의 고유 관계를 형성하는 단계; 및

    상기 스트롱 네임 서명에 기초하여 형성된 상기 고유 관계에 적어도 부분적으로 기초하여, 상기 스키마 패키지를 상기 클라이언트측 어셈블리 내의 임베디드 리소스(embedded resource)로서 배포하는 단계

    를 포함하는, 컴퓨터로 구현된 방법.
12. 제11항에 있어서,

    상기 서명된 스키마 패키지를 상기 클라이언트측 어셈블리 내의 리소스로서 임베딩하는 단계를 더 포함하는, 컴퓨터로 구현된 방법.
13. 제11항에 있어서,

    상기 스키마 패키지를 상기 클라이언트측 어셈블리에 대한 위성 어셈블리로서 지정하는 단계를 더 포함하는, 컴퓨터로 구현된 방법.
14. 제11항에 있어서,

    상기 스키마 패키지로부터 별도의 파일을 발생시키고, 상기 별도의 파일을 상기 클라이언트측 어셈블리에 관련시키는 단계를 더 포함하는, 컴퓨터로 구현된 방법.
15. 제11항에 있어서,

    상기 배포하는 단계는,

    상기 암호 키에 적어도 부분적으로 기초하여 상기 스키마 패키지를 발견하는 단계; 및

    상기 클라이언트측 어셈블리에 의해 이용되도록 상기 스키마 패키지를 로딩하는 단계

    를 더 포함하는, 컴퓨터로 구현된 방법.
16. 제11항에 있어서,

    상기 스키마 패키지를 특정 개인 및 조직 중 적어도 하나에 연관시키는 단계를 더 포함하는, 컴퓨터로 구현된 방법.
17. 제11항에 있어서,

    상기 배포하는 단계 전에 상기 스키마 패키지를 압축하는 단계를 더 포함하는, 컴퓨터로 구현된 방법.
18. 제11항에 있어서,

    상기 배포하는 단계 전에 상기 스키마 패키지를 암호화하는 단계를 더 포함하는, 컴퓨터로 구현된 방법.
19. 컴퓨터 판독가능 저장 매체 상에 구현되어, 스키마 패키지를 배포하기 위한 시스템으로서,

    스키마를 정의하는 스키마 패키지를 발생시키는 수단;

    상기 스키마 패키지를 암호 키로 서명하는 수단;

    클라이언트측 어셈블리를 상기 암호 키로 서명하는 수단;

    상기 클라이언트측 어셈블리에게 상기 스키마 패키지를 발견할 권한을 부여하는 상기 암호 키를 포함하는 스트롱 네임 서명에 기초하여, 상기 클라이언트측 어셈블리 및 상기 스키마 패키지 간의 고유 관계를 설정하는 수단;

    상기 스키마 패키지를 상기 클라이언트측 어셈블리의 리소스로서 상기 클라이언트측 어셈블리 내에 임베딩하는 수단;

    상기 스키마 패키지를 상기 클라이언트측 어셈블리와 함께 배포하는 수단; 및

    상기 클라이언트측 어셈블리가 상기 스키마에 의해 정의된 스키마화된 유형의 인스턴스를 인스턴싱할 때, 상기 클라이언트측 어셈블리에 의해 이용되도록 상기 스키마 패키지를 자동 발견하는 수단

    을 포함하는, 시스템.
20. 제19항에 있어서,

    상기 스키마 패키지 내에 포함된 스키마화된 유형을 상기 클라이언트측 어셈블리에 의해 인스턴싱하는 경우, 상기 스키마 패키지를 자동 액세스하는 수단을 더 포함하는, 시스템.

Images