KR100260682B1

KR100260682B1 - 애플릿실행방법및컴퓨터워크스테이션

Info

Publication number: KR100260682B1
Application number: KR1019970032208A
Authority: KR
Inventors: 제프리 알렉산더 코헨; 데이비드 루이스 캐민스키; 리챠드 아담 킹; 매튜 레이몬드 맥키논
Original assignee: 포만 제프리 엘; 인터내셔널 비지네스 머신즈 코포레이션
Priority date: 1996-10-01
Filing date: 1997-07-11
Publication date: 2000-07-01
Also published as: JPH10124324A; GB2317974B; GB9710095D0; GB2317974A; KR19980032220A; US5805829A; JP3405666B2

Abstract

본 발명은 비 IP 네트워크(non-IP network) 상에서 애플릿(applet)이 고유하게(natively) 실행되도록 하는 방법 및 장치를 제공한다. 본 발명의 방법 및 장치는 애플릿 다운로드를 개시하고, 클래스 장해(class fault)가 일어난 경우 이를 서비스하고, TCP/IP(Transmission Control Protocol/Internet Protocol) 상에서 동작하는 자바(Java)의 보안 메커니즘(security mechanism)을 손상시키지 않으면서 비 IP API(Application Programming Interface)에 대한 호출(call)을 허용하는 애플릿 로더(applet loader)를 제공한다. 그 결과, 애플릿이 웹 브라우저(web browser) 또는 웹 서버(web server)없이 실행될 수 있다.

Description

애플릿 실행 방법 및 컴퓨터 워크스테이션{A PROCESS FOR RUNNING APPLETS OVER NON-IP NETWORKS}

"웹(web)", www, 또는 "인터넷(internet)"이라고 알려진 월드 와이드 웹(World Wide Web)은 컴퓨터간의 통신을 위한 전송(transportation) 메커니즘으로서, TCP/IP(Transmission Control Protocol/Internet Protocol)를 사용하여 연결된 컴퓨터들의 네트워크이다. 월드 와이드 웹에 의해 한 컴퓨터 상의 사용자는 웹 브라우저(web browser)라 불리는 프로그램을 이용해 원격 컴퓨터에 있는 데이터를 액세스할 수 있게 된다. 웹 브라우저는 사용자가 하이퍼텍스트(hypertext)를 판독할 수 있도록 하는 소프트웨어 애플리케이션(application)이다. 웹 브라우저는 또한 사용자가 네트워크 상의 한 노드(node)로부터 다른 노드로 네비게이션(navigation)하는 것을 가능하게 한다. 넷스케이프 통신사(Netscape Communications Corp.)에 의해 만들어진 넷스케이프 네비게이터(Netscape Navigator)는 브라우저의 좋은 예이다. 찾고 있는 정보를 가지고 있는 머신(machine) 상에서, 웹 서버(web server)는 웹 브라우저로부터의 요구에 응답한다. 웹 서버는 HTTP(HyperText Transfer Protocol)를 통해서 요구된 웹 페이지(web page)를 전송한다.

초기에, 웹은 웹 페이지로 불리는 정적(static) 문서들에만 한정되었다. 웹 페이지는 웹 브라우저에 의해 디스플레이되는 텍스트(text) 및 이미지(image)를 포함할 수는 있었으나, 이 페이지들은 컴퓨터 프로그램을 포함할 수는 없었다. 1996년에 선 마이크로시스템즈사(Sun Microsystems)는 인터넷에서 구동 가능한 인터프리터(internet-capable interpreter)(가상 머신(Virtual Machine) 또는 VM이라 불리기도 함)인 자바(Java)(자바는 선 마이크로시스템즈사의 등록 상표임)를 소개하였다. 자바에 의해, 웹 페이지는 애플릿(applets)이라 불리는 프로그램을 포함할 수 있다. 브라우저는 애플릿이 포함된 페이지(page)를 다운로드할 때, 이 페이지로부터 애플릿을 추출하여, 실행을 위해 자바 가상 머신으로 전송한다. 이렇게 하여, 프로그램 또는 애플릿은 사용자가 이를 명시적으로 설치하지 않아도 사용자의 머신에서 실행될 수 있다.

