KR20150108749A - 서비스 지향 아키텍쳐 네트워크 내 서비스들의 검색 방법 - Google Patents

Abstract

서비스 지향 아키텍쳐 네트워크 내의 서비스들을 탐색하기 위한 방법 및 시스템은 특정 서비스에 대한 검색 쿼리를, 클라이언트로부터 로컬 서비스 레지스트리 내에서, 수신하는 것을 포함할 수 있다. 로컬 서비스 레지스트리는 로컬 서비스 레지스트리에 등록된 서비스들을 기록하는 로컬 데이터 베이스를 포함할 수 있다. 로컬 서비스 레지스트리는 서비스 레지스트리들의 네트워크 내에 있을 수 있다. 네트워크는 검색 쿼리를 만족하는 서비스들의 제1 리스트를 결정하도록 로컬 데이터 베이스에 질의하고 이웃하는 서비스 레지스트리를, 서비스 레지스트리들의 네트워크 내에서, 검색 대상인 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티를 기초로, 결정하는 것을 포함할 수 있다. 본 방법은 검색 쿼리를 이웃하는 서비스 레지스트리에 전송하는 것 및 이웃하는 서비스 레지스트리로부터, 검색 쿼리를 만족하는 이웃하는 서비스 레지스트리에 등록된 서비스들의 제2 리스트를 수신하는 것을 포함할 수 있다. 본 방법은 클라이언트에게 검색 쿼리를 만족하는 서비스들의 제1 리스트 및 서비스들의 제2 리스트를 반환하는 것을 포함할 수 있다.

Description

서비스 지향 아키텍쳐 네트워크 내 서비스들의 검색 방법{FINDING SERVICES IN A SERVICE-ORIENTED ARCHITECTURE(SOA) NETWORK}

본 발명은 전체적으로 서비스 지향 아키텍쳐(Service-Oriented Acrchitecture, "SOA") 네트워크 내에서 서비스들을 탐색하는 것에 관한 것이다.

서비스 지향 아키텍쳐(SOA)는, 서비스로서 다른 어플리케이션들에 어플리케이션 기능을 제공하는 소프트웨어의 유닛들을 기초로하는 소프트웨이 디자인 및 소프트웨어 아키텍쳐 디자인 방법론이다. 서비스는 기능에 대한 유닛이다. 서비스들은, 더 큰 소프트웨어 어플리케이션의 완전한 기능을 제공하도록 다른 소프트웨어 어플리케이션들에 의하여 결합될 수 있다. SOA는 네트워크에 걸쳐 연결된 컴퓨터들이 협동하는 것을 더 쉽게 만든다.

본 발명이 해결하고자 하는 과제는 전체적으로 개선된 서비스 지향 아키텍쳐 네트워크 내에서 서비스들을 탐색하는 방법 및 시스템을 제공하는 것이다.

일 실시예에서, 방법은 (a) 클라이언트로부터 로컬 서비스 레지스트리 내에서 특정 서비스에 대한 검색 쿼리를 수신하는 단계를 포함할 수 있다. 이러한 실시예에서, 로컬 서비스 레지스트리는, 로컬 서비스 레지스트리에 등록된 서비스들을 기록하는 로컬 데이터 베이스를 포함한다. 로컬 서비스 레지스트리는 서비스 레지스트리들의 네트워크 내에 있다. 이 방법은 (b) 검색 쿼리를 만족하는 서비스들의 제1 리스트를 결정하도록 로컬 데이터 베이스에 질의하는 단계를 포함할 수 있다. 이 방법은 (c) 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티를 기초로, 서비스 레지스트리들의 네트워크 내에서, 이웃하는 서비스 레지스트리를 결정하는 단계를 포함할 수 있고, 이 때, 이웃하는 서비스 레지스트리는 로컬 서비스 레지스트리에 이웃한다. 이 방법은 (d) 이웃하는 서비스 레지스트리에 검색 쿼리를 전송하는 단계를 포함할 수 있다. 이러한 실시예에서, 이웃하는 서비스 레지스트리는 이웃하는 서비스 레지스트리에 등록된 서비스들을 기록하는 이웃하는 데이터 베이스를 포함한다. 이 방법은 (e) 이웃하는 서비스 레지스트리로부터, 검색 쿼리를 만족하는, 이웃하는 서비스 레지스트리에 등록된, 서비스들의 제2 리스트를 수신하는 단계를 포함할 수 있다. 이 방법은 (f) 클라이언트에게, 검색 쿼리를 만족하는 서비스들의 제1 리스트 및 서비스들의 제2 리스트를 반환하는 단계를 포함할 수 있다. 본 실시예의 몇몇 가능한 이점들은 다음 문단에서 기술된다.

일 실시예에서, 서비스 레지스트리들은 네트워크 내의 디바이스들 사이에 분산될 수 있고, 서비스 레지스트리들은 동일하지 않을 수 있다. 이 경우, 서비스들은 로컬 서비스 레지스트리에 등록할 수 있다. 그런 서비스 레지스트리들은 네트워크 내의 모든 서비스들을 인지하지 못할 수 있으나 로컬 서비스들은 인지할 수 있다. 만일 로컬 서비스 레지스트리가 검색 쿼리를 만족하지 못한다면, 검색 쿼리는 바로 가까이의 서비스 레지스트리들(예를 들어, 로컬 서비스 레지스트리에 가까운 하나 또는 그 이상의 이웃하는 서비스 레지스트리들)에 포워딩될 수 있다. 가능한 하나의 이점으로서, 이러한 실시에는 (네트워크 내의 디바이스들 사이로 분산되지 않은 중앙형 서비스 레지스트리와는 대조적으로) 더 큰 결함 허용성(fault tolerance)를 제공할 수 있다. 다른 가능한 이점으로서, 이러한 실시예는 (네트워크 내의 디바이스들 내에서 거의 복제되지 않는 서비스 레지스트리와는 대조적으로) 동기화를 위한 네트워크 트래픽을 감소시킬 수 있다. 또 다른 가능한 이점으로서, 이러한 실시예는, (잠재적으로) 높은 결함 허용성 및 낮은 네트워크 트래픽을 갖는 효율적인 방식으로 서비스들을 검색 또는 탐색하는 것을 가능케 한다. 다른 가능한 이점은, 검색 대상인 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티를 기초로 특정 서비스를 탐색할 때, 이웃하는 서비스 레지스트리을 결정할 수 있는 능력이다.

기술된 바와 같이, 일 실시예에서, 특정 서비스에 대한 검색 요청(쿼리)는 네트워크 내에서 이웃하는 서비스 레지스트리에 포워딩 될 수 있고, 이때, 이웃하는 노드는 검색 대상이 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티을 기초로 결정된다. 예를 들어, 데이터 저장 서비스에 대한 요청은 네트워크 지연 시간(예를 들어 데이터 저장이 아닌 프로퍼티)을 기초로 이웃하는 서비스 레지스트리에 포워딩 될 수 있다. 가능한 이점으로서, 이와 같은 방식으로 이웃하는 노드들을 선택하는 것은 국부적으로(locally) 호스팅되지 않은 서비스들을 고속으로 검색하는 것을 가능케 할 수 있다.

일 실시예에서, 특정 서비스의 프로퍼티는 특정 프로퍼티이고, 검색 쿼리는 특정 서비스 및 특정 서비스의 특정 프로퍼티를 식별한다. 이러한 실시예에서, 이 방법은 이웃하는 서비스 레지스트리를 특정 프로퍼티가 아닌 다른 프로퍼티를 기초로 결정하는 것을 포함한다. 이러한 실시예의 이점은 더 큰 결함 혀용성을 포함하고 동기화를 위한 네트워크 트래픽을 감소시킬 수 있는 것이다. 또 다른 가능한 이점으로서, 이러한 실시예는, 효율적인 방식으로 서비스들을 검색 또는 탐색하는 것을 가능케 한다. 다른 가능한 이점은, 검색 대상인 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티를 기초로 특정 서비스를 탐색할 때, 이웃하는 서비스 레지스트리을 결정할 수 있는 능력이다.

다른 실시예에서, 이 방법은 이웃하는 서비스 레지스트리를 복수의 프로퍼티들을 기초로 결정하는 것을 포함하고, 이때, 복수의 프로퍼티들은 특정 서비스의 프로퍼티들이 아니며, 복수의 프로퍼티들의 각각의 프로퍼티는 계량된다. 이 실시예의 이점은, 검색이 하나의 프로퍼티를 초과하는 프로퍼티를 참작할 수 있게 하는 것이고, 이 때, 프로퍼티들은 특정 서비스의 프로퍼티들이 아니다. 프로퍼티들을 계량하는 것은, 각각의 프로퍼티에 상이한 계량치(weight)를 부여할 때, 상이한 프로퍼티들을 사용하는 이점을 제공할 수 있다.

다른 실시예에서, 검색 쿼리는 특정 서비스를 데이터 저장으로 나타내고, 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티는 대역폭, 지리적 위치, 개방 채널들, 지연 시간, 멀티캐스트 용량, 홉(hop)의 수, 비용, 또는 네트워크 타입을 포함한다.

일 실시예에서, 서비스 레지스트리들의 네트워크는 서비스 레지스트리들의 트리 네트워크이다. 다른 실시예에서, 서비스 레지스트리들의 네트워크는 서비스 레지스트리들의 메쉬 네트워크이다. 트리 네트워크 및 메쉬 네트워크의 가능한 이점은 각각이 병렬적으로(및 잠재적으로 효율적인 방식으로) 서비스들을 검색하는 것을 가능케하는 것이다. 트리 네트워크의 가능한 이점은 (메쉬 네트워크에 비교 시) 그것이 네트워크 트랙픽을 감소시킬 수 있는 것이다(예를 들어, 더 적은 분산된 검색들 및 더 적은 매칭하는 결과들). 메쉬 네트워크의 가능한 이점은 (트리 네트워크에 비교 시) 그것이 더 빠르고 더 병렬적일 수 있는 것이다.

일 실시예에서, 이 방법은 또한 (g) 이웃하는 서비스 레지스트리 내의 검색 쿼리를 수신하는 단계, (h) 검색 쿼리를 만족하는 서비스들의 제2 리스트를 결정하도록 이웃하는 서비스 레지스트리에 질의하는 단계; 및 (i) 로컬 서비스 레지스트리에 제2 리스트를 전송하는 단계를 포함할 수 있다. 이러한 실시에의 이점은 더 큰 결함 허용성을 갖고 동기화를 위한 네트워크 트래픽을 감소 시킬 수 있는 것이다. 또 다른 가능한 이점으로서, 이러한 실시예는 효율적인 방식으로 서비스들을 검색 또는 탐색하는 것을 가능케 할 수 있다.

일 실시예에서, 이웃하는 서비스 레지스트리는 요청하는 서비스 레지스트리이다. 이러한 실시예에서, 이 방법은, (j) 서비스들의 제2 리스트가 충분한지 여부를 결정하는 것을 포함할 할 수 있다. 서비스들의 제2 리스트가 충분하지 않을 때, 이 방법은, 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티를 기초로, 서비스 레지스트리들의 네트워크 내에서, 다른 이웃하는 서비스 레지스트리를 결정하는 것을 포함할 수 있고, 이 때, 다른 이웃하는 서비스 레지스트리는 요청하는 서비스 레지스트리에 이웃한다. 서비스들의 제2 리스트가 충분하지 않을 때, 이 방법은, 검색 쿼리를 다른 이웃하는 서비스 레지스트리에 전송하는 것을 포함할 수 있고, 이 때, 다른 이웃하는 서비스 레지스트리는 다른 이웃하는 서비스 레지스트리에 등록된 서비스들을 기록하는 다른 이웃하는 데이터베이스를 포함한다. 서비스들의 제2 리스트가 충분하지 않을 때, 이 방법은, 검색 쿼리를 만족하는, 다른 이웃하는 서비스 레지스트리에 등록된, 서비스들의 다른 리스트를 다른 이웃하는 서비스 레지스트리로부터 수신하는 것을 포함할 수 있고, 이 때, 제2 리스트는 다른 리스트를 포함한다. 이러한 실시에의 이점은 더 큰 결함 허용성을 갖고 동기화를 위한 네트워크 트래픽을 감소 시킬 수 있는 것이다. 또 다른 가능한 이점으로서, 이러한 실시예는 효율적인 방식으로 서비스들을 검색 또는 탐색하는 것을 가능케 할 수 있다. 예를 들어, 추가의 이웃하는 노드들에 쿼리를 전송해야 할 필요 없이, 검색은 결과들이 충분할 때 중단될 수 있다.

일 실시예에서, 이 방법은 연속하는 다른 노드들에서 (j)의 단계를 반복하는 것을 포함한다. 가능한 이점으로서, 이러한 실시예는 결과들이 충분할 때 까지, 네트워크를 통해 쿼리가 전파되는 것을 가능하게 한다.

본 명세서에서 시스템 또한 기술된다. 이 시스템은 디바이스를 포함할 수 있고, 여기서, 디바이스는 로컬 서비스 레지스트리에 등록된 서비스들을 기록하는 로컬 데이터 베이스를 저장하는 메모리를 포함한다. 이러한 실시예에서, 로컬 서비스 레지스트리는 서비스 레지스트리들의 네트워크 내에 있다. 디바이스는 또한 클라이언트로부터 특정 서비스에 대한 검색 쿼리를 수신하는 프로세서를 또한 포함할 수 있다. 이러한 실시예에서, 프로세서는 또한 검색 쿼리를 만족하는 서비스들의 제1 리스트를 결정하도록 로컬 데이터 베이스에 질의할 수 있고, 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티를 기초로, 서비스 레지스트리들의 네트워크 내에서, 이웃하는 서비스 레지스트리를 결정할 수 있다. 이 때, 이웃하는 서비스 레지스트리는 로컬 서비스 레지스트리에 이웃한다. 이러한 실시예에서, 디바이스는 이웃하는 서비스 레지스트리에 검색 쿼리를 전송하는 송신기를 포함한다. 이 경우, 이웃하는 서비스 레지스트리는 이웃하는 서비스 레지스트리에 등록된 서비스들을 기록하는 이웃하는 데이터 베이스를 포함한다. 이러한 실시예에서, 디바이스는 또한 검색 쿼리를 만족하는, 이웃하는 서비스 레지스트리에 등록된, 서비스들의 제2 리스트를, 이웃하는 서비스 레지스트리로부터 수신하는 수신기를 포함할 수 있고, 이 때, 프로세서는 클라이언트에게 검색 쿼리를 만족하는 제1 리스트 및 제2 리스트를 반환하도록 구성된다. 이러한 실시예의 몇몇 가능한 이점들이 다음 단락들에서 기술된다.

일 실시예에서, 서비스 레지스트리들은 네트워크 내의 디바이스들 사이에 분산될 수 있고, 서비스 레지스트리들은 동일하지 않을 수 있다. 이 경우, 서비스들은 로컬 서비스 레지스트리에 등록할 수 있다. 그런 서비스 레지스트리들은 네트워크 내의 모든 서비스들을 인지하지 못할 수 있으나 로컬 서비스들은 인지할 수 있다. 만일 로컬 서비스 레지스트리가 검색 쿼리를 만족하지 못한다면, 검색 쿼리는 바로 가까이의 서비스 레지스트리들(예를 들어, 로컬 서비스 레지스트리에 가까운 하나 또는 그 이상의 이웃하는 서비스 레지스트리들)에 포워딩될 수 있다. 가능한 하나의 이점으로서, 이러한 실시에는 (네트워크 내의 디바이스들 사이로 분산되지 않은 중앙형 서비스 레지스트리와는 대조적으로) 더 큰 결함 허용성(fault tolerance)를 제공할 수 있다. 다른 가능한 이점으로서, 이러한 실시예는 (네트워크 내의 디바이스들 내에서 거의 복제되지 않는 서비스 레지스트리와는 대조적으로) 동기화를 위한 네트워크 트래픽을 감소시킬 수 있다. 또 다른 가능한 이점으로서, 이러한 실시예는, (잠재적으로) 높은 결함 허용성 및 낮은 네트워크 트래픽을 갖는 효율적인 방식으로 서비스들을 검색 또는 탐색하는 것을 가능케 한다. 다른 가능한 이점은, 검색 대상인 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티를 기초로 특정 서비스를 탐색할 때, 이웃하는 서비스 레지스트리를 결정할 수 있는 능력이다.

기술된 바와 같이, 일 실시예에서, 특정 서비스에 대한 검색 요청(쿼리)는 네트워크 내에서 이웃하는 서비스 레지스트리에 포워딩 될 수 있고, 이때, 이웃하는 노드는 검색 대상이 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티을 기초로 결정된다. 예를 들어, 데이터 저장 서비스에 대한 요청은 네트워크 지연 시간(예를 들어 데이터 저장이 아닌 프로퍼티)을 기초로 이웃하는 서비스 레지스트리에 포워딩 될 수 있다. 가능한 이점으로서, 이와 같은 방식으로 이웃하는 노드들을 선택하는 것은 국부적으로(locally) 호스팅되지 않은 서비스들을 고속으로 검색하는 것을 가능케 할 수 있다.

