제 출 문

정보통신부장관 귀하

본 보고서를 "인터넷 기반 객체관리 기술 개발"의 1997년 최종 연구보고서로 제출합니다.

1997년 12월 31일

주관연구기관 : 한국전자통신연구원

총괄책임자: 책임연구원 박 치 항

연구책임자: 책임연구원 남 궁 한

선임연구원 유 인 원

선임연구원 김 동 진

선임기술원 이 근 영

행정기능원 정 선 미

공동연구기관 : (주)도화정보통신

과제책임자: 책임연구원 김 인 호

선임연구원 장 대 완

선임연구원 김 호 성

공동연구기관 : 울산대학교

과제책임자: 책임연구원 구 자 록

책임연구원 옥 철 영

책임연구원 이 명 준

책임연구원 이 명 재

선임연구원 김 규 년

선임연구원 고 재 진

선임연구원 김 종 수


요 약 문

1. 제목

인터넷 기반 객체관리 기술 개발

2. 연구 개발의 목적 및 중요성

가. 연구의 목적

1) 연구 배경

●인터넷의 정보화 사회 기본 구조화(Infrastructure)

전기통신망, 컴퓨터통신망, 사설망 등이 인터넷으로 통합되고 이를 효율적으로 이용하기 위하여는 서비스 제공자, 이용자, 망 관리자, 시스템 관리자 등을 포함하는 인터넷 기반 관리 구조가 제공되어야 함

●관리 대상의 변화로 새로운 관리 기능이 요구됨

폐쇄된 환경에서 제한적인 자원만을 관리하는 기존의 관리 기능은 관리 대상이 동적으로 변하는 인터넷 환경에서는 그대로 적용할 수 없음

●객체 단위의 관리 기술이 요구됨

인터넷이 분산 객체 환경으로 전이(轉移)됨에 따라 컴퓨팅 자원(프로그램, 서비스, 시스템, 망 등)을 분산 객체로 나타내고 이를 관리하기 위한 객체관리 기술이 필요하게 됨

2) 연구 목적

●인터넷 환경에서 컴퓨팅 자원(프로그램, 서비스, 시스템, 망 등)을 분산객체로 나타내고

●분산 객체를 효율적으로 관리하기 위한 객체 관리 기술을 연구하며

●객체 관리 기술을 적용한 인트라넷용 시스템 관리 프로그램을 구현

나. 연구 개발의 중요성

1) 객체 관리 기술의 필요성

●관리 기술의 필요성

인터넷 환경에서는 컴퓨팅 자원이 동적으로 변화하므로(연결, 단절, 내용 변경 등) 한정된 자원을 관리 대상으로 하여 제한된 기능(오류 여부, 연결 및 단절 여부 등)만을 제공하는 기존의 관리 기술로는 효율적인 관리를 할 수 없으므로 새로운 관리 기술이 필요하다.

●객체 기반 관리 기술이 요구됨

차세대 인터넷에서는 정보의 검색, 가공, 분배가 객체 단위로 이루어질 것으로 예상되므로 분산 객체를 다루는 기본 기능인 객체 찾기, 객체 타이밍, 객체 복구 등을 기반으로 하고, 객체를 관리 대상으로 하는 객체 기반 관리 기술이 요구된다.

2) 중요성

가) 기술적 측면

●인터넷 환경에서 필수적인 컴퓨팅 자원 관리 기술

인터넷은 개방형 처리를 가능하게 하였고 이러한 개방형 환경에서는 컴퓨팅 자원이 동적으로 변하기 때문에 분산된 자원을 이용하여 하나의 일관된 작업을 수행하기 위하여는 자원을 효율적으로 이용하게 하여주는 관리 기술이 필수적이다.

●차세대 정보처리 환경에서 핵심 기술로서 분산 객체 관리 기술

분산 객체 관리 기술은 차세대 정보처리 환경으로 예상되는 분산 객체 기술, 관리 대상을 객체로 나타내고 객체는 시스템, 망, 서비스, 소프트웨어 등 다양하게 변할 수 있는 관리 기술과 인터넷 기술을 기반으로 하는 복합 기술이다. 따라서 분산 객체 관리 기술은 관리 기술 그 자체만을 가지고 구현할 수 있는 것이 아니라 분산 객체 기술과 인터넷 기술을 동시에 보유할 때만 가질 수 있는 복합 기술로서 차세대 정보처리 환경이 인터넷 분산 객체임을 고려할 때 핵심 기술임을 알 수 있다.

●국내 경험 및 기술을 결집하여 만든 분산 객체 관리 기술

분산 객체 관리 기술은 기반 기술, 응용 기술, 응용 서비스 기술 그리고 소프트웨어 개발 기술 등 국내 경험과 기술을 적용하여 만든 결집체이다.

나) 경제적 측면

(1) 방대한 관리 소프트웨어 시장

●기존 관리 소프트웨어 분야 시장 규모

관리 분야 소프트웨어 시장 규모는 1996년 3월 Gartner Group에서 발표한 (표 1)과 같이 1997년에는 US$4,281,000,000규모로, 1999년에는 US$6,891,000,000 규모로 예측되고 있다.

(표 1) 관리 분야 시장 규모 (1996.3.,Gartner Group 예측, US$백만)

응용 분야

1995

1996

1997

1998

1999

2000

합계

ESD

300

420

588

794

976

1,172

4,250

Backup

410

513

641

769

907

1,043

4,282

성능 관리

120

156

211

284

378

492

1,641

사건 관리

210

273

355

444

546

655

2,482

Help Desk

275

358

465

581

715

857

3,250

작업 분배

90

126

176

229

294

352

1,267

망응용개발

300

420

588

794

1,016

1,219

4,337

Framework

230

276

331

381

430

473

2,122

LAN tools

300

435

631

883

1,174

1,468

4,891

출력/계정

35

46

59

74

91

109

414

관리 tools

140

182

237

296

364

437

1,655

총계

2,410

3,203

4,281

5,528

6,891

8,277

30,591

●중장기 시장 규모 전망

인터넷 기반 관리 소프트웨어 시장 규모는 인터넷 사용 시스템의 기하급수적인 증가에 따라 기존 시장보다 최소한 1.5배가 큰 규모의 시장을 형성할 것으로 예상되고 있으며 매년 전년도 대비 20%이상 증가할 것으로 예측된다.

●초고속정보통신망 구축에 따른 관리 소프트웨어의 새로운 시장 예상

정보화 사회의 구축을 사회 간접 자본으로 인식하고 시행 중인 초고속정보통신망 구축 사업의 일환으로 선도 시험망 구축, 공공 응용 서비스 개발, 기반 기술 개발 사업 등을 수행하고 있다. 이렇게 구축된 초고속정보 통신망을 기반으로 하여 인터넷 사용이 활성화됨으로 관리 소프트웨어의 새로운 시장이 예상된다.

(2) 세계 시장 선점

세계적으로 인터넷 기반 관리 소프트웨어 시장은 이제 형성 단계이고 아울러 제품도 개발 중에 있다. 따라서 본 과제의 결과물을 조기에 상품화하면 세계 시장을 선점할 수 있다고 예상된다.

●산업체 동향

많은 업체들이 기존의 사설 네트워크나 자기들만의 하드웨어 제품에 부가 가치를 더하는 방식으로 관리 소프트웨어를 제공하고 있다. 아직은 인터넷 기반으로 하는 관리 소프트웨어도 나오지 않았을 뿐만 아니라 인터넷에서 관리 대상을 객체를 표현하여 관리하고자 하는 연구, 개발은 극히 일부 선진 기업체와 연구소에서만 부분적으로 수행하고 있다. 한편으로는 기존의 네트워크나 시스템 단위로 수행하였던 관리 기능을 객체단위로 관리하는 방법에 관한 표준화 작업이나 객체 관리에 이용할 수 있는 공통응용 서비스의 개발에 초점을 맞추고 있다. 한편 인터넷을 이용하여 서비스를 제공하는 업체가 많아지고 업체 내에서 컴퓨터 통신망을 구축하는 사례가 많아지면서 많은 SI 업체들도 인터넷에서의 관리 기능에 대한 지원 전략을 개발하기 시작하였다.

●관리 제품 분석

인터넷 기반 관리 제품은 아직은 시장에 나오지 않았고 현재 연구, 개발 중에 있으며, 간단한 기능의 관리 소프트웨어는 1998년 하반기에는 시장에 나타나기 시작할 것으로 예상된다.

다) 사회적 측면

본 과제는 정보통신부 정보통신 연구개발 사업 중 처음으로 기 개발된 관리 기술과 새롭게 개발할 예정인 객체 중개자 기술을 결합하여 새로운 기술인 분산 객체관리 기술을 개발하는 사업으로 추진되고 있으며, 이는 앞으로 새로운 인터넷 분야의 소프트웨어 기술을 개발하는 데 당위성을 부여하고 참고가 될 수 있을 것이다. 나아가 본 과제를 통하여 초고속 정보통신망을 구축할 때나 향후 인터넷 시대로 가는데 보다 능동적으로 대처할 수 있다.

3. 연구개발의 내용 및 범위

가. 최종목표

인터넷 환경에서 자원을 분산 객체로 나타내고 효율적으로 관리하기 위한 핵심 기술 연구 및 이 기술을 초기검증물 개발

●세부 개발 목표

- 인터넷 객체관리 기술 개발

● 객체관리 공용서비스 개발

● 인터넷 기반 객체관리 소프트웨어 개발

1) 세부 목표 내용

●인터넷 객체관리 기술 개발

■Web 사용자 인터페이스

■인터넷 기반 객체관리 구조

●객체관리 공용서비스 개발

■ 객체 찾기 기능 (Naming Service)

■ 객체 타이밍 기능 (Timing Service)

■ 객체 사건 기능 (Event Service)

■ 객체 생명주기 기능 (LifeCycle Service)

●인터넷 기반 객체관리 소프트웨어 개발

■ Intranet용 시스템관리 소프트웨어 (초기검증물)

2) 인터넷 기반 객체관리 환경

나. 당해년도 (최종년도) 목표 및 내용

인터넷 환경에서 자원을 분산 객체로 나타내고 효율적으로 관리하기 위한 핵심 기술 연구 및 이 기술을 적용한 초기검증을 개발

●세부 개발 목표

● 인터넷 객체관리 기술 개발

● 객체관리 공용서비스 개발

● 인터넷 기반 객체관리 소프트웨어 개발

1) 세부 목표 내용

●인터넷 객체관리 기술 개발

■ Web 사용자 인터페이스

■ 인터넷 기반 객체관리 구조

●객체관리 공용서비스 개발

■ 객체 찾기 기능 (Naming Service)

■ 객체 타이밍 기능 (Timing Service)

■ 객체 사건 기능 (Event Service)

■ 객체 생명주기 기능 (LifeCycle Service)

●인터넷 기반 객체관리 소프트웨어 개발

■ Intranet용 시스템관리 소프트웨어 (초기검증물)

4. 연구 개발 결과

가. 주요결과 요약

연구 개발 항목

세부 내용

인터넷 객체관리 기술

(응용 서비스 측면)

●객체관리 기술 동향 분석

●객체관리 요구 사항 정의

●객체관리 구조 설계

객체 중개자 기술

●객체 중개자 설계, 부분 구현

●IDL-to-Java Compiler 구현, 시험

●IIOP 구현, 시험

●객체 정보 자료 저장 시스템 구현, 시험

●객체중개자 응용 프로그램 구현, 시험

(전자 투표 시스템)

객체관리 공용서비스

(객체 찾기, 사건, 타이밍, 생명주기)

●공용 서비스 분석, 설계

●공용 서비스 구현, 시험

초기 검증물

●인트라넷용 시스템 관리 요구 사항 정의,

구조 설계

●관리 프로그램 구현, 시험

1) 인터넷 객체관리 기술

기존의 관리 기술은 관리 대상을 시스템과 망으로 한정하였고 일부 제한된 응용 서비스를 제한된 방법으로 제한된 영역(domain)에서 관리하였으나 분산 객체 환경에서는 관리 대상이 시스템, 망 뿐만 아니라 응용 서비스, 프로그램 등에 이르기까지 다양하게 구성된다. 특히 분산 객체 기반에서는 분산 객체 컴퓨팅을 가능하게 하는 기본 기능과 연계되어서 관리 기능이 구현되어야 하고 이러한 요구 사항을 반영한 CORBA 기반 응용 서비스 구조를 분석, 설계하고 관리 시스템을 구현, 시험을 하였다.

2) 객체 중개자 기술

객체 중계자 부분은 CORBA 2.0을 만족하고 multimedia audio/video stream을 지원하는 iORB를 설계완료하고 일부분을 Java 구현하였다. IDL-to-Java compiler 도 OMG IDL-to-Java 규격(안)을 IIOP 부분은 CORBA 2.0을 지원하도록 설계, 구현하였다. 또한 객체 중개자가 수행되는데 필요한 information repository 및 객체관리 프로그램에서 사용할 정보 저장 시스템으로 객체 관리 정보 저장 시스템을 구현, 시험하였다. 나아가 객체 중개자를 이용한 응용 서비스로서 전자 투표 시스템을 구현, 시험하였다.

3) 객체 관리 공용 서비스 기술

객체 관리용 공용 서비스로는 CORBAServices 의 여러 공용 서비스 중에서 분산 객체 컴퓨팅 환경을 이용할 때 가장 기본 기능으로 간주되는 4개의 서비스, 객체 찾기/사건/타이밍/생명주기 서비스를 구현하고 시험하였다. 아울러 이들 각각의 서비스는 객체 관리에만 사용되는 것이 아니라 해당 기능을 필요로 하는 경우에는 별도로 사용할 수 있도록 Java 클래스로 구현, 시험하였다.

4) 초기 검증물 구현(인트라넷용 시스템 관리 프로그램)

초기 검증물로서는 시스템 관리를 대상 분야로 정하였고 특히 인트라넷에 속하여 있는 시스템을 대상으로 하였다. 기능으로는 오류 발생 여부, 구성 상태, 트래픽 상태 등을 기본으로 보여 주도록 하고 사용자 인터페이스로는 Web에서 Java 의 Management API(Application Programming Interface)를 기본으로 하여 필요하되 없는 기능은 독자적인 Management API를 클래스로 정하여서 이용하였다. 또한 가장 기본적인 기능과 Pure Java로 구현하였기에 시스템 종류에 관계없이 어디서나 수행될 수 있으므로 기존의 라우터 업자들이 기본 소프트웨어로 제공하되 자기 회사 제품에서만 수행되는 단점을 제거하였으므로 널리 사용될 것으로 예상한다.

나. 주요 연구 결과물 리스트

구 분

결과물 리스트

소스 코드

●CORBA/DCE 상호 연동 S/W 생성기

●CORBA/DCE 상호 연동 S/W 전처리기

●CORBA/DCE 상호 연동 S/W 정수형 변수 호출 프로그램

●CORBA/DCE 상호 연동 S/W "Enum" 시험 프로그램

●CORBA/DCE 상호 연동 S/W 은행 업무 Demo 프로그램

논문

●Intercommunication Between CORBA and DCE through Bridge

●Integration Multimedia Applications with Transaction Processing in Web

●An Integrated Approach to Legacy Data for Multimedia Applications

●Design of Audio/Video Stream Transfer Module in CORBA

●웹과 CORBA 상호 운용 방법에 대한 분석

●Java 와 CORBA

●iORB에서 RTP를 이용한 오디오/비디오 스트림 전송 방법

특허

●분산 객체 시스템에서 원격 객체 생성 및 접근 방법

●원격 객체 메소드 호출에서 대리 객체의 전달 인수 처리 방법

기술 문서

●CORBA/DCE 사이의 on-demand Bridge의 설계 및 구현

●인터넷 기반 객체 관리 기술개발 사업 수행 계획서

●인터넷 기반 객체 관리 기술개발 사업 수행 계획 요약서

●CORBA Programming(Java)의 환경

●CORBA Programming(C++)의 환경

●객체 공용 서비스 개략 설계서 (생명주기)

●객체 공용 서비스 개략 설계서 (시간)

●객체 공용 서비스 개략 설계서 (사건)

●객체 공용 서비스 개략 설계서 (찾기)

●인트라넷용 시스템 관리 기술 동향 분석서

●인트라넷용 시스템 관리 요구 사항 정의서

●A CORBA-based Management Framework for Distributed Multimedia Services and Applications.

●Design and Implementation of Bridge between CORBA and DCE

●Java 환경과 CORBA 환경을 연동하는 분산 컴퓨팅 플랫폼

●웹에서 트랜잭션과 멀티미디어 응용의 통합

●Intercommunication between CORBA and DCE through Bridge

●상용 자료를 멀티미디어 응용에서 통합 접근하는 방법

●iCom: Audio/Video Stream Transfer Modules in iORB

●CORBA에서 오디오/비디오 스트림 전송 모듈 설계

●iORB에서 RTP를 이용한 오디오/비디오 스트림 전송방법


5. 활용에 대한 건의

가. 예상 결과물과 활용 방안

연구 결과

활용 분야

활 용 방 안

인트라넷용

시스템 관리

소프트웨어

객체 저장

시스템

객체 찾기

소프트웨어

객체 타이밍

소프트웨어

객체 사건

소프트웨어

객체 관리

소프트웨어

●인트라넷 기본 구성요소

●사내 시스템 관리

●인터넷 시스템 관리

●분산 환경에서 사용되는 모든 자료 저장 업무

●객체 위치 제공

●서로 다른 영역에 있는 관리 대상 객체들의 시각

●대상 객체의 이상 유무

●분산 객체 기술

응용 분야

●조기 기술 전수하여 시장별 특성 있는 제품으로 상품화

●공개 소프트웨어로 발표하여

사용 권장하고 기반

소프트웨어로 사용하게 함

●조기 기술 전수, 상품화

●공개 소프트웨어로 발표하여

사용 권장하고 기반

소프트웨어로 사용하게 함

●조기 기술 전수, 상품화

●조기 기술 전수, 상품화

나. 사업화 계획(최종년도 결과물)

●1998년 4월에 사업 설명회를 통하여 "인트라넷용 시스템 관리 소프트웨어" 설명회를 개최하고 기술 전수하여 상품화를 추진한다.

●1998년도 10월경에 Web Browser에서 기본으로 제공되는 소프트웨어로 추진하여 인트라넷 구축 시에 별도의 추가 비용 없이 활용할 수 있도록 한다.

다. 향후 추진계획

●핵심 기술 조기 확보

향후 사용자 환경이 객체를 기반으로 한 인터넷 환경이 될 것으로 예상되며 이에 대비하기 위하여 객체 관리를 효율적으로 할 수 있는 기본 기술을 조속히 개발한다.

●표준화 현황 조기 파악

현재 표준화 과정에 있는 객체 관리 관련 표준화 활동 내용을 조기에 파악하여 표준화 제정과 동시에 기술 전수를 할 수 있도록 신속히 개발한다.

라. 건의 사항

인터넷은 향후 모든 처리에 관한 기반(infrastructure)이 될 것이며 나아가 향후 사용자 환경은 분산 객체를 기반으로 한 환경이 예상된다. 이에 대비하기 위하여 분산 객체를 효율적으로 관리할 수 있는 관리 기술과 이를 지원하는 분산 객체 기본 기술을 계속하여 개발하는 것이 절실히 요구됨.

6. 기대효과

가. 기술적 측면

인터넷 기반 분산 객체 관리 기술 개발 사업을 통하여 우리나라의 취약한 분산 객체 컴퓨팅 분야의 기반 기술을 획득할 것으로 전망하고 선진국에서 집중적으로 투자하여 개발 중인 분산 객체 기반 시스템 관리 기술을 보유하게 될 것이다. 아울러 지금까지 선진국이 독점하고 있는 분산 객체 기술분야에서 종속 관계를 탈피하여 우리나라의 독자적인 소프트웨어 기술을 가지게 되고 다른 소프트웨어 기술 분야에서 비약적인 발전을 가져올 수 있다.

1) 분산 객체 관리 기술 보유

● 분산 객체 공용서비스 기술

■ 객체 찾기 기술(Naming Service)

■ 객체 타이밍 기술(Timing Service)

■ 객체 사건 기술(Event Service)

■ 객체 생명주기 기술(LifeCycle Service)

● 인터넷 기반 객체관리 기술

2) 초기 검증물 기술 전수

인터넷 기반 소프트웨어 산업 활성화에 기여

3) 분산 객체 컴퓨팅 기술 활용

분산 객체 컴퓨팅 플랫폼 구축을 위한 기반 기술로 활용

4) 차세대 인터넷 핵심 기술로 활용

분산 객체 기술을 계속 적용하여 차세대 인터넷 핵심 기술로 활용

나. 사회 경제적 측면

1) 인트라넷 상호 운용성 보장

인트라넷 도입 시에 상호 운용성을 보장하는 표준 규격으로 활용

2) 사용자의 컴퓨터 활용도 향상

분산 객체 기술은 인터넷상의 상호 운용성 문제를 해결하여 주고 분산 객체 관리 기술은 사용자에게 편리한 인터넷 사용 환경을 제공하여 컴퓨터 활용도를 높여준다.

3) 전산 비용 절감

시스템의 관리 및 자원의 공동 활용을 가능하게 함으로써 효율적인 컴퓨팅 비용을 유지할 수 있다.

다. 산업적 측면

분산 객체 기술을 보유하게 되면 외국에 지급하여 온 많은 기술료를 절약하게 되고 더 나아가 시장 수요가 무한한 분산 객체 기반 소프트웨어를 상품으로 수출하여 기술 자립도를 높인다. 이 결과 우리 나라 정보 산업의 전반적인 분야에 파급되는 효과는 막대하다고 할 수 있으며 소프트웨어 후진국에서 소프트웨어의 선진국으로 발전하는 바탕을 확립할 수 있다.


SUMMARY

1. Title

Development of Object Management Technologies in Internet

2. Project Objectives and Backgrounds

a. Project Objectives

1) Backgrounds

● Internet as Infrastructure of Information Society

To utilize Internet efficiently which includes Telecommunication Network, Computer Network and Private Network, Management Framework should be provided for Service Providers, Service Users, Network Managers, and System Managers.

● Net Management Function due to Change of Management Targets

Traditional Management Functions which covers only limited resources in closed environment can not be applied to Internet environment, where Management Targets are changed dynamically.

● Necessity of Management Technology based on Object

Object Management Technology should be provided as Internet goes into Distributed Objects environment and Computing Resources(programs, services, systems, network etc.) are represented as Distributed Objects.

2) Objectives

● Represents Computing Resources(programs, services, systems, networks etc.) as Distributed Objects in Internet

● Do Research of Object Management Technology for efficient Management of Distributed Objects

● Development of Intranet System Management Program, which is a adaptation of Object Management Technology

b. The Importance of Object Management Technology

1) The Necessity of Object Management Technology

● The Necessity of Management Technology

New Management Technology is required as Computing resources(programs, services, systems, network etc.) are changed dynamically in Internet and Traditional Management Functions covers only limited resources with limited Management Functions(error, disconnection, status change etc.).

● The Necessity of Management Technology based on Object

Management Technology based on Object which utilizes CORBA services such as Naming, Event, Timing and LifeCycle service should be provided because Information Retrieval, Information Distribution and Information Handling are done by Object in Internet age.

2) The Importance of Object Management Technology

a) Technical Viewpoint

● Mandatory Computing Resources Management Technology in Internet

It is mandatory to have Management Technology which utilizes resources efficiently when you want to do one single job using distributed resources in Internet because Internet makes Open Distributed Processing possible and Computing Resources are changed dynamically in Internet.

● core technology in the Next Generation Information Processing

Distributed Object Management Technology is comprised of Distributed Object Technology of next generation information processing, Management Technology Which covers systems, networks, services and software, Internet Technology. Distributed Object Management Technology, core technology, can not be done by Management Technology itself but also need Distributed Object Technology and Internet Technology.

● Integration of Domestic Experience and Technology

Distributed Object Management Technology is the Integration of base Technology, Applied Technology, Application Service Technology and Method of Software Development.

b) Economical Viewpoint

(1) Huge Management Software Market

● Size of Traditional Management Software Market

(Source: 1996.3., Gartner Group), Unit: US$ in Million

Area

1995

1996

1997

1998

1999

2000

Total

ESD

300

420

588

794

976

1,172

4,250

Backup

410

513

641

769

907

1,043

4,282

Performance

120

156

211

284

378

492

1,641

Event

210

273

355

444

546

655

2,482

Help Desk

275

358

465

581

715

857

3,250

Task Allocation

90

126

176

229

294

352

1,267

Network

Appl. Dev

300

420

588

794

1,016

1,219

4,337

Framework

230

276

331

381

430

473

2,122

LAN Tools

300

435

631

883

1,174

1,468

4,891

Printing,

Accounting

35

46

59

74

91

109

414

Management

Tools

140

182

237

296

364

437

1,655

Total

2,410

3,203

4,281

5,528

6,891

8,277

30,591

● Market Size of Mid-Term

The market size of Object Management Software will be reached at 1.5 times of traditional management market size due to Internet and every year has 20% increase compared with previous year`s market size.

● New Market from Information Super Highway Project

Information Super Highway Project implements test-bed network, public application service development, and basic technology development and is going to make new software market based on active Internet.

(2) To Enter into World Market

The World Market of Internet based Management is just forming and products of such type are under development by many companies. The result od this research can go into the World Market if commercialization follows.

● Industry Trends

Many vendors only support management software on their hardware and there is no Internet based management software. Furthermore research of representing management targets as objects are done only a few number of companies and standardization of new management functions including common object services like Naming, Event, Timing, and LifeCycle service, in distributed object environment are under discussion. Many SI companies consider seriously management function to meet the requirements of services and communication network on Internet.

● Analysis of Management Products

There is no Internet based management product but expected to be in the market around the second half of 1998.

c) Social Viewpoint

This project combines traditional technology, management technology, and new era technology, object request broker technology, and makes new distributed object management technology. A sound basis for the new development of Internet software can also be shown through this project.

3. Topics and Scopes

a. Topics (Final Year)

● Represents Computing Resources(programs, services, systems, networks etc.)as Distributed Objects in Internet

● Do Research of Object Management Technology for efficient Management of Distributed Objects

● Development of Intranet System Management Program, which is a adaptation of Object Management Technology

● Scope (Final Year)

Development of Internet Distributed Object Management Technology

Development of Object Common Services for Object Management

Development of Internet based Object Management Software

1) Detailed Scope(Final Year)

● Development of Internet Distributed Object Management Technology

■ Web User Interface

■ Internet based Object Management Architecture

● Development of Object Common Services for Object Management

■ Naming Service

■ Timing Service

■ Event Service

■ LifeCycle Service

● Development of Internet based object Management Software

■ Intranet System Management Program (Prototype)

2) Internet based Object Management Environment

b. Scope (Final Year)

● Development of Internet Distributed Object Management Technology

● Development of Object Common Services for Object Management

● Development of Internet based Object Management Software

1) Detailed Scope(Final Year)

● Development of Internet Distributed Object Management Technology

■ Web User Interface

■ Internet based Object Management Architecture Level

● Development of Object Common Services for Object Management

■ Naming Service

■ Timing Service

■ Event Service

■ LifeCycle Service

● Development of Internet based object Management Software

4. Results

a. Summary of Primary Results

Area

Results

Internet based Object management

Technology (Application Level)

●Analysis of Technology Trends

●Definition of Users Requirements

●Design of Management Architecture

Object Request Broker Technology

●Design and Partial Implementation

●IDL-to-Java Compiler Impl. & Test

●IIOP Impl. & Test

●Object Storage System Impl. & Test

●Implementation and Test Electronic

Voting System

Common Object Services for Object

Management

(naming, event, timing, lifecycle)

●Analysis and Design

●Implementation and Test

Prototype

(Intranet System Management)

●Design of Architecture

●Implementation and Test

1) Internet based Object Management Technology

Traditional Management Technology covers only network and system plus limited application in a limited manner in closed domain but distributed object environment extends management targets to network, system, application service, and program. Especially Internet based Object Management technology can only be set-up on the common object services and we made analysis of CORBA based application architecture, design, implementation, and test on Internet,

2) Object Request Broker Technology

iORB(Our own ORB) supports CORBA 2.0 plus multimedia audio/video stream and was implemented by Java. IDL-to-Java compiler also follows OMG IDL-to-Java draft standard and IIOP also meets CORBA 2.0 without problems. Object storage system for information repository and temporary information of object status was designed, programmed, and tested in Java. As an example of iORB we also made electronic voting system and tested under heterogeneous ORB environment.

3) Common Object Services Technology

Common Object Services for Object Management are the basic functions of distributed object computing, which are Naming, Event, Timing, and LifeCycle service. We implemented these services as Java classes, so each service can be included into other program.

4) Prototype(Intranet System Management Software)

Prototype provides basic system management functions like error detection, dynamic configuration, and statistics of network and(or) system. We designed and tested web interface and Java Management API(Application Programming Interface) plus private Management API through pure Java.

b. List of Major Results

Item

List of Results

Source code



●CORBA/DCE Interoperable S/W Generator

●CORBA/DCE Interoperable S/W Pre-Processor

●CORBA/DCE Interoperable S/W Interger Variable Calling Program

●CORBA/DCE Interoperable S/W "Enum" Test Program

●CORBA/DCE Interoperable S/W Banking Demo Program

Paper






●Intercommunication Between CORBA and DCE through Bridge

●Integrating Multimedia Applications with Transaction Processing in Web

●An Integrated Approach to Legacy Data for Multimedia Applications

●Design of Audio/Video Stream Transfer Module in CORBA

●A Analysis of Interoperable Method between Web CORBA

●Java and CORBA

●Audio/Video Stream Transfer using RTP in iORB

Patent



●Remote Object Creation and Access Method in Distributed Object

System

●(Domestic and Foreign Patent)

●A Method of Proxy Object's Parameter Processing in Remote Object

Method Call (Only Domestic)

Technology

Documents


















●Implementation of on-demand Bridge between CORBA and DCE

●Project Plan of Object Management Technology in Internet

●Summary of Object Management Technology in Internet Project

●CORBA Programming Environment in Java

●CORBA Programming Environment in C++

●Block Design of Object Common Services (LifeCysle)

●Block Design of Object Common Services (Timing)

●Block Design of Object Common Services (Event)

●Block Design of Object Common Services (Naming)

●A Survey of System Management Technology Trend in Intranet

●A CORBA-based Management Framework for Distributed Multimedia Services and Applications.

●Design and Implementation of Bridge between CORBA and DCE

●Portable Distributed Object System using Trader Service in Internet

●Integration of Transaction and Multimedia in Web

●Intercommunication between CORBA and DCE through Bridge

●An Integrated Access Method to Legacy System for Multimedia

Applications

●iCom: Audio/Video Stream Transfer Modules in iORB

●Design of Audio/Video Stream Transfer Module in CORBA

●Audio/Video Stream Transfer Method using RTP in iORB


5. Suggestion for application

a. Expecting Results and Application

Result

Area

How to use

Intranet

System Management

Software

Object Storage

System

Naming Software

Timing Software

Event Software

Life Cycle

Software

●Core to Intranet

●In-house system managt.

●Internet system managt.

●Every task needs

Object Storage Function

●Object Location Function

●Timing Coordination

●Event of Object

●Any application based on

Distributed object

●Technology Transfer and

Commercialization

●Technology Transfer and

Commercialization

●Freeware(only object)

●Technology Transfer and

Commercialization

●Freeware(only object)

●Technology Transfer and

Commercialization

●Freeware(only object)

b. Commercialization Plan(Final Year`s Result)