애플릿이 동영상(animation)과 같이 "생생한(live)" 웹 내용을 실현시킴으로써 주목을 받기 시작한 한편, 이는 또한 기업 컴퓨팅의 가장 큰 비용 중 하나인 클라이언트(client) 컴퓨터 설치 비용을 줄인다. 분산 애플리케이션(distributed application)은 서버 구성 요소와 클라이언트 구성 요소의 개별적인 두 구성 요소를 지닌다. 서버 구성 요소는 하나 또는 몇 개의 서버 머신에 설치되기만 하면 되지만, 클라이언트 구성 요소는 모든 워크스테이션에 설치되어야만 한다. 이는 회사의 분산 컴퓨터 환경에 있어서 매우 큰 비용이 될 수 있다. 애플릿을 이용하면, 클라이언트와 서버 구성 요소 모두가 서버 머신에만 설치되면 된다. 서버 구성 요소는 서버 컴퓨터에서 작동하고, 클라이언트 구성 요소는 필요할 때 서버로부터 클라이언트 컴퓨터로 다운로드되며, 클라이언트에 별도로 설치될 필요가 없다.

그러나, 오늘날의 자바 애플릿은 IP 네트워크에만 제한되거나, 비 IP 프로토콜 상에서 동작하기 위해서는 IBM의 애니넷(AnyNet)과 같은 다중 프로토콜 게이트웨이(Multiprotocol gateway)를 필요로 한다. 자바는 SNA에 대한 고유의 지원 체제나, 다른 비 IP 프로토콜을 갖지 않는다. 많은 기업 네트워크가 SNA를 광범위하게 이용하고 있고, 특히 세계의 비지니스 데이터를 많이 포함하는 메인프레임 컴퓨터와의 연결을 위해 SNA를 광범위하게 이용하고 있으므로, 이러한 사실은 큰 단점이 된다.

본 발명의 목적은 다중 프로토콜 게이트웨이를 필요로 하지 않으면서, SNA와 같은 비 IP 네트워크를 통해 자바 애플릿을 전송할 수 있게 하는 방법 및 장치를 제공하는 것이다.

본 발명의 다른 목적은 CPI-C(Common Programming Interface for Communications)와 같은 비 IP API(Application Programming Interface)를 통해 서버와 연결되도록, 애플릿이 비 IP 네트워크 상에서 전송되도록 하는 방법 및 장치를 제공하는 것이다.

본 발명의 또다른 목적은 웹 서버 또는 웹 브라우저를 사용하지 않고서도, 상기 목적을 달성하는 것이다.

본 발명은 "애플릿 로더(applet loader)"를 이용한다. 본 발명의 애플릿 로더는 클라이언트 컴퓨터 상에서 작동한다. 본 발명의 애플릿 로더는 비 IP 네트워크 상에서 애플릿을 로드하기 위한 메커니즘을 함께 제공하는 3 프로세스, 즉, 초기 애플릿 다운로드, 애플릿 "클래스 장해(class fault)"에 대한 서비스, 그리고 자바의 애플릿 보안 메커니즘을 손상시키지 않고 비 IP API를 호출하는 프로세스를 실행한다. 클라이언트는 이 작업을 완수하기 위해 웹 브라우저를 실행시킬 필요가 없다.

서버 컴퓨터는 IBM사에 의한 SNA의 AFTPD와 같은 비 IP 파일 전송 프로그램을 사용하여, 애플릿을 서버로부터 클라이언트로 전송한다. 이러한 프로그램은 본 기술 분야에서 잘 알려져 있다. 클라이언트와 마찬가지로 서버 또한 웹 서버 애플리케이션을 실행시킬 필요가 없다.