일 실시예에서, 특정 서비스의 프로퍼티는 특정 프로퍼티이고, 검색 쿼리는 특정 서비스 및 특정 서비스의 특정 프로퍼티를 식별한다. 이러한 실시예에서, 프로세서는 이웃하는 서비스 레지스트리를 특정 프로퍼티가 아닌 다른 프로퍼티를 기초로 결정하도록 구성될 수 있다.. 이러한 실시예의 이점은 더 큰 결함 혀용성을 포함하고 동기화를 위한 네트워크 트랙픽을 감소시킬 수 있는 것이다. 또 다른 가능한 이점으로서, 이러한 실시예는, 효율적인 방식으로 서비스들을 검색 또는 탐색하는 것을 가능케 한다. 다른 가능한 이점은, 검색 대상인 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티를 기초로 특정 서비스를 탐색할 때, 이웃하는 서비스 레지스트리을 결정할 수 있는 능력이다.

일 실시예에서, 프로세서는 이웃하는 서비스 레지스트리를 복수의 프로퍼티들을 기초로 결정하도록 구성되고, 이 때, 복수의 프로퍼티들은 특정 서비스의 프로퍼티들이 아니며, 프로세서는 복수의 프로퍼티들의 각각의 프로퍼티를 계량하도록 구성된다. 이 실시예의 이점은, 검색이 하나의 프로퍼티를 초과하는 프로퍼티를 참작할 수 있게 하는 것이고, 이 때, 프로퍼티들은 특정 서비스의 프로퍼티들이 아니다. 프로퍼티들을 계량하는 것은, 각각의 프로퍼티에 상이한 계량치(weight)를 부여할 때, 상이한 프로퍼티들을 사용하는 이점을 제공할 수 있다.

일 실시예에서, 검색 쿼리는 특정 서비스를 데이터 저장으로 나타내고, 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티는 대역폭, 지리적 위치, 개방 채널들, 지연 시간, 멀티캐스트 용량, 홉(hop)의 수, 비용, 또는 네트워크 타입을 포함한다.

일 실시예에서, 서비스 레지스트리들의 네트워크는 서비스 레지스트리들의 트리 네트워크이다. 다른 실시예에서, 서비스 레지스트리들의 네트워크는 서비스 레지스트리들의 메쉬 네트워크이다. 트리 네트워크 및 메쉬 네트워크의 가능한 이점은 각각이 병렬적으로(및 잠재적으로 효율적인 방식으로) 서비스들을 검색하는 것을 가능케하는 것이다. 트리 네트워크의 가능한 이점은 (메쉬 네트워크에 비교 시) 그것이 네트워크 트랙픽을 감소시킬 수 있는 것이다(예를 들어, 더 적은 분산된 검색들 및 더 적은 매칭하는 결과들). 메쉬 네트워크의 가능한 이점은 (트리 네트워크에 비교 시) 그것이 더 빠르고 더 병렬적일 수 있는 것이다.

시스템은 다른 디바이스를 더 포함할 수 있다. 다른 디바이스는 이웃하는 데이터 베이스를 저장하는 메모리를 포함할 수 있다. 다른 디바이스는 검색 쿼리를 저장하는 수신기, 및 서비스들의 제2 리스트가 검색 쿼리를 만족하는 지를 결정하도록 이웃하는 데이터 베이스에 질의하도록 구성된 프로세서를 포함할 수 있다. 다른 디바이스는 로컬 서비스 레지스트리에 제2 리스트를 전송하는 송신기를 포함할 수 있다. 이러한 실시예의 가능한 이점은 더 큰 결함 허용성을 갖고 동기화를 위한 네트워크 트래픽을 감소킬 수 있는 것이다. 또 다른 가능한 이점으로, 이러한 실시예는 효율적인 방식으로 서비스들을 검색 또는 탐색하는 것을 가능케 할 수 있는 것이다.

일 실시예에서, 이웃하는 서비스 레지스트리는 요청하는 서비스 레지스트리이다. 이러한 실시예에서, 다른 디바이스 내의 프로세서는, 서비스들의 제2 리스트가 충분한지 여부와, 언제 서비스들의 제2 리스트가 충분하지 않은 지를 결정하도록 구성된다. 프로세서는 또한 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티를 기초로, 서비스 레지스트리들의 네트워크 내에서, 다른 이웃하는 서비스 레지스트리를 결정하도록 구성될 수 있고, 이 때, 다른 이웃하는 서비스 레지스트리는 요청하는 서비스 레지스트리에 이웃한다. 프로세서는 또한 검색 쿼리를 다른 이웃하는 서비스 레지스트리에 전송하도록 구성될 수 있고, 이 때, 다른 이웃하는 서비스 레지스트리는 다른 이웃하는 서비스 레지스트리에 등록된 서비스들을 기록하는 다른 이웃하는 데이터베이스를 포함한다. 수신기는 검색 쿼리를 만족하는, 다른 이웃하는 서비스 레지스트리에 등록된, 서비스들의 다른 리스트를 다른 이웃하는 서비스 레지스트리로부터 수신하도록 구성될 수 있다. 제2 리스트는 다른 리스트를 포함한다. 이러한 실시에의 이점은 더 큰 결함 허용성을 갖고 동기화를 위한 네트워크 트래픽을 감소 시킬 수 있는 것이다. 또 다른 가능한 이점으로서, 이러한 실시예는 효율적인 방식으로 서비스들을 검색 또는 탐색하는 것을 가능케 할 수 있다. 예를 들어, 추가의 이웃하는 노드들에 쿼리를 전송해야 할 필요 없이, 검색은 결과들이 충분할 때 중단될 수 있다.

시스템은 또한 검색 쿼리를 만족하는 서비스들을 연속적으로 검색하도록 다른 디바이스와 같이 구성되는 메모리들, 수신기들, 프로세서들, 및 송신기들을 포함하는 추가 디바이스들을 포함할 수 있다. 가능한 이점으로, 이러한 실시예는 결과들이 충분할 때까지 쿼리가 네트워크를 통하여 전파되는 것을 가능케 한다.

다른 실시예에서, 방법은 특정 서비스에 대응하는 서비스 레지트리의 네트워크의 접속 형태를 결정하는 것을 포함할 수 있다. 이러한 실시예에서, 각각의 서비스 레지스트리들은 대응하는 서비스 레지스트리에 등록된 서비스들의 인스턴스들을 기록한다. 접속 형태를 결정하는 것은, 각 서비스 레지스트리에 대하여, 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티를 기초로 하나 또는 그 이상의 이웃하는 서비스 레지스트리를 결정하는 것을 포함할 수 있다. 이러한 실시예의 이점은 더 큰 결함 허용성을 갖고 동기화를 위한 네트워크 트래픽을 감소시키는 것일 수 있다. 또 다른 가능한 이점으로서, 이러한 실시예는 효율적인 방식으로 서비스들을 검색 또는 탐색하는 것을 가능케 하는 것일 수 있다.

서비스 레지스트리들의 네트워크 접속 형태는 복수의 노드들의 네트워크 상의 오버레이 네트워크일 수 있다. 이러한 실시예에서, 이 방법은 서비스 레지스트리들에 대하여 복수의 접속 형태들을 결정하는 것을 포함할 수 있고, 각 접속 형태는 상이한 특정 서비스에 대응된다. 하나의 가능한 이점으로, 접속 형태에 따라 연속적인 이웃하는 노드들에 질의하는 것은 국부적으로(locally) 호스팅되지 않은 서비스들을 고속으로 탐색하는 것을 가능케 할 수 있다.

상이한 접속 형태들은 상이한 가능한 이점들을 가질 수 있다. 예를 들어, 네트워크의 트리 접속 형태와 메쉬 접속 형태 모두의 하나의 가능한 이점은 각각이 병렬적으로 서비스들을 검색할 수 있는 것이다. 트리 접속 형태의 가능한 이점은 (메쉬 네트워크에 비교 시) 그것이 네트워크 트래픽을 감소시킬 수 있는 것이다. 메쉬 네트워크의 가능한 이점은 (트리 네트워크에 비교 시) 그것이 더 빠르고 더 병렬적일 수 있는 것이다. 또한, 하나의 가능한 이점은 적절하거나 최적의 접속 형태(트리, 메쉬, 또는 다른 것)가 검색 대상인 특정 서비스를 기초로 선택될 수 있는 것이다.

도 1은 이하에서 기술되는 하나 또는 그 이상의 실시예들에 따른 예시적인 환경을 도시하는 블록도이다.
도 2는 도 1의 디바이스의 예시적인 구성들을 도시하는 블록도이다.
도 3은 도 1의 디바이스의 예시적인 기능적인 계층들을 도시하는 블록도이다.
도 4a는 도 3의 서비스 계층의 예시적인 기능적인 구성들을 도시하는 블록도이다.
도 4b는 도 4a의 서비스 레지스트리의 기능을 도시하는 블록도이다.
도 4c는 도 4a의 서비스 레지스트리의 예시적인 기능적인 구성들을 도시하는 블록도이다.
도 4d는 특정 서비스에 대한 예시적인 프로퍼티 테이블의 블록도이다.
도 5a는 도 3의 오버레이 네트워크 계층의 기능적인 구성들을 도시하는 블록도이다.
도 5b는 예시적인 기능적인 오버레이 네트워크의 트리의 블록도이다.
도 6a 및 6b는 네트워크의 예시적인 접속 형태의 블록도들이다.
도 7a는 일 실시예에서 네트워크의 접속 형태를 결정하기 위한 예시적인 프로세스의 순서도이다.
도 7b는 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티들을 결정하기 위한 프로세스의 순서도이다.
도 8은 서비스를 검색하기 위한 예시적인 프로세스의 순서도이다.

아래의 상세한 설명들은 첨부된 도면들을 참조한다. 동일한 식별 부호들은 상이한 도면들에서 동일 또는 유사한 구성요소들을 나타낸다.

아래에서 기술되는 바와 같이, 디바이스들의 네트워크는 네트워크 전반에 걸쳐 통신할 수 있고, 일련의 다양한 서비스들을 제공하는 시스템의 일부를 형성할 수 있다. 상이한 디바이스들은 상이한 시간에서 상이한 서비스들을 제공할 수 있고, 시스템은, 바람직하게, 효율적이고 신뢰성 있는 방식으로(예를 들어, 기술적 문제를 소개하여) 특정 서비스를 호스팅하는 디바이스의 위치를 찾거나 검색하는 것을 요구할 수 있다.

상이한 디바이스들에 의해 요청되는 서비스들을 탐색하는 것의 문제를 해결하기 위하여, 디바이스들은 요청된 서비스들을 서비스 레지스트리에 저장할 수 있다. 일 해결책/실시예에서, 서비스 레지스트리는 네트워크 내에서 중앙 집중(centralized)될 수 있다. 그러한 해결책/실시예에서, 네트워크 내의 모든 서비스들은 중앙 서비스 레지스트리에 저장된다. 중앙 서비스 레지스트리는 오직 하나이기 때문에, 그것은 항상 동기 상태이며 상대적으로 유지하기 쉽다. 그러나, 중앙 서비스 레지스트리는 단일 지점의 결함(failure)(즉, 다른 기술적 문제)를 유발할 수 있다. 즉, 만일 중앙 서비스 레지스트리가 고장난다면, 서비스들은 불가능한 것은 아니나 탐색되기(find) 어려울 수 있다. 또한, 중앙 서비스 레지스트리는 크기 변경을 잘 할 수 없다(즉, 또 다른 기술적 문제). 즉, 네트워크가 지수적으로 증가함에 따라, 서비스 레지스트리의 가용한 대역폭 및 처리 속도(processing) 속도 또한 지수적으로 증가한다.

다른 해결책/실시예에서, 서비스 레지스트리는 네트워크 내의 디바이스들 사이로 분산될 수 있다(즉, 서비스 레지스트리의 전체 카피본이 복제될 수 있다.). 이러한 해결책/실시예는 중앙 서비스 레지스트리에 걸친 추가적인 결함 허용성(fault tolerance)을 가능케 한다. 다른 한편으로, 네트워크가 증가함에 따라, 디바이스들 사이의 레지스트리의 동기화가 점점 더 어려워지고 네트워크 트래픽이 이슈가 될 수 있다(즉, 다른 기술적 문제).

또 다른 해결책/실시예에서, 서비스 레지스트리들은 네트워크 내의 디바이스들 사이에 분산되되, 서비스 레지스트리들은 동일하지 않을 수 있다. 이러한 실시예에서, 서비스들은 로컬 서비스 레지스트리에 저장될 수 있다. 서비스 레지스트리들은 네트워크 내의 모든 서비스를 인지하지 못할 수 있으나, 로컬 서비스들을 인지할 수 있다. 그러므로, 국부적으로(locally) 호스팅 되지 않은 서비스를 탐색하는 것이 과제가 될 수 있다(즉, 하나의 기술적 문제). 네트워크 내의 서비스를 탐색하기 위하여, 이러한 해결책/실시예들은 (서비스를 찾는) 클라이언트가 로컬 서비스 레지스트리로부터의 서비스를 요청(예를 들어, 쿼리를 전송하여)할 수 있게 한다. 만일, 로컬 서비스 레지스트리가 그 요청을 만족할 수 없다면, 그 요청은 가까운 서비스 레지스트리들(예를 들어, 해당 로컬 서비스 레지스트리에 가까운 하나 또는 그 이상의 이웃하는 서비스 레지스트리들)에 전달될 수 없다. 이러한 해결책/실시예는 (중앙 서비스 레지스트리와는 대조적으로) 더 큰 결함 허용성(fault tolerance)를 가능케 하면서도(즉, 하나의 가능한 이점), (완전히 분산된 서비스 레지스트리들과는 다르게) 동기화를 위한 네트워크 트래픽을 감소시킬 수 있다(즉, 다른 가능한 이점). 하나의 해결책/ 실시예에서, 특정 서비스에 대한 검색 요청(쿼리)는 네트워크 내의 이웃하는 서비스 레지스트리로 포워딩될 수 있고, 여기서, 이웃하는 노드가 검색되는 특정 서비스의 프로퍼티(property)가 아닌 프로퍼티를 기초로 선택될 수 있다. 예를 들어, 데이터 저장 서비스에 대한 요청은 네트워크 지연시간(예를 들어, 데이터 저장과 무관한 프로퍼티)을 기초로 이웃하는 서비스 레지스트리에 포워딩 될 수 있다. 이러한 해결책/실시예에 따라 이웃하는 노드들을 선택하는 것(selecting)은 국부적으로(locally) 호스팅되지 않은 서비스들을 빠르게 탐색하는 것을 가능케 할 수 있다(즉, 다른 가능한 이점). 다른 가능한 이점은 검색되는 특정 서비스의 프로퍼티가 아닌 프로퍼티를 기초로 특정 서비스를 검색하는 이웃하는 서비스 레지스트리를 결정할 수 있는 능력에 있다.

도 1은 예시적인 환경(100)의 블록도이고, 여기서, 기술되는 시스템들 및/또는 방법들이 구현될 수 있다. 도 1의 실시예에서 도시된 바와 같이, 환경(100)은 네트워크(110), 서브-네트워크(120-A 내지 120-N) (전체적으로 "서브-네트워크들(120)" 및 개별적으로 "서브-네트워크(120)"으로 참조됨), 디바이스들 (130-A-A 내지 130-N-K) (전체적으로 "디바이스들(130)" 및 개별적으로 "디바이스(130)"으로 참조됨), 및 관리 장치(150)을 포함한다. 이 실시예에서, 환경(100) 내의 구성들(components)은 서비스 지향 아키텍쳐 (Service-Oriented Architecture, "SOA") 시스템 서비스 버스(140)를 형성한다.

네트워크(110)는 서브-네트워크들(120) 및/또는 디바이스들(130)이 서로 통신할 수 있게 한다. 네트워크(110)는 하나 또는 그 이상의 회선 교환 네트워크들(circuit switched networks) 및/또는 패킷 교환 네트워크들(packet switched networks)를 포함할 수 있다. 예를 들어, 일 실시예에서, 네트워크(110)은 근거리 네트워크(Local Area Network, "LAN"), 광역 네트워크(Wide Area Network, "WAN"), 대도시 네트워크(Metropolitan Area Network, "MAN"), 일반 전화 교환 네트워크(Public Switched Telephone Network, "PSTN"), 애드훅 네트워크(Ad hoc Network), 인트라넷, 인터넷, 광 섬유 기반 네트워크(Fiber Optic-based Network), 무선 네트워크(Wireless Network), 및/또는 이들 또는 다른 타입의 네트워크들의 결합을 포함할 수 있다.