● Technology Transfer of Intranet System Management Software in March 1998 and afterward Commercialization

● Try to be a standard component in Internet Browser around the first half

c. Future plan

● Early Development of Core Technology

In a near future user environment shall be changed into object based and to manage object efficiently we have to develop Object Management Technology and related Object Services as possible.

● We should check the status of standardization of Object Management in OMG and put the result into development.

d. Suggestion

Internet will be the infrastructure of next generation information processing era and distributed object is expected as user environment. To manage such an environment efficiently we need both management technology and distributed object basic technology which makes object management technology possible in Internet.

6. Expecting Effects

a. Technical viewpoint

we expect to have distributed object technology through Internet based Object Management Technology project and jump to advanced level in Internet software area, which will be key factor of Internet based management market.

1) Possession of Distributed Object Management Technology

● Common Object Services Technology

■ Naming Service

■ Timing Service

■ Event Service

■ LifeCycle Service

● Internet based Object Management Technology

2) Technology Transfer of Results and Commercialization

3) Base Technology for Distributed Object Computing Platform

4) Utilization of Results as Next Generation Internet Core Technology

b. Social and Economical Viewpoint

1) Standard of Interoperability in Intranet

2) Utilization of Computing Power for Users

Distributed Object Technology provides a solution of Interoperability in Internet and convenient environment, so we will have an increased utilization of computing resources.

3) Reduction of Computing Cost

Due to the efficient management of system and resources we can have economic computing cost.

c. Industrial Viewpoint

We can save royalty of distributed technology from foreign countries and can build our own basis of basic object technology. With the technology we expect to be in advanced countries of information processing.


CONTENTS

CHAPTER 1. INTRODUCTION

Section 1. The Necessity of Research

Section 2. Contents and Scope

Section 3. Major Results

CHAPTER 2. DEVELOPMENT OF INTERNET BASED OBJECT MANAGEMENT TECHNOLOGY

Section 1. Introduction

Section 2. Distributed Systems Management Technology

Section 3. Related Technologies Trends

Section 4. Design

Section 5. Implementation

Section 6. Execution and Results

Section 7. Other Items

CHAPTER 3. DEVELOPMENT OF OBJECT REQUEST BROKER

Section 1. Introduction

Section 2. Development of iORB

Section 3. IIOP Engine

Section 4. IDL-to-Java Compiler

Section 5. Object Management Storage

Section 6. Application for Object Request Broker

Section 7. Internet Application Service Management

CHAPTER 4. DEVELOPMENT OF COMMON OBJECT SERVICE

Section 1. Introduction

Section 2. Naming

Section 3. Event

Section 4. Timing

Section 5. Life Cycle

CHAPTER 5. REFERENCE SYSTEM (IMPLEMENTATION AND ANALYSIS)

Section 1. Introduction

Section 2. CORBA Programming Comparison

Section 3. Analysis of Reference System

Section 4. Modified Implementation of Reference System

CHAPTER 6. CONCLUSION

Bibliography

Abbreviations

Appendices

Appendix 1: List of Project Results

Appendix 2: List of Subordinate Project


List of Figures

(Figure 1-1) Internet based Object Management Environment

(Figure 2-1) Management Architecture of Distributed System

(Figure 2-2) WBEM Architecture

(Figure 2-3) JMAPI High-Level Architectural Components

(Figure 2-4) Management Software Architecture of Distributed System

(Figure 2-5) Configuration of Application Module

(Figure 2-6) Object Management Process Architecture

(Figure 2-7) Disk Monitoring Output

(Figure 2-8) Error Log Output

(Figure 2-9) Object Management Tree Architecture

(Figure 3-1) iORB Layout

(Figure 3-2) iORB Compiler Output Files

(Figure 3-3) iORB Core Communication Object Configuration

(Figure 3-4) iORB Runtime Component

(Figure 3-5) Example of IDL Interface

(Figure 3-6) Example of Client Application

(Figure 3-7) Example of Implimentation Object

(Figure 3-8) iORB IIOP Engine Architecture

(Figure 3-9) iOBR Compiler Architecture

(Figure 3-10) iORB Object Storage

(Figure 3-11) EVS/jORB System Layout

(Figure 3-12) CorbaMan Architecture

(Figure 4-1) Relationship of Common Object Service

(Figure 4-2) Communication Model of Event Service

(Figure 5-1) Output File of IDL Compiler of VisiBroker

(Figure 5-2) Output File of IDL Compiler of OrbixWeb

(Figure 5-3) BOAImpl Approach

(Figure 5-4) TIE Approach

(Figure 5-5) Socket Implementation between Client and Server

(Figure 5-6) Compile Step of JacORB IDL


List of Tables

(Table 1) Scope of Distributed System Management

(Table 1-1) Technology between Korea and Abroad

(Table 2-1) Function of Monitoring Method

(Table 3-1) Development and Execution Environment of iORB


목 차

제1장 연구개요

제1절 연구 개발의 필요성

제2절 연구 개발 목표 및 범위

제3절 주요 연구 개발 결과

제2장 인터넷 기반 객체관리 기술 개발

제1절 개 요

제2절 분산 시스템 관리 기술

제3절 관리 기술 동향

제4절 분산 시스템 관리 소프트웨어 설계

제5절 분산 시스템 관리 소프트웨어 구현

제6절 수행 및 결과

제7절 보완 사항

제3장 객체중계자 개발

제1절 개 요

제2절 iORB ,개발

제3절 IIOP 엔진 개발

제4절 IDL-to-Java 컴파일러 개발

제5절 객체 관리 정보 저장 시스템 개발

제6절 객체 중개자 응용 연구

제7절 인터넷 응용 서비스 관리 기술

제4장 객체 관리 공용 서비스 기술 개발

제1절 개 요

제2절 객체 찾기 서비스

제3절 사건 서비스

제4절 타이밍 서비스

제5절 생명 주기 서비스

제5장 참조 시스템 구축 및 분석

제1절 개 요

제2절 CORBA Programming 방법 비교

제3절 참조 시스템 분석

제4절 참조 시스템의 개량 구축

제6장 결 론

참고문헌

약어표

부록

부록1. 연구결과물 목록

부록2. 위탁 연구 및 공동 연구


그 림 목 차

(그림1-1) 인터넷 기반 객체 관리 환경

(그림2-1) 분산 시스템 관리 구조

(그림2-2) WBEM의 구조

(그림2-3) JMAPI High-Level Architectural Components

(그림2-4) 분산 시스템 관리 소프트웨어 구조

(그림2-5) 응용 모듈의 구성

(그림2-6) 객체관리 처리 구조

(그림2-7) 디스크 모니터링 화면

(그림2-8) 에러 로그 화면

(그림2-9) 객체 관리 트리 브라우저의 클래스 구조

(그림3-2) jORB 구성도

(그림3-2) iORB 컴파일러에 의해 생성되는 화일 종류

(그림3-3) iORB Core 통신 객체 구성도

(그림3-4) iORB 실행 컴포넌트 구성도

(그림3-5) IDL 인터페이스 작성 예

(그림3-6) 클라이언트 응용 작성 예

(그림3-7) 구현 객체 작성 예

(그림3-8) iORB LLOP 엔진 구조

(그림3-9) iORB 컴파일러 구조

(그림3-10) iORB 객체 저장소 구성도

(그림3-11) EVS/jORB 시스템 기본 구성도

(그림3-12) CorbaMan의 구조

(그림4-1) 공용 객체 서비스의 의존 관계

(그림4-2) 사건 서비스 통신 모델

(그림5-1) VisiBroker의 IDL 컴파일러에 의한 생성 파일

(그림5-2) OrbixWeb의 IDL 컴파일러에 의한 생성 파일

(그림5-3) BOAImpl Approach

(그림5-4) TIE Approach

(그림5-5) 클라이언트/서버 프로그램에서 socket의 처리 과정

(그림5-6) JacORB의 IDL 컴파일 순서


표 목 차

(표1) 관리 분야 시장 규모

(표1-1) 국내외 기술 수준 현황

(표2-1) 모니터링 메소드 수행 기능

(표1-1) jORB와 jORB 컴파일러 개발 및 운용 환경


제1장 연구 개요

제1절 연구 개발의 필요성

1. 국내의 기술수준 비교

(표 1-1)은 분산 객체 관련 기술들에 관련된 국내외 기술 수준을 비교한 것이다.

(표 1-1)국내외 기술 기준 현황

핵심기술내용

기술현황분석

(국내외 개발실태)

기술격차

(년 단위)

비 고

(경쟁자)

●인터넷 기반

분산 처리

●분산 객체

컴퓨팅

●분산 객체 관리

●분산 객체

공용 서비스

(Naming, Timing,

Event, Life Cycle)

●연구 및

시험 시제품 개발

●표준화 작성,

규격 제품 개발

●이론 연구 및

시제품 개발 중

●연구, 시제품개발

2년



2년



2년



2년

-DSTC(호주), 유럽 대학들

-APM(영국), GMD(독일)

-OMG(미국), DSTC(호주)

-전세계 연구기관,대학

-IONA,HP,IBM,DEC,SUN

-HP,IBM,DEC,SUN

-OMG(미국), 유럽연구기관

-IONA,IBM,DEC,HP,SUN

●객체 지향

정보 처리

●OMG에서 표준화

●일부 업체 상품화

2년

-IONA,HP,IBM,DEC,SUN

-OMG(미국), 유럽연구기관

●객체관리 구조

●표준화 단체 등에서

개발 중

2년

-기초 분석 단계

●객체관리 표준화

●표준화 작업 중

2년

-기초 개발 단계

한국전자통신연구원에서는 초고속정보통신망의 시험 망 구축 연구 및 개방 환경의 통신 규약, 개방 환경에서 분산 처리할 수 있는 기술인 분산 시스템 소프트웨어 기술 개발을 수행하고 있다. 또한 정보 저장소인 데이터베이스 서비스 시스템과 정보 검색 도구에 관한 연구 및 응용 기술을 개발하기 위한 연구도 수행하고 있다. 이들은 객체 지향 개발 방법을 이용하여 개발하였기 때문에 객체를 이용하는 소프트웨어 기반 기술도 확보하였다. 한편 관리 기반 기술에 관한 연구인 시스템 관리, 망 관리 등을 일부 수행하였고 인터넷에서 객체 컴퓨팅에 관한 객체 중개자 연구도 진행 중에 있다.

2. 국내 연구개발의 타당성 분석

국내에서 초고속 정보통신망 구축은 인터넷 사용을 일반화 시키고 다수의 사용자가 인터넷 정보에 접근할 수 있으므로 정보 손실이 미치는 영향을 최소화하기 위한 관리가 필수이다. 초고속정보통신망 구축에 필요한 장비는 개발되어 있으나, 운용을 제대로 하기 위한 관리 체계 및 기술은 아주 미흡한 상태이다. 현재 인터넷에서의 관리는 사용자들이 각자가 알아서 하는 등 인터넷 사용 증가에 대비한 관리 기술의 연구는 전무한 실정이다. 이에 대한 연구는 외국에서도 이제 시작하고 있는 분야로 이 분야에 대한 연구를 수행하여 이제까지 우리가 가지고 있던 분산 시스템 소프트웨어 기술과 접목하면 외국의 관리 기술과 대등한 관계를 이룰 수 있고 미래의 통합 정보 관리 기술 개발에 대비할 수 있다.

3. 기술개발의 당위성 범 국가적으로 추진하고 있는 초고속정보통신망에서 제공되는 응용 서비스들은 국가적으로 중요한 정보를 지니고 있으며, 국민들에게 보다 나은 정보 사회의 복지를 제공하는 수단이 될 것이다. 이것을 성공적으로 지원하기 위해서는 정보의 체계적인 관리가 보장되어야 한다. 따라서 본 연구에서 수행되는 연구 결과는 정보 서비스의 질을 높이고 안정적인 서비스를 제공하는 데 필수적인 기능이 될 것이다.

제2절 연구 개발 목표 및 범위

1. 최종 목표

인터넷 환경에서 자원을 분산 객체로 나타내고 효율적으로 관리하기 위한 핵심 기술 연구 및 이 기술을 적용한 초기검증물 개발

● 세부 개발 목표

- 인터넷 객체관리 기술 개발

- 객체관리 공용서비스 개발

- 인터넷 기반 객체관리 소프트웨어 개발

[세부 목표 내용]

● 인터넷 객체관리 기술 개발

■ Web 사용자 인터페이스

■ 인터넷 기반 객체관리 구조

● 객체관리 공용서비스 개발

■ 객체 찾기 기능 (Naming Service)

■ 객체 타이밍 기능 (Timing Service)

■ 객체 사건 기능 (Event Service)

■ 객체 생명주기 기능 (LifeCycle Service)

● 인터넷 기반 객체관리 소프트웨어 개발

■ Intranet용 시스템관리 소프트웨어 (초기검증물)

2. 당해연도(최종년도) 목표 및 범위

인터넷 환경에서 자원을 분산 객체로 나타내고 효율적인 관리를 하기 위한 핵심 기술 연구 및 이 기술을 적용한 초기검증물 개발

● 세부 개발 목표

- 인터넷 객체관리 기술 개발

- 객체관리 공용서비스 개발

- 인터넷 기반 객체관리 소프트웨어 개발

[세부 목표 내용]

● 인터넷 객체관리 기술 개발

■ Web 사용자 인터페이스

■ 인터넷 기반 객체관리 구조: 응용 서비스 측면

● 객체관리 공용서비스 개발

■ 객체 찾기 기능 (Naming Service)

■ 객체 타이밍 기능 (Timing Service)

■ 객체 사건 기능 (Event Service)

■ 객체 생명주기 기능 (LifeCycle Service)

● 인터넷 기반 객체관리 소프트웨어 개발

■ Intranet용 시스템관리 소프트웨어 (초기검증물)

제3절 주요 연구 개발 결과

1. 주요결과 요약

연구 개발 항목

세부 내용

인터넷 객체관리 기술

(응용 서비스 측면)

●객체관리 기술 동향 분석

●객체관리 요구 사항 정의

●객체관리 구조 설계

객체 중개자 기술

●객체 중개자 설계, 부분 구현

●IDL-to-Java Compiler 구현,시험

●IIOP 구현, 시험

●객체 정보 자료 저장 시스템

구현, 시험

●객체중계자 응용 프로그램

구현, 시험(전자 투표 시스템)

객체관리 공용서비스

(객체찾기,사건,타이밍,생명주기)

●공용 서비스 분석,설계

●공용 서비스 구현, 시험

초기 검증물

●인트라넷용 시스템 관리

요구 사항 정의, 구조 설계

●관리 프로그램 구현, 시험

2. 인터넷 객체관리 기술

기존의 관리 기술은 관리 대상을 시스템과 망으로 한정하였고 일부 제한된 응용 서비스를 제한된 방법으로 제한된 영역(domain)에서 관리하였으나 분산 객체 환경에서는 관리 대상이 시스템, 망 뿐만 아니라 응용 서비스, 프로그램 등에 이르기까지다양하게 구성된다. 특히 분산 객체 기반에서는 분산 객체 컴퓨팅을 가능하게 하는 기본 기능과 연계되어서 관리 기능이 구현되어야 하고 이러한 요구 사항을 반영한 CORBA 기반 응용 서비스 구조를 분석 설계하고 관리 시스템을 구현, 시험하였다.

3. 객체 중개자 기술

객체 중개자 부분은 CORBA 2.0를 만족하고 multimedia audio/video stream을 지원하는 iORB를 설계완료하고 일부분을 Java로 구현하였다. IDL-to-Java compiler도 OMG IDL-to-Java 규격(안)을 HOP 부분은 CORBA 2.0을 지원하도록 설계, 구현하였다. 또한 객체 중개자가 수행되는 데 필요한 information repository 및 객체관리 프로그램에서 사용할 정보 저장 시스템으로 객체 관리 정보 저장 시스템을 구현, 시험하였다. 나아가 객체 중개자를 이용한 응용 서비스로서 전자 투표 시스템을 구현, 시험하였다.

4. 객체 관리 공용 서비스 기술

객체 관리용 공용 서비스로서는 CORBAServices 의 여러 공용 서비스 중에서 분산객체 컴퓨팅 환경을 이용할 때 기본 기능으로 간주되는 4개의 공용 서비스인 객체 찾기, 사건, 타이밍, 생명 주기 서비스를 구현하고 시험하였다. 아울러 이들 각각의 서비스는 객체 관리에만 사용되는 것이 아니라 해당 기능을 필요로 하는 경우에는 별도로 사용할 수 있도록 Java 클래스로 구현, 시험하였다.

5. 초기 검증물 구현(인트라넷용 시스템 관리 프로그램)

초기 검증물로서는 시스템 관리를 대상 분야로 정하였고 특히 인트라넷에 속하여 있는 시스템을 대상으로 하였다. 기능으로는 오류 발생 여부, 구성 상태, 트래픽 상태 등을 기본으로 보여 주도록 하고 사용자 인터페이스로는 Web에서 Java의 Management API(Application Programming Interface)를 기본으로 하되 필요 없는 기능은 독자적인 Management API를 클래스로 정하여 이용하였다. 또한 가장 기본적인 기능과 Pure Java로 구현하였기에 시스템 종류에 관계없이 어디서나 수행될 수 있으므로 기존의 라우터 업자들이 기본 소프트웨어로 제공하여 자기 회사 제품에서만 수행되는 기존 관리 소프트웨어의 단점을 제거하였으므로 널리 사용될 것으로 예상한다.


제2장 인터넷기반 객체관리 기술 개발

제1절 개 요

최근 분산 시스템의 보급 확대로 인하여 시스템 관리 기술이 정보 분야의 큰 관심사로 떠오르고 있다. 전용 시스템에 비해 뛰어난 확장성과 유연성, 업무 개발 생산성 그리고 개방성 등으로 발전해온 분산 환경이 시스템 관리의 어려움에 직면하였다. 시스템 관리는 분산 환경의 도입 초기에는 간과되기 쉬우나 시간이 지나면 심각한 양상을 보인다. 설치 노드의 수가 증가하고 이 기종 하드웨어 및 소프트웨어가 늘어나면서 관리가 복잡해진다. 또한 여러 지역에 분산돼 있는 다양한 전산 자원의 시스템을 환경 변화에 따라 일관되게 유지하기 어렵고 원거리에 위치한 시스템들의 통제도 쉽지 않은 실정이다.

일반적으로 클라이언트 서버 모델이나 어플리케이션 개발 방법론은 비교적 잘 정리돼 있고 참조할 만한 사례들도 많아 구축 실패의 위험성은 그리 높지 않다. 그러나 유지 관리면에서는 아직 문제가 많다. 잘 구축된 시스템 환경일지라도 유지 관리할 수 있는 명확한 표준이 아직 없는 실정이다.

인트라넷용 시스템 관리 소프트웨어 개발은 인터넷 환경에서 지원을 분산 객체로 나타내고 효율적인 관리를 위한 핵심기술 연구 및 이 기술을 적용한 초기 검증물을 개발하는데 목적이 있으며, 구성, 성능, 상태를 보여주고 조정하는 인트라넷용 시스템 관리 소프트웨어를 개발한다.

제2절 분산 시스템 관리 기술

시스템 관리는 일반적으로 소프트웨어, 하드웨어 및 네트워크 등 시스템 운영에 사용되는 모든 자원을 사용자의 통제하에서 운영되도록 하는 것이다. 이와는 대조적인 네트워크 관리란 네트워크의 물리적 하부 구조인 허브, 라우터, 게이트웨이 등에 대한 관리를 말한다. 이 두 가지의 관리 형태 구별은 분명하지 않고 관리 도구들은 시스템과 네트워크를 통합하여 관리할 수 있도록 하여 준다. 다음(그림 2-1)은 분산 시스템 관리 구조이다. 분산 시스템 관리는 국제표준화기구(International Standards Organization: ISO)에서 정의한 장애 관리, 구성 관리, 계정 관리, 성능 관리 및 보안 관리의 5가지 기능으로 구성된다.

1. 장애 관리

장애 관리는 시스템의 비정상적인 동작에서 발생하는 특별한 이벤트인 장애의 발견, 격리, 수정을 의미한다. 장애 관리 기능에는 에러 로그 파일의 관리, 에러 탐지, 장애 분석과 추적, 시스템 진단 및 장애 복구 같은 기능들을 포함한다.

2. 구성 관리

구성 관리란 서로 연결된 개방 시스템들 사이의 서비스 초기화, 시작, 지속적인 동작을 위한개방 시스템 데이터 수집, 제어, 확인을 의미한다. 구성 관리의 기능에는 다음과 같은 기능들을 포함한다.

● 개방 시스템 동작 제어 값 지정

● 관리 객체들 사이의 관리 설정

● 관리 객체들의 초기화와 종료

● 개방 시스템들의 상태 정보 수집

● 개방 시스템의 설정 변경 탐지

● 개방 시스템의 설정 변경 수행

3. 계정 관리

계정 관리란 서로 연결된 개방 시스템들 사이의 시스템 자원들에 대한 사용과 이들 자원들에 대한 이용도를 추적하여 사용 비용을 산출하는 것을 말한다. 계정 관리 기능에는 다음과 같은 기능들을 포함한다.

● 사용자의 사용 비용 계산 및 사용 자원 계산

● 계정의 한계 설정과 자원 사용의 계획표 설정

● 객체 통신을 위한 다중 자원들의 복합 비용의 계산

4. 성능 관리

성능 관리란 서로 연결된 개방 시스템에서 시스템 자원들의 성능을 측정하는 것을 의미한다. 성능 관리의 기능에는 다음과 같은 기능들을 포함한다.

● 통계정보 수집

● 시스템 상태 변화 기록

● 물리적, 논리적 상태를 바탕으로 시스템 성능 결정

● 성능 관리를 위한 시스템 동작 모드 변경

5. 보안 관리

보안 관리란 서로 연결된 개방 시스템들 사이의 정보에 대한 통제를 통하여 중요 정보를 보호함을 의미한다. 보안 관리의 기능에는 다음과 같은 기능들을 포함한다.

● 보안 서비스의 생성, 삭제와 제어

● 보안 관련 정보의 분배

● 보완 관련 이벤트의 보고

분산 시스템 관리는 기본적인 5가지 관리 기능을 바탕으로 네트워크에 연결되어 존재하는 여러 자원들에 대하여 공통되고 일관성 있는 방법으로 관리를 수행하는 것을 말한다. 시스템 관리 환경의 구축은 관리 도구를 설치하여 일정한 기간 동안 해당 조직의 특성에 적절한 관리 모델의 구축 작업이 필요하다. 이 기간 동안 관리 운영자의 배치 권한 위임, 관리 업무의 흐름, 자원별 관리 방침의 정의 및 논리적 재배치 등 충분한 검토가 이루어져야 한다.

제3절 관련 기술 동향

웹이 네트워크 환경을 주도하게 되면서 자연스럽게 웹을 이용한 분산 시스템의 관리가 대두되고 있다. 인증 과정만 거치면 어느 곳에서나 접근가능하고 이미 구현된 구성 요소들을 그대로 이용할 수 있는 이점을 제공하기 때문이다., 웹을 이용한 객체 지향적 시스템 관리에 대한 연구 개발이 현재 WBEM(Web-Based Enterprise Management)과 JMAP(Java Management API)를 중심으로 이루어지고 있다.

1. WBEM

WBEM은 1996년 7월에 Intel, Cisco, Compaq, Microsoft 등 66개 업체가 웹을 이용한 관리 규격을 개발하기로 합의한 웹 기반의 기업 관리 방법이다. WBEM의 주목적은 현재의 시스템 관리 기술을 웹 기반으로 통합 정리하는 것이다. WBEM은 개방 시스템간의 네트워크 관리를 지원하기 위한 구조로 만들었다. WBEM의 구조는 분석과 조작을 위한 관리 객체에 대한 명백한 접근을 지원하고 클라이언트 분석을 위한 정보를 중앙에 집중시키며 관리 객체에 관한 정보의 접근에 필요한 구조와 협정을 포함한다. 또한 WBEM은 중요한 관리 프로토콜인 SNMP, DMI, CMIP를 포함하여 설계되었다.

WBEM은 크게 3개의 구성 요소로 되어 있다. 브라우저에서 각종 장치와 어플리케이션에 대한 경보와 사건 보고 등의 시스템 및 네트워크 관리 자료를 접근하고 수령하는 HMMP(Hypermedia Management Protocol), 피관리 객체를 인체를 인터넷에서 표현 하는데 사용되는 데이터 모델로서 공통 정보 모델로 알려진 HMMS(Hypermedia Management Schema), 그리고 어플리케이션에서 관리 자료를 입수해 중앙 콘솔에 표시하는 HMON(Hypermedia Object Manager) 등이다.

WBEM의 주 개요(Schema)는 CIM(Common Information Model)과 같이 알려진 관리 객체를 위한 데이터의 표현 형식으로 HMMP를 사용하여 접근과 조작이 이루어진다. WBEM은 웹 인터페이스를 위한 접근 가능한 표준과 이들간의 관계는(그림 2-2)와 같다.

● HMMS: 관리 환경을 나타내는 확장 가능한 데이터 모델이며 컴퓨터 시스템, 망, 어플리케이션들을 객체로 표현한다.

● HMMP: HMMP들 사이의 관리 정보를 상호 교환 하는데 사용된다. HMMP는 플래폼 영역 관리 서비스를 제공한다. HMMP는 요청/응답 형태의 관리 모델로 프로토콜에 독립적으로 작동한다.

● HMOM: 통신망의 구성 요소들인 객체들을 통한 WBEM 서비스의 정의를 나타내며 Java,CGI,CORBA, ActiveX 등을 이용하여 구현한다.

WBEM 표준을 이용하면 모든 시스템 관리에 동일한 프로토콜, 동일한 데이터 구조, 동일한 웹 기반 인터페이스를 이용하여 정보를 수집하고 제공하는 것이 가능하게 되지만 제정하게 될 표준 결과는 앞으로 주시해 보아야 할 것이다.

2. JMAPI

웹을 이용한 분산 시스템 관리의 다른 방법은 JMAPI 이다. JMAPI는 모든 기종의 시스템에서 동일한 Java 코드로 동일하게 작동한다. 이러한 특성을 이용하여 SUN에서는 자사 협력 업체들에게 분산 시스템 관리를 위한 이용자 인터페이스 표준 세트를 제공하여 관리 도구를 개발하는 노력을 줄이고 웹 기반의 관리를 위한 표준화 방법을 제안하였다. SUN은 JMAPI의 이점을 다음과 같이 주장하고 있다.

