KR101176757B1

KR101176757B1 - 서비스 디스커버리 및 퍼블리케이션

Info

Publication number: KR101176757B1
Application number: KR1020117016088A
Authority: KR
Inventors: 앤드류 디. 밀리간; 찰스 알. 리베스; 제프리 비. 파햄; 고팰 크리스나 알. 카키바야; 로렌스 에이. 부에르크; 안젤라 밀스; 리차드 엘. 하샤
Original assignee: 마이크로소프트 코포레이션
Priority date: 2003-10-24
Filing date: 2004-07-21
Publication date: 2012-08-23
Also published as: WO2005045563A3; EP1676215A4; AU2004279194B2; MXPA05006611A; WO2005045563A2; AU2004279194A8; JP2007509406A; CA2782812C; CA2782812A1; RU2005115975A; JP5193280B2; EP1676215A2; CA2501718A1; RU2365973C2; KR20060130479A; CA2501718C; US20100217782A1; BRPI0406411A; CN1705947A; CN100481069C

Abstract

서비스 디스커버리 및 퍼블리케이션 방법 및 시스템이 개시된다. 애플리케이션 프로그램은 서비스 디스커버리, 퍼블리케이션 및 가입을 위한 요청을 서비스 디스커버리 애플리케이션 프로그래밍 인터페이스에 기록한다. 서비스 디스커버리 애플리케이션 프로그래밍 인터페이스는 상기 디스커버리, 퍼블리케이션 및/또는 가입 요청을 충족시키는 하나 이상의 로우 레벨 프로토콜을 호출한다. 로우 레벨 프로토콜로부터 검색된 서비스 정보는 일관된 데이터 모델로 포맷팅되어 클라이언트 애플리케이션에게 리턴된다. 또한, 서비스 정보는 서비스 디스커버리 API에 통신가능하게 접속된 디스커버리 퍼시스턴스 서비스에 의해 관리되는 영속적 데이터 저장소에 저장될 수 있다.

Description

서비스 디스커버리 및 퍼블리케이션{SERVICE DISCOVERY AND PUBLICATION}

본 발명은 디지털 컴퓨팅에 관한 것으로서, 특히 컴퓨팅 장치 및 컴퓨팅 네트워크에서의 서비스 디스커버리(발견: discovery)에 관한 것이다.

컴퓨팅 장치 및 컴퓨터 네트워크 상에서 실행되는 애플리케이션 프로그램들은, 컴퓨팅 장치 또는 네트워크에 접속된 다른 물리 또는 논리 장치에 의해 제공되는 서비스를 사용할 필요가 있을 수 있다. 현재, 애플리케이션 프로그램들은 광범위한 애플리케이션 프로그래밍 인터페이스(API: Application Programming Interface), 프로토콜 및 오브젝트 모델들을 사용하여, 로컬 컴퓨팅 장치 상에 또는 컴퓨터 네트워크 내의 복수의 장치들에 걸쳐 존재하는, 서비스들 및 장치들을 발견, 열거(enumerate) 및 기술한다. 서비스들 및 장치들을 발견, 열거 및 기술하는데 이용 가능한 메커니즘은, 관련된 서비스들 및 장치들이 개념적으로 동일한 경우에도 매우 상이하다.

예를 들어, 애플리케이션이 이용 가능한 프린터들을 열거하고자 하는 상황을 가정해 보자. 회사의 운영 환경에서 실행하는 경우, 애플리케이션은 LDAP(Lightweight Directory Access Protocol)를 사용하여, 등록된 회사 프린터를 발견하기 위하여 Microsoft Active Directory(등록상표)라는 디렉토리 서비스 스토어(store)와 통신하고, 프린트 큐 서버를 발견하기 위하여 NetBT와 통신하고, 개인 영역 네트워크 프린터를 발견하기 위하여 블루투스와 통신할 필요가 있을 수 있다. 또한, 애플리케이션은 직접 접속된 프린터를 발견하기 위하여 장치관리 API를 호출하고, UPnP 프린터를 발견하기 위하여 UPnP(상표) API를 호출해야 할 것이다. 이러한 메커니즘은 특정 API, 프로토콜 및 쿼리 시맨틱(Semantic)에 대한 이해를 필요로 한다.

애플리케이션이 서비스를 발견, 열거 및 기술하는데 필요한 API 및 프로토콜의 수는 소프트웨어 개발 작업을 어렵게 한다.

본 명세서에 기재 및 청구된 구현예들은, 디스커버리 및 퍼블리케이션 작업을 단순화한 유니폼(uniform) 인터페이스를 제공함으로써 전술한 및 그 밖의 문제점들을 해결하고자 하는 것이다. 유니폼 인터페이스는 기초(underlying) 프로토콜들의 작용은 허용하되, 애플리케이션 개발자들이 로우 레벨 프로토콜을 이해할 필요성을 제거한다. 유니폼 인터페이스는 광범위한 로우 레벨 API, 프로토콜, 스토어 및 네트워크 환경에 걸친, 서비스 상세(service details)의 디스커버리 및 퍼블리케이션을 목적으로 하는, 서비스 및 관련 동작들에 대한 일관된 하이 레벨 추상화를 제공한다.

일 실시예에 따르면, 컴퓨팅 환경에 이용 가능한 서비스의 디스커버리(discovery) 방법이 제공된다. 상기 방법은, 애플리케이션 프로그램에서, 디스커버리 범위(discovery scope)를 지정하는 단계; 디스커버리 필터를 지정하는 단계; 및 제1 애플리케이션 프로그래밍 인터페이스에 서치 요청(search request)을 발행하는 단계; 상기 제1 애플리케이션 프로그래밍 인터페이스에서, 상기 서치 요청을 파싱하는 단계; 상기 요청된 디스커버리 범위 및 디스커버리 필터에 대응하는 서비스 정보를 검색하는 단계; 및 상기 서비스 정보를 상기 애플리케이션 프로그램에게 리턴하는 단계를 포함한다.

일 실시예에 따르면, 컴퓨팅 환경에 이용 가능한 서비스의 퍼블리케이션(publication) 방법이 제공된다. 상기 방법은, 애플리케이션 프로그램에서, 서비스 엔트리 오브젝트를 지정하는 단계; 퍼블리케이션 범위를 지정하는 단계; 상기 서비스에 유니크 키(unique key)를 부여하는 단계; 서비스 타입을 부여하는 단계; 상기 서비스의 속성을 지정하는 단계; 상기 서비스의 엔드포인트(endpoints)를 지정하는 단계; 및 제1 애플리케이션 프로그래밍 인터페이스에 퍼블리케이션 요청을 발행하는 단계; 상기 제1 애플리케이션 프로그래밍 인터페이스에서, 상기 서치 요청을 파싱하는 단계; 및 상기 서비스를 퍼블리싱하기 위하여 적어도 하나의 로우 레벨 API 호출을 실행하는 단계를 포함한다.

일 실시예에 따르면, 컴퓨팅 환경에서 퍼블리싱된 서비스를 삭제하는 방법이 제공된다. 상기 방법은, 애플리케이션 프로그램에서, 서비스 엔트리 오브젝트를 지정하는 단계; 상기 퍼블리싱된 서비스에 대응하는 키를 지정하는 단계; 삭제 범위를 지정하는 단계; 및 제1 애플리케이션 프로그래밍 인터페이스에 삭제 요청을 발행하는 단계; 상기 제1 애플리케이션 프로그래밍 인터페이스에서, 상기 서치 요청을 파싱하는 단계; 및 상기 서비스를 삭제하기 위하여 적어도 하나의 로우 레벨 API 호출을 실행하는 단계를 포함한다.

