KR20060097577A - 시스템 데이터 인터페이스, 관련 아키텍처, 프린트 시스템데이터 인터페이스 및 관련 프린트 시스템 아키텍처 - Google Patents

Abstract

시스템 데이터 인터페이스 및 관련 아키텍처가 설명된다. 각종 실시예는 다음과 같은 기능 즉, 포괄적 데이터 모델, 비동기 클라이언트 및 서버 디스패치, 취소, 배칭, 트랜잭션 호출, 병렬 호출, 인터셉션 또는 반영 중 하나 이상의 기능을 제공할 수 있다. 한 실시예에서, 시스템 데이터 인터페이스는 프린트 시스템의 문맥에서 채용될 수 있다.

인터페이스, 아키텍처, 프린트, 데이터 모델

Description

시스템 데이터 인터페이스, 관련 아키텍처, 프린트 시스템 데이터 인터페이스 및 관련 프린트 시스템 아키텍처{System Data Interfaces, Related Architectures, Print System Data Interfaces and Related Print System Architectures}

도 1은 일 실시예에 따른 데이터 인터페이스의 다양한 컴포넌트를 도시하는 고 레벨 블럭도.

도 2는 일 실시예에 따른 프린팅 데이터 액세스 인터페이스의 고 레벨 블럭도.

도 3은 일 실시예에 따른 프로세스 통신으로부터의 양상을 도시하는 블럭도.

도 4는 일 실시예에 따른 보안 모델의 개관을 도시하는 고 레벨 블럭도.

도 5는 일 실시예에 따른 유형 매핑 메커니즘을 도시하는 블럭도.

도 6은 일 실시예에 따른 공통 데이터 인터페이스 객체 액세스 인터페이스의 블럭도.

도 7은 일 실시예에 따른 동적 유형 맵의 블럭도.

도 8은 일 실시예에 따른 객체 생성 및 복제(cloning)을 도시하는 블럭도.

도 9는 일 실시예에 따른 추상화 계층구조를 도시하는 블럭도.

도 10은 일 실시예에 따른 클래스 계층구조 및 보안을 도시하는 블럭도.

도 11은 일 실시예에 따른 객체로부터 검색된 메타데이터를 도시하는 블럭도.

도 12는 일 실시예에 따른 공통 데이터 인터페이스의 예시적인 컴포넌트의 블럭도.

도 13은 일 실시예에 따른 플러그인 모델의 블럭도.

도 14는 일 실시예에 따른 집합 어댑터 서비스에 의해 이용되는 객체 모델의 블럭도.

도 15는 일 실시예에 따른 프레임에 의해 제공되는 집합을 도시하는 블럭도.

도 16은 일 실시예에 따른 관리되는 객체와 관리되지 않는 객체의 상호운용성을 도시하는 블럭도.

도 17은 하나 이상의 실시예를 구현하는 데에 이용될 수 있는 컴퓨팅 장치의 예시적인 컴포넌트를 도시하는 블럭도.

<도면의 주요 부분에 대한 부호의 설명>

102: 공통 데이터 인터페이스(CDI)

104: 배칭 라우터

106: 플러그-인 테이블

108: 인터셉션 테이블

110: 메시지 플러그-인

112: 메시지 서비스

114: 집합

본 발명은 시스템 데이터 인터페이스 및 관련 아키텍처에 관한 것이며, 보다 상세한 실시예에서는, 프린트 시스템 데이터 인터페이스 및 관련 아키텍처에 관한 것이다.

몇몇의 시스템은 데이터를 처리하고 다양한 유형의 클라이언트와 통신하는 서버를 포함할 수 있다. 한 특정 시스템 유형은 작업, 장치, 논리적 서버로의 액세스를 제공하고 다양한 클라이언트로부터 데이터를 형성하는 프린트 서버를 포함할 수 있는 프린트 시스템이다. 프린트 시스템과 같은 다수의 현재 시스템은 새로운 데이터 클래스가 지원될 필요가 있을 때마다 수정되어야 하는 융통성 없는 기본 네트워크 인터페이스를 가진다. 또한, 몇몇의 인터페이스는 필요할 수 있는 것보다 훨신 많은 통신을 요구하고 서버에 컨텍스트(context)를 생성할 수 있으며, 이 두 가지 모두는 프린트 시스템 및 다른 시스템과 같이 서버를 채용한다는 점에 관련해서 서버 성능을 제한할 수 있다.

많은 시스템을 곤란하게 하는 다른 문제들은 프로토콜이 특정적인 한, 확장에 있어서 어려움, 융통성 없음(inflexibility), 및 규제를 초래할 수 있다.

따라서, 본 발명은 향상된 데이터 인터페이스 및 관련 아키텍처를 포함하는 향상된 시스템을 제공하려는 것에 연관된 관심사로부터 비롯되었다.

시스템 데이터 인터페이스 및 관련 아키텍처가 기술된다. 다양한 실시예는 포괄적(generic) 데이터 모델, 비동기식 클라이언트 및 서버 디스패치(dispatch), 취소, 배칭(batching), 트랜잭션 호출(transactional invocation), 병렬 호출, 인터셉션 또는 반영(reflection)과 같은 기능 중 하나 이상을 제공할 수 있다.

일 실시예에서, 프린트 시스템의 관점에서 시스템 데이터 인터페이스를 채용하였다.

개관

이하의 설명에서, 현재 시스템의 수많은 결점을 해결하는 새로운 시스템이 제공된다. 일 실시예에서, 시스템, 이 시스템의 데이터 인터페이스 및 관련된 아키텍처가 프린트 시스템의 관점으로 기술된다. 그러나, 이하 기술될 본 발명의 특징은 청구된 본 발명의 요지의 사상 및 범위로부터 벗어나지 않고, 프린트 시스템 이외의 시스템에서 채용될 수 있다고 이해되고 인식되어야 한다.

기술된 프린트 시스템은 많은 것들을 할 수 있지만, 기본적으로 기술된 프린트 시스템은 2가지 기본 태스크를 수행한다. 첫번째로, 프린트 시스템은 객체들 및 이들의 속성의 세트를 포함하는 데이터를 관리한다. 두번째로, 프린트 시스템은 처음에는 렌더링을 위하여 프린트 작업을 스케줄링하고 그 다음 프린팅을 위하여 적절한 프린트 장치에 프린트 작업들을 전송한다. 문서를 랜더링하는 프로세스는 그 작업을 처리하기 위해 어떤 컴포넌트를 호출할지 지정하는 데이터 인터페이스로부터 구성 정보를 수신함으로써 수행될 수 있다. 그러므로, 프린트 시스템이 데이터를 표현하는 방식은 이 시스템의 동작의 근본이 될 수 있다.

이들 주요 태스크를 수행하기 위하여, 본 발명의 프린트 시스템은 특정 인터페이스 및 관련된 컴포넌트를 이용한다. 이 인터페이스 및 그 일부인 프린트 시스템은 복수의 현재 프린트 시스템보다 우월한 이점을 제공할 수 있다. 이하의 설명에서, 프린트 시스템 및 인터페이스의 예비적인 평가를 제공하기 위하여 다양한 이점이 기술된다. 이 설명에 이어서, "예시적인 실시예"라는 제목의 섹션에서는 프린트 시스템, 및, 보다 상세히는 데이터 인터페이스의 특정 구현예를 기술한다.

이하 기술될 데이터 인터페이스는 포괄적 데이터 모델, 비동기식 클라이언트 디스패치, 비동기식 서버 디스패치, 취소, 배칭, 트랜잭션 호출, 병렬 호출, 인터셉션 또는 반영 기능을 지원하며, 이 기능들 각각은 자신의 표제 아래 기술되고 나타난다.

포괄적 데이터 모델( Generic Data Model )

기술된 데이터 인터페이스는 포괄적 데이터 모델로서 고려될 수 있는 것을 지원하고 이와 관련하여 이용될 수 있다. 데이터 모델은 다음의 기능을 가지는 객체의 클래스를 지원할 수 있다.

ㆍ 속성(Properties): 임의의 객체가 임의적인 속성 세트를 가질 수 있다. 클라이언트는 임의의 객체로부터 검색하기 위해 임의의 속성 세트를 지정할 수 있다. 클라이언트가 관심을 갖는 속성들만이 검색될 것이다.

ㆍ 명령(Commands): 임의의 객체는 임의적인 매개변수 세트를 가지는 명령 세트를 지원할 수 있다.

ㆍ 서버로부터 클라이언트에게 이용가능한 클래스, 명령 및 속성을 임의적으로 확장하기 위하여 와이어(wire) 포맷이 수정될 필요는 없다.

비동기식 클라이언트 디스패치( Asynchronous Client Dispatch )

숙련된 기술자들이 인식할 바와 같이, 비동기식 클라이언트 디스패치란 클라이언트 또는 클라이언트 애플리케이션으로 하여금 클라이언트 스레드에 즉시 제어를 반환하라는 데이터 요청을 시작할 수 있게 하는 데이터 인터페이스 API(application program interface)의 기능을 말한다. 동작의 결과가 완료되었을 때, 클라이언트에게 시그널링되는 콜백 또는 시스템 이벤트를 통해 통지되어 데이터의 결과를 검색할 수 있다. 예시되고 기술된 실시예에서, 이 기능은 동기식으로 블러킹(block)되고 클라이언트가 진행하도록 하는 스레드를 스핀(spin)하는 작은 래퍼(wrapper)로서 제공되는 것이 아니다. 오히려, 비동기식 디스패치가 하위의 장치 레벨로 확장된다. 저 레벨에서, 호출의 결과는 네트워크 카드에 의해 구동되는 인터럽트이다. 이러한 모델을 이용하는 것은 서버로부터 데이터를 검색하면서도 응답성을 유지하는 클라이언트 사용자 인터페이스를 설계하는 것을 간단하게 한다. 이는 또한 클라이언트에서 요구되는 스레드의 개수를 줄여준다. 이러한 특징은 클라이언트 시스템이 다른 프린트 시스템으로의 브릿지로서 행동하는 프린트 시스템일 때 특히 유용하다.

비동기식 서버 디스패치( Asynchronous Server Dispatch )

비동기식으로 서버로의 요청을 디스패치하는 클라이언트 기능과 연결되는, 서버는 클라이언트로부터 비동기식으로 요청을 서비스할 수 있다. 클라이언트가 서버 수행을 요청하는 액션이 IO 바운드(bound)라면(예를 들면, 데이터를 디스크에 기록하거나 다른 서버로부터 데이터를 요청할 필요가 있다면), 플러그인 컴포넌트는 다른 비동기식 호출을 발행하고, 제어를 서버 측 데이터 인터페이스로 반환한 다음, IO가 완료되었을 때 이 호출을 완료할 수 있다. 이 메커니즘은 서버에서 실행되는 스레드의 개수를 상당량 줄일 수 있고 모든 스레드가 시스템 CPU를 완전히 이용하는 것을 보장할 수 있다.

시스템에서 실행되는 모든 스레드는 시스템으로부터 상당수의 "페이징되지 않은 풀"을 취득한다(페이징되지 않은 풀(non-paged pool)은 물리적 메모리가 한정되게 되었을 때 디스크에 기록할 수 없는 메모리이다). 시스템 잠금들을 요하는 시스템에서 실행되는 각 스레드는 또한 시스템에서 상당수의 "경쟁"을 생성한다(이는 실행 중의 스레드들 간의 변환에 필요한 CPU 자원 및 시간 량이다). 그러므로, 시스템에서 실행되는 스레드의 개수를 줄이는 것은 시스템 성능을 향상시키는 데에 중요한 메커니즘이다.

취소( Cancellation )

이하의 기술된 실시예에서, 서버에서 진행중인 호출들은 언제든지 클라이언트에 의해 취소될 수 있다. 이는 클라이언트가 호출자에게 대화식 사용자 인터페이스를 제공하는 것을 돕는다.

배칭( Batching )

배칭이란 데이터 인터페이스를 이용하여 임의적인 액션 시퀀스를 작성하고 이 액션의 시퀀스를 한 단위로서 서버에게 전송하는 클라이언트의 기능을 칭한다. 그런 다음 이 시퀀스는 처리되어 단일한 전송 응답으로 클라이언트에게 반환된다. 이 액션들은 속성들을 획득 및 설정하기, 속성 세트를 찾기 위해 질의하기, 서버 객체에 대한 명령을 발행하기, 및 서버 객체 속성 변경에 대한 통지를 등록하기 등의 임의 유형의 액션을 포함할 수 있다.

트랜잭션 호출( Transactional Invocation )

트랜잭션 호출이란 전체적으로 실행되거나, 서버의 상태를 변경하지 않아야 한다는 의미가 정해진 배치(batch)를 칭한다.

병렬 호출( Parallel Invocation )

병렬 호출이란 배치 내의 모든 항목이 병렬로 처리되어야 한다는 의미가 정해진 배치를 칭한다. 이는 서버가 장기적으로-실행되는 액션을 병렬로 실행시킬 수 있게 하며, 또한 배치가 다른 어떤 액션이 실패할지라도 이에 관계없이 모든 액션을 실행시킬 것이라는 의미를 제공한다.

인터셉션( Interception )

시스템이 지원할 수 있는 동작들 및 속성들이 순수한 데이터 전송에 의해 나타나기 때문에, 다른 컴포넌트가 시스템의 거동을 모니터링하고 이 거동에 동기식으로 응답하고 이 거동을 수정할 수 있는 시스템에 삽입될 수 있으며, 이를 인터셉션이라 칭한다. 이는 모니터링 소프트웨어가 시스템에 플러그인되고 시스템으로부터 제거될 수 있게 한다. 이는 또한 독립형 하드웨어 벤더(IHV)가 시스템 거동을 확장할 수 있게 한다. 예를 들면, 큐가 정지했을 때, 관련 서비스는 또한 정지되어야 할 필요가 있을 수 있다. 큐에서의 "정지" 명령은 IHV에 의해 인터셉션될 수 있고 그 다음 이들은 정지 동작을 완료시키기 전에 서비스가 정지됨을 보장할 수 있다. 인터셉션 메커니즘은 또한 트랜잭션 적인 의미를 제공할 수 있다.

반영( Reflection )

반영은 소정 클래스의 객체에 의해 지원되는 속성들 및 그 객체와 관련되는 다른 정보를 검색하는 메커니즘의 시스템의 규정을 칭한다. 이러한 메커니즘을 이용하여 검색할 수 있는 정보는 다음을 포함하지만 이에 한정되지 않는다.

ㆍ 각 속성의 데이터 유형, 필드 이름, 및 유형 이름

ㆍ 속성 이용에 대한, 사람이 읽을 수 있는 설명

ㆍ 객체에 의해 지원되는 명령, 및 명령에 의해 지원되는 입력 및 출력 매개변수. 각 명령은 명령의 이용에 대한, 사람이 읽을 수 있는 설명을 가진다. 각 매개변수에 대하여, 매개변수의 이름 및 유형, 및 매개변수에 대한 사람이 읽을 수 있는 설명과 같은 데이터가 검색될 수 있다.

예시되고 기술된 실시예에서, 시스템의 반영 기능은 프로토콜에 구속되지 않는다. 또한, 반영 기능은 서버 플러그인의 관리되는 코드 구현 및 본래의 코드 둘 다에 또는 이 둘다로부터 이용될 수 있다. 또한, 반영 기능은 네트워크 인터페이스를 통하여 반영을 수행하는 기능을 제공하고, 클라이언트에게 제공되어야 할 서버-측 객체의 구현은 요구되지 않는다.

이들 및 다른 기능은 이하의 상세한 설명으로부터 명백해질 것이다.

예시적인 실시예

이하의 설명에서, 본 발명의 인터페이스에 대한 고 레벨 설명이 도 1에 관련 하여 제공된다. 이 설명에 이어서, 구현예가 제공되고 이 구현예는 구현-특정 정보를 포함한다. 구현-특정 예가 제공되지만 상술한 기능을 포함하는 프린트 시스템을 구현할 수 있는 방법의 한 예일 뿐임을 이해하고 인식하여야 한다. 이와 같이, 다른 구현예가 청구된 본 발명의 요지의 사상 및 범위로부터 벗어나지 않고 이용될 수 있다. 다른 구현은 상술한 바와 같이 프린트 시스템의 관점에서 채용될 수 있거나 채용되지 않을 수 있다.

도 1은 일반적으로, 공통 데이터 인터페이스(102), 플러그인 테이블(106) 및 인터셉션 테이블(108)을 포함하는 배칭 라우터(104)를 포함하는 시스템(100)을 도시한다. 시스템(100)은 또한 메세지 플러그인(110), 메세지 서비스(112), 집합(114), 다양한 객체(116), 시스템 확장(118) 및 소위 "다른 협력"(120)을 포함하며, 이들은 각각 이하에 기술된다.

공통 데이터 인터페이스( CDI : Common Data Interface )

공통 데이터 인터페이스(CDI)는 배칭 라우터(104)로의 인터페이스이며 메세지가 작성되고 배칭 라우터에게 디스패칭될 수 있게 한다. CDI는 또한 클라이언트에 응답을 전송하는 것을 담당한다.

배칭 라우터( Batching Router )

배칭 라우터(104)는 CDI(102)에 의해 패키지화되고 시스템에 전달되는 메세지를 수신한다. 각각의 메세지는 복수의 플러그인에 예정될 수 있는 복수의 동작을 포함할 수 있다. 이들 메세지는 동기식으로 디스패칭되고 그 다음 그 결과가 배칭 라우터(104)에 의해 검색된다. 메세지는 메세지가 전송되어야 할 목적지인 집합을 식별하는 모호하지 않는 경로에 기초하여 라우팅된다. 클라이언트의 관점으로부터의 단일 메세지는 복수의 목적지를 가질 수 있다.

플러그인 테이블( Plug - In Table )

플러그인 테이블(106)은 소정의 객체 집합을 담당하는 모든 메세지 핸들링 플러그인을 추적한다. 각각의 집합이 GUID(Globally Unique Identifier)에 의해 식별된다. 메세지가 하위에 있는 객체로 전달되기 전에 객체로의 경로가 조사되고 플러그인 테이블에서 탐색된다.

메세지 플러그인( Message Plug - In )

일단 적절한 집합이 식별되었다면, 메세지 세트는 메세지 플러그인(110)에 전달된다. 메세지 플러그인(110)은 단순히 이들 메세지를 배선을 통해 원격으로 다른 기기에 전송할 수 있다. 그러나, 보다 통상적으로, 메세지 플러그인(110)은 메세지를 해석하고 적절하게 응답할 것이다. 예시되고 기술된 실시예에서, 제3자들은 메세지 플러그인을 제공할 수 있다. 그러나, 이 제3자들이 메세지 플러그인을 제공한다면, 메세지 서비스가 제공하는 서비스들은 이들에게 이용될 수 없다. 이는 이 계층에서 플러그인하는 것을 보다 어렵게 만들 것이다. 메세지 플러그인의 주요 이점은 본래의 메세지의 형태가 이용가능하게 된다는 점이다. 이는 전체 메세지가 플러그인 집합에 의해 원격 기기에 중계되도록 하는데에 유용할 수 있다. 또한, 이 메세지들이 배칭을 지원하였던 원격 시스템도 가졌었고 수신된 메세지 포맷과 이들만의 메세지 포맷 간의 변환을 할 수 있기를 원할 경우에 독립형 하드웨어 벤더에게 이득이 될 수 있다.

메세지 서비스( Message Services )

메세지 기반 시스템에서의 주된 문제중 하나가 메세지 호출을 통하여 상태를 유지하기 어렵다는 점이기 때문에, 컴포넌트 - 메세지 서비스(112) - 가 제공되어 메세지들을 분해하고 이 메세지들을 집합 인터페이스에서의 호출의 보다 간단한 시퀀스로 변환한다. 예로서, 예시되고 기술된 실시예에서, 메세지 서비스는 다음의 태스크들을 수행할 수 있지만, 이에 한정되지 않는다.

ㆍ 메세지들을 스레드들에게 할당한다

ㆍ 메세지들을 복수의 보류된 호출에 응답하도록 한다

ㆍ 메시지를 파퓰레이트하기 위해 집합 내의 객체로부터 적절한 데이터를 검색한다

ㆍ 동작 취소를 올바르게 처리한다

ㆍ 시간에 따라 객체 인스턴스를 캐싱(caching)한다.

ㆍ 투명하게 객체를 잠금, 및

ㆍ 집합 내에 보유된 객체를 위한 반영 서비스

집합( Collections )

집합(114)은 동질의 객체 세트를 보유한다. 시스템은 객체들이 자신들을 초기에 영속시킬 수 있게 하는 집합을 제공할 것이다. 집합을 이용하는 한가지 이점은 독립형 하드웨어 벤더들이 시스템을 임의적인 객체들을 가지고 쉽게 확장할 수 있게 한다는 점이다. 예시되고 기술된 실시예에서, 집합은 동적 링크 라이브러리(DLL)로부터 검색되는 COM 인터페이스로서 구현된다. DLL은 전역 어셈블리 캐쉬 (Global Assembly Cache)에서 탐색되며 DllGetClassObject로의 직접적인 호출이 이루어져, COM 등록을 피할 수 있게 한다고 숙련된 기술을 가진 자는 인식할 것이다.

객체( Objects )

앞서 기술되고 이하 기술될 시스템의 한가지 목적은 독립형 하드웨어 벤더들 및 다른 개발자들이, 이들의 구현 언어를 위한 직접적인 지원을 가지고, 클래스 계층에서 대량으로 코딩할 수 있게 한다는 것이다. 이 목적은 가능한 많은 코드를 집합으로 통합하여 독립형 하드웨어 벤더 및 다른 개발자가 작성해야하는 코드의 총 량을 줄여줄 수 있다. 객체(116)는 집합에 의해 보유되는 논리적 구조체(construct)이다. 메세지 서비스(112)는 이들 객체가 C++ 클래스에 직접적으로 대응하는 계층을 제공한다.

인터셉션 테이블( Interception Table )

인터셉션 테이블(108)은 일반적이고, 전체적인, 확장 메커니즘을 프린트 시스템에 제공한다. 여기에서의 목적은 확장들이 시스템 내의 임의의 객체, 특정 클래스의 객체 또는 특정 객체 인스턴스를 목적지로 하는 메세지를 가로채고 수정할 수 있게 하는 것이다.

시스템 확장( System Extensions )

시스템 내의 거의 모든 것들이 중앙 메세지 시스템으로부터 발신되었으며 메세지에 의해 나타나기 때문에, 시스템 확장(118)은 이들이 보기에 적절한 임의의 방식으로 시스템이 확장되며, 가장 특출하게는 제3자에 의해 모니터링될 수 있게 한다. 이들 확장은 또한 직접 스풀러(spooler) 팀에 의한 유용한 확장 모니터링을 제공한다.

다른 협력( Other collaborations )

모든 시스템 거동이 데이터-구동형 메세징 시스템으로서 표현될 수 있는 것은 아니라고 인식될 것이다. 이와 같이, 기기 내의 다른 서브-시스템을 생성하는 객체들 간의 다른 협력(120)이 존재하며 존재할 것이다. 이들은, 예를 들면, 파이프라인(pipeline) 및 스케줄러(scheduler)를 포함할 수 있다. 여기에서의 목적은 다른 자들이 시스템에 플러그인될 수 있게 하기 위하여 모든 협력을 가능한 융통성있게 만드는 것이다.

이들 다른 서브-시스템이 CDI 관점의 시스템과의 일관성을 유지하는 방식은 객체를 직접적으로 생성하거나, 적절한 데이터를 반환하여 객체가 인스턴스화될 수 있게 하는 CDI를 통하여 팩토리 객체를 호출함에 의한 것이다. 이러한 패턴을 이용하는 것은 시스템 확장이 팩토리 객체로의 이러한 호출을 가로챌 수 있게 하고 이들이 팩토리를 구현하고 본래의 인터페이스를 래핑할 수 있게 하는 결과를 가진다. 이는 시스템 확장이 임의의 시스템 양상을 모니터링하고 수정할 수 있음을 의미한다. 이는 플러그인될 수 있는 모니터링 컴포넌트가 임의적인 시점에서 시스템에 삽입될 수 있게 하는 것이 매우 유용한다.

지금까지는 본 발명의 인터페이스의 고 레벨 설명을 제공하였으며, 이하의 섹션에서는 구현-특정 정보를 포함하는 구현예를 기술한다. 상술한 바와 같이, 구현-특정 예가 제공되지만 본원에 기술된 본 발명의 원리에 따라 프린트 시스템을 구현할 수 있는 한 방식의 일례일 뿐이라고 이해되고 인식되어야 한다. 이와 같 이, 다른 실시예가 청구된 본 발명의 요지의 사상 및 범위로부터 벗어나지 않고 이용될 수 있다.

구현예

우선, 다음의 해설된 용어 및 두문자어가 다음의 설명 전반에 걸쳐 이용될 것이다.

ㆍ 액션( Action ) - 배치 참조

ㆍ 액세스 어댑터( Access Adaptor ) - 데이터 액세스 어댑터 참조

ㆍ 접근자( Accessor ) - 객체로부터 데이터를 검색하는 데에 이용되는 메소드. .Net 속성이 접근자의 일례이다.

ㆍ 배치( Batch ) - 누산된 이후에 한 시점에서 실행되는 액션들(Actions)의 시퀀스. 배치는 통상적으로 하나의 네트워크 호출이 일어날 것이다. 액션들은 획득(Gets), 설정(Sets), 질의(Queries), 명령(Commands) 및 통지 요청(Notification requests)일 수 있다.

ㆍ 배칭 집합( Batching Collection ) - 배칭 라우터에 플러그인되는 최고 레벨 인터페이스. 이는 수행될 액션들의 적절하게 라우팅된 배치를 수신한다.

ㆍ 배칭 라우터( Batching Router ) - 집합들의 세트 중 어떤 것으로 배치로 된 액션들이 전달되는 지를 선택하는 CDI 내의 구성요소

ㆍ 카노니컬 이름( Canonical Name ) - 시점 및 공간에서 객체 인스턴스를 고유하게 식별하는 이름. CDI에서 이는 집합 GUID 및 객체 GUID일 것이다. CDI는 카노니컬 이름에만 기초하여 라우팅된다. 애플리케이션은 시스템과 통신할 때 가 능한 임의의 곳에서 카노니컬 이름을 이용하여야 한다. 사용하기 편한 이름 참조.

ㆍ CDI - 공통 데이터 인터페이스 침조

ㆍ 클래스( Class ) - CDI에서는, 객체의 종류. 클래스는 프린터, 작업 또는 서버 또는 임의의 다른 논리적 부분일 수 있다. 클래스는 유형들로 구성된다.

ㆍ 클라이언트 집합( Client Collection ) - 클라이언트에서 보유되는 객체의 집합. CDI는 이들의 유형 맵들에 기초하여 클라이언트 집합에 객체를 채운다.

ㆍ 집합( Collection ) - 하나의 논리적 코드 조각에 의해 제공되는 객체의 이질성 세트. CDI는 카노니컬 이름에 기초하여 복수의 집합으로 요청을 라우팅한다.

ㆍ 집합 어댑터 서비스( Collection Adapter Service ) - 배칭 집합 인터페이스를 배칭 라우터에 노출시키고 객체의 세트가 노력을 덜 들이며 노출될 수 있게 하는 서비스들을 구현하는 서비스

ㆍ 명령( Command ) - 배치가 마지막으로 서버에 전송될 때 객체 상의 메소드가 실행되게 하는 배치 액션의 한 종류

ㆍ 공통 데이터 인터페이스( Common Data Interface ) - 카노니컬 이름을 통한 객체로의 액세스를 허용하는 컴포넌트. 이는 또한 호출들을 모두 배칭하는 것을 지원 및 객체로의 비동기식 또는 동기식 액세스를 제공한다.

ㆍ 데이터 액세스 어댑터( Data Access Adapter ) - 데이터 액세스 어댑터는 CDI에 플러그인되며 몇몇의 방식으로 그 기능을 변환한다. 이 어댑터는 CDI에 의해 노출되는 인터페이스를 다른 것(inproc Adaptor)으로 변형시킬 수 있거나, CDI에서 원격화(remote) 될 수 있는데, 이 경우 이 어댑터는 원격 액세스 어댑터 (Remote Access Adaptor )이다.

ㆍ 디스플레이 이름( Display Name ) - 사용하기 편한 이름 참조.

ㆍ 내장된 유형( Embedded Types ) - 다른 집합 내의 다른 객체에 의해 지원되는 속성들을 상당히 확장시키는 데에 이용되는 집합 내의 한 객체

ㆍ 필드( Field ) - 데이터의 명명된 조각

ㆍ 사용하기 편한 이름( Friendly Name ) - 디스플레이 이름이라고도 알려져 있음. 사용하기 편한 이름은 시스템이 객체 인스턴스를 식별하는 데에 이용되는 카노니컬 이름과는 다르게 사용자가 객체(프레드의 프린터)를 관련짓는 이름이다. 사용하기 편한 이름이 카노니컬 이름으로 변환되도록 하기 위하여, CDI는 이름 레졸루션 파이프라인( Name Resolution Pipeline )을 제공한다.

ㆍ 계층구조 - CDI에서 계층구조란 부모 객체로부터의 링크들을 찾기 위해 질의함으로써 얻을 수 있는 부모 객체와 자식 객체 간의 임의적 관계이다.

ㆍ In - proc Adaptor - 애플리케이션에서 실행되는 CDI 인스턴스를 가지고 in-proc를 실행시키는 데이터 액세스 어댑터의 한 형태이다. 이들은 통상적으로 데이터를 몇몇의 방식으로 변환하기만 할 것이다. 예를 들면, 데이터를 액세스하기 위해 API를 제공함에 의해서이다.

