KR100915776B1 - 웹 서비스 중개기를 위한 포트 타입 어그노스틱 프록시지원 - Google Patents

웹 서비스 중개기를 위한 포트 타입 어그노스틱 프록시지원

Info

Publication number
KR100915776B1
KR100915776B1 KR1020067011403A KR20067011403A KR100915776B1 KR 100915776 B1 KR100915776 B1 KR 100915776B1 KR 1020067011403 A KR1020067011403 A KR 1020067011403A KR 20067011403 A KR20067011403 A KR 20067011403A KR 100915776 B1 KR100915776 B1 KR 100915776B1
Authority
KR
South Korea
Prior art keywords
target service
request
delete delete
endpoint
web service
Prior art date
Application number
KR1020067011403A
Other languages
English (en)
Other versions
KR20060123294A (ko
Inventor
그레고리 알란 플러리
사이먼 안토니 제임스 홀스워스
제임스 미첼 스넬
Original Assignee
인터내셔널 비지네스 머신즈 코포레이션
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US10/734,770 external-priority patent/US7296072B2/en
Priority claimed from US10/734,773 external-priority patent/US7464142B2/en
Application filed by 인터내셔널 비지네스 머신즈 코포레이션 filed Critical 인터내셔널 비지네스 머신즈 코포레이션
Publication of KR20060123294A publication Critical patent/KR20060123294A/ko
Application granted granted Critical
Publication of KR100915776B1 publication Critical patent/KR100915776B1/ko

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/564—Enhancement of application control based on intercepted application data

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)
  • Telephone Set Structure (AREA)
  • Structure Of Receivers (AREA)
  • Structure Of Telephone Exchanges (AREA)
  • Stored Programmes (AREA)
  • Multi Processors (AREA)
  • Small-Scale Networks (AREA)

Abstract

웹 서비스 중개기들을 위한 포트 타입 어그노스틱 프록시 지원이 전형적으로 제공되는 방법, 시스템 및 제품이 개시되는데, 이러한 방법, 시스템 및 제품은 웹 서비스들 오퍼레이션의 실행에 대한 요청을 웹 서비스들 중개기(202) 내에서 수신하는 것 - 요청은 오퍼레이션을 지원하는 타겟 서비스의 종단점이 식별될 수 있는 파라메트릭 정보를 포함함-; 파라메트릭 데이터에 의존하여, 오퍼레이션을 지원하는 타겟 서비스의 종단점을 식별하는 것; 타겟 서비스(118) 상의 오퍼레이션의 실행에 대한 타겟 서비스 요청을 생성하는 것; 및 타겟 서비스 요청을 타겟 서비스에 송신하는 것을 포함한다. 예시적인 실시예는 전형적으로, 타겟 서비스로부터의 응답을 중개기(202) 내에서 수신하고; 중개기 내에서, 타겟 서비스로부터의 응답에 의존하여, 중개기로부터의 응답을 생성하며; 중개기(202)로부터의 응답을 요청 클라이언트(102)에게 돌려보내는 요청-응답 프로세싱의 복귀 경로를 또한 포함한다.

Description

