ObjectWeb 기반의 시스템 통합 기술

박재현 , 한상만

경기도 용인시 구성면 마북리 산1-1

현대정보기술(주) 정보기술연구소 데이타웨어하우징팀

E-mail : jhpark@shinbiro.com, smhan@shinbiro.com

URL :

http://www.shinbiro.com/~jhpark

Abstract:

현재 WWW(World Wide Web)을 기반으로 한 인터넷 서비스는 일대 변환기를 맞이 하고 있다. 웹클라이언트나 기타 인터넷 통신 서비스용 응용 프로그램 개발에서 컨텐트 서비스로 발전하고 있는 것이다. 특히 개발되는 컨텐트들도 기존의 CGI(Common Gateway Interface)나 BGI(Binary Gateway Interface)를 기반으로 한 데이타베이스 연동 컨텐트에서 기업의 사활이 걸린(mission-critical) 대규모의 엔터프라이즈 컨텐트들로 속속 전환되고 있다. 이러한 환경하 에서 기존의 CGI와 이의 보완 방법인 넷스케이프사의 NSAPI(Nestscape API)와 마이크로소프 트의 ISAPI(Internet Information Server API)같은 개발방식은 엔터프라이즈 컨텐트를 개발하는 데 있어 많은 문제점을 내포하고 있다. 이런 배경하에서 객체지향 패러다임을 근간으로 하는 CORBA(Common Object Request Broker)와 WWW의 통합환경은 앞선 방법들의 문제를 해결할 수 있다. 특히 인터넷 모빌 코드 패러다임을 제공해주는 자바 언어로의 CORBA 매핑은 WWW상에서 데이타웨어하우징과 같은 엔터프라이즈 컨텐트를 개발하는 데 많은 유연성을 제공해준다. 이 글에서는 CORBA, Java를 근간으로 한 WWW 통합 기술과 적용 방법에 대해 살펴본다.

Keywords:

CORBA , CGI , Data Warehousing , Java , Middleware , Object , WWW

1. 서론

인터넷, 특히 WWW의 폭발적인 성장은 소프트웨어 분야에서 글로벌 서비스라는 새로운 패러다임을 제시하였다. 이 패러다임은 기존의 응용 서비스들의 서비스 제공범위를 소규모 LAN환경하에서 전세계를 근간으로 한 글로벌 서비스로의 확장을 의미한다. 글로벌 서비스는 현재의 정보시스템에서 요구하고 있는 패러다임이다. 왜냐하면 현재의 기업 환경은 국가와 국경을 초월한 글로벌 경영과 조직으로 발전하고 있기 때문이다. 따라서 이런한 환경변화에 능동적으로 대처하기 위해 글로벌 환경을 지원하는 새로운 형태의 정보 관리 시스템이 필요하게 된다. 다음은 현재의 환경에서 필요로 하고 있는 정보 시스템의 모습이다.

"정보 시스템은 조직이나 기관의 정보처리 과정과 경영 철학을 지원함에 있어 지리적으로 분산되고 이종인 정보 자원을 보다 쉽고 , 안정되고, 일관된 방법으로 관리해야 한다.[jhpark96] "

이러한 정보 시스템은 다음의 기능들을 보장해야 한다.

사용자 인터페이스 측면에서 사용하기 쉬워야 하고 직관적으로 사용가능해야 한다. 또한 사용자의 요구사항에 따라 적절히 원하는 정보를 선택적으로 취합할 수 있는 기능들을 제공해야 한다. 또한

시스템 측면 에서 기존의 시스템들과 쉽게 통합되거나 통합할 수 있는 인터페이스를 지원해야 하며 기존의 시스템보다 빠르거나 최소한 동등한 성능을 보장해야 한다. 아울러 시스템과 정보에 대한 모든 접근과 통일된 방법으로 관리되며 합법적이어야 한다.

정보 측면 에서 기업의 생산 활동을 지원할 수 있는 신선한 정보가 지속적으로 공급되고 해당 정보를 적절히 가공하기 위한 응용 서비스가 지원돼야 하며 , 정보 자체의 안정성과 무결성을 보장해야 한다. 마지막으로

기업 측면 에서는 해당 정보 시스템은 조직의 변화에 능동적으로 재구성가능하며 해당 조직의 환경이나 문화에 적합하게 구축, 운영돼야 하며 글로벌 네트웍 환경을 지원해야 한다.

이러한 시스템을 구축하기 위한 각 분야의 노력들은 다음과 같다.

먼저 시스템 측면에서 이종의 다양한 시스템을 쉽게 통합하고 이들을 일관된 방법으로 개발하기 위한 노력으로 다양한 미들웨어 솔루션을 들 수 있다[orfali96][tresch96]. 초기 대부분의 정보시스템은 메인프레임을 중심으로 한 중앙집중방식이었다. 이 방식은 중앙의 시스템에 모든 작업이 집중되는 문제를 초래했다. 따라서 이 방법을 채택한 곳에서는 중앙 시스템으로 값비싼 IBM 호스트같은 대형 컴퓨터를 사용해야만 했다. 그러나 기하급수적 으로 증가하는 클라이언트의 요청을 해결하기 위해서는 계속적으로 중앙의 대형시스템을 늘려야만 했다. 이러한 문제들을 해결하고자 제안된 방법이 일정하게 작업을 분배하여 협동하는 시스템 모델인 분산 컴퓨팅 시스템이다. 분산 컴퓨팅 시스템은 대형 컴퓨터를 이용하지 않고 유닉스같이 대형 컴퓨터에 비해 상대적으로 값이 싼 중형 컴퓨터들에게 일을 적절히 분배하여 활용함으로써 많은 효과를 얻었다. 이러한 분산 컴퓨팅 시스템을 구성하는 대표적인 기술적 방법이 클라이언트/서버 기술이다. 이 방법은 상대적으로 많은 클라이언트 들이 서버의 자원을 쉽게 공유할 수 있으며 네트웍을 기반으로 하기 때문에 적정 규모로 시스템을 구성할 수 있는 장점들이 있다. 그러나 이 방식 역시 수많은 이종의 시스템을 처리하는 데 있어 많은 문제들을 내포하고 있다. 특히 서로 다른 종류의 시스템을 추가할 때마다 새로운 인터페이스를 작성해야 만 한다. 예를 들면, 서로 다른 N개의 클라이언트와 M개의 서버를 연결하기 위해서 프로그래머는 N X M 개의 인터페이스를 작성해야만 한다. 이러한 단점들을 극복하고자 나온 해결책이 바로 미들웨어 방법이다. 미들웨어는 클라이언 트와 서버사이에 비지니스 로직을 처리해주고 클라이언트에게 서버에 대한 통일된 인터페이 스를 제공한기 때문에 다단계 클라이언트/서버 구조라고도 한다. 미들웨어 구조를 사용하여 구축된 정보시스템은 다양한 정보시스템을 하나의 인터페이스를 통해 처리할 수 있으며 정보시스템의 로직을 구조적으로 추상화시킬 수 있기 때문에 많은 유연성을 제공한다. 일반적으로 미들웨어에는 DBMS 서버들을 중앙에서 관리해 주는 DBMS미들웨어와 서버사이의 트렌젝션과 로드발랜싱을 적절히 지원해주는 OLTP 미들웨어, 객체지향 패러다임을 통해 통합 시스템을 구축하게 해주는 CORBA[OMG96]가 있다. 현재 이들 솔루션은 많은 기업의 정보시스템을 구축하는 데 적용되고 있다.

또한 정보측면에서는 분산된 기업의 데이타베이스들을 적절히 통합하여 기업의 의사결정을 비롯하여 각종 중요 결정사항에 이용하게 해주는 데이타웨어하우징 기술이 확산되고 있다[inmon81]. 기존의 단순한 데이타 처리위주에서 보다 적극적으로 정보를 가공하려는 노력이 바로 데이타웨어 하우징이란 구축 방법론으로 표출된 것이다. 그러나 현재 이 방법 역시 실시간 데이타의 반영여부와 기존의 데이타들과 데이타웨어 하우스상에 있는 데이타 사이의 불일치및 유지 보수상의 문제점들을 내포하고 있다 [jhpark97] [tresch96].

