KR20000037695A

KR20000037695A - 웹과 응용을 위한 멀티프로토콜 게이트웨이의 구조 및 처리방법

Info

Publication number: KR20000037695A
Application number: KR1019980052344A
Authority: KR
Inventors: 김완석; 박노삼; 김명준
Original assignee: 정선종; 한국전자통신연구원
Priority date: 1998-12-01
Filing date: 1998-12-01
Publication date: 2000-07-05
Also published as: KR100282616B1

Abstract

본 발명은 웹과 응용을 위한 멀티프로토콜 게이트웨이의 구조에 관한 것으로, 상태관리가 필요한 데이터를 효과적으로 처리하는 프로토콜들을 인터넷에서 지원할 수 있는 멀티프로토콜 게이트웨이의 구조를 제안한다. 사용자는 일관된 인터페이스를 가지는 웹 브라우저를 이용함으로써 여러 프로토콜의 인터페이스를 새로이 습득할 필요가 없다. 본 발명의 멀티프로토콜 게이트웨이는 상태 없는 프로토콜인 HTTP를 웹의 표준인 쿠키를 이용하여 상태를 유지하도록 하였다. 본 발명은 일괄적으로 상태 지향적인 요청들을 처리해 내고 있다. 또한 정보 검색의 표준 프로토콜인 Z39.50 프로토콜을 지원한다. 본 발명은 게이트웨이의 응용 서버가 Z39.50 클라이언트로서 Z39.50 서버에 접근하는 모델의 구조를 제안하였다. 본 발명에서 제안한 게이트웨이는 가능한 한 시스템과 Web을 독립적으로 설계하였다. 이를 통해 시스템에 연결함으로써 생길 수 있는 성능상의 오버헤드를 최소화하고, 다른 시스템으로의 이식을 용이하게 하였다. 본 발명의 응용 인터페이스 구조로써 웹을 통하여 다른 프로토콜도 자연스럽게 서비스 될 수 있다.

Description

웹과 응용을 위한 멀티프로토콜 게이트웨이의 구조 및 처리방법

본 발명은 웹과 응용을 위한 멀티프로토콜 게이트웨이의 구조에 관한 것으로, 상태관리가 필요한 데이터를 효과적으로 처리하는 프로토콜들을 인터넷에서 지원할 수 있는 멀티프로토콜 게이트웨이의 구조 및 처리방법에 관한 것이다.

기존의 게이트웨이에 대한 연구는 단순히 웹과 데이터베이스 연동에만 중점을 두어 시스템의 성능을 저하시키는 요소가 많다. 그리고 특정 DBMS에 제한적이기 때문에 다른 DBMS로의 이식이 어렵고 응용 프로그램의 개발과 유지에도 어려움이 많다. 현재 웹과 데이터베이스를 연결하는 게이트웨이는 상용, 프리웨어, 쉐어웨어 등 많은 제품이 출시되어 있다. 그러나 단순히 데이터베이스와 웹만의 통합을 고려한 것으로서, 인터넷의 다양한 프로토콜을 지원하는데에는 한계가 있다.

기존의 게이트웨이는 WWW와 정보 시스템의 종류에 따라 몇 가지로 나눌 수 있다.

1. WWW와 DBMS의 통합

정보 시스템 중에서 가장 많은 부분을 차지하고 있는 것이 DBMS이다. 데이터베이스 관리 시스템(DBMS)은 데이터베이스 시스템에서 사용자와 물리적 데이터베이스 사이에 위치하여 데이터베이스를 관리하고 사용자의 요구대로 데이터베이스에 대한 연산을 수행해서 정보를 생성하는 소프트웨어이다. DBMS는 먼저 데이터베이스 사용자로부터 데이터베이스 접근에 대한 요구를 접수해서 이것을 시스템이 수행할 수 있도록 변환한다. 사용자의 요구는 일반적으로 데이터의 검색, 삽입, 갱신, 삭제, 그리고 데이터의 생성 등이다. 이러한 연산을 수행하기 위해서 DBMS는 데이터베이스 스키마(schema) 간의 사상(mapping)을 통하여 목표 데이터에 접근한다. 지능적이고 고급 DBMS일수록 사용자로 하여금 데이터베이스 시스템 내부에 대해 알 필요 없이 편리한 방법으로 그 요구를 표현할 수 있다. DBMS는 정보 시스템의 소프트웨어나 하드웨어의 세세한 것으로부터 사용자를 독립시켜 주는 기능도 수행한다.