● Write Once, Run Everywhere

JMAPI는 시스템과 무관하게 동작하므로 한번 작성하면 모든 시스템에서 사용할 수 있다.

● Integration is the key

JMAPI에 준비된 클래스들은 객체와 사용자 인터페이스를 쉽게 통합할 수 있다.

● Eliminates Agent Versioning and Distribution Problems

JMAPI 는 분산 환경에서 발생하는 소프트웨어, 하드웨어의 버전 및 분산 문제에 대한 해결책으로 라이브러리와 클래스들을 안전하게 내려 받기 할 수 있다.

● A Model for Representing Distributed Resources

JMAPI 클래스들은 개발자들이 관리 자원을 묘사하는데 사용하는 관리 객체를 추상화할 수 있게 제공한다.

● Secure, Distributed Management Operations

JMAI 는 권한을 부여하거나 입증을 거쳐 비권한자에 대한 접근을 제한 할 수 있다.

이러한 장점에도 불구하고 JMAPI를 지원하는 플랫폼은 Windows95와 WindowsNT 및 SUN의 Solaris 제품에 한정되므로 진정한 분산 환경의 관리 도구라고 보기는 어렵다. 이러한 문제는 데이터베이스와 관련된 요소가 JDBC드라이버들과의 호환성 문제를 발생시킨다. 또한, JMAPI가 지원하는 것은 데이터베이스와 사용자 인터페이스 뿐으로 시스템 자원을 동작시키고, 관리하는 부분은 실제 구현하거나 기존의 망 관리 프로토콜을 이용하여야 한다.

가. JMAPI 구조

JMAPI는 브라우저 사용자 인터페이스 (Browser User Interface : BUI), 실시간 관리 모듈 (Adminstration Runtime Module : ARM) 및 관리군 (Appliance)으로 구성된다.

아래의 (그림 2-3)은 2개의 ARM으로 BUI 및 관리군과 통신하는 JMAPI의 구조이다. JMAPI의 기본적인 통신 방법은 RMI(Remote Method Invocation)이다. RMI는 직접 객체를 주고 받으므로 관리 객체를 다루는 JMAPI에 적합할 뿐만 아니라 보안적인 측면이나, 시스템에 걸리는 부하의 양에서도 일반적인 통신 소켓보다 유리하다.

BUI는 개발자를 위한 JMAPI 기반의 클라이언트측 클래스들을 포함하고 있다. 이 클래스들은 사용자 인터페이스와 응용 수준의 기능을 제공한다.

ARM은 JMAPI 애플릿에서 접근하며 특정한 관리 객체의 변화를 통보 받을 수 있다. 관리군은 JMAPI를 사용하여 모든 장치들이 실행될 때 시스템들을 관리하며 대부분 ARM에서 수행된다.

나. SNMP

SNMP는 현재 가장 많이 사용되는 관리 프로토콜이다. JMAPI에서는 기존의 SNMP에이전트에 대해 접근할 수 있다. JMAPI는 SNMP 에이전트와 통합하기 위해 SNMP 인터페이스를 제공하며 SNMP 트랩을 JMAPI 이벤트로 변환시키는 기능을 제공한다.

제4절 분산 시스템 관리 소프트웨어 설계

본 과제에서는 웹을 이용한 분산 시스템 관리 기술 중에서 JMAPI를 이용한 연구 방법을 선택하였다. 또한, 국제 표준화 기구에 의해 정의된 5가지 기능 중에서 장에 관리, 구성 관리, 성능 관리를 우선 구현하고 향후에 이를 보완하는 방향으로 추진하였다.

이 장에서는 분산 시스템 관리 소프트웨어를 모듈별로 구분하여 각 모듈의 기능을 기술한다. 분산 시스템 관리 소프트웨어는 분산 시스템 관리자가 직접 접근 가능한 분산 응용 모듈, 전송 규약에 관한 투명성과 응용 모듈의 이식성을 제공하는 관리 하부 구조 모듈, 관리자의 요구 사항을 에이전트 시스템에게 전달하는 통신 규약을 정의하고 있는 전송 규약 모듈로 (그림 2-4)와 같이 구성된다.

1. 응용 모듈

응용 모듈 은 관리자의 요구 사항을 그래픽 사용자 인터페이스로 표현하는 것으로 모니터링, 이벤트 관리, 객체 관리로 구성된다. 응용 모듈은 시스템 관리 전반에 걸쳐 사용되는 모듈로서 가장 기초적인 기능을 담당한다. 아래의 (그림 2-5)는 응용 모듈의 구성 관계를 나타낸다.

가. 모니터링

모니터링은 분산 환경에서 네트워크에 연결된 각 시스템들의 자원 구성 및 상태 정보를 나타낸다. 모니터링은 시스템 성능 관리에 해당하는 부분으로서 사용자 인터페이스를 구현하는 부분과 브라우저에서 요청된 내용을 처리하는 관리 서버, 에이전트 시스템에 상주하는 에이전트 모니터링으로 구성된다. 이들의 구성 내용은 아래와 같다.

● 디스크 모니터링

디스크별 사용 공간과 여유 공간 및 사용율을 나타낸다.

● 프로세스 모니터링

시스템에서 활동중인 프로세스, 수행 시각, 수행 시간 및 수행 프로세스 이름 등을 나타낸다.

● 네트워크 모니터링

프로토콜별 활동중인 소켓, 인터페이스별 입출력 패킷수, 충돌 횟수, 라우팅 테이블 정보, 멀티캐스트 라우팅 테이블 정보, 각 프로토콜 별 통계등을 나타낸다.

● 프린터 모니터링

프린터 큐 상태, 큐에 존재하는 작업, 작업에 대한 크기, 작업 수행자, 수행 시각 등의 정보를 나타낸다.

● 시스템 자원 모니터링

시스템의 CPU 상태, 가상 메모리의 상태, I/O 상태, 접속 사용자 현황과 각 사용자의 현재 작업중인 내용 등을 나타낸다.

모니터링에서 브라우저는 관리자가 모니터링 항목을 선택할 수 있게 화면을 구성하고 요청한 결과를 표시하는 화면 구성한다. 또한 주기적으로 관리 서버의 이벤트 관리자에게 새로운 이벤트 발생 여부를 확인하여 관리자의 화면에 통보한다.

모니터링은 관리 서버를 항상 가동한다. 브라우저를 통해 전송된 관리자의 요구에 따라 모니터링 관리 서버는 디스크, 프로세스, 네트워크, 프린터 및 시스템 자원에 대한 정보를 각 에이전트에 요청하고 결과를 관리자 브라우저에 전달한다.

또한 모니터링은 에이전트를 항상 가동한다. 이 에이전트는 디스크, 프로세스, 네트워크, 프린터, 시스템 자원을 수집하는 하위 에이전트를 동시에 가동하고 있으며 모니터링 관리 서버를 통하여 자료를 요청하면 요청된 내용에 따라 하위 레벨 에이전트에게 그 내용을 전달하여 수행 결과를 관리 서버에게 전달한다.

나, 이벤트 관리

이벤트 관리는 시스템 관리의 장애 관리에 해당하는 부분으로서 사용자 인터페이스를 구현하는 부분과 브라우저로부터 요청된 내용을 처리하고 각 에이전트에서 발생하는 이벤트를 파일에 기록하는 관리 서버의 데몬 그리고 에이전트 시스템에 상주하는 이벤트 관리 데몬으로 구성된다.

이벤트 관리는 분산 환경에서 네트워크에 연결된 각 시스템 자원에서 발생하는 오류, 시스템 상태 변화 등에 대한 이벤트를 생성, 조회 그리고 삭제할 수 있게 한다. 또한 이러한 이벤트를 로그에 기록하여 시스템 진단 및 분석 자료로 사용한다.

● 에러 로그 검사

시스템 오류에 대한 분석 정보를 나타낸다.

● 상태 변화 통지 및 처리

각 시스템에서 발생되는 상태 변화에 대한 이벤트들을 수집하여 관리자에게 통보하고 관리자로 하여금 그 내용을 처리할 수 있게 한다.

이벤트 관리 방법은 브라우저를 통하여 관리자가 이벤트 관리 항목을 처리할 수 있게 화면을 구성하고 그 결과를 표시하는 화면을 구성한다. 또한 주기적으로 상시 가동중인 관리 서버에게 새 이벤트 발생 여부를 문의하여 이벤트 발생 여부를 관리자 화면에 통보한다.

이벤트 관리는 관리 서버를 상시 가동하고 있으며 브라우저를 통하여 요청된 에러 로그,이벤트 조회, 삭제 등 관리자의 요구를 자신이 관리하는 이벤트 데이터베이스에서 처리하여 결과를 브라우저에 되돌리거나 에이전트에 요청하여 그 결과를 브라우저에 전달한다.

에이전트는 시스템에게 발생하는 이벤트를 감시하고 관리 서버에게 이벤트 처리를 요구한다. 관리 서버는 시스템에서 이벤트가 발생하는지 감사하고, 또한 관리 서버가 요청한 이벤트를 수행한다.

다. 객체 관리

분산 시스템 환경의 구성 요소들의 물리적, 논리적인 정보를 총괄하여 관리하며 시스템을 구성하는 자원들을 객체로 표현한다. 객체 관리는 호스트 중심으로 자원 정보를 구성하여 데이터베이스에 저장하며 워크스테이션, 프린터, CPU, 메모리 등의 객체를 생성, 삭제, 수정 조회하여 제어 기능을 수행한다. 이러한 객체들의 정보는 모니터링과 이벤트 관리 기능 수행에 사용된다.

객체 관리의 핵심 요소는 시스템의 정보를 저장하는 데이터베이스와 데이터베이스를 일관성 있고, 안전하게 다루어 주는 객체 관리 데몬이다. 객체의 모든 기록, 수정, 열람은 객체 관리 데몬을 통해서 이루어지고 객체 관리 데몬은 인증된 객체 관리 에이전트, 모니터링이나 애플릿에 한하여 데이터베이스에 대한 접근을 허용한다.

객체 관리는 호스트를 등록하는 것으로 시작한다. 호스트가 입력되면 입력된 호스트의 객체 관리 에이전트로부터 그 시스템을 구성하고 있는 기타 구성 요소들에 대한 정보를 객체 관리 데몬이 받아서 데이터베이스에 기록한다. 객체 관리 에이전트는 관리 대상 에이전트에 존재하고 그 호스트의 구성 정보를 객체 관리 데몬에 보낸다. 객체 관리 에이전트는 RMI를 이용하여 제작 되었으며 호스트의 명령을 분석하여 정보를 얻는다. 사용자는 브라우저의 애플릿을 통하여 각 객체들의 값을 열람하고, 수정할 수 있다. 모니터링 데몬은 모니터링할 객체의 정보를 객체 관리 데몬에서 얻고, 모니터링 값이 등록된 정보와 일치하는지 살핀다. 만약, 다르다면 이벤트를 발생시킨다.

라. 사용자 접속

응용 모듈은 기본적으로 모니터링, 이벤트 관리, 객체 관리 그리고 관리자의 인증절차가 요구되므로 모듈 구현 이외에 사용자 접속 기능을 추가하여 상호 작용을 정의한다.

사용자 접속 기능은 시스템 관리 소프트웨어를 수행할 관리자 인증 절차를 수행한다. 관리 서버에서 가동중인 HTTP서버의 디렉토리 인증 기능을 이용하여 특정 디렉토리에 관리자의 계정을 설정하고 응용 모듈을 구현한 파일들을 위치하며 관리 프로그램을 구동하는 사용 권한을 검사하고 인증된 사용자에 한하여 관리 프로그램을 구동하게 하는 과정을 수행한다.

2. 관리 하부 구조 모듈

관리 하부 구조 모듈은 응용 모듈을 통해 들어온 관리자의 요구 사항을 전송 규약 모듈로 전달하는 중개자 연할을 수행한다. 관리 하부 구조는 JMAPI로 인터페이스를 구현한다. 관리 하부 구조 모듈에서는 HTTP서버, 관리 객체 Factory, 데이터베이스 인터페이스의 3가지 기본 서비스를 제공한다. 관리 하부 구조 모듈은 응용 모듈에서 활동하는 관리 객체들을 제공하는 구조를 이루며 이 구조 안에서 응용 모듈에 자체 서비스를 제공하거나 전송 규약 모듈로 관리자의 요구 사항을 전달하는 중개자의 역할을 수행한다.

3. 전송 규약 모듈

전송 규약 모듈은 TCP/IP 네트워크를 기반으로 한 RMI를 사용한다. RMI는 소켓을 추상화하여 원거리 분산 객체의 메소드를 직접 액세스할 수 있다. RMI는 개발 언어적인 측면에서 자연스럽고 사용하기 쉬우므로 분산 시스템 관리 프로그램 제작에 소요되는 시간과 노력을 절감할 수 있다.

4. 모듈간 상호 작용

관리자가 요청한 내용은 응용 모듈에서 관리 하부 구조 모듈로 전달되고 관리 하부 구조 모듈은 수신된 내용을 분석하여 자체 서비스를 제공할 것인지 아니면 원격 객체에 의뢰할 것인지 판단한다. 관리 하부 구조 모듈에서 원격 객체와 관련된 자료라고 판단되면 전송 규약 모듈을 요구 사항을 전달하고 전송 규약 모듈은 통신망을 통하여 에이전트에 요구 사항을 전달한다. 에이전트에서 처리된 결과는 다시 역순으로 응용 모듈에 전송되어 관리자에게 응답하게 된다.

제5절 분산 시스템 관리 소프트웨어 구현

1. 모니터링 서버 구현

모니터링 서버는 주 화면을 구성하며 관리자로 하여금 모니터링 관리 항목을 선택 할 수 있게 한다. (그림 2-7)의 디스크 모니터링 화면과 같이 좌측의 트리 구조 창은 관리 항목을 나타내고 화면 중앙의 창은 관리자의 선택 항목을 표시하며 화면 중앙 하단부는 선택한 항목에 대한 처리 상황을 나타낸다.

트리 항목을 선택하면 트리 구조를 분석하여 선택된 에이전트의 해당 기능을 (표 2-1)과 같이 실행한다.

메소드 명

수행 기능

getDiskStatus

디스크 상태

getProcessStatus

프로세스 상태

getNetwork_anv_Status

네트워크 활성 소켓별 상태

getNetwork_i_Status

네트워크 인터페이스별 상태

getNetwork_r_anv_Status

네트워크 라우팅 테이블상태

getNetwork_M_nsStatus

네트워크 멀티캐스트 라우팅 테이블 상태

getNetwork_s_Status

네트워크 프로토콜별 통계

getPrinterStatus

프린터 상태

getCPUStatus

CPU 상태

getMemoryStatus

가상 메모리 상태

getIoStatus

입출력 장치의 입출력 상태

getLoStatus

접속 사용자 상태

이 메소드들은 RMI를 사용하여 관리 서버에 있는 모니터링 객체의 원격 메소드를 수행한다. 관리 서버의 역할은 특정 에이전트 시스템이 네트워크를 통해서 접근 가능한지를 판단하는 서비스를 제공하며 중개자로서 관리자의 요구를 해당 에이전트 시스템의 원격 객체인 모니터링 데몬에게 전달하고 결과를 되돌리는 것이다. 에이전트 시스템에서 작동하는 원격 객체는 모니터링을 각 기능별로 수행하는 단일 기능의 원격 객체들을 통합하고 있다.

주기적인 모니터링을 일정 시간 간격으로 계속해서 자료를 수신해야 하므로 타이머의 도움이 필요하다. 주기적인 데이터를 수신하기 위해 First, Next, Last 라는 구조를 사용한다. First는 해당 기능의 시작을 요청하고 타이머는 계속해서 중간 데이터를 요청하는 Next를 부른다. 관리자가 트리 창에서 다른 항목을 선택하면 Last가 불려진다. Last는 에이전트 시스템이 사용하던 자원을 반납한다. 주기적인 모니터링은 네트워크의 인터페이스별 상태, CPU상태, 가상메모리 상태, 입출력 상태의 4가지를 수행한다.

이 과정을 통하여 브라우저의 애플릿에 자료가 수신되면 중앙부의 화면에 그래프나, 테이블로서 표시하게 된다. 또한 애플릿에서 10초 간견의 일정한 시간 단위로 관리 서버의 이벤트 객체를 호출하여 전체 에이전트 시스템에서 새로 발생된 이벤트가 있는지 검사하여 발생 사실을 확인한다.

2. 이벤트 관리 서버의 구현

이벤트 관리의 주 화면은 애플릿을 등록하여 구성한다. (그림 2-8)의 예와 같이 중앙 화면은 이벤트 목록을 표시하는 테이블이며 그 하단에는 이벤트를 조작하는 기능 버튼을 배치하고 제일 하단에는 각 기능들이 수행될 때 전개되는 상황을 나타내도록 구성하였다. 애플릿이 초기화면되면 마지막으로 읽은 다음 이벤트 목록들을 요청한다.

관리 서버의 원격 객체는 이벤트 관리의 중추로서 애플릿의 이벤트 처리 요청과 이벤트 수집 에이전트에 의하여 수집된 이벤트 추가 요청을 처리한다. 각 에이전트의 이벤트를 수집하는 원격 객체는 10분마다 시스템에서 발생하는 이벤트를 검사하고 관리 서버의 원격 객체를 호출하여 이벤트를 등록하며 FIFO방식으로 목록을 관리한다.

3. 객체 관리의 구현

객체 관리는 데이터베이스 관리, 데이터베이스 사용자 인터페이스, 객체 관리 에이전트 및 객체 관리 애플릿을 관리하는 것이다. 데이터베이스 관리는 JMAPI에서 데이터베이스의 조작을 위하여 제안한 MO(Managed Object)와 화일 포맷을 이용하였다. 데이터베이스 사용자 인터페이스는 그래픽 패널에 객체의 생성, 삭제, 수정 등의 액션을 라벨이나 이미지 버튼으로 정의하거나 객체의 속성을 텍스트 필드에 정의한다. 버튼은 JMAPI 클래스를 사용하고, 버튼을 누르면 패널에서 정의한 액션이 수행된다.

객체 관리 에이전트는 시스템 정보를 얻는 RMI 메소드를 정의하여 에이전트의 정보를 애플릿에 제공한다. 이 메소드들은 시스템에 독립적인 순수 Java 코드 메소드와 시스템에 의존적인 고유 메소드로 구분한다. 고유 메소드는 JMAPI에서 외부 명령어의 실행, 표준 입력을 스트링 변수에 입력, 스트링에서 필요한 정보를 추출하는 기능 등을 제공한다.

객체 관리 애플릿은 객체의 생성, 수정, 삭제, 열람 기능을 가지고 있다. 이 애플릿은 네트워크 관리 대상의 위상 관계를 표현하는 트리 구조의 구현을 중심으로 작성하고, 사용자 인터페이스까지 이 구조에 포함하였다. 여기 사용된 트리는 JMAPI의 패키지를 사용하여 전체 네트워크의 이름을 갖는 최상위 폴더를 구성하고 그 아래에 객체를 멤버로 갖는 개별 호스트, 호스트 에 종속하는 아이템 그룹 및 그룹에 속한 개별 아이템으로 구성한다. 예를 들어 아이템 그룹 Printer 에는 개별 아이템 printer1과 printer2가 소속된다.

제6절 수행 및 결과

1. 수행 환경 설정

분산 시스템 관리 소프트웨어를 수행하려면 관리 서버와 에어전트 시스템에 반드시 Java와 JMAPI 라이브러리가 설치되어야 하며 관리 서버에서 웹 서버와 데이터베이스가 설치되어야 한다. 소프트웨어 수행을 위해 제작된 Java 클래스 파일들은 관리 서버의 웹 서비스 루트 디렉토리에 위치하고 에이전트 시스템의 원격 객체용 파일들은 관리자 계정 디렉토리에 위치한다.

RMI 서버를 지원하기 위해서 데몬을 생성할 때는 반드시 Java 설치에 제공되는 rmiregistry를 먼저 수행해야 한다. Windows 환경에서는 "start rmiregistry" 명령으로 수행하고 UNIX 환경에서는 "rmiregistry &" 명령으로 수행한다. rmiregistry는 호스트에 원격 객체 명부를 생성하고 등록하여 RMI 데몬들이 원격 객체와 이름을 연결하는데 사용할 수 있게 한다.

2. 모니터링 수행

각각의 에이전트 시스템에서 모니터링 데몬을 먼저 수행한다. 수행 명령은 명령어 행에서 "java MonAgent"를 입력한다. 모든 에이전트 시스템에서 모니터링 데몬이 수행되면 관리 서버에서 모니터링 데몬을 수행해야 한다. 수행 명령은 명령어 행에서 "java MonServerImp"를 입력한다.

3. 이벤트 관리 수행

각각의 에이전트 시스템에 대해 이벤트 관리 데몬을 먼저 수행한다. 수행 명령은 명령어 행에서 "java EventAgent"를 입력한다. 모든 에이전트 시스템에서 이벤트 관리 데몬이 수행되면 관리 서버에서 이벤트 관리 데몬을 수행한다. 수행 명령은 명령어 행에서 "java EventDbDa-emonImp"를 입력한다.

4. 객체 관리 수행

객체 관리는 데이터베이스를 설치하고 컴파일된 모든 관리 객체 클래스를 데이터베이스에 등록한 다음 객체 관리 데몬을 수행한다. 객체 관리 데몬 수행 명령은 Windows에서 jmapisvc.exe를 실행시킨다. 다음으로 객체 관리 에이전트를 수행하여 관리군을 동작시킨다.

객체 관리에 접속하는 방법은 각 에이전트 시스템과 관리 서버의 데몬들이 수행된 후 브라우저를 이용하여 관리 서버에 접속하고 홈 페이지 화면에서 인트라넷용 시스템 관리 소프트웨어 항목을 선택하면 관리자 인증 절차가 수행되고 인증을 받은 사용자의 화면에 관리 화면이 제공된다. 모니터링 화면의 트리 구성 화면에서 최상위 노드인 관리 서버를 선택함으로써 관리 대상 에이전트 시스템들의 목록을 관리 서버의 객체 관리 데몬에서 수신하는 것으로부터 시작된다.

5. 산출 화면 내역

본 연구 과제의 산출 화면은 HotJava 브라우저에 의해 생성된 화면이다.

● 관리 접속 화면

분산시스템 관리 접속 화면은 시스템 관리자 인증 작업을 수행하는 화면이다.

● 모니터링 화면

모니터링 화면은 기능별로 디스크, 프로세스, 네트워크, 프린터, 시스템 자원 화면을 각각 구성하였으며 주기적인 모니터링인 네트워크와 I/O 부분은 테이블과 그래프로 표현하는 2가지 방법을 사용하였다. 모니터링의 화면은 애플릿에서 확장된 클래스로 구성되었으며 가장자리 부분의 화면은 그대로 유지하고 각 항목에 따라 중앙 화면에 위치하는 컴포넌트를 재배치하는 구조를 가지고 있다.

● 이벤트 관리 화면

이벤트 관리 화면은 에러 로그, 상태 변화 통지 및 처리, 객체 관리 화면으로 나뉘는데 주요 기능인 에러 로그 화면과 목록 화면을 구현하였다. 이벤트 관리 화면은 애플릿에서 확장된 클래스로 구성되며 하단부의 버튼기능에 따라 중앙 화면에 위치하는 컴포넌트를 재배치하는 구조를 가지고 있다

6. 개발 결과

JMAPI를 이용한 분산 시스템 관리는 다음과 같은 이점이 있다.

● 분산 시스템 자원의 효율적인 관리

분산 시스템 자원은 관리 객체에서 적절히 표현할 수 있는 데이터베이스구조를 제공함으로써 효과적인 기술과 관리를 제공한다. 또한, 기존의 SNMP와 같은 프로토콜과 연동할 수 있는 인터페이스를 제공함으로써 기존의 분산 시스템 관리 프로그램에 적용할 수 있다.

● 웹을 이용한 시스템 관리

최근 폭발적인 이용 증가 추세를 보이고 있는 인터넷에서 시스템 관리가 이루어짐으로써 범용성과 원격 접근의 용이성을 제공한다.

● 보안성

Java 언어의 보안 특성이 응용 프로그램의 안전을 보장할 뿐만 아니라 추가적인 보안 기능을 지원한다.

● 플랫폼 독립

Java의 플랫폼 독립적인 특성을 이용할 수 있으므로 개발 비용을 절감할 수 있다.

그러나 JMAPI는 아직 최종 규격도 발표되지 않은 상태로 아직 보완되어야 할 여러 가지 문제점이 존재한다. 또한 JMAPI는 Window 제품과 Solaris 제품에만 지원되고 있다. 이러한 문제점은 JMAPI의 데이터베이스를 다루는 부분이 Java 언어로 작성되지 못하고 고유 코드로 작성되었기 때문이다. JMAPI에 일부 JDBC드라이버가 지원되고 있지만 완벽하게 JDBC드라이버에 대한 지원이 보장되어야 할 것이다. 그리고 JMAPI는 자원 관리를 위하여 상당한 양의 시스템의 자원을 이용하므로 성능 저하를 가져온다. 실제로 WindowsNT상에서 JMAPI는 가상메모리를 포함하여 30M정도의 메모리를 사용한다. 또한 Java 자체의 문제인 느린 속도도 해결되어야 할 것으로 보인다.

제7절 보완 사항

본 연구 과제에서 시스템 자원을 관리하는 모듈들은 실제 고유 메소드와 시스템 명령어를 사용하는 방식으로 작성되었다. 이는 Java에서 시스템 자원에 직접 접근하기 어려운 특성 때문이다. 이러한 문제는 Java 운영체제가 일반화되지 않으면 해결되기 곤란한 것으로 생각된다.

그러나 이러한 고유 메소드를 이용하는 방식은 시스템마다 다른 코드가 필요하게 되어 Java의 가장 중요한 특성인 플랫폼 독립성을 위협한다. 이러한 문제의 해결책으로 기존의 망 관리 프로토콜인 SNMP 등과 연동시키는 방법이 좋은 대안이 되리라 생각된다.

그리고 본 연구 과제에 있어서는 관리 객체들을 단순화하여 기술하였는데 효율적인 관리를 위해서는 분산 객체 사이의 구조에 대한 정확한 묘사가 필요하다. 인터넷의 비약적인 발전으로 분산 시스템 환경을 이용하는 사용자도 폭발적으로 증가하고 있으나 아직 이러한 시스템을 효율적으로 관리하지는 못하고 있다. 그러므로 인터넷을 주도하고 있는 웹과 Java 기술을 이용한 분산 시스템 관리는 기존에 구축된 시스템을 이용한다는 측면에서 인터넷 환경하의 분산 시스템 관리에 강력한 대안이 될 것으로 생각된다.


제3장 객체 중개자 개발

제1절 개 요

분산 객체 기술은 추상화, 상속성, 재사용성의 특성을 갖는 객체 기술과 지역적으로 분산되어 있는 이 기종 시스템 사이의 위치 투명성을 제공하여 사용자는 응용의 위치에 관계없이 사용할 수 있도록 하는 분산 처리 기술이 결합된 것이다. 분산객체들이 네트워크에 연결되어 있는 시스템 상에서 생성, 소멸, 이동, 복제 및 서로 다른 객체와 메소드 호출을 주고 받을 수 있으려면 분산 객체 환경이 필요하다.

OMG 객체 중개자는 이 기종 분산 환경에 있는 객체들 사이에서 클라이언트의 서비스 요청을 서버에 전달하고 서버의 응답을 클라이언트에 전달하는 객체 버스 역할을 담당하고 있다.

객체 중개자 개발에서는 CORBA 2.0[10] 규격을 만족하는 객체 중개자인 iORB를 설계 및 일부 구현하였다. 당해연도에는 CORBA 2.0 규격 중에서 클라이언트와 서버의 정적 인터페이스를 지원하는 객체 중개자를 구현하고 시험하였다.

객체 중개자 개발과 관련하여 수행한 학연 공동 연구로는 인터넷을 통한 객체 중개자 사이 상호 운용을 지원하는 IIOP 엔진 개발, IDL로 정의된 인터페이스를 자바 언어로된 스텁 화일과 스켈리턴 화일 및 기타 필요한 화일을 생성하는 번역기 개발과 iORB에 사용되는 객체 정보를 지속적으로 유지 관리하기 위한 객체 관리 정보 저장 시스템 개발, 객체 중개자를 이용한 다양한 응용 개발 기술을 확보하기 위한 객체 중개자 응용에 관한 연구, 그리고 인터넷 상에서 운용 되는 서비스들을 관리할 수 있는 기술을 확보하기 위한 인터넷 응용 서비스 관리기술 연구를 수행하였다.

제2절 iORB 개발

1. iORB 설계

가. 설계 개념