기업의 측면에서는 정보의 데이타웨어하우징화와 아울러 기업 조직의 글로벌화와 급속한 리엔지니어링에 적합한, 규모조정 가능한 시스템의 구축이 필요하다. 이러한 대표적인 노력은 WWW 또는 인터넷 기술을 기반으로 한 인트라넷과 익스트라넷 기술이다. 인트라넷은 기존의 기업 업무와 정보 시스템을 인터넷 기술, 특히 WWW 기반으로 재구축하는 것을 말하며 익스트라넷은 인트라넷의 규모와 범위를 전세계로 확장한 것을 의미한다. 이러한 기술의 기반에는 WWW의 안정성과 아울러 Java같은 인터넷 엔지니어링 언어의 확산을 들 수 있다.

이들 노력들은 개별적으로 경주되는 것은 아니다. 실제 목표 시스템을 구축하기 위해서는 다양한 측면에서 개발되는 기술들을 통합해야 한다. 이 통합기술은 현재 WWW과 CORBA , 그리고 Java를 기반으로 하여 비지니스 솔루션을 개발하는 것으로 모아지고 있다[ashley96] [almasi96] [beitz95] [condict96] [merle96]. 비지니스 솔루션에는 기존의 데이타웨어하우징을 비롯하여 인사,회계 시스템처럼 기업의 다양한 정보 시스템을 포함하고 있다.

본 글에서는 향후 정보 시스템 구축시 근간이 될 WWW와 CORBA 그리고 Java의 통합기술인 ObjectWeb에 대해 살펴본다.

2. 관련 연구

2.1 WWW의 개발 환경

정보시스템의 근간 기술로서 자리매김하고 있는 WWW은 안정된 프로토콜을 기반으로 다양한 요구사항들을 수용하고 기존의 시스템들을 통합하며 발전해오고 있다. 1994년 초기 WWW은 HTTP(Hyper Text Transfer Protocol)과 하이퍼텍스트 인터페이스를 기반으로 텍스트나 이미지, 오두토콜로는 지속적인 상태정보를 유지하지 못한다는 데 기인한다. 웹 클라이언트와 서버사이에는 기껏해야 한번의 요청과 이에 대한 서비스 제공이 이루어지며 이후의 요청은 새로운 세션으로 설정되기 때문에 웹 클라이언트와 서버사이에 지속적인 트렌젝션을 유지하지 못한다. 이 단점은 기업에서 요구하는 대규모의 시스템을 구축을 불가능하게 한다[그림1].

[ 그림1 ] CGI를 통한 웹 개발 환경

壙握賦灌지속적인 상태정보를 유지하지 못한다는 데 기인한다. 웹 클라이언트와 서버사이에는 기껏해야 한번의 요청과 이에 대한 서비스 제공이 이루어지며 이후의 요청은 새로운 세션으로 설정되기 때문에 웹 클라이언트와 서버사이에 지속적인 트렌젝션을 유지하지 못한다. 이 단점은 기업에서 요구하는 대규모의 시스템을 구축을 불가능하게 한다[그림1].

[ 그림1 ] CGI를 통한 웹 개발 환경

물론 이에 대한 보완책으로 쿠기(Cookies)라 불리는 방법이 있으나 안정성과 보안측면에서 많은 문제점을 내포하고 있다. 이 외에도 기존의 CGI방식은 해당 웹 클라이언트의 요청이 제출될 때마다 새로운 서버를 생성하고 이를 통해 서비스를 제공한다. 따라서 이 과정에서 발생하는 컨텍스 교환(Context Switing) 비용은 웹 클라이언의 요구가 많고 DBMS처럼 웹과 연동되는 응용 프로그램 서버가 큰 경우 기하급수적으로 증가한다. 이러한 문제점을 해결하고자 넷스케이프나 마이크로소프트 같은 WWW 서버 공급업자와 오라클이나 사이베이스, 유니SQL같은 DBMS 공급업자들은 그들 자신의 시스템과 WWW을 적은 비용으로 연계하기 위한 방법을 제공하고 있다. 그러나 이 방법역시 CGI 와 WWW서버 자체가 갖고 있는 한계를 벗어나지 못한다.

이러한 속에서 1996년 선마이크로시스템에서 개발한 자바라는 객체지향 인터프리터 언어는 기존의 WWW에 대화형 응용 프로그램을 추가하고 상태정보를 유지할 수 있는 가능성을 제시하였다[그림2]. 이 후, WWW는 자바의 이러한 장점을 받아들여 기존의 정적WWW에서 동적WWW으로 변환하기 시작한다. 이 시기의 동적WWW의 특징은 WWW 서버에 위치시킬 수 있는 애플릿이라는 코드와 이 코드를 자바가능한 웹 브라우져를 통해 다운로드 받은 후 이를 실행시킬 수 있는 모빌 코드 환경이다. 이후 , 1997년에 이르러 WWW는 기존의 자바 기술외에 하드웨어나 소프트웨어에 상관없이 응용 프로그램을 개발하고 다양한 개발 서비스를 이용하게 해주는 객체지향 미들웨어인 CORBA[OMG96]를 수용하게 되었다. 좀더 자세히 말하자면 CORBA의 표준 프로토콜인 IIOP(Internet Inter-ORB Protocol)와 WWW의 표준 프로토콜인 HTTP의 통합에 의해 WWW상에서 컴포넌트 서비스를 개발하기 위한 토대를 갖추게 된 것이다. CORBA외에도 JAVA의 콤포넌트 기술인 Java Beans나 마이크로소프트의 컴포넌트 기술인 ActiveX가 기존 WWW의 확장을 위해 적극 채택되고 있다. 이들을 묶어 동적 WWW라 한다.

[ 그림2 ] Java를 통한 웹 개발 환경

특히 이러한 기술중에서 WWW과 CORBA , 그리고 CORBA의 자바 매핑은 자바에서 제공하는 모빌 코드 기능과 CORBA에서 제공하는 객체 컴포넌트 기술을 적용하여 대규모의 기업 정보시스템을 기존의 WWW상에서 구축할 수 있게 해준다. 이렇게 구축된 정보 시스템을 CORBA 비지니스 객체라 하며 이러한 개발환경을 ObjectWeb 이라 정의한다[orfali97]. [그림3]은 앞서 설명한 WWW 개발 환경의 변화를 보여준다.

[그림3] WWW 개발 환경의 변화

3. ObjectWeb의 구조

3.1 CORBA와 WWW의 연동 현황

지금까지 CORBA와 WWW를 연동하기 위한 많은 선행 노력들이 있었다[ashley96] [almasi96] [beitz95] [condict96] [merle96]. 이들 방법은 크게 기존 시스템의 구조를 변경하지 않고 기능을 확장하는 방법과 시스템에 변형을 가해 연동하는 방법으로 분류할 수 있다.

전자의 경우, 기존의 CGI를 이용하여 게이트웨이를 구성하는 방법과 HTTP 프로토콜을 CORBA IIOP프로토콜로 변경해주는 게이트웨이를 구성하는 방법, 그리고 자바-CORBA 매핑 방법이 있다. CGI게이트웨이의 경우, 디지탈의 Web Broker에서 구현되었다. 이 방법은 여전히 CGI의 문제를 내포하고 있다. HTTP-to-IIOP의 경우 ANSA[ashley96]와 오라클에서 사용하고 있다. 이 방법은 CORBA가 HTTP를 처리하는 역할을 갖는 것을 의미한다.

마지막 방법은 기존의 HTTP와 CORBA를 공존시키는 것이다. 웹 클라이언트는 CORBA에 서비스를 요청하기 위한 ORB 기능을 갖고 있고 실행시에 서버측에 자바로 작성된 CORBA 응용 프로그램을 다운로드 받은 후 이를 수행시킨다. 이러한 애플릿을 ORBlet이라 한다. 이 방법은 추가적인 게이트웨이를 개발할 필요가 없다는 장점이 있다. 반면에 CORBA ORB기능을 자동으로 다운로드할 수 없기 때문에 웹에 내장해야 한다는 문제가 발생한다. 현재 넷스케이프와 Visibroker[visigenic], Orbix/Web[iona] , 선사의 NEO[joe][neo]등에서 사용하고 있다.

이 방법외에 시스템 변형을 통해 연동하는 방법은 CORBA IDL(Interface Definition Language) 컴파일러를 확장하여 해당 IDL 파일을 WWW에 적합한 코드로 생성해 주는 방법이 있다. 이 방법은 CORBA IDL을 그대로 사용할 수 있다는 장점이 있으나 CORBA 인터페이스마다 개별적인 FORM 문을 생성하기 때문에 대규모 시스템 개발에 부적합하다. 이 방법외에도 웹 서버를 확장하여 CORBA 서비스를 호출할 수 있게 확장하는 방법과 자바 애플릿이 CORBA상에서 상태정보를 유지할 수 있게 CORBA 프로토콜에 스트림 기능을 추가하도록 확장하는 방법이 있다[resnick96].

