KR20080087867A - 서비스 생성 방법, 그 방법을 구현하기 위한 컴퓨터프로그램 제품 및 컴퓨터 시스템 - Google Patents

Abstract

본 발명은 요청에 기초하여 서비스를 생성하는 방법(100)을 개시한다. 이러한 방법은 이동 전화 또는 PDA(150)로부터 보내진(20) 요청과 같은 자연어 요청을 의미 분석(30)하는 단계를 포함한다. 이러한 방식으로, 요청은 임의의 기술적 지식을 가질 필요 없이 자연어로 공식화(10)될 수 있다. 의미 분석(30)은 웹 서비스 요건들(또는 명세들)을 식별할 수 있게 한다. 다음, 웹 서비스들은 식별된 서비스 요건들에 기초하여 결정(40) 및 시퀀싱(50)된다. 그 후, 예를 들어 자연어 요청을 한 사용자에게 새로운 서비스가 이용가능하게 된다.

요청, 서비스, 의미 분석, 웹 서비스, 요건, 자연어

Description

서비스 생성 방법, 그 방법을 구현하기 위한 컴퓨터 프로그램 제품 및 컴퓨터 시스템{SERVICE CREATION METHOD, COMPUTER PROGRAM PRODUCT AND COMPUTER SYSTEM FOR IMPLEMENTING SAID METHOD}

본 발명은 서비스 생성 방법뿐만 아니라, 그 방법을 구현하기 위한 컴퓨터 프로그램 제품 및 컴퓨터 시스템에 관한 것이다.

본 설명에서는, 별다른 언급이 없는 한, 다음의 용어들이 지시된 의미로 사용된다.

- "UDDI(Universal Description Discovery and Integration)"을 위한 "UDDI 레지스트리": XML 기반의 레지스트리를 가리키며, 더 구체적으로는, 특히 SOA 아키텍처("서비스 지향 아키텍처(Service-Oriented Architectures)"의 약어) 내에서, 웹 서비스들을 위한 것을 가리킨다. 사설 및 공중 레지스트리들 모두가 존재하며, 특정 서비스 제공자들을 위한 특정 레지스트리들이 존재한다. UDDI 레지스트리에 의해, 네트워크 상에 검색용(searched-for) 웹 서비스를 배치하는 것이 가능해진다. 특히, UDDI 레지스트리는 서비스들 및 그 기능들에 관한 간단한 설명과 같은, 웹 서비스들에 접속하기 위한 정보 및 문맥상의 정보를 포함한다. UDDI 레지스트리는, 특히,

- 비즈니스 관련 정보를 포함하는 화이트 페이지들;

- WSDL 표준을 이용하는 이들 비즈니스들의 웹 서비스들을 열거하는 옐로우 페이지들; 및

- 제공된 서비스들에 관한 특정 기술 정보를 제공하는 그린 페이지들을 포함하며, 이 기술 정보는 다른 것들 중에서도, 서비스들, 링크들, 또는 그와 연관된 비즈니스 프로세스들에 관한 설명들에 관한 것이다.

- "컴퓨터 애플리케이션(computer application)": 그의 사용자들에게 서비스를 제공하기 위한 것으로, 함께 작용하도록 의도된 임의의 프로그램 또는 임의의 프로그램 세트를 가리킨다.

- "BPEL(Business Process Execution Language)": 웹 서비스 상호작용 모델의 의미(semantics)를 확장하는, 상호작용 로직들 및 상호작용 프로토콜 로직들의 형식상의 표기(formal notation)에 사용되는 XML 언어를 가리킨다. 웹 서비스들 간의 상호작용들 이외에, BPEL은 상호작용들의 순서 및 애플리케이션 로직을 기술한다.

- "합성(composition)": 웹 서비스들의 문맥에서, 새로운 개별 웹 서비스로서 작용할 수 있는 서비스들의 집적(aggregation)을 가리킨다. 합성과 "편성(orchestration)" 간에 구별이 이루어질 것이며, 여기서는 합성된 서비스들에 의해 수행되는 프로세스들의 순서화(ordering)에 중점을 두며, 합성과 "구성(choreography)" 간에 구별이 이루어질 것이며, 여기서 서비스들의 순서화는 합성된 서비스들에 의한 이벤트들의 고려 및 교환된 메시지들에 기초한다.

- "입력 파라미터(input parameter)": 웹 서비스의 처리 연산에의 입력으로서 제공되는 데이터를 가리키며, 연산의 입력 데이터는 출력 결과를 제공하기 위해 연산에 의해 변환된다.

- "출력 결과(output result)": 입력 데이터(또는 "파라미터들")에 대해 웹 서비스 연산에 의해 수행된 처리로부터 결과로서 생기는 정보를 가리킨다. 출력 결과는 웹 서비스의 사용자에 의해 예상되는 생성물이며, 상기 사용자는 잠재적으로는 컴퓨터 애플리케이션 또는 다른 웹 서비스이다.

- "RSS(Really Simple Syndication)": XML을 기반으로 하여 웹 페이지의 콘텐츠를 기술하는데 이용되는 포맷이며, 이것에 의해 웹사이트의 콘텐츠를 자동으로 색인(index)하고 이용가능하게 할 수 있다.

