KR100683812B1 - 인바운드 커넥터 - Google Patents

인바운드 커넥터 Download PDF

Info

Publication number
KR100683812B1
KR100683812B1 KR1020047001456A KR20047001456A KR100683812B1 KR 100683812 B1 KR100683812 B1 KR 100683812B1 KR 1020047001456 A KR1020047001456 A KR 1020047001456A KR 20047001456 A KR20047001456 A KR 20047001456A KR 100683812 B1 KR100683812 B1 KR 100683812B1
Authority
KR
South Korea
Prior art keywords
service
inbound
connector
component
server
Prior art date
Application number
KR1020047001456A
Other languages
English (en)
Other versions
KR20040032876A (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
Application filed by 인터내셔널 비지네스 머신즈 코포레이션 filed Critical 인터내셔널 비지네스 머신즈 코포레이션
Publication of KR20040032876A publication Critical patent/KR20040032876A/ko
Application granted granted Critical
Publication of KR100683812B1 publication Critical patent/KR100683812B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/465—Distributed object oriented systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols

Abstract

본 발명은 다양한 미들웨어 제품과 애플리케이션 프로그래밍 인터페이스와 상호작용하는 일반적인 인터페이스를 갖는 컴퓨터 서버를 개시한다. 인터페이스의 제안된 아키텍처는 기존의 미들웨어 시스템의 인식이 서버 애플리케이션을 개발하거나 변경하는데 필요하지 않도록 한다.
컴포넌트 서버, 인바운드 커넥터, 아웃바운드 커넥터, 인터페이스

Description

인바운드 커넥터{INBOUND CONNECTOR}
본 발명은 일반적으로 일반 인터페이스로 서버와 클라이언트를 접속하는 분야에 관한 것으로, 특히 다양한 미들웨어(middleware) 제품과 애플리케이션 프로그래밍 인터페이스로 상호작용하는 균일한 인터페이스를 서버에 제공하는 것에 관한 것이다.
다른 유형의 하드웨어에 장착되고 다른 유형의 소프트웨어 하에서 동작하는 컴퓨터가 종종 서로 통신해야 할 필요가 있다. 이러한 상황은 클라이언트(즉, 애플리케이션 프로그램 또는 그 컴포넌트)가 프로세싱을 요구하기 위하여 서버에 액세스하거나 데이터에 액세스하는 것을 필요로 하는 경우이다.
일반적으로, "미들웨어"로 공지된 소프트웨어는 이들 상호작용을 용이하게 한다. 다수의 미들웨어 제품은 데이터베이스 및 트랜잭션 시스템 등의 백엔드(backend) 시스템에 대한 접속성(connectivity)의 문제점을 처리한다. 이들 미들웨어 제품은 백엔드 시스템을 액세스하도록 다양한 프로그래밍 모델, 인터페이스 및 프로토콜을 클라이언트에게 제공한다. 특히, 미들웨어는 클라이언트로부터 서버 및 백(back)으로 정보 및 요구를 전달하는 데이터용 콘딧(conduit)으로서 동작할 것이다. 이 방법으로 미들웨어를 사용하는 경우의 문제점은 미들웨어가 주어 진 서버 시스템에 특정되는 경향이 있다는 것이다. 따라서, (특정 서버 유형에 접속된) 한 유형의 미들웨어를 처리하도록 기입된 클라이언트 애플리케이션 (또는 컴포넌트)은 다른 서버 유형과 접속하기 위하여 변경되거나 재기입될 수 있다. 개발자는 클라이언트 애플리케이션이 코드를 기입하기 위하여 상호작용할 각각의 미들웨어 제품의 세부사항을 알 필요가 있다.
Middleware'98에 있는 M. Radestock 및 S. Eisenbach의 논문 "Component Coordination in Middleware System"은 "트랩(trap)"이라 불리우는 시스템을 기술하고 있으며, 여기에서, 하나의 컴포넌트로부터 다른 컴포넌트로의 메시지가 인터셉트(intercept)되고, 변환된 후 의도된 (또는 다른) 컴포넌트로 라우팅될 수 있다. 이 논문은 트랜잭션을 수행하는 컨테이너 및 메시지를 인터셉트하고 재라우팅하는 트랩을 기술하지만, 모든 출력 메시지는 중앙 트랩핑 시스템에 의해 모니터링될 것이 요구되며, 중앙 트랩핑 시스템은 분산된 환경에서 미들웨어 베이스드 시스템(middle-based system)과 상호동작하는 컴포넌트를 조정하기 위한 강력하고 실용적인 자원이다.
본 발명의 양수인에 의해 제출된 캐나다 특허 출원 제 2,232,626 호는 이 문제를 처리하기 위하여 "공통 커넥터 구조(common connector framework)"를 개시한다. 커넥터 아키텍처는 많은 미들웨어 제품의 복잡성으로부터 애플리케이션 컴포넌트의 개발자를 분리하고, 백엔드 시스템을 액세스하도록 클라이언트 애플리케이션에 아웃바운드 커넥터 및 균일한 어프로치(approach)를 제공한다. 이 기술은 미들웨어와 클라이언트 애플리케이션간의 층으로서 동작한다. 클라이언트 애플리케 이션 또는 컴포넌트는 단일 프로토콜(즉, 공통 커넥터 구조에 의해 사용된 그 프로토콜)에 기초하여 출력을 생성하고 입력을 수신하도록 기입될 수 있다. 따라서, 클라이언트 애플리케이션의 견지에서, 클라이언트 애플리케이션이 어느 서버 또는 어느 미들웨어와 상호작용하는지는 문제가 되지 않는다. 대신에, 클라이언트 애플리케이션은 공통 커넥터 구조에 의해 사용된 프로토콜에 맞도록 한번만 기입될 필요가 있다. 공통 커넥터 구조 소프트웨어는 미들웨어와의 인터페이스를 정의할 것이며, 클라이언트 애플리케이션에 의해 사용된 프로토콜과 미들웨어에 의해 사용된 프로토콜 사이의 입력 및 출력 데이터를 변환할 것이다.
캐나다 특허 출원 제 2,232,626 호에 기재된 공통 커넥터 구조는 이들 트랜잭션의 서버측상의 상호작용의 어려움을 처리하지 못한다. 특히, 새로운 서버 애플리케이션을 기입할 때, 개발자는 서버가 상호작용하는 미들웨어의 세부사항을 알 필요가 있다. 이것은 새로운 서버 애플리케이션을 개발하는 어려움을 증가시킬 수 있다. 또한, 서버는 추가의 보안 및 서비스의 품질을 제공해야 하기 때문에, 클라이언트-서버 트랜잭션의 서버측은 좀더 복잡해진다.
서버측에 영향을 주는 또다른 문제가 있다. 기업간 전자 상거래(business-to-business; B2B) 상호작용의 개발은 하나의 비즈니스로부터의 서버가 클라이언트 애플리케이션과만 상호작용하는 것이 아니라 다른 비즈니스로부터 다른 서버와 직접 상호작용할 수 있는 것을 의미하는 것이다. 기업간 전자 상거래 환경에서, 애플리케이션은 다른 애플리케이션과의 기업간 전자 상거래 상호작용을 드라이브할 필요가 있다. 클라이언트 서버 기업간 전자 상거래 애플리케이션은, 다양한 프로 토콜과 미들웨어를 사용하여, 기업간 전자 상거래 서비스를 제공하는 서버 기업간 전자 상거래 애플리케이션과 상호작용을 통신할 것이다. 상호작용이 동일한 조직내에서 클라이언트와 서버사이에서 엄격하면, 서버측과의 상호작용은 미들웨어에 의해 처리되었다. 그러나, 일단 한 회사의 서버가 (다른 하드웨어 및 소프트웨어 구성을 사용할 수 있는) 다른 회사의 서버와 직접 통신할 것을 요구하면, 문제가 발생하기 시작한다. 예를 들어, 모든 비즈니스가 동일한 프로토콜을 사용하는 것이 아니다. 따라서, 다른 미들웨어는 각 유형의 "파트너" 서버와 통신해야 할 필요가 있을 수 있다. 이것은 복잡성을 증가시키고, 새로운 서버 애플리케이션을 개발할 때 미들웨어의 관련 유형에 대한 인식을 요구한다.
클라이언트 애플리케이션 또는 다른 서버의 형태이든, 기존의 미들웨어 시스템에 대한 인식이 서버 애플리케이션을 개발하거나 변경하는데 필요하지 않도록 그 환경에서 서버 시스템의 상호작용을 정의하는 방법이 필요하다. 따라서, 서버측 애플리케이션에 대한 커넥터 아키텍처를 제공하는 것이 바람직하다.
본 발명은 다양한 미들웨어 제품과 애플리케이션 프로그래밍 인터페이스와 상호작용하는 일반 인터페이스를 갖는 컴퓨터 서버를 제공하는 시스템 및 방법에 관한 것이다.
본 발명의 일형태에 있어서,
a) 하나 이상의 서비스 컴포넌트와 하나 이상의 인바운드 커넥터에 서비스를 제공하는 컴포넌트 서버와,
b) 애플리케이션 로직을 제공하는 서비스 컴포넌트 각각과,
c) 복수의 컴퓨터 시스템에 인터페이스 세트를 제공하는 서비스 컴포넌트를 포함하고,
인터페이스 세트는 복수의 컴퓨터 시스템에 의해 호스팅된 미들웨어, 통신 네트워크로 통신하는 인바운드 커넥터, 컴포넌트 서버 및 서비스 컴포넌트에 독립적인 통신 네트워크로 통신하는 통신 시스템이 제공된다.
본 발명의 다른 형태에 있어서,
a) 서비스를 요구하는 단계와,
b) 서비스의 인스턴스가 이용가능하면, 서비스의 인스턴스를 이용하는 단계와,
c) 서비스의 인스턴스가 이용가능하지 않으면, 서비스의 인스턴스를 생성하는 단계를 포함하는 서비스 컴포넌트와 통신하기 위하여 서비스를 확립하는 방법이 제공된다.
본 발명의 다른 형태에 있어서,
a) 하나 이상의 서비스 컴포넌트 및 하나 이상의 인바운드 커넥터에 서비스를 제공하기 위한 컴포넌트 서버에 대한 명령과,
b) 애플리케이션 로직을 제공하기 위하여 명령을 갖는 서비스 컴포넌트의 각각과,
c) 복수의 컴퓨터 시스템에 인터페이스 세트를 구현하기 위하여 명령을 제공하는 서비스 컴포넌트
를 포함하고,
인터페이스 세트는 복수의 컴퓨터 시스템에 의해 호스팅된 미들웨어, 통신 네트워크로 통신하는 인바운드 커넥터, 컴포넌트 서버 및 서비스 컴포넌트에 독립적인 컴퓨터 시스템이 통신 네트워크로 통신하도록 명령을 포함하는 컴퓨터 판독가능 매체가 제공된다.
본 발명은 첨부된 도면을 참조하여 단지 예로서 설명될 것이다.
도 1은 기업간 전자 상거래 시스템의 블록도이다.
도 2는 서버의 컴포넌트의 블록도이다.
도 3은 서버 상의 인바운드 커넥터의 스택을 도시하는 블록도이다.
도 4는 서버 상에서 구현되는 인바운드 커넥터의 컴포넌트의 개략도이다.
도 5는 서비스를 확립하기 위한 인바운드 커넥터의 프로세스를 나타내는 플로우챠트이다.
도 6은 요구를 서비스하기 위한 인바운드 커넥터의 프로세스를 나타내는 플로우챠트이다.
본 발명은 네트워크를 통해 서로 통신하는 클라이언트와 서버간 및 서버 및 서버들간의 상호작용을 간략화하는 시스템 및 방법을 제공한다. 이것은 미들웨어 소프트웨어 및 서버간의 계층으로서 동작하는 인바운드 커넥터를 제공함으로써 달성된다. 인바운드 커넥터는 서버 컴포넌트에 기업간 전자 상거래 상호작용과 통신 하도록 사용되는 미들웨어와 프로토콜의 복잡성으로부터 서버 컴포넌트를 분리시키는 인터페이스 세트를 제공하고, 서버 컴포넌트가 균일한 방법으로 상호작용을 통신하도록 한다. 이것은 다른 유형의 미들웨어를 사용하여 다른 서버와 인터페이스하고 클라이언트와 인터페이스하도록 새로운 서버측 애플리케이션을 개발하는 것을 용이하게 한다.
인바운드 상호작용이 서버에 송신될 때, 그 상호작용의 형태는 송신된 트랜잭션과 미들웨어 계층을 통해 상호작용을 송신한 시스템에 의해 정의될 것이다. 결과적으로, 이 인바운드 상호작용은 많은 형태를 취할 수 있다. 인바운드 커넥터는 서버 애플리케이션이 인바운드 상호작용을 정의하는 특정 미들웨어에 맞도록 기입되거나 변경되지 않고 다양한 소스로부터의 인바운드 상호작용을 효율적으로 핸들링할 수 있도록 서버와 그 환경간의 균일한 인터페이스를 정의할 수 있다.
도 1을 참조하면, 본 발명을 이용하는 기업간 전자 상거래 시스템의 블록도는 일반적으로 10으로서 도시된다. 시스템(10)은 클라이언트(12)와 서버(14)를 포함한다. 기업간 전자 상거래 통신의 시나리오에서, 클라이언트(12)를 "비즈니스 A"로 간주하고, "비즈니스 B"를 서버(14)로 간주한다. 일반적인 상호작용에서, 클라이언트(12)는 서버(14)로부터 정보를 요구한다.
클라이언트(12)는 컴포넌트 서버(16), 서비스프록시(ServiceProxy; 18) 및 아웃바운드 커넥터(20)를 포함한다. 애플리케이션 프로그램("요구자"; 도시하지 않음)은 인터페이스(22)를 통해 (컴포넌트 서버(16)를 통해) 서비스프록시(18)에 요구를 송신하고, 요구를 재포맷한다. 요구는 서버(14)와의 접속 확립 및 필요한 통신 프로토콜 등의 세부사항을 감추기 위하여 재포맷된다.
그후, 서비스프록시(18)는 인터페이스(24)를 통해 아웃바운드 커넥터(20)에 요구를 발송한다. 아웃바운드 커넥터(20)는 적절한 인터페이스와 통신 프로토콜을 사용하여 요구를 패키징하고, 네트워크(28)를 통해 서버(14)에 요구를 송신한다. 요구를 생성할 때, 아웃바운드 커넥터(20)는 인터페이스(26)를 통해 컴포넌트 서버(16)에 의해 제공된 데이터 로깅(data logging) 등의 일반적인 서비스를 사용할 수 있다.
어떤 지점에서, 아웃바운드 커넥터(20)는 네트워크(28)를 통해 서버(14)로부터의 요구에 대한 응답을 수신할 것이다. 그후, 응답은 인터페이스(24)를 통해 서비스프록시(18)로 리턴된다. 서비스프록시(18)는 그후 인터페이스(22)를 통해 그 결과를 요구자에게 리턴한다. 서버(14)는 컴포넌트 서버(30), 인바운드 커넥터(32) 및 서비스 컴포넌트(34)를 포함한다.
컴포넌트 서버(30)는 애플리케이션에 서비스를 제공한다는 점에서 컴포넌트 서버(16)와 유사하다. 그러나, 이 시나리오에서, 이 서버는 요구 애플리케이션(즉, 요구자)이 아니라 요구자에 데이터를 제공하는 애플리케이션이다.
인바운드 커넥터(32)는 네트워크(28)를 통해 아웃바운드 커넥터(20)로부터 요구를 수신한다. 인바운드 커넥터(32)는 그후 요구를 조사하여 서버(14)가 어떤 정보를 제공해야 하는지를 결정한다. 임의의 경우, 커넥터(20)로부터의 요구는 서비스품질(QOS; quality of service) 데이터가 제공되는 것을 요구할 수 있다. 이 경우, 요구가 프로세싱을 위하여 인터페이스(36)를 통해 컴포넌트 서버(30)로 전달 된다. 용어 QOS는 산업상 널리 사용되며 다양한 정의를 취한다. 본 발명에서, 본 발명자는 QOS가 컴포넌트 서버(30)의 QOS(92; 도 4 참조)에 의해 제공된 서비스를 나타내는 것을 의미한다. 이러한 두가지 예는 다음과 같다.
a) 보안, 이 경우 QOS(92)는 데이터를 액세스하는데 허용되는 것만이 보안될 수 있는 것을 보증한다.
b) 트랜잭션의 로깅, 실패 또는 보안 침해가 발생하는 경우, QOS(92)는 트레이스 데이터를 제공한다.
이들 2개의 예는 철저한 리스트를 의미하는 것이 아니라, 단지 본 발명의 QOS(92)에 의해 제공될 수 있는 서비스 유형의 표시이다.
인바운드 커넥터(32)는 그후 특정 서비스 컴포넌트(34)에 요구된 데이터에 관한 정보를 전달하고, 인터페이스(38)를 통해 데이터를 제공할 수 있다. 서비스 컴포넌트(34)는 요구를 만족시키기 위하여 인터페이스(40)를 사용하여 컴포넌트 서버(30)에 의해 제공된 서비스를 이용할 수 있다.
요구의 결과는 서비스 컴포넌트(34)에 의해 인바운드 커넥터(32)로 리턴되고 네트워크(28)를 통해 커넥터(20)로의 전송을 위해 재포맷된다.
여기에 개시된 인바운드 커넥터(32)는 서비스 컴포넌트(34)를 위한 잘 정의되고 지속적인 인터페이스(38)를 제공한다. 본 발명의 인터페이스(38)는 통신을 허용하는 데 사용되는 미들웨어 및 애플리케이션 프로그래밍 인터페이스(API)의 복잡성을 줄인다. 특히, 서비스 컴포넌트(34)는 상이한 미들웨어 프로그램의 다양한 API와의 인터페이스를 필요로 하지 않는다. 대신에, 서비스 컴포넌트(34)는 동일 한 인터페이스 호출을 구현하여 클라이언트로부터 요구를 획득하고, 요구를 실행하고, 클라이언트에 의해 사용된 소프트웨어 또는 플랫폼에 관계없이 응답을 리턴한다.
인터페이스(36)는 인바운드 커넥터(32)가 컴포넌트 서버(30)에 의해 제공되는 에러 핸들링, 트레이스 로깅, 보안 제어 또는 원격 액세스 서비스(RAS) 등의 인프라스트럭쳐 서비스를 사용할 수 있도록 허용한다. 유사한 구조가 인터페이스(26)를 갖는 컴포넌트 서버(16)에 사용된다.
인바운드 커넥터(32)와 아웃바운드 커넥터(20)는 별개의 엔티티이고, 주어진 서버가 (즉, 상황에 의존하는 상이한 역할에서) 클라이언트와 서버로서 동작하면 인바운드 커넥터와 아웃바운드 커넥터 양자 모두가 필요하다. 이것은 아웃바운드 및 인바운드 상호작용에 대하여 상이한 API가 있기 때문이며, 대부분의 프로토콜은 통신 자원이 재사용되는 것을 허용하지 않는다(인터내셔널 비즈네스 머신즈 코오포레이션에 의해 제공된 MQSeries 및 선 마이크로시스템즈에 의해 제공된 Java Message Service 등의 임의의 것은 이것을 허용한다). *MQSeries는 인터내셔널 비즈네스 머신즈 코오포레이션의 상표이고 Java는 선 마이크로시스템즈의 상표이다. 따라서, 특정 시스템이 클라이언트로서만 기능하면, 아웃바운드 커넥터(20)만이 필요하고, 서버로서만 기능하면, 인바운드 커넥터(32)만이 요구된다. 그러나, 시스템이 클라이언트 및 서버 양자로서 기능하면, 아웃바운드 커넥터(20)와 인바운드 커넥터(32)를 가져야 한다.
클라이언트(12) 상의 인터페이스(24) 및 서버(14) 상의 인터페이스(38)는 동 일한 것이 바람직하다. 특히, 클라이언트(12) 상의 이 인터페이스의 구현이 서버(14) 상의 인터페이스의 구현과 상이할 수 있지만, 인보크(invoke)되는 방법, 전달되고 리턴되는 엘리먼트의 관점에서 동일한 인터페이스가 인터페이스(24 및 38)용으로 사용되는 것이 바람직하다. 인터페이스(24, 38)가 동일하면, 네트워크(28)는 투과하게 되고 서비스프록시(18)가 서비스 컴포넌트(34)를 직접 호출하는 것처럼 개발될 수 있다. 반면에, 서버(14) 상의 인터페이스(38)가 클라이언트(12) 상의 인터페이스(24)와 상이하면, 클라이언트 애플리케이션은 이들 차이점을 처리해야 하며, 이것은 복잡성을 증가시키고 클라이언트 애플리케이션을 개발하고 변경하는 것을 더 어렵게 한다. 그러나, 서버(14)에 대한 애플리케이션의 개발 및 변경에 인바운드 커넥터(32)를 사용하는 이점은 서버(14) 상의 인터페이스(38)와 동일한 인터페이스가 클라이언트(12) 상의 인터페이스(24)용으로 사용되는지에 관계없이 존재하고, 아웃바운드 커넥터(20)가 클라이언트(12) 상에서 사용되지 않을때 조차도 존재할 것이다.
인터페이스(36)를 통해 잘 정의된 세트의 시스템 계약 인터페이스를 사용하여 컴포넌트 서버(30)로부터 서비스를 요구할 수 있으므로, 아키텍처는 실행되는 플랫폼과 독립적으로 인바운드 커넥터(32)의 구현을 허용한다. 마찬가지로, 컴포넌트 서버(30)가 임의의 인바운드 커넥터(32)에 의해 사용될 수 있는 (접속 및 트랜잭션 관리 등의) 일반적인 서비스를 제공할 수 있으므로, 컴포넌트 서버(30)가 특정 인바운드 커넥터 구현(32)의 세부사항과 관련될 필요는 없다. 컴포넌트 서버(30)와 인바운드 커넥터(32)사이 및 컴포넌트 서버(30)와 서비스 컴포넌트(34) 사이의 인터페이스(36, 40)가 동일하다.
인바운드 커넥터(32)는 인터페이스(36)를 구현하는 한 세트의 클래스로 구성되고 특정 프로토콜을 사용하여 다른 애플리케이션과의 통신을 허용하도록 임의의 필요한 미들웨어 및 API를 사용한다. 커넥터(32)의 구현은 미들웨어 또는 프로토콜의 각각의 유형에 대하여 상이하지만, 인터페이스(36, 38)는 동일하다. 이것은 미들웨어 및 API의 복잡성으로부터 서비스 컴포넌트(34)를 분리하는 특징이며, 따라서, 서버 애플리케이션의 개발 및 변경을 상당히 간략화시킨다.
도 2를 참조하면, 서버의 컴포넌트의 블록도가 14로서 도시된다. 도 1에 관련하여 설명한 바와 같이, 서버(14)는 컴포넌트 서버(30), 인바운드 커넥터(32) 및 서비스 컴포넌트(34)를 포함한다.
기업간 전자 상거래 애플리케이션에 사용되는 통신 프로토콜은 상호작용을 통신하기 위하여 확장 마크업 언어(XML)로 표시되는 "엔벨로프(envelope)" 및 "페이로드(payload)"로서 단순 객체 접근 프로토콜(SOAP) 컨텍스트에서 일반적으로 지칭되는 것을 사용한다. 특히, 도 2에 도시된 XML 통신은 요구 엔벨로프(50)(클라이언트(12)로부터 서버(14)로의 입력 통신) 및 응답 엔벨로프(52)(서버(14)로부터 클라이언트(12)로의 출력 통신)의 형태를 취한다. 요구 엔벨로프(50)는 요구 페이로드(54)를 포함하고, 응답 엔벨로프(52)는 응답 페이로드(56)를 포함한다. 요구 엔벨로프(50) 및 응답 엔벨로프(52)는 서비스 품질(QOS) 엘리먼트(58, 60) 뿐만 아니라 프로토콜 특정 정보를 각각 포함하는 반면, 요구 페이로드(54) 및 응답 페이로드(56)는 애플리케이션 데이터를 포함한다. 서비스 품질 소자(58, 60)는 일반적 으로 컨텍스트 및 자원 조정 엘리먼트 뿐만 아니라 보안 정보를 포함한다. 애플리케이션 데이터가 서비스 컴포넌트(34)에 전달되기 전에 컴포넌트 서버(30) 상에서 프로세싱될 필요가 있다.
인바운드 커넥터(32)는 요구 엔벨로프(50)로부터 QOS 소자(58)를 추출하고 임의의 요구된 프로세싱을 실행할 책임이 있으며, 일반적으로 컴포넌트 서버(30)와 관련된다. 인바운드 커넥터(32)는 잘 정의된 인터페이스(36)를 사용하여 컴포넌트 서버(30)로부터 서비스를 인보크하므로 플랫폼과 독립적으로 이 프로세싱을 구현할 수 있다.
클라이언트(12)로부터 HTTP(HyperText Treansfer Protocol)를 사용하여 요구가 전송되는 인바운드 커넥터(12)의 사용에 대하여 설명된다. 인바운드 커넥터(32)는 HTTP를 구현하고, 클라이언트(12)와 서버(14)가 통신 프로토콜로서 HTTP를 사용하여 기업간 전자 상거래 애플리케이션을 구현하도록 허용한다. 컴포넌트 서버(30)는 서비스 컴포넌트(34)에 의해 요구된 런타임(runtime) 환경(예를 들어, 자바 서비스 컴포넌트(34)를 위한 자바 가상 머신(Java Virtual Machine)) 및 인프라스트럭처 서비스를 제공하고, 인바운드 커넥터(32)는 컴포넌트 서버(30)로의 인터페이스(36)를 통해 QOS의 프로세싱 및 클라이언트 애플리케이션과의 통신을 핸들링한다. 서비스 컴포넌트(34)는 서비스로서 노출될 필요가 있는 (애플리케이션 로직으로서 수행되는) 비즈니스 기능을 제공한다.
서버(14) 상의 정보의 흐름은 다음과 같다. 요구 엔벨로프(50)를 포함하는 클라이언트(12)로부터의 서비스 요구는 HTTP를 사용하여 송신되어 인바운드 커넥터(32)에 의해 수신된다. 인바운드 커넥터(32)는 요구 엔벨로프(50)를 수신하고 QOS 소자(58) 및 요구 페이로드(54)를 추출한다. 인바운드 커넥터(32)는 그후 요구 엔벨로프(50)로부터 추출된 QOS 소자(58)를 프로세싱힌다. 특히, 인바운드 커넥터(32)는 인터페이스(36)를 사용하여 보안 컨텍스트의 셋업 또는 트랜잭션의 시동 등의 컴포넌트 서버(30)로부터의 서비스를 요구한다. 인바운드 커넥터(32)는 그후 인터페이스(38)를 사용하여 요구 페이로드(54)에 포함된 애플리케이션 데이터를 서비스 컴포넌트(34)에 전달한다. 서비스 컴포넌트(34)는 요구 페이로드(54)에 포함된 애플리케이션 데이터를 수신하고 요구된 임의의 애플리케이션 로직을 실행한다. 요구 페이로드(54)에 포함된 애플리케이션 데이터의 프로세싱동안, 서비스 컴포넌트(34)는 또한 인터페이스(40)를 통해 컴포넌트 서버(30)로부터의 인프라스트럭처 서비스를 사용할 수 있다. 일반적으로, 서비스 컴포넌트(34)는 QOS 소자(58)를 프로세싱할 때 인바운드 커넥터(32)에 의해 설정된 보안 컨텍스트 또는 자원 조정 컨텍스트를 사용할 것이다. 서비스 컴포넌트(34)는 인터페이스(38)를 통해 응답을 인바운드 커넥터(32)에 리턴시키고, 응답 페이로드(56)로서 응답을 패키징한다. 인바운드 커넥터(32)는 인터페이스(36)를 통해 컴포넌트 서버(30)로부터 임의의 필요한 QOS 소자(60)를 얻고, 그후 응답 엔벨로프(52)의 응답 페이로드(56)에 따라 이들 QOS 소자(60)를 패키징한다. 응답 엔벨로프(52)의 QOS 엘리먼트(60)가 필요하지 않을 수 있다. QOS 소자가 필요한 경우, QOS 소자는 보안 또는 트랜잭션 정보일 수 있다. 응답 엔벨로프(52)는 그후 클라이언트(12)에 리턴된다.
바람직한 실시예에서, 기업간 전자 상거래 애플리케이션은 동일한 서비스 세트를 HTTP를 사용하여 클라이언트에게 제공할 수 있고 인터내셔널 비즈네스 머신즈 코오포레이션에 의해 제공된 MQSeries 등의 메시징 미들웨어를 사용하여 메시징 애플리케이션에 제공할 수 있다. 이들의 다양한 프로토콜 및 미들웨어 제품을 수용하기 위하여, 인바운드 커넥터(32)의 아키텍처는 상이한 전송 프로토콜의 상부 상에서 동일한 인터페이스(38)를 구현하도록 인바운드 커넥터가 스택되도록 한다.
도 3은 서버(14) 상의 인바운드 커넥터(32)의 스택을 나타내는 블록도이다. 특히, 도 3은 HTTP를 통해 단순 객체 접근 프로토콜(SOAP)를 구현하기 위하여 인바운드 커넥터(32)를 사용하는 것을 나타낸다. HTTP는 전송 프로토콜이고, SOAP는 기업간 전자 상거래 교환에 사용되는 고레벨 프로토콜이고, 이는 선 마이크로시스템즈에 의해 제공된 HTTP, SMTP(Simple Mail Transfer Protocol) 또는 JMS(Java Message Service) 등의 다양한 전송 프로토콜을 통해 사용될 수 있다.
서버(14)는 복수의 인바운드 커넥터(32)를 포함할 수 있고, 인바운드 커넥터의 각각은 상이한 유형의 통신 프로토콜을 핸들링한다. 특히, 하나의 프로토콜을 구현하는 인바운드 커넥터(32)가 상이한 프로토콜을 구현하는 또다른 인바운드 커넥터(32)에 요구를 전달할 수 있도록 인바운드 커넥터(32)는 계층화될 수 있다.
도 3에 도시된 바와 같이, 인바운드 커넥터(32a)는 HTTP를 구현하고, 인바운드 커넥터(32b)는 SOAP를 구현한다. 따라서, 도 3에서, HTTP 요구 페이로드(54)는 실제적으로 SOAP 요구 엔벨로프(54)이다. 서버(14)가 요구를 수신하면, 인바운드 커넥터(32a)는 HTTP 요구 엔벨로프(50)를 개방하고 대응하는 QOS 소자(58)를 프로 세싱한 후 요구 페이로드(54)(SOAP 요구 엔벨로프(54))를 인터페이스(38a)를 통해 다음의 인바운드 커넥터(32b)에 전달한다. 인바운드 커넥터(32b)는 HTTP 페이로드(54)(SOAP 요구 엔벨로프(54))를 수신하고, SOAP 요구 엔벨로프(54)를 개방하고 대응하는 QOS 소자(62)를 프로세싱한 후 (만약에 있다면) SOAP 요구 엔벨로프(54)에서 탐색한 SOAP 요구 페이로드(64)를 다음의 인바운드 커넥터(32)에 전달한다. 도 3에서와 같이, 인바운드 커넥터(32b)가 인바운드 커넥터(32)의 스택에서 가장 낮으면, 인바운드 커넥터(32b)는 SOAP 요구 페이로드(64)를 추출하고 그것을 서비스 컴포넌트(34)에 직접 전달한다. 인바운드 커넥터(32)가 임의의 프로토콜과 일치할 수 있고 임의의 수의 인바운드 커넥터가 본 발명을 벗어나지 않고 스택될 수 있음을 당업자는 이해할 것이다.
HTTP를 통한 SOAP를 사용하여 서버(14)에 서비스 요구를 송신할 때 도 3에 도시된 기능의 논리적 흐름은 다음과 같다. HTTP 인바운드 커넥터(32a)는 HTTP 요구 엔벨로프(50)의 형태로 HTTP의 서비스 요구를 수신한다. HTTP 인바운드 커넥터(32a)는 그후 HTTP 요구 엔벨로프(50)로부터 QOS 소자(58) 및 HTTP 요구 페이로드(54)(SOAP 요구 엔벨로프(54))를 추출한다. HTTP 인바운드 커넥터(32a)는 인터페이스(36a)를 사용하여 추출된 QOS 소자(58)를 프로세싱한다. 그후, HTTP 인바운드 커넥터(32a)는 인터페이스(38a)를 사용하여 HTTP 요구 페이로드(54)(SOAP 요구 엔벨로프(54))를 SOAP 인바운드 커넥터(32b)에 전달한다. 그후 SOAP 인바운드 커넥터(32b)는 인터페이스(36b)를 사용하여 SOAP 특정 QOS 소자(62)를 추출하고 그들을 프로세싱한다. 그후, 인바운드 커넥터(32b)는 SOAP 요구 페이로드(64)를 추출하고 그 요구 페이로드를 서비스 컴포넌트(34)로 전달하고, 여기서 임의의 요구된 애플리케이션 로직을 실행한다. 그후, 서비스 컴포넌트(34)는 인터페이스(38b)를 통해 응답을 SOAP 인바운드 커넥터(32b)로 리턴시킨다. 그후, SOAP 인바운드 커넥터(32b)는 인터페이스(36b)를 사용하여 임의의 필요한 QOS 소자(66)를 얻고 이들 QOS 소자를 SOAP 응답 엔벨로프(56)내의 SOQP 응답 페이로드(68)와 함께 패키징한다. 그후, SOAP 응답 엔벨로프(56)는 HTTP 인바운드 커넥터(32a)에 리턴되고, HTTP 응답 페이로드(56)로서 HTTP 응답 엔벨로프(52)에 배치된다. 그후, HTTP 인바운드 커넥터(32a)는 인터페이스(36a)를 사용하여 QOS 소자(60)를 HTTP 응답 엔벨로프(52)에 부가한 후 HTTP를 사용하여 HTTP 응답 엔벨로프(52)를 클라이언트(12)에 다시 송신한다.
HTTP 인바운드 커넥터(32a)와 SOAP 인바운드 커넥터(32b) 사이의 인터페이스(38a)는 SOAP 인바운드 커넥터(32b)와 서비스 컴포넌트(34) 사이의 인터페이스(38b)와 동일하다. 이것은 인바운드 커넥터의 사용에 유연성을 부여한다. 필요하다면, 어느 프로토콜이 사용되는지에 의존하여 계층화된 상이한 인바운드 커넥터를 사용할 수 있고, 상호작용은 어떤 프로토콜이 송신에 사용되는지에 관계없이 궁극적으로 동일한 인터페이스(38)를 사용하여 서비스 컴포넌트(34)에 전달될 것이다.
도 4는 서버(14) 상에서 구현되는 인바운드 커넥터(32)의 컴포넌트의 개략도이다. 인바운드 커넥터(32)의 구현은 다음의 클래스 및 관련 인터페이스를 포함한다: 서비스팩토리(ServiceFactory; 80), 서비스(82), 매니지드서비스팩토리(ManagedServiceFactory; 84), 매니지드서비스(ManagedService; 86) 및 매니지드서비스 프로세싱 규격(ManagedServiceProcessingSpec; 87). 또한, 컴포넌트 서버(30)는 QOS 서비스(92) 뿐만 아니라 서비스 매니저(ServiceManager; 88), 서비스 이벤트 리스너(ServiceEventListener; 90)의 클래스를 구현한다. 또한 (Java 예외 메카니즘을 사용하여) 에러를 보고하는 데 사용되는 예외 클래스인 서비스 예외(ServiceException; 도 4에 도시하지 않음)이 있다. 이들 클래스는 함께 발명자가 "프로세싱 코어"로 지칭하는 것을 형성한다.
서비스팩토리 클래스(80)는 서비스(82)의 인스턴스(instance)를 생성할 수 있는 객체를 나타낸다. 그러나, 서비스팩토리(80)는 서비스(82)의 인스턴스에 관한 참조를 유지하지 않는다. 서비스팩토리(80)는 서비스 매니저(88)와 동작하여 클라이언트(12)로의 물리적 접속에 대한 핸들의 풀(pool of handles)을 할당하고 제어한다. 특히, 서비스팩토리(80)의 인스턴스는 서비스 매니저(88)에 대한 참조를 유지하고 매니지드서비스팩토리(84)와 관련된다. 서비스팩토리(80)는 서비스 매니저(88)의 할당 서비스 방법(allocateService method)을 인보크함으로써 서비스(82)의 인스턴스를 얻는다(이에 대해서는 후술함). 서비스팩토리(80)에 대한 인스턴스는 다음과 같다.
public interface ServiceFactory extends java.io.Seriallizable {
Service getService();
}
서비스(82)는 클라이언트(12)로의 물리적 접속에 대한 핸들을 나타낸다. 서비스(82)의 인스턴스는 서비스 매니저(88)의 할당 서비스 방법을 인보크함으로써 서비스팩토리(80)에 의해 생성된다. 서비스(82)의 인스턴스는 매니지드서비스(86)의 인스턴스와 관련된다. 서비스(82)는 클라이언트(12)로부터의 상호작용 요구를 수신하고 그 요구를 관련된 (타겟 서비스 컴포넌트(34)를 인보크하는) 매니저 서비스(86)에 전달하고, 매니지드서비스(86)로부터 응답을 송신한다. 서비스(82)는 다음의 인터페이스를 갖는다.
public interface Service{
public javax.resource.cci.Record execute(
javax.resource.cci.InteractionSpec interactionSpec,
javax.resource.cci.Record inputRecord)
throws javax.resource.ResourceException;
public Boolean execute{
javax.resource.cci.InteractionSpec interactionSpec,
javax.resource.cci.Record inputRecord,
javax.resource.cci.Record outputRecord)
throws javax.resource.ResourceException;
}
서비스(82)는 인바운드 커넥터(32) 및 서비스 컴포넌트(34)에 의해 구현된다. 서비스(82)의 실행 방법은 인바운드 커넥터 상호작용을 실행한다. 매니지드 서비스(86)는 매니지드서비스 프로세싱 규격(87)의 상호작용 규격 획득(getInteractionSpec) 방법을 호출하여 상호작용 규격(InteractionSpec)을 얻는다. 상호작용 규격은 상호작용의 세부사항을 특정하는 특성을 포함한다. 특성 세트는 커넥터 특정이다. 예를 들어, HTTP 커넥터는 콘텐츠, 헤더 필드, 법(verb)(예를 들어, GET 또는 POST)의 유형 등의 HTTP 특정 특성을 갖는다. 그것은 인바운드 커넥터(32)가 적절한 서비스 컴포넌트(34)를 선택하도록 하는 상호작용 규격의 콘텐츠이다. 매니지드서비스(86)는 그후 상호작용 규격을 서비스(82)의 실행 방법에 전달한다. 서비스(82)의 실행 방법의 입력 레코드(inputRecord)는 상호작용 요구 데이터를 포함한다. 서비스(82)의 실행 방법으로부터의 리턴에서, 실행 방법의 출력 레코드(outputRecord)는 임의의 상호작용 응답 데이터를 포함한다. 서비스 컴포넌트(34)는 적절한 애플리케이션 로직을 수행함으로써 서비스(82)의 실행 방법을 구현한다. 본 발명자에 의하면, 애플리케이션 로직이 실행 방법을 구현할 필요가 있는 로직을 의미한다. 일반적으로, 개발자는 상호작용 규격 및 데이터 입력 레코드를 고찰하여 요구된 기능을 구현한다(예를 들어 데이터베이스를 질의하거나 파일을 업데이트한다). 인바운드 커넥터(32)는 커넥터 특정 방법에서 (즉, 호출 시퀀스, 방법 이름 및 다른 구현 팩터의 관점에서 특정 커넥터 구현의 특성) 매니지드서비스(86)의 관련된 인스턴스에 상호작용을 델리게이트(delegate)함으로써 서비스 클래스(82)의 실행 방법을 구현한다. 이 구조는 인바운드 커넥터(32)의 구현이 관련된 매니지드서비스(86)를 이용하도록 허용하여 그들의 요구를 가장 충족하도록 한다.
매니지드서비스팩토리(84)는 매니지드서비스(86)의 인스턴스를 생성할 수 있는 클래스이다. 매니지드서비스팩토리(84)의 인터페이스는 다음과 같다.
public interface ManagedServiceFactory extends java.io.Serializable {
ManagedService createManagedService();
Object createServiceFactory();
Object createServiceFactory(ServiceManager serviceManager);
}
매니지드서비스팩토리(84)는 서비스팩토리(80)의 인스턴스 뿐만 아니라 매니지드서비스(86)의 인스턴스를 생성할 수 있는 객체를 나타낸다. 그러나, 매니지드서비스팩토리(84)는 생성된 매니지드서비스(86)에 대한 참조를 유지하지 않는다. 매니지드서비스팩토리(84)의 매니지드서비스 생성(createManagedService) 방법은 매니지드서비스(86)의 인스턴스를 생성한다. 매니지드서비스팩토리(84)의 서비스팩토리 생성(createServiceFactory) 방법은 매니지드서비스팩토리의 인스턴스와 관련된 서비스팩토리(80)의 새로운 인스턴스를 생성하고 서비스 매니저(88)의 인터페이스의 인스턴스를 생성된 서비스팩토리(80)에 전달한다.
매니지드서비스(86)는 서비스 컴포넌트(34)에 대한 접속 핸들을 나타낸다. 매니지드서비스(86)의 인스턴스는 매니지드서비스팩토리(84)에 의해 생성된다. 본 발명의 구현에서, 서비스(82)의 하나의 인스턴스만이 한번에 서비스 컴포넌트(34)와 상호작용할 수 있지만, 매니지드서비스(86)는 다수의 서비스(82)를 지원할 수 있다. 다수의 스레드(thread)의 사용 및 동시 사용자가 가능하지만, 발명자는 바 람직한 실시예에서 이 기능을 제공하지 않도록 선택함을 당업자는 인식할 것이다. 매니지드서비스(86)는 입력 요구로부터 임의의 QOS 소자를 추출하고 서비스 이벤트 리스너(ServiceEventListener; 90)를 통해 임의의 QOS 요구사항을 컴포넌트 서버(30)에 통지한다. 컴포넌트 서버(30)는 서비스 이벤트 리스너(90)로부터의 요구를 핸들링하도록 QOS(92)의 임의의 인스턴스를 생성한 후 매니지드서비스팩토리(84) 및 매니지드서비스(86)를 인보크한다. 매니지드서비스팩토리(84)는 매니지드서비스(86)의 인스턴스의 풀(pool)을 형성하기 위하여 QOS(92)를 이용한다. 따라서, 매니지드서비스(86)의 인스턴스가 풀에 존재하고 QOS(92)에 의해 지정된 특정 보안 또는 다른 트랜잭션 특성을 충족하면, 그 인스턴스가 사용될 것이다. 매니지드서비스(86)가 QOS(92)의 요구사항을 충족하지 않으면, 매니지드서비스(86)의 새로운 인스턴스가 매니지드서비스팩토리(84)에 의해 생성될 것이다. 매니지드서비스(86)는 QOS(92)에서 지정된 임의의 보안을 프로세싱하기 위하여 서비스 이벤트 리스너(90)의 인증 방법을 사용한다. 매니지드서비스(86)는 다음의 인터페이스를 갖는다.
public interface managedService {
void addServiceEventListener(ServiceEventListener serviceEventListener)
;
java.io.PrintWriter getLogWriter();
java.lang.Object getService();
void removeServiceEventListener(ServiceEventListener serviceEvent Listener);
void setLogWriter(java.io.PrintWriter logWriter)'
}
매니지드서비스(86)는 서비스 컴포넌트(34)와의 상호작용을 핸들링하는 객체를 포함한다. 매니지드서비스(86)는 매니지드서비스 프로세싱 규격(87)의 서비스팩토리 획득(getServiceFactory) 방법을 호출하고, 매니지드서비스팩토리(84)의 서비스팩토리 생성(createServiceFactory) 방법을 호출함으로써 서비스팩토리(80)의 인스턴스를 제공한다. 그후, 매니지드서비스(86)는 서비스팩토리(80)의 서비스 획득(getService) 방법을 호출하고, 서비스(82)의 새로운 인스턴스를 리턴한다. 서비스(82)의 실행 방법을 인보크하고 타겟 서비스 컴포넌트(34)에 필요한 정보를 전달하기 위하여, 매니지드서비스(86)는 입력 레코드, 출력 레코드 및 상호작용 규격(상호작용의 커넥터 지정 특성을 포함)을 요구한다. 매니지드서비스(86)는 입력 레코드 및 출력 레코드를 가지며, 매니지드서비스 프로세싱 규격(87)의 참조를 통해 상호작용 규격을 얻는다. 일단 상호작용 규격을 구하면, 매니지드서비스(86)는 모든 필요한 데이터를 가지며 서비스(82)의 실행 방법을 통해 서비스 컴포넌트(34)에 데이터를 전달할 수 있다.
매니지드서비스(86)의 서비스 이벤트 리스너 부가(addServiceEventListener) 방법이 서비스 매니저(88)에 의해 사용되어 매니지드서비스(86)로 서비스 이벤트 리스너(90)를 등록한다. 매니지드서비스(86)는 (예를 들어, 인바운드 상호작용이 프로세싱될 수 있기 전에, 인증이 필요하면)임의의 QOS 관련 이벤트를 모든 서비스 이벤트 리스너(90)에 통지할 것이다.
매니지드서비스 프로세싱 규격(87)은 상호작용 규격 및 서비스팩토리(80)에 대한 참조를 유지하는데 사용되는 클래스이다. 매니지드서비스 프로세싱 규격 클래스(87)는 다음의 인터페이스를 갖는다.
public interface ManagedServiceProcessingSpec extends java.io.Serializable {
javax.resource.cci.InteractionSpec getInteractionSpec();
com.ibm.service.cci.ServiceFactory getServiceFactory();
void setInteractionSpec(javax.resoruce.cco.InteractionSpec interactionSpec);
void setServiceFactory (com.ibm.service.cci.ServiceFactory serviceFactory);
}
매니지드서비스 프로세싱 규격(87)은 본 발명의 구현자에 의해 선택된 수단에 의해 초기화된다. 일반적으로 이것은 구성 또는 전개 기술어(deployment descriptor)를 통해 수행될 수 있다.
서비스 매니저(88)는 인바운드 커넥터를 지원하기 위하여 컴포넌트 서버(30)에 의해 구현된 클래스이다. 서비스 매니저(88)는 서비스(82)에 의해 사용된 자원을 조정하고 제어하는 능력을 컴포넌트 서버(30)에 제공한다. 서비스 매니저(88)는 다음의 인터페이스를 갖는다.
public interface ServiceManager extends java.io.Serializable {
java.lang.Object allocateService(ManagedServiceFactory managedServiceFactory);
}
서비스 매니저(88)의 allocateService 방법은 인바운드 커넥터(32)를 위한 방법을 제공하여 서비스 할당 요구를 컴포넌트 서버(30)에 전달한다. 컴포넌트 서버(30)는 보안, 트랜잭션 관리 또는 서비스 요구에 대한 로깅 등의 서비스 품질(QOS; 92)를 제공하고, 그후 서비스(82)의 인스턴스의 실제 생성을 매니지드서비스팩토리(84)에 델리게이트한다.
서비스 이벤트 리스너(90)는 인바운드 커넥터(32)를 지원하기 위하여 컴포넌트 서버(30)에 의해 구현된 클래스이다. 서비스 이벤트 리스너(90)는 매니지드서비스(86)의 인스턴스로부터 이벤트를 수신하고 임의의 요구된 QOS(92)의 셋업 또는 핸들 등의 컴포넌트 서버(30)내의 대응하는 액션을 구현한다. 서비스 이벤트 리스너(90)의 인터페이스는 다음과 같다.
public interface ServiceEventListener extends java.util. EventListener {
void authenticate(javax.security.auth.Subject subject)
throws com.ibm.service.ServiceException;
}
서비스 이벤트 리스너(SeviceEventListener; 90)의 인터페이스는 매니지드서 비스(86)의 인스턴스로부터 QOS 관련 이벤트를 수신하도록 한다. 서비스 이벤트 리스너(90)의 인스턴스는 매니지드서비스(86)의 서비스 이벤트 리스너 부가(addServiceEventListener) 방법을 사용하여 매니지드서비스(86)로 등록된다. 매니지드서비스(86)는 서비스 이벤트 리스너(90)의 인증 방법을 인보크하고, 서비스(82)의 실행 방법을 인보크하고 타겟 서비스 컴포넌트(34)에 상호작용을 전달하기 전에 인바운드 상호작용을 인증한다.
서비스 예외(ServiceException) 클래스는 자바 예외 클래스를 확장하고 인바운드 커넥터 에러를 보고하는 데 사용된다. 서비스 예외 클래스는 다수의 클래스에 의해 런타임시에 잠재적으로 사용되고 도 4에는 도시되어 있지 않다. 서비스 예외 클래스(91)의 인터페이스는 다음과 같다.
public class ServiceException extends Exception {
public ServiceException();
public ServiceException(String s);
}
도 5를 참조하면, 서비스(82)를 확립하기 위하여 인바운드 커넥터(32)의 프로세스를 나타내는 플로우챠트가 일반적으로 100으로 도시된다.
단계(102)에서 시작하여, 매니지드서비스(86)는 매니지드 프로세싱 규격(87)의 서비스팩토리 획득(getServiceFactory) 방법을 호출하고, 매니지드서비스팩토리(84)의 서비스팩토리 생성(createServiceFactory) 방법을 호출함으로써 서비스팩토리(80)의 인스턴스를 생성한다. 단계(104)에서, 매니지드서 비스(86)는 매니지드서비스팩토리(84)의 서비스 획득 방법을 호출한다. 단계(106)에서, 서비스팩토리(80)는 서비스 매니저(88)의 서비스 할당(allocateService) 방법을 인보크한다. 단계(108)에서, 이러한 인스턴스의 풀에서 매니지드서비스(86)의 사용하지 않은 인스턴스가 존재하는지를 판정하는 테스트가 수행된다. 인스턴스가 없으면, 프로세싱은 단계(110)로 진행하여, 매니지드서비스팩토리(84)는 매니지드서비스(86)의 새로운 인스턴스를 생성하고, 단계(112)로 진행한다. 단계(108)에서의 테스트가 인스턴스가 존재하는 것을 가리키면, 인스턴스가 사용되어 프로세싱은 단계(212)로 진행한다. 단계(112)에서, 매니지드서비스(86)는 서비스팩토리(80)의 서비스 획득 방법을 호출하여 서비스(82)의 새로운 인스턴스를 생성한다.
매니지드서비스(86)의 풀링(pooling)에 관하여, 서비스 매니저(88)는, 생성되고 사용된 후 해제된 각각의 매니지드서비스(86)의 리스트를 유지한다(즉, 매니지드서비스는 요구를 서비스하는데 사용되지 않는다). 더이상 필요로 하지 않을 때 매니지드서비스(86)를 폐기하는 대신에, 서비스 매니저(88)는 매니지드서비스(86)를 폐기하는 대신에, 서비스 매니저(88)는 매니지드서비스를 저장하고 필요할 때 매니지드서비스를 재사용하고, 따라서, 매니지드서비스(86)의 새로운 인스턴스를 생성할 필요성을 감소시키고, 컴포넌트 서버(30)의 효율을 개선한다. 제안된 아키텍처는 단순히 풀링을 제안하는 것이지만 이것을 강요하는 것은 아니며, 각각의 서비스 매니저 클래스(88)를 구현하는 사람에게 이 풀링을 강요할지에 대하여 결정하도록 함을 당업자는 이해할 것이다.
도 6을 참조하면, 요구를 서비스하기 위하여 인바운드 커넥터(32)의 프로세스를 나타내는 플로우챠트가 일반적으로 200으로 도시된다. 단계(202)에서 시작하면, 매니지드서비스(88)는 단계(204)에서 매니지드서비스 프로세싱 규격(87)으로부터 상호작용 규격의 인스턴스를 얻는다. 그후, 매니지드서비스(88)는 실행의 파라미터로서 상호작용 규격의 인스턴스를 전달하는 서비스(82)의 실행 방법을 호출한다. 단계(206)에서, 타겟 서비스 컴포넌트(34)가 선택된다. 단계(208)에서, 타겟 서비스 컴포넌트(34)의 애플리케이션 로직이 입력 인수(argument)만으로 실행 방법의 호출 포맷(invocation format)을 지원하는지에 대한 결정을 수행한다. 지원되지 않는 예외가 있으면, 단계(210)에서 매니지드서비스(86)는 출력 레코드를 생성하고 이것을 실행 방법에 전달하고, 프로세싱은 단계(206)로 리턴한다. 단계(208)에서 예외가 없으면, 프로세싱은 단계(212)로 진행하고, 이 단계에서, 결과가 얻어지고 매니지드서비스(86)로 리턴한다.
도 5 및 도 6에 도시된 특정 시나리오에서, 커넥터의 스택(stackablility; 도 3 참조)가 도시되어 있지 않다. 인바운드 커넥터(32)의 스택은, 모든 커넥터(32)가 프로세싱을 완료할 때까지 스택내의 각각의 인바운드 커넥터(32)에 대하여 도 5 및 도 6에 도시된 시퀀스가 수행되는 것을 의미한다.
여기에 개시된 발명은 자바를 위한 J2EE 커넥터 아키텍처의 컨텍스트로 설명되었지만, 당업자는 본 발명이 다른 환경 및 프로그래밍 언어에 용이하게 적용될 수 있고 이러한 적응이 청구범위에 의해 정의된 본 발명의 범위 이내에 있음을 이해할 것이다.