3.2 ObjectWeb의 정의

ObjectWeb이란 WWW에서 CORBA와 자바에서 제공하는 다양한 분산 서비스들과 객체지향 패러다임을 이용하기 위해, 시스템 변형없이, WWW에 CORBA를 통합한 환경을 말한다. 반대로 CORBA와 자바는 WWW에서 제공하는 안정된 전달 프로토콜(HTTP)과 웹브라우져로 지칭되는 통일된 클라이언트 인터페이스를 얻을 수 있다. ObjectWeb은 하나의 독자적인 시스템이 아니다. 단지 현재 분산 개발 환경을 선도하고 있는 기술들을 통합하여 상승효과를 얻는 방법이다. [그림4]는 ObjectWeb의 구성도이다. 먼저 ObjectWeb은 WWW의 HTTP와 CORBA의 IIOP를 기본 프로토콜로 사용하며 CORBA IDL로 작성된 인터페이스를 자바 언어로 매핑한다. 따라서 ObjectWeb을 통해 작성된 응용 프로그램은 자바 애플릿(또는 Orblet) 또는 순수 자바 응용 프로그램이 될 수 있다. 이렇게 작성된 ObjectWeb의 응용 프로그램은 WWW의 HTTP를 통해 전송되며 일단 전송된 응용 프로그램들은 CORBA의 IIOP를 통해 구동되며 서비스를 주고 받는다.

[그림4] ObjectWeb의 구성

4. ObjectWeb의 구성요소

ObjetWeb은 [그림4]에서 처럼 기본적으로 WWW와 CORBA , 그리고 자바로 이루어진다. 이번 장에서는 CORBA를 중심으로 각 구성요소에 대해 정리해 본다.

4.1 WWW

WWW는 기본적으로 URL(Uniform Resource Locator)라 불리는 질의 구조과 이에 대한 결과를 HTML라 불리는 멀티미디어 하이퍼 링크 문서로 보내는 구조로 이루어져 있다. 이때 전송은 HTTP라는 프로토콜을 이용한다. 이러한 기본 기능외에 CGI라는 외부 프로그램 인터페이스를 통해 외부 서비스와 연동하는 구조로 이루어져 있다[그림5].

[그림5] WWW의 구성

4.2 자바

자바는 초기 애플릿이라는 모빌 코드 개념을 웹 브라우져에 내장함으로써 WWW에 대화형 응용 프로그램 작성의 길을 제공해 주었다. 그러나 이 기능만으로는 WWW에 엔터프라이즈 규모의 응용 시스템을 개발하기에는 역부족이다. 따라서 선 마이크로시스템은 자바를 엔터프라이즈 환경에서 사용할 수 있도록 자바 데이타베이스 연동 패키지인 JDBC(Jaa Database connectivity) , 자바 RPC(Remote Procedure Call)인 RMI(Remote Method Invocation), 그리고 자바의 CORBA 지원 툴인 JAVA IDL, 자바OLE인 자바 Beans, 자바 커머스 프레임웍인 JavaWallet , 보안 프레임웍, 다양한 멀티미디어를 지원해주는 미디어 프레임웍등을 개발하고 있다. [그림6]은 자바에서 지원하는 서비스들을 정리한 것이다.

[그림6] Java의 서비스들

4.3 CORBA

1989년 4월, 현재 존재하는 객체 기술을 바탕으로 응용 프로그램들을 결합하기 위한 객체지향 표준을 제정하기 위해 OMG라는 비영리 단체가 탄생하였다. 이 단체에는 마이크로소프트를 포함하여 600개의 컴퓨터 관련 단체들이 참가하여 객체지향 기술을 기반으로 이종의 분산된 환경하에서 응용 프로그램들을 서로 통합할 수 있는 표준기술을 탄생시켰다. 바로 이 표준이 OMA(Object Management Architecture)이다. OMA는 응용 프로그램간의 결합뿐만 아니라 객체의 생성 , 소멸에서 부터 저장 , 트렌젝션 기능에 이르기까지 분산 객체 환경에서 필요한 모든 서비스를 총칭하는 것이다. 이들 기능중 CORBA는 컴퓨터 내부의 버스처럼 서로 다른 프로그램들 사이의 버스 역할을 하는 모듈로서 OMA 구조에서 가장 중요한 요소가 된다. 또한 CORBA에서 가장 중요한 요소는 ORB이다. [ 그림7 ] 은 OMG 에서 발표한 OMA 와 CORBA , ORB 를 포함관계로 표시한 것이다. 그림에서 처럼 CORBA 는 OMA의 한 부분이고 ORB는 CORBA 의 핵심기술을 말하는 것이다.

현재 OMG는 1990년 OMA를 발표한 이래 지금까지 CORBA2.0 스펙을 발표하였다.

[그림7] OMG , OMA , CORBA의 관계

4.3.1 OMG의 OMA

OMA는 [그림8]에서 보듯이 이종의 분산환경에서 필요한 모든 기능을 정의하기 때문에 상당히 광범위하다. 먼저 OMA를 이해하는 데 있어 가장 기초사항이 객체지향 개념의 이해이다. 왜냐하면 OMA가 제공하는 모든 서비스는 객체개념을 기반으로 하기 때문이다. 다음은 CORBA를 이해하는 데 필요한 객체지향 개념만을 모아 정리한 것이다.

객체 = 애트리뷰트 + 메소드

객체는 프로그램에서 데이타 형을 갖는 변수같은 애트리뷰트(상태)와 함수같은 메소드(행동)로 구성된 일련의 코드를 의미한다. 예를 들어 , 자동차란 객체는 바퀴와 핸들 등의 애트리뷰트를 갖을 뿐만 아니라 전진이나 후진 등의 메소드도 포함하고 있다.

클래스 = 객체들에 공통된 특성 , 객체는 클래스를 통한 생성물

클래스는 객체들이 가지고 있는 공통의 특성들을 모아 만든 틀을 의미한다. 따라서 이 틀을 통해 사용자는 원하는 만큼의 객체를 생성하거나 삭제할 수 있다. 예를들어, 자동차는 기존의 소나타나 엘란트라 , 엑셀같은 객체의 공통적인 특성을 뽑아만든 객체이다. 이러한 객체를 클래스라고 한다.

캡슐화(Encapsulation)

캡슐화는 객체를 구성할 때 애트리뷰트와 메소드를 함께 정의한 후, 해당 객체의 애트리뷰트에 접근하기 위해서는 미리 정의된 메소드만을 통해서 가능하게 하는 것을 말한다. 캡슐화는 다른 객체와 해당 객체를 추상적으로 구분할 수 있게 해준다. 따라서 고도의 모듈화와 추상화가 가능하다.

다중성(Polymorphism)

다중성이란 하나의 메소드 이름으로 여러 개의 서로 다른 기능을 제공하는 메소드로 만들 수 있는 기능을 의미한다. 예를 들어 , Insert( int ) , Insert( char* ) 처럼 같은 이름으로 서로 다른 기능을 수행하는 메소드를 작성할 수 있다.

상속, 상위 클래스, 하위 클래스

상속이란 한 클래스가 갖고 있는 애트리뷰트와 메소드를 특정 클래스가 물려받는 관계를 말하며 이때 물려주는 클래스를 상위 클래스 , 물려받는 대상이 되는 클래스를 하위 클래스라고 한다.

예를 들어 , 트럭같은 클래스는 자동차 클래스의 애트리뷰트와 메소드를 상속받을 수 있다. 왜냐하면 자동차는 트럭에 필요한 애트리뷰트와 메소드를 포함하고 있기 때문이다. 이때 자동차 클래스를 상위 클래스 , 트럭 클래스를 하위 클래스라고 한다.

