KR20050048679A

KR20050048679A - 웹 서비스 아키텍쳐의 서비스 순위 결정 방법 및 시스템

Info

Publication number: KR20050048679A
Application number: KR1020057006121A
Authority: KR
Inventors: 로버트 해리스
Original assignee: 인터내셔널 비지네스 머신즈 코포레이션
Priority date: 2002-10-24
Filing date: 2003-04-28
Publication date: 2005-05-24
Also published as: US20130346581A1; AU2003227887A1; WO2004038621A1; US8560332B2; DE60306186T2; US20060112367A1; EP1556807A1; GB0224805D0; CN100568227C; CN1689019A; JP4223004B2; EP1556807B1; DE60306186D1; ATE330296T1; JP2006504172A; KR100745480B1

Abstract

본 발명은 웹 서비스 아키텍쳐의 서비스를 순위 결정하는 방법 및 웹 서비스 아키텍쳐를 제공한다. 웹 서비스 아키텍쳐는 근원 서비스 요청자(401)를 가진 서비스 계층 구조(401, 406, 408, 410)를 하위 레벨의 서비스를 호출하는 계층 구조의 제1 레벨의 서비스를 가진다. 근원 서비스 요청는(401)가 하나 이상의 서비스에 관한 선호도를 표시하고 순위 결정기(405)는 선호도에 기초한 선택 알고리즘을 제공한다. 근원 서비스 요청자(401)는 하나 이상의 레벨의 계층 구조의 서비스를 호출한다. 계층 구조(401, 406, 408, 410)의 각각의 레벨에서, 서비스는 디렉토리(411)를 사용하여 가능한 하위 레벨 서비스 세트를 검색하며 순위 결정기(405)는 선택 알고리즘을 가능한 하위 레벨 서비스 세트에 적용한다. 일 실시예에서, 가능한 하위 레벨 서비스 세트는 디렉토리(411)로부터 순위 결정기(405)를 참조하며 선호하는 시퀀스가 순위 결정기(405)에 의해 디렉토리에 리턴된다.

Description

웹 서비스 아키텍쳐의 서비스 순위 결정 방법 및 시스템{Method and System for Ranking Services in a Web Services Architecture}

본 발명은 웹 서비스 아키텍쳐의 순위 서비스용 방법 및 시스템에 관한 것이다. 특히, 본 발명은 순위가 최상위 호출자(invoker)에 의해 특정되는 서비스 제공자의 계층 구조를 갖는 웹 서비스 아키텍쳐에 관한 것이다.

웹 서비스는 IBM 소프트웨어 그룹의 "웹 서비스 개념 아키텍쳐 (WSCA1.0)" 문서에 기술되어 있다 (2001년 5월). 웹 서비스는 HTTP(hypertext transfer protocl), XML(Extensibl Markup Language), SOAP(Simple Obejct Access Protocal), WSDL(Web Services Description Language) 및 UDDI와 같은 기존 및 새로운 표준 위에 이룩된 프로그램과 프로그램간의 통신 모델을 제공한다.

웹 서비스는 표준화된 XML 메시징을 매개로 네트위크 접속이 가능한 기능의 조합들을 기술하는 인터페이스를 통하여 기술된다. 웹 서비스는 서비스 기술(service description)이라 칭하는 표준 정격 XML 표기법을 이용하여 기술된다. 서비스 기술은 메시지 양식, 전송 규약 및 위치를 포함하는 서비스와 상호 작용하기 위하여 필요한 모든 상세한 부분을 다루고 있다. 인터페이스는 서비스의 구현 상세를 숨김으로써 서비스가 구현되는 하드웨어 및 소프트웨어 플랫폼과 작성된 프로그램 언어에 독립적으로 사용 가능하게 한다. 또한, 이는 호출자(caller)의 하드웨어 및 소프트웨어 환경과도 독립적이다. 이는 웹서비스 기반 응용들이 네트위크에 걸친 공개(published), 위치 확인 및 호출 가능한 느슨한 결합(lossely coupled), 요소 배향(component-oriented) 및 기술을 넘나드는 구현을 가능하게 한다.

웹 서비스는 네트워크 내에서 구현된다. 네트워크는 인터넷, 인트라넷 또는 다른 형태의 네트워크와 같은 공개 접근이 가능한 네트워크일 수 있다. 인터넷 기반의 웹 서비스는 일반적으로 사용되는 네트워크 규약을 사용한다. 이런 규약은 HTTP 또는 SMTP 또는 FTP와 같은 다른 인터넷 규약일 수 있다. 다른 네트워크 (예를 들어, 인트라넷)는 MQSeries, COBRA 등과 같은 신뢰할만한 메시지 호출 기초 구조를 사용할 수 있다.

설명된 방법 및 시스템은 웹 서비스 아키텍쳐 내에서 현재 사용할 수 없는 기능을 제공하기 위한 UUDI/WSDL 규약 및 XML/SOAP 구문(syntax) 확장에 관한 것이다.

www.uuid.org을 통하여 취득 가능한 다음의 문헌을 참조한다.

UUID 2.0 Data structure reference,

UUID 2.0 API Specification,

UUID 2.0 Operators Specification, 및

Web Services Description Language (WDSL) 1.1

웹 서비스의 UDDI 목적은 디렉토리 또는 레지스트리 조회에 기초한 기능에 대한 공개 접근을 제공하는 것이다. 이들 서비스는 WSDL 부분에 따라 기술되고 XML/SOAP 기능에 의하여 호출된다. 호출자의 서비스에 대한 결합은 동적이고 고정 되어 있지 않다. 이는 개방적이어서 디렉토리는 자유롭게 사용 가능하고 조회 및 선택이 어떻게 일어나는가에 대한 제약은 존재하지 않는다. UUID 목적 수행에 매우 적합하다. 그러나 서비스 품질의 개념에 있어서는 불만족스럽다.

설명된 방법 및 시스템은 서비스 질에 대한 이슈 및 선택에 영향을 미치는 다른 요소가 UUID/WSDL 영역에 도입 될 수 있는 수단을 제공한다.

웹 서비스에서, 디렉토리 또는 레지스트리는 구성 요소 형태로 소프트웨어를 모으는데 사용된다. UDDI의 착안점은 서비스 선택을 위하여 WSDL 양식의 요청을 디렉토리 또는 레지스트리 서버에 송신하는 데 있다. 이러한 서비스 선택은 제공하는 회사별 및 수행하는 기능별과 같은 일반적으로 적용 가능한 특정 기준 (criteria)으로 명시 가능하다. 이러한 선택 정보는 매우 일반적이고 모든 사용자에게 동일하며 언급된 서비스의 요청 근원자에 대해 특정된 것이 없다.