- "웹 서비스(Web service)": 표준 인터페이스를 통해, 인터넷에서 접속가능한 애플리케이션을 가리키며, 이것은 XML을 기반으로 하는 것과 같은, 통신 프로토콜들을 이용하는 것에 의해 애플리케이션들 또는 다른 웹 서비스들과 다이내믹하게 상호작용할 수 있고, 어떤 오퍼레이팅 시스템 및 프로그래밍 언어들이 사용되는지에 상관없이 상호작용할 수 있다. 그것의 실제 인터페이스들과 관련하여, 웹 서비스는 입력 데이터 또는 "입력 파라미터들"에 기초하여 결과들을 제공하는 처리 연산들을 포함한다. 웹 서비스를 사용하기 위해, 연산들 중 하나가 예상되는 입력 데이터에 웹 서비스를 제공하는 것에 의해 호출되고, 출력 결과가 검색된다.

- "SGML": 디지털 문서의 콘텐츠와 그 구조 사이의 관계를 기술하는 데 이용되는 표준화된 언어를 가리킨다.

- "WSDL": W3C에 의해 표준화된 언어(2001년 3월 15일자 버전 1.1, http://www.w3.org/TR/wsdl 참조, 특히 XML을 참조함). WSDL은 다음의 요소들, 즉, 서비스의 명칭, 연산들, 처리되는 데이터의 유형들, 및 이 유형들과 이 연산들 간의 링크들을 이용한 웹 서비스에의 공중 액세스를 위한 인터페이스를 기술한다. 이러한 식으로, WSDL은 서비스를 이용하기 위해 통신하는 방법, 통신 프로토콜, 및 이 서비스와 통신하는 데 요구되는 메시지 포맷을 지시한다.

- "XML(eXtensible Markup Language)": SGML 언어의 개량이며, 특히, 데이터의 구조를 개인화(personalizing)할 목적으로, 그들 자신의 태그를 정의하기 위해 HTML 문서들의 설계자들에 의해 사용되는 언어를 가리킨다.

현대의 전자통신 기술, 특히, 인터넷은 사용자들이 다양한 서비스에 신속하게 액세스할 수 있게 한다. 계속해서 문제가 발생할 때마다, 반복된 사용자들의 요구를 충족시키기 위해, 적절한 서비스를 생성하는 것이 보통이다. 예를 들어, 일부 인터넷 검색 엔진들은 기계 번역(machine translation)과 같은 진보된 특징들을 제공한다. 그러나, 사용자에게 생길 수 있는 특정 문제들이 기존의 서비스에 의해 해결되지 않는다. 특히, 때때로 (특수한 기술 지식이 없는) 사용자가, 기존의 이러한 서비스 없이, 1회성 문제(one-time problem)를 해결하는 서비스에 액세스하기를 희망할 수 있다. 예를 들어, IP 단말기(예를 들어, 이동 전화기, PDA(personal digital assistant), 포켓 PC 등)의 사용자는 주어진 RSS 서비스를 모국어(native language)로 번역하기를 희망할 수 있다.

따라서, (사용자) 요청에 기초하여 서비스를 생성하는 방법뿐만 아니라, 이 방법을 구현하기 위한 컴퓨터 프로그램 제품 및 컴퓨터 시스템이 필요하다.

이것을 위해, 본 발명은 요청에 기초하여 서비스를 생성하는 방법을 개시하는데, 이 방법은 자연어(natural-language) 요청을 의미론적으로 분석하는 단계; 수행된 의미 분석에 기초하여 웹 서비스 요건들을 식별하는 단계; 및 식별된 서비스 요건들에 기초하여 웹 서비스들을 결정하고 시퀀싱하는(sequencing) 단계를 포함한다.

바람직한 실시예들에서, 본 발명의 서비스 생성 방법은 다음의 특징 중 하나 이상을 포함한다.

- 프로세스는 시퀀싱된 웹 서비스들을 편성하는(orchestrating) 단계를 더 포함한다.

- 웹 서비스들을 결정하는 단계는 UDDI 레지스트리에 액세스하는 단계를 포함한다.

- 요청을 의미론적으로 분석하는 단계는 어휘 및 의미 분석을 포함한다.

- 결정하고 시퀀싱하는 단계는, 웹 서비스들을 결정하는 단계와, 그 다음에 결정된 웹 서비스들을 시퀀싱하는 단계로 분할된다.

- 웹 서비스들을 결정하는 단계는, 웹 서비스들의 기술(description)에 기초하여 웹 서비스 특징들을 식별하는 단계, 이 특징들 중 적어도 일부를 식별된 요건들과 비교하는 단계, 및 비교 결과에 따라 웹 서비스들을 결정하는 단계를 포함한다.

- 웹 서비스들을 시퀀싱하는 단계는 식별된 요건들에 따라 시퀀싱하는 단계를 더 포함한다.

- 웹 서비스 특징들의 식별 스테이지(stage)는, 서비스들 각각에 대하여, 웹 서비스의 기술에의 액세스; 및 이러한 서비스의 기술로부터의 이러한 서비스의 특징들의 식별을 포함한다.

- 웹 서비스의 기술은 WSDL 언어로 되어 있다.

- 특징들을 식별하는 단계는 웹 서비스들의 기술의 의미 분석을 포함한다.

- 시퀀싱하는 단계는 결정된 서비스들 각각에 대한 적어도 하나의 식별된 특징을 포함하는 호환성 테스트를 포함한다.

- 식별된 특징들은, 서비스들 각각에 대하여, 각각 적어도 3개의 필드를 갖는 적어도 2개의 세트를 포함하고, 그 세트들 중 하나의 제1 필드는 서비스 입력과 관련되고, 그 세트들 중 다른 하나의 제1 필드는 서비스의 출력과 관련되고, 그 세트들 각각의 제2 필드는 제1 필드에 관한 데이터의 유형과 관련되고, 그 세트들 각각의 제3 필드는 제1 필드에 관한 의미 태그와 관련되고, 합성 단계는 그 세트들 각각의 제3 필드를 포함하는 호환성 테스트 단계를 포함한다.

- 본 발명의 방법은 결정되고 시퀀싱된 웹 서비스들에 기초하여 새로운 웹 서비스를 생성하는 단계를 더 포함한다.

- 본 발명의 방법은 결정되고 시퀀싱된 웹 서비스들에 대한 승인(approval)을 수신하는 단계, 및 새로운 웹 서비스의 제공 단계를 더 포함한다.

본 발명은 또한 본 발명의 방법의 단계들을 구현할 수 있는 컴퓨터 프로그램 제품에 관한 것이다.

본 발명은 또한 본 발명의 방법의 단계들을 구현할 수 있는 코드 수단을 포함하는 컴퓨터 시스템에 관한 것이다.

본 발명의 다른 특징 및 이점은 본 발명의 실시예들에 관한 다음의 상세한 설명을 읽으면 명백해질 것이며, 이것은 단지 예시를 위해 예들뿐만 아니라 첨부 도면(도 1)을 참조하여 주어지며, 첨부 도면은 본 발명의 일 실시예에 따른 방법의 단계들 및 컴포넌트들을 도시한다.

이러한 방식으로, 본 발명은 요청에 기초하여 서비스를 생성하는 방법을 개시한다. 이 방법은 휴대 전화기 또는 PDA로부터 전송되는 것과 같은, 자연어 요청을 의미론적으로 분석하는 단계를 포함한다. 따라서, 요청은 어떠한 임의의 기술 지식도 갖추고 있을 필요 없이, 자연어로 공식화(formulate)될 수 있다. 수행된 의미 분석은 웹 서비스 요건들(또는 사양들)을 식별할 수 있게 한다. 다음으로, 웹 서비스들의 결정 및 시퀀싱이 식별된 서비스 요건들에 기초하여 수행된다. 그 다음, 예를 들어, 대응하는 자연어 요청을 한 사용자에 대해 새로운 서비스가 이용가능하게 된다. 본 발명의 방법은, (예를 들어) 이동 전화기로부터의 자연어로 표현된 요청에 기초하여, 인터넷에서 발견되는 기존의 컴포넌트 웹 서비스들을 집적하는 것에 의해 새로운 서비스를 생성하고, 그 다음에 이 새로운 서비스가, (적용가능한 경우) 컴포넌트 서비스들의 제안된 시퀀스의 승인 후에, 사용자에게 이용가능하게 될 수 있게 한다.

이 방법은 다중 결합된 소프트웨어 모듈들을 포함하는 보조물(assistant) 또는 애플리케이션과 같은 "통합된(integrated)" 컴퓨팅 툴 내에서 구현되는 것이 바람직하며, 이 모듈들 각각은 주어진 태스크에 할당된다.

도 1은 본 발명의 일 실시예에 따른 방법의 단계들 및 컴포넌트들을 나타낸다.

이 도면을 참고하면, 본 발명의 서비스 생성(creation) 방법(100)은 자연어(natural-language) 요청을 의미론적으로(semantically) 분석(30)하는 단계를 포함한다.

이러한 요청은 예를 들면, PDA(personal digital assistant)(150)로부터 사용자(120)에 의해 공식화(formulation) 되었을 수 있다(단계 10). 그 후 요청은 전기 통신망(telecommunications network)을 통하여 송신되고(단계 20) 서버(도시 안됨)에 의해 수신된다. 이 텍스트는 예를 들면, 다음과 같을 수 있다: "I want to get the text of Reuters bulletins translated into German."

클라이언트의 이동 전화기 또는 PDA 내와 같은, 클라이언트측 또는 서버측 중 어느 하나에서 상술된 컴퓨팅 툴(computing tool)을 구현할 수 있다는 것을 주의해야 한다.

요청을 분석하는 단계(30)는 예를 들면, 구문 분석기(syntactic analyzer)(또는 "파서(parser)", 즉 구문 단위(syntatic unit)들의 인식에 기초하여 기술(description)을 분석할 수 있는 툴) 또는 의미 분석기에 연결된 구문 분석 루틴을 이용하여 수행될 수 있다. 이러한 구문 분석 및 의미 분석의 연결을 (제1) "의미 모듈(semantic module)"이라고 부를 것이다. 이러한 모듈은, 정의에 의해, 상술된 컴퓨팅 툴에 통합될 수 있고, 그 목적은 요청의 의미 분석을 수행하는 것이다.

이러한 분석은 컴퓨터 판독 가능 포맷(computer-readable format)의 요청을 논리적으로 조직화(structure)하는 것을 가능하게 한다. 자연어 텍스트들에 대한 다양한 의미 분석 기술들이 알려져 있다. 통상적으로, 이를테면, 명칭, 그들 각각의 정의들, 및 이러한 명사들 사이에서의 연산들이 요청으로부터 추출되거나 추론(deduce)된다. 그렇게 하기 위하여, 종래 기술에서 알려진 바와 같이, 사전들 또는 문법적 분석이 사용된다.

특히, 의미 분석 단계(30)는 첫째로 어휘 분석을 포함할 수 있다. 이전의 예에서, 어휘 분석의 제1 결과는 관련 단어의 목록, 또는 필요하다면, 그들의 표준형(무관한 단어들은 무시된다)의 목록이다. 이러한 목록은 표 1에서 나타난다.

둘째로, 표 2에서 지시된 것과 같이, 문맥-특정의(context-specific) 의미 정보(semantic information)가 의미 분석 모듈에 의해 추가될 수 있다.

그 후 요청을 어휘적 및 의미론적으로 분석하는 단계는 컴포넌트 웹 서비스(component Web service)들에 대한 요청들(즉, "사양(specification)들")을 식별(단계 35)하는 것을 가능하게 한다. 이전의 예에서, 원래 요청의 추가적인 의미 정보 및 문법적 형식을 고려하여, 의미 모듈은 컴포넌트 서비스들에 대한 이하의 요건들을 생성할 수 있다:

게다가, 이하의 단계, 즉 웹 서비스들을 결정하는 단계(40) 및 시퀀싱(sequencing)하는 단계(50)들을 용이하게 하기 위해, 이러한 요건들을 WSDL 포맷에 필적하는 포맷(위의 정의를 참고)으로 조직화하는 것도 가능하다. 나중에 세부 사항이 제공될 것이다.

이러한 이중 단계(40, 50)는 바람직하게 웹 서비스들을 결정하는 단계(40) 및 결정된 웹 서비스들을 시퀀싱하는 단계(50)로 나누어진다. 이러한 방식으로, 서비스들이 결정된 후에, 시퀀스가 승인(approval)을 위해 사용자에게 제시될 수 있다(단계 52). 그 후 사용자는 그것을 승인하거나(단계 55) 그 자신의 시퀀스를 합성(compose)할 수 있고, 그 후 여기에서 적절한 모듈에 의해 처리되는 기계 시퀀싱(machine sequencing)을 발생시킬 수 있다.

대안적으로, 웹 서비스들은 하나씩 결정될 수도 있고, 그 후 부분적 및 점진적 시퀀싱을 위해 제공(submit)될 수 있다. 그러한 경우에, 결정하는 단계(40) 및 시퀀싱(50)하는 단계는 중첩(nest)된다. 그러나 시퀀싱이 완료된 후에, 시퀀스는 여전히 승인을 위해 사용자에게 제공될 수 있다. 또한, 복수의 시퀀스가 소정의 기준들에 기초하여 계산된 순서로 제시될 수 있다는 것을 주의해야 한다.

일 실시예에서, 웹 서비스들을 결정하는 단계(40)는 상기 웹 서비스들의 기술(description)에 기초하여 웹 서비스들의 특징을 식별하는 것을 포함한다. 이 단계 동안, 이용 가능한 웹 서비스들은 예를 들면, 조직적으로(systematically) 검토될 수 있다. 그들 각각에 대하여, 특징들이 식별되고 이러한 특징들 중 적어도 일부와 이전에 설정된 요건들 사이에서 비교가 행해진다. 그러면 비교 결과에 기초하여 웹 서비스들을 결정할 수 있게 된다.

또한 웹 서비스들의 특징들의 식별과 관련하여, 더욱 상세한 방식, 이러한 서비스들의 표준화된 기술이 이용된다. 바람직하게는, 웹 서비스들의 개별적인 기술이 사용된다. 이러한 방식으로, 소정의 웹 서비스에 대하여, 위에서 언급된 컴퓨팅 툴은 서비스의 기술에 접근하고 그 후 서비스의 기술에 기초하여 특정 특징들을 식별한다. 이러한 특징들은 서비스의 기술 내부 등에 명백하게 존재하지 않는다는 것을 주의해야 한다. 특징들은 본 발명의 방법에 의해 추론된다.

특히 상술된 바와 같이, UDDI 레지스트리와 같은 기술 카탈로그(description catalogue)가 이용가능하다면, 웹 서비스들의 개별적인 기술들을 사용하는 것이 바람직하다.

바람직하게는, 서비스들의 각 기술은, 예를 들면 UDDI 레지스트리(UDDI registry)들에서와 같이 WSDL 언어로 되어 있다. 이러한 방식으로, 표준화된 기술은 각 웹 서비스에 대하여 이용가능하다. 게다가, 그러한 기술은 공개된 웹 서비스의 인터페이스 외부로부터 이러한 서버에 의해 자동적으로 작성되기 때문에, 언제나 레지스트리 서버 상에서 이용가능하다. 이것은 본 방법에 더 큰 호환성을 제공한다.

게다가, 그러한 기술들을 구문 분석기(또는 상술된 바와 같은 "파서")를 사용하는 등에 의해 자동적으로 분석하는 것이 가능하다. (제2) 의미 모듈이 아래에서 참조된다. 그리하여 이러한 제2 모듈의 기능은 WSDL 기술을 의미론적으로 분석한다.

더욱 상세하게, 구문 분석기는 예를 들면, 종래 기술에서 알려진 것과 같은 어휘 분석을 포함할 수 있다. 그 후, 추출된 어휘(lexical) 컴포넌트들의 의미를 결정하기 위해 웹 서비스들의 기술들의 의미 분석이 수행된다.

서비스들의 기술(description)들의 분석은 각 서비스들에 대한 특징들을 식별하는 것을 가능하게 한다. 예를 들면, 서비스들의 연산들의 각각에 대한 특징들의 세트들을 식별하는 것을 가능하게 한다. 이러한 특징들은 식별된 서비스들의 접속성(connectivity)을 결정하기 위해 나중에 사용될 것이다.

이전에 설정된 요건들 및 식별된 특징들은 바람직하게는 유사하게 조직화되기 때문에, 그들을 비교하는 것은 (예를 들면, 공유된 특징들의 수에 기초함에 의해)더 쉬워지고 더 빨라진다. 이러한 비교의 완료시 및 소정의 요건들의 세트에 대하여, 하나의 웹 서비스(또는 그 이상)가 결정된다. 적용가능하다면, 그것은 순위들을 결정하고 (비교의 의미 내에서) "최상의(best)" 서비스만을 유지하는 데 유용할 수 있다.

컴포넌트 웹 서비스들을 결정(35)하는 단계의 완료 시, 소정 개수의 알려진 서비스들이 이용가능하다. 그 후 이러한 서비스들을 요청에서 표현된 논리에 기초하여 합성하는 것이 바람직하다.

그렇게 하기 위해서, 식별된 특징들이 기본으로 사용될 수 있고, 상기 특성은 이전에 설정된 요건들을 반영한다. 그 후 이러한 특징들은 서비스 접속성(service connectivity), 즉 접속될 서비스들의 경향을 결정하는 것을 가능하게 한다. 다음으로, 그들의 접속성에 기초하여 이러한 서비스들을 자동적으로 합성하는 것이 가능할 수 있다.

웹 서비스들의 특징들 중에서 예를 들면, 소정의 웹 서비스의 연산들 각각에 대한 적어도 하나의 입력 및/또는 출력을 식별하도록 요구할 수 있다.

보다 일반적으로, 예를 들면, "입력 파라미터들" 또는 "출력 결과들"(위의 이러한 용어들의 정의들을 참고)과 같은 각 서비스의 각 연산의 입력들-출력들을 검색할 수 있다. 그 후 이러한 방식으로, 웹 서비스들의 연산들의 입력/출력 특징들을 비교함으로써 웹 서비스들의 접속성을 테스트하는 것이 가능할 것이다. 예를 들면, 서비스 B의 연산의 입력과 호환되는 출력을 제공하는 연산을 갖는 서비스 A가 서비스 B에 접속될 수 있다.

서비스들의 접속성을 결정하기 위해서, 및 이러한 서비스들의 미래의 합성들에 대한 안목을 가지고, 일 실시예에서, 소정의 웹 서비스의 연산들의 각 입력 및 각 출력에 대한 특징들의 세트를 생성하는 것이 가능할 수 있다.

웹 서비스의 하나의 연산이 다수의 입력들 또는 다수의 출력들을 갖는다면, 대응하는 세트들의 수는 웹 서비스의 기술이 분석될 때 생성될 수 있다.

파라미터들 자체의 명칭에 부가하여, 이들 세트들은 예를 들어, 각각 3개(또는 계획된 테스트 모델에 따라 그 이상)의 필드들을 가질 수 있다. 그러나, WSDL 기술이 해석되는 방법에 따라 2개의 필드들 이용하는 것이 충분하다고 판명될 수 있음을 주목해야 한다.

따라서, 각각의 세트는 바람직하게 3개의 필드들을 가질 수 있고, 웹 서비스의 연산의 입력 파라미터 또는 출력 결과에 관련된다. 제1 필드는 문제의 결과 또는 파라미터에 대한 입력 또는 출력 정보와 관련된다. 각각의 세트의 제2 필드는 파라미터 또는 결과의 데이터 유형을 특정화한다. 데이터 유형은 서비스의 WSDL 기술에 있는 요소들 중 하나이다. 제3 필드는 파라미터 또는 결과와 관련될 의미 태그(semantic tag)(아래 예에서는 "SemTag")에 관련된다. 의미 태그는, 명칭, 문자열 또는 보다 일반적으로 데이터와 관련되고 그것을 의미론적으로 더 특징짓는 역할을 하는 코드로서 본원에 도시될 수 있다. 유형이 WSDL 기술로부터 직접 추출될 수 있다면, 태그는 이러한 동일한 기술이 분석된 후 위치된다는 것을 주목해야 한다.

그 후, 특징 호환성 비교 테스트는 각각의 세트의 각각의 필드를 포함할 수 있다.

상술된 제2 의미 모듈은 앞서 언급된 컴퓨팅 툴(computing tool)의 통합 부분을 형성하는데 전형적으로 이용될 수 있어, 입력 및 출력 둘 다에서, 데이터의 각각의 유형에 대한 의미 태그를 위치시킨다. 이 태그는 입력/출력 데이터의 본질을 특정하고, 따라서, 데이터가 처리되는 방법을 특정한다. 이러한 방식으로, 입력/출력 데이터의 각각의 종류가 트리플릿(triplet)으로 기술된다.

{입력 또는 출력, 데이터의 유형, 의미 태그}

3개의 필드들을 이용하여, 추후 언급될 웹 번역 서비스의 입력들의 의미론적 기술(semantic description)에 대응하는 XML 파일의 추출이 아래 도시된다(이 XML 파일 추출은 대응하는 WSDL 파일에 대해 수행된 의미론적 처리의 결과임):

이러한 방식으로, 입력 정보 이외에, 모든 파라미터는 그것의 명칭, 그것의 유형 및 그것의 의미 태그("semtag")에 대응하는 3개의 필드들을 포함하는 것을 볼 수 있다. 그 후 서비스들 사이의 호환성에 대한 테스트 동안 이용될 3개의 정보의 종류는 입력 및 출력 정보, 유형 정보 및 의미 태그이다.

의미 태그에 대한 보다 상세한 설명들이 지금 제공된다.

WSDL 파일이 분석될 때마다, 서비스의 유형들, 메시지들, 연산들 및 명칭에 대응하는 4개의 메인 파트들이 식별될 수 있다. 또한, "포트유형(PortType)" 및 "바인딩(Binding)"에 대응하는 다른 정보가 식별되고(이러한 2가지 용어들은 WSDL 기술에서 일반적인 용어들임), 이는 연산의 입출력과 메시지들 사이에 접속을 생성하는 역할을 할 것이다.

WSDL 기술에 대한 제1의 순수 구문의 분석 레벨은 서비스의 "유용한" 구문 구조, 즉, 필수적이고 충분한 정보를 획득하도록 할 수 있다. 이러한 정보는 4개의 상술된 부분들로부터 주로 획득된다. 검색에 유용하지 않은 요소들은 제거된다. 남은 정보는 "바인딩" 및 "포트유형"을 이용하여 재순서화되고 상호접속된다. 이것은 구문 분석기를 이용하여 용이하게 실현된다. 이러한 레벨에서, 의미 데이터는 아직 추가되지 않는다.

예로서, 번역 서비스를 통해 획득된 유용한 구문 구조는 다음과 같다(용어들은 XML 언어로부터 취해짐) :

유용한 구문 구조에 기초하여, 제2 의미 모듈을 이용하여 한정된 분석이 행해진다. 이 모듈은 예를 들어, 이하의 연산들을 이용하여 작업을 할 수 있다. 이것은 이용된 용어들(상기, 용어들 "Translate", "lang", "text", "TranslateResult" 등)을 선택하고, 이러한 용어들의 "연결을 끊기(deconcatenate)"위해 용어들을 분해한다(이러한 용어들은 일반적으로 프로그래밍 언어에 이용된 용어들과 유사한 방식으로 기입되거나 "_"과 같은 문자들에 의해 구분됨). 그 후, (예를 들어 사전을 검색함으로써) 필요하다면, 모듈은 잘린(truncated) 용어들을 확장시킨다. 이전 예에서, 모듈은 "translate", "text" 및 "translate result"를 제공한다. 확장이 행해진 후, 적절한 사전들을 이용하여, 명사를 각각의 명사에 대한 정의들뿐만 아니라, 그 명사와 만나는 각각의 동사와 연관시키도록 노력한다. 적절하다면, 모듈은 이러한 정의를 검사하여 단지 하나만 보유한다. 적절하다면, 이러한 처리 작업들을 단순화하고, 쉽게 이용할 수 있는 결과들을 달성하는 것을 가능하게 하는 보완적인 기술들이 알려져 있다.

상기 주어진 제5 단계의 주요 목적은, 서비스의 전술된 유용한 구문 구조에 대한 각각의 입력/출력의 명칭들 각각에 의미 태그를 추가하는 것이다. 이러한 방식으로, "텍스트" 태그는 대응하는 입력 "텍스트"에 대해 위치될 것이다. 이러한 방식으로, 서비스의 재작업 기술이 얻어진다. 번역 서비스의 예에서, 상술된 XML 파일의 추출과 유사한 기술이 얻어진다.

의미 태그 - "수퍼태그(supertag)"로서 보여질 수도 있음 - 를 배치시키는 것은 웹 서비스들의 접속성을 효과적으로 결정할 수 있게 한다. 그러나, 다른 의미 분석 기술들이 이러한 배치를 위해 이용될 수 있다.

이 때, 하나의 웹 서비스를 다른 웹 서비스에 접속시키는 것이 가능한 모든 컴포넌트들이 존재한다.

다음에서, 웹 서비스들의 접속성을 결정하는 단계는 예를 이용하여 기술된다.

이러한 예에서, 사용자는, 그의 요청에서 그가 번역 서비스 및 RSS 서비스로부터 (신문의 웹사이트로부터 얻어진 것과 같은) RSS 피드를 번역한 결과의 디스플레이된 것을 보고 싶다고 표현한다. RSS 피드는 특히, 뉴스 사이트로부터의 헤드라인들 또는 전체 텍스트 중 하나를 자동적으로 재생한다. 이러한 포맷은 특히, 컨텐츠가 통상 업데이트되는 페이지들을 이용할 수 있도록 하는데 이용된다.

이 경우에는, 요청이 전달되고 나서 분석된 때에, 요청으로부터 웹 서비스 요건들이 나오고, 마지막으로, 이러한 웹 서비스들이 UDDI 레지스트리를 참고하여 발견된다고 가정된다. 따라서, 필수적인 웹 서비스들이 이용가능하다. 현재, 발생하는 하나의 문제는 RSS 컨텐츠 일부의 기계 번역을 획득하기 위해 이러한 서비스들을 자동적으로 합성하는 방법이다.

우선, 입력(제1 언어로 기입된 텍스트 또는 "lang 1") 및 출력(제2 언어로 기입된 다른 텍스트 또는 "lang 2")을 가진 번역용 웹 서비스가 이용가능하다. 대응하는 WSDL 기술의 분석에 의해 다음 트리플릿 세트들에 의해 기술된, 입력 및 출력 데이터가 식별된다:

{입력 1, 유형=string, 의미 태그: 번역될 텍스트}

{입력 2, 유형=string, 의미 태그: 언어 1}

{출력 1, 유형=string, 의미 태그: 번역된 텍스트}

{출력 2, 유형=string, 의미 태그: 언어 2}

단어 "string"은 문자들의 스트링을 의미한다.

RSS 피드를 제공하는 웹 서비스도 이용가능하다. 이러한 웹 서비스는 예를 들어, 전술된 툴에 의해 행해진 분석 이후, 다음과 같이 특정된 출력들을 제공할 수 있다:

{출력 1, 유형= string, 의미 태그=헤드라인};

{출력 2, 유형= string, 의미 태그=헤드라인의 언어};

{출력 3, 유형=string, 의미 태그: 기술}; 및

{출력 4, 유형=string, 의미 태그=기술 언어}

또한, 디스플레이 서비스가 이용가능하고, 분석 이후의 식별된 문자들은 다음과 같을 수 있다:

{입력=디스플레이될 텍스트, 유형=string, 의미 태그=텍스트}; 및

{출력=디스플레이, 유형=screen, 의미 태그=디스플레이}

그 후, 합성될 서비스들 각각의 접속성이 결정되는데, 바람직하게는 한번에 2개가 결정된다. 그렇게 함으로써, 웹 서비스들 중 하나의 입력(들) 및 또 다른 서비스의 출력(들) 사이의 의미론적 대응관계, 즉, 2개의 의미론적 트리플릿 사이의 호환성이 조사될 수 있다.

이러한 호환성은 특히, 3가지 조건들을 만족할 수 있다:

a) 제1 트리플릿은 출력, 나머지는 입력에 관계된다.

