코바

위키백과, 우리 모두의 백과사전.
이동: 둘러보기, 검색

코바(Common Object Request Broker Architecture; CORBA)는 OMG에서 정의한 규격으로서 소프트웨어 컴포넌트들을 언어와 사용환경에 대한 제약이 없는 통합을 위한 표준을 지칭한다.

개요[편집]

코바는 응용프로그램 객체 간의 메소드 호출을 표준화하기 위한 목적을 두고 있다. 각 객체의 위치는 로컬과 원격(네트워크 간)에 구애받지 않는다. CORBA는 응용프로그램 객체를 외부에 노출시키는 방법으로써 '인터페이스정의언어'(IDL)을 사용하고 있는데 이는 각 응용프로그램 객체를 IDL을 이용해 필요한 부분만 노출시키겠다는 의도에서이다. 초창기의 코바는 IDL 대 C++ / 자바 프로그래밍 언어와 매핑시켰으나 현재는 다수의 언어(에이다, 파이썬, 루비 등)를 공식적으로 지원한다. 이외에도 비공식적으로 , 비주얼 베이직 등의 언어도 지원한다.

코바의 사양에서 객체요청브로커를 통해서 응용프로그램이 다른 객체들과 상호작용 하게 한다고 구술하고 있다. 실제로 응용프로그램은 객체요청브로커를 초기화 하는 과정은 아래와 같이 간결하게 이루어져있다.

먼저, 생성코드클래스를 작성해야 한다. 이는 개발자가 IDL로 작성한 코드를 IDL 컴파일러를 통해 배포환경에 최적화시켜 컴파일 한 결과물이다. 이를 통해서 생성코드클래스의 생성이 완성되면 객체연결자에 등록시켜야 하는 데 이 객체연결자의 용도는 객체에 대한 참조수 확인, 객체(혹은 참조)초기화 정책, 객체에 대한 생명주기 정책 등이다.

이러한 과정은 코바에 있어서 꼭 필요한 과정이다.

프로그래밍 언어의 일부는 IDL과 매핑시키기 어렵다. 예를 들어 자바의 경우에는 IDL과의 조화가 잘 이루어지지만 C++의 경우는 매핑이 단순하지가 않다. 게다가 C언어의 경우에는 매우 생소하기까지 하다.(C언어의 경우 객체지향언어가 아니다)

프로그래밍 언어와의 매핑은 개발자가 실객체의 메소드를 얼마나 잘 노출시킬 수 있는지에 달려있다. 이를 위해 대부분의 코바 구현체는 IDL을 컴파일러와 툴을 가지고 있다. 전통적으로 IDL 컴파일러는 응용프로그램에서 사용가능한 오브젝트 파일로 IDL파일을 컴파일한다. 이 구조를 아래의 관계도에서 표현하고 있다.

배경[편집]

분산 시스템원격 시스템 간의 자원 공유, 개방성, 병렬성, 확장성, 내구성, 투명성 등을 제공해야 한다. 또한 80년대부터 대두 되었던 객체지향 기술의 객체는 데이터와 그 데이터를 조작할 수 있는 메소드(method)로 구성되어 있으며, 프로그램은 메시지에 의한 객체 간의 상호 작용을 기술함으로써 여러 문제를 해결할 수 있게 됐다.

분산 객체 기술은 이러한 두 기술의 장점을 효과적으로 통합하는 기술이며, 개발자에게 애플리케이션 개발의 생산성을 향상시켜주고, 사용자에게 분산 환경에 투명하게 통합된 정보를 제공한다.

이를 위해 OMG(Object Management Group)에서는 분산 컴퓨팅과 객체지향 기술을 하나로 합친 표준 아키텍처를 제안하게 되는데, 그것이 바로 CORBA이다.

특징[편집]

