공통 객체 요청 브로커 아키텍처

Common Object Request Broker Architecture
공통 객체 요청 브로커 아키텍처
줄임말코바
상황출판된
시작한 해1991년; 31년 전(1991년)
최신 버전3.4
2021년 2월, 1년 전(2021-02)
조직오브젝트 관리 그룹
웹 사이트corba.org

CORBA(Common Object Request Broker Architecture)는 다양한 플랫폼에 배치된 시스템의 통신을 용이하게 하기 위해 설계된 Object Management Group(OMG; 객체 관리 그룹)에 의해 정의된 표준입니다.CORBA를 사용하면 서로 다른 운영 체제, 프로그래밍 언어 및 컴퓨팅 하드웨어의 시스템 간 협업이 가능합니다.CORBA를 사용하는 시스템이 객체 지향적일 필요는 없지만 CORBA는 객체 지향 모델을 사용합니다.CORBA는 분산 객체 패러다임의 한 예입니다.

개요

CORBA는 서로 다른 언어로 작성된 소프트웨어와 서로 다른 컴퓨터에서 실행되는 소프트웨어 간의 통신을 가능하게 합니다.특정 운영체제, 프로그래밍 언어 및 하드웨어 플랫폼의 구현에 대한 자세한 내용은 CORBA를 사용하는 개발자의 책임에서 제외됩니다.CORBA는 동일한 주소 공간(애플리케이션) 또는 원격 주소 공간(같은 호스트 또는 원격 h)에 있는 애플리케이션 개체 간의 메서드 호출 의미를 정규화합니다.ost)를 표시합니다.버전 1.0은 1991년 10월에 출시되었습니다.

CORBA는 Interface Definition Language(IDL; 인터페이스 정의 언어)를 사용하여 오브젝트가 외부에 제시하는 인터페이스를 지정합니다.CORBA는 IDL에서 C++나 Java와 같은 특정 구현 언어에 대한 매핑을 지정합니다.표준 매핑은 Ada, C, C++, C++11, COBOL, Java, Lisp, PL/I, Object Pascal, Python, Ruby 및 Smalltalk에 대해 존재합니다.비표준 매핑은 C#, Erlang, Perl, Tcl 및 Visual Basic에 대해 이들 언어로 작성된 Object Request Broker(ORB; 객체 요청 브로커)에 의해 구현됩니다.

CORBA 규격은 애플리케이션이 다른 물체와 상호작용하는 ORB가 있어야 한다고 규정하고 있다.실제 구현 방법은 다음과 같습니다.

  1. 응용 프로그램은 ORB를 초기화하고 참조 카운트, 개체(및 참조) 인스턴스화 정책 및 개체 수명 정책 등의 작업을 유지하는 내부 개체 어댑터에 액세스합니다.
  2. 개체 어댑터는 생성된 코드 클래스의 인스턴스를 등록하는 데 사용됩니다.생성된 코드 클래스는 사용자 IDL 코드를 컴파일한 결과입니다.이것에 의해, 개략적인 인터페이스 정의가, 유저 애플리케이션이 사용하는 OS 및 언어 고유의 클래스 베이스로 변환됩니다.이 순서는 CORBA의 시멘틱스를 적용하여 CORBA 인프라스트럭처와 인터페이스하기 위한 클린 사용자 프로세스를 제공하기 위해 필요합니다.

일부 IDL 매핑은 다른 IDL 매핑보다 사용하기 어렵습니다.예를 들어 Java의 특성상 IDL-Java 매핑은 비교적 간단하며 Java 응용 프로그램에서 CORBA를 매우 쉽게 사용할 수 있습니다.이는 IDL에서 Python으로의 매핑에도 해당됩니다.C++ 매핑에서는 프로그래머가 C++ Standard Template Library(STL; 표준 템플릿 라이브러리)보다 이전 데이터 유형을 학습해야 합니다.반면 C++11 매핑은 사용하기 쉽지만 STL을 많이 사용해야 합니다.C 언어는 객체 지향적이지 않기 때문에 IDL에서 C로의 매핑에서는 C 프로그래머가 객체 지향 기능을 수동으로 에뮬레이트해야 합니다.

