레거시 구성 요소가 0 인 오늘부터 시작되는 분산 컴퓨팅 프로젝트의 경우 CORBA를 살펴볼만한 이유가 있습니까?
답변
CORBA가 좋은 대답이 될 수있는 상황이 여전히 있습니다.
- 여러 프로그래밍 언어와 여러 플랫폼을 포함하는 분산 시스템을 구축 할 때
- 시스템이 복잡한 데이터 구조를 보내는 것을 수반하고 SOAP가 그것을 자르지 않을 때,
- 메시징 비율이 높고 HTTP가이를 차단하지 않을 때
- 기존 CORBA 클라이언트 및 / 또는 서비스와 상호 작용해야 할 때.
그러나 그렇게 말하면서 CORBA가하는 일을하는 대안이 있습니다. 예를 들어 ZeroC의 ICE
편집 ICE 무료 아니지만, TAO는 말 (또는 의미)에 차임 @fnieto.
이것은 부정확하고 오해의 소지가 있습니다.
- ICE는 GPL 소프트웨어이며 무료로 다운로드 할 수 있습니다. 귀하 / 귀하의 회사가 GPL 조건을 준수 할 준비가되어 있지 않은 경우에만 ICE 비용을 지불하면됩니다. (또는 지원이 필요한 경우.)
- CORBA 에 대한 대안 의 예로 ICE를 사용했습니다 . TAO는 CORBA입니다. ICE 작성자는 CORBA를 준수하지 않음으로써 더 나은 성능을 얻을 수있는 이유에 대해 신뢰할 수있는 사례를 제시합니다.
- TAO는 결코 유일한 무료 / 오픈 소스 CORBA 구현이 아닙니다. 내 머릿속에서 다른 3 명을 생각할 수 있습니다.
ICE의 단점은 CORBA 미들웨어 스택과의 상호 운용성이 부족하지만 내 경험상 다른 CORBA 구현의 상호 운용성도 문제가 될 수 있습니다. (해당 분야에서 상황이 개선되었을 수 있지만 … 2002 년 이후로 CORBA 작업을 한 적이 없으므로 약간의 접촉이 없습니다.)
답변
기존 답변에서 이것은 거의 종교적인 주제로 들어갑니다. 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라는 비표준 서버 측 구현을 제공합니다.
답변
나는 EJB가 약간의 구성으로 쉽게 CORBA 빈으로 전환 될 수 있기 때문에 Corba가 원래 EJB 사양에 의해 일종의 부활했다고 생각합니다. 대부분의 Corba 배포는 실제로 Java로 구현되었다고 생각합니다.
인기에 관해서는 수십 년 동안 일부 고급 배포가 남아있을 수 있지만 대부분의 사람들은 Corba가 죽었습니다.
동일한 작업을 수행 할 수있는 매우 섹시한 방법이 많이 있습니다 (위에서 언급 한 하이 엔드 제외).
- 클라우드 컴퓨팅 (웹 서비스, 확장 가능한 컴퓨팅, 느슨한 결합, 큐잉).
- REST 서비스 (웹 서비스 라이트).
- SOAP 서비스 (웹 서비스가 많음).
- 그리드 / 클러스터 컴퓨팅 (대기열, 맵 축소 및 유사)
물론 마일리지는 다를 수 있습니다.
답변
분명히 그것은 당신이 고려하고있는 서버와 프로세스 간 통신의 유형에 달려 있습니다. 그리고 저는 Stephen C와 Chris Cleeland가 Corba의 긍정적 인 부분을 잘 다루고 있다고 생각합니다.
우리 애플리케이션은 10 년 넘게 CORBA (Orbix)를 사용해 왔으므로 이제는 레거시입니다. 그리고 그것이 작성되는 방법에 대해 CORBA는 좋은 기술입니다. 그러나 처음부터 다시 시작했다면 CORBA를 사용하지 않을 것입니다.
- 그것은 복잡하고 내 조직의 소수의 사람들 만이 그것을 잘 알고 있으며 결과적으로 모든 어려운 문제가 해결되어야합니다.
- 직원 모집이 문제가 될 수 있습니다. CORBA는 더 이상 시원하지 않고 더 시원해지지 않습니다. 아일랜드에서는 C ++ 개발자도 약간 얇습니다.
- 대부분의 컨설팅 회사는 통합 작업을 위해 웹 서비스를 사용하기를 원하므로 타사에서 통합을 수행하려면 웹 서비스 API가 필요합니다.
이제 내가 원하는 의사 소통 유형에 따라 다음을 고려할 것입니다.
- 많은 작은 메시지를위한 프로토콜 버퍼 (전송을 제공해야한다는 것을 알고 있습니다)
- 적은 대용량 메시지를위한 웹 서비스
이것은 직원과 전문 지식, 타사 지원 및 오픈 소스 라이브러리를 활용하는 것보다 더 많은 것을 기반으로합니다. CORBA의 기술적 품질은 매일 사용하고 약간 번거 롭더라도 강력합니다.
답변
CORBA는 확실히 구식이지만 기본적으로 특정 고급 기능을 제공합니다 ( 여기 참조 ). 이 기능은 모두 최신 웹 서비스를 사용하여 수행 할 수 있지만 표준 방식은 아니고 많은 추가 작업 없이는 수행 할 수 없습니다.
그러나 99 %의 분산 서비스의 경우 CORBA는 바람직하지 않습니다. 추악하고 복잡하며 사용하기 어렵습니다.
답변
여기에서 아무도 언급하지 않은 것은 OPEN, OPEN STANDARDS입니다. 존재하는 모든 기술 (SOAP 제외) 중에서 유일한 진정한 개방형 백서 표준입니다. 표준은 한 조직의 기술에 의존하지 않습니다. RMI (Sun / Oracle), DCOM (현재는 사용되지 않음-Microsoft). 완전히 공급 업체 및 언어 중립적입니다. SOAP를 제외하고 다른 DOS (분산 개체 기술) 기술은
저는 소프트웨어 설계자이며 시스템 설계에 사용할 DOS를 정기적으로 선택해야합니다. 매번 직면하는 종교 전쟁이 아니었다면 MOM 또는 CORBA 중 하나 일 것입니다.
이런 식으로보세요. 그렇게 죽었다면 3 / 4G 네트워크는 작동하지 않습니다. 3GPP는 완전히 CORBA로 지정됩니다. 유럽 위성 시스템은 모두 CORBA로 지정됩니다. 이유를 스스로 물어보십시오. 공급 업체 및 언어 중립적 인 아키텍처를 기반으로해야하기 때문입니다!
답변
웹 서비스 (REST 포함) 및 Java 세계 EJB (커버 아래에서 CORBA를 사용할 수도 있음)의 현재 성숙도 수준은 분산 된 엔터프라이즈 시스템에 필요한 사항을 포함합니다.
주의 깊게 살펴보아야 할 한 가지 측면은 분산 시스템에서 필요한 비동기 상호 작용의 정도입니다. 사소하지 않은 규모의 분산 시스템에는 비동기 통신이 필요하며 선택한 인프라는 일반적으로 대기열을 의미하는 비동기 처리를 지원해야한다고 가정합니다.
이는 WebServices (또는 실제로 CORBA)의 사용과 일치하지 않지만 일부 분산 처리가 진행되는 초기 흥분에서 간과 될 수있는 제품 선택 측면을 지적합니다.