ㆍ 링크( Link ) - 객체들 간의 계층구조적 관계를 질의하는 데에 이용되는 특별히 예약된 클래스이다.

ㆍ 메타데이터( Metadata ) - CLR에서의 반영과 혼동하면 안된다. 메타데이터는 임의의 객체로부터 질의되어 이것이 지원하는 유형, 필드 및 명령을 찾을 수 있 다. 대응하는 어셈블리가 클라이언트에 이용가능한지 그렇지 않은지를 검색할 수 있다.

ㆍ 메소드 ( Method ) - 객체를 호출할 때 실행되어지는 그 객체 상의 실제 코드 조각이다. 약간 다른 개념에 대한 명령 참조.

ㆍ 이름 레졸루션 파이프라인( Name Resolution Pipeline ) - 사용하기 편한 이름을 카노니컬 이름으로 변환하기 위하여 애플리케이션 공간에서 실행되는 리졸버라 칭하는 앨리먼트의 시퀀스.

ㆍ 최적화된 유형 맵( Optimized Type Map ) - 필드 세트를 한 객체에서 다른 객체로 전송하기 위하여 이 두 객체에 대하여 수행될 획득 및 설정의 시퀀스. 이는 클라이언트 객체의 유형 맵의 필드 및 서버 객체의 유형 맵의 필드를 합함으로써 구축된다.

ㆍ 영속적인 객체 집합 서비스( Persistent Object Collection Service ) - 객체가 데이터베이스에 영속될 수 있게 하는 집합 어댑터 서비스에 플러그인되는 서비스

ㆍ 질의( Query ) - CDI의 관점에서, 최적화된 필터 및 최적화된 질의 베이스를 가지는 소정의 클래스의 객체 세트에 대한 요청.

ㆍ 질의 베이스( Query Base ) - 질의가 시작되는 개념적인 지점. 예를 들면, 베이스는 로컬 기기 또는 소정의 서버일 수 있다.

ㆍ 원격 액세스 어댑터( Remote Access Adapter ) - 원격 액세스 어댑터는 CDI에 의해 노출되는 인터페이스가 기기들 간에 원격화될 수 있게 한다. 이는 한 CDI 로의 객체의 집합 및 원격화되고 있는 CDI로의 데이터 어댑터로서 나타냄으로써 행해진다

ㆍ 리졸버 ( Resolver ) - 이름 레졸루션 파이프라인의 구성요소. 각각의 리졸버는 집합과 관련되고 이 집합 내의 구성요소를 식별하는 방식을 안다.

ㆍ 유형 맵( Type Map ) - 객체로부터 데이터를 검색하고 이 데이터를 객체에 적용할 방식을 기술하는 필드들과 그 관련된 접근자들의 테이블. 유형 맵들은 동적이거나 정적일 수 있다. 2가지 유형 맵들은 필드들을 비교함으로써 결합되어 최적화된 유형 맵을 산출한다.

ㆍ 유형( Type ) - 인터페이스와 유사하다. 유형은 항상 완전하게 구현되어야 하는 필드들 및 명령들의 논리적 그룹이다.

공통 데이터 인터페이스( Common Data Interface )

공통 데이터 인터페이스(CDI)는 (사용하기 편한 또는 바람직하게는 카노니컬) 이름으로 의해 객체를 찾아내는 것을 포함하는 함수를 제공하여, 객체로부터 데이터를 획득하거나 객체에 데이터를 적용시키며, 객체 변경에 대한 통지를 지원하고 객체에 명령을 발행한다. CDI는, 몇 가지만 언급하자면, 동기식 인터페이스의 이용, 확장성 부재, 이름 기반 라우팅 및 배칭 부재를 포함하지만 이에 한정되지 않는, 현재 아키텍처의 많은 한계를 해결하고 극복한다.

CDI는 임의적인 개수의 고유하게 식별가능한 집합이 시스템에 플러그인될 수 있게 함으로써 이를 행한다. 이들 집합은 이들이 원하는 임의의 종류의 객체를 지원할 수 있다. 인터페이스 자체는 비동기식 동작 및 배칭을 지원하기 위한 이유로 복잡하지만, 서비스들이 제공되고 집합들에 플러그인되어 보다 쉽게 작성될 수 있게 한다.

라우터 리-아키텍처( Router Re - architecture )

현재의 스풀러 아키텍처의 대다수의 기본적인 문제점은 라우터로부터 유래된다. 이는 동기식 API 세트의 이용, 자신의 제공자 모두를 시작시에 로딩(및 모니터링)할 필요성, 객체를 재명명할 수 없음, 임의의 스풀러 컴포넌트를 언로딩할 수 없음 및 시스템을 끌 수 없음을 포함한다. 이 섹션에서는 본 발명의 프린트 시스템에서의 라우터들을 위한 교체 아키텍처를 기술한다.

이하의 설명은 도 2에 도시된 개관 다이어그램에 기초한다. 이 예에서, 라우터는 훨씬 더 융통성있는 데이터 엑세스 메커니즘, 공통 데이터 인터페이스(CDI)로 교체된다. CDI는 기본적으로 액세스 어댑터와 집합 간의 라우팅 및 서비스 계층이다. 이는 복수의 프로토콜을 통하여 임의의 시스템에서 프린트 객체를 찾아내는 기능을 제공하고 서비스의 세트 또한 제공하여 모든 객체가 동일한 의미를 가지도록 한다. 이들 의미는 객체 데이터의 서브셋을 검색하고 설정하는 기능, 이들의 상태를 찾기 위하여 모든 객체를 질의하는 기능, 객체에 명령을 발행하는 기능 및 시스템 내의 모든 객체로부터 균일하게 변경 통지를 송신하는 기능이다. 데이터 액세스 어댑터는 in-proc 어댑터 및 원격 액세스 어댑터로 나뉜다.

예시되고 기술된 실시예에서, 모든 내부 컴포넌트 및 (집합 제공자 및 액세스 어댑터를 제외한) 애플리케이션 인터페이스는 오직 in-proc 어댑터와 인터페이스한다. 프로세스 경계를 통한 통신 및 클라이언트-서버 통신을 위하여 COM/DCOM 원격 액세스 어댑터가 이용된다. 웹-서비스 기반 시나리오를 위하여, SOAP 어댑터가 이용된다. 그 다음 어댑터는 다른 프로세스 공간 또는 다른 기기에서 집합으로서 나타난다. 이는 공통 데이터 인터페이스를 완전하게 지원할 수 있는 임의의 액세스 어댑터가 in-proc 어댑터를 통하여 항상 액세스될 수 있게 한다. 이 접속 스킴의 개관은 도 3에 도시된다.

다운-레벨 및 업-레벨 프로토콜 액세스(Down-level and up-level Protocol Access)

업-레벨 어댑터는 전체 공통 데이터 인터페이스를 전적으로 캡슐화할 수 있는 임의의 어댑터이다 - 오직 전체 in-proc 어댑터가 속성 기반의 관리되는 코드 어댑터가 될 것이다. 시스템으로의 관리되는 API는 시스템 기능들의 유용한 애플리케이션 서브셋만을 나타낼 것이다. 로컬 기기 및 내부 클라이언트-서버 기반 시나리오에서의 통신용인 외부 proc COM 어댑터를 포함하는 원격 액세스 어댑터 및 원격 액세스 어댑터와 웹 서비스를 통하여 데이터로의 액세스를 제공할 SOAP 원격 액세스 어댑터인 2가지 유형이 존재할 것이다.

어댑터들에 대한 다른 후보들은 CDI의 전체 성능을 이용할 수 있는 어댑터이며, 이들 자신들은 오직 제한된 데이터 유형들을 노출시키지만, 여기서 이들은 전체적인 데이터 구동 방식으로 매핑될 수 있다. 예를 들면, MOF 파일 데이터-유형과 공통 데이터 인터페이스 데이터 유형 간의 매핑이 전체적인 데이터 구동으로 이루어질 수 있다. MOF 파일은 윈도우즈® 관리 도구(WMI:Windows® Management Instrumentation) 시스템이 시스템 객체들을 기술하는 데에 이용된다.

보다 융통성이 떨어지는 다른 프로토콜들은 in-proc 어댑터를 이용하여 프린트 시스템 컴포넌트와 통신할 가능성이 가장 클 것인데, 예를 들면, RPC 클라이언트는 C++ 템플릿 라이브러리를 통하여 새로운 프린트 시스템과 통신할 것이다.

다운-레벨 제공자에 대한 지원은 내부-메모리 집합을 제공하고 사용자가 관리되는 클래스 및 객체 어댑터를 작성하여 데이터를 시스템에 제공할 수 있게 함으로써 간소화될 것이다. 다운-레벨 제공자는 시스템에 의해 이용가능한 특정 제한된 유형의 서브셋을 지원해야할 것이다.

공통 데이터 인터페이스 객체 모델( Common Data Interface Object Model )

예시되고 기술된 실시예에서, 공통 데이터 인터페이스(CDI)는 다음과 같은 속성들을 가진다. CDI는 객체 상의 개개의 속성들을 획득하고 설정하는 것을 지원한다. 이는 또한 질의 필터 및 속성 세트에 기초하여 객체의 그룹을 찾기 위하여 질의하여 각 객체로부터 검색하는 것을 지원한다. CDI는 객체에게 명령을 실행시키기를 요청하는 것, 매개변수 세트를 이 객체에 전달하는 것 및 이 객체로부터 반환 매개변수 세트를 수신하는 것을 지원한다. 또한, CDI는 객체 변경에 대한 통지를 요청하는 것을 지원한다. 통지는 호출자가 통지하기를 원하는 대상인 속성 세트 및 필터를 포함한다. 또한, CDI는 단지 in-proc이며, 인터페이스를 원격화하는 기능이 적절한 플러그인 어댑터에 의해 제공된다. CDI는 통지를 위한 콜백을 이용하고; 통지는 클라이언트에 의해 보유되는 접속들이 급격하게 서버 확장성을 줄이기 때문에 다소 난해한 역관계(trade off)를 제공한다. 이 문제를 해결하기 위하여, 2가지 통지 클래스가 이용될 수 있다: 첫째, 관리 통지들이 비동기식 인터페 이스를 이용하여 서버로의 접속을 보유할 수 있다. 이들 통지는 관리 목적을 갖도록 의도하는 데이터, 예를 들면, 논리적 큐에서의 작업들의 뷰를 자주 변경하기 위해 이용될 것이다. 둘째로, 상태 변경 통지들이 TTL 스킴 및 메세징 시스템(예를 들면, MSMQ)을 이용하여 전달을 보장하면서도 보다 적은 빈도의 통지를 송신할 수 있다. 통지 메커니즘이 서버측 질의를 지원할 것이기 때문에, 일반적으로 필요한 사용자 통지는 서버측 질의를 지정하고 보장되는 전달 메커니즘을 이용함으로써 구현될 것이다.

또한, CDI는 접근자들에 기초한다. 이 CDI는 사전 인터페이스를 노출시키지 않는다. 오히려, 객체 메타데이터를 검색하는 기능 및 데이터를 획득하기 위하여 질의 메커니즘이 제공되어 사전 인터페이스를 에뮬레이팅한다. CDI는 또한 복수의 객체 집합을 모두 통합한다. 전체 질의 지원을 제공하기 위하여 업-레벨 집합이 이용된다. 모든 프린트 집합은 유사하게 보여야 하기 때문에, 에뮬레이션 지원을 제공하기 위하여 다운-레벨 집합이 이용된다; 모든 객체를 에뮬레이팅하고 필터를 이들에 적용함으로써 질의가 구축된다. CPU 바운드가 아닌 임의의 메소드가 비동기식으로 호출될 수 있다.

공통 데이터 인터페이스는 객체 집합으로의 액세스를 허용한다. 모든 CDI 객체는 집합을 통하여 액세스된다. 모든 집합은 객체 클래스들의 세트로의 액세스를 허용한다. 객체 클래스는 객체의 클래스, 예를 들면, 논리 장치, 프로토콜 어댑터, 논리 서버를 식별한다. 객체 클래스는 프로그래밍적 이름에 의해 식별된다. 프로그래밍적 이름은 <Company>.<Class>[.<Version>] 형태로 되어야 한다. 이러한 이름은 객체를 식별하기 위하여 임의의 위치에서 이용될 수 있다. 문자열은 유니코드 문자열으로서 구현될 수 있지만, 다른 구현에서는 영어 식별자를 포함할 수 있다.

예시되고 기술된 실시예에서, 임의의 이전의 서버의 버전 또는 다운-레벨 서버를 나타내는 임의의 집합들을 포함하는 특정 객체의 클래스는 항상 시스템의 전체 수명 주기 동안에 동일한 프로그래밍적 이름에 의해 식별될 것이다.

소정의 객체 클래스는 복수의 유형으로 구성된다. 객체 클래스가 행하는 것과 동일한 방식으로 유형은 프로그래밍적 이름에 의해 식별된다. 유형은 복수의 필드로 구성되며 - 각 필드는 프로그래밍적 필드 이름 및 필드 유형에 의해 식별된다. 한 유형으로 된 필드는 운영 체제의 모든 버전에 따라서도 임의의 플랫폼 상에서도 변하지 않아야 한다. 유형은 또한 명령 및 필드를 캡슐화한다. 명령은 문자열에 의해 식별되고 복수의 정렬된 입력 및 출력 인수를 취한다.

CDI는 제3자에 의해 CDI를 통하여 송신된 메세지의 확장 및 인터셉션을 허용할 것이다. 이는 이들 제3자들이 객체 기능을 모니터링하고 확장할 수 있게 할 것이다. 객체는 또한 특정 호출을 포함된 객체로 재지정할 수 있을 것이다.

객체 명명( Object Naming )

예시되고 기술된 실시예에서, 객체는 항상 객체의 그 인스턴스를 정확하게 식별하는 고유한 카노니컬 이름을 갖는다 - 이 규칙은 다운-레벨 서버 상의 객체를 나타내는 집합에 대할 경우에서만은 예외이다.

객체는 객체 경로에 의해 식별된다. 객체 경로는 항상 이 객체가 포함된 집 합 인스턴스의 GUID로 시작한다. 따라서, {XXXXXXX}＼{YYYYYY}는 집합 {XXXXX} 내의 GUID {YYYYY}를 가진 객체를 말한다. 업-레벨 서버 상의 객체에 대하여 경로는 {WWWWW}＼<server>＼{XXXXX}＼{YYYYY}일 수 있는데, 여기서 {WWWW}는 원격 집합 GUID이고, {XXXXX}는 객체 {YYYYY}가 위치된 원격 집합이다.

모든 CDI 인스턴스는 파일 시스템 내의 현재 경로와 유사한 디폴트 집합의 개념을 지원한다. 그러므로, 애플리케이션 공간 내에 호스팅된 CDI는, 위성 샌드박스(sandbox) 프로세스들 및 애플리케이션 도메인 모두일 수 있으므로, 로컬 기기 상의 스플러로 설정된 이 CDI의 디폴트 집합을 가질 수 있다. 완전히 특성화된 경로가 없는 임의의 객체 카노니컬 이름은 자동적으로 디폴트 집합에서 검색될 것이다. 애플리케이션 공간 내에 구현된 집합(예를 들면, 로컬 서비스를 우회하는 서버로의 직접적인 네트워크 액세스)이 액세스되어야 한다면, 완전히 특성화된 경로(즉, "＼"로 시작하는 것)가 이용되어야 한다.

예시되고 기술된 실시예에서, 다음은 객체 경로의 예약된 문자: '＼',':','"','^' 및 '.'이다.

삽입기호 문자(^)는 이후의 문자를 탈출하는 데에 이용되고 문자열에서 임의의 문자가 표현될 수 있도록 한다. 유효한 탈출 문자들이 바로 아래의 테이블에 도시된다.

그러므로, 경로 내에 '＼'를 포함해야 하는 객체 이름을 구별하기 위하여, '＼'는 '^＼'에 의해 탈출될 수 있다.

사용하기 편한 이름 및 이름 레졸루션 파이프라인

선택적으로 객체에 사용하기 편한 이름(또는 디스플레이 이름) 또한 부여될 수 있다. 객체는 항상 다음과 같은 메커니즘을 이용하여 찾아내야 한다.

ㆍ 디스플레이를 위하여, 객체 클래스를 찾기 위한 기초가 없는 질의가 서비스에 대하여 생성될 수 있다. 이 클래스와 일치하는 모든 로컬 객체가 반환될 것이다. 그 다음 UI 형태는 이 반환된 객체의 카노니컬 이름을 이용하고 클래스 디스플레이 이름을 보여주어야 한다.

ㆍ (원격 서버 UNC 이름을 포함하는) 사용자 인터페이스에 직접 타이핑될 수 있는 이름들에 대하여, 이름 리졸버라 칭하는 플러그인될 수 있는 컴포넌트들의 시퀀스가 제공될 수 있다. 카노니컬 이름에 대한 "사용하기 편한 이름"을 결정하기 위하여 애플리케이션은 이들을 호출한다. 기존의 API는 OpenPrinter 및 ClosePrinter와 같은 사용하기 편한 이름 기반 호출을 카노니컬 이름 형태로 변환하는 데에 이름 리졸버를 이용할 것이다(이름 레졸루션이 느릴 가능성이 있기 때문에, 계층을 캐싱하는 것이 도입될 필요가 있을 것이다).

ㆍ 이름 리졸버들의 시퀀스는 소정의 이름 매핑의 순위를 내포할 것이다. 예를 들면, 원격 UNC 이름이 접속으로 업그레이드될 때, 동일한 이름이 원격 큐를 나타내는 큐 객체 보다는 논리 집합 내의 논리 큐 객체로 결정할 것이다.

ㆍ 애플리케이션은 이에 반환되는 가장 완전한 특징적 이름 바인딩만을 가지거나 이에 반환되는 사용하기 편한 이름에 대한 모든 이름 바인딩을 가지도록 선택할 수 있다. 결정을 위하여 많은 집합을 로딩할 필요가 있을 수 있기 때문에 모든 가능한 이름 바인딩을 반환하는 것이 더 비용이 들 것이다.

ㆍ 이름 레졸루션 구성요소를 가지는 것은 현재 라우터 아키텍처와는 다르게 전체 집합이 불필요하게 로딩되는 것을 방지한다. 이들의 객체에 대한 사용하기 편한 이름을 지원하기를 원하는 모든 집합은 구성요소를 결정하는 이름 또한 구현해야 할 것이다.

ㆍ 애플리케이션은 또한 이름 레졸루션을 수행할 때 의도를 기술할 수 있을 것이다. 예를 들면, 관리 애플리케이션은 캐싱되지 않은 정보만을 원한다는 것을 기술할 수 있다. 이러한 경우, 캐싱되지 않은 객체는 그 캐싱된 버전이 덜 이용가능한 경우에도 반환될 것이다.

보안( Security )

예시되고 기술된 실시예에서, 보안은 시스템에 의해 제공될 서비스 계층으로 밀접하게 맞추어진다. 그러나 보안이 동작할 방식에 대한 개관은 중요한 주제이며 이 모델의 전체적인 개관은 구현이 설명되기 전에 나타나는 것이 바람직하기 때문에 지금 제시된다.

도 4는 일 실시예에 따른 새로운 스풀러 보안 모델의 개념적인 도면을 도시한다. 새로운 스풀러 보안 모델의 한 목적은 CDI를 객체로의 경량의 내부 인터페이스로서 유지하여, 임의의 인증(authentication) 기능을 수행하지 않는 것이다. 또한, CDI는 원격 집합을 통하여 서버에게 데이터를 라우팅할 수 있다. 그 다음 허가(authorization)가 서버에 의해 수행된다. 그러므로, 본 발명에 따른, CDI 라우팅 계층은 허가 기능을 제공하지 않을 것이다. 마지막으로, CDI는 또한 인증이나 허가가 모두 필요하지 않은 애플리케이션 공간에서 실행될 것이다.

그러므로, 인증은 원격 액세스 어댑터에 의하여 액세스 전송 및 프로토콜과 일관되는 방식으로 수행되고 허가는 적절한 집합 서비스에 의해 수행된다(또는 원격 서버에게 미룬다). 이러한 접근법의 한 결과는 CDI 및 모든 집합이 허가되지 않은 사용자에 의해 액세스될 수 있다는 것이다. 이를 완화시키는 것을 돕기 위하여, 논리적 시스템 객체는 전체 프린트 시스템으로의 액세스를 제어하는 액세스 제어 리스트(ACL:access control list)를 기기에 제공한다. 명령의 배치가 원격 액세스 어댑터에 의해 수신될 때 이 배치는 논리 시스템 객체에서 액세스 검사를 수행한다. 명령들(뿐만 아니라 획득, 설정 및 질의들)은 액세스 검사가 성공할 경우에만 실행될 수 있다. 이러한 동작은 원격 액세스 어댑터에 의해 수신된 임의의 배치 명령에 대하여 한번 수행된다. 예시되고 기술된 실시예에서, 논리적 시스템 ACL은 ("Anonymous"가 아닌) "Everyone"이 디폴트이다. 관리자는 논리적 시스템 권한을 변경하여 전체 프린트 서브-시스템으로의 액세스를 제한할 수 있다.

예시되고 기술된 실시예에서, 원격 액세스 어댑터가 허가 없이도 논리적 기기 객체로 도달해야 할 필요가 있는 논리적 시스템 객체 상에서는 특수한 예약된 시스템 재설정(reset) 명령이 존재한다. 논리적 기기 객체는 오직 관리자만이 이러한 명령을 실행할 수 있게 하고 관리자를 논리적 기기 ACL로 다시 추가한다. 이 메커니즘은 관리자가 자신이 서브시스템을 절대로 다시 액세스할 수 없게 할 논리적 기기 객체로의 자신의 권한을 부인하는 것을 방지한다.

예시되고 기술된 실시예에서, 로컬 집합의 모든 객체는 이와 관련된 ACL을 가진다. 객체 상의 액세스 검사는 이 객체의 ACL에 대하여 액세스를 정확하게 검사하는 것을 포함한다. 각 객체 인스턴스는 그 클래스의 새로운 객체에 디폴트 상속적인 ACL을 제공할 클래스 객체를 포함하고, CDI는 클래스 객체의 집합을 보유한다. 관리자는 소정의 클래스의 임의의 새로운 객체에 디폴트 ACL을 제공할 클래스 ACL을 자유롭게 수정할 수 있다. 이는 관리자가 객체에 대한 생성 권한을 다른 사용자에게 위임할 수 있게 하지만, 생성 시에 여전히 디폴트 ACL을 그 객체에 적용한다.

예시되고 기술된 실시예에서, CDI는 객체의 로컬 집합이 가능한 쉽게 작성될 수 있게 하는 서비스 계층을 제공한다. 서비스 계층은 자유롭게 이것을 이용하는 임의의 객체 구현에 보안 인프라스트럭처를 제공한다.

권한이 변경될 때 모든 참여하는 클래스에게 새로운 ACL을 재귀적으로 적용시키는 권한 에이전트는 도 4에 도시되지 않았다. 이 에이전트는 클래스의 인스턴스에게 클래스 객체에 대한 변경을 전달하는 것을 담당하고 객체 인스턴스에 대한 임의의 관리적 계층구조 변경을 전달하는 것 또한 담당한다.

CDI 접근자 모델( CDI Accessor Model )

이 인터페이스의 보다 기본적인 양상들 중 하나는 접근자 모델이다. 이 메커니즘은 공통 데이터 인터페이스 및 집합이 호출자의 데이터 구조를 채울 수 있게 한다. 예시되고 기술된 실시예에서, CDI 액세스기 모델은 이 모델이 함께 동작하기를 의도한 프린트 스풀러가 관리되지 않는 코어 서비스로 구성되기 때문에 관리되지 않는다. 프린트 시스템의 컴포넌트 몇몇이 관리될 것이고 프린트 시스템의 데이터로의 완전한 액세스를 원할 것이기 때문에, 관리되는 코드 액세스 계층 또한 존재한다.

CDI 접근자 모델의 배경이 된 생각은 CDI가 클라이언트 객체의 집합과 서버 객체의 복수의 집합 간의 중개자라는 것이다. 이는 클라이언트 및 서버가 각각이 전송하고 싶어하는 필드만을 이용하여 이러한 정보를 교환하는 효과적인 메커니즘을 제공한다.

예로서, 일 실시예에 따라서, 서버 집합, 클라이언트 집합 및 CDI의 관점에서, 이러한 기능이 구현될 수 있는 방식의 양상을 도시하는 도 5를 고려해보자.

이러한 예에서, 서버와 클라이언트는 모두 이들이 노출하고 동일한 메커니즘을 통해 검색하기를 원하는 데이터-유형 맵을 기술한다. 유형 맵은 각각의 객체가 지원하는 다양한 서브타입 및 필드를 기술한다. 각 필드에 대하여, 기술하는 클래스의 모든 인스턴스에 대한 소정의 속성을 획득하고 설정하는 방식을 아는 인터페이스가 제공된다. 따라서, 유형 맵이 주어지면, 클래스 인스턴스의 모든 속성이 액세스될 수 있다.

클라이언트 및 서버 클래스의 설명이 주어지면, CDI는 훌륭한 최적화를 수행할 수 있다. 상세히는, CDI는 클라이언트 유형 맵 및 서버 유형 맵으로부터 각각의 필드 및 유형을 일치시키고 액세스 인터페이스만으로 구성된 최적화된 유형 맵을 생성할 수 있다. 이러한 최적화된 유형 맵이 2개의 객체 인스턴스에서 실행될 때, 모든 요청된 데이터는 어떠한 중간 저장 장치 또는 어떠한 데이터의 탐색도 없이 2개의 객체들 간에 전송된다. 최적화된 유형 맵의 목적은 타깃 객체가 일반적인 구조를 가진다는 사실을 이용한다는 것이다. 소정의 집합에 대하여, 서버측 객체는 일반적인 구조를 가진다. 그리고, 소정의 질의에 대하여, 일반적으로 시스템 내의 모든 객체로부터 동일한 데이터를 원한다. 그러므로, 소스 객체의 특정 클래스와 목적지 객체의 특정 클래스 간의 바인딩은 항상 동일하다. 또한, 소스 및 목적지 객체가 결국에는 시스템 컴포넌트이고 이들 자체가 일반적인 구조이기 때문에, 각각의 객체 인스턴스는 경량적인 방식으로 저장될 수 있다.

데이터가 검색될 수 있는 오직 하나의 서버 객체가 존재하는 경우가 충분할 것이라고 더 생각해보자. 그러나, 실제로는, 호환될 수 있는 서버 객체의 복수의 구현이 있을 수 있고 각각이 유형 맵을 가질 것이다. 그러므로, 클라이언트가 자신의 유형 맵을 CDI에 등록한다면, CDI는 GUID에 의해 탐색될 수 있는 최적화된 유형 맵들을 위한 저장 공간을 생성한다. 그 다음 서버 측은 필요할 경우 각각의 최적화된 맵을 저장한다. 그 목적은 클라이언트가 애플리케이션 시작 시에 자신의 맵을 등록하기 위함이다. 그 다음 클라이언트가 데이터를 검색하는 것을 시작할 때 시스템은 그 특정 클라이언트 유형에 걸쳐 최적화 세트를 작성한다.

탬플릿 파생된 유형 맵(Template derived type maps)

클래스 인스턴스에 대한 액세스 객체를 생성하는 것은 각각의 인터페이스 배후의 각각의 인스턴스가 오직 하나의 속성을 액세스하는 방식을 알기 때문에 많은 코드를 작성시킬 수 있다. 적절한 양의 작업이 각 인스턴스가 데이터를 이용하여 서버 및 클라이언트 내의 속성을 액세스할 수 있게 함으로써 저장될 수 있다(예를 들면, 필드 오프셋은 일반적으로 복수의 객체를 통하여 필드를 액세스하는 데에 이용된다). 이를 행하는 것은 코딩되어야 할 액세스 객체 구현의 개수를 급격히 줄여준다.

예시되고 기술된 실시예에서, CDI는 또한 사용자가 클래스를 정의하게 하고, 복수의 메소드 또는 필드를 생성한 다음 이들이 정의하기를 원하는 정의된 임의의 필드 또는 메소드들을 노출시키는 테이블을 작성할 수 있게 하는 템플릿 라이브러리를 제공한다. 템플릿 메커니즘은 클래스 필드 유형 또는 메소드 시그니처로부터 직접적으로 유형 정보를 추출하고 자동적으로 액세스 객체 인스턴스를 작성한다. 이는 클라이언트(또는 서버)가 IDL을 작성해야할 필요 없이 객체를 노출시킬 수 있게 한다. 그 다음 객체는 프린트 시스템에 의해 지원되는 임의의 전송을 통하여 지원될 수 있고 자동적으로 동기식 호출의 이점들을 수신할 것이다.

바로 아래의 발췌된 코드는 클라이언트가 서버로부터 검색하기를 원하는 구조를 정의하는 가장 간단한 메커니즘을 보여주는데, 에러 처리는 생략되었다.

유형 맵 메커니즘은 또한 호출자가 메소드를 기술할 수 있게 할 것이다. 다음의 발췌된 코드는 이러한 경우 메소드가 정의될 수 있는 방식을 보여주는데, 에러 처리는 생략되었다.

예시되고 기술된 실시예에서, 템플릿 라이브러리는 CDI 유형으로부터 C++ 타임으로의 매핑들의 코어 세트를 지원한다. 라이브러리는 제3자에 의해 확장가능하므로, 템플릿 라이브러리의 어떠한 부분도 변경시키지 않고 새로운 유형들이 도입되거나 정련될 수 있다.

