KR20060112590A

KR20060112590A - 객체 시스템 간의 파일 속성 관리를 용이하게 하기 위한프로모션 및 디모션 기술

Info

Publication number: KR20060112590A
Application number: KR1020057012360A
Authority: KR
Inventors: 프래잔나 브이. 크리스난; 삼바비 머터크리스난; 사미트 에이치. 아가왈; 발랜 세투 라맨; 마이클 이. 딤
Original assignee: 마이크로소프트 코포레이션
Priority date: 2003-10-23
Filing date: 2004-07-27
Publication date: 2006-11-01
Also published as: MXPA05007144A; AU2004287137A1; TWI359374B; WO2005045575A2; EP1634145A4; NZ540655A; NO20052799L; NO20052799D0; MY137808A; RU2348973C2; RU2005120652A; WO2005045575A3; AU2004287137B2; IL169465A0; US20050091285A1; CN1867911B; CA2511528A1; US7155444B2; JP2007509415A; CN1867911A

Abstract

본 발명은 이종 데이터 시스템들 간에 상호운용 및 호환성을 용이하게 하는 시스템 및 방법에 관한 것이다. 일 특징에서, 하나 이상의 비구조화 속성과 연관되는 적어도 하나의 파일을 갖는 파일 변형 시스템이 제공된다. 파일 속성 핸들러는, 구조화 객체 저장소 환경과 연관되는 하나 이상의 구조화 속성에 따라 비구조화 속성을 조작한다. 비구조화 파일이 구조화 객체 저장소 환경의 정황에서 동작될 것이면, 구조화 객체 저장소 환경의 동작에 적절한 구조화 속성으로 파일의 비구조화 속성을 갱신하기 위해 프로모션 동작이 수행된다. 프로모트된 아이템이 구조화 객체 저장소 환경에서 조작될 것이면, 파일의 속성을 갱신하기 위해 디모션 동작 또는 역 변형이 수행된다.

구조화 속성, 파일 속성 관리자, 파일 속성 핸들러, 프로모트, 디모트

Description

객체 시스템 간의 파일 속성 관리를 용이하게 하기 위한 프로모션 및 디모션 기술{PROMOTION AND DEMOTION TECHNIQUES TO FACILITATE FILE PROPERTY MANAGEMENT BETWEEN OBJECT SYSTEMS}

본 발명은 컴퓨터 시스템에 관한 것으로, 특히 파일 속성(file properties)의 프로모션(promotion) 및 디모션(demotion)을 통하여 파일의 구조화 객체 표현(structured object representations)과 바이트 스트림(byte streams)의 비구조화 파일 속성 저장(unstructured file property storage) 간의 호환성(compatibility)을 용이하게 하기 위해 파일 속성 핸들러(file property handlers)를 채용하는 시스템 및 방법에 관한 것이다. 일반적으로, 본 명세서에서 채용되는 용어 아이템은 구조화 객체 저장소(structured object store)에 저장되는 구조화된 도식화된 객체(structured, schematized object)를 말한다. 파일 후원 아이템(file-backed item)은 객체 저장소의 파일의 구조화 객체 표현을 말한다. 용어 파일은 주어진 파일 후원 아이템에 대응하는 비구조화 바이트 스트림을 표현하기 위해 사용될 수 있다.

[관련 출원]

본 출원은, 2003년 10월 23일 출원된 미국 특허출원 제10/693,090호, "PROMOTION AND DEMOTION TECHNIQUES TO FACILITATE FILE PROPERTY MANAGEMENT BETWEEN OBJECT SYSTEMS"를 우선권으로 주장하고, 이는 본 명세서에 참조로서 모두 포함된다.

종래에, 컴퓨터 파일 시스템에서, 파일은 데이터 저장의 기본 단위이다. 일반적으로, 파일 시스템의 파일은 다음의 특성을 갖는다. 그것은 바이트의 단일 시퀀스(single sequence)이다. 그것은 유한한 길이를 갖고 비휘발성 저장 매체(non-volatile storage medium)에 일반적으로 저장된다. 그것은 디렉토리에 생성되고 이름(name)을 갖는데, 파일은 아마 그것의 경로와 함께 파일 동작(file operations)에서 이름에 의해 참조될 수 있다. 또한, 파일 시스템은 허가 비트(permission bits) 또는 다른 파일 특질(file attributes)(파일 생성, 최종 개정 및 최종 액세스 등에 대한 타임스탬프)과 같은 다른 정보를 파일과 연관시킬 수 있다. 또한, 특정 애플리케이션은 파일의 바이트 스트림으로 도메인 특정 속성(domain-specific properties)을 저장할 수 있다. 예컨대, 워드 프로세싱 애플리케이션에 의해 사용되는 파일 - 그래서 '문서(documents)'로서 간주됨 - 은 문서의 제목 및 저자와 같은 속성을 저장할 수 있다. 이들 속성은, 파일을 생성하는 애플리케이션에 특정한 포맷으로 파일의 바이트 스트림 내에 저장된다. 속성은 객체로서 구조화되지 않고, 표준화된 이름을 가지지 않는다. 바이트 스트림은 비구조화 값(unstructured values)이다. 다른 예는, 음악 클립(music clip)을 저장하는 파일이, 바이트 스트림으로 저장되는 장르(Genre), 저자, 기록일, 예술가 등과 같은 다수의 흥미로운 속성을 갖는 것이다. 이러한 메타 데이터(meta-data)에 추가하 여, 몇몇 범용적으로 인식되는 포맷(some universally recognized format)으로 음악 자체를 표현하는 바이트 스트림이 있다. 이들 속성을 취급하는 프로그래밍 모델은 전체 바이트 스트림을 조작(manipulating)하도록 연동된다(geared). 프로그래밍 모델은, 핸들이 바운드 인스턴스(bound instance)(CreateFile/OpenFile 호출의 결과)를 위해 제조되도록 하는 바인드-참조 모델(bind-reference model)이다. 값의 후속 조작은 ReadFile/WriteFile에 의해 행해져서, 바이트 스트림의 관련 부분을 검색(retrieve) 및 갱신한다.

[발명의 요약]

다음의 내용은, 본 발명의 몇몇 특징에 대한 기본적인 이해를 제공하기 위하여 본 발명의 간략화된 요약을 제시한다. 이 요약은 본 발명의 광범위한 개관(extensive overview)은 아니다. 본 발명의 중요한/중대한 요소를 식별하거나 본 발명의 범위를 묘사하려는 것은 의도되지 않는다. 이것의 유일한 목적은, 후에 제시되는 더 상세한 설명에 대한 서두로서 간략화된 형태로 본 발명의 몇몇 개념을 제공하는 것이다.