서브-네트워크(120)은 LAN (예를 들어, 계층 2 네트워크) 및/또는 사설 네트워크 (예를 들어, 계층 3 네트워크)를 포함할 수 있다. 서브-네트워크(120)는 하나 또는 그 이상의 디바이스들(130)을 상호 연결시킬 수 있다. 예를 들어, 서브-네트워크(120-A)는 디바이스들(130-A-A 내지 130-A-J)를 상호 연결시킬 수 있다. 디바이스(130)는, 예를 들어, SOA 시스템 서비스 버스(140)를 통해 통신하도록 구성되는 임의의 디바이스를 포함할 수 있다.

디바이스(130)는 하이퍼텍스트 전처리기 (Hypertext Preprocessor, "PHP") 서버 디바이스, C 프로그램 서버 디바이스, 리눅스(Linux) 서버 디바이스, 윈도우(Windows) 서버 디바이스, 및/또는 다른 타입의 서버 디바이스; 데스크탑(desktop), 랩탑(laptop), 테블릿(tablet), 휴대용 통신 디바이스(mobile communication device), 및/또는 윈도우, 리눅스, 안드로이드, iOS 및/또는 다른 운영체제에서 작동하는 다른 타입의 개인용 컴퓨터 디바이스와 같은 개인용 컴퓨터 디바이스; 가시광 카메라(visible light camera), 적외선(IR) 카메라, 열 감지(heat signature) 카메라와 같은 감시 디바이스(monitoring device); 마이크로폰(Michrophone); 동작 센서(motion sensor), 열 센서, 압력 센서, 및/또는 다른 타입의 알람 센서와 같은 알람 센서(alarm sensor); 마이크로 제어 컴퓨터 디바이스(Microcontroller Computer Device); 및/또는 다른 타입의 컴퓨터 디바이스를 포함할 수 있다. 디바이스들(130)이 서브-네트워크(120)에 연결되는 것으로 도시되었으나, 특정 디바이스(130)은 네트워크(110)에 직접 연결될 수 있다.

일 실시예에서, SOA 시스템 서비스 버스(140)는 현재의 네트워크 접속 형태(existing network topology)의 최상층 상의 디바이스들(130) 사이에서 구현될 수 있다. SOA 시스템 서비스 버스(140)은 상이한 타입의 디바이스들(130), 및/또는 상이한 플랫폼들을 사용하여 구현되는 디바이스들(130)이 서비스 지향 아키텍쳐를 사용하여 통신할 수 있게 한다. SOA 시스템 서비스 버스(140)은 제1 디바이스(130)가 임의의 디바이스(130)(예를 들어, 그 자신 또는 다른 디바이스 (130))로부터의 특정 서비스를 요청할 수 있게 할 수 있다. 이에, 제1 디바이스(130)에 의해 호스팅 되는 클라이언트(예를 들어, "클라이언트 서비스" 또는 "서비스" 그 자신)는 (예를 들어, 제1 디바이스(130)가 가용하지 않을 때) 제2 디바이스(130)에 의해 호스팅되는 서비스를 호출(call upon)할 수 있다. (제2 디바이스(130) 내의) 다른 서비스를 요청하는 (예를 들어, 제1 디바이스 내의) 제1 서비스는 "클라이언트" 또는 "클라이언트 서비스"로서 그 요청을 개시한 것으로 지칭된다. 제1 서비스는 또한 예를 들어, 네트워크의 다른 서비스들에 서비스들을 제공할 수 있다.

일 실시예에서, 서비스는 표준화된 서비스 인터페이스를 통하여 접속(access)된다. 각각의 타입의 서비스는 특정 서비스 인터페이스(예를 들어, 상이한 서비스 인터페이스)에 연관될 수 있다. 이에, 서비스를 요청하는 클라이언트는 서비스 인터페이스와 통신할 수 있고, 그 클라이언트는 그 서비스이 실제 구현(implementation)에 관하여 모를 수 있다. 다시 말해, 서비스들의 구현들은 그 서비스 인터페이스들로 정의되는 프로토콜을 사용하여 서로 통신하며, 이로써, 각 서비스들의 구현은 다른 서비스들의 구현들과는 무관해야 한다. 특정 서비스 인터페이스에 연관되는 동작 중인 서비스 구현은 서비스 인스턴스로 지칭될 수 있다. 서비스 호스트(예를 들어, 서비스를 호스팅하는 디바이스)를 포함하는 디바이스(130)는 가용한 서비스 인스턴스를 서비스 레지스트리(예를 들어, 서비스들의 데이터 베이스 또는 리스트)에 기록할 수 있다. SOA 시스템 서비스 버스(140)는 디바이스들(130) 사이의 통신이, 디바이스들(130) 내의 서비스 호스트들의 서비스 레지스트리들을 검색함으로써, 요청된 서비스의 위치를 알아낼 수 있게 할 수 있다.

관리 장치(150)는 관리자가 SOA 시스템 서비스 버스(140)를 구성하거나 아니면 관리할 수 있게 한다. 예를 들어, 관리 장치(150)은 휴대용 통신 장치(예를 들어, 휴대폰, 스마트폰, 패블릿 기기, 위성 위치 확인 시스템(GPS) 기기, 및/또는 다른 타입의 무선 기기); 개인용 컴퓨터 또는 워크스테이션; 서버 디바이스; 랩탑, 태블릿, 또는 다른 타입의 휴대용 컴퓨터; 및/또는 통신 가능한 모든 타입의 디바이스를 포함할 수 있다.

네트워크(110)과 유사하게, 서브-네트워크(120)은 하나 또는 그 이상의 회선 교환 네트워크들(circuit switched networks) 및/또는 패킷 교환 네트워크들(packet switched networks)를 포함할 수 있다. 예를 들어, 서브-네트워크(120)은 LAN, WAN, MAN, PSTN, 애드훅 네트워크, 애드훅 네트워크, 인트라넷, 인터넷, 광 섬유 기반 네트워크, 무선 네트워크(Wireless Network), 및/또는 이들 또는 다른 타입의 네트워크들의 결합을 포함할 수 있다.

비록 도 1은 환경(100)의 예시적인 구성들을 도시하고 있으나, 다른 구현예들에서, 환경(100)은 도 1에 도시된 것에 비하여 더 적은 구성들, 상이한 구성들, 상이하게 배열되는 구성들, 또는 추가적인 구성들을 포함할 수 있다. 추가적으로 또는 대안적으로, 환경(100) 내의 임의의 일 디바이스(또는 임의의 디바이스들의 그룹)은 환경(100) 내의 하나 또는 그 이상의 다른 디바이스들에 의해 수행되는 것으로 기술된 기능들을 수행할 수 있다.

도 2는 디바이스(130)의 예시적인 구성들을 도시하는 블록도이다. 도 2에 도시된 바와 같이, 디바이스(130)은 버스(210), 프로세서(220), 메모리(230), 입력 디바이스(240), 출력 디바이스(250), 및 통신 인터페이스(260)을 포함할 수 있다.

버스(210)은 디바이스(130)의 구성들 사이의 통신을 허용하는 경로를 포함할 수 있다. 프로세서(220)는 명령어(instruction)을 해석 및 실행하는 임의의 타입의 싱글-코어 프로세서(single-core processor), 멀티-코어 프로세서(multi-core processor), 마이크로프로세서, 래치-기반 프로세서(latch-based processor), 및/또는 처리 로직(또는 프로세서들, 마이크로프로세서들, 및/또는 처리 로직들의 동종의 것)을 포함할 수 있다. 다른 실시예들에서, 프로세서(220)은 주문형 반도체(Application Specific Integrated Circuit, "ASIC"), 필드 프로그래머블 게이트 어레이(FPGA), 및/또는 다른 타입의 집적 회로 또는 처리 로직을 포함할 수 있다.

메모리(230)는, 프로세서(220)에 의한 실행을 위한 정보(information) 및/또는 명령어들을 저장할 수 있는 임의의 타입의 휘발성 및/또는 동적 저장 기기, 및/또는 프로세서(220)에 의한 사용을 위한 정보를 저장할 수 있는 임의의 타입의 비휘발성 저장 기기를 포함할 수 있다. 예를 들어, 메모리(230)는 랜덤 억세스 메모리(Random Access Memory, "RAM") 또는 다른 타입의 동적 저장 기기, 리드 온리 메모리(Read Only Memory, "ROM") 기기 또는 다른 타입의 정적 저장 기기, 내용 주소화 저장 장치(Content Addressable Memory, "CAM"), 자기 및/또는 광학 기록 메모리 기기 및 그것의 상응하는 드라이브(예를 들어, 하드 디스크 드라이브, 광학 드라이브 등), 및/또는 플래시 매모리와 같은 착탈 형태의 메모리를 포함할 수 있다.

입력 디바이스(240)은 운영자가 디바이스(130)에 정보를 입력하는 것을 가능케 할 수 있다. 입력 디바이스(240)은, 예를 들어, 키보드, 마우스, 펜, 마이크로폰, 원격 제어, 오디오 캡쳐 기기, 이미지 및/또는 비디오 캡쳐 기기, 터치 스크린 디스플레이, 및/또는 다른 타입의 입력 디바이스를 포함할 수 있다. 일 실시예에서, 디바이스(130)은 원격으로 관리될 수 있고, 입력 디바이스(240)을 포함하지 않을 수 있다. 다시 말해서, 디바이스(130)은 "헤드리스(headless)"일 수 있고, 예를 들어, 키보드를 포함하지 않을 수 있다.

출력 디바이스(250)은 디바이스(130)의 운영자에게 정보를 출력할 수 있다. 출력 디바이스(250)은 디스플레이, 프린터, 스피커, 및/또는 다른 타입의 출력 디바이스를 포함할 수 있다. 예를 들어, 디바이스(130)은 디스플레이를 포함할 수 있고, 이때, 디스플레이는 고객(customer)에게 컨탠츠를 표시하기 위한 액정 디스플레이(Liquid Crystal Display, "LCD")를 포함할 수 있다. 일 실시예에서, 디바이스(130)은 원격으로 관리될 수 있고, 출력 디바이스(250)을 포함하지 않을 수 있다. 다시 말해서, 디바이스(130)은 "헤드리스(headless)"일 수 있고, 예를 들어, 디스플레이를 포함하지 않을 수 있다.

통신 인터페이스(260)는, 디바이스(130)이 다른 디바이스들 및/또는 시스템들과 통신하는 것을 가능케 하는 송수신기(transceiver)(예를 들어, 송신기 및/또는 수신기)를 포함할 수 있다. 통신 인터페이스(260)는, 무선 통신들(예를 들어, 무선 주파수, 적외선, 및/또는 가시광 등), 유선 통신들(예를 들어, 도선(conductive wire), 연선 케이블(twisted pair cable), 동축 케이블(coaxial cable), 전송 선로(transmission line), 광섬유 케이블(fiber optic cable), 및/또는 도파관(waveguide) 등), 또는 무선 통신 및 유선 통신들의 조합을 통해 통신할 수 있다. 통신 인터페이스(260)은 기저 대역 신호들(baseband signals)을 무선 주파수(Radio Frequency, "RF") 신호들로 변환하는 송신기 및/또는 RF 신호들을 기저 대역 신호들로 변환하는 수신기를 포함할 수 있다. 통신 인터페이스(260)은 신호들을 전송하고 수신하기 위한 안테나에 연결될 수 있다.

통신 인터페이스(260)은 입력 및/또는 출력 포트들, 입력 및/또는 출력 시스템들, 및/또는 다른 디바이스들로의 데이터의 송신을 용이하게 하는 다른 입력 및 출력 구성들을 포함하는 논리 구성(logical component)을 포함할 수 있다. 예를 들어, 통신 인터페이스(260)는 유선 통신들을 위한 네트워크 인터페이스 카드(예를 들어, 이너넷 카드(Ethernet card)) 및/또는 무선 통신들을 위한 무선 네트워크 인터페이스(예를 들어, WiFi) 카드를 포함할 수 있다. 통신 인터페이스(260)은 또한 케이블을 통한 통신을 위한 범용 직렬 버스(Universal Serial Bus, "USB") 포트, 블루투스 무선 인터페이스, 전파 식별(Radio Frequency Identification, "RFID") 인터페이스, 근거리 무선 통신(Near Field Communication, "NFC") 무선 인터페이스, 및/또는 데이터를 하나의 형태에서 다른 형태로 변환하는 임의의 다른 타입의 인터페이스를 포함할 수 있다.

아래에서 기술되는 바와 같이, 디바이스(130)은 SOA 네트워크 내에서 서비스들(예를 들어, 가까운 서비스들)을 탐색하는 것과 관련된 특정 동작들을 수행할 수 있다. 디바이스(130)은 메모리(230)와 같은 컴퓨터에서 판독가능한 매체 내에 포함되는 소프트웨어 명령어들을 실행하는 프로세서(220)에 응답하여 이러한 동작들을 수행할 수 있다. 컴퓨터에서 판독가능한 매체는 비-일시적인 메모리(non-transitory memory) 디바이스를 포함할 수 있다. 메모리 디바이스는 단일 물리적 메모리 디바이스 내에서 구현되거나 다수의 물리적 메모리 디바이스들에 걸쳐 퍼져서 구현될 수 있다. 소프트웨어 명령어들은 다른 컴퓨터에서 판독가능한 매체로부터 또는 다른 디바이스로부터 메모리(230) 내로 읽혀질 수 있다. 메모리(230) 내에 포함되는 소프트웨어 명령어들은 프로세서(220)가 본 명세서에서 기술되는 프로세스들을 수행하도록 할 수 있다. 대안적으로, 고정 배선(hardwired) (예를 들어, 고정된) 회로가 본 명세서에서 기술되는 프로세스들을 구현하는 소프트웨어 명령어들을 대신하여, 또는 소프트웨어 명령어들과 결합하여 사용될 수 있다. 이에, 본 명세서에서 기술되는 구현예들은 고정 배선 회로 또는 소프트웨어의 어떠한 특정 조합에 한정되지 않는다.

비록, 도 2는 디바이스(130)의 예시적인 구성들을 도시하고 있으나, 다른 구현예들에서, 디바이스(130)는 도 2에 도시된 것에 비하여 더 적은 구성들, 상이한 구성들, 추가적인 구성들, 또는 상이하게 배열된 구성들을 포함할 수 있다. 추가적으로 또는 대안적으로, 디바이스(130)의 하나 또는 그 이상의 구성들은 디바이스(130)의 하나 또는 그 이상의 구성들에 의해 수행되는 것으로 기술되는 하나 또는 그 이상의 작업들(tasks)을 수행할 수 있다. 관리 장치(150)은 디바이스(130)과 유사하게 구성될 수 있다.

도 3은 디바이스(130)의 예시적인 통신 계층들을 도시하는 블록도이다. 디바이스(130)의 기능적인 구성들은, 예를 들어, 메모리(230)로부터의 명령어들을 실행하는 프로세서(220)에 의해 구현될 수 있다. 추가적으로 또는 대안적으로, 디바이스(130)의 기능적인 구성들은 하나 또는 그 이상의 ASIC들의 고정 배선(예를 들어, 고정된) 회로를 통해 구현될 수 있다. 도 3에 도시된 바와 같이, 디바이스(130)은 서비스 계층(310), 오버레이 네트워크 계층(320), 및 디바이스 계층(330)을 포함할 수 있다.

일 실시예에서, 서비스 계층(310)은 클라이언트들이 특정 서비스 타입의 서비스 인스턴스들을 검색할 수 있게 하고 클라이언트들이 특정 서비스 인스턴스에 요청들을 전송할 수 있게 한다. 서비스는 표준화된 서비스 인터페이스를 통하여 억세스될 수 있고, 일 실시예에서, 표준화된 서비스 인터페이스는 그 서비스의 실제 구현에 관하여 모를 수 있다. 서비스 인스턴스는 명시적인 경계들(explicit boundaries)에 연관될 수 있다. 이러한 실시예에서, 디바이스(130) 상에서 동작하는 특정 프로세서, 및/또는 디바이스(130) 상에 저장된 특정 데이터 각각은 명확하게 서비스 인스턴스 내에 또는 서비스 인스턴스 외부에 위치한다. 서비스 인스턴스는 다른 서비스 인스턴스들에 관하여 자율적일 수 있다. 예를 들어, 특정 서비스 인스턴스는 그 특정 서비스 인스턴스와 상호작용하는 다른 서비스 인스턴스들에 부정적인 영향을 끼치지 않고 변경될(예를 들어, 코드가 재작성될) 수 있다. 서비스는 기법(scheme) 및/또는 약속(contract)를 (동일한 타입의 또는 다른 타입의) 다른 서비스 인스턴스와 공유할 수 있으나, 일 실시예에서, 특정 서비스 인스턴스는 그 서비스의 구현은 공유하지 않는다. 기법은 서비스 인터페이스에 의해 전송되거나 수신되는 메세지들의 포맷 및 내용을 구체화한다. 약속은 서비스 인터페이스에 의해 전송되거나 수신되는 허용가능한 일련의 메세지들을 구체화한다.