CORBA 기반의 분산 객체 인터페이스를 사용하거나 구현하는 시스템을 구축하기 위해 개발자는 시스템이 사용하거나 구현하는 논리에 대해 객체 지향 인터페이스를 정의하는 IDL 코드를 얻거나 작성해야 합니다.일반적으로 ORB 구현에는 IDL 컴파일러라고 불리는 툴이 포함되어 있어 IDL 인터페이스를 시스템의 해당 부분에서 사용하는 타깃 언어로 변환합니다.그런 다음 기존 컴파일러는 생성된 코드를 컴파일하여 응용 프로그램에서 사용할 링크 가능 객체 파일을 만듭니다.다음 그림은 CORBA 인프라스트럭처 내에서 생성된 코드가 어떻게 사용되는지를 보여 줍니다.

Illustration of the autogeneration of the infrastructure code from an interface defined using the CORBA IDL

이 그림은 CORBA를 사용한 리모트프로세스간 통신의 개략적인 패러다임을 나타내고 있습니다.CORBA 규격은 데이터 입력, 예외, 네트워크 프로토콜, 통신 제한 시간 등을 추가로 다룬다.예: 보통 서버 측에는 로컬서번트 또는 (부하 밸런싱을 위해) 콜을 다른 서버로 리다이렉트하는 Portable Object Adapter(POA; Portable Object Adapter)가 있습니다.CORBA 사양(따라서 이 그림)은 분산 시스템의 다양한 측면을 애플리케이션에 맡겨 객체 수명(어플리케이션에서 참조 카운트 시멘틱을 사용할 수 있음), 용장성/페일오버, 메모리 관리, 동적 로드 밸런싱 및 di 간의 분리 같은 애플리케이션 지향 모델을 정의합니다.스플레이/데이터/제어 의미론(예: 모델-뷰-제어기 참조) 등

CORBA는 언어 및 플랫폼 중립 Remote Procedure Call(RPC; 리모트프로시저 콜) 사양을 사용자에게 제공할 뿐만 아니라 트랜잭션 및 보안, 이벤트, 시간 및 기타 도메인 고유의 인터페이스 모델 등 일반적으로 필요한 서비스를 정의합니다.

버전 이력

다음 표에 CORBA 표준 버전의 [1][2]이력을 나타냅니다.

버전 버전 날짜 하이라이트
1.0 1991년 10월 첫 번째 버전, C 매핑
1.1 1992년 2월 상호운용성, C++매핑
1.2 1993년 12월 -
2.0 1996년 8월 CORBA 2라고도 불리는 표준의 첫 번째 주요 업데이트
2.1 1997년 8월 -
2.2 1998년 2월 자바 맵핑
2.3 1999년 6월 -
2.4 2000년 8월 -
2.5 2001년 9월 -
2.6 2001년 12월 -
3.0 2002년 7월 CORBA 3이라고도 불리는 표준의 두 번째 주요 업데이트
CORBA 컴포넌트 모델(CCM)
3.0.1 2002년 11월 -
3.0.2 2002년 12월 -
3.0.3 2004년 3월 -
3.1 2008년 1월 -
3.1.1 2011년 8월 2012년판 ISO/IEC 19500으로 채택
3.2 2011년 11월 -
3.3 2012년 11월 ZIOP 추가
3.4 2021년 2월

하인들

servant는 원격 메서드 호출을 처리하기 위한 메서드를 포함하는 호출 대상입니다.새로운 CORBA 버전에서는 리모트오브젝트(서버 측)는 오브젝트(리모트 호출에 노출됨)와 서번트(전자가 메서드 호출을 전송하는 대상)로 분할됩니다.리모트 오브젝트당 1개의 서번트가 될 수도 있고, 같은 서번트가 지정된 Portable Object Adapter와 관련된 여러 개의 (모든) 오브젝트를 지원할 수도 있습니다.각 객체의 서번트는 "1회 및 영원"(서번트 액티베이션)을 설정 또는 찾거나 해당 객체의 메서드가 호출될 때마다 동적으로 선택할 수 있습니다(서번트 위치).서번트 로케이터와 서번트액티베이터는 모두 콜을 다른 서버로 전송할 수 있습니다.전체적으로 이 시스템은 부하를 분산하는 매우 강력한 수단을 제공하며, 여러 머신 간에 요청을 분산합니다.오브젝트 지향 언어에서 리모트 오브젝트와 그 서브젝트는 오브젝트 지향 프로그래밍의 관점에서 오브젝트입니다.