본 발명은, 독립하여 갱신될 때 동기화되는 파일의 구조화 객체 표현의 속성 및 바이트 스트림의 속성 저장을 이네이블시킴으로써 파일 바이트 스트림으로서 그리고 구조화 객체로서 파일 조작을 용이하게 하는 시스템 및 방법에 관한 것이다. 객체 저장소의 파일 후원 아이템을 조작하기 위한 그리고 비구조화 바이트스트림으로서 파일을 조작하기 위한 적절한 애플리케이션 프로그래밍 인터페이스가 있다는 것이 주어진다. 파일 속성 핸들러는, 프로모션 및 디모션이라고 하는 시스템 상호 작용, 메소드 및 절차(procedures)를 통하여 파일에 대한 파일 후원 아이템 표현에 적절히 매핑되고 일관되게 유지되도록 파일의 비구조화 속성을 이네이블시키도록 제공된다. 프로모션은, 파일에 대응하는 바이트 스트림을 직접 조작함으로써 파일을 수정 또는 조작하는 것을 애플리케이션이 시도할 때, 인보크된다(invoked). 그러므로, 프로모션은 프로세스인데, 이에 의해 파일 속성 핸들러는, 두 개의 환경들 간에 일관성을 획득하기 위하여 바이트 스트림의 비구조화 파일 속성을 애플리케이션이 갱신할 때, 객체 저장소의 비구조화 파일 속성을 갱신한다. 구조화 객체 저장소의 객체로의 비구조화 파일 속성의 프로모션은, 예컨대 다음과 같은 다양한 목적을 용이하게 한다.

a) 구조화 객체 저장소는 파일의 속성에 기초하여 파일의 충분한 질의를 허용한다. 일반적으로, 이것은 비구조화 바이트 스트림으로 저장되는 속성에는 가능하지 않다.

b) 비구조화 속성은 표준화된 객체 표현에 부착하는 잘 구조화된 객체(well-structured objects)로서 표현된다. 그러므로, 애플리케이션은, 바이트 스트림을 조작하는 모델보다 오히려 객체 지향 프로그래밍 모델을 사용하는 이들 객체와 용이하게 동작할 수 있다.

객체 저장소의 프로모트된 파일 후원 아이템이 조작되고 갱신되면, 파일 속성 핸들러는 디모션 프로세스를 용이하게 하는데, 여기서 역 변형(reverse transformation)은 구조화 객체의 변화에 대응하는 비구조화 파일의 속성을 갱신하도록 수행된다. 이러한 방식으로, 프로모션 및 디모션은, 파일 속성이, 가까운 장 래에 타겟 시스템에 대해 적절한 속성에 따라 자동으로 갱신 및 유지되는 것을 이네이블시킨다(예컨대, 프로모션 그리고 역으로는 디모션을 통하여 구조화 속성에 대한 비구조화 속성을 갱신).

본 발명의 일 특징에서, 브리지 콤포넌트(bridge component){예컨대, 파일 속성 관리자(file property manager)}는, 애플리케이션이 비구조화 파일에 대한 속성을 조작 및 저장할 때, 구조화 객체로 파일 바이트 스트림의 비구조화 속성의 변형을 유발하도록 파일 속성 핸들러(file property handler)와 통신한다. 파일 속성 관리자는, 객체 저장소에서 갱신될 수정된 비구조화 파일을 추적하기 위해 비구조화 파일 저장소에 의해 노출되는 메커니즘을 이용한다.

전술한 목적 및 관련 목적을 달성하기 위해, 본 발명의 특정 예시적인 특징은 다음의 설명 및 첨부된 도면과 함께 설명된다. 이들 특징은 본 발명이 실시될 수 있는 다양한 방법을 나타내고, 이들 모두는 본 발명에 의해 커버될 의도이다. 본 발명의 다른 이점 및 신규한 특징은 도면과 함께 읽으면 본 발명의 다음의 상세한 설명으로부터 자명할 것이다.

도 1은 본 발명의 특징에 따른 파일 변형 시스템의 개략적인 블록도.

도 2는 본 발명의 특징에 따른 더 상세한 파일 변형 시스템의 개략적인 블록도.

도 3 내지 도 6은 본 발명의 특징에 따라 속성 핸들러 및 파일 속성 관리자에 대한 자동화된 프로모션 및 디모션 프로세스를 도시하는 흐름도.

도 7은 본 발명의 특징에 따른 아이템에 대한 상태도.

도 8은 본 발명의 특징에 따른 적절한 동작 환경을 도시하는 개략적인 블록도.

도 9는 본 발명이 상호작용할 수 있는 샘플 컴퓨팅 환경의 개략적인 블록도.

[발명의 상세한 설명]

본 발명은, 특정 애플리케이션 프로그래밍 인터페이스를 통하여 다른 것과 독립하여 갱신될 때, 비구조화 바이트 스트림으로서의 파일과 구조화 객체가 일관되도록 이네이블함으로써 이들의 조작을 용이하게 하기 위한 시스템 및 방법론에 관한 것이다.

파일 속성 핸들러는, 대응하는 파일 후원 아이템과 연관되는 하나 이상의 구조화 객체 속성에 따라 파일의 비구조화 속성을 조작한다. 비구조화 파일 스트림이 직접 갱신될 때마다, 구조화 속성으로 파일 후원 아이템을 갱신하기 위해 프로모션 동작이 수행된다. 마찬가지로, 구조화 객체 환경에서 사용되는 애플리케이션 프로그래밍 인터페이스로 파일 후원 아이템이 조작되고 갱신되면, 디모션 동작 또는 역 변형이 파일의 비구조화 표현의 속성을 갱신하기 위해 수행된다.

본 출원에서 사용되는 바와 같이, 용어 "콤포넌트", "핸들러", "관리자", "시스템" 등은 컴퓨터 관련 엔티티(computer-related entity), 즉 하드웨어, 하드웨어 및 소프트웨어의 조합, 소프트웨어, 또는 실행 중의 소프트웨어를 의미하도록 의도된다. 예컨대, 콤포넌트는 프로세서 상에서 실행하는 프로세스, 프로세서, 객체, 실행가능(executable), 실행의 스레드(thread of execution), 프로그램, 및/또 는 컴퓨터일 수 있지만, 이들에 한정되는 것은 아니다. 설명의 방법으로, 서버 상에서 실행하는 애플리케이션 및 서버 양자 모두는 콤포넌트일 수 있다. 하나 이상의 콤포넌트는 프로세스 및/또는 실행의 스레드 내에 상주할 수 있고, 콤포넌트는 하나의 컴퓨터 상에 지역화되고(localized) 그리고/또는 두 개 이상의 컴퓨터들 간에 분산될 수 있다.

