방명록 에 소감을 남겨주십시요.
여러분의 의견이 책의 내용을 더욱 풍부하게 만들 것 입니다.

코아 코바의 모든 내용은 본 저자와 영한 출판사 그리도 여러 회사들에 의해서 소유되어 있읍니다. 본 저자의 허락없이 무단 복사 및 인용을 금합니다. 이 사항을 위반시 모든 법적인 책임을 지셔야 합니다.
[ 다음 | 이전 ]

8막 CORBA 의 미래

현재 CORBA는 시스템 통합 기술에 관한한 가장 폭넓게 받아들여지는 표준 기술이다. 따라서 별 이변이 없는 한 계속해서 전 분야로 확산될 것이다. 이런 차원에서 CORBA는 모든 엔지니어와 경영자들에게 있어 필히 숙지해야 할 기술임에 틀림없다. 더욱 이 CORBA는 보다 안정되고 호환성있는 서비스를 제공하기 위해 지금도 많은 기능을 추가하고 있기 때문에 향후 CORBA에 어떤 기능들과 서비스들이 추가될 것인가를 숙지하는 것이 중요하다. 특히, 이 기능들은 CORBA의 미래를 알 수 있게 해 준다.

이런 배경하에서 이번에는 CORBA에 새롭게 보강되고 있는 기능들에 무엇이 있는 지 살펴보면서 조심스럽게 CORBA의 미래를 전망해 본다. 먼저 1992년 CORBA1.2 표준에서는 ORB구조로서 ORB의 기본 기능과 인터페이스 저장소, 기본 객체 아답터를 정의했었고 IDL언어 매핑은 C를 , 객체 서비스로는 명명 서비스, 이벤트 서비스, 생명주기 서비스, 지속성 서비스 등을 정의했었다. 그러나 1.2 표준의 가장 큰 문제로서 등장한 서로 다른 ORB 간의 호환문제를 해결하고자 1995년 제안된 CORBA2.0에서는 서로 다른 ORB들의 IR간에 연동이 가능하도록 기존의 IR을 확장했으며 ORB간 표준 통신 프로토콜로 IIOP를 정의했다. IDL 언어 매핑도 기존의 C외에 C++를 추가로 정의했고 객체 서비스로는 트렌젝션 서비스, 동시성 서비스, 외형화 서비스, 객체 관계 서비스, 질의 서비스, 라이센싱 서비스, 보안 서비스, 시간 서비스, 켈렉션 서비스, 기동 서비스 등을 추가로 정의하였다.

현재 많은 회사들이 CORBA 2.0 표준에 새로운 기능을 추가하고 있다. 이 기능들은 크게 ORB에 메세징 처리 기능을 강화하는 부분과 서버 구현 객체 부분을 강화하여 어떤 ORB상에서도 서버 구현 객체가 수행되도록 해주는 것이 있다. 또한 IDL을 확장하여 기존의 CORBA객체 모델에 다중 인터페이스를 지원하고 있으며 IDL의 자바 매핑을 지원하고 있다. 특히, 값에 의한 객체전달 기능을 강화하여 자바 언어와의 연동을 강화하고 있다. 다음 [표8-1]은 지금까지의 내용을 정리한 것이다.


[ 표 8-1 ] CORBA 표준 기능의 변천

지금부터 CORBA2.0 표준에 추가되는 기능들에 대해 좀 더 자세히 살펴보자. 먼저 이 들 기능은 크게 CORBA의 적용 모델을 강화하여 보다 폭넓게 사용될 수 있도록 해주는 부분과 자바 언어와의 연동을 통해 자바 언어에서 제공하는 모빌 코드 기능과 쓰레드 , 예외상황 처리 등 보다 안정적인 시스템을 구축하는 데 있다고 할 수 있다.

1장. CORBA의 적용 모델을 강화하기 위해 추가된 기능들

CORBA는 일반적으로 클라이언트 객체와 서버 구현 객체 사이에 전형적인 동기형 서비스 모델인 "요청(request)<->응답(reponse)"에 의해서 작업을 수행한다. 이 방법 외에 CORBA는 oneway 라는 비동기 방식으로 메소드를 호출할 수 있다. 그러나 이러한 비동기 방식으로는 기존의 메세징 시스템에서 제공하는 다양한 기능을 제공할 수 없었다. 가령, OLTP 시스템에서 처럼 클라이언트의 요청에 대한 로드밸런싱이나 복수 개의 서버를 동시에 수행시키는 것은 아주 힘들다. 이러한 문제들로 인해 아이오나사를 비롯한 7개 회사(Expersoft, Tibco, Digital, IBM, Nortel, PeerLogic)가 메세지 서비스에 대한 RFP를 제안하였다.