iORB는 CORBA 2.0 규격을 준수하면서 인터넷 환경에서 다양한 응용에 적합하도록 IDL-to-Java 언어 사상과 웹 인터페이스를 지원하는 자바로 구현된 객체 중개자이다. 이러한 iORB의 기본 설계 개념은 다음과 같다.

● CORBA 2.0 규격 준수

● IDL-to-Java 언어 사상 규격 준수

● 기본 통신 프로토콜로 IIOP 사용

● 자바로 구현

이와 같은 설계 개념에 따라 구현된 iORB는 인터넷 환경에서 홈쇼핑, 원격 교육, 가상 은행, 전자 상거래, 그리고 전자 투표 등의 응용과 통신 시스템 관리 등에 효과적으로 이용될 수 있다.

나. iORB 구조

iORB는 CORBA 2.0 규격에 따라 (그림 3-1)과 같이 구성되어 있다. iORB 응용에서 사용할 인터페이스를 정의한 IDL 파일을 IDL-to-Java 컴파일러로 컴파일하면 클라이언트에서 사용할 스텁 화일과 서버에서 사용할 스켈리턴 화일, 그리고 클라이언트 응용과 서버의 구현 객체에서 이용한 Interface 파일을 생성한다. 인터페이스는 클라이언트 프로그램과 접속되는 DII(Dynamic Invocation Interface), SII(Static Invocation Interface)서버 프로그램과 접속되는 SSI(Static Skeleton Interface), DSI(Dynamic Skeleton Interface), BOA(Basic Object Adapter)로 구성되어 있다. 그리고 클라이언트와 서버에서 사용하는 OI(ORB Interface)가 있다. iORB Core는 iORB의 핵심 부분으로 앞에서 기술한 6 개의 인터페이스들이 동작하는데 필요한 기본 기능을 제공하며 하위의 자바 가상기계와 네트워크를 통하여 원격 시스템에 있는 같은 iORB나 다른 ORB와의 통신을 담당한다.

iORB는 기본 통신 프로토콜로 CORBA 2.0 의 IIOP를 사용한다. IIOP 는 여러 업체에서 만든 객체 중개자 사이의 상호 운용을 지원하기 위해서 규정한 프로토콜로 TCP/IP을 기반으로 하는 통신 프로토콜이다. IIOP에 대해서는 iORB 통신 프로토콜 부분에서 자세히 설명한다.

iORB에서 응용이 과정은 먼저 IDL로 정의된 IDL화일을 iORB 컴파일러로 컴파일하여 생성된 클라이언트 스텁 화일을 사용하여 작성한 클라이언트 응용이 SII 또는 DII를 통하여 iORB Core를 거쳐 필요한 원격의 서버 시스템에 있는 구혁 객체를 SSI나 DSI, 그리고 BOA를 통하여 바인딩을 수행하고 바인딩이 완료되면 클라이언트의 요청을 iORB Core를 통하여 서버의 구현 객체에 전달한다. 클라이언트로 부터 요청을 받은 구현 객체의 수행 결과는 역순으로 클라이언트 응용에 전달된다.

1) iORB 컴파일러

iORB 컴파일러는 IDL로 작성한 인터페이스를 컴파일하여 클라이언트와 서버에서 사용할 자바 언어로된 자바 인터페이스 화일, 스팁 화일, 스캘리턴 화일, 그리고 자바 인터페이스 및 사용자 정의 IDL 데이터 타입에 대한 Helper와 Holder 파일을 생성하게 된다. 이때 iORB 컴파일러의 IDL 자바 사상은 IDL-to-Java Language Mapping 1.0 규격에 따른다. 예제 프로그램의 "voting" 인터페이스를 정의한 IDL 화일을 iORB 컴파일러로 컴파일하는 경우 생성되는 화일을 그림으로 나타내면 (그림 3-2)와 같다.

● 자바 인터페이스 화일 (interfacename.java): IDL 로 정의한 인터페이스를 자바 인터페이스로 재 정의한 화일이다.

● 인터페이스 Helper 화일(interfacenameHelper.java): 자바 인터페이스에 대한 Helper 클래스 정의 화일이다.

● 인터페이스 Holder 화일(interfacenameHolder.java): 자바 인터페이스에 대한 Holder 클래스 정의 파일이다.

● 스팁 화일(interfacenameST.java): 클라이언트에서 응용 작성에 필요한 클라이언트 스팁 화일로 대리 객체 생성에 사용되는 인터페이스에 대한 대리 클래스가 정의되어 있다.

● 스켈리턴 화일(interfacenameSK.java): 서버에서 구현 객체 작성에 필요한 서버 스켈리턴 화일로 인터페이스을 구현하는데 필요한 구현 객체가 상속 받을 스켈리턴 클래스가 정의되어 있다.

● Helper 화일(interfacenameHelper.java): 사용자가 IDL 화일에 정의한 데이터 타입에 대한 Helper 화일이다.

● Holder 화일(interfacenameHolder.java): 사용자가 IDL 파일에 정의한 데이터 타입에 대한 Holder 화일이다.

2) iORB 인터페이스

iORB 인터페이스는 앞에서 기술한 것과 같이 클라이언트 쪽 인터페이스로 SII, DII와 서버 쪽 인터페이스로 SSI,DSI,BOA가 있다. 그리고 클라이언트와 서버에서 공통으로 사용되는 OI로 구성되어 있다. 당해연도에는 정적 인터페이스인 클라이언트의 SII와 서버의 SSI, 그리고 BOA와 OI 인터페이스 중에서 정적 인터페이스에 필요한 부분만을 구현 대상으로 한다. 여기서는 SII,SSI,BOA 그리고 OI 대해서 설명한다.

● SII

클라이언트 응용이 인터페이스에 대한 스팁 클래스를 사용하여 대리 객체를 생성하고 클라이언트의 호출을 요청 메시지로 만들어 iORB Core를 통하여 서버에 전달한다. 그리고 서버에서 받은 응답 메시지를 해당 대리 객체를 통하여 클라이언트 응용에 전달하는데 필요한 작업을 수행한다.

● SSI

클라이언트가 요청한 구현 객체를 실행 시간에 적재하여 iORB Core를 통하여 전달 받은 클라이언트의 요청을 구현 객체에 전달하고 구현 객체의 실행 결과를 응답 메시지로 만들어 클라이언트에 전달하는데 필요한 작업을 수행한다.

● BOA

SSI가 클라이언트의 요청을 받은 구현 객체를 적재하기 위해서 찾거나 적재하는데 필요한 기본적인 기능을 제공한다.

● OI

클라언트와 서버에 공통으로 사용되는 인터페이스인 객체를 문자열로 변환하거나, 문자열을 객체로 변환하는 인터페이스, 그리고 ORB 초기화와 BOA 초기화 등의 인터페이스를 제공한다.

3) iORB Core

iORB Core는 SII,SSI,BOA 그리고 OI가 동작하는데 필요한 기능을 제공하고 하위의 자바 가상 기계와 네트워크를 통하여 원격 시스템에 있는 iORB나 다른 객체 중개자 사이에 통신에 필요한 일을 수행하게 된다.

iORB Core에서 지원하는 통신 방법은(그림 3-3)에 나타나 있듯이 iORB에서 고유 통신 프로토콜인 iORBP(iORB Protocol)와 CORBA IIOP 통신 프로토콜을 지원하는 iIIOP 그리고 다른 통신 프로토콜을 지원할 수 있는 구조로 되어 있다.

2. iORB 구현

가. 개발 및 운용 환경

iORB 는 설계 개념에서 언급한 것과 같이 자바 가상 기계가 설치된 시스템이면 하드웨어 기종이나 운영체제에 종류에 관계없이 개발 및 운용될 수 있도록 하였다. 그러나 iORB 컴파일러는 워크스테이션급 이상에서 Solaris 환경에서 개발 및 운용 된다. iORB 와 iORB 컴파일러의 개발 환경과 운용 환경은 (표 3-1)과 같다.

(표3-1)iORB와 iORB 컴파일러 개발 및 운용 환경

구분

iORB

iORB 컴파일러

개발환경

운용환경

개발환경

운용환경

시스템 기종

펜티엄 PC 이상

제한 없음

워크스테이션

좌동

운영체제

Windows95

제한 없음

Solaris2.5.1

좌동

자바 환경

JDK1.1

자바 가상 기계



개발도구

MS Visual J++1.1


GCC2.7.2.2


나. iORB 실행 시스템 구성

iORB 실행 시스템은 먼저 IDL로 인터페이스를 정의한 IDL 화일을 읽어 인터페이스 화일, 스팁 화일, 스켈리턴 화일, 그리고 기타 필요한 화일들을 생성하는 iORB IDL-to-Java 컴파일러가 있다. 그리고 CORBA 2.0에서 규정한 객체 중개자의 클라인언트와 서버 기능을 모두 가지고 있는 iORB 서버, 객체 중개자의 클라이언트 기능을 가진 iORB 클라이언트가 있으며, iORB 클라이언트와 iORB 서버에서 통신을 담당하는 iORB 프로토콜로 구성되어 있다.

● iORB 컴파일러

iORB IDL-to-Java 컴파일러로 OMG IDL 로 작성한 인터페이스 정의 화일을 읽어 스팁 화일, 스켈리턴 화일, 그리고 기타 필요한 화일들을 생성한다.

● iORB 클라이언트

iORB 클라이언트로 객체 중개자의 클라이언트 기능인 요청 메시지를 생성하여 이를 iORB 서버에 전달하거나 iORB 서버에서 받은 응답 메시지를 처리한다. IORB 클라이언트는 라이브러리 형태로 존재하며 iORB Applet 이나 iORB Application 이 수행될 때 자동으로 적재된다.

● iORB 서버

iORB 서버로 iORB 클라이언트에서 요청한 구현 객체를 적재하고, 클라이언트 요청을 구현 객체에 전달하며 구현 객체의 수행 결과를 응답 메시지로 만들어 클라이언트에 전달한다. iORB 서버는 데몬 형태로 한 시스템에 하나만 수행될 수 있다. iORB 서버는 iORB 클라이언트 기능도 포함하고 있다.

● iORB 프로토콜

iORB 프로토콜은 iORB에서 통신을 담당하고 모듈로 iORB 와 iORB, 그리고 iORB 와 다른 객체 중개자 사이 상호운용을 지원한다. CORBA IIOP 프로토콜을 구현한 것으로 라이브러리 형태로 전용 API를 제공하며 iORB 클라이언트나 iORB 서버 호출에 의해 적재되어 실행된다.

이들 iORB 실행 컴포넌트들 사이의 관계를 그림으로 나타내면 (그림 3-4)와 같다.

다. iORB 프로그래밍 방법

iORB에서 응용 프로그램을 작성하기 위해서는 먼저 IDL을 사용하여 클라이언트와 서버에서 사용할 인터페이스를 정의하고 이를 iORB 컴파일러로 컴파일한다. 응용 개발자는 iORB 컴파일러에 의해 생성된 클라이언트 스팁 화일과 필요한 Helper 및 Holder 화일을 사용하여 클라이언트 응용을, 스켈리턴 화일과 필요한 Helper 및 Holder 클래스를 사용하여 구현 객체를 작성한다.

1) IDL 인터페이스 정의

OMD IDL를 사용하여 개발하고자 하는 응용에 필요한 IDL 인터페이스를 정의한다. 화일 이름은 반드시 "xxxx.idl"로 지정해야 하며, 작성 방법은 CORBA 2.0 IDL 문법에 따라 작성한다. (그림 3-5)는 "voting"인터페이스를 정의한 IDL 작성 예이다.

voting.idl

module Example

interface voting {// 인터페이스 정의

attribute long totalVoters;// 읽기, 쓰기 에트리뷰트 정의

readonly attribute string pubkey;// 읽기 전용 에트리뷰트 정의

// 오펴레이션 정의

boolean check(in string pID, out string pName, inout long vID);

}

}

(그림 3-5) IDL 인터페이스 작성 예

2) 클라이언트 응용 작성

clientApp.java

package voting:

import iORBclt.*:// 필요한 패키지 import

...

class votingApp {// 클라이언트 응용 객체 정의

public static void main( ) { // 자바 응용 메인 선언

votingST a Voting=new votingST(serverNꍨ);// 대리객체 생성

...

aVoting,totalVoters(...);// 에트리뷰터 사용

...

...// 호출한 오퍼레이션의 전달인수 값 설정

boolean aRetVal = aVoting.check(...);// 대리객체 오퍼레이션 호출

..// 대리객체 오퍼레이션 호출 결과값 및 출력 전달인수 사용

}

}

(그림 3-6) 클라이언트 응용 작성 예

클라이언트 응용 작성에서는 IDL로 정의한 인터페이스에 대한 자바 인터페이스 화일과 클라이언트 스텁 화일을 사용하게 된다. 클라이언트 응용에서는 먼저 iORB 사용에 필요한 패키지를 선언한다. 그리고 클라이언트 스텁 화일에 정의된 IDL 인터페이스에 대한 대리 클래스를 사용하여 대리 객체를 생성한 다음에 대리 객체를 통하여 속성 값을 설정하거나 가져오며, 또한 필요한 대리 객체의 오퍼레이션을 호출하고 수행 결과값을 사용하게 된다. 클라이언트 응용 작성 예는 (그림 3-6)과 같다.

3) 구현 객체 작성

votingIO.java

package voting;

import iORB칫.*;// 필요한 패키지 import

...

public class votingIO {// 구현객체 클래스 정의

public votingOBJ() {...} // 생성자

// 메소드 구현

public boolean check(String pID, StringHolder PName, IntHolder vID) {

...// 실제 업무처리 로직 구현

...// 리턴값 처리

}

}

(그림 3-7) 구현 객체 작성 예

구현 객체는 서버에서 IDL로 정의한 인터페이스가 실제 처리해야 할 업무 흐름을 작성하는 것이다. 구현 객체 구현에는 IDL 인터페이스에 대한 자바 인터페이스 화일과 스켈리턴 화일, 그리고 이와 관련된 Helper와 Holder 화일이 사용된다. 구현 객체 프로그램에서 화일 명을 반드시 interfacenameIO.java로 지정해야 하며, iORB 사용에 필요한 패키지를 선언해야 한다. 그리고 구현 객체 클래스명도 반드시 interfacenameIO로 지정한다. 그리고 IDL 인터페이스에서 정의한 오퍼레이션에 해당하는 메소드를 작성한다. 이 메소드에는 실제 처리해야 할 업무 처리 내용이 들어가게 된다. 구현 객체 작성 예는 (그림 3-7)과 같다.

제3절 IIOP 엔진 개발

1. 연구 목표

IIOP 엔진 개발은 CORBA 2.0에서 규정하고 있는 객체 중개자 상호운용 프로토콜인 IIOP를 지원하고 iORB 내에서 클라이언트와 서버간 통신은 물론 iORB와 다른 객체 중개자 사이에 상호 연동하도록 한다.

CORBA 2.0 명세서에는 객체 중개자간 상호 연동을 지원하기 위하여 IIOP 프로토콜을 정의하고 있는데 이것은 ORB들간의 객체 서비스의 상호 교환에 TCP/IP 프로토콜을 사용할 수 있도록 한 것이다. 상호 연동이란 서로 다른 ORB들간에 객체 서비스를 투명하게 교환할 수 있도록 ORB들간에 공통의 메시지 형식과 통신 프로토콜을 정의하여, 클라이언트는 객체 서비스가 어떤 ORB에 존재하는지 알 필요 없이 투명하게 서비스를 제공받을 수 있게 하는 것이다.

IIOP 엔진 개발에서는 CORBA 2.0 명세서와 GIOP 1.0 명세서의 주요 내용 및 GIOP 1.1의 개정 내용을 분석하였으며, 참조 시스템으로 SunSoft의 IIOP 엔진과 APM의 Jade IIOP 엔진의 기능과 구조를 분석하였다. 또한 iORB를 위한 IIOP 엔진의 전체 구조를 설계하였고 이를 위한 주요 클래스들과 메소드들을 구현하였다.

2. 참조 시스템 분석

참조 시스템으로 SunSoft의 IIOP 엔진과 APM의 Jade IIOP 엔진의 기본 구조와 각 클래스 및 메소드들의 기능을 분석하였으며, IIOP 엔진을 통하여 메시지가 전달되는 과정에 초점을 맞추어 각 클래스들간의 상호 관계를 분석하였다. Sun의 IIOP 엔진과 APM의 Jade를 비교해 보면 구현언어는 각각 C++와 Java로 다르지만, 내부적으로는 메시지를 처리하는 부분과 통신을 처리하는 부분이 유사한 구조로 되어 있음을 알 수 있다.

가. Jade IIOP 엔진

Jade는 웹을 통해 사용자가 CORBA 객체에 대한 서비스를 제공 받을 수 있는 CORBA 환경의 구축을 위해 APM에서 Java 언어를 사용하여 개발되었다. Jade 개발의 세부 관심사항은 첫째, 인터넷이 가장 큰 정보 은행인 만큼 인터넷에 대한 연결성이 보장되고 둘째, 웹 브라우저가 새로운 네크워크 운영체제로의 전환에 있는 만큼 웹 브라우저와의 상호 연동이 필요하다는 것이다. 셋째, Java는 웹의 프로그래밍언어로써 확장성이 뛰어나고 하드웨어 환경에 독립적인 특성을 갖기 때문에 Java를 개발 언어로 선택한다는 것이고 그리고 CORBA와 웹과의 상호연동을 Java 언어를 통해 제공하고 있다는 것이다.

나. SunSoft IIOP 엔진

SunSoft의 IIOP 엔진은 CORBA 2.0을 토대로 설계, 구현된 IIOP 엔진으로 소오스코드가 공개되어 있다. SunSoft의 IIOP 엔진은 유닉스, POSIX의 쓰레드와 DCE Alpha, HP 9000, Solaris 2.4 플랫폼을 지원한다. SunSoft IIOP 엔진의 특징은 서버 IIOP와 클라이언트 IIOP 간에 다중 연결에 대한 관리와 쓰레드 처리 지원, 마이크로 스프트사의 COM과 연동 지원을 지원한다.

SunSoft의 IIOP 엔진은 내부에 분산 객체 시스템 즉 분산 미들웨어로서 같이 존재하는 마이크로 소프트사의 OLE/COM과의 연동을 위하여 OLE/COM에서 사용되는 객체 인터페이스를 사용하고 있다는 것이다. 또한 CORBA 2.0에서 정의하고 있는 OMG IDL 자료형들 외에 몇 가지 자료형을 더 첨가하여 사용하고 있다. 이들은 더 큰 자료형을 요구하거나 UNICODE 등의 처리를 위하여 사용되고 있다.

3. iORB IIOP 엔진 구현

iORB의 IIOP 엔진은 Java 언어로 구현되었으며 in-line 브리지의 형태로 개발되었다. IIOP 모듈은 ORB의 클라이언트 부분과 ORB 데몬에 각각 라이브러리 형태로 구성되어 API 형태로 제공되며 이 API를 통하여 클라이언트와 데몬 서버는 IIOP 모듈을 구동할 수 있다. iORB IIOP 엔진의 구조는 (그림 3-8)과 같다.

제4절 IDL-to-Java 컴파일러 개발

1. 연구 목표

IDL-to-Java 컴파일러 개발은 범용 컴파일러 기술을 사용하여 CORBA 2.0 규격을 만족하는 객체 중개자인 iORB에서 사용할 IDL-to-Java 컴파일러를 구현하였다. iORB 컴파일러는 OMG IDL로 작성된 파일을 입력 받아서 IDL-to-Java 사상 규격을 준수하는 자바 코드로 된 클라이언트 스텁 화일, 스켈리톤 화일, 그리고 기타 필요한 화일들을 생성하게 된다.

분석 단계에서는 기존 OrbixWeb, VisiBroker, Joe, JacORB의 IDL-to-Java 컴파일러 분석과 OMG IDL 문법 분석, IDL을 현재 이기종 플랫폼에서 사용되는 언어인 Java로 사상하는 원리 분석의 순으로 수행하였다.

개발 단계에서는 iORB 컴파일러 전체 구조의 설계, 컴파일러 전반부인 Lexer와 Parser의 구현, 그리고 마지막 단계인 코드 생성의 순으로 수행하는 범용 컴파일러 기술을 사용하였으며, 컴팰러 전반부인 Lexer와 Parser의 구현 단계에서 중간 코드를 생성하고, 마지막 단계에서 중간 코드를 IDL 선언문 별로 사상하여 자바 코드를 생성하였다.

2. 참조 시스템 분석

가. OrbixWeb

OrbixWeb은 IONA에서 만든 Java ORB로 CORBA의 지역 투명성과 방화벽 통과를 지원하기 위해 Wonderwall라는 접근 방식을 제안하였으며 Orbix 고유 프로토콜과 IIOP 프로토콜을 제공한다.

OrbixWeb의 IDL-to-Java 컴파일러는 CORBA에서 제안한 내용에 충실하게 화일들을 생성하지만 프로그램 작성이나 사용자의 편의를 위해 요구되는 라이브러리와 같은 파일들을 생성하지는 않는다. 또한 항상 디렉토리 이름을 명시하여야 하는 불편한 점이 있다.

나. VisiBroker

VisiBroker for Java는 Visigenic의 Java ORB이며 구현 객체, ORB 인터페이스, ORB, 그리고 인터페이스 저장소와 같은 필수적인 CORBA 특징들을 구현한 제품으로 CORBA 공용 객체 서비스인 이름 찾기와 사건 서비스를 구현하였다.

VisiBroker의 IDL-to-Java 컴파일러는 자바 패키지를 포함하는 새로운 디렉토리를 만들고 디렉토리와 패키지 이름은 IDL 모듈의 이름과 같다. 생성된 자바 패키지는 스텁, 스켈리톤, 그리고 분산 응용 프로그램을 지원하기 위한 코드들을 구현한 자바 인터페이스와 클래스들을 포함한다.

다. Joe

Joe는 Sun의 Java ORB이며 클라이언트측 사상과 부분적인 서버측 사상을 제공해 주는 제품이다. Joe는 IIOP 뿐만 아니라 고유 프로토콜인 Door 같은 많은 프로토콜들을 지원해 준다. Apache HTTP 서버에 대한 패치를 제공해줌으로써 위치 투명성과 방화벽 통과를 구현하였다.

Joe의 IDL 컴파일러는 클라이언트 스텁과 서버 스켈리톤을 선택하여 생성한다. 자바를 개발한 Sun에서 만든 컴파일러로 생성된 파일들의 사상 내용이 자바의 특성을 잘 고려하였다. 하지만 Joe 자체가 CORBA를 완전히 지원하기보다는 지사에서 생산되는 제품과 연동하는 목적으로 제작되었다는 단점이 있다.

라. JacORB

JacORB는 베를린에 있는 Freie 대학에서 학생들의 교육을 주된 목적으로 개발된 자바 기반의 ORB로서 JacORB에 의해 실현되는 모든 CORBA 기능들은 JacORB 클래스 라이브러리를 사용하는 스텁과 스켈리톤에 의해서 제공된다.

JacORB에서 제공하는 IDL-to-Java 컴파일러의 자바 사상 함수는 독자적으로 개발하였다기보다는 SunSoft와 IONA의 사상 함수들을 복합한 것이다. 그리고 다른 컴파일러와는 달리 IDL을 사상하는 IDL 컴파일러와 스텁과 스켈리톤 코드 생성기를 독립적으로 두었으며 IDL 컴파일러를 C 소스로 생성해주는 Lex, Yacc과 유사하게 자바 소스를 생성하는 CUP을 사용하여 개발되었다.

3. iORB 컴파일러 구현

iORB 컴파일러는 (그림 3-9)와 같이 IDL 화일을 입력 받아서 정규식으로 표현한 패턴에 맞는 토큰을 분리하는 어휘 분석기와 어휘 분석기로부터 토큰 문자열을 전달받아 구문이 IDL 문법에서 허용하는 올바른 문장인가를 검사하여 그 결과로 중간 코드를 생성하는 구문 분석기가 있다. 그리고 중간 코드를 IDL-to-Java 사상 규격에 따라 필요한 자바 화일을 생성하는 IDL-to-Java 사상 모듈로 구성되어 있다.

제5절 객체 관리 정보 저장 시스템 개발

1. 연구 목표

객체 관리 정보 저장 시스템 개발은 iORB의 인터페이스 저장소와 구현 저장소에 사용하기 위한 객체 저장 시스템을 Java 언어를 사용하여 구현하였다. iORB 객체 저장소를 통하여 분산 환경의 객체들은 보조 기억 장치에 저장되며 객체 단위로 관리된다.

객체 관리 정보 저장 시스템 관리에서는 자바를 사용하여 iORB에서 인터페이스 저장소와 구현 저장소로 사용되는 iORB 객체 저장소를 개발하고 이를 이용하여 인터페이스 저장소를 구현하였다.

2. iORB 객체 저장소 구현

iORB 객체 저장소는 객체 저장 관리자, 객체 저장소, PersistentRoot 클래스로 나누어진다. iORB 객체 저장소의 구성은 (그림 3-10)과 같다. 객체 저장 관리자는 실제적인 입출력을 담당하고, PersistentRoot 클래스는 사용자에게 제공되는 API 부분이다. 그리고 객체 저장소는 메모리상의 색인을 담당한다.

●객체 저장 관리자 : 객체 저장 관리자는 실제 디스크 접근을 담당하는 가장 기초가 되는 부분이다. 객체의 데이터를 받아서 디스크에 저장하거나 디스크에 저장된 객체를 메모리로 읽어 들이는 디스크 입출력을 담당한다.

●객체 저장소 : 객체 저장소는 메모리 상에 있는 모든 저장 가능한 객체를 객체 저장 관리자를 이용하여 디스크에 저장하고 필요한 경우에 디스크에 있는 모든 객체를 역시 Object Storage Manager를 이용하여 메모리로 불러들이는 기능을 제공한다.

●PersistentRoot 클래스: PersistentRoot 클래스는 객체 저장소를 이용하여 제작된 Java 클래스이다. 사용자는 단순히 이 PersistentRoot 클래스를 상속함으로써 저장, 복구, 검색 등 객체 저장 시스템의 모든 기능을 이용할 수 있다.

3. 인터페이스 저장소 구현

인터페이스 저장소 구현에서는 iORB 객체 저장소를 이용하여 시험용 구현 저장소를 개발한 것으로 CORBA 2.0에서 규정하고 있는 IDL의 모든 정보들이 저장된다.

제6절 객체 중개자 응용 연구

1. 연구 목표

객체 중개자 응용에 연구는 Java/CORBA 기반의 통합 모델을 이용하여 인터넷 환경에서 비밀성과 안전성을 보장할 수 있는 전자투표 시스템인 EVS/jORB(Electronic Voting System Based on Java/CORBA)를 개발하는 것이다. EVS/jORB 전자투표 시스템은 투표자 대리 서버, 인증 서버, 확인 서버, 집계 서버 등 5 개의 주요 서버 모듈과 투표자 등록, 투표 결과 분석 등의 부가 서비스 모듈로 구성된다. 본 연구에서는 투표자 확인, 투표과정 및 투표 결과의 신뢰성 보장, 시스템의 정확성 및 안전성 등이 보장되고 투표자 대리인 모듈, 인증 모듈, 확인자 모듈, 집계자 모듈 사이의 관계에서 투표 부정이 방지될 수 있는 안전한 전자 투표 프로토콜 알고리즘을 개발하여 EVS/jORB 전자투표 시스템 구현과정에서 활용한다.

2. 전자 투표 요구 사항

가. 전자 투표 특성

전자 투표는 일반적으로 적법한 투표자의 리스트가 작성되는 선거인 명부 작성 과정과 선거권이 있는 투표자인지 또는 선거를 한번 이상 수행하지 않는 투표자인지를 확인하는 과정, 투표가 완료된 투표용지를 수집하는 과정, 그리고 투표용지를 집계하는 집계 과정 등의 4 단계로 구분된다.

나. 전자 투표 프로토콜 분석

전자 투표 시스템에서는 앞서와 같은 전자투표 특성을 고려한 전자투표 프로토콜이 필요하다. 기존에 연구된 전자 투표 프로토콜은 다음과 같은 것이 있다.

●단순 프로토콜

●Two Agency 프로토콜

●Blind Signature 프로토콜

다. 보안 및 암호화 기법

전자투표는 선거인 명부를 데이터베이스로 구축한 서버 시스템과 직접 연결된 클라이언트에서 자신이 정당한 투표자임을 증명할 수 있으면 네크워크에 연동된 어떤 클라이언트에서도 무기명 투표가 가능한 투표 방식으로 정의를 할 수 있다. 신뢰성 있는 전자투표 시스템 환경에서 정보의 안전한 전달과 흐름을 통제하기 위해서는 기본적인 보안 서비스와 적절한 암호화 기술이 적용되어야 한다.

라. 전자 투표 프로토콜 설계