일 실시예에 따르면, 컴퓨팅 환경에서 서비스 이벤트에 가입하는 방법이 제공된다. 상기 방법은, 애플리케이션 프로그램에서, 범위를 지정하는 단계; 필터를 지정하는 단계; 콜백(callback) 함수를 지정하는 단계; 및 제1 애플리케이션 프로그래밍 인터페이스에 가입 요청을 발행하는 단계; 상기 제1 애플리케이션 프로그래밍 인터페이스에서, 상기 서치 요청을 파싱하는 단계; 서비스 이벤트에 가입하기 위하여 적어도 하나의 로우 레벨 API 호출을 실행하는 단계; 및 서비스 이벤트로부터의 정보를 상기 애플리케이션 프로그램에게 리턴하는 단계를 포함한다.

일 실시예에 따르면, 컴퓨팅 환경에 이용 가능한 서비스에 관한 정보를 관리하는 시스템이 제공된다. 상기 시스템은, 애플리케이션으로부터 서비스 쿼리(query)를 받아 들이도록 구성된 제1 애플리케이션 프로그래밍 인터페이스 - 상기 제1 애플리케이션 프로그래밍 인터페이스는 제1 서비스 쿼리 프로토콜로 서비스 쿼리를 수신하며, 상기 서비스 쿼리를 처리하여 적어도 하나의 대응하는 서비스 쿼리를 제2 프로토콜로 론칭함 -; 상기 제1 애플리케이션 프로그래밍 인터페이스에 통신가능하도록 접속된 디스커버리 퍼시스턴스(persistence) 서비스 - 상기 디스커버리 퍼시스턴스 서비스는 상기 제1 애플리케이션 프로그래밍 인터페이스로부터 서비스 정보를 수신하며 상기 서비스 정보를 데이터 저장소에 저장함 -를 포함한다.

도 1은 예시적 컴퓨팅 장치를 개략적으로 설명하는 도면.
도 2는 예시적 소프트웨어 구조를 설명하는 블록도.
도 3은 서비스 디스커버리(discovery)를 위한 동작을 설명하는 흐름도.
도 4는 서비스 퍼블리케이션(publication)을 위한 동작을 설명하는 흐름도.
도 5는 서비스 삭제(deletion)를 위한 동작을 설명하는 흐름도.
도 6은 서비스 이벤트 가입(subscription)을 위한 동작을 설명하는 흐름도.
도 7은 구체 범위(concrete scope)와 추상 범위(abstract scope)의 관계를 설명하는 블록도.
도 8은 C# 프로그래밍 언어를 사용하여, 분당 50매를 인쇄할 수 있는 컬러 프린터를 액티브 디렉토리 프로토콜 상의 심플 필터 오브젝트를 이용하여 찾아내기 위한 방법을 설명하는 의사 코드(pseudo-code).
도 9는 C# 프로그래밍 언어를 사용하여, 웹 서비스를 찾아내기 위한 방법을 설명하는 의사 코드.
도 10은 C# 프로그래밍 언어를 사용하여, 특정 tModel 인터페이스를 지원하는 서비스를 심플 필터 오브젝트 및 UDDI 프로토콜을 이용하여 찾아내기 위한 방법을 나타낸 의사 코드.
도 11은 Visual Basic.NET를 사용하여, 특정 tModel 인터페이스를 지원하는 서비스를 심플 필터 오브젝트 및 UDDI 프로토콜을 이용하여 찾아내기 위한 방법을 나타낸 의사 코드.
도 12는 C# 프로그래밍 언어를 사용하여, Office Printer라는 명칭을 갖는 프린터를 액티브 디렉토리를 갖는 RichFilter를 이용하여 찾아내기 위한 방법을 나타낸 의사 코드.
도 13은 Visual Basic.NET를 사용하여, Office Printer라는 명칭을 갖는 프린터를 액티브 디렉토리를 갖는 RichFilter를 이용하여 찾아내기 위한 방법을 나타낸 의사 코드.
도 14는 C# 프로그래밍 언어를 사용하여, 특정 유니크 식별자에 의해 식별된 특정 타입의 서비스를 SSDP 프로토콜을 이용하여 퍼블리싱하기 위한 방법을 나타낸 의사 코드.
도 15는 Visual Basic.NET를 사용하여, 특정 유니크 식별자에 의해 식별된 특정 타입의 서비스를 SSDP 프로토콜을 이용하여 퍼블리싱하기 위한 방법을 나타낸 의사 코드.
도 16은 C# 프로그래밍 언어를 사용하여, SSDP 프로토콜로부터 서비스를 삭제하기 위한 방법을 나타낸 의사 코드.
도 17은 Visual Basic.NET를 사용하여, SSDP 프로토콜로부터 서비스를 삭제하기 위한 방법을 나타낸 의사 코드.
도 18은 C# 프로그래밍 언어를 사용하여, SSDP 프로토콜을 사용하는 특정 타입의 이벤트를 심플 필터를 이용하여 등록하는 방법을 설명하는 의사 코드이며, 여기서 등록된 콜백 함수는 필터에 매칭된 모든 이벤트마다 호출(invoke)되며 대응하는 서비스 엔트리 오브젝트가 핸들러(handler)에게 제공됨.
도 19는 Visual Basic.NET를 사용하여, SSDP 프로토콜을 사용하는 특정 타입의 이벤트를 심플 필터를 이용하여 등록하는 방법을 설명하는 의사 코드.

실시예

본 명세서에 개시된 방법 및 소프트웨어 구조는 서비스 디스커버리 및 퍼블리케이션을 위한 방법 및 소프트웨어 구조의 일례이다. 본 명세서에 개시된 방법은 컴퓨터 판독가능 매체 상의 로직 명령문으로서 구현될 수 있다. 프로세서에서 실행된 경우 상기 로직 명령문이 범용 컴퓨팅 장치가 개시된 방법을 구현하는 전용 머신으로서 프로그램되도록 한다. 상기 프로세서는 로직 명령문에 의해 본 명세서에 기술된 방법을 실행하도록 구성된 경우 기재된 방법을 수행하기 위한 구조를 갖는다.

오퍼레이팅 환경의 일례

도 1은 기술된 실시예에 따른 하나 이상의 컴퓨팅 장치들을 구현하는데 사용될 수 있는 예시적 컴퓨팅 장치(130)를 개략적으로 설명하는 도면이다. 컴퓨팅 장치(130)는 기술된 실시예들에 따른 각종 구현예들을 구현하는데 사용될 수 있다.

컴퓨팅 장치(130)는 하나 이상의 프로세서 또는 프로세싱 유닛(132), 시스템 메모리(134), 및 시스템 메모리(134)를 포함한 각종 시스템 컴포넌트들을 프로세서(132)에 결합시키는 버스(136)를 포함한다. 버스(136)는 메모리 버스 또는 메모리 컨트롤러, 주변 버스, 가속 그래픽 포트 및 임의의 버스 구조를 이용한 프로세서 또는 로컬 버스를 포함하는 하나 이상의 임의의 타입의 버스 구조를 나타낸다. 시스템 메모리(134)는 ROM(138) 및 RAM(140)을 포함한다. 기동 시와 같이 컴퓨팅 장치(130) 내의 엘리먼트들 사이의 정보 교환을 도와주는 기본 루틴을 포함하고 있는 BIOS(142)는 ROM(138)에 저장되어 있다.