먼저 도 1을 참조하면, 본 발명의 특징에 따른 파일 변형 시스템(100)이 도시된다. 시스템(100)은, 일반적으로 하나 이상의 비구조화 파일(120)과 연관되는 시스템 또는 애플리케이션(110)을 포함하는데, 애플리케이션(110) 및 파일은 일반적으로 비구조화 파일 환경과 연관된다. 브리지 모듈(130) 및 파일 속성 핸들러(140)는, 일반적으로 구조화 객체 저장소 환경과 연관되는 구조화 객체 시스템 또는 애플리케이션(150)과의 통신 및 호환성을 용이하게 하기 위하여 제공된다. 일 예에서, 구조화 시스템 애플리케이션은, 예컨대 일반적으로 XML과 같은 코드와 연관되는 하나 이상의 개략화된 객체(schematized objects)와 "160"에서 연관될 수 있다.

파일이 비구조화 파일로서 수정, 저장, 및/또는 조작되려면, 브리지 모듈 또는 파일 속성 관리자(130)는 비구조화 파일로부터 구조화 객체로의 변형을 지시하도록(direct) 기능한다. 변형은 파일 속성 핸들러(140)를 인보크시키는 브리지 모듈에 의해 수행되고, 파일 속성 핸들러는 다시, 구조화 저장소(160)에 대항하여 동작하는 애플리케이션과 연관되는 구조화 객체로 비관리 파일(unmanaged file)의 비구조화 속성을 변형시키기 위해 프로모션 동작을 수행한다. 프로모트된 객체가 구 조화 저장소 애플리케이션으로부터 조작될 것이면, 파일 속성 핸들러(140)는, 속성이, 비구조화 파일에서 갱신되는 속성으로 역 변형되도록 유발하는 디모션 동작을 수행한다.

일 특징에서, 파일 후원 아이템으로서도 알려진 바와 같이, 구조화 객체에 대응하는 파일 스트림을 갱신함으로써 속성을 수정하는 것을 파일 기반 애플리케이션(110)이 지속할 때, 프로모션은 동작한다. 그러므로, 프로모션은, 파일을 갱신함으로써 만들어지는 변화를 아이템이 반영하도록, 구조화 객체 시스템(160)의 아이템에 있는 이들 속성의 카피를 갱신하는 프로세스로서 모델링될 수 있다. 반대로, 예컨대 아이템이 파일 후원 아이템인지 아닌지에 상관없이, 구조화 객체(structured object) 애플리케이션 프로그램 인터페이스(Application Programming Interface; API)를 사용하여, 구조화 저장소에 대항하여 작동하는 새로운 애플리케이션이 아이템에 질의하고 아이템을 수정할 때, 디모션이 동작한다. 파일 후원 아이템의 경우에, (일찍이 파일로부터 프로모트된) 이들 속성의 약간은 그 후 파일에 다시 기입된다. 이 프로세스는 디모션이라고 불리는데, 이는 본질적으로 프로모션의 역 변형이다.

파일 속성 핸들러(140)에 대해서, 프로모션 및 디모션은, 속성을 주어진 파일로부터 프로모트 그리고/또는 주어진 파일로 다시 디모트를 어떻게 할지를 결정하는 파일 속성 핸들러(FPH)라고 불리는 코드 모듈을 호출함으로써 달성된다. 일반적으로, FPH(140)는 하나 이상의 선택된 파일 확장자를 처리하도록 등록된다. 몇몇 경우에는, FPH는 프로모트 또는 디모트 기능만을 구현하는 것을 결정할 수 있 음을 유의. 설명하는 바와 같이, 용어 "프로모터(promoter)"는, 사용되면, 프로모션의 정황에서 설명되고 있는 FPH를 말하고, "디모터"는 디모션의 정황에서의 FPH로서이다.

브리지 콤포넌트(130)(파일 속성 관리자라고도 함)는 프로모션 및 디모션을 용이하게 하기 위해 FPH(140)와 상호작용한다. 그러므로, 프로모션 변화 큐(promotion change queue)(후술함)로부터 엔트리를 수신하면, 브리지 콤포넌트(130)는, 프로모트될 파일의 스트림에 대한 포인터로 파일에 대해 적절한 FPH(140)를 호출한다. 그 후, FPH(140)는, 구조화 개체 저장소(160)에 저장되는 관리되는 아이템(managed item)의 구조화 속성으로의 파일의 비구조화 속성의 추출 및 변형(후술함)을 수행한다. 디모션에 관해서, 구조화 객체 API는, 아이템이 구조화 객체 저장소(160)에서 갱신될 때, 디모터를 호출한다. 디모터는 다시 파일에 갱신된 속성을 기입하기 위해 역 변형 및 추출 코드를 채용한다. FPH(140)의 추출 부분은, 속성을 추출하기 위해 파일 포맷에 특정한 API를 사용한다. 일반적으로, 주어진 파일에 대해 호출되는 하나의 등록된 FPH(140)가 있다는 것을 유의.

도 2를 참조하면, 본 발명의 특징에 따른 더 상세한 변형 시스템(200)이 도시된다. 시스템(200)은 프로모션 및/또는 디모션에 대한 논리 모델(logical model)을 표현한다. 이 특징에서, 하나 이상의 FPH(210)(파일 속성 핸들러)는 관리되는 코드에 상주한다. FPM(File Property Manager)(220)는 관리되는 FPH(210)에 대한 상호운용(interoperability) 또는 브리지 콤포넌트로서 행동한다. 일반적으로, FPM(220)은, 실제 객체 저장소(230)를 유지하는 프로세스와는 다른 별개의 프로세스로서 실행한다. 전술한 바와 같이, 프로모션 및 디모션에 대한 메소드를 규정하는 BaseFilePropertyHandler 클래스가 제공될 수 있다. 그러므로, 파일 속성 핸들러(210)는, 프로모션 및/또는 디모션에서 인보크될 메소드를 구현하는 추상 BaseFilePropertyHandler 클래스로부터 유도하는 구체적 관리 클래스(concrete managed class)로서 모델링된다. 예컨대, FPM(220)은, 특정 파일 확장자를 갖는 파일에 대해 프로모션을 인보크시키기 위한 클래스를 인스턴스화한다(instantiate). 다음의 발췌 코드는 예시적인 클래스 지정(class designation)을 나타낸다.

using System;

using System.Storage;

using System.Storage.Base;

namespace System.Storage.FPM