공통 데이터 인터페이스를 이용하기( Using the Common Data Interface )

이 섹션에 나타난 소재는 상술한 소재를 확장하지만 상당히 저 레벨에서 이를 행한다. 본 명세서의 나머지 부분은 일 실시예에 따라 CDI의 구현 및 사용의 저 레벨 설명에 대한 것이다.

CDI 유형들( CDI Types )

CDI 유형 시스템은 복수의 표준 유형을 지원하도록 설계되며 이 유형들에 대한 보장을 시스템이 제공한다(예를 들면, 이들은 시스템에 의해 지원되는 임의의 프로토콜을 통해 동작할 것이며 대부분은 질의용으로 이용될 수 있다). CDI 유형 시스템은 또한 설계 시에 새로운 유형을 생성하는 메커니즘들을 제공하고 런타임 시에 시스템에서 이 메커니즘들을 이용한다.

이를 위해, ImgVariant 유형이 바로 아래의 발췌된 코드에 나타난 바와 같이 정의된다. 시스템 변형과 마찬가지로, 이는 유형 및 명명되지 않은 공용체(union)를 가질 수 있다. 그러나 이는 이하의 테이블에 나타난 바와 같이, 기본 유형의 매우 다른 세트를 시스템 변형에 지원한다.

다른 차이점은 ImgVariant 유형이 확장가능하다는 것이다. 이는 ImgType이 공용체가 아니라, 포인터로서 정의함으로써 수행된다. 이러한 선언은 바로 아래의 발췌된 코드에 나타난다.

새로운 유형에 대한 열거(enumeration)를 보관하기 위하여, ImgTypeReservation 전역 변수를 정의하고, 이 변수의 주소는 정의된 유형에 대한 보장되는 고유한 식별자가 된다. 마찬가지로 시스템은 자신만의 유형을 전역적으로 고유한 포인터로서 정의할 것이다. 이는 로더를 이용하여 유형들이 임의의 주소 공간 간에서 충돌하지 않는 것을 보장한다.

예시되고 기술된 실시예에서, 프린트 시스템은 변형을 조작하는 데에 다음의 메소드를 제공한다.

새로운 CDI 원시 유형들(New CDI Primitive types)

CDI ImgVariant 유형 자체는 CDI에 의해 정의되는 몇몇의 새로운 유형들을 포함할 수 있다. 이들은 다음의 순서로 존재한다:

IImgImutableString

이것은 ref-카운팅된 문자열이다. 이 유형은 CDI에 의하여 BSTR로 또는 BSTR로부터 자유롭게 변환될 것이고 이는 문자열의 효율적인 조작을 제공한다. 이러한 인터페이스 및 생성 함수는 바로 아래의 발췌된 코드에 나타난다.

Value 메소드는 변경되지 않는 문자열 내에서 보유되는 문자열으로의 포인터를 반환한다. 호출자는 값을 수정되면 안돼지만, 자유롭게 읽는다. 이 값의 주소는 변경되지 않을 것이며 비워지거나 수정되지는 않으면서 문자열 참조가 보유될 것이다.

NewInterface 메소드는 호출자가 동일한 문자열으로의 새로운 인터페이스를 요청할 수 있게 한다. 이 메소드는 참조 카운팅 문제를 방지하는 데에 유용하다. 호출자는 문자열으로의 단일한 스레딩된 인터페이스를 요청할 수 있다. 이러한 경우, 새로운 인터페이스 상의 참조 카운팅은 인터록(interlock)되지 않을 것이다. 호출자가 단일한 스레딩된 컨텍스트에서 복수의 문자열의 조작을 하고 있을 것임을 안다면, 이는 이들에게 이들의 성능을 향상시킬 수 있게 할 수 있다. ImgCreateString에 의해 생성되는 초기 문자열은 항상 자유롭게 스레딩된다.

IImgCanonicalName

이 유형은 내부적으로 및 다른 유형들에 대한 카노니컬 이름 참조를 제공하는 플러그인에 의해 이용된다. 이 유형은 바로 아래의 발췌된 코드에 나타난다.

카노니컬 이름은 객체 경로의 구문분석된 구성요소로 구성된다. 각각의 구성요소는 변하지 않는 문자열으로서 저장된다. 카노니컬 이름은 한 경로에 의해서 생성될 수 있거나, 변경되지 않는 문자열의 세트로부터 직접 구축될 수 있다. 예를 들면, 경로 "＼{GUID}＼abc^＼def"에 대하여, 카노니컬 이름은 2개의 문자열: "{GUID}" 및 "abc＼def"로 구성될 것이다. 인터페이스는 또한 호출자가 카노니컬 이름의 부분문자열(substrings)으로부터 경로를 구축할 수 있게 하는데, 예를 들면, 이들은 문자열 "ab＼＼cd", "efg"로 카노니컬 이름을 생성한 다음 경로 "ab^＼^＼cd＼efg"를 획득한다.

변경되지 않는 문자열과 마찬가지로, 카노니컬 이름은 변경되지 않으며, 스레딩 또는 참조 카운팅을 위하여 이 이름으로부터 새로운 별칭이 붙은 인터페이스를 획득할 수 있다.

IImgMultiValuedName

카노니컬 이름에 의한 참조를 복수의 서로 다른 객체에 반환하는 데에 복수의-값 이름이 이용된다. 이 복수의-값 이름은 2개의 객체 클래스들 간의 1-N 또는 N-N 관계를 나타내기 위하여 이용된다. 이 복수의-값 이름의 인터페이스는 바로 다음의 발췌된 코드에 나타난다.

복수의-값 이름은 카노니컬 이름의 세트로부터 구축될 수 있고 각각의 카노니컬 이름이 검색될 수 있다. 변경되지 않는 문자열 및 카노니컬 이름 인터페이스와 마찬가지로, 이 복수의-값 이름은 변경되지 않으며, 참조 카운팅 또는 스레딩을 이유로 이 복수의-값 이름으로의 새로운 인터페이스를 획득할 수 있다.

이들 인터페이스를 항해(navigating)하는 것은 호출자에게 다소 복잡하게 될 수 있기 때문에, 복수의 값 이름은 전체 첨부된 카노니컬 이름을 GetNamesAsStrings 인터페이스를 통하는 BSTR 경로의 배열로서 획득하는 메커니즘을 제공한다. 반환된 복수의-문자열을 비우기 위하여, ImgFreeMultiString 호출이 이용된다. 또한, 호출자는 경로의 복수의-문자열으로부터 복수의-이름으로 직행할 수 있다. 이는 정적인 경로 세트로부터 복수의-값 이름을 구축하는 데에 특히 유용할 수 있다.

새로운 변형 유형을 등록하기(Registering new variant types)

표준 변형은 항상 배선을 통하여 올바르게 마셀링(marshal)할 것이고 모두가 시스템에 의해 이용되는 질의 언어에서 지원할 것이다. 그러나, in-proc-경우에서 특히, 이는 변형된 유형들을 확장하는 데에 매우 유용할 수 있다. 이는 포인트, 또는 문자열으로 변환될 필요가 없는 프린트 가능한 영역과 같은 새로운 값 유형을 생성할 수 있게 한다. 대안으로, 명령의 일부로서 조작되거나 검색될 수 있는 인터페이스를 정의할 수 있게 한다. 이를 위해, CDI는 VariantCopy, VariantClear 및 VariantConvert에 의해 처리될 수 있는 변형을 확장하기 위한 메커니즘을 제공한다.

이 인터페이스는 다음의 발췌된 코드에 나타난다.

여기서, 등록된 유형들에서 모든 동작들을 수행하는 방식을 알고 있는 IImgVariantExtende 인터페이스에서 공급될 필요가 있다. 그 다음 또한 인터페이스에 의해 지원되는 유형 세트 및 인터페이스가 수행할 변환 세트를 제공한다. 그 다음 시스템은 기술되어 왔던 유형들을 위한 이들 인터페이스를 호출하는 것을 포함하도록 변형된 유형 처리를 확장할 것이다.

표준 변형 유형으로부터 또는 이러한 유형으로의 변환이 제공되면, 원격화 계층은 또한 배선을 통하여 적절한 데이터를 올바르게 마셀링 것이다. 이는 이 유형을 서버 객체와 동일한 프로세스 내에서 또는 배선을 통하여 투명하게 이용할 수 있게 한다.

유형 맵들을 등록하기( Registering Type Maps )

일단 클라이언트 유형 맵이 구축되면, 이 유형 맵은 CDI에 등록되고 인터페이스가 이 유형 맵 등록을 나타내는 클라이언트에 반환된다. 이 객체는 다양한 집합 클래스로 바인딩하는 데에 이용되는 최적화된 유형 맵을 축적한다. 이는 프로세스가 처음부터 이용하고 그로부터 소정의 유형 맵을 이용할 수 있게 하기 위해 의도하는 모든 유형을 등록할 수 있게 하기 위함이다. 최적화된 유형 맵이 구축될 때, 객체로부터 데이터를 질의하는 데에 요구되는 시간은 어떠한 필드도 비교될 필요가 없기 때문에 매우 작아진다. 유형 맵을 등록하기 위한 전체 인터페이스는 바로 다음의 발췌된 코드에 나타난다.

이 인터페이스용으로 이용되는 복수의 유형들이 존재하기 때문에, 각각을 다음에서 살펴보기로 한다.

EImgCopyFlags

이들 플래그는 복사 동작에 관련되며 클라이언트가 데이터를 복사할 때 직면하였던 임의의 이슈(issue)들에 대하여 알게 한다. 대부분의 플래그는 설명이 필요 없다. 다음은 몇몇의 보다 흥미로운 플래그이다:

ㆍ Private - 데이터는 시스템의 외부에서 복사되지 않아야 한다. 시스템의 일부로서 고려되는 다른 프로세스가 데이터를 수신할 수 있다. 이 데이터는 절대로 배선을 통하여 송신되지 않을 것이다.

ㆍ NotModified - 데이터가 서버 상의 데이터로부터 수정되지 않았음을 나타낸다. 이는 세트 동작을 최적화하는 데에 유용할 수 있다.

ㆍ CollectHistory - 이것은 CDI에게 수집되어야 할 이 필드에 대한 변경의 이력을 나타낸다. 디폴트 거동은 필드의 이력을 축약하는 것이다

ImgExtraCopyData

이것은 접근자에게 전달되어 플래그가 접근자에 의해 수정되고 삽입되게 한다. 이것은 또한 한 세트가 수행되고 있을 때 변경 핸들러를 접근자에 전달하는 데에 이용되어, 속성 값이 변경되는 경우 변경 처리기가 변경들을 송신할 수 있게 한다.

ImgFieldAccess

이것은 필드를 기술한다. 대부분의 구조 필드는 설명이 필요 없다. 클라이언트에서는 설명할 필요가 없다. 서버 상에서, 이러한 필드는 반영을 위해 이용될 수 있다. 서버 상에서 태그가 이용되어 특정 필드가 저렴하게 참조될 수 있다. 태그를 고유하게 유지시키는 것은 구조를 전달하는 모든 자들의 역할이다.

ImgFieldAccessors

이것은 필드 접근자들의 세트를 기술한다.

ImgClassDescription

이것은 클래스를 기술하고, 액세스를 획득, 및 접근자 설정을 지정한다.

IImgAccessor

이 인터페이스는 특정 필드로의 액세스를 할 수 있게 한다. ImgVariant는 데이터를 일시적으로 저장하고 데이터의 많은 다른 유형들이 전달될 수 있게 한다.

IImgTypeMaps

이 인터페이스는 클라이언트에 의해 배포될 수 있다. 차례로, 등록 시에서 전달된 모든 접근자 인터페이스가 배포될 것이다.

IImgCommonData

이것은 유형 맵을 등록하는 데에 이용될 수 있는 중앙 인터페이스이다. 이 인터페이스가 배포될 수 있고 유형 맵 등록은 유효한 상태를 유지할 것이다.

배칭 인터페이스

나머지 서브-섹션(즉, 객체 질의들, 객체 명령들 및 통지)은 매우 상세하게 데이터 액세스 인터페이스를 다룬다. 이 섹션들은 객체가 무엇이고, 클라이언트가 객체를 어떻게 얻고, 설정하고, 질의하는지를 다룬다.

클라이언트가 이들 객체를 액세스하는 데에 이용하는 인터페이스가 바로 다음의 발췌된 코드에 나타난다.

이 액세스 인터페이스는 새로운 개념을 노출시키며, 이 개념들은 예로서 다음을 포함하지만 이에 한정되지 않는다:

ㆍ 배칭 인터페이스(IImgBatch)

ㆍ 비동기식 프로그래밍 메커니즘(IImgAsyncResult)

ㆍ 클라이언트 집합 인터페이스(IImgClientCollection)

이들 인터페이스 각각은 우선 추상적으로 기술될 것이고 그 다음 이들 아이디어를 보다 구체적으로 하기 위하여 잠재적인 호출 시퀀스의 예가 나타날 것이다.

데이터 액세스 인터페이스에 발행되는 모든 액션이 배칭된다. 배칭 인터페이스는 IImgCommonData::GetDataBatch()로의 호출로부터 반환된 다음, 액션 세트가 배칭 인터페이스에 발행되고, 마지막으로 이 배치가 실행된다. 호출자가 단일한 액션을 발행하기를 원한다면, 이들은 한 액션의 배치 요청만을 생성한다.

어떠한 액션도 Execute 메소드가 호출될 때까지 실행되지 않는다. Execute는 (Execute가 호출되는지 BeginExecute가 호출되는지에 따라) 동기식으로 또는 비동기식으로 호출될 수 있다. 호출자는 완료 인터페이스로 전달할 수 있거나, 이들은 IImgAsyncResult 인터페이스로부터 반환된 wait 핸들을 이용할 수 있다. 호출자가 완료 인터페이스에서 전달된다면, 이들은 wait 핸들을 검색할 수 없다는 규칙이다. 호출자는 쿠키 인터페이스를 통하여 여분의 데이터를 호출과 관련지을 수 있다. CDI는 필요한 경우 쿠키를 비울 수 있도록 하기 위해 Done 메소드가 호출 완료 인터페이스에서 호출될 것임을 보장한다. 호출자는 배칭 호출의 결과를 검색하기 위해서 EndExecute 호출을 호출해야 한다.

호출자는 일련의 배치, 병렬 배치 또는 트랜잭션 배치 중 하나로서 배치를 열 수 있다. 넌-트랜젝션 배치는 트랜잭션 배치가 아닐 경우 부분적인 성공 반환을 가질 수 있다. 불행히도, 모든 집합이 트랜잭션을 지원하는 것은 아닐 것이며(이들 집합은 트랜젝션을 지원하지 않는 다운-레벨 시스템과 통신할 수 있다), 임의의 배치의 액션들이 넌-트랜젝셔널 집합 상에 있다면, 전체 배치는 실패할 것이다. 그러므로, 일 실시예에 따르면, 트랜잭션 배칭은 시스템 내부에서 주로 수행될 수 있거나 서버 버전은 오직 한번만 긍정적으로 식별되었다.

"모든 프린터 중지"와 같은 몇몇의 배치가능한 액션에 대하여, 한 큐가 중지하기를 실패함에 의해 모두를 중지하지 않는 것보다 큐의 반을 중지시킬 것이기 때문에 트랜잭션 적이 되는 것을 이해하지 못한다. 배치의 의미가 일련적이라면, 배치로된 액션은 일련적으로 실행되는 것을 보장한다. 배치의 의미가 병렬적이라면, 충분한 자원이 존재하거거나 이를 행하는 데에 최적화되어 있는 경우, 시스템은 액션들을 병렬적으로 실행시킬 수 있다. 이는 병렬 배치 의미에 대하여 임의의 액션이 임의의 순서로 실패할 수 있음을 의미한다. 트랜잭션 배치들은 또한 순차적인 의미를 내포한다.

배치로 된 각각의 액션은 증가하는 인덱스를 반환한다. 호출자는 이들이 배치 호출의 결과를 검색할 필요가 없을 경우 인덱스를 무시할 수 있다. (이는 트랜잭션 배치가 될 수 있고 배치의 상태는 액션의 상태이다). 각 호출의 결과는 배치의 인터페이스의 대응하는 "결과" 메소드를 호출함으로써 검색될 수 있다. 호출이 에러를 보고할 경우, 확장된 에러 정보가 배치로부터 반환될 수 있다.

실행의 동기식 형태 및 비동기식 형태는, 동기식 경우에서, 반환 상태가 EndExecute 호출로부터 반환된다는 점을 제외하고는, 동일하다. 배치 명령이 병렬로 실행되기 때문에, 배치는 부분적인 실패 결과를 가질 수 있다. 그 다음 각 인덱스는, 호출자가 원할 경우, 어떤 호출이 실패되고, 왜 실패되었는지 정확사게 판정하기 위해 질의된다.

일 실시예에 따라서, 배칭 인터페이스에서의 메소드들이 다음에 요약된다:

ㆍ GetObjectData - 소정의 유형 맵 및 호출자가 기술한 객체를 이용하여 소정의 객체 이름으로부터 데이터를 검색한다.

ㆍ SetObjectData - 소정의 유형 맵을 이용하여 소정의 객체에 데이터를 기록하여 데이터가 검색되는 객체 및 기록(클라이언트 집합 및 서버 집합 간의 접근자가 반대로 됨)을 작성한다. 데이터가 원격 목적지로 송신되고 있다면, 컨텐츠는 먼저 이 객체로부터 복사되었을 것이다. 데이터가 로컬 객체에 대하여 설정되었다면, 컨텐츠는 추후에 실제 설정이 일어날 때에 복사될 것이다.

ㆍ QueryObjectData - 특정 객체 클래스에 대하여 질의를 발행한다. 질의는 이하 보다 상세히 기술된다. 질의는 개념적으로 단 하나의 객체가 아닌 질의를 만족시키기 위하여 다수의 객체가 집합으로부터 할당될 것이라는 점을 제외하고는 획득(Get) 명령과 상당히 유사하다.

ㆍ IssueCommandToObject - 객체에 대한 명령을 발행한다. 명령들은 이하 보다 상세히 기술된다. 명령은 소정의 객체에 대한 특정 유형에 발행된다. 명령 자체는 유니코드 문자열이며 입력 인수의 정렬된 리스트를 수신한다. 출력 매개변수는 ResultIssueCommand 호출을 통하여 호출자에 의해 검색될 수 있다.

ㆍ Execute - 지금까지 실행될 모든 명령이 배칭되도록 한다.

ㆍ Cancel - 실행 호출 이후에 현재 진행중인 임의의 액션을 취소한다. 또한 호출이 실행되기 전에 배칭 인터페이스로부터 임의의 명령들을 플러슁(flush)한다.

배칭 인터페이스는 Cancel 호출 반환 이후에, 또는 동기식 Execute 호출이 완료되거나 비동기식 EndExecute 호출이 반환된 이후에만 재사용될 수 있다.

도 6은 배치 호출 명령의 도면을 도시한다. IImgDataBatch 인터페이스가 실행된 명령들의 리스트를 작성했다고 가정한다.

질의, 명령 및 통지는 다음의 섹션에서 상세히 다룰 것이다. 따라서, 객체의 상태를 획득한 다음 객체의 이름 및 주석을 변경시키고 변경을 다시 적용시키는 간단한 코드 조각이 다음에 나타난다. 이 코드는 비동기식 배칭 인터페이스를 나타내기 위하여 비동기식 호출 형태로 작성되었지만, 절대로 이렇게 복잡할 필요는 없다.

객체 질의(Object Queries)

이 섹션은 객체 질의를 기술한다. IDataAccessBatch에 의해 노출된 인터페이스는 바로 아래에 도시되어 있다.

typeMap과 clientCollection 매개변수는 이미 설명되었다. queryString 매개변수는 질의를 제어한다. 이것이 널(null)이면, 질의는 질의 베이스에 의해 명시되는 소정의 유형의 모든 객체를 요청한다. 이것이 널이 아니면, 질의용 필터를 명시한다. 질의는 질의 베이스, 질의 클래스, 및 질의 문자열로 구성된다. 질의 문자열은 좀 더 나중에 다루어진다. 질의 베이스는 질의용 루트 객체, 즉 그 아래에 다른 객체가 존재한다고 생각될 수 있는 객체(작업 열거용 질의 베이스는 프린터 또는 서버 객체일 수 있음)이다. 질의 베이스 관계는 전형적으로 계층구조적이 아니고 관계적이다(즉, 당신은 질의 베이스 아래에 2개 레벨 객체를 열거할 수 없다). 그러나, 엄격한 계층구조와는 달리, 객체는 여러 다른 질의 베이스 아래에 위치될 수 있다. 이는 기본 저장소가 관계형이란 사실을 반영한다. 질의 베이스를 지원하는 주된 이유는 질의 구현에 근거하여 다운-레벨 열거가 열거용 루트 객체를 쉽게 찾아내도록 허용하는 것이다. 그러나 질의 베이스는 업-레벨용 질의의 구문분석을 복잡하게 한다.

질의 및 유형의 샘플 리스트는 바로 아래의 테이블에 도시되어 있다. 집합의 객체가 집합의 프로그램적 이름을 사용할 수 없음에 유의해야 한다. 그들은 사용하기 편한 이름에 대해 이름 레졸루션 메커니즘을 사용해야 하고, 그런 다음 그 객체를 지칭하는데 내부적으로 뉴메릭(numeric) 객체 이름을 사용한다. 집합은 질의용으로 프로그램적 이름을 사용하여 명시되게 되는데, 왜냐하면 문자열이 인간에 의해 보다 잘 수집되는 경향이 있기 때문이다.

원격 집합은 로컬 기기에 대한 질의용으로 임의 객체를 반환하도록 요구되지 않음을 인식해야 한다. 그들이 모든 서버에 질의하는 것은 너무 비효율적이다. 질의 문자열은 소정의 객체가 가져야 하는 특성을 명시하는 필터이다. 필드는 이하 형태를 취한다.

Programmatic.Type.Name.Version:FieldName.

나중 질의는 데이터 내에 내장된 XML 문서 내의 데이터를 액세스하도록 허가될 수 있다. 이들 질의는 이하 형태를 가질 수 있다.

Programatic.Type.Name.Version:FieldName\Node\Node\Property.

유효한 연산자 및 그 순위는 바로 아래 테이블에 도시된다.

필드가 상수와 비교될 수 있다. 다음은 유효한 상수이다.

● 임의 정수. 정수는 십진수 또는 십육진수 형태로 표현될 수 있음.

● 임의 부동 소수점

● 인용 부호로 구별된 문자열. 인용 부호가 문자열의 일부일 필요가 있을 경우, BASIC 스타일 " "이 사용된다.

유효한 질의가 바로 아래에 도시된다. 일부 공통으로 액세스된 객체의 의미론을 간략화하기 위해, 다운-레벨 서버와의 손쉬운 상호운용성을 허용하는 잘 정의된 질의 베이스가 존재할 수 있다. 이 베이스는 이하를 포함할 것이다.

● 프린트 큐 질의 - 질의 베이스는 프린트 큐를 포함하는 서버 객체이어야 한다.

● 작업 객체 질의 - 질의 베이스는 작업을 포함하는 큐 또는 서버이어야 한다.

하기의 제약은 일 실시예에 따른 질의에 적용된다.

● 질의가 필드를 뉴메릭 유형(정소 또는 부동 소수점)과 비교하는 경우, 실제 필드는 뉴메릭이어야 한다(32 bit 정수, 64 bit 정수 또는 double형)

● 질의가 필드를 문자열 유형과 비교하고, 비교 연산자가 CONTAINS이 아닌 경우, 단지 유효한 필드 유형은 BSTR 또는 IImgImutableString이다.

● CONTAINS 연산자는 단지 문자열 유형에 대해 작업한다. 단일 값의 문자에 대해, 등가를 체크하는 것에 이른다. 카노니컬 이름에 대해, 경로가 동일하다고 체크하는 것에 이른다. 다중-문자열(multi-string)에 대해, 이는 다중-문자열의 문자열 중 하나가 같은가를 체크하는 것을 평가한다. Multi-Valued Name에 대해, 이는 다중-값의 이름(multi-valued name)의 카노니컬 이름 중 하나에 의해 표현된 경로 중 하나가 contains 연산자가 지칭하는 문자열과 같은가를 체크하는 것이다.

● Bitwise AND 연산자는 단지 적분(integral) 유형에 적용된다.

이런 설명을 보다 구체화하기 위해, 바로 아래에 발췌된 코드가 샘플을 제시한다. 이는 프린트 객체 세트에 대해 질의하고, 그런 다음 그것들을 열거한다. 이 샘플은 IAsyncResult 인터페이스의 대기가능한 형태를 사용한다. 다시, 이런 예에서, 이것은 필요하지 않으나, 인터페이스의 다른 사용을 도시한다. 우리는 템플릿 라이브러리의 특징을 사용하여 IImgClientCollection 및 호출자의 열거자를 자동으로 작성함을 인식해야 한다. 에러 처리는 간결함을 위해 생략된다.

객체 명령(Object Commands)

객체 집합에 대한 질의하기 뿐만 아니라, 명령이 소정의 객체에 발행될 수 있다.

객체에 대한 명령은 객체가 가질 수 있는 다른 집합으로부터의 임의 내장된 임의 유형을 포함하는 유형에 맞추어져 있다. 이는 확장되거나 인스턴스 마다 기초한 객체의 명령 세트를 허용한다.

일 실시예에 따라, 명령은 다음의 속성을 가진다.

● 명령은 절대 캐시되지 않고, 데이터는 캐시될 수 있다.

● 명령은 실패 예외처리를 넘어서 매개변수를 호출자에게 반환할 수 없다.

● 명령은 정해진 세트의 순서화된 입력 및 출력 매개변수를 가진다. 명령은 오버로드 또는 확장될 수 없다. 명령의 의미론은 시스템의 새 버전들에 대해 변경될 수 없다(명령은 못쓰게 될 수 있고, 나중에는 지원이 중단될 수 있다).

명령은 객체 작성 및 객체 삭제에 사용될 것이다. 객체 삭제의 경우, 예정된 유형 및 메소드가 정의된다-"Microsoft.GenericObject.1", 명령 "Delete". 모든 삭제가능한 객체는 이 명령을 노출하도록 요구된다. 모든 내장된 객체는 또한 이 명령을 노출하도록 요구된다. 내장된 객체를 포함하는 객체가 삭제될 때, 이는 모든 내장된 객체가 자기 자신을 삭제할 것을 요청한다.

모든 보안성 있는 객체가 노출하도록 요구되는 다른 명령은 "Microsoft.GenericObject.1" 명령 "AccessCheck"이며, 이는 단일 매개변수-허가 객체를 취할 것이며, 참 또는 거짓을 반환한다. 이 명령은 임베디드 유형에 의해 사용되어, 임베디드 객체가 자신 자신의 집합을 통해 액세스될 때, 임베디드 객체가 그 내장된 객체와 동일한 보안 의미론을 시행하도록 보장한다.

명령 호출 결과로부터 반환된 매개변수의 존속기간은 배치의 존속기간과 동일하다. 배치가 Released 되거나, Canceled 또는 다른 액션이 그 배치에 대해 수행되어, 명령 매개변수가 지워질 것이다.

최종적으로, 명령 인터페이스의 샘플 사용이 바로 아래에 제시된다. 이는 이전에 발견된 프린트 큐로부터의 스트림 객체를 요청한다.

통지(Notifications)

통지는 또한 객체, 객체 클래스, 서버, 또는 집합으로부터 수신될 수 있다. 이 인터페이스는 또한 클라이언트로부터 배치된다. 인터페이스는 바로 아래에 도시된다.

이 인터페이스는 예컨대, 통지 집합, 통지 객체, 통지 필터, 및 통지 채널에 의해 포함되는 것 중에서 수많은 새로운 개념을 노출시킨다. 이 인터페이스는 2개의 다른 액션 RegisterNotificationCollection 및 ResultNotificationCollection으로 배치 인터페이스를 확장한다.

통지 집합은 좀 더 풍부한 의미론을 가진 클라이언트 집합이다. 이는 동질 클라이언트 객체 집합이다. 각 객체는 유형 맵으로 설명될 수 있다. 특정 객체 변경에 대한 통지가 발생할 때 또는 객체가 추가되는 경우, 객체가 검색되고, 파퓰레이트된다. 그 객체에 대한 새 데이터가 이곳에 놓여지고, 구현자가 임의 필요한 수행하도록 허용하는 객체의 EndNotifyChanges 메소드가 일단 그 객체가 갱신되면 호출된다.

호출자에 의해 명시된 통지 집합은 항상 직렬로 갱신될 것이다(즉, 이는 멀티 스레드에 의해 호출될 수 있지만, 단지 한 스레드가 한 순간 이를 호출할 것이다). 통지 집합은 단지 Populate 또는 Update 호출이 채널에 행해질 때, 갱신될 것이다. 그러므로, 호출자는 그들이 멀티-스레드디(multi-threaded) 액세스를 그들의 객체에 수행하는 경우에, 적절한 잠금을 Populate 또는 Update 호출에 해놓음으로써 그들의 객체를 보호할 수 있다. 호출자가 통지에 대한 콜백(callback)을 지정하는 경우, 단지 하나의 스레드만 한 순간에 콜백으로 실행되도록 보장받는다.

통지는 다음의 방식으로 작동한다. Populate 호출이 채널에 행해질 때, 객체는 지정된 집합으로부터 Add 메소드를 통해 할당될 것이다. 그런 다음, 객체는 EndNotifyChanges 호출로 호출될 것이며, 이것이 이 시점에 갱신 사이클 또는 파퓰레이트 사이클인지 여부를 객체에 전달될 것이다,