본 연구에서는 안전한 전자 투표를 위해 전자서명 방식을 적용하고, 전자 투표 프로토콜을 설계 및 구현하였다. 전자 투표 프로토콜에서는 Blinded Signature를 이용하여 전자 서명이 가능하도록 하였다. Blinded Signature 기술은 편지 봉투의 외부에 수기 서명이 편지 봉투 내부에도 서명이 남아 있는 이중 서명 기술로 한번의 서명으로 투표용지 외부에 서명이 이루어지면 암호화된 투표 용지에도 서명이 남아 있는 암호화 기법이다.

3. EVS/jORB 설계 및 구현

EVS/jORB 전자 투표 시스템은 (그림 3-11)과 같이 인터넷 환경에서 지리적으로 분산된 여러 투표 장소에서 투표자의 투표 대리 모듈을 통해 인증 서버 및 확인자와 통신하여 인증 과정과 확인 과정을 거치고, 유효한 투표권자가 인정되면 투표행위를 하고 그 결과를 집계자에게 전송한다. 미리 사전에 등록된 모든 유권자의 투표행위가 끝나면 집계자는 투표 결과를 집계하고 그 결과를 결과 분석기를 통해 통계 처리한다.

제7절 인터넷 응용 서비스 관리 기술

1. 연구 목표

인터넷 응용 서비스 관리 기술은 인터넷을 기반으로 한 많은 응용 서비스 중에서도 가장 각광 받고 있는 분산 기술의 하나인 CORBA 환경에서의 응용 서비스의 관리에 초점을 맞추었다. 이에 따라 CORBA 기반의 서비스를 관리하기에 적합한 관리 프레임워크를 설계하고 여러 가지 서비스를 정의하여 간단한 프로토타입 시스템을 개발하여 검증하는 것을 목표로 하였다.

2. 표준화 및 관련 연구 조사

표준화 및 관련 연구 조사에서는 인터넷 관리 구조와 OSI 관리 구조 표준 그리고 CORBA 상에서의 서비스 관리에 대해서 조사하였다.

가. 인터넷 관리 프레임워크

인터넷 관리 프레임워크는 1990년에 TCP/IP를 기반으로 한 인터넷의 관리를 위해서 채택되었다. 이는 TCP/IP위에서의 프로토콜이나 서비스들도 결국은 OSI 기반의 프로토콜과 서비스들로 전환할 것이라는 예상 하에 그 전환 과정에서 필요한 몇 가지 기본적인 기능만을 제공할 수 있도록 간단하게 설계된 것이다.

나. OSI 관리 프레임워크

OSI 관리 프레임워크는 ITU-T와 ISO가 공동으로 제정한 것으로 X.700 시리즈로 알려져 있다. 이 프레임워크 역시 관리자-대리자 구조를 가지며 프로토콜로는 CMIP을 사용하고 객체 지향적 방법으로 정의되는 관리 정보를 가진다.

다. 응용 서비스 관리 시스템

●MAScOTTE Project

MAScOTTE 프로젝트는 CORBA 환경에서의 관리 대상을 OMA의 구성요소들로 정의하고 있다. 이 구성 요소들에는 객체들과 관련된 기본 서비스인 공용 객체 서비스, 공용 객체 서비스 보다 한단계 위의 공용 시설, 사용자에 의해 개발되고 사용되는 응용 객체, 객체간 통신을 담당하는 ORB 그리고 CORBA 객체들을 이용하는 클라이언트 5개가 포함된다.

●CORBA Assistant

CORBA Assistant는 MAScOTTE 프로젝트의 일부이다. 주요 내용은 CORBA MIB의 정의, 관리 인터페이스를 위한 라이브러리의 개발, CORBA MIB 브라우저의 개발 CORBA 관리 facility 일부 개발이다.

3. CorbaMan 구현

CorbaMan은 포항공과대학교의 분산처리환경 연구실에서 개발된 CORBA 기반의 분산 멀티미디어 시스템인 MAESTRO를 대상으로 구현된 프로토타입 시스템이다. 여기서는 관리 대상 시스템인 MAESTRO에 대해 간단한 소개와 CorbaMan의 구조와 환경 그리고 관리 서버와 관리 인터페이스 관리 인터페이스의 구현에 대해 간단히 설명한다.

가. MAESTRO 개요

MAESTRO는 분산 멀티미디어 응용 프로그램들을 보다 쉽게 개발, 운용, 관리할 수 있도록 다양한 멀티미디어 서비스를 제공하는 시스템이므로 CORBA 기반의 분산 서버를 포함하고 있다. 이 서버들이 제공하는 서비스에는 이름 서비스, 통신 서비스, 세션 서비스, 저장/인출 서비스가 있으며 서비스를 제공하는 각각의 서버들도 역시 CORBA 객체들로 구성된다. 나아가, 멀티미디어 응용 프로그램에서 공통적으로 필요한 멀티미디어 데이터 처리와 멀티미디어 관련 장치의 조작을 위한 멀티미디어 API를 제공함으로써 MAESTRO를 이용한 멀티미디어 응용 프로그램의 개발을 더욱 손쉽게 하여준다.

나. CorbaMan의 구현

여기서는 앞에서 소개된 MAESTRO의 서버들을 관리하기 위해 구현된 CorbaMan에 대해 설명한다.(그림 3-12)는 CorbaMan의 대략적인 구조를 보여 준다.

●개발 환경

CorbaMan은 IONA에서 개발한 ORB인 OrbixWeb 2.0.1 상에서 개발되었다. CorbaMan의 관리 인터페이스 및 관리 서버들을 C++를 사용하여 구현되었으며 관리 응용 프로그램은 Java를 이용하여 웹 기반의 인터페이스를 가지도록 개발되었다.

●관리 기구

MAESTRO의 서버들은 CORBA 기반의 분산 서버 모델에서 설명한 대로 여러 가지 서비스 객체로 구성된다.

●관리 서버의 구현

관리 서비스는 구성 관리 서버, 결함 관리 서버, 이벤트 채널, 성능 관리 서버, 보안 관리 서버로 구현되었다.

●관리 응용 프로그램의 구현

관리 응용 프로그램은 Java Applet으로 구현되어 따로 설치될 필요가 없으며 어떤 플랫폼에서든지 웹 브라우저를 이용하여 실행시킬 수 있다. 뿐만 아니라, CorbaMan의 관리 응용 프로그램은 웹을 기반으로 한 일관성 있고 쉬운 사용자 인터페이스를 제공한다.


제4장 공용 객체 서비스 기술 개발

제1절 개 요

CORBA 공용 객체 서비스는 객체를 수행하고 사용하기 위한 기본 함수를 지원하는 인터페이스와 객체들을 제공하는 것이다. 공용 객체 서비스는 응용 영역과 독립된 부분이며 분산 응용 객체의 구성을 위하여 기본적으로 필요한 기능을 제공한다.

공용 객체 서비스는 클라이언트나 요구 자료 구조 및 다른 객체 서비스와 무관하도록 독립된 구조로 간단하게 설계하고 공용 객체 서비스간에 함께 결합하도록 하였다. 공용 객체 서비스의 의존 관계는 (그림 4-1)과 같다. 공용 객체 서비스는 지역에 관계없이 서비스를 제공하며, 서비스 인터페이스는 광범위한 수행 접근을 허용하면서 품질은 특별 환경에서 제공하도록 하였다. 클라이언트의 요구 특성에 따라 서비스는 몇 개의 인터페이스로 분리되어 다른 종류의 클라이언트에는 다른 인터페이스가 제공된다. 클라이언트에서 재귀적 호출 서비스를 제공하면 호출하도록 하였다. 식별자 범위는 전역 식별자에 의존하지 않고 문맥으로 제한하였다.

●객체 찾기 서비스

객체 찾기 서비스는 분산 환경에서 이름으로 객체를 찾을 수 있도록 한다. 객체 찾기 서비스는 이름 문맥과 관계 있는 이름으로 객체에 접합하는 기능을 제공한다. 이름 문맥은 객체로서 유일한 이름을 접합하는 정보를 포함하며, 문맥에서 이름과 관련된 객체를 결정하여 객체 찾기 서비스를 제공한다.

●사건 서비스

사건 서비스는 특정한 작업을 수행하도록 원하는 사건을 기탁하거나 인출할 수 있도록 한다. 사건 서비스는 비동기 사건인 생산자와 소비자, 전송경로에서의 사건 수집 및 분배 통고에서 사건을 전달한다. 생산자와 소비자의 신원은 서로 확인하지 않는다.

●타이밍 서비스

타이밍 서비스는 사용자에게 오류 추정 범위 내에서 현재 시간을 제공한다. 시간 사건의 주문을 확인하고 타이머나 시간 경보기에 근거하여 시간 사건을 생성하고 두 시간 사건의 시간 간격을 계산한다.

●생명 주기 서비스

생명 주기 서비스는 객체의 생성, 제거, 복제, 이동을 위한 편리를 제공한다. CORBA에 근거한 환경은 분산 객체를 제공하므로 다른 지역에서 생명 주기 서비스를 수행한다. 생명 주기 서비스에서 제조 객체는 OMG IDL 인터페이스와 수행 코드로 다른 객체를 생성하며, 생명 주기 객체 인터페이스는 제거, 복제, 이동 서비스를 정의한다.

제2절 객체 찾기 서비스

1. 객체 이름

객체 이름으로 서비스를 제공하는 객체의 위치를 찾는 것을 객체 찾기라고 한다. 객체 이름은 객체의 위치를 제공하는 이름 문맥과 대응된다. 어떤 이름을 연결하는 것은 주어진 문맥에서 그 이름과 관련된 객체를 찾아 문맥내의 이름 연결을 생성하는 것이다. 이름은 항상 문맥과 관련되어 결정되며 독립된 이름은 존재하지 않는다. 이름 문맥은 노드가 문맥이고 이름으로 연결되는 방향성 이름 그래프이며 복잡한 이름을 사용해서 객체를 참조한다. 이름 그래프 내에 임의의 문맥이 주어지면 나열된 이름은 객체를 참조할 수 있다. 이러한 나열된 이름들을 복합 이름이라 부르고 결정 과정을 다루기 위해 이름 그래프내의 경로를 정의한다.

2. 객체 찾기 서비스 설계

이름은 문맥 내에서 유일해야 한다. 객체는 여러 이름을 가질 수 있고 여러 이름 문맥에 존재할 수 있다. 객체 찾기 서비스의 구현은 다음 설계 원리에 근거한다.

●복합 이름 표기법과 접근 방법을 제공한다.

●분산 환경에서 이름과 문맥을 관리해야 한다.

●이름은 객체를 찾기 위한 문자열 구조체이다.

●이름 서버의 물리적인 위치 및 해석 방법은 추상화된다.

●객체 찾기 서비스는 다른 서비스에 의존하지 않아야 한다.

●이름 문맥은 중첩 그래프와 함께 이용된다.

●다른 환경에서 존재하는 이름과 목록은 요약된다.

●이름 보안은 OMG 보안 모델 표준에 따른다.

●이름 공간 관리는 higher-level software의 책임이다.

3. 객체 찾기 구현 사례

객체 찾기 서비스는 이름 서버가 구축된 제품 중 소스 코드가 배포된 각 제품의 이름 그래프의 구성 방식에 대해서 비교하였다.

가. OrbixWeb 2.0

OrbixWeb 2.0은 이름 서버, 사용자 서버, 클라이언트로 구분된다. 이름 서버는 이름 그래프와 이름 그래프를 다루기 위한 오퍼레이션으로 구성된다. 사용자 서버는 클래스를 정의하고 객체를 생성하여 이름 서버에 연결하여 이름 그래프를 구성한다. 클라이언트는 사용자 서버에서 생성된 이름 그래프를 순회하면서 이름과 관련된 객체를 찾아낸다.

나. OmniBroker

OmniBroker의 객체 찾기 서비스는 이름 도서실을 제외한 나머지 부분이 구현되었다. 특징이 있다면 공용 객체 서비스 명세서에 없는 리스트 구조를 추가적으로 정의하여 공통 함수를 호출하여 연결을 도와준다. OmniBroker의 이름 그래프는 자식노드로 모든 이름 문맥 정보나 객체 정보를 담고 있다.

다. JacORB

JacORB는 Network 인터페이스를 Java 언어 자체에서 지원한다. JacORB의 이름 서버는 대부분이 구현되어 있으나 복합 이름 처리를 아직 구현하지 못하고 있다. 특징이 있다면 이름 그래프를 유지하기 위해 각 문맥마다 두 개의 Hash 구조인 이름 테이블과 문맥 테이블을 가지고 있다. 이름 테이블에는 실제 객체의 단순 이름이 입력되고, 문맥 테이블에는 실제 객체의 복합 이름이 입력된다.

4. 객체 찾기 서버 구현

객체 찾기 서버로 작동하는 클래스는 이름 문맥 클래스와 연결 동작 클래스 및 이름 그래프를 유지하기 위한 사용자 클래스이다. 이름 문맥 클래스는 이름 그래프를 다루는 메소드의 집합으로서 클라이언트 프로그램에서 사용할 수 있다. 연결 동작 클래스는 이름 연결을 다루기 위한 메소드의 집합이다. 사용자 클래스는 이름 연결을 유지하기 위한 이름 그래프의 구조를 보여주고 있다. 이 이름 그래프의 구조는 문맥 리스트와 이름 공간 리스트로 구성된다. 문맥 리스트는 문맥이 입력되면 생성된다. 각 문맥은 자신만의 이름 공간 리스트를 유지하고 있다. 이름 공간 리스트는 임의의 문맥에 관련된 이름 공간을 유지한다. 문맥 리스트는 문맥이 항목으로 입력이 되지만 이름 공간 리스트에는 객체 레퍼런스와 문맥이 입력될 수 있다.

위의 구조만으로도 이름 그래프를 운행할 수 있지만 수백만개의 이름 연결이 구성되면 효율성에 문제가 된다. 그러므로 위의 구조가 기본으로 사용되고, 검색, 삭제, 삽입을 위한 인덱스구조를 추가로 사용해야 한다. 이 구조는 아직 설계 중에 있다.

5. 객체 찾기 서버 시험

성능 평가에 사용된 시스템은 RAM 256MB를 가진 Ultra Sparc 시스템에서 시험하였다. 객체 찾기 서버의 성능에 영향을 미치는 것은 hash 테이블의 크기이다. 즉, hash 테이블의 크기에 따라 검색 속도가 차이를 보인다. 평가를 한 인터페이스는 연결과 해결이다. 결국, 입력되는 자료의 크기에 따라 적절한 크기의 hash 테이블의 크기를 조절해 주어야 한다.

제3절 사건 서비스

1. 사건 개요

기존의 CORBA 통신 모델은 직접 통신 형태로서 사건을 생성하는 공급자와 사건을 처리하는 소비자가 직접 연결된다. 이러한 공급자와 소비자간의 직접 통신은 다중 작업을 지원하는 분산 환경에서는 거의 사용되지 않는다. 사건 서비스는 이러한 직접 통신 모델이 가지는 단점을 보완하고 비 동기적인 통신이 가능한 간접 통신 모델 형태를 제공한다.

사건 서비스는 CORBA 수행 모델의 통신 제약을 극복하기 위하여 분산 객체 응용 프로그램간에 비동기적이고 결합도가 낮은 통신을 제공하기 설계된 CORBA 공용 객체 서비스이다. 사건 서비스는 비동기적인 메시지를 전달하고 다수의 공급자들이 다수의 소비자들에게 메시지를 보낼 수 있도록 해준다. 또한 사건 서비스에서 정의하는 사건 채널은 공급자들을 대신하여 소비자들에게 사건을 전달하는 중개자 역할을 수행한다.

사건 채널은 다수의 공급자들과 다수의 소비자들 간의 중개자 역할을 수행한다. 사건 채널은 각각의 공급된 사건을 각 소비자에게 유효하게 할 수 있도록 하기 위한 책임을 진다. 사건 서비스 IDL에 정의된 사건 채널은 개념적으로 그 자신을 객체로 정의하고 있다.

공급자들은 소비자들에게 자료를 보내주기 위해 사건 채널을 사용한다. 반대로, 소비자들은 사건 채널을 통하여 공급자들로부터 자료를 받을 수 있다. 사건 자료를 전달할 때 공급자와 소비자는 서로의 위치 정보를 알 필요가 없다. 이것은 공급자와 소비자간의 결합도가 낮은 통신의 원리를 구현한 것이다.

2. 사건 서비스 통신 모델

사건 서비스는 사건의 전달 방법에 따라 푸시 모델과 풀 모델로 구분되며, 전달하는 자료 형태에 따라 일반 모델과 형 정의모델로 구분된다.

가. 전달 방법별 분류

사건 서비스는 공급자와 소비자들이 사건 채널에서 능동적이거나 수동적으로 사건을 전달을 주도하는가에 따라 (그림 4-2)의 통신 모델과 같이 푸시/푸시, 풀/풀, 푸시/풀, 풀/푸시 모델로 구분한다. 푸시/푸시 모델에서는 공급자들이 자료를 전달하는 주도자이고 소비자들은 요청에 대한 수동적인 목표물이며 사건 채널은 사건 통보자의 역할을 수행한다. 풀/풀 모델에서는 소비자들이 사건 자료를 명시적으로 요청하는 주도자이고 공급자들은 풀 요청에 대한 수동적인 목표물이 되며 사건 채널은 획득자의 역할을 수행한다. 푸시/풀 모델은 공급자들과 소비자들 모두가 사건에 대한 주도자로서 소비자들이 공급자들에 의해 사건 채널에 저장된 사건을 요구하며 사건 채널은 큐의 역할을 수행한다. 풀/푸시 모델은 사건 채널이 공급자들로부터 사건들을 풀하고 소비자들에게 사건을 푸시하는 형태이며 사건 채널은 지능적인 대리인 역할을 수행한다.

나. 전달 자료형에 따른 분류

사건 서비스의 통신 모델은 사건의 전달 연산자와 인자의 형에 따라 다시 일반 모델과 형 정의 모델로 구분한다. 일반 모델은 모든 통신이 사건 자료를 위한 하나의 인자를 가진 푸시와 풀 연산자에 의해서 수행된다. 인자로 전달되는 사건 자료는 응용 프로그램에서 자료형을 정의하고 있지 않는 형태로 ORB 시스템을 통해 전달된다. 형 정의 모델은 OMG IDL로 정의한 사용자 인터페이스에 의해서 통신이 이루어진다. 즉, 공급자와 소비자가 응용 프로그램에 의존적인 인터페이스에 대한 지식을 공유하고 있는 경우이다. 사건 자료는 공급자와 소비자간에 합의된 연산자를 이용하여 사건 자료가 전달되도록 한다.

3. 사건 서비스 설계

일반 모델은 사건 서비스의 기본 모델로 푸시 형태와 풀 형태의 공급자들과 소비자들 간의 사건 통신을 위한 IDL 인터페이스를 정의하는 모듈과 공급자들과 소비자들간의 연결을 성립시키기 위한 인터페이스를 정의하는 모듈로 구성한다. 형 정의 모델에서는 공급자들이 소비자들과 상호간에 합의된 인터페이스를 사용하여 사건 자료를 전달 받도록 구현한다. 이러한 사건 모델들은 앞의 4 가지 사건 방법을 만족하기 위하여 다음과 같은 설계 조건을 고려한다.

●사건들은 특정 서비스나 플랫폼에 의존해서는 안된다.

●다중 소비자와 다중 공급자들이 사건을 전달하여야 한다.

●소비자들은 사건을 요구하거나 공급자로부터 전달 받을 수 있다.

●소비자들과 공급자들은 표준 IDL 인터페이스를 이용한다.

●사건 자료의 통신은 한번의 표준 요청으로 이루어진다.

●공급자와 소비자들의 상대 정보는 서로 알 필요가 없다.

●사건 인터페이스는 다양한 운영 환경에서 사용된다.

4. 사건 서비스 구현 사례

가. OrbixTalk

OrbixTalk는 IONA 사에서 최근 구현한 OMG의 사건 서비스로 고수준의 성능과 스칼라 기능을 제공한다. OrbixTalk는 일반 모델과 형 정의 모델의 통신을 수행할 수 있는 확장된 API와 메시지 저장의 지속성 확장에 의한 효율적이고 보장성이 포함된 다양한 특성의 메시지 전달 서비스를 제공한다.

나. JacORB

JacORB는 OMG CORBA를 GNU 공공 허가 조항에 따라 공개 구현한 것으로 독일 베를린의 Freie 대학에서 개발되었다. JacORB 사건 서비스에서 푸시 모델의 통신은 간단하게 구현되어 있다. 사건이 사건 채널 속으로 푸시된 후 바로 분리된 쓰레드가 구동된다. 그래서 푸시 공급자들은 사건이 전달될 때까지 기다릴 필요 없이 바로 복귀된다. 사건의 전달은 사건 채널과 통신될 시점에 연결되어 있는 소비자들만이 사건을 받게 된다.

5. 사건 서비스 구현

사건 서비스는 사건을 생성하는 공급자와 공급자로부터 사건을 전달 받아 처리하는 소비자, 그리고 공급자들과 소비자들간의 비동기적이고 결합도가 낮은 통신을 제공하기 위한 사건 채널로 구성된다. 공급자와 소비자는 사건의 전달 방법에 따라서 사건을 전달하는 푸시 모델을 사용할 것인지, 사건을 요구하는 풀 모델을 사용할 것인지를 결정하고 연산자와 인자 형태에 따라서 일반 모델을 사용할 것인지, 형 정의 모델을 사용할 것인지를 결정하여 IDL 로 정의된 사건 서비스 인터페이스를 별도의 구현 작업 없이 상속 받아서 사용한다. 이때 사용될 공급자와 소비자를 위한 IDL 인터페이스는 별도의 구현이 필요없다.

그러나, 사건의 중개자인 사건 채널을 위하여 정의된 IDL 명세는 서비스 기능을 수행하기 위한 별도의 구현 코드를 추가하여 ORB의 구현 저장소에 등록하여야 한다. 공급자와 소비자는 ORB를 통해 사건 서비스를 제공하는 사건 채널의 구현객체와 연결하고 IDL 명세에 정의된 대리 객체와 연결 단계를 거쳐 야만 실제로 사건을 전달하고 또한 전달 받을 수 있게 된다.

사건 서비스는 사건 채널을 통하여 공급자들과 서비스들간에 사건 자료의 전달을 제공하는데 그 목적이 있다. 사건 서비스 명세서에는 일반 모델의 개념은 명확하게 정의되어 있지만 형 정의 모델은 구현자의 의도나 모델의 구조에 따라 여러 가지 형태로 구현되어질 수 있다. 즉, 전달 방법이나 서비스의 질은 사건 채널의 구현방식에 따라 달라질 수 있다.

일반 모델의 구현에 있어 주요 과제는 사건 버퍼의 동기화이다. 사건 버퍼는 사건 자료를 전달하기 전에 임시로 저장해두는 곳으로 다중의 대리 객체들 간의 동기화가 반드시 이루어져야만 한다. 형 정의 모델은 다양한 사용자 정의형의 연산자를 일반적인 하나의 형 정의 사건 채널을 통해 전달될 수 있도록 하기 위해 암호/해독 객체를 이용한다.

가. 사건 채널의 구현

사건 채널은 전달되는 사건을 저장하고 해당 대리 객체들이 필요한 사건을 가져갈 수 있도록 한다. 사건 버퍼에 사건을 저장할 때, 저장을 호출한 객체의 정보와 전달되는 사건 자료, 및 사건을 받을 대리 객체들의 리스트 정보를 가지고 저장된다. 사건 버퍼에 자료를 저장할 수 있는 객체는 한 순간에 한개 밖에 없게 하기 위해 임계 영역으로 설정하고 사건 버퍼의 동기화를 위해 세마포를 사용하였다. 반대로, 사건 버퍼에서 사건 자료를 얻는 대리 객체들에 대해서는 동시에 접근 할 수 있도록 허용하였다. 단, 사건을 가져간 대리 객체의 정보를 제거할 때에는 동기화가 이루질 수 있도록 하였다.

나. 일반 모델의 대리 객체 구현

사건 버퍼에 사건 자료를 저장하고 가져가는 것은 사건 채널 내부의 대리 객체들이 그 역할을 수행한다. 공급자와 소비자는 이 대리 객체와 연결하여 사건을 전달한다. 대리 객체는 접속한 공급자와 소비자만큼 생성되며 하나의 대리 객체는 하나의 공급자나 소비자를 대신한다. 따라서 대리 객체는 기본적으로 쓰레드로 구현되어야 한다. 대리 객체의 종류는 다음과 같다.

●대리 푸시 공급자

●대리 푸시 소비자

●대리 풀 공급자

●대리 풀 소비자

다. 형 정의 모델의 대리 객체 구현

형 정의 모델은 대리 객체의 기능이 일반 모델의 대리 객체와 거의 동일한 기능을 수행한다. 추가된 연산자는 사용자 정의 형의 객체를 얻는 객체 참조를 얻기 위한 연산자가 있다.

6. 결론

사건 서비스의 구현은 사건을 저장하기 위한 사건 버퍼와 공급자나 소비자와 접속하여 사건을 전달해 주는 역할을 수행하는 대리 객체를 구현하는 것이다. 사건 채널을 구현하는데 있어서 가장 중요한 부분은 사건 버퍼의 설계와 사건 자료에 대한 대리 객체들간의 동기화 부분이다. 사건 버퍼의 설계는 사건 자료의 효과적인 관리 능력과 처리 성능에 밀접한 관련이 있다. 다중의 대리 객체들간에 사건 자료 전달의 효율성과 자료의 안정성을 제공하는 신뢰성 있는 사건 처리는 사건 버퍼의 동기화를 통해서 이루어 질 것이다.

형 정의 모델을 구현하기 위하여 사용자 정의형의 암호/해독 객체의 생성을 통한 사건 방법을 제시하였다. 본 구현 방법은 사용자 정의형의 연산자와 그 인자값을 사건 채널에 전달하고, 그 사건 자료를 형 정의 소비자에게 전달하기 전에 사용자 정의형의 연산자로 다시 변환하여 전달하는 방식이다. 이러한 방법은 암호/해독 객체의 구현 코드를 생성하기 위한 별도의 추가적인 개발 작업이 필요하지만, 이것은 자동 코드 생성기 개발을 통하여 사용자 입장에서는 큰 부담이 없다. 사용자 정의형의 사건을 저장하기 위한 형 정의 사건 버퍼와 형 정의 사건을 전달하는 대리 객체의 구현이 내부적으로 일반 모델의 사건 채널을 사용할 수 있는 구현 모델이기 때문에 사건 채널을 구현하는데 있어서 더 효과적이라고 생각한다. 또한 하나의 사건 채널을 통하여 다양한 사용자 정의형의 사건을 전달할 수 있는 장점을 가진다.

추후 연구과제로 사건 채널의 지속성과 사건 필터링에 관한 연구가 수행되어야 할 것이다. 표준 CORBA 사건 서비스는 직속성을 제공하도록 사건 채널에 요구하지 않는다. 따라서 사건 채널을 구현시에 시스템이 중지되었을 때의 공급자와 소비자의 연결 정보와 아직 전달되지 못한 사건을 저장할 필요가 없다. 이러한 지속성의 결핍은 사건 채널의 견고성을 감소시키며 분산 응용 프로그램의 유용성을 감소시킨다. 또한 표준 CORBA 사건 서비스의 사건 채널은 모든 사건들을 모든 푸시 소비자들에게 제공하도록 정의되어 있다. 소비자가 측정 사건만을 원할 경우, 각 소비자가 스스로 자신이 관심을 가지는 사건을 찾기 위해 전달되는 모든 사건에 대해 필터링 작업을 수행해야만 한다. 이러한 작업은 소비자가 사건 채널에 등록하면 조건 값으로 받아 처리할 수 있을 것이다.

제4절 타이밍 서비스

1. 분산 시간 개요

타이밍 서비스는 기본 시간 서비스와 시간 사건 서비스로 구성된다. 기본 시간 서비스는 사용자에게 유효 범위의 현재 시간을 제공하고 그리니치 시간대에 관련된 UTC (Universal Time Coordinated)를 사용하여 적절하게 시간 간격을 조정한다. 시간사건 서비스는 일정 시간마다 시간 사건을 발생하여 사건 채널을 통해 요구자에게 전달한다.

2. 타이밍 서비스 설계

분산 환경에서 응용 프로그램들 사이의 상호 운용성과 오퍼레이션의 투명성을 제공하기 위하여 OMG에서 CORBA를 제안하였다. 그러나 CORBA 명세만으로는 분산 환경에서 발생할 수 있는 사건의 순서화, 시간에 기반을 둔 사건의 발생과 관리 등이 필요한 응용 프로그램을 작성하기에는 충분하지 않다. OMG에서는 이러한 필요성에 의해 타이밍 서비스를 명세하였다. 본 보고서에서는 OMG에서 제안된 타이밍 서비스를 설계하고 이의 구현에 대하여 기술한다. 이를 위하여 사건의 순서화를 위한 시간의 동기화, 시간에 관련된 사건의 발생을 유지하고 관리하기 위한 타이머 사건 핸들러의 구현 모형과 실제 구현 과정을 제시한다.