본 발명의 애플릿 로더는 사용자가 실행하고자 하는 애플릿명을 알기 위해 사용자에게 프롬프트(prompt)한 후, 애플릿명을 받아들인다. 애플릿의 이름인 URL(Universal Resource Locator)은 서버의 이름을 암시적으로 나타낸다. (URL은 본 기술 분야에 잘 알려져 있음.) 이와 유사한 애플릿과 서버의 명명법들도 본 발명을 크게 변화시키지 않으면서 사용될 수 있다. 현재의 방법은 단지 일 예로서 쓰인다. 다음, 애플릿 로더는 애플릿 서버 컴퓨터에게 상기 애플릿을 포함하는 제 1 클래스 파일을 전송할 것을 요구한다. 클래스 파일은 가상 머신에 의해 실행될 인스트럭션들을 포함한다. 이러한 인스트럭션들은 이진 목적 코드(binary object code)와 유사하고, 클래스 파일은 C 컴파일러 등의 컴파일러들에 의해 생성되는 목적 파일(object file)과 유사하다. 통상 제 1 클래스 파일명은 애플릿명에 ".class" 확장자를 붙인 것과 같다. (예를 들어, 애플릿명이 "foo"이면, 제 1 클래스 파일명은 "foo.class"임.) 파일 전송은 SNA의 AFTP, IND$FILE, 또는 다른 잘 알려진 전송 메커니즘과 같은 비 IP 파일 전송 방식을 이용하여 이루어진다.

애플릿 로더는 초기 클래스 파일을 수신하고, 이를 클라이언트 컴퓨터에 있는 자바 가상 머신으로 전송한다. 이 과정에 의해 애플릿 동작이 개시된다. 자바 가상 머신이 애플릿을 실행시키는 동안에, 애플릿이 클라이언트 컴퓨터에 없는 클래스를 요구한다는 것이 감지될 때("클래스 장해"라 불리는 상태), 자바 가상 머신은 애플릿 로더 내의 프로세스인 "클래스 로더"에 특정 이름의 클래스를 로드하라는 요구 신호를 송출한다. 위에서와 같이, 클래스 로더는 초기 클래스 파일을 로드하기 위해 사용된 서버 컴퓨터로 비 IP 파일 전송 요구를 송출한다.

초기의 애플릿 다운로드 및 클래스 장해 서비스를 수행하기 위한 이러한 프로세스들의 결합은 애플릿이 비 IP 네트워크 상에서 실행되는 것을 가능케 한다.

애플릿이 SNA API를 호출할 수 있도록 하기 위해, 본 발명은 상기 애플릿 로더에 부가적인 메커니즘을 추가해야만 한다. 애플릿 로더는 보안 관리자(Security Manager)를 인스턴스화(instantiate)해야 한다. 자바에 있어서는, 보안 관리자가 애플릿의 로컬 자원 액세스 제어를 총괄한다. 이들은 대체로 비 자바 호출을 허용하지 않는다. SNA API는 자바에 포함되지 않으므로, 이 제한 사항은 SNA API와 같은 API 사용을 배제시킬 것이다.

본 발명의 애플릿 로더는 애플릿이 SNA API의 자바 버전(version)을 포함하는 동적 링크 라이브러리(dynamic link library; DLL)를 로드할 수 있게 하는 것을 제외하고는 보안 관리자가 통상적인 모든 애플릿 제한 사항들을 수행하도록 보안 관리자를 인스턴스화한다. 보안 관리자는 애플릿이 로드하고자 하는 각 DLL의 이름을 통상적으로 "javasna.dll"이라 불리는 SNA API DLL의 이름과 비교함으로써, 이 특정 DLL만이 로드될 수 있도록 보장한다. 만일, DLL이 "javasna.dll"이라 불리지 않으면, 보안 관리자는 보안 예외(security exception)를 호출하여(자바 용어에 의하면 던져(throws)), 애플릿을 종료시킨다.

SNA API에 대한 액세스가 가능한 DLL과 같이 자바가 호출할 수 있는 DLL을 구축하는 것은 본 기술 분야에 잘 알려져 있고, 본 발명의 새로운 기술은 아니다. 애플릿이 비 IP 전송에 의해 지원되는 API를 호출하도록 비 IP 전송을 통해 다운로드되게 하는 것이 바로 본 발명의 신기술이다. 본 발명이 자바 가상 머신에 관해 기술하고 있기는 하지만, 본 발명이 애플릿 또는 프로그램 개시(launching)를 지원하는 다른 어느 가상 머신에도 동일하게 적용될 수 있다는 것을 당업자라면 명백히 알 수 있다.

도 1a는 애플릿을 로드하기 위한 단계들을 도시한 흐름도,

도 1b는 ACOPY 루틴을 이용하는 도 1a의 단계들을 도시한 흐름도,

도 2a는 본 발명을 위한 클래스 장해 처리를 도시한 흐름도,