현재 진행되고 있는 WWW와 DBMS를 통합하는 방법들에 대해 살펴보면 다음과 같다.

먼저, Oracle 방식은, DBMS와 WWW를 통합하기 위해 고유의 웹 서버를 인스톨 만드는 방법을 택하고 있다. 특징적인 것 중에 하나가 서버 내에 웹 요청 브로커(Web Request Broker)라는 메커니즘을 가지는 것이다. 웹 요청 브로커는 다양하고 편리한 응용 프로그래머 인터페이스(API)를 제공하며, 부하 분산이나, 디스패칭(dispatching) 기능을 가진다.

또한, More 시스템에서는 웹 서버 자체에 게이트웨이 기능을 포함하는 구조를 제공한다. 여기서 http 데몬(demon)과 데이터베이스 인터페이스와의 연결(glue)은 CGI를 채택하고 있다.

2. WWW와 CORBA의 통합

CORBA와 같은 미들웨어(middleware)들은 그 자체가 분산 시스템을 구성하고 있지만 보다 많은 시스템을 자신의 환경에 끌어들이기 위하여 WWW을 이용한 접근 인터페이스를 제공하려 시도하고 있다.

CORBA(Common Object Request Broker Architecture) 표준은 하드웨어(hardware)나 소프트웨어(software)의 플랫폼(Platform)에 구애됨이 없이, 자원들을 공동으로 이용이 가능하게 하려는 취지에서 발전하게 되었다. 이 표준은 수백 여개의 하드웨어와 소프트웨어 업체들이 구성원으로 참여한 OMG(Object Management Group)에 의해서 만들어졌다. CORBA를 사용하게 되면, 하드웨어 구조나, 프로그래밍 언어에 독립되어 프로그램을 작성할 수 있다. 예를 들면, CORBA 표준을 따르기만 하면, C, C++, Scheme, Fortran 등 어느 언어로 만들어진 프로그램도 PC, Sparc, Silicon Graphics등 다양한 구조의 컴퓨터에서 어느 운영체제를 사용하든지 다양한 언어로 만들어진 클라이언트 프로그램을 이용하여 접근할 수 있다. CORBA 표준은 객체 지향의 원칙 하에 인터페이스 정의 언어(Interface Definition Language)를 이용하여 서비스를 정의한다.

CORBA와 WWW통합을 위한 대표적인 예는 Web*이다. 이는 도 1에 도시된 바와 같이, HTTP서버(1)는 CGI를 통해서 Web*(4) 및 OGI스크립트(3)와 연결되고, Web*(4)은 Web*스크립트(5)와 연결됨과 아울러 TcDii를 통해서 OBR(6)과 연결된다. 즉, Web*(4)에서는 WWW과 게이트웨이 사이의 연결은 CGI를 썼고 게이트웨이와 정보 시스템과의 연결에 있어서는 정보 관리자 게이트웨이 방식과 같이 정보 시스템인 CORBA의 정보 관리 주체인 ORB에 연결하는 방식을 취하고 있다.

Web*의 구조는 도 1과 같다. Web*(4)와 ORB(6)와의 연결은 TclDii를 통하여 이루어진다. TclDii는 스크립트 언어인 Tcl(Tool Command Language)로 만들어진 스크립트들을 동적 호출 인터페이스(Dynamic Invocation Interface)를 통하여 CORBA의 ORB에 연결하는 역할을 하는 기능을 가진 도구이다. 이것은 CORBA 표준을 따르는 Obrix 클라이언트 라이브러리 상에서 구현되었으며 Obrix 클라이언트 라이브러리는 CORBA의 인터페이스 정의 언어(Interface Definition Language)에 사상되도록 구현되어 있다. 이 방법은 현재 떠오르고 있는 미들웨어 표준인 CORBA 표준을 따르는 정보 시스템을 WWW을 이용하여 접근하였기 때문에 객체 지향 서비스를 이용할 수 있다는 점에서 그 의의를 찾을 수 있다. 그러나 아직까지 CORBA 표준을 따르는 정보 시스템이 많지 않다는 단점이 있다.

따라서, 본 발명은 종래의 문제점을 해결하기 위하여 웹에서 멀티프로토콜을 지원하기 위한 게이트웨이의 구조를 제안한다.