가. 타이밍 서비스 요구사항

●사용자는 현재 시간과 그와 관련된 부정확 정도를 얻을 수 있다.

●사용자는 사건들의 발생한 순서를 확인할 수 있다.

●사용자는 타이머와 경보에 기반을 둔 사건을 발생시킬 수 있다.

●사용자는 두 사건 사이의 시간 간격을 계산할 수 있다.

나. 타이밍 서비스의 구성

타이밍 서비스는 두 개의 서비스로 구성된다. 기본 시간 서비스는 범용 시간 객체와 시간 간격 객체를 관리하고 서비스는 표준 시간을 얻고 조작하는 오퍼레이션을 제공한다. 타이머 사건 서비스는 타이머 사건 핸들러 객체를 다루고 시간 사건 인터페이스로 표현된다. 시간 사건 서비스는 시간 발생기와 발생된 시간을 다루는 오퍼레이션을 제공한다.

3. 타이밍 서비스 구현 사례

시간 사건 서비스는 사용자가 푸쉬형의 사건 채널을 생성하는 것이다. 그리고 사용자는 등록 오퍼레이션을 수행하여 반환 받은 타이머 사건 핸들러를 가지고 그와 관계된 사건이 발생할 때 사건 채널을 통로로 사용한다. 사용자는 원하는 시간 사건으로 지정하기 위하여 타이머 사건 핸들러를 사용할 수 있다. 타이머 사건 서비스는 요구했던 사건 시간의 적당한 간격 안에서 사건 채널을 통해 사건을 푸쉬한다. 사건과 관계되어진 자료는 요구했던 사건 시간과 실제 사건 발생 시간을 포함하는 타임 스템프를 포함한다. 또한 기본 타이밍 서비스에서 제공하는 시간을 가지고 네트워크 내의 각 노드들의 시스템 시간을 동기화 할 수 있다.

사건 서비스의 관점에서 객체 시간 서비스의 사용 예를 살펴보면 시간에 관련된 사건을 발생시키는 사용자는 공급자가 된다. 공급자는 소비자들에게 자료를 전달하기 위해 사건 채널을 사용한다. 반대로 소비자들은 사건 채널을 통해 공급자로부터 자료를 전달 받는다.

4. 타이밍 서비스의 구현

타이밍 서비스의 구현은 플랫폼에 독립적이고 이식성 및 호환성이 뛰어난 자바 언어를 사용하였고, 기존의 IONA사에서 자바로 구현한 CORBA 제품인 OrbixWeb을 기반으로 개발하였다.

가. 기본 시간 서비스의 구현

기본 시간 서비스는 분산 객체 환경에서 사용자에게 동기화 시간을 제공한다. OMG에 의해 정의된 객체 시간 서비스 명세서에는 시간의 동기화를 위해 특정 기법을 제시하고 있지 않다. 그러므로 본 연구 구현에서는 다음과 같은 방법으로 시간 동기화를 수행한다. 만약 클라이언트로부터 현재 시간을 묻는 요청이 로컬 서버에게 전달되면 로컬 서버는 글로벌 서버로부터 제공 받은 시간 몇 기타 지연 시간에 대한 정보와 자신의 시스템 시간에서 얻은 시간을 가지고 동기화 시간을 만들게 된다. 명세서에 제시된 UTC 시간 표현에 따르기 위해 기본 시간인 1582년 10월 15일 0시 0분 0초를 기준 시간으로 변환한다. 지연 시간은 매번 전송 트래픽에 따라 달라지기 때문에 그 값을 예상할 수 없게 된다. 이를 해결하기 위해 클라이언트와 글로벌 서버 사이에 로컬 서버를 두고 로컬 서버가 글로벌 서버로부터 전달 받은 시간 정보들을 가지고 동기화 시간을 만들어 로컬 시스템 시간을 동기화 시키거나 따로 정보를 보관하고 있다가 클라이언트로부터 요청을 전달받으면 이를 고려하여 클라이언트에게 동기화된 시간을 제공한다.

나. 시간 사건 서비스의 구현

타이밍 서비스 구조는 시간의 동기화를 위해 로컬 서버에게 시간을 제공해주는 글로벌 서버, 글로벌 서버로부터 전달받은 시간을 가지고 전송 지연시간과 요청 처리시간, 그리고 부정확 정도를 고려하여 로컬 시스템 시간을 동기화하는 로컬 서버로 크게 구분된다. 결국 클라이언트의 시간 요청은 글로벌 서버를 통해 동기화된 로컬 서버에서 처리하게 된다. 타이머 사건 서비스는 주어진 특정 시간에 시간 사건을 발생시킨다. 사용자는 특정 시간 후에 사건을 발생시키기 위해 시간을 설정하는데 지정된 시간이 상대 시간인지, 절대 시간인지 혹은 주기 시간인지를 나타내는 시간 형과 사건이 발생할 시간을 지정한다.

5. 결론

CORBA 객체 시간 서비스는 분산 컴퓨팅 환경에서 발생하는 사건들의 순서를 확인하고자 하는 사용자들에게 동기화된 시간을 제공하고, 시간에 기반을 둔 사건의 발생 및 관리하는 기능을 제공하는 서비스이다. 객체 시간 서비스의 구현에서의 핵심은 동기화된 시간을 제공하는 것과 지정된 시간에 사건을 발생시키는 기능을 제공하는 것이다. 이는 요구자와 서버간의 요청/응답에 걸리는 지연 시간을 감안하여 현재 시간을 제공하여 분산 객체 환경에서 시간의 동기화를 꾀하고, 타이머를 생성하여 이를 이용함으로써 특정 시간에 관련된 사건을 발생시킴으로써 해결된다. 보고서에서 객체 시간 서비스의 정의와 구성요소를 살펴보았고 아울러 정의에 따라 객체 시간 서비스를 설계 및 구현에 관하여 살펴보았다.

제5절 생명 주기 서비스

1. 생명 주기 개요

객체를 생성하는 방법은 두 가지가 있다. 최초의 객체들은 사용자 명령어에서 생성되고, 실행을 시작하게 된다. 사용자에 의하여 생성된 객체들을 다른 객체들을 생성하고 실행시킨다. 생명 주기는 생성된 객체가 다른 객체를 생성, 제거, 복사, 이동하는 기능이다. 생명 주기 서비스는 분산 환경에서 다른 장소에 있는 객체들에서도 서로 연관되어 동작한다. 생명 주기 서비스는 다른 객체를 생성하는 제조 객체에 의하여 제공된다. 제조 객체는 객체 응용에 의존하며 다른 객체들과 같이 정의된 IDL 인터페이스를 갖고 있으며 프로그래밍 언어로 구현되어 있다.

제조 객체는 객체를 만들기 위하여 필요로 하는 자원들을 모으며, 자신이 이용할 수 있는 자원의 할당 범위를 표현한다. 클라이언트는 제조 객체에서 생명 주기 연산을 수행할 목적 객체를 찾아서 생명 주기 연산을 호출한다. 제조 객체에서 목적 객체를 찾는 방법은 객체 찾기 서비스를 이용한다.

2. 생명 주기 서비스 설계

생명 주기 서비스는 이것을 사용하는 사용자를 기준으로, 그들의 역할에 기반해서 이 서비스를 설계를 하였다. 이 사용자들에는 서비스를 사용하는 클라이언트 프로그래머, 서비스의 목적 객체들을 만들어 제공하는 응용 프로그래머, 그리고 서비스를 제공하는 시스템 프로그래머가 있으며, 이 서비스에 대한 각각의 관점을 가지고 있다. 생명 주기 서비스 설계는 다음 설계 사항을 고려한다.

●클라이언트는 제조 객체에서 객체 응용을 검색한다.

●객체 응용은 제조 객체에서 위치 정보를 포함한다.

●생명 주기 연산 결과는 객체 관계에 의존한다.

●생명 주기 서비스는 다른 공용 서비스와 독립적이다.

3. 생명 주기 서비스의 구현

생명 주기 서비스는 객체 찾기 서비스와 객체 관계 서비스에 의존한다. 그러므로 생명 주기 서비스를 구현하기 위하여 구현 환경으로 객체 찾기 서비스와 객체 관계 서비스가 있어야 한다. 그러므로 이와 같은 구현 환경을 갖춘 공개된 ORB 제품인 Expersoft사의 CORBAplus2.1을 선택하여 사용하였다.

CORBAplus에서 분산 클라이언트/서버 시스템을 작성하기 위해 일반적으로 다음과 같은 단계들이 요구된다. CORBA의 표준 인터페이스 정의 언어인 IDL로, 애플리케이션에서 사용되는 객체들의 인터페이스를 정의한다. IDL 컴파일러를 사용해서 IDL 인터페이스로부터 클래스들을 생성한다. 클래스들의 인스턴스들을 생성하고, 초기화를 해서 서버가 요청을 받을 수 있게 준비되면 서버 프로그램을 작성한다. 서버를 CORBAplus의 구현 저장소에 등록한다. 서버에 접속해서, 서버가 제공하는 객체들을 사용하는 클라이언트 프로그램을 작성한다. 클라이언트를 실행 시킨다. 생명 주기 서비스의 시험은 단순 객체에 생명 주기 연산들을 요청하는 문제는 객체들에 그래프에 복합 생명 주기 연산을 요청하는 예제에서도 다루어지기 때문에 여기서는 객체들의 그래프 예제만 사용하여 시험하였다.

4. 결론

분산 환경에서 객체들이 서로 관계를 갖고 객체 관계 서비스에 의하여 그래프를 형성하고 이 그래프에서 생명 주기 연산을 정확하게 수행할 수 있도록 생명 주기 서비스를 구현하였다. 생명 주기 서비스는 객체의 응용을 찾는 제조 객체를 서버로 만들고, 제조 객체를 이 서버에 등록해서 사용하도록 하였다. 객체를 찾는 방법은 제조 객체에서 찾기도 하며 CORBA 구현 저장소에 등록된 객체의 응용을 찾아내어 실행 시킬 수도 있다.

제조 객체 찾기를 설계할 수 있는 다른 방법은 구현 저장소를 이용하는 방법이 있다. 구현 저장소를 이용하려면 제조 객체들을 등록하고, 제조 객체 찾기를 사용해 찾을 있도록 구현 저장소를 알맞게 확장 해주어야 한다. 이러한 사례는 Expersoft사의 PowerBroker는 객체 찾기를 구현 저장소로 구현하였다.


제5장 참조 시스템 구축 및 분석

제1절 개 요

본 연구에서 구축한 참조 시스템은 독일 Freie 대학에서 발표, 공개한 JacORB를 기준으로 하였다. 이 시스템은 Java를 이용하여 CORBA의 스텁 및 스켈리턴을 위한 IDL 컴파일러를 구현함과 동시에 ORB 자체도 Java로 구현되어 있으므로 참조와 구축이 용이하다. 공개되어 있는 소프트웨어는 현재 GNU 소프트웨어에 등록되어 공개되어 있으므로 설치 및 실험이 용이하다. 현재의 문제점은 이 시스템이 한 사람에 의하여 설계, 작성되었기 때문에 컴파일러 및 클래스 구조의 최적화에 기본적인 문제가 있고 또한 성능 및 기타 기능(CORBAservices)에 있어서 부족한 점이 많다. ORB 내부의 구현에서는 BOA(Basic Object Adapter)의 접속이 충분히 기술되어 있지 않다. 장점으로는 인터넷의 기본 프로토콜인 HTTP를 이용하여 서버 객체에 접속함으로써 firewall에 의한 객체 이용의 지리적 제한을 극복하였다는 것이다. 이러한 접속 방법은 현재 Visigenic(Borland 사에 합병됨)사의 VisiBroker에서 사용되고 있으며 VisiBroker의 Java 클래스는 Netscape4.0 브라우저에 내장되어 공급되고 있다. 따라서 인터넷 사용자의 무료 사용을 통하여 시장을 선점하기 위한 전략임을 인식할 수 있다.

객체의 관리를 위하여 제안된 CORBA 규격을 구현하는데 기본으로 사용되는 언어는 C++ 및 Java이다. 사용자 측면에서 볼 때 C++로 작성된 응용 프로그램과 Java로 작성된 것은 서로 차이점을 갖는다. 객체 지향 언어로 널리 사용되는 C++의 경우 컴파일러의 차이로 시스템간의 호환성에 많은 문제점을 갖고 있다. 실행 파일자체에 대한 호환성 문제점을 물론, 프로그램 개발자가 SUN 시스템에서 개발한 것을 DEC 알파 스테이션, HP 9000 시리즈, IBM RS6000 시리즈의 UNIX 환경, 또는 PC 환경에서 바로 컴파일 한다는 것을 사실상 불가능하다. 그 반대의 경우도 마찬가지이다. 매우 단순한 C++ 프로그램의 경우 별 문제가 없지만 프로그램이 커지고 내용이 복잡해지면 별도의 시간을 투자하여 이식 작업을 하여야 한다. 그러나 Java의 경우 JVM(Java Virtual Machine)이 설치되어 있다면 어떠한 시스템에서도 동일한 컴파일러 환경에서 동작할 수 있다. 물론 CORBA 응용에서는 CORBA에 종속적인 최소의 클래스 라이브러리가 존재하여야 한다. 다음 절에서는 상용 CORBA 시스템으로 널리 알려진 IONA사의 OrbixWeb과 Visigenic사의 VisiBroker에 관련된 응용 프로그램을 비교하고 그 차이점을 기술한다.

제2절 CORBA 프로그래밍 방법 비교

1. VisiBroker의 운용 환경

이 절에서는 Java 프로그램에 의한 CORBA의 사용자 환경을 실제의 시험 프로그램을 통하여 기술하고자 한다. 상호 비교를 편리하게 하기 위하여 idl 인터페이스는 동일한 것을 사용한다. 다루고자 하는 시스템 플랫폼은 Java 버전인 Visigenic의 VisiBroker와 IONA의 OrbixWeb2.0 이다.

가. IDL 파일의 작성

Java를 이용한 CORBA 환경에서도 idl을 필요로 한다. 기본적으로 idl은 CORBA 2.0 사양을 만족하기 때문에 사용자의 프로그램 언어에 관계없이 동일하다. 따라서 새로운 구문의 정의를 필요로 하지 않으며 C++버전의 상용 CORBA에서 사용하는 것과 동일하다. Idl의 내용은 다음과 같다.

여기서 calc.idl은 Visigenic의 VisiBroker에서 제공하는 idl2java 컴파일러에 의하여 컴파일되며 인터페이스당 기본적으로 5개의 Java 파일을 생성한다. 여기서 idl2java 컴파일러의 실행 이전에 VisiBroker의 환경 변수를 다음과 같이 설정하여야 한다.

% setenv CLASSPATH .:/usr/local/orbeline:$CLASSPATH

% setenv ORBELINE /usr/local/orbeline/adm

% setenv PATH /usr/local/orbeline/bin:$PATH

예를 들어서 idl2java 컴파일러의 명령은 (그림 5-1)과 같다.

●_example_calc.java: 서버측의 calc 객체를 구현하기 위하여 사용자가 구현하는 파일

●_sk_calc.java: 서버측 스켈리턴 파일(이 파일은 사용자가 수정하지 않는다.)

●_st_calc.java: 클라이언트 스텁 파일(이 파일은 사용자가 수정하지 않는다.)

●_tie_calc.java: Tie 방법을 이용할 경우 calc 객체를 구현하기 위하여 서버에서 사용할 파일

●calc.java: calc 인터페이스의 정의

●calcOperations.java: add 메소드 함수를 정의

●calc_var.java: calc_var 클래스를 정의하고 여기에 사용자가 정의한 calc 및 ORB 호출에 필요한 bind, any 등의 메소드를 정의한다.

●calc.idl.tmp: calc.idl의 복제

기본적으로 Java 환경에서는 C, C++와 같은 헤더 파일을 갖지 않는다. 따라서 여기에 해당되는 정의는 각각 calc.java, calcOperations.java 및 calc_var.java에 정의된다. 즉 interfacename.java, interfacenameOperations.java 및 interfacename_var.java 이다.

나. 서버 파일의 작성

Java 프로그램은 기존의 C++에 의한 경우보다 더욱 간단하다. 예문에 표시한 것은 VisiBroker의 Impl approach를 이용하였으며 이것은 IONA/OrbiWebx의 BOAImpl approach에 해당하는 것이고 다음과 같이 기술하였다.

1. //

2. // FILENAME: calserver.java

3. //

4. // A server file for the calc example by using VisiBroker.

5. //

6. // D. J. Kim March 27, 1997

7. //

8. public class calserver {

9. public static void main(String args[]) {

10. try {

11. CORBA.ORB orb = CORBA.ORB.init();

12. CORBA.BOA boa = orb.BOA_init();

13.

14. calcImpl calcref = new calcImpl("Calc");

15. boa.obj_is_ready(calcref);

16. boa.impl_is_ready();

17. }

18. catch(CORBA.SystemException e) {

19. System.err.printIn(e);

20. }

21. }

22. }

11, 12번째 줄에서는 ORB 및 BOA를 초기화 한다. 14번째 줄에서는 calc 객체의 객체 참조를 제공하는 Calc의 새로운 객체를 calcref로 선언하고 초기화 한다. 15, 16에서는 obj_is_ready() 및 impl_is_ready() 메소드 함수를 호출한다. 이것으로 서버는 클라이언트로부터 호출을 받을 준비가 종료된다.

다. 클라이언트 파일의 작성

기본적으로 클라이언트 파일은 bind 방법에서 약간의 차이를 나타내는 것 이외에는 플랫폼 별로 거의 동일하다.

1. //

2. // FILENAME: calclient.java

3. //

4. // A client file for the calc example by using VisiBroker.

5. //

6. // D. J. Kim March 27, 1997

7. //

8. public class calserver {

9. public static void main(String args[]) {

10. // Process input argument

11. int num1 = Integer.parseInt(args[0]);

12. int num2 = Integer.parseInt(args[1]);

13.

14. try {

15. CORBA.ORB orb = CORBA.ORB.init();

16.

17. calc calref = calc_var.bind("Calc");

18.

19. long sum = calref.add((short) num1, (short) num2);

20. System.out.printIn(num1 + " + " + num2 + " = " + sum);

21. }

22. catch(CORBA.SystemException e) {

23. System.err.printIn(e);

24. }

25. }

26. }

11, 12에서는 사용자 명령어로부터 받아들이는 입력 변수를 처리한다. 15번째 줄에서는 ORB를 초기화 한다. 17번째 줄에서는 Calc 객체에 대하여 bind 메소드를 호출하여 서버와 세션을 설정한다. 19번째 줄에서는 idl에서 정의하고 메니저 파일에서 사용자에 의하여 구현된 add 메소드를 호출한다. 20번째 줄에서는 출력결과를 인쇄한다. 14-24에 의하여 핵심 메소드 호출은 모두 TRY 블록내에서 익셉션을 처리한다.

라. 오퍼레이션 파일의 작성

서버 프로그램과 같이 적재(loading)되는 메니저 파일은 idl2java 컴파일러에 의하여 생성된 _example_calc.java를 변경하여 작성한다. 처음 컴파일러에 의하여 생성된 파일 및 개발자에 의하여 정의된 파일의 차이를 다음에 표시하였다.

마. 컴파일 환경 설정

다음의 내용은 TrMakefile에서 컴파일 옵션만을 추출한 것이며 gnumake에서도 동일하게 작동한다.

●Makefile 내의 VisiBroker 환경변수 설정:

●Java 컴파일 환경 설정: Java 환경에서는 C, C++와 같은 include 디렉토리의 설정 및 LD_LIBRARY_PATH에 관한 옵션이 없다. 이것은 기능적으로 Java의 CLASSPATH에 대응된다. 사실상 CLASSPATH는 위의 두 가지 기능을 함께 갖고 있다.

바. 프로그램의 실행

VisiBroker의 응용을 실행시키기 위해서는 다음과 같이 시스템 서비스 데몬 프로세스를 수행시켜야 한다.

사. TIE approach에 의한 방법

TIE approach에 의하여 프로그램을 작성하는 경우 기본적으로 서버 프로그램 및 오퍼레이션 파일에서만 차이가 있다. 서버 프로그램에서는 서버의 클래스에서 직접 객체의 인스턴스를 선언하며 클라이언트 프로그램은 BOA Impl approach의 경우와 동일하다.

VisiBroker의 컴파일러에서는 개발자의 접근 방법에 따른 옵션의 차이가 없다. 기본적으로 모든 스텁, 스켈리턴, 오퍼레이션 파일을 한꺼번에 생성하기 때문에 개발자는 선택적으로 이들을 이용하면 된다.

1. //

2. // FILENAME: tcalserver.java

3. //

4.. // A server for the Tie_c 및 example by using visiBroker.

5. //

6. // D.J. Kim March 28, 1997

7. //

8.

9. public class tcalserver {

tcalcOperations.java 파일은 VisiBroker의 idl 컴파일러인 idl2java에 의하여 생성되고 여기에 tcalcOperation이 인터페이스로 정의된다.

tcalcOperations.java의 내용은 다음과 같다.

1. public interface tcalcOperations {

2. public int add(in short a,

3. in short b)

4. throws CORBA.SystemException;

5. }

●VisiBroker의 특징

1. GateKeeper는 HTTP tunnelling을 지원한다. HTTP tunnelling은 클라이언트로 하여금 인터넷 환경의 기본 프로토콜인 HTTP(tirewall을 통과 할 수 있다)를 이용하여 통신하는 것을 말한다.

2. VisiBroker는 native IIOP를 지원한다. VisiBroker의 기본 통신 프로토콜은 IIOP를 사용하고 있으므로 사용자의 프로그램에서 별도의 IIOP를 명기하지 않아도 IIOP의 서비스를 제공받을 수 있다. 예를 들어서 현재 hanuri99에는 osagent가 동작하지 않고 hanuri0에서 동작하고 있을 때 hanuri99에서 다음과 같은 실행이 가능하다.

% java -DOSAGENT_ADDR=hanuri0 calclient

2. OrbixWeb(2.0)의 운용 환경

OrbixWeb2.0은 IONA/Orbix(C++ 버전)의 Java 버전이며 BOAImpl approach, TIE approach 및 IIOP와 DII 기능을 모두 안정적으로 제공한다. 단 현재의 OrbixWeb은 시스템 환경변수에 있어서 Orbix와 중복되는 것이 있으므로 하나의 시스템에 Orbix와 OrbixWeb을 동시에 수행시킬 수는 없다. 필요하다면 OrbixWeb의 Implementation Repository에 Orbix의 객체를(OrbixWeb의 putit 명령어를 이용하여) 지정하여야 한다. 여기서는 위에서 언급한 4가지 응용을 나열하여 각각의 차이점을 알아보도록 한다.

가. OrbixWeb2.0 환경변수의 설정 및 IDL 컴파일

●기본환경: OrbixWeb은 다음과 같은 환경 변수가 사용자에 의하여 시스템 데몬 프로세스 및 사용자 프로세스의 실행 이전에 설정되어 있어야 한다.

●컴파일 환경

앞에서와 같은 환경 설정에 의하여 OrbixWeb IDL 컴파일러에 의하여 생성되는 파일은 (그림 5-2)와 같다.

●_calcRef.java: 이 인터페이스의 메소드 함수는 Java 클라이언트 프로그램의 관점에서 본 IDL의 인터페이스를 정의한다.

●calc.java: 인터페이스 _calcRef.java에 정의된 메소드를 구현한 Java 클래스

●_calcHolder.java: 클래스 calc를 위한 Holder 타입을 정의하는 Java 클래스; IDL 오퍼레이션으로부터 inout 또는 out 변수로 calc 객체를 처리할 경우에만 필요하다.

●_calcOperations.java: Java의 메소드를 위한 IDL 정의내의 오퍼레이션에 대응하는 Java 인터페이스; 이 메소드들은 서버 프로그램에 정의된 클래스내에서 구현되어야 한다.

●_boaimpl_calc.java: BOAImpl을 이용하여 calc 인터페이스를 구현하기 위한 abstract Java 클래스

●_tie_calc.java: TIE approach를 이용하여 calc 인터페이스를 구현하기 위한 abstract Java 클래스

●_dispatcher_calc.java: 객체를 구현하기 위하여 들어오는 서버의 처리요구를 배포하기 위한 OrbixWeb에 의하여 내부적으로 사용되는 Java 클래스

나. BOAImpl approach를 이용한 서버 파일의 작성

IDL 파일은 앞에서 사용한 것과 동일한 인터페이스를 사용하므로 여기서는 생략한다. Idl 컴파일러에 의하여 생성되는 스텁, 스켈리턴, 오퍼레이션 파일은 Orbix에서 C++에 의한 것과 매우 상이하지만 개발자가 작성하여야 할 클라이언트, 서버 프로그램은 기본적으로 동일한 구조를 갖는다.

1. //

2. // FILENAME: calserver.java

3. // A server for the IONA.OrbixWeb calc example.

4. //

5. // D. J. Kim April 1, 1997

6. //

7. import IE.Iona.Orbix2._CORBA;

8. import IE.Iona.Orbix2.CORBA.SystemException;

9.

10. public class calserver {

11. public static void main(String args[] } {

12. String serverName = "CALC";

13. _calcRef calcImpl = null;

14.

15. try {

16. calcImpl = new calc_i();

17. }

18. catch(SystemException se)

19. System.out.printIn("Exception in calc_i" + se.toString();

20. System.exit(1);

21. }

22.

23. try

24. _CORBA.Orbix.impl_is_ready(serverName, // Alive!

25. _CORBA.IT_INFINITE_TIMEOUT);

26. }

27. catch(SystemException se) {

28. System.out.printIn("Error in impl_is_ready: " +

29. se.toString( );

30. System.exit(1);

31. }

32. }

33. }

7, 8에서는 OrbixWeb의 응용에서 필요한 클래스 라이브러리를 선언한다. 위의 클래스 라이브러리는 $ORBIX_HOME/classes/IE/Iona/Orbix2에 설정되어 있다. 16에서는 calc 객체의 객체 참조를 제공하는 calc_i의 새로운 객체 참조로써 calcImpl을 정의하고 초기화 한다. 24에서는 impl_is_ready 메소드 함수를 이용하여 클라이언트로부터 호출을 받는 대기 상태로 들어가게 한다. 16 및 24는 각각 TRY 블럭에 의하여 익셉션 처리를 한다.

11번째 줄의 calc_i는 _boaimpl_calc로부터 상속된다. _boaimpl_calc는 컴파일러에 의하여 생성되며 이 클래스는 IDL 인터페이스에 정의된 calc로부터 상속된 것이다. 15번째 줄에서는 메소드의 실제 처리 내용을 기술한다.

다. BOAImpl approach를 위한 클라이언트 파일의 작성

1. //

2. // FILENAME: calclient.java

3. // A client for the IONA.OrbixWeb calc example.

4. //

5. // D. J. Kim April 1, 1997

6. //

7. import IE.Iona.Orbix2._CORBA;

8. import IE.Iona.Orbix2.CORBA.SystemException;

9.

10. public class calclient {

11. public static _calcRef calcP = null ; // from compiler!

12. public static void main(String args[])

13.

14. // Process input argument

15. int num1 = Integer.parseInt(args[0]);

16. int num2 = Integer.parseInt(args[0]);

17. long sum = 0;

18.

19. String hostname = new String(_CORBA.Orbix.myHost());

20.

21. try {

22. calcP = calc._bind(":CALC", hostname);

23. }

24. catch (SystemException ex) {

25. System.out.printIn("Exception in bind");

26. }

27.

28. try {

29. sum = calcp.add((short) num1, (short) num2);

30. }

31. catch (SystemException ex) {

32. System.out.printIn(ex.toString());

33. }

34. System.out.printIn(num1 + " + " + num2 + " = " + sum);

35. }

36. }

11에서는 idl 컴파일러에 의하여 생성된 _calcRef로부터 사용자에 의하여 정의된 calcp 객체 참조를 선언하고 이것을 초기화 한다. 15∼17에서는 입출력 변수를 선언하고 입력변수로부터 데이터를 받아들인다. 22에서는 _bind 메소드 호출에 의하여 proxy 생성하여 OrbixWeb 데몬 프로세스를 통하여 서버의 위치를 알아내고 이것을 객체 참조에 할당한다. 29에서는 객체참조로부터 사용자가 정의한 add 메소드 함수를 호출하고 결과를 되돌려 받는다. 22, 29는 각각 TRY 블럭에 의하여 익셉션 처리를 한다. 34에서는 출력결과를 인쇄하고 프로그램을 종료한다.

라. TIE approach를 이용한 프로그램 작성

TIE approach의 경우 Orbix의 경우와 마찬가지로 클라이언트는 동일한 프로그램을 이용하고 서버 프로그램의 경우 사용하고자 하는 객체의 상속관계에 차이가 있게 된다. BOAImpl approach와 TIE approach의 기본적인 개념은 Orbix의 경우와 동일하다.

1. //

2. // FILENAME: calserver.java