도 2b는 ACOPY 루틴을 이용하는 도 2a의 클래스 장해 처리를 도시한 흐름도,

도 3은 본 발명의 보안 메커니즘을 위한 단계들의 흐름도.

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

101 : URL 입력 102 : URL 판독

103 : 서버명과 애플릿명 파싱 104 : 서버에 접속

105 : 제 1 클래스를 위한 파일 전송 요구 송출

106 : 애플릿의 제 1 클래스 파일 수신

107 : 가상 머신으로 데이터를 전송

본 발명의 바람직한 실시예에서 SNA 네트워크를 통해 애플릿을 로드하기 위한 방법 및 장치가 기술된다. 본 발명은 SNA 애플릿을 위한 애플릿 로더를 포함하는 3 프로세스의 결합을 설명한다. 이 3 프로세스는 초기 애플릿 로드, 클래스 장해 서비스, 그리고 SNA API 사용 가능화(enablement)이다. 이 프로세스들은 이하에 자세히 설명된다.

현재의 환경에서, 애플릿을 클라이언트 컴퓨터에 다운로드하는 것은 본질적으로 IP 태스크이다. 웹 브라우저는 HTTP 프로토콜을 통해 웹 서버로 연결되고, 웹 서버는 애플릿을 포함하는 자바 파일(클래스)을 클라이언트 컴퓨터로 다운로드하고, 클라이언트 컴퓨터는 자바 파일을 확인하고 자바 파일들을 가상 머신에서 실행시킨다.

우선, 다양한 전송 매개체(transports)를 통해 파일과 자바 프로그램들을 로드할 수 있는 대체 파일 전송 프로그램을 자바 애플릿 로더가 사용할 수 있게 하는 대체 프로세스가 설명된다. (IP 애플릿 로더는 자바 환경에서 잘 알려져 있으며, 본 발명은 IP를 사용하지 않는 특유한 애플릿 로더에 관한 것이다.) 이 프로세스는 웹 브라우저나 웹 서버를 필요로 하지 않는다. 유사한 프로세스가 클래스 장해를 서비스하기 위해 사용된다.

다음에, 자바 가상 머신을 확장하고, 애플릿으로 하여금 고유의 비 IP 프로토콜에 의해 통신하도록 하는 프로세스가 설명된다. 이 기술은 비 IP 애플릿 로딩과 결합되어, 애플릿이 비 IP 네트워크를 통해 완전히 고유하게 실행되도록 한다.

도 1a의 흐름도에서 나타낸 바와 같이, 다음의 프로세스들을 실행하기 위해 애플릿 로더가 사용된다. 먼저, (101)에서 사용자는 원하는 애플릿의 URL을 위해 프롬프트된다. 다음, 애플리케이션은 사용자에 의해 입력된 URL명을 판독한다(102). 이로서, 사용자로부터 입력을 받는 과정이 완료된다. 이후에, 애플리케이션은 URL을 파싱(parsing)하여(103), 사용자가 입력한 정보로부터 서버명과 애플릿명을 분리한다. 다음, 원하는 애플릿을 가진 서버와 접속이 설정된다(104). 이 접속은 IP 접속이 아니다. 바람직한 실시예에서, 이는 LU 6.2 프로토콜을 이용하는 SNA 접속이다. 상기 바람직한 실시예에서는 클라이언트 상에서 ACOPY를, 서버 상에서 AFTPD를 사용하며, 이들은 모두 IBM에서 출판한 것이다. 애플릿 로더는 자바 "네이티브 호출(native call)"을 ACOPY로 송출함으로써 접속을 설정한다.

다음에, 애플릿 로더는 애플릿의 제 1 클래스를 얻기 위해 서버에게 파일 요구를 송출한다(105). 통상적으로, 애플릿의 제 1 클래스는 애플릿과 동일한 이름을 가지며, ".class" 확장자가 붙는다. 일단 서버가 요구 신호를 수신하면, 서버는 자신의 디스크로부터 파일을 판독하여, 요구된 데이터를 전송하기 시작한다. 그 후, 애플릿의 제 1 클래스 파일을 포함하는 데이터는 클라이언트 측의 요구 애플리케이션에 의해 수신된다(106). 그 후, 수신된 데이터는 자바 호출 ClassLoader.defineClass()를 사용하여 자바 가상 머신으로 전송된다(107). 이것으로, 애플릿을 로드하는 과정이 완료된다.