Claims (14)

  1. 통신 네트워크로 통신하는 컴퓨터 시스템에 있어서,
    a) 하나 이상의 서비스 컴포넌트와 하나 이상의 인바운드 커넥터에 서비스를 제공하는 컴포넌트 서버와,
    b) 애플리케이션 로직을 제공하는 각각의 상기 서비스 컴포넌트와,
    c) 복수의 컴퓨터 시스템에 인터페이스 세트 - 상기 인터페이스 세트는 상기 복수의 컴퓨터 시스템에 의해 호스팅된 미들웨어, 상기 통신 네트워크로 통신하는 상기 인바운드 커넥터, 상기 컴포넌트 서버 및 상기 서비스 컴포넌트에 독립적임- 를 제공하는 상기 서비스 컴포넌트
    를 포함하는 컴퓨터 시스템.
  2. 제 1 항에 있어서,
    상기 인바운드 커넥터는,
    a) 상기 통신 네트워크에 접속된 컴퓨터 시스템으로부터 요구를 수신하는 네트워크 인터페이스와,
    b) 상기 네트워크 인터페이스로부터 상기 요구를 수신하고 상기 하나 이상의 서비스 컴포넌트 중 어느 서비스 컴포넌트가 상기 요구를 핸들링해야 하는지를 판정하는 프로세싱 코어와,
    c) 상기 하나 이상의 서비스 컴포넌트의 각각과 상기 프로세싱 코어와 통신 하고 이로써 상기 요구가 전달되며 응답이 상기 프로세싱 코어- 상기 프로세싱 코어는 상기 통신 네트워크에 접속된 상기 컴퓨터 시스템에 상기 응답을 리턴함- 에 리턴되는 인터페이스
    를 포함하는 컴퓨터 시스템.
  3. 제 2 항에 있어서, 상기 인바운드 커넥터의 각각은 스택된 인바운드 커넥터 세트를 제공하도록 복제될 수 있는 컴퓨터 시스템.
  4. 제 3 항에 있어서, 상기 스택된 인바운드 커넥터 세트의 각각의 인바운드 커넥터는 스택된 인바운드 커넥터 세트내의 그 아래의 인바운드 커넥터와 다른 통신 프로토콜을 구현하는 컴퓨터 시스템.
  5. 제 4 항에 있어서, 상기 스택된 인바운드 커넥터 세트의 베이스의 베이스 인바운드 커넥터가 상기 서비스 컴포넌트 중의 하나의 서비스 컴포넌트와 통신하고 상기 서비스 컴포넌트 중의 상기 하나의 서비스 컴포넌트로부터 상기 응답을 수신하는 컴퓨터 시스템.
  6. 제 5 항에 있어서, 상기 응답은 상기 스택된 커넥터 세트의 상기 베이스 인바운드 커넥터로부터 다음의 최저 인바운드 커넥터로 통신되는 컴퓨터 시스템.
  7. 청구항 7은(는) 설정등록료 납부시 포기되었습니다.
    삭제
  8. 청구항 8은(는) 설정등록료 납부시 포기되었습니다.
    삭제
  9. 컴퓨터 시스템이 통신 네트워크로 통신하게 하는 명령을 포함하는 컴퓨터 판독가능 매체에 있어서,
    a) 하나 이상의 서비스 컴포넌트 및 하나 이상의 인바운드 커넥터에 서비스 를 제공하기 위한 컴포넌트 서버에 대한 명령과,
    b) 애플리케이션 로직을 제공하기 위하여 명령을 갖는 상기 서비스 컴포넌트의 각각과,
    c) 복수의 컴퓨터 시스템에 인터페이스 세트 -상기 인터페이스 세트는 상기 복수의 컴퓨터 시스템에 의해 호스팅된 미들웨어, 상기 통신 네트워크로 통신하는 상기 인바운드 커넥터, 상기 컴포넌트 서버 및 상기 서비스 컴포넌트에 독립적임-를 구현하기 위하여 명령을 제공하는 서비스 컴포넌트
    를 포함하는, 컴퓨터 판독가능 매체.
  10. 제 9 항에 있어서, 상기 인바운드 커넥터는,
    a) 상기 통신 네트워크에 접속된 컴퓨터 시스템으로부터 요구를 수신하는 네트워크 인터페이스를 제공하기 위한 명령과,
    c) 상기 네트워크 인터페이스로부터 상기 요구를 수신하고 상기 하나 이상의 서비스 컴포넌트 중 어느 서비스 컴포넌트가 상기 요구를 핸들링해야 하는지를 판정하는 프로세싱 코어를 제공하기 위한 명령과,
    c) 상기 하나 이상의 서비스 컴포넌트의 각각과 상기 프로세싱 코어와 통신하고 이로써 상기 요구가 전달되고 응답이 상기 프로세싱 코어 -상기 프로세싱 코어는 상기 통신 네트워크에 접속된 상기 컴퓨터 시스템에 상기 응답을 리턴함- 에 리턴되는 인터페이스를 제공하는 명령
    을 포함하는, 컴퓨터 판독가능 매체.
  11. 제 10 항에 있어서, 스택된 인바운드 커넥터 세트를 제공하기 위하여 상기 인바운드 커넥터의 각각이 복제되도록 하는 명령을 제공하는 단계를 더 포함하는 컴퓨터 판독가능 매체.
  12. 제 11 항에 있어서,
    상기 스택된 인바운드 커넥터 세트의 각각의 인바운드 커넥터는 상기 스택된 인바운드 커넥터내의 그 아래의 인바운드 커넥터와 다른 통신 프로토콜을 구현하는 컴퓨터 판독가능 매체.
  13. 제 12 항에 있어서, 상기 스택된 인바운드 커넥터 세트의 베이스의 베이스 인바운드 커넥터는 상기 서비스 컴포넌트 중의 하나의 서비스 컴포넌트와 통신하고 상기 서비스 컴포넌트의 상기 하나 이상의 서비스 컴포넌트로부터 상기 응답을 수신하는 컴퓨터 판독 가능 매체.
  14. 제 13 항에 있어서, 상기 응답은 상기 스택된 커넥터 세트내의 상기 베이스 인바운드 커넥터로부터 다음의 최저 인바운드 커넥터로 통신되는 컴퓨터 판독가능 매체.