그런 다음, 통지가 통지 채널을 통해 수신된다. 호출자가 콜백을 지정하였다면, 콜백은 새로운 갱신이 수신될 때(또는 채널이 에러를 생성할 때) 호출될 것이다. 호출자가 콜백을 지정하지 않았다면, 대기 핸들이 이용가능하게 되거나 또는 채널이 IsCompleted 메소드용으로 폴링될 수 있다. 통지가 서브시스템에 의해 수신되나, Update 메소드가 채널상에서 호출될 때까지 클라이언트 객체에 적용되지 않는다. 채널이 몇몇 이유로 망가지는 경우, 갱신은 적절한 에러를 반환할 것이다.

Update에 대한 호출 동안에, 클라이언트 객체는 어떤 속성이든지 서버상에서 변경되면 이에 따라 갱신될 것이다. 임의의 새 객체가 서버상에서 생성되는 경우, 또는 객체들이 통지 필터에 매칭되는 경우 중 어느 한 경우에, 집합은 Add 메소드에 대한 호출을 수신할 것이고, 집합은 통지에 대한 이유가 객체가 통지 필터에 매칭됨에 대한 것인지 또는 그 객체가 새로운 것임에 대한 것인지 알게 될 것이다.

유사하게, 임의 객체가 필터에 매칭되지 않을 경우, 또는 객체가 삭제될 경우, 집합에 대해 Remove 메소드가 호출된다.

객체가 그 속성에 대한 직접적인 호출을 통해 갱신된다. 갱신은 BeginNotifyChanges 및 EndNotifyChanges에 대한 호출에 의해 괄호로 묶일 것이다.

호출자가 통지를 수신하는 것을 멈추길 원할 때, 호출자는 그들이 수신했던 INotificationChannel 인터페이스를 해제한다.

집합의 2개 필드에 대한 통지를 모든 로컬 객체로부터 수신하는 샘플 코드가 바로 아래에 도시된다. 이 샘플 코드는 로컬 집합의 모든 프린터들에 대한 자격(Status) 및 이름(Name) 필드에 대한 변경을 수신한다. 프린터가 스크린상에서 질의 결과로서 갱신된다고 가정한다. 에러 처리는 가독성을 위해 생략된다.

클라이언트 집합( Client Collections )

CDI 인터페이스의 한 양상, 즉 데이터를 중간 데이터 객체로 기입하여 그 데이터 세트를 전파하기 보다는 클라이언트 집합 및 클라이언트 객체를 파퓰레이트하는 것을 선택하는 것은 몇몇 이점을 가져온다.

예를 들어, 이를 행하여 통지와 데이터 파퓰레이션은 매우 유사하게 취급될 수 있다. 이것이 클라이언트 관점으로부터 의미하는 것은 클라이언트 객체가 이런 두 가지 경우 간에 매우 쉽게 재이용될 수 있다는 것이다. 또한, 이를 행하여 클라이언트 코드는 최대로 효과적이 될 수 있다. 상세히는, 일단 데이터가 클라이언트 객체로 수집되면, 이것은 구조 내에서 오프셋(offset)로 고유하게 참조된다. 데이터가 중간 집합으로 저장되는 경우, 클라이언트는 데이터를 클라이언트 객체로 차례로 복사하여 이를 조작하거나, 데이터가 매 시점마다 집합으로부터 검색되어야 한다.

클라이언트 집합 및 클라이언트 객체는 클라이언트 코드의 실패 상태를 데이터가 집합으로부터 복사될 때가 아닌 데이터가 파퓰레이트될 때로 제한한다. 이는 클라이언트 코드의 복잡성을 상당히 감소시키는 가능성을 가진다. 중간 집합이 사용될 때는, 집합의 데이터가 액세스될 때마다 실패의 가능성이 존재한다.

또한, 클라이언트 집합 및 클라이언트 객체를 파퓰레이트하는 것은 여러 종류의 집합이 사용되도록 허용한다. 본질적으로, 이런 메커니즘은 완벽하게 융통성있는 작성자 패턴을 캡슐화한다. 이는 포괄적 "클라이언트"가 유형 맵을 동적으로 작성할 수 있고, 유형 맵을 클라이언트가 좋아하는 중간 집합의 임의 종류로 매핑할 수 있다는 것을 의미한다. 이는 관리되는 데이터 제공자를 위한 데이터 세트(Data Set) 객체를 작성하는데 사용될 수 있다. 대안으로서, 이는 데이터의 XML 뷰를 작성하는데 사용될 수 있다. 이는 중간 데이터 세트의 끼워넣기(interjection)에 의해 야기된 충실도(fidelity) 또는 성능의 손실 없이 행해질 수 있다. 또한, 관련된 속성은 클라이언트 집합 및 클라이언트 객체를 파퓰레이트하는 것에 의해, 클라이언트 집합은 쉽게 원격화될 수 있는 형태로 데이터를 준비하는 액세스 어댑터가 실제로 될 수 있다. 그러나 부정적인 측면으로, 이는 또한 클라이언트 객체가 그것이 검색하길 원하는 각각의 속성에 대한 접근자를 노출하도록 강요할 수 있다.

동적 유형 맵( Dynamic Type Maps )

예시 및 기술된 실시예는, 사용자가 하나의 객체 인스턴스를 가지길 원하지만 호출하는 상태에 따라 서버 객체로부터 동적으로 다른 필드를 검색할 수 있기를 원할 때, 그 상황을 해결하는데 이용될 수 있다.

이런 경우가 발생할 수 있는 2 경우가 존재하는데, 한 경우는 많은 속성을 가진 구체적인 객체가 존재하지만 호출자가 소정의 호출에서 전파되길 원하는 속성이 동적일 때이며, 다른 한 경우는 호출자가 정말로 데이터를 완벽히 동적으로 취급하길 원할 때이다. 각 경우가 예시 및 기술된 아키텍처에서 솔루션을 가진다.

첫 번째 문제를 해결하기 위해, 예시 및 기술된 실시예는 클래스로부터 서브세트 동적 유형 맵을 작성하기 위해 각 속성에 연관된 태그를 사용한다. 이런 태그는 또한 템플릿 라이브러리의 일부로서 명시될 수 있다. 템플릿 라이브러리는 명시된 태그에만 매칭되는 부분적인 유형 맵을 검색할 것이다. 이 솔루션은 바로 아래에 발췌된 코드에 도시되어 있다.

완벽히 런타임 결정된 속성의 완벽히 랜덤한 세트가 원격 서버로부터 검색되도록 허용하는 것도 유형 맵 인터페이스를 통해 달성될 수 있다. 설사 이런 경우, 그것은 클래스에 바운드되는 한 세트의 속성을 가질 수 없다. 저 레벨의 유형 맵 인터페이스의 강력함 및 융통성은 실제로 이런 경우에 작용한다. 이런 경우, 호출자는 모든 인터페이스가 또한 객체 인스턴스이며 직접 변형 유형을 사용한다는 사실의 이점을 취할 수 있다. 이는 도 7에 도시되어 있다.

거기서, 각 인터페이스는 실제로 정적 메소드 또는 필드보다는 오히려 객체를 지칭한다. 각 객체는 이것이 최종 목적지 객체를 조작하는 방법에 관한 상태의 몇몇 종류를 유지한다. 이런 경우, 이는 목적지 객체가 유지하는 객체 배열로의 인덱스를 유지한다. 목적지 객체의 배열의 크기는 가변적이며, 대리 객체와 유형 맵 모두가 동적으로 작성될 수 있다. 그러므로 이 메커니즘은 호출자가 임의 소스 객체에 바인딩하도록 해주며, 임의 소스 객체가 계속 작성되도록 해준다.

예시 및 기술된 실시예에서, 이 메커니즘은 실제로 완벽하게 일반적이다. 인터페이스가 XML 문서를 작성하는데, 데이터세트를 생성하는데, 또는 데이터를 스크린에 기입하는데 참여할 수 없는 특별한 이유가 존재하지 않는다. 이는 또한 객체의 집합을 임의 형태로 작성하는데 사용될 수 있다. 이는 longhorn API 또는 다른 데이터 액세스 API에 브릿지될 때 가장 유용하다.

이 스킴을 구현하는 코드가 바로 아래에 도시되어 있으며, 배치 인터페이스를 통해 하나의 객체를 액세스하는 것을 포함한다(에러 처리는 생략됨).

특성 템플릿 라이브러리 및 상속( Attribute Template Library and Inheritance)

템플릿 라이브러리에 대한 흥미로운 양상 중 하나는 이것이 객체 간 상속(다중 상속을 포함함)을 지원한다는 것이다. 이 사실은 이것이 서버상에 존재할 경우보다 클라이언트 상에 있을 경우 덜 유용하다. 서버상에서, 이는 공통 기능, 및 대응하는 필드와 메소드가 베이스 클래스에 저장되도록 해주며, 필요한 때 파생 클래스로 삽입(pull)되도록 해준다.

상속을 지원하는 것 외에, 라이브러리는 또한 가상적인 메소드를 올바르게 처리한다. 즉, 베이스 클래스의 가상적인 메소드는 베이스 클래스 유형 맵에서 참조될 수 있고, 그런 다음 파생 유형 맵의 파생 클래스를 올바르게 호출할 것이다. 유형에 대한 작업 세트의 예가 바로 아래에 발췌된 코드에 도시되어 있다. 이 코드는 클래스의 구조만 보여주고, 임의 구현은 간결함을 위해 생략된다.

이 예에서, 파생 클래스는 하나의 가상적인 메소드를 오버라이드하고, 2개 pure 메소드를 구현한다. 다른 필드와 메소드 모두는 베이스 클래스로부터 삽입된다. 파생 클래스의 메소드는 그 테이블의 정의가 베이스 클래스에서 정의된 테이블로부터 실제로 삽입되는 경우라도 여전히 호출된다.

파생 테이블은 테이블에서 "상속" 필드를 가진 베이스 클래스 테이블의 정의에서 나온다. 베이스 클래스와 베이스 클래스 테이블로의 임의 확장은 즉시 파생 클래스의 테이블에 반영될 것이다. 그러므로, 테이블이 올바른 다중 상속을 구현할 수 있다.

커서( Cursors )

커서는 호출자가 하나의 요청으로라기 보다는 한 번에 한 청크(chunk) 씩 서버로부터 데이터를 검색하도록 해주는 인터페이스이다. 이는 특히 열거될 필요가 있는 많은 개수의 객체가 서버상에 존재할 때 유용하다. 이는 하나의 호출로 네트워크에 걸쳐 반환되어야 하는 데이터 양을 감소시키며, 이는 서버 측의 작업 세트를 감소시킨다. 매우 많은 객체 집합에 대해, 이것은 또한 클라이언트가 모든 객체들을 메모리에 저장하지 않아도 되도록 해줄 수 있다. 대신에, 클라이언트는 테이블 내로 커서를 유지할 수 있고, 요구된 것보다 많은 행을 검색할 수 있다. 이런 특정 구현예에서, 커서는 현재 많은 이유로 인해 CDI에 구현되어 있지 않다.

● 서버상에서 유지되는 객체의 개수는 전형적인 데이터베이스에 저장된 것과 같은 크기의 같은 차수가 거의 아니다. 클라이언트가 데이터의 복제본을 저장하기에 충분한 메모리를 가지고 않을 가능성이 매우 크다.

● 대부분의 큐들이 작업을 수신할 것이기 때문에, 서버상의 많은 객체가 할 수 없이 활성화된다. 그러므로, 작업 세트가 데이터베이스에서보다 적게 고려된다.

● 네트워크 트래픽이 2 단계(pass)의 질의, 즉 각 객체의 카노니컬 이름을 검색하는 초기 질의와 각 객체에 대한 데이터를 검색하는 제2 세트의 GetObjectData 호출을 행함으로써, 임의로 감소될 수 있다. GetObjectData 호출이 임의로 청크될 수 있으므로, 당신은 각 객체로부터 데이터를 검색하기 위해 네트워크 라운드 트립할 필요가 없다.

● 호출자는 정확한 질의 필터를 명시할 수 있기 때문에, 데이터 세트의 크기는 더욱 작아질 수 있다. 예를 들어, 클라이언트 스풀러(spooler)는 모든 작업을 열거해야함 없이 오히려 소정의 사용자에 속하는 작업에 대해 열거할 수 있고, 소정의 사용자에 속하지 않는 작업은 필터링할 수 있다.

● 호출자는 그들이 어떤 필드를 검색하길 원하는지 자세히 명시할 수 있기 때문에, 데이터 양은 그 융통성 없는 정보 레벨 시스템을 가진 현재 시스템에서 더욱 감소될 수 있다. 예를 들어, 현재 큐의 작업 개수를 검색하기 위해, 호출자는 또한 디폴트 DEVMODE 및 보안 서술자를 포함하는 PRINTER_INFO_2를 명시해야 한다.

● 인터페이스는 통지를 제외한 와이어 레벨에서 현재 스테이트리스(stateless)한 것이다. 커서는 많은 서버 상태를 초래할 수 있다. 이는 커서에 필요한 상태를 유지하기 위한 오버헤드가 특히 정해진 이동 횟수에서, 이로부터 파생된 이득을 초과한다는 것일 수 있다.

그럼에도, 시스템의 일부 지점에 커서를 구현하는 것이 바람직할 수 있으며, 특히, 프린터 시스템이 문서 저장을 행하도록 확장되는 경우 또는 대용량 프린터 서버가 소수만 활성화되는 매우 많은 개수의 큐를 처리하게 될 수 있는 경우 그러하다(객체를 메모리에 불필요하게 풀링하는 것을 방지하는 것이 이런 시나리오에서 매우 중요하다). 이 섹션은 단지 질의용 커서에 대하여 공평한 할인가격을 초래하는 메커니즘을 기술한다.

통지에 관해서, 통지가 클라이언트 인터페이스에 대한 어떤 변경도 요구하지 않음을 고려한다. 와이어 인터페이스는 파퓰레이트된 데이터를 클라이언트에 청크로 전송하고, 클라이언트 객체를 갱신하기 시작할 것이다. 최적화된 성능을 위해, 갱신은 원래의 파퓰레이트에 삽입될 수 있다.

클라이언트 커서에 관해서, 다음 것을 고려한다. 예시 및 기술된 시스템의 한 가지 목적은 가능한 범위까지 스테이트리스 와이어 프로토콜(stateless wire protocol)을 유지하는 것이다. 그러므로, 우리는 어떤 세트의 객체가 커서에서 검색되는지를 정의하고, 그런 다음 이런 목적을 충족하는 구현예를 제공한다. 커서에 대한 이성적인 의미론은 다음과 같다.

● 커서는 앞쪽으로만 이동한다.

● 커서에 의해 검색될 세트의 객체는 커서가 생성될 때 질의에 매칭되는 객체의 수이며, 그 후에 삭제되는 객체 개수보다 적다. 이는 커서가 먼저 생성된 이후에 생성되는 임의 객체를 포함하지 않는다. 이것은 신속히 변하는 객체 세트를 가진 서버에 대해 느린 클라이언트가 절대 종료하지 않도록 방지한다.

기술된 솔루션은 각 객체와 함께 증가하는 시쿼스 카운트를 유지한다. 커서가 설정될 때, 클라이언트가 커서 최대 시퀀스 카운트 번호를 기억한다. 객체 세트가 린턴되고, 마지막 객체의 최대 시퀀스 카운트가 기억된다. 다음 객체 세트가 검색될 때, 이것은 이런 질의와 같아지며, Timestamp>last_max 및 Timestamp < initial_max 인 경우 다음 CHUNKSIZE 객체를 검색한다.

서버상의 각 요청에 대해 이런 질의를 실행하는 오버헤드는 서버상의 커서 컨텍스트를 유지하는데 필요한 연결을 유지하는 평균 오버헤드를 초과한다고 판명될 것이다. 타협적인 솔루션은 GUID에 의해 식별된 서버상에 커서들의 캐쉬를 유지하는 것이다. 클라이언트는 타임스탬프와 GUID를 서버에 제출한다. 서버 측 커서가 캐시에 여전히 존재하는 경우, 해당 상태만 이용된다. 그렇지 않을 경우, 타임스탬프 질의를 실행함으로써 복구되며, 캐시에 재삽입된다. 이는 서버가 느린 클라이언트용 상태를 낮은 비용으로 버리도록 해준다.

주요 목적이 각각의 네트워크 요청의 크기를 감소시키고, 질의에 대해 서버에서 요구되는 작업 세트를 감소시키는 것임을 가정할 경우, CDI 인터페이스가 필수적으로 어떤 변경을 요구하지 않을 것이며, 원격 액세스 어댑터 및 로컬 액세스 어댑터는 클라이언트가 질의를 발행할 때 서버 측에 대한 커서를 투명하게 사용할 것이다.

매우 큰 데이터세트에 대해, 클라이언트는 커서 자체를 조작하길 원해서, 한 번에 그 상태들 모두를 메모리에 유지하지 않아도 될 것이다. 이런 경우, 커서를 나타내는 인터페이스가 CDI 인터페이스로부터 검색될 것이다. 암시적으로 단일 커서가 대량의 데이터를 검색하므로 이런 호출이 배치(batch)되도록 하는 것이 불필요할 것이다.

사용하기 편한 레졸루션( Friendly name resolution )

다양한 점에서, 사용하기 편한 이름을 카노니컬 이름으로 변환하는 생각이 폐기되었다. 사용하기 편한 이름은 객체 인스턴스의 인간 판독가능한 버전이고, 예를 들어, server.mydomain.org라 불리는 서버가 사용하기 편한 이름이라는 생각하는 것이다. 카노니컬 이름은 논리적 서버는 호스팅되는 서버, 즉 물리적 서버와 통신하는 프로토콜 사용을 식별하는 완벽하게 분명한 이름이고, 그 논리적 서버 객체 인스턴스에 대한 완벽히 분명한 참조이다. 예를 들어, 상기 사용하기 편한 이름은 이하의 카노니컬 이름, "{63315ca9-bef6-4cc5-9152-05e369d3d691}\www.realhost.net\{a4b6e956-dee0-46d0-b82c-7ffc8f814e95}\{ f091b5a1-ad2a-4dfe-9d37-9592b1ae2512}"에 대응할 것이다. 카노니컬 이름은 완벽하게 분명하다는 이점을 가지며, 이는 컴퓨터에게 더할 나위 없이 좋다. 그러나, 이것은 인간이 쉽사리 입력할 수 있는 것이 아니다.

카노니컬 이름이 주어지면, 이것이 적절한 경우 객체의 사용하기 편한 이름을 결정하는 것은 쉽다. 객체는 객체로부터 검색될 수 있는 "Object:Name" 등의 속성을 단순히 가질 것이다. 그러나, 시스템이 사용하기 편한 이름만을 가질 경우, 카노니컬 이름을 결정할 수 있어야만 한다. 이 인터페이스의 애플리케이션 호출가능한 측면이 이 섹션에 서술된다. 이름 리졸버를 구현하는 것에 대해 하기에 섹션의 명칭이 "사용하기 편한 레졸루션 플러그 인"이란 곳에 서술한다. 클라이언트 사용하기 편한 레졸루션 인터페이스가 바로 아래에 일 실시예에 따라 도시된다.

호출자가 사용하기 편한 이름 리졸버를 얻기를 원할 때, IImgCommonData 인터페이스상에서 GetFriendlyNameResolver 메소드를 호출한다. 사용하기 편한 이름은 단지 2개 논리적 메소드(와 그것들 중 하나에 대한 비동기 호출 패턴)를 노출한다.

ResolveName

예컨대, "server.mydomain.org" 등의 결정될 이름과, 예컨대, "Server" 등의 이름의 클래스가 주어지면, 이름 레졸루션 인터페이스는 사용하기 편한 이름 리졸버 플러그 인을 호출하고 IImgCanonicalNameIterator와 같은 플러그 인에 의해 반환되는 모든 유효한 결과를 반환한다. 이름 반복자(iterator)는 호출자가 사용하기 편한 이름에 대응하는 모든 카노니컬 이름을 검색하도록 해준다. 다수의 카노니컬 이름 반환을 허용하는 이유는 동일한 객체가 여러 가지 경로를 통해 보일 수 있도록 하기 위함이다. 예를 들어, 동일한 서버는 SOAP 및 RPC 모두를 통해 액세스될 수 있다.

ResolveName 메소드는 특정 객체를 액세스할 수 있는 방법을 알기 위해 다수의 프로토콜에게 질의해야할 것이므로, 긴 주기가 필요할 것이다. 그러므로, 인터페이스는 또한 BeginResolveName 및 EndResolveName 메소드 형태의 비동기 호출 패턴을 제공한다. 이런 것은 배치 BeginExecute 및 EndExecute 메소드에 의해 사용되는 것과 같은 동일한 비동기 호출 패턴을 사용한다. 호출자는 콜백 인터페이스를 명시할 수 있거나 IImgAsyncResult 반환을 통해 반환되는 시스템 대기가능한 핸들을 얻을 수 있다. 그것들은 대응하는 카노니컬 이름의 모두가 언제 결정되었는지에 대해 통지받을 것이다.

RemoveName

이름 리졸버는 사용하기 편한 이름에 대해 결정된 이름의 캐시를 유지하는데, 왜냐하면 이름 리졸버가 잠재적으로 매우 느리고 비싸기 때문이다. 캐시는 시간에 따라 자동으로 플러시될 것이다. 임의 이름 레졸루션이 캐시에 있는 것과 동일한 이름을 결정하는데 계속해서 실패하는 경우, 그들 이름 연관성은 삭제될 것이다. 일정 시간이 지난 후, 이름이 진부하다고 고려되는 거동이 발생한다. 호출자가 이름을 다시 요청하는 경우, 진부한 이름이 이름 리졸버에 의해 반환되지만, 이름 리졸버 플러그 인 중 어떤 것도 이름을 린턴하지 않을 경우, 이름은 캐시에서 삭제되고, 이것은 또 다른 라운드의 이름 레졸루션을 이름 리졸버 플러그 인에 발행한다. 이는 매우 빠른 이름에 대한 해결책을 제공하지만, 한 주기 동안 반환되는 진부한 이름 바인딩을 초래할 수 없다.

호출자는 사용하기 편한 이름을 해석하여, 그 이름이 진부하다고 독립적으로 판정할 것인데, 왜냐하면 카노니컬 이름이 CDI에 의해 액세스될 때 실패하기 때문이다. 호출자가 다시 동일한 사용하기 편한 이름을 요청한다면, 동일한 진부한 이름을 되돌려받을 것이다. 이를 방지하기 위해, 진부한 이름이 RemoveName 메소드를 통해 명시적으로 캐시로부터 제거될 수 있다. 호출자가 이를 행하지 않는 경우, 이름은 결국 지워질 것이며, 이는 선택적인 최적화이다.

확장된 객체 거동( Extended Object Behavior )

이전 섹션의 목적은 CDI의 인터페이스 및 기본 개념을 제시하는 것이다. 제시의 목적은 주로 사용의 관점(usage stand point)에서 이것을 노출시켰다. 이전 섹션에 제시된 것과 같은 인터페이스는 임의 애플리케이션 기록자가 프린트 시스템의 객체용으로 통지를 획득하고, 설정하고, 질의하고, 수신하도록 해주는데 충분히 강력한 것이다. 이 섹션의 초점은 새로운 보안과 발견 기능(capabilities)을 가능케 하는 객체에 의해 노출될 수 있는 특별한 거동을 제시하는 것이다.

객체 팩토리 , 객체 복제( Object Factories , Object Cloning )

이 섹션은 시스템에서 새 객체를 생성하고, 이런 객체들을 (적용가능하다면) 다른 시스템으로 전송하고, 새 객체 생성 사용자 인터페이스(UI)가 삽입되도록 허용하는데 사용될 수 있는 메커니즘을 다룬다. 팩토리 객체를 제외한 시스템의 모든 객체는 이 메커니즘을 지원해야 한다. 이 메커니즘은 도 8에 도시되어, 하기에 설명에 대한 기초로서 기능한다.

객체 생성 및 복제 메커니즘은 이하의 기능을 가능케 하는 드라이버 저장소가 존재한다고 가정한다.

1. UI 어셈블리 강력한(strong) 이름에 근거하여 클라이언트 또는 서버에 UI 어셈블리를 제공한다.

2. 집합 어셈블리 강력한 이름에 근거하여 집합 어셈블리를 서버 측에 제공한다.

강력한 이름의 자세한 정의, 및 이것이 버저닝에 관련되는 방법은 또 다른 설명이 된다. 그러나, 문맥을 위해, 다음을 고려한다.

강력한 이름은 사용중인 어셈블리의 실제 인스턴스와, 어셈블리의 공개자를 별명으로 고유하게 식별하는 이름이다. 이것의 한 구현예는 공개 키 암호법을 사용하여 어셈블리의 내용에 서명하고, 서명의 암호화된 해시(전형적으로 MD5 해시)를 취하고, 그 해시를 (또는 해시의 일부를) 이름에 내장하는 것이다. 이 이름은 실제로 어셈블리의 내용에 매여 있을 뿐 아니라, 어셈블리의 공개자와 밀접하게 연관된다. 어떤 사람이 다른 기능을 가진 또 다른 어셈블리를 생성할 수 있고, 어셈블리의 매우 많은 수(128bit 해시에 대해서 10³⁸개)를 생성함 없이, 또한 각각에 대해 전체 프로세스를 시도함 없이 나의 어셈블리의 강력한 이름을 사용할 수 있는 공지된 기술이 존재하지 않는다.

핵심적인 아이디어는 각 집합이 한 세트의 객체 인스턴스에 대해 팩토리 객체로서 동작하는 공지된 객체 인스턴스를 제공한다는 것이다. 새 객체의 구성 매개변수는 이미 알려질 수 없으므로, 객체는 새 객체 인스턴스를 생성하는 Greate()라 불리는 명령을 가진 커스텀(custom) 유형(이 예에서, Company.Type.1)을 구현한다. 호출자가 팩토리 객체와 팩토리 유형을 알고 있는 경우, 그들은 해당 클래스의 객체를 새 스풀러에 생성할 수 있다.

복제는 Microsoft.Object.1 유형을 지원하는 객체에 의해 지원된다. 그 객체에 의해 지원되는 필드는 집합 SN, 그 생성에 사용되는 팩토리 객체 인스턴스 및 3개 명령, GetStream, Delete, 및 UpdateFromStream을 포함한다. GetStream 은 객체의 내용을 스트림 내로 가져오며, Delete는 객체를 삭제하며, UpdateFromStream은 객체의 상태를 객체에 전달된 스트림에 근거하여 갱신한다. 이 객체는 스트림 중 임의 유형을 지원할 수 있으나, 상호운용성을 위해, 이상적으로 스트림은 XML이어야 한다.

객체가 복제될 때, 객체 인스턴스는 그 집합 SN과 팩토리 객체 인스턴스에 대해 질의 받는다. 그것들은 스트림으로 저장되어 있고, 이어서 스트림에 의해 표현된 객체의 상태가 저장된다.

객체를 복구하기 위해, 집합이 드라이버 저장소로부터 검색되고, 팩토리 객체를 위치찾기 한다. 팩토리 객체는 GreateClone 명령을 통해 전달된 스트림의 나머지이다. 이에 의해 팩토리는 꼭 일치하는 객체 인스턴스를 생성하게 된다.

시스템의 모든 객체가 분리된 UI 생성 및 복제를 지원해야 한다는 점을 인식할 필요가 있다. 그러나, 간략화를 위해, 팩토리 객체 및 복제 인터페이스는 설명과 도식을 단순화하기 위해 나머지 섹션에 나타내지 않았다.

계층구조( Hierarchy )

계층구조는 전형적으로 2가지 목적을 달성한다. 먼저, 이것은 객체의 효과적인 위치를 고려하기 위해 검색 공간을 분할한다. CDI를 복수의 집합, 이것이 소정의 클래스를 지원한다면 그 집합을 로딩하는 기능, 및 소정의 서버로의 액션 세트를 지시하는 기능으로 분할하는 것에 의해 이미 이 목적을 달성한다. 두 번째로, 이것은 시스템 또는 관리자가 논리적 계층구조로 객체를 그룹화하도록 허용함으로써 비동질 객체의 관리능력 및 발견을 제공한다. 모든 객체가 계층구조의 어디나 위치되기 때문에 계층구조에 의해 발견을 가능케 한다. 그러므로, 시스템의 모든 객체가 발견되고 나서 사용자가 각 객체로 드릴 다운하도록 해주는 브라우저가 작성될 수 있다. 계층구조는 또한 한 관리상의 액션에 의해 보안 변경을 객체의 서브 트리에 적용시킴으로써, 시스템의 보안성 관점을 제공할 수 있다. 이 메커니즘은 파일 시스템이 보안성을 구현하는 방법과 유사하다.

계층구조는 전형적으로 객체 간의 관계를 보여주는데에 유용하지 않다. 순수한 계층구조에 의해 한 객체는 세밀하게 그 다른 객체 아래 위치되게 된다. 그러므로, 작업은 프린터와 서버 둘 다 속할 수 없다. 계층구조는 또한 객체 간의 한 관계에 대해 많은 관계를 효과적으로 보여줄 수 없다. 관계형 모델은 객체 관계를 나타내는 훨씬 더 강력한 모델이다. CDI는 배칭 인터페이스(이는 다른 객체에 포함되도록 논리적으로 고려될 수 있는 객체를 반환함)상에서 Query 액션의 QueryBase 메커니즘을 통해 이를 효과적으로 허용한다.