{

struct FPMContext

{

ItemContext itmCtxt;

public string fileExtension;

};

abstract class BaseFilePropertyHandler

{

abstract public void Promote (

ref Item itm, // File item (for write)

FileStream fStream, // File stream (for read)

PromotionContext ctx); // Promotion context

abstract public void Demote (

Item existingItm, // File item (for read)

FileStream fStream, // File stream (for write)

PromotionContext ctx); // Promotion context

abstract public void FirstPromote (

ref Item itm, // File item (for write)

FileStream fStream, // File stream (for write)

PromotionContext ctx); // Promotion context

abstract public void StoreSerializedItem(

Item existingItm, // File item (for read)

FileStream fStream, // File stream (for write)

PromotionContext ctx); // Promotion context

abstract public void RetrieveSerializedItem(

ref Item itm, // File item (for write)

FileStream fStream, // File stream (for read)

PromotionContext ctx); // Promotion context

};

}

파일과 작동하는 애플리케이션에 의해 파일 API를 사용하여 파일 후원 아이템의 파일 스트림이 수정될 때, 프로모션이 인보크된다. 그러므로, 구조화 저장소 이름공간의 파일을 수정하기 위하여 이러한 애플리케이션이 사용될 때, 프로모션은 인보크되어야 한다. 일반적으로, 구조화 저장소 이름공간(structured store namespace)으로 이주하지 않고 비구조화 파일 환경에서 계속해서 존재하는 파일에 대해서 프로모션이 없어야 한다. 구조화 저장소 이름공간 파일이, 파일 API를 사용하는 애플리케이션에 의해 수정되면, 파일 프로모션 관리자(220) 또는 서비스는 파일에 대응하는 아이템을 갱신하기 위해 이 파일에 비동기적으로 FPH(210)를 인보크시킨다. 일반적으로, 하나의 FPH(210)가 파일 확장자 당 등록된다. 파일 후원 아이템에 보류 프로모션(pending promotion)이 있으면, 아이템 상의 'promotionStale' 플래그는 1로 설정된다.

도 2에 도시된 바와 같이, 비구조화 파일(200)과 작동하는 애플리케이션이 "230"에서 구조화 저장소 이름공간의 파일을 수정하면, FPH(210)는 "230"에서 저장될 프로모트된 아이템을 반환하기 전에 "250"에서 비구조화 속성의 추출 및 변형을 수행한다. 반대로, 일반적으로 디모션은, 파일 후원 아이템이 구조화 저장소 API(200)를 통하여 갱신될 때, 인보크된다. 구조화 저장소 API(200)는 애플리케이션이, 하나 이상의 파일 후원 아이템 또는 이러한 아이템의 부분을 수정하는 것을 허용한다. 이를 수행한 후에, 애플리케이션이 구조화 저장소 API를 사용하여 변화된 아이템을 저장하는 것을 시도하면, 저장하도록 인보크되는 구조화 저장소 API의 메소드는 다음을 수행한다: (아이템을 저장하는 기능을 수행하는 구조화 저장소 API의 메소드는 '저장" 메소드라고 하여 여기서 개념적으로 언급되지만, 정확한 메소드 이름은 구현에 의존한다)

파일 후원 아이템 또는 이것의 일부가 구조화 저장소 API(260)를 통하여 수정되면, 구조화 저장소 API의 저장 메소드는 파일 후원 아이템에 대응하는 디모터(demoter)를 찾고(looks up)(파일 확장자에 기초함) 이를 인보크한다. 디모터는, 판독-기입(read-write)용 아이템(또는 이의 부분) 및 기입용 파일 스트림을 받아들여서, 아이템에 대한 변화에 기초하여 파일 내용을 갱신한다. 일반적으로, 디모션은 동기 동작인데, 이는 그것이 구조화 저장소에 아이템을 저장하려고 시도하는 동작 동안 인보크되기 때문이다. 전술한 저장 메소드는 디모터를 인보크함으로써 파일(240)을 갱신하고, 구조화 데이터 저장소의 아이템에 적절한 속성을 기입한다.

도 3 내지 도 6은 본 발명의 특징에 따른 파일 속성 핸들러 및 파일 속성 관리자에 대한 자동화된 프로모션 및 디모션 프로세스를 도시한다. 설명의 간략화를 위해, 방법론들이 일련의 행동(series of acts)으로서 도시되고 설명되지만, 본 발명은 행동의 순서에 의해 제한되지 않고, 몇몇 행동은 본 발명에 따라, 도시되고 설명되는 것과 다른 순서 및/또는 다른 동작과 동시에 발생할 수 있다는 것이 이해되고 인정될 것이다. 예컨대, 당업자는, 방법론이, 상태 다이어그램(state diagram)에서와 같이 상호관련된 상태(interrelated states) 또는 이벤트의 시리즈로서 선택적으로 표현될 수 있다는 것을 이해할 것이다. 더욱이, 본 발명에 따른 방법론을 구현하기 위해 요구되는 모든 도시된 행동이 요구되지 않을 수 있다.

도 3 및 도 4는 동시에 설명되는데, 도 3은 프로모션 동안 파일 프로그램 관리자(file program manager; FPM)에 대한 프로세스를 나타내고, 도 4는 프로모션 동안 파일 속성 핸들러(FPH)에 대한 프로세스를 나타낸다. 일반적으로, 파일은 Change Queue라고 하는 큐에 프로모션을 위해 큐잉된다(queued). 다음은, 파일 프로그램 관리자가 Change Queue로부터 파일 후원 아이템을 수신한 후에 프로모션하는데 포함되는 동작들이다. "310"에서, FPM은, 파일이 있는 구조화 저장소로부터 FPH 등록 정보를 찾음으로써 파일에 대한 FPH를 찾는다. "320"에서, FPM은 대응하는 FPH를 로드한다. 예컨대, 이것은 개별 머신에 대한 전역 어셈블리 캐시(Global Assembly Cache)로부터 FPH 어셈블리를 로딩함으로써, 그리고 FPH 클래스의 인스턴스를 검색함으로써 달성될 수 있다. "330"에서, FPM은 트랜잭션(transaction)을 시작하고, Change Queue로부터 아이템을 디큐잉한다(dequeues). "340"에서, FPM은 변화된 파일에 대응하는 구조화 저장소 아이템(I1)을 검색한다. "350"에서, FPM은 FPH 상의 적절한 메소드를 호출함으로써 프로모션을 수행한다.

"350" 후에, 프로세스는 FPH 프로세싱에 관한 도 4의 "410"으로 진행한다. 이 지점에서 FPH는 아이템의 구조를 먼저 변화시킬 수 있다. "420"에서, FPH는 속 성을 추출하고, 속성에 기초하여 아이템을 갱신한다. "430"에서, FPH는 아이템의 수정된 부분을 프로모트된 것으로 표시한다. "430"에서, 프로세스는 더 이상의 FPM 프로세싱을 위해 도 3의 "360"으로 다시 진행한다. "360"에서, FPM은 아이템을 promotionStale이 아닌 것으로 표시한다. "370"에서, FPM은 구조화 객체 저장소에 변화를 적용한다. "380"에서, FPM은 커미트(commit)/롤백(rollback)을 수행하고 파일 핸들을 닫는다.

도 5 및 도 6은 함께 설명되는데, 도 5는 디모션 동안 구조화 저장소 저장 기능(이미 규정됨)에 대한 프로세스를 나타내고, 도 6은 디모션 동안 파일 속성 핸들러(FPH)에 대한 프로세스를 나타낸다. 도 5를 참조하면, 다음의 행동들은 수정된 아이템에 대해 수행된다. "510"에서, 갱신 기능은 그것이 파일 후원 아이템인지를 확인한다. 파일 후원 아이템이 아니면, 디모션 코드는 바이패스되고 비 파일 후원 아이템(non file-backed item)에 대한 정상적인 프로세싱이 개시되며, 그렇지 않으면, 파일 후원되는 아이템의 부분에 대해서만 수행되는 갱신에 대해 적절한 아이템을 결정한다. 이는, 구조화 객체 저장소의 아이템과 연관되는 isFileBacked 비트를 찾음으로써 달성될 수 있다.

"520"에서, 저장 기능은, 파일 확장자에 대하여 등록되는 FPH를 확인하기 위해 파일 후원 아이템이 어디에 상주(이것은 원격 파일의 경우에는 다른 머신 상일 수 있음)하는지를 저장소에 질의한다. 이것은 파일을 프로모트한 FPH에 대한 상세 사항(예컨대, 어셈블리 이름 & 버전 #)를 반환한다. "530"에서, 갱신 기능은 상기 정보에 기초하여 적절한 FPH(예컨대, 그것은 개별 머신의 전역 어셈블리 캐시에 등 록될 수 있음)를 로드한다. "540"에서, 저장 기능은 디모션을 수행하기 위해 FPH에 대해 메소드를 인보크한다. 또한, 변화된 아이템은 Item에 대해 만들어진 변화의 레코드를 포함한다. 이들 변화는 구조화 저장소 API에 의해 추적된다.

"540" 후에, 프로세스는 더 이상의 FPH 프로세싱을 위해 도 6의 "610"으로 진행한다. "610"에서, FPH는 아이템의 추적된 변화를 보고, 어느 필드가 디모트될 필요가 있는지를 식별한다. "620"에서, FPH는 아이템으로부터 변화를 판독하고, 파일 속성에 기입한다. 또한, 이것은 저장소로부터 다른 정보를 판독하도록 구조화 저장소 API를 호출하는 것을 포함할 수 있다. "630"에서, FPH는 디모트되는 아이템 또는 이의 부분에 'promoted' 플래그를 1로 표시한다. 그 후, 프로세스는 더 이상의 저장 기능 프로세싱을 위해 도 5의 "550"으로 진행한다. "550"에서, 저장 기능은 아이템에 만들어진 변화를 저장소에 적용한다. "560"에서, 저장 기능은 스트림을 닫고 파일에 대해 트랜잭션을 커미트한다.

전술한 바와 같이, 프로세싱은 "제1 프로모션"에 대해서 다를 수 있다. 일반적으로, 제1 프로모션의 행동은 다른 프로모션으로부터 구별된다. 이것은, 제1 프로모션이 서로 동기적으로 아이템 및 파일을 가져올 필요가 있다는 것에 기인할 수 있다.

도 7은 본 발명의 특징에 다른 파일 후원 아이템에 대한 상태 다이어그램(700)을 도시한다. 전술한 설명에서, 파일 후원 아이템에 대한 상태가 다이어그램(700)에 도시된다. 구조화 저장소 API는 promotionStale=1을 가진 파일 후원 아이템을 갱신할 수 없다. 아이템 상의 'promotionStale' 비트는, 그것이 파일 후원 아이템이고 "710"에서 아이템에 보류 중인 프로모션이 있으면, 참(true)이다. 구조화 저장소 API를 사용하여 파일 후원 아이템을 갱신하고 디모션을 인보크하기를 소망하는 애플리케이션은 다음과 같이 동작할 수 있다.

1) 아이템을 페치(fetch)

2) 아이템이 'promotionStale'인지를 질의