일 실시예에서, 오버레이 네트워크 계층(320)은 현재의 네트워크 접속 형태(existing network topology)의 최상층 상의 오버레이 네트워크를 구현한다. 오버레이 네트워크(320)은 방화벽들(firewalls)을 통과하는 라우팅 트래픽 및/또는 언더라잉 네트워크 접속 형태(underlying network topology) 내에서 네트워크 주소 번역(Network Address Translation, “NAT”)을 처리하는 것의 원인이 될 수 있다. 일 실시예에서, (예를 들어, 언더라잉 네트워크 접속 형태와 상이할 수 있는) 오버레이 네트워크 접속 형태는 트리 구조(tree structure) 내에서 조직되는 노드들을 포함할 수 있다. 오버레이 네트워크 접속 형태는 논리적으로 노드들에 연결된다. 다른 실시예들에서, 오버레이 네트워크 접속 형태는 상이한 타입의 구조(예를 들어, 메쉬 접속 형태(mesh topology))를 포함할 수 있다. 디바이스(130) 내의 각각의 서비스 호스트는 오버레이 네트워크 내의 일 노드에 상응할 수 있고, 일 노드 식별자(identifier, “ID”)에 할당될 수 있다. 위에서 언급한 바와 같이, 디바이스(130)은 다수의 서비스 호스트들 및/또는 다수의 노드들을 포함할 수 있다. 디바이스(130)은 하나의 노드에 상응하는 하나의 호스트를 포함하는 것으로 기술될 수 있다. 노드들은 라우팅 트리(routing tree)와 같은 접속 형태를 통하여 연결될 수 있고, 일 노드는 라우팅 트리를 통해 다른 노드에 메세지를 전달할 수 있다. 일 실시예에서, 일 노드는 오버레이 네트워크 접속 형태를 운행(traverse)하는 메시지 없이 언더라잉 네트워크 접속 형태를 통해 메세지를 다른 노드에 전달할 수 있다. 각각의 노드는 오버레이 네트워크(뿐만 아니라 언더라잉 네트워크도) 그 이웃들에 닿도록 정보(예를 들어, 네트워크(110)과 같은 언더라잉 네트워크의 주소)를 저장할 수 있다. 오버레이 네트워크 계층(320)은 노드들 사이의 통신 계층에 대응될 수 있고, 특정 기능을 실현하는 다수의 네트워크 접속 형태를 사용할 수 있다. 예를 들어, 특정 타입의 서비스에 대한 서비스 레지스트리들을 검색할 때, 오버레이 네트워크 계층(320)은 노드들의 트리의 에지들(edges)을 운행(traverse)하면서, 서비스 레지스트리들을 통한 검색을 할 수 있다. 일 실시예에서, 제1 노드로부터 제2 노드로 메세지를 전송할 때, 오버레이 네트워크 계층(320)은 트리의 에지들을 추종하는 것에 의한 것 대신에 제1 노드로부터 제2 노드로 직접 그 메세지를 전달 할수 있다. 오버레이 네트워크 계층(320)은 노드 ID들을 서비스 계층(310)에 제공할 수 있고 서비스 계층(310)은 메세지들을 특정 노드 ID들에 언더라잉 네트워크 접속 형태를 알 필요 없이 전송할 수 있다.

일 실시예에서, 디바이스 계층(330)은 SOA 시스템 디바이스 버스(140)의 초기 설치 동안 디바이스 검색을 수행한다. 디바이스 계층(330) 및/또는 오버레이 네트워크 계층(320)은 또한 초기 설치에 후속하여 노드 검색을 수행할 수 있고, 및/또는 오프라인 상태가 되었다가 나중에 오버레이 네트워크에 재접속된 잃어버린 노드들을 재검색할 수 있다. 일 실시예에서, 오버레이 네트워크 계층(320)은 노드들이 서로의 정체를 확인할 수 있게 하는, 인증서와 같은 오버레이 네트워크에 대한 비밀을 관리할 수 있다. 오버레이 네트워크 계층(320)은 하나 또는 그 이상의 근거리 매트릭스(metrics of nearness)를 기초로 오버레이 네트워크에 대한 접속 형태(예를 들어, 라우팅 트리 또는 매쉬(routing tree or mesh))를 형성할 수 있다. 그러나, 제1 노드로부터 제2 노드로 가는 메시지는 라우팅 트리를 운행(traverse)할 것이 요구되지 않고, 대신에 제1 노드로부터 제2 노드로 직접 전달될 수 있다. 다른 실시예에서, 제1 노드로부터 제2 노드로 가는 메시지는 라우팅 트리를 운행(traverse)한다. 또한, 오버레이 네트워크 계층(320)은 멀티캐스트 그룹들(multicast groups)를 기초로 멀티캐스트 메시지들을 전송할 수 있다. 또한, 오버레이 네트워크 계층(320)은 서비스 품질(quality of service, “QoS”) 보증(guarantee)를 서비스 계층(310)에 제공할 수 있다.

네트워크 계층(320)은 일반적으로 “노드들”을 다루고, 디바이스 계층(330)은 일반적으로 “디바이스들”을 다룬다. 디바이스 계층(330)은, 언더라잉 네트워크 접속 형태(underlying network topology)(예를 들어, 네트워크(110) 및/또는 서브-네트워크(120))를 사용하는 통신에 필요한 기능을 포함하는 디바이스(130)의 기능의 가장 하위 레벨들에 대응된다. 예를 들어, 디바이스 계층(330)은 개방형 시스템 간 상호 접속(Open Systems Interconnection, “OSI”) 모델(예를 들어, 물리 계층, 데이터 링크 계층, 네트워크 계층, 전송 계층, 세션 계층, 표현 계층)의 계층 1 내지 계층 6을 구현할 수 있다. 이러한 계층들의 구현은 이더넷 프레임들(Ethernet frames)을 라우팅하는 것, 인터넷 프로토콜(Internet Protocol, “IP”) 패킷들을 라우팅 하는 것, 세션 관리(session management), 패킷들을 암호호화 및 복호화하는 것, 유실 패킷들을 재 전송하는 것 등을 포함할 수 있다.

도 3은 디바이스(130)의 예시적인 기능적인 구성들을 도시하고 있으나, 다른 구현예에서, 디바이스(130)은 도 3에 도시된 실시예에 비하여 더 적은 기능적인 구성들, 상이한 기능적인 구성들, 상이하게 배열된 기능적인 구성들, 또는 추가적인 기능적인 구성들을 포함할 수 있다. 더하여, 디바이스(130)의 구성들 중 임의의 하나(또는 구성들 중 임의의 그룹)는 디바이스(130)의 하나 또는 그 이상의 다른 기능적 구성들에 의해 수행되는 것으로 기술되는 기능들을 수행할 수 있다.

도 4a는 서비스 계층(310)의 예시적인 기능적인 구성들을 도시하는 블록도이다. 도 4a에 도시된 바와 같이, 서비스 계층(310)은 서비스 호스트(415)를 포함한다. 서비스 호스트(415)는 하나 또는 그 이상의 서비스들(410-A 내지 410-N)(전체적으로 "서비스들(410)" 및 개별적으로 "서비스(410)"으로 참조됨), 하나 또는 그 이상의 클라이언트들(420-A 내지 420-K)(전체적으로 "서비스들(410)" 및 개별적으로 "서비스(410)"으로 참조됨), 메시지 전송부(message dispatcher)(430), 및 서비스 레지스트리(440)를 포함할 수 있다.

서비스(410)은 디바이스(130)의 서비스 계층(310)의 서비스 호스트(415)에 연관된 서비스 인스턴스(service instance)에 대응된다. 일 실시예에서, 서비스(410)은 서비스 인터페이스(412) 및 서비스 구현(414)을 포함한다. 서비스 인터페이스(412)는 표준화된 통신 프로토콜과 같은 통신 프로토콜을 포함할 수 있다. 일 구현 예에서, 통신 프로토콜은 특유한(unique) 이름 및 버전을 포함한다. 서비스 인터페이스(412)는 단순 객체 접근 프로토콜(Simple Object Access Protocol, "SOAP") 인터페이스 규격, 자바스크립트 객체 표기법(JavaScript Object Notation, "JSON") 인터페이스 규격, 및/또는 다른 타입의 인터페이스 규격을 사용하여 구체화 될 수 있다. 서비스 구현(414)는 서비스(410)의 구현을 포함한다. 서비스 구현(414)은, 서비스 인터페이스(412)를 통해 수신된 요청들을 처리하고, 및/또는 서비스 인터페이스(412)를 통하여 서비스 요청들에 응답한다. 서비스 인터페이스(412)는 서비스 구현(414)로부터 수신된 응답들을 클라이언트(420)가 서비스(410)와 메시지들을 교환하기 위하여 사용하는 데 적합한 특정 포맷으로 변환할 수 있다.

일 실시예에서, 클라이언트(420)는 서비스 레지스트리(440)에 요청을 전달함으로써 특정 서비스 타입의 서비스 인스턴스를 요청할 수 있다. 서비스 인스턴스가 식별되고 선택되는 경우, 클라이언트(420)은 메시지 전송부(430)을 통해 식별되고 선택된 특정 서비스 인스턴스에 요청을 전달할 수 있다. 위에서 기술된 바와 같이, 클라이언트(420)은 또한 서비스들(410)일 수 있다. 용어 "클라이언트" 또는 "클라이언트 서비스"는 서비스를 다른 서비스를 요청하는 것으로 식별한다.

메시지 전송부(430)는 클라이언트(420)로부터 들어오는 메시지들을 수신하고 그것들을 들어오는 메시지의 의도된 수신지인 서비스(410)로 전달한다. 또한, 메시지 전송부(430)는 서비스로부터 메시지들을 수신할 수 있고, 메시지를 특정 클라이언트(420)에 전송할 수 있다. 들어오는 메시지의 목적지가 메시지 전송부(430)과 같은 디바이스(130) 상에 있지 않다면, 메시지는 정확한 디바이스(130)에 포워딩하기 위하여 오버레이 네트워크 계층(320)으로 포워딩될 수 있다. 서비스들(410) 및 클라이언트들(420)은 오버레이 네트워크 계층(320)에 의해 구현되는 오버레이 네트워크 내의 종단점(endpoint)로 기능할 수 있다. 이에, 일 실시예에서, 오버레이 네트워크 계층(320)은 오버레이 네트워크의 라우팅 트리를 기초로 라우팅 테이블을 유지할 수 있다. 라우팅 테이블은 특정 노드 ID들에 대한 다음 홉(next hop) 목적지들의 리스트를 포함할 수 있다. 메시지 전송부(430)는 나가는(outgoing) ID에 대한 다음 홉 목적지를 식별할 수 있고, 전달을 위하여 메시지를 오버레이 계층에 제공할 수 있다. 이에 따라, 이러한 실시예에서, 메시지 전송부(430)은 요청-응답 메시징 기법(request-response messaging mechanism)을 구현한다.

서비스 레지스트리(440)는 배치된(deployed) 서비스들(예를 들어, 서비스들의 인스턴스들)에 연관된 프로퍼티들과 함께 배치된 서비스들(410)의 리스트를 유지할 수 있다. 서비스 레지스트fl(440)의 예시적인 구성들이 도 4c를 참조하여 아래에서 더 상세하게 기술된다. 서비스(410)는 서비스 레지스트리(440)에 (예를 들어, 서비스의 프로퍼티들을 포함하는) 서비스의 상세 내역(description)을 서비스 레지스트(440)에 제공함으로써 서비스 레지스트리(440)에 등록(register)할 수 있다. 클라이언트들(420)은 또한 서비스들(410)일 수 있기 때문에, 클라이언트들(420)은 또한 서비스 레지스트리(440)에 등록할 수 있다.

도 4b는 서비스 레지스트리(440)의 기능을 도시하는 블록도이다. 도 4b에 도시된 바와 같이, 서비스 레지스트리(440)는 검색 쿼리들(search queries)을 클라이언트들(420)로부터 수신할 수 있다. 검색 쿼리는 특정 서비스 타입, 특정 서비스 타입에 대한 하나 또는 그 이상의 요청된 프로퍼티들, 요청된 히트 수(number of hits), 및/또는 하나 또는 그 이상의 다른 파라미터들을 구체화할 수 있다. 서비스 레지스트리(440)은 검색 쿼리를 만족하는 서비스(410)를 식별할 수 있다. 서비스 레지스트리(440)에 의하여, 요청된 히트 수가 만족되지 못하면, 서비스 레지스트리(440)은 쿼리를 오버레이 네트워크 내에서 다른 서비스 레지스트리(440)(예를 들어, 인접하는 서비스 레지스트리(440))에 포워딩할 수 있다. 일 실시예에서, 서비스 레지스트리(440)는 특정 서비스 인스턴스를 검색 쿼리를 기초로 선택하지 않는다. 다만, 이러한 실시예에서, 서비스 레지스트리(440)은 쿼리의 결과들을 클라이언트(420)에게 반환(return)하고, 그 쿼리를 발생시켰던 클라이언트(420)는 검색 결과들로부터 특정 서비스 인스턴스를 선택할 수 있다. 다른 실시예에서, 서비스 레지스트리(440)은 쿼리의 결과들로부터 특정 서비스 인스턴스를 검색 쿼리를 기초로 선택할 수 있다.

비록 도 4a 및 4b는 서비스 계층(310)의 예시적인 기능적인 구성들을 도시하고 있으나, 다른 구현 예들에서, 서비스 계층(310)은 도 4a 및 4b에 도시된 것에 비하여 더 적은 기능적인 구성들, 상이한 기능적인 구성들, 상이하게 배열된 기능적인 구성들, 또는 추가적인 기능적인 구성들을 포함할 수 있다. 또한, 서비스 계층(310)의 구성들 중 임의의 일 구성 (또는 구성들의 임의의 그룹)은 서비스 계층(310)의 하나 또는 그 이상의 다른 기능적인 구성들에 의해 수행되는 것으로 기술되는 기능들을 수행할 수 있다.

도 4c는 서비스 레지스트리(440)의 예시적인 기능적인 구성들을 도시하는 블록도이다. 도 4c에 도시된 바와 같이, 서비스 레지스트리(440)은 호스트 서비스 레지스트리 데이터베이스(DataBase, "DB")(442), 쿼리 핸들러(query handler)(444), 서비스 레지스트리 캐시(service registry cache)(446)을 포함할 수 있다.

호스트 서비스 레지스트리 DB(442)는 서비스 호스트(415)에 의해 호스팅되는 서비스들(410) 및/또는 그 서비스들의 프로퍼티들의 리스트를 유지할 수 있다. 도 4c에 관하여, 호스트 서비스 레지스트리 DB(442) 내에 기록된(listed) 일 서비스 및 그 서비스의 프로퍼티들의 예시가 아래에서 제공된다. 호스트 서비스 레지스트리 DB(442)는 서비스들(410)을 서비스 레지스트리(440)에 등록함으로써 증식될(populated) 수 있다.

호스트 서비스 레지스트리 DB(442)는 또한 기록된 서비스들을 추가 또는 삭제하기 위한 또는 서비스 호스트(415)에 의해 호스팅되는 서비스들의 프로퍼티들을 독출(reading) 또는 기입(writing)하기 위한 인터페이스를 노출시킬(expose) 수 있고, 및/또는 서비스 프로퍼티들을 기입할 수 있다. 일 실시예에서, 예를 들어, 호스트 서비스 레지스트리 DB(442)는 상이한 디바이스(130) 상에서 서비스 호스트(415)에 의해 호스팅되는 서비스들(410)의 리스트를 유지할 수 있다. 상이한 디바이스 상의 서비스 호스트(415)는 그것의 서비스들을 노출된 인터페이스를 사용하는 다른 디바이스 상의 서비스 레지스트리 내에 기록(list)할 수 있다. 또한, 호스트 서비스 레지스트리 DB(442)는 다른 서비스 레지스트리들에 의해 접근 가능한 검색 쿼리 서비스 인터페이스를 노출시킬 수 있다. 따라서, 다른 서비스 레지스트리들은 호스트 서비스 레지스트리 DB(442)가 특정 쿼리를 만족하는 입력(entry)을 포함하는 지 여부를 결정하기 위하여 검색 쿼리 서비스 인터페이스를 사용할 수 있다. 일 실시에에서, DB(442)가 만료된(outdated) 정보를 저장하는 것을 방지하기 용이하도록 호스트 서비스 레지스트리 DB(442)에 기록된 서비스들은 (예를 들어, 재생(refresh)되지 않는 한, 일 시간 구간이 지난 후에 DB(442)로부터 삭제되어) 종료(expired)될 수 있다.