본 발명은 쿠키(cookie)를 이용하여 HTTP의 무상태(stateless)를 유상태(stateful)로 유지함으로써 트랜잭션을 처리한다. 이는, 웹서비스에 있어 트랜잭션 처리는 웹의 특성을 고려하여 제공해야 한다. 웹의 HTTP 통신 규약은 상태가 없는 반면, 트랜잭션은 처리 상태가 유지돼야 한다. 본 발명은 트랜잭션의 상태 유지를 위하여, HTTP의 쿠키를 사용하여 웹서비스를 요청하는 웹 클라이언트를 개별화하여 식별하고, 트랜잭션 상태는 데이터베이스 시스템에서 유지한다.

또한, 본 발명은 정보 검색용 표준 프로토콜인 Z39.50을 지원한다. 시스템마다 다른 환경의 차이에서 비롯된 이용자들의 정보 검색상의 불편함을 해소시키기 위해서 등장한 미국 국가표준인 Z39.50은 두 컴퓨터간의 표준화된 통신 프로토콜로서 클라이언트와 서버간의 개방형 상호접속을 용이하게 한다. Z39.50 표준은 이 표준을 기반으로 하는 Z39.50 서버에 적용되고 이 서버에 연결할 수 있도록 준비된 게이트웨이에 이용자가 접근함으로써 응용된다. 본 발명은 웹 브라우저를 통하여 Z39.50 서버에 접근하는 모델을 제시하므로 웹 브라우저의 장점을 최대한 살려 쉽게 이용할 수 있다. 또한 별도의 시스템에 연결을 하지 않아도 되므로 정보자원의 접근이 용이하다.

또한, 본 발명은 기본 응용 서버와 여타의 프로토콜을 위한 응용 사이의 독립적인 구조를 가진다. 작은 크기의 디스패처와 데몬 형식의 응용 서버 구조를 가지는 CGI 응용 서버 방식은 게이트웨이에 많은 부하가 걸리는 문제점을 해결한다. 하지만 응용 서버가 많은 기능을 지원함으로써 응용 서버의 크기가 너무 커지는 단점이 있다. 본 발명은 게이트웨이의 기본적인 기능인 데이터베이스 접속과 그 결과 처리, DBMS의 유용한 기능을 지원하는 응용 서버와, Z39.50과 같은 여타의 프로토콜을 지원하기 위한 응용을 분리함으로써 응용 서버에 과다한 부하가 걸리지 않도록 하고, 이식성과 확장성을 높인다. 즉, 여타의 프로토콜을 지원함에 있어서, 모니터에 추가적인 모듈만 추가함으로써 쉽게 다른 프로토콜을 지원할 수 있다.

도 1은 일반적인 웹(Wep*) 구조도.

도 2는 본 발명이 적용되는 멀티프로토콜 게이트웨이 모듈의 구성도.

도 3은 본 발명을 구성하는 모듈의 동작 흐름도.

도 4은 본 발명에 의한 유상태 요구 처리 과정을 보인 설명도.

＜도면의 주요부분에 대한 부호의 설명＞

11 : 게이트 웨이 12 : 모니터

13 : 응용서버 14 : 클라이언트

15 : 메시지 큐 16 : 데이타베이스관리시스템

17 : 서버 18 : 데이타베이스

이하, 첨부된 도면을 참조하여 본 발명의 실시예를 상세히 설명한다.

도 2는 본 발명이 적용되는 환경의 전체 구성도를 나타낸다. 이에 도시된 바와 같이, 게이트웨이(Gateway)(11), 모니터(Monitor)(12), 응용 서버(ApServer)(13), Z39.50 클라이언트(Zclient)(14)로 구성되고, 이들은 하나의 메시지 큐(15)를 공유한다. 본 발명은 클라이언트(14)로부터 요청을 받으면 CGI 실행 가능 구조인 게이트웨이(11)가 메시지 큐(15)에 요청을 쓰고, 모니터(12)가 메시지큐(15)로부터 자신에게 보내진 메시지 내용을 분석하여 응용서버(13)와 클라이언트(14)가 처리하는 방식이다. 본 발명의 구성에서 모니터(12)는 데몬 형식으로 상주해 있으며, 응용 서버(13)는 DBMS(16)에 요청을 넘겨주고 결과를 전달받는다. 클라이언트(14)는 이미 수행중인 서버(Zserver)(17)에 접속하여 Z39.50 프로토콜 요구를 처리한다.