컴퓨팅 장치(130)는 하드디스크(미도시)에의 판독 및 기록을 위한 하드디스크 드라이브(144), 착탈식 자기디스크(148)에의 판독 및 기록을 위한 자기디스크 드라이브(146) 및 CD ROM 또는 광학매체와 같은 착탈식 광디스크(152)에의 판독 및 기록을 위한 광디스크 드라이브(150)를 더 포함한다. 하드디스크 드라이브(144), 자기디스크 드라이브(146) 및 광디스크 드라이브(150)는 SCSI 인터페이스 또는 기타 적절한 인터페이스에 의해 버스(136)에 접속되어 있다. 드라이브 및 이들의 관련 컴퓨터 판독가능 매체는 컴퓨팅 장치(130)용의 컴퓨터 판독가능 명령문, 데이터 구조, 프로그램 모듈 및 기타 데이터에 대한 불활성 스토리지를 제공한다. 본 명세서에 기술된 예시적 환경에서는 하드디스크, 착탈식 자기디스크(148) 및 착탈식 광디스크(152)를 채용하고 있지만, 본 기술분야의 전문가라면 컴퓨터에 의한 액세스가 가능한 데이터를 저장할 수 있는, 자기 카셋트, 플래시 메모리 카드, 디지털 비디어 디스크, RAM, ROM 등 다른 타입의 컴퓨터 판독가능 매체가 예시적 오퍼레이팅 환경에 사용될 수도 있음을 인식할 것이다.

오퍼레이팅 시스템(158), 하나 이상의 애플리케이션 프로그램(160), 기타 프로그램 모듈(162) 및 프로그램 데이터(164)를 포함한 다수의 프로그램 모듈이 하드디스크, 자기디스크(148), 광디스크(152), ROM(138) 또는 RAM(140)에 저장될 수 있다. 사용자는 키보드(166) 및 포인팅 디바이스(168)와 같은 입력 장치를 통해 컴퓨팅 장치(130)에 명령 및 정보를 입력할 수 있다. 다른 입력 장치(미도시)의 예로는 마이크, 조이스틱, 게임패드, 위성수신기, 스캐너 등을 포함한다. 이들 및 다른 입력 장치는 버스(136)에 결합되어 있는 인터페이스(170)를 통해 프로세싱 유닛(132)에 접속되어 있다. 비디오 어댑터(174)와 같은 인터페이스를 통해 모니터(172) 또는 다른 타입의 디스플레이 장치가 버스(136)에 접속되어 있다. 모니터 외에도, 퍼스널 컴퓨터는 일반적으로 스피커 및 프린터와 같은 다른 주변 출력 장치(미도시)를 포함한다.

컴퓨팅 장치(130)는 보통 원격 컴퓨터(176)와 같은 하나 이상의 원격 컴퓨터에의 논리 접속을 이용하는 네트워크 환경에서 동작한다. 원격 컴퓨터(176)는 또 다른 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 장치 또는 기타의 공통 네트워크 노드일 수 있으며, 도 1에서는 메모리 저장 장치(178)만을 예시하고 있지만, 일반적으로 컴퓨팅 장치(130)와 관련하여 전술한 모든 또는 대부분의 엘리먼트를 포함한다. 도 1에 도시된 논리 접속의 예로는 LAN(180) 및 WAN(182)을 포함한다. 이러한 네트워킹 환경은 사무실, 엔터프라이즈(enterprise) 컴퓨터 네트워크, 인트라넷 및 인터넷에서 일반적인 것이다.

LAN 네트워킹 환경에서 사용된 경우, 컴퓨팅 장치(130)는 네트워크 인터페이스 또는 어댑터(184)를 통해 로컬 네트워크(180)에 접속된다. WAN 네트워크 환경에서 사용된 경우, 컴퓨팅 장치(130)는 일반적으로 인터넷 등의 WAN(182)을 통해 통신을 확립하기 위한 모뎀(186) 또는 기타 수단을 포함한다. 모뎀(186)은 내장형 또는 외장형일 수 있으며, 시리얼 포트 인터페이스(156)을 통해 버스(136)에 접속된다. 네트워크 환경에서, 컴퓨팅 장치(130)와 관련하여 도시된 프로그램 모듈 또는 그 일부분은 원격 메모리 저장 장치에 저장될 수도 있다. 여기서 주목할 점은, 도시된 네트워크 환경은 예시를 위한 것이며 컴퓨터들 사이에 통신 링크를 확립하기 위한 다른 수단이 사용될 수도 있다는 것이다.

일반적으로, 컴퓨팅 장치(130)의 데이터 프로세서들은 컴퓨터의 각종 컴퓨터 판독가능 저장매체에 서로 다른 때에 저장된 명령문에 의해 프로그램된다. 프로그램 및 오퍼레이팅 시스템은 일반적으로 예를 들어 FD(floppy disk) 또는 CD-ROM에 분산되어 있다. 프로그램 및 오퍼레이팅 시스템은 FD 또는 CD-ROM으로부터 적어도 부분적으로 컴퓨터의 메인(primary) 전자 메모리에 로딩된다. 실행 시, 이들은 컴퓨터의 보조(secondary) 메모리에 인스톨 또는 로딩된다. 본 발명은 마이크로프로세서 또는 기타 데이터 프로세서와 연계하여 후술하는 각 단계들을 구현하기 위한 명령문 또는 프로그램을 포함하는 전술한 및 기타의 각종 타입의 컴퓨터 판독가능 저장매체를 포함한다. 본 발명은 또한 후술하는 방법 및 기술에 따라 프로그램된 컴퓨터 장체도 포함한다.

예시적 소프트웨어 구조의 개요

도 2는 도 1의 시스템 메모리(134)에 존재하는 서비스 디렉토리를 위한 예시적 소프트웨어 구조(200)의 블록도이다. 본 구현예에서는 시스템 메모리(134)가 복수의 애플리케이션 프로그램(210)을 포함한다. 네트워크 환경에서 애플리케이션 프로그램은 클라이언트 프로그램으로서 기능하며 PC 환경에서는 자립형(stand-alone) 프로그램으로서 실행될 수 있다. 애플리케이션 프로그램의 특정 성격은 중요하지 않다.

애플리케이션 프로그램(210)은 컴퓨팅 환경에 이용 가능한 서비스를 발견하기 위하여 서비스 디렉토리 API(214)를 호출한다. 서비스 디렉토리 API(214)는 디스커버리 쿼리를 표현하기 위한 하이 레벨 문법을 제공한다. 이 문법은 디스커버리 쿼리를 표현하기 위해 사용되는 자연 쿼리 언어(natural query language)인 OPath로 구현될 수 있다. 이 하이 레벨 문법은 기초 프로토콜이 필요로 하는 보다 구체적(granular)이고 프로토콜-특정 표현을 요구하는 대신에, 소프트웨어 개발자가 찾고자 하는 서비스를 표현하기 위한 보다 개념적인 메커니즘을 소프트웨어 개발자에게 제공한다. 개발자는 이 하이 레벨 문법을 이용하여 쿼리를 구축한 다음 특정 세트의 프로토콜(다수의 "구체 범위"라 함)에 포워딩하거나 미리 정해진 또는 설정된 구체 범위 세트인 "추상 범위"를 사용하게 된다. 상기 시스템은 서비스 디렉토리를 지원하는 것 외에도 서비스 퍼블리케이션/삭제 및 이벤트의 모니터링을 지원한다.