OMA는 크게 이종의 분산 환경에서 통신을 담당하는 CORBA와 객체를 조작하는 데 필요한 각종 기본 기능들을 정의하고 있는 COSS (Common Object Service Specification) , 그리고 추가적으로 제공되는 기능 서비스가 존재하고 있다. 그리고 마지막으로 이들 기능들을 이용하여 사용자들이 작성한 각종 응용 객체들이 존재한다. 앞서도 언급했듯이 OMA 구조에서 가장 중요한 것이 CORBA이며 현재 수많은 구현 제품이 존재하고 있다. 그러나 실제 CORBA만으로는 복잡한 응용 프로그램을 작성하는 데 있어 충분한 기능을 제공하지는 못한다. 따라서 이들 필요한 기능을 모아서 만든 것이 COSS이다. 현재 CORBA 를 구현한 대부분의 제품은 이들 COSS기능을 제공하기 위해 많은 작업을 수행하고 있다. 일단 CORBA가 제공하는 이종의 분산기능은 다음 절에서 살펴보기로 하고 간략하나마 COSS 에서 제공하는 객체를 다루는 서비스들에 대해 살펴본다.

[표1] 1993년 COSS I 서비스 명	서비스 내용
생명주기(LifeCycle)	객체의 생성및 소멸 기능을 제공한다.
명명(Naming)	원하는 객체를 객체의 고유한 식별자가 아니라 이름으로 찾을 수 있도록 해준다.
사건전달(Event Notification)	특정한 작업을 수행하도록 원하는 사건을 등록하거나 삭제할 수 있다.
지속성(Persistence)	객체를 파일이나 데이타베이스에 저장하도록 해준다.

[표2]1994년 COSS II 서비스 명	서비스 내용
객체 관계(Relationship)	각 객체들사이의 관계를 정의하고 이 관계가 유지되도록 해준다.
객체 외형화(Externalizaction)	기존의 객체를 제거가능한 보조 기억장치 등에 저장하도록 해준다.
트렌젝션	트렌젝션을 요구하는 객체들 사이의 2단계 커밋( 2 Phase commit)기능을 제공한다.
동시성 제어	복 수의 메소드들에 의한 객체접근을 보장한다

[표3]기타 서비스들 서비스 명	서비스 내용
라이센싱	객체 사용에 대한 정당한 지불을 위해 객체의 사용에 대한 예측을 가능하게 한다.
객체 특성(Properties)	타이틀이나 날짜처럼 각 객체와 관련된 특성을 부여할 수 있다.
질의	관계형 데이타베이스 시스템의 SQL3나 객체지향 데이타베이스의 OQL 질의를 상위기능으로 객체에 대한 질의 기능을 제공한다.
트레이딩( Trading )	분산된 환경에서 각각의 객체가 제공하는 서비스의 종류에 대한 안내를 제공한다.

이들 서비스외에도 객체의 보안 , 시간 , 변화관리 , 데이타 교환에 관한 서비스가 정의되어 있다.

[ 그림8 ] OMA(Object Managemant Architecture)

4.3.2 OMA중 CORBA 1.2 의 이해

분산 객체 시스템을 위한 OMA 에서 CORBA는 가장 중추적인 역할을 한다. 다름아니라 CORBA는 분산 환경에서 객체간의 통신을 담당하기 때문이다.

4.3.2.1         CORBA 구성도

CORBA는 [ 그림9 ]와 같은 구조로 구성되어 있다. CORBA를 이해하는 데 있어 중요한 점은 CORBA는 서버라는 용어를 사용하지 않는다는 것이다. 왜냐하면 CORBA는 객체지향 개념을 바탕으로 하여 원격지의 클라이언트가 원격지에 있는 서버를 호출하는 것이 아니라 객체의 메소드를 호출함으로써 서비스가 이루어지기 때문이다. 따라서 CORBA 에서는 서버가 아니라 구현 객체( Object Implementation )라는 용어를 사용한다. 이때 고려해야 할 점은 사용자가 클라이언트와 구현 객체사이의 통신부분을 직접 관여해야 하는가에 대한 여부와 구현시 사용하는 프로그래밍 언어에 따라 각기 다르게 작성해야 하는가 하는 문제이다. 만약 그렇다면 사용자에게 너무 많은 짐을 지우는 셈이 된다. 이러한 점을 해결하고자 CORBA에서는 IDL이라는 표준언어를 제공한다. 뒤에 자세히 다루겠지만 사용자는 IDL을 사용하여 원하는 프로그램을 작성할 수 있다. 일단 작성된 IDL은 CORBA 에서 제공하는 IDL 컴파일러를 통해 컴파일된다. 이 결과 원하는 프로그램 언어로 작성된 클라이언트 코드와 구현 객체 코드를 얻을 수 있다.( 이 코드는 C나 C++ 또는 스몰토크처럼 사용자가 원하는 형태로 제공된다.) 이 코드들에는 통신을 위해 필요한 모든 기능이 자동적으로 포함된다. 따라서 사용자는 네트웍과 구현언어에 대한 걱정을 할 필요가 없다.

일단 CORBA의 클라이언트에는 클라이언트 스터브와 프로그램 수행시 원하는 메소드를 호출하는 동적 호출(Dynamic Invocation) 기능을 통해 구현객체를 호출할 수 있다. 일단 클라이언트의 호출이 발생하면 통신을 담당하는 ORB 기능을 통해 구현객체에게 전달된다. 이때 구현객체쪽의 객체 아답터(Object Adaptor)는 기본적으로 해당 객체를 호출가능하게 생성하고 원하는 호출에 해당하는 메소드를 실행시킨다. 일단 실행된 메소드에 의해서 처리된 결과는 다시 클라이언트에게 전달된다. 이 과정을 요약해서 보면 [ 그림10 ]과 같다. 클라이언트에 의해서 요청된 서비스는 CORBA를 통해 원격지의 구현객체에게 전달되고 구현객체에 의해서 처리된 결과는 다시 클라이언트에게 반환된다. 이때 호출시 전달되는 정보로는 호출시 대상이 되는 객체와 메소드 , 파라메터등이 있다.

[ 그림9 ] CORBA 구성도

[ 그림10 ]CORBA 클라이언트와 객체 구현사이의 통신

4.3.2.2 CORBA 호출 원리 이해

CORBA를 이해하는 데 있어 객체지향 개념이 가장 기본이 됨을 강조한 바 있다. 또하나 정확히 이해해야 할 것이 CORBA의 호출 원리를 이해하는 것이다. 먼저 CORBA 에서 서비스가 호출되는 원리는 [ 그림11 ]과 같다. 기존의 객체지향 코드에서는 메소드의 호출(Caller)가 이에 대한 호출 처리자(Callee)는 하나의 프로세스로 존재한다. 그러나 만약 메소드의 호출과 이에 대한 처리가 네트웍을 기준으로 양분된다면 어떻게 될까? 실제 이에 대한 대답은 간단하다. 먼저 호출하는 쪽 , 클라이언트에는 네트웍을 통해 서비스를 호출하고 이에 대한 결과를 전달받는 코드를 작성해 주고 호출 처리자측 , 구현 객체쪽에서는 네트웍상으로 전달되는 서비스 호출을 받고 이를 처리한 후 다시 클라이언트에게 전달해주는 코드를 작성해 주면 된다. 이러한 기능을 수행하는 코드를 전자는 스터브(Stub) , 후자는 스켈리턴(Skeleton)이라 한다.

실제 예로, 만약 구현 객체로서 Person이라는 C++ 클래스를 작성했다고 가정하자. 만약 클라이언트가 Person클래스의 getAge()라는 메소드를 호출할 때 이 호출은 클라이언트측 getAge()스터브를 통해 원격지의 스켈리턴으로 전달된다. 이 과정에서 스터브는 해당 메소드의 호출에 필요한 각종 정보를 네트웍으로 전달하기 위해 포장을 해야 한다. 이 포장된 메소드는 getAge()의 스켈로턴에 의해서 포장이 풀려지고 호출된다. 처리된 getAge()는 다시 네트웍을 통해 클라이언트 스터브에게 전달되기 위해 포장되고 전달된다. 클라이언트쪽의 getAge()스터브는 스켈리턴을 통해 넘겨받은 결과의 포장을 풀고 해당 결과값을 처리한다.

실제 이러한 과정을 통해 CORBA객체의 호출이 이루어진다. 이때 스터브와 스켈리턴을 위해 필요한 모든 기능의 코드는 CORBA에 의해서 자동적으로 제공된다.

[ 그림11 ] CORBA 호출 원리

4.3.2.3 CORBA 구성 요소 이해

다음은 CORBA의 각 구성요소들에 대한 설명이다.

CORBA 클라이언트 부분