ORB에 메세징 기능을 추가함으로 인해 다음 [그림8-1] 처럼 기존의 CORBA 클라이언트 객체와 서버 구현 객체사이의 불특정한 호출을 중간의 메세지 규를 사용하여 예측하고 제어할 수 있게 됨으로써 클라이언트 객체와 서버 구현 객체사이의 완벽한 비동기 호출과 클라이언트 객체의 호출을 적절하게 로드밸런싱(균등분할 수행)할 수 있다.


[ 그림 8-1 ] CORBA 메세징 기능

CORBA 클라이언트는 CORBA2.0에서 정의한 IIOP상에서 정적 인터페이스 호출과 동적 인터페이스 호출을 사용하면 어떤 ORB건 상관 없이 서버 구현 객체의 서비스를 이용할 수 있다. 그러나 서버 구현 객체측에서는 BOA 인터페이스를 통해서 기동된다. 여기서 발생하는 문제는 BOA 인터페이스가 ORB마다 다르다는 데 있다. 따라서 A사의 ORB상에서 만든 서버 구현 객체는 B사의 ORB에서는 수행될 수 없다. 다시 말해, 서버 구현 객체의 이식성이 극도로 제약받는다. 이러한 문제를 해결하고자 추가된 기능이 휴대 객체 아답터(POA, Portable Object Adapter)와 서버 프레임웍 아답타(SFAs , Server Framework Adapters)이다.

POA는 기존의 BOA가 수행하던 모든 기능을 수행한다: 서버 구현 객체를 구동시키고 해당 메소드를 호출한다. 또한 POA는 프로그램 수행중에 만 존재하는 일시성 객체와 파일이나 데이타베이스에 저장되어 있는 지속성 객체 모두를 지원한다. 그리고 POA는 각 객체 인터페이스의 구현시 인스턴스 관리자(instance manager)를 정의해야 한다. 왜냐하면 인스턴스 관리자가 실제 서버 구현 객체를 생성시키기 때문이다. 따라서 POA인터페이스를 이용하여 작성한 서버 구현객체는 인스턴스 관리자를 통해 어떤 ORB상에서도 생성되고 작동될 수 있다.

SFA는 CORBA의 서버측에서 구현언어에 의존적인 환경을 제공하는 프레임웍이다. 다시 말해, 특정 구현 언어상에서 직접 서버 구현 객체를 생성하고 조작할 수 있게 해준다. 예를 들면, C++용 SFA는 C++생성자에서 직접 CORBA 구현 객체를 생성하고 조작할 수 있게 해준다. 현재 C와 C++, 자바용 SFA가 제안된 상태이다.

주의할 점은 SFA와 POA는 동시에 사용할 수 없다는 것이다. 여러분은 이 둘 중의 하나를 결정하여 사용해야 한다는 것이다.


[ 그림 8-2 ] SFA와 POA

다중 인터페이스란 서버 구현 객체의 속성과 객체 참조자를 다양한 목적으로 구분하여 외부의 인터페이스에게 제공하는 기능을 말한다. 다시 말해, CORBA 프로그래머는 서버 구현 객체의 인터페이스를 다양한 목적과 용도에 따라 여러 개로 분리할 수 있다. 클라이언트 객체는 런타임에 서버 구현 객체의 인터페이스 중 원하는 것을 찾아 이용할 수 있다. 이것은 마치 COM이나 OLE에서 원하는 서비스의 함수 포인터를 찾은 후 이를 실행시키는 것 과 유사하다. 단지 차이점은 COM과 OLE에서는 단지 함수를 호출하는 것인 반면에 CORBA 다중 인터페이스를 이용하면 서버 객체의 객체 참조자를 통해 원하는 메소드를 호출할 수 있으며 서버 객체의 속성에 직접 접근하여 이용할 수 있다.

이러한 다중 인터페이스를 지원하기 위해 CORBA IDL을 확장하였다. 먼저 supports라는 키워드를 사용하여 다중 인터페이스를 선언한다. 또한 initial 이란 키워드를 사용하여 초기 설정되는 기본 인터페이스를 선언할 수 있다. 아울러 선언된 다중 인터페이스에 접근하기 위해 해당 구현 객체의 인터페이스 정보를 제공해주는 메소드로 request_interface와 해당 구현 객체를 생성해주는 create_obejct 메소드를 제공한다.

가령, 다음 [그림8-3]은 MultiplePersonInterface라는 인터페이스를 선언한 것이다. 이 인터페이스는 외부에 Student, Police, Faculty라는 다른 이름의 인터페이스를 제공한다. 외부의 객체는 request_interface 메소드를 호출하여 MultiplePersonInterface인터페이스에 3개의 다중 인터페이스가 있다는 것을 알아낸 후 이중에서 원하는 인터페이스를 찾고 create_object를 통해 해당 서버 구현 객체를 생성한 후 이를 이용한다.