그러면, 서비스 디렉토리 API(214)는 도면에서 프로토콜1(220) 내지 프로토콜8(234)로 나타낸 하나 이상의 기초 프로토콜을 호출한다. 기초 프로토콜의 특정 갯수는 중요하지 않다. 프로토콜(220-234) 중 일부는 예를 들어 LDAP, UDDI(Universal Description, Discovery and Integration), DNS(Domain Name System) 서버와 같은 디렉토리-지원(backed) 프로토콜일 수 있다. 다른 프로토콜은 예를 들어 Bluetooth, UPnP 및 NetBT와 같은 특정 프로토콜일 수 있다. 하나 이상의 기초 프로토콜(220-234)은 컴퓨팅 환경에 이용 가능한 다른 컴포넌트나 서비스와 통신하기 위하여 통신 접속부(236)를 이용한다.

서비스 디스커버리 API는 디스커버리 요청에 대한 응답으로서 로컬 머신 또는 네트워크 상에서 발견된 매칭 서비스를 나타내는 서비스 엔트리 오브젝트의 컬렉션을 리턴한다. 서비스 엔트리 오브젝트는 시스템이 지원하는 기초 프로토콜에 의해 리턴된 관련 상세의 대부분을 표현할 수 있는 일반화된 데이터 구조이다. 각 서비스 엔트리 오브젝트는 서비스의 단일 인스턴스에 대응한다. 일 구현예에서, 서비스 엔트리 오브젝트는 (1) 서비스 명칭; (2) 서비스 설명; (3) 해당 서비스의 네트워크 어드레스를 일반적으로 포함하는 엔드포인트; (4) 서비스 인스턴스를 식별하는 키; (5) 예를 들어 서비스 또는 장치 특징에 대한 명칭-값 페어의 확장가능 리스트와 같은 속성; 및 (6) 예를 들어 해당 서비스를 제공하는 엔티티를 식별하는 식별자와 같은 제공자를 포함하는 설명 및 식별 속성을 제공한다.

디스커버리 퍼시스턴스 서비스(212)는 서비스 디스커버리 API(214)와 통신한다. 다른 것들도 있지만, 디스커버리 퍼시스턴스 서비스(212)는 특정 프로토콜을 통한 어나운스먼트(announcement) 이벤트를 등록한다. 어나운스먼트 이벤트가 검지된 경우 디스커버리 퍼시스턴스 서비스는 통지를 받으며 디스커버리 퍼시스턴스 서비스는 이 서비스 어나운스먼트에 관한 정보를 데이터 저장소(240) 내의 메모리 장소에 복사한다. 서비스 상세를 메모리 장소에 저장해 둠으로써 현재 이용 가능하지 않은 서비스를 발견할 수 있다. 예를 들어, 현재 프린터의 전원이 오프된 상태에 있는 경우에도 프린터에 관한 상세는 메모리 장소에 등록되어 있으므로 발견될 수 있다. 또한, 서비스 쿼리는 서비스와 통신하고 있는 프로토콜에만 국한되지 않는다. 또한, 메모리 장소에 대해 쿼리를 수행하는 경우 브로드 네트워크 디스커버리 쿼리를 발행한 경우에 비해 훨씬 성능이 우수할 것이다.

예시적 동작

예시적 구현예에서, 서비스 디스커버리 API(214)는 서비스 디스커버리, 서비스 퍼블리케이션 및 서비스 이벤트 통지에 대한 가입을 위한 방법을 제공한다. 도 3은 서비스 디스커버리를 위한 동작(300)을 설명하는 흐름도이다. 단계 310에서 애플리케이션은 범위를 지정하고, 단계 315에서 애플리케이션은 필터를 지정하고, 단계 320에서 애플리케이션은 서치 요청을 발행한다. 서비스 디스커버리 API(214)는 서치 요청을 수신하면, 단계 325에서 서치 요청을 파싱한다. 선택적 단계 330에서 서비스 디스커버리 API(214)는 디스커버리 퍼시스턴스 서비스(212)에 저장되어 있는 정보를 이용하여 서치 요청을 분해할 수 있는지의 여부를 판정한다. 일 구현예에서, 디스커버리 퍼시스턴스 서비스(212)에 의해 관리되는 정보는 디스커버리 퍼시스턴스 서비스(212) 내의 정보의 수명을 상세 지정하는 수명 표시자를 포함한다. 컨트롤 및 설정에 따라서, 서비스 디스커버리 API(214)는 디스커버리 퍼시스턴스 서비스(212)에 쿼리하여 디스커버리 퍼시스턴스 서비스(212)가 데이터 저장소(240)에 관리하고 있는 정보를 이용하여 디스커버리 요청을 충족시킬 수 있는지의 여부를 판정할 수 있다. 디스커버리 퍼시스턴스 서비스(212)를 이용하여 디스커버리 요청을 분해할 수 있다면, 단계 350으로 진행하여 디스커버리 퍼시스턴스 서비스(212)로부터 검색된 서비스 엔트리 오브젝트를 애플리케이션에게 리턴한다.

이와 비교하여, 디스커버리 퍼시스턴스 서비스(212)에 의해 관리되고 있는 정보를 이용하여 디스커버리 요청이 분해되지 않거나 분해할 수 없는 경우에는, 단계 335로 진행하여 서비스 디스커버리 API(214)가 디스커버리 요청을 완수하는데 필요한 로우 레벨 API 호출(call)을 실행한다. 단계 340에서 로우 레벨 API로부터 리턴된 서비스 정보는 서비스 엔트리 오브젝트로 포맷되며, 선택적 단계 345에서 서비스 엔트리 오브젝트가 디스커버리 퍼시스턴스 서비스에 포워딩되며, 디스커버리 퍼시스턴스 서비스는 서비스 엔트리 오브젝트를 데이터 저장소(240)에 저장한다. 선택적 단계 347에서 중복 검지 및 삭제와 같은 서비스 엔트리 결과에 대한 추가 프로세싱 및 필터링이 수행될 수 있다. 단계 350에서 서비스 엔트리 오브젝트는 단계 355에서의 추가 프로세싱을 위해 애플리케이션에 리턴된다. 애플리케이션에 의해 수행되는 추가 프로세싱의 특정 상세는 중요하지 않다.

도 4는 서비스 퍼블리케이션을 위한 동작을 설명하는 흐름도이다. 단계 410에서 애플리케이션은 서비스 퍼블리케이션을 위한 서비스 엔트리 오브젝트를 지정한다. 단계 415에서 애플리케이션은 서비스 퍼블리케이션을 위한 범위를 지정한다. 단계 420에서 애플리케이션은 서비스 퍼블리케이션에 유니크 키를 부여하고, 단계 425에서 애플리케이션은 서비스 퍼블리케이션에 서비스 타입을 부여한다. 단계 430에서 애플리케이션은 서비스 퍼블리케이션의 엔드포인트를 지정하고, 단계 432에서 애플리케이션은 서비스 퍼블리케이션의 속성을 지정하고, 단계 435에서 애플리케이션은 퍼블리케이션 요청을 생성한다. 수행되는 각 단계들은 퍼블리싱될 정보의 상세 및 사용될 로우 레벨 API에 따라서 변할 수 있다.

