KR20040071308A

KR20040071308A - 네트웍 기반 서비스들로의 억세스를 도모하는 시스템 및방법

Info

Publication number: KR20040071308A
Application number: KR10-2004-7010806A
Authority: KR
Inventors: 니카넨페트리; 포자셉포; 코이부헤이크키
Original assignee: 노키아 코포레이션
Priority date: 2002-01-11
Filing date: 2003-01-06
Publication date: 2004-08-11
Also published as: AU2003235777A1; KR100718026B1; CN1636200A; WO2003058474A1; US20030133554A1; EP1464002A1

Abstract

웹 서비스 요소 억세스를 도모하기 위한 시스템 및 방법. 어플리케이션 인터페이스의 복잡성을 줄이고 그에 따라 어플리케이션(402)의 간편성을 증가시키기 위해, 어플리케이션(402)에 대해 브로커에 대한 하나의 논리적 목적(OLVB) 어플리케이션 프로그램 인터페이스(API)가 설정된다. 네트웍 서비스 브로커 관련 패러미터들(204, 304)은 어플리케이션(402)으로부터 선택의 세부사항을 감추면서, 최선의 정합 네트웍 브로커나 웹 서비스 요소에 대한 요청을 가능하게 한다. 서비스 제공 하부구조(208)와 네트웍 서비스 브로커들(212, 232, 238) 간 실시간 비즈니스 관계가 룩업 기능(414) 내 짝 만들기 기능(416)을 이용해 도모된다.

Description

네트웍 기반 서비스들로의 억세스를 도모하는 시스템 및 방법{System and method for facilitating access to network based services}

오늘날의 통신 기술은 네트워킹 기반 구조의 극적인 확대 및 다양화를 가져오고 있다. 네트웍 억세스는, 두 네트웍 노드 간의 간단한 일대일(point to point) 접속 스레드(threads)로부터, 각 네트웍 노드가 노드에서 노드로의 왕래를 위해 필요한 통신 규칙이나 프로토콜에 따르고 있는 유선 및 무선 네트웍들 모두에 분포된 이동 전화, 고정 워크스테이션, 랩탑 컴퓨터, 개인 데이터 보조기(PDA), 어플리케이션 서버 등으로 이뤄진 수십만 노드들을 포함하는 복잡한 멀티-포인트(multi-point) 접속 웹들에 이르기까지 진보해 왔다.

통신 네트웍 및 그 관련 통신 프로토콜들의 다양화는 통신에 대한 과잉의 표준화 모델들을 양산해 내었다. 이러한 표준화 모델들 가운데 많은 수가 개방형 시스템 연결(OSI, Open System Interconnection) 기준을 채택해, 일대일 데이터 통신에 매우 급급한 베이스라인 모델로서 사용되어 왔다. OSI 모델은 분포된 어플리케이션 프로세싱을 위해 개방형 시스템들을 연결하는 기준을 제공함으로써, 데이터 제공자들끼리 통신하도록 허용하는 일군의 표준들의 발전을 위한 공통적인 토대를 제공한다. OSI 모델은 수직으로 정렬되거나 쌓이는 7 개의 통신 계층을 설정하며, 이것은 두 통신 개체들 간에 설정되는 물리적 입/출력(I/O) 포트들을 제공하는 최하부 계층에서 시작된다. 다른 6개의 계층, 또는 피어(peer)들은 특정 계층에 대해 설정된 프로토콜에 따라 실질적으로 서로 연결되어 있다.

월드 와이드 웹(WWW), 또는 인터넷이 가령 OSI 기준 모델에 따라 정의된 것과 같은 일대일 통신 모델에 의해 반드시 억세스되는 것은 아니며, 대신 도처에 존재하는(ubiquitous) 인터넷 프로토콜(IP) 및 하이퍼텍스트 전송 프로토콜(HTTP)과 확장형 마크업 랭귀지(XML)와 같은 데이터 형식을 활용해 그 인터페이스를 지원한다. 인터넷 내에서의 일대일 통신이 보다 분산된 억세스로 바뀌고 있음에 따라, 독립 조작 가능(standalone) 컴퓨팅 어플리케이션들도 보다 통합되는 쪽으로 바뀌고 있으며, 이때 어플리케이션들, 기기들, 및 서비스들은 인터넷 안에서 함께 작업하여 공통된 목적을 달성한다. 또, 현재 많은 비율의 비즈니스 프로세스들이 상호 작용이 점점 자동화되어 가는 교섭 파트너들과 관계하기 때문에, 이 통신 모델은 서비스 위주의 표현, 또는 웹 서비스 모델 쪽으로 진행해 나가고 있다. 웹 서비스 모델은 방화벽 통과, 가변하는 동작 시스템 환경을 갖는 동작과, 가변하는 미들웨어 기술을 가진 동작을 요구하는 어플리케이션들의 통합을 수월하게 하도록 돕는다.

두 프로그램들 간 상호작용을 위한 웹 서비스 모델은 가령 HTTP와 같은 이송수단을 이용하는 XML 표준에 기반하고 있다. 각 프로그램은 클라이언트들이 인식하는 XML 표준을 사용해 자신의 인터페이스들과 기타 사양들을 공개한다. 클라이언트들은 느슨한 연결을 촉진하고 여러 대상들과 연루된 프로그램들에 대해 이상적인 XML-기반 프로토콜을 이용해 프로그램들과 상호 동작한다. 그러나, 느슨한 연결의 한가지 결과로서, 비공개 웹 서비스 또는 웹 요소로부터의 서비스를 요구하는 어떤 클라이언트에게 필요한 웹 서비스를 자동으로 찾도록 요구될 수 있다는 것이다.

웹 서비스 어플리케이션들이 점차 대중적이 되어감에 따라, 많은 실행 환경들이, 약간만 이름을 대자면 자바 환경, 마이크로소프트.Net 및 리눅스와 같은 웹 요소 어플리케이션들을 수용하도록 발전되어 가고 있다. 예를 들어, 자바 2 엔터프라이즈 에디션(J2EE)은 판매자 시장과 거대한 개발자 사회 내에서 큰 인기를 누리고 있다. 가령 J2EE는 사업 어플리케이션들에 대해, 많은 다른 유형의 실행 플랫폼들 위에서 실행할 수 있는 표준화된 모듈라 요소들에 기초를 둠으로써 그 사업 어플리케이션들을 단순화한다.

웹 서비스들은 사업체들 사이 및 그 안에서 고정형 및 이동형 네트웍들 모두에 걸쳐 비즈니스 기능들을 연결하는데 이상적인 특성을 갖는 한 모델을 규정한다. 네트웍 서비스 브로커들(NSB)이 생성되어, 상기 고정형 또는 이동형 네트웍들 안에 분포된 단말들에서 실행될 수 있는 다른 네트웍 요소들로 네트웍 서비스 기능을 제공한다. 그러나, NSB에 의해 노출된 서비스들은 단말이 활용하고 있는 특정한 이동형 또는 고정형 네트웍에 따라 빈번하게 좌우된다. 예를 들어, 이동 단말의 경우, 로밍(roaming)은 그 이동 단말로 하여금, 단말이 각 네트웍을 지나면서 많은 네트웍들에 노출될 수 있게 한다. 각 네트웍은 그 자신의 NSB를 가질 수 있으며, 이것은 그 NSB에 의해 제공되는 네트웍 서비스들로의 억세스를 가능하게 한다. 그러나, 그 NSB 및 결부된 네트웍들은 흔히 서로 다른 비즈니즈 관계를 가지며, 이것이 로밍 협정을 복잡하게 한다.

일반적인 웹 서비스들로부터 서비스를 요청하는 현재의 방법이 가진 다른 문제는, 그 웹 서비스들에 의해 제공되는 서비스들의 발견시 내재하는 복잡성이다. 요청하는 어플리케이션에게 제공되는 인터페이스들은 보통 복잡하고 맞춤화되어 있어, 요구하는 어플리케이션에 의해 제공 서비스의 완전한 발견이 수행될 수 있기 전에 웹 서비스에 대한 특정한 지식을 필요로 한다. 일단 발견되었으면, 특정 웹 서버의 활용 방법은 한층 더 나아간 정도의 복잡함을 제공한다. 알 수 있는 바와 같이, 웹 서비스 발견 및 웹 서비스 활용을 수행하는 요청 어플리케이션들은, 의미있는 데이터 교환이 일어나기 전에 그 웹 서비스에 대해 맞춤화될 것이 요구된다.