본 발명이 동작하는 과정은 도 3과 같다. 먼저 게이트 웨이(11)는, CGI를 통하여 질의 문자열, 호스트 이름 등의 정보를 얻는다(21). 질의 문자열이 트랜잭션 처리의 시작을 요구하는 경우(22), 쿠키를 생성하여 서비스를 요청한 사용자를 개별화하여 식별한다(24). 이어 게이트웨이(11)는 질의 문자열을 메시지 큐(15)에 전하고, 처리 결과가 응용서버(13) 및 클라이언트(14)로부터 작업 큐에 도달하기를 기다린다. 게이트 웨이(11)의 메시지가 모니터(12)에 도착하면 메시지의 내용을 분석하여 트랜잭션의 시작을 요구하면 새로운 응용서버를 생성하고, 이후부터는 동일 쿠키를 가진 메시지는 지속적으로 동일 응용서버에게 연결하여 트랜잭션 처리를 돕는다(25). 질의가 Z39.50의 시작일 경우는(23) 모니터가 클라리언트(14) 응용을 생성하고 이후의 Z39.50 서비스 메시지는 클라이언트(14) 응용에게 전달한다(26). 그리고 일반 메시지인 경우는 모니터는 응용서버들의 부하를 파악하여 가장 부하가 적은 응용서버에게 메시지 처리를 요청한다(27). 게이트웨이는 결과가 도착하면(28), 데이터를 분석하여 스스로 MIME 타입을 설정하여 웹서버에게 MIME 타입과 데이터를 전달한다(29).

게이트 웨이(11)는 웹서버의 서비스 요구를 전달하고 응용서버로부터 결과 혹은 오류 메시지를 전달받아 웹서버에게 전하는 역할을 한다. 그리고, Z39.50 접속을 설정하고 일정 시간이 지나면 자동적으로 그 연결을 해제하고, 클라이언트에게 재접속을 요구하게 된다.

모니터(12)는 시스템 환경 변수를 통하여 응용 서버명과 경로 그리고 응용서버 수 등의 정보를 얻어 데이터베이스를 초기화하고 응용 서버들을 실행 가능한 상태로 만든다. 계속하여 데몬 형식으로 상주하면서 작업 큐에 게이트 웨이(11)와 응용서버(13)의 메시지 수신 여부를 모니터링한다.

그리고 각 응용서버(13)의 동작 상태를 확인하기 위하여 일정한 간격으로 메시지를 보내고, 정해진 시간의 경과 후, 각 응용서버로부터 도착한 메시지를 확인하고 이상이 발견되면, 비정상 상태의 응용서버를 제거하고 메시지를 회수한다. 이어 새로운 응용서버로 대치하고 메시지를 재분배한다. 즉, 모니터(12)는 게이트웨이(11)의 서비스 요구를 응용 서버들에게 적절하게 분배한다. 또한 응용 서버의 상태를 관리하고, 문제가 발생하면 복구 처리한다.

응용서버(13)는, 게이트 웨이(11)의 서비스 요구를 처리할 수 있는 데이터베이스의 서버인 동시에 데이터베이스 시스템의 한 응용으로, 모니터(12)로부터 할당받은 서비스 요구에 대한 처리 결과를 게이트웨이(11)에게 전하는 역할을 수행한다.

클라이언트(14)는 Z39.50 서비스를 처리하기 위한 클라이언트로서, 시스템에 의하여 이미 수행 중인 Z39.50 서버(ZServer)(17)와 연결을 맺고, 이후의 Z39.50 서비스 요구에 대한 결과를 게이트웨이(11)에게 전달한다. 클라이언트(14)는 zinit이라는 접속 요구가 들어오면 모니터(12)에 의해 생성되며 일정 시간동안 요구가 없으면, 게이트웨이(11)에게 재접속을 요구하고 연결을 해제한다.