바람직한 실시예에서, 파일 전송을 수행하기 위해 ACOPY는 IBM에 의해 출하된 형태 그대로 사용된다. 그렇게 하여, ACOPY는 서버로부터 수신한 파일을 로컬 디스크에 기록하며, 클래스 로더가 이를 판독한다. 이를 위해 도 1a에 정의된 프로세스에 약간의 수정이 필요하며, 도 1b에 이것이 도시되어 있다.

애플릿 로더가 애플릿의 제 1 클래스에 대한 파일 전송 요구를 송출한 후(105), ACOPY 루틴은 애플릿의 제 1 클래스 파일을 디스크에 기록하고(115), 이어서 애플릿 로더는 방금 ACOPY가 기록한 파일을 디스크로부터 판독한다(116). 일단 데이터가 디스크로부터 판독되면, 프로세스는 데이터를 자바 가상 머신에 전송(107)하면서 계속된다.

다른 실시예에서, ACOPY가 자바 파일을 디스크에 기록하는 대신, 자바 파일을 포함하는 데이터 버퍼(buffer)를 클래스 로더에 반환하는 것으로 쉽게 변경할 수 있다. 결과적으로 디스크 기록 및 차후의 판독을 생략할 수 있다.

현재의 애플릿 환경에서는, 전술한 단계들이 TCP/IP 전송 프로토콜에 의해 운영되는 웹의 HTTP 프로토콜을 사용하여, 넷스케이프사의 네비게이터와 같은 웹 브라우저에 의해 실행된다. 이는 종래의 대규모 기업 환경에서 다음과 같은 결점들을 갖는다.

- 현재의 애플릿은 SNA 네트워크 상에서 동작하지 않는다.

- HTTP 파일 전송은 텍스트 기반이므로, LU 6.2보다 비효율적이다.

- 현재의 애플릿 환경은 기존에 설치되어 있는 파일 전송 루틴에 의존하지 않고, 서버에 웹 서버가 설치될 것을 필요로 한다.

- 현재의 애플릿 환경은 클라이언트 상에서 웹 브라우저를 필요로 하고, 이에 따라 웹 전체를 탐색(browse)하기 위한 액세스를 허용하여, 네트워크 소유자(owner)에 의해 액세스되는 정보에 대한 제어를 상실할 수 있다. 그러므로, 애플릿을 SNA 상에서 로드하는 것은 웹 기반 애플릿 로드에 비해 장점을 갖는다.

일단 애플릿이 실행되기 시작하면, 애플릿은 서버 상에는 있으나, 아직 클라이언트에게로 다운로드되지 않은 클래스 파일에 대한 액세스가 필요하게 될 수 있다. 이 상태는 "클래스 장해(class fault)"라고 불린다. 클래스 장해가 발생하면, 가상 머신은 요구된 클래스명을 애플릿 로더에게로 전달한다. 애플릿 로더는 도 2a에 도시된 바와 같이 다음의 프로세스를 수행하여 SNA의 LU 6.2를 통해 클래스 장해를 처리한다.

우선, 클래스가 로컬 컴퓨터에 저장되었거나, 클래스 로더가 이전에 클래스를 접하여 캐쉬(cache)에 저장하여 놓은 경우와 같이, 요구된 클래스가 로컬 컴퓨터에 존재하고 있는지를 확인하는 테스트(201)가 이루어진다. 만일, 이 클래스가 로컬 컴퓨터에 있으면, 그 정보가 로컬 컴퓨터의 디스크로부터 판독되거나(202), 메모리에 캐쉬로서 저장되었다가 이 캐쉬로부터 판독된다. 만일, 클래스가 로컬 컴퓨터에 있지 않으면, 찾고 있는 애플릿을 포함하는 서버로 애플릿 로더가 접속을 형성한다(203). 통상적으로, 처음에 애플릿을 다운로드했던 그 서버 즉, 애플릿의 제 1 클래스가 로드되었던 서버가 모든 후속적인 클래스 파일들을 포함할 것이다.