인시파이어는 CORBA 객체와 서번트를 관련지어 요구를 처리할 수 있도록 하는 행위입니다.Incephonation은 가상 CORBA 오브젝트에 구체적인 서번트 폼을 제공합니다.활성화 및 비활성화란 CORBA 오브젝트만을 가리킵니다.단, 구현 및 Etherealization이라는 용어는 서브셋을 가리킵니다.그러나 물건과 하인의 수명은 독립적입니다.activate_object()를 호출하기 전에 항상 서번트를 구현하지만 그 반대의 경우도 가능합니다.create_reference()는 서번트를 구현하지 않고 오브젝트를 활성화하며 서번트의 구현은 나중에 서번트 매니저를 사용하여 필요에 따라 실행됩니다.

Portable Object Adapter(POA; Portable Object Adapter)는 서버 측 리모트 호출 핸들러를 리모트오브젝트와 그 서번트로 분할하는 CORBA 오브젝트입니다.오브젝트는 리모트 호출에 대해서 공개됩니다만, 서번트에는 실제로 요구를 처리하는 메서드가 포함되어 있습니다.각 객체의 서번트는 정적(1회) 또는 동적(리모트 호출마다) 중 하나를 선택할 수 있습니다.두 경우 모두 콜을 다른 서버로 전송할 수 있습니다.

서버측에서 POA는 트리형 구조를 형성하고 각 POA는 1개 이상의 오브젝트를 처리합니다.이 트리의 브랜치는 독립적으로 활성화/비활성화할 수 있으며, 서번트 위치 또는 활성화에 대한 다른 코드와 다양한 요청 처리 정책을 가지고 있습니다.

특징들

다음은 분산 객체 간의 통신을 용이하게 하기 위해 CORBA를 사용할 수 있는 가장 중요한 방법에 대해 설명합니다.

참조별 객체

이 참조는 문자열화된 Uniform Resource Locator(URL; 유니폼리소스 로케이터), NameService lookup(Domain Name System(DNS; 도메인네임 시스템)과 유사) 또는 콜 중 메서드파라미터로서 취득됩니다.

오브젝트 참조는 실제 오브젝트(리모트 또는 로컬)의 인터페이스와 일치하는 경량 오브젝트입니다.메서드는 참조를 호출하면 ORB에 대한 후속 호출이 이루어지며 응답, 성공 또는 실패를 기다리는 동안 스레드에서 차단됩니다.파라미터, 리턴 데이터(있는 경우) 및 예외 데이터는 로컬 언어 및 OS 매핑에 따라 ORB에 의해 내부적으로 수집됩니다.

값별 데이터

CORBA 인터페이스 정의 언어는 언어 및 OS 중립 객체 간 통신 정의를 제공합니다.CORBA 객체는 참조로 전달되며 데이터(정수, 배수, 구조체, 에넘 등)는 값으로 전달됩니다.참조별 객체 및 값별 데이터 조합을 통해 클라이언트 및 서버를 컴파일할 때 우수한 데이터 입력을 강제할 수 있으며 CORBA 문제 공간 고유의 유연성을 유지할 수 있습니다.

OBV(Objects By Value)