CORBA 클라이언트는 구현 객체에 대한 서비스 요청을 담당한다. 이때 CORBA 클라이언트는 정적인 호출방법인 스터브를 사용하거나 동적 호출방법을 이용할 수 있다. 또한 ORB에서 직접 제공하는 기능을 이용하기도 한다. 다음은 각각의 부분에 대한 설명이다.

- 클라이언트 스터브

클라이언트 스터브는 정적 호출이라고도 한다. 왜냐하면 메소드 호출이 컴파일시 미리 결정되기 때문이다.

- 동적 호출

동적 호출은 실행중에 원하는 메소드를 동적으로 호출할 수 있는 기능을 의미한다. 이를 위해 CORBA는 인터페이스 저장소라는 데이타베이스에 해당 클래스의 모든 인터페이스를 저장해 두고 동적 호출이 수행될 때 이를 참조하여 해당 메소드를 수행한다.

- ORB 인터페이스

통신 기능과 메소드 호출등 ORB의 기본기능을 제공한다. 이 기능은 클라이언트와 구현 객체 모두에 적용된다.

[ 그림12 ] CORBA의 클라이언트 부분

CORBA 구현 부분

구현 객체는 스켈리턴을 통해 클라이언트의 서비스 요청을 처리한다. CORBA 구현 부분은 이 기능을 수행하기 위해 구현 스켈리턴 , 객체 아답타 , ORB 인터페이스로 구성되어 있다. 각각의 기능은 다음과 같다.

- 구현 스켈리턴(Implementation Skeleton)

구현 스켈리턴은 클라이언트의 서비스 요청에 대한 구현 객체를 직접 호출하는 역할을 한다. 이때 서비스 요청시 제공되는 정보를 해석하고 이를 구현 객체에 전달하며 처리된 결과를 포장하여 네트웍을 통해 클라이언트에게 전달한다.

- 객체 아답타(Object Adapter)

객체 아답타는 CORBA를 적용하려는 분야에 따라 다양하게 선택되어 사용되어 질수 있다. 가령, 데이타베이스가 필요하다면 데이타베이스 아답타를 사용할 수도 있다. 그러나 CORBA1.1에서는 기본적인 객체 아답타(BOA , Basic Object Adapter)만을 정의하고 있다. 위치적으로 객체 아답타는 구현 스켈리턴과 ORB에 위치한다. 따라서 객체 아답타는 구현 객체를 등록하거나 삭제하며 해당 구현 객체를 유일하게 관리한다. 또한 실제 메소드를 호출시키는 역할을 한다. 이처럼 구현 객체를 호출하기 위해서 모든 구현객체에 대한 정보를 구현 저장소(Implementation Repository)에 저장하고 이를 참조한다.

- ORB 인터페이스

클라이언트 부분에서 처럼 통신 기능과 메소드 호출등 ORB의 기본 기능을 제공한다.

[ 그림13 ] CORBA의 구현 객체 부분

인터페이스 정의어

IDL은 분산 환경에서 C , C++ , 스몰톡처럼 어떤 언어나 컴파일러등에 상관없이 CORBA 응용 프로그램을 작성할 수 있게 해준다. 다시 말해, 일단 IDL로 작성된 CORBA 응용 프로그램은 IDL컴파일러를 통해 원하는 프로그래밍 언어에 적합한 코드로 변환된다. 사용자는 이 코드를 이용하여 원하는 응용 프로그램을 작성하면 된다. 다음 [ 그림14 ]는 IDL의 역할을 잘 나타내 주고 있다. 현재 IDL은 표준으로 C 언어로의 매핑을 지원하고 있으나 많은 제품들은 C++과 자바 매핑도 지원하고 있다. 또한 스몰톡와 Ada , 코볼등 다양한 언어를 지원할 예정이다.

다음은 IDL의 특징을 정리한 것이다.

- 특정 프로그램언어와 컴파일러에 독립적이다.

- 다중 상속등 객체지향 개념을 지원한다.

- 구현을 위한 언어가 아니다. 즉, 프로그래밍 언어가 아니다.

- 동적 호출 메카니즘을 제공한다.

[ 그림14 ] IDL의 역할

실제로 다음은 IDL로 은행계정 클래스를 정의한 것이다. IDL언어는 실제 C++처럼 원하는 클래스를 interface라는 키워드를 사용 해서 선언할 수도 있으며 이 interface안에 애트리뷰트 와 메소드를 선언할 수도 있다. 아울러 각종 데이타 타입도 존재한다.

interface account

{

readonly attribute float balance;

readonly attribute string name;

void make_lodgement(in float f);

void make_withdrawal(in float f);

};

[ 예제 1 ] IDL로 작성된 account 인터페이스

실제 IDL에서 가장 기본이 되는 단위는 인터페이스(Interface)이다. interface는 애트리뷰트 와 메소드로 구성된다. 다음은 IDL의 사용문법을 간단하게 정리한 것이다. 대부분의 문법은 자바 구문과 아주 유사하다. 그러나 파라메터_타입의 경우 클라이언트와 구현객체 사이로의 이동 방향에 따라 in, out, input으로 선언할 수 있다. in의 경우 클라이언트에서 구현객체로, out은 구현객체에서 클라이언트로, inout은 양방향으로 이동이 가능한 파라메터를 의미한다.

[ 표4 ] IDL 사용 문법 인터페이스	:= INTERFACE { 메소드 | 애트리뷰트 }
메소드	:= 리턴타입 메소드 이름 ( 파라메터_타입 아규먼트)
리턴타입	:= void | boolean | ...
메소드 이름	:= 스트링
파라메터_타입	:= in | out | inout
type	:= int | boolean | float | ...
아규먼트	:= 스트링
애트리뷰트	:= [readonly] ATTRIBUTE 리턴타입 애트리뷰트_이름
애트리뷰트_이름	:= 스트링

인터페이스를 선언하기 위한 문법뿐만 아니라 IDL은 기본 자료형을 제공한다. 다음은 IDL로 사용가능한 기본 자료형들이다. 이 기본 자료형을 사용하여 작성된 인터페이스를 새로운 자료형으로 사용할 수 있다.

short, long, unsigned short, unsigned long, float, double, char,

boolean, octet, any, string, constant, struct, typedef, sequence,

arrays, exceptions, enum, union, contexts, inheritanc

정적 인터페이스 호출과 동적 인터페이스 호출

앞서도 잠시 언급했지만 CORBA는 클라이언트에게 2가지 서비스 호출방식을 제공한다. 하나는 정적인 방법이고 또 하나는 동적인 방법이다. 먼저 정적인 호출방법은 ORB에서 제공하는 기본 API기능을 이용하여 서비스를 요청하는 것이다. 따라서 사용자들이 가장 손쉽게 프로그램을 작성할 수 있는 방법이다. 그러나 마우스 프로그래밍처럼 프로그램이 수행중에 특정한 서비스를 필요로 할 경우 정적인 방법으로는 불가능하다. 따라서 이러한 상황에서 사용가능한 방법이 동적 인터페이스 호출이다. 클라이언트는 동적 인터페이스 호출방법을 이용하여 다음과 같은 일을 할 수 있다.

- 프로그램 실행중에 원하는 객체를 찾는다.

- 프로그램 실행중에 원하는 객체의 인터페이스를 찾는다.

- 프로그램 실행중에 원하는 서비스를 생성한다.

- 프로그램 실행중에 원하는 서비스를 요청한다.

- 프로그램 실행중에 원하는 서비스의 결과를 받는다.

이 뿐만 아니라 동적 인터페이스 호출은 동기방식과 비동기 방식 모두를 지원한다. 따라서 사용자는 다양한 응용 프로그램을 작성할 수 있다. 단점으로는 프로그램시 정적 인터페이스 호출에 비해 많은 코드와 노력이 필요하다는 것이다.

인터페이스 저장소(Interface Repository)

IDL로 작성된 모든 인터페이스 정보는 인터페이스 저장소에 저장된다. 이곳에 저장된 정보를 사용하여 클라이언트가 제출한 서비스 요청에 대한 인터페이스 정보를 조회할 수 있으며 해당 요청이 정당한지 검사할 수 있다. ( 실제 클라이언트의 요청은 앞서 살펴본대로 원하는 객체의 메소드 호출을 의미한다. 따라서 이 메소드 호출시 전달되는 파라메터나 아규먼트의 타입이 정확한지 검사할 때 인터페이스 저장소를 이용한다. ) 인터페이지 저장소는 [그림10]과 같은 구조로 인터페이스 정보를 관리한다

[ 그림15 ] 인터페이스 저장소