[ 그림8-3 ] 다중 인터페이스

모빌 에이젠트란 자동적으로 IIOP상의 네트웍을 이동하면서 지정된 작업을 수행하는 CORBA 객체를 말한다. 이를 위해서 모빌 에이젼트는 자신의 코드와 속성 등을 네트웍상에서 다른 곳으로 이동할 수 있다. 모빌 에이젼트는 CORBA기반의 웍플로우(Workflow) 같은 분야에 유용하다. 가령, 모빌 에이전트를 이용하여 CORBA 도메인상에서 특정 작업을 시간 순서대로 수행하도록 할 수 있다.

비지니스 객체란 비지니스 문제들을 해결하기 위해 협력하는 독립적인 객체들을 말한다. 따라서 비지니스 객체에는 비지니스 정보와 규칙, 대처 방안들을 갖고 있으며 서로 간에 공유할 수 있다. 비지니스 객체는 현재 OMG의 BODTF(Business Object Domain Task Force)에서 제정중이다. 여기서 비지니스 객체는 비지니스 이름, 정의, 속성, 행동 방식, 관계, 규칙, 제약 사항, 정책, 전략처럼 비지니스 영역에서 활동중인 모든 것들을 표현하는 객체라고 정의된다. 또한 이들 비지니스 객체는 CORBA 상에서 서로 상호연동되어 특정 시스템을 구성하기 위해 플러그-인-플레이 될 수 있다. 예를 들면, 다음 [그림8-4]처럼 비지니스 객체는 특정 비지니스에 포함되는 모든 객체를 의미한다 : 종업원, 프로세스, 트렌젝션, ... 또한 이 들 비지니스 객체는 다른 비지니스 객체와 일련의 관계를 유지하고 있다.

[ 그림 8-4 ] 비지니스 객체

이들 비지니스 객체를 구현하기 위해서는 일일이 모든 객체를 작성하고 이 들 사이의 인터페이스를 작성해야 만 한다. 그러나 비지니스 객체 프레임웍을 사용하면 이러한 수고를 덜 수 있다. 왜냐하면 비지니스 객체 프레임웍이 비지니스 객체들 사이의 통신을 담당하기 때문이다. 다음은 비지니스 객체 프레임웍의 역할을 보여 준다.

[ 그림 8-5 ] 비지니스 객체 프레임웍 기반의 비지니스 객체

현재 CORBA2.0에 정의된 비지니스 객체 모델은 [그림8-6]에처 처럼 3개의 객체로 이루어져 있다: 비지니스 객체(Business Object), 비지니스 프로세스 객체(Business Object Process), 표현 객체(Presentation Object). 먼저 비지니스 객체는 활동중인 비지니스 객체와 관련된 비지니스 규칙과 메타 데이타, 저장 구조 등을 정의한 객체를 말하며 비지니스 프로세스 객체는 비지니스 규칙(프로세스)을 정의한 객체로서 주로 장시간에 걸쳐 수행되는 프로세스를 처리한다. 마지막으로 표현 객체는 사용자에게 객체 정보를 다양하게 시각화 해준다.

[ 그림 8-6 ] 비지니스 객체 모델

현재 이들 비지니스 객체 모델은 CORBA2.0에 정의된 것이다. 현재 BODTF에서는 이 모델을 강화하고자 다각적인 노력을 기울이고 있다. 다음은 이러한 노력들을 정리한 것이다.

CORBA 서비스들이 제공하는 모든 기능을 상속받는 클래스로서 다른 비지니스 클래스들의 토대 클래스 역할을 하는 클래스를 추가하였다. 이 토대 CORBA 비지니스 클래스는 상속관계에 있는 다른 비지니스 클래스들에게 모든 CORBA 서비스의 기능을 이용하게 해준다.

컴포넌트 정의어는 IDL의 확장어로서 CORBA 비지니스 객체의 의미들을 서술할 수 있게 해준다. 예를 들면, 컴포넌트 정의어를 사용하여 해당 비지니스 객체의 속성, 행동 방식, 관계, 규칙, 제약 사항, 정책, 전략 등을 명시할 수 있다.

비지니스 객체는 특정한 작업을 수행하기 위해 일련의 의미가 담겨있는 메세지를 전달함으로써 다른 비지니스 객체를 호출한다. 이 메세지에는 해당 비지니스 객체에게 의미있는 내용들이 전달된다. 이 과정에서 필요한 메세지 작성 기능을 새로이 추가할 예정이다.