리모트 오브젝트와는 별도로 CORBA 및 RMI-IOP는 OBV 및 밸류 타입의 개념을 정의합니다.Valuetype 객체의 메서드 내부 코드는 기본적으로 로컬에서 실행됩니다.리모트측으로부터 OBV를 수신했을 경우, 필요한 코드는, 양쪽에서 인식되고 있는 priori 또는 송신측으로부터 동적으로 다운로드되고 있을 필요가 있습니다.이를 가능하게 하기 위해 OBV를 정의하는 레코드에는 공백으로 구분된 URL 목록인 Code Base가 포함되어 있습니다.이 목록은 이 코드를 다운로드해야 합니다.OBV에는 리모트 방식도 있습니다.

CORBA 컴포넌트 모델(CCM)

CORBA Component Model(CCM; CORBA 컴포넌트 모델)은 CORBA 정의 [3]패밀리에 추가된 것입니다.CORBA 3과 함께 소개되었으며 CORBA 구성 요소를 위한 표준 애플리케이션 프레임워크를 설명합니다."언어 의존형 엔터프라이즈 자바 빈(EJB)"에 의존하지 않지만, EJB가 정의하는 두 가지 구성 요소 유형이 아닌 네 가지 구성 요소 유형을 제공하는 EJB의 보다 일반적인 형태입니다.포트라고 불리는 잘 정의된 이름 있는 인터페이스를 통해 서비스를 제공하고 받아들일 수 있는 엔티티의 추상화를 제공합니다.

CCM에는 소프트웨어 컴포넌트를 전개할 수 있는 컴포넌트 컨테이너가 있습니다.컨테이너는 구성 요소가 사용할 수 있는 서비스 집합을 제공합니다.이러한 서비스에는 통지, 인증, 지속성 및 트랜잭션 처리가 포함되지만 이에 한정되지 않습니다.이러한 서비스는 분산형 시스템에서 가장 많이 사용되는 서비스이며, 이러한 서비스를 소프트웨어 컴포넌트에서 컴포넌트 컨테이너로 이행함으로써 컴포넌트의 복잡성을 대폭 줄일 수 있습니다.

휴대용 요격기

휴대용 요격기는 CORBA 및 RMI-IIOP에 의해 CORBA 시스템의 가장 중요한 기능을 중재하기 위해 사용되는 "훅"입니다.CORBA 표준에서는, 다음의 타입의 대행 수신기를 정의하고 있습니다.

  1. IOR 인터셉터는 현재 서버에 의해 제공되는 리모트개체에 대한 새로운 참조 작성을 중개합니다.
  2. 클라이언트 인터셉터는 보통 클라이언트(발신자) 측에서 리모트메서드 콜을 중개합니다.오브젝트 Servant가 메서드가 호출된 서버와 동일한 서버에 존재하는 경우 로컬콜도 중개됩니다
  3. 서버 대행 수신기는, 서버(핸들러)측의 리모트 메서드 콜의 처리를 중개합니다.

대행 수신자는 송신되는 메시지 및 작성되는 IOR에 특정 정보를 첨부할 수 있습니다.이 정보는 나중에 리모트측의 대응하는 인터셉터로 판독할 수 있습니다.대행 수신기는 전송 예외를 발생시켜 요청을 다른 대상으로 리디렉션할 수도 있습니다.

GeneralORB 프로토콜(GIOP)

주요 기사:일반 ORB 프로토콜

GIOP는 객체 요청 브로커(ORB)가 통신하는 추상 프로토콜입니다.프로토콜과 관련된 표준은 OMG(Object Management Group)에 의해 유지됩니다.GIOP 아키텍처는 다음과 같은 몇 가지 구체적인 프로토콜을 제공합니다.

  1. 인터넷 인터ORB 프로토콜(IIOP) – Internet Inter-Orb Protocol은 인터넷을 통해 사용하기 위한 GIOP의 구현으로 GIOP 메시지와 TCP/IP 계층 간의 매핑을 제공합니다.
  2. SSL 인터ORB Protocol (SSIOP)– SSIOP은 IIOP over SSL로 암호화와 인증을 제공합니다.
  3. 하이퍼텍스트 인터ORB Protocol(HTIOP) – HTIOP는 IIOP over HTTP로 트랜스페어런트프록시 바이패스를 제공합니다.
  4. Zipped IOP(ZIOP) – 대역폭 사용량을 줄이는 압축된 버전의 GIOP.