다음에, 애플릿 로더는 애플릿의 제 1 클래스에 대해 파일 전송 요구 신호를 송출한다(204). 서버는 수신할 애플릿 로더에게 데이터를 전송하고, 애플릿 로더는 요구된 클래스 파일을 포함하는 데이터를 수신한다(205). 최종적으로, 애플릿 로더는 전송된 데이터를 자바 가상 머신으로 전송한다(206).

도 1과 함께 설명된 바와 같이, 만일 바람직한 실시예에서와 같이 ACOPY가 사용되었다면, 흐름은 도 2b에서 나타낸 바와 같이 변경된다. 도 2b에서, 애플릿 로더가 애플릿의 제 1 클래스에 대한 파일 전송 요구 신호를 송출한 후(204), 이 요구를 만족시키는 데이터가 디스크에 기록된다(214). 다음으로, 애플릿 로더는 디스크로부터 클래스 파일을 판독하고(215), 작업을 계속 진행하여 이 데이터를 자바 가상 머신으로 전송한다(206).

이 경우에도, 데이터를 메모리에 저장하도록 ACOPY를 변경하면, 디스크에 기록하고 판독하는 과정이 제거될 것이다.

이처럼, 애플릿을 포함하는 클래스는 위에서 기술된 발명을 이용하여 비 IP 네트워크 상에서, 특히 LU 6.2 상에서 로드될 수 있다. 그러나, 현재의 기술 수준의 한계로 인하여, 상기 애플릿은 자바의 소켓(socket) API를 이용하는 IP 상에서의 서버 구성 요소에게로의 통신만이 가능하다. (애플릿은 IBM 제품인 애니넷(AnyNet)을 이용하여 LU 6.2 상에서 소켓 API를 이용하여 통신할 수 있다. 그러나, 상기 애플릿은 LU 6.2의 트랜잭션 기능과 같은 서비스에 대한 액세스를 상실한다.) 이제, 본 발명에 의하여 어떻게 애플릿이 LU 6.2를 이용하여 통신을 할 수 있는지가 기술된다.

자바 애플리케이션들이 로컬 컴퓨터에 상주하는 어떠한 루틴(OS/2의 DLL과 같은)으로도 "네이티브(native)" 호출을 할 수 있다는 것은 본 기술 분야에 잘 알려져 있다. 예를 들어, IBM의 OS/2 통신 관리자(Communications Manager)에 포함되어 있는 것과 같이, 자바 애플리케이션이 네이티브 CPI-C 지원을 호출할 수 있게 하는 네이티브 CPI-C API(IBM이 출간한)의 상부에 프로그램 작성자는 약간의 코드를 더 추가할 수 있다.

그러나, 애플릿은 그러한 호출을 할 수 없다. 웹 브라우저에 포함된 자바의 보안 관리자가 네이티브 호출을 허용하지 않는다. 바이러스 감염을 예방하는 것이 주 관심사인 인터넷 환경에서는, 이러한 제한이 타당하다. 보안의 다른 방편들이 있게끔 되어 있는 인트라넷(Intranet) 환경에서는 위의 제한이 덜 타당함에도 불구하고 여전히 웹 브라우저에 의해 일방적으로 제한이 가해진다.

전술한 바와 같이, 여기에 설명되는 프로세스는 애플릿 로더를 포함한다. 자바에서는 애플릿 로더와 같은 프로그램이 애플릿 보안을 담당하는 일련의 코드를 대체할 수 있다. 이 코드는 보안 관리자로 불린다. 이 프로세스는 인트라넷을 위해 고안된 것이므로, 애플릿 로더가 덜 엄격한 보안을 요구하는 것은, 특히 기업 내에서 로드되는 애플릿의 경우에 합리적이다. 위에서 기록한 애플릿 로더가 기업/인트라넷 프로토콜인 LU 6.2를 사용하므로, 애플릿 로더가 로드하는 애플릿에게 다른 기능들을 호출할 수 있는 자유를 더 허락하는 것이 합리적이다.

자바 코드가 SNA API를 액세스하도록 하는, 자바에 의해 호출 가능한 라이브러리(Java-callable library)를 만드는 것은 본 기술 분야에 잘 알려져 있고, 8/27/96에 출판된 IBM의 기술 보고서 TR 29.2168에 설명되어 있다.