3. // A client for the OrbixWeb calc example using TIE

4. //

5. // D. J. Kim April 1, 1997

6. //

7. import IE.Iona.Orbix2._CORBA;

8. import IE.Iona.Orbix2.CORBA.SystemException;

9.

10. public class calserver {

11. public static void main(String args[]) {

12. String serverName = "TIE_CALC";

13. _calcRef calcImpl = null;

14.

15. try {

16. calcImpl = new _tie_calc(new calc_i());

17. }

18. catch (SystemException se)

19. System.out.printIn("Error in calc_i" + se.toString());

20. System.exit(1);

10번째 줄의 내용은, 11장의 BOAImpl approach를 이용한 서버 파일의 작성에서 calc_i.java의 경우 calc_i와 _boaimpl_cal는 상속 관계를 갖고 있으나 여기서 calc_i는 _calcOperations 인터페이스(IDL 에 정의된 오퍼레이션을 Java 메소드에 대응 시키기 위하여 정의된 인터페이스이며 OrbixWeb의 IDL 컴파일러에 의하여 자동적으로 생성된다.)로 부터 직접 구현된다. calc_i와 _calcOperations 인터페이스의 관계를 (그림 5-3)과 (그림 5-4)에 표시하였다. 11번째 줄의 SystemException()은 익셉션 처리를 위한 통상의 처리 루틴이다.

마. BOAImpl approach와 TIE approach의 비교

Orbix에서 C++의 경우와 마찬가지로 TIE approach는 이미 존재하고 있는 Java 클래스를 사용하고자 할 때 이것을 IDL 인터페이스의 구현 클래스로 이용할 수 있으므로 매우 유용한 개발 방법이 될 수 있다. 또한 구현 클래스 사이에 상속 관계가 없으므로 프로그램 개발자는 filter 등의 필요한 부가적인 기능을 자유롭게 구현할 수 있다.

●OrbixWeb IDL 컴파일러의 문제점

Idl 컴파일러에 의하여 CORBA IDL 파일을 컴파일한 결과로 생성되는 모든 java 파일에서 인터페이스에 정의한 수치 인수의 타입을 따르지 못한다. 즉 idl 파일에서 메소드 함수의 리턴 타입을 long으로 선언한 경우 생성된 자바 스텁, 스켈리턴 파일 등의 내부에서는 모두 int로 선언한다. 따라서 특히 사용자의 클라이언트 프로그램에서 별도의 타입 케스팅을 하여야 하며, 처리에 직접적인 문제를 발생시킬 경우 일반적으로 프로그램의 개발자가 변경할 필요없는 스텁 파일 등을 직접 hard coding에 의하여 조작하여야 할 필요가 있다. unsigned long, unsigned short의 경우도 마찬가지이다. 그러나 short, float, double의 경우에는 정상적으로 파일을 생성한다. 프로그래머 매뉴얼에 위의 사항이 언급되어 있으나 원인에 대한 설명이 없고 결과만 기록되어 있다.

3. Socket에 의한 Java 클라이언트/서버 프로그래밍

가. Socket 객체만을 이용할 경우

OrbixWeb 또는 VisiBroker와 같은 사용 CORBA 시스템을 이용하지 않고 socket 만을 이용하여 Java 클라이언트/서버 프로그램의 구현이 가능하다. 다음에 표시한 클라이언트 프로그램은 앞의 예에서 기술한 OrbixWeb 프로그램과 비교할 수 있으며 순수한 Java 프로그램일 경우 하부의 네트워크 프로그램이 어떠한 단계를 필요로 하는지 살펴보는데 의미가 있다.

25에서는 지정된 호스트 이름과 포트 번호에 의하여 새로운 소켓을 생성한다. 28, 29에서는 생성된 소켓 객체에서 출력할 데이터 스트림을 설정하고 이 객체에서 writeUTF 메소드 함수를 호출한다. 31, 32의 UTF는 Unicode Transfer Format을 말한다. Java 프로그램에서 송수신되는 데이터는 이 포멧으로 전송하여야 한다. 35에서는 반대로 서버로부터 데이터를 받아 들일 입력 데이터 스트림을 설정한다. 38에서는 31, 32의 반대로 입력 데이터 스트림 객체에서 readUTF 메소드 함수를 호출하여 서버로부터 되돌려진 결과를 읽는다.

1. //

2. // FILENAME: calserver.java

3. // Pure java code by using socket

4. //

5. import java.net.*;

6. import java.io.*;

7.

8. class calserver {

9. public static void main(String args[]) {

10.

11. int Port = 5432;

12. int MaxQ = 5;

13.

14. Socket soc;

15. ServerSocket s = null;

16.

17. InputStream InStr;

18. OutputStream OutStr;

19.

20. DataInputStream DiS;

21. DataOutputStream DoS;

22.

23. // Register service on the designated port.

24. try {

25. s = new ServerSocket(Port, MaxQ);

26. }

27. catch (IOException e) {}

28. System.out.printIn("Socket Calserver started");

29.

30. // Run the listen/accept loop forever

31. while (true) {

32. try {

33. soc = s.accept() ; // Wait & listen for a connect.

34.

35. InStr = soc.getInputStream();

36. Dis = new DataInputStream(InStr);

37.

38. // Type conversion parameter from client

39. int num1 = Integer.parseInt(new String(Dis.readUTF()));

40. int num2 = Integer.parseInt(new String(Dis.readUTF()));

41.

42. // Process input value

43. int sum = num1 + num2;

44.

45. // Get a comm stream associated with the socket

46. OutStr = soc.getOutputStream();

47. Dos = new DataOutputStream(OutStr);

48.

49. // Send the sum

50. DoS.writeUTF(Integer.toString(sum) );

51.

52. // Close connection, but not the server socket

53. Dis.close(); DoS.close();

54. InStr.close(); OutStr.close();

55. soc.close();

56. }

57. catch (IOException e) {}

58. }

59. }

60. }

25에서는 서버 소켓을 선언하여 클라이언트로부터 요구를 받아들일 준비를 한다. 선언의 내용은 포트 번호와 처리할 수 있는 최대 큐의 길이를 정의한다. 33에서는 클라이언트로부터 요구를 받아들인 후 새로운 클라이언트 소켓 객체를 생성하는데 이것을 서버측의 클라이언트 소켓 객체라고 한다. 이렇게 생성된 클라이언트 소켓 객체를 이용하여 클라이언트와 데이터를 주고 받게 된다. 원래의 서버 소켓은 다시 클라이언트로부터 요구를 받아들이는 역할을 계속 수행하게 된다. 35∼40에서는 클라이언트로부터 데이터를 받아들인 후, 42에서 필요한 처리과정을 거친 후 46∼50에서 다시 클라이언트로 데이터를 전송시킨다. 다음 장에 socket에 의한 클라이언트/서버 프로그램의 처리 과정을 (그림 5-5)에 표시하였다.

나. Thread 기능을 추가한 경우

앞에서 기술한 socket을 이용한 Java 클라이언트/서버 프로그램은 서버에서 하나의 클라이언트 처리만을 지원한다. C 언어에 의한 클라이언트/서버 socket 프로그램에서는 accept 시스템 호출이후 서버에서 fork() 시스템 호출을 이용하여 서버 프로세스는 계속 또 다른 클라이언트의 요구를 처리할 listen 상태로 들어가고 새로 생성된 child 프로세스는 클라이언트 프로세스의 요구를 처리한다. Java에서는 기본적으로 서버에서 통산적인 Unix의 소켓 응용 프로그램처럼 프로세스(프로세스의 개념도 아니지만)를 fork할 수가 없다. 따라서 위와 같은 경우 하나의 클라이언트 요구를 서버에서 종결하기 이전에 또다시 들어온 클라이언트 요구는 지정된 큐의 길이만큼 대기 되어질 수 밖에 없다. 이러한 블록 상태를 회피하고 병렬로 처리하기 위한 방법으로 Java에서는 thread 기능을 제공한다. 즉 서버에서 처리하여야 할 오퍼레이션 부분을 thread block에 삽입하여 처리하므로써 여러 개의 클라이언트를 처리 할 수 있게 된다.

Thread를 이용한 클라이언트/서버 프로그램은 서버 프로그램만 변경하면 된다. 기본적인 thread 프로그램의 개념은 처리에 필요한 오퍼레이션 부분만을 thread 블록내부에 정의하면 된다. 다음에 thread을 이용한 서버 프로그램을 예로 들었다. 앞의 경우와 마찬가지로 calserver.java는 서버 프로그램의 본체이고, calcThread.java는 앞 장의 calserver.java 프로그램에서 오퍼레이션에 관련된 부분만을 추출하여 thread 블럭을 구현한 것이다.

제3절 참조 시스템 분석

본 과제에서는 Java ORB의 설계에 참조하기 위하여 독일 Freie 대학에서 개발된 JacORB를 설치하고 분석하였다. JacORB를 스텁, 스켈리턴 파일의 생성을 위한 컴파일러와 Java 클래스 라이브러리로 구성되어 있으며 모든 부분이 순수한 Java로 구성되어 있다. 이 시스템을 참조 시스템으로 선택한 이유는 첫째, 인터넷을 통하여 무료로 설치, 사용할 수 있고, 둘째, 인터넷 프로토콜로 가장 많이 사용되는 http를 이용하고 있으므로 방화벽(firewall) 외부의 클라이언트 시스템에서 방화벽을 통과하여 서버 객체를 호출할 수 있으며, 마지막으로 모든 부분이 공개되어 이용시 저작권의 영향을 받지 않는다는 점 등이다. 이 절에서는 JacORB를 설치하는 과정과 클래스 구조 및 JacORB의 사용자 프로그램의 특징을 기술하도록 한다.

1. JacORB의 설치과정

가. Java_cup의 설치

Java_cup은 Georgia Tech에서 개발된 UNIX의 yacc, lex에 해당하는 컴파일러이다. 이 도구는 전체가 Java로 작성되었으며 사용자가 작성한 "filename.cup" 이라는 형식의 구문(grammar)화일을 parsing하여 해당하는 Java 화일(parser.java와 sym.java)를 생성한다. Java_cup의 설치는 비교적 단순하다. Java_cup을 디렉토리에 풀어놓은 이후에 Java_cup 디렉토리에 있는 "INSTALL" 화일을 상위 디렉토리로 옮기고 거기서 실행시키면 설치가 종료된다. JDK가 설치되어 있는 디렉토리를 질문하는 부분이 있으나 기술적으로 별 어려움이 없고 지시한데로 수행하면 된다.

Java_cup의 실행을 위해서는 Java_cup이 설치되어 있는 디렉토리(Java_cup 그 자체가 아님의 상위 디렉토리를 CLASSPATH에 다음과 같이 정의하여야 한다.

JacORB에서 정의한 parser.cup의 grammar 화일을 Java_cup의 컴파일러를 이용하여 컴파일하면 다음과 같은 결과를 화면에 출력하고 parser.javasym.java를 생성한다.

% java java_cup.Main < parser.cup

Warning: Terminal "LONG_NUMBER" was declared but never used

Warning: Terminal "INF" was declared but never used

Warning: Terminal "BSLASH" was declared but never used

Warning: Terminal "DOT" was declared but never used

------- CUP v0.9e Parser Generation Summary ----------

0 errors and 4 warnings

69 terminals, 81 non terminals, and 168 productions declared, producing 279 unique parse states.

4 terminals declared but not used.

0 non terminals declared but not used.

0 productions never reduced.

0 conflicts detected (0 expected).

Code written to "parser.java", and "sym.java".

------------------------------------------------ (v0.9e)

나. IDL 컴파일러의 생성

앞에서 생성한 parser.java 및 sym.java 이외의 나머지 화일들은 javac를 이용하여 컴파일하면 된다. 사용자는 Generator 디렉토리의 jacorb.Generator.Main에서 스텁 Gen.class 등을 통하여 호출된다. 생성된 idl 컴파일러는 bin 디렉토리에 있는 jgen 스크립트를 통하여 실행되며 스크립트의 내용은 다음과 같다.

# !/bin/csh -f

java jacorb.Generator.Main $agv # argv에는 CORBA IDL 파일이 지정됨.

다. ORB 클래스 라이브러리의 생성

ORB 클래스 라이브러리는 JacORB/jacorb/Orb에 있다. 여기에는 스텁과 스켈리턴에서 처리하여야 할 수치 및 문자 데이타의 객체 참조 처리와 소켓에 의한 데이타의 입출력 처리내용, 쓰레드의 생성, IDL 컴파일러에 의하여 생성된 스텁 및 스켈리턴과의 인터페이스(앞서 언급한 수치 및 문자 데이타 포함), 그리고 클라이언트에서 필요한 proxy의 생성, 동작에 관한 내용이 구현되어 있다.

이 디렉토리에 있는 Java 화일은 단순히 Java 컴파일러(javac)만을 필요로 하며 별도의 도구를 필요로 하지 않는다.

라. Naming 클래스 라이브러리의 생성

Naming 클래스 라이브러리는 JacORB/jacorb/Naming 디렉토리에 있다. 여기에는 http 서버를 통한 지명의 bind 초기 실행, 또는 중복실행(이미 bind 되어 있을 경우 앞서 bind 되어 있는 값을 되돌려 준다)의 확인, 지정된 Logfile에 대하여 서버(object implementation)를 통한 IOR 데이타의 저장 및 클라이언트에 의한 참조 등에 관한 내용을 구현하였다.

2. JacORB의 계층 구조

가. ORB의 Interface 계층

나. ORB 의 Implementation 계층

3. JacORB의 프로그래밍 환경

가. JacORB의 실행환경

JacORB의 동작을 위해서는 다음과 같은 C-shell 환경설정이 필요하다.

●Java 환경

% setenv CLASSPATH /usr/local/jdk1.1/lib/classes.zip

% setenv CLASSPATH . ; $CLASSPATH

% sentnv PATH /usr/local/jdk1.1/bin;$PATH

●Java_Cup: Java로 작성된 YACC 컴파일러

현재 hanuri99의 ∼djkim 및 /afs/etri/proj/tools/java_cup에 설치되어 있으므로 어느 한 곳을 CLASSPATH에 삽입시키면 된다. Java_Cup은 설치된 디렉토리 자체를 설정하는 것이 아니고 그 상위 디렉토리를 설정하도록 되어있다. 왜냐 하면 항상 java_cup이라는 이름(설치된 디렉토리와 동일한 이름)으로 클래스를 참조하기 때문이다. Java_cup에는 Java와 같은 바이너리 명령어가 없고 모두 Java class만 존재한다.

●JacORB의 환경

hanuri99에 설치되어 있는 JacORB를 이용하기 위해서는 다음과 같이 CLASSPATH를 설정한다.

나. JacORB를 이용한 응용 프로그램의 작성

인터페이스의 경우 JacORB에서 CORBA 사양을 만족하므로 2절에 기술한 calc.idl을 사용하였다. 정의된 IDL 화일을 이용하여 다음과 같이 컴파일 한다.

보다 편리하게 명령어를 수행하기 위하여 원시 코드내에 있는 shell script 보다는 다음과 같은 alias를 설정하는 것이 편리하다.

cpp의 위치는 /usr/ccs/lib/cpp이며 인수에서 또는 IDL 화일에 include가 선언되지 않은 CORBA IDL 화일의 경우 출력결과에 영향을 미치지 못한다. 일단 기본값으로 "/usr/ccs/lib" 디렉토리를 PATH에 포함하여 설정하면 중복하여 생각할 필요가 없다.

위의 명령어에 의하여 idl2java는 다음과 같이 calc.java를 생성한다. 생성된 Java 화일을 javac로 컴파일한 후에 다시 jgen을 이용하여야 스텁 및 스켈리턴 화일을 얻을 수 있다. 과정을 (그림 5-6)에 표시하였다.

위의 내용을 보아서 알 수 있듯이 여기서는 사용자가 정의한 인터페이스를 클라이언트, 서버 및 스텁, 스켈리턴 화일에서 참조할 수 있도록 선언하고 CORBA.CORBject라는 클래스로 부터 계승시킨다. Orbix의 경우에는 Implementation 헤더화일로 보면 적당하다. 따라서 이것을 기준으로 하여 클라이언트 화일 및 서버 화일을 작성하면 된다. 윗 그림에 도시한 바와 같이 JacORB에서는 이 화일을 javac에 의하여 컴파일한 이후, 여기서 생성된 class 화일을 갖고서 jgen이라는 명령어를 이용하여 스텁 및 스켈리턴 화일을 작성한다. 그러므로 다음과 같은 일련의 과정을 필요로 한다.

프로그램 개발자가 작성하여야 할 기본적인 화일에는 calcImpl.java(오퍼레이션 화일; 구체적인 처리를 기술), calcserver.java(바인드하여야 할 위치를 지정) 및 calclient.java(필요한 객체, 메소드를 호출)가 있다. calcImpl.java, calcserver.java 및 calclient.java의 작성 내욤은 다음과 같다.

실제 컴파일은 TrMakefile에 의하여 일정한 형태로 class 화일을 생성하도록 정의하였다.

19. sk.skeleton_ini("calc", 20. new URL("http://hanuri99. erti.re.kr/djkim/ServiceLog"));

21. }

22. catch (IOExceltion e) {

23. e.printstackTrace();

24. }

25. }

26. }

1. //

2. // File: calcient.java

3. // calc client for the remote server.

4. //

5. // D.J. Kim May 11, 1997

6. //

7. import jacorb. *;

8. import java.net. *;

9. import java.io. *;

10.

11. public class c 및 ient (

12. // Use the stub instead if the real thing

13. public static c 및 calcp = new calcstub();

14.

15. public static void main(String args[ ]) {

16. if (args.length != 2) {

17. System.out.println("usage: java calclient num1 num2");

18. System. exit(1);

19. }

20.

21. // Process input argument

22. int num1 = Integer.parseInt(args [0]);

23. int num2 = Integer.parseInt(args [1]);

24. long sum = 0;

25.

26. try {

27. // new code : bind to the server

28. // (URL needed to locate name server)

29. //

30. ((calcstub)calcp).bind("calc", new URL

31. ("http://hanuri99.etri.re.kr/djkim/ServiceLog"));

32.

33. sum = calcP.add({short) num1, (short) num2) ;

34. }

35. catch (IOException e) {

36. e.printstackTrace();

37 }

38. system.out.println(num1+" + "+num2+" = "+sum);

39. }

40. }

앞에서 작성한 3개의 화일은 다음과 같이 javac 컴파일러를 이용하여 컴파일하면 된다. 이 과정은 마찬가지로 TrMakefile에 의하여 자동적으로 수행된다.

% javac calcImpl. java

% javac calcserver. java

% javac calclient. java

다. 스텁 및 스켈리턴의 내용

여기서는 JacORB의 CORBA IDL 컴파일러에 의하여 생성된 스텁 및 스켈리턴의 내용에 대하여 살펴보도록 한다. 첫 번째로 JacORB의 IDL 컴파일러는 그 자체가 Java에 의하여 구현되었다. Unix 환경에서 보통 사용하는 Yacc 및 Lex를 대신하여 Georgia Tech 대학에서 개발한 Java_cup을 사용하였다. Java_cup은 Unix의 yacc 및 lex에 대응하는 컴파일러로써 동일한 내용의 grammar 화일을 이용하여 개발자가 필요로하는 Java 출력화일을 얻을 수 있다. 따라서 개발자가 컴파일러의 내용을 수정, 보완하고자 할 경우에는 Java_cup에 의하여 grammar 화일을 다시 컴파일하여야 한다.

JacORB의 IDL 컴파일러에 의하여 생성된 스텁 및 스켈리턴의 내용은 다음과 같다.

calcStub.java

1. //

2. // This file was automatically generated by JacORB Gen

3. //

4.

5. import jacorb.*;

6.

7. public class calcStub extends jacorb.Naming.NameStub implements calc {

8.

9. String typeId = "calc";

10.

11. public calcStub narrow()

12. throws jacorb.Orb.StubFactoryException

13. {

14. return (calcStub)stubCreate(netRef(), typeId() );

15. }

16.

17. public int add(short a1, short a2) {

18. Object args[] = new Object[2];

19. args[0] = e.wrapArg(a1);

20. args[1] = e.wrapArg(a2);

21. Object result = invoke("add", "(SS) I", args);

22. return ((Integer)result).intValue();

23. }

24. }

7번째 줄에서 정의된 calcStub 클래스는 jacorb.Naming.NameStub을 상위 클래스로 하여 생성된 하위 클래스이고 calc 인터페이스를 구현한 것이다. 9번째 줄에서는 인터페이스 이름을 스트링에 입력하여 식별자로 사용한다. 14번째 줄에 stubCreate 메소드는 Orb/Stub.java에 정의되어 있는데 클라이언트 객체 호출자를 위한 proxy factory의 개념과 동일하다. 즉 하나의 proxy를 생성하고 그것을 calcStub으로 형변환(type casting) 된다. 17번째 줄에서는 인터페이스에 정의되어 있는 오퍼레이션 함수(여기서는 메소드 함수)를 호출하며 각각의 입력 변수를 18∼20에서 처리하였다. 21번째 줄에서는 서버에 구현된 오퍼레이션 함수를 호출하는 마지막 단계로 invoke를 호출하는데 이것은 Orb/Stub.java에 정의되어 있다.

필요한 변수에는 정의된 오퍼레이션 함수와 되돌려지는 인수의 타입(여기서는 integer(=I), SS는 인수가 두 개이고 형태가 모두 short로 정의되었음을 표시한다), 그리고 배열변수로 묶여진 args 이며 22에서는 21에서 되돌려진 결과를 정수형 변수로 형 변환하여 되돌린다.

calcSkeleton.java

1. //

2. // This file was automatically generated by JacORB Gen

3. //

4.

5. import java.net.*;

6. import java.io.*;

7.

8. public class calcSkeleton extends jacorb.Naming.NameSkeleton {

9. calc objImpl;

10. jacorb.Orb.Request r;

11. jacorb.Orb.External e;

12.

13. public calcSkeleton() {}

14.

15. public calcSkeleton( calc m, jacorb.Orb.Request _r, jacorb.Orb.External _e ) {

16. objImpl = m;

17. r = _r;

18. e = _e;

19. start();

20. }

21.

22. public calcSkeleton( Object m ) {

23. setImpl (m);

24. }

25.

26. public void setImpl( Object m ) {

27. objImpl = (calc)m;

28. myType = "calc";

29. netServer = new jacorb.Orb.NetServer( this );

30. }

31.

32. protected void dispatch( jacorb.Orb.Request _r, jacorb.Orb.External _e ) {

33. new calcSkeleton (objImpl, _r, _e);

34. }

35.

36. public void run() {

37. jacorb.Orb.ObjectInputStream o = r.in_bytes;

38. try {

39. if( r.mline.equals("add")) {

40. short _a0 = o.read_object((short)0);

41. short _a1 = o.read_object((short)0);

42. jacorb.Orb.Holder out_args[] = null;

43. Object result = null;

44. try {

45. result = e.wrapArg(objImpl.add(_a0, _a1));

46. } catch( Exception ex ) {

47. if( r.response_expected )

48. e.sendReply(r, getExceptionTrace(ex), null, null,

49. GIOP.ReplyStatusType.USER_EXCEPTION);

50. return;

51. }

52. if( r.response_expected )

53. e.sendReply(r, result, "I", out_args,

54. GIOP.ReplyStatusType.NO_EXCEPTION);

55. } else if( r.mline.equals("_name$ping")) {

56. java.lang.String _a0

57. =(java.lang.String)o.receiveobject("Ljava.lang.String;");

58. Object result = null;

59. try{

60. result = e.wrapArg(ping(_a0));

61. } catch( Exception ex ) {

62. e.sendReply(r, getExceptionTrace (ex), null, null,

63. GIOP.ReplyStatusType.USER_EXCEPTION);

64. return;

65. }

66. e.sendReply(r, result, "Z", null,

67. GIOP.ReplyStatusType.NO_EXCEPTION);

68. } else throw new jacorb.Orb.NetException("Method not found:"

69. + r.mline);

70. } catch ( Exception exc ) {

71. exc.printStackTrace();

72. }

73. }

74. }

8번째 줄에서 정의된 calcSkeletion 클래스는 jacorb.Naming.NameSkeleton을 상위 클래스로 하여 생성된 하위 클래스이다. 10번째 줄에 정의된 jacorb.Orb.Request r 15, 17, 37로 각각 할당되어진다. 39의 r.mline은 string 타입으로 정의되어 있다. equals 메소드 함수에 의하여 객체의 값(동일성)을 검사한다. 검사의 결과가 true이면 인터페이스에서 정의된 변수의 타입으로 초기값을 설정한다. 45번째 줄에서는 서버 객체 내부(여기서는 calcImpl)에 정의된 메소드 함수를 호출한다. 이 결과는 47∼49의 sendReply에 의하여 결과를 되돌려주게 된다. sendReply 함수내의 변수 중 "I"는 변수의 타입이 정수형 변수(integer = "I") 임을 말한다. "Z"는 boolean 결과를 의미한다. String res.type에 정의되어 있다. JacORB의 스텁 및 스켈리턴은 어떠한 상용 CORBA 제품보다도 간단하다. 왜냐 하면 상용제품의 경우(예를 들어서 OrbixWeb) BOAImpl, TIE, IIOP, DII 등에 해당하는 모든 클래스, 메소드를 동시에 하나의 화일에 기술하도록 되어 있으므로(사실상 상용 제품의 경우 이렇게 하는 것이 편리하며 또한 응용 개발자의 시간을 단축시키는 것이다.) 분석하는 사람의 관점에서 볼 때 해석이 쉽지 않았으나 JacORB의 경우 제공하는 기본 프로토콜로써 httpd를 사용하므로 이 부분을 단순화 시킬 수 있다.

라. 프로그램의 실행

calserver.java의 22번째 줄 및 calclient.java의 35번째 줄에서 알 수 있듯이 JacORB 프로그램의 실행을 위해서는 http 서버(httpd 프로세스)를 필요로 한다. 따라서 hanuri99에 Web 서버(httpd)를 설치하였다. 첫 번째로 하여야 할 일을 네임서버를 동작시키는 것이다. 이것에 의하여 클라이언트는 필요한 서버를 찾을 수 있다.

% java jacorb.Naming.NameServer ~ /wwwhome/ServiceLog &

# 네임서버 실행

% java calcserver & # 서버 실행

% java calclient 3 5 # 클라이언트 실행

3 + 5 = 8 # 결과 출력

마. JacORB의 상태

●DII, DSI를 제공하지 않는다.

●현재 사용 가능한 activation mode는 unshared server(=one object per server) 뿐이다.

●Interface 또는 Implementaion repository를 갖지 않으며 별도의 Object Adaptor가 없다.

●JacORB만을 위한 데몬 프로세스를 필요로 하지 않는다. 응용 프로그램 수준에서 네임 서버만이 존재한다.

제4절 참조 시스템의 개량 구축

JacORB를 참조 시스템으로 구성하는데 있어서 첫 번째로 하여야 할 일은 컴파일러 및 네임서버를 제어하는 명령어와 CORBA, ORB의 클래스 구조의 재정의이다. 우선 명령어에서 컴파일러와 관련된 클래스가 함께 있는 디렉토리의 최상의 디렉토리까지 Java의 package에 의하여 정의하고 하위 디렉토리의 컴파일러는 Unix의 alias를 사용하는 것이 독립적으로 shell script에 의한 정의보다 안전하다. 왜냐 하면 쉘에 의한 정의는 각 사용자의 환경에 따라 차이가 있기 때문이다. 예를 들어서 Java Developer's Kit에서도 환경변수는 setenv에 의한 C-shell의 정의만을 기본으로 하고 있으며 나머지는 사용자의 환경에 맞추도록 하고 있다. 이러한 경우에 통상적으로 사용자 환경의 기본은 C-shell이고 경우에 따라서 tcsh, 또는 K-shell을 사용하고 있다. 이러한 경우 후자의 경우는 모두 C-shell의 기능을 포함하고 있으므로 사용에 불일치를 가져오는 경우는 없다.

1. IDL-to-Java 컴파일러의 수정

IDL-to-Java 컴파일러의 역할은 OMG IDL로 작성된 파일을 읽어 들여서 사용자의 응용 프로그램 작성에 필요한 스텁, 스켈리턴 및 메니저 파일을 생성하는 것이다. JacORB에서는 스텁, 스켈리턴의 내용상에는 문제가 없으나 사용자가 IDL 내부에 module을 정의하지 않았을 경우 개발자가 자동적으로 Global을 모듈로 정의한 파일을 생성한다. 여기에는 장단점이 있다. 우선 장점으로는 IDL에서 생성하는 모든 파일을 정의된 별도의 디렉토리에 생성하므로써 클래스 파일의 정리가 편리하다는 장점이 있다. 그러나 대표적인 단점은 생성된 Java 파일의 컴파일시에 개발자의 CLASSPATH에 통상적으로 Global 디렉토리가 정의되어 있지 않는 경우가 대부분이므로(실제로 정의할 필요가 없다) 디렉토리의 불필요한 이동이 필요하고 또한 필요한 클래스 파일을 컴파일러에 의하여 생성한 이후 다시 상위 디렉토리로 이동 시켜야 하는 불편함이 있다. 또한 이 위치를 그대로 유지한다면 실행 시에도 CLASSPATH의 참조 범위를 벗어나게 된다. 따라서 사용자가 명확히 IDL 내부에 Global, 또는 다른 이름의 모듈을 정의하지 않았을 경우 현재의 작업 디렉토리에 IDL-to-Java 컴파일러의 출력 파일을 생성하도록 수정하였다. 다음은 수정에 관련된 파일명이다.