VMCID(벤더 마이너코드셋 ID)

각 표준 CORBA 예외에는 예외의 하위 카테고리를 지정하는 마이너코드가 포함되어 있습니다.마이너 예외 코드는 부호 없는 긴 타입으로 상위 20비트를 차지하는 20비트 "Vendor Minor Codeset ID"(VMCID)와 하위 12비트를 차지하는 마이너코드로 구성됩니다.

표준 예외의 마이너코드는 부호 없는 긴 상수 CORBA로 정의된 OMG에 할당된 VMCID에 의해 프리픽스 됩니다.OMGVMCID: 상위 20비트를 점유하는 OMG에 할당된 VMCID가 있습니다.3-58페이지의 표 3-13에 있는 표준 예외와 관련된 마이너 예외 코드는 OMGVMCID와 함께 편집하여 ex_body 구조에서 반환되는 마이너 코드 값을 얻습니다 (섹션 3.17.1, "표준 예외 정의"(3-52페이지 및 섹션 3.17.2 "표준 예외 코드" 참조).

벤더가 할당한 공간 내에서 마이너코드에 대한 값 할당은 벤더가 맡깁니다.벤더는 tagrequest@omg.org으로 이메일을 보내 VMCID 할당을 요청할 수 있습니다.현재 할당되어 있는 VMCID 목록은 OMG 웹사이트(http://www.omg.org/cgi-bin/doc?vendor-tags에서 확인할 수 있습니다.

VMCID 0 및 0xfffff는 실험용으로 예약되어 있습니다.VMCID OMGVMCID(섹션 3.17.1, "표준 예외 정의"(3-52페이지)) 및 1~0xf는 OMG용으로 예약되어 있습니다.

공통 개체 요청 브로커:아키텍처 및 사양(CORBA 2.3)

Corba 위치(Corba Loc)

Corba Location(Corba Loc)은 URL과 유사한 CORBA 객체의 문자열화된 객체 참조를 참조합니다.

모든 CORBA 제품은 2개의 OMG 정의 URL을 지원해야 합니다.corbaloc:" 및 "corbaname:"을 지정합니다.이 방법의 목적은 IOR을 얻을 수 있는 위치를 지정할 수 있는 읽기 쉽고 편집 가능한 방법을 제공하는 것입니다.

corbaloc의 예를 다음에 나타냅니다.

corbaloc::160.45.110.41:38693/표준NS/NameServer-POA/_root

CORBA 제품은 옵션으로 "http:", "ftp:" 및 "file:" 형식을 지원할 수 있습니다.이러한 의미에서는 문자열화 IOR(또는 재귀적으로 문자열화 IOR을 제공하는 다른 URL)을 다운로드하는 방법에 대한 자세한 내용을 제공합니다.일부 ORB는 해당 ORB에 고유한 추가 형식을 제공합니다.

혜택들

CORBA의 이점으로는 언어와 OS에 의존하지 않고, 기술 관련 구현으로부터 자유로워지며, 강력한 데이터 타이핑, 높은 수준의 조정 가능성, 분산 데이터 전송의 세부 사항으로부터 자유로워집니다.

언어의 독립성
CORBA는 엔지니어가 특정 소프트웨어 언어에 디자인을 결합하는 제한에서 벗어나도록 설계되었습니다.현재 다양한 CORBA 프로바이더에 의해 지원되는 언어는 여러 가지가 있으며, 가장 인기 있는 언어는 Java와 C++입니다.C++11, C-only, Smalltalk, Perl, Ada, Ruby, Python 등의 구현도 있습니다.
OS에 의존하지 않다
CORBA의 설계는 OS에 의존하지 않습니다.CORBA는 Java(OS에 의존하지 않음), Linux/Unix, Windows, Solaris, OS X, OpenVMS, HPUX, Android, LynxOS, VxWorks, ThreadX, Integrity 등의 네이티브 버전을 지원합니다.
테크놀로지로부터의 해방
주요 암묵적 이점 중 하나는 CORBA가 엔지니어가 다양한 신규 시스템과 레거시 시스템 간의 인터페이스를 정상화할 수 있는 중립적인 경쟁의 장을 제공한다는 것입니다.C, C++, Object Pascal, Java, Fortran, Python 및 기타 언어 또는 OS를 하나의 응집력 있는 시스템 설계 모델로 통합할 때 CORBA는 필드를 평준화하고 나중에 전체 시스템으로 통합될 수 있는 시스템 및 유닛 테스트를 서로 다른 팀이 개발할 수 있는 수단을 제공합니다.이는 스레드화, 타이밍, 오브젝트 라이프타임 등 기본적인 시스템엔지니어링 결정이 필요하다는 것을 배제하지 않습니다.이러한 문제는 테크놀로지에 관계없이 모든 시스템의 일부입니다.CORBA를 사용하면 시스템 요소를 하나의 응집력 있는 시스템 모델로 정규화할 수 있습니다.
예를 들어 웹 서버의 Java Servlet과 비즈니스 로직을 포함하는 다양한 CORBA 서버를 사용하여 데이터베이스 접근을 랩핑하여 멀티티어 아키텍처 설계를 단순화합니다.이것에 의해, 비즈니스 로직의 실장이 변경되는 한편, 인터페이스의 변경은 다른 테크놀로지와 같이 처리할 필요가 있습니다.예를 들어 서버에 의해 랩된 데이터베이스는 외부 인터페이스에 영향을 주지 않고 디스크 사용률 또는 성능 향상(또는 전체 데이터베이스 벤더 변경)을 위해 데이터베이스 스키마를 변경할 수 있습니다.동시에 C++ 레거시 코드는 C/Fortran 레거시 코드 및 Java 데이터베이스 코드와 통신할 수 있으며 웹 인터페이스에 데이터를 제공할 수 있습니다.
데이터 타이핑
CORBA는 유연한 데이터 입력(예: "ANY" 데이터 유형)을 제공합니다.CORBA는 또한 긴밀하게 결합된 데이터 입력 기능을 적용하여 사람의 실수를 줄입니다.Name-Value 쌍이 전달되는 상황에서는 서버가 문자열이 예상되는 번호를 제공할 수 있습니다.CORBA Interface Definition Language는 사용자 코드가 메서드 이름, 리턴, 파라미터 유형 및 예외에 적합하도록 하는 메커니즘을 제공합니다.
높은 조정성
많은 구현(예: ORBexpress(Ada, C++, Java 구현)[4] 및 OmniORB(오픈 소스 C++ 및 Python 구현)[5]에는 스레드 및 연결 관리 기능을 조정하는 옵션이 있습니다.모든 ORB 구현이 동일한 기능을 제공하는 것은 아닙니다.
데이터 전송에 대한 상세 정보 배제
낮은 수준의 연결 및 스레드를 처리할 때 CORBA는 오류 상황에서 높은 수준의 세부 정보를 제공합니다.이것은 CORBA 정의 표준 예외 세트 및 구현 고유의 확장 예외 세트에 정의되어 있습니다.예외에 의해 어플리케이션은 콜이 "Small problem, small problem, server is dead" 또는 "The reference is not sense"와 같은 이유로 실패했는지 여부를 판별할 수 있습니다.일반적인 규칙은 다음과 같습니다.예외를 수신하지 않는 것은 메서드콜이 정상적으로 완료되었음을 의미합니다.이것은 매우 강력한 디자인 기능입니다.
압축
CORBA는 데이터를 바이너리 형식으로 캡슐화하고 압축을 지원합니다.IONA, Remedy IT 및 Telefonica는 압축 기능을 제공하는 CORBA 표준을 확장하기 위해 노력했습니다.이 확장은 ZIOP라고 불리며 현재 공식적인 OMG 표준입니다.

문제와 비판

CORBA는 코드가 작성되고 소프트웨어가 구축되는 방식으로 많은 것을 전달했지만 [6]비판의 대상이 되어 왔다.

CORBA에 대한 비판의 대부분은 규격 자체의 결함이 아니라 규격의 불충분한 구현에서 비롯된다.표준 자체의 실패 중 일부는 CORBA 규격이 작성된 프로세스와 많은 경쟁 시행사가 소싱한 공통 표준을 작성하는 정치 및 비즈니스에 내재된 타협 때문이었다.

초기 구현 비호환성
CORBA의 초기 사양에서는 IDL만 정의되어 있으며, 온더와이어 형식은 정의되어 있지 않습니다.즉, 소스코드의 호환성은 몇 년 동안 이용 가능한 최고의 것이었습니다.CORBA 2 이후에서는 이 문제가 해결되었습니다.
위치 투과성
CORBA의 로케이션 투과성에 대한 개념은 비판받아 왔습니다.즉, 동일한 주소 공간에 존재하며 단순한 함수 호출로 액세스할 수 있는 오브젝트는 다른 곳에 존재하는 오브젝트(같은 머신 또는 다른 머신상의 다른 프로세스)와 동일하게 취급됩니다.이것은 모든 오브젝트접근을 가장 복잡한 경우처럼 복잡하게 하기 때문에 근본적인 [7][failed verification]설계상의 결함입니다(즉, 로컬콜에서는 불가능한 광범위한 종류의 장애를 가진 리모트네트워크 콜).또, 2개의 클래스간의 피할 수 없는 차이를 숨기고 있기 때문에, 애플리케이션으로 적절한 사용 전략을 선택할 수 없습니다(즉, 1 의 레이텐시와 확실한 리턴을 가지는 콜은, 전송 장해가 발생할 가능성이 있는 1 초 레이텐시를 가지는 콜과는 매우 다른 방법으로 사용됩니다.이 콜에서는, 전송 상태가 불명확하게 되어 이행할 가능성이 있습니다).타임아웃에는 30대가 걸립니다).
설계 및 프로세스의 결함
CORBA 표준의 작성은 위원회에 의한 설계 프로세스로도 자주 인용된다.상충되는 제안들 사이를 중재하거나 해결해야 할 문제의 계층을 결정하는 과정이 없었다.따라서 표준은 [8]일관성과 관계없이 모든 제안의 특징을 결합함으로써 작성되었다.이로 인해 규격이 복잡해지고 구현 비용이 많이 들 뿐만 아니라 종종 모호해졌습니다.
구현 벤더와 고객의 혼합으로 구성된 설계 위원회는 다양한 관심사를 창출했습니다.이러한 다양성으로 인해 난관이 응집력 있는 표준이 되었다.표준과 상호 운용성에 의해, 경쟁이 심해져, 고객의 대체 실장간의 이동이 완화되었습니다.이로 인해 위원회 내에서 많은 정치적 다툼이 발생하였고 일부 ORB 구현자가 보증한 CORBA 표준의 개정판이 자주 발표되었습니다.[6]윤리성이 떨어지는 CORBA 벤더는 고객 구속을 장려하고 강력한 단기적 성과를 달성했습니다.시간이 지남에 따라 휴대성을 장려하는 ORB 벤더가 시장 [citation needed]점유율을 차지했습니다.
구현에 관한 문제
CORBA의 역사를 통해 CORBA는 열악한 ORB 구현의 단점에 시달려 왔습니다.유감스럽게도 CORBA를 표준으로 비판하는 논문의 대부분은 단순히 CORBA ORB 구현에 대한 비판일 뿐이다.
CORBA는 많은 기능을 갖춘 포괄적인 표준입니다.모든 [8]사양을 구현하려는 구현은 거의 없으며, 초기 구현은 불완전하거나 불충분했습니다.참조 구현을 제공해야 하는 요건이 없었기 때문에, 구성원들은 유용성이나 구현 가능성을 테스트하지 않은 특징을 자유롭게 제안할 수 있었다.표준이 장황한 일반적인 경향과 제출된 모든 제안의 합계를 채택하여 타협하는 일반적인 관행으로 인해 구현이 더욱 저해되었습니다. 이 경우 개별 제안이 완전히 [citation needed]합리적이어도 일관성이 없고 사용하기 어려운 API가 종종 생성되었습니다.
CORBA의 강력한 구현은 과거에는 획득하기가 매우 어려웠지만 지금은 훨씬 더 쉽게 찾을 수 있습니다.SUN Java SDK에는 CORBA가 내장되어 있습니다.잘못 설계된 구현 중에는 복잡하고, 느리고, 호환되지 않으며, 불완전하다는 것이 밝혀졌습니다.상당한 비용이 들지만 강력한 상용 버전이 등장하기 시작했습니다.고품질 무료 구현이 가능해짐에 따라 불량한 상용 구현은 빠르게 사라졌습니다.
방화벽
CORBA(더 정확히는 GIOP)는 특정 통신 전송에 관련되지 않습니다.GIOP의 전문화는 Internet Inter-ORB Protocol(IIOP)입니다.IIOP는 데이터를 전송하기 위해 원시 TCP/IP 연결을 사용합니다.
클라이언트가 매우 제한적인 방화벽 또는 트랜스페어런트프록시 서버 환경의 배후에 있으며 포트 80을 통한 외부로의 HTTP 접속만 허용하고 있는 경우 해당 프록시 서버가 HTTP CONNECT 방식 또는 SOCKS 접속도 허용하지 않는 한 통신이 불가능할 수 있습니다.한 때 구현에서 하나의 표준 포트를 사용하도록 강제하는 것조차 어려웠습니다.대신 여러 개의 랜덤 포트를 선택하는 경향이 있었습니다.현재 ORB에는 이러한 결함이 있습니다.이러한 어려움 때문에 일부 사용자들은 CORBA 대신 웹 서비스를 점점 더 많이 이용하고 있다.이들은 포트 80을 통해 XML/SOAP을 사용하여 통신합니다.이 포트 80은 일반적으로 HTTP를 통한 웹 브라우징을 위해 열려 있거나 조직 내부의 HTTP 프록시를 통해 필터링됩니다.다만, 최근의 CORBA 실장은 SSL을 서포트하고 있어, 1개의 포토로 동작하도록 간단하게 설정할 수 있습니다.또한 TAO, 옴니ORB 및 JacORB와 같은 일부 ORBS는 양방향 GIOP를 지원하며, CORBA는 웹 서비스 구현의 폴링 접근 방식 특성보다는 콜백 통신을 사용할 수 있는 이점을 제공합니다.또한 대부분의 최신 방화벽은 GIOP 및 IIOP를 지원하므로 CORBA 친화적인 방화벽입니다.

「 」를 참조해 주세요.

소프트웨어 엔지니어링

컴포넌트 기반 소프트웨어 테크놀로지

언어 바인딩

레퍼런스

  1. ^ "History of CORBA". Object Management Group. Retrieved 12 March 2017.
  2. ^ "History of CORBA". Object Management Group. Retrieved 4 June 2017.
  3. ^ "The CORBA Component Model". Dr. Dobb's Journal. 1 September 2004. Retrieved 13 March 2017.
  4. ^ "ORBexpress : Real-time CORBA ORB".
  5. ^ "omniORB : Free CORBA ORB". sourceforge.net. Retrieved 9 January 2014.
  6. ^ a b Chappel, David (May 1998). "Trouble with CORBA". davidchappel.com. Archived from the original on 3 December 2012. Retrieved 15 March 2010.
  7. ^ Waldo, Jim; Geoff Wyant; Ann Wollrath; Sam Kendall (November 1994). "A Note on Distributed Computing" (PDF). Sun Microsystem Laboratories. Retrieved 4 November 2013.
  8. ^ a b Henning, Michi (30 June 2006). "The Rise and Fall of CORBA". ACM Queue. Association for Computing Machinery. 4 (5): 28–34. doi:10.1145/1142031.1142044. S2CID 12103742. Retrieved 15 March 2010.

추가 정보

외부 링크

Wikibooks는 CORBA 프로그래밍에 관한 책을 가지고 있습니다.