설명된 방법 및 시스템은 근원자에 대한 특정 기준이 조회 시 반영될 수 있는 수단을 제공한다. 종래의 웹 서비스 기술과는 달리, 선택 서비스의 근원자 또는 요청자에 따라 선택 서비스가 영향을 받는다.

다음은 실제적인 예이다. 사용자 소프트웨어는 서적을 구입할 예정이다. 사용자는 서적 판매자 카테고리 하의 디렉토리를 조회하고 그러한 서비스를 제공하는 회사 목록을 취득한다. 그러나, 사용자는 예들 들어 두 개의 공급자와 선호 요금을 협상하여 먼저 이들 두 공급자 중의 하나에게 구매 요청을 보내고, 다른 사람을 제3의 선택으로 하고자 한다.

검색은 정보를 사용자에게 직접 복귀(return)시키고 사용자가 다음 행동을 제어하므로 사용자는 검색을 통하여 복귀된 회사 목록을 필터링함으로써 이를 수행할 수 있다.

서적 구매 요청이 다른 사람에 의하여 제공되는 서비스 기능의 일환인 경우 차이점이 발생한다. 예를 들어, 사용자는 StarTrek 서적의 라이브러리를 생성할 수 있다. 사용자는 '라이브러리 생성(Build Library)' 선택을 이용하고 적절한 판매자 목록을 취득한다. 사용자는 이 작업을 수행할 공급자에게 Get-me-a-library-for-StarTrek 요청을 한다. 그러나, 서적 구매 기능이 다른 사람에 의하여 이루어지므로 사용자는 더 이상 그의 애용 서적 판매자 목록을 사용 할 수 없다. 실제로, 그들은 사용자 대신에 그들의 선호하는 공급자를 이용한다.

설명된 발명의 결과 중 하나는 중간 판매자가 아닌 사용자가 선호하는 판매자를 통하여 서적(또는 다른 상품)을 구매하는 방법을 제공한다.

사용자: 라이브러리 판매자1: 사용자 선호

생성기: 판매자 2

종래 기술: 라이브러리 생성 -> 서적 1 구매 --> 구매

본 발명: 라이브러리 생성 -> 서적 1 구매 --------------> 구매

설명된 방법 및 시스템은 근원자의 선호도에 따라 WSDL/UDDI 요청이 어떠한 경항을 가지는 지에 관한 것이다. 사용자의 선호도에 영향을 미치는 조건에 대하여서는 다루지 않고 있으며 이는 사용자에 따른다. 사용자 선호에 영향을 미칠 수 있는 조건의 예로는 비용, 효율, 속도 및 신뢰성의 표준을 포함한다.

도 1은 웹 서비스 모델의 개략도.

도 2는 웹 서비스 스택의 개략도.

도 3은 UDDI(Universal Description, Discovery and Integration) 데이터 구조의 블록도.

도 4a는 본 발명에 따른 웹 서비스 계층 구조의 개략적인 블록도.

도 4b는 본 발명에 따른 웹 서비스 아키텍쳐의 개략적인 블록도.

도 5a는 종래 기술로부터 공지된 바와 같은 서비스 선택의 플로우 라인도.

도 5b는 본 발명에 따른 서비스 선택의 제1 실시예의 플로우 라인도.

도 5c는 본 발명에 따른 서비스 선택의 제2 실시예의 플로우 라인도.

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

400: 계층 구조

401: 서비스 요청자

402 ~ 404: 서비스 레벨

405: 순위 결정기

406, 408, 410: 선택된 서비스

411: 디렉토리

412: 포트

본 발명의 제1 특징에 따르면, 근원 서비스 요청자를 가진 서비스 계층 구조를 구비한 웹 서비스 아키텍쳐의 서비스를 순위 결정하는 방법에 있어서 - 계층 구조의 제1 레벨의 서비스는 하위 레벨의 서비스를 호출함 -, 근원 서비스 요청자가 하나 이상의 서비스에 관한 선호도를 표시하고 순위 결정기가 선호도에 기초한 선택 알고리즘을 갖는 단계, 근원 서비스 요청자가 하나 이상의 레벨의 계층 구조의 서비스를 호출하는 단계, 계층 구조의 각각의 레벨에서, 서비스가 디렉토리를 사용하여 가능한 하위 레벨 서비스 세트를 검색하는 단계, 및 순위 결정기가 선택 알고리즘을 가능한 하위 레벨 서비스 세트에 적용하는 단계를 포함하는 방법이 제공된다.

하위 레벨 서비스는 서비스 요청자 또는 서비스 제공자일 수 있다.

일 실시예에서, 가능한 하위 레벨 서비스 세트는 디렉토리로부터 순위 결정기를 참조할 수 있으며 선호하는 시퀀스는 순위 결정기에 의해 디렉토리에 복귀될 수 있다. 순위 결정기를 참조하는 단계는 디렉토리를 사용하는 서비스에게 보이지 않을 수 있다.

다른 실시예에서, 가능한 하위 레벨 서비스 세트는 디렉토리를 사용하는 서비스에 의해 순위 결정기에 보내질 수 있으며 선호하는 시퀀스는 순위 결정기에 의해 서비스에 복귀될 수 있다.

단일 결과 또는 일련의 결과가 디렉토리를 사용하는 서비스에 복귀 가능하다.

바람직하게는, 계층 구조의 서비스의 하위 레벨 호출는 상위 레벨 서비스에게 보이지 않는다.

근원 서비스 요청자의 선호도는 근원 서비스 요청자가 서비스 사용을 원하는 순서로 서비스를 순위 결정할 수 있으고, 서비스 사용을 배제할 수 있으며, 및/또는 기준에 영향을 미치는 다른 선택을 제공할 수 있다.

근원 서비스 요청자의 선호도는 예를 들어 비용, 효율, 속도 및 신뢰성을 포함하는 서비스 기준의 품질에 기초할 수 있다.

근원 서비스 요청자의 선호도가 존재하는 상황에서, 선호도는 디렉토리를 사용하는 서비스에 의한 선택에 우선할 수 있다. 선호하는 서비스가 이용 불가능하면, 후속 서비스가 근원 서비스 요청자의 선호도를 참조하여 달성 가능하다.