KR1020047001456A 2001-09-10 2002-06-24 인바운드 커넥터 KR100683812B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CA002357168A CA2357168A1 (en) 2001-09-10 2001-09-10 Inbound connector
CA2,357,168 2001-09-10
PCT/GB2002/002865 WO2003024054A2 (en) 2001-09-10 2002-06-24 Inbound connector

Publications (2)

Publication Number Publication Date
KR20040032876A KR20040032876A (ko) 2004-04-17
KR100683812B1 true KR100683812B1 (ko) 2007-02-20

Family

ID=4169951

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020047001456A KR100683812B1 (ko) 2001-09-10 2002-06-24 인바운드 커넥터

Country Status (5)

Country Link
US (1) US20040243693A1 (ko)
KR (1) KR100683812B1 (ko)
CA (1) CA2357168A1 (ko)
TW (1) TW582147B (ko)
WO (1) WO2003024054A2 (ko)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7200674B2 (en) * 2002-07-19 2007-04-03 Open Invention Network, Llc Electronic commerce community networks and intra/inter community secure routing implementation
EP1570389A4 (en) * 2002-10-10 2006-01-25 Adc Telecommunications Inc SYSTEMS AND METHODS FOR MAINTAINING AND DISTRIBUTING A TRADING CATALOG
US7342918B2 (en) * 2003-04-15 2008-03-11 American Express Travel Related Services Co., Inc. Transaction card information access web service
US7802260B1 (en) * 2004-06-07 2010-09-21 Oracle America, Inc. Receiver-processor-dispatcher mechanism for inbound connectors
US20060129560A1 (en) * 2004-12-15 2006-06-15 Adams Greg D Architecture for enabling business components to access middleware application programming interfaces (APIs) in a runtime environment
US8495664B2 (en) * 2005-07-06 2013-07-23 International Business Machines Corporation System, method and program product for invoking a remote method
US20080046582A1 (en) * 2006-08-21 2008-02-21 International Business Machines Corporation System, apparatus, and method for handling and representing context data in a service component architecture
US20090138891A1 (en) * 2007-11-27 2009-05-28 Winig Robert J Integrating service-oriented architecture applications with a common messaging interface
US8606651B2 (en) * 2008-09-05 2013-12-10 Sony Corporation Generation of home network use recommendations based on collected metadata of prior connected items
US9367582B2 (en) * 2009-08-07 2016-06-14 International Business Machines Corporation Systems and methods involving information objects

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3652376B2 (ja) * 1995-06-07 2005-05-25 インターナショナル・ビジネス・マシーンズ・コーポレーション 従来の非オブジェクト指向業務アプリケーションをアクセスするためのオブジェクト構造を生成するための方法論
US5802367A (en) * 1995-07-07 1998-09-01 Microsoft Corporation Method and system for transparently executing code using a surrogate process
US6243751B1 (en) * 1997-06-11 2001-06-05 Oracle Corporation Method and apparatus for coupling clients to servers
US6006264A (en) * 1997-08-01 1999-12-21 Arrowpoint Communications, Inc. Method and system for directing a flow between a client and a server
US6370592B1 (en) * 1997-11-04 2002-04-09 Hewlett-Packard Company Network interface device which allows peripherals to utilize network transport services
US6192414B1 (en) * 1998-01-27 2001-02-20 Moore Products Co. Network communications system manager
US6452915B1 (en) * 1998-07-10 2002-09-17 Malibu Networks, Inc. IP-flow classification in a wireless point to multi-point (PTMP) transmission system
US6463078B1 (en) * 1998-07-22 2002-10-08 Microsoft Corporation Method for switching protocols transparently in multi-user applications
US6438594B1 (en) * 1999-08-31 2002-08-20 Accenture Llp Delivering service to a client via a locally addressable interface
US20010047383A1 (en) * 2000-01-14 2001-11-29 Dutta Prabal K. System and method for on-demand communications with legacy networked devices
US6915525B2 (en) * 2000-04-14 2005-07-05 Sony Corporation Method and apparatus for controlling set-top box hardware and software functions