2장. 자바 언어와의 연동을 통한 CORBA 기능 강화

CORBA2.0에 추가되는 기능중에는 자바 언어의 기능을 보다 적극적으로 받아들이기 위한 노력들이 눈에 뛴다. 이러한 노력들에는 먼저 IDL언어의 자바 매핑 기능과 값에 의한 전달 기능이 있다.

현재 CORBA 표준에는 C,C++,스몰톡 만이 IDL언어의 표준 매핑 언어로 정의되었다. 그러나 현재 자바 언어로의 매핑이 추가될 예정이다. 특히, 많은 제품들이 이미 IDL-자바 매핑을 지원하고 있으며 자바 언어의 확산과 아울러 사용자 수도 크게 늘고 있는 실정임을 비추어 볼 때 상당히 현실적인 결정이라 할 수 있다. 현재 IDL-자바 매핑안은 크게 선소프트에서 제안한 안과 아이오나사에서 제안한 안 등 여러 개가 존재했으며 이미 이들을 구현한 제품으로 선사의 JOE와 아이오나사의 Orbix/Web이 소개됐었다. 현재 OMG에서는 이 들 안을 검토하여 통합안을 마련중에 있다. 각 공급업체는 이 표준안을 준수할 것이다. 일반적으로 IDL언어는 C++보다 자바에 더욱 가깝기 때문에 매핑에는 크게 문제될 것이 없다. 그러나 가장 큰 문제점으로는 자바 원격 메소드 호출(RMI, Remote Method Invocation) 시스템의 경우 "값에 의한 전달"을 기본으로 하는 데 반해 CORBA는 문자형 처럼 기본 자료형을 제외한 다른 모든 객체의 경우 "참조에 의한 전달"을 기본으로 하기 때문에 많은 문제를 안고 있었다. 그러나 이어서 언급하겠지만 CORBA에서도 "값에 의한 전달" 기능을 지원할 예정이다.

기본적으로 CORBA의 모든 객체는 네트웍상에서 존재하고 이용되기 때문에 기본 자료형을 제외하고는 모두 객체 참조자에 의해서 전달되고 이를 통해서 서비스를 호출할 수 있다. 따라서 객체의 상태를 직접 전달하지 못한다. 따라서 이를 위해서는 별도의 방법들을 고민해야 한다. 특히, 자바 원격 객체들은 "값에 의한 전달"을 기본으로 하기 때문에 자바와의 연동을 위해서는 "값에 의한 전달" 기능을 필히 제공해야 한다. 이런 배경하에서 "값에 의한 전달" 기능이 CORBA에 추가될 것이다. 이미 비지제닉사의 비지브로커는 IIOP상에서 객체의 상태를 전달하는 기능을 제공하고 있다.

3장. CORBA의 미래

지금까지 살펴본 것 처럼 CORBA는 계속해서 많은 기능을 추가하고 있으며 WWW,자바, COM/DCOM등 다른 서비스들을 불가사리처럼 흡수해 나가고 있다. 따라서 진정한 시스템 통합 기술로서 성장하고 있다라고 말할 수 있다. 특히, 몇가지 측면에서 발전해 나가리라고 전망한다.

인터넷은 가장 효율적인 정보 유통망으로서 지속적으로 성장할 것이다. 따라서 기존의 모든 시스템들과 새롭게 개발되는 시스템은 이러한 환경하에서 구축될 것이 분명하다. 이러한 상황에서 다양한 시스템을 통합하기 위한 유일한 기술은 CORBA가 유일하다. 특히, WWW와의 연동, 자바와의 연동 기능 , TCP/IP기반의 IIOP 프로토콜 등은 CORBA를 인터넷상에서의 유일한 통합 기술로 만들고 있다.

객체지향 방법론을 보다 강화한 방법이 컴포넌트 기반의 소프트웨어 개발이다. 이 들 컴포넌트를 개발하기 위해서는 컴포넌트들의 기반 프레임웍이 필수적이다. 특히, 이 프레임웍은 하드웨어나 운영체제, 구현 언어 등 외부 환경에 무관하게 컴포넌트를 작동시켜야 한다. 이런 측면에서 CORBA는 컴포넌트들의 기반 구조로서 성장할 것이다.

8막을 마치며

CORBA는 계속 발전하는 기술로서 지금도 새로운 많은 기능을 추가하고 있다. 새롭게 추가되거나 추가될 기능은 다음과 같다.

이러한 추가된 기능들을 바탕으로 CORBA는 향후 컴포넌트 소프트웨어의 기반 버스로서 , 인터넷 환경하에서 유일한 시스템 통합 기술로서 성장할 것이다. [ 다음 | 이전 ]