근원 서비스 요청자의 선호도가 저장되어 있지 않으면, 디렉토리를 사용하는 서비스가 선택을 행할 수 있다.

본 발명의 제2 특징에 따르면, 웹 서비스 아키텍쳐에 있어서, 근원 서비스 요청자, 제1 레벨의 서비스가 하위 레벨의 서비스를 호출하는 서비스 계층 구조, 계층 구조의 서비스를 검색하는 디렉토리, 및 하나 이상의 서비스에 관한 근원 서비스 요청자의 선호도에 기초한 서비스에 대한 선택 알고리즘을 적용하는 수단을 구비한 순위 결정기를 포함하며, 계층 구조의 각각의 레벨에서, 디렉토리는 가능한 서비스 세트를 제공하며 순위 결정기는 선택 알고리즘을 적용하여 일련의 선호하는 서비스를 제공하는 웹 서비스 아키텍쳐가 제공된다.

순위 결정기는 포트에 의해 디렉토리에 접속되고 가능한 서비스 세트는 디렉토리에 의해 순위 결정기를 참조하며 일련의 선호하는 서비스는 순위 결정기에 의해 디렉토리에 복귀된다.

제1 레벨의 서비스는 UDDI 디렉토리에 의해 하위 레벨의 서비스를 검색할 수 있다. 순위 결정기는 UDDI 디렉토리 상의 포트를 가지며 TModel 백(bags)을 선택된 세트의 TModles로 전환시키는 플로우를 처리 가능하다.

각각의 UDDI 동작은 순위 결정기를 참조할 수 있으며 서비스 요청자의 선호도와 일치하는 시퀀스로서 복귀될 수 있다.

근원 UDDI 어플리케이션 코드는 참조를 수행할 수 있으며 순위 결정기의 위치를 후속 XML 플로우에 첨부 가능하다.

본 발명의 제3 특징에 따르면, 근원 서비스 요청자를 가진 서비스 계층 구조를 구비한 웹 서비스 아키텍쳐용 컴퓨터 판독가능 저장 매체 상에 저장된 컴퓨터 프로그램 제품에 있어서 - 제1 레벨의 서비스는 하위 레벨의 서비스를 호출함 -, 근원 서비스 요청자가 하나 이상의 서비스에 관한 선호도를 표시하고 순위 결정기가 선호도에 기초한 선택 알고리즘을 갖는 단계, 근원 서비스 요청자가 하나 이상의 레벨의 계층 구조의 서비스를 호출하는 단계, 계층 구조의 각각의 레벨에서, 서비스가 디렉토리를 사용하여 가능한 하위 레벨 서비스 세트를 검색하는 단계, 및 순위 결정기가 선택 알고리즘을 가능한 하위 레벨 서비스 세트에 적용하는 단계를 포함하는 컴퓨터 프로그램 제품이 제공된다.

다음으로, 첨부 도면을 참조하여 본 발명의 실시예를 예시적으로 설명한다.

본 명세서에서, 웹 서비스라는 용어가 사용된다. 그러나, 이것은 웹 서비스가 웹을 통하여 (즉, 브라우저로부터) 호출되어야 함을 의미하지는 않는다. 웹 서비스는 인터넷, 인트라넷, LAN, WAN 등을 포함한 임의 형태의 네트워크로 구현 가능하다. 전술한 바와 같이, 웹 서비스는 프로그램과 프로그램간 통신 모델을 제공하며, 웹 서비스의 기능을 설명하는 인터페이스를 통해 설명된다.

도 1은 서비스 제공자(101), 서비스 레지스트리(102) 및 서비스 요청자(103)의 세 가지 역할을 도시한 웹 서비스 모델(100)을 도시한다. 상호 작용은 공개(publish: 104), 검색(find: 105) 및 결합(couple: 106) 동작을 수반한다. 결합 동작(106)은 느슨하게 결합된 환경에서의 객체들간의 액세스 흐름이다. 웹 서비스 소프트웨어 모듈(107) 및 그 기술(descriptions: 108)인 웹 서비스 아티팩트(artefacts) 상에서 이들 역할 및 동작이 함께 작용한다.

통상적인 시나리오에서, 서비스 제공자(101)는 웹 서비스의 구현인 네트워크 액세스 가능 소프트웨어 모듈(107)을 호스팅(hosting)한다. 서비스 제공자(101)는 웹 서비스(107)에 대한 서비스 기술(108)을 정의하며 그것을 서비스 레지스트리(102)에 공개한다. 서비스 요청자(103)도 푸쉬(push) 동작 보다는 풀(pull) 동작으로서 서비스 제공자(101)로부터 직접 서비스 기술(108)을 전부 혹은 일부 획득 가능하다. 서비스 요청자(103)는 검색 동작(105)을 사용하여 서비스 레지스트리(102)로부터 서비스 기술(108)을 불러오고 서비스 기술(108)을 사용하여 서비스 제공자(101)와 결합(106)하여 웹 서비스 구현(107)을 호출 또는 상호 작용한다. 서비스 제공자(101) 및 서비스 요청자(103)는 역할(roles)이며 서비스는 이들 양자의 특성을 나타낼 수 있다.

서비스 제공자(101)는 적어도 서비스의 프론트 엔드(front end)에 대한 엑세스를 호스팅하는 플랫폼이다. 서비스 요청자(103)는 서비스를 조회 및 호출 또는 상호 작용을 초기화하는 어플리케이션이다. 서비스 요청자 역할은 사용자 인터페이스 없이 개인 또는 프로그램에 의해 구동된 브라우저, 예를 들어 다른 웹 서비스에 의해 실행될 수 있다. 서비스 레지스트리(102)는 서비스 제공자(101)가 그들의 서비스 기술(108)을 공개하는 서비스 기술(108)의 검색 가능 레지스트리이다. 서비스 요청자(103)는 서비스를 검색하고 서비스 기술(108)로부터 결합 정보를 확보하여 서비스를 위한 통신 및 실행을 확립한다.

액세스 가능하도록, 서비스 기술(108)은 서비스 요청자(103)가 그것을 검색할 수 있도록 공개(104)될 필요가 있다. 검색 동작(105)에서, 서비스 요청자(103)는 서비스 기술(108)을 직접 불러오거나 서비스 디스커버리 처리(service discovery process)를 사용하여 요구된 서비스 유형에 대하여 서비스 레지스트리(102)에 질의한다. 결합 동작(106)에서, 서비스 요청자(103)는 서비스 기술(108) 내의 결합 상세를 사용하여 런타임에서 서비스를 호출 또는 상호 작용을 초기화하여 서비스와 접촉 및 호출한다.