b) 두 유형은 동일하거나 호환가능하다.

c) 두 의미 태그들은 동일하거나 호환가능하다.

이러한 목적으로, 호환성 표가 제공되어 전술된 컴퓨팅 툴에 대해 이용가능하게 될 수 있다.

상기 예에서, 호환성은 이러한 방향으로 자동적으로 발견된다:

RSS 서비스 -> 번역 서비스 -> 디스플레이 서비스

실제로, 의미 모듈에 이용가능한 표는 서비스들 각각을 이용하여, 한번에 2개의(two-at-a-time) 완벽한 매치를 생성하는 것이 가능하게 할 수 있다.

한편, 시퀀스 "RSS 서비스 -> 디스플레이 서비스 -> 번역 서비스"는, 디스플레이 서비스의 출력과 번역 서비스의 입력 사이의 의미론적 비호환성으로 인해, 고려되지 않을 것이다.

반복 프로세스 즉 "반복 처리"는, 적절하다면, 제1 서비스로부터의 동일한 유형의 소정수의 출력들을 다른 서비스로부터의 입력에 연결하기 위해 채택될 수 있다는 것을 주목해야 한다. 이는 특히, 이전 예에서 유용하다. 이러한 방법에서, 각각의 RSS 서비스 출력(제목, 기술 등)이 번역된 후 디스플레이된다.

