CORBA는 레거시입니까?

79

레거시 구성 요소가 0 인 오늘부터 시작되는 분산 컴퓨팅 프로젝트의 경우 CORBA를 살펴볼만한 이유가 있습니까?

corba 
— 플라이 바이 와이어
소스
27
솔직히 말해서 그들이 좋은 이유인지는 모르겠습니다. 그것은 끔찍한 기술입니다. 저는 여기서 전 CORBA 프로그래머로 말하고 있습니다.
2
좋은 이유는 CORBA가 처음 등장했을 때 실행 가능한 대안이 없었기 때문입니다 (DCOM 또는 DCE를 사용할 수없는 경우).
— skaffman
@skaffman 예를 들어 TIBCO와 같은 대안이있었습니다.
물론입니다.하지만 그것은 비싸다는 것은 말할 것도없이 추악했습니다.
— skaffman
3
@Skaffman 농담입니다! TIBCO Rendezvous는 CORBA보다 10 배 이상 사용하기 쉬웠습니다. 비용에 관해서는이 물건을 사용하는 IB가 그것을 감당할 수 있다고 생각합니다. 아니면 적어도 그때는 할 수있었습니다.

답변:

46

CORBA가 좋은 대답이 될 수있는 상황이 여전히 있습니다.

  • 여러 프로그래밍 언어와 여러 플랫폼을 포함하는 분산 시스템을 구축 할 때
  • 시스템이 복잡한 데이터 구조를 보내는 것을 수반하고 SOAP가 그것을 자르지 않을 때,
  • 메시징 비율이 높고 HTTP가이를 차단하지 않을 때
  • 기존 CORBA 클라이언트 및 / 또는 서비스와 상호 작용해야 할 때.

그러나 그렇게 말하면서 CORBA가하는 일을하는 대안이 있습니다. 예를 들어 ZeroC의 ICE

편집 ICE 무료 아니지만, TAO는 말 (또는 의미)에 차임 @fnieto.

이것은 부정확하고 오해의 소지가 있습니다.

  1. ICE는 GPL 소프트웨어이며 무료로 다운로드 할 수 있습니다. 귀하 / 귀하의 회사가 GPL 조건을 준수 할 준비가되어 있지 않은 경우에만 ICE 비용을 지불하면됩니다. (또는 지원이 필요한 경우.)
  2. CORBA 에 대한 대안 의 예로 ICE를 사용했습니다 . TAO는 CORBA입니다. ICE 작성자는 CORBA를 준수하지 않음으로써 더 나은 성능을 얻을 수있는 이유에 대해 신뢰할 수있는 사례를 제시합니다.
  3. TAO는 결코 유일한 무료 / 오픈 소스 CORBA 구현이 아닙니다. 내 머릿속에서 다른 3 명을 생각할 수 있습니다.

ICE의 단점은 CORBA 미들웨어 스택과의 상호 운용성이 부족하지만 내 경험상 다른 CORBA 구현의 상호 운용성도 문제가 될 수 있습니다. (해당 분야에서 상황이 개선되었을 수 있지만 ... 2002 년 이후로 CORBA 작업을 한 적이 없으므로 약간의 접촉이 없습니다.)

— 스티븐 C
소스
요점 1과 관련하여-크로스 플랫폼 및 크로스 언어 관점에서 CORBA와 웹 서비스가 어느 정도 동등 할 것으로 예상했습니다. 각각은 커버하지 않는 약점을 가지지 만 전반적으로 큰 차이는 보이지 않습니다. 이 비 레거시 시나리오의 경우 이것이 문제라고 생각하지 않습니다.
— djna
@djna :하지만 오늘날의 비 레거시 앱이 내일의 레거시 앱이라는 점을 고려하십시오. 오늘날 다국어 / 다중 플랫폼 미들웨어 기술을 사용하면 차세대 엔터프라이즈 앱과 통합 할 때 5 ~ 10 년 내에 도움이 될 수 있습니다.
— Stephen C
@Stephen. ICE의 유일한 문제는 가격이며 TAO는 무료입니다.
— fnieto-Fernando Nieto
3
잘했다. 실제로 Java 는 가장 눈에 띄는 무료 CORBA 구현입니다. 그리고 J2EE가 IIOP를 전송으로 요구한다는 사실은 CORBA가 그 어느 때보 다 더 널리 보급되고 '현재'있음을 의미합니다.
— user207421 2011
33