쿼리 핸들러(444)는 클라이언트(420)으로부터 수신된 쿼리들을 처리할(handle) 수 있다. 일 실시예에서, 쿼리가 주어지면, 쿼리 핸들러(444)는 우선 로컬 호스트 서비스 레지스트리 DB(442)를 검색하고, 이어서, 서비스 레지스트리 캐시(446)를 검색한다. 쿼리 핸들러(444)는 예를 들어 쿼리가 만족되지 못한다면 다른 서비스 레지스트에 요청할 수 있다. 서비스 레지스트리 캐시(446)은 원격 서비스 레지스트리(440)로부터의 데이터를 저장할 수 있다. 각 서비스 호스트(415)는 로컬 서비스 레지스트(440) 및 서비스 호스트(415)에 등록한 서비스들로서 로컬 서비스 레지스트(440) 내에 등록된 서비스들(410)을 유지할 수 있다. 로컬 서비스 레지스트리(440)에 의해 만족되지 못하는 클라이언트(420)로부터의 쿼리는, 이웃하는 서비스 호스트들(415)이 그 쿼리를 만족하는 서비스들을 포함하는 서비스 레지스트리들(440)을 갖는지를 알기 위해, 하나 또는 그 이상의 이웃하는 서비스 호스트들(415)에 전달될 수 있다. 원격 서비스 레지스트리(440)은 쿼리의 결과들을 로컬 서비스 레지스트리(440)에 다시 반환할 수 있고, 그 결과들은 서비스 레지스트리 캐시(446)에 저장될 수 있다. 몇몇 구현 예들에서, 부모 노드들(parent nodes)은 그들의 자식 노드들(children nodes)에 대한 데이터를 캐시에 저장(cache)할 수 있고, 이때, 자식 노드들은 그들의 부모 노드들에 대한 데이터를 캐시에 저장하지 않을 수 있다. 일 실시예에서, 캐시(446)이 만료된 정보를 저장하는 것을 방지하기 용이하도록 서비스 레지스트리 캐시(446) 내에 기록된 서비스들은 (예를 들어, 재생(refresh)되지 않는 한, 일 시간 구간이 지난 후에 캐시(446)으로부터 삭제되어) 종료(expired)될 수 있다.

비록 도 4c는 서비스 레지스트리(440)의 예시적인 기능적인 구성들을 도시하고 있으나, 다른 구현 예들에서, 서비스 레지스트리(440)는 도 4c에 도시된 것에 비하여 더 적은 기능적인 구성들, 상이한 기능적인 구성들, 상이하게 배열된 기능적인 구성들, 또는 추가적인 기능적인 구성들을 포함할 수 있다. 또한, 서비스 레지스트리(440)의 구성들 중 임의의 일 구성(또는 구성들의 임의의 그룹)은 서비스 레지스트리(440)의 하나 또는 그 이상의 다른 기능적인 구성들에 의해 수행되는 것으로 기술되는 기능들을 수행할 수 있다.

도 4d는 특정 서비스에 대한 예시적인 프로퍼티 테이블(460)의 블록도이다. 일 실시예에서, 서비스의 인스턴스(예를 들어, 각각의 인스턴스)는 테이블(460)과 같은 프로퍼티 테이블에 연관된다. 호스트 서비스 레지스트리 데이터베이스 DB(442)는 상응하는 서비스 레지스트리(440)에 등록된 각각의 서비스에 대한 프로퍼티 테이블을 저장할 수 있다. 일 실시예에서, 위에서 기술된 바와 같이, 임의의 일 서비스 레지스트리 DB(442) 내에 저장된 정보는 다른 서비스 레지스트리 데이터베이스들에 저장된 정보와 상이할 수 있다. 예시적인 프로퍼티 테이블(460)은 여덟 개의 필드들: ID 필드(462), 인터페이스 필드(464), 서비스 포맷 필드(468), 전송 프로토콜 필드(470), CPU 랭킹(ranking)(472), 디스크 용량 필드(474), 및 램(RAM) 필드(476)를 포함할 수 있다.

인스턴스 ID 필드(462)는 특정 서비스의 인스턴스를 특유하게(uniquely) 정의한다. 인스턴스 ID는 (가능하다면 노드 ID와 함께) 네트워크 내의 (동일한 타입 또는 상이한 타입의) 임의의 다른 서비스들로부터 서비스 인스턴스를 특유하게 식별할 수 있다. 일 실시예에서, 인스턴스 ID 필드(462)는 정수이다. 테이블(460)에서, 인스턴스 ID는 예시적으로 6529이다.

인터페이스 필드(464)는 서비스의 인터페이스의 이름을 식별한다. 이 경우, 인터페이스 필드(464)는 또한 서비스의 타입을 인터페이스의 타입에 의해 식별할 수 있다. 예를 들어, 테이블(460)은 인터페이스를 "저장 서비스(STORAGE SERVICE)"로 식별할 수 있다. 서비스 포맷 필드(468)은 서비스의 인스턴스에 의해 사용되는 포맷을 식별한다. 예시적으로, 테이블(460)은 서비스 포맷을 "JSON"으로 식별한다. 전송 프로토콜 필드(470)은 서비스의 인스턴스에 의해 사용되는 프로토콜을 식별한다. 예시적으로, 테이블(460)은 서비스 포맷을 "노드 프로토콜(NODE PROTOCOL)"로 식별한다.

CPU 랭킹 필드(472)는 서비스 인스턴스와 연관된 CPU의 성능을 식별한다. 일 실시예에서, (예를 들어, 1 내지 100인) 척도가 사용된다. 테이블(460)은 CPU 랭킹 필드(472) 내의 서비스에 대하여 CPU 랭킹을 20/100으로 식별한다. 램(RAM) 필드(476)는 서비스에서 가용한 랜덤 억세스 메모리의 용량을 식별한다. 테이블(460)은 가용한 램(RAM)을 필드(476) 내에서 2GB로 식별한다.

비록 도 4d는 프로퍼티 테이블(460)의 예시적인 구성들을 도시하고 있으나, 다른 구현 예에서, 프로퍼티 테이블(460)은 도 4d에 도시된 것에 비하여 더 적은 구성들, 상이한 구성들, 상이하게 배열된 구성들, 또는 추가적인 구성들을 포함할 수 있다.

도 5a는 오버레이 네트워크 계층(320)의 기능적인 구성들을 도시하는 블록도이다. 도 5a에 도시된 바와 같이, 오버레이 네트워크 계층(320)은 노드 관리자(node manager)(510), 통신 관리자(communication manager)(520), 및 멀티캐스트 관리자(multicast manager)(530)를 포함할 수 있다. 노드 관리자(510)은 노드 ID와 같은 노드 정보를 오버레이 네트워크 내의 다른 노드들에 제공할 수 있다. 또한, 노드 관리자(510)은 오버레이 네트워크 내의 노드들의 리스트를 유지할 수 있다. 노드 관리자(510)은 오버레이 네트워크에 추가된 새로운 노드들을 식별하기 위해 및/또는 오버레이 네트워크에 다시 접속(re-join)한 유실된 노드들을 재탐색(rediscover)하기 위하여 노드 탐색을 수행할 수 있다. 노드 관리자(510)은 또한 네트워크의 접속 형태(topology)를 아래에서 기술되는 바와 같이(예를 들어, 노드들은 가장 가까운 다른 노드들임) 결정할 수 있다.

통신 관리자(520)는 노드들이 서로 통신할 수 있게 할 수 있다. 통신 관리자(520)는 오버레이 네트워크의 트리를 운행(traverse)하기 위한 기법(mechanism)을 구현할 수 있다. 트리 운행법(tree traversal)은, 서비스 레지스트리들의 검색 쿼리들과 연관되어, 또는 다른 노드에 직접 통신 방법(direct communication method)을 사용할 수 없을 때, 수행될 수 있다. 또한, 통신 관리자(520)는 오버레이 네트워크의 트리를 운행할 필요 없이 오버레이 네트워크의 특정 노드들이 직접 통신할 수 있게 하는 직접 통신 방법을 구현할 수 있다.

멀티캐스트 관리자(530)은 멀티캐스트 기법(multicast mechanism)을 구현할 수 있다. 멀티캐스트 기법은 멀티캐스트 그룹의 구성원들(예를 들어, 모든 구성원들)에게 메시지를 전송하도록 사용될 수 있다. 또한, 멀티캐스트 기법은 구독-통지 메시징 패턴(subscribe-notify messaging pattern)을 구현하도록 사용될 수 있다. 이에, 특정 서비스 인스턴스에 연관된 이벤트는 특정 서비스 인스턴스로부터의 메시지들을 구독(subscribe)하는 노드들에 전송되는 메시지를 촉발(trigger)하도록 사용될 수 있다. 멀티캐스트 관리자(530)는 어플리케이션 계층 멀티캐스트 관리자 또는 하위 OSI 계층들로부터의 멀티캐스트 관리자를 포함할 수 있다.

비록 도 5a는 오버레이 네트워크 계층(320)의 예시적인 기능적인 구성들을 도시하고 있으나, 다른 구현 예들에서, 오버레이 네트워크 계층(320)은 도 5a에 도시된 것에 비하여 더 적은 기능적인 구성들, 상이한 기능적인 구성들, 상이하게 배열된 기능적인 구성들, 또는 추가적인 기능적인 구성들을 포함할 수 있다. 또한, 오버레이 네트워크 계층(320)의 구성들 중 임의의 일 구성(또는 구성들 중 임의의 그룹)은 오버레이 네트워크 계층(320)의 하나 또는 그 이상의 다른 기능적인 구성들에 의해 수행되는 것으로 기술되는 기능들을 수행할 수 있다.

도 5b는 오버레이 네트워크(540)의 예시적인 접속 형태(topology)의 블록도이다. 도 5b의 예시에서 기술된 바와 같이, 오버레이 네트워크(540)은 노드들(N1 내지 N7)을 포함한다. 노드들(N1 및 N2)은 멀티캐스트 그룹(560-1) 내에 있다. 노드(N1)은 서비스 종단점들(service endpoint)(S1 및 S3) 및 클라이언트 종단점(C1)을 포함한다. 노드(N3)은 노드(N1 및 N2)에 대한 부모 노드이다. 노드(N3)는 서비스 종단점(S7) 및 클라이언트 종단점(C3)를 포함한다.

노드들(N6 및 N7)은 멀티캐스트 그룹(560-2) 내에 있고, 노드(N7)는 클라이언트 종단점(C2) 및 서비스 종단점(S5 및 S6)를 포함한다. 노드(N5)는 노드들(N6 및 N7)에 대한 부모 노드이고 서비스 종단점(S9)를 포함한다. 노드들(N3 및 N5)는 멀티캐스트 그룹(560-3) 내에 있다. 노드(N4)는 노드들(N3 및 N5)에 대한 부모 노드이고, 오버레이 네트워크(540)의 뿌리 노드(root node)이다. 또한, 노드(N4)는 멀티캐스트 그룹(560-4) 내에 있고 서비스 종단점(S8)을 포함한다. 비록 네트워크(540)의 접속 형태(topology) 내에서, 부모 노드들이 두 개의 자식 노드들을 가지고 있으나, 다른 구현 예들에서, 부모 노드들은 두 자식 노드들 이상의 노드들을 가질 수 있다.

각각의 종단점이 서비스 레지스트리(440)에 연관되는 것으로 가정할 때, 검색 쿼리는 오버레이 기능 네트워크(540)를 다음과 같이 운행할 수 있다. 서비스 종단점(S1) 및 서비스 종단점(S5) 내에 포함되는 (즉, S1 및 S5가 매칭(match)되는) 특정 서비스를 탐색(예를 들어, 식별 또는 검색) 하도록 서비스 종단점(S7)이 검색 쿼리를 실행하는 것이 가정된다. 서비스 종단점(S7)은 그것의 로컬 서비스 레지스트리에 검색 쿼리를 전송할 수 있고, 이는 검색 쿼리 내에 아무런 매치들(matches)도 없게 할 수 있다. 그러면 로컬 서비스 레지스트리는 오버레이 네트워크 내에서 인접하는 서비스 레지스트리들을 식별할 수 있고, 이는 노드(N1) 내의 서비스 레지스트리 및 노드(N4) 내의 서비스 레지스트리를 포함한다(노드(N2)에 연관되는 서비스 종단점들이 없기 때문에, 노드(N2)는 서비스 레지스트리를 포함하지 않을 수 있다). 노드(N1) 내의 서비스 레지스트리는 서비스 종단점(S1)을 식별하는 히트(hit)를 반환할 수 있다. 노드(N4) 내의 서비스 레지스트리는 아무런 히트도 반환하지 않을 수 있고 검색 쿼리를 그것의 인접하는 서비스 레지스트리들에 포워딩할 수 있고, 이 경우, 그것은 노드들(N3 및 N5) 내의 서비스 레지스트리들을 포함한다. 다만, 노드(N3) 내의 서비스 레지스트리는 검색을 이미 처리하였기 때문에, 검색 쿼리는 노드(N5) 내의 서비스 레지스트리에만 전송될 수 있다. 노드(N5)에 있는 서비스 레지스트리는 아무런 히트도 찾지 못할 수 있고 검색 쿼리를 노드(N7)에 있는 서비스 레지스트리에 포워딩할 수 있다. 노드(N7)는 서비스 종단점(S5)를 히트(hit)로 식별할 수 있고 검색 쿼리의 결과들을 노드(N4)에 반환할 수 있고 노드(N4)는 검색 결과들을 노드(N3) 내의 서비스 종단점(S7)에 포워딩 할 수 있다.

도 6a 및 6b는 (예를 들어, 각각의 서비스 레지스트리들(440)을 형성하는 서비스 호스트(415)(도 4a 참조)를 포함하는) 노드들의 네트워크(600)(예를 들어, 트리 네트워크)의 다른 예시적인 접속 형태(topology)의 블록도들이다. 네트워크(600)는 여섯 개의 노드들:노드들(P 내지 U)을 포함한다. 노드(P)는 두 자식 노드: 노드(Q) 및 노드(R)을 갖는다. 노드(R)은 어떠한 자식 노드도 갖지 않는다. 노드(Q)는 세 개의 자식 노드들: 노드(S), 노드(T), 및 노드(U)를 갖는다. 네트워크(600)의 예시에서, 각 노드는 도 4a에 도시된 구성들(예를 들어, 서비스(410), 클라이언트(420), 메시지 전송부(430), 및 서비스 레지스트리(440))을 포함하는 서비스 호스트(415)에 대응된다.