네트웍 서비스들로의 네트웍 억세스가 점점 분산되어 감에 따라, 종래의 네트웍 억세스 패러다임은 시대에 뒤진 것이 되어, 미래를 위해 단순화된 패러다임에 대한 필요성이 필연적으로 따르게 된다. 네트웍 서비스들에 대한 특정한 지식이 없는 어플리케이션들로부터의 서비스 요청들이 수월해 질 수 있도록, 예를 들어 그러한 네트웍 서비스들이나 그들의 브로커들에 대한 단순화된 논리적 목적이 요구된다. 네트웍 서비스들에 대한 단순화된 논리적 목적은 어떠한 실행 환경 내에서도 실행이 수월하게 될 수 있도록 일반화되어야 한다. 또, 네트웍 서비스가, 이동 단말, 어플리케이션 서버, 개인용 컴퓨터 등과 같이 필요한 어떤 네트웍 요소 안에 존재하도록 허용되어져야 한다.

이에 따라, 네트웍 통신 산업에 있어서 개발자 우호적 웹 서비스들 또는 웹 요소들이 활용될 수 있도록 특별한 기능이 부여된 기술을 가진 웹 서비스 클라이언트들이 갖춰질 필요가 있다. 이러한 웹 서비스 클라이언트들은, 웹 서비스 클라이언트의 복잡함을 줄이고 휴대 간편성을 증가시키는 하나의 논리적 목적을 가진 어플리케이션 프로그램 인터페이스들(APIs)을 필요로 한다. 본 발명은 이러한 종래 기술이나 기타의 단점을 해결하고, 종래의 네트웍 서비스 억세스에 비해 수많은 이점을 제공한다.

본 발명은 일반적으로 네트웍 통신 시스템에 관한 것으로서, 보다 상세하게는 네트웍 통신 시스템들에 의해 제공되는 네트웍 서비스들로의 억세스를 수월하게 하기 위한 시스템 및 방법에 관한 것이다.

본 발명은 이하의 도면들에 예시된 실시예들과 관련지어 기술될 것이다.

도 1은 통신 네트웍을 도시한 것이다.

도 2는 네트워킹된 서비스 브로커들의 집합에서 한 서비스 브로커를 찾는 어플리케이션을 도시한 것이다.

도 3은 네트워킹된 웹 서비스 요소들의 집합에서 한 웹 서비스 요소를 찾는 어플리케이션을 도시한 것이다.

도 4는 브로커 예에 대한 한 논리적 목적으로의 소프트웨어 인터페이스 방식을 도시한 것이다.

도 5는 브로커 예에 대한 한 논리적 목적으로의 프로토콜 인터페이스 방식을도시한 것이다.

도 6은 웹 서비스들로의 단순화된 억세스의 동작을 설명함에 있어 유용한 흐름도를 도시한 것이다.

본 발명은 네트웍 서비스들에 대한 억세스를 수월하게 하기 위한 시스템 및 방법에 대한 것이다. 본 발명은 프로토콜 기반 또는 소프트웨어 기반 인터페이스 모듈 정의를 제공하는데 관여하며, 이러한 정의는 네트웍에 걸친 웹 서비스 선택시 내재되는, 찾기 및 서비스 활용 세부 사항과 관련된 복잡성을 감춘다. 본 발명은 상기 인터페이스 모듈이 관련 네트웍들 간 비즈니스 관계에 관한 정보를 유지할 수 있게 하고, 또한 인터페이스 모듈이 어플리케이션에 의해 요구된 것과 같은 최선의 정합 NSB 또는 웹 요소를 자동으로 선택하도록 여러 개의 패러미터들을 가지는 결정 기능을 채용할 수 있도록 한다. 또 본 발명은 인터페이스 모듈로 하여금 네트웍들의 짝 찾기(matchmaking) 프로세스로 자동 진입할 수 있게 하는 한편, 그 네트웍들의 소유자들과 SPI 간의 직접 상호 동작을 없앤다.

본 발명의 일실시예에 따르면, 복수개의 서비스 요소들을 포함하는 네트웍 안에 네트웍 서비스들을 설정하는 방법이 제공된다. 이 방법은 복수개의 인터페이스 모듈들을 제공하여 복수개의 서비스 요소들 중 하나와 통신을 설정하도록 한다. 또한 이 방법은 복수개의 인터페이스 모듈들에 대한 하나의 논리적 억세스 포인트를 제공하여 복수개의 서비스 요소들 중 하나의 쇄신이 수월해지도록 한다. 이러한 방법은 서비스 요소 관련 패러미터들을 수신하여 상기 쇄신에 따라 복수개의 서비스 요소들 중 하나를 선택한다. 서비스 요소 관련 패러미터들은 복수개의 서비스 요소들 중 하나에 대해 동적 선택 최적화를 규정한다. 인터페이스 모듈들은 소프트웨어나 프로토콜 기반 모듈들이다.

본 발명의 다른 실시예에 따르면, 서비스 요청 및 관련 소비스 요청 패러미터들에 따라 네트웍 서비스들을 촉진하는 시스템이 제공된다. 이 시스템은 한 네트웍 안에 분포된 복수개의 서비스 요소들과 그 복수개의 서비스 요소들과의 통신을 설정하기 위해 복수개의 인터페이스 오브젝트들을 포함하는 인터페이스 모듈을 구비한다. 인터페이스 모듈은 복수개의 서비스 요소들 중 하나와 복수개의 인터페이스 오브젝트 중 하나 사이에 요구되는 연결 패러미터들을 설정하기 위한 복수개의 인터페이스 오브젝트들과의 통신시의 룩업(lookup) 오브젝트, 복수개의 서비스 요소들과 연관된 속성들을 식별하는 패러미터들을 제공하기 위한 상기 룩업 오브젝트와의 통신시의 데이터 오브젝트, 및 복수개의 인터페이스 오브젝트들로의 외부 억세스를 가능하게 하는 단일 논리 억세스 포인트를 포함한다.

본 발명의 또 다른 실시예에 따르면, 복수개의 서비스 요소들을 포함하는 네트웍 안에 네트웍 서비스들을 설정하기 위한 컴퓨터-실행 명령들을 구비하는 컴퓨터-판독 가능 매체가 제공된다. 컴퓨터-실행 가능 명령들은 복수개의 서비스 요소들 중 하나와 통신을 설정하도록 복수개의 인터페이스 모듈들을 제공하는 동작을 수행한다. 복수개의 인터페이스 모듈들로의 한 논리 억세스 포인트는 복수개의 서비스 요소들 중 하나의 외부적 쇄신을 가능하게 한다. 본 발명의 동작에는, 서비스 요소 관련 패러미터들을 수신하는 동작과, 상기 쇄신에 따라 복수개의 서비스 요소들 중 하나를 선택하는 동작이 더 포함된다. 상기 서비스 요소 관련 패러미터들은 복수개의 서비스 요소들 중 하나에 대한 동적 선택 최적화를 규정한다.

상술한 본 발명의 개요는 본 발명의 각 실시예 또는 구성을 설명하기 위한 것이 아니다. 그것은 다음에 이어지는 관련 설명 및 도면들을 위한 것이다.

여러가지 실실예들에 대한 이하의 설명에서, 명세서의 일부로서 첨부된 도면들이 참조되며, 이들은 본 발명이 실시될 수 있는 다양한 실시예들을 예로서 보이고 있다. 다른 실시예들이 활용될 수 있고, 본 발명의 범주를 벗어남이 없이 구조적이고도 기능적인 변형이 이뤄질 수 있다는 것이 이해되어야 한다.

본 발명은 네트웍 서비스들로의 억세스를 수월하게 하기 위한 시스템 및 방법에 관한 것이다. 본 발명은 프로토콜 기반 혹은 소프트웨어 기반 인터페이스 모듈 규정을 제공하는 동작을 수반하며, 그 규정은 네트웍을 통한 웹 서비스 선택시 내재되는 찾기 및 서비스 활용 세부사항들과 관련된 복잡성을 감춘다. 본 발명은 인터페이스 모듈로 하여금 관련 네트웍들 간 비즈니스 관계에 대한 정보를 보유하도록 하고, 어플리케이션에 의해 요청된 최선의 정합 NSB 또는 웹 서비스 요소를 자동으로 선택하기 위해 여러 패러미터들을 가진 결정 동작을 채용할 수 있도록 한다. 본 발명은 또한 인터페이스 모듈로 하여금 네트웍들과의 짝짓기 프로세스에 자동으로 진입할 수 있도록 하면서, 네트웍들의 소유자 및 SPI 사이의 직접적인 상호 동작을 없앤다.