3) 아이템이 스테일(stale)이면

- 최신의 아이템을 가져오기 위해 API의 'SynchronousPromote' 메소드를 호출

유의: 2 및 3은 선택사양(optional)임.

4) 페치된 아이템을 갱신

5) 아이템을 저장하는 것을 시도하기 위해 구조화 저장소 API의 저장 메소드를 호출

6) 저장이 디모션에서 성공하면, 마침(done)

7) 그렇지 않으면

8) 반환된 에러 코드가 'Item Is PromotionStale'이면(이는 app가 위의 2 및 3을 수행하지 않았으면 그러함)

- 최신 아이템을 가져오기 위해 API의 'SynchronousPromote' 메소드를 호출. updatedItem을 반환.

updatedItem 상의 변화를 적용하기 위해 4로 이동

9) 반환되는 에러 코드가 'Item Has been Updated'이면,

- 위의 4로 감

일반적으로 파일 유형 당 등록된 하나의 FPH가 있다. 그러나, 파일 포맷이 확장가능(extensible)인 경우에, FPH가 그것이 언제 개발되었는지를 인식하지 못하는 파일의 비구조화 속성에 새로운 속성이 추가될 수 있다. 확장될 주어진 파일 유형에 대한 FPH가, 최종 사용자(end-users)뿐만 아니라 FPH-기입자(writer) 이외의 소프트웨어-벤더/솔류션 제공자에 의해 추가되는 새로운 또는 커스텀(custom) 속성을 프로모트/디모트하는 것을 허용하기 위해 시스템에 의해 지원되는 상이한 확장가능 스킴이 있다. 이것은, 새롭게 추가된 비구조화 파일 속성을 또한 아이템 상의 새로운 구조화 속성으로 변형하는 것을 가능하게 한다. 예시적인 확장가능 스킴은 아래에서 설명된다.

1. 파일에 간단한 비구조화 속성을 추가하고 이것이 아이템 상의 간단한 구조화 속성으로 변형되기를 원하는 소프트웨어 벤더/솔류션 제공자는 다음을 한다.

a) 대응하는 새로운 간단한 구조화 속성을 아이템에 추가하고

b) 새롭게 추가된 비구조화 속성이, 새롭게 추가된 구조화 아이템 속성으로 어떻게 변형되어야 하는지를 XML 스킴을 사용하여 선언적으로(declaratively) 지정(specify).