더 상세히, 웹 서비스들의 접속성에 대한 결정은 두 단계들:

i) 우선, 그들 각각의 입력들-출력들을 검사함으로써 얻은 논리적 순서화(ordering)에 기초하고; 및

ii) 다음으로, 입력들-출력들 자체의 접속에 의해, (전술된 호환성 테스트를 수행함으로써) 그들의 의미 태그들 및 그들의 유형들에 대한 상세 기술에 기초하여 수행될 수 있다.

이러한 방식으로, 특정 모듈은 서비스들의 편성(orchestration) 순서를 포괄적으로 결정(서비스 X는 서비스 Y 전에 나오는 등)하고, 그 후, 보다 상세한 수준에서 어떤 서비스의 출력을 다른 어떤 서비스의 입력에 접속하는지를 결정하는 작업을 한다.

포괄적인 편성 순서는, 적용가능하고 상술된 바와 같다면, 승인(단계(55))을 위해 사용자에게 제안(단계(52))될 수 있다. 그러나, 이러한 사용자는 이러한 순서를 변화시키거나 다른 서비스를 가져오도록 결정할 수 있다.

편성 순서는 예를 들어, 규칙 데이터베이스 내에 구현될 수 있고 추론 엔진의 제어 하에 위치될 수 있는 발견적 지도법(heuristics)을 기초로 결정될 수 있다. 예를 들어, 서비스(A)가 그것의 입력-출력에서, 텍스트에 대응하는 의미 태그들을 처리하고, 서비스(B)가 그것의 입력에서, 상이하거나 비호환성의 태그들을 갖는다면, 순서는 우선적으로 B 이후 A가 될 것이다.