IDL/ArrayDeclarator.java

IDL/ConstDecl.java

IDL/EnumType.java

IDL/Interface.java

IDL/StructType.java

STGEN/StubGen.java

2. 클래스 구조의 최소화

현재의 클래스 구조 정의는 필요 이상으로 계승되어(inherited) 있는 부분이 많다. 따라서 참조 시스템에서는 모든 클래스 구조를 점검하여 최소한의 클래스로 동작이 가능하도록 최적화하였다. ORB 클래스에서 원래의 Java 클래스 40개에서 실험 시스템에서는 37개, Naming에서는 원래의 Java 클래스 20개에서 실험 시스템에서는 17개로 축소 조정하였다. 컴파일러에서는 기본적으로 갖은 갯수의 클래스를 갖지만 생성되는 스텁, 스켈리턴 내부에 정의되는 메소드명에 있어서 다른 이름을 갖을 수 있다.

3. 클래스 개발환경의 체계화

기존의 Java 개발 환경은 단순히 javac 컴파일러에 의존하고 통상적으로 다수개의 Java 파일을 이용하여 클래스 파일을 생성할 경우 쉘 스크립트 수준의 개발도구를 이용하는 것이 한계이다. 그러나 이러한 방법을 이용할 경우 Source Code Control System(SCCS), RCS(Revision Control System)과 같은 진화된 원시 코드 관리 시스템을 적용하기 힘들게 된다. 따라서 참조 시스템은 원래 Transarc사에서 개발된 trmake(gnumake의 강화 버전)를 이용하여 원시 코드와 생성되는 Java 클래스 파일이 놓이게 되는 위치를 원천적으로 분리하여 생성, 관리함으로써 개발에 효율적인 환경을 구축하였다. 이러한 체계는 Java 파일에 관련되는 모든 구조에 적용 가능 하도록 TrMakefile에 새로운 매크로를 추가 시켰다.

ifneq (, $(findstring $ (SYSTEM_TYPE), sun_solaris))

JAVA_HOME := /usr/local/jdkl.1

JAVA_BINDIR := $(JAVA_HOME)/bin

JAVAC := $(JAVA_BINDIR)/javac

JAVA := $(JAVA_BINDDIR)/java

%.CLASS: %.java

@$(RM) $@

$(JAVAC) -d $(.buildDir)/../../ $<

혹은 $(JAVAC) -g -d $(.buildDir)/../../ $< # 디버깅용

endif

위와 같은 정의에 의하여 TrMakefile에서는 사용자가 정의한 Java 파일을 자동적으로 클래스 파일을 위한 원시 파일로 인식하여 필요한 컴파일러를 수행한다.

이러한 환경의 정의에도 또 다른 장점이 따른다. 예를 들어서 생성된 클래스 파일을 사전에 정의된 디렉토리로 EXPORT 시킬 경우(Unix의 symbolic link(link -s)를 이용하여 항상 같은 파일을 참조하게 한다) 다른 개발자들도 항상 일정한 버전의 클래스를 참조 할 수 있게 되므로 개발자간의 버전 불일치 문제점을 해결하는 아주 중요한 방법이 제공되는 것이다.

4. IDL 컴파일러에 의하여 생성된 파일의 문제점

IDL-to-Java 컴파일러에 의하여 생성되는 파일 중 GIOP 클래스를 구성하는 파일 중 MessageHeader.java 내부에 다음과 같은 문제를 발생 시킨다. 문제의 원인은 원래의 OMG IDL 명세에서 발생하는 것(OMG IDL의 내용을 수정하여서는 안됨)으로 이것은 컴파일러의 오류라고 볼 수 있으나 현재는 수작업에 의하여 교정하였으며 이후의 시스템에서는 컴파일러 또는 ORB의 Java 클래스를 수정할 예정이다.

module GIOP {

. . .

struct MessageHeader {

char magic[4]:

version GIOP_version;

boolean byte_order;

octet message_type;

unsigned long message_size;

}

...

};

GIOP 내부의 다른 Java 파일인 MessageHeadercharArray4.java에서는 MessageHeader가 아닌 MessageHeadercharArray4를 요구하고 있으며 이것은 다시 ORB 모듈내의 NetData.java에서 동일한 지명을 요구한다. 다음의 diff 명령어에 의한 결과에서는 원래의 파일(*.java.bak)과 수정된 파일(*.java)의 차이점을 나타내고 있다.

% diff MessageHeader.java MessageHeader.java.bak

6c6

< public MessageHeadercharArray4 magic;

---

> public charArray4 magic;

11c11

< public MessageHeader (MessageHeadercharArray4 magic, GIOP.Version GIOP_version, boolean byte_order, byte message_type, int message_size) {

---

> public MessageHeader (charArray4 magic, GIOP.Version GIOP_version, boolean byte_order, byte message_type, int message_size) {

28c28

< this.magic = (GIOP.MessageHeadercharArray4) Class.forName(

"GIOP.MessageHeadercharArray4").newInstance();

< this.magic = (GIOP.charArray4) Class.forName(

"GIOP.charArray4") .newInstance() ;

이와 유사한 오류가 NamingContextStub.java 및 NamingContextSkeleton.java에서도 발생하고 있다. 원래 이 두 개의 파일은 OMG IDL의 GIOP 모듈의 일부에서 생성되는 NamingContext.java에서 이 파일을 javac 컴파일러를 이용하여 생성된 NamingContext.class를 다시 idl-to-java 컴파일러를 이용하여 출력된 스텁, 스켈리턴 파일이다. 그러나 IDL 컴파일러에서 생성되는 모든 스텁, 스켈리턴에서 기본적으로 NAME.NameStub 및 NAME.NameSkeleton에서 상속 되도록 정의되어 있기 때문에 직접 ORB.Stub 및 ORB.Skeleton에서 상속 되어야 할 경우 수정을 하여야 한다. 이 경우 컴파일러를 반드시 수정하여야 하는 이유나 요구사항도 사실상 불명확하다. 또한 원래의 원시 파일에서는 이 부분이 수정되어 있으나 컴파일러에 의하여 그러한 상태로 생성시키기는 불가능 하였고 인위적인 수정이 이루어진 것 같으나 문서로 명확이 언급되어진 부분은 없었다.

NamingContextStub.java

//

// Written by Iorb 스텁/Skeleton compiler

//

package Iorb.NAME;

import Iorb.*;

// public class NamingContextStub extends Iorb.NAME.NameStub

implements NamingContext { // IDL 컴파일러 생성시

public class NamingContextStub extends Iorb.ORB.Stub implements

NamingContext { // 수정시

···

NamingContextSkeleton.java

//

// Written by Iorb 스텁/Skeleton compiler

//

package Iorb.NAME;

import java.io.*;

import java.net.*;

// public class NamingContextSkeleton extends Iorb.NAME.NameSkeleton {

// IDL 컴파일러 생성시

public class NamingContextSkeleton extends Iorb.ORB.Skeleton {

// 수정시

···

5. 익셉션의 수정사항

OMG의 CORBA 사양에서는 익셉션의 정의가 매우 단순하게 되어있다. 기본적으로 NO_EXCEPTION, USER_EXCEPTION, SYSTEM_EXCEPTION의 3단계로 구분되어 있고 USER 및 SYSTEM 익셉션에서 세부사항을 분리하여 정의하도록 되어있다. 이것은 특히 지명부분에서 세밀하게 구분하여야 하는데 원래의 사양은 물론 Orbix, OrbixWeb, 또는 VisiBroker와 같은 상용 CORBA 시스템에서도 다양한 익셉션이 정의되어 있지 못하다. 익셉션의 많고 적음에 따른 장단점에는 많은 논쟁이 있으나 정확한 익셉션의 정의는 응용 프로그램을 안정적으로 동작하게 하는데 필수적인 것이다. 그러나 필요없는 중복 정의(예를 들어서 완전히 동일한 자손 익셉션으로 상속되었을 때)의 경우에는 개발자의 프로그램 환경을 복잡하게 한다.

원래의 JacORB에서는 불필요한 익셉션이 중복 정의 되어있다. 이것은 Naming 및 ORB에서 익셉션 클래스를 정의하는데 나타나 있으며 실험 시스템에서는 이러한 부분은 삭제 또는 수정하여 정의하였다. 여기서 명확히 고려하여야 할 점은 구현하는 언어의 익셉션 수준이다. 즉, Java를 이용할 경우 익셉션의 정의가 매우 정교하여 질 수 있다. C 또는 C++의 경우 언어 수준에서 제공하는 익셉션이 양적이나 질적인 면에서 다소 제약을 갖고 있다면 Java의 경우 매우 풍부한 익셉션을 보유하고 있는 언어라고 말 할 수 있다. 따라서 Java 자체에 정의되어 있는 익셉션을 적절히 이용하면 Java ORB의 구현에 유용하게 이용할 수 있다.

6. 메소드 내용상의 수정사항

JacORB에서는 다음과 같은 구현의 오류가 있다. 원래의 파일에서는 Java의 특성을 충분히 이용하지 못하였다고 보여지며 다음과 같이 수정하였다. 이러한 내용은 ORB를 구성하는 클래스의 여러군데에서 나타나고 있는데 여기서는 대표적인 것으로 한가지만 기술하였다.

원래의 파일: ParsedIOR.java

protected void decode( IOP.IOP _ior) {

···

Line 48 ∼

try {

ByteArrayOutputStream bos = new ByteArrayOutputStream();

ObjectOutputStream out = new ObjectOutputStream(bos);

boolean endianness = false;

out.send_object(endianness);

_ior.send(out);

byte bytes[] = bos.toByteArray();

// External.dumpBA(bytes);

StringBuffer sb = new StringBuffer("IOR:");

for (int j=0; j<bytes.length; j++)

{

int b = bytes[j];

if(b<0) b+= 256;

int n1 = b / 16;

int n2 = b % 16;

int c1 = (n1<10)?('0'+n1):('a' + (n1-10));

int c2 = (n2<10)?('0'+n2):('a' + (n2-10));

sb.append((char)c1);

sb.append((char)c2);

}

···

----------------------------------------------

Line 97 ∼

protected void parse( String object_reference ) {

try {

if (object_reference.indexOf("IOR:")==0)

{

ior_str = object_reference;

ByteArrayOutputStream bos = new ByteArrayOutputStream();

int cnt = (object_reference.length()-4) / 2;

for(int j=0; j<cnt; j++)

{

char c1 = object_reference.charAt(j*2+4);

char c2 = object_reference.charAt(j*2+5);

int i1 = (c1 >= 'a') ? (10 + c1 - 'a') :

((c1 >= 'A') ? (10 + c1 - 'A') : (c1 - '0'));

int i2 = (c2 >= 'a') ? (10 + c2 - 'a') :

((c2 >= 'A') ? (10 + c2 - 'A') : (c2 - '0'));

bos.write((i1*16+i2));

}

수정된 파일: ParsedIOR.java

protected void decode(IOP.IOR _ior) {

Line 83 ∼

try {

ByteArrayOutputStream bos = new ByteArrayOutputStream();

ObjectOutputStream out = new ObjectOutputStream(bos);

boolean endianness = false;

out.send_object(endianness);

_ior.send(out);

byte bytes[] = bos.toByteArray();

StringBuffer sb = new StringBuffer("IOR:");

for (int j = 0; j < bytes.length; j++) {

int b = bytes[j];

if(b < 0) b += 256; // b is decimal number

String c = (b<16)?('0' + Integer.toHexString(b)) :

(Integer.toHexString(b));

System.out.printIn("IOR(c) is: " + c);

sb.append(c); // c is Hex in two digit

"XX"

}

···

----------------------------------------------

Line 113 ∼

protected void parse( String object_reference ) {

try {

if (object_reference.indexOf("IOR:")==0) {

ior_str = object_reference;

ByteArrayOutputStream bos = new ByteArrayOutputStream();

int cnt = (object_reference.length()-4) / 2;

for(int j = 0; j < cnt; j++) {

char c1 = object_reference.charAt(j*2 + 4);

char c2 = object_reference.charAt(j*2 + 5);

// Hex -> Int

int i1 = Character.digit(c1, 16);

int i2 = Character.digit(c2, 16);

bos.write((i1*16 + i2));

}

Java를 이용한 개발에서 주의하여야 할 점은 Java의 클래스 및 메소드 구조가 아직 완전히 정의되지 않은 부분이 많이 있기 때문에 개발자가 적절한 메소드를 찾아내는 것이 어렵다. 예를 들어서 형 변환의 경우 char로 정의된 것과 string으로 정의된 문자를 각각 정수형 변수로 변환 시킬 경우 사용되는 클래스 및 메소드에서 일관성을 찾기 힘들다. char에서 int로 변환 시키는 경우 Charater 클래스의 digit 메소드를 사용하지만 string에서 int의 경우 Integer 클래스의 valueOf 메소드를 사용한다. 따라서 이와 유사한 비정렬 구조체는 개발자를 매우 당황하게 하는 점이다. 아직까지 Java 언어는 다른 언어와 마찬가지로 상당한 수준의 개발 경험을 필요로 한다.


제6장 결론

전기통신망, 컴퓨터통신망, 사설망 등이 인터넷으로 통합되고 이를 효율적으로 이용하기 위하여는 서비스 제공자, 이용자, 망 관리자, 시스템 관리자 등을 포함하는 인터넷 기반 관리 구조가 제공되어야 하며 이는 폐쇄된 환경에서 제한적인 자원만을 관리하는 기존의 관리 기능은 관리 대상이 동적으로 변하는 인터넷 환경에서는 그대로 적용할 수 없고 더 나아가 인터넷이 분산 객체 환경으로 전이(轉移)됨에 따라 컴퓨팅 자원(프로그램, 서비스, 시스템, 망 등)을 분산 객체로 나타내고 이를 관리하기 위한 객체관리 기술이 필요하게 되었다.

본 사업은 1997년 1년간 수행되었고 연구 목표는 인터넷 환경에서 컴퓨팅 자원(프로그램, 서비스, 시스템, 망 등)을 분산 객체로 나타내고, 분산 객체를 효율적으로 관리하기 위한 객체 관리 기술을 연구하며 객체 관리 기술을 적용한 인트라넷용 시스템 관리 프로그램을 구현하는 것으로 되어 있다.

●인터넷 객체관리 기술

기존의 관리 기술은 관리 대상을 시스템과 망으로 한정하였고 일부 제한된 응용 서비스를 제한된 방법으로 제한된 영역에서 관리하였으나 분산 객체 환경에서는 관리 대상이 시스템, 망 뿐만 아니라 응용 서비스, 프로그램 등에 이르기까지 다양하게 구성된다. 특히 분산 객체 기반에서는 분산 객체 컴퓨팅을 가능하게 하는 기본 기능과 연계되어서 관리 기능이 구현되어야 하고 이러한 요구 사항을 반영한 CORBA 기반 응용 서비스 구조를 분석, 설계하고 관리 시스템을 구현, 시험을 하였다.

●객체 중개자 기술

객체 중개자 부분은 CORBA 2.0를 만족하고 multimedia audio/video stream을 지원하는 iORB를 설계완료하고 일부분을 Java 구현하였다. IDL-to-Java compiler로 OMG IDL-to-Java 규격(안)을 IIOP 역시 CORBA 2.0를 지원하도록 설계, 구현하였다. 또한 객체 중개자가 수행되는데 필요한 information repository 및 객체관리 프로그램에서 사용할 정보 저장 시스템으로 객체 관리 정보 저장 시스템을 구현, 시험하였다. 나아가 객체 중개자를 이용한 응용 서비스로서 전자 투표 시스템을 구현하고 시험하였다.

●객체 관리 공용 서비스 기술

객체 관리 공용 서비스로서는 CORBAServices의 여러 공용 서비스 중에서 분산 객체 컴퓨팅 환경을 이용할 때 가장 기본 기능으로 간주되는 4개의 서비스, 객체 찾기/사건/타이밍/생명주기 서비스를 구현하고 시험하였다. 아울러 이들 각각의 서비스는 객체 관리에만 사용되는 것이 아니라 해당 기능을 필요로 하는 경우에는 별도로 사용할 수 있도록 Java 클래스로 구현, 시험하였다.

●초기 검증물 구현

인트라넷용 시스템 관리 프로그램의 초기 검증물로서는 시스템 관리를 대상 분야로 정하였고 특히 인트라넷에 속하여 있는 시스템을 대상으로 하였다. 기능으로는 오류 발생 여부, 구성 상태, 트래픽 상태 등을 기본으로 보여 주도록 하고 사용자 인터페이스로는 Web에서 Java의 Management API(Application Programming Interfacc)를 기본으로 하여 필요하되 없는 기능은 독자적인 Management API를 클래스로 정하여서 이용하였다. 또한 가장 기본적인 기능과 Pure Java로 구현하였기에 시스템 종류에 관계없이 어디서나 수행될 수 있으므로 기존의 라우터 업자들이 기본 소프트웨어로 제공하되 자기 회사 제품에서만 수행되는 단점을 제거하였으므로 널리 사용될 것으로 예상한다.

1998년 4월에 사업 설명회를 통하여 "인트라넷용 시스템 관리 소프트웨어" 설명회를 개최하고 기술 전수하여 상품화를 추진한다. 또한 1998년도 10월경에 Web Browser에서 기본으로 제공되는 소프트웨어로 추진하여 인트라넷 구축 시에 별도의 추가 비용 없이 활용할 수 있도록 할 예정이다.

인터넷 기반 분산 객체 관리 기술 개발 사업을 통하여 우리나라의 취약한 분산 객체 컴퓨팅 분야의 기반 기술을 획득할 것으로 전망하고 선진국에서 집중적으로 투자하여 개발 중인 분산 객체 기반 시스템 관리 기술을 보유하게 될 것이다. 아울러, 지금까지 선진국이 독점하고 있는 분산 객체 기술 분야에서 기술적인 종속 관계를 탈피하여 우리나라의 독자적인 소프트웨어 개발 기술을 가지게 되고, 다른 소프트웨어 기술의 개발 분야에 비약적인 발전을 가져올 수 있다.

인터넷은 향후 모든 정보 처리에 관한 기반이 될 것이며 나아가 향후 사용자 환경은 분산 객체를 기반으로 한 환경이 예상된다. 이에 대비하기 위해서 분산 객체를 효율적으로 관리할 수 있는 관리 기술과 이를 지원하는 분산 객체 기본 기술을 계속하여 개발하는 것이 절실히 요구된다.


참고문헌

[1] ISO,"System Management Overview",ISO/IEC 10040

[2] ISO,"Basic Reference Model:Management Framework,"ISO/IEC 7498-4

[4] "Web-based Enterprise Management Specification,"http://wbem.freerange.com/

[5] "Java Management API Specification,"http//java.sun.com/products/JavaManagement/

[6] "Java Management API User Interface Style Guide,"http//java.sun.com

products/JavaManagement

[7] "Java Management API Online Programmer's Reference Manual",

"http//java.sun.com/products/JavaManagement/

[8] Robert Orfali & Dan Harkey,"Client/Server Programing with Java and CORBA,"John Wiley & Sons,Inc., 1997

[9] Object Management Group,"CORBA:Object Management Architecture Guide,"OMG, 1993.

[10] Object Management Group,"The Common Object Request Broker:Architecture and Specification Revision 2.0,"OMG, July 1995.

[11] Object Management Group,"CORBAservices: Common Object Services Specification,"OMG 95-3-31, 1995.

[12] Object Management Group,"IDL/Java Language Mapping,"OMG TC Document orbos/97-03-01, March 19, 1997.

[13] Richard Mark Soley, Christopher M. Stone, "Object Management Architecture Guide Revision 3.0,"OMG, June 13, 1995.

[14] Andrew Watson Ed.,"IDL type Extensions RFP,"OMG Doc.No.95-1-35, 1995.

[15] Jon Siegel,"CORBA:Fundamentals and Programming,"OMG, John Wiley & Sons, Inc., 1996.

[16] IONA,"OrbixWeb for Java: Programming Guide,"IONA, 1997.

[17] IONA,"OrbixTalk White Paper:The CORBAservice Event Service,"IONA Technologies, Ltd., 1996.

[18] Douglas C. Schmidt, Steve Vinoski,"Object Interconnections: Overcoming Drawbacks in the OMG Event Service(Column 10),"SIGS C++ Report Magazine, June 1997.

[19] Andreas Vogel, Keith Duddy,"Java Programming with CORBA,"John Wiley & Sons, Inc., 1996.

[20] Gerald Brose,"JacORB-A Java Object Request Broker,"Technical Report B 97-2, Freie University, April 1997.

[21] Yvan Peter,"An Implementation of CORBA's LifeCycle Service", IEEE Computer Society, Proceedings of First Imternational Workshop of Enterprise Distributed Object Computing, pp. 111-117, 1997.

[22] PowerBroker,"CORBAplus for C++: Programmer's Guide,"Expersoft Corporation, 1997.

[23] "IIOP Engine 개발에 관한 연구," 최종연구보고서, 한국전자통신연구원, 1997.11.30.

[24] "IDL-to-Java 컴파일러 개발에 관한 연구," 최종연구보고서, 한국전자통신연구원, 1997.11.28.

[25] "객체 관리 정보 저장 시스템의 개발에 관한 연구," 최종연구보고서, 한국전자통신연구원, 1997.11.27.

[26] "객체 중개자 응용에 관한 연구," 최종연구보고서, 한국전자통신연구원, 1997.11.28.

[27] "인터넷 응용 서비스 관리 기술에 관한 연구," 최종연구보고서, 한국전자통신연구원, 1997.11.30.

[28] 김현규 외 4명,"CORBA 개방형 분산 환경을 위한 공유 객체 명세 언어의 설계," 제24회 정보과학회 춘계 학술발표논문집, pp.529-532, 1997.4.

[29] 문기영, CORBA 기반 분산 객체 컴퓨팅, 정보처리학회지 제 2 권 제 1 호, 1995.3


약 어 표

약어 의 미

ACL Access Control List

AP Application Program

ARM Administration Runtime Module

AVM Admin View Module

BOA Basic Object Adapter

BUI Browser User Interface

CIM Common Information Model

CORBA Common Object Request Broker Architecture

CUP Constructor of Useful Parsers

DCE Distributed Computing Environment

DII Dynamic Invocation Interface

DSI Dynamic Skeleton Interface

EVS Electronic Voting System

GIOP General Inter-ORB Protocol

HMMP Hypermedia Management Protocol

HMMS Hypermedia Management Schema

HMON Hypermedia Object Manager

HTTP Hypertext Transfer Protocol

IDL Interface Definition Language

IIOP Internet Inter-ORB Protocol

iORB Internet Object Request Broker

ISO International Standards Organization

ITU International Telecommunication Union

JDBC Java Data Base Connectivity

JDK Java Developer's Kit

JMAPI Java Management Application Programming Interface

JVM Java Virtual Machine

MO Managed Object

MOF Managed Object Factory

ODP Open Distributed Processing

OI ORB Interface

OMA Object Management Architecture

OMG Object Management Group

ORB Object Request Broker

OSF Open Software Foundation

RMI Remote Method Invocation

SII Static Invocation Interface

SNMP Simple Network Management Protocol

SSI Static Skeleton Interface

TCP/IP Transport Control Protocol/Internet Protocol

TINA Telecommunication Intelligent Network Architecture

UDP User Datagram Protocol

UTF Unicode Transfer Format

WBEM Web-Based Enterprise Management


부 록

부록1. 연구 결과물 목록

가. 기술 문서

순번

제 목

등록일

작성자

1

인터넷에서 트레이드 서비스를 이용한 휴대형 분산 객체 시스템

97.1.17.

유인원

2

Java 환경과 CORBA 환경로부터 연동하는 분산 컴퓨팅 플랫폼

97.1.17.

이근영

3

웹에서 트랜잭션과 멀티미디어 응용의 통합

97.2.26.

유인원

4

웹과 CORBA 상호 운용 방법에 대한 분석

97.3.21.

이근영

5

Intercommunication between CORBA and DCE through Bridge

97.4.24.

김동진

6

상용 자료를 멀티미디어 응용에서 통합 접근하는 방법

97.7.24.

유인원

7

iCom:Audio/Video Stream Transfer Modules in iORB

97.9.25.

이근영

8

CORBA에서 오디오/비디오 스트림 전송 모듈 설계

97.10.17.

이근영

9

iORB에서 RTP를 이용한 오디오/비디오 스트림 전송방법

97.11.20.

이근영

나. 연구 보고서

순번

제 목

등록일

작성자

1

CORBA/DCE 사이의 on-demand Bridge의 설계 및 구현

97.1.9.

김동진

2

인터넷 기반 객체 관리 기술개발 사업 수행 계획서

97.2.14.

남궁한

3

인터넷 기반 객체 관리 기술개발 사업 수행 계획 요약서

97.2.14.

남궁한

4

Andrew File System(AFS) 설치 지침서

97.7.11.

김동진

5

CORBA Programming(C++)의 환경

97.7.11.

김동진

6

CORBA Programming(Java)의 환경

97.7.11.

김동진

7

객체 공용 서비스 개략 설계서 (생명주기)

97.7.18.

유인원

8

객체 공용 서비스 개략 설계서 (시간)

97.7.18.

유인원

9

객체 공용 서비스 개략 설계서 (사건)

97.7.18.

유인원

10

객체 공용 서비스 개략 설계서 (찾기)

97.7.18

유인원

11

인트라넷용 시스템 관리 기술 동향 분석서

97.7.24.

유인원

12

인트라넷용 시스템 관리 요구 사항 정의서

97.7.24.

유인원

13

A CORBA-based Management Framework for Distributed Multimedia Services and Appls.

97.7.31.

김동진

14

Design and Implimentation of Bridge between CORBA and DCE

97.7.31.

김동진

15

A Bridge for Heterogeneous Communication between CORBA and DEC

97.10.22.

김동진

다. 프로그램

순번

제 목

등록일

작성자

1

CORBA/DCE 상호 연동 S/W 생성기

97.1.17.

김동진

2

CORBA/DCE 상호 연동 S/W 전처리기 (Preprocessor: Parser)

97.1.17.

김동진

3

CORBA/DCE 상호 연동 S/W 정수형 변수 호출 시험 프로그램

97.1.17.

김동진

4

CORBA/DCE 상호 연동 S/W "Enum" 시험 프로그램

97.1.17.

김동진

5

CORBA/DCE 상호 연동 S/W 은행 업무 Demo 프로그램

97.1.17.

김동진

라. 논문

1) 국제 논문

순번

논문 제목

게재/

발표처

거재/

발표일

대표저자

1

Intercommunication Between CORBA and DEC through Bridge

PDPTA'97

97.7.1.

김동진

2

Integrating Multimedia Applications with Transaction Processing in Web

ICT'97

97.4.2.

남궁한

3

An Integrated Approach to Legacy Data for Multimedia Applications

EURO

MICRO'97

97.9.3.

남궁한

4

Design of Audio/Video Stream Transfer Module in CORBA

ICOMT'97

97.10.30.

이근영

마. 특허

순번

구분

발명의 명칭

접수일

발명자

1

국제 출원

원격 객체 메소드 호출에서 대리 객체의 전달 인수 처리 방법

97.10.20.

이근영

2

국내 출원

원격 객체 메소드 호출에서 대리 객체의 전달 인수 처리 방법

97.10.20.

이근영

3

국내 출원

분산 객체 시스템에서 원격 객체 생성 및 접근 방법

97.11.14.

유인원

부록2. 위탁 연구 및 공동 연구

분야

세부 연구 내용

기간

수행자

(수행기관)

위탁

연구

IIOP Engine 개발

97.3.1. -

11.30.

엄영익

(성균관대학교)

"

IDL-to-Java Compiler 개발

97.3.1 -

11.30.

정태명

(성균관대학교)

"

객체 관리 정보 저장 시스템 개발

97.3.1 -

11.30.

이희웅

(고려대학교)

"

객체 중개자 응용에 관한 연구

97.3.1 -

11.30.

최한석

(목포대학교)

"

인터넷 응용 서비스 관리 기술 연구

97.3.1 -

11.30.

홍원기

(포항공대)

공동

연구

객체 관리 공용 서비스 개발

97.3.1 -

12.31.

구자록

(울산대학교)

"

인트라넷용 시스템 관리

프로그램 개발

97.3.1 -

12.31.

김인호

((주)도화정보통신)