제1 유형에 대해 등록되는 주 FPH는 (프로모션 및 디모션 양자 모두 동안) 이러한 변환(conversions)을 구현할 것이므로, 벤더가 임의의 새로운 코드를 기입하기 위해 파일을 확장하는 것을 요구하지 않는다.

2. 파일에 비구조화 속성을 추가하고 아이템 상의 더 복잡한 구조화 속성으 로 이것이 변형되기를 원하거나 아이템들 간에 관계를 확립하려는 소프트웨어 벤더/솔류션 제공자는 다음을 한다.

a) 대응하는 복잡한 구조화 속성을 아이템에 추가하고

b) 비구조화 속성을 새롭게 추가된 구조화 아이템 속성으로 변형하기 위해 구조화 저장소 API를 사용하거나 아이템들 간의 관계를 확립하는 코드를 기입. 이 코드는 파일 유형에 대한 주 FPH의 구현에 유사할 수 있다.

3. 최종 사용자는 파일에 새로운 속성을 추가할 수 있다. 이것은 파일의 구조화 아이템 표시 상에 설정되는 디폴트 속성으로 프로모트 및 디모트된다.

도 8을 참조하면, 본 발명의 다양한 특징을 구현하기 위한 예시적인 환경(810)은 컴퓨터(812)를 포함한다. 컴퓨터(812)는 프로세싱 유니트(814), 시스템 메모리(816), 및 시스템 버스(818)를 포함한다. 시스템 버스(818)는 시스템 메모리(816)를 포함하는 시스템 콤포넌트를 프로세싱 유니트(814)에 연결하지만, 이에 제한되지는 않는다. 프로세싱 유니트(814)는 다양한 이용가능한 프로세서 중 임의의 것일 수 있다. 듀얼 마이크로프로세서 및 다른 멀티프로세서 구조(architecture)도 프로세싱 유니트(814)로서 채용될 수 있다.

시스템 버스(818)는, 메모리 버스 또는 메모리 제어기와, 주변장치 버스(peripheral bus) 또는 외부 버스(external bus)와, 그리고/또는 16-비트 버스, ISA(Industrial Standard Architecture), MSA(Micro-Channel Architecture), EISA(Extended ISA), IDE(Intelligent Drive Electronics), VLB(VESA Local Bus), PCI(Peripheral Component Interconnect), USB(Universal Serial Bus), AGP(Advanced Graphics Port), PCMCIA(Personal Computer Memory Card International Association bus), 및 SCSI(Small Computer Systems Interface)를 포함하는 이용가능한 다양한 버스 구조 중 임의의 것을 사용하는 로컬 버스 중 임의의 것일 수 있다.

시스템 메모리(816)는 휘발성 메모리(820) 및 비휘발성 메모리(822)를 포함한다. 기동(start-up) 동안과 같이 컴퓨터(812) 내의 소자들 간에 정보를 전달하기 위한 기본적인 루틴(basic routines)을 포함하는 기본 입출력 시스템(basic input/output system; BIOS)은 비휘발성 메모리(822)에 저장된다. 제한이 아닌 설명의 방법으로, 비휘발성 메모리(822)는 ROM(read only memory), PROM(programmable ROMM), EPROM(electrically programmable ROM), EEPROM(electrically erasable ROM), 또는 플래시 메모리를 포함할 수 있다. 휘발성 메모리(820)는 외부 캐시 메모리로서 행동하는 RAM(random access memory)를 포함한다. 제한이 아닌 설명의 방법으로, RAM은 SRAM(synchronous RAM), DRAM(dynamic RAM), SDRAM(synchronous DRAM), DDR SDRAM(double data rate SDRAM), ESDRAM(enhanced SDRAM), SLDRAM(Synchlink DRAM), 및 DRRAM(direct Rambus RAM)과 같은 다수의 형태로 이용가능하다.

또한, 컴퓨터(812)는 착탈식(removable)/비착탈식(non-removable), 휘발성/비휘발성 컴퓨터 저장 매체를 포함한다. 예컨대, 도 8은 디스크 저장장치(824)를 도시한다. 디스크 저장장치(824)는 자기 디스크 드라이브(magnetic disk drive), 플로피 디스크 드라이브(floppy disk drive), 테이프 드라이브(tape drive), 재즈 드라이브(Jaz drive), 집 드라이브(Zip drive), LS-100 드라이브, 플래시 메모리 카드, 또는 메모리 스틱(memory stick)을 포함하지만, 이에 제한되지는 않는다. 또한, 디스크 저장장치(824)는, CD-ROM(compact disk ROM device), CD-R 드라이브(CD recordable drive), CD-RW 드라이브(CD rewritable drive) 또는 DVD-ROM(digital versatile disk ROM drive)과 같은 광학 디스크를 포함하는 다른 저장 매체와 함께 또는 별도로 저장 매체를 포함하지만, 이에 한정되는 않는다. 시스템 버스(818)로의 디스크 저장 장치(824)의 접속을 용이하게 하기 위하여, 일반적으로 인터페이스(826)과 같은 착탁실 또는 비착탈식 인터페이스가 사용된다.

도 8은, 적절한 동작 환경(810)에서 설명되는 기본 컴퓨터 자원(basic computer resources)과 사용자 간에 중개자(intermediary)로서 행동하는 소프트웨어를 도시한다는 것을 이해하여야 한다. 이러한 소프트웨어는 운영 시스템(828)을 포함한다. 디스트 저장 장치(824) 상에 저장될 수 있는 운영 시스템(828)은 컴퓨터 시스템(812)의 자원을 제어 및 할당하도록 행동한다. 시스템 애플리케이션(830)은, 디스크 저장 장치(824) 상에 또는 시스템 메모리(816)에 저장되는 프로그램 데이터(834) 및 프로그램 모듈(832)을 통해 운영 시스템(828)에 의해 자원의 관리를 이용한다. 본 발명은, 다양한 운영 시스템 또는 운영 시스템들의 조합으로 구현될 수 있다는 것을 이해하여야 한다.