서비스 디스커버리 API(214)는 퍼블리케이션 요청을 수신하면 단계 440에서 퍼블리케이션 요청을 파싱한다. 단계 450에서 서비스 디스커버리 API(214)는 서비스 퍼블리케이션 요청을 실행하기 위하여 로우 레벨 API 호출을 실행한다. 선택적 단계 455에서 서비스 퍼블리케이션은 디스커버리 퍼시스턴스 서비스(212)에 저장된다.

서비스 디스커버리 API(214)의 서비스 퍼블리케이션 수단(facilities)은 퍼블리싱된 서비스를 삭제하는 데에도 이용될 수 있다. 도 5는 서비스 삭제를 위한 동작을 설명하는 흐름도이다. 단계 510에서 애플리케이션은 서비스 퍼블리케이션을 위한 서비스 엔트리 오브젝트를 지정한다. 단계 515에서 애플리케이션은 서비스에 대한 유니크 키를 상세 지정한다. 단계 520에서 애플리케이션은 서비스 삭제를 위한 범위를 지정한다. 단계 530에서 애플리케이션은 서비스 삭제 요청을 생성한다.

서비스 디스커버리 API(214)는 삭제 요청을 수신하면 단계 540에서 삭제 요청을 파싱한다. 단계 550에서 서비스 디스커버리 API(214)는 서비스 삭제 요청을 실행하기 위하여 로우 레벨 API를 실행한다. 단계 555에서 디스커버리 퍼시스턴스 서비스(212)로부터 서비스 퍼블리케이션이 삭제된다.

서비스 디스커버리 API(214)는 새로운 서비스 또는 특정 타입의 디바이스의 도착(arrival) 또는 출발(departure)과 같은 서비스 이벤트를 애플리케이션이 통지받을 수 있도록 하는데 이용될 수도 있다. 도 6은 서비스 이벤트에의 가입을 위한 동작(600)을 설명하는 흐름도이다. 단계 610에서 애플리케이션은 모니터할 특정 로우 레벨 프로토콜을 상세 지정하는 범위를 지정한다. 단계 615에서 애플리케이션은 이벤트 타입을 상세 지정하는 필터를 지정한다. 단계 620에서 애플리케이션은 매칭 이벤트가 발생할 때마다 서비스 엔트리의 상세를 수신하게 될 콜백(callback) 함수를 지정한다. 단계 625에서 애플리케이션은 가입 요청을 생성하며, 이는 서비스 디스커버리 API(214)에게 포워딩된다.

서비스 디스커버리 API(214)는 가입 요청을 수신하면 단계 630에서 가입 요청을 파싱한다. 단계 635에서 서비스 디스커버리 요청은 가입 서비스를 구현하는데 필요한 로우 레벨 프로토콜 호출을 실행한다. 서비스 이벤트가 발생되면, 로우 레벨 프로토콜은 이벤트의 통지를 서비스 디스커버리 API에게 제공한다. 단계 640에서 이벤트 통지는 서비스 엔트리 오브젝트에 포맷된다. 선택적 단계 645에서 서비스 엔트리 오브젝트는 디스커버리 퍼시스턴스 서비스(212)에 저장되며, 단계 650에서 서비스 엔트리 오브젝트는 이전에 상세 지정된 콜백 함수를 이용하여 애플리케이션에 리턴된다. 단계 655에서 애플리케이션은 서비스 엔트리 오브젝트에 추가의 프로세싱을 수행한다. 애플리케이션에 의해 수행되는 추가 프로세싱의 특정 상세는 중요하지 않다.

이하, 시스템 컴포넌트 및 동작에 대해서 상세히 설명한다.

API 클래스

필터

필터는 서비스 설명이 평가되는 일련의 규칙으로서 참(즉, 서비스 설명이 필터에 매칭됨)과 거짓(즉, 서비스 설명이 필터에 매칭되지 않음)의 결과를 갖는다. 필터는 특정 속성을 상세 지정하는 심플(simple) 필터나 보다 표현적인(expressive) 문법을 사용한 리치(rich) 필터로서 표현될 수 있다. 심플 필터로 표현되든 리치 필터로 표현되든, 쿼리는 기초 프로토콜의 성능에 종속하여 변경없이 하나 이상의 프로토콜을 통해 상세 지정되고 실행될 수 있다. 서비스 디스커버리 요청(214)은 보다 하이 레벨의 쿼리를 기초의 로우 레벨 프로토콜을 위한 올바른 포맷으로 재표현하는 것을 관리한다. 예를 들어, 서비스 디스커버리 요청 API(214)는 특정 서비스 타입의 쿼리를 수신하고, 액티브 디렉토리를 위한 LDAP 및 UDDI 웹 서비스 레지스트리를 위한 UDDI 프로토콜을 이용하여 이를 표현하고 평가할 수 있다. 애플리케이션 개발자는 개별 프로토콜에 대해 직접 작업할 필요가 없다.

예시적 구현예에서, 서비스 디스커버리 요청 API(214)는 제공된 평가기준에 대한 정확한 매칭 시맨틱을 제공하는 심플 필터와 OPath 문법으로 표현된 쿼리를 포함하는 리치 필터를 지원하기 위한 디스커버리 모듈을 필요로 한다. 여기서, 각각이 추가의 "네이티브" 필터 타입을 지원할 수도 있다는 것을 이해해야 한다. 서로 다른 디스커버리 모듈들은 프로토콜-특정 네이티브 필터 타입을 가질 수 있으며, 예를 들어 UPnP는 XPath 필터를 사용하고, 액티브 디렉토리는 기본적으로 LDAP 필터를 사용하고, UDDI는 기본적으로 UDDI 필터를 사용한다.

상기 모듈들에 대해 기능적으로 걸쳐 있는 OPath 필터의 베이스 레벨은 또한 기초 디스커버리 프로토콜들로부터 애플리케이션을 격리시킨다. 필터 클래스는 상기 모듈들에 걸쳐 공유되는 방식으로 필터를 파싱하고 해석하는 추가의 방법을 제공한다.

심플 필터는 서비스 타입, 서비스 인터페이스 및/또는 속성을 상세 지정함으로써 쿼리에 대한 표현을 제공한다. 이들 셋팅의 임의의 조합은 서치 쿼리에 제공될 수 있으며, 평가기준의 모든 것이 정확하게 매칭된다면, 그 결과의 서비스 엔트리 컬렉션에 서비스가 포함될 것이다.

서비스 타입은 서비스 엔티티들이 반드시 매칭되어야 하는 타입을 상세 지정하는 스트링으로서 구현된다. 커먼 서비스 타입 세트는 서비스 디스커버리 요청 API(214)에 미리 정해져 있다. 이 세트는 저장소 및 프로토콜들 내의 키 엔티티로서 확장되어 식별될 수 있다. 예를 들어, 액티브 디렉토리 내의 프린터에 대해서, filter.ServiceType=CommonServiceTypes.Printer와 같이 상세 지정할 것이다.

서비스 인터페이스는 서비스가 반드시 매칭되어야 하는 인터페이스의 식별자를 상세 지정하는 스트링 컬렉션으로서 구현된다. 일례로서, UDDI 내의 웹 서비스에 대해서, 하기의 tModel 식별자는 filter.ServiceInterfaces.Add ("uuid:ac104dcc-d623-452f-88a7-f8acd94d9b2b"); filter.ServiceInterfaces.Add ("uuid:4d2ac1ca-e234-142f-e217-4d9b2f8acd9b")와 같이 상세 지정된다.