서비스 기술(108)은 인터페이스의 상세를 포함하여 서비스를 구현한다. 이것은 그 데이터 유형, 동작, 결합 정보 및 네트워크 위치를 포함한다. 이것은 서비스 요청자(103)에 의한 디스커버리 및 이용을 용이하게 하는 분류도 포함할 수 있다.

도 2를 참조하면, 공개, 검색 및 결합의 세 가지 동작이 상호 동작 가능한 방식으로 수행되도록, 각 레벨의 표준을 포함하는 웹 서비스 스택(200)이 있어야 한다.

웹 서비스가 서비스 요청자에 의해 시행될 네트워크 액세스 가능하여야 하므로, 웹 서비스 스택(200)의 밑단은 네트워크 레벨(201)이다. 스택(200)의 네트워크 레벨(201)에 대해 적용하는 표준 기술은 HTTP, FTP, email, MQSeries, IIOP 등을 포함한다.

다음 레벨은 메시징 규약을 위한 기초로서 XML의 사용자를 나타내는 XML 기반 메시징 레벨(202)이다. XML 메시징 규약에 대한 개선 사항으로서 SOAP를 사용할 수 있다.

그 다음 레벨은 기술 문서의 집합인 서비스 기술 레벨(203)이다. 기술은 세 유형, 즉 위치, 액티비티(activity) 및 인터페이스로 그루핑된다. WSDL은 XML 기반 서비스 기술을 위한 표준이다. WSDL은 서비스 상호 작용의 인터페이스 및 역학을 정의한다. WSDL 문서는 웹 서비스의 보다 상위 레벨 특징을 기술하도록 다른 서비스 기술 문서에 의해 보완될 수 있으며, 예를 들어, 비즈니스 문맥(business context)은 WSDL 문서에 더하여 UDDI 데이터 구조를 사용하여 설명된다.

네트워크 레벨(201), XML 기반 메시징 레벨(202) 및 서비스 기술 레벨(203)의 최초 세 개의 층은 임의의 웹 서비스를 제공하거나 사용하도록 요구된다.

도 2에 도시한 다음 2 레벨의 스택(200)은 다수의 솔루션으로 구현 가능한 서비스 공개 및 서비스 디스커버리 레벨(204, 205)이다. WSDL 문서를 서비스 요청자에 대해 유용하게 만드는 임의의 동작은 서비스 공개이다. 공개 UDDI 레지스트리는 서비스 공개의 사본을 유지한다.

웹 서비스가 공개되어 있지 않으면 웹 서비스를 찾을 수 없으며, 따라 서비스 디스커버리 레벨(205)은 서비스 공개 레벨(204)에 의존한다. 디스커버리 메커니즘의 다양성은 공개 메커니즘에 필적한다. 서비스 요청자로 하여금 서비스 기술에 액세스 가능하게 하고 런타임 중인 어플리케이션에 유용하게 하는 임의의 메커니즘은 서비스 디스커버리로서의 자격을 얻는다.

도 2의 최상위 레벨(206)은 서비스와 서비스간 통신, 협조 및 플로우(flows)가 어떻게 수행되는 지를 설명하는 서비스 플로우 레벨(206)이다.

완전한 웹 서비스 기술은 서비스의 기본 WSDL 설명 상에 세워진다. 완전한 웹 서비스 기술은 다음의 것들을 언급하고 있다: 서비스를 호스팅하는 비즈니즈; 비즈니스 유형 서비스와 연관된 제품; 비즈니스 또는 웹 서비스가 연관된 카테고리; 요청자로 하여금 서비스 호출을 선택하도록 영향을 미칠 수 있는 특징; 서비스 검색을 보다 용이하게 하도록 제공 가능한 키워드 등.

UDDI는 웹 서비스의 기술을 유지하는 메커니즘을 제공한다. UDDI가 디렉토리 메커니즘으로서 종종 간주되지만, 이것은 XML의 서비스 기술 정보를 표현하는 데이터 구조 표준을 정의하기도 한다. 도 3은 4 개의 기본 데이터 구조를 가진 UDDI 엔트리(300)를 도시한다.

UDDI 엔트리는 비즈내즈 객체(301)로 시작한다. 비즈니스 객체(301)는 비즈니즈에 대한 정보를 모델링한다. 비즈니스 객체(301)는 비즈니즈가 공개하기를 원하는 각각의 웹 서비스마다 하나씩인 비즈니스 서비스(302)의 집합을 포함한다. 각각의 비즈니스 서비스(302)는 비즈니스 객체의 웹 서비스에 대한 기술적 및 설명적 정보를 포함한다. 비즈니스 서비스(302)는 결합 템플릿(303) 집합을 포함한다.

결합 템플릿(303)은 액세스 정보, 예를 들어 종점 어드레스(end point address)를 설명하며, 어떻게 비즈니스 서비스(302)가 다양한 기술 명세를 사용하는 지를 설명한다. 기술 명세는 tModel(304)로서 모델링된다. tModel(304)은 서비스 유형, HTTP와 같은 플랫폼 기술 또는 분류(taxonomy)와 같은 많은 서로 다른 개념들을 모델링 가능하다. 비즈니스 객체(301), 비즈니스 서비스(302) 및 결합 템플릿(303)은 정의된 유형의 tModel을 사용하여 구현된다. 비즈니스 서비스(302)와 연관된 결합 템플릿(303) 집합은 비즈니스 서비스(302)에 의해 사용된 기술의 핑거프린트(fingerprint)를 나타낸다.

tModel(304)은 호출 인터페이스 및 결과를 정의한다. 이것은 사용자가 볼 수 없는 하위 레벨에서 API를 통하여 그리고 상위 레벨에서 XML로 표현된다. tModel(304)은 키(key)라고 불리는 고유의 식별자를 가진다. UDDI는 동일 키의 명세를 통하여 하나 이상의 장소에서의 소정의 tModel(304)의 사용을 지원하며, 두 장소에서의 행동이, 외부와 관련되는 한, 추가의 플랫폼 특정 복귀 코드 없이 정확히 동일함을 보증한다.

설명된 방법 및 시스템은 요청 근원자에 대한 모든 UDDI 동작에 대한 참조를 포함한다. 일단 디텍토리 또는 레지스트리가 요청을 처리하면, 결과는 필터링을 위하여 이러한 레퍼런스를 참조한다.