웹 서비스 중개기를 위한 포트 타입 어그노스틱 프록시 지원{PORT TYPE AGNOSTIC PROXY SUPPORT FOR WEB SERVICES INTERMEDIARIES}
본 발명은 데이터 프로세싱, 또는 더욱 구체적으로 웹 서비스 중개기를 위한 포트 타입 어그노스틱(port type agnostic) 프록시 지원을 위한 방법, 시스템 및 제품에 관한 것이다.
"웹 서비스"라는 용어는 웹 기반의 애플리케이션을 통합하는 표준화 방식을 말하는 것이다. 웹 서비스는 전형적으로, 바인딩(binding)이라고 하는 표준화 포맷의 데이터 통신을 통해 요청시에 비즈니스 서비스를 제공한다. 바인딩은 데이터 인코딩 방법 및 데이터 통신 프로토콜의 스펙(specification)이다. 웹 서비스를 위한 사용시에 가장 일반적인 바인딩은 SOAP 프로토콜 및 HTTP로의 데이터 통신에 따른 XML의 데이터 인코딩이다.
브라우저 클라이언트로부터의 요청에 응답하여 HTML 문서를 제공하는 HTTP 서버와 같은 종래의 클라이언트/서버 모델과 달리, 웹 서비스는 디스플레이와 관련되지 않는다. 그 대신에, 웹 서비스는 네트워크 전반에서 프로그램 인터페이스를 통해 비즈니스 로직, 데이터 및 프로세스들을 공유한다. 웹 서비스 애플리케이션들은 서로 인터페이싱하지만, 사용자들과는 인터페이싱하지 않는다. 웹 서비스들 사이의 모든 데이터 통신이 표준화 바인딩에 따라 실행되기 때문에, 웹 서비스는 임의의 한 운영 체계 또는 프로그래밍 언어에 구속되지 않는다. 윈도우스(WindowsTM) 플랫폼에서 실행되는 자바 클라이언트는 펄(Perl)로 기입되고 유닉스(Unix) 하에 실행되는 웹 서비스 오퍼레이션을 호출할 수 있다. C++로 기입된 윈도우스 애플리케이션은 자바 서블릿(servlet)으로서 구현된 웹 서비스 내의 오퍼레이션을 호출할 수 있다.
오늘날, 웹 서비스는 많은 산업분야 전반에서 성장하고 있다. 웹 서비스의 중요성이 커짐에 따라, 웹 서비스 중개기는 점점 더, 다수의 부가가치 서비스를 제공하기 위한 수단으로서 인식된다. 이 명세서에서 일반적으로 "중개기(intermediary)"라 칭해지는 웹 서비스 중개기는 웹 서비스 클라이언트와 웹 서비스 제공자 사이에 놓인 웹 서비스 컴포넌트이다. 중개기는 일반적으로, 클라이언트로부터의 요청을 가로채서, 중개기 서비스를 제공한 다음에, 클라이언트 요청을 웹 서비스 제공자에게 전송함으로써 동작한다. 이와 유사하게, 웹 서비스 제공자로부터의 응답은 가로채져서, 동작된 다음에, 클라이언트에게 돌려보내진다. 웹 서비스 중개기가 구현될 수 있는 시판중인 제품의 예는 IBM의 Web Service GatewayTM 및 IBM의 Web Service BusTM를 포함한다.
중개기에 의해 제공된 서비스는 타겟 서비스에 대한 요청의 소스의 인증, 내용(content)에 대한 그리고 형식(form)에 대한 메시지 확인, 및 감사(auditing) 목적을 위한 메시지 로깅(logging)을 포함한다. 중개기는 관리 보고 서비스, 웹 서비스 히트(hit)의 수, 및 개별 클라이언트에 의해 사용된 서비스의 수량 및 타이밍 등등을 제공할 수 있다. 중개기는 예를 들어, 새로운 스토리와 같은 자주 변경되지만 자주 요청된 데이터를 저장함으로써 개선된 성능 지원시 캐시로서 사용될 수 있다. 중개기는 한산한 서비스 시간 동안에, 부하 균형을 맞추고, 몇몇 클라이언트로부터의 서비스 요청을 저장하며, 타겟 서비스로 그것을 전송한다는 점에서 성능 개선을 위해 사용될 수 있다. 중개기는 예를 들어, 다음에 지불 계정, 수취 계정을 위한 분리된 타겟 서비스들, 및 일반 원장(ledger) 서비스들에 전송되는 계정 포스팅에 대한 요청을 받아들이는 회계(accounting) 중개기로서 서비스들을 수집할 수 있다.
종래 기술에서는, 웹 서비스 중개기들이 그들의 타겟 서비스에 밀접하게 결합되도록 웹 서비스 중개기들을 구현하는 것이 일반적이다. 즉, 특정 중개기는 특정 타겟 웹 서비스에만 중개기 서비스를 제공한다. 이것의 필요성은, 예를 들어 중개기가 메시지 확인을 제공하고, 따라서 적절한 메시지 내용 및 형식에 관한 정확한 지식을 가져야 할 때 명백하다. 웹 서비스의 전문용어에서, 한 그룹의 오퍼레이션(operation)은 "포트 타입(port type)"이라 칭해진다. 이 용어에서, 밀접한 결합의 제한은 종래 기술에서 그것을 일반적인 것으로 나타내는데, 중개기 서비스, 및 이 중개기 서비스에 의해 제공된 모든 타겟 서비스는 동일한 포트 타입을 가지곤 했다. 그러나, 중개기 서비스가, 포트 타입에 상관없이, 예를 들어 임의의 타겟 서비스로 향한 메시지 상에 정확하게 동일한 인증 기능을 제공하도록 되어 있는 클라이언트 식별정보 인증 기능과 같이 포트 타입들 전반에서 기능하는 것이 유익한 상황들이 있다. 종래 기술은 그러한 경우에 구성 복잡도를 강제로 추가시키고, 웹 서비스 중개기에 있어서의 계속적인 개선의 필요성이 있다.
본 발명의 양호한 실시예는 단지 예시적으로 다음 도면을 참조하여 이제 설명될 것이다.
도 1a 및 1b는 웹 서비스 중개기를 위한 포트 타입 어그노스틱 프록시 지원이 본 발명의 실시예에 따라 구현될 수 있는 웹 서비스를 위한 예시적인 아키텍처의 선도(line drawing)를 나타낸 도면이다.
도 2a는 본 발명의 실시예에 따른 예시적인 중개기의 블럭도의 선도를 나타낸 도면이다.
도 2b는 본 발명의 실시예에 따라 SOAP-HTTP 채널을 구현하는 예시적인 중개기(202)의 블럭도의 선도를 나타낸 도면이다.
도 3은 제1 실시예에 따른, 웹 서비스 중개기를 위한 포트 타입 어그노스틱 프록시 지원의 방법을 도시한 플로우차트이다.
도 4는 제2 실시예에 따른, 웹 서비스 중개기를 위한 포트 타입 어그노스틱 프록시 지원의 방법을 도시한 플로우차트이다.
도 5는 제2 실시예에 따른, 요청이 동기 응답을 요구할 때 타겟 서비스로부터의 응답을 기다리는(316) 방법을 도시한 플로우차트이다.
제1 실시양상에 따르면, 웹 서비스 중개기를 위한 포트 타입 어그노스틱 프록시 지원의 방법이 제공되는데, 이 방법은 웹 서비스들 오퍼레이션(operation)의 실행에 대한 요청을 웹 서비스들 중개기 내에서 수신하는 단계 - 요청은 오퍼레이션을 지원하는 타겟 서비스의 종단점이 식별될 수 있는 파라메트릭(parametric) 정보를 포함함-; 파라메트릭 데이터에 의존하여, 오퍼레이션을 지원하는 타겟 서비스의 종단점을 식별하는 단계; 타겟 서비스 상의 오퍼레이션의 실행에 대한 타겟 서비스 요청을 생성하는 단계; 및 타겟 서비스 요청을 상기 타겟 서비스에 송신하는 단계를 포함한다.
한 실시예에서, 요청이 동기 응답을 요구하는 지의 여부가 판정되고, 요청이 동기 응답을 요구하면 타겟 서비스로부터 응답을 기다린다.
전형적인 실시예에서, 요청이 동기 응답을 요구하는 지의 여부를 판정하는 것은 파라메트릭 정보에 의존하여, 요청이 동기 응답을 요구하는 지의 여부를 판정함으로써 실행된다. 전형적인 실시예에서, 타겟 서비스 상의 오퍼레이션의 실행에 대한 타겟 서비스 요청을 생성하는 단계는 요청이 동기 응답을 요구하는지 여부의 판정에 의존하여 타겟 서비스 요청을 생성하는 단계를 포함한다. 동기 응답을 요구하지 않는 요청의 경우, 몇몇 실시예는 타겟 서비스 요청의 확인응답(ACK)을 타겟 서비스로부터 수신하는 단계; 및 응답 메시지를 기다리지 않고 확인응답을 요청기에게 돌려보내는 단계를 포함한다.
동기 응답을 요구하지 않는 요청의 경우, 몇몇 실시예는 타겟 서비스로부터의 응답을 중개기 내에서 동기적으로 수신함으로써 타겟 서비스로부터의 응답을 기다리는 단계; 중개기 내에서, 타겟 서비스로부터의 응답에 의존하여, 중개기로부터의 응답을 생성하는 단계; 및 중개기로부터의 응답을 요청기에게 돌려보내는 단계를 구현한다. 전형적인 실시예에서, 타겟 서비스로부터의 응답을 중개기 내에서 동기적으로 수신하는 단계는 중개기와 타겟 서비스 사이의 데이터 통신들 접속 상에서 블록킹(blocking) 수신 기능을 호출함으로써 실행된다.
다수의 실시예에서, 생성되어 타겟 서비스로 송신된 타겟 서비스 요청은 웹 서비스들 중개기 내에 수신된 요청의 검사되지 않고 변경되지 않은 메시지 내용들을 포함한다. 예시적인 실시예는 전형적으로, 타겟 서비스로부터의 응답을 중개기 내에서 수신하고; 중개기 내에서, 타겟 서비스로부터의 응답에 의존하여, 중개기로부터의 응답을 생성하며; 중개기로부터의 응답을 요청 클라이언트에 돌려보내는 요청-응답 프로세싱의 복귀 경로를 또한 포함한다.
본 발명의 전형적인 실시예는 오퍼레이션을 지원하는 종단점으로서 웹 서비스들 중개기의 종단점을 요청기에게 확인하는 단계를 더 포함한다. 그러한 실시예에서, 파라메트릭 정보는 오퍼레이션에 대한 포트 타입을 종종 포함한다. 또한, 오퍼레이션을 지원하는 타겟 서비스의 종단점을 파라메트릭 정보에 의존하여 식별하는 단계는 파라메트릭 정보에 의존하여, 오퍼레이션을 지원하는 타겟 서비스들의 다수의 종단점들을 식별하는 단계; 및 선택 규칙들에 따라 다수의 종단점들로부터 하나의 종단점을 선택하는 단계를 더 포함한다. 오퍼레이션을 지원하는 타겟 서비스들의 다수의 종단점들을 식별하는 단계는 포트 타입에 의존하여, 포트 타입에 대한 다수의 타겟 서비스들을 레지스트리(registry)로부터 식별함으로써 실행될 수 있다. 다수의 종단점들로부터 하나의 종단점을 선택하는 단계는 타겟 서비스들 사이의 부하 균형을 위해 선택 규칙들에 따라 다수의 종단점들로부터 하나의 종단점을 선택하는 단계를 포함할 수 있다.
타겟 서비스 상의 오퍼레이션의 실행에 대한 타겟 서비스 요청을 생성하는 단계는 바인딩-뉴트럴(binding-neutral) 인터페이스에서 유용한 데이터 구조로 상기 요청을 구성하고, 바인딩-뉴트럴 인터페이스를 호출하여 요청을 호 파라미터로서 보냄으로써 실행될 수 있다. 타겟 서비스 요청을 타겟 서비스로 송신하는 단계는 바인딩-뉴트럴 인터페이스 내의 하나 이상의 멤버 메소드들(member methods)을 호출하는 단계를 포함할 수 있다.
제2 실시양상에 따르면, 본 발명은 웹 서비스 중개기들을 위한 포트 타입 어그노스틱 프록시 지원을 위한 시스템을 제공하는데, 이 시스템은 웹 서비스들 오퍼레이션의 실행에 대한 요청을 웹 서비스들 중개기 내에서 수신하는 수단 - 요청은 오퍼레이션을 지원하는 타겟 서비스의 종단점이 식별될 수 있는 파라메트릭 정보를 포함함-; 파라메트릭 데이터에 의존하여, 오퍼레이션을 지원하는 타겟 서비스의 종단점을 식별하는 수단; 타겟 서비스 상의 오퍼레이션의 실행에 대한 타겟 서비스 요청을 생성하는 수단; 및 타겟 서비스 요청을 상기 타겟 서비스에 송신하는 수단을 포함한다.
제3 실시양상에 따르면, 웹 서비스 중개기들을 위한 포트 타입 어그노스틱 프록시 지원을 위한 컴퓨터 프로그램 제품이 제공되는데, 이 컴퓨터 프로그램 제품은 기록 매체; 웹 서비스들 오퍼레이션의 실행에 대한 요청을 웹 서비스들 중개기 내에서 수신하기 위한, 기록 매체 상에 기록된 수단 - 요청은 오퍼레이션을 지원하는 타겟 서비스의 종단점이 식별될 수 있는 파라메트릭 정보를 포함함-; 파라메트릭 데이터에 의존하여, 오퍼레이션을 지원하는 타겟 서비스의 종단점을 식별하기 위한, 기록 매체 상에 기록된 수단; 타겟 서비스 상의 오퍼레이션의 실행에 대한 타겟 서비스 요청을 생성하기 위한, 기록 매체 상에 기록된 수단; 및 타겟 서비스 요청을 타겟 서비스에 송신하기 위한, 기록 매체 상에 기록된 수단을 포함한다.
본 발명은 컴퓨터 소프트웨어로 구현될 수 있다.
본 발명은 이 명세서에서 대부분, 웹 서비스 중개기를 위한 포트 타입 어그노스틱 프록시 지원을 위한 방법과 관련하여 설명된다. 그러나, 본 분야에 숙련된 기술자들은 개시된 방법에 따라 동작하는 적합한 프로그래밍 수단을 포함하는 임의의 컴퓨터 시스템도 본 발명의 범위에 속한다는 것을 알 수 있을 것이다. 적합한 프로그래밍 수단은, 예를 들어 컴퓨터 메모리에 연결된 연산-논리 회로 및 프로세싱 유닛으로 이루어진 시스템들을 포함하여, 컴퓨터 시스템에게 본 발명의 방법의 단계들을 실행하라고 명령하는 임의의 수단을 포함하는데, 상기 시스템들은 컴퓨터 메모리 내에 저장하는 능력을 갖고 있고, 컴퓨터 메모리는 프로세싱 유닛에 의해 실행하기 위한 본 발명의 방법의 프로그램된 단계들과, 데이터 및 프로그램 명령어를 저장하도록 구성된 전자 회로를 포함한다.
본 발명은 또한 임의의 적합한 데이터 프로세싱 시스템과 함께 사용하기 위해 디스켓 또는 그외 다른 기록 매체와 같은 컴퓨터 프로그램 제품으로 구현될 수 있다. 컴퓨터 프로그램 제품의 실시예는 자기 매체, 광 매체 또는 그외 다른 적합한 매체를 포함하여, 기계-판독가능 정보를 위한 임의의 기록 매체의 사용에 의해 구현될 수 있다. 본 분야에 숙련된 기술자들은 적합한 프로그래밍 수단을 갖는 임의의 컴퓨터 시스템이 프로그램 제품으로 구현된 본 발명의 방법의 단계들을 실행할 수 있을 것이라는 것을 바로 알 수 있을 것이다. 본 분야에 숙련된 기술자들은 이 명세서에서 설명된 대부분의 예시적인 실시예가 컴퓨터 하드웨어 상에 설치되어 실행되는 소프트웨어에 관한 것이지만, 그럼에도 불구하고, 펌웨어 또는 하드웨어로서 구현된 대안적인 실시예가 또한 본 발명의 범위 내에 속한다는 것을 바로 알수 있을 것이다.
정의
"비즈니스 레지스트리(business registry)"는 이 용어가 이 명세서에서 사용되는 바와 같이, 비즈니스 및 이 비즈니스에 의해 제공된 웹 서비스의 리스팅(listing)을 포함하는 웹 서비스의 인터넷 디렉토리이다. 웹 서비스의 리스팅은 지원된 오퍼레이션, 포트 타입, 종단점(endpoint), 바인딩(binding) 등등을 포함한다. 몇몇의 비즈니스 레지스트리는 ebXML과 같은 개방 표준안에 기초하고, 몇몇은 UDDI와 같은 기업 협회가 선도하는 규격서에 기초한다. 비즈니스는 레지스트리에 그들 자신을 등록할 수 있다. 비즈니스는 레지스트리를 통해 공유될 자료를 제출할 수 있고, 레지스트리 클라이언트는 다른 비즈니스들이 제출한 자료를 검색할 수 있다. 비즈니스 레지스트리는 브라우저를 통해 수동으로, 또는 그들 자신이 웹 서비스일 수 있는 API들을 통해 프로그램으로 액세스되고 검색될 수 있다. 레지스트리는 비즈니스들이 느슨하게 결합된 방식으로 동적으로 서로 협력하게 할 수 있기 때문에 웹 서비스의 점점 더 중요한 컴포넌트가 되고 있다.
HTTP는 웹 상에서 가장 일반적인 데이터 통신 프로토콜인 "HyperText Transfer Protocol(하이퍼텍스트 전송 프로토콜)"을 의미한다. 하지만, 이 명세서에서, "웹"이라는 용어는 HTTP 통신에 한정되는 것이 아니라, HDTP(Handheld Device Transfer Protocol) 또는 WAP(Wireless Access Protocol) 및 본 분야에 숙련된 기술자들에게 생각날 수 있는 기타 프로토콜과 같은 유사한 통신 모드들을 지원하는 다른 프로토콜과의 통신을 포함할 수도 있다.
"SOAP"는 웹 서비스 요청 및 응답 메시지를 네트워크를 통해 보내기 전에 인코딩하기 위해 사용된 가벼운 XML 기반의 메시징 프로토콜인 "Simple Object Access Protocol(단순 객체 액세스 프로토콜)"을 의미한다. SOAP 메시지는 임의의 운영 체계 또는 프로토콜에 독립적이어서, SMTP, MIME 및 HTTP를 포함하는 여러가지 인터넷 프로토콜을 사용하여 전달될 수 있다.
"UDDT"는 종래의 전화번호부의 노란색 및 흰색 페이지와 유사하게, 비즈니스가 인터넷 상에 그들자신을 리스팅할 수 있게 하고 서로 발견할수 있게 하는 웹 기반의 분산 디렉토리인 "Universal Description, Discovery and Integration(범용 설명, 발견 및 통합)"을 의미한다.
"WSDL"은 "Web Services Description Language(웹 서비스 설명 언어)"를 의미한다. WSDL은 마이크로소프트와 IBM에 의해 공동으로 개발된 XML-포맷된 언어이고, 메시지를 교환할 수 있는 통신 종단점들의 모음으로서 웹 서비스의 능력을 설명하기 위해 사용된다. WSDL은 UDDI가 웹 서비스의 능력을 설명하기 위해 WSDL을 사용하는 UDDI의 통합 부분이다.
"ebXML"은 전자상거래를 용이하게 하기 위해 XML로 웹 서비스의 설명을 표준화하기 위한 스펙의 모듈러 슈트(modular suit)인 "electronic business Extensible Markup Language(전자 비즈니스 확장성 생성 언어)"를 의미한다. UDDI와 마찬가지로, ebXML 스펙은 웹 서비스를 규정하고 등록하는 표준 방법을 비즈니스에게 제공한다.
이러한 스펙은 일반적으로, WSDL의 용어와 유사한 용어로 웹 서비스의 컴포넌트를 설명한다. 웹 서비스는 메시지를 교환할 수 있는 데이터 통신의 종단점인 네트워크 종단점의 모음으로서 설명된다. 종단점은 때때로 "포트"로 칭해진다. 그러나, 이 명세서에서, 일반적으로 "종단점"이라는 용어는 "포트 타입"이라는 용어와 혼동할 위험을 줄이기 위해 "포트"보다 바람직하다. 포트 타입은 포트의 타입 또는 종단점의 타입이 아니다. 포트 타입은 "오퍼레이션", 즉 서비스에 의해 지원된 소프트웨어 액션 또는 기능의 모음이다.
포트 타입에 대한, 특정 통신 프로토콜 및 데이터 포맷 스펙은 "바인딩"을 구성한다. 바인딩의 한 예로는 SOAP/HTTP가 있는데, 메시지 데이터는 SOAP에 따라 인코딩되고, 메시지는 HTTP에 따라 종단점들 사이에서 통신된다. 바인딩의 다른 예는 GET/POST/HTTP가 있는데, 메시지 데이터는 GET 또는 POST 메시지로 인코딩되고, 데이터 통신은 HTTP에 따라 실행된다.
각각의 포트 타입은 하나보다 많은 바인딩을 가질 수 있다. 하나의 종단점은 네트워크 주소를 바인딩과 연관시킴으로써 규정되고, 상술된 바와 같이, 종단점의 모음은 서비스를 규정한다. 웹 서비스에서 오퍼레이션 요청 및 데이터의 통신은, 이번에는 "파트(part)들"로 구성되는 "메시지들"이라고 하는 데이터 구조들을 통해 실행된다. "요청" 및 "응답"이라는 용어는 일반적으로 메시지 흐름 방향의 표시이다. 특정 바인딩을 위한 요청 메시지 및 응답 메시지는 동일한 구조를 가질 수 있다.
웹 서비스 중개기를 위한 포트 타입 어그노스틱 프록시 지원
첨부 도면을 참조하여, 웹 서비스 중개기를 위한 포트 타입 어그노스틱 프록시 지원을 위한 방법, 시스템 및 제품에 대해 도 1a 및 도 1B부터 참조를 시작하여 설명된다. 도 1a는 웹 서비스를 위한 포트 타입 어그노스틱 프록시 지원이 본 발명의 실시예에 따라 구현될 수 있는 웹 서비스를 위한 예시적인 아키텍처의 선도를 나타낸 것이다. 도 1a의 아키텍처에서, 중개기(202)는 프로토콜을 통해 요청기(requester)(102) 및 타겟 서비스(118)로의 데이터 통신을 위해 접속할 수 있다. 요청기(102) 입장에서의 웹 서비스 컴포넌트는 때때로 클라이언트로 칭해진다. 이와 마찬가지로, 중개기(202) 입장에서의 컴포넌트는 특히 요청기 시점에서 바라보았을 때, 때때로 서버라 칭해진다.
클라이언트/서버 구별은 웹 서비스와 관련하여 신중하게 사용되어야 한다. 도 1B의 아키텍처에서, 예를 들어, 요청기(102)로부터의 요청에 대한 응답을 준비하는 과정에서, 타겟 서비스(118)는 이번에는 중개기(203)를 통해 타겟 서비스(119)로부터 웹 서비스를 요청할 수 있다. 그렇게 할 때는, 타겟 서비스(118)가 클라이언트로서 동작한다. 타겟 서비스(118)로 요청을 전송할 때의 중개기(202)는 클라이언트로서 동작한다. 특정 컴포넌트가 임의의 특정 시기에 클라이언트 또는 서버로 간주되는 지의 여부는 그 시기에 컴포넌트에 의해 실행되는 특정 기능에 따라 좌우된다. 즉, 웹 서비스 컴포넌트는 잠깐동안은 클라이언트일 수 있고, 그 다음에는 서버일 수 있다. 그러므로, 용어로부터 혼동할 위험을 줄이기 위해, 웹 서비스 컴포넌트는 일반적으로 이 명세서에서, "클라이언트" 또는 "서버"보다는 "요청기", "중개기" 및 "타겟 서비스"라는 용어를 사용하여 설명된다.
중개기(202)가 타겟 서비스(118)를 위해 중개기 서비스를 제공하기 위해서는, 중개기(202)가 타겟 서비스(118) 상의 종단점을 알아야 한다. 상술된 바와 같이, 종래 기술에서, 중개기(202) 상에서 실행되는, "프록시"라고 불리우는 서비스는 타겟 서비스(118)와 동일한 포트 타입을 지원할 수 있고, 타겟 서비스(118)에 대한 종단점을 그것의 구성 데이터 내에 가질 수 있다. 그러나, 도 1의 아키텍처에서, 프록시는 'port type agnostic(포트 타입 어그노스틱)'이고, 이것은 프록시에 이용가능한 어떤 구성 데이터도 타겟 서비스의 종단점을 설명하지 못하고, 요청기(102)가 중개기에게 전혀 알려지지 않은 포트 타입 내의 오퍼레이션에 대한 요청을 제출할 수 있다는 것을 의미한다.
도 2A는 본 발명의 실시예에 따른 예시적인 중개기(202)의 블럭도의 선도를 나타낸 것이다. 중개기(202)는 최소한 하나의 중앙 처리 장치, 컴퓨터 메모리, 시스템 버스 등을 포함하는 컴퓨터 시스템인 자동화 컴퓨팅 기계를 포함한다. 도 2A의 블럭도 내의 블럭은 중개기(202)의 컴퓨터 시스템에서 동작가능한 소프트웨어 응용 모듈을 나타낸다. 도 2A의 화살표는 소프트웨어 모듈들 사이의 데이터 흐름을 나타낸다.
중개기(202)는 웹 서비스 동작의 실행을 위해, 파라메트릭 정보(107)를 포함하는 요청(106)을 요청기(102)로부터 수신할 수 있는 인바운드(inbound) 엔진(208)을 포함한다. 다음은 SOAP-HTTP 바인딩에 대한 그러한 요청의 한 예이다:
이러한 예시적인 POST 메시지는 중개기로부터 'myOp' 오퍼레이션을 요청하는 SOAP 엔벨로프를 포함한다. 즉, 타겟 서비스(118) 상에서 실행될 오퍼레이션의 이름은 soap 메시지 내에서 내부적으로 식별된다. myOp 오퍼레이션, 그것의 포트 타입, 및 그 종단점은 요청이 수신되기 전에는 중개기에게 전혀 알려져 있지 않다. 이 예에서, 오퍼레이션을 지원하는 타겟 서비스(118)의 종단점이 식별될 수 있는 파라메트릭 정보(107)는 POST:"portType=A"의 제1 라인 내의 URI-인코딩된 조회 문자열의 이름-값 쌍으로 설명된다.
제2 실시예에서, 예시적인 요청의 제1 라인은 다음을 판독해야 한다:
POST/Channel/proxy?portType=A&synchRespReqd=True HTTP/1.1
이 제2 실시예에서, 파라메트릭 정보는 요청이 동기 응답을 요구하는 지의 여부를 본 발명의 실시예에 따른 포트 타입 어그노스틱 프록시가 판정할 수 있는 이름 값 쌍 "synchRespReqd=True"를 포함한다.
웹 서비스를 위해, 파라메트릭 정보(107)를 포함하는 요청(106)을 요청기(102)로부터 수신하는 것 이외에, 인바운드 엔진(208)은 또한 그것의 파라메트릭 데이터를 포함하는 요청을 포트 타입 어그노스틱 프록시(212)에 제공하는 능력을 갖는다. 인바운드 엔진 동작의 한 예로서, 바로 앞에서 설명된 예시적인 요청을 고려해보자. 그 예시적인 요청은 SOAP-HTTP로서 바인드된다. 그러므로, 이 예시적인 요청의 경우에, 인바운드 엔진은 SOAP-인에이블드 HTTP 서버일 수 있는데, 이 서버는, 예를 들어 자바 빈(Java Bean), 자바 서블릿(Java servlet), 또는 펄(Perl)로 기입된 CGI(Common Gateway Interface) 스크립트를 포함하여, 서버형 애플리케이션의 임의의 종류로서 구현된 프록시(212)에게 착신 요청을 넘긴다. 자바 서블릿 및 CGI 스크립트는 단지 설명을 위해 언급되는 것이지, 제한하기 위한 것은 아니다. 본 발명의 범위 내에서, 본 분야에 숙련된 기술자들에게 생각날 수 있는 임의의 종류의 서버측 기능은 웹 서비스 중개기를 위한 포트 타입 어그노스틱 프록시 기능을 구현하기 위해 사용될 수 있다.
포트 타입 어그노스틱 프록시(212)는 오로지 포트 타입 어그노스틱 프록시로서만 동작하도록 하드 코드화될 수 있고, 또는 대안적으로, 포트 타입 어그노스틱 프록시(212)는 구성 파라미터(223)에 의존하여 형식상으로 동작할 수 있다. 구성 파라미터는 포트 타입 어그노스틱 프록시(212)가 종래의 중개기 서비스로서 동작할 것인지, 또는 포트 타입 어그노스틱 모드로 동작할 것인지 나타내기 위해 제공될 수 있다. 그러한 구성 파라미터는 특히 양쪽 모드에서 이용될 수 있는 코드 세그먼트의 재사용을 포함하는 효율적인 프로그램 코딩을 유리하게 촉진한다. 프로그램 코드의 효율적인 사용을 지원하는 다른 구성 파라미터는 프록시를 위한 바인딩 또는 '채널 유형'을 식별하는 파라미터이다. 더욱 상세하게 후술되는 바와 같이, 포트 타입 어그노스틱 프록시는 웹 서비스, SOAP, MIME, GET/POST/HTTP 등등에 의해 지원된 임의의 바인딩으로 동작할 수 있다. 포트 타입 어그노스틱 프록시는 임의의 바인딩 또는 채널 유형으로 동작하도록 코딩된 다음에, 프록시에게 실시간 동작을 위한 그것의 바인딩 또는 채널 유형을 알려주는 파라미터로 구성될 수 있다. 또한, 구성 파라미터는 요청 또는 응답 메시지의 내용의 구문분석을 요구할 수 있는 프록시 내의 임의의 중개기 서비스를 턴온 또는 턴오프하도록 제공될 수 있다. 그러한 파라미터는 메시지 내용의 구문분석이 중개기 성능을 느리게 하는 경향을 갖기 때문에 성능을 최적화하도록 유리하게 사용될 수 있다. 다른 중개기 서비스뿐만 아니라 다수의 포트 타입 어그노스틱 프록시는 중개기(202) 내에서 동시에 동작할 수 있고, 각각에 대한 이름은 구성 파라미터로서 할당될 수 있다. 메시지 핸들러 및 필터는 구성 파라미터가 프록시에 할당될 수 있다. 이 파라그래프는 제한하기 위해서가 아니라 설명을 위해서, 포트 타입 어그노스틱 프록시용의 몇가지 구성 파라미터를 설명한다. 본 발명의 숙련된 기술자들에게 생각날 수 있는 임의의 구성 파라미터의 사용 또한 본 발명의 범위 내에 속한다.
도 2B는 본 발명의 실시예에 따른 SOAP-HTTP 채널을 구현하는 예시적인 중개기(202)의 블럭도의 선도를 나타낸 것이다. 설명된 바와 같이, SOAP 바인딩으로의 요청을 위해, 파라메트릭 데이터를 포함한 요청을 포트 타입 어그노스틱 프록시(212)에 제공할 수 있는 인바운드 엔진(208)은 SOAP-인에이블드 HTTP 서버로서 구현될 수 있다. 그러한 인바운드 엔진은 프록시를 위한 SOAPHandler 객체(210)들에 대한 다수의 레퍼런스로 구성될 수 있고, 각각의 SOAPHandler 객체(210)는 프록시 요청에 관한 소정의 데이터 프로세싱 태스크를 제공하도록 구성된다. 그러한 인바운드 엔진은 전형적으로, SOAPContext 객체(209) 내의 그 파라메트릭 정보와 함께 착신 요청을 캡슐화하고, SOAPContext 객체에 대한 레퍼런스를 차례로 프록시용으로 구성된 각각의 SOAPHandler(210)에 보낸 다음에, SOAPContext(209)를 전체적으로 프록시(212)에 보냄으로써 동작한다. 일반적으로 보아서, 그것은 종단점을 식별하는 포트 타입 어그노스틱 프록시가지만, 상세한 구현 레벨은 SOAP의 경우에서처럼, 핸들러 내의 프록시 기능을 포함할 수 있다. 즉, 착신 엔진은 SOAP/HTTP의 경우에 URL인 타겟 서비스의 종단점으로 설정될 수 있는 SOAPContext의 특성을 설정할 수 있다. 그러한 실시예에서, SOAPHandler 객체(210)들 중의 하나는 보통, 요청으로부터 파라메트릭 정보를 추출하여 그것을 SOAPContext 내의 이름-값 쌍에 배치하도록 프로그램될 수 있으므로, 프록시는 요청된 웹 서비스 동작을 지원하는 타겟 서비스(118)에 대한 종단점을 식별하기 위해 그것을 사용할 수 있다.
대안적으로, 착신 요청은 SOAP보다는 GET/HTTP로 바인드될 수 있다. 그러한 한 예에서, 프록시(도 2A 상의 212)는 자바 서블릿으로 구현될 수 있다. 인바운드 엔진(208)은 그것의 파라메트릭 정보를 포함한 요청을 HTTPServletRequest 객체 내에 캡슐화하고 그 HTTPServletRequest 객체에 대한 레퍼런스를 프록시에 제공하는 자바-인에이블드 HTTP 서버로서 구현될 수 있다. 그 다음, 프록시는 요청 URL로부터의 조회 문자열, 즉 의문 부호 뒤의 요청 URL 내의 모든것을 되돌려보내는, HTTPServletRequest.getQueryString()에 대한 호출을 통해 파라메트릭 정보를 얻을 수 있다. 전체 조회 문자열을 갖고 있으므로, 그러한 예시적인 프록시는 조회 문자열로부터 파라메트릭 데이터, 즉 이 예에서 "portType=A"를 추출하고, 요청된 웹 서비스 동작을 지원하는 타겟 서비스(118)에 대한 종단점을 식별하기 위해 그렇게 추출된 정보를 사용하도록 프로그램된다. 요청된 웹 서비스 동작을 지원하는 타겟 서비스의 종단점을 프록시가 식별할 수 있는 한가지 방법은 UDDI 레지스트리 또는 ebXML 레지스트리와 같은 비즈니스 레지스트리(211)로부터 종단점 설명을 검색하는 것이다. 타겟 서비스(118)는 전형적으로, 예를 들어 WSDL 문서로 표현된 설명을 포함하는 그러한 설명을 비즈니스 레지스트리(211) 내에 등록함으로써(224) 그러한 설명을 생성한다.
SOAP 기반의 웹 서비스에서, SOAP 메시지 자체는 오퍼레이션의 이름, 및 오퍼레이션에 대한 파라미터를 포함하는데; 그들은 종단점 URL 내에 없다. 중개기가 portType 파라미터와 같은 파라메트릭 정보를 수신하는 것이 유용하다. 그 파라미터는 portType의 이름과 같이 단순한 어떤 것일 수 있다. 그러한 경우라면, 서버 내에서(예를 들어, 핸들러 내에서, 또는 심지어 프록시 기능 자체에서) 실행되는 소정의 '비즈니스 로직'은 포트 타입 또는 다른 파라메트릭 정보에 기초하여 타겟 서비스(118)의 종단점 URL을 선택해야 한다. 파라메트릭 정보는 심지어 실제 종단점 URL을 포함할 수 있다. 그 경우에, '비즈니스 로직'은 최종적으로 요청을 그 URL에 보낼 수 있다. 포트 타입 및 종단점 URL 둘다는 파라메트릭 정보 내에 있을 수 있고, 그러면 '비즈니스 로직'은 종단점 URL을 결정하고자 시도할 수 있고, 그보다 나은 것이 더 이상 발견되지 않으면 디폴트로서 요청시의 것을 사용할 수 있다. 본 발명은 양호하게, 비즈니스 로직에 의해 제어될 수 있는 3개 모두의 시나리오뿐만 아니라 임의의 변형들을 허용한다. '비즈니스 로직'의 제어를 돕는 그외 다른 파라미터들이 항상 있을 수 있다.
이 명세서는 SOAP/HTTP 바인딩과 관련하여, 때때로 GET/POST/HTTP 바인딩과 관련하여 예시적인 바인딩을 설명하는 경향이 있지만, 이들 예시적인 바인딩의 설명은 설명의 편의를 위한 것이지, 제한하고자 하는 것은 아니다. 본 발명의 여러 실시예에 따라 유용한 대안적인 예시적인 바인딩은 MIME/SMTP(Multipart Internet Mail Extensions over the Small Message Transport Protocol) 및 RMI/IIOP(Java's Remote Method Invocation over the Common Object Request Broker Architecture's Internet Inter-ORB Protocol)를 포함한다. 실제로, 임의의 자바 클래스는 액세스 프로토콜로서 원시 자바 호출을 갖는 웹 서비스로서 취급될 수 있고, 본 분야에 숙련된 기술자들에게 생각날 수 있는 임의의 다른 바인딩의 포트 타입 어그노스틱 프록시에서의 사용도 또한 양호한 실시예에 따른 본 발명의 범위 내에 속한다.
도 2A의 예시적인 중개기(202)에서, 프록시(212)는 요청기 인증, 메시지 확인, 메시지 로깅, 관리 보고 서비스 등등을 위해 설계되는 어떤 중개기 서비스라도 실행하고, 요청된 동작을 지원하는 타겟 서비스(118)의 종단점을 식별하며, 그 다음에 바인딩-뉴트럴(neutral) 인터페이스(218)를 통해 타겟 서비스에 요청을 전송하는 포트 타입 어그노스틱 프록시가다. 더욱 상세하게 후술되는 바와 같이, 바이딩-뉴트럴 인터페이스(218)는 사용 형식이 요청 바인딩에 의존하지 않는 인터페이스이다.
도 2A의 예시적인 중개기(202)에서, 바인딩-뉴트럴 인터페이스(218)는 요청(106)을 타겟 서비스(118)에 전송하기 위해 이번에는 아웃바운드(outbound) 엔진(222)을 호출하는 제공자(220)를 동작시킨다. 인터페이스(218)는 프로토콜이 특정된 제공자(220) 내의 코드에 의해 백업되기 때문에 바인딩-뉴트럴 형태로 동작하는 것이 가능하다. 제공자(220)는 특정 프로토콜, SOAP, HTTP 등등의 특성에 따라 실제 메시지 교환을 실행한다. 실제 데이터 통신을 실행하는 제공자로부터의 바인딩-뉴트럴 인터페이스의 분리는 새로운 제공자의 동적 등록을 지원하므로, 중개기는 재컴파일 또는 재배치할 필요없이 자신의 데이터 통신 능력을 향상시킬 수 있다. 제공자는 바인딩-뉴트럴 인터페이스 내에 동적으로 설치된 제공자에 대한 레퍼런스를 갖고, 제공자의 프로토콜에 의해 지원된 타겟 서비스에 의해 흔히 제공된 객체로서 구현될 수 있다. 아웃바운드 엔진(222)은 제공자(222)에 의해 구현된 프로토콜을 위한 실제 데이터 통신 엔진이다. 예를 들어, 프로토콜이 SOAP/HTTP로서 취해질 때, 아웃바운드 엔진은 타겟 웹 서비스로/로부터 SOAP/HTTP 요청 및 응답 메시지를 송/수신할 수 있는 SOAP/HTTP 엔진이다. 예를 들어, 프로토콜이 HTTP일 때, 아웃바운드 엔진은 웹 브라우저의 데이터 통신 모듈과 유사하게, HTTP 데이터 통신 클라이언트 모듈이다.
중개기 서비스를 제공하기 위해, 중개기는 요청의 종단점을 유리하게 식별할 수 있다. 그렇게 하기 위한 방법은 도 3을 참조하여 설명된다. 도 3은 웹 서비스 오퍼레이션의 실행에 대한 요청(106)을 웹 서비스 중개기 내에서 수신하는 단계(104)를 포함하는 웹 서비스 중개기를 위한 포트 타입 어그노스틱 프록시 지원의 방법을 도시한 플로우차트를 나타낸 것으로, 요청은 동작을 지원하는 타겟 서비스의 종단점이 식별될 수 있는 파라메트릭 정보(107)를 포함한다.
또한, 다음은 SOAP-HTTP 바인딩에 대한 그러한 요청의 한 예이다:
이 예시적인 POST 메시지는 중개기로부터 'myOp' 오퍼레이션을 요청하는 SOAP 엔벨로프를 포함한다. myOp 오퍼레이션, 그것의 포트 타입 및 그것의 종단점은 요청이 수신되기 전에는 중개기에게 모두 알려져 있지 않다. 이 예에서, 메시지는 SOAP 엔벨로프로서 취해지고, 오퍼레이션을 지원하는 타겟 서비스의 종단점이 식별될 수 있는 파라메트릭 정보(107)는 HTTP 파라미터 "portType=A"이다. 이 예에서, 타겟 서비스 상의 오퍼레이션의 이름이 SOAP 엔벨로프 내에 미리 인코딩되기 때문에, 추가될 유일한 파라메트릭 데이터는 타겟 서비스 상의 오퍼레이션을 포함하는 포트 타입인 포트 타입 "A"이다.
도 3의 방법은 또한 오퍼레이션을 지원하는 타겟 서비스의 종단점(110)을 파라메트릭 데이터에 의존하여 식별하는 것(108)을 포함한다. 이 SOAP-HTTP 예에서, 오퍼레이션을 지원하는 타겟 서비스의 종단점(110)의 식별(108)은 UDDI 레지스트리 또는 ebXML 레지스트리와 같은 비즈니스 레지스트리로부터 종단점 설명을 검색함으로써 실행된다. 이 예에서, 중개기는 네트워크 주소 http://www.myTarget.com/SOAP-HTTP/servlets/에서 SOAP-HTTP에 의해 연결되는 것으로 설명된 포트 타입 A의 종단점을 레지스트리로부터 검색한다.
도시된 방법은 타겟 서비스 상의 오퍼레이션의 실행에 대한 타겟 서비스 요청(114)을 생성하는 단계(112)를 포함한다. 이 예에서, 중개기는 타겟 서비스 상의 종단점을 사용하여 HTTP POST 메시지로서 타겟 서비스 요청을 생성하도록 프로그램된다. 종단점을 식별하는 파라메트릭 데이터는 삭제되고, 요청은 SOAP 엔벨로프 내의 오퍼레이션 이름으로부터 오퍼레이션을 그 자신이 식별할, SOAP 메시지를 처리하는 스크립트로 향하게 된다.
그 결과 얻어지는 타겟 서비스 요청은 다음과 같다:
도 3의 방법은 또한 타겟 서비스 요청(114)을 타겟 서비스(118)에 송신하는 단계(116)를 포함한다. 이 예에서, 타겟 서비스 요청의 송신은 http://www.myTarget.com/에서 타겟 서비스 종단점으로의 TCP/IP 접속을 오픈하는 단계, 및 타겟 서비스로의 TCP/IP 접속을 통해 HTTP POST 메시지를 보내는 단계를 포함한다.
본 발명의 최소한 몇몇 실시예에서, 도 3에 도시된 것과 같은 포트 타입 어그노스틱 프록시 지원의 방법에서, 생성되어 타겟 서비스에 송신된 타겟 서비스 요청은 웹 서비스 중개기 내에 수신된 요청의 검사되지 않고 변경되지 않은 메시지 내용을 갖고 있다는 것을 알아차리는 것이 유용하다. 바로 전에 설명된 예에서, 중개기 상의 프록시 서비스는 파라메트릭 데이터 "portType=A"로부터 타겟 서비스의 종단점을 식별했고, 요청기로부터 타겟 서비스로의 전체 전달 과정의 전반을 통해 검사되지 않고 변경되지 않은 상태로 있는 SOAP 엔벨로프인 메시지 본문(body)을 전혀 터치하거나, 오픈하거나, 검사하거나, 구문분석하거나 임의의 다른 방식으로 혼란시키거나 하지 않고, 그렇게 식별된 종단점으로 메시지를 다시 보냈다. 그 과정 중에, 프록시 서비스는 중개기 서비스, 인증, 관리 보고, 부하 균형, 서비스 수집 등등 중의 하나 이상을 제공했다.
더욱 설명을 하기 위해, 예시적인 요청은 GET/HTTP 바인딩으로 나타내지고, http://www.myIntermediary/channelApps/GET-HTTP/servlets/proxy에서 종단점으로 행하게 된다. 예시적인 착신 요청 메시지는 이 형식을 갖는다:
이 예에서, 메시지는 이름-값 쌍으로서 인코딩된 URI-인코드화 조회 데이터 "message=messageContentString"으로서 취해진다. 메시지 내용은 URI-인코드화 문자열이다. 이 예에서, 오퍼레이션을 지원하는 타겟 서비스의 종단점이 식별될 수 있는 파라메트릭 정보(107)는 모두, 메시지 내용 문자열 다음에 오는 조회 데이터이다. 이 예에서, 조회 데이터는 "A"의 포트 타입, 및 타겟 서비스 상의 오퍼레이션의 이름을 둘다 포함한다.
이 예에서, 오퍼레이션을 지원하는 타겟 서비스의 종단점(110)의 식별(108)은 UDDI 레지스트리 또는 ebXML 레지스트리와 같은 비즈니스 레지스트리로부터 종단점 설명을 검색함으로써 실행된다. 이 예에서, 중개기는 네트워크 주소 http://www.myTarget.com에서 GET/HTTP에 의해 바인드된 것으로 설명된 포트 타입 A의 종단점을 레지스트리로부터 검색한다.
도 3의 방법은 또한 타겟 서비스 상의 오퍼레이션의 실행을 위한 타겟 서비스 요청(114)을 생성하는 단계(112)를 포함한다. 이 예에서, 중개기는 타겟 서비스 요청을 위한 종단점 주소를 오퍼레이션 이름 및 메시지 부분과 연결함으로써 HTTP GET 메시지로서 타겟 서비스 요청을 생성하도록 프로그램된다. URI 공간에 표현된, 결과적으로 얻어진 타겟 서비스 요청은 다음과 같다:
http://www.myTarget.com/servlets/myOp?message=messageContentString
도 3의 방법은 또한 타겟 서비스(118)로 타겟 서비스 요청(114)을 송신하는 단계(116)를 포함한다. 이 예에서, 타겟 서비스 요청을 송신하는 단계는 http://www.myTarget.com/에서의 타겟 서비스 종단점으로의 TCP/IP 접속을 오픈하는 단계, 및 다음과 같은 HTTP GET 메시지를 보내는 단계를 포함한다:
GET/servlets/myOp?message=messageContentString HTTP/1.1
본 분야에 숙련된 독자들은 요청기가 타겟 서비스 상의 오퍼레이션에 대한 요청을 중개기에게 보내는 것을 어떻게 알았을까 생각하고 있을 것이다. 그 답은 중개기 또는 중개기의 개발자가 타겟 서비스 상의 오퍼레이션을 지원하는 종단점으로서 웹 서비스 중개기의 종단점을 요청기에게 확인한다는 것이다. 타겟 서비스 상의 오퍼레이션을 지원하는 종단점으로서 중개기의 종단점을 확인하는 단계는 요청기에 의해 발견용 비느지스 디렉토리 내에 등록되는 WSDL 문서로 구현될 수 있다. 대안적으로, 그러한 확인은 중개기로부터 요청기에게로 다운로드되거나, 또는 심지어 단순히 요청기에게 이메일로 보내지거나, 또는 요청기의 웹 서비스 구성 데이터 내의 관리자에 의한 설치를 위해 요청기의 관리자에게 이메일로 보내질 수 있다.
다음과 같은 WSDL 의사코드의 세그먼트에 의해 타겟 서비스가 설명되는 예를 고려해보자:
그 타겟 서비스를 위한 중개기는 다음:
과 같이 타겟 서비스 설명 내에 주소 확장 요소의 위치 속성을 대체하고, 이로 인해, 타겟 서비스 상의 "getQuote" 오퍼레이션을 지원하는 종단점으로서 웹 서비스 중개기의 종단점을 확인하는 다음과 같은 세그먼트에 의해 예시된 WSDL 문서를 생성함으로써, 타겟 서비스 상의 오퍼레이션을 지원하는 종단점으로서 웹 서비스 중개기의 종단점을 요청기에게 확인할 수 있다:
레지스트리, 다운로드, 이메일을 통하거나, 또는 본 분야에 숙련된 기술자들에게 생각날 수 있는 그외 다른 수단에 의해 이 나중의 세그먼트에 의해 예시된 종류의 WSDL의 요청기로의 제공은 타겟 서비스 상의 오퍼레이션을 지원하는 종단점으로서 웹 서비스 중개기의 종단점을 요청기에게 확인한다.
도 3의 방법에서, 오퍼레이션을 지원하는 타겟 서비스의 종단점을 파라메트릭 정보(107)에 의존하여 식별하는 단계(108)는 종종, 타겟 서비스의 단 하나의 종단점이 아니라, 오퍼레이션을 지원하는 타겟 서비스의 2개 이상의 종단점을 식별하는 단계를 포함할 수 있다. 본 발명의 방법의 한 실시예에 따른 포트 타입 어그노스틱 프록시가 파라메트릭 정보(107)로서 오퍼레이션에 대한 포트 타입을 수신하고, 조회 파라미터로서 그 포트 타입을 갖는 비즈니스 레지스트리를 조회함으로써, 오퍼레이션을 지원하는 타겟 서비스의 2개 이상의 종단점을 확인하는 예를 고려해 보자. 2개 이상의 종단점의 그러한 확인은 예를 들어, 그 포트 타입을 갖는 UDDI 레지스트리를 조회하고, 그 포트 타입에 대한 타겟 서비스를 설명하는 2개 이상의 WSDL 문서를 응답시에 수신함으로써 실행될 수 있다.
2개 이상의 종단점이 그렇게 확인될 때, 본 발명의 실시예에 따른 웹 서비스 중개기를 위한 포트 타입 어그노스틱 프록시 지원을 위한 방법은 전형적으로 선택 규칙에 따라 종단점들 중의 하나를 선택하는 단계를 포함한다. 보통의 경우에, 선택 규칙은 그렇게 확인된 종단점들 중의 제1 종단점을 선택하고, 나머지 것들은 무시하도록 될 수 있다. 선택 규칙은 예를 들어, 부하 균형을 위한 선택을 포함하여 더욱 복잡해질 수 있다. 부하 균형을 위한 규칙은 표 1에 도시된 것과 유사한 데이터 구조의 사용에 의해 구현될 수 있다.
지연 추적
포트 타입 종단점 URI 송신 시간 수신 시간 주행(Trip) 지연(ms.) 누적 지연 (ms.)
AAAA------ http:/www.ibm.com /aTargetService http:/www.ibm.com /aTargetService http:/www.ibm.com/anotherTargetService http:/www.ibm.com/anotherTargetService------ 12:01:01.1 12:05:02.3 01:10:01.5 01:15:02.5------ 12:01:01.2 12:05:02.45 01:10:01.57 01:15:02.8------ 1001507030------ 10025070100------
표 1의 각 행은 중개기와 타겟 서비스 사이의 웹 서비스 통신에 있어서 요청-응답 왕복 주행(round trip)에 대한 지연 측정치를 나타낸다. 표 1은 요청 및 응답의 각각의 왕복에 대한 포트 타입 및 종단점 URI의 열을 제공한다. 송신 시간 열은 중개기로부터 포트 타입의 오퍼레이션을 위한 타겟 서비스 상의 종단점으로 송신되는 시간을 기록한다. 수신 시간 열은 대응하는 응답 메시지가 타겟 서비스로부터 수신되는 시간을 기록한다. 주행 지연은 수신 시간과 송신 시간 사이의 차이이다. 누적 지연은 표에 표시된 각 종단점에 대해 진행되는 주행 지연의 합이다. 표 1과 유사한 구조로, 요청을 위한 2개 이상의 종단점이 확인될 때 사용하기 위한 선택 규칙은 다음과 같은 예시적인 규칙으로서 구현될 수 있다:
동일한 포트 내의 오퍼레이션에 대한 더 많은 요청들이 중개기에 도달함
에 따라, 2개 이상의 확인된 종단점들의 각각을 차례로 한번씩 사용한다;
각각의 그러한 사용에 대해 지연 데이터를 기록한다;
동일한 포트 타입의 오퍼레이션에 대한 후속 요청을 위해, 최저 누적 지
연을 갖는 종단점을 지연 표에서 선택하고, 그 종단점으로 요청을 보내
고, 메시지가 타겟 서비스로 보내질 때 및 대응하는 응답이 중개기 내에
수신될 때 적절한 지연 데이터를 기록한다.
표 1에서의 예시적인 데이터는 포트 타입 A가 2개의 종단점, 즉 URI http://www.ibm.com/aTargetService에서의 제1 종단점 및 URI http://www.ibm.com/anotherTargetService에서의 제2 종단점으로 최근에 보낸 요청에 대한 누적 지연을 나타낸다. 처음은 250 밀리초의 누적 요청 지연을 갖고, 두번째는 100 밀리초의 누적 요청 지연을 갖는다. 상술된 예시적인 시나리오를 사용하여, 포트 타입 A 상에서의 오퍼레이션에 대한 현재의 요청은 URI http://www.ibm.com/anotherTargetService에서의 종단점인 제2 종단점으로 라우팅될 수 있다.
도 3의 방법에서, 타겟 서비스 상의 오퍼레이션의 실행에 대한 타겟 서비스 요청(14)을 생성하는 단계(112)는 바인딩-뉴트럴 인터페이스에서 유용한 데이터 구조로 요청을 구성하고, 바인딩-뉴트럴 인터페이스를 호출하여 호 파라미터로서 요청을 보냄으로써 실행될 수 있다. 이와 유사하게, 타겟 서비스로 타겟 서비스 요청(114)을 송신하는 단계(116)는 바인딩-뉴트럴 인터페이스 내의 하나 이상의 멤버 메소드(member method)를 호출하는 단계를 포함한다.
바인딩-뉴트럴 인터페이스는 인터페이스의 사용이 요청 또는 메시지 바인딩에 의존하지 않는 것이다. 즉, 인터페이스를 구현하고 그것을 통해 데이터 통신을 실행하기 위해 사용된 데이터 구조 및 호출 방법은 메시지 내에 사용된 데이터 인코딩의 유형에도 의존하지 않고, 메시지를 위해 사용된 데이터 통신 프로토콜에도 의존하지 않는다. 본 발명의 실시예에 따른 중개기를 위한 포트 타입 어그노스틱 프록시의 개발자는 종종 그들 자신의 바인딩-뉴트럴 인터페이스를 구축할 것이다. 그러나, "WSIF(Web Service Invocation Framework)"로서 공지된 바인딩 -뉴트럴 인터페이스를 위한 개방 표준안이 있다. WSIF는 이제 아파치 소프트웨어 재단의 웹 서비스 프로젝트의 일부로서 지원된다.
바인딩-뉴트럴 인터페이스의 사용은 본 발명의 실시예에 장점을 제공한다. SOAP-HTTP 바인딩은 사용자 및 개발자가 소정의 다른 바인딩이 존재한다는 것을 잊어버릴 만큼 현재의 분야에서 일반적이다. 이것은 다른 바인딩과 함께 사용할 수 없거나 다른 바인딩과 함께 사용하도록 적응할 수 없는 경우에 시스템의 개발을 매우 어렵게 한다. 그러나, 웹 서비스가 성장함에 따라, 다른 바인딩들은 더욱 쓸모있게 되고 더욱 일반적이 될 것이다. 게다가, 본 발명의 실시예의 뒷부분의 바인딩-뉴트럴 인터페이스의 사용은 또한, 이용가능한 바인딩이 런타임시에 결정될 수 있어서, 유연성있고, 강력하며, 더욱 널리 유용한 웹 서비스 중개기를 제공할 수 있다는 것을 의미한다.
바인딩-뉴트럴 인터페이스를 구현하는 한가지 방법은 포트 타입 및 종단점이 주어지면 타겟 서비스 내의 서비스들을 호출할 수 있는 종단점 객체를 제공하는 것이다. 그러한 종단점 객체를 제공하는 한가지 방법은 다음과 같은 의사코드 세그먼트에 나타낸 것과 유사한 종단점 팩토리(factory)의 사용에 의한 것이다:
종단점 클래스 Endpoint1, Endpoint2, Endpoint3 등등은 메시지 부분들을 포함하기 위해 메시지 객체를 생성하는 멤버 메소드를 제공하는 추상 종단점 클래스를 계승하는(또는 그것을 인터페이스로서 구현하는) 구상 클래스들이다. 그러한 바인딩-뉴트럴 인터페이스 내의 그러한 종단점 팩터 및 그외 다른 구성요소는 다음과 같은 의사코드 세그먼트에 나타낸 바와 같이, 타겟 서비스 요청(114)을 생성하는 단계(112) 및 타겟 서비스 요청(114)을 타겟 서비스로 보내는 단계(116)를 실행하기 위해 사용될 수 있다:
이 예시적인 의사코드 세그먼트는 종단점에 대한 네트워크 주소 및 포트 타입이 주어지면, 종단점 팩토리를 호출하여 종단점 객체를 생성한다. 그 다음, 세그먼트는 메시지 부분들을 종단점 객체 내로 로드함으로써 타겟 서비스 요청을 생성하고, 멤버 메소드 executeRequestResponseOperation()를 호출함으로써 타겟 서비스 요청을 타겟 서비스로 보낸다. 도 3의 방법은 중개기 내에서, 타겟 서비스로부터의 응답(122)을 수신하는 단계(120); 중개기 내에서, 타겟 서비스로부터의 응답(122)에 의존하여, 중개기로부터의 응답(126)을 생성하는 단계(124); 및 중개기로부터의 응답(126)을 요청 클라이언트에게 되돌려보내는 단계(128)를 포함한다. 이러한 예시적인 의사코드 세그먼트에서, 타겟 서비스로부터의 응답(122)을 수신하는 단계(120) 및 중개기로부터의 응답(126)을 생성하는 단계(124)는 타겟 서비스로부터의 응답을 기다려서, 'output'에 대한 메시지 레퍼런스를 통해 이용가능한 응답을 생성하는 전형적으로 블로킹(blocking) 호인, executeRequestResponseOperation()에 대한 호에 의해 구현된다.
상기 예시적인 의사코드 세그먼트는 종단점이라 칭해진 포트를 갖는 바인딩-뉴트럴 인터페이스의 사용을 예시하고 있다. 그러나, WSIF 인터페이스 구문은 종단점을 나타낼 때 "포트"라는 용어를 사용한다. 그러므로, 바인딩-뉴트럴 인터페이스의 사용에 관한 설명을 더 하기 위해, 더욱 예시적인 의사코드 세그먼트가 제시되는데, 이것은 WSIF 표준에 더욱 가깝다. 이 예에서, "포트"는 "종단점"을 의미하는 것으로 사용되고, 설명의 편의상, 팩토리라는 이름은 "portFactory"로 변경된다.
이 명세서는 주로 요청기로부터 타겟 서비스로 진행하는 경로 상의 요청을 프로세스하는 것과 관련하여, 웹 서비스 중개기 내의 포트 타입 어그노스틱 프록시 지원의 예시적인 방법을 설명하고 있지만, 본 발명의 실시예에 따른 중개기는 또한 전형적으로, 타겟 서비스에서 중개기를 통해 원래의 요청기에게로 다시 진행하는 경로를 형성하는 응답 메시지를 프로세스할 수 있다는 것을 아는 것이 유용하다. 예를 들어, 도 3의 방법은 중개기 내에서, 타겟 서비스로부터의 응답(122)을 수신하는 단계(120); 중개기 내에서, 타겟 서비스로부터의 응답(122)에 의존하여, 중개기로부터의 응답(126)을 생성하는 단계(124); 및 중개기로부터의 응답(126)을 요청 클라이언트에게 되돌려보내는 단계(128)를 포함한다.
도 4는 웹 서비스 오퍼레이션의 실행에 대한 요청(106)을 웹 서비스 중개기 내에서 수신하는 단계(304)를 포함하는 웹 서비스 중개기를 위한 포트 타입 어그노스틱 프록시 지원의 방법을 도시한 플로우차트를 나타낸 것으로, 요청은 오퍼레이션을 지원하는 타겟 서비스의 종단점이 식별될 수 있는 파라메트릭 정보(107)를 포함한다.
또한, 다음은 SOAP-HTTP 바인딩에 대한 그러한 요청의 한 예이다:
이 예시적인 POST 메시지는 중개기로부터 'myOp' 오퍼레이션을 요청하는 SOAP 엔벨로프를 포함한다. myOp 오퍼레이션, 그것의 포트 타입 및 그것의 종단점은 요청이 수신되기 전에는 중개기에게 모두 알려져 있지 않다. 이 예에서, 메시지는 SOAP 엔벨로프로서 취해지고, 오퍼레이션을 지원하는 타겟 서비스의 종단점이 식별될 수 있는 파라메트릭 정보(107)는 HTTP 파라미터 "portType=A"이다. 이 예에서, 타겟 서비스 상의 오퍼레이션의 이름이 SOAP 엔벨로프 내에 미리 인코딩되기 때문에, 추가될 유일한 파라메트릭 데이터는 타겟 서비스 상의 오퍼레이션을 포함하는 포트 타입인 포트 타입 "A"이다.
도 4의 방법은 또한 오퍼레이션을 지원하는 타겟 서비스의 종단점(110)을 파라메트릭 데이터에 의존하여 식별하는 단계(108)를 포함한다. 이 SOAP-HTTP 예에서, 오퍼레이션을 지원하는 타겟 서비스의 종단점(110)의 식별(108)은 UDDI 레지스트리 또는 ebXML 레지스트리와 같은 비즈니스 레지스트리로부터 종단점 설명을 검색함으로써 실행된다. 이 예에서, 중개기는 네트워크 주소 http://www.myTarget.com/SOAP-HTTP/servlets/에서 SOAP-HTTP에 의해 바인드되는 것으로 설명된 포트 타입 A의 종단점을 레지스트리로부터 검색한다.
도 4에 도시된 방법은 또한 요청(106)이 동기 응답을 요구하는 지의 여부를 판정하는 단계(350)를 포함한다. 요청(106)이 동기 응답을 요구하는 지의 여부를 판정하는 단계(350)는 수신된 요청 메시지의 제1 라인의 조회 데이터를 검사함으로써 실행될 수 있다. 상술된 예시적인 POST 메시지에서, 그것의 제1 라인의 조회 데이터는 '?'와 HTTP 버전 코드 사이의 모든 데이터인데, 즉 다음과 같다:
portType=A&synchRespReqd=True
이 예에서, "synchRespReqd=True"는 동기 응답이 요구된다는 것을 나타내기 위해 중개기에 의해 취해진 것이다. 이와 유사하게, "synchRespReqd=False"는 동기 응답이 요구되지 않는다는 것을 나타낼 수 있다. 이들은 단지 예시적인 인코딩이고, 물론 본 발명을 제한하지 않는다. 동기 응답이 중개기로부터 요구되는지 여부의 표시를 파라메트릭 정보 내에 인코딩하는 임의의 수단은 또한 양호한 실시예에 따른 본 발명의 범위에 속한다. 이 예에서, 요청이 동기 응답을 요구하는 지의 여부를 판정하는 단계(350)는 파라메트릭 정보(107)에 의존하여 그러한 판정을 함으로써 실행되는데, 파라메트릭 정보는 이름-값 쌍 "synchRespReqd=True"이다.
도시된 방법은 타겟 서비스 상의 오퍼레이션의 실행에 대한 타겟 서비스 요청(114)을 생성하는 단계(312)를 포함한다. 이 예에서, 중개기는 타겟 서비스 상의 종단점을 사용하여 HTTP POST 메시지로서 타겟 서비스 요청을 생성하도록 프로그램된다. 더욱 구체적으로, 다음과 같은 POST 메시지는 요청된 웹 서비스 오퍼레이션을 위한 입력 메시지 또는 입력 데이터의 예를 나타낸 것이다. 동기 응답이 요청되는지 판정하는 임의의 파라메트릭 데이터뿐만 아니라 종단점을 식별하는 파라메트릭 데이터는 삭제되고, 요청은 SOAP 엔벨로프 내의 오퍼레이션 이름으로부터 오퍼레이션을 스스로 식별할, SOAP 메시지를 처리하는 스크립트, 서블릿 또는 그외 다른 기능으로 향하게 된다.
그 결과 얻어지는 타겟 서비스 요청은 다음과 같다:
도 4의 방법에서, 타겟 서비스 상의 오퍼레이션의 실행에 대한 타겟 서비스 요청(114)을 생성하는 단계(312)는 요청이 동기 응답을 요구하는 지의 여부를 판정하는 단계(152)에 의존하여 타겟 서비스 요청(114)을 생성하는 단계(312)를 더 포함할 수 있다. 중개기는 요청된 웹 서비스 오퍼레이션을 위한 입력 데이터를 포함하는 입력 메시지를 생성할 수 있는 것처럼, 또한 출력 메시지를 생성할 수 있다. 그러한 출력 메시지는 전형적으로, 타겟 서비스로부터의 임의의 응답 메시지를 저장하고 통신할 때 사용하기 위한 플레이스-홀딩(place-holding) 객체이다. 동기 응답을 요구하는 요청을 위한 응답 메시지 객체를 생성하는 예시적인 방법은 중개기가 적절한 클래스의 객체를 생성하고, 그 객체를 빈 상태로 두고, 하나 이상의 호에서의 파라미터로서 그 객체에 대한 레퍼런스를, 타겟 서비스로 요청을 통신하는 (도 2A 및 2B의 제공자(220) 및 아웃바운드 엔진(222)과 같은) 다운스트림 인터페이스로 보내는 것이다. 동기 응답을 요구하지 않는 요청을 위한 응답 메시지 객체를 생성하는 예시적인 방법은 중개기가 하나 이상의 호에서의 파라미터로서 널(null) 레퍼런스(단순히 빈 출력 객체에 대한 레퍼런스가 아니라, 완전한 널 레퍼런스)를, 타겟 서비스로 요청을 통신하는 다운스트림 인터페이스로 보내는 것이다. 그러한 실시예에서, 다운스트림 인터페이스는 제어를 그 호출자에게 되돌려보내기 전에 단지 '확인응답(acknowledgment)'을 기다리는 표시와 같은 널 레퍼런스를 해석하도록 프로그램된다.
도 4의 방법은 또한 타겟 서비스 요청(114)을 타겟 서비스(118)에 송신하는 단계(316)를 포함한다. 이 예에서, 타겟 서비스 요청의 송신은 http://www.myTarget.com/에서 타겟 서비스 종단점으로의 TCP/IP 접속을 오픈하는 단계, 및 타겟 서비스로 TCP/IP 접속을 통해 HTTP POST 메시지를 보내는 단계를 포함한다.
본 발명의 최소한 몇몇 실시예에서, 도 4에 도시된 것과 같은 포트 타입 어그노스틱 프록시 지원의 방법에서, 생성되어 타겟 서비스에 송신된 타겟 서비스 요청은 웹 서비스 중개기 내에 수신된 요청의 검사되지 않고 변경되지 않은 메시지 내용을 갖고 있다는 것을 아는 것이 유용하다. 바로 전에 설명된 예에서, 중개기 상의 프록시 서비스는 파라메트릭 데이터 "portType=A"로부터 타겟 서비스의 종단점을 식별했고, 요청기로부터 타겟 서비스로의 전체 전달 과정의 전반을 통해 검사되지 않고 변경되지 않은 상태로 있는 SOAP 엔벨로프인 메시지 본문(body)을 전혀 터치하거나, 오픈하거나, 검사하거나, 구문분석하거나 임의의 다른 방식으로 혼란시키거나 하지 않고, 그렇게 식별된 종단점으로 메시지를 다시 보냈다. 그 과정 중에, 프록시 서비스는 중개기 서비스, 인증, 관리 보고, 부하 균형, 서비스 수집 등등 중의 하나 이상을 제공했다.
더욱 설명을 하기 위해, 예시적인 요청은 GET/HTTP 바인딩으로 표시되어, http://www.myIntermediary/channelApps/GET-HTTP/servlets/proxy에서 종단점으로 향하게 된다. 예시적인 착신 요청 메시지는 이 형식을 갖는다:
이 예에서, 메시지는 이름-값 쌍으로서 인코딩된 URI-인코드화 조회 데이터 "message=messageContentString"으로서 취해진다. 메시지 내용은 URI-인코드화 문자열이다. 이 예에서, 오퍼레이션을 지원하는 타겟 서비스의 종단점이 식별될 수 있는 파라메트릭 정보(107)는 모두, 메시지 내용 문자열 다음에 오는 조회 데이터이다. 이 예에서, 조회 데이터는 "A"의 포트 타입, 및 타겟 서비스 상의 오퍼레이션의 이름을 포함한다.
이 예에서, 오퍼레이션을 지원하는 타겟 서비스의 종단점(110)의 식별(108)은 UDDI 레지스트리 또는 ebXML 레지스트리와 같은 비즈니스 레지스트리로부터 종단점 설명을 검색함으로써 실행된다. 이 예에서, 중개기는 네트워크 주소 http://www.myTarget.com에서 GET/HTTP에 의해 바인드된 것으로 설명된 포트 타입 A의 종단점을 레지스트리로부터 검색한다.
도 4의 방법은 또한 타겟 서비스 상의 오퍼레이션의 실행에 대한 타겟 서비스 요청(114)을 생성하는 단계(112)를 포함한다. 이 예에서, 중개기는 타겟 서비스 요청을 위한 종단점 주소를 오퍼레이션 이름 및 메시지 부분과 연결함으로써 HTTP GET 메시지로서 타겟 서비스 요청을 생성하도록 프로그램된다. URI 공간에 표현된, 결과적으로 얻어진 타겟 서비스 요청은 다음과 같다:
http://www.myTarget.com/servlets/myOp?message=messageContentString
상술된 바와 같이, 도 4의 방법은 또한 타겟 서비스(118)로 타겟 서비스 요청(114)을 송신하는 단계(136)를 포함한다. 이 예에서, 타겟 서비스 요청을 송신하는 단계는 http://www.myTarget.com/에서의 타겟 서비스 종단점으로의 TCP/IP 접속을 오픈하는 단계, 및 다음과 같은 HTTP GET 메시지를 보내는 단계를 포함한다:
GET/servlets/myOp?message=messageContentString HTTP/1.1
도 4의 방법은 또한 요청이 동기 응답(360)을 요구하면 타겟 서비스로부터의 응답을 기다리는 단계(361)를 포함한다. 도 5는 타겟 서비스로부터의 응답을 기다리는(361) 방법을 도시한 플로우차트를 나타낸 것으로, 이 방법은 타겟 서비스로부터의 응답(122)을 중개기 내에서 동기적으로 수신하는 단계(320); 중개기 내에서, 타겟 서비스로부터의 응답(122)에 의존하여, 중개기로부터의 응답(126)을 생성하는 단계(324); 및 중개기로부터의 응답(126)을 요청기(102)에게 되돌려보내는 단계(328)를 포함한다. 도 5의 방법에서, 타겟 서비스로부터의 응답을 중개기 내에서 동기적으로 수신하는 단계(320)는 중개기와 타겟 서비스 사이의 데이터 통신 접속에 관한 블록킹 수신 기능을 호출함으로써 실행될 수 있다.
다음과 같은 의사코드 세그먼트는 HTTP 바인딩의 경우에, 중개기로부터의 요청을 타겟 서비스로 전송하고, 요청이 동기 응답을 요구하면 타겟 서비스로부터의 응답을 기다리는 것의 한 예이다. 다음과 같은 세그먼트는 웹 서비스 중개기의 아웃바운드 엔진 내에서 또는 제공자를 통해(도 2의 220, 222) 본 발명의 실시예에 따라 종종 제공되는 바와 같은 HTTP 바인딩에 대한 클라이언트 오퍼레이션을 예시한 것이다:
이 예시적인 의사코드 세그먼트는 자바 URL 객체를 생성하고, URL 객체를 사용하여, 네트워크 주소 "targetURL"을 갖는 것으로 식별된 타겟 서비스로의 'connection'이라고 이름붙여진 TCP/IP 접속을 개방한다. 이 세그먼트는 또한 "out"이라고 이름붙여진 접속 상의 버퍼링된 스트림, 및 "in"이라고 이름붙여진 접속 상의 입력 스트림을 개방한다. 이 세그먼트는 "out.println(request)"와 같은 접속을 통해 요청을 전송한 다음, 동기 응답이 요구되면, 동일한 접속을 통해 응답 메시지 "Message responseMessage=in.readLine()"을 수신하기 위한 블록킹 호를 생성하고, 응답 메시지를 그 호출자에게 되돌려 보낸다. 이 예는 HTTP 바인딩에 대한 것이다.
더욱 설명하기 위해, 또 다른 예가 아래에 제시되는데, 'JMS' 바인딩, 즉 자바 메시지 서비스에 대한 것이다. JMS는 2개의 메시징 도메인을 제공하는데, 하나는 점 대 점 메시징을 위한 것이고, 또 하나는 발행-구독(publish-subscribe) 메시징을 위한 것이다. 이 예는 JMS 메시지 큐를 사용하는, 중개기와 타겟 서비스 사이의 점 대 점 메시징을 설명한다. JMS 점 대 점 메시징에서, 소켓과 같은 데이터 통신 접속은 JMS 'connection' 객체에 의해 캡슐화된다. JMS 접속은 'connection factory'라고 불리는 관리 객체를 통해 생성된다. JMS 접속은 하나 이상의 JMS 'session'을 생성하기 위해 사용된다. 하나의 세션은 메시지를 생성하고 소비하는 단일-스레디드 문맥이다. 세션은 메시지 생성자, 메시지 소비자, 및 메시지를 만들기 위해 사용된다. 메시지 생성자는 메시지를 큐에 보내기 위해 사용된 객체이다. 메시지 생성자의 점 대 점 형식은 send() 메소드를 포함하는 JMS 'queueSender' 인터페이스를 구현한다. 메시지 소비자는 큐로부터 메시지를 수신하기 위해 사용된 객체이다. 메시지 생성자의 점 대 점 형식은 만료 기간이 있거나 없이 호출될 수 있는 blocking receive() 메소드를 포함하는 JMS 'queueReceiver' 인터페이스를 구현한다.
다음과 같은 의사코드 세그먼트는 JMS 바인딩의 경우에, 중개기로부터의 요청을 타겟 서비스로 전송하고, 요청이 동기 응답을 요구하면 타겟 서비스로부터의 응답을 기다리는 것의 한 예이다.
이 예시적인 JMS 세그먼트는 queueConnection이라고 이름붙여진 접속을 생성하고, queueSession이라고 이름붙여진 세션을 생성하며, queueSender라고 이름붙여진 송신자를 생성하여, JMS 큐를 통해 타겟 서비스로 요청 메시지를 보내며, 동기 요청이 요구되면, queueReceiver라고 이름붙여진 수신자를 생성하여, blocking receive() on queueReceiver를 송신하고, 응답 메시지를 기다린다.
요청이 동기 응답을 요구하지 않으면(362), 본 발명의 실시예에 따른 웹 서비스 중개기를 위한 포트 타입 어그노스틱 프록시 지원의 방법은 타겟 서비스로 요청을 송신하는 것 이외에 절대로 아무것도 하지 않는 것을 포함할 수 있다. 즉, 요청이 동기 응답을 요구하지 않는 경우(362), 확인응답, 비동기 응답 등에 관해 전혀 아무것도 하지 않는 것도 또한 양호한 실시예에 따른 본 발명의 범위에 속한다. 대안적으로, 도 4에 도시된 바와 같이, 본 발명의 제2 실시예에 따른 방법은 타겟 서비스 요청의 확인응답(ACK)을 타겟 서비스(156)로부터 수신하는 단계(354), 및 응답 메시지를 기다리지 않고 요청기(102)에게 확인응답(156)을 돌려보내는 단계(358)를 포함할 수 있다.
다음은 응답 메시지를 기다리지 않고 요청기에게 확인응답을 돌려보내는 예시적인 의사코드 세그먼트이다:
이 예시적인 의사코드 세그먼트는 자바 URL 객체를 생성하고, 네트워크 주소 "targetURL"을 갖는 것으로 식별된 타겟 서비스로의 'connection'이라고 이름붙여진 TCP/IP 접속을 HTTPURLConnection 객체의 형태로 URL 객체에게 개방한다. 이 세그먼트는 또한 "out"이라고 이름붙여진 접속 상의 버퍼링된 스트림, 및 "in"이라고 이름붙여진 소켓 상의 입력 스트림을 개방한다. 이 세그먼트는 "out.println(request)"와 같은 접속을 통해 요청을 전송한 다음, 동일한 접속을 통해 확인응답 "int acknowledgment=connection.getResponseCode()"를 수신하기 위한 블록킹 호를 생성한다. 세그먼트는 확인응답을 그 호출자(이 예에서는 HTTP 응답 코드 '200')에게 되돌려 보내거나, 에러 메시지를 되돌려 보낸다. 확인응답은 요청이 수신되었다는 것을 확인응답하는 타겟 서비스로부터의 절차적인 확인응답이다. 이 세그먼트는 요청에 대한 실질적인 응답을 기다리지 않는다.
바로 위의 예시적인 의사코드 세그먼트는 중개기로부터의 요청을 타겟 서비스로 전송하고, 실질적인 응답 메시지를 기다리지 않고 확인응답을 제공하는 것의 예이다. 이 세그먼트는 웹 서비스 중개기의 제공자를 통하거나 아웃바운드 엔진 내에서(도 2의 220, 222) 본 발명의 실시예에 따라 종종 제공되는 것과 같은 HTTP 바인딩에 대한 클라이언트 오퍼레이션을 예시한 것이다.
본 분야에 숙련된 독자들은 지금쯤은 이미, 타겟 서비스 상의 오퍼레이션에 대한 요청을 중개기에게 보내는 것을 요청기가 어떻게 알았을까 생각하고 있을 것이다. 그 답은 중개기 또는 중개기의 개발자가 타겟 서비스 상의 오퍼레이션을 지원하는 종단점으로서 웹 서비스 중개기의 종단점을 요청기에게 확인한다는 것이다. 타겟 서비스 상의 오퍼레이션을 지원하는 종단점으로서 중개기의 종단점의 확인은 요청기에 의해 발견용 비지니스 디렉토리 내에 등록되는 WSDL 문서로 구현될 수 있다. 대안적으로, 그러한 확인은 중개기로부터 요청기에게로 다운로드되거나, 또는 심지어 단순히 요청기에게 이메일로 보내지거나, 또는 요청기의 웹 서비스 구성 데이터 내의 관리자에 의한 설치를 위해 요청기의 관리자에게 이메일로 보내질 수 있다.
다음과 같은 WSDL 의사코드의 세그먼트에 의해 타겟 서비스가 설명되는 예를 고려해보자:
그 타겟 서비스를 위한 중개기는 다음:
과 같이 타겟 서비스 설명 내에 주소 확장 요소의 위치 속성을 대체하고, 이로 인해, 타겟 서비스 상의 "getQuote" 오퍼레이션을 지원하는 종단점으로서 웹 서비스 중개기의 종단점을 확인하는 다음과 같은 세그먼트에 의해 예시된 WSDL 문서를 생성함으로써, 타겟 서비스 상의 오퍼레이션을 지원하는 종단점으로서 웹 서비스 중개기의 종단점을 요청기에게 확인할 수 있다:
레지스트리, 다운로드, 이메일을 통하거나, 또는 본 분야에 숙련된 기술자들에게 생각날 수 있는 그외 다른 수단에 의해 이 나중의 세그먼트에 의해 예시된 종류의 WSDL의 요청기에게의 제공은 타겟 서비스 상의 오퍼레이션을 지원하는 종단점으로서 웹 서비스 중개기의 종단점을 요청기에게 확인한다.
도 4의 방법에서, 오퍼레이션을 지원하는 타겟 서비스의 종단점을 파라메트릭 정보(107)에 의존하여 식별하는 단계(308)는 종종, 타겟 서비스의 단 하나의 종단점이 아니라, 오퍼레이션을 지원하는 타겟 서비스의 2개 이상의 종단점을 식별하는 단계를 포함할 수 있다. 본 발명의 방법의 한 실시예에 따른 포트 타입 어그노스틱 프록시가 파라메트릭 정보(107)로서 오퍼레이션에 대한 포트 타입을 수신하고, 조회 파라미터로서 그 포트 타입을 갖는 비즈니스 레지스트리를 조회함으로써, 오퍼레이션을 지원하는 타겟 서비스의 2개 이상의 종단점을 확인하는 예를 고려해 보자. 2개 이상의 종단점의 그러한 확인은 예를 들어, 그 포트 타입을 갖는 UDDI 레지스트리를 조회하고, 그 포트 타입에 대한 타겟 서비스를 설명하는 2개 이상의 WSDL 문서를 응답시에 수신함으로써 실행될 수 있다.
2개 이상의 종단점이 그렇게 확인될 때, 본 발명의 실시예에 따른 웹 서비스 중개기를 위한 포트 타입 어그노스틱 프록시 지원을 위한 방법은 전형적으로 선택 규칙에 따라 종단점들 중의 하나를 선택하는 단계를 포함한다. 보통의 경우에, 선택 규칙은 그렇게 확인된 종단점들 중의 제1 종단점을 선택하고, 나머지 것들은 무시하도록 될 수 있다. 선택 규칙은 예를 들어, 부하 균형을 위한 선택을 포함하여 더욱 복잡해질 수 있다. 부하 균형을 위한 규칙은 표 1에 도시된 것과 유사한 데이터 구조의 사용에 의해 구현될 수 있다.
지연 추적
포트 타입 종단점 URI 송신 시간 수신 시간 주행(Trip) 지연(ms.) 누적 지연 (ms.)
AAAA------ http:/www.ibm.com /aTargetService http:/www.ibm.com /aTargetService http:/www.ibm.com/anotherTargetService http:/www.ibm.com/anotherTargetService------ 12:01:01.1 12:05:02.3 01:10:01.5 01:15:02.5------ 12:01:01.2 12:05:02.45 01:10:01.57 01:15:02.8------ 1001507030------ 10025070100------
표 1의 각 행은 중개기와 타겟 서비스 사이의 웹 서비스 통신에 있어서 요청-응답 왕복 주행에 대한 지연 측정치를 나타낸다. 표 1은 요청 및 응답의 각각의 왕복에 대한 포트 타입 및 종단점 URI의 열을 제공한다. 송신 시간 열은 중개기로부터 포트 타입의 오퍼레이션을 위한 타겟 서비스 상의 종단점으로 요청 메시지가 송신되는 시간을 기록한다. 수신 시간 열은 대응하는 응답 메시지가 타겟 서비스로부터 수신되는 시간을 기록한다. 주행 지연은 수신 시간과 송신 시간 사이의 차이이다. 누적 지연은 표에 표시된 각 종단점에 대해 진행되는 주행 지연의 합이다. 표 1과 유사한 구조로, 요청을 위한 2개 이상의 종단점이 확인될 때 사용하기 위한 선택 규칙은 다음과 같은 예시적인 규칙으로서 구현될 수 있다:
동일한 포트 타입 내의 오퍼레이션에 대한 더 많은 요청들이 중개기에 도달함에 따라, 2개 이상의 확인된 종단점들의 각각을 차례로 한번씩 사용한다;
각각의 그러한 사용에 대해 지연 데이터를 기록한다;
동일한 포트 타입의 오퍼레이션에 대한 후속 요청을 위해, 최저 누적 지
연을 갖는 종단점을 지연 표에서 선택하고, 그 종단점으로 요청을 보내
고, 메시지가 타겟 서비스로 보내질 때 및 대응하는 응답이 중개기 내에
수신될 때 적절한 지연 데이터를 기록한다.
표 1에서의 예시적인 데이터는 포트 타입 A가 2개의 종단점, 즉 URI http://www.ibm.com/aTargetService에서의 제1 종단점 및 URI http://www.ibm.com/anotherTargetService에서의 제2 종단점으로 최근에 보낸 요청에 대한 누적 지연을 나타낸다. 처음은 250 밀리초의 누적 요청 지연을 갖고, 두번째는 100 밀리초의 누적 요청 지연을 갖는다. 상술된 예시적인 시나리오를 사용하여, 포트 타입 A 상에서의 오퍼레이션에 대한 현재의 요청은 URI http://www.ibm.com/anotherTargetService에서의 종단점인 제2 종단점으로 라우팅될 수 있다.
도 4의 방법에서, 타겟 서비스 상의 오퍼레이션의 실행에 대한 타겟 서비스 요청(14)을 생성하는 단계(312)는 바인딩-뉴트럴 인터페이스에서 유용한 데이터 구조로 요청을 구성하고, 바인딩-뉴트럴 인터페이스를 호출하여 호 파라미터로서 요청을 보냄으로써 실행될 수 있다. 이와 유사하게, 타겟 서비스로 타겟 서비스 요청(114)을 송신하는 단계(316)는 바인딩-뉴트럴 인터페이스 내의 하나 이상의 멤버 메소드를 호출하는 단계를 포함한다.
바인딩-뉴트럴 인터페이스는 인터페이스의 사용이 요청 또는 메시지 바인딩에 의존하지 않는 것이다. 즉, 인터페이스를 구현하고 그것을 통해 데이터 통신을 실행하기 위해 사용된 데이터 구조 및 호출 방법은 메시지 내에 사용된 데이터 인코딩의 유형에도 의존하지 않고, 메시지를 위해 사용된 데이터 통신 프로토콜에도 의존하지 않는다. 본 발명의 실시예에 따른 중개기를 위한 포트 타입 어그노스틱 프록시의 개발자는 종종 그들 자신의 바인딩-뉴트럴 인터페이스를 구축할 것이다. 그러나, "WSIF(Web Service Invocation Framework)"로서 공지된 바인딩 -뉴트럴 인터페이스를 위한 개방 표준안이 있다. WSIF는 이제 아파치 소프트웨어 재단의 웹 서비스 프로젝트의 일부로서 지원된다.
바인딩-뉴트럴 인터페이스의 사용은 본 발명의 실시예에 장점을 제공한다. SOAP-HTTP 바인딩은 사용자 및 개발자가 소정의 다른 바인딩이 존재한다는 것을 잊어버릴 만큼 현재의 분야에서 일반적이다. 이것은 다른 바인딩과 함께 사용할 수 없거나 다른 바인딩과 함께 사용하도록 적응할 수 없는 경우에 시스템의 개발을 매우 어렵게 한다. 그러나, 웹 서비스가 성장함에 따라, 다른 바인딩들은 더욱 쓸모있게 되고 더욱 일반적이 될 것이다. 게다가, 본 발명의 실시예의 뒷부분의 바인딩-뉴트럴 인터페이스의 사용은 또한, 이용가능한 바인딩이 런타임시에 결정될 수 있어서, 유연성있고, 강력하며, 더욱 널리 유용한 웹 서비스 중개기를 제공할 수 있다는 것을 의미한다.
바인딩-뉴트럴 인터페이스를 구현하는 한가지 방법은 포트 타입 및 종단이 주어지면 타겟 서비스 내의 서비스들을 호출할 수 있는 종단점 객체를 제공하는 것이다. 그러한 종단점 객체를 제공하는 한가지 방법은 다음과 같은 의사코드 세그먼트에 나타낸 것과 유사한 종단점 팩토리의 사용에 의한 것이다:
종단점 클래스 Endpoint1, Endpoint2, Endpoint3 등등은 메시지 부분들을 포함하기 위해 메시지 객체를 생성하는 멤버 메소드를 제공하는 추상 종단점 클래스를 계승하는(또는 그것을 인터페이스로서 구현하는) 구상 클래스들이다. 그러한 바인딩-뉴트럴 인터페이스 내의 그러한 종단점 팩터 및 그외 다른 구성요소는 다음과 같은 의사코드 세그먼트에 나타낸 바와 같이, 타겟 서비스 요청(114)을 생성하는 단계(312) 및 타겟 서비스 요청(114)을 타겟 서비스로 보내는 단계(316)를 실행하기 위해 사용될 수 있다:
이 예시적인 의사코드 세그먼트는 종단점에 대한 네트워크 주소 및 포트 타입이 주어지면, 종단점 팩토리를 호출하여 종단점 객체를 생성한다. 그 다음, 세그먼트는 메시지 부분들을 종단점 객체 내로 로드함으로써 타겟 서비스 요청을 생성하고, 멤버 메소드 executeRequestResponseOperation()를 호출함으로써 타겟 서비스 요청을 타겟 서비스로 보낸다. 도 5의 방법은 요청이 동기 응답을 요구하면, 중개기 내에서, 타겟 서비스로부터의 응답(122)을 수신하는 단계(320); 중개기 내에서, 타겟 서비스로부터의 응답(122)에 의존하여, 중개기로부터의 응답(126)을 생성하는 단계(324); 및 중개기로부터의 응답(126)을 요청 클라이언트에게 되돌려보내는 단계(328)를 포함한다.
이러한 예시적인 의사코드 세그먼트에서, 타겟 서비스로부터의 응답(122)을 수신하는 단계(320) 및 중개기로부터의 응답(126)을 생성하는 단계(324)는 executeRequestResponseOperation()에 대한 호에 의해 구현된다. 이 예에서, 출력 메시지에 대한 레퍼런스의 값은 요청이 동기 응답을 요구하면 널 상태로 있게 된다. 이러한 종류의 실시예에서의 널 'output' 파라미터는 동기 응답이 요구되지 않는다는 것을 나타내기 위해 제공자(도 2A의 220)에 의해 채택된다. 그러므로, 제공자는 요청을 타겟 서비스로 송신하고, 응답 기다리지 않고 즉시 되돌려보낸다.
이와 유사하게, 요청이 동기 응답을 요구하면, 응답 메시지 'output'에 대한 레퍼런스의 값은 output=ep.createOutputmessage()에 의해 비-널로 설정된다. 호:
ep.executeRequestReponseOperation("getQuote", input, output)
에서 'output'이라고 이름붙여진 응답 메시지에 대한 파라미터 레퍼런스가 널이 아니라는 사실은 동기 응답이 요구된다는 것을 나타내기 위해 제공자(도 2A의 220)에 의해 채택된다. 그 다음, 그러한 제공자는 아웃바운드 엔진(도 2의 222) 상에서 블록킹 수신 호를 실행시키고, 타겟 서비스로부터 대응하는 응답 메시지를 기다리도록 프로그램된다. 이때, 도 5의 방법과 관련하여, 이 세그먼트는 요청이 동기 응답을 요구하는지 여부의 판정(152)에 의존하여 타겟 서비스 상의 오퍼레이션의 실행에 대한 타겟 서비스 요청(114)을 생성하는(312) 예시적인 방법을 나타낸다.
상기 예시적인 의사코드 세그먼트는 종단점이라 칭해진 포트를 갖는 바인딩-뉴트럴 인터페이스의 사용을 예시하고 있다. 그러나, WSIF 인터페이스 구문은 종단점을 나타낼 때 "포트"라는 용어를 사용한다. 그러므로, 바인딩-뉴트럴 인터페이스의 사용에 관한 설명을 더 하기 위해, 더욱 예시적인 의사코드 세그먼트가 제시되는데, 이것은 WSIF 표준에 더욱 가깝다. 이 예에서, "포트"는 "종단점"을 의미하는 것으로 사용되고, 설명의 편의상, 팩토리라는 이름은 "portFactory"로 변경된다.
이 명세서는 주로 요청기로부터 타겟 서비스로 진행하는 경로 상의 요청을 프로세스하는 것과 관련하여, 웹 서비스 중개기 내의 포트 타입 어그노스틱 프록시 지원의 예시적인 방법을 설명하고 있지만, 본 발명의 실시예에 따른 중개기는 또한 전형적으로, 타겟 서비스에서 중개기를 통해 원래의 요청기에게로 반대로 진행하는 경로를 형성하는 응답 메시지를 프로세스할 수 있다는 것을 아는 것이 유용하다. 예를 들어, 도 5의 방법은 요청이 동기 응답을 요구할 때, 중개기 내에서, 타겟 서비스로부터의 응답(122)을 수신하는 단계(320); 중개기 내에서, 타겟 서비스로부터의 응답(122)에 의존하여, 중개기로부터의 응답(126)을 생성하는 단계(324); 및 중개기로부터의 응답(126)을 요청 클라이언트에게 되돌려보내는 단계(328)를 포함한다.
상기 설명으로부터, 본 발명의 진정한 정신을 벗어나지 않고서 본 발명이 여러 실시예에 변형 및 변경이 행해질 수 있다는 것을 알 수 있을 것이다. 이 명세서의 설명은 예시적으로 나타내고자 하는 것이지 제한하고자 하는 것은 아니다. 본 발명의 범위는 다음 청구범위에 의해서만 제한된다.