상술한 예에서, 우선, RSS 서비스가 호출되는데, 그 출력은 텍스트에 대응하는 의미 태그들을 갖는다(입력 태그는 예를 들어 웹 어드레스에 대응하고 "텍스트"와는 다르다). 다음, 입력 및 출력에서 텍스트에 대응하는 태그를 갖는 번역 서비스가 호출된다. 또한, RSS 서비스의 출력은 번역 서비스의 입력에 접속될 수 있다.

의미 태그와 유형 태그를 비교하는 것으로부터 알 수 있는 명백한 비호환성의 견지에서, 제안된 자동 접속들은 다음과 같을 것이다:

- RSS 서비스의 헤드라인들에 대응하는 텍스트 출력은 번역 서비스의 (단독) 텍스트 입력에 접속될 수 있다.

- RSS 서비스의 기술에 대응하는 텍스트 출력은 번역 서비스의 (단독) 텍스트 입력에 접속될 수 있다.

이러한 제안들은 이하의 합성 단계를 위해 직접 이행될 수 있고, 또는, 적용가능하다면, 상기 지시된 대로 사용자에 의해 승인될 수 있다.

다음, 접속성이 설정되면, 실제 웹 서비스들의 합성이 그들의 접속성에 따라 특수 어셈블리 모듈에 의해 수행된다. 결과적으로, 접속들의 스트링은 예를 들어 형식상의 편성 또는 구성 언어(choreography language)로 번역될 수 있다(문서 앞부분의 정의 참조). 그 후 접속들의 스트링은 편성 엔진으로 제공될 수 있는데, 편성 엔진은 이산(discrete) 웹 서비스이므로 그것을 실행하는 것에 의해 작업이 부과될 것이다. 특히, 이하의 유형:

서비스 A의 "입력 1" => 결과 "출력 1"

-> 서비스 B의 "입력 2" => 결과 "출력 2"

-> 서비스 C의 "입력 3" => 결과 "출력 3"

의 접속 스트링은 번역된 후 편성 엔진으로 제공될 수 있는데, 편성 엔진은 A, B 및 C로 이루어진 이산 서비스 D로서 접속 스트링을 실행할 것이고, 입력 1이 주어지면 "최종 결과 3"를 바로 제공할 수 있다.

그 후 어셈블리 모듈은 웹 서비스들을 자동적으로 접속할 수 있게 한다

이에 의해, 상기 컴퓨팅 툴에 의해 자동 합성된 서비스(단계 60)가 얻어진다.

이러한 방식으로 합성된 서비스는 사용자에게 이용가능하게 된다(단계 65, 70).

하나의 대안에서, 서비스는 또한 사용자에게 이용가능하게 유지될 수 있고(이 경우에, 서비스가 생성됨), 적용가능하다면, 주어진 시간 주기동안 그와 같이 유지될 수 있다.

이러한 툴을 특정 애플리케이션에 통합시키는 것에 의해 실시간으로 서비스들의 합성을 획득할 수 있다. 상기 예에서, 필요한 요소들을 지정하라고 요청된다면, 원하는 언어로 번역된 RSS 피드(feed)를 제공할 수 있다.