다음으로 도 4a를 참조하여, 웹 서비스 계층(400)을 도시한다. 3 계층(400)의 루트 노드(root node)는 웹 서비스 호출을 원하는 서비스 요청자(401)이다.

3 계층(400)은 서비스 요청자(401)가 호출하기 원하는 엔드 웹 서비스를 찾기 위하여 서비스 요청자(401)에 의해 (직접 또는 간접적으로) 호출될 수 있는 중간 서비스를 나타내는 다수의 서비스 레벨(402, 403)을 구비한다. 엔드 웹 서비스(404)는 3 계층(400) 상의 리프 노드(leaf node)이다. 레벨(402)은 서비스 요청자(401)에 의한 서비스의 선택일 수 있으며, 레벨(403, 404)은 서비스 요청자(401)에 대해 보이지 않는 숨겨진 서브 서비스의 선택일 수 있다.

다음으로 도 4b를 참조하여, 각각의 레벨(402, 403) 상에서 선택된 서비스(406, 408)만을 도시한다. 디렉토리(411)는 서비스 제공자 또는 서비스 형태의 가능한 형태의 일 그룹 또는 백(bag)을 찾기 위해 사용되도록 제공된다.

순위 결정기(ranker machine: 405)는 서비스 선택에 대한 서비스 요청자(401)의 선호도의 세부 사항을 저장하도록 제공된다. 이것은 임의의 적절한 시점에서 순위 결정기(405)에 대해 존재하는 옵션들간의 선택 알고리즘 형태로 제공된다. 서비스 요청자(401)는 순위 결정기(405)에게 임의의 서비스 제공자에 대한 그 선호도를 통지하고, 선택 알고리즘은 서비스 제공자에 대한 선호도를 순위 결정하도록 저장된다.

제1 실시예에서, 순위 결정기(405)는 디렉토리(411) 상의 포트(412) 상에서 대기(listen)한다. 디렉토리(411)가 조회를 행하여 결과 백을 발생시킬 때, 순위 결정기(405)는 포트(412) 상에서 대기하고 결과 백이 순위 결정기(405)에 보내진다. 순위 결정기(405)는 그 선택 알고리즘을 결과 백에 적용하고 서비스 요청자(401)의 선호 순서로 일련의 결과를 디렉토리(411)에 복귀시킨다. 디렉토리(411)는 순위 결정기(405)에 의해 제공된 일련의 결과에 따른 조회에 응답한다.

디렉토리의 서비스를 조회하는 모든 중간 서비스 제공자(402, 403)는 서비스 요청자(401)에 대해 표지된 선호도에 따라 검색 결과를 필터링하는 순위 결정기(405)를 참조한 조회 기능을 가진다. 순위 결정기(405)에 저장된 선호도가 존재하면, 순위 결정기(405)는 선호도에 기초하여 선택을 이루고 중간 서비스 제공자(402, 403)는 다음 레벨의 서비스 제공자를 시행시킬 때 그 선호도를 따를 것이다.

도 4a 및 도 4b에 예시된 예에서, 서비스 요청자(401)는 하위 레벨 서비스를 사용을 수반하는 제1 레벨(402)의 중간 서비스 제공자의 서비스를 사용하기를 원한다. 그러나, 임의의 하위 레벨 서비스가 사용된다는 사실은 서비스 요청자(401)에게 드러나지 않는다. 서비스 요청자(401)는 제1 레벨(402)의 서비스 제공자에 대한 디렉토리(411)를 사용하여 검색을 행하여, 일련의 가능한 서비스 제공자(402)를 얻는다. 일련의 가능한 서비스 제공자(402)는 순위 결정기(405)에 의해 필터링되어 명백한 비경쟁자(non-contenders)를 제거하거나 특정 선택을 강요한다 (즉, 하나의 결과만이 백에 있을 경우). 백에 하나 이상의 결과가 존재하면, 서비스 요청자(401)는 제1 레벨(402)의 서비스 제공자(406) 중의 하나를 선택한다.

디렉토리(411)에 의해 제공된 각각의 조회 응답은 순위 결정기(405)에 의해 필터링되는 잠재적 후보 그룹을 생성한다. 디렉토리(411)의 소프트웨어는 순위 결정기(405)를 참조한다. 디렉토리(411)의 조회를 요청한 객체는 순위 결정기(405)가 존재하지 않았던 것처럼 결과 리스트를 복귀시킨다. 조회를 요청한 객체는 디렉토리(411)에 의해 복귀된 결과에 대한 자유로운 선택권을 가지지만, 복귀된 결과는 순위 결정기(405)에 의해 이미 제한된 것이다.

서비스 요청자(401)만이 제1 레벨(402)의 서비스 제공자(406)와 통신한다. 그러나, 그 작업을 수행하기 위하여, 서비스 제공자(406)는 최종 서비스(end service: 410)를 차례로 사용하는 제2 레벨(403)의 서비스 제공자(408)를 사용한다. 서비스 요청자(401)는 최종 서비스(410) 또는 제2 레벨의 서비스 제공자(408)에 대해 알지 못한다. 마찬가지로, 제1 레벨의 서비스 제공자(406)는 제2 레벨의 서비스 제공자(408)에 의해 사용된 최종 서비스(41)에 대해 알지 못한다.

제1 레벨(402)의 서비스 제공자(406)는 디렉토리(411)의 조회를 수행하여 제2 레벨(403)의 서비스 제공자(408)를 검색한다. 마찬가지로, 제2 레벨(403)의 서비스 제공자(408)는 디렉토리(411)의 조회를 수행하여 최종 서비스(410)를 검색한다. 각각의 조회에서, 디렉토리(411)에 의해 발견된 결과 백은 근원이 되는 서비스 요청자(401)의 선호도에 따라 순위 결정기(405)에 이해 순위 결정된다. 선택 알고리즘에서 순위 결정기(405)에 의해 사용된 선호도는 광범위 하며 계층 내에서 레벨 독립적이다.

제2 실시예에서, 디렉토리는 근원이 되는 서비스 요청자 또는 중간 서비스 제공자일 수 있는 요청자에게 조회 요청 결과를 복귀시키고 요청자는 결과 백을 순위 결정용 순위 결정기에 보낸다. 순위 결정기는 일련의 결과를 요청자에게 복귀시킨다.