속성은 서비스가 반드시 매칭되어야 하는 서비스 특징을 상세 지정하는 속성 사전으로 구현된다. 일례로서, 액티브 디렉토리 내의 프린터에 대해서, 하기의 속성은 filter.Properties.Add("printcolor","TRUE"); filter.Properties.Add ("pagesperminute","50")와 같이 상세 지정된다.

리치 필터는 예를 들어 OPath 문법을 이용하여, 쿼리 스트링 속성을 설정함으로써 보다 풍부한 쿼리 시맨틱을 표현하기 위한 메커니즘을 제공한다. 일례로서, UDDI 내의 웹 서비스에 대해서, 쿼리 스트링은 필요한 명칭과 필요한 지원 인터페이스를, filter.Query="WebService[name='fabrikam' and ServiceInterface ='uuid:ac104dcc-d623-452f-88a7-f8acd94d9b2b']"와 같이 상세 지정할 것이다.

A4 용지의 이용이 가능하지 않고 분당 25매 이상 인쇄할 수 있는, 액티브 디렉토리 내의 프린터를 찾기 위한 보다 표현적인 예는 다음과 같다: filter.Query="Printer[prinPagesPerMinute>20+5 and not(printmediaReady='A4' )]".

기초 프로토콜 및 저장소의 성능은, 기본 NetBT로부터 리치 액티브 디렉토리 쿼리 시맨틱에 걸쳐, 이상적인 것과는 거리가 멀기 때문에, 보다 표현적인 OPath 구조를 이용하는 능력은 선택된 범위(프로토콜)에 따를 것이다.

범위

범위는 네트워크 장소 또는 관리 경계에 의해 서치 가능한 통상적으로 성긴 쿼리 도메인을 식별한다. 디스커버리 쿼리는 하나 이상의 범위를 대상으로 하며, 쿼리 결과는 이들 범위 내의 서비스들의 서브세트를 포함하는 것으로, 즉 쿼리 결과는 주어진 필터에 매칭되는 범위 내의 모든 서비스들의 서브세트이다. 범위의 예로는 워크그룹, 로컬머신 및 도메인을 들 수 있다.

서비스 디스커버리 API(214)는 구체 범위와 추상 범위를 제공한다. 구체 범위는 쿼리 도메인을 3개로 상세 지정한다. 프로토콜 식별자는 ConcreteScope.NetBtProtocol 또는 ConcreteScope.ADProtocol과 같은 단일 디스커버리 모듈을 매핑하는 특정 프로토콜을 식별하며; 어드레스 식별자(옵션임)는 인트라넷 UDDI 서버에서의 "http://intra-uddi/uddi/inquire.asmx"와 같은 이 범위에서의 다이렉트 동작을 수행할 서버를 상세 지정하며; 경로 식별자(옵션임)는 "CN=joe-dev,CN=Computers,DC=corp,DC=fabrikam,DC=com"와 같이 설정되는 LDAP 서치 베이스 또는 UPnPv2 범위 명칭과 같은 모듈의 네임스페이스의 파티션을 식별한다.

서비스 디스커버리 요청 API(214)는 구체 범위를 모듈에 전달한다. 서비스 디스커버리 요청 API(214)는 예를 들어 구체 범위를 유선을 통해 제2 머신에 전송하고 구체 범위를 제2 머신 상의 대응 API에 전달하는 것과 같은 구체 범위에 대한 추가의 인다이렉션(indirection)을 모듈들이 수행하는 것을 배제하지 않는다.

추상 범위는 하나 이상의 구체 범위 및 (가능한 경우) 추가의 추상 범위에 대한 모니터이다. 추상 범위는 논리적으로 미리 정해진 또는 설정된 구체 범위 컬렉션에 대한 쿼리를 타겟팅(targeting)하는 메커니즘을 제공한다. 이것은 개발자로 하여금, 예를 들어 명시적인 프로토콜, 어드레스 및 특정 디렉토리 서비스를 위한 접속 상세를 필요로 하지 않고 "엔터프라이즈" 범위를 타겟팅할 수 있도록 하는 추가의 추상화를 제공한다.

추상 범위의 구체 범위로의 매핑은 머신 전체적인 것이며 설정이 가능하다. 예를 들어, 추상 범위 AbstractScope.Enterprise는 표 1의 구체 범위의 양방을 포함하도록 매핑할 것이다.

도 7은 구체 범위와 추상 범위 사이의 관계의 일례를 설명하는 블록도이다. 구체 범위(730-750)는 쿼리들이 평가되게 될 도메인에 대한 상세 지정을 제공한다. 구체 범위(730-750)는 프로토콜 식별 상세 및 필요에 따라 이용할 저장소 또는 서버의 세부(specific)를 그 저장소 또는 서버에 대한 추가 범위지정(scoping)의 가능성(potential)과 함께 구비한다. 서비스 디스커버리 API(214) 내에서 이들은 프로토콜, 어드레스 및 경로 속성에 각각 상세 지정된다.

추상 범위(710-725)는 구체 범위에 대한 그 상위의 보다 높은 레벨의 계층적 추상화를 제공한다. 추상 범위는 자신을 구성하는 구체 또는 추상 범위를 포함하도록 설정된다. 이러한 범위 매핑은 예를 들어 AbstractScope.EnterpriseScope를 어떻게 분해할 것인지를 정확하게 설정할 수 있는 시스템 관리자들이 이용할 수 있다.

구체 범위 및 추상 범위는 모두 서비스 디스커버리 API(214)의 사용자에 의해 이용될 수 있다. 추상 범위가 제공된 경우, 서비스 디스커버리 API(214)는 계층 구조를 따라서 이를 다수의 구체 범위로 분해할 것이다.

추상 범위는 애플리케이션 프로그램(210)의 개발자로 하여금 비교적 하이 레벨에서 작업하여, "AbstractScope.Enterprise"와 같은 범위 식별 용어를 코드에 포함시킬 수 있도록 한다. 이러한 방식으로, 예를 들어 개발자는 특정 UDDI 서버의 세부를 자신의 코드에 하드코딩(hardcode)할 필요가 없게 된다. 이러한 추상화는 코드에 대한 보다 높은 재사용성 및 휴대성을 제공한다. 동일한 코드를 각종 엔터프라이즈 환경에서 변경 또는 재컴파일없이 사용할 수 있다. 추상 범위의 설정만 환경에 따라 변화할 뿐이다.

구체 범위로의 추상 범위 매핑에는 다수의 계층구조가 존재한다. 도 7에서 AbstractScope.LocalMachine은 그것의 모든 구성요소가 포함되더라도 AbstractScope.All로 매핑되지 않는다.

예시적 구현예에서 범위 매핑 설정은 그룹 폴리시에 따라 시스템 관리자가 엔터프라이즈에서 서비스 디스커버리 API(214)의 이용을 제어함으로써 조정될 수 있다. 예를 들어, 관리자는 엔터프라이즈 컴퓨팅 환경 도는 그 일부분에서 이용 가능한 하나 이상의 추상 범위를 지정할 수 있다. 이것은 시스템 관리자로 하여금 애플리케이션에 의한 리소스의 이용 및 디스커버리를 통제할 수 있도록 한다.

서비스 엔트리 결과

애플리케이션 개발자는 서비스 파인더 오브젝트에서 속성으로서 설정되게 될 적절한 범위 및 필터 표현을 선택할 수 있다. 그러면, 애플리케이션은 FindOne 또는 FindAll 방법을 이용하여 디스커버리 요청을 실행할 수 있다. FindAll 방법은 주어진 평가기준에 매칭되는 모든 서비스를 리턴하는 반면, FindOne 방법은 단일 매칭 서비스를 리턴한다. 이들 방법은 동시적 또는 비동시적 호출 패턴(asynchronous calling pattern)을 이용하여 실행될 수도 있다.