계층구조의 제1 목적은 CDI 및 원격 액세스 어댑터 라우팅 메커니즘에 의해 달성되기 때문에, 또한 CDI의 관계형 메커니즘은 객체 관계를 나타내는 보다 강력한 방법이기 때문에, 우리는 단지 시스템의 비동질 객체의 관리 및 발견을 지원하는 메소드를 요구한다. 기존의 모델은 대부분의 경우에 충분히 강력하지만, 모든 객체가 반드시 계층구조를 지원하는 것은 아니라는 것에 유의할 필요가 있다. 서비스 계층에 의해 제공되는 디폴트의 영속 저장소는 계층구조를 자동으로 지원할 것이다. 그러므로, 로컬 객체의 가장 간단한 구현이 자동으로 계층구조를 지원할 것이다. 우리가 발견할 수는 있으나 수정할 수 없는 계층구조를 지원하는 경우가 있을 것이다. 예를 들어, 현재의 스풀러 RPC 인터페이스를 지원하는 원격 어댑터는 클라이언트가 서버 아래의 프린터와 프린터 아래의 작업을 발견하도록 해주나, 구성이 변경되도록 허용하지는 않을 것이다.

계층구조는 한 가지 유형을 가지는 링크 클래스라 불리는 새 클래스를 도입하여 표현될 수 있고, 그 링크 유형은 어떤 점에서는 현재의 객체 "아래에서(beneath)" 고려될 수 있는 객체의 카노니컬 이름인 한 가지 속성 객체를 가진다. 한 사람이 어떤 객체 인스턴스가 현재의 클래스로부터 계층구조적으로 트래블링될 수 있는지 알아내길 원한 때, 그 사람은 질의 베이스로서 트래블링되는 객체 인스턴스를 가진 링크 클래스에 대해 질의한다. 계층구조로 설정된 수많은 객체의 예가 도 9에 도시되어 있다. 이는 논리적 시스템 객체를 포함하고, 각각의 기계 및 모든 기계 상에서 루트 객체가 될 것이다.

링크 클래스 질의의 구현예는 영구적인 객체 집합 서비스에 의해 자동으로 제공될 것이다. 그러나, 발견할 수 있는 계층구조를 노출하길 원하는 임의 집합은 링크 질의를 파퓰레이트할 수 있다. 예를 들어, DS 객체를 노출하는 집합은 각 DS 객체의 자식을 열거하고, 그런 다음 부모 객체가 열거될 때 각 객체의 구별된 이름(Distinguished Name)을 링크 탭 내로 파퓰레이트할 수 있다.

보안 및 계층구조(Security and Hierarchy)

계층구조는 발견가능성 및 보안을 제공한다. CDI는 보안 대리인을 제공하고, 보안 대리인은 객체의 보안 서술자가 변경될 때, 자식 객체를 통해 보안 상속 규칙을 시행하기 위해 실행될 것이다. 보안은 영구적인 객체 집합 서비스에 의해 자동으로 처리될 것이며, 보안 대리인은 이 집합의 객체 상에서 자동으로 실행될 것이다.

관리자가 임의 객체 세트를 그 아래에 둘 수 있는 논리적 그룹이라 불리는 특수 객체가 제공될 것이다. 이는 관리자가 논리적 그룹상의 ACL을 변경하도록 해주고, ACL이 자동으로 논리적 그룹 아래의 모든 객체에 적용되도록 해준다. 이는 관리자가 그들이 유용하다고 찾아낸 관리형 계층구조를 관리자의 서버상에서 적용하고, 그런 다음 보안 규칙을 해당 계층구조에 적용하도록 해준다.

보안 및 클래스 믹스-인(Security and Class Mix-ins)

계층구조에 의해 보안을 제어할 뿐만 아니라, 시스템은 또한 클래스에 의해 보안이 제어되도록 허용할 것이다. 이는 생성자/소유자(Creator/Owner) 관리형 액세스를 시스템 상에서 생성된 모든 작업에 제공하는 것 등의 특징을 허용한다. 현재의 시스템에서, 클래스 규칙은 시스템 내에 하드 코딩되며, 나중에 믹스-인이 임의 클래스에 대해 이용가능하게 될 것이다.

도 10에 도시된 바와 같이, 클래스 속성은 보안 계층구조의 편집가능한 클래스 객체를 노출시킴으로써 달성된다. 이 객체들은 생성 시에 각 클래스에 적용될 디폴트 보안 서술자를 초기에 각각 포함할 것이다. 모든 다른 객체와 마찬가지로, 그것들은 전체 시스템에 대한 베이스 객체로서 사용되는 논리적 시스템 객체로부터 그 서술자를 상속할 것이다. 적절한 클래스의 객체가 생성될 때, 부모 객체와 클래스 객체 둘 다 그 보안 서술자를 파생시키는데 사용된다. 도 10은 또한 계층구조 상에서의 논리적 그룹의 효과를 도시한다. 여기서, 관리자는 2개 논리적 그룹을 생성했으며, 하나는 임의 클러스터 서버에 대한 액세스를 제어할 수 있는 것이고, 또 하나는 로컬 서버 객체 상에서 프린터에 대한 액세스를 제어하는 것이다. 여기서 각 경우에 단 하나의 객체가 도시되어 있지만, 임의 개수의 객체가 각각의 논리적 그룹 아래에 놓일 수 있다.

메타데이터( Metadata )

예시 및 기술된 실시예에서, CDI는 임의 객체를 원격 객체에 바인딩하는 기능을 제공하나, 임의 객체가 원격 객체에 바인딩되기 전에 호출자는 그 객체가 지원하는 필드와 명령을 알아야한다. 그 동안 대부분, 클라이언트는 객체가 지원하는 서버 객체와 인터페이스를 알고 있다. 클라이언트가 알지 못할 경우, 클라이언트는 올바르게 동작할 수 없을 것인데, 왜냐하면 클라이언트가 동작하기 위해 서버 객체의 선험적 지식(a-priori knowledge)을 요구하기 때문이다. 인터페이스는 이런 거동을 최적화하도록 제어 받으며, 클래스들이 호출될 것인지에 관한 문맥을 자세히 알고 있는 클래스는 임의 메타데이터 메커니즘을 구현할 필요가 없다.

그러나, 클라이언트가 그가 조작하고 있는 클래스에 대한 사전 지식을 소유하지 않는 경우들도 있다. 예를 들어, 클라이언트는 CDI 호출을 관리되는 데이터 제공자 인터페이스로 변환하는 액세스 어댑터일 수 있다. 이 경우, 그 클라이언트에 의해 요청된 데이터는 선험적으로(a-priori) 알려질 수 없다. 클라이언트가 통신하고 있는 서버 객체 또한 선험적으로 알려질 수 없다. 또는, 클라이언트는 클라이언트 또는 서버 상의 객체들 전부가 검색되고 객체 유형에 관계없이 조작될 수 있도록 하는 포괄적 관리형 UI일 수 있다.

이를 위해, 예시 및 기술된 실시예는 호출자가 그 메타데이터용 객체 인스턴스를 질의하도록 하는 표준 시스템 유형을 제공한다. 이런 유형은 유형(Type), 속성(Property), 명령(Command), 및 매개변수(Parameter) 유형이다. 집합 어댑터 서비스를 사용하여 구현된 클래스는 공짜로 전체 메타데이터 지원을 자동으로 얻을 것이다. 메타데이터는 서버 객체 유형 맵으로부터 검색될 것이며, 그것들은 그 클래스 각각을 지원할 것이다.

메타데이터를 검색하기 위한 베이스로서 객체와 함께 질의될 수 있는 유형은 도 11에 도시되어 있다.

메타데이터는 질의의 베이스로서 객체와 함께 Type 유형에 첫 번째로 질의함으로써 검색된다. Type 유형은 논리적 객체 인스턴스에 의해 지원되는 모든 유형들의 리스트를 제공한다. 나중에 시스템은 객체들이 다른 객체에 내장되도록 허용하거나 다른 객체를 확장하는 것이 가능하기 때문에, 유형은 근간이 되는 기본 객체만이 아닌 해당 객체 인스턴스에 대해 통합된 유형 모두를 포함할 것이다. 각 Type 유형은 그것이 지원하는 명령 또는 속성에 대해 차례로 질의 받을 수 있다. 그리고, 각 명령은 그것이 지원하는 매개변수에 대해 질의 받을 수 있다.

질의 베이스( Query Bases )

질의 베이스는 다른 비계층구조 시스템에서 통상적이지 않은 설계 양상이다. 이 섹션은 도대체 왜 질의 베이스가 구현되어 있는지, 질의 베이스가 어떻게 관계형 질의에 매핑되는지를 설명한다.

질의 베이스는 소스 객체를 명시하고, 이는 질의 받고 있는 클래스의 인스턴스가 일부 측정에 의해 "아래에(Under)" 고려될 수 있다. 질의 베이스는 수많은 이유로 인해 제공된다. 첫 번째로, 이는 부분-구성요소(sub-element)에 대한 열거가 어떤 사람에 의해 구성되도록 해주며, 달리 그 사람은 질의의 일부로서 관계를 표현하는 방법을 알고 있지 않다. 두 번째로, 이는 연결에 근거하는 다운-레벨 시스템에 매우 잘 매핑된다. 질의 베이스는 매우 자연스럽게 열거의 부모 객체가 된다. 그러므로, 다운-레벨 객체에 대해, 객체 상태에 대한 질의 베이스 및 필터는 질의를 구현하는 자연스러운 방법이다. 세 번째로, 상당히 가변성 있는 구성(예를 들어, 객체에 의해 저장된 메타데이터)을 가진 객체에 대해, 질의를 부모 객체로부터의 열거 시퀀스로서 취급하는 것은 보다 논리적인 일이다.

그러나, 질의 베이스는 관계형 질의에 매핑하는 일부 조작을 필요로 한다. 다행히도, 이것은 상대적으로 쉽게 달성된다.

이름	서버 ( class =" Server ")	프린터 ( class =" Printer ")	설명	크기
프레드의 작업	{SSSS}	{PPPP}	작은 작업	120KB
존의 작업	{SSSS}	{QQQQ}	큰 작업	300KB
마리의 작업	{TTTT}	{RRRR}	가장 큰 작업	1MB

예시하기 위해, 상기 테이블은 프린트 큐의 수많은 작업을 도시한다. 거기에는 (기본 데이터베이스의 외부(foreign) 키로서 구현되며) 작업과 연관된 객체의 카노니컬 이름을 저장하는 2개의 필드가 존재하다. 원격 객체를 참조하는 각 컬럼은 원격 객체 클래스를 알고 있다.

질의가 특정 베이스 객체용으로 입력될 때, 객체의 클래스는 객체의 논리적 필드에 상관되고, 질의는 올바른 값을 가지는 이런 필드를 포함하도록 확장된다.

예를 들어, 질의가 Base = "{SSSS}", Base Class ="Server"용으로 질의 문자열 "Jobs:Size<150KB"과 함께 입력될 때, 이는 이하의 질의로 번역될 것이다.