양 실시예에서, 서비스 요청자의 선호도는 비용, 효율, 속도 및 신뢰성과 같은 서비스 사안의 품질에 관한 것일 수 있고, 선호도에 영향을 미치는 임의의 기타 선택 사항에 관한 것일 수 있다. 서비스 요청자가 서비스 사용을 원하거나 서비스 사용을 특별히 배제하는 순서로 선호도는 서비스를 순위 결정할 수 있으며 또는 임의의 기타의 선호 지표를 제공할 수 있다.

선호도가 왜 기록되어야 하는 지에 대한 논증은 서비스 요청자에게 요구되지 않으며 선호도는 중간 서비스 제공자에게 보여지거나 이해될 필요는 없다. 서브 서비스(sub-service) 선택의 제어는 공급자와 멀어지며 적어도 근원이 되는 서비스 요청자에 의해 영향을 받는다.

예 1

다음은 사용자로서 언급되는 서비스 요청자에 의해 웹 서비스를 호출하는 예이다. 도 5a는 종래 기술의 UDDI 조회 요청이 작동하는 방법을 도시한다. UDDI 디렉토리는 여기서 {세트}로 표시되는 결과 백을 복귀시킨다.

사용자(501)는 라이브러리 생성을 원하여, UDDI 디렉토리(502)에 요청하여 이것을 행하는 서비스 제공자(503)를 검색한다. 사용자(501)는 요청(511)을 디렉토리(502)에 전송하여 UDDI 조회가 라이브러리 생성기(library builders)를 검색하게 한다. 이 경우, 이러한 카테고리의 단 하나의 서비스 제공자(503)가 있으므로 디렉토리(502)는 {라이브러리 생성기 1} 세트의 결과를 복귀시킨다(512).

사용자(501)는 이어서 "라이브러리 생성" 요청(513)을 서버 라이브러리 생성기 1(504)에 보낸다. 라이브러리 생성기 1(504)은 이어서 UDDI 디렉토리(502)에서 서적 공급자(505) 리스트를 조회한다(514, 515). 디렉토리(502)는 {판매자1, 사용자 선호 판매자 2} 세트를 복귀시킨다 (516). 라이브러리 생성기 1(504)은 그 후 판매자 1(506)인 제1 공급자를 고르거나 서적을 구매하기에 가장 적합한 공급자라고 생각되는 것을 고른다(517). 그 결과, 이 경우 사용자 선호 판매자 2(507)인 사용자가 선호하는 판매자가 아니라 라이브러리 생성기 1에 대해 유리한 곳으로부터 서적이 구매된다(518)

도 5b는 도 5a와 같은 UDDI 조회이지만 본 발명의 제1 실시예에 따른 조회를 도시한다. 설명된 방법 및 시스템은 각각의 UDDI 요청이 사용자의 선호도에 따른 순서로 복귀 백을 순위 결정할 수 있는 곳을 참조하여야 하는 것을 요구한다. 이러한 순위 결정에 어떠한 기준을 사용되는 지는 관련이 없다.

이로써, {백}은 리스트의 전방에 원하는 항목을 가진 <시퀀스>로서 복귀된다. 시퀀스는 백, 서브셋 또는 심지어 완전히 다른 것에 대한 모든 요소를 포함할 수 있다. 이것은 근원적인 UDDI 조회 코드 (즉 근원적인 UDDI APls)이며 참조를 행한다. 여분의(extra) 코드 단계는 호출자에게 요구되지 않는다.

도 5b는 서적 공급자(509)에 대하여 사용자(501)에 의해 표지된 선호도를 반영하는 선택 알고리즘을 유지하는 순위 결정기(508)의 추가 성분을 가진다.

사용자는 UDDI 디렉토리(502)에 요청하여(521) 라이브러리 생성기를 검색한다. 디렉토리(502)는 {라이브러리 생성기 1} 세트를 검색한다. 그러나, 참조가 없는 국부 요청이 여전히 순위 결정되어야 하며 이것은 구성 옵션(configuration options)을 통해 이루어져 사용자에게 보여지지 않는다는 것을 서비스 제공자의 근원적인 층은 인지하고 있기 때문에, 이것은 사용자(501)에게 노출되지 않는다. 이로써, UDDI 디렉토리(502)로부터의 복귀 흐름은 그 후 분석을 위해 국부 순위 결정기(508)를 참조한다. 허용 가능한 <라이브러리 생성기 1>인 하나의 선택만이 존재하므로, 결과는 변경되지 않으며 결과를 사용자(501)에게 돌려 보내는(524) UDDI 디렉토리(502)에 초기에 돌려 보내진다(523).

사용자(501)는 이어서 제1 (및 이 예에서는 유일한) 공급자(504)를 고르고 라이브러리 생성 동작을 호출한다(525). 이것은 서비스에 대한 XML/SOAP 요청이며 이로써 요청된 순위 결정기(508)의 위치를 XML 흐름에 첨부한다는 사실을 근원적인 층은 인지한다.

공급자, 라이브러리 생성기 1(504)은 이어서 UDDI 디렉토리(502)가 서적 판매자(504) 리스트를 검색하고 플로우 상에 적절한 순위 결정기(508)의 위치를 첨부할 것을 요청한다(526). 이러한 디렉토리 조회(527)은 보유한 서적 판매자 세트{판매자 1, 사용자 선호 판매자 2}를 복귀시킨다. 근원적인 층은 이어서 이전과 마찬가지로 순위 결정기(508)에 대해 이러한 세트를 참조한다(528). 이 경우, 순위 결정기(508)는 사용자 선호 서적 공급자(509)의 사용을 강요하기를 원하여, 그 조회(507) 결과로서 라이브러리 생성기(504)에 결과를 돌려 보내는(530) UDDI 디렉토리(502)에 결과를 돌려보내기 전에 UDDI 결과를 시퀀스 <사용자 선호 판매자 2>로 변경시킨다. 결과적으로, 서적은 이제 판매자 1(506)이 아니라 사용자 선호 판매자 2(507)로부터 주문된다(321, 322).

도 5c는 도 5a 및 도 5b와 같은 UDDI 조회이지만 본 발명의 제2 실시예에 따른 조회를 도시한다. 도 5b에 도시한 바와 같이, 앞서 설명한 방법 및 시스템은 각각의 UDDI 요청이 사용자의 선호도에 따른 순서로 복귀 백을 순위 결정할 수 있는 곳을 참조하여야 하는 것을 요구한다. 이러한 순위 결정에 어떠한 표준을 사용할 것인 지는 관계없다.