도 1은 본 발명의 원리에 따른, 개발자 우호적 웹 서비스, 또는 웹 요소, 억세스를 채용하는 네트웍 시스템(100)의 전형적 실시예이다. 단말(110)은 이동 장치(TE), PDA 또는 랩탑 컴퓨터 등과 같은 어떤 이동 네트웍 요소를 포함할 것이다. 단말(110)은 또한 개인용 데스크 탑 컴퓨터나 어플리케이션 서버 등과 같은 어떤 고정 네트웍 요소도 역시 포함할 수 있다. 네트웍(130)은 인터넷, 이동 통신 네트웍, 공공 또는 사설 지상 라인 통신 네트웍 또는 이들의 임의의 조합 형태를 구비한다. 웹 서비스 요소(140)는 네트웍(130)에 대한 웹 서비스로서 제공되는 임의의 네트웍 요소와 같은 것을 포함한다. 일반적으로, 웹 서비스 요소(140)는 웹 서비스, NSB, 또는 어플리케이션(120)에 의해 억세스 가능한, 웹 서비스와 조화된 인터페이스를 포함하는 어떤 요소이다. 웹 서비스 요소(140)는 가령 어플리케이션(120)의 서비스 최종 지점이라고 생각될 수 있고, 또한 이동 단말, 서버, 네트웍 요소 등에 해당하는 것일 수 있다. 웹 서비스 요소(140)로의 프로토콜 억세스는 HTTP, 심플 오브젝트 억세스 프로토콜(SOAP), 또는 비즈니스 트랜잭션 프로토콜(BTP) 등과 같은 임의의 수의 프로토콜들을 이용해 구현되지만, 이들 말고 전송 제어 프로토콜/인터넷 프로토콜(TCP/IP) 또는 유저 데이터그램 프로토콜(UDP) 등과 같은 다른 웹 아닌 서비스 스택 프로토콜들을 사용해서 억세스될 수도 있다. 어플리케이션(120)은 임의의 네트웍 가능 서비스를 요청할 수 있는 임의의 노드를 나타내지만, 인터페이스 모듈(150)을 통해, 요구되는 바른 최종 지점 또는 웹 서비스 요소로 연결될 수도 있다. 인터페이스 모듈(150)은 다양한 실행 환경들에서 구동되는 자바 어플리케이션이라고 예를 들 수 있으나, 가령 마이크로소프트.넷 또는 리눅스 환경과 같은 임의의 실행 환경에서도 구동하는 어플리케이션들을 나타낼 수도 있다. 또한, 네트웍(130)과 인터페이스 모듈(150) 사이의 프로토콜 인터페이스는 HTTP, SOAP, BTP, 등을 포함해 임의의 수의 프로토콜 스택들에 기반할 수 있다. 어플리케이션(120)은 본 발명에 따라, 웹 서비스 요소(140)에 대한 어떤 가시성(visibility)도 유지하고 있지 않는데, 이는 인터페이스 모듈(150)이 어플리케이션(120)으로부터 웹 서비스 요소(140)를 선택하는데 있어서의 복잡도를 감추는데 효과적인 모든 비즈니스 관련 기능을 제공하기 때문이다. 인터페이스 모듈(150)에 의해 제공되는 단순화된 논리적 목적은 소프트웨어 기반이나 프로토콜 기반의 인터페이스에 의해 구현될 수 있으며, 이때 최선의 웹서비스 요소, 또는 최종 지점의 선택에 대한 세부 내용은 어플리케이션(120)으로부터 감춰진다. 또, 인터페이스 모듈(150)은 동적 결정 기능을 제공하여, 네트웍(130) 내의 비즈니스 관계가 필요할 때 자동으로 설정될 수 있게된다.