본 발명에 의한 게이트웨이의 유상태(stateful) 요구 처리는, 웹의 HTTP 통신 규약은 무상태(stateless)를 기반으로 하는 반면, 트랜잭션은 처리 상태가 유지 되어야 한다. 본 발명은 유상태 요구처리를 위하여 HTTP 통신 규약의 쿠키를 사용하여 웹서비스를 요청하는 웹클라이언트를 개별화하여 식별하고, 트랜잭션 상태는 데이타베이스 관리 시스템에서 유지한다. 본 발명의 트랜잭션 처리는 도 4에 도시된 바와 같이, 배치(batch) 처리를 기본으로 하며, 트랜잭션 명령은 시작(txbegin), 통신(txcommit), 롤백(txrollback)을 기본으로 제공한다. 임의 사용자가 시작 명령을 송신함에 따라 새로운 트랜잭션이 시작되고, 시작 명령 수행 이후의 모든 웹서비스는 동일한 응용서버에게 할당된다. 수행 중의 트랜잭션은 통신 혹은 롤백 명령에 의해 종료된다.

실제로 응용서버(13)는 시작(txbegin)명령에서 통신(txcommit) 혹은 롤백(txrollback) 명령이 올 때까지의 모든 요구를 처리하지 않은 채 작업 큐(15)에 유지하고 있다. 통신(txcommit)명령이 도착하면 작업 큐(15)의 요구를 순서에 따라 처리하고 트랜잭션 허락과 함께 트랜잭션을 종료한다. 롤백(txrollback)명령이 도착하면 작업 큐의 모든 요구를 처리하지 않고 제거하는 일괄처리 방식을 채택한다.

Z39.50 프로토콜 지원 방법은, Z39.50 표준은 이 표준을 기반으로 하는 Z39.50 서버에 적용되고 이 서버에 연결할 수 있도록 준비된 게이트웨이에 이용자가 접근함으로써 응용된다. 본 발명에서 제시하는 멀티프로토콜 게이트웨이는 웹 브라우저를 통하여 Z39.50 서버에 접근하는 모델을 제시하므로 웹 브라우저의 장점을 최대한 살려 쉽게 이용할 수 있다. 또한 별도의 시스템에 연결을 하지 않아도 되므로 정보자원의 접근이 용이하다.

Z39.50 프로토콜은 클라이언트와 서버의 한 어플리케이션 연결(A association) 내의 Z39.50 연결(Z-association)을 통해 이루어진다. 한 Z39.50 연결은 클라이언트에 의해 시작되며 클라이언트나 서버에 의해서 종료되거나 어플리케이션 연결이 종료되어 그때 같이 종료된다. Z39.50 서비스들은 클라이언트와 서버 사이의 메시지(request, response)의 교환에 의해 수행되며, 초기화(Init), 찾기(Search), 현재(Present), 삭제(Delete), 스캔(Scan), 소트(Sort), 리소스-리포트(Resource-report), 외부-서비스(Extended-services) 등의 8개의 연산이 표준으로 되어 있다. 연산은 초기화 요구(initiating request)로 시작해서 종료 응답(terminating response)으로 끝난다.

멀티프로토콜 게이트웨이의 Z39.50 프로토콜 명령은 클라이언트 zinit, zsearch을 기본으로 제공한다. zinit은 서버와 접속하기 위하여 클라이언트가 요구하는 서비스이다. zsearch는 서버에 있는 데이터베이스에 질의를 하여 검색된 결과를 클라이언트에서 전송받을 수 있도록 클라이언트가 요구하는 질의 서비스이다. 이렇게 검색된 결과세트로부터 원하는 레코드를 전송받는 전송(present)서비스도 제공한다. Z39.50 연결은 일정 시간이 지나면 자동적으로 연결이 끊어지게 된다.

클라이언트(ZServer)에 연결하기 위한 요청인 zinit() 명령의 사용 예는 다음과 같고, 사용자에게 데이터베이스를 검색할 수 있는 페이지를 화면에 보여준다.

http://bada.etri.re.kr/b3gateway?function=zinit()＆

한편, 본 발명의 응용 서버와 클라이언트의 독립성을 설명하면 다음과 같다. 응용서버(ApServer) 안에 클라이언트(ZClient) 기능을 포함하지 않고 다른 응용 서버로 수행함으로써 구조의 독립성과 확장성을 높이게 된다. 즉, 다른 프로토콜을 지원함에 있어서도 응용서버가 아닌 독립적인 모듈을 추가하고, 게이트 웨이와 모니터에 그 모듈을 처리하는 부분만을 삽입하여 시스템을 쉽게 확장할 수 있다.