당연히, 다른 예 및 합성이 예측될 수 있다.

Claims (17)

1. 요청으로부터 서비스를 생성하는 방법(100)으로서,

   자연어로 된 요청을 의미 분석(semantically analyzing)(30)하는 단계;

   수행된 의미 분석(30)에 기초하여 웹 서비스 요건들을 식별(35)하는 단계; 및

   상기 식별된 서비스 요건들에 따라 웹 서비스들을 결정(40)하고 시퀀싱(sequencing)(50)하는 단계;

   를 포함하는 서비스 생성 방법.
2. 제1항에 있어서,

   상기 시퀀싱된 웹 서비스들을 편성(orchestrating)(60)하는 단계를 더 포함하는 서비스 생성 방법.
3. 제1항에 있어서,

   상기 웹 서비스들을 결정하는 단계는 UDDI 레지스트리(200)를 액세스하는 단계를 포함하는 서비스 생성 방법.
4. 제1항에 있어서,

   상기 요청을 의미 분석(30)하는 단계는 어휘 및 의미 분석(30)을 포함하는 서비스 생성 방법.
5. 제4항에 있어서,

   상기 결정(40)하고 시퀀싱(50)하는 단계는 웹 서비스들을 결정(40)한 후 결정된 웹 서비스들을 시퀀싱(50)하는 단계로 분할되는 서비스 생성 방법.
