•  22-07-2019
  •  | 
  •  

Pergunta

Para um projeto de computação distribuída a partir de hoje, com 0 componentes legados, existem boas razões para olhar para CORBA?

Foi útil?

Solução

Há ainda situações em que CORBA poderia ser uma boa resposta:

  • quando você está construindo uma distribuídos sistema que envolve programação múltipla línguas e múltiplas plataformas,
  • quando o sistema implica o envio estruturas de dados complexas ... e sabão não cortá-la,
  • quando você tem altas taxas de mensagens ... e HTTP não cortá-la, ou
  • quando você tem que interagir com clientes CORBA existentes e / ou serviços.

Mas tendo dito isso, existem alternativas que fazem o que CORBA faz, só que melhor ... ou assim eles dizem. Por exemplo zeroc

Editar @fnieto sinos para dizer (ou implica) que o ICE não é livre, mas TAO é.

Esta é imprecisa e enganosa .

  1. ICE é um software GPL, e está disponível para download gratuito. Você só precisava para pagar ICE se você / sua empresa não estão preparados para viver com os termos da GPL. (Ou, se você precisar de suporte.)
  2. Eu costumava ICE como um exemplo de um alternativa para CORBA. TAO é CORBA. Os autores ICE fazer um caso credível por que eles podem obter um melhor desempenho por não ser compatível com CORBA.
  3. TAO não é de forma a implementação CORBA única free / open-source. Eu posso pensar de 3 outros, fora do topo da minha cabeça.

O lado negativo da ICE é a falta de interoperabilidade com pilhas de middleware CORBA, mas na minha experiência interoperabilidade dos diferentes implementações CORBA também poderia ser problemático. (As coisas podem ter melhorado nessa área ... mas eu não ter feito qualquer trabalho CORBA desde ~ 2002, por isso estou um pouco fora de contato.)

Outras dicas

A partir das respostas existentes, este fica em quase um tema religioso. Pode-se olhar para CORBA da mesma forma que o meio cheio de vidro / meio vazio: por um lado, CORBA é datada de cruft legado, e, por outro lado, é relativamente estável, com várias implementações disponíveis e o "diabo que você conhece" <. / p>

Na minha linha de trabalho, vejo CORBA implantado em sistemas embarcados, sistemas de tempo real (CORBA tem extensões RT), e similares. Não há muitas alternativas AFAIK.

Outra "vantagem" de CORBA é a disponibilidade de vários de alta qualidade implementações de código aberto, por exemplo, TAO, MICO, JacORB, etc., com diferentes de licenciamento e suporte modelos. Há também edições ainda comerciais disponíveis.

Com relação à "maioria" CORBA os aplicativos a ser implementado em Java - que não é o caso na minha experiência. Enquanto o mapeamento idioma para CORBA para Java é uma das mais bonitas existe (que não pode estar dizendo muito), Java já tem um muito bom modelo de computação distribuída que oferece riqueza além CORBA, e todo-aplicativos Java uso que mais de CORBA. A grande maioria do desenvolvimento CORBA que eu vi é em C ++ (que é também o mapeamento da linguagem pior).

Finalmente, CORBA ofertas padronizadas invocações do lado do cliente assíncronas na forma de AMI, mas nunca ofereceu a manipulação assíncrona no lado do servidor. TAO oferece uma implementação do lado do servidor não-padrão chamado AMH.

Eu acredito que Corba era uma espécie de revivido por especificação EJB original, como EJB pode ser facilmente transformado em grãos CORBA por um pouco de configuração. Eu suspeito que a maioria das implantações Corba foram realmente implementado em Java.

Quanto à popularidade, acho que pode haver algumas implantações de ponta restantes para um número de décadas, mas para a maioria das pessoas Corba está morto.