도 6b는 서비스 호스트들(예를 들어, 서비스 호스트들(415-P 내지 415-U)) 및 서비스 레지스트리들(예를 들어, 레지스트리(440-P) 내지 레지스트리(440-U))의 관계를 도시한다. 네트워크(600)의 예시에 대하여, 각 서비스 호스트는 또한 상응하는 클라이언트(예를 들어, 클라이언트(420P) 내지 클라이언트(420-U), 미도시) 및 상응하는 서비스(예를 들어, 서비스(410-P) 내지 서비스(410-U), 미도시)를 포함한다. 또한, 각 서비스 레지스트리(440-P 내지 440-U)는 호스트 서비스 레지스트리 DB(DB(442-P) 내지 DB(442-U), 미도시), 쿼리 핸들러(예를 들어, 쿼리 핸들러(444-P) 내지 쿼리 핸들러(444-U)), 및 서비스 레지스트리 캐시(예를 들어, 캐시(446-P 내지 캐시(446-U))를 포함한다.

기술된 바와 같이, 클라이언트가 특정 서비스를 검색할 때, 그 검색은 접속 형태(topology)에 따라 일 노드로부터 다른 노드로 네트워크를 통하여 전파(propagate)될 수 있다. 네트워크 접속 형태는 검색되는 특정 서비스에 따라 달라질 수 있다. 예를 들어, 저장 용량에 대한 검색은 특정 타입의 트랜스코더(transcoder)에 대한 검색에 비하여 상이한 네트워크 접속 형태에 연관될 수 있다. 도 7a는 일 실시예에서 SOA 네트워크의 접속 형태를 결정하기 위한 예시적인 프로세스(700A)의 순서도이다. 노드 관리자(510)(도 5a를 참조)는 프로세스(700A)를 수행하며 그것을 주기적으로 수행할 수 있다. 다만, 다른 실시예들에서, 환경(100) 내의 임의의 디바이스는 프로세스(700A)의 전체 또는 일부들을 수행할 수 있다.

일 실시예에서, 노드 관리자(510)는 네트워크 접속 형태를 생성하는 것(블럭(702))에 대한 특정 서비스를 선택한다. 예를 들어, 노드 관리자(510)은 “저장 서비스(STORAGE SERVICE)”를 네트워크에 대한 접속 형태를 만드는 것에 대한 서비스로 선택할 수 있다. 다른 실시예에서, 노드 관리자(510)는 마음에(in mind) 특정 서비스 없이, 노드의 프로퍼티(예를 들어, 프로세서 속도) 또는 일 노드에서 다른 노드의 관계의 프로퍼티(예를 들어, 대역폭)와 같은 하나 또는 그 이상의 프로퍼티들을 기초로 접속 형태를 생성(블럭(702))할 수 있다.

노드 관리자(510)은 네트워크의 접속 형태를 하나 또는 그 이상의 프로퍼티들을 기초로 결정할 수 있다. 만일, 특정 서비스가 선택된다면(블록(702)), 노드 관리자(510)는 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티를 기초로 접속 형태를 결정할 수 있다. 만일, 특정 서비스가 선택되지 않는다면, 노드 관리자(510)는 여전히 특정 서비스(이에 대해 접속 형태가 특정 서비스를 검색하기 위하여 사용될 수 있음)의 프로퍼티가 아닌 다른 프로퍼티를 기초로 (블록(702) 내에서 선택된 프로퍼티 또는 프로퍼티들에 대한) 접속 형태를 결정할 수 있다. 즉, 접속 형태는 (예를 들어, 접속 형태가 마음에 특정 서비스 없이 생성되더라도) 특정 서비스를 검색하기 위하여 사용될 수 있고, 그 접속 형태는 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티를 기초로 생성되었던 것이다. 따라서, 노드 관리자(510)는 또한 접속 형태를 생성하는 프로퍼티(또는 프로퍼티들)을 결정(블록(706))할 수 있다 (예를 들어, 프로퍼티 또는 프로퍼티들은 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티임). 예를 들어, 도 7b는 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티들을 결정하기 위한 예시적인 프로세스(700B)의 순서도이다. 프로퍼티(또는 프로퍼티들)을 결정하는 단계(블록(706))은 도 7b에 도시된 프로세스(700B)를 포함할 수 있다. 도 7a의 프로세스(700A)와 유사하게, 프로세스(700B)는 노드 관지자(510)에 의해 수행될 수 있다.

블록(706)(도 7a 참조)를 상술하기 위하여 도 7b를 바꿔 설명하면, 프로세스(700B)는 복수의 프로퍼티들을 결정할 수 있다. 일 실시예에서, 결정된 프로퍼티들은 (예를 들어, 블록(702) 내에서 선택된 또는 접속 형태가 검색을 위하여 사용될 때 검색된) 특정 서비스의 프로퍼티들이 아니다. 예를 들어, 프로세스(700B)는 두 노드들이 동일한 도메인 내에 있는 지 여부를 결정하는 것(블록(722))을 포함할 수 있다. 동일한 도메인 내의 노드들은 다른 도메인들 내의 노드들에 비하여 더 가까울 수 있다. 동일한 도메인 내의 노드들은 예를 들어, 동일한 방화벽(firewall) 뒤의(behind) 노드들일 수 있다. 프로세스(706)는 노드들이 멀티캐스트를 통하여 서로에게 접근할 수 있는 지 여부를 결정하는 것(블록(724))을 포함할 수 있다. 몇몇 실시예들에서, 동일한 네트워크 내의 노드들(블록(722))는 멀티캐스트(예를 들어, 멀티캐스트 용량)을 통해 서로 접근가능한 동일한 노드들일 수 있다. 다른 구현 예에서, 멀티캐스트를 통해 접근가능한 노드들은, 노드들이 동일한 멀티캐스트 그룹의 구성원들인지를 결정하는 것과 같은, 다른 테크닉(technique)을 사용하여 결정될 수 있다. 멀티캐스트를 통해 접근가능한 노드들은 멀티캐스트를 통해 접근가능하지 않은 노드들에 비하여 더 가까운 것으로 여길 수 있다.

프로세스(700B)는 또한 노드들의 지리학적 위치를 결정하는 것(블록(726))를 포함할 수 있다. 이 경우, 지리학적으로 서로 더 가까운 노드들은 지리학적으로 더 멀리 떨어진 노드들에 비하여 접속 형태 내에서 더 가까운 것으로 여길 수 있다. 프로세스(700B)는 노드들 사이의 지연 시간 및/또는 노드들 사이의 가용한 대역폭을 결정하는 것(블록(728)))을 포함할 수 있다. 낮은 지연 시간을 갖는 노드들은 높은 지연 시간을 갖는 노드들에 비하여 네트워크 내에서 더 가까운 것으로 여길 수 있다. 서로에 대하여 높은 대역폭을 갖는 노드들은 낮은 대역폭을 갖는 노드들에 비하여 네트워크 내에서 더 가까운 것으로 여길 수 있다.

프로세스(700B)는 노드들의 저장 용량을 결정하는 것(블록(730))을 포함할 수 있다. 프로세스(700B)는 또한 프로세서 속도 또는 노드들의 클래스(class)를 결정하는 것(블록(732))을 포함할 수 있다. 높은 저장 용량 및 높은 프로세서 속도를 갖는 노드들은 접속 형태 내에서 예를 들어, 부모 노드들이 될 수 있다. 예를 들어, (검색될 특정 서비스의 프로퍼티가 아닌 다른) 프로퍼티들은 도 7b에 도시된 것과 다르게 결정될 수 있다. 예를 들어, (예를 들어, 특정 서비스의 프로퍼티가 아닌 다른) 프로퍼티들은 임의의 두 노드들 사이의 채널(channel)이 존재하며 개방된 지 여부(예를 들어, 개방 채널들), 두 노드들(예를 들어, 모바일 서브스크립션 서비스(mobile subscription service)) 사이에서 데이터를 운송하기 위한 (예를 들어, 화폐 단위의) 비용, 지리적 위치(예를 들어, 데이터가 특정 나라를 통과해야 하는 지 여부), 및/또는 네트워크 타입(예를 들어, 광섬유(fiber optic), 와이파이(WiFi), 휴대용(mobile), 무선전화(cellular) 등)을 포함할 수 있다.

다시 도 7a를 참조하면, 노드 관리자(510)는 네트워크 접속 형태를 결정하기 위하여 프로퍼티들(예를 들어, 각각의 프로퍼티들의 계량치(weight))을 계량(weigh)(블록(708))할 수 있다. 계량된 프로퍼티들을 기초로, 노드 관리자(510)는 각각의 노드의 다른 노드들에 대한 가까운 정도(nearness)를 결정(블록(710))할 수 있다. 일 실시예에서, 가까운 정도의 결정은 특정 서비스의 프로퍼티와 다른 프로퍼티를 부분적으로 기초로 한다(블록(710)).

가까운 정도를 기초로, 노드 관리자(510)은 (블록(702)에서 결정된) 특정 서비스 또는 (블록(702)에서 또한 결정된) 선택된 프로퍼티나 프로퍼티들에 대한 네트워크의 접속 형태를 결정(블록(712))할 수 있다. 예를 들어, 접속 형태는 그 중에서도 트리 네트워크, 매쉬 네트워크(mesh network)일 수 있다. 일 실시예에서,

노드 관리자(510)은 각각의 서비스에 대하여 접속 형태를 결정할 수 있다. 예를 들어, 노드 관리자(510)은 "카메라(CAMERA)"에 대한 접속 형태와는 상이한 "저장 서비스(STORAGE SERVICE)"에 대한 접속 형태를 결정할 수 있다. 다른 예시에서, 노드 관리자(510)는 지연 시간 또는 지리적 위치(또는 임의의 조건에 대한 계량치의 혼합)과 같은 상이한 조건들에 대하여 상이한 접속 형태를 결정할 수 있다. 일 실시예에서, 클라이언트(420)(예를 들어, 검색을 요청했던 클라이언트)는 요청을 발송할 때 접속 형태를 식별할 수 있다. 이 경우, 노드 관리자(510)가 상이한 조건들에 대한 접속 형태를 결정할 때, 접속 형태에 연관되는 조건들은, 예를 들어, 검색 쿼리에서 검색되는 것으로 식별되는 특정 서비스의 프로퍼티가 아닌 하나 또는 그 이상의 프로퍼티들을 포함할 수 있다. 이러한 실시예는 클라이언트가 큰 대역폭이 필요한 파일을 스트리밍할 때 "양호한 대역폭을 갖는 저장 서비스"를 검색 할 수 있게 한다. 다른 예시로서, 이러한 실시예는 클라이언트가 작은 지연 시간을 요구하는 파일을 스트리밍할 때 "지리적으로 가까운(예를 들어, 낮은 지연 시간의) 저장 서비스"를 검색할 수 있게 한다. 하나의 접속 형태가 지리적으로 가까운 정도에 대하여 사용될 수 있고 및 대역폭에 대한 다른 접속 형태가 사용될 수 있다. 또한, 상이한 접속 형태가 정의되어 지리적으로 가까운 정도 및 대역폭의 결합에 대하여 사용될 수 있다. 앞서의 예시들에서, 대역폭 및 지리적으로 가까운 정도는 검색 대상인 특정 서비스(예를 들어, 저장 용량)의 프로퍼티들이 아닌 다른 프로퍼티들이다.

네트워크(600)가, 예를 들어, 서비스를 검색하기 위해 사용된다. 도 8은 SOA 네트워크 내의 서비스를 검색하기 위한 예시적인 프로세스(800)의 순서도이다. 프로세스(800)는, 예를 들어, 서비스 호스트 내에서, 서비스 계층(310) 내의 서비스 호스트 내에서 실행될 수 있다. 일 실시예에서, 프로세스(800) (또는 프로세스(800)의 부분들)은 재귀적(recursive) 및/또는 반복적(iterative)일 수 있고, 이때, 프로세스(또는 프로세스의 부분들)의 다수의(multiple) 인스턴스들이 다수의 서비스 호스트들에서 발생되고 프로세스는, 예를 들어, 다른 서비스 호스트 내에서 자신을 호출(call)한다. 프로세스(800)은 도 6의 네트워크(600)에 대하여 기술된다.

프로세스(800)은 클라이언트 내의 검색 쿼리를 수식화(formulating)하며 서비스 레지스트리에 그 쿼리를 전송(블록(802))하는 것으로 시작할 수 있다. 일 실시예에서, 클라이언트는 그 쿼리를 (예를들어, 상이한 노드 내의 서비스 호스트(415)와 반대로 동일한 서비스 호스트(415) 내에서) 로컬 서비스 레지스트리로 전송한다. 예시로서, 네트워크(600)을 참조하면, 노드(S) 내의 클라이언트(420-S)는 특정 서비스에 대한 쿼리를 수식화하며 그 쿼리를 서비스 노드(S) 내의 레지스트리(440-S)에 전송한다(블록(802)). 도 8에 도시된 바와 같이, 쿼리는: (&(인터페이스 = 저장 서비스) (CPU 랭킹 > 10) (디스크 용량 >= 500MB))일 수 있다. 쿼리는 많은 수의 결과들(예를 들어, 여섯 개와 같이 많은 수의 서비스들)을 구체화하며 요청할 수 있다. 이러한 예시에서, 쿼리는 특정 서비스(예를 들어, "저장 서비스(STORAGE SERVICE))" 및 특정 서비스의 특정 프로퍼티(예를 들어, 디스크 용량 >= 500MB)를 구체화한다. 클라이언트(440-S)에 의해 생성된 쿼리는 또한 오버레이 네트워크의 접속형태를 크롤링(crawl)(예를 들어, 운행(traverse), 추종(follow), 또는 트래블(travel))하기 위해 구체화 또는 요청할 수 있다. 위에 언급된 바와 같이, 쿼리는 지리적 가까움, 지연 시간, 대역폭, 동일하거나 상이한 도메인, 저장 용량, 프로세서 속도 등, 또는 이러한 프로퍼티들의 임의의 계량된 결합에 대한 접속 형태를 구체화할 수 있다.

서비스 레지스트리는 클라이언트로부터 쿼리를 수신한다(블록(804)). 네트워크(600)의 예시를 계속 살피면, 노드(S) 내의 서비스 레지스트리(440-S)는 클라이언트(420-S)(예를 들어, 로컬 서비스 레지스터리)로부터 특정 서비스에 대한 쿼리를 수신한다. 특히, 쿼리 핸들러(444-S)(도 4c 참조)는 그 쿼리를 수신할 수 있다. 도 8에 표시되고 아래에서 더욱 상세히 기술되는 바와 같이, 서비스 레지스트리는 또한 다른 서비스 레지스트리(예를 들어, 상이한 노드 내의 상이한 서비스 호스트(415) 내의 서비스 레지스트리)로부터 검색 쿼리를 수신할 수 있다(블록(804)).

검색 쿼리를 수신했으면, 서비스 레지스트리는 호스트 서비스 레지스트리 DB(예를 들어, 로컬 데이터 베이스)에 그 DB에 등록된 서비스들을 매칭(matching)하기 위하여 질의(queries)한다(블록(806)). 위의 예시에 대하여 계속 살피면, 쿼리 핸들러(444-S)는, 클라이언트(420-K)로부터 수신된 검색 쿼리로 호스트 서비스 레지스트리 DB(442-S)(도 4c 참조)에 질의한다(블록(806)). 쿼리는 그 쿼리에 매칭되는(예를 들어, 그 쿼리를 만족하는) 등록된 서비스들의 리스트(예를 들어, 제1 리스트)를 만약 있다면 가져올 수 있다.

만일 쿼리의 결과들이 충분하다면(블록(808):"예"), 쿼리를 만족하는 등록된 서비스들의 리스트(예를 들어, 제1 리스트)는 클라이언트에게 반환될 수 있다(블록(810)). 충분한 매칭 결과들이, 예를 들어, 리스트의 서비스들의 수를 어떤 수(a number)(예를 들어, 클라이언트에 의해 요청된 수 또는 디폴트(default) 수)에 대해 비교함으로써 결정될 수 있다. 클라이언트에 검색 결과들이 반환된(블록(810)) 이후에, 프로세스(800)은 (적어도 블록(804)에서 검색 쿼리를 수신한 서비스 레지스트리(440)에 대하여) 종료될 수 있다.

앞서 기술된 바와 같이, 로컬 서비스 레지스트리(440-S)는, 원격 서비스 호스트들로부터의 서비스 정보가 더 빠른 검색들을 위하여 저장되는 캐시(446-S)를 가질 수 있다. 이에, 쿼리 핸들러(444-S)는 또한 서비스 레지스트리 캐시(446-S)에 그것의 결과들을(또는, 로컬 DB(442-S) 내에 불충분한 결과들만 있다면) 보충하도록 질의(query)할 수 있다. 캐시(446-S)로부터의 결과들은 클라이언트에 반환되는 서비스들의 리스트 내에 포함될 수 있다.

서비스 레지스트리(440-S)는 다른 서비스 레지스트리들을 서비스들을 매칭하는 검색에 선발 (draft)할 수 있다. 검색 결과들이 충분하지 않다면(블록(808): "아니오"), 서비스 레지스트리(440-S)(예를 들어, 쿼리 핸들러)는 이웃하는 노드들을 결정하기 위한 접속 형태를 결정 및/또는 선택할 수 있다(블록(811)). 일 실시예에서, 접속 형태는 클라이언트에 의해 발행된 쿼리 내에서 식별될 수 있다. 다른 실시예에서, 접속 형태는 검색 대상인 특정 서비스를 기초로 선택될 수 있다. 또 다른 실시예에서, 쿼리 핸들러(444-S)는 다른 인자들(fators)을 기초로 접속 형태를 선택한다. 선택된 접속 형태는 앞서 논의된 것들: 지리적 가까움, 지연 시간, 대역폭 등, 또는 그것들의 임의의 계량된 결합을 포함할 수 있다. 일 실시예에서, 접속 형태는, 예를 들어 요청된 접속 형태가 없다면 그 때에 맞게 (on-the-fly) 생성될 수 있다.

상이한 접속 형태들은 검색 대상인 특정 서비스에 따르는(depending on) 다른 접속 형태들(및 블록(811)에서 선택될 수 있는 최적의 접속 형태)에 비하여 나을 수 있다. 예를 들어, 대역폭은, 검색 대상인 특정 서비스가 고화질(high definition) 비디오의 스트리밍일 때 접속 형태에 대한 중요한 프로퍼티(예를 들어, 블록(706)에서 선택되고 블록(708)에서 계량된 프로퍼티)일 수 있다. 반면에, 지연 시간은, 검색 대상인 특정 서비스가 전화통화(telephony)일 때 접속 형태에 대한 가장 중요한 프로퍼티(예를 들어, 블록(706)에서 선택되고 블록(708)에서 계량된 프로퍼티)일 수 있다. 따라서, 이러한 실시예는 검색 대상인 특정 서비스에 대한 가장 적절한 접속 형태의 선택을 가능케 한다.

쿼리 핸들러(444-S)는 다른 이웃하는 노드들의 ID(identity)를 요청 및 수신할 수 있다(블록(812)). 이웃하는 노드는, 예를 들어, (블록(811)로부터) 선택된 접속 형태 내의 떨어진(away) 하나의 홉(hop)인 네트워크(예를 들어, 네트워크(600)) 내의 노드일 수 있다. 위에서 기술된 바와 같이, 이웃하는 노드(예를 들어, 서비스 레지스트리)는 검색 대상인 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티를 기초로 하는 (예를 들어, 먼저 가까운 이웃으로 선택된) 이웃이다. 예를 들어, 특정 서비스 "저장 서비스(STORAGE SERVICE)" (그 서비스의 프로퍼티가 아닌 다른) 프로퍼티에 대한 이웃하는 서비스 레지스트리는 네트워크 지연 시간을 포함할 수 있다. 네트워크(600)의 예시에 관하여 계속 살피면, 서비스 레지스트리(440-S) 내의 쿼리 핸들러(444-S)는 호스트 서비스 레지스트리 DB(442-S)에 질의(query)하고 (블록(806)), 세 개의 매칭하는 서비스들, 즉, 불충분한 수의 결과들(예를 들어, 클라이언트에 의해 여섯 개의 결과들이 요구됨)을 탐색한다(블록(808): "아니오"). 이 결과, 쿼리 핸들러(444-S)(도 4c 참조)는 네트워크 계층(320) 내의 노드 관리자(510)로부터 이웃하는 노드들(예를 들어, 하나의 떨어진 홉(hop))의 ID(identity)를 요청한다. 쿼리 핸들러(444-S)는 노드 관리자(510): 도 6에 도시된 바와 같이 노드(S)의 부모 노드가 되어버린 노드(Q)로부터 이웃하는 노드들의 리스트를 수신한다.

쿼리 핸들러는 이웃하는 노드(예를 들어, 이웃하는 서비스 레지스트리)가 검색을 포워딩하는 것이 가능한 지를 결정한다(블록(814)). 만일, 검색을 지속하는 것이 가능한 이웃하는 어떠한 노드도 없다면(블록(814): “아니오”), 그 때, 이것의 식별자(indication)가, 만일 있다면, 검색 결과와 함께 클라이언트(또는 서비스 레지스트리를 요청하는 다른 이)에게 전송될 수 있다(블록(810)). 이 경우에, 프로세스(800)은 (적어도 쿼리를 수신했던 서비스 레지스트리(415)에 대하여) 종료될 수 있다. 쿼리 핸들러는, 노드 관리자(510)이 이웃하는 노드들의 리스트를 반환하는 때에 조차도 검색이 가능한 다른 어떠한 이웃하는 노드도 결정하지 않을 수 있다. 예를 들어, 쿼리 핸들러는, 검색 쿼리를 포워딩하는 것이 가능한 어떠한 노드도 남겨두지 않고, 이웃하는 노드들의 리스트 내의 모든 노드가 동일한 검색 내에 참여되는 지 또는 이미 참여하였는 지를 결정할 수 있다.

만일, 이웃하는 노드가 검색을 지속하는 것이 가능하다면(블록(814): “예”), 서비스 레지스트리(예를 들어, 쿼리 핸들러)는 검색 쿼리를 이웃하는 노드 내의 서비스 레지스트리(예를 들어, 이웃하는 서비스 레지스트리)에 전송할 수 있다(블록(816)). 이러한 예시에서, 쿼리 핸들러(444-S)는 노드(Q)가 검색을 지속하는 것이 (예를 들어, 서비스 레지스트리(440-q)가 검색에 참여하였는 지를 모르기 때문에) 가능한 지를 판단한다(블록(814): “예”). 서비스 레지스트리(440-S)는 검색 쿼리를 노드(Q) 내의 서비스 레지스트리(440-Q)로 포워딩한다(블록(816)). 점선으로 보여지는 바와 같이, 이웃하는 노드 내의 서비스 레지스트리는 (다른 서비스 레지스트리로부터 검색 쿼리를 수신함으로써 블록(804)에서 시작된) 프로세스(800)의 다른 인스턴스를 발생시킬 수 있다. 일 실시예에서, 서비스 레지스트리(440-S)는, 이미 발견된 매칭하는 검색 결과들의 수를 기초로, 검색 쿼리에 대한 요청된 검색 결과들의 수를 조정한다. 아래에서 더욱 상세히 기술되는 바와 같이, 결국 서비스 레지스트리(440-S)는 이웃하는 서비스 레지스트리(440-Q)로부터 검색 결과들(예를 들어, 서비스들의 제2 리스트)을 수신할 수 있다(블록(818)). 서비스 레지스트리(440-S)는 서비스 레지스트리(440-Q)로부터 수신된 결과들(예를 들어, 서비스들의 제2 리스트)을 그것의 자신의 결과들(예를 들어, 블록(806)으로부터의 제1 리스트))과 결합하여 두 리스트들을 클라이언트에게 반환할 수 있다(블록(810)).