Claims (49)

  1. 웹 서비스 중개기(intermediary)들을 위한 포트 타입 어그노스틱(port type agnostic) 프록시 지원의 방법에 있어서,
    웹 서비스 오퍼레이션(operation)의 실행에 대한 요청을 웹 서비스 중개기 내에서 수신하는 단계 - 상기 웹 서비스 중개기는 프록시를 포함하고, 상기 프록시에 이용가능한 어떤 구성 데이터도 상기 오퍼레이션을 지원하는 타겟 서비스의 종단점을 설명하지 못하고, 요청기(requester)는 상기 웹 서비스 중개기에게 전혀 알려지지 않은 포트 타입 내의 오퍼레이션에 대한 상기 요청을 제출하고, 상기 요청은 상기 오퍼레이션을 지원하는 타겟 서비스의 종단점이 식별되는 파라메트릭(parametric) 정보를 포함함 -;
    상기 웹 서비스 중개기에 의해 상기 파라메트릭 정보에 의존하여, 상기 오퍼레이션을 지원하는 타겟 서비스의 종단점을 식별하는 단계;
    상기 웹 서비스 중개기에 의해, 상기 타겟 서비스 상의 오퍼레이션의 실행에 대한 타겟 서비스 요청을 생성하는 단계; 및
    상기 웹 서비스 중개기에 의해, 상기 타겟 서비스 요청을 상기 타겟 서비스에 송신하는 단계
    를 포함하고,
    상기 타겟 서비스 상의 오퍼레이션의 실행에 대한 타겟 서비스 요청을 생성하는 단계는,
    상기 웹 서비스 오퍼레이션의 실행에 대한 요청을 바인딩-뉴트럴(binding-neutral) 인터페이스에서 유용한 데이터 구조로 구성하는 단계; 및
    상기 바인딩-뉴트럴 인터페이스를 호출하여 상기 웹 서비스 오퍼레이션의 실행에 대한 요청을 호 파라미터로서 보내는 단계
    를 더 포함하는
    포트 타입 어그노스틱 프록시 지원 방법.
  2. 제1항에 있어서, 생성되어 상기 타겟 서비스로 송신된 상기 타겟 서비스 요청은 상기 웹 서비스 중개기 내에 수신된 상기 웹 서비스 오퍼레이션의 실행에 대한 요청의 검사되지 않고 변경되지 않은 메시지 내용들을 포함하고 있는 것인 포트 타입 어그노스틱 프록시 지원 방법.
  3. 제1항에 있어서, 상기 웹 서비스 중개기가 상기 오퍼레이션을 지원하는 종단점으로서 상기 웹 서비스 중개기의 종단점을 상기 요청기에게 확인하는 단계를 더 포함하는 것인 포트 타입 어그노스틱 프록시 지원 방법.
  4. 제1항에 있어서, 상기 파라메트릭 정보는 상기 오퍼레이션에 대한 포트 타입을 포함하는 것인 포트 타입 어그노스틱 프록시 지원 방법.
  5. 제1항에 있어서, 상기 파라메트릭 정보에 의존하여 상기 오퍼레이션을 지원하는 타겟 서비스의 종단점을 식별하는 단계는
    상기 파라메트릭 정보에 의존하여, 상기 오퍼레이션을 지원하는 타겟 서비스들의 다수의 종단점들을 식별하는 단계; 및
    선택 규칙들에 따라 상기 다수의 종단점들로부터 하나의 종단점을 선택하는 단계
    를 더 포함하는 것인 포트 타입 어그노스틱 프록시 지원 방법.
  6. 제5항에 있어서, 상기 파라메트릭 정보는 상기 오퍼레이션에 대한 포트 타입을 포함하고, 상기 파라메트릭 정보에 의존하여 상기 오퍼레이션을 지원하는 타겟 서비스들의 다수의 종단점들을 식별하는 단계는 상기 포트 타입에 의존하여, 상기 포트 타입에 대한 다수의 타겟 서비스들을 레지스트리(registry)로부터 식별하는 단계를 포함하는 것인 포트 타입 어그노스틱 프록시 지원 방법.
  7. 삭제
  8. 삭제
  9. 제1항에 있어서, 상기 타겟 서비스 요청을 상기 타겟 서비스로 송신하는 단계는 바인딩-뉴트럴 인터페이스 내의 하나 이상의 멤버 메소드들(member methods)을 호출하는 단계를 포함하는 것인 포트 타입 어그노스틱 프록시 지원 방법.
  10. 삭제
  11. 삭제
  12. 삭제
  13. 삭제
  14. 삭제
  15. 삭제
  16. 제1항에 있어서,
    상기 타겟 서비스로부터의 응답을 상기 웹 서비스 중개기 내에서 수신하는 단계;
    상기 웹 서비스 중개기 내에서, 상기 타겟 서비스로부터의 상기 응답에 의존하여, 상기 웹 서비스 중개기로부터의 응답을 생성하는 단계; 및
    상기 웹 서비스 중개기에 의해, 상기 웹 서비스 중개기로부터의 상기 응답을 상기 요청기에게 돌려보내는 단계
    를 더 포함하는 것인 포트 타입 어그노스틱 프록시 지원 방법.
  17. 제1항 내지 제6항, 제9항 또는 제16항 중 어느 한 항에 기재된 방법의 각 단계를 수행하기 위한 각각의 수단을 포함하는, 웹 서비스 중개기들을 위한 포트 타입 어그노스틱 프록시 지원 시스템.
  18. 삭제
  19. 삭제
  20. 삭제
  21. 삭제
  22. 삭제
  23. 삭제
  24. 삭제
  25. 삭제
  26. 삭제
  27. 삭제
  28. 삭제
  29. 삭제
  30. 삭제
  31. 삭제
  32. 삭제
  33. 웹 서비스 중개기들을 위한 포트 타입 어그노스틱 프록시 지원을 위한 컴퓨터 프로그램이 기록되어 있는 컴퓨터 판독가능 기록 매체로서,
    상기 컴퓨터 프로그램은, 제1항 내지 제6항, 제9항 또는 제16항 중 어느 한 항에 기재된 방법의 각각의 단계를 수행하기 위한 각각의 프로그램 코드 수단을 포함하는 것인 컴퓨터 판독가능 기록 매체.
  34. 삭제
  35. 삭제
  36. 삭제
  37. 삭제
  38. 삭제
  39. 삭제
  40. 삭제
  41. 삭제
  42. 삭제
  43. 삭제
  44. 삭제
  45. 삭제
  46. 삭제
  47. 삭제
  48. 삭제
  49. 삭제