Há um monte de maneiras muito sensuais para fazer a mesma coisa (exceto a grande final mencionado acima).

  • Cloud computing (serviços web, computação escalável, de acoplamento frouxo, filas).
  • serviços REST (web-services Lite).
  • serviços SOAP (web-services pesados).
  • Grade / cluster de computação (filas, Map-Reduce e similar)

Mas, claro, sua milhagem pode variar.

Obviamente, isso depende do tipo de comunicação do servidor e entre processos que você está considerando. E eu acho que Stephen C e Chris Cleeland cobrir positivos do Corba muito bem.

A nossa aplicação usou CORBA (Orbix) há mais de 10 anos, então é o legado agora. E para CORBA como está escrito é uma tecnologia boa. No entanto, se eu estava começando de novo, eu provavelmente não iria usar CORBA:

  • É complicado e só um pequeno número de pessoas em minha organização sabe muito bem como resultado todos os problemas difíceis cair sobre eles para resolver.
  • equipe de recrutamento pode ser um problema. CORBA apenas não é legal mais e não está ficando mais frio Embora em desenvolvedores Irlanda do C ++ são um pouco fina no chão também.
  • A maioria das empresas Consultoria quiser usar serviços da web para o trabalho de integração, então se você quiser 3 partes para fazer a integração que você provavelmente irá requerer uma API de serviços web de qualquer maneira.

Agora, dependendo do tipo de comunicação que eu queria eu provavelmente considerar:

  • buffers de protocolo para os lotes de pequenas mensagens (eu sei que eu teria que fornecer o transporte)
  • serviços web para menos mensagens grandes

Isto é baseado mais em encontrar pessoal e peritos, o apoio do 3o partido e alavancar bibliotecas de código aberto, em seguida, a qualidade técnica de CORBA, que eu uso todos os dias e é forte se um pouco complicado.

CORBA é certamente antiquado, mas também fornece algumas funções de alto nível fora da caixa (ver aqui ). Esta funcionalidade pode ser feito usando serviços da Web modernas, mas provavelmente não de forma padrão, e não sem uma grande quantidade de trabalho extra.

Para 99% dos serviços distribuídos, porém, CORBA é indesejável. É feio, complexo e difícil de usar.

Uma coisa que ninguém tenha mencionado aqui é aberta, abra padrões. De todas as tecnologias que existem (com exceção SOAP) é o único verdadeiro padrão papel branco aberto. A norma não é dependente de qualquer um tecnologias organizações. RMI (Sun / Oracle), DCOM (agora defuncted - Microsoft). É completamente Vendor e idioma neutro. Com exceção SOAP, nenhum dos outros DOS (Distributed objeto Technology) tecnologias são

Eu sou um arquiteto de software e regularmente ter que fazer a escolha de qual DOS deve ser usado em um projeto de sistema. Se não fosse para a guerra religiosa que enfrentar a cada vez, ele seria ou um MOM ou CORBA.

Olhe isto deste modo, se fosse assim tão morto, nenhuma das 3 redes / 4G iria funcionar. 3GPP está totalmente CORBA especificado. O Sistema Europeu satélite é tudo CORBA especificado. Pergunte-se porquê? É porque eles devem basear-se em fornecedores e de idioma arquiteturas neutros!

Eu diria que o actual nível de maturidade da Web Services (incluindo REST) ??e nos EJBs mundo Java (que pode até mesmo usar CORBA debaixo das cobertas) de cobertura que é necessário para os sistemas empresariais distribuídos.

Eu aconselho que um aspecto que você deve olhar com cuidado é o grau de interação assíncrona que você precisa em seu sistema distribuído. Eu postular que qualquer sistema distribuído de uma escala não-trivial precisa de comunicações assíncronas, e a infra-estrutura escolhida deve suportar o processamento asynch, normalmente isso significa filas.

Isso não é inconsistente com o uso de WebServices (ou mesmo CORBA), mas ele faz ponto-se um aspecto da sua seleção de produtos que podem passar despercebidos na excitação inicial de obter algum processamento distribuído indo

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top