본 발명은 웹과 데이터베이스를 연동하며 정보 검색 표준 프로토콜인 Z39.50을 지원한다. 웹의 HTTP는 상태 없는 프로토콜이므로 상태관리가 필요한 응용의 처리에 어려움을 가지고 있다. 본 발명은 상태관리가 필요한 데이터를 효과적으로 처리하는 프로토콜들을 인터넷에서 지원할 수 있는 멀티프로토콜 게이트웨이의 응용 인터페이스 설계를 제안한다. 사용자는 일관된 인터페이스를 가지는 웹 브라우저를 이용함으로써 여러 프로토콜의 인터페이스를 새로이 습득할 필요가 없다.

본 발명은 상태 없는 프로토콜인 HTTP를 웹의 표준인 쿠키를 이용하여 상태를 유지하도록 하였고, 일괄적으로 상태 지향적인 요청들을 처리해 내고 있다. 또한 정보 검색의 표준 프로토콜인 Z39.50 프로토콜을 지원한다.

본 발명은 게이트웨이의 응용 서버가 Z39.50 클라이언트로서 Z39.50 서버에 접근하는 모델과 그 응용 인터페이스를 제안하였다. 웹 브라우저를 통하여 Z39.50 서버에 접근하는 모델을 제시함으로써 웹 브라우저의 장점을 최대한 살리며 별도의 시스템에 연결을 하지 않아도 되므로 정보자원의 접근이 용이하다. 본 발명에서 제시한 게이트웨이의 응용 인터페이스 구조로써 웹을 통하여 다른 프로토콜도 자연스럽게 서비스 될 수 있다.

Claims

CGI를 통하여 질의 문자열, 호스트 이름 등의 정보를 입력받아 메시지 큐에 전달하며, 처리된 결과를 수신받아 웹서버에게 전달하는 게이트웨이와;

상기 메시지 큐에 전달된 질의를 분석하여 적절한 응용서버에게 할당하되, 데몬 형식으로 상주하는 모니터와;

직접 데이타 베이스와 연결하여 상기 모니터에 의해 할당되는 트랜잭션을 처리하고 그 결과를 상기 게이트 웨어에게 전달하는 응용서버와;

직접 Z39.50 서버에 연결하여 상기 모니터에 의해 할당되는 Z39.50 프로토콜 질의를 처리하여 그 결과를 상기 게이트 웨어에게 전달하는 클라이언트(Zclient)와,

상기 게이트웨이, 모니터, 응용서버, 클라이언트가 공유하는 하나의 메시지 큐로 구성된 것을 특징으로 하는 멀티프로토콜 게이트웨이의 구조.
제 1 항에 있어서, 상기 멀티프로토콜 게이트웨이의 구조는,

응용서버(ApServer) 안에 클라이언트(ZClient) 기능을 포함하지 않고 다른 응용 서버로 클라이어트 기능을 수행하도록 구성하고, 다른 프로토콜을 지원시 응용서버가 아닌 독립적인 모듈을 추가하고, 게이트 웨이와 모니터에 그 모듈을 처리하는 부분만을 삽입하여 시스템을 확장시키도록 구성된 것을 특징으로 하는 멀티프로토콜 게이트웨이의 구조.
게이트웨이가 CGI를 통하여 질의 문자열, 호스트 이름 등의 정보를 얻는 제1과정과;

게이트웨이가 질의 문자열을 메시지 큐에 전하고, 처리 결과가 응용서버 및 클라이언트로부터 도착되기를 기다리는 제2과정과;

데몬상태로 상주하는 모니터가 상기 메시지 큐에 전달된 메시지의 내용을 분석하여 응용서버나 클라이언트에게 메시지 처리를 할당하는 제3과정과;

상기 제3과정에서 각기 메시지 처리를 할당받은 응용서버, 클라이언트가 데이타베이스와 클라이언트 서버를 연결하여 메시지 처리를 하고 그 결과를 상기 게이트웨이에 전달하면, 게이트웨이는 데이터를 분석하여 스스로 MIME 타입을 설정하여 웹서버에게 MIME 타입과 데이터를 전달하는 제4과정을 수행하는 것을 특징으로 하는 멀티프로토콜 게이트웨이 처리방법.
제 3 항에 있어서, 상기 제 2 과정은,

데몬 상태로 상주하는 모니터가,

시스템 환경 변수를 통하여 응용 서버명과 경로 그리고 응용서버 수 등의 정보를 얻어 데이터베이스를 초기화하고 응용 서버들을 실행 가능한 상태로 만드는 단계와;