KR1020067011403A 2003-12-12 2004-12-09 웹 서비스 중개기를 위한 포트 타입 어그노스틱 프록시지원 KR100915776B1 (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US10/734,770 US7296072B2 (en) 2003-12-12 2003-12-12 Enhanced port type agnostic proxy support for web services intermediaries
US10/734,773 2003-12-12
US10/734,773 US7464142B2 (en) 2003-12-12 2003-12-12 Port type agnostic proxy support for web services intermediates
US10/734,770 2003-12-12

Publications (2)

Publication Number Publication Date
KR20060123294A KR20060123294A (ko) 2006-12-01
KR100915776B1 true KR100915776B1 (ko) 2009-09-04

Family

ID=34704440

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020067011403A KR100915776B1 (ko) 2003-12-12 2004-12-09 웹 서비스 중개기를 위한 포트 타입 어그노스틱 프록시지원

Country Status (11)

Country Link
EP (1) EP1695520B1 (ko)
JP (1) JP4959339B2 (ko)
KR (1) KR100915776B1 (ko)
AT (1) ATE410873T1 (ko)
AU (1) AU2004300300A1 (ko)
BR (1) BRPI0417511A (ko)
CA (1) CA2548368C (ko)
DE (1) DE602004017052D1 (ko)
IL (1) IL176118A0 (ko)
MX (1) MXPA06006342A (ko)
WO (1) WO2005060212A1 (ko)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8270293B2 (en) * 2005-12-02 2012-09-18 Panasonic Corporation Systems and methods for efficient electronic communication in a distributed routing environment
US20090083441A1 (en) * 2007-09-24 2009-03-26 Microsoft Corporation Synchronization of web service endpoints in a multi-master synchronization environment
JP2009135583A (ja) * 2007-11-28 2009-06-18 Toshiba Tec Corp クライアント装置、アプリケーションプログラム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020178214A1 (en) * 2001-05-23 2002-11-28 International Business Machines Corporation Dynamic undeployment of services in a computing network
US20030061404A1 (en) * 2001-09-21 2003-03-27 Corel Corporation Web services gateway
US20030135628A1 (en) * 2002-01-15 2003-07-17 International Business Machines Corporation Provisioning aggregated services in a distributed computing environment
US20030204645A1 (en) * 2002-04-09 2003-10-30 Sun Microsystems, Inc. Method, system, and articles of manufacture for providing a servlet container based web service endpoint

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3741818B2 (ja) * 1997-03-31 2006-02-01 株式会社野村総合研究所 多数のコンピュータが参加する情報分配応答システム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020178214A1 (en) * 2001-05-23 2002-11-28 International Business Machines Corporation Dynamic undeployment of services in a computing network
US20030061404A1 (en) * 2001-09-21 2003-03-27 Corel Corporation Web services gateway
US20030135628A1 (en) * 2002-01-15 2003-07-17 International Business Machines Corporation Provisioning aggregated services in a distributed computing environment
US20030204645A1 (en) * 2002-04-09 2003-10-30 Sun Microsystems, Inc. Method, system, and articles of manufacture for providing a servlet container based web service endpoint

Also Published As

Publication number Publication date
EP1695520A1 (en) 2006-08-30
ATE410873T1 (de) 2008-10-15
JP4959339B2 (ja) 2012-06-20
DE602004017052D1 (de) 2008-11-20
MXPA06006342A (es) 2006-08-23
WO2005060212A1 (en) 2005-06-30
CA2548368C (en) 2010-11-02
JP2007515716A (ja) 2007-06-14
EP1695520B1 (en) 2008-10-08
BRPI0417511A (pt) 2007-03-13
IL176118A0 (en) 2006-10-05
CA2548368A1 (en) 2005-06-30
AU2004300300A1 (en) 2005-06-30
KR20060123294A (ko) 2006-12-01

Similar Documents

Publication Publication Date Title
US7296072B2 (en) Enhanced port type agnostic proxy support for web services intermediaries
US7464142B2 (en) Port type agnostic proxy support for web services intermediates
US10489730B2 (en) Managing virtual business instances within a computer network
US7428597B2 (en) Content-based routing system and method
US7571208B2 (en) Creating proxies from service description metadata at runtime
US7191450B2 (en) Data-driven application integration adapters
US7895589B2 (en) Dynamic data-driven application integration adapters
US8234406B2 (en) Method of redirecting client requests to web services
US20030009539A1 (en) Distributed object middleware connection method
JP2004530194A (ja) 異なるオブジェクト・タイプのサーバとクライアントを結合するための方法およびブリッジ
US20060271570A1 (en) System and method for simple object access protocol access to interface definition language based services
EP1825384A2 (en) A method and system for providing reconciliation of semantic differences amongst multiple message service providers
KR100915776B1 (ko) 웹 서비스 중개기를 위한 포트 타입 어그노스틱 프록시지원
US20060168268A1 (en) Specific method of setting transport-specific properties from transport-agnostic clients
Werner et al. Architecture and standardisation of web services
Burnett et al. Application Development for IBM CICS Web Services
EP1715646A1 (en) System and method for connecting applications to heterogeneous backend servers via a gateway server
WO2005029807A1 (en) Personalized web service description
BRPI0417511B1 (pt) Método e sistema para suporte de proxy agnóstico quanto ao tipo de porta para intermediários de serviços da web
Sarang Web services architecture
McArthur Introduction to Web Services with SOAP
Taylor et al. Web Services Protocols

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
LAPS Lapse due to unpaid annual fee