다시, {백}은 리스트의 전방에 원하는 항목을 가진 <시퀀스>로서 복귀된다. 제2 실시예에서, UDDI 디렉토리(502)에 대한 조회의 요청자는 결과 {백}을 수신하며 순위 결정용 순위 결정기(508)에 대해 백을 참조하며 요청자는 이어서 사용자(501) 선호도에 따라 순위 결정기(508)로부터 <시퀀스>를 수신한다.

구현

제1 실시예에서, 순위 결정기는 UDDI/순위 결정기 포트 상에서 대기하며 tModel 그룹을 선택된 그룹의 tModel로 전환하는 상술한 플로우를 처리한다.

UDDI API 용어에서, 10개의 find_xx 동사는 순위 결정기의 URL:포트를 추가함으로써 확장된다.

예를 들어,

<fine_tModel [maxRows="n"] generic"2.0 xmlns="urn:uddi-org:api_v2">

[<findQualifiers/>] [name/.] [<identifierBag/>] [<categoryBag/>]

</find_tModel>]

은 다음과 같이 전환될 수 있다:

<fine_tModel [maxRows="n"] generic"3.0" xmlns="urn:uddi-org:api_v3">

[<Ranker>ranker_rul</Ranker>]

[<findQualifiers/>] [name/>] [<identifierBag/>] [<categoryBag/>]

</find_tModel>]

서비스의 SOAP/XML 실행 측면에서, 이것은 순위 결정기 URL(ranker URL)을 포함하도록 확장될 것이다. 이것은 후속 UDDI 관련 시행에 대해 통과되어야 한다는 UDDI 패러다임의 요구 사항이다.

<wsdl:declarations>

.......

<wsdl:ranker> ?