구현 저장소(Implementation Repository)

인터페이스와 마찬가지로 구현 객체의 정보도 구현 저장소에 저장된다. 이 정보는 해당 서비스에 합당한 구현객체를 구동시키는 데 사용된다. [그림10]는 IDL로 작성된 응용 프로그램에서 인터페이스 저장소와 구현 저장소가 사용되는 예이다. IDL로 작성된 인터페이스는 IDL 컴파일러를 통해 컴파일시 인터페이스와 구현 정보가 각기 인터페이스 저장소와 구현 저장소에 저장된다. 이렇게 저장된 정보는 각기 클라이언트와 구현객체가 실행될 때 이용된다.

[ 그림16 ] IDL 과 인터페이스 저장소

4. CORBA 2.0의 추가 기능

CORBA 1.0 표준안의 가장 큰 단점은 다른 CORBA 제품과 호환이 되지 않는다는 것이다. 가령, A사에서 공급하는 CORBA 제품과 B사의 제품은 호환이 되지 않는다. 왜냐하면 각기 객체를 인식하는 방법이 틀리기 때문이다. 이러한 문제점를 해결하는 데 중점을 둔 것이 CORBA 2.0 표준안이다. 따라서 CORBA 2.0은 기존의 CORBA 1.2의 기능에 다음의 기능들을 추가하였다.

- 동적 스켈리턴 인터페이스(Dynamic Skeleton Interface)

CORBA 1.2에서는 클라이언트의 스터브에 따라 구현 객체상의 스켈리턴이 컴파일시 결정되었다. 그러나 2.0에서는 이러한 방식이외에 실행시간에 요청된 서비스의 파라메터를 해석하여 해당 구현 객체의 메소드를 호출하는 동적 스켈리턴 인터페이스 방식을 추가하였다. 특히 이 기능은 다른 ORB들 사이의 서비스 교환시 유용한 기능이다.

- CORBA2.0의 ORB간 호환 구조

CORBA2.0에서는 ORB사이의 호환을 위해 [그림17]과 같은 구조를 제안하였다. 이 구조에서 보면 크게 필수적인 요구사항으로 GIOP(General Inter-ORB Protocol)과 TCP/IP 가 , 옵션사항으로 ESIOP(Environment-Specific Inter-ORB Protocol)이 소개되었다.

먼저 GIOP는 ORB들 사이의 통신을 위한 일련의 메시지 형태와 공통의 데이타 표현을 명시한다. GIOP로 명시된 클라이언트의 요구사항은 TCP/IP를 비롯하여 네트웨어등 일련의 네트웍을 공유하여 다른 ORB에게 바로 전달된다. 이때 IDL로 정의된 데이타 타입을 네트웍 메시지 형태로 변환하기 위해 CDR(Common Data Format)이라는 방법이 사용된다.

CORBA 2.0에서 정의한 TCP/IP를 IIOP(Internet Inter-ORB Protocol)이라고도 하는데 여기서는 GIOP로 정의된 메세지가 TCP/IP상에서 어떻게 전달되는지를 정의하고 있다. 이 IIOP는 인터넷을 ORB 의 기본 네트웍으로 사용가능하게 한다. 결국 CORBA 2.0 을 지원하는 말은 TCP/IP 상에서 GIOP를 사용하여 서로 다른 ORB들 사이의 메소드 호출을 지원한다는 말이다. GIOP와 IIOP가 필수적인 요구사항인데 반해 ESIOP는 옵션사항으로서 다른 분산 서비스 시스템들과의 호환을 위해 설정된다. 현재 DCE(Distributed Computing Environment)가 그 첫번째 호환대상으로서 정의되어 있다. DCE/ESIOP 에 따르면 GIOP의 CDR로 표현된 메시지는 DCE 에서 해석이 가능하도록 변환되어 진다. 따라서 ESIOP를 사용하면 보안기능이나 디렉토리 서비스등 DCE에서 제공하는 추가적인 기능을 이용할 수 있다.

[ 그림17 ] ORB간 호환을 위한 구조

- ORB간 브리지 제공

CORBA2.0 에서 정의한 동적 스켈리턴 인터페이스를 이용하면 마이크로소프트의 COM/OLE와 같은 다른 객체에 대한 게이트웨이를 생성할 수 있을 뿐만 아니라 다른 ORB사이에서도 특별한 기능의 게이트웨이를 만들 수 있다.

5. 분산 객체 시스템의 여러 가지 구성방법

실제 이러한 분산 객체 시스템을 구성하는 데에는 [그림18]에서 처럼 크게 3가지 방법이 존재한다.

하나는 단일 프로세스 내부에서 라이브러리를 통해 클라이언트와 구현 객체사이의 서비스가 진행되는 방법이다. 이 방법은 분산된 환경에 적합하지 않다.

또 하나의 방법은 분산 객체 시스템에서 제공하는 기능이 클라이언트용 라이브러리와 구현 객체용 라이브러리 형태로 존재하고 이를 이용하여 분산된 환경에서 응용 프로그램을 작성한다. 작성된 프로그램은 별도의 프로세스로 존재한다.

마지막으로 기존의 운영체제에 분산 객체 기능을 추가하거나 별도의 분산 객체 데몬 프로그램이 존재하여 클라이언트와 분산 객체사이의 서비스를 주관하는 방법이 있다.

현재 대다수의 구현제품은 두번째와 세번째 방법을 사용하여 분산 객체 시스템을 개발하고 있다.

[ 그림18 ] 분산 객체 시스템의 여러 가지 구조

5. ObjectWeb 구축 환경

ObjectWeb의 구축 환경은 기존의 WWW환경과 동일하다. 단지 다른 점은 CORBA IIOP를 지원하는 웹 브라우져와 CORBA와 연동가능한 웹서버에 있다. 일단 ObjectWeb을 통해 개발된 클라이언트 Orblet은 CORBA IIOP를 지원하는 웹 브라우져에 HTTP를 통해 다운로드된다. 다운로드된 Orblet은 IIOP를 통해 CORBA와의 서비스를 개시하게 된다. 이 때 유의할 점은 Orblet 역시 자바 애플릿이기 때문에 자바 애플릿이 갖고 있는 보안상의 제약, 특히 다운로드 받은 호스트에만 연결을 설정할 수 있는 제약에 지배된다. 따라서 기본적으로 다운로드된 WWW서버를 통해 서비스 연결을 시도한다. 결국 WWW서버는 Orblet 이 요청한 서비스를 네트웍상의 다른 곳에 위치한 CORBA에게 전달하기 위한 방법을 갖고 있어야 한다. 이 때 사용되는 연동방법은 3.1에서 설명한 바와 같다. ObjectWeb 환경은 위와 같은 CORBA 서비스외에도 기존의 CGI 인터페이스와 HTML 문서 서비스를 여전히 제공한다. 현재 넷스케이프4.0에 내장된 CORBA IIOP 기능을 통해 ObjectWeb 서비스를 이용할 수 있다.

[ 그림19 ] ObjectWeb 구축 환경

6. ObjectWeb 제품들

현재 ObjectWeb 환경을 지원하는 많은 CORBA 제품들이 소개되고 있다. 다음은 해당 제품들에 대한 목록이다. 먼저 주목할 만한 제품으로는 넷스케이프사와 볼랜드등에서 CORBA IIOP 기능을 지원하기 위해 라이센스한 제품으로 비지브로커사의 비지브로커[visigenic]와 가장 많은 플래폼과 다양한 CORBA 서비스를 제공하는 Orbix[iona]와 선사의 JOE[joe][neo]가 있다. 현재 Iona와 선사는 공동으로 작업을 진행하고 있다.

[표5] ObjectWeb 상용제품 제품명	회사	URL
OrbixWeb	IONA	http://www.iona.com
Visibroker for Java	Visigenic	http://www.visigenic.com
JOE	Sun	http://www.sunsoft.com
CHORUS/COOL	CHORUS Systems	http://www.chorus.com/Products/Cool/index.html

[표6] ObjectWeb 공개 제품들 제품명	URL
JacORB	http://www.inf.fu-berlin.de/~brose/jacorb
Julu	http://Coho.stanford.EDU/~hassan/Jylu
ELECTRA	http://www.olsen.ch/~maffeis/electra.html
Omnibroker	http://www.ooc.com/ob.html
Jade	http://pariah.ansa.co.uk:8080/~jade/
DOME	http://www.realobj.demon.co.kuk/
JORBA	http://www.progsoc.uts.edu.au/~raz/jorba/
Java ID	http://splash.javasoft.com/JavaIDL/pages/index.html