기존 답변에서 이것은 거의 종교적인 주제로 들어갑니다. CORBA는 반쯤 비었거나 반쯤 가득 찬 유리와 같은 방식으로 볼 수 있습니다. 한편으로는 CORBA는 오래된 레거시 cruft이고 다른 한편으로는 여러 구현이 가능하고 "당신이 알고있는 악마"로 비교적 안정적입니다.

내 작업 라인에서는 임베디드 시스템, 실시간 시스템 (CORBA에는 RT 확장 기능이 있음) 등에 CORBA가 배포되어 있습니다. AFAIK 대안이 많지 않습니다.

CORBA의 또 다른 "장점"은 TAO, MICO, JacORB 등과 같은 다양한 라이센싱 및 지원 모델과 함께 여러 고품질 오픈 소스 구현을 사용할 수 있다는 것입니다. 사용 가능한 상용 버전도 있습니다.

Java로 구현되는 "대부분의"CORBA 응용 프로그램과 관련하여 내 경험으로는 그렇지 않습니다. CORBA에서 Java 로의 언어 매핑은 가장 좋은 방법 중 하나이지만 (별로 말할 수는 없을 수도 있음) Java는 이미 CORBA 이상의 풍부함을 제공하는 매우 멋진 분산 컴퓨팅 모델을 가지고 있으며 모든 Java 앱은 CORBA보다 더 많이 사용합니다. 내가 본 대부분의 CORBA 개발은 C ++ (최악의 언어 매핑이기도 함)에 있습니다.

마지막으로 CORBA는 표준화 된 비동기 클라이언트 측 호출을 AMI 형식으로 제공하지만 서버 측에서는 비동기 처리를 제공하지 않았습니다. TAO는 AMH라는 비표준 서버 측 구현을 제공합니다.

— 크리스 클리 랜드
소스
20

나는 EJB가 약간의 구성으로 쉽게 CORBA 빈으로 전환 될 수 있기 때문에 Corba가 원래 EJB 사양에 의해 일종의 부활했다고 생각합니다. 대부분의 Corba 배포는 실제로 Java로 구현되었다고 생각합니다.

인기에 관해서는 수십 년 동안 일부 고급 배포가 남아있을 수 있지만 대부분의 사람들은 Corba가 죽었습니다.

동일한 작업을 수행 할 수있는 매우 섹시한 방법이 많이 있습니다 (위에서 언급 한 하이 엔드 제외).

  • 클라우드 컴퓨팅 (웹 서비스, 확장 가능한 컴퓨팅, 느슨한 결합, 큐잉).
  • REST 서비스 (웹 서비스 라이트).
  • SOAP 서비스 (웹 서비스가 많음).
  • 그리드 / 클러스터 컴퓨팅 (대기열, 맵 축소 및 유사)

물론 마일리지는 다를 수 있습니다.

— 앤드류 러셀
소스
15

분명히 그것은 당신이 고려하고있는 서버와 프로세스 간 통신의 유형에 달려 있습니다. 그리고 저는 Stephen C와 Chris Cleeland가 Corba의 긍정적 인 부분을 잘 다루고 있다고 생각합니다.

우리 애플리케이션은 10 년 넘게 CORBA (Orbix)를 사용해 왔으므로 이제는 레거시입니다. 그리고 그것이 작성되는 방법에 대해 CORBA는 좋은 기술입니다. 그러나 처음부터 다시 시작했다면 CORBA를 사용하지 않을 것입니다.

  • 그것은 복잡하고 내 조직의 소수의 사람들 만이 그것을 잘 알고 있으며 결과적으로 모든 어려운 문제가 해결되어야합니다.
  • 직원 모집이 문제가 될 수 있습니다. CORBA는 더 이상 시원하지 않고 더 시원해지지 않습니다. 아일랜드에서는 C ++ 개발자도 약간 얇습니다.
  • 대부분의 컨설팅 회사는 통합 작업을 위해 웹 서비스를 사용하기를 원하므로 타사에서 통합을 수행하려면 웹 서비스 API가 필요합니다.

이제 내가 원하는 의사 소통 유형에 따라 다음을 고려할 것입니다.

  • 많은 작은 메시지를위한 프로토콜 버퍼 (전송을 제공해야한다는 것을 알고 있습니다)
  • 적은 대용량 메시지를위한 웹 서비스

이것은 직원과 전문 지식, 타사 지원 및 오픈 소스 라이브러리를 활용하는 것보다 더 많은 것을 기반으로합니다. CORBA의 기술적 품질은 매일 사용하고 약간 번거 롭더라도 강력합니다.