<wsdl:rankerurl [port="nn">url</wsdl:rankerurl>

</wsdl:ranker>

.......

</wsdl:declarations>

이 플로우는 WSDL 공급자에 의해 삽입 또는 처리되거나 적어도 이 기능은 UDDI 서버 (A 어드레스:포트가 조회 요청을 통과하는 것과 같이) 또는 UDDI 처리에 사용된 호출자의 DLL에 잠복한다. 이 경우, UDDI 조회 처리는 호출자의 개입 없이 필터링을 행한다.

이러한 순위 결정기 어드레스를 수신하는 서비스가 후속 UDDI/XML/SOAP 동작에 대한 통과를 방해하지 않는다면, 이것은 규약 침해일 것이며 서비스는 규칙에 따라 행동하지 않을 것이다.

그러나, 새로운 엔트리가 결합 템플릿 및 비즈니스 서비스 tModles에 부가되어 서비스가 이러한 규칙을 준수하는 지 여부를 나타낸다. 이러한 요소는 <RankingSupported/>로 간주될 수 있다. <RANKER> 요소가 호출 상에 공급되고 <RankingSupported/>가 존재하지 않으면, fine_xx APls는 tModel을 선택하지 않을 것이다.

API 실행 측면에서, 이것은, 필수적으로, UDDI 디렉토리를 호스팅하는 박스 상에서 수행된다. 선택을 행하는 코드가 수정되어 새로운 API 및 tModel 태그(tags)를 지원한다.

따라서, 이러한 설명은 UDDI/WSDL 규약에 연관된 확장과 함께 URL 요청을 처리하도록 순위 결정기를 사용하는 것이 어떻게 새로운 근원자 선호 선택 기능을 UDDI 패러다임 속에 도입할 수 있는 지를 보여준다.

하나의 서비스 제공자가 이용 불가능하여 다른 사용자가 선택되어야 하는 상황에서는, 다음이 적용된다. 실제 서비스 자체가 특정 결합 tModel에 의한 인터페이스(파라미터 호출) 레벨에서 특정된다. 특정 서비스가 요구되면, 특정 tModel이 사용되어 (또는 그 밖의 많은 서로 다른 XML 시행이 코딩되어) 결합 템플릿을 호출해야 한다. 특정 tModel을 사용하는 공급자가 바람직하지 않으면 (너무 느리거나, 너무 비싸거나, 작업하지 않는 등) 문제가 발생하며 코드는 다른 인터페이스를 갖는 다른 공급자를 사용하도록 변경될 수 없다.

기록 문제를 방지하기 위하여, 다른 공급자는 정확히 동일 인터페이스로 선택되어야 한다: 즉, 동일 결합 tModel을 사용하는 것. 이것은 UDDI 조회를 통하여 용이하게 수행된다.

UDDI는 공적 (즉, 일반적으로 이용 가능한) 디렉토리 및 사적 (즉, 호출자에 대해 특정된) 디렉토리를 지원함을 인지하여야 한다. 모든 요청 서비스가 사적 디렉토리 범주 내 (동일 조직 내 및 동일 - 또는 모사된 - UDDI 서버를 사용하는)에 있어서 이러한 사적 디렉토리에서 사실상 이루어지는 것에 의해서만 선호도 사안이 다루어질 수 있으면 괜찮다. 그러나, 요청이 사적 디렉토리 범주 밖에서 실행되면 이러한 접근법은 부적절하다. 설명된 방법 및 시스템은 이러한 문제점을 해결한다.

또한, UDDI는 비즈니스간의 관계성(PublisherAssertion)을 위한 tModel을 지원한다. 이것은 공급자를 일종의 보다 큰 객체로 링크시키는 것을 목적으로 한다. 비즈니스간의 관계성이 공적(Public), 정적(Static)이며 이것을 통지받게 된다는 보증이 없으므로, 이것은 설명된 방법 및 시스템과 중첩하지 않는다.

이상의 설명에 대해 본 발명의 범주에서 벗어나지 않는 개선 및 수정도 가능함은 자명할 것이다.

Claims

근원 서비스 요청자(401)를 가진 서비스 계층 구조(401, 406, 408, 410)를 구비한 웹 서비스 아키텍쳐의 서비스를 순위 결정하는 방법에 있어서, 상기 계층 구조의 제1 레벨의 서비스는 하위 레벨의 서비스를 호출하고, 상기 방법은,

상기 근원 서비스 요청자(401)가 하나 이상의 서비스에 관한 선호도를 표시하고 순위 결정기(405)가 상기 선호도에 기초한 선택 알고리즘을 갖는 단계,

상기 근원 서비스 요청자(401)가 하나 이상의 레벨의 계층 구조의 서비스를 호출하는 단계,

상기 계층 구조의 각각의 레벨에서, 서비스가 디렉토리(411)를 사용하여 가능한 하위 레벨 서비스 세트를 검색하는 단계, 및

상기 순위 결정기(405)가 상기 선택 알고리즘을 상기 가능한 하위 레벨 서비스 세트에 적용하는 단계

를 포함하는 방법.
제1항에 있어서, 상기 하위 레벨 서비스는 서비스 요청자 또는 서비스 제공자인 방법.
제1항 또는 제2항에 있어서, 상기 가능한 하위 레벨 서비스 세트는 디렉토리(411)로부터 순위 결정기(405)에 참조되며 선호하는 시퀀스는 상기 순위 결정기(405)에 의해 상기 디렉토리에 리턴(return)되는 방법.
제3항에 있어서, 상기 순위 결정기(405)를 참조하는 단계는 상기 디렉토리(411)를 사용하는 상기 서비스에게 보이지 않는 방법.
제1항 또는 제2항에 있어서, 상기 가능한 하위 레벨 서비스 세트는 상기 디렉토리(411)를 사용하는 상기 서비스에 의해 상기 순위 결정기(405)에 보내지며 선호하는 시퀀스는 상기 순위 결정기(405)에 의해 상기 서비스에 리턴되는 방법.
제1항 내지 제5항 중의 어느 한 항에 있어서, 단일 결과 또는 일련의 결과가 상기 디렉토리(411)를 사용하는 상기 서비스에 리턴되는 방법.
제1항 내지 제6항 중의 어느 한 항에 있어서, 상기 계층 구조의 서비스의 하위 레벨 호출은 상위 레벨 서비스에게 보이지 않는 방법.
제1항 내지 제7항 중의 어느 한 항에 있어서, 상기 근원 서비스 요청자(401)의 상기 선호도는 상기 근원 서비스 요청자(401)가 상기 서비스 사용을 원하는 순서로 서비스를 순위 결정하고, 서비스 사용을 배제하고/하거나 기준(criteria)에 영향을 미치는 다른 선택을 제공하는 방법.
제1항 내지 제8항 중의 어느 한 항에 있어서, 상기 근원 서비스 요청자(401)의 상기 선호도는 비용, 효율, 속도 및 신뢰성을 포함하는 서비스 기준의 품질에 기초하는 방법.
제1항 내지 제9항 중의 어느 한 항에 있어서, 근원 서비스 요청자의 선호도가 존재하는 경우, 상기 선호도는 상기 디렉토리(411)를 사용하는 상기 서비스에 의한 선택에 우선하는 방법.
제1항 내지 제10항 중의 어느 한 항에 있어서, 상기 선호하는 서비스가 이용 불가능하면, 후속 서비스가 상기 근원 서비스 요청자의 선호도를 참조하여 달성되는 방법.
제1항 내지 제9항 중의 어느 한 항에 있어서, 근원 서비스 요청자의 선호도가 저장되어 있지 않으면, 디렉토리(411)를 사용하는 상기 서비스가 상기 선택을 행하는 방법.
웹 서비스 아키텍쳐에 있어서,

루트 근원 서비스 요청자(401),

제1 레벨의 서비스가 하위 레벨의 서비스를 호출하는 서비스 계층 구조(401, 406, 408, 410),

상기 계층 구조에서 서비스를 검색하기 위한 디렉토리(411), 및

하나 이상의 서비스에 관한 상기 근원 서비스 요청자의 선호도에 기초하여 서비스에 대한 선택 알고리즘을 적용하는 수단을 구비한 순위 결정기(405)

를 포함하며,

상기 계층 구조의 각각의 레벨에서, 상기 디렉토리(411)는 가능한 서비스 세트를 제공하며 상기 순위 결정기(405)는 상기 선택 알고리즘을 적용하여 일련의 선호하는 서비스를 제공하는 웹 서비스 아키텍쳐.
제13항에 있어서, 상기 하위 레벨 서비스는 서비스 요청자 또는 서비스 제공자인 웹 서비스 아키텍쳐.
제13항 또는 제14항에 있어서, 상기 순위 결정기(405)는 포트(412)에 의해 상기 디렉토리(411)에 접속되고 상기 가능한 서비스 세트는 상기 디렉토리(411)에 의해 상기 순위 결정기(405)를 참조하며 상기 일련의 선호하는 서비스는 상기 순위 결정기(405)에 의해 상기 디렉토리(411)에 리턴되는 웹 서비스 아키텍쳐.
제13항 내지 제15항 중의 어느 한 항에 있어서, 제1 레벨의 서비스는 UDDI 디렉토리(411)에 의해 하위 레벨의 서비스를 검색하는 웹 서비스 아키텍쳐.
제16항에 있어서, 상기 순위 결정기(405)는 상기 UDDI 디렉토리(411) 상의 포트(412)를 가지며 TModel 백(bags)을 선택된 세트의 TModel들로 전환시키는 플로우를 처리하는 웹 서비스 아키텍쳐.
제16항 또는 제17항에 있어서, 각각의 UDDI 동작은 상기 순위 결정기(405)에 참조되며 상기 서비스 요청자의 선호도와 일치하는 시퀀스로서 리턴되는 웹 서비스 아키텍쳐.
제16항 내지 제18항 중의 어느 한 항에 있어서, 근원 UDDI 어플리케이션 코드는 상기 참조를 수행하며 상기 순위 결정기(405)의 위치를 후속 XML 플로우에 첨부하는 웹 서비스 아키텍쳐.
루트 근원 서비스 요청자(401)를 가진 서비스 계층 구조(401, 406, 408, 410)를 구비한 웹 서비스 아키텍쳐용 컴퓨터 프로그램 제품에 있어서, 제1 레벨의 서비스는 하위 레벨의 서비스를 호출하고, 상기 제품은,

상기 근원 서비스 요청자(401)가 하나 이상의 서비스에 관한 선호도를 표시하고 순위 결정기(405)가 상기 선호도에 기초한 선택 알고리즘을 갖는 단계,

상기 근원 서비스 요청자(401)가 하나 이상의 레벨의 계층 구조의 서비스를 호출하는 단계,

상기 계층 구조의 각각의 레벨에서, 서비스가 디렉토리(411)를 사용하여 가능한 하위 레벨 서비스 세트를 검색하는 단계, 및

상기 순위 결정기(405)가 상기 선택 알고리즘을 상기 가능한 하위 레벨 서비스 세트에 적용하는 단계

를 수행하는 컴퓨터 판독가능 프로그램 코드 수단을 포함하는 컴퓨터 프로그램 제품.