CORBA는 애플리케이션들끼리 어느 위치든, 누가 만들었든 상관없이 상호간 통신을 보장하고 분산 객체 간의 상호 운용을 위한 통신 미들웨어 역할을 하며, 분산 객체 소프트웨어의 기본 틀로서 서비스를 제공하는 부분과 제공받는 부분간의 투명한 정보 교환이 가능하도록 하며 분산 환경에서 응용 소프트웨어를 쉽게 개발할 수 있도록 지원한다.

분산 환경에서 클라이언트와 서버 간의 인터페이스만 정의되면 이들 서로 간의 서비스 요구나 결과 값의 전달이 하부 통신 메커니즘에 반영될 수 있다.

CORBA를 이용한 응용 소프트웨어 개발은 각종 투명성이 보장되기 때문에 사용자의 특정 응용 업무 개발 환경에 적합하고 개발 과정이 간단하고 효율적이다.

CORBA 애플리케이션 개발[편집]

CORBA 애플리케이션 디자인은 다른 기계에 존재하는 객체네트워크에서 통신할 수 있도록 추가 계층(layer)을 포함해야 한다. 이런 추가 계층은 스텁(stub)과 스켈레톤(skeleton)이라는 특수한 객체에 의해 조절한다.

CORBA 클라이언트에서 스텁은 서버에 실제로 구현한 객체에 대한 프록시(proxy) 역할을 한다. 클라이언트는 인터페이스를 구현한 객체와 직접 상호 작용하듯이 스텁에 접근하여, ORB(Object Request Broker) 소프트웨어를 통해 인터페이스를 호출한다.

CORBA 서버에서 ORB 소프트웨어는 인터페이스 호출을 생성된 스켈레톤에 자동으로 넘겨준다. 스켈레톤은 Portable Object Adapter(POA)를 통해 ORB 소프트웨어와 통신한다. 스켈레톤은 POA를 사용해 객체를 등록하고, 여기에 객체의 범위와 객체가 인스턴스화해 클라이언트에 반응할 수 있게 되는 시기등을 결정한다.

CORBA의 구조[편집]

  • ORB의 구성 (클라이언트 사이드)
    • IDL 스텁 : 클라이언트의 정적 통신을 담당
    • 동적 호출 인터페이스(DII: Dynamic Invocation Interface) : 동적 통신을 담당
    • 인터페이스 저장소(interface repository): 인터페이스들을 저장하고 동적 호출시 참조
    • ORB 인터페이스 : 클라이언트측과 서버측에서 모두 이용할 수 있는 의사 객체(pseudo object) 관련 서비스 제공
  • ORB의 구성 (서버 사이드)
    • 객체 어댑터(Object Adapter) : 디스크에 적재된 응용 서버의 활성화 및 비활성화 등을 담당
    • IDL 스켈레톤 : 서버 측에서의 정적 통신을 담당
    • 동적 스켈레톤 인터페이스(DSI:Dynamic Skeleton Interface) : 동적 통신을 담당
    • 구현 저장소(Implementation Repository) : 서버 측 객체와 관련한 각종 정보를 저장
  • ORB 코어
    • 선택 가능한 컴포넌트에 ORB의 커널 기능을 제공
    • 최소한의 기능
      • 객체 레퍼런스의 생성, 해석 등의 객체의 기능적인 표현 기능
      • 클라이언트와 객체 구현 사이의 요청(Request)의 통신 기능
    • ORB 서비스 : 보안 콘텍스트를 요청(Request)와 함께 전송
  • 서버측과 클라이언트간의 정보 전달 경로
    • 클라이언트의 요구 메시지가 클라이언트 스텁(또는 DSI)을 통해 ORB core를 지나 서버측의 객체 어댑터로 전달며, 객체 어댑터는 요구한 서버의 위치를 구현 저장소를 통해 확인한 후 서버 활성화를 한다. 서버 실행이 끝나면 생성된 결과 값은 요구가 전달된 역순으로 클라이언트에게 전달된다.

CORBA 구현체 목록[편집]

상용[편집]

오픈소스[편집]

관련 항목[편집]

참고문헌[편집]

바깥 고리[편집]