— Iain
소스
@iain : 좋은 점. CORBA는 대부분의 CORBA 개발을 수행 한 Java에서도 사용하기가 쉽지 않습니다. POA / BOA 물건은 머리를 돌리기가 어렵습니다.
— Stephen C
3
예, 특히 POA 물건은 생각보다 어렵습니다
— iain
2
IDL을 C ++ 11 언어 매핑으로 표준화하고 CORBA를 사용하는 것이 훨씬 쉽습니다. 언어 매핑은 간단하며 STL에서 최대한 재사용합니다. 여전히 POA를 배워야하지만 그것은 정말 어렵지 않습니다.
— Johnny Willemsen 2013
13

CORBA는 확실히 구식이지만 기본적으로 특정 고급 기능을 제공합니다 ( 여기 참조 ). 이 기능은 모두 최신 웹 서비스를 사용하여 수행 할 수 있지만 표준 방식은 아니고 많은 추가 작업 없이는 수행 할 수 없습니다.

그러나 99 %의 분산 서비스의 경우 CORBA는 바람직하지 않습니다. 추악하고 복잡하며 사용하기 어렵습니다.

— Skaffman
소스
12
그리고 그 마지막 요점을 고려할 때 사람들이 soap / ws- *를 생각 해낸 이유입니다. 이제는 추하고 복잡합니다.
— leeeroy
대부분의 비하인드 스토리를 수행하는 프레임 워크로 작업 할 때 Soap은 그렇게 추하지 않습니다.
— arg20
어떤 대안을 제안합니까?
— schoetbi 2011-06-16
5
@ arg20 - 그건 조금 당신이 그것을 볼 수없는 경우 SOAP는 :-) 너무 추한 아니라고 말처럼
— 스티븐 C
12

여기에서 아무도 언급하지 않은 것은 OPEN, OPEN STANDARDS입니다. 존재하는 모든 기술 (SOAP 제외) 중에서 유일한 진정한 개방형 백서 표준입니다. 표준은 한 조직의 기술에 의존하지 않습니다. RMI (Sun / Oracle), DCOM (현재는 사용되지 않음-Microsoft). 완전히 공급 업체 및 언어 중립적입니다. SOAP를 제외하고 다른 DOS (분산 개체 기술) 기술은

저는 소프트웨어 설계자이며 시스템 설계에 사용할 DOS를 정기적으로 선택해야합니다. 매번 직면하는 종교 전쟁이 아니었다면 MOM 또는 CORBA 중 하나 일 것입니다.

이런 식으로보세요. 그렇게 죽었다면 3 / 4G 네트워크는 작동하지 않습니다. 3GPP는 완전히 CORBA로 지정됩니다. 유럽 ​​위성 시스템은 모두 CORBA로 지정됩니다. 이유를 스스로 물어보십시오. 공급 업체 및 언어 중립적 인 아키텍처를 기반으로해야하기 때문입니다!

— 셀빈
소스
2
Ermm ... 과거에는 OMG 표준 개발에 참여했으며 프로세스가 항상 원하는만큼 개방적이고 투명하지는 않았다고 말할 수 있습니다. 그리고 OMG는 역사적으로 컴플라이언스 문제에서 멀리 떨어져 있습니다. IETF 나 W3C가 더 잘하는 것은 아닙니다.
— Stephen C
1+ @Selvyn 나는이 정보를 찾고 있었다
— 토니의 Shih
@Selvyn, Michi Henning은 반대로 OMG의 개방성이 문제의 체계적인 원인이라는 매우 설득력있는 주장을 제시합니다. -queue.acm.org/detail.cfm?id=1142044 . 잘 읽었습니다.
— 준 보안
9

웹 서비스 (REST 포함) 및 Java 세계 EJB (커버 아래에서 CORBA를 사용할 수도 있음)의 현재 성숙도 수준은 분산 된 엔터프라이즈 시스템에 필요한 사항을 포함합니다.

주의 깊게 살펴보아야 할 한 가지 측면은 분산 시스템에서 필요한 비동기 상호 작용의 정도입니다. 사소하지 않은 규모의 분산 시스템에는 비동기 통신이 필요하며 선택한 인프라는 일반적으로 대기열을 의미하는 비동기 처리를 지원해야한다고 가정합니다.

이는 WebServices (또는 실제로 CORBA)의 사용과 일치하지 않지만 일부 분산 처리가 진행되는 초기 흥분에서 간과 될 수있는 제품 선택 측면을 지적합니다.

— djna
소스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.