Jobs:Sever="{SSSS}"AND(Jobs:Size<150KB

이는 올바른 결과, 프레드의 작업을 반환할 것이다. 이런 번역은 집합 어댑터 서비스에서 자동으로 수행될 것이다. 이는 서버 객체 유형 맵의 메타데이터를 약간 더 요구할 것인데, 왜냐하면 우리는 어떤 필드가 질의 베이스로서 기능할 수 있는가, 및 질의 베이스가 어떤 클래스들에 대응하는가를 알 필요가 있을 것이기 때문이다.

CDI 구현예( CDI Implementation )

이전 섹션은 객체로부터 예측되는 거동을 기술하고, 클라이언트에 노출된 인터페이스를 기술한다. 이 섹션은 CDI의 서버 측에 대한 구현예를 기술한다. 이는 CDI에 의해 제공된 서비스, 및 모델의 플러그를 기술한다.

도 12는 CDI의 주요 컴포넌트뿐 아니라 시스템 내로 삽입된 다양한 플러그인을 도시한다. 예비로, 각각의 주요 컴포넌트에 대한 설명을 제공할 것이고, CDI 박스 자체 내의 컴포넌트에 대한 상세한 설명을 제공할 것이다. 집합 어댑터 서비스는 시스템에 의해 제공되나, 플러그-인에 의해 호스팅되는 분리된 서비스로서 고려되며, CDI 그 자체(per-se)의 일부는 아니다. 집합 어댑터 서비스는 다음 섹션에 설명된다.

애플리케이션( Application )

애플리케이션에 대한 인터페이스는 이전 섹션의 주요 관심사였다. 애플리케이션은 CDI로부터의 배치 인터페이스를 요청하고, 수많은 액션을 기록하고, 이것들을 실행한다. 실행이 완료되면, 애플리케이션은 결과를 얻을 수 있다.

라우터( Router )

액션을 실행하는 것은 라우터에 의해 라우팅되고 플러그-인에 전달되는 배치를 초래한다. 라우터는 동일한 플러그-인으로 주소지정된 배치의 인접 영역을 찾고, 호출로 이런 영역을 플러그-인에 전달한다. 그러므로, 플러그-인은 여전히 배칭 거동 그 자체를 보존할 것이다. 애플리케이션에 의해 호출된 의미론에 따라, 섹션은 병렬로 또는 순차적으로 플러그-인에 전달될 수 있거나, 트랜잭션 객체는 플러그-인이 트랜잭션을 조정하도록 허용하기 위해 배치에 연관될 수 있다.

플러그-인( Plug - Ins )

플러그-인은 DLL 목록 및 구성 정보에 관련해서 DLL에 의해 노출된 인터페이스이다. 단일 DLL은 하나 이상의 플러그-인 인터페이스를 노출할 수 있다. 예시 및 기술된 실시예에서, 플러그-인 인터페이스는 하나의 메소드를 가진 하나의 팩토리 인터페이스로 구성되고, 플러그-인 인터페이스(IImgBatchCollection)는 2개 메소드-AsyncProcessRequest 및 Shutdown을 가진 것으로 구성된다. 플러그-인 인터페이스는 그 동작을 배치로서 수신한다. 그러므로, 이것은 배치를 지원하는 다른 시스템에 원격 연결되는데 사용되는 논리적 인터페이스이다. 이를 위해, 예시 및 기술된 실시예에서, 다음의 플러그-인, 즉 로컬 액세스 어댑터(Local Access Adapter), 원격 액세스 어댑터(Remote Access Adapter), 샌드박스 어댑터(Sandbox Adapter), 및 적합한 플러그-인(Adapted Plug-in)이 제공되고, 이들 각각은 이하에서 개별적으로 설명된다.

Local Access Adapter는 로컬 서비스 또는 사용자별(per-user) 서비스로의 액세스를 제공한다. 현재 이것은 비동기 COM을 사용하나, 임의 다른 원격 메커니즘이 사용될 수 없을 특정한 이유가 없다.

Remote Access Adapter는 원격 기계로의 액세스를 제공하고, 서버의 클라이언트-당(per-client) 상태를 줄이기 위해 일부 차이점을 가진 Local Access Adaptor와 동일한 메커니즘을 주로 사용할 것이다.

Sandbox Adapter는 요청을 배치로 그룹화하기 위해 지금까지의 애플리케이션의 작업을 보관하는데 사용된다. 이는 또한 동일한 보편적인 플러그-인 모델이 in-proc 또는 out-of-proc 컴포넌트에 사용될 수 있음을 의미하며, 심지어 우리가 원한다면 샌드박스 시스템 컴포넌트를 사용할 수 있음을 의미한다. CDI 이외의 시스템의 모든 부분이 플러그-인으로서 노출될 수 있다.

Adapted Plug - in은 몹시 단순한 형태이나, 이는 플러그-인이 복잡할 수 있는 비동기 호출에서 큐에 저장되는 배치 동작을 해석할 것을 요구한다. 이런 이유로, 집합 어댑터 서비스(CAS:Collection Adaptor Service)가 제공된다. 집합 어댑터 서비스는 객체(IImgObject)의 다수의 객체 집합(IImgObjectCollection)이 플러그되게 해주며, 차례로 배치된 호출을 해석하여, 호출을 제공된 집합 및 객체상의 호출로 번역한다. 집합 어댑터 서비스는 이런 인터페이스의 동기식 및 비동기식 구현의 효율적인 처리를 제공한다. 집합 인터페이스는 다운-레벨 프로토콜을 액세스하는데 사용될 수 있을 만큼 충분히 광범위하다. 프로토콜들은 전형적으로 배칭을 지원하지 않기 때문에 이런 경우 성능 저하는 없다.

서비스( Services )

예시 및 기술된 실시예에서, CDI는 일련의 서비스를 제공한다. 서비스 대부분은 단지 플러그-인으로부터 액세스될 수 있다. 이런 서비스는 공개적이고, CAS 및 기타 플러그-인에 동일하게 노출된다. 이는 독자적인 소프트웨어 벤더 또는 독자적인 하드웨어 벤더가 스스로 동일한 기능을 얻기에는 CAS가 너무 제한적이라고 발견하도록 해준다. 명시적인 목적은 CAS가 대부분의 시나리오를 해결하도록 해주는 것이며, 시스템 제공된 객체 모두가 이를 사용할 것이다. CDI에 의해 제공된 서비스는 질의 컴파일러, 작업 흐름, 트랜잭션, 변경 범위, 변형, 및 유형 맵을 포함하며, 이들 각각은 이하에서 개별적으로 설명된다.

query compiler는 애플리케이션에 의해 제공된 질의를 파스 트리(parse tree) 및 필터(filter) 둘 중 한 형태로 컴파일할 수 있다. 파스 트리는 플러그-인이 질의를 다른 형태의 질의로 번역하길 원하는 경우에 유용하며, 이것은 당신 자신이 재차-구문분석(re-parse)하려고 노력하는 것보다 쉬운데, 왜냐하면 블래킷(bracket) 및 연산자 순위가 해결되었을 것이고, 일부 기본적인 잘-구성된 체크가 파서(parser)에 의해 이미 수행되었을 것이기 때문이다. 필터는 객체에 바운딩될 수 있고, 메소드-"DoesMatch"를 제공하며, 이 메소드는 호출자가 주어진 객체의 상태가 전달되었던 질의와 매칭되는가를 체크하도록 해준다.

work flow는 애플리케이션이 CDI 내에 호출을 실행할 때마다 인스턴스화되는 인터페이스이다. 이는 사용자 액션의 논리적 실행에 대응한다. 작업 흐름은 작업을 스케줄링하고, 작업에 연관된 작업 항목에 작업 흐름이 취소되는 시점(전형적으로, 사용자로부터의 원래 호출이 취소되기 때문임)을 통지할 것이다. 작업 흐름은 검출한 토큰 세트를 추적할 수 있고, 반복(recursion)을 방지할 수 있다. 플러그-인이 CDI로부터의 호출 결과로서 시스템 내로 호출을 발생시키길 원할 때, 이것은 호출을 원래 시작하던 때와 동일한 작업 흐름을 사용해야 한다. 플러그-인은 특수한 서버-측 만의 호출(IImgCommonDataServer::RecurseDataBatch)을 통해 이를 행한다.

반복을 수행할 때, 이것은 동일한 연산이 동일한 흐름에 대해 재발생하는가를 체크하고 그러므로 반복을 중단하기 위해 나중에 사용할 수 있도록 토큰을 작업 흐름에 삽입해야 한다. 작업 흐름은 또한 원래 호출자의 토큰을 추적할 것이다. 플러그-인이 비동기적으로 및 독자적으로 CDI 내로 호출을 행할 때, 이는 클라이언트 인터페이스를 통해 이를 행할 수 있거나, 그 자신의 작업 흐름을 생성할 수 있거나, RecurseDataBatch를 호출할 수 있다.

호출자가 transaction을 요청하는 경우, 이 객체는 생성되고, 배치와 연관된다. 트랜잭션은 하나의 트랜잭션 집합과 한 세트의 종속적인 항목을 트랜잭션에 연관시키는 메커니즘을 제공한다. 이것은 동기 및 비동기 인터페이스를 트랜잭션에 제공한다. 배치가 실행을 종료할 때, 트랜잭션이 커밋된다. 결과가 저장소에 전송되고, 저장소가 올바르게 갱신되는 경우, 종속적인 항목이 실행된다. 종속적인 항목으로서 자격을 부여하기 위해, 항목은 커밋 요청을 실패시킬 수 있어야 한다. 이는 살아있는 in-memory 객체를 저장소에 전달되고 있는 상태 변경에 따르도록 만드는데 사용된다. 플러그-인이 다른 객체를 포함하도록 트랜잭션을 확장하는 경우(예를 들어, 차례로 다른 객체를 삭제하는 "Delete" 명령을 구현하기 위해), RecurseDataBatch를 통해 CDI 내로 호출을 되돌려 줄 때 동일한 트랜잭션을 명시할 수 있다. 각각의 반복을 통해 모든 변경이 계류중에 있으며, 가장 바깥쪽 배치가 성공적으로 완성될 때까지 그러할 것이다.

Change scope는 각 채널을 나타내는 서버 측 변경 핸들러에 속한다. 변경 범위는 트랜잭션에 삽입될 것이다.

Variants는 이전 섹션에 포함되어 있다. 변형(Variants)은 클라이언트 또는 서버 측 중 어느 한 측에 의해 사용될 수 있다.

Type Maps도 이전 섹션에 포함되어 있다. 최적화된 맵은 서버 측에서만 보일 수 있다.

플러그-인 인터페이스( Plug - in interface)

예시 및 기술된 실시예에서, 플러그-인 인터페이스는 COM 유사(COM-like) 객체 인스턴스화 모델을 사용하여 인스턴스화된다. 이것은 플러그-인이 자신의 클래스 id를 레지스트리에 등록하는 것을 요구하지 않는다. 플러그-인을 인스턴스화하는 프로세스가 도 13에 도시되어 있다.

예시 및 기술된 실시예에서, 모든 플러그-인이 WMI.Config에 CDI 구성의 일부로서 저장되어 있다. 플러그-인 데이터의 일부는 플러그-인 DLL의 XML 구성 파일로부터 WMI.Config에 의해 분석될 것이다(이는 XCOPY 기반의 솔루션에 유용함). CDI 구성은 플러그-인 DLL의 리스트로 구성된다. 각 DLL에 대해, 우리는 각각 지원하는 집합 GUID뿐만 아니라, 각각의 논리적 집합에서 지원되는 클래스를 리스트화한다. 각각은 또한 몇몇 연관된 초기화 데이터를 가진다. 이는 전형적으로 DLL에 의해 지원되는 객체가 영속되고 검색되는 위치를 나타낼 것이다. 라우터가 플러그 인 인터페이스를 인스턴스화하길 원할 때, 이것은 집합 GUID를 검색하고, 대응하는 DLL을 찾아내고, 그런 다음 DllGetClassObject를 호출한다.

그런 다음 우리는 CLSID_IImgBatchCollection 와 IID_IImgBatchCollectionFactory를 요청한다. 그런 다음 DLL은 플러그-인에 의해 지원되는 IImgBatchCollection의 다양한 인스턴스를 반환할 수 있는 클래스 팩토리를 반환한다. IImgBatchCollectionFactory는 다음의 인터페이스를 지원한다.

팩토리는 CreateInstance 동안에 다음의 정보를 전달받는다.

● IImgCommonDataServer 인터페이스. 이 인터페이스는 IImgCommonData로부터 상속하고, 또한 서버 측 서비스를 액세스하는 일부 플러그-인 특정 메소드를 포함한다. 주의: 플러그-인은 CoCreateInstance(CLSID_IImgCommonData)을 호출하지 않아야(not) 하며, 왜냐하면 이것이 클라이언트 인터페이스를 생성하기 때문이다. 시스템은 마지막 클라이언트 인터페이스가 해제될 때 셧 다운되고, 서버 측 플러그-인이 클라이언트 인터페이스를 잡고 있는 경우, 셧 다운되지 않을 것이다.

● collectionGUID. 이것은 CDI 구성에 존재하는 동일한 GUID이다. 팩토리는 이런 GUID에 따라 여러 다른 IImgBatchCollection 인터페이스를 인스턴스화하는 것을 선택할 수 있다.

● 초기화 데이터 - 이 데이터는 WMI.Config로부터 검색될 것이다. 현재 이것은 문자열에 의해 표현된다. 플러그-인은 어디서 그 객체를 얻어올 것인지 선택하는데 이런 초기화 데이터를 사용한다.

● Riid - 이것은 CDI에 의해 요청된 인터페이스이다. 현재 단지IID_IImgBatchCollection만 요청되지만, 미래의 인터페이스는 여기서 요청될 수 있다.

플러그-인에 의해 반환되는 인터페이스는 다음과 같다.

AsyncProcessRequest 인터페이스는 임의 데이터가 배치로부터 플러그-인으로 정해지는 경우 호출된다. 집합은 다음을 전달받는다.

● IImgServerItemCompletion 인터페이스. 이 인터페이스는 단일 메소드-"Done"을 지원하며, "Done"은 요청이 완벽하게 처리되었을 때 호출된다. 호출자는 AsyncProcessRequest로부터 즉시 반환될 수 있다. 호출자는 그들이 AsyncProcessRequest 호출에 실패하지 않는 한 "Done"을 호출해야 한다. 호출 "Done"에 대한 실패는 클라이언트의 Execute 호출이 완료되지 않게 한다.

● BatchArray, 이 인터페이스는 클라이언트에 의해 요청된 액션으로의 액세스를 제공한다.

● 배치 배열(batch array)의 시작 및 종료 인덱스. 이는 라우터가 다양한 플러그-인에 의해 공유되는 하나의 배치를 생성하도록 허용한다. 플러그-인은 클라이언트가 병렬 실행 의미론을 요청하는 경우, 병렬로 실행될 수 있다.

배치 배열은 다음의 인터페이스를 가진다.

배치 신택스, 임의 연관된 트랜잭션, 및 작업 흐름은 배치 배열으로부터 검색될 수 있다. 인터페이스는 그것이 배치 배열에 알리어스되기 때문에 증가된 참조 카운트를 가지고 반환되지 않는다. ItemAt 메소드는 배치 액션을 주어진 인덱스에 반환한다. 이것은 항목의 유형을 제공하는 열거를 포함한다. 이것은 또한 플러그-인이 어떤 항목이 완료된 것인지와, 임의의 에러 정보를 나타내기 위해 설정할 수 있는 필드를 포함한다. 이는 대응하는 액션용으로 호출자에 의해 전달된 매개변수를 포함하는 공용체를 포함한다.

인터셉션( Interception )

플러그-인 인터페이스와 라우터가 정의되고, 인터셉션의 구현예에 대한 설명은 다음과 같다. 인터셉션은 예시 및 기술된 실시예에서, 배칭 라우터가 데이터를 전송할 수 있는 또 다른 플러그-인 인터페이스로서 구현된다. 그러나, 라우팅을 위해 단지 집합 id(또는 질의용 클래스)를 요구하는 보통의 플러그-인용으로 저장된 구성 정보와는 달리, 인터셉션 플러그-인은 다음의 정보 조각을 명시한다.

● 액션 인터셉션하기(The intercepting action). 인터셉터는 이것이 Gets, Sets, Queries, Commands 또는 Notification을 트랩(trap)하길 원하는지 명시할 수 있다.

● 클래스 인터셉션하기(The intercepting class). 인터셉터는 이것이 객체의 어떤 클래스가 호출되기를 원하는지를 명시한다. 클래스는 이것이 모든 클래스에 대해 등록될 수 있는 '*'로서 명시될 수 있다.

● 집합 인터셉션하기(The intercepting collection). 인터셉터는 이것이 가로채길 원하는 객체 집합의 고유한 GUID를 명시한다. 이 집합은 이것이 모든 집합에 대해 등록될 수 있는 '*'로서 명시될 수 있다.

● 객체 인터셉션하기(The intercepting object). 인터셉터는 이것이 모니터링하기 원하는 객체의 고유한 id를 명시할 수 있다(인터셉터가 이를 행할 경우, 인터셉터는 인터셉션을 제거하는 객체의 Delete 명령을 가로채야 한다). '*'가 명시되는 경우, 인터셉터는 모든 클래스에 대해 호출된다.

인터셉션 테이블의 각 등록에 대해 GUID가 할당된다. 인터셉션 메커니즘은 "명령의 체인(Chain of command)" 패턴을 이용할 것이다. 배칭 라우터에 의해 취해진 액션은 다음과 같다.

1. 배치에서 주어진 항목을 집합으로 라우팅하기 전에, 라우터는 먼저 상술된 필드를 사용하여 호출에 대해 등록된 인터셉터가 존재하는지 여부를 알기 위해 검사한다.

2. 존재하는 경우, 동일한 규칙에 대한 동일한 인터셉터로 정해진 인접한 액션 세트가 발견된다.

3. 인터셉션 등록과 연관된 GUID가 작업 흐름에 삽입되고, 인터셉터가 호출된다.

임의 다른 플러그-인이 그런 것처럼, 인터셉터는 이 시점에 배치 액션을 전달받는다. 인터셉터는 액션의 실행을 2가지 방식으로 변경한다.

1. 인터셉터는 라우터에 대해 RecurseBatchActions() 을 호출하고 원래 배치 액션을 더해 작업 흐름에 전달한다. 이는 액션 중 일부가 수정되게 하지 않으나, 이것에 의해 인터셉터는 액션을 판독하고 추가적인 액션 그 자체를 수행하게 된다(예를 들어, 인터셉터가 동기화기(synchronizer)이면, 이것은 동기화기를 사용하여 캐시된 데이터가 오염되는 경우 동기화 액션을 트리거한다).

2. 인터셉터는 각각의 배치 액션을 해석하고, RecurseDataBatch을 호출하여 액션을 수정하여 작업 흐름에 다시 전달한다. 이런 옵션에 의해 인터셉터는 액션의 결과를 변경하게 되나, (내재적으로) 구현하기는 훨씬 더 어렵다. 예를 들어, "Get"의 결과를 변경하기 위해, 임시 프록시 객체가 실제 객체 겟(get)의 결과를 유지하기 위해 인스턴스화되어야 하고, 새 유형 맵이 이런 임시 객체에 기입하기 위해 등록되어야 한다.

이런 호출 중 하나는 배칭 라우터로의 콜백을 초래할 수 있다. 배칭 라우터는 이것이 작업 흐름에 리스트 된 GUID 토큰을 가진 임의 인터셉터 내로 호출을 행하지 않을 것이란 점을 제외하고, 딱 이전과 같은 룩업을 수행한다. 그러므로, 각 인터셉터는 차례로 액션이 목적지 객체로 라우팅될 때까지 지쳐갈 것이다. 이런 동일한 메커니즘은 잘 구성된 인터셉터와 객체 세트가 반복을 공개하는 것을 방해하며, 왜냐하면 라우터는 호출이 반복적이 되는 경우 이미 호출되었던 인터셉터를 자동으로 무시할 것이기 때문이다.

인터셉터는 호출을 연결하는 책임을 지기 때문에, 이것은 연결 이전 또는 이후에 액션을 실행할 것을 선택할 수 있다. 이것은 배치의 신맨틱을 변경할 수 있다. 전형적으로, 배치가 트랜잭션 적이 아니면, 인터셉션이 트랜잭션 적이 되도록 보장하길 원할 것이다. 이것이 비동기적으로 호출되므로, 이것은 심지어 인터셉션된 액션을 가진 인터셉션을 병렬로 실행할 수 있다.

인터셉션의 사용(Uses of interception)

인터셉션은 2가지 목적, 즉 시스템 확장 또는 양상 확장에 유용한다. 인터셉션은 배치 액션의 거동을 확장하기 위해 IHV에 의해 사용될 수 있다. 예를 들어, 큐가 일시정지될 때, 다른 액션이 드라이버에 의해 취해질 필요가 있을 수 있다. 이런 확장은 그것이 원래 액션의 결과를 변경하려고 시도하지 않는 한 당연히 안전하다. 이런 이유로 인해, RecurseBatchActions 메소드는 구현하기에 훨씬 더 단순하게 만들어진다. 배치 액션의 결과를 변경하는 것은 훨씬 더 어려울 것인데, 왜냐하면 이것은 인터셉션을 요구하고, 유형 맵, 클라이언트 객체, 및 클라이언트 객체 집합 등의 일부 까다로운 것을 포함하는 모든 매개변수를 수정하는 것을 요구한다. 인터셉션은 또한 호환성을 유지하고 시스템을 패칭하는 메커니즘으로서 사용되는 것으로 생각할 수 있다. 예를 들어, 시스템의 개정(revision)이 플러그-인 오작동(misbehaving)을 초래하는 경우, 시스템 내로의 호출을 시스템이 이해하는 호출로 변경하는 인터셉터가 생성될 수 있다. 시스템은 예컨대, 호출이 타겟 객체에 도달하기 전에 너무 큰 문자열을 가진 호출을 인터셉션 하여 보안 구멍을 패치(patch)하는 인터셉터를 제공하는 서비스를 받을 수 있다. 이는 심지어 꽤 일반적으로 행해질 수 있으며, 예컨대, MAX_PATH 보다 큰 모든 문자열을 거절하는 인터셉터가 기입될 수 있거나, 필드마다 적절한 문자열 길이를 기입한 테이블이 제공될 수 있다.

인터셉터가 가장 유용할 경우는 수많은 객체를 크로스/컷(cross/cut)하는 시스템의 양상을 구현하는 경우이다. 예컨대, 특정 패턴을 따르는 시스템의 액션 모두를 잘라버리는 인터셉터가 기입될 수 있다(예컨대, 그들이 "액세스 거부(Access Denied)"로 인해 실패한다).

객체 명령( Object Commands )

객체 명령은 그 객체 명령이 서버 측에서만 호출된다는 점에서 객체 속성과 다르다. 이는 명령 호출이 클라이언트로부터의 변형 배열을 서버에 전달하고 되돌려 받음으로써 수행되기 때문이다. 호출되는 클라이언트 측 프록시 객체에 대한 생각이 존재하지 않는다. 데이터 표현은 바로 아래에 도시되어 있다.

위에서 알 수 있듯이, 서버 클래스 설명은 클라이언트 클래스 설명과 동일하지만, 명령 세트의 설명을 또한 포함한다. 하나의 명령은 유형, 명령 및 설명을 포함한다. 이것은 명령 인터페이스로의 포인터를 포함한다. 명령 인터페이스는 속성을 액세스하는 데에 사용된 접근자 인터페이스와 유사하게 작동한다. 명령을 적용해야만 하는 객체 및 명령에 대한 입력 매개변수를 포함하는 ImgVarient의 배열을 명령 인터페이스에 전달한다. 각 명령은 비동기로 실행될 수 있는데, 이로 인해 인터페이스는 BeginCommand와 EndCommand 메소드 둘 다를 가지고 있다.

각 명령은 또한 모든 매개변수의 유형을 정의하고 또한 각 명령에 대한 모든 설명의 목록을 지니고 있다.

속성 접근자처럼, 명령은 동적 유형 위에 구축될 수 있다. 그러나, 기본 레벨에서 이것은 액션을 수행하는 것(데이터를 검색하는 것에 대비됨)에 대응하기 때문에 그리고 명령을 호출할 때 선을 정리하는 목적으로 동적 프록시 객체가 구성될 필요는 없기 때문에, 이것은 속성에 대해서만큼 유용한 것이 아니다. 이것은 인터셉션(interception)을 통해 명령이 확장된 경우 유용할 수 있다.

IATL 명령( IATL Commands )

IATL은, 그것이 CDI 유형 맵 속성을 바로 C++ 필드 및 메소드로 매핑하는 메커니즘을 제공하는 것과 똑같이, CDI 명령을 C++ 클래스 메소드 호출로 바로 매핑하는 메커니즘을 제공한다.

IATL은 호출자가, 구현자를 위해 비동기의 BeginCommand, EndCommand 쌍이 자동으로 구축되는 단일 메소드로서 명령을 구현할 수 있도록 한다. 이것은 구현자가 IO가 전혀 없는 명령을 구현하고자 할 때 유용하다. 또는, IATL은 클래스가 두 개의 메소드를 제공하도록 하고 비동기로 명령을 구현하도록 한다. IATL 명령을 구축하기 위해 사용된 메커니즘은 바로 아래의 발췌된 코드에 요약되어 있다.

이 발췌는 클래스의 메소드가 CDI 명령으로서 노출될 수 있는 많은 다른 방법들을 도시한다.

Print 명령은 ServerPrinterCommandBase에서 구현되고, 이것은 단일 동기 메소드로서 구현된다. 모든 동기 메소드는 제1 인수로서 Img::iatl::CommandParams 매개변수를 수신한다. 이 구조는 명령과 관련된 작업 흐름 및 공통의 데이터 인터페이스를 보유한다. 제2 매개변수는 제1 명령 인수 등에 매핑한다. 어느 매개변수가 입력이고 어느 매개변수가 출력인지 명확하게 하기 위해, 호출자는 그 메소드가 몇 개의 입력 및 출력을 지니고 있는지를 나타내는 Command 함수의 매개변수를 반드시 제공해야 한다. 예를 들어 print 명령은 다음과 같다:

g1In 매개변수는 이것이 하나의 입력 매개변수를 지니는 명령이라는 것을 나타낸다. 입력 매개변수는 명령으로서 호출될 수 있는 모든 메소드에서 출력 매개변수보다 반드시 앞에 있어야 한다.

속성 유형 맵과 같이, 명령 유형 맵은 기본 유형에서 파생 유형(a derived type)으로 상속될 수 있다. 이것은 다음의 Inherits 함수로 달성된다:

명령 매개변수의 유형은 메소드 인수로부터 자동으로 유래된다. 그러나, 선택가능한 설명 필드는 반드시 테이블에서 제공되어야만 한다. 이것은 InDescrip 및 OutDescrip 함수를 통해 행해진다. 예를 들어:

여기서 Command 함수는 명령의 기본 정의를 제공하고, InDescrp 및 OutDescrip 함수는 제1 입력 및 매개변수들을 각각 설명한다. 하나 이상의 매개변수가 설명되는 경우, InDescrp 및 OutDescrip가 여러 번 호출될 수 있다.

IATL 명령 맵에서 도시되는 기타 주목할 만한 특징은 비동기 명령을 구현하는 기능이다. 이것은 ServerPrinter 클래스의 BeginNothing 및 EndNothing 메소드에 의해 도시된다.

이것은 이하의 명령 설명에 의해 참조된다:

이 경우에서 Command 함수는 어느 것이 입력 및 출력 매개변수인지 알 필요가 없는데, 그 이유는 입력 매개변수는 Begin 메소드에 얻어진 정의에 의해, 출력 매개변수는 End 메소드에 의해 반환된 정의에 의한 것이기 때문이다. 이 경우, Begin 메소드 및 End 메소드는 또한 동기(단일 메소드) 명령에 대해 Img::iatl::InCommandParams 및 Img::iatl::OutCommandParams의 상이한 구조를 취한다. InCommandParams은 동작이 완료되었다는 것을 나타내는 콜백 인터페이스 및 저장될 수 있고 동작과 관련될 수 있는 문맥 정보를 포함한다. End 메소드에게 문맥 정보가 다시 전달되고, 에러 코드 또는 반환 매개변수 세트로서 명령의 결과를 반환할 수 있다.

질의 컴파일러( Query compiler )

질의 컴파일러는 CDI 질의를 클래스 설명을 지니는 임의의 객체에 대해 적용될 수 있는 필터 또는 파스 트리(a parse tree) 둘 중 하나도 컴파일하는 메커니즘을 제공한다. 이 질의 컴파일러에 의해 노출된 인터페이스는 바로 아래에 발췌된 코드에 도시되어 있다.

서버 측 CDI 인스턴스는 질의를 컴파일하는 메커니즘을 제공한다. 질의 필터를 원하는 경우, IImgCommonDataServer 인터페이스의 CompileQuery 메소드가 사용된다. 파스 트리가 필요한 경우, CompileQueryTree 메소드가 호출된다.

질의 필터는 팩토리로서 반환된다. 특정 클래스 설명이 질의 필터 팩토리에 전달될 때, 질의 필터가 반환된다. 커버 하의 질의 필터는 질의에 의해 동적으로 생성된 클래스에 대해 유형 맵을 구축한다. 그것이 서버 객체에 바운드된 경우, 이것은 서버 객체에 대해 최적화된 맵을 구축한다. 이 최적화된 맵은 질의가 적용되는 것에 대해 질의 객체를 파퓰레이트하는 데에 사용된다.

질의 필터 팩토리로부터 반환된 질의 필터는 특정 서버 클래스에 정의에 의해 바운딩된다. 이것은 다수의 서버 클래스 객체 인스턴스에 대해 적용될 수 있다. 이것은 안전한 스레드(thread)가 아니다. 호출자가 다른 스레드로부터 동일한 질의를 사용하기를 원하는 경우, 동일한 질의 팩토리로부터 상이한 질의 필터 인스턴스를 획득할 수 있고, 그것을 다른 스레드에서 사용할 수 있다.

절의 필터는 그것이 클래스 설명을 지원하는 임의의 클래스에 대해 적용될 수 있는 이점을 지니고 있다. 그러나, 필터가 클래스에 대해 적용되는 것은 반드시 인스턴스화되어야만 하고 아마도 필터에 의해 일치될 모든 인스턴스는 평가되어야만 한다. 이것은 (아마도 최신 컴퓨터에 대해 10,000 정도로) 상당히 작은 객체 세트에 대해 좋지만, 큰 객체 세트에 대해서는 매우 좋지 못하다. 큰 객체 세트에 대해서는, SQL에 의해 사용되는 그러한 질의 메커니즘이 사용되어야 한다. 그러나, CDI 질의 문법은 SQL 문법과 동일하지 않다. 이 문제를 해결하기 위해, 질의 트리는 대신 컴파일될 수 있고 SQL 질의로 번역될 수 있다. CDI 질의 컴파일러가 실행되도록 허용함으로써, 연산자 순위 및 괄호와 같은 이슈가, 질의 필터에 대해 동일한 질의가 어떻게 처리될 것인가와 함께 일관되게 CDI 컴파일러에 의해 평가될 수 있다.

CompileQueryTree 메소드로부터 반환된 인터페이스는 Root 메소드를 통해 컴파일된 질의 트리로 알리아스(alias)를 반환한다. 반환된 파스 트리에 의해 점유되는 메모리는 IImgQueryTree 인터페이스가 해제될 때 시스템에 반환될 것이다.

한 실시예에서, 파스 트리는 질의 노드로 시작된다. 질의 노드는 비교 또는 불 노드(a Boolean node)일 수 있다. 불 노드인 경우, 노드는 연산자를 지니고, 이어서 두 개의 질의 노드를 포함한다. 이것은 파스 트리가 구축되도록 하는 구성이다. 이것이 비교 노드인 경우, 비교는 파스 ID와 상수를 포함한다. ID가 다음의 질의, "Printer.cJobs > 10 AND Printer.cJobs < 100"에서 볼 수 있듯이 동일한 표현식에서 두 번 나타나는 경우, 동일한 ImgParseIdentifier 인스턴스가 파스 트리에서 두 번 나타날 것이다. pCookie 필드는 호출자가 쿠키의 ID의 그 개념을 저장하도록 하는 트리의 플레이스홀더(placeholder)이다. 예를 들어, Printer.cJobs가 데이터베이스의 NumberOfJobs 컬럼으로 번역된 경우, 이것은 쿠키에 저장될 것이다. 확장성 포인트를 제공하는 것 외에는 쿠키는 무시된다.

트랜잭션( Transactions )

트랜잭션은 동작이 완전히 성공하거나 그리고 만약 실패하는 경우, 기계에 중간의 상태가 저장되지 않는다는 것을 보장하기 위해 CDI가 사용하는 메커니즘이다. 트랜잭션을 처리하는 이 실제 메커니즘은 CDI와 CAS 사이에 분산된다. CDI는 트랜잭션 및 처리 흐름을 처리하는 인터페이스를 제공한다. CAS는 트랜잭션 수정을 보장하고 데드락이 없는 잠금(locking) 전략을 제공하기 위해 필요한 메커니즘을 제공한다.

각 트랜잭션은 정확하게 하나의 트랜잭션 객체에 의해 제어된다. 각 트랜잭션 객테는 하나의 논리 저장소 객체를 지닌다. 시스템의 각 논리 저장소는 GUID에 의해 참조된다. 저장소 객체는 트랜잭션이 조정될(coordinate) 필요가 있는 임의의 지속 상태를 처리하는 것을 조정한다. 저장소가 분산 자원 관리자(distributed resource managers:DRM)이 아닌 경우, 두 개의 트랜잭션 저장소에 대한 두 번의 커밋이 성공된다는 것이 보장될 수 있다는 것을 시스템이 보장할 수 없다는 것을 고려해 보면, 단 하나의 저장소라는 제약은 합리적이다. 저장소가 DRM인 경우, 트랜잭션은 하나의 논리 저장소를 걸쳐 조화롭게 될 것이고, 즉 COM+에서 볼 수 있는 것과 같이 분산 트랜잭션 조정자(distributed transaction coordinator:DTC)에 의해 제공될 것이다.

각 트랜잭션은 많은 종속 액션을 보유한다. 규칙은 종속 액션은 그 동작을 커밋하거나(Commit) 그 동작을 되돌리는(Revert) 데에 실패할 수 없다는 것이다. 종속 액션은 일반적으로 캐시된 상태(또는 잠금)를 영구 저장소의 상태에 결합시키는 데에 사용된다. 예를 들어, CAS는 트랜잭션을 저장소에 적용하기 전에 각 객체를 복제하고, 저장소가 성공적으로 변경을 커밋하는 경우, 복제된 객체는 캐시로 스왑된다. 트랜잭션 인터페이스는 바로 아래에 도시된다.

호출자 또는 구현자가 비동기 호출 메커니즘을 사용하고자 하는 경우, 모든 인터페이스는 COM 비동기 호출 패턴을 사용한다는 것을 유의한다. 그렇지 않을 경우, 인터페이스는 인터페이스로의 동기 호출을 하거나 또는 동기 트랜잭션 종속 액션을 구현할 수 있다.

저장소 또는 트랜잭션 종속 항목을 구현하고자 하는 사용자는 IImgTransactionDepedentItem 인터페이스를 구현해야만 한다. 이 인터페이스는 두 개의 메소드, Commit 또는 Revert를 지닌다. 저장소는 (Revert가 아니라) Commit을 실패할 수 있지만, 임의의 기타 종속 항목은 그 Commit과 Revert 메소드에서 반드시 성공해야만 한다.

각 트랜잭션은 정확하게 하나의 저장소를 지닐 수 있다. 현재의 저장소 및 그 저장소 GUID는 GetTransactionalCollection 메소드로 검색될 수 있다.

호출자가 트랜잭션 저장소를 설정하기를 원하는 경우, SetTransactionalCollection 호출이 사용된다. 트랜잭션은 멀티 스레드 인터페이스이기 때문에, SetTransactionalCollection 태스크는 GUID, 설정될 집합 둘 다를 가지고, 이것은 기존의 집합이 있을 경우 그것을 반환한다. (ETransactionalSetResult가 매개변수를 반환하는 것에 의해 표시되는 바와 같이) 세 가지의 경우가 있다.

● 트랜잭션은 현재 관련 저장소 객체를 지니고 있지 않음. 이런 경우, 반환은 TransactionColletionSet가 되고, 집합에 전달되는 것은 트랜잭션과 관련된 저장소가 될 것이다.

● 트랜잭션이 현재 저장소 객체를 지니고 있지만, 사용자가 명시한 것과 동일한 GUID를 지니고 있음. 이런 경우, 트랜잭션 객체는 호출자에게 기존의 집합을 반환할 것이다. 호출자는 자신의 이전의 집합을 해제하고 트랜잭션의 현재 영구 저장소로 호출을 계속해야 한다.

● 트랜잭션이 현재 저장소 객체를 지니고 있고, 그것은 다른 저장소임(다른 저장소 GUID를 지니고 있음). 이런 경우, 트랜잭션 객체는 TransactionColletionIncompatible을 반환할 것이다. 호출자는 통상적으로 이 시점에서 동작이 실패한다(이것이 트랜잭션의 복귀를 야기하기 때문).

트랜잭션 조정자는 저장소 객체로의 인터페이스(트랜잭션 파일 시스템에서 SQL 데이터베이스로의 어느 것이나 될 수 있음)를 알 수 없기 때문에, QueryInterface를 통해 실제 저장소 인터페이스를 검색할 수 있는 것으로부터 IUnknown으로서 호출자에게 반환된다. 저장소는 트랜잭션 객체가 저장소에 변경을 제대로 커밋하거나 되돌릴 수 있도록 IImgTransactionDependentItem을 구현해야만 한다.

트랜잭션 종속 항목은 두 단계로 커밋되거나 되돌려진다. 이것은 InsertDependentAction에 대한 TransactionOrderFirst 및 TransactionOrderLast 매개변수를 통해 명시된다. 잠금을 위해 CAS에 의존하는 트랜잭션은 반드시 TransactionOrderFirst만을 사용해야 하는데, 그 이유는, 조정 트랜잭션이 커밋되거나 또는 되돌려진 후에 객체 잠금이 해제되는 것을 보장하기 위해, CAS가 TransactionOrderLast의 종속 항목을 사용하기 때문이다.

작업 흐름( Work Flow )

CDI 인터페이스는 주로 비동기이다. 따라서, 당일 동작은 하나의 스레드에서 완료될 수 있고, 또는 다수의 스레드에서 완료될 수 있다. 비동기 프로그램을 덜 사용하는 시스템은 종종 상태와 스레드를 관련시킬 수 있는데, 예를 들어, 스레드는 일단 트랜잭션이 시작되면 스레드로부터 임의의 메소드 이슈에 항상 수반되는 관련 트랜잭션을 지닐 것이다. 작업 흐름의 생각은 CDI의 스레드의 일반적인 개념을 대체한다. 작업 흐름은 사용자에 의해 제출되는 배치에 항상 정확하게 대응한다. 사용자는 작업 흐름을 생성하지 않는다. 그것은 새로운 배치가 발생할 때 CDI에 의해 자동으로 생성된다. 서버 플러그인은 그 자신의 목적을 위해 원하는 경우 스크래치로부터 작업 흐름을 생성할 수 있다.

작업 흐름은 또한 새 비동기 작업 항목을 생성하고, 그것을 작업 흐름 및 발생 배치(origination batch)와 관련시키는 것에 대한 지원을 제공한다. 배치가 취소되면, 작업 흐름이 취소되고, 따라서 작업 흐름의 모든 항목이 취소되도록 요청된다. 이 메커니즘을 사용으로 인해 CDI는 모든 인터페이스에 대해 명시적인 취소 메소드를 지원할 필요가 없고, 메소드는 단지 대신 작업 흐름을 수신한다.

작업 흐름 인터페이스는 바로 아래에 도시된다.

작업 흐름에 의해 제공되는 다음의 서비스들, 작업 항목, 토큰, 범위 및 트랜잭션에 관한 설명에 초점을 맞춘다. 트랜잭션은 위에서 별도로 커버되지만, 작업 흐름은 트랜잭션을 위한 좀 특별한 처리를 가진다.

작업 항목(Work Items)

작업 항목을 구현하기 위해, 호출자는 IImgWorkItem 인터페이스를 반드시 구현해야 한다. 작업 항목이 실행될 때 인터페이스에 Run 메소드가 호출되고, 작업 흐름이 취소될 때 Cancel 메소드가 호출된다.

작업 항목에는 세 개의 기본 유형이 있다:

● "AddWorkItem"으로 생성되는 정상 작업 항목. 이러한 종류의 작업 항목은 사용가능한 자원이 충분하면 바로 실행될 것이다. 모든 작업 항목과 같이, 호출자는 어느 종류의 작업 항목이 작업 항목 플래그를 통해 실행되는가를 명시할 수 있다.

● "AddWaitableItem"으로 생성되는 기다릴 수 있는 작업 항목. 이 기다릴 수 있는 작업 항복은 그 관련 이벤트가 신호하면 실행될 것이다.

● "AddDependentItem"으로 생성되는 종속 작업 항목. 이 종속 작업 항목은 실행되지 않으며, 작업 흐름이 취소되면 그 "Cancel" 메소드가 호출된다. 이것은 호출자가 다른 비동기 메소드를 사용하는 것을 허용하지만(예를 들어, 오버랩된 구조로 ReadFile을 호출할 수 있음), 원래의 작업 흐름으로부터 여전히 취소 통지를 수신한다.

IImgWorkItemControl 인터페이스는 두 가지 목적을 충족시킨다 - 이것은 기다릴 수 있는 작업 항목이 작업 항목을 트리거하도록 설정될 수 있는 이벤트 핸들러를 반환할 수 있도록 한다. 이것은 또한 호출자가 인터페이스를 해제함으로써 특정 작업 항목을 취소할 수 있도록 한다. 이 경우 취소 호출은 항상 비동기인데, 즉, 작업 항목에 취소가 통보되지만 인터페이스의 Release 호출은 완료하기 위해 호출을 기다리지 않는다.

이것은 작업 흐름의 Shutdown 메소드의 거동과는 다르다. Shutdown 메소드는 취소될 작업 흐름의 모든 작업 항목을 동기로 기다린다.

토큰(Tokens)

토큰은 작업 흐름의 특정 상태를 마킹하기 위해 사용된다. 이것은 인터셉션(interception)을 구현할 때 무한 재귀(infinite recursion)를 방지하기 위해 사용되도록 의도된다. 즉, 특정 유형의 인터셉션은 토큰을 작업 흐름에 추가하여, 그러한 종류의 인터셉션이 다시 발생하는 것을 방지할 수 있다.

토큰은 GUID이다 - 토큰은 작업 흐름에 추가될 수 있고, 작업 흐름에서 발견될 수 있고, 작업 흐름에서 제거될 수 있다.

트랜잭션(Transactions)

작업 흐름은 정확하게 하나의 트랜잭션이다. 작업 흐름은 유일한 인터페이스이고, 이 인터페이스로부터 트랜잭션이 생성될 수 있다. 작업 흐름은 현재의 트랜잭션을 다루는 많은 헬퍼 메소드를 제공한다.

● CreateTransaction은 트랜잭션을 생성하고 그것을 현재의 작업 흐름과 관련시킨다. 트랜잭션이 이미 존재하는 경우, 이것은 양성(benign)으로 간주되고, 현재의 트랜잭션이 반환된다(호출자는 이것이 EImgBatchTransactionCreation 반환을 통해 발생했다는 것을 추론할 수 있다).

● GetBatchTransaction은, 현재 작업 흐름(이것이 존재할 경우)과 관련된 배치 트랜잭션을 반환한다. 이것은 존재하지 않을 경우 NULL을 반환한다.

● InsertTransactionalCollection은 작업 흐름과 관련된 트랜잭션에 집합을 삽입한다. 이 삽입된 집합 또는 기존의 집합은 반환된 ppISetTransCollection을 통해 반환된다. 집합이 호환되지 않는 경우(이것이 다른 GUID를 사용하는 경우), 호출은 실패할 것이다.

● GetTransactionalCollection은 작업 흐름과 관련된 트랜잭션과 관련된 트랜잭션의 집합을 검색한다.

스코핑된 작업 흐름(Scoped work flows)

작업 흐름은 다른 작업 흐름을 포함할 수 있다. 하나의 작업 흐름이 다른 작업 흐름 내에 포함되는 경우, 이것은 그 부모로부터 모든 작업 항목 및 토큰을 자동으로 상속받는다. 이것은 또한 부모 작업 흐름으로부터 진행 중인 모든 트랜잭션을 상속받는다. 작업 흐름의 스코핑은 두 가지의 주요 유형의 기능을 허용한다:

● 부모 작업 흐름의 토큰은 삭제될 수 없다. 이것은 작업 흐름 호출이 호출자에게 다시 돌아갈 때까지 작업 흐름의 토큰 세트가 잠기도록(locked) 한다. 이것은 인터셉터(interceptor)가 토큰을 제거해서는 안 되는데 부주의하게 제거하는 것을 방지할 수 있다.

● 사용자로부터의 비트랜잭션 요청은 구현 상세사항으로서 실행되기 위해 트랜잭션을 요청할 수 있다. 예를 들어, 삭제 요청은 많은 서브-객체들의 삭제를 또한 요청할 수 있다. 원래의 배치는 트랜잭션을 만들어서는 안 되고 만들어지지 않는 다른 항목들을 포함할 수 있기 때문에, 트랜잭션을 호출자에 의해 생성된 작업 흐름에 추가하는 것을 원하지 않을 것이다. 이 해결책은 제1 작업 흐름 내부에 포함된 작업 흐름을 생성하고, 그 트랜잭션을 내부의 작업 흐름과 관련시킬 것이다. 이것은 임의의 작업 항목의 모든 취소 요청이 유지되도록 하고, 또한 원래의 작업 흐름의 모든 토큰이 원래의 작업 흐름을 트랜잭션 가능하도록 만들지 않아도 보존될 수 있도록 한다.

서버 측 통보( Server Side Notifications )

CDI는 통보를 지원하고자 하는 플러그인 집합에 대한 지원을 제공한다. 이것은 통보 채널이 원격 집합과 로컬(in-proc 또는 sandboxed) 집합으로부터 동시에 데이터를 검색하도록 하고, 클라이언트를 대신하여 통보 패널을 여전히 일관되게 처리하도록 한다. CAS는 (통보가 그 잠금 인프라스트럭처를 통해 제대로 직렬화되었다는 것을 가정하는 것과 같은) 특정 객체의 통보에 대해 추가의 지원을 제공한다.

각 배치 집합에 IImgNotificationDataServer 인터페이스가 주어지고, 이것은 각 통보 채널에 대해 클라이언트 집합을 통해 데이터를 푸시(push)하는 데에 사용된다. CDI 자체는 클라이언트 집합 및 다른 통보에 대한 다른 인프라스트럭처를 유지한다.

통보 데이터 서버는 세 개의 메소드를 노출한다:

● RegisterShutdown - 이것은 호출자가 셧 다운되고 있는 채널의 관심사를 등록할 수 있도록 한다. 예를 들어, 원격 액세스 어댑터는 클라이언트 통보 채널이 풀 다운(pulled down)될 때 자신의 통보 채널을 풀 다운한다는 것을 알아야 할 필요가 있다.

● CreateNotificationObject - 이것은 통보 채널을 통해 데이터를 푸시하는 데에 반드시 사용되는 새 통보 인터페이스를 생성한다. 각 IImgPushNotifyDataThroughChannel 인스턴스는 스레드가 안전하지 않다. 시스템은 IImgPushNotifyDataThroughChannel 인스턴스를 통해 전송된 모든 변경은 그룹으로서 전송되거나 또는 전혀 전송되지 않는다는 보증을 제공한다.

● SendFailure - 통보가 채널을 통해 전송되는 것을 방지하는 치명적인 오류가 발생할 수 있다. 이 경우, SendFailure 메소드가 호출될 수 있다. 이것은 채널을 잡아채는(tear down) 것을 보장한다. 이것은 또한 가장 효율적인 방식으로 호출자에게 오류 정보를 전송할 것이다.

채널 인터페이스를 통한 푸시 통보 데이터는 다음의 메소드를 지닌다:

● SendAddObjectNotify - 이것은 채널에게 새 통보 객체가 추가되었다는 것을 알린다. 이 객체는 추가될 수 있는데, 그 이유는 객체가 진짜 지금 막 생성되었거나 또는 대신 질의 필터에 일치하기 위해 상태를 변경했기 때문일 수도 있다.

● SendRemoveObjectNotify - 이것은, 객체가 실제로 삭제되었다거나 또는 더 이상 질의 필터와 일치하기 않아 클라이언트 집합에서 논리적으로 제거되었다는 것 둘 중 하나를 채널에게 알린다.

● SendChangeDataNotify - 이것은 채널을 따라 개개의 필드 정보를 클라이언트로 전송한다. 이 맵 인덱스는 클라이언트의 등록된 클래스 설명의 필드의 인덱스이다. 전송된 각 변경은 두 개의 거동 중 하나를 지닐 수 있다. 변경이 시스템의 어디에선가 버퍼링되고 동일한 필드에 대해 동일한 변경이 일어나는 경우, 새 필드 값이 그것을 대신한다. 이것은 임의의 버퍼링된 통보 데이터를 위해 요구되는 저장 장치를 최소화하는 이점이 있다. 또는, 모든 변경은 중요한 경우, 호출자는 각 변경의 이력이 유지되도록 요청할 수 있다.

● SendDone - 이것은 IImgPushNotifyData 인터페이스에 전송되었던 변경을 종료한다. 통보에 대한 초기 데이터가 전송중이거나(이 경우 NotifyUpdatePopulate 변수가 사용될 수 있음) 또는 객체 상태의 연이은 변경에 대한 통보(이 경우 NotifyUpdate가 명시될 수 있음) 둘 중 하나이다.

사용하기 편한 이름 레졸루션 플러그인( Friendly name resolution plus - ins )

플러그인 배치 집합이 카노니컬 이름 공간으로 플러그인하기 위해 사용하는 메커니즘은, 상술된 "플러그인 인터페이스" 섹션에서 설명된다. 기본적으로, 각 집합은 GUID에 의해 식별된다. 배치 집합이 또한 사용하기 편한 이름을 지원하고자 하면, 반드시 사용하기 편한 이름 결정 핸들러를 등록해야 한다. 이것은 요청된 클래스의 사용하기 편한 이름을 가능한 경우 카노니컬 이름으로 변환한다. 사용하기 편한 이름 결정은, 사용하기 편한 이름 클래스가 GUID 집합 대신에 사용되고 다른 클래스 팩토리 및 인터페이스가 대신 사용된다는 점을 제외하고는, 정상 플러그인이 등록되는 동일한 방식으로, CDI로 등록된다. 클래스 팩토리 및 플러그 인 인터페이스는 바로 아래에 도시된다.

클라이언트가 이름 결정을 요청하면, 사용하기 편한 이름 결정이 캐시에서 이름을 찾을 수 없는 경우, 그 클래스에 대해 등록된 플러그인 각각에 대한 이름 해결 핸들러가 (병렬 호출로) 호출된다. 이름 리졸버 각각은 이름의 해결을 시도하고, 이름 해결이 완료되면, 리졸버는 IImgServerItemCompletion 인터페이스의 Done을 호출한다. 이름 리졸버는 BeginResolveName에 의해 반환된 동일한 문맥으로 EndResolveName을 호출할 것이다. 이후 이름 리졸버는 그것이 사용하기 편한 이름에 대응하는 것으로 판정한 임의의 카노니컬 이름을 포함하는 IImgCanonicalName 반복자를 반환한다.

이름 리졸버 플러그인이 CDI 인터페이스에 대해 Gets, Queries 또는 Commands를 사용함으로써 그 이름 해결을 통상적으로 수행한다는 것을 유의한다. 따라서, 비동기 인터페이스를 구현하는 것은 통상적으로 아주 문제가 되지는 않을 것인데, 그 이유는 이것인 이어서 다른 비동기 인터페이스를 호출하고 있기 때문이다.

호출자가 매 질의 집합마다 IImgCanonicalName 반복자를 구현해야 하는 것을 방지하기 위해, 카노니컬 이름이 축적되고 반복자 인스턴스가 반환될 수 있는 집합 인터페이스가 제공된다. 이 인터페이스가 바로 아래에 도시된다.

집합 어댑터 서비스( Collection Adapter Service )

도시되고 설명된 실시예에서, IImgBatchCollection 인터페이스는 구현하기가 매우 복잡하다. 호출자는 반드시 각 배치 항목을 통해 실행해야 하고, 그것을 디코딩해야 하고, 그것에 어떻게 응할지를 결정해야 한다. 일반적으로, 집합이 배치에 액세스하기를 원하는 유일한 이유는 기계에 걸친 전송 또는 프로세스 경계에 대해 배치를 보존하기 위해서이다. 배치가 실제로 영구 저장소로 또는 영구 저장소로부터 로딩된 객체 그룹과 상호작용하는 경우, 플러그인이 처리하는 것은 매우 복잡하다. 이러한 이유에 대해 집합 어댑터 서비스가 제공된다. 집합 어댑터 서비스는 이하의 기능을 제공한다:

● 한 세트의 플러그인 집합에서 객체를 검색한다.

● 인스턴스화된 객체를 캐시하고 사용중이지 않을 때는 이것을 플러시(flush)한다.

● 유형 맵을 통해 클라이언트 객체를 서버 객체로 바인딩하는 것을 관리한다.

● 호환가능한 집합 간의 트랜잭션을 조정한다.

● 트랜잭션과 함께 객체 잠금을 관리한다.

● 동기 및 비동기 객체 둘 다를 관리한다.

● 객체 필터를 구현하기 위해 질의 컴파일러와 상호작용한다.

● 직렬로 또는 병렬로 호출을 실행하기 위해 동적으로 선택함으로써 자원을 아주 효율적으로 사용한다.

● 최적의 잠금 스킴(scheme)을 통해 객체의 병행성(concurrency)을 유지한다.

● 객체 변경 통보를 처리한다.

기본 CDI가 각종 플러그인을 함께 묶는 글루(glue)인 경우, 집합 어댑터 서비스는 똑똑하고, 비동기이고, 높은 성능의 플러그인이 구현하기에 가능한 한 단순하다는 것을 보장한다. 집합 어댑터 서비스 모델은 한 실시예에 따라 도 14에 도시되어 있다.

소정의 CAS 인스턴스는 그것에 플러그인 된 다수의 객체 집합을 지닐 수 있다. 각 객체 집합은 예를 들어 "Printers"의 단일 클래스 이름을 지원하고, 소정의 객체 집합의 모든 객체는 동질(homogenous)이다. 따라서, 모든 객체는 소정의 서버 객체가 구현하는 속성 및 명령 전부를 표현하는 단일 클래스 설명에 의해 설명될 수 있다. 집합 어댑터 서비스는 서버 클래스 설명을 사용하여 클라이언트와 서버 객체 간에 데이터를 전송하고 객체 명령을 실행한다. 서버의 각 객체는 그 IImgObject 인터페이스를 통해 일부 기본 기능을 구현한다. IImgCollectionAdapter는 이하의 인터페이스를 지닌다:

이 클라이언트는 자신의 IImgBatchCollectionFactory::CreateInstance 메소드의 "CoCreateInstance"를 호출함으로써 집합 어댑터를 인스턴스화한다. 이것은 IImgCollectionAdapter::Initialize를 호출하고, 이것이 전달되었던 IImgCommonDataServer로 이것을 전달한다. 이후 이것은 RegisterObjectCollection 호출을 통해 그 객체 집합 각각을 인스턴스화하고 등록한다.

IImgObjectCollection은 이하의 메소드를 지닌다:

GetTransactionCollectionData 호출은 집합이 트랜잭션을 지원하는 방법을 반환하고, 집합은 종속 항목인 트랜잭션은 지원할 수 없거나(이것은 임시 집합에 의해 지원될 수 있음) 또는 기초가 되는 저장 시스템 및 트랜잭션이 성공적일 수 있는 범위를 유일하게 식별하는 ID에 따라 커스텀 트랜잭션 인터페이스를 반환함으로써 트랜잭션을 지원할 수 있다.

GetCollectionData 호출은 객체 클래스 이름, 최적화된 유형 맵에서 사용된 ObjectID 및 각 객체를 설명하는 서버 클래스 설명을 반환한다. 나머지 호출, BeginGet 및 EndGet 그리고 BeginEnum/EndEnum은 객체을 집합으로부터 검색한다. IImgBatchCollection::Shutdown 메소드가 호출될 때 도시된 메소드는 CAS에 의해 호출된다.

CAS가 실행하고 시간이 많이 소요될 것 같은 임의의 호출은 Begin/End 쌍의 형태를 취할 것이다. 각각의 Begin 호출은 IImgServerItemCompletion 인터페이스를 취하고 ppContext 매개변수를 통해 문맥이 반환되도록 한다. CAS는 인터페이스를 구현하기 위해 이하를 보증한다:

● Begin 호출이 실패하면, End 호출은 호출되지 않는다.

● Begin 호출이 성공하면, End 호출은 반드시 호출된다.

● IImgServerItemCompletion::Done 메소드가 호출된 후 End 호출이 호출된다.

● Begin 메소드가 반환된 후 End가 호출된다.

● End 호출은 Begin 호출에서 반환된 문맥에 전달된다.

이것은 Begin 메소드 내의 Done을 호출함으로써 Begin 메소드가 동기 호출을 구현할 수 있도록 한다. 그것이 구현하는 임의의 IO 바운드 동작은 다른 스레드에서 실행되어야 하거나(다른 동작과 통합되는 것이 바람직함) 또는 비동기 호출로서 이어서 구현되어야만 한다. 비동기 항목이 완료될 때, IImgServerItemCompletion::Done 메소드가 호출되어야 한다. Begin 메소드가 특정 호출에 대한 임의의 상태를 추적할 필요가 있을 경우, 이것은 ppContext 매개변수로 반환될 수 있다. End가 호출될 것이라는 것을 CAS가 보증하기 때문에, 문맥은 항상 비어있을 수 있다. CAS는 호출을 스케줄링하기 위해 이하의 메커니즘을 사용한다:

● 호출이 동기인 경우(Begin 메소드 내부에서 Done이 호출됨), 호출자는 병령 실행을 요청하고, 메소드의 실행은 CPU 바운딩될 것이다. 따라서, 다음 호출이 제일 처음으로 직렬화될 것이다. 호출이 실패하면, 결과가 기록되지만 모든 이후의 호출은 여전히 호출된다.

● 호출이 비동기이고 클라이언트가 병렬 실행을 요청하는 경우, 다음의 "Begin" 메소드는 원래의 스레드에서 즉시 호출된다.

● 호출이 비동기이고 클라이언트가 순차 또는 트랜잭션 의미론을 요청한 경우, 나머지 작업은 IImgServerItemCompletion::Done 메소드가 호출된 스레드와 동일한 스레드에서 수행될 것이다.

이 규칙은, 클라이언트 집합 또는 CAS의 객체가, 반드시 IO 바운드 동작이 비동기 호출 패턴으로 실행되어야 하고, 그렇지 않을 경우 이것이 다른 작업 항목의 병렬 실행을 방해할 수 있다는 것을 반드시 보장해야 한다는 것을 의미한다.

객체는 이하의 인터페이스를 지닐 수 있다:

구현될 메소드는 이하와 같다:

● Initialize 호출은 객체가 집합으로부터 CAS로 처음 반환될 때 CAS에 의해 호출된다. 이것은 객체를 핸들러 인터페이스로 전달하고, 이 핸들러 인터페이스는 객체가 자신을 삭제하고, 자신을 잠그고, 트랜잭션과 상호작용하고, 시스템의 나머지에 변경 통보를 전송하도록 한다. 이것은 또한 호출 필터를 반환할 수 있다. 호출 필터는 객체가 부분 인스턴스화를 지원하는지 여부를 나타낸다(이 경우, 그로부터 임의의 데이터를 판독하기 전에 BeginGet/EndSet 메소드가 호출된다). 이것은 또한 일부 필드만을 기록함으로써 객체를 유지하는 것을 지원하는지 여부를 나타낸다. 이 경우 BeginGet/EndSet 메소드는 호출자가 어느 속성을 세트에 명시했는지를 정확하게 명시하면서 호출될 것이다.

● GetRealObjectAddress는 ImgServerClassDescription 접근자가 관련되어 있는 객체 주소를 반환한다. 이것은 꼭 필요한데, 그 이유는 객체가 다수의 상속을 이용하여 구현되는 경우, IImgIObjectInterface 주소가 실제 객체의 주소와 반드시 동일할 필요가 없기 때문이다.

● BeginGet/EndGet - 이 메소드는 객체가 자신의 호출 필터의 부분 객체를 지원한다는 것을 나타낼 때에만 호출된다. 객체는 최적화된 맵이 판독하려 하는 필드를 나타내는 태그로 전달될 것이다. 객체는 영구 저장소로부터 자신의 제1 인스턴스화 후에 무거운 필드를 사용하기 위해 이것을 이용할 수 있다. 객체가 이것을 하고 호출이 IO 바운드인 경우(이것은 거의 항상 그러할 것임), 객체는 반드시 비동기 호출 패턴을 사용해야 한다.

● CloneObject - CAS는 객체가 불변의 방식으로 구현된다고 가정한다. 이것은 데이터가 객체로부터 판독될 때 그 객체가 여전히 잠겨지지 않도록 한다. 이것은 트랜잭션을 단순화하는데, 그 이유는 객체가 트랜잭션이 커밋할 때까지 중복 상태로 유지될 수 있기 때문이다. 따라서, 객체는 설정이 일어나기 전에 자신을 복제하도록 요청된다. 객체는 CAS와 호환하기 위해 불변의 방식으로 코딩되어야 한다.

● BeginSet/EndSet - 이 한 쌍의 메소드는 객체가 복제되고 그 접근자가 그 상태를 변경하기 위해 사용된 후 세트에서 호출된다. 객체는 이 호출에서 자신의 새로운 상태가 유효한지를 검증할 수 있다. 객체가 호출 필터의 것을 요청하는 경우, 설정이 발생했을 때 클라이언트에 의해 어느 필드가 명시되었는지를 알 수 있을 것이다.

객체 핸들러( Object Handler )

객체 핸들어는 CAS에 의해 각 객체로 전달되는 인터페이스이며, 이것은 객체가 각종 방식으로 CAS와 상호작용할 수 있도록 한다. CAS에서 개시되고 유지되는 각 객체에 대한 객체 핸들러의 단 하나의 인스턴스가 있다. IImgObjectHandler 또한 각 객체에 대한 비동기 잠금을 노출한다. 이 잠금은 트랜잭션 및 변경 통보 둘 다를 포함하는 상태 변경에 대해 객체로의 접근을 논리적으로 직렬화하기 위해 CAS에 의해 사용된다. 객체의 몇몇 액션에서 객체는 잠겨져야 한다. 객체 핸들러 인터페이스는 이 의미론을 시행한다. 객체 핸들러 인터페이스는 바로 아래에 도시된다:

객체 비동기 잠금(Object Asynchronous Lock)

중요한 메소드는 GetObjectLock인데, 이것을 이용하여 호출자는 객체와 관련된 잠금을 검색할 수 있다. 반환된 잠금은 트랜잭션 잠금에 대한 지원을 지니는 비동기 잠금이다. CAS에 의해 이 잠금 및 관련된 의미론이 사용되고 동일한 의미론은 다른 호출자에 의해 사용되어야 한다. 이 인터페이스는 바로 아래에 도시된다.

잠금은 비동기인데, 즉, 이것은 사용자가 잠금을 획득할 수 있을 때 사용자를 다시 호출한다. 이것은 이하의 기능을 제공하는 의도적인 설계의 선택이다.

● 잠금을 획득하는 것을 시도하는 작업 흐름은 취소될 수 있다. 잠금 인터페이스는 비동기이기 때문에, 호출자에게 잠금 획득 시도가 취소되었다는 것이 통보될 수 있다.

● 트랜잭션에 걸쳐 객체 액세스를 직렬화하는 잠금이 사용될 수 있고 트랜잭션은 아마도 많은 객체를 획득해야만 하고 통상적으로 상태를 저장소에 기록해야만 하기 때문에, 객체 잠금은 아마도 오랜 기간 동안 보유될 수 있다. 따라서, 임의의 잠금 액세스는 아마도 IO 바운드인 동작에서 기다리고 있을 것이다. 비동기 잠금을 이용함으로써, 스레드는 IO가 완료되기를 기다리기보다는, 다른 CPU 바운드 동작에 대해 다시 사용될 수 있다.

CAS가 Gets/Queries 및 Commands에 대해 객체 잠금을 사용하지 않는다는 것을 유의한다. 이것은 트랜잭션이 논리적으로 동작을 보유하고 있을 것임에도 불구하고, 이것은 세트 및 통보를 단지 직렬화한다는 것을 의미한다. 호출자가 명령이 트랜잭션이 되기를 원하는 경우, 호출자는 트랜잭션 그 자체를 반드시 생성하고 객체 잠금을 획득해야만 한다.

잠금을 획득하고자 하는 호출자는 반드시 IImgLockEntry 인터페이스를 구현해야만 한다. 이 인터페이스는 두 개의 메소드, EnterLock 및 Notify Cancel을 지닌다.

EnterLock은 호출자가 잠금을 획득했을 때에 호출된다. ImgLockContext는 EnterLock 함수로 전달된다. 이 잠금 문맥은 정확하게 그 특정 잠금 획득과 관련되고, 잠금이 해제되었을 때 잠금 인터페이스로 반드시 전달되어야 한다. 이는 두 가지 목적을 충족시킨다.

● 또 다른 호출자가 오류로 잠금을 획득하지 않고 잠금을 해제하려고 하는 경우, 해제는 아무 효력이 없다.

● 잠금이 반드시 유지되어야 한다는 사실은 제공될 잠금 문맥을 요청함으로써 다른 인터페이스에 의해 문법적으로 표현될 수 있다. 이것은 또한 관련 액션을행하기 전에 잠금이 실제로 유지되어야 한다는 것을 점검할 수 있다.

또한, 호출자가 잠금을 획득한 작업 흐름이 취소되는 경우, 그 인터페이스의 NotifyCancel 메소드가 호출된다. 이후 호출자는 자신이 아직도 잠금을 획득해야만 하는지의 여부 또는 잠금으로의 액세스를 취소할 것인지의 여부를 결정할 수 있다. 호출자는 자신이 AcquireLock을 호출한 반환된 잠금 시퀀스 인터페이스를 해제함으로써 잠금의 획득을 취소할 수 있다.

잠금이 획득될 수 있다는 것을 호출자가 보증할 수 없는 경우는 바람직하지 못하다. 예를 들어, 호출자는 잠금을 획득하고, 참조 카운트를 증가시키고, 그리고 잠금을 해제하기를 원할 수 있다. 이후 호출자는 그 객체의 일부 액션을 수행하고, 잠금을 다시 획득하고, 참조 카운트를 감소시킬 것이다. 호출자가 제2 동작에 대해 잠금을 획득하지 못하는 경우, 참조 카운트는 절대로 제대로 감소될 수 없을 것이다.

호출자가 잠금으로의 액세스를 보증하는 기능은 IImgLockSequence 인터페이스에 의해 제공된다. 잠금 시퀀스가 일단 잠금으로부터 반환되면, 임의의 잠금의 순차적 획득 및 해제는 성공하도록 보증된다. 이것은, 구현 상세사항으로서 IImgLockSequence 인터페이스가 항상 잠금을 획득할 수 있도록 충분한 저장소를 보존하는 객체에 의해 구현되기 때문에 작동된다.

잠금 및 트랜잭션(Locks and Transactions)

트랜잭션은 순차적으로 많은 객체를 잠궈야 할 필요가 있을 수 있다. 이것은 하나 이상의 트랜잭션 간에 임의의 잠금의 획득이 순환되는 경우, 시스템이 데드락하는 기회를 제공한다. 두 개의 트랜잭션이 동일한 잠금을 보유하는 것은 문법적으로 비논리적이므로, 잠금은 트랜잭션에 특별 지원을 제공한다. 이것은 속성을 설정하기 전에 객체를 잠글 때 CAS에 의해 자동으로 활용되고, 트랜잭션 문법을 구현하기를 원하는 임의의 객체에 의해 사용되어야만 한다.

정확하게 한 번에 하나의 트랜잭션만이 잠금을 보유할 수 있다. 잠금을 획득하고자 하는 트랜잭션은 AddTransactionToLock 호출을 사용한다. 잠금을 이미 보유하고 있는 트랜잭션이 있는 경우, 호출은 pbTransactionAdded 매개변수에 FALSE를 반환할 것이다. 이후 트랜잭션은 되돌려져야 하고(트랜잭션에 의해 현재 보유된 모든 잠금 및 자원이 풀려나야 함) 호출자에게 실패를 반환하기 전에 완료될 기존의 트랜잭션을 기다린다. 호출자는 완료될 잠금을 보유하는 임의의 트랜잭션을 기다리기 위해 WaitForTransactionToFinish를 호출한다(이것은 비동기로 통보됨). 잠금을 보유하는 트랜잭션이 없는 경우, 이것은 즉시 다시 호출된다. 잠금은 전송이 커밋되거나 되돌려지는 경우 자동으로 트랜잭션과 연관관계가 끊어질 것이다.

호출자가 기존의 트랜잭션이 완료되는 것을 기다려야 하는 이유는 호출자가 동작을 재시도하는 경우, 호출자가 단지 오래된(변경되지 않은) 객체의 상태를 검색하기만 하는 것이 아니라 잠금을 보유하는 트랜잭션에 대해 "스핀(spin)"을 한다는 것을 보증하기 위해서이다.

CDI/CAS 최적의 잠금 모델(CDI/CAS optimistic locking model)

CDI는 의도적으로 임의의 잠금 구성을 클라이언트에게 노출하지 않는다. 이에 대해서는 여러 이유가 있다:

● 각각의 잠금은 클라이언트에 의해 유지될 수 있는 추가의 오버헤드를 서버에 추가해야만 한다.

● 클라이언트가 오류 상태로 되고 잠금으로 되는 경우, 이것은 서버의 동작을 무능하게 할 수 있다.

● 잠금을 해제하지 않는 클라이언트를 다루기 위해, 수동 잠금-해제 메커니즘이 서버에 추가되어야 할 것이다. 이것은 단지 피할 수 없는 추가의 UI 및 유지보수이다.

그러나, 서버 상태가 제대로 유지되고 "이중 관리자"(dueling administrator) 문제를 피한다는 것은 바람직하다. 두 관리자가 동시에 프린터의 이름을 바꾸고자 시도하는 경우, 이름 바꾸는 것이 한 번은 성공하고 다른 한 번은 실패한다는 것을 보장하기를 원한다.

시스템은 트랜잭션이 객체 잠금을 획득하기 위해 사용하는 메커니즘에 의해 부분적으로 이들 메커니즘을 유지한다. 이것은 또한 각 객체에 "Object::LockId" 속성을 부여함으로써 유지된다. 객체 상태를 변경하기 위해 단순히 쓰고, 또한 현재의 객체 잠금 id와 일치하는 잠금 id를 제공해야 한다. 이것은 객체의 변경을 시도하기 전에 사용자가 마지막 객체 상태를 알고 있었다는 것을 나타낸다. 일치하니 않는 객체 id를 제공하는 경우, 상태를 변경하고자 하는 시도는 실패할 것이다. 응답에서, 호출자는 반드시 변경하고자 하는 속성을 반드시 다시 얻어야 하고 따라서 잠금 id를 다시 얻어야 한다. 이어서 잘 기록된 클라이언트는 달성하고자 하는 변경이 여전히 중요하고 따라서 그 동작을 다시 시도한다는 것을 보장하기 위해 속성을 점검한다.

객체 변경 핸들러(Object change handler)

객체에 대한 변경을 검색하기 위해서는, 객체 잠금이 반드시 획득되어야 하고, 이후 객체 핸들러의 GetChangeHandler 메소드가 반드시 호출되어야 한다. GetChangeHandler 메소드는 잠금 문맥을 필요로 한다. 객체가 변경 핸들러를 획득하기 위해 사용할 수 있는 다른 메커니즘은 세트 동안 매개변수로서 속성 접근자에게 전달된 것이다(이 경우의 CAS는 사용자를 위해 임의의 객체 속성을 설정하기 전에 객체 잠금을 획득한다). 객체 변경 핸들러 인터페이스는 바로 아래에 도시된다.

CDI 변경 핸들러 인터페이스는 위의 섹션에서 설명되었다. 이 인터페이스는 특정 채널을 통해 변경을 전송하는 기능을 제공한다. CAS는 질의를 제대로 스코핑하고 특정 객체에 관심이 있을 수 있는 모든 채널을 다루는 기능을 추가한다. 객체가 해야 할 일은 어느 속성이 변경되었는가를 표시하는 것이다. 가장 간단한 메커니즘은 NotifyChange를 호출하고 변경된 필드에 대한 태그를 전달하는 것이다. 이후 CAS는 속성 접근자를 통해 그 필드에 대한 데이터를 검색하고 변경에 관심이 있는 모든 채널에 속성 변경 통보를 전송할 것이다.

속성을 검색하는 CAS의 노력을 줄이기 위해, 호출자는 또한 NotifyChangeData 호출을 통해 데이터를 직접 명시할 수 있다.

마지막으로 모든 변경이 변경 핸들러에 축적될 때, 이 모든 변경은 SendChanges 메소드를 통해 전송될 수 있다. 변경들 중 임의의 것이 전송되지 않는 경우, CAS는 그 객체를 타겟할 수 있는 모든 통보 채널을 해체할 수 있다.

변경 통보에 대한 IATL 지원(IATL support for change notifications)

변경 통보는 객체가 구현하기에 어렵지 않다. 더 쉽게 하기 위해, 객체의 속성이 CDI 속성 get 또는 set을 통해서만 수정되고 그 속성이 데이터 멤버로서 구현되는 경우, IATL은 사용자를 위해 자동으로 변경 통보 코드를 생성할 것이다. 필드를 명시할 때, gNotify modifier는 유형 맵의 Field 함수로 전달될 필요가 있다. 이것이 바로 아래에 도시된다:

이것은 속성에 대한 get 및 set 접근자를 자동으로 구축한다. 속성이 변경되면, 변경은 CAS에 의해 속성 접근자로 제공된 변경 핸들러로 전송될 것이다.

나머지 객체 핸들러 함수(Remaining Object handler functions)

Delete 객체

이 함수는 CAS 캐시에서 객체를 삭제한다. 이것은 또한 클라이언트에 변경 통보를 전송한다. 객체는 반드시 잠겨져야 하고 객체를 삭제하기 위해서는 잠금 문맥이 제공되어야 한다.

Current 객체

CAS는 불변의 객체 모델을 사용한다. 객체가 수정되면, 객체는 복제되어 그 상태가 변경되는 경우 그것이 캐시로 삽입된다. 오류가 발생하면, 새 객체는 버려진다. 이러한 설계에 있어 흥미있는 사실은, 객체가 비동기 이벤트의 결과로서 변경 통보를 전송하고자 하는 경우, 또는 객체가 속성 get 동안 또는 명령 동안 객체의 가장 최근 버전을 필요로 하는 경우, 객체가 현재 보유하고 있는 객체의 인스턴스가 옳은 것인지를 알 수 없다는 것이다. 이런 경우를 다루기 위해, 객체 핸들러는 현재의 객체 인스턴스를 검색할 수 있다. 객체 상태 변경이 객체 잠금에 의해 보호되기 때문에, 잠금은 반드시 현재 객체가 유효하게 검색될 수 있기 전에 획득되어져야만 한다.

HoldObjectInCache 및 ReleaseObjectFromCache

CAS는 보통 메모리의 객체가 버려지기 전에 약 10초 동안 메모리에 객체를 캐시한다. 객체는 대신 캐시에 영구적으로 남아 있을 것인지 또는 다른 객체가 캐시되는 동안 캐시되어 있을 것인지 여부를 결정할 수 있다. 이러한 요구사항을 다루기 위해, HoldObjectCache 메소드는 객체 핸들러에서 호출될 수 있다. 호출될 때, 객체는 대응 ReleaseObjectFromCache가 호출될 때까지 캐시에 있을 것이다. ReleaseObjectFromCache에 대해 소정수의 호출이 행해져 객체가 해제될 수 있을 때에만 HoldObjectInCache를 상기 소정수 호출과 동일 수 만큼 호출될 수 있다.

객체가 일부 다른 동작 때문에 이미 활성으로 캐시에 보유되어 있는 경우에만 HoldObjectInCache를 안전하게 호출할 수 있다. 그렇지 않을 경우, HoldObjectInCache가 호출되고 있는 동안 객체가 캐시에서 해제되는 특성 상태(race condition)가 있을 수 있다. 이것은 충돌을 일으키지는 않겠지만, 명백하게, HoldObjectInCache 호출은 이 경우 이행될 수 없다.

HoldObjectInCache가 성공하도록 보증되는 시점은 아래와 같다:

● IImgObject 인터페이스로의 Intialize 호출이 객체에 의해 지원되는 동안

● 임의의 속성 get 또는 set 또는 명령 호출 동안

● 호출자가 자신이 과거에 HoldObjectInCache 호출을 생성했다는 것을 알 때

집합이 제공된 프레임워크( Framework Provided Collections )

IImgObjectCollection 및 IImgObject 인터페이스는 구현하기에 특별히 어렵지 않은데, CAS를 사용하는 플러그인이 둘 다를 구현하기를 원하거나 또는 둘 다를 구현해야 하는 그런 경우가 있을 것이다. 예를 들어, 새 데이터 모델을 통해 아래 레벨 서버의 객체를 나타내는 어댑터를 기록하고 있을 때, 사용자는 사용자 자신의 IImgObjectCollection을 제공하기를 원할 것이다. 그러나, 객체 집합이 제공된 표준 프레임워크가 사용될 수 있는 많은 경우가 있다. 이것은 도 15에 도시된다.

집합이 제공된 프레임워크 및 그 기능은 이하와 같다.

In Memory Collection은 지속되지 않는 객체의 동적 집합을 제공한다. 이 집합은 이것이 플러그인에 의해 노출할 몇몇 실제의 불변의 객체에 제공될 때 유용할 수 있다. 이것은 또한 TS 프린팅과 같은 시나리오에서 경량의 지속할 수 없는 객체(light-weight non-persist-able objects)에 저장소를 제공하는 데에 있어 유용할 수 있다.

Persistent Object Collection Service는 영구 저장소에서 객체를 지속시키는 기능을 제공하는 집합이다. 레지스트리, SQL 데이터베이스 또는 WinFS 를 포함하여 객체가 지속될 수 있는 여러 저장소가 있다. 각각의 저장소는 소유의 Persistent Object Collection Service 인스턴스를 지닐 것이다. Persistent Object Collection Service는 객체 상태를 적절한 저장소로 지속시키는 것을 지원할 것이다. 이것은 저장을 위해 필요한 객체 상태를 검색하기 위해 서버 유형 맵(ImgServerClassDescription)을 사용할 것이다. 또한, 할 수 있는 경우에, 기초가 되는 저장소에 의해 제공되는 질의 지원으로 질의를 바로 매핑할 것이다.

Notification Shim Collection은 이하와 같이 동작한다. 많은 경우, 시스템은 제한된 통보에 대한 지원 또는 통보에 대한 지원을 제공하지 않은 다운 레벨 시스템으로 연결될 것이다. 이 경우, 호출자는 모든 객체를 나열하여, 새 객체가 도착하거나 떠날 경우를 점검하고, 임의의 필드 변경이 있는 경우 적절한 통보를 발행할 필요가 있다. IImgObjectCollection 인터페이스가 공용이고 IImgServerClassDescription이 호출자가 객체의 모든 필드를 액세스할 수 있도록 하기 때문에, 이 거동을 자동화하는 일반적인 심 객체 집합(generic shim object collection)이 제공될 것이다. 이것은 또한 통보를 지원하기 위해 단지 두 줄의 여분의 코드 라인을 추가하기를 원하지 않는 호출자에 대해 사용될 수 있다. 그러나, 필드가 변경될 경우 자동으로 통보를 생성할 필드가 디폴트 구현에 제공된다.

요약하면, 프레임워크는 대부분의 사람이 자기 자신의 집합 인터페이스를 절대 구현할 필요가 없게 될 많은 캔 객체 집합(a number of canned object)을 제공할 것이다. 어댑터 집합 인터페이스는 예외일 수 있다. 다운 레벨 어댑터로부터 이벤트의 생성을 자동화하기 위해 심 집합이 제공된다.

IImgObject 의 IATL 구현

IImgObject는 또한 구현하기에 특별히 어려운 인터페이스는 아니다. 표준 객체를 기록하는 것을 가능한 한 단순하게 하기 위해, IATL은 비부분(non-partial) 객체 구현을 지원하는 IImgObject의 표준 구현을 제공한다. 이것이 구현하는 클래스들은 이하와 같다:

● TServerObjectBase - IUnknown, Initialize, BeginGet/EndGet 및 BeginSet/EndSet의 디폴트 구현을 제공한다. get 및 set 함수는 아무것도 하지 않는다.

● TServerObject - 이 템플릿은 기본 클래스 템플릿화를 통해 GetRealObjectAddress 구현을 추가한다.

● TServerDefaultCloneableObject - 이 템플릿은 CloneObject 메소드를 추가한다. 호출자는 자신의 파생 클래스(a derived class)에 복사 생성자(a copy constructor)를 반드시 제공해야 하고, 예외를 던지지 않거나, 또는 오류인 경우 예외를 던져야 하며, 또는 객체가 복사된 후에는 그 IsValid() 메소드로부터 오류를 반환해야 한다.

● TIMCServerObject - 이 객체는 인 메모리 집합(In Memory Collection)에 대한 BeginSet/EndSet 메소드 쌍을 구현한다.

관리되는 객체( Managed Objects )

IATL은, 메소드 및 필드가 속성으로서 표현되도록 하고 CDI를 통해 메소드가 명령으로서 표현되도록 하는 템플릿 라이브러리르 제공함으로써 관리되지 않는 C++ 클래스에 자동화된 지원을 제공하도록 설계된다. 관리되지 않는 공간을 남겨 두는 데에는 여러 이점이 있지만, 특히 관리되는 코드가 성능, 강인성(robustness) 및 설계 안정성(design stability)을 향상시켜 주기 때문에, 시스템은 또한 관리되는 객체에 대해 데이터 주도 지원(data driven support)을 제공하기를 원한다.

CAS가 많은 중요한 기능을 캡슐화하기 때문에, 동일한 일을 하는 병렬 관리되는 구현을 지닌다는 것은 잘 알려지지 않았을 것이다. 결정은 관리되는 메타데이터를 사용하여 관리되지 않는 공간의 ImgServerClassDescription을 생성하고, 그것을 사용하여 새도우 비관리 객체(a shadow unmanaged object)를 파퓰레이트하고 유지하는 것이다.

한 실시에에 따라, 결정이 도 16에 도시되어 있다. 여기서, 비관리 객체의 클래스 메타-데이터는 비관리 공간의 ImgServerClassDescription으로 매핑된다. 이 클래스 설명은 새도우 비관리 객체를 조작할 수 있는 접근자를 사용한다. 비관리 객체의 각 속성은 인덱스화되고 관리 객체의 속성에 대응할 것이다. 관리 객체는 변경 통보 메커니즘을 사용하여 새도우 비관리 객체에게 비동기 변경을 전파할 것이다. 비관리 객체에 대해 설정이 발생할 때마다, 속성은 우선 관리 객체에 적용되고, 관리 객체의 상태는 다시 비관리 객체로 복제된다. 메소드로 바로 매핑되는 명령은 관리 객체를 호출한다.

이 메커니즘의 이점은 객체의 가장 일반적인 동작인 Gets 및 Queries가 완전치 비관리 새도우 객체 상에서 실행될 것이라는 것이다. 또한, 비관리 새도우 객체는 비관리 Persistent Object Collection Service에 의해 저장될 수 있고, In Memory Collection에 저장될 수 있다. 이것은 또한 property get을 수행하는 데에 필요할 느린 반영 메커니즘(a slow reflection mechanism)을 우회한다. 관리 객체에 대한 변경은 배치 액션당 하나의 인터롭 성크(interop thunk)로 제한된다. 이것은 CAS후에 발생하기 때문에, 전체 배치가 번역되기 전에 그것을 정렬할 수 없다. 이 한계는 모든 질의 및 겟 경우에서 관리 경로를 피함으로써 오프셋되어야 한다.

예시적인 클라이언트 장치/프린트 서버 컴포넌트( Exemplary Client Device/Print Server Components )

도 17은 상술된 실시예를 구현하기 위해 클라이언트 장치 및 프린트 시스템 둘 다에 채용될 수 있는 컴포넌트를 지니는 예시적인 컴퓨팅 장치를 도시한다.

컴퓨팅 장치(1742)는 하나 이상의 프로세서 또는 처리 장치(1744), 시스템 메모리(1746) 및 시스템 메모리(1746)를 포함하는 각종 시스템 컴포넌트를 프로세서(1744)에 결합하는 버스(1748)를 포함한다. 버스(1748)는 메모리 버스 또는 메모리 컨트롤러, 주변 버스 및 AGP 및 각종 버스 아키텍처 중 임의의 것을 이용하는 로컬 버스 또는 프로세서를 포함하는 몇몇 유형의 버스 구조 중 어느 것이라도 될 수 있다. 시스템 메모리(1746)는 ROM(1750) 및 RAM(1752)을 포함한다. 시동 시 컴퓨팅 장치(1742) 내의 구성요소 간의 정보 전송을 돕는 기본 루틴을 포함하는 BIOS(1754)는 ROM(1750)에 저장되어 있다.

컴퓨팅 장치(1742)는 또한 하드 디스크(도시 생략)로의 기록 또는 그로부터의 판독을 위한 하드 디스크 드라이브(1756), 이동식 자기 디스크(1760)로의 기록 또는 그로부터의 판독을 위한 자기 디스크 드라이브(1758), CD-ROM 또는 기타 광 매체 등의 이동식 광 디스크(1764)로의 기록 또는 그로부터의 판독을 위한 광 디스크 드라이브(1762)를 포함한다. 하드 디스크 드라이브(1756), 자기 디스크 드라이브(1758) 및 광 디스크 드라이브(1762)는 SCSI 인터페이스(1766) 또는 일부 기타 적절한 인터페이스에 의해 버스(1748)에 접속되어 있다. 드라이브 및 이에 관련된 컴퓨터 판독가능 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 및 컴퓨터(1742)의 다른 데이터의 불휘발성 저장을 제공한다. 본 명세서에 설명된 예시적인 환경이 하드 디스크, 이동식 자기 디스크(1760) 및 이동식 광 디스크(1764)를 채용하지만, 당업자들은 자기 카세트, 플래시 메모리 카드, DVD, RAM, ROM 등과 같은 컴퓨터에 의해 액세스가능한 데이터를 저장할 수 있는 다른 유형의 컴퓨터 판독가능 매체 또한 예시적인 운영 환경에서 사용될 수 있다는 것을 이해할 것이다.

운영 체제(1770), (사용자 에이전트 또는 브라우저와 같은) 하나 이상의 애플리케이션 프로그램(1772), 기타 프로그램 모듈(1774) 및 프로그램 데이터(1776)를 포함하는 많은 수의 프로그램 모듈이 하드 디스크(1756), 자기 디스크(1760), 광 디스크(1764), ROM(1750) 또는 RAM(1752)이 저장될 수 있다. 사용자는 키보드(1778) 및 포인팅 장치(1780) 등의 입력 장치를 통해 명령 및 정보를 컴퓨터(1742)에 입력할 수 있다. 다른 입력 장치(도시 생략)로는 마이크, 조이스틱, 게임 패드, 위성 안테나, 스캐너 등이 있을 수 있다. 이들 및 기타 입력 장치는 버스(1748)에 결합된 인터페이스(1782)를 통해 처리 장치(1744)에 접속된다. 모니터(1784) 또는 다른 유형의 디스플레이 장치도 비디오 인터페이스(1786) 등의 인터페이스를 통해 버스(1748)에 접속될 수 있다. 모니터 외에, 퍼스널 컴퓨터는 통상적으로 스피커 및 프린터 등의 기타 주변 출력 장치(도시 생략)를 포함할 수 있다.

컴퓨터(1742)는 일반적으로 프린터 서버(이것은 이어서 하나 이상의 프린터로 접속됨)(1788)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 사용하여 네트워크화된 환경에서 동작할 수 있다. 프린터 서버(1788)는 또 하나의 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 장치 또는 다른 공통 네트워크 노드일 수 있고, 통상적으로 컴퓨터(1742)와 관련하여 상술된 구성요소의 대부분 또는 그 전부를 포함한다. 도 17에 도시된 논리적 연결로는 LAN(1790) 및 WAN(1792)을 포함한다. 이러한 네트워킹 환경은 사무실, 회사 전체에 걸친 컴퓨터 네트워크, 인트라넷 및 인터넷에서 일반적인 것이다.

LAN 네트워킹 환경에서 사용될 때, 컴퓨터(1742)는 네트워크 인터페이스 또는 어댑터(1794)를 통해 로컬 네트워크에 접속된다. WAN 네트워킹 환경에서 사용될 때, 컴퓨터(1742)는 통상적으로 인터넷과 같은 WAN(1792) 상에서의 통신을 설정하기 위한 모뎀(1796) 또는 기타 수단을 포함한다. 내장형 또는 외장형일 수 있는 모뎀(1796)은 직렬 포트 인터페이스(1768)를 통해 버스(1748)에 접속된다. 네트워크화된 환경에서, 퍼스널 컴퓨터(1742) 또는 그의 일부와 관련하여 기술된 프로그램 모듈은 원격 메모리 저장 장치에 저장될 수 있다. 도시된 네트워크 접속은 예시적인 것이며 이 컴퓨터들 사이의 통신 링크를 설정하는 다른 수단이 사용될 수 있다는 것을 이해할 것이다.

일반적으로, 컴퓨터(1742)의 데이터 프로세서는 컴퓨터의 각종 컴퓨터 판독가능 저장 매체에 다른 시간에 저장된 명령어에 의해 프로그램된다. 프로그램 및 운영 체제는 통상적으로 예를 들어 플로피 디스크 또는 CD-ROM에 분산된다. 여기에서, 프로그램 및 운영 체제가 설치되거나 이것은 컴퓨터의 보조 메모리로 로딩된다. 실행 시, 프로그램 및 운영 체제는 적어도 부분적으로 컴퓨터의 주 전자 메모리로 로딩된다. 마이크로프로세서 또는 다른 데이터 프로세서와 함께 컴퓨터 판독가능 매체가 설명된 블록을 구현하는 명령어 또는 프로그램을 포함할 때, 본 명세서에서 설명된 시스템은 프로그램 및 운영체제 그리고 각종 다른 유형의 컴퓨터 판독가능 매체를 포함한다. 기술된 시스템은 또한 본 명세서에 설명된 방법 및 기술에 따라 프로그램될 때 컴퓨터 그 자체를 포함할 수 있다.

도시를 위해, 운영 체제와 같은 프로그램 및 기타 실행가능 프로그램 컴포넌트는 컴퓨터의 상이한 저장 컴포넌트에 다른 시간에 상주할 수 있고, 컴퓨터의 데이터 프로세서에 의해 실행될 수 있다는 것을 인식함에도 불구하고, 이러한 프로그램 및 컴포넌트는 본 명세서에 분리된 블록으로서 도시되었다.

결론

상술된 각종 실시예는 제3자 컴포넌트 기록기가 시스템에 쉽게 새 클래스를 삽입할 수 있도록 하는 플러그가능한 아키텍처를 제공한다. 다수의 데이터 제공자로부터 데이터를 검색할 수 있도록 하는 라우팅 시스템이 제공된다. 또한, 네임 레졸루션 파이프라인은 사람이 제공한 이름을 내부의 카노니컬 이름으로 해결한다. 또한, 각종 실시예는 클라이언트가 객체로부터 검색하고자 하는 데이터를 정확하게 명시하는 기능을 제공한다. 객체로부터 데이터를 검색하는 아주 효율적인 메커니즘은 최적화된 유형 맵을 사용한다. 일단 유형 맵이 구축되면, 추가의 문자열 비교 또는 검색이 수행될 필요가 없다. 임의의 데이터를 지원할 수 있는 단일 플러그가능한 인터페이스가 또한 제공된다. 이것은 셋업에 관해서라면, 단 하나의 유형의 설치가능한 객체만이 필요하다는 것을 의미한다. 다른 객체 유형은 집합을 통해 팩토리 객체로부터 획득될 수 있다. 이것은 예를 들어 파이프라인 구성요소를 구축하는 데에 사용될 수 있다.

또한, 시스템의 임의의 객체가 질의 및 (필터링된 통보를 포함하여) 통보를 쉽게 지원하고, 캐싱 및 작업 스케줄링을 쉽게 지원하도록 하는 서비스 세트가 제공된다.

설명된 실시예는 또한 터널링하는 기능 또는 액세스 어댑터를 통해 기본 유형 세트를 다룰 수 있는 임의의 프로토콜 또는 전송에 대해 터널링하는 기능을 제공할 수 있다. 각종 실시예는 또한 다운 레벨 프로토콜을 통해 전송되는 객체의 집합을 제공하고, 다운 레벨(및 업 레벨) 프로토콜이 동적으로 시스템에 추가되도록 하는 기능을 지원한다.

또한, 비동기 데이터 인터페이스가 제공된다. 이것은 중요한데, 그 이유는 많은 수의 IO 바운드 데이터 기록이 발생할 때마다 비동기 인터페이스가 서버를 초크하기(choke) 때문이다. 이것은 또한 UI 프로그래밍을 단순화하는데, 그 이유는 단일 UI 스레드가 실행될 수 있고 그것이 수행 중인 동작에 대해 지연시킬 수 없기 때문이다.

또한, 배칭 인터페이스는 객체 명령, gets, sets, 질의 및 통보 요청의 임의의 그룹핑을 허용한다. 이것은 배칭 인터페이스를 이용하여 클라이언트가 프린트 집합을 삭제하는 것과 같은 동작의 지원을 가능하게 하기 때문에 중요하다. 이것은 또한 배칭 인터페이스가 네트워크의 대기 시간이 감소되도록 하는 효과가 있기 때문에 이롭다. 예를 들어, UI가 특정 큐에 대해 많은 속성을 검색하기를 원할 때, UI는 데이터가 순차적으로 검색될 때 필요한 많은 네트워크 라운드 트립(round trip)보다는, 하나의 네트워크 라운드 트립으로 하나의 메시지에 모든 요청을 배치로 처리할 수 있다.

또한, 각종 실시예는 통보의 예외로, 거의 완전히 상태가 없는(stateless) 인터페이스를 제공할 수 있다.

또한, 프로그래밍 모델은 클라이언트 객체 집합을 활용함으로써 단순화된다. 일단 객체가 성공적인 배치 실행에 의해 파퓰레이트되면, 검색된 데이터의 모든 연이은 동작들은 성공이 보증되는데, 그 이유는 이 데이터들이 객체 상태에 저장되기 때문이다. 프로그래밍 모델은 또한 깔끔하게 통보 및 질의 클라이언트 의미론을 거의 동일하게 만든다.

또한, CDI는 이어지는 반복 또는 특정 집합에서 이하를 가능하게 한다. 먼저, CDI는 표준 유형 메타데이터 시스템을 통해 새로운 데이터 유형을 동적으로 발견하게 하는 기능을 가능하게 한다. 이것은 일반 디버깅 인터페이스 및 데이터 질의 인터페이스와 같은 특정 특징을 가능하게 한다. 두 번째로, 모든 집합이 동일한 인터페이스를 지니기 때문에, 집합들은 다른 프로세스 또는 애플리케이션 도메인에서 샌드박스화(sandbox)될 수 있다. 세 번째로, 모든 집합이 동일한 인터페이스를 지니기 때문에, CDI는 시스템이 임의의 집합을 유지 모드에 있도록 하고 호출 카운팅 심(call counting shim)을 구현함으로써 그것을 언로드할 수 있도록 한다. 이것은 그것이 기존의 컴포넌트를 업그레이드할 때 매우 유용하다. 네 번째로, 배치가 또한 트랜잭션이 되도록 함으로써 트랜잭션 지원을 아주 쉽게 추가할 수 있다. 마지막으로, 모든 객체가 동일한 인터페이스를 사용하기 때문에, 데코레이터(decorator)와 같은 패턴이 시스템에 쉽게 추가될 수 있다. 이것은 아주 유연한 방식으로 제3자에 의해 시스템이 확장되도록 하는 가능성을 제공한다.

본 발명이 구조적 특징 및/또는 방법론의 단계에 특징적인 언어로 설명되었지만, 첨부된 청구항을 정의하는 본 발명이 설명된 특징 또는 단계에 제한될 필요가 없다는 것을 이해할 것이다. 오히려, 특정 특징 및 단계는 청구된 발명을 구현하는 바람직한 형태로서 개시된다.

포괄적 데이터 모델, 비동기 클라이언트 및 서버 디스패치, 취소, 배칭, 트랜잭션 호출, 병렬 호출, 인터셉션 또는 반영 중 하나 이상의 기능을 제공할 수 있는 시스템 데이터 인터페이스 및 관련 아키텍처를 제공하는 효과가 있다.

Claims (20)

1. 실행될 때 소프트웨어 아키텍처를 제공하는 컴퓨터 판독가능 명령어를 포함하는 하나 이상의 컴퓨터 판독가능 매체에 있어서,

   상기 소프트웨어 아키텍처는,

   포괄적 데이터 모델(a generic data model)을 제공하도록 구성되는 인터페이스를 제공하고;

   클라이언트 또는 클라이언트 애플리케이션이 클라이언트 스레드로 제어를 즉시 반환하는 데이터 요청을 시작하는 것을 허용하는 비동기 클라이언트 패치를 제공하고;

   서버가 상기 클라이언트로부터의 요청을 비동기로 서비스할 수 있는 비동기 서버 디스패치를 제공하도록 구성되는 하나 이상의 컴퓨터 판독가능 매체.
2. 제1항에 있어서, 상기 소프트웨어 아키텍처는 상기 서버에서 진행 중인 호출이 언제든지 상기 클라이언트에 의해 취소될 수 있는 취소(cancellation)를 제공하도록 구성되는 하나 이상의 컴퓨터 판독가능 매체.
3. 제1항에 있어서, 상기 소프트웨어 아키텍처는 클라이언트가 임의의 액션 시퀀스를 구축할 수 있고 상기 액션을 하나의 단위로서 상기 서버로 전송할 수 있는 배칭(batching)을 제공하도록 구성되는 하나 이상의 컴퓨터 판독가능 매체.
4. 제1항에 있어서, 상기 소프트웨어 아키텍처는 액션 배치가 반드시 전체 실행되어야 하거나 또는 상기 서버의 상태를 변경해서는 안 되는 의미론(semantics)을 지정할 수 있는 트랜잭션 호출(transational invocation)을 제공하도록 구성되는 하나 이상의 컴퓨터 판독가능 매체.
5. 제1항에 있어서, 상기 소프트웨어 아키텍처는 액션 배치가 모든 항목들이 병렬로 실행될 수 있는 의미론을 지정할 수 있는 병렬 호출을 제공하도록 구성되는 하나 이상의 컴퓨터 판독가능 매체.
6. 제1항에 있어서, 상기 소프트웨어 아키텍처는, 관련 시스템을 모니터하는 것, 상기 시스템에 동기로 응답하는 것 또는 상기 시스템의 거동을 수정하는 것 중 하나 이상을 수행할 수 있는 컴포넌트를 상기 아키텍처 내에 삽입시킬 수 있는 인터셉션(interception)을 제공하도록 구성되는 하나 이상의 컴퓨터 판독가능 매체.
7. 제1항에 있어서, 상기 소프트웨어 아키텍처는 반영(reflection)을 제공하도록 구성되며, 상기 반영을 통해 소정 클래스의 객체에 의해 지원되는 속성(properties)이 검색될 수 있는 하나 이상의 컴퓨터 판독가능 매체.
8. 제1항에 있어서, 상기 소프트웨어 아키텍처는,

   클라이언트가 임의의 액션 시퀀스를 구축할 수 있고 상기 액션을 하나의 단위로서 상기 서버로 전송할 수 있는 배칭(batching); 및

   액션 배치가 반드시 전체 실행되어야 하거나 또는 상기 서버의 상태를 변경해서는 안 되는 의미론을 지정할 수 있는 트랜잭션 호출

   을 제공하도록 구성되는 하나 이상의 컴퓨터 판독가능 매체.
9. 제1항에 있어서, 상기 소프트웨어 아키텍처는,

   클라이언트가 임의의 액션 시퀀스를 구축할 수 있고 상기 액션을 하나의 단위로서 상기 서버로 전송할 수 있는 배칭; 및

   액션 배치가 모든 항목들이 병렬로 실행될 수 있는 의미론을 지정할 수 있는 병렬 호출

   을 제공하도록 구성되는 하나 이상의 컴퓨터 판독가능 매체.
10. 제1항에 있어서, 상기 소프트웨어 아키텍처는,

    클라이언트가 임의의 액션 시퀀스를 구축할 수 있고 상기 액션을 하나의 단위로서 상기 서버로 전송할 수 있는 배칭;

    액션 배치가 반드시 전체 실행되어야 하거나 또는 상기 서버의 상태를 변경해서는 안 되는 의미론을 지정할 수 있는 트랜잭션 호출; 및

    액션 배치가 모든 항목들이 병렬로 실행될 수 있는 의미론을 지정할 수 있는 병렬 호출

    을 제공하도록 구성되는 하나 이상의 컴퓨터 판독가능 매체.
11. 제1항에 있어서, 상기 소프트웨어 아키텍처는,

    클라이언트가 임의의 액션 시퀀스를 구축할 수 있고 상기 액션을 하나의 단위로서 상기 서버로 전송할 수 있는 배칭; 및

    관련 시스템을 모니터하는 것, 상기 시스템에 동기로 응답하는 것 또는 상기 시스템의 거동을 수정하는 것 중 하나 이상을 수행할 수 있는 컴포넌트를 상기 아키텍처 내에 삽입시킬 수 있는 인터셉션(interception)

    을 제공하도록 구성되는 하나 이상의 컴퓨터 판독가능 매체.
12. 제1항에 있어서, 상기 소프트웨어 아키텍처는,

    클라이언트가 임의의 액션 시퀀스를 구축할 수 있고 상기 액션을 하나의 단위로서 상기 서버로 전송할 수 있는 배칭; 및

    소정 클래스의 객체에 의해 지원되는 속성이 검색될 수 있는 반영

    을 제공하도록 구성되는 하나 이상의 컴퓨터 판독가능 매체.
13. 제1항에 있어서, 상기 소프트웨어 아키텍처는,

    클라이언트가 임의의 액션 시퀀스를 구축할 수 있고 상기 액션을 하나의 단위로서 상기 서버로 전송할 수 있는 배칭;

    소정 클래스의 객체에 의해 지원되는 속성이 검색될 수 있는 반영; 및

    관련 시스템을 모니터하는 것, 상기 시스템에 동기로 응답하는 것 또는 상기 시스템의 거동을 수정하는 것 중 하나 이상을 수행할 수 있는 컴포넌트를 상기 아키텍처 내에 삽입시킬 수 있는 인터셉션

    을 제공하도록 구성되는 하나 이상의 컴퓨터 판독가능 매체.
14. 실행될 때 소프트웨어 아키텍처를 제공하는 컴퓨터 판독가능 명령어를 포함하는 하나 이상의 컴퓨터 판독가능 매체에 있어서,

    상기 소프트웨어 아키텍처는 프린팅 시스템을 포함하고,

    상기 프린팅 시스템은,

    배칭 라우터에 인터페이스로서 기능하는 공통의 데이터 인터페이스 - 상기 공통의 데이터 인터페이스는 클라이언트로부터의 메시지가 구축될 수 있고 상기 배칭 라우터에 디스패치될(dispatch) 수 있도록 하고, 응답을 상기 클라이언트로 전송하도록 구성됨 -;

    상기 공통의 데이터 인터페이스와 통신에 관하여 링크되어 있고, 상기 공통의 데이터 인터페이스에 의해 전달되는 메시지를 수신하고 상기 메시지를 하나 이상의 집합에 비동기로 디스패치하도록 구성된 배칭 라우터;

    하나 이상의 집합에 대해 의도된 메시지를 수신하고 처리하도록 구성된 플러그인을 처리하는 메시지를 추적하도록 구성되는 플러그인 테이블; 및

    하나 이상의 객체를 목적으로 하는 메시지를 인터셉션하고 수정하는 데에 사용되도록 구성된 인터셉션 테이블

    을 포함하는 하나 이상의 컴퓨터 판독가능 매체.
15. 제14항에 있어서, 상기 메시지는 하나 이상의 플러그인용으로 예정된 하나 이상의 동작을 포함할 수 있는 하나 이상의 컴퓨터 판독가능 매체.
16. 제14항에 있어서, 상기 배칭 라우터와 통신에 관하여 연관되고, 상기 배칭 라우터로부터 메시지 세트를 수신하고, 적절한 경우, 다른 장치로 상기 메시지를 송신하도록 구성되는 메시지 플러그인을 더 포함하는 하나 이상의 컴퓨터 판독가능 매체.
17. 제14항에 있어서, 상기 배칭 라우터와 통신에 관하여 연관되고, 메시지들을 수신하여 상기 메시지들을 집합 인터페이스상의 호출 시퀀스로 분해하도록 구성되는 메시지 서비스를 더 포함하는 하나 이상의 컴퓨터 판독가능 매체.
18. 제14항에 있어서, 상기 배칭 라우터와 통신으로 연관되고, 메시지들을 수신하여 상기 메시지들을 집합 인터페이스에 관한 호출 시퀀스로 분류하도록 구성되는 메시지 서비스를 더 포함하고, 상기 메시지 서비스는 다음의 태스크 중 하나 이상을 수행하도록 구성되고,

    상기 다음의 태스크는,

    메시지를 스레드에 할당하는 것;

    메시지가 다수의 지연된 호출에 응답되도록 허용하는 것;

    메시지를 파퓰레이트하기 위해 집합의 객체로부터 적절한 데이터를 검색하는 것;

    취소 동작을 처리하는 것;

    객체 인스턴스를 캐시하는 것;

    객체를 투명하게 잠그는 것; 또는

    집합에서 유지되는 객체에 대해 반영 서비스를 수행하는 것

    인 하나 이상의 컴퓨터 판독가능 매체.
19. 제14항에 있어서, 하나 이상의 객체 집합을 더 포함하고, 개개의 집합은 동질 세트의 객체를 유지하는 하나 이상의 컴퓨터 판독가능 매체.
20. 제14항에 있어서, 하나 이상의 객체 집합을 더 포함하고, 개개의 집합은 동질 세트의 객체를 유지하고, 개개의 집합은 DLL로부터 검색되는 COM 인터페이스로서 구현되는 하나 이상의 컴퓨터 판독가능 매체.

Images