애플릿이 로드되었던 비 IP 네트워킹 프로토콜에 대한 API로 애플릿이 액세스하는 것을 가능하게 하는 메커니즘을 만드는 것은 본 기술 분야에 잘 알려져 있지 않으며, 특히 그 액세스가 보안성을 손상시키지 않을 때 더욱 그러하다. 본 발명은 네트워크에 대해 요구되는 보안성을 감소시키지 않으면서, 애플릿이 비 IP 네트워킹 프로토콜을 위한 API에 액세스할 수 있도록 하는 메커니즘을 포함한다.

전술한 애플릿 로드 메커니즘이 변경되어 보안 관리자 객체(object)를 인스턴스화한다. 그 후, 애플릿 로딩 메커니즘은 자바 가상 머신이 그 보안 관리자를 새롭게 인스턴스화된 보안 관리자 객체로 설정할 것을 요구한다. 그러면, 자바 가상 머신은 애플릿 로더에 의해 로드된 애플릿에 대한 모든 보안 상호 작용을 위해 상기 인스턴스화된 보안 관리자를 사용한다. (다른 애플릿 로더에 의해 로드된 애플릿은 그들을 로드한 로더의 보안 관리자의 지배를 받는다.)

애플릿이 보안 침해로 여겨질 수 있는 동작(로컬 디스크에 액세스하려 하거나 DLL을 로드하는 등)을 수행할 때, 자바 가상 머신은 애플릿을 로드한 애플릿 로더에 대해 등록된 보안 관리자를 호출한다. 본 발명의 보안 관리자는 도 3에 설명된 바와 같이, 다음의 과정을 수행한다.

우선, 애플릿 로더는 자바 가상 머신으로부터 보안 검사 요구를 받아들인다(301). 이 요구 신호가 보안 관리자에게 있어 유일하게 허용되는 "위반(violation)"인, DLL을 로드하기 위한 요구인지를 테스트한다(302). 만일, 이 요구가 DLL을 로드하라는 것이라면, 로드될 DLL의 이름을 판단하는 검사가 이루어진다. 만일, 그 이름이 자바/SNA API DLL의 이름이면(관행에 의하면 "javasna.dll")(303), 보안 예외는 무시되고(305), 프로세스가 종료되며, 애플릿을 종료시키지 않음으로써 이 동작을 암시적으로 허용한다. 만일, 요구 신호가 DLL 로드 요구가 아니거나, 자바/SNA API DLL을 로드하라는 것이 아니면, 보통의 예와 같이 보안 예외 처리가 실행되어, 실질적으로 애플릿을 종료시킨다(304).

전술한 프로세스는 애플릿이 비 IP 환경에서 효과적으로 기능할 수 있도록 한다. 이는 클라이언트와 서버의 오퍼레이팅 시스템(operating systems)으로서 공통적으로 OS/2를 이용하는 AFTP 서버와, ACOPY 클라이언트를 이용하는 SNA LU 6.2 네트워크의 바람직한 실시예를 이용하여 예시되었다. LU 6.2가 IP에 비해서 효율상의 잇점을 가지며, LU 2와 LU 6.2가 많은 기업에 의해 사용되기 때문에, 이러한 전송 프로토콜 상에서 애플릿을 운영하는 기능은 중요하다. 당업자라면, 본 발명이 SNA/LU 6.2 환경에 한정된 것이 아님을 명백히 알 수 있을 것이다. 본 발명은 애플릿을 실행하는 것이 이로운, 어떠한 비 IP 환경에도 적용 가능하다.

본 발명은 비 IP 네트워크 상에서 애플릿이 고유하게 실행되도록 하는 방법 및 장치를 제공한다. 본 발명의 방법 및 장치는 애플릿 다운로드를 개시하고, 클래스 장해가 일어난 경우 이를 서비스하고, TCP/IP 상에서 동작하는 자바의 보안 메커니즘을 손상시키지 않으면서 비 IP API로의 호출을 허용하는 애플릿 로더를 제공한다. 그 결과, 애플릿이 웹 브라우저 또는 웹 서버없이도 실행될 수 있게 된다.

Claims

비 IP 네트워크(non-IP network) 상의 컴퓨터 워크스테이션으로부터의 클래스 파일(class file)들로 표현되는 애플릿(applet)을 실행하는 방법에 있어서,

① 호출된 애플릿의 이름을 사용자가 입력하는 단계와,