다음은 주요한 상용 제품들의 기능을 비교한 표이다[Orfali97].

[ 표7 ] 상용 ObjecdtWeb 기능 비교표 CORBA 기능	OrbixWeb	Joe	Visibroker for Java
클라이언트측 자바	0	0	0
서버측 자바	0	X	0
정적 메소드 호출	0	0	0
동적 메소드 호출	0	X	0
인터페이스 저장소	0	X	0
서버 콜백	0	0	0
IIOP를 통한 네이티브 자바	X	X	0 (Caffeine)

7. ObjectWeb 응용 프로그램 개발

5장과 6장에서 살펴본 것처럼 현재 많은 제품들이 ObjectWeb 환경을 제공한다. 그러나 다행스러운 것은 이 제품들 모두 CORBA 표준을 준수하기 때문에 그 개발 방법과 절차는 동일하다는 것이다. 물론 표준에 준수하는 규약외에 각 제품들이 나름대로 제공하는 기능들도 다수 존재한다. 따라서 본 절에서는 여러 제품들중 비지브로커를 사용하여 ObjectWeb에서의 일반적인 개발과정을 살펴보도록 한다.

7.1 ObjectWeb의 일반적인 개발 과정

ObjectWeb에서의 개발 과정은 기존의 CORBA 개발 방법과 동일하다. 다음은 그 개발과정을 정리한 것이다.

[단계1] IDL을 사용하여 원하는 객체들의 인터페이스를 작성한다.

[단계2] IDL 컴파일러를 사용하여 작성한 IDL 파일을 컴파일한다. 컴파일한 후 클라이언트 스터브 코드와 서버 스켈리턴 코드가 생성되며 인터페이스 정보가 인터페이스 저장소에 저장된다.

[단계3] 서버 구현 부분과 클라이언트 구현 부분을 작성한다.

[단계4] 서버 구현 부분과 서버 스켈리턴턴 코드, 클라이언트 구현 부분과 스터브 코드를 컴파일한다.

[단계5] 컴파일된 서버를 구현 저장소에 등록한다.

[단계6] ORB를 통해 서버를 자동 호출하게 하거나 미리 ORB와 서버를 구동시킨다.

[단계7] 클라이언트를 구동시킨다.

참고로 넷스케이프와 비지브로커에서 발표한 카페인(caffeine)의 경우 IDL없이 작성된 자바 인터페이스 코드(.class)로 부터 스터브와 스켈리턴 코드를 생성해 낸다. 한마디로 카페인은 CORBA IIOP위에 자바 RMI를 구현한 것이라 할 수 있다. [그림20]는 앞서 설명한 과정을 나타낸 그림이다.

[ 그림20 ] ObjectWeb 프로그래밍 절차

7.2 프로그램 개발 과정

ObjectWeb의 개발 과정은 초보자의 경우 상당히 복잡하게 느껴진다. 그러나 항상 일련의 과정을 통해 진행되기 때문에 그 진행 절차를 숙지하면 손쉽게 원하는 프로그램을 작성할 수 있다. 다음은 ObjectWeb 제품중 비지브로커를 통해 이 과정을 익혀보도록 한다.

7.2.1 ObjectWeb 환경 구축

다음은 비지브로커 제품의 환경 구축 과정이다. 설치환경은 윈도우즈라고 가정한다.