6. 제5항에 있어서,

   상기 웹 서비스들을 결정(40)하는 단계는,

   웹 서비스들의 기술(description)에 기초하여 웹 서비스들의 특징들을 식별하는 단계;

   이들 특징들 중 적어도 일부를 상기 식별된 요건들과 비교하는 단계; 및

   상기 비교의 결과에 기초하여 웹 서비스들을 결정하는 단계

   를 포함하는 서비스 생성 방법.
7. 제5항에 있어서,

   상기 웹 서비스들을 시퀀싱(50)하는 단계는 식별된 요건들에 기초하여 시퀀싱하는 단계를 더 포함하는 서비스 생성 방법.
8. 제6항에 있어서,

   싱기 웹 서비스들의 특징들을 식별하는 단계는, 상기 서비스들 각각에 대해,

   상기 웹 서비스의 기술에 액세스하는 단계; 및

   그 서비스의 기술에 기초하여 그 서비스의 특징들을 식별하는 단계를 포함하는 서비스 생성 방법.
9. 제8항에 있어서,

   상기 웹 서비스의 기술은 WSDL 언어로 된 서비스 생성 방법.
10. 제6항에 있어서,

    상기 특징들을 식별하는 단계는 웹 서비스들의 기술들의 의미 분석을 포함하는 서비스 생성 방법.
11. 제6항에 있어서,

    상기 식별된 특징들은 상기 결정된 서비스들 각각에 대한 입력 및/또는 출력을 포함하는 서비스 생성 방법.
12. 제6항에 있어서,

    상기 시퀀싱(50)하는 단계는, 상기 결정된 서비스들의 각각에 대해 적어도 하나의 식별된 특징을 포함하는 호환성 테스트(compatibility test)를 포함하는 서비스 생성 방법.
13. 제11항에 있어서,

    상기 식별된 특징들은, 상기 서비스들 각각에 대해, 적어도 3개의 필드들을 각각 갖는 적어도 2개의 세트를 포함하고,

    상기 세트들 중 하나의 제1 필드는 상기 서비스의 입력에 관련되고,

    다른 세트의 제1 필드는 상기 서비스의 출력에 관련되고,

    상기 세트들 각각의 제2 필드는 상기 제1 필드와 관련된 데이터의 유형에 관련되고,

    상기 세트들 각각의 제3 필드는 상기 제1 필드와 관련된 의미 태그에 관련되고,

    상기 합성 단계는 상기 세트들 각각의 상기 제3 필드를 포함하는 호환성 테스트 단계를 더 포함하는 서비스 생성 방법.
14. 제1항에 있어서,

    상기 결정 및 시퀀싱된 웹 서비스들에 기초하여 새로운 웹 서비스를 생성(60)하는 단계를 더 포함하는 서비스 생성 방법.
15. 제14항에 있어서,

    상기 결정 및 시퀀싱된 웹 서비스들에 대한 승인을 수신(55)하는 단계, 및

    상기 새로운 웹 서비스를 이용가능하게 하는(65) 단계

    를 더 포함하는 서비스 생성 방법.
16. 제1항 내지 제15항 중 어느 한 항의 방법(100)의 단계들을 구현할 수 있는 컴퓨터 프로그램 제품.
17. 제1항 내지 제15항 중 어느 한 항의 방법(100)의 단계들을 구현할 수 있는 코드 수단을 포함하는 컴퓨터 시스템.

Images