이러한 예시에서, 서비스 레지스트리(440-Q)는 서비스 레지스트리(440-S)로부터 검색 쿼리를 수신하고(블록 (804)), 그것의 호스트 서비스 레지스트리 DB(442-Q)에 질의한다(블록(806)). 서비스 레지스트리(440-Q) 내의 쿼리 핸들러(444-Q)는 호스트 서비스 레지스트리 DB(442-Q)에 질의하고(블록(806), 아무런 매칭하는 서비스도(즉, 결과들의 불충분한 수) 탐색하지 않는다(블록(808): “아니오”). 예시로서, 쿼리 핸들러(444-Q)에 의해 수신된 쿼리는 요청된 결과들의 수가 세 개인(예를 들어, 여섯 개의 원래의 요청이 세 개로 감소됨) 것을 나타낼 수 있다. 결과적으로, 쿼리 핸들러(444-Q)는 노드 관리자(510)으로부터 이웃하는 노드들의 ID(identity)를 요청할 수 있다. 쿼리 핸들러(444-Q)는 노드 관리자(510): 도 6a 및 6b에서 도시된 바와 같은 노드(S), 노드(T), 노드(U), 및 노드(P) 로부터 이웃하는 노드들의 리스트를 수신한다. 일 실시예에서, 만일 미리결정된(predetermined) 양의 시간이 지나가면, 결과들은 결과들의 수에도 불구하고 충분한 것으로 여겨질 수 있다(블록(808):”예”).

쿼리 핸들러(444-Q)는 이웃하는 노드가 검색을 포워딩 하는 것이 가능한 지를 결정한다(블록(814)). 쿼리 핸들러(444-Q)는 노드(T), 노드(U), 및 노드(P)가 검색을 지속하는 것이 가능한 지를 결정한다(블록(814): “예”). 쿼리 핸들러(444-Q)는 노드(S)를, 그것이 서비스 레지스트리(440-S)로부터 검색 쿼리를 수신하였고 노드(S)가 분명하게 이미 검색에 포함되었기 때문에, 포함하지 않는다. 이에, 쿼리 핸들러(444-Q)는 검색 쿼리를 이웃하는 노드(T), 이웃하는 노드(U), 및 이웃하는 노드(P) 내의 서비스 레지스트리에 전송한다(블록(816)). 점선으로 도시된 바와 같이, 이웃하는 노드들(T,U, 및 P) 내의 서비스 레지스트리는 (다른 서비스 레지스트리로부터의 검색 쿼리를 수신함으로써 블록(804)에서 시작된) 프로세스(800)의 다른 인스턴스를 발생시킬 수 있다.

그러면 서비스 레지스트리(440-Q)는 서비스 레지스트리(400-T), 서비스 레지스트리(440-U), 및 서비스 레지스트리(440-P)에 검색 요청을 전송한다(블록(816)). 위에서 언급된 바와 같이, 일 실시예에서, 서비스 레지스트리(440-Q)는 이미 발견된 매칭하는 검색 결과들의 수를 기초로 쿼리 내의 요청된 검색 결과들의 수를 (예를 들어, 세 개로) 조정한다. 일 실시예에서, 검색 결과들은 모든 가용한 이웃하는 노드들에 전송되고 이로써 이러한 이웃하는 노드들 내의 검색이 병렬적으로 이루어진다. 다른 실시예들에서, 검색 결과들(예를 들어, 검색 쿼리)는 차례로(예를 들어, 각각의 결과들이 수신된 이후 또는 일 시간 구간이 지난 이후) 전송될 수 있다. 검색 결과들을 차례로 전송하는 것은, (예를 들어, 블록(814)에서 결정된) 모든 가용한 노드들에 검색 결과를 전송하기 전에 서비스 레지스트리(440-T)가 검색 결과들이 검색 결과들이 충분한 지를 결정할 수 있도록 한다. 서비스 레지스트리(440-T)는 요청을 수신하고(블록(804)), 그 호스트 서비스 레지스트리 DB(442-T)(블록(806)) 내에 쿼리에 매칭하는 하나의 서비스를 탐색한다(블록(806)). 그러나, 총 네 개의 검색 결과들은 (예를 들어, 여섯 개 보다 작으므로) 여전히 불충분하다(블록(808): "아니오"). 서비스 레지스트리(440-T)는 네트워크 접속 형태를 결정 및/또는 선택하며(블록(811)), 이웃하는 노드들(예를 들어, 하나의 떨어진 홉(hop))의 ID(identity)에 대하여 오버레이 네트워크 계층(320)의 노드 관리자(510)에 요청을 전송한다(블록(812)). 노드 관리자(510)은 노드(Q)의 ID(identity)를 서비스 레지트리(440-T)에 반환한다(블록(812)). 다만, 서비스 레지스트리(440-T)는, 다른 어떠한 가용한 이웃을 남기지 않고, 노드(Q) 내의 서비스 레지스트리(440-Q)가 이미 검색에 포함된 것을 안다. 서비스 레지스트리(444-T)는 서비스 레지스트리(440-Q)에 이 결과를 전송하고(블록(810)), 서비스 레지스트리(440-T) 내의 프로세스(800)을 종료한다.

서비스 레지스트리(440-U)는 또한 요청을 수신하나(블록(804)) 그 호스트 서비스 레지스트리 DB(442-U)의 검색 동안 서비스를 탐색할 수 없다)(블록(808): "아니오"). 서비스 레지스트리(440-U)는 네트워크 접속 형태를 결정 및/또는 선택하고(블록(811)), 이웃하는 노드들(예를 들어, 하나의 떨어진 홉(hop))의 ID(identity)에 대하여 오버레이 네트워크 계층(320)의 노드 관리자(510)에 요청을 전송한다(블록(812)). 노드 관리자(510)은 노드(Q)의 ID(identity)를 서비스 레지스트리(440-U)에 반환한다(블록(812)). 다만, 서비스 레지스트리(440-U)는, 다른 어떠한 가용한 이웃을 남기지 않고, 노드(Q) 내의 서비스 레지스트리(440-Q)가 이미 검색에 포함(서비스 레지스트리(440-U)는 서비스 레지스트리(440-Q)로부터 요청을 수신했음)된 것을 알고(블록(814): "아니오"), 이 결과를 서비스 레지스트리(440-Q)에 전송하고(블록(810)), 서비스 레지스트리(440-T) 내의 프로세스(800)를 종료한다.

서비스 레지스트리(440-P)는 또한 요청을 수신하고(블록(804)) 그 호스트 서비스 레지스트리 DB(442-P)의 검색 쿼리를 매칭 또는 만족하는 두 개의 서비스들을 탐색한다(블록(806)). 그럼에도 불구하고, 두 개의 결과들은 (예를 들어, 요청된 세 개보다 작으므로) 충분치 않다고 여겨진다(블록(808): "아니오"). 서비스 레지스트리(440-P)는 네트워크 접속 형태를 결정 및/또는 선택하고(블록(811)), 이웃하는 노드들(예를 들어, 하나의 떨어진 홉(hop))의 ID(identity)에 대해 오버레이 네트워크 계층(320)의 노드 관리자(510)에 요청을 전송한다(블록(812)). 노드 관리자(510)는 노드(Q 및 R)의 ID(identity)를 서비스 레지스트리(440-P)에 반환한다(블록(812)). 다만, 서비스 레지스트리(440-P)는, 오직 노드(R)만이 가용한 이웃으로 남은 채 , 노드(Q) 내의 서비스 레지스트리(440-Q)가 이미 검색에 포함(서비스 레지스트리(440-P)는 서비스 레지스트리(440-Q)로부터 요청을 수신했음)된 것을 안다.(블록(814): "예"). 서비스 레지스트리(444-P)는 검색 요청을 서비스 레지스트리(440-R)에 전송한다, 이는 서비스 레지스트리(440-R) 내의 프로세스(800)의 다른 인스턴스를 발생시킨다(블록(816)). 검색 결과는 요청된 결과들의 수를 (예를 들어, 요청된 세 개에 비교된 두 개의 검색 결과들을 반영하여) 한 개로 조정할 수 있다.