상세 지정된 범위 내에 제공된 필터에 매칭되는 서비스가 존재한다고 가정하면, FindOne 또는 FindAll 방법은 하나 서비스 엔트리 오브젝트 또는 서비스 엔트리 오브젝트의 컬렉션을 리턴할 것이다. 서비스 엔트리 오브젝트는 기초 프로토콜이 제공할 수 있는 각종 표현의 서비스에 대한 추상화이다. 각 서비스 엔트리 오브젝트는 서비스의 단일 인스턴스에 대응하며, 따라서 표 2에 개시된 것을 포함한 설명적인 식별 속성들을 제공한다.

일반 void Save() 함수는 범위 컬렉션에 상세 지정된 범위 내의 서비스 엔트리 표현을 생성 또는 갱신하기 위하여 제공된다.

일반 void Delete() 방법은 이 서비스 엔트리 오브젝트를 범위 속성에 상세 지정된 범위로부터 삭제한다. 해당 서비스가 이미 퍼블리싱되었다면 예외가 적용된다.

의사 코드

도 8 내지 도 19는 각종 서비스 디스커버리, 퍼블리케이션 및 가입 함수를 수행하기 위한 의사코드들을 예시한 것이다.

도 8은 C# 프로그래밍 언어를 사용하여, 분당 50매를 인쇄할 수 있는 컬러 프린터를 액티브 디렉토리 프로토콜 상의 심플 필터 오브젝트를 이용하여 찾아내기 위한 방법을 설명하는 의사 코드이다.

도 9는 C# 프로그래밍 언어를 사용하여, 웹 서비스를 찾아내기 위한 방법을 설명하는 의사 코드이다.

도 10은 C# 프로그래밍 언어를 사용하여, 특정 tModel 인터페이스를 지원하는 서비스를 심플 필터 오브젝트 및 UDDI 프로토콜을 이용하여 찾아내기 위한 방법을 나타낸 의사 코드이다.

도 11은 Visual Basic.NET를 사용하여, 특정 tModel 인터페이스를 지원하는 서비스를 심플 필터 오브젝트 및 UDDI 프로토콜을 이용하여 찾아내기 위한 방법을 나타낸 의사 코드이다.

도 12는 C# 프로그래밍 언어를 사용하여, Office Printer라는 명칭을 갖는 프린터를 액티브 디렉토리를 갖는 RichFilter를 이용하여 찾아내기 위한 방법을 나타낸 의사 코드이다.

도 13은 Visual Basic.NET를 사용하여, Office Printer라는 명칭을 갖는 프린터를 액티브 디렉토리를 갖는 RichFilter를 이용하여 찾아내기 위한 방법을 나타낸 의사 코드이다.

도 14는 C# 프로그래밍 언어를 사용하여, 특정 유니크 식별자에 의해 식별된 특정 타입의 서비스를 SSDP 프로토콜을 이용하여 퍼블리싱하기 위한 방법을 나타낸 의사 코드이다.

도 15는 Visual Basic.NET를 사용하여, 특정 유니크 식별자에 의해 식별된 특정 타입의 서비스를 SSDP 프로토콜을 이용하여 퍼블리싱하기 위한 방법을 나타낸 의사 코드이다.

도 16은 C# 프로그래밍 언어를 사용하여, SSDP 프로토콜로부터 서비스를 삭제하기 위한 방법을 나타낸 의사 코드이다.

도 17은 Visual Basic.NET를 사용하여, SSDP 프로토콜로부터 서비스를 삭제하기 위한 방법을 나타낸 의사 코드이다.

도 18은 C# 프로그래밍 언어를 사용하여, SSDP 프로토콜을 사용하는 특정 타입의 이벤트를 심플 필터를 이용하여 등록하는 방법을 설명하는 의사 코드이며, 여기서 등록된 콜백 함수는 필터에 매칭된 모든 이벤트마다 호출되며 대응하는 서비스 엔트리 오브젝트가 핸들러(handler)에게 제공된다.

도 19는 Visual Basic.NET를 사용하여, SSDP 프로토콜을 사용하는 특정 타입의 이벤트를 심플 필터를 이용하여 등록하는 방법을 설명하는 의사 코드이다.

예시적 OPath 신택스

표 3은 각종 디스커버리 함수를 위한 예시적 OPath 신택스를 제공한다.

표 4는 UDDI 프로토콜에서 사용될 수 있는 OPath 신택스의 일례를 포함하고 있다.

표 5는 NetBT 프로토콜에서 사용될 수 있는 OPath 신택스의 일례를 포함하고 있다.

디스커버리 퍼시스턴스 서비스

앞에서 간략하게 설명한 바와 같이, 디스커버리 퍼시스턴스 서비스(212)는 서비스 정보에 대한 영속적 데이터 저장소를 관리한다. 디스커버리 퍼시스턴스 서비스는 정기적 또는 기동 시와 같은 미리 정해진 이벤트가 있을 때마다 특정(ad-hoc) 디바이스/서비스 어나운스먼트를 수신하기 위하여 등록한다. 일례로서, 새로운 UPnP 디바이스가 도입된 경우, 디스커버리 퍼시스턴스 서비스는 UPnP 프로토콜 모듈에 의해 처리될 디바이스 어나운스먼트를 발생시킬 것이다. 그러면, UPnP 프로토콜 모듈은 그 이벤트(디바이스 및 그 서비스)의 상세를 서비스 디스커버리 API(214)를 통해 디스커버리 퍼시스턴스 서비스에게 공표(surface)할 것이다.

그런 다음, 디스커버리 퍼시스턴스 서비스는 자신의 영속적 데이터 저장소를 이용하여 그것이 새로운 디바이스/서비스인지 또는 리턴된 디바이스/서비스인지를 판정할 것이다. 그것이 새로운 디바이스/서비스라면, 그 디바이스의 상세 및 그 서비스는 영속적 데이터 저장소에 등록될 것이다. 서비스 디스커버리 API(214)의 또다른 컨슈머(consumer)가 서비스를 찾고자 한다면, 서비스 디스커버리 API(214)는 그 디바이스가 현재 이용 가능하지 않은 경우에도 그 특정 디바이스/서비스를 위한 서비스를 리턴할 수 있을 것이다. 상기한 예에서, 상기 디바이스/서비스를 현재 이용할 수 있는 경우에는, 상세 지정된 범위에 따라서, UPnP 프로토콜 모듈 및 영속적 데이터 저장 모듈의 양방은 그 디바이스에 대한 결과를 리턴할 것이다. 이러한 기능은 UPnP 뿐만 아니라 다른 특정 디스커버리 메커니즘에도 적용될 수 있다.

따라서, 디스커버리 퍼시스턴스 서비스(212), 서비스 디스커버리 API(214) 및 로컬 데이터베이스 저장소(240)는 디바이스 및 서비스 디스커버리에 사용되는 각종 로우 레벨 프로토콜들에 대한 한 계층의 추상화를 제공한다. 이러한 추가 계층의 추상화는 애플리케이션 개발자들이 애플리케이션을 개발할 때 사용할 수 있는 공통의 개선된 서치 시맨틱을 확립한다.