Also Published As

Publication number Publication date
KR20040032876A (ko) 2004-04-17
WO2003024054A3 (en) 2003-10-30
WO2003024054A2 (en) 2003-03-20
US20040243693A1 (en) 2004-12-02
CA2357168A1 (en) 2003-03-10
TW582147B (en) 2004-04-01

Similar Documents

Publication Publication Date Title
US11171897B2 (en) Method and apparatus for composite user interface generation
US5926636A (en) Remote procedural call component management method for a heterogeneous computer network
US7693955B2 (en) System and method for deploying a web service
US7769825B2 (en) System and method for web services Java API-based invocation
US6757899B2 (en) Dynamic CORBA gateway for CORBA and non-CORBA clients and services
US7707564B2 (en) Systems and methods for creating network-based software services using source code annotations
US7930701B2 (en) JMS integration into an application server
US20040044656A1 (en) System for web service generation and brokering
US20130081067A1 (en) Proxy object creation and use
KR100683812B1 (ko) 인바운드 커넥터
US9940178B2 (en) System and method for integrating a transactional middleware platform with a centralized audit framework
US7823169B1 (en) Performing operations by a first functionality within a second functionality in a same or in a different programming language
US7251674B2 (en) Internationalization of the web services infrastructure
US10402307B2 (en) System and method for providing runtime tracing for a web-based client accessing a transactional middleware platform using an extension interface
US8255933B2 (en) Method and system for reading data, related network and computer program product therefor
US8024746B2 (en) Common handler framework
US7353521B1 (en) Object oriented distributed software system with methodology for piggybacked reflective callbacks
WO2004003770A1 (en) System and method for web services java api-based invocation
van Welie et al. Chatting on the Web
Team DIMMA Design and Implementation
Jungmann Web Services and their support in Java
CA2237646A1 (en) Registry communications middleware
WO2003060709A2 (en) Proxy framework

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
G170 Re-publication after modification of scope of protection [patent]
LAPS Lapse due to unpaid annual fee