서비스 레지스트리(440-R)은 검색 결과를 수신하고(블록(804)), 그 호스트 서비스 레지스트리 DB(442-R)의 검색 쿼리를 매칭 또는 만족하는 하나의 서비스를 탐색한다(블록(806)). 한 개의 결과는 충분한 것으로 여겨지고(블록(808: "예"), 결과들은 서비스 레지스트리(440-P)(검색을 서비스 레지스트리(440-R)에 전송했던 서비스 레지스트리)에 전송된다. 서비스 레지스트리(440-P)는 결과들(예를 들어, 리스트)을 서비스 레지스트리(440-R)로부터 수신하며(블록(818)) 수신된 결과들을 그 자신의 결과들과 결합할 수 있다. 그러면, 서비스 레지스트리(440-P)는 그 결과들을 서비스 레지스트리(440-Q)(즉, 서비스 레지스트리(440-P)가 검색에 참여하는 것을 요청했던 레지스트리)에 전송한다. 이러한 예시에서, 서비스 레지스트리(440-P)는 세 개의 결과들을 서비스 레지스트리(440-Q)에 전송한다. 서비스 레지스트리(440-Q)는 검색 결과들을 서비스 레지스트리(440-P)로부터 수신하며(블록(818)) , 수신된 결과들을 그 자신의 것과 결합하고, 그 결과들을 서비스 레지스트리(440-S)(예를 들어, 서비스 레지스트리(440-Q)가 검색에 참여하는 것을 요청했던 서비스 레지스트리)에 반환한다(블록(818)). 이러한 예시에서, 서비스 레지스트리(440-Q)는 네 개의 결과들을 서비스 레지스트리(440-S)에 전송한다. 서비스 레지스트리(440-S)는 그 결과들(예를 들어, 서비스들의 제2 리스트)을 서비스 레지스트리(440-Q)로부터 수신한다(블록(818)). 서비스 레지스트리(440-S)는 서비스 레지스트리(440-Q)로부터 수신된 결과들(예를 들어, 서비스들의 제2 리스트)을 그 자신의 결과들(예를 들어, 블록(806)으로부터의 제1 리스트의 세 개의 결과)에 결합할 수 있고 클라이언트에게 그 결과들을 반환한다(블록(810)). 이러한 예시에서, 서비스 레지스트리(440-S)는 일곱 개의 결과들을 클라이언트에게 전송한다.

도시된 바와 같이, 클라이언트는 원래의 쿼리 내에서 여섯 개의 결과들을 요청했으나 일곱 개를 수신했다. 서비스 레지스트리(440)이 병렬로 검색했기 때문에 추가적인 결과들이 발생할 수 있다. 이는 요청된 것 이상의 검색이 이루어짐을 나타내는 한편, 다음의 가능한 이익들: 노드들이 전체 데이터 베이스에 대한 카피를 필수적으로 갖는 것이 아닌 분산된 데이터베이스에 대한 작은 계산(computational) 비용은 여분(extra)의 결과가 된다.

일 실시예에서, 서비스 레지스트리가 결과들을 이웃으로부터 수신할 때(블록(818)), 그것은 이러한 결과들을 그 서비스 레지스트리 캐시(446) 내에 저장할 수 있다. 캐시(446) 내에 저장된 정보는 유효 기간(Time-To-Live, "TTL")을 가질 수 있고 시간 구간이 지난 이후 삭제될 수 있다. 다른 실시예에서, 서비스 레지스트리는 이웃 서비스 레지스트리들로부터 결과들을 수신하지 않는다(블록(818)). 대신에, 이웃하는 서비스 레지스트리는 요청하는 클라이언트에 직접 결과를 전송한다. 후자의 실시예의 이점은, 서비스 레지스트리가 임의의 수행중인 검색의 상태 및 서비스 레지스트리가 이웃으로부터 응답을 수신했는 지 여부를 저장해야 할 필요가 없다는 점이다. 반면에, 이러한 후자의 실시예는 캐시(446)의 크기가 제한될 수 있고 이는 종국에는 검색을 느리게 할 수 있다.

오버레이 네트워크 의 접속 형태의 다른 예시는 메쉬 네트워크(mesh network)이고, 여기서 각 노드는 오버레이 네트워크 내에서 하나 또는 그 이상의 다른 노드들에 직접 연결된다. 메쉬 네트워크 내의 각 노드는, 오버레이 네트워크 접속 형태 내의 연결들 (예를 들어, 미리 정의된 분산 패턴)에 따라, 그 것에 연결된 노드들로 트래픽(traffic)을 포워딩할 수 있다. 트리 접속 형태는 많은 메쉬 접속 형태들 중 하나로 여겨질 수 있다. 다른 예시로서, 하나의 메쉬 접속 형태는 각 노드를 모든 다른 노드에 연결할 수 있다. 이 경우, 네트워크 내의 각 노드는 검색 쿼리를 수신할 수 있고, 검색 쿼리를 클라이언트(420)으로부터 수신했던 서비스 레지스트리(440)는 모든 노드들로부터 검색 결과들을 수신한 이후에 검색 결과들을 순위 매김(rank)할 수 있다.

위에서 트리 접속 형태에 관해 기술한 바와 같이, (네트워크 접속 형태들의 그룹의) 상이한 메쉬 네트워크 접속 형태들이 검색 대상인 상이한 특성 서비스들(또는 상이한 프로퍼티들의 그룹)에 연관될 수 있다. 또한, 메쉬 접속 형태 내의 각각의 연결은 검색 대상인 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티(또는 프로퍼티들)을 기초로 형성(establish)될 수 있다. 예를 들어, 각 노드는 네 개의 지리적으로 가장 가까운 노드들에 연결될 수 있다. 다른 예시로서, 오버레이 네트워크의 접속 형태(메쉬 또는 트리)는 수동으로(manually) 구성될 수 있다. 일 실시예에서, 검색 결과들은, 예를 들어, 요청하는 클라이언트(420)으로부터의 서비스인 홉(hop)들의 수를 기초로 순위 매김될 수 있다.

메쉬 네트워크에 대한 이와 같은 경우에, 검색 결과들의 요청된 수 이상의 수가 반환될 수 있다(그리고 이에 따라 추가적인 계산(computation) 자원이 소모된다)(즉, 가능한 기술적 어려움). 그럼에도 불구하고, 메쉬 네트워크는 분산된 데이터베이스의 병렬적 검색을 효율적인 방식으로 가능하게 할 수 있다(예를 들어, 다른 기술적 어려움에 대한 가능한 해결책). 또한, 메쉬 접속 형태를 통한 검색은 트리 접속 형태를 통한 검색에 비하여 더 빠르고 더 병렬적일 수 있다(예를 들어, 기술적 어려움에 대한 가능한 해결책). 메쉬 접속 형태를 통한 검색은, 그러나, 트리 접속 형태에 의한 것에 비하여 더 많은 네트워크 트래픽 및 더 과도한 검색 결과들을 야기할 수 있다(예를 들어, 메쉬 접속 형태에 대한 가능한 기술적 어려움, 및 트리 접속형태가 제공하는 가능한 해결책).

앞서의 발명의 상세한 설명에서, 다양한 선호되는 실시예들이 첨부된 도면들을 참조하여 기술되었다. 그러나, 이후 기술될 청구항들에 기재된 발명의 포괄적인 범주로부터 벗어나지 않는 범위에서, 다양한 변형예들 및 변경예들이 그것에 대하여 이루어질 수 있고, 추가적인 실시예들이 구현될 수 있음은 명백할 것이다. 발명의 상세한 설명 및 도면들은 이에 제한적인 의미 보다는 예시적인 의미로 간주된다.

예를 들어, 일 실시예에서, 클라이언트는 로컬 서비스 호스트나 로컬 서비스 레지스트리가 아닌 다른 서비스 호스트 및 서비스 레지스트리에 검색 쿼리를 전송할 수 있다(예를 들어, 블록(802)). 이러한 실시예에서, 클라이언트는 SOA 네트워크 내의 임의의 노드 또는 SOA 네트워크 내의 특정(예를 들어, 가까운) 노드에 검색 쿼리를 전송할 수 있다. 다른 예시로서, 일 실시예에서, 노드 관리자(510)은 특정 서비스의 프로퍼티를 기초로 (예를 들어, 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티를 추가하여) 네트워크의 접속형태를 결정할 수 있다.

예를 들어, 일련의 블록들이 도 7a, 7b, 및 8에 대하여 기술되었고, 신호 흐름들의 순서가 기술되었으나, 블록들 및/또는 신호 흐름들의 순서가 다른 구현예에서 변경될 수 있다. 또한, 비-종속적인(non-dependent) 블록들 및/또는 신호 흐름들이 병렬로 수행될 수 있다.

위에서 기술된 바와 같은 시스템들 및/또는 방법들이 도면들에서 도시된 구현 예들에서 소프트웨어, 펌웨어, 및 하드웨어의 많은 상이한 형태들에서 구현될 수 있음이 명백할 것이다. 이와 같은 시스템들 및 방법들을 구현하는 데 사용되는 특화된 제어 하드웨어 또는 실제 소프트웨어는 그 실시예들에 한정되는 것이 아니다. 이에, 시스템들 및 방법들의 동작(operation) 및 거동(behavior)은 특정한 소프트웨어 코드에 대한 참조없이 기술되었다-소프트 웨어 및 제어 하드웨어는 시스템들 및 방법들을 본 명세서의 기술 내용을 기초로 설계될 수 있는 것으로 이해된다.

또한, 위에서 기술된 특정 부분들은 하나 또는 그 이상의 기능들을 수행하는 구성으로 구현될 수 있다. 본 명세서에 사용된 구성은 프로세서, ASIC, 또는 FPGA와 같은 하드웨어, 또는 하드웨어 및 소프트웨어의 결합(예를 들어, 소프트웨어를 실행하는 프로세서)을 포함할 수 있다. 본 명세서에서 사용된 단어 "예시적으로"는 "실례(illustration)를 위한 예시로서"를 의미한다.

용어들 "포함하다"/"포함하는"은, 본 명세서에서 사용될 때, 기술된 특징들(fetures), 정수들(integers), 단계들(steps), 구성들(components) 또는 그들의 그룹의 존재를 구체화하도록 사용된 것임이 강조되어야 한다. 그러나, 하나 또는 그 이상의 다른 특징들, 정수들, 단계들, 구성들 또는 그들의 그룹의 부가 또는 존재를 제한하는 것은 아니다.

명시적으로 그러한 기술이 없다면, 본 출원서 내에서 사용된 어떠한 엘리먼트(element), 작용(act), 또는 명령어(instruction)도 실시예들에 대해 임계적 또는 본질적인 것으로 해석되지 않는다. 또한, 본 명세서에 사용된 바와 같이, 관사 "a"는 하나 또는 그 이상의 것(item)을 포함하도록 의도된다. 또한, 문구 "기초로"는, 다른 명시적인 기술이 없다면, "적어도 부분적으로 기초로"를 의미하도록 의도된다.

Claims (15)

1. (a) 클라이언트로부터 로컬 서비스 레지스트리 내에서 특정 서비스에 대한 검색 쿼리를 수신하는 단계로서,
   상기 로컬 서비스 레지스트리가 로컬 서비스 레지스트리에 등록된 서비스들을 기록하는 로컬 데이터 베이스를 포함하고,
   로컬 서비스 레지스트리가 서비스 레지스트리들의 네트워크 내에 있는, 검색 쿼리를 수신하는 단계;
   (b) 검색 쿼리를 만족하는 서비스들의 제1 리스트를 결정하도록 로컬 데이터 베이스에 질의하는 단계
   (c) 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티를 기초로, 서비스 레지스트리들의 네트워크 내에서, 이웃하는 서비스 레지스트리를 결정하는 단계로서,
   상기 이웃하는 서비스 레지스트리는 상기 로컬 서비스 레지스트리에 이웃하는, 이웃하는 서비스 레지스트리를 결정하는 단계;
   (d) 상기 이웃하는 서비스 레지스트리에 검색 쿼리를 전송하는 단계로서,
   상기 이웃하는 서비스 레지스트리는 상기 이웃하는 서비스 레지스트리에 등록된 서비스들을 기록하는 이웃하는 데이터 베이스를 포함하는, 검색 쿼리를 전송하는 단계;
   (e) 상기 이웃하는 서비스 레지스트리로부터, 상기 검색 쿼리를 만족하는, 상기 이웃하는 서비스 레지스트리에 등록된, 서비스들의 제2 리스트를 수신하는 단계;
   (f) 클라이언트에게, 상기 검색 쿼리를 만족하는 서비스들의 제1 리스트 및 서비스들의 제2 리스트를 반환하는 단계를 포함하는,
   방법.
2. 제1 항에 있어서,
   상기 특정 서비스의 프로퍼티는 특정 프로퍼티이고,
   상기 검색 쿼리는 상기 특정 서비스 및 상기 특정 서비스의 특정 프로퍼티를 식별하고,
   상기 이웃하는 서비스 레지스트리를 결정하는 단계는, 상기 특정 프로퍼티가 아닌 다른 프로퍼티를 기초로 상기 이웃하는 서비스 레지스트리를 결정하는 것을 포함하고,
   상기 이웃하는 서비스 레지스트를 결정하는 단계는 복수의 이웃하는 서비스 레지스트리들로부터 상기 이웃하는 서비스 레지스트리를 결정하는 단계를 포함하되, 서비스 레지스트리들의 네트워크 내의 일부의 서비스 레지스트리들은 이웃하는 서비스 레지스트리가 아닌,
   방법.
3. 제2 항에 있어서,
   상기 이웃하는 서비스 레지스트리를 결정하는 단계는: 복수의 프로퍼티들을 기초로 상기 이웃하는 서비스 레지스트리를 결정하는 것을 포함하되, 상기 복수의 프로퍼티들은 특정 서비스의 프로퍼티들이 아니고, 복수의 프로퍼티들의 각각의 프로퍼티는 계량되는,
   방법.
4. 제1 항에 있어서,
   상기 검색 쿼리는 상기 특정 서비스를 데이터 저장으로 나타내고,
   상기 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티는 대역폭, 지리적 위치, 개방 채널들, 지연 시간, 멀티캐스트 용량, 홉(hop)의 수, 비용, 또는 네트워크 타입을 포함하는,
   방법.
5. 제2 항에 있어서, 서비스 레지스트리들의 네트워크는 서비스 레지스트리들의 트리 네트워크인,
   방법.
6. 제1 항에 있어서,
   (g) 상기 이웃하는 서비스 레지스트리 내의 검색 쿼리를 수신하는 단계;
   (h) 상기 검색 쿼리를 만족하는 서비스들의 제2 리스트를 결정하도록 상기 이웃하는 서비스 레지스트리에 질의하는 단계; 및
   (i) 로컬 서비스 레지스트리에 상기 제2 리스트를 전송하는 단계를 더 포함하는,
   방법.
7. 제6 항에 있어서,
   상기 이웃하는 서비스 레지스트리는 요청하는 서비스 레지스트리이고,
   (j) 서비스들의 제2 리스트가 충분한지 여부를 결정하고, 서비스들의 제2 리스트가 충분하지 않을 때:
   상기 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티를 기초로, 서비스 레지스트리들의 네트워크 내에서, 다른 이웃하는 서비스 레지스트리-다른 이웃하는 서비스 레지스트리는 상기 요청하는 서비스 레지스트리에 이웃함-를 결정하고,
   상기 검색 쿼리를 상기 다른 이웃하는 서비스 레지스트리-다른 이웃하는 서비스 레지스트리는 상기 다른 이웃하는 서비스 레지스트리에 등록된 서비스들을 기록하는 다른 이웃하는 데이터베이스를 포함함-에 전송하고,
   상기 검색 쿼리를 만족하는, 상기 다른 이웃하는 서비스 레지스트리에 등록된, 서비스들의 다른 리스트-상기 제2 리스트는 상기 다른 리스트를 포함함-를, 상기 다른 이웃하는 서비스 레지스트리로부터 수신하는,
   단계; 및
   (k) 연속적으로 다른 노드들에 대하여 (j) 단계를 반복하는 단계를 더 포함하는,
   방법.
8. 디바이스를 포함하는 시스템에 있어서, 디바이스는:
   로컬 서비스 레지스트리에 등록된 서비스들을 기록하는 로컬 데이터 베이스를 저장하는 메모리로서, 상기 로컬 서비스 레지스트리는 서비스 레지스트리들의 네트워크 내에 있는, 메모리;
   프로세서로서,
   클라이언트로부터 특정 서비스에 대한 검색 쿼리를 수신하고,
   상기 검색 쿼리를 만족하는 서비스들의 제1 리스트를 결정하도록 상기 로컬 데이터 베이스에 질의하고,
   상기 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티를 기초로, 서비스 레지스트리들의 네트워크 내에서, 이웃하는 서비스 레지스트리-이웃하는 서비스 레지스트리는 상기 로컬 서비스 레지스트리에 이웃함-를 결정하는, 프로세서;
   상기 이웃하는 서비스 레지스트리에 상기 검색 쿼리를 전송하는 송신기로서, 상기 이웃하는 서비스 레지스트리는 상기 이웃하는 서비스 레지스트리에 등록된 서비스들을 기록하는 이웃하는 데이터 베이스를 포함하는, 송신기; 및
   상기 검색 쿼리를 만족하는, 상기 이웃하는 서비스 레지스트리에 등록된, 서비스들의 제2 리스트를, 상기 이웃하는 서비스 레지스트리로부터 수신하는 수신기를 포함하되,
   상기 프로세서는 클라이언트에게 상기 검색 쿼리를 만족하는 서비스들의 제1 리스트 및 서비스들의 제2 리스트를 반환하도록 구성되는,
   시스템.
9. 제8 항에 있어서,
   상기 특정 서비스의 프로퍼티는 특정 프로퍼티이고,
   상기 검색 쿼리는 상기 특정 서비스 및 상기 특정 서비스의 특정 프로퍼티를 식별하고,
   상기 프로세서는 상기 특정 프로퍼티가 아닌 다른 프로퍼티를 기초로 상기 이웃하는 서비스 레지스트리를 결정하도록 구성되는,
   시스템.
10. 제9 항에 있어서,
    상기 프로세서는 복수의 프로퍼티들을 기초로 상기 이웃하는 서비스 레지스트리를 결정하도록 구성되고, 상기 복수의 프로퍼티들은 상기 특정 서비스의 프로퍼티들이 아니고, 상기 프로세서는 상기 복수의 프로퍼티들의 각각의 프로퍼티들 계량하도록 구성되는,
    시스템.
11. 제8 항에 있어서,
    상기 검색 쿼리는 상기 특정 서비스를 저장 용량으로 나타내고,
    상기 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티는 대역폭, 지리적 위치, 개방 채널들, 지연 시간, 멀티캐스트 용량, 홉(hop)의 수, 비용, 또는 네트워크 타입을 포함하는,
    시스템.
12. 제9 항에 있어서, 서비스 레지스트리들의 네트워크는 서비스 레지스트리들의 트리 네트워크이거나, 또는 서비스 레지스트리들의 네트워크는 서비스 레지스트리들의 메쉬 네트워크인,
    시스템.
13. 제8 항에 있어서, 다른 디바이스를 더 포함하되, 상기 다른 디바이스는:
    상기 이웃하는 데이터 베이스를 저장하는 메모리;
    상기 검색 쿼리를 저장하는 수신기;
    서비스들의 제2 리스트가 상기 검색 쿼리를 만족하는 지를 결정하도록 상기 이웃하는 데이터 베이스에 질의하도록 구성된 프로세서; 및
    상기 로컬 서비스 레지스트리에 제2 리스트를 전송하는 송신기를 포함하는,
    시스템.
14. 제13 항에 있어서,
    상기 이웃하는 서비스 레지스트리는 요청하는 서비스 레지스트리이고;
    상기 다른 디바이스 내의 프로세서는 서비스들의 제2 리스트가 충분한지 여부를 결정하여, 서비스들의 제2 리스트가 충분하지 않을 때:
    상기 특정 서비스의 프로퍼티가 아닌 다른 프로퍼티를 기초로, 서비스 레지스트리들의 네트워크 내에서, 다른 이웃하는 서비스 레지스트리-다른 이웃하는 서비스 레지스트리는 상기 요청하는 서비스 레지스트리에 이웃함-를 결정하도록 구성되고,
    상기 다른 디바이스 내의 프로세서는, 상기 검색 쿼리를 상기 다른 이웃하는 서비스 레지스트리-다른 이웃하는 서비스 레지스트리는 상기 다른 이웃하는 서비스 레지스트리에 등록된 서비스들을 기록하는 다른 이웃하는 데이터베이스를 포함함-에 전송하도록 구성되고,
    상기 다른 디바이스 내의 수신기는, 상기 검색 쿼리를 만족하는, 상기 다른 이웃하는 서비스 레지스트리에 등록된, 서비스들의 다른 리스트-상기 제2 리스트는 상기 다른 리스트를 포함함-를, 상기 다른 이웃하는 서비스 레지스트리로부터 수신하도록 구성되는,
    시스템.
15. 제14 항에 있어서,
    상기 검색 쿼리를 만족하는 서비스들을 연속적으로 검색하도록 상기 다른 디바이스와 같이 구성되는 메모리들, 수신기들, 프로세서들, 및 송신기들을 포함하는 추가 디바이스들을 더 포함하는,
    시스템.

Images