데몬 형식으로 상주하면서 작업 큐에 게이트 웨이와 응용서버의 메시지 수신 여부를 모니터링하는 단계와;

각 응용서버의 동작 상태를 확인하기 위하여 일정한 간격으로 메시지를 보내고, 정해진 시간의 경과 후, 각 응용서버로부터 도착한 메시지를 확인하는 단계와;

메시지의 이상이 발견되면, 비정상 상태의 응용서버를 제거하고 메시지를 회수하고 새로운 응용서버로 대치하여 메시지를 재분배하는 단계를 더 포함하여 응용 서버의 상태를 관리하고, 문제가 발생하면 복구 처리하는 것을 특징으로 하는 멀티프로토콜 게이트웨이 처리방법.
제 3 항에 있어서, 상기 제2과정은,

분석된 메시지가 트랜잭션의 시작을 요구인 경우는, 새로운 응용서버를 생성하고, 서비스를 요청한 사용자를 개별화하고, 그 응용서버가 트랜젝션을 처리하게 하는 제1단계와;

분석된 메시지가 질의 메시지로서 Z39.50의 시작일 경우는, 모니터가 클라리언트 응용을 생성하고 이후의 Z39.50 서비스 메시지는 클라이언트 응용에게 전달하는 제2단계와;

상기 모니터의 메시지 분석 결과가 일반 메시지인 경우, 응용서버들의 부하를 파악하여 가장 부하가 적은 응용서버에게 메시지 처리를 요청하는 제3단계; 를 수행하여 모니터는 게이트웨이의 서비스 요구를 응용 서버들에게 적절하게 분배하는 것을 특징으로 하는 멀티프로토콜 게이트웨이 처리방법.
제 3 항에 있어서, 상기 멀티프로토콜 게이트웨이 처리방법은,

HTTP 통신 규약의 쿠키를 사용하여 웹서비스를 요청하는 웹클라이언트를 개별화하여 식별하는 단계와;

트랜잭션 상태는 데이타베이스 관리 시스템에서 유지하며, 배치(batch) 처리를 기본으로 하여 트랜잭션 명령으로, 시작(txbegin), 통신(txcommit), 롤백(txrollback)을 기본으로 제공하는 단계와,

임의 사용자가 시작 명령을 송신함에 따라 새로운 트랜잭션이 시작되고, 시작 명령 수행 이후의 모든 웹서비스는 동일한 응용서버에게 할당하며, 수행 중의 트랜잭션은 통신 혹은 롤백 명령이 올 때까지의 모든 요구를 처리하지 않은 채 작업 큐(15)에 유지하는 단계와;

통신(txcommit)명령이 도착하면 작업 큐(15)의 요구를 순서에 따라 처리하고 트랜잭션 허락과 함께 트랜잭션을 종료하는 단계와;

롤백(txrollback)명령이 도착하면 일괄처리 방식을 채택하여 작업 큐의 모든 요구를 처리하지 않고 제거하는 단계를 포함하여 게이트웨이의 유상태(stateful) 요구 처리를 하는 것을 특징으로 하는 멀티프로토콜 게이트웨이 처리방법.
제 3 항에 있어서, 상기 멀티프로토콜 게이트웨이 처리방법은,

상기 클라이언트가 Z39.50 프로토콜 처리를 하기 위하여,

웹 브라우저를 통하여 Z39.50 서버에 접근하되,

서버와 접속하기 위하여 클라이언트가 요구하는 서비스(zinit)와,

서버에 있는 데이터베이스에 질의를 하여 검색된 결과를 클라이언트에서 전송받을 수 있도록 클라이언트가 요구하는 질의 서비스(zsearch)와,

검색된 결과세트로부터 원하는 레코드를 전송받는 전송 서비스(present)를 제공하며,

접속 요구시 사용자에게 데이터베이스를 검색할 수 있는 페이지를 화면에 보여주어 Z39.50 프로토콜 처리를 지원 하는 것을 특징으로 하는 멀티프로토콜 게이트웨이 처리방법.
제 3 항에 있어서, 상기 멀티프로토콜 게이트웨이 처리방법은,

응용서버(ApServer) 안에 클라이언트(ZClient) 기능을 포함하지 않고 다른 응용 서버로 클라이어트 기능을 수행하여 구조의 독립성과 확장성을 높이는 것을 특징으로 하는 멀티프로토콜 게이트웨이 처리방법.