사용자는 입력 장치(836)를 통하여 컴퓨터(812)에 명령어(commands) 또는 정보를 입력한다. 입력 장치(836)는, 마우스와 같은 포인팅 장치(pointing device), 트랙볼(trackball), 스타일러스(stylus), 터치 패드(touch pad), 키보드, 마이크로 폰(microphone), 조이스틱, 게임 패드, 위성 접시, 스캐너, TV 튜너 카드, 디지털 카메라, 디지털 비디오 카메라, 웹 카메라 등을 포함하지만, 이에 제한되지는 않는다. 이들 및 다른 장치는 인터페이스 포트(838)를 통해 시스템 버스(818)를 통하여 프로세싱 유니트(814)에 접속한다. 예컨대, 인터페이스 포트(838)는 시리얼 포트(serial port), 병렬 포트(parallel port), 게임 포트, 및 USB(universal serial bus)를 포함하지만, 이에 제한되지 않는다. 출력 장치(840)는 입력 장치(836)와 동일한 유형의 포트 몇몇을 사용한다. 그러므로, 예컨대, USB 포트는 컴퓨터(812)에 입력을 제공하기 위해, 그리고 컴퓨터(812)로부터 출력 장치(840)로 정보를 출력하기 위해 사용될 수 있다. 출력 어댑터(842)는, 다른 출력 장치(840) 중에서도, 특별한 어댑터를 요구하는 모니터, 스피커, 및 프린터와 같은 몇몇 출력 장치(840)가 있다는 것을 설명하기 위하여 제공된다. 제한이 아닌 설명의 방법으로, 출력 어댑터(842)는 출력 장치(840)와 시스템 버스(818) 간에 접속 수단을 제공하는 비디오 및 사운드 카드를 포함한다. 다른 장치 및/또는 장치의 시스템이 원격 컴퓨터(844)와 같은 입력 및 출력 능력 양자 모두를 제공한다는 것을 유의하여야 한다.

컴퓨터(812)는 원격 컴퓨터(844)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 사용하는 네트워크된 환경에서 동작할 수 있다. 원격 컴퓨터(844)는 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 워크스테이션, 마이크로프로세서 기반 가전기구(microprocessor based appliance), 피어 장치(peer device) 또는 다른 공통 네트워크 노드 등일 수 있고, 일반적으로 컴퓨터(812)에 관련되어 설명되는 많 은 또는 모든 요소를 포함한다. 간결하게 하기 위하여, 메모리 저장 장치(846)만이 원격 컴퓨터(844)와 도시된다. 원격 컴퓨터(844)는 네트워크 인터페이스(848)를 통하여 컴퓨터(812)에 논리적으로 접속되고, 그 후 통신 접속(850)을 통하여 물리적으로 접속된다. 네트워크 인터페이스(848)는 LAN(local-area networks) 및 WAN(wide-area networks)과 같은 통신 네트워크를 포함한다. LAN 기술은, FDDI(Fiber Distributed Data Interface), CDDI(Copper Distributed Data Interface), Ethernet/IEEE 1102.3, Token Ring/IEEE 1102.5 등을 포함한다. WAN 기술은, 포인트-대-포인트 링크(point-to-point links), ISDN(Integrated Services Digital Networks) 및 그 위의 변형과 같은 회로 스위칭 네트워크(circuit switching networks), 패킷 스위칭 네트워크(packet switching networks), 및 DSL(Digital Subscriber Lines)을 포함하지만, 이에 제한되지는 않는다.

통신 접속(850)은 버스(818)에 네트워크 인터페이스(848)를 접속하기 위해 채용되는 하드웨어/소프트웨어를 말한다. 통신 접속(850)은 설명의 명확화를 위해 컴퓨터(812) 내에 도시되지만, 컴퓨터(812) 외부에 있을 수도 있다. 예컨대, 네트워크 인터페이스(848)로의 접속을 위해 필요한 하드웨어/소프트웨어는, 단지 예시적인 목적으로, 정규 전화 등급 모뎀(regular telephone grade modems), 케이블 모뎀 및 DSL 모뎀을 포함하는 모뎀과, ISDN 어댑터와, 에더넷 카드와 같은 내부 및 외부 기술을 포함한다.

도 9는, 본 발명이 상호작용할 수 있는 샘플-컴퓨팅 환경(900)의 개략적인 블록도이다. 시스템(900)은 하나 이상의 클라이언트(910)를 포함한다. 클라이언 트(910)는 하드웨어 및/또는 소프트웨어(예컨대, 스레드, 프로세스, 컴퓨팅 장치)일 수 있다. 또한, 시스템(900)은 하나 이상의 서버(930)를 포함한다. 서버(930)도 하드웨어 및/또는 소프트웨어(예컨대, 스레드, 프로세스, 컴퓨팅 장치)일 수 있다. 서버(930)는, 예컨대 본 발명을 채용함으로써 변형을 수행하기 위해 스레드를 하우스(house)할 수 있다. 클라이언트(910)와 서버(930) 간의 하나의 가능한 통신은, 두 개 이상의 컴퓨터 프로세스 간에 전송되도록 조정되는 데이터 패킷의 형태일 수 있다. 시스템(900)은, 클라이언트(910)와 서버(930) 간의 통신을 용이하게 하기 위해 채용될 수 있는 통신 프레임워크(950)를 포함한다. 클라이언트(910)는, 클라이언트(910)에 로컬인 정보를 저장하기 위해 채용될 수 있는 하나 이상의 클라이언트 데이터 저장소(960)에 동작적으로 접속될 수 있다. 마찬가지로, 서버(930)는, 서버(930)에 로컬인 정보를 저장하기 위해 채용될 수 있는 하나 이상의 서버 데이터 저장소(940)에 동작적으로 접속될 수 있다.

전술한 내용은 본 발명의 예를 포함한다. 물론, 본 발명을 설명하기 위한 목적으로 콤포넌트 또는 방법론의 생각할 수 있는 모든 조합을 설명하는 것은 가능하지 않지만, 당업자는 본 발명의 많은 그 이상의 조합 및 교환(permutations)을 인식할 것이다. 따라서, 본 발명은 첨부된 청구항의 취지 및 범위에 해당하는 모든 교체(alternation), 수정 및 변경을 포함하는 것으로 의도된다. 나아가, 용어 "포함한다(include)"가 상세한 설명 또는 청구항에서 사용되는 한도에서는, 이러한 용어는, "포함하는(comprising)"이 청구항의 전이어(transitional word)로서 사용될 때 해석되는 바와 같은 용어 "포함하는(comprising)"에 유사한 방식으로 포함한 다는 것을 의도한다.

Claims

파일 변형 시스템(file transformation system)에 있어서,

하나 이상의 비구조화 속성들(unstructured properties)과 연관되는 적어도 하나의 파일; 및

구조화 객체 환경(structured object environment)과 연관되는 하나 이상의 구조화 속성에 따라 상기 비구조화 속성들을 조작(manipulate)하기 위한 파일 속성 핸들러(file property handler)