[단계1] 해당 소프트웨어를 다운로드 받고 라이센스를 신청한다. (http://www.visibroker.com)

[단계2] 해당 프로그램(VisiJava_12_win.ZIP)을 풀고 setup.exe를 수행한다. 설치된 디렉토리밑에 adm이란 디렉토리에 라이센스(license.dat)파일을 작성한다. 가령, c:\orb20이란 디렉토리에 설치했다면 license.dat은 다음에 위치한다. c:\orb20\adm\license.dat.

license.dat에 필요한 내용은 전자우편을 통해 전달받는다. 다음은 실제 license.dat 파일에 포함되어 있는 내용이다.

Product Name: Orbeline2.0

Host id: 0

Num Units: 0

Expiration Time: 04/18/1997

Checksum: 1251-0101-0610-1112

[단계3] 환경설정

set PATH = C:\ORB20\bin

set ORBLINE = C:\ORB20\ADM

set CLASSPATH=,;C:\ORB20\CLASSES;C:\JAVA\LIB\CLASSES.ZIP

[단계4] 비지브로커 서버 수행

osagent

[단계5] 해당 서버를 수행한 후, 이상이 없으면 클라이언트를 수행한다.

만약, 클라이언트가 자바 애플릿이라면 수행하기 전에 gatekeeper 라는 프로그램을 수행해야 한다. getekeeper는 HTTP를 통해 비지브로커

서버를 호출하게 해주는 HTTP-to-IIOP 게이트웨이이다.  gatekeeper가 제대로 수행되지 않으면 애플릿 형태의 클라이언트는 수행되지 않는다.

gatekeeper 수행시 가장 빈번히 발생하는 것은 UnknownHost Exceprion이다. 이 경우, 실제 자바의 라이브러리(getHostByName)의 오류인데

로컬 호스트의 도메인 이름과 DNS 서버상의 도메인이름의 틀린 경우이다. 따라서 DNS 서버에서 제공하는 도메인 이름으로 설정을 바꾸면

제대로 수행할 수 있다.

7.2.2 ObjectWeb 개발 과정 이해

앞서 무사히 설치를 마쳤다면 다음의 과정에 따라 응용 프로그램을 작성한다. 편의상 예제로서 설치 후 예제 디렉토리에 복사되는

bank 예제를 사용하기로 한다.

[단계1] bank 객체에 대한 IDL 파일을 작성한다. 실제 예는 아래과 같다. bank 객체는 Bank라는 모듈내에 두개의 인터페이스로 구성된다. 하나는 balance() 메소드를 갖는 Account 이고 다른 하나는 특정 소유주의 이름을 받고 해당 계정을 개방한 후 임의의 계정 평잔액을 반환하는 open() 메소드를 갖는 AccountManager 클래스이다. open()메소드의

전달인자는 String 형태로 클라이언트에서 서버로만 전달되기 때문에 in을 사용하였다.

// Bank.idl

module Bank {

interface Account {

float balance();

};

interface AccountManager {

Account open(in string name);

};

};

[단계2] 해당 IDL 파일을 컴파일 한다. idl2javaBank.idl 컴파일 후, 현재 디렉토리하에 Bank라는 이름의 디렉토리와 다수의 파일들이 생성된다. 각 파일들이 의미하는 것은 다음과 같다.

클라이언트측 파일들

_st_Account.java

Account의 스터브 코드

_st_AccountManager.java

AccountManager의 스터브 코드

Account_var.java

클라이언트측의 Account가 서버쪽을 호출할 수 있도록 해주는 bind()메소드와 파라메터들

AccountManager_var.java

클라이언트측의 AccountManager가 서버쪽을 호출할 수 있도록 해주는 bind()메소드와 파라메터들

서버측 파일들

_sk_Account.java

Account의 스켈리턴 코드

_sk_AccountManager.java

AccountManager의 스켈리턴 코드

_example_Account.java

Account 구현을 위한 템플릿 코드

_example.AccountManager.java

AccountManager 구현을 위한 템플릿 코드

공통

Account.java

Account 인터페이스 파일

AccountManager.java

AccountManager 인터페이스 파일

[단계3] _example_Account.java와 _example.AccountManager.java를 이용하여 서버쪽 구현 객체를 작성한다. 볼드체 부분에 원하는 응용 프로그램의 로직을 작성하고 해당 서버객체를 생성하고 이를 ORB에 등록하기 위한 main()함수를 작성한다. 참고로 예제 코드에서 볼드체 부분은 사용자가 작성한 부분이다.

//_example_Account.java

package Bank;

public class _example_Account extends Bank._sk_Account {

/** Construct a persistently named object. */

public _example_Account(java.lang.String name) {

super(name);

}

/** Construct a transient object. */

public _example_Account() {

super();

}

public float balance() throws CORBA.SystemException {

// 이곳에 사용자의 로직을 작성한다.

}

}

//_example_AccountManager.java

package Bank;

public class _example_AccountManager extends Bank._sk_AccountManager {

/** Construct a persistently named object. */

public _example_AccountManager(java.lang.String name) {

super(name);

}

/** Construct a transient object. */

public _example_AccountManager() {

super();

}

public Bank.Account open(

java.lang.String name

) throws

CORBA.SystemException {

// 이곳에 사용자의 로직을 작성한다.

}

}

작성된 코드는 다음과 같다.

//Server.java

import java.util.*;

class Account extends Bank._sk_Account {

Account(float balance) {

_balance = balance;

}

public float balance() throws CORBA.SystemException {

return _balance;

}

private float _balance;

}

class AccountManager extends Bank._sk_AccountManager {

AccountManager(String name) {

super(name);

}

public Bank.Account open(String name) throws CORBA.SystemException {

// 계정 Dictionary에서 해당 계정을 얻어 온다.

Bank.Account account = (Bank.Account) _accounts.get(name);

if(account == null) {

// 0 과 1000달러 사이의 계정을 생성한다.

float balance = Math.abs(_random.nextInt()) % 100000 / 100f;

account = new Account(balance);

System.out.println("Created " + name + "'s account: " + account);

// 새로운 객체 참조자를 얻어온다.

_boa().obj_is_ready(account);

// 계정 목록에 해당 계정을 저장한다.

_accounts.put(name, account);

}

// 계정을 반환한다.

return account;

}

private Dictionary _accounts = new Hashtable();

private Random _random = new Random();

}

public class Server {

public static void main(String[] args) {

try {

// ORB를 초기화 시킨다.

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

// BOA를 초기화 시킨다.

CORBA.BOA boa = orb.BOA_init();

// account manager 객체를 생성한다.

AccountManager manager =

new AccountManager("WWW-KR Bank");

// 새롭게 생성된 객체를 BOA에등록한다. 지금부터 사용준비가 된 셈이다.

boa.obj_is_ready(manager);

System.out.println(manager + " is ready.");

//클라이언트의 요청을 기다린다.

boa.impl_is_ready();

}

catch(CORBA.SystemException e) {

System.err.println(e);

}

}

}

[단계4] 클라이언트 코드를 작성한다.

// Client.java

public class Client {

public static void main(String args[]) {

try {

// ORB를 초기화 시킨다.

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

// 서버 account manager객체에 대한 객체 참조자를 얻어온다.

Bank.AccountManager manager =

Bank.AccountManager_var.bind("WWW-KR Bank");

// 디폴트 사용자 이름이나 args[0]를 계정 이름으로 설정한다.

String name = args.length > 0 ? args[0] : "Jirubak";

// 해당 계정이름의 계정을 열라고 요청한다

Bank.Account account = manager.open(name);

// 계정의 평잔액을 얻어온다.

float balance = account.balance();

// 평잔액을 출력한다.

System.out.println

("The balance in " + name + 객□객 + balance);

}

catch(CORBA.SystemException e) {

System.err.println(e);

}

}

}

[단계5] 작성된 클라이언트와 서버 코드를 컴파일한다.

javac Client.java -> Client.java

javac Server.java -> Server.java

[단계6] 먼저 osagent라는 비지브로커 데몬을 수행시킨다. osagent는 ObjectWeb 클라이언트와 서버사이의 위치 서비스를 제공한다. 따라서 LAN환경에 적어도 하나의 osagent가 수행되어야 한다.

start osagent

다음으로 서버 객체를 수행시킨다.

start java Server

osagent와 서버 객체를 서로 다른 프로세스상에서 수행하기 위해 start 명령어를 사용하였다.

[단계7] 다른 윈도우상에서 클라이언트 프로그램을 수행한다.

java Client

만약 전달인자가 없다면 다음과 같은 결과를 생성해 낸다.

The balance in jirubak's account is $73.17

만약 전달인자로 www-kr을 사용하면 다음과 같은 결과를 생성해 낸다.

The balance in www-kr's account is $11.17

마지막으로 주의할 점은 앞서 설명한 것처럼 클라이언트가 자바 애플릿인 경우 반드시 실행하기 전에 osagent와 gatetkeeper(IIOP GeteKeeper)라는 프로그램을 수행해야 한다. gatekeeper는 HTTP 터널링을 통해 방화벽내에 객체 서버들과 통신하게 해준다. 다시 말하면 getekeeper는 ObjectWeb 클라이언트 애플릿이 다운로드 된 호스트외에 다른 곳에 위치한 객체들과 통신하게 해준다.

8. 결론

지금까지 WWW와 CORBA, Java의 연동 기술을 지칭하는 ObejctWeb에 대해 살펴보았다. 정리하면 ObjectWeb은 현재 인터넷을 중심으로 한 기술중 가장 중요한 핵심 기술인 WWW와 CORBA, Java의 장점들을 연동하여 보다 유연한 시스템을 개발하게 해준다. 따라서 ObjectWeb 사용자는 애플릿을 통해 여러 호스트상의 객체들과 서비스를 주고 받을 수 있으며 엔터프라이즈 규모의 시스템을 디자인하고 개발하게 해준다. 또한 ObjectWeb은 WWW 기반의 시스템을 구축하는 데 있어 기존의 CGI에서 발생한 문제를 해결할 뿐만 아니라 CORBA에서 제공하는 분산 객체 기술을 통해 인터넷 어느 곳에서든지 수행가능한 시스템을 구축하고 이를 규모있게 조정할 수 있다. 또한 기존의 자바 애플릿을 통해 CORBA로 작성된 다른 언어의 객체들을 이용할 수 있기 때문에 컴포넌트 소프트웨어 구축과 재사용이 가능하다. 이러한 이유들로 인해 ObjectWeb 기술은 웹을 기반으로 한 표준 시스템 구축 방법으로 확산될 것이며 기존의 CGI나 기타 연동 기술은 ObjectWeb 기술로 대체될 것이다. 특히, 웹을 기반으로 한 정보시스템중 규모와 종류가 다양한 데이타와 환경위에 기존의 시스템을 바탕으로 새로운 표준 시스템을 구축하려 할 때 ObjectWeb은 그 진가를 발휘할 것이다.

참고문헌(Reference)

[almasi96]

G. Almasi, V juggy Jagannathan, Integrating the WWW and CORBA-based Environment, West virginia University, 1996

URL:http://webstar.cerc.wvu.edu/www4/www4/html

[ashley96]

Ashley McClenaghan, Building a Web from Distributed Objects, ANSA Project, 1996

URL:http://www.ansa.co.uk/ANSA/ISF/96-6-workshop-tms.html

[beitz95]

Ashley Beitz, Renato Iannella, etc, Integrating WWW an\d Middleware, Ausweb95 , 1995

URL:http://www.scu.edu.au/ausweb95/papers/management/beitz/

[condict97]

Michael Condict, Dejan Milojicic, etc, Towards a World-Wide Civilization of Objects, SIGOPS96, 1996

URL:http://www.osf.org/~condict/WebOS/Papers/SIGOPS96/

[iona]

URL:http://www.iona.com/www/Orbix/OrbixWeb/index.htmll

[inmon96]

Inmon, Using the Data Warehousing , 하이테크 정보 , 1996

[joe]

URL:http://www.sun.com/sunsoft./neo

[merle96]

Philippe Merle, Distributed Object Technology abd the Web , 7 May, WWW5 Conference , 1996

URL:http://www.ansa.co.uk/ANSA/ISF/WWW5/DOWpanel.html

[neo]

URL:http://www.sun.com/sunsoft.neo

[OMG96]

CORBA Specification , OMG, 1996

URL:http://www.omg.org

[tresch96]

Markus Tresch, middleware for Distributed Object Management, Tutorial at CIKM96, 1996

[jhpark 96]

jaehyun park, WWW와 분산객체시스템, WWW-KR Workshop , Aug 17, 1996

[jhpark 97]

jaehyun park, 비지니스 환경에서의 CORBA, KIECO , Apr 14, 1997

URL:http://www.aminet.co.kr/~jhpark/wwwcorba.zip

[orfali 96]

Robert Orfali , The Essential Client/Server Survival Guide , 2nd edition , Wiley, 1996

[orfali 97]

Robert Orfali , Dan Harkey , Client/Server Programming with JAVA and CORBA , Wiley, 1997

[resnick]

Ron Resnick , Bring Distributed Objects to the World Wide Web , 1996

URL:http://www.interlog.com/~resnick/javacorb.html

[siegal 96]

CORBA Fundamentals and Programming , Wiley, 1996

[visigenic]

URL:http://www.visigenic.com