도 2는 어플리케이션(202)이 SPI(208)로부터 서비스를 요청하는 상황을 도시한 것으로, 여기서 여러 개의 NSB들(212, 220, 및 238)이 그 요청된 서비스를 제공하도록 선택된다. 어플리케이션(202)은 이하에서 상세히 설명될 인터페이스(206)에 의해 예시된 프로토콜 인터페이스 또는 소프트웨어 인터페이스를 통해 SPI(208)와 통신한다. 네트웍 서비스 브로커(220)는 단말 장치(244, 248, 및 246)의 홈 네트웍인, 네트웍 B(222)의 거주 브로커 등을 나타낸다. NSB(220)는 인터페이스(206)를 통해 어플리케이션(202)에 의해 SPI(208)로 제공되는 거주 서비스 요청들을 처리한다. 프로토콜 인터페이스(2100는 HTTP, SOAP, 또는 BTP 등을 포함해 임의의 개수의 프로토콜들로 이뤄진다.

네트웍 B(222)는 서브네트웍 B1(226) 및 서브네트웍 B2(228)을 포함하여, 네트웍 B(222)의 단일 오퍼레이터에 의해 소유된 네트웍 하부구조를 나타내나, 그 서브 네트웍 하부구조는 서브네트웍 B1(226) 및 B2(228)에 대해 별개로 된 두 제조자들을 가진다. 따라서 서브네트웍 B1(226)과 연관된 하부구조는 서브네트웍 B2(228)와 관련된 하부구조의 복잡도와는 다른 복잡도를 가진다. 그러나, 그러한 복잡도의 차이는 장소 브로커 NSB(220)에 의해 SPI(208)로부터 숨겨지게 되고, 그에 따라 SPI(208)는 장소 서비스 요청 중에 서브네트웍 B1(226) 및 서브네트웍 B2(228 사이의 복잡도의 차에 대한 어떤 지식도 요구하지 않는다. NSB(220)가 SPI(208)에 대해 그러한 복잡도를 명쾌히 보이고 있기 때문에, 일반적으로 SPI(208)는 네트웍 A(216), B(222) 또는 C(240)의 복잡도들에 대한 어떤 특정한 지식도 요구하지 않는다.

가령 장소 브로커로서 작동하는 NSB(220)가 TE(244, 246, 및 248)에 관해, 어플리케이션(202)으로부터의 장소 요청을 처리할 때, TE(244, 246, 및 248)와 관련해 몇 몇 로밍(roaming) 시나리오들이 존재한다. 그 중 한 로밍 시나리오는 네트웍 B(222)에 거주하는 TE(244)가 네트웍 A(216) 안으로 돌아다니는 것(로밍)을 포함한다. 어플리케이션(202)으로부터의 장소 요청(214)은 SPI(208)에 의해 처리되고 나서 NSB(220)로 보내진다. TE(244)가 네트웍 A(216)로 로밍할 때, 네트웍 B(222)의 장소 업데이트는 더 이상 필요하지 않으며, 그 보다는 이제 네트웍 A(216)에 대해 장소 업데이트가 필요로 된다. 그러나, 네트웍 A(216) 및 네트웍 B(222)는 각각 장소 브로커 NSB(220)에 의해 알려진 서로 다른 복잡도를 가질 것이다. 네트웍 A(216)의 운영자 및 네트웍 B(222)의 운영자 사이에서 적절한 서비스로밍 협정을 맺음으로써, 장소 브로커 NSB(220)는, TE(244)의 위치를 결정하도록 요구된 방문중인 네트웍 A(216)의 네트웍 요소(NE)(218)와 네트웍 B(222)의 알맞는 NE 사이에서, 장소 브로커 NSB(212)와 협력하여 장소 업데이트를 수행하도록 허용된다. SPI(208)는 장소 브로커 NSB(220)와 장소 브로커 NSB(212) 사이의 로밍 협정 덕에 네트웍 A(216)와 네트웍 B(222) 사이의 복잡도 차이에 대한 지식을 가질 필요가 없게 되는데, 이는 장소 브로커(220)가 네트웍 A(216)와 네트웍 B(222) 사이의 그 복잡도 차를 숨기기 때문이다.

TE(244)의 로밍 상태에 대한 지식을 가지고 있는, 네트웍 B(22)의 상기 알맞는 NE가 네트웍 A(216)의 NE(218)를 접촉하여 로밍하는 TE(244)의 장소 업데이트치를 수신하는 데에서도, 유사한 로밍 효과가 존재한다. 이 경우, 로밍은 NSB(220)에서 NSB(212)로의 접속 안에서 다뤄지지 않으며, 그보다는 NE 레벨에서 다뤄진다. 이때, 가령 네트웍 B(222)의 NE(224)는 네트웍 A(216)의 NE(218)에 직접 접촉하여 위치 업데이트를 행한다. 네트웍 A와 B 사이의 복잡도 차이는, 네트웍 A(216)와 네트웍 B(222)의 운영자들 사이에 설정된 로밍 협정 때문에 SPI(208)로부터 계속 감춰진다.

추가로 존재하는 로밍 시나리오는, 서브네트웍 B1(226)에 거주하는 TE(248)가 서브네트웍 B2(228) 안으로 로밍하는 것이다. 어플리케이션(202)으로부터의 장소 요청(232)이 SPI(208)에 의해 처리되어 NSB(220)로 보내진다. TE(248)가 서브네트웍 B2(228) 안으로 로밍할 때, 서브네트웍 B1(226)의 장소 업데이트는 더 이상 필요하지 않으며, 대신 이제는 서브네트웍 B2(228)의 장소 업데이트가 필요로 된다. 서브네트웍 B1(226) 및 서브네트웍 B2(228)는 각각 서로 다른 복잡도를 가질 수 있으며, 이것은 장소 브로커 NSB(220)에 의해 알려진다. TE(248)가, TE(248)의 위치를 결정하라고 요구되는 서브네트웍 B1(226)과 서브네트웍 B2(228) 사이에서 로밍하는 동안, 장소 브로커 NSB(220)는 SPI(208)로부터의 장소 업데이터 요청에 대해 서비스한다. SPI(208)는 장소 브로커 NSB(220)의 덕택으로, 서브네트웍 B1(226)과 서브네트웍 B2(228) 사이의 복잡도 차이에 대한 어떠한 지식도 가질 필요가 없게 되는데, 이는 장소 브로커(220)가 서브네트웍 B1(226)과 서브네트웍 B2(228) 사이의 그 복잡도 차를 숨기기 때문이다.

또 다른 로밍 시나리오는, TE(246)가 네트웍 B(222)에서 네트웍 C(240)으로 로밍할 때의 경우 존재한다. 알 수 있다시피, 장소 요청(236)은 NSB(220)에 의해 처리되기 보다는, NSB(238)로 직접 보내진다. 장소 브로커 NSB(220)를 활용하지 않는 하나의 이유에는, 네트웍 B(222)의 운영자들과 네트웍 C(240)의 운영자들이 적절한 로밍 협정을 맺고 있지 않다는 가능성을 포함한다. 그러한 것은, 가령, 네트웍 C(240)가 무선 랜(LAN)이나 회사 랜으로 대표되는 경우가 될 것이다. 로밍 협정은 TE(246)가 네트웍 C(240)로 로밍할 때는 적절할 것 같지 않으며, 그에 따라 NSB(220)가 SPI(208)로부터의 위치 업데이트 요청을 처리하는 것이 허용되지 않는다. 두 NSB(220, 및 238)가 모두 SPI(208)에 의해 가시적이고, 또한 네트웍 B(222)와 네트웍 C(240) 사이에 로밍 협정이 존재하지 않기 때문에, SPI(208)는 TE(246)의 장소 업데이트를 위해 NSB들(220 또는 238) 중 어떤 것을 사용할지를 결정하는 문제에 노출된다.

SPI(208)가 위치 브로커 선택 문제에 직면할 때, SPI(208) 안이나 SPI(208) 밖에서 실행중인 어플리케이션(202) 역시 이와 마찬가지로 선택 문제에 직면한다. 일단 어플리케이션이 선택 문제에 직면하게 되면, 어플리케이션(202)은 SPI(208)와 단단히 결합하게 되고 따라서 다른 SPI 어플리케이션들에 대해 이동성이 떨어지게 된다. 그러면 이러한 장소 선택 문제를 다루기 위해 필요로 되는 특수화된 코드 베이스(bases)가 요구되기 때문에 저장용량을 증가시키게 되며 어플리케이션(202)은 결국 SPI(208)에 맞춤화되어야 한다.

따라서, 본 발명의 중요한 양상은 어플리케이션들을 그 각자의 호스트 SPI에 맞춰야 할 필요성을 막는데에 있으며, 이것은 그 어플리케이션에 대해, 브로커에 대한 하나의 논리적 목적(OLVB, One Logical View to Broker) 어플리케이션 프로그램 인터페이스(API, Application Program Interface)의 전형을 생성함으로써 수행된다. 즉, NSB에 의해 제공되는 웹 서비스나 웹 요소에서 보여지는 어떤 고유의 복잡성에 직면하지 않고, 특정 어플리케이션이 어떤 특정 NSB와 통신할 수 있다.

상기 OLVB 전형을 도모하기 위해 NSB 패러미터 리스트(204)가 필요하게 된다. 각각의 어플리케이션은 그 자신의 고유한 식별 번호 등을 제공할 필요가 있으며, 그에 따라 그 어플리케이션과 통신 중인 특정 NSB는 그 어플리케이션에서 사용 가능한 서비스 레벨을 추종할 수 있다. 만일 장소 데이터를 요청하는 어플리케이션에 의해 사용되는 식별 번호가 가령 장소 리포트를 위해 사용될 입도(granularity)가 대도시 지역 수준임을 나타내면, 그 어플리케이션과 통신하는 장소 브로커는 다른 입도들이 존재하더라도 상기 입도에서의 장소 업데이트값들 만을전송한다. 그러한 경우는, 예를 들어, GPS(Global Positioning System) 사용을 통해 TE의 정확한 좌표가 얻어질 수 있을 때의 경우가 된다. 덧붙여, 가령 요청하는 어플리케이션들로 장소 업데이트 정보를 제공하기 위해 최종 사용자나 기타 정책 결정자들이 협정했을 보안 요건을 강제하기 위해 어플리케이션의 고유한 식별 번호가 요구된다.

특정 SPI가 어플리케이션(202)을 주관하는 플랫폼으로 사용되는 경우, 고유 서비스 제공자 식별 번호 역시 필요하게 된다. 그 SPI의 소유자 아이덴티티는, 강력한 인증 방식 등에 의해, NSB들에 의해 제공되는 서비스들로의 억세스를 얻도록 실제 SPI의 아이덴티티로 대체될 것이다. SPI는 가령, 그 SPI 상의 어플리케이션을 주관하고 있는 대상이 하는 것과는 다른 비즈니즈 협정을 NSB와 맺을 것이다. 예를 들어, 셀룰라 운영자가 법인 고객을 위해 자신의 SPI 내 어플리케이션을 주관하고 있을 때, 그 법인 고객의 무선 LAN 네트웍은 일반적으로 그 운영자의 SPI로부터의 문의를 허용하지 않는다. 그러나, 만일 서비스 제공자의 식별 번호가 법인의 NSB로 제공되면, SPI와 NSB 간의 통신이 허용된다.

NSB의 서비스들이 특정 TE나 사용자 아이덴티티와 관련될 때, 고유한 사용자 식별 번호가 필요하게 된다. 예를 들어, 바른 장소 브로커를 선택하는 것은 TE의 특정 아이덴티티에 좌우되는데, 이는 TE의 홈 네트웍의 장소 브로커가, 장소 정보가 어디에서 발견되어야 할지를 정하도록 사용자 식별 번호를 필요로 하기 때문이다. 여러 NSB들로부터 서비스가 이용가능할 때 비용 기능 역시 요구될 수 있다. 그 비용 기능의 사용을 통해 어플리케이션은 NSB에 의해 제공된 서비스 관련 비용을 규정 및 제한할 수 있다. 비즈니스 협정 역시 필요로 되어, 어플리케이션이 어느 비즈니스 협정을 활용할지를 정하거나 가리키거나 강제할 수 있도록 한다. 예를 들어 선택 프로세스 중에, SPI는 NSB 관련 패러미터 리스트(204)의 비즈니스 협정에 의해 명시된 비즈니스 협정의 멤버인 서비스 브로커를 선택할 수 있다. NSB 관련 패러미터 리스트(204)가, 본 발명에 따른 OLVB 전형을 제공하기 위해 필요로 될 수 있는 포괄적인 패러미터 리스트를 나타내는 것이 아니고, 그 보다는 OLVB 전형을 제공하는데 유용할 수 있는 패러미터들의 예가 되는 리스트를 나타내도록 주어지고 있다는 것을 이해해야 한다.

도 3은 어플리케이션(302)이 여러 웹 서비스 요소들과 함께 주어지고 그 요소들 가운데에서 NSB 관련 패러미터 리스트(304)에 기반하는 최선의 웹 서비스 요소를 선택하는 데 있어서의 일반적인 문제를 도시한 것이다. 어플리케이션(302)은 이하에서 상세히 설명될 인터페이스(306)에 의해 예시된 프로토콜 인터페이스나 소프트웨어 인터페이스를 통해 SPI(308)와 통신한다. 일반적으로, 다양한 웹 서비스 요소들(314-320)이 SPI(308)에 의해 사용 가능하다. 각각의 웹 서비스 요소(314-320)는 웹 서비스 레지스트리(312)로 통지되는 서비스 특성을 가진다. 일반적으로, 웹 서비스 요소들(314-320)은 상술한 것과 같은 웹 서비스들이 될 필요가 없으며, 그보다는 웹 서비스들과 양립하는 한 인터페이스를 가진 네트웍 요소들일 것만이 필요로 된다.

레지스트리(312)는, 웹 서비스를 위해, 분포된 웹 기반 정보 레지스트리들의 UDDI(Universal Discovery Description Integration, 범 디스커버리 기술 통합) 사양에 의해 규정된 것과 같이 구현될 것이다. 레지스트리들은 공개적으로 억세스가능하며, 가령 소프트웨어 회사, 개인 개발자, 표준 단체, 및 회사 지원 서비스들을 설명하기 위한 비즈니스 등록 유형들에 대한 서비스 유형 등록을 지원한다. UDDI는 웹 상의 비즈니스 레지스트리의 공유된 동작을 포함한다. UDDI 비즈니스 레지스트리는 비즈니스 레벨에서 이용되어, 소정 파트너가 특정 웹 서비스 인터페이스를 포함하는지의 여부를 체크한다. 또, UDDI 비즈니스 레지스트리는 소정 유형의 서비스를 제공하는 소정 산업 분야의 회사들을 찾고, 어떤 파트너나 의도한 파트너가 웹 서비스를 어떻게 하는지에 대한 정보를 위치시키기 위해 사용된다. 레지스트리(312)에서 제공되는 정보로부터, 웹 서비스 요소들(314-320)의 동작에 대해 고유한 세부 사항들이 얻어진다. J2EE 관점에서, UDDI 레지스트리(312)는 단순히, 가령 자바 명명 및 디렉토리 인터페이스(Java Naming and Directory Interface, JNDI) 등과 같이, 특정하고 관련있는 웹 서비스 정보를 포함하는 저장실이며, 웹 서비스 요소 자체를 주관하거나 주관하지 않을 수 있다. NSB 관련 패러미터 리스트(304)는 SPI(308)가, 예를 들어 SPI(308)나 주관된 어플리케이션(302)의 소유자가 비즈니스 협정을 맺은 웹 서비스 요소들을 선택하는 것을 가능하게 한다. 또, NSB 관련 패러미터 리스트(302)는 현재 적절한 비즈니스 협정을 맺지 않은 웹 서비스 요소들(314-320)과 SPI(308) 사이의 짝 맞추기를 돕는다. 여기에 또, 패러미터 리스트(304)는 비용 기능을 사용해 어플리케이션(302)과 웹 서비스 요소들(314-320) 사이에 가장 비용 효용성이 큰 짝 만들기를 가능하게 한다.

도 4는 본 발명에 따른 전형적 J2EE 웹 서비스 환경을 도시한 것으로, 어플리케이션(402)과 NSB들(424-428) 사이에 소프트웨어 인터페이스 기반 접근 방식을 도시하고 있다. NSB들(424-428)은 도 2 및 도 3에 도시된 NSB들과 같은 것이거나, 웹 서비스 인터페이스를 구비한 실제 웹 서비스들 또는 웹 요소들을 나타낸다. 어플리케이션(402), 소프트웨어 인터페이스 모듈(432), 및 라이브러리(420)가 모두 자바 어플리케이션 서버 환경 하에 공존한다. 일반적으로 빈(bean)들(406-410, 및 414)은 소프트웨어 모듈들, 라이브러리들, 및, 방법과 서비스와 데이터와 기능이 어플리케이션(402)에 의한 소프트웨어 인터페이스(404)를 통해 가능한 에이젼트들이나 오브젝트들을 나타낸다. J2EE 구성이 예시되었지만, 가령 마이크로소프트.넷이나 리눅스 어플리케이션들과 같이, 임의의 수의 실시예들 역시 실행 가능하다는 것에 유의해야 한다.

빈들(406-410)은 가령, 자바 환경 내 엔터프라이즈 자바 빈(EJB) 컨테이너 안에서 실행되는 복수개의 엔터프라이즈 빈들을 나타낸다. 각각의 엔터프라이즈 빈은 어플리케이션의 비즈니스 로직을 나타내며, 세션이나 개체와 같은 여러 기능적 유형을 취하여 클라이언트 요구에 대해 특정 작업을 수행한다. 예를 들어, 빈(410)은 장소 요청 작업에 해당하는 것으로, 가령 도 2와 관련해 설명된 것과 같은 TE의 장소 변경을 수행하기 위해 NSB들(424-428) 중 하나와 접촉한다. 일반적으로, 엔터프라이즈 빈들(406-410)은, OLVB 전형을 지원하는 어플리케이션(402)으로부터 브로커나 웹 서비스 복잡성을 가리는 브로커 서비스 고유 소프트웨어 라이브러리들이나 오브젝트들을 구성함으로써, 인터페이스(404)의 복잡성을 줄이고 어플리케이션(402)의 이동 간편성을 증대시킨다. 엔터프라이즈 빈들(406-410)이 브로커들(424-428) 사이에 일대일 통신으로 정해지지만, 브로커들(424-428)로의 인터페이스를 구축하기 위한 다양한 빈들의 상호작용과 같이, 빈들(406-410)과 브로커들(424-428) 사이에는 다른 관계들 역시 당연히 존재할 수 있다.

빈(414)은 엔터프라이즈 빈들(406-410)의 공통 기능에 비해 별도의 기능 블록으로서 존재한다. 가령 J2EE 구성에서, 빈(414)은 룩업 빈이라고 불린다. 룩업 빈(414)은 가령, 도 2 및 3의 NSB 관련 패러미터 리스트(204 및 304)에 리스트된 것과 같은 패러미터들을 입력으로서 수신한다. 그 패러미터들 또는 그들 중 일부가 빈들(410, 408, 406) 중 어느 하나를 통해 제공된다. 그 경우, 어플리케이션(402)은 룩업 빈(414)과 직접 통신(444)하지 않는다. 빈들(406-410)과 통신하기 전에 어플리케이션(402)이 444를 통해 룩업 기능을 능동적으로 요청하는 것과 같은 다른 경우도 있을 수 있다. 그러한 통신은 어플리케이션으로 하여금 어느 NSB가 선택될지에 대한 어떤 개선된 통제를 가능하게 할 수 있다. 그러나, 이러한 것은 어플리케이션(402)의 휴대 간편성을 제한하기 때문에, 어플리케이션(402)에서 직접 룩업 기능(414)으로 억세스하는 것은 정상적 실시예들에서 권장되고 있지 않다. 결정 기능(412)의 출력은 짝을 만드는 서비스 브로커들(424-428)과 통신하기 위해 필요한 접속 패러미터들을 제공한다. 일반적으로, 요소들(424-428)은 웹 서비스 인터페이스를 구비한 웹 서비스들 또는 웹 요소들을 나타낸다.

룩업 빈(414)의 짝만들기 기능은 SPI 및 짝 만드는 서비스 브로커 사이의 동적 비즈니즈 관계를 제공하도록 구현될 수도 있다. 예를 들어, 룩업 빈(414)에 의해 수행된 룩업 기능이 로컬 혹은 리모트 데이터베이스 REG(418)에 저장된 룩업 테이블을 검색하여 정합 NSB, 즉 그 NSB의 요구되는 어드레스 등으로의 접속을 설정할 때, 룩업 기능은 SPI와 그 정합 NSB 사이에 비즈니스 관계가 없다는 것을 반드시 모면할 수는 없다. 짝만들기 기능(416)은 룩업 빈(415)의 반(semi)-고정(static) 룩업 기능을 확장시켜 SPI의 소유자, 혹은 관리되는 어플리케이션과, NSB의 소유자 사이에 설정된 실시간 비즈니스 관계가 시작되도록 한다. 필요하다면 룩업 빈(414)으로의 외부 접속(444) 역시 제공되나, 상술한 외부 접속(444)을 금지하거나, 제한하거나 또는 위임하는 다른 실시예들 역시 존재할 수 있다. 데이터베이스(418)는 웹 서비스 레지스트리(430)와 매우 유사한 데이터 레지스트리를 나타내고, 여기에 NSB(424-428)가 제공하는 웹 서비스들에 대한 속성들이 저장되고나서 나중에 웹 서비스 찾기 도중에 짝만들기 기능(416) 및 결정 기능(412)에 의해 억세스된다.

라이브러리(420)는, XML 문서 처리를 지원하는 XML 프로세싱용 자바 API (JAXP), 어플리케이션들로 하여금 XML 메시지 위주의 문서를 송수신할 수 있게 하는 XML 메시지용 자바 API (JAXM), SOAP 사양을 이용해 RPC 기능을 생성하기 위한 XML 기반의 원격 절차 통화(JAXP-RPC)용 자바 API (JAXP-RpC), 및 웹 서비스 레지스트리들로의 XML 억세스를 위한 XML 레지스트리용 자바 API (JAXR)과 같은 웹 서비스 관련 프로토콜들의 활용을 가능하게 하는 모든 API들 등을 나타낸다.

도 4에 도시된 것과 같은 웹 서비스 환경은 본 발명에 따른 전형적인 환경을 제공하며, 그 환경은 어플리케이션(402)과 관련해 OLVB 전형을 양산한다. 인터페이스들(434, 및 440)은 어플리케이션(402)으로 단순화되고 간편한 API를 제공하며,이것은 어플리케이션(402)에 대한 호스트 어플리케이션 서버에 관계 없이 일정하게 유지될 것이다. EJB들(406-410)은 어플리케이션(402)에 의해 인터페이스(434)를 거쳐 그들로 전송되는 고유한 클라이언트 메시지들의 사용을 통해 구체적으로 예시되는데, 이것은 자바 메시지 서비스(JMS)의 사용을 통해 메시지 처리 빈들과 함께 사용될 수 있는 것과 같다. 일단 어플리케이션(402)에 의해 메시지 처리 빈이 구체적으로 예시되고 나서, 인터페이스(436)는 룩업 빈(414)이 어플리케이션(402)에 의해 요청된 서비스 유형을 인식하는데 필요한 요청 정보를 그 룩업 빈(414)으로 제공한다. 어플리케이션(402)은 NSB 관련 패러미터들(204)을 인터페이스(444)를 거쳐 직접 룩업 빈(414)으로 전송하거나, 그 NSB 관련 정보를 인터페이스(434)를 거쳐 전송한다.

일단 룩업 빈(414)이 어플리케이션(402)에 의해 요청된 특정한 서비스 유형이나, 어플리케이션(402)에 의해 제공되었을지 모를 임의의 NSB 관련 패러미터들을 소지하고 있다면, 룩업 빈(414)은 인터페이스(440)를 활용해 찾기(discovery) 도중 JAXR을 통해 웹 서비스 레지스트리를 검색하여, 어플리케이션(402)에 의해 요청된 서비스 및 자유선택에 따라 연관된 NSB 관련 패러미터들에 따른 최선의 짝 NSB를 찾는다. 최선의 짝 선택 과정은 동적인 최적화 선택 과정으로서, NSB 관련 패러미터들과 어플리케이션(402)의 서비스 요청을 활용해 어플리케이션(402)에 가장 적합한 사양을 갖는 최선의 서비스 요소를 선택한다. 그러면 레지스트리(418)가 추가 억세스를 위해 그 동적 최적화 선택 과정의 결과들로 업데이트 된다. 그리고 나서 최선의 짝 NSB와, 해당하는 메시지 처리 빈이 라이브러리(420) 안에 존재하는 적절한 자바 API들을 통해 인터페이스들(442 및 438)을 거쳐 실질적으로 연결된다. 그러면 어플리케이션(402)은 구체적으로 예시된 EJB와 인터페이스(434)를 통해 통신하여, 서비스 요청에 따른 데이터를 수신하고, 이로써 트랜잭션이 마무리된다.

도 5는 본 발명에 따른 J2EE 웹 서비스 환경의 예를 도시한 것으로서, 어플리케이션(502)과 NSB들(524-528) 사이에 한 프로토콜 인터페이스 기반 접근 방식을 예시하고 있다. NSB들(524-528)은 도 2 및 도 3에 도시된 NSB들과 같거나, 웹 서비스 인터페이스를 구비한 실제 웹 서비스들이나 웹 요소들을 나타낸다. 어플리케이션(502), 프로토콜 모듈(532), 및 라이브러리(520)은 모두 자바 어플리케이션 서버 환경하에 공존한다. J2EE 구성이 예시되고 있지만, 가령 마이크로소프트.넷 및 리눅스 어플리케이션들과 같은 임의의 수의 구성들 역시 가능하다는 것을 이해해야 한다.

도 5는 본 발명에 따른 다른 실시예를 나타내 도 4에 도시된 소프트웨어 인터페이스 모듈과 교체 가능한 것으로서 프로토콜 인터페이이스 모듈(532)를 이용해 OLVB 전형을 구축한다. 어플리케이션(502)과 NSB들(524-528) 사이의 통신은 라이브러리(520) 내 웹 서비스 프로토콜들을 활용해 단 대 단(end to end)으로 수행되고, 이때 웹 서비스 프로토콜들로의 어플리케이션 인터페이스의 매핑은 일어나지 않는다. 네트웍 어드레스 트랜잭션(NAT) 프록시들(506-510)은 어플리케이션(502)으로부터 NSB들(524-528)의 IP 어드레스들을 감추어, 어플리케이션(502)이 NSB들(524-528)의 고정 IP 어드레스들을 반드시 포함하지 않을 수 있게 된다. 알맞는 서비스 브로커의 선택은 NAT 프록시들(506-510)과 룩업 기능(514) 둘 모두의 기능에 의해 수행된다.

도 4 및 5에 도시된 것과 같은 짝 찾기 기능(416 및 516)은 인터넷 상에서 사용가능한 기존의 주요 기술들을 복제하기 보다 가능한 한 많이 활용하도록 모색한다. 핵심 기술 재사용에 대한 한가지 예가 휴렛 패커드(HP)의 e-Speak에 관한 것이다. HP의 e-Speak은 인터넷에 억세스한 소비자들로 하여금, 소비자의 질의에 기반해 서비스 제공자들을 찾아 연결하도록 하는 기능을 제공한다. 그러나 e-Speak 엔진은 가령 소비자가 찾는 특정 서비스의 "최적의" 공급자를 검색 및 발견하기 위한 기능은 갖고 있지 않을 것이다. 물론, "최적"이라는 용어의 정의가 주어져야 한다.

본 발명에 따른 짝 찾기 기능과 e-Speak과 같은 기존의 핵심 기술 사이의 상호동작에 대한 하나의 가능한 예가, HP의 e-Speak을 그 자신의 웹 서비스, 웹 요소 또는 서비스 브로커로서 나타내는 것이다. 그러면 룩업 기능(414 또는 514)은 NSB 관련 패러미터들(204 또는 304)을 고려해 "최적의" 서비스 공급자를 찾도록, HP의 e-Speak이 제공한 출력을 필터링하도록 사용될 수 있다. 그렇게 HP의 e-Speak의 출력을 필터링하는 한 예가, $ 25 이하의 가격으로, 프랑스어로 작성된 문서의 영어 번역 서비스를 요청하는 것을 포함할 수 있다. 그러면 HP의 e-Speak은 네트웍 상에서의 모든 프랑스어 번역 서비스들을 찾는 일을 하며, 이때 룩업 기능(414 또는 514)과 결부된 가격 기능 패러미터는 e-Speak이 보고한 모든 번역 서비스 제공자들을 번역료가 $ 25을 초과하지 않는 것들로 한정시킨다.

도 6은 본 발명에 따른 흐름도를 도시한 것으로, 이 흐름도는 도 2의 네트웍B(222)에서 네트웍 C(240)로의 TE(246)의 로밍 중의 동작 양상을 도 4와 결합해 설명할 때 유용하다. TE(246)가 네트웍 C(240)로 로밍한 후에 어플리케이션(202)이 TE(246)의 장소 업데이트를 요청한다(600 단계). 이러한 장소 업데이트를 위해, 어플리케이션 ID, 사용자 ID, 및 비즈니스 협정 데이터가 어플리케이션(202)에 의해 제공된다. NSB 관련 패러미터들이 존재하는지가 검사된다(610 단계). 어플리케이션 ID가 가능한 최상의 해상도를 가진 장소 업데이트값을 수신해야 한다는 것을 나타내는데(620 단계), 이는 "어플리케이션 202"이 그러한 정밀도에 대한 특권을 가지기 때문이다. 사용자 ID는 "TE 246"에 대한 장소 요청이 요구됨을 나타내며, 비즈니스 협정 패러미터는 네트웍 B(222)와 네트웍 C(240) 사이에 어떤 적절한 비즈니스 협정도 없음을 나타낸다. 결정 기능(412)이 NSB 관련 패러미터들을 수신하여 NSB(238)가 패러미터 리스트에 기반해 올바른 짝임에도 NSB(220)와 NSB(238) 사이에 어떤 적절한 비즈니스 협정도 없다는 것을 판단한다(630 단계). 짝 만들기 기능(416)이 시작되어, NSB(220)와 NSB(238) 사이에 비즈니스 관계가 자동으로 생성된다(640 단계). NSB(238)에 의해 제공된 장소 업데이트 서비스를 일으켜(650단계) 상기 서비스 요청을 끝낸다.

요약하면, 개발자 우호적 API가 브로커에 대한 하나의 논리적 목적(OLVB)의 전형을 가지는 것으로 구현되어, 서비스를 요구하는 어플리케이션과 서비스 브로커 또는 웹 서비스 요소간의 인터페이스를 단순화한다. 또한, 웹 서비스 복잡성에 대한 지식이 어플리케이션 안에 존재하지 않기 때문에, 어플리케이션은 보다 큰 간편성을 가질 수 있게 된다. 요구하는 어플리케이션과 비즈니스 관계를 가진 NSB에대한 반-고정 룩업이 사용 가능하게 된다. NSB가 요청 어플리케이션과의 사이에 설정된 비즈니스 관계를 가지고 있지 않는 경우에는, 그러나 서비스 요청 중에 동적 동작이 설정되어, 서비스 제공 개체들과 요청 어플리케이션 사이의 비즈니즈 관계에 대한 동적 교섭을 규정한다.

상술한 사양을 이용해, 본 발명은 표준 프로그래밍 및/또는 엔지니어링 기술을 이용해 프로그래밍 소프트웨어, 펌웨어, 하드웨어 또는 그들의 임의의 조합을 제공함으로써, 네트웍 시스템, 네트워킹된 장치, 프로세스, 또는 제조물로서 구현될 수 있다.

컴퓨터 판독가능 프로그램 코드를 구비한 임의의 파생 프로그램(들)이 메모리 장치들이나 전송 장치들과 같은 하나 이상의 컴퓨터 이용가능 매체 안에서 실시될 수 있게 되어, 본 발명에 따른 컴퓨터 프로그램 생성물이나 제조물을 만들 수 있다. 이와 같이, 여기에 사용된 "제조물"이라는 용어와 "컴퓨터 프로그램 생성물"이라는 용어는, 어떤 메모리 장치나 어떤 전송 장치에서와 같이 임의의 컴퓨터 사용가능 매체 상에서 (영구적이거나, 임시적이거나 일시적으로) 존재하는 컴퓨터 프로그램을 포괄하기 위한 것이다.

한 매체로부터 직접 프로그램 코드를 수행하거나, 매체 상에 프로그램 코드를 저장하거나, 한 매체에서 다른 매체로 코드를 복사하거나, 전송 장치를 이용해 코드를 전송하거나, 또는 이와 상응하는 동작을 수행하는 것은, 본 발명을 만들거나 이용하거나 판매함에 있어 예비 또는 최종 단계로서 프로그램 코드를 일시적으로 구현하는 메모리나 전송 장치를 사용하는 것을 포함한다.

메모리 장치들로는 하드 디스크 드라이브, 디스켓, 광 디스크, 자기 테이프, 램, 롬, 프로그램 가능 롬, 등과 같은 반도체 메모리들이 포함되나, 꼭 그것들에 국한되는 것은 아니다. 전송 장치들에는, 인터넷, 인트라넷, 전화/모뎀 기반 네트웍 통신, 배선/유선 통신 네트웍, 셀룰라 통신, 무선 웨이브 통신, 위성 통신, 및 기타 고정형이거나 이동형 네트웍 시스템/통신 링크가 포함되나, 여기에 국한되는 것은 아니다.

본 발명을 실시하는 장치는, 소프트웨어, 펌웨어, 하드웨어, 또는 그들의 임의의 조합 또는 서브 조합을 포함해 청구항들에 개시된 것과 같은 본 발명을 실시하는, CPU, 메모리/저장 기기, 통신 링크, 통신/전송 장치, 서버, I/O 기기, 또는 하나 이상의 처리 시스템들 중 임의의 서브요소나 개개 파트들을 포함하지만, 그것에만 국한되지 않는, 하나 이상의 처리 시스템들을 포함한다.

여기 제공된 설명으로부터, 이 분야의 당업자라면 당연히, 상술한 바와 같이 생성된 소프트웨어를 적절한 범용 또는 특수용 컴퓨터 하드웨어와 결합하여 본 발명을 구현하는 컴퓨터 시스템 및/또는 컴퓨터 서브요소들을 생성하고, 본 발명의 방법을 수행하기 위한 컴퓨터 시스템 및/또는 컴퓨터 서브 요소들을 생성할 수 있을 것이다.

본 발명의 범위와 개념으로부터 벗어남이 없이 상술한 여러 실시예들에 대한 다양한 변형과 추가가 이뤄질 수 있다는 것 역시 이해할 수 있을 것이다. 예를 들어, 본 발명은 어떤 유형의 실행 환경과 관련해서도 이용될 수 있으며, 상술한 J2EE 실행 환경 예에 한정되지 않는다. 예시된 실시예들에 대한 상술한 설명으로부터, 이 분야의 당업자라면, 본 발명이 마이크로소프트.넷과 리눅스와 같은 어떤 필적 가능한 실행 환경에서도 응용가능하다는 것을 알 수 있을 것이다. 따라서, 본 발명의 범위는 상술한 특정 실시예들에 의해 한정되어서는 안되며, 아래에 설명된 청구항들과 그에 상응하는 것들에 의해서만 규정되어져야 한다.

Claims

복수개의 서비스 요소들을 구비한 네트웍 내에서 네트웍 서비스들을 설정하는 방법에 있어서,

복수개의 인터페이스 모듈들을 제공하여 상기 복수개의 서비스 요소들 중 하나와의 통신을 설정하는 단계;

상기 복수개의 인터페이스 모듈들에 대한 하나의 논리적 억세스 포인트를 제공하여 상기 복수개의 서비스 요소들 중 하나의 발동을 도모하는 단계;

서비스 요소 관련 패러미터들을 수신하는 단계; 및

상기 발동에 따라 상기 복수개의 서비스 요소들 중 하나를 선택하는 단계를 포함하고,

상기 서비스 요소 관련 패러미터들은 상기 복수개의 서비스 요소들 중 하나에 대한 동적 선택 최적화를 규정함을 특징으로 하는 방법.
제1항에 있어서, 상기 복수개의 인터페이스 모듈들을 제공하는 단계는, 상기 하나의 논리적 억세스 포인트로부터 수신된 메시지들에 의해 억세스 가능한 복수개의 소프트웨어 오브젝트들을 제공하는 단계를 포함함을 특징으로 하는 방법.
제2항에 있어서, 상기 서비스 요소 관련 패러미터들을 수신하는 단계는, 상기 하나의 논리적 억세스 포인트를 통해 사이 서비스 요소 관련 패러미터들을 수신하는 단계를 포함함을 특징으로 하는 방법.
제3항에 있어서, 상기 서비스 요소 관련 패러미터들을 수신하는 단계는, 외부 접속을 통해 상기 서비스 요소 관련 패러미터들을 수신하는 단계를 포함함을 특징으로 하는 방법.
제4항에 있어서, 상기 복수개의 서비스 요소들 중 하나를 선택하는 단계는, 상기 서비스 요소 관련 패러미터들을 이용하여, 잠정적으로 적합한 서비스 요소들의 처음의 개수를 줄이는 단계를 포함함을 특징으로 하는 방법.
제5항에 있어서, 상기 복수개의 서비스 요소들 중 하나를 선택하는 단계는, 상기 서비스 요소 관련 패러미터들을 이용하여 상기 복수개의 서비스 요소들 중 하나와의 비즈니스 협정을 일으키는 단계를 더 포함함을 특징으로 하는 방법.
제1항에 있어서, 상기 복수개의 인터페이스 모듈들을 제공하는 단계는, 상기 하나의 논리적 억세스 포인트로부터 수신된 메시지들에 의해 억세스 할 수 있는 복수개의 네트웍 어드레스 전환 프록시들을 제공하는 단계를 포함함을 특징으로 하는 방법.
제7항에 있어서, 상기 서비스 요소 관련 패러미터들을 수신하는 단계는, 상기 하나의 논리적 억세스 포인트를 통해 상기 서비스 요소 관련 패러미터들을 수신하는 단계를 포함함을 특징으로 하는 방법.
제8항에 있어서, 상기 서비스 요소 관련 패러미터들을 수신하는 단계는, 외부 접속을 통해 상기 서비스 요소 관련 패러미터들을 수신하는 단계를 포함함을 특징으로 하는 방법.
제9항에 있어서, 상기 복수개의 서비스 요소들 중 하나를 선택하는 단계는, 상기 서비스 요소 관련 패러미터들을 이용하여, 잠정적으로 적합한 서비스 요소들의 처음의 개수를 줄이는 단계를 포함함을 특징으로 하는 방법.
제10항에 있어서, 상기 복수개의 서비스 요소들 중 하나를 선택하는 단계는, 상기 서비스 요소 관련 패러미터들을 이용하여 상기 복수개의 서비스 요소들 중 하나와의 비즈니스 협정을 일으키는 단계를 더 포함함을 특징으로 하는 방법.
서비스 요청 및 관련 서비스 요청 패러미터들에 따라 네트웍 서비스들을 도모하는 시스템에 있어서,

적어도 하나의 네트웍 안에 분포된 복수개의 서비스 요소들; 및

복수개의 인터페이스 오브젝트들을 포함하고, 그 복수개의 인터페이스 오브젝트들과 통신하여 상기 복수개의 서비스 요소들 중 하나와 상기 복수개의 인터페이스 오브젝트들 중 하나 간에 요구되는 접속 패러미터들을 설정하는 룩업 오브젝트, 상기 룩업 오브젝트와 통신하여 상기 복수개의 서비스 요소들 관련 속성들을 식별하는 패러미터들을 제공하는 데이터 오브젝트, 및 상기 복수개의 인터페이스 오브젝트들로의 외부 억세스를 허용하는 하나의 논리적 억세스 포인트를 구비하여, 상기 복수개의 서비스 요소들 중 하나와의 통신을 설정하는 인터페이스 모듈을 포함함을 특징으로 하는 시스템.
제12항에 있어서, 상기 복수개의 인터페이스 오브젝트들은 상기 하나의 논리적 억세스 포인트로부터 수신된 메시지들에 의해 억세스될 수 있는 소프트웨어 오브젝트들을 포함함을 특징으로 하는 시스템.
제13항에 있어서, 상기 룩업 오브젝트는, 상기 관련 서비스 요청 패러미터들에 따라 상기 복수개의 서비스 요소들 중 하나와 비즈니스 협정을 촉진할 짝 만들기 기능을 포함함을 특징으로 하는 시스템.
제13항에 있어서, 상기 룩업 오브젝트는, 상기 관련 서비스 요청 패러미터들을 수신하고, 그 관련 서비스 요청 패러미터들에 의해, 요청된 접속 패러미터들을 제공하는 결정 기능을 제공함을 특징으로 하는 시스템.
제12항에 있어서, 상기 복수개의 인터페이스 오브젝트들은 상기 하나의 논리적 억세스 포인트로부터 수신된 메시지들에 의해 억세스 가능한 복수개의 네트웍 어드레스 전환 프록시들을 포함함을 특징으로 하는 시스템.
제16항에 있어서, 상기 룩업 오브젝트는, 상기 관련 서비스 요청 패러미터들에 의해 상기 복수개의 서비스 요소들 중 하나와의 비즈니스 협정을 촉진할 짝 만들기 기능을 포함함을 특징으로 하는 시스템.
제16항에 있어서, 상기 룩업 오브젝트는, 상기 관련 서비스 요청 패러미터들을 수신하고, 그 관련 서비스 요청 패러미터들에 의해, 요청된 접속 패러미터들을 제공하는 결정 기능을 제공함을 특징으로 하는 시스템.
복수개의 서비스 요소들을 구비하는 한 네트웍 안에서 네트웍 서비스들을 설정하는, 컴퓨터 실행가능 명령을 포함한 컴퓨터 판독 매체에 있어서,

상기 컴퓨터 실행가능 명령은,

복수개의 인터페이스 모듈들로의 하나의 논리적 억세스 포인트가 상기 복수개의 서비스 요소들 중 하나의 외부 발동을 가능하게 할 때, 상기 복수개의 인터페이스 모듈들을 제공하여 상기 복수개의 서비스 요소들 중 하나와의 통신을 설정하는 동작;

서비스 요소 관련 패러미터들을 선택적으로 수신하는 동작; 및

상기 서비스 요소 관련 패러미터들이 상기 복수개의 서비스 요소들 중 하나의 동적 선택 최적화를 규정할 때, 상기 발동에 의해 상기 복수개의 서비스 요소들 중 하나를 선택하는 동작을 포함함을 특징으로 하는 매체.
제19항에 있어서, 상기 복수개의 인터페이스 모듈들을 제공하는 컴퓨터 실행가능 명령의 동작은, 상기 하나의 논리적 억세스 포인트로부터 수신된 메시지들에 의해 억세스 가능한 복수개의 소프트웨어 오브젝트들을 제공하는 동작을 포함함을 특징으로 하는 매체.
제20항에 있어서, 상기 서비스 요소 관련 패러미터들을 수신하는 컴퓨터 실행가능 명령의 동작은, 상기 하나의 논리적 억세스 포인트를 통해 상기 서비스 요소 관련 패러미터들을 수신하는 동작을 포함함을 특징으로 하는 매체.
제21항에 있어서, 상기 서비스 요소 관련 패러미터들을 수신하는 컴퓨터 실행 명령의 동작은, 외부 접속을 통해 상기 서비스 요소 관련 패러미터들을 수신하는 동작을 포함함을 특징으로 하는 매체.
제22항에 있어서, 상기 복수개의 서비스 요소들 중 하나를 선택하는 컴퓨터 실행 명령의 동작은, 상기 서비스 요소 관련 패러미터들을 이용하여 잠정적으로 적합한 서비스 요소들의 초기 개수를 줄이도록 하는 동작을 포함함을 특징으로 하는 매체.
제23항에 있어서, 상기 복수개의 서비스 요소들 중 하나를 선택하는 컴퓨터 실행 명령의 동작은, 상기 서비스 요소 관련 패러미터들을 이용하여 상기 복수개의 서비스 요소들 중 하나와의 비즈니스 협정을 일으키는 동작을 더 포함함을 특징으로 하는 매체.
제19항에 있어서, 상기 복수개의 인터페이스 모듈들을 제공하는 컴퓨터 실행 명령의 동작은, 상기 하나의 논리적 억세스 포인트로부터 수신된 메시지에 의해 억세스 가능한 복수개의 네트웍 어드레스 전환 프록시들을 제공하는 동작을 포함함을 특징으로 하는 매체.
제25항에 있어서, 상기 서비스 요소 관련 패러미터들을 수신하는 컴퓨터 실행 명령의 동작은, 상기 하나의 논리적 억세스 포인트를 통해 상기 서비스 요소 관련 패러미터들을 수신하는 동작을 포함함을 특징으로 하는 매체.
제26항에 있어서, 상기 서비스 요소 관련 패러미터들을 수신하는 컴퓨터 실행 명령의 동작은, 외부 접속을 통해 상기 서비스 요소 관련 패러미터들을 수신하는 동작을 포함함을 특징으로 하는 매체.
제27항에 있어서, 상기 복수개의 서비스 요소들 중 하나를 선택하는 컴퓨터실행 명령의 동작은, 상기 서비스 요소 관련 패러미터들을 이용하여 잠정적으로 적합한 서비스 요소들의 초기 개수를 줄이도록 하는 동작을 포함함을 특징으로 하는 매체.
제28항에 있어서, 상기 복수개의 서비스 요소들 중 하나를 선택하는 컴퓨터 실행 명령의 동작은, 상기 서비스 요소 관련 패러미터들을 이용하여 상기 복수개의 서비스 요소들 중 하나와의 비즈니스 협정을 일으키도록 하는 동작을 더 포함함을 특징으로 하는 매체.