를 포함하는 파일 변형 시스템.
제1항에 있어서, 상기 파일 속성 핸들러는, 상기 비구조화 속성들을 상기 구조화 속성들로 프로모트(promote)하기 위하여 추출(extraction) 및 변형 중 적어도 하나를 수행하는 파일 변형 시스템.
제1항에 있어서, 상기 파일 속성 핸들러는 상기 구조화 속성들을 상기 비구조화 속성들로 디모트(demote)하기 위하여 추출 및 변형 중 적어도 하나를 수행하는 파일 변형 시스템.
제1항에 있어서, 비구조화 속성 스트림/파일(unstructured property stream/file)과 작동하는 애플리케이션들과, 파일의 구조화 객체 표현(structured object representation)과 작동하는 애플리케이션들 간의 통신을 용이하게 하기 위한 파일 속성 관리자(file property manager)를 더 포함하는 파일 변형 시스템.
제1항에 있어서, 상기 파일 속성 핸들러는, 구조화 객체 저장소 아이템(structured object store item)에 대한 파일 스트림을 갱신함으로써 파일 API 기반 애플리케이션(file API based application)이 속성들을 수정할 때, 프로모션 동작(promotion operation)을 용이하게 하는 파일 변형 시스템.
제5항에 있어서, 상기 구조화 객체 저장소 아이템은 파일 후원 아이템(file-backed item)인 파일 변형 시스템.
제1항에 있어서, 상기 속성 핸들러는, 애플리케이션이, 상기 파일 후원 아이템을 조작하는 구조화 저장소 API(Application Programming Interface)를 채용하여 아이템들에 질의하고 아이템들을 수정할 때, 디모션 동작을 용이하게 하는 파일 변형 시스템.
제1항에 있어서, 상기 파일 속성 핸들러는 하나 이상의 선택된 파일 확장자들(file extensions)을 처리하도록 등록되는 파일 변형 시스템.
제4항에 있어서, 상기 파일의 상기 비구조화 바이트 스트림 표현이 수정되었 다는 통지(notification)를 수신하면, 상기 파일 속성 관리자는 프로모트될 상기 파일의 상기 바이트 스트림에 대한 포인터로 그것에 대한 파일 속성 핸들러를 호출하는 파일 변형 시스템.
제1항에 있어서, 상기 파일 속성 핸들러는 프로모션 및 디모션용 메소들을 규정하는 추상 클래스(abstract class)와 연관되는 파일 변형 시스템.
제10항에 있어서, 상기 추상 클래스는, BaseFilePropertyHandler, 프로모트 메소드, 디모트 메소드, 제1 프로모트 메소드, 저장소 직렬화 아이템 메소드(store serialized item method), 및 검색 직렬화 아이템 메소드(retrieve serialized item method) 중 적어도 하나를 포함하는 파일 변형 시스템.
제1항에 있어서, 애플리케이션들이 파일 후원 아이템을 수정하는 것을 허용하는 API를 더 포함하는 파일 변형 시스템.
제1항의 상기 파일 속성 핸들러를 구현하기 위한 컴퓨터 판독 가능 명령어들을 갖는 컴퓨터 판독 가능 매체.
데이터 변형을 용이하게 하기 위한 시스템에 있어서,

구조화 저장소 애플리케이션에 비구조화 파일 속성들을 노출시키기 위한 수 단;

상기 구조화 저장소 애플리케이션과 연관되는 구조화 아이템 속성들로 상기 비구조화 파일 속성들을 변형시키기 위한 수단; 및

상기 구조화 저장소 애플리케이션의 상기 구조화 아이템 속성들을 갱신하기 위한 수단

을 포함하는 시스템.
제14항에 있어서, 상기 구조화 아이템 속성들을 비구조화 파일 속성들로 변형시키기 위한 수단을 더 포함하는 시스템.
데이터 아이템 이주(data item migration)를 용이하게 하기 위한 방법에 있어서,

파일 API 기반 애플리케이션으로부터의 구조화 저장소 이름공간(structured store namespace)의 아이템을 수정하는 단계; 및

상기 구조화 저장소 이름공간과 연관되는 속성들에 따르도록 상기 아이템과 연관되는 하나 이상의 속성들을 프로모트하는 단계

를 포함하는 방법.
제16항에 있어서, 상기 파일 API 기반 애플리케이션을 따르도록 상기 아이템과 연관되는 하나 이상의 속성들을 디모트하는 단계를 더 포함하는 방법.
제16항에 있어서, 상기 하나 이상의 속성들을 프로모트 또는 디모트하는 것을 용이하게 하기 위하여 파일 속성 핸들러를 등록하는 단계를 더 포함하는 방법.
제16항에 있어서, 변화 아이템(change item)을 디큐잉하는(de-queuing) 단계를 더 포함하는 방법.
제16항에 있어서, 선택된 아이템 경로(selected item path)에 대한 구조화 아이템을 검색하는 단계를 더 포함하는 방법.
제16항에 있어서, 아이템의 유형/구조(type/structure)를 모핑(morphing)하거나 아이템 유형/구조를 변화시키는 단계를 더 포함하는 방법.
제16항에 있어서, 자동으로 속성들을 추출하고 아이템을 갱신하는 단계를 더 포함하는 방법.
제16항에 있어서, 아이템의 수정된 부분들을 프로모트된 것으로서 표시하는(marking) 단계를 더 포함하는 방법.
제16항에 있어서, 상기 아이템에 대한 변화들을 상기 구조화 객체 저장소에 적용하는 단계를 더 포함하는 방법.
제17항에 있어서, 상기 아이템의 부분들로의 갱신들에 대한 상기 아이템을 결정하는 단계를 더 포함하는 방법.
제17항에 있어서, 파일 속성 핸들러 등록에 대해 아이템 저장소에 질의하는 단계를 더 포함하는 방법.
제26항에 있어서, 상기 파일 속성 핸들러를 캐시(cache)에 로드하는 단계를 더 포함하는 방법.
제17항에 있어서, 갱신될 필드들(fields)을 자동으로 식별하는 단계를 더 포함하는 방법.
제17항에 있어서, 아이템으로부터 변화들을 판독하고 파일 속성들을 갱신하는 단계를 더 포함하는 방법.
제29항에 있어서, 상기 아이템 변화들을 상기 저장소로 송신하는 단계, 및 스트림을 종료하는 단계 중 적어도 하나를 더 포함하는 방법.
저장된 데이터 구조체(data structure)를 갖는 컴퓨터 판독가능 매체에 있어서,

파일 데이터와 연관되는 비구조화 속성에 관련되는 제1 데이터 필드;

구조화 객체(아이템) 데이터와 연관되는 구조화 속성에 관련되는 제2 데이터 필드; 및

상기 구조와 속성 데이터와 상기 비구조화 속성 데이터를 상관(correlate)시키기 위해 채용되는 제3 데이터 필드

를 포함하는 컴퓨터 판독 가능 매체.