② 상기 입력된 이름으로부터 서버명과 애플릿명을 파싱(parsing)하는 단계와,

③ 상기 서버가 사용자 입력이 유래한 워크스테이션이 아닌 경우, 상기 명명된 서버와의 접속을 설정하는 단계와,

④ 상기 애플릿의 제 1 클래스 파일을 위해 상기 서버에게 파일 전송 요구(file transfer request) 를 송출하는 단계와,

⑤상기 서버로부터 상기 제 1 클래스 파일을 수신하는 단계와,

⑥상기 제 1 클래스 파일을 가상 머신(virtual machine)으로 전송함으로써, 상기 애플릿을 실행하는 단계를 포함하되,

상기 애플릿이 추가적인 클래스 파일을 요구하면, 상기 가상 머신에 의해 '클래스 장해(class fault)'가 송출되고,

상기 클래스 장해에 응답하여, 상기 워크스테이션은 상기 명명된 서버와의 접속을 재설정하고,

상기 추가적인 클래스 파일을 위해 상기 서버에게 파일 전송 요구를 송출하고,

상기 서버로부터 상기 추가적인 클래스 파일을 수신한 후, 처리를 위해 상기 클래스 파일을 수신한 후, 처리를 위해 상기 클래스 파일을 상기 가상 머신으로 전송하는

애플릿 실행 방법.
제 1 항에 있어서,

상기 애플릿은 '네이티브 호출(native call)'을 호출(invoke)하며,상기 방법은,

상기 네이티브 호출이 DLL(dynamic link library)을 로드하라는 요구인지를 판단하는 단계와,

상기 네이티브 호출이 DLL을 로드하라는 요구인 경우, 로드될 DLL이 비 IP 프로토콜 API(Application Programming Interface)에 대한 것인지를 판단하는 단계와,

상기 요구가 비 IP 프로토콜 API에 대한 것이면, 요구를 충족시키고, 그렇지 않으면 요구를 거절하는 단계를 더 포함하는

애플릿 실행 방법.
컴퓨터 워크스테이션에 있어서,

① 컴퓨터 네트워크에 대한 비 IP 접속과,

② 상기 비 IP 네트워크를 통하여 호출될 애플릿의 이름을 사용자가 입력할 수 있도록 하는 수단과,

③ 상기 이름을 파싱하여 애플릿명과 서버명을 식별하는 수단과,

④ 상기 이름으로부터 파싱된 상기 서버가 상기 컴퓨터 워크스테이션이 아닌 경우, 상기 서버에 대한 비 IP 접속을 설정하는 수단과,

⑤ 상기 이름으로부터 파싱된 상기 애플릿의 제 1 클래스 파일을 위해 상기 서버에게 파일 전송 요구를 송출하는 수단과,

⑥ 상기 서버로부터 상기 제 1 클래스 파일을 상기 워크스테이션에서 수신하는 수단과,

⑦ 상기 비 IP 네트워크를 통하여 상기 워크스테이션으로부터의 상기 애플릿을 실행하는 수단과,

⑧ 상기 애플릿이 상기 서버로부터 추가적인 클래스 파일을 요구함을 표시하는 '클래스 장해'를 처리하는 수단과,

⑨ 상기 서버에 대한 비 IP 접속을 재설정하는 수단과,

⑩ 상기 추가적인 클래스 파일을 위해 상기 서버에게 파일 전송 요구를 송출하는 수단과,

⑪ 상기 서버로부터의 상기 추가적인 클래스 파일을 상기 워크스테이션에서 수신하는 수단을 포함하는

컴퓨터 워크스테이션.
제 3 항에 있어서,

상기 애플릿에 의한 '네이티브 호출'을 인터셉트(intercepting)하는 수단과,

상기 네이티브 호출이 DLL을 로드하라는 요구인지를 판단하는 수단과,

상기 네이티브 호출이 DLL을 로드하라는 요구인 경우, 상기 DLL이 비 IP 프로토콜 API에 대한 것인지를 판단하는 수단과,

상기 DLL이 비 IP 프로토콜 API에 대한 것이면, 상기 요구를 충족시키고, 그렇지 않으면 상기 요구를 거절하는 수단을 더 포함하는

컴퓨터 워크스테이션.