또한, 디스커버리 퍼시스턴스 서비스(212), 서비스 디스커버리 API(214) 및 로컬 데이터베이스 저장소(240)는 로컬 머신, 홈 네트워크, 엔터프라이즈 네트워크 및 인터넷 상의 디바이스 및 서비스에 대한 견고한(consolidated) 디스커버리 모듈을 제공한다. 따라서, 애플리케이션 개발자들이 단일의 일관된 API에 기록하는 것으로 광범위한 장소에 걸쳐 서비스를 발견할 수 있다.

결론

이상, 본 발명을 구조적인 특징 및/또는 방법론적인 동작(methodological acts)에 특수한 언어로 기술하였지만, 아래의 청구항에 규정된 발명은 전술한 특정 피쳐 또는 동작에 국한될 필요는 없다. 오히려 상기 특정 피쳐 및 동작은 청구항에 기재된 발명을 구현한 예시적 형태로서 기재된 것이다.

Claims

컴퓨팅 환경에서 이용 가능한 서비스를 관리하는 시스템으로서,
애플리케이션으로부터 서비스 쿼리(query)를 받아 들이도록 구성된 제1 애플리케이션 프로그래밍 인터페이스 - 상기 제1 애플리케이션 프로그래밍 인터페이스는 제1 서비스 쿼리 프로토콜로 서비스 쿼리를 수신하며, 상기 서비스 쿼리를 처리하여 적어도 하나의 대응하는 서비스 쿼리를 제2 프로토콜로 개시하도록 구성됨 -; 및
상기 제1 애플리케이션 프로그래밍 인터페이스에 통신가능하도록 접속되고, 심플(simple) 필터 및 리치(rich) 필터를 포함하는 디스커버리 퍼시스턴스(persistence) 서비스 - 상기 디스커버리 퍼시스턴스 서비스는 상기 제1 애플리케이션 프로그래밍 인터페이스로부터 서비스 정보를 수신하며 상기 서비스 정보를 데이터 저장소에 저장하도록 구성됨 -
를 포함하는 서비스 관리 시스템.
제1항에 있어서,
상기 제1 애플리케이션 프로그래밍 인터페이스는 적어도 하나의 디렉토리 기반 프로토콜 및 적어도 하나의 특정(ad-hoc) 프로토콜에 대한 인터페이스를 제공하는 서비스 관리 시스템.
제1항에 있어서,
상기 심플 필터는 서비스 타입, 서비스 인터페이스 및 서비스 속성 중 적어도 하나에 의해 상기 서비스 쿼리의 표현을 제공하는 서비스 관리 시스템.
제1항에 있어서,
상기 리치 필터는 쿼리 시맨틱(semantic)을 사용하여 상기 서비스 쿼리의 표현을 제공하는 서비스 관리 시스템.
제1항에 있어서,
상기 제1 애플리케이션 프로그래밍 인터페이스는 로컬 컴퓨팅 장치에서 이용 가능한 서비스를 발견하는 서비스 관리 시스템.
제1항에 있어서,
상기 제1 애플리케이션 프로그램 인터페이스는 원격 컴퓨팅 장치에서 이용 가능한 서비스를 발견하는 서비스 관리 시스템.
제1항에 있어서,
상기 제1 애플리케이션 프로그래밍 인터페이스는 시스템 관리자에 의한 설정이 가능한 범위 맵을 구현하는 서비스 관리 시스템.
컴퓨팅 환경에서 이용 가능한 서비스를 퍼블리싱(publishing) 하기 위한 방법으로서,
애플리케이션 프로그램에서,
서비스 엔트리 오브젝트를 지정하는 단계;
퍼블리케이션 범위를 지정하는 단계;
상기 서비스에 유니크 키(unique key)를 부여하는 단계;
상기 서비스에 서비스 타입을 부여하는 단계;
상기 서비스의 속성을 지정하는 단계;
상기 서비스의 엔드포인트(endpoints)를 지정하는 단계; 및
제1 애플리케이션 프로그래밍 인터페이스에 퍼블리케이션 요청을 개시하는 단계;
상기 제1 애플리케이션 프로그래밍 인터페이스(API)에서,
복수의 서치 요청을 파싱하는 단계; 및
상기 서비스를 퍼블리싱하기 위하여 적어도 하나의 로우 레벨 API 호출을 실행하는 단계
를 포함하는 서비스 퍼블리케이션 방법.
제8항에 있어서,
서비스 정보를 영속적 데이터 저장소에 저장하는 단계를 더 포함하는 서비스 퍼블리케이션 방법.
제8항에 있어서,
상기 서비스 엔트리 오브젝트는 상기 퍼블리싱 서비스에 대한 설명 및 식별 속성을 제공하는 서비스 퍼블리케이션 방법.
제10항에 있어서,
상기 설명 및 식별 속성은,
서비스 명칭;
서비스 설명;
특정 서비스에 대한 복수의 네트워크 어드레스들을 포함하는 복수의 엔드포인트들;
상기 특정 서비스를 식별하는 키;
서비스 및 장치 특징에 대한 명칭-값 페어의 확장가능 리스트를 포함하는 복수의 속성들; 및
상기 특정 서비스를 제공하는 엔티티에 대한 식별자를 포함하는 제공자(provider)를 포함하는 서비스 퍼블리케이션 방법.
컴퓨팅 환경에서 퍼블리싱된 서비스를 삭제하는 방법으로서,
애플리케이션 프로그램에서,
서비스 엔트리 오브젝트를 지정하는 단계;
상기 퍼블리싱된 서비스에 대응하는 키를 지정하는 단계;
상기 서비스에 대한 삭제 범위를 지정하는 단계; 및
제1 애플리케이션 프로그래밍 인터페이스 (API)에 삭제 요청을 개시하는 단계;
상기 제1 API에서,
상기 삭제 요청을 파싱하는 단계; 및
상기 서비스를 삭제하기 위하여 적어도 하나의 로우 레벨 API 호출을 실행하는 단계
를 포함하는 퍼블리싱된 서비스 삭제 방법.
제12항에 있어서,
영속적 데이터 저장소로부터 서비스 정보를 삭제하는 단계를 더 포함하는 퍼블리싱된 서비스 삭제 방법.
제13항에 있어서,
상기 삭제된 서비스 정보를 영속적 데이터 저장소에 등록하는 단계를 더 포함하는 퍼블리싱된 서비스 삭제 방법.
삭제
제12항에 있어서,
상기 적어도 하나의 로우 레벨 API로부터 수신된 정보를 영속적 데이터 저장소에 저장하는 단계를 더 포함하는 퍼블리싱된 서비스 삭제 방법.
제12항에 있어서,
상기 범위는 모니터할 특정 로우 레벨 프로토콜을 특정하는 퍼블리싱된 서비스 삭제 방법.
삭제
제12항에 있어서,
상기 서비스 엔트리 오브젝트는 상기 퍼블리싱된 서비스에 대한 설명 및 식별 속성을 제공하는 퍼블리싱된 서비스 삭제 방법.
제19항에 있어서,
상기 설명 및 식별 속성은,
서비스 명칭;
서비스 설명;
특정 서비스에 대한 복수의 네트워크 어드레스들을 포함하는 복수의 엔드포인트들;
상기 특정 서비스를 식별하는 키;
서비스 및 장치 특징에 대한 명칭-값 페어의 확장가능 리스트를 포함하는 복수의 속성들; 및
상기 특정 서비스를 제공하는 엔티티에 대한 식별자를 포함하는 제공자(provider)를 포함하는 퍼블리싱된 서비스 삭제 방법.