Arquitetura Common Object Request Broker - Common Object Request Broker Architecture

Arquitetura Common Object Request Broker
Status Publicados
Ano começou 1991 ; 30 anos atrás ( 1991 )
Última versão 3,3
outubro de 2012 ; 8 anos atrás ( 2012-10 )
Organização Grupo de Gerenciamento de Objetos
Abreviação CORBA
Local na rede Internet corba .org

A Common Object Request Broker Architecture ( CORBA ) é um padrão definido pelo Object Management Group (OMG) projetado para facilitar a comunicação de sistemas que são implantados em diversas plataformas. CORBA permite a colaboração entre sistemas em diferentes sistemas operacionais, linguagens de programação e hardware de computação. O CORBA usa um modelo orientado a objetos, embora os sistemas que usam o CORBA não precisem ser orientados a objetos. CORBA é um exemplo do paradigma de objetos distribuídos .

Visão geral

CORBA permite a comunicação entre softwares escritos em diferentes idiomas e rodando em diferentes computadores. Os detalhes de implementação de sistemas operacionais, linguagens de programação e plataformas de hardware específicos são removidos da responsabilidade dos desenvolvedores que usam CORBA. CORBA normaliza a semântica de chamada de método entre objetos de aplicativos que residem no mesmo espaço de endereço (aplicativo) ou em espaços de endereço remotos (mesmo host ou host remoto em uma rede). A versão 1.0 foi lançada em outubro de 1991.

CORBA usa uma linguagem de definição de interface (IDL) para especificar as interfaces que os objetos apresentam para o mundo exterior. CORBA então especifica um mapeamento de IDL para uma linguagem de implementação específica como C ++ ou Java . Existem mapeamentos padrão para Ada , C , C ++ , C ++ 11 , COBOL , Java , Lisp , PL / I , Object Pascal , Python , Ruby e Smalltalk . Existem mapeamentos não padrão para C # , Erlang , Perl , Tcl e Visual Basic implementados por object request brokers (ORBs) escritos para essas linguagens.

A especificação CORBA determina que deve haver um ORB por meio do qual um aplicativo interagiria com outros objetos. É assim que é implementado na prática:

  1. O aplicativo inicializa o ORB e acessa um Adaptador de Objeto interno , que mantém itens como contagem de referência , políticas de instanciação de objeto (e referência) e políticas de tempo de vida do objeto.
  2. O Adaptador de objeto é usado para registrar instâncias das classes de código geradas . As classes de código geradas são o resultado da compilação do código IDL do usuário, que traduz a definição da interface de alto nível em uma base de classe específica do sistema operacional e do idioma para uso pelo aplicativo do usuário. Esta etapa é necessária para aplicar a semântica CORBA e fornecer um processo de usuário limpo para fazer a interface com a infraestrutura CORBA.

Alguns mapeamentos IDL são mais difíceis de usar do que outros. Por exemplo, devido à natureza do Java, o mapeamento IDL-Java é bastante direto e torna o uso do CORBA muito simples em um aplicativo Java. Isso também é verdadeiro para o mapeamento IDL para Python. O mapeamento C ++ requer que o programador aprenda tipos de dados anteriores à Biblioteca de Modelos Padrão C ++ (STL). Por outro lado, o mapeamento C ++ 11 é mais fácil de usar, mas requer uso intenso do STL. Como a linguagem C não é orientada a objetos, o mapeamento IDL para C requer um programador C para emular manualmente os recursos orientados a objetos.

Para construir um sistema que usa ou implementa uma interface de objeto distribuída baseada em CORBA, um desenvolvedor deve obter ou escrever o código IDL que define a interface orientada a objeto para a lógica que o sistema usará ou implementará. Normalmente, uma implementação de ORB inclui uma ferramenta chamada de compilador IDL que traduz a interface IDL para o idioma de destino para uso naquela parte do sistema. Um compilador tradicional então compila o código gerado para criar os arquivos de objetos vinculáveis ​​para uso no aplicativo. Este diagrama ilustra como o código gerado é usado na infraestrutura CORBA:

Ilustração da geração automática do código de infraestrutura a partir de uma interface definida usando o CORBA IDL

Esta figura ilustra o paradigma de alto nível para comunicações remotas entre processos usando CORBA. A especificação CORBA aborda ainda mais tipos de dados, exceções, protocolos de rede, tempos limite de comunicação, etc. Por exemplo: Normalmente, o lado do servidor tem o Adaptador de Objeto Portátil (POA) que redireciona as chamadas para os servidores locais ou (para equilibrar a carga) para o outros servidores. A especificação CORBA (e, portanto, esta figura) deixa vários aspectos do sistema distribuído para o aplicativo definir incluindo vidas úteis do objeto (embora semântica de contagem de referência esteja disponível para aplicativos), redundância / failover, gerenciamento de memória, balanceamento de carga dinâmico e aplicativo- modelos orientados, como a separação entre exibição / dados / semântica de controle (por exemplo, consulte Model – view – controller ), etc.

Além de fornecer aos usuários uma linguagem e uma especificação de chamada de procedimento remoto (RPC) neutra para a plataforma , o CORBA define serviços comumente necessários, como transações e segurança, eventos, tempo e outros modelos de interface específicos de domínio.

Histórico de versões

Esta tabela apresenta o histórico das versões do padrão CORBA.

Versão Data da Versão luzes
1.0 Outubro de 1991 Primeira versão, mapeamento C
1,1 Fevereiro de 1992 Interoperabilidade, mapeamento C ++
1,2 Dezembro de 1993 -
2.0 Agosto de 1996 Primeira grande atualização do padrão, também apelidada de CORBA 2
2,1 Agosto de 1997 -
2,2 Fevereiro de 1998 Mapeamento Java
2,3 Junho de 1999 -
2,4 Agosto de 2000 -
2,5 Setembro de 2001 -
2,6 Dezembro de 2001 -
3,0 Julho de 2002 Segunda grande atualização do padrão, também apelidada de CORBA 3
CORBA Component Model (CCM)
3.0.1 Novembro de 2002 -
3.0.2 Dezembro de 2002 -
3.0.3 Março de 2004 -
3,1 Janeiro de 2008 -
3.1.1 Agosto de 2011 Adotado como edição de 2012 da ISO / IEC 19500
3,2 Novembro de 2011 -
3,3 Novembro de 2012 Adição de ZIOP

Funcionários

Um servant é o destino de chamada que contém métodos para lidar com as chamadas de métodos remotos . Nas versões CORBA mais recentes, o objeto remoto (no lado do servidor) é dividido em objeto (que é exposto a invocações remotas) e servidor (para o qual a parte anterior encaminha as chamadas de método) . Pode ser um servidor por objeto remoto ou o mesmo servidor pode suportar vários (possivelmente todos) objetos, associados ao Adaptador de Objeto Portátil fornecido . O servidor para cada objeto pode ser definido ou encontrado "uma vez e para sempre" (ativação do servidor) ou escolhido dinamicamente cada vez que o método nesse objeto é chamado (localização do servidor). Tanto o localizador de servidor quanto o ativador de servidor podem encaminhar as chamadas para outro servidor. No total, esse sistema fornece um meio muito poderoso de balancear a carga, distribuindo as solicitações entre várias máquinas. Nas linguagens orientadas a objetos, tanto o objeto remoto quanto seu servidor são objetos do ponto de vista da programação orientada a objetos.

Encarnação é o ato de associar um servidor a um objeto CORBA para que este possa atender a solicitações. Encarnação fornece uma forma de servo concreta para o objeto CORBA virtual. Ativação e desativação referem-se apenas a objetos CORBA, enquanto os termos encarnação e eterealização se referem a servidores. No entanto, as vidas úteis de objetos e servos são independentes. Você sempre encarna um servo antes de chamar activate_object (), mas o inverso também é possível, create_reference () ativa um objeto sem encarnar um servo, e a encarnação de servo é feita posteriormente sob demanda com um Gerenciador de Servidores.

O O Adaptador de Objeto Portátil (POA) é o objeto CORBA responsável por dividir o manipulador de invocação remota do lado do servidor noobjetoremotoe seuservidor. O objeto é exposto para as invocações remotas, enquanto o servant contém os métodos que estão realmente tratando as solicitações. O servidor para cada objeto pode ser escolhido estaticamente (uma vez) ou dinamicamente (para cada chamada remota), em ambos os casos permitindo o encaminhamento de chamadas para outro servidor.

No lado do servidor, os POAs formam uma estrutura semelhante a uma árvore, onde cada POA é responsável por um ou mais objetos sendo servidos. Os ramos desta árvore podem ser ativados / desativados independentemente, ter o código diferente para a localização ou ativação do servidor e as diferentes políticas de tratamento de pedidos.

Características

O seguinte descreve algumas das maneiras mais significativas que o CORBA pode ser usado para facilitar a comunicação entre objetos distribuídos.

Objetos por Referência

Essa referência é adquirida por meio de um Localizador Uniforme de Recursos (URL), pesquisa NameService (semelhante ao Sistema de Nomes de Domínio (DNS)) ou passada como um parâmetro de método durante uma chamada.

As referências de objeto são objetos leves que correspondem à interface do objeto real (remoto ou local). O método chama o resultado de referência em chamadas subsequentes para o ORB e bloqueio no encadeamento enquanto espera por uma resposta, sucesso ou falha. Os parâmetros, dados de retorno (se houver) e dados de exceção são empacotados internamente pelo ORB de acordo com o idioma local e o mapeamento do sistema operacional.

Dados por valor

A linguagem de definição de interface CORBA fornece a definição de comunicação entre objetos neutra em termos de linguagem e sistema operacional. Objetos CORBA são passados ​​por referência, enquanto dados (inteiros, duplos, structs, enums, etc.) são passados ​​por valor. A combinação de objetos por referência e dados por valor fornece os meios para impor uma ótima tipagem de dados ao compilar clientes e servidores, ainda preservando a flexibilidade inerente ao espaço de problema CORBA.

Objetos por valor (OBV)

Além dos objetos remotos, o CORBA e o RMI-IIOP definem o conceito dos tipos OBV e Valuetypes. O código dentro dos métodos dos objetos Valuetype é executado localmente por padrão. Se o OBV foi recebido do lado remoto, o código necessário deve ser conhecido a priori para ambos os lados ou baixado dinamicamente do remetente. Para que isso seja possível, o registro, que define o OBV, contém a Base de Código que é uma lista separada por espaços de URLs de onde este código deve ser baixado. O OBV também pode ter os métodos remotos.

Modelo de Componente CORBA (CCM)

CORBA Component Model (CCM) é uma adição à família de definições CORBA. Foi introduzido com CORBA 3 e descreve uma estrutura de aplicativo padrão para componentes CORBA. Embora não dependa de " Enterprise Java Beans (EJB) dependente de linguagem ", é uma forma mais geral de EJB, fornecendo quatro tipos de componentes em vez dos dois que o EJB define. Ele fornece uma abstração de entidades que podem fornecer e aceitar serviços por meio de interfaces nomeadas bem definidas chamadas portas .

O CCM possui um contêiner de componentes, onde os componentes de software podem ser implantados. O contêiner oferece um conjunto de serviços que os componentes podem usar. Esses serviços incluem (mas não estão limitados a) notificação , autenticação , persistência e processamento de transações . Esses são os serviços mais usados ​​que qualquer sistema distribuído requer e, ao mover a implementação desses serviços dos componentes de software para o contêiner de componentes, a complexidade dos componentes é drasticamente reduzida.

Interceptores portáteis

Interceptores portáteis são os "ganchos", usados ​​pelo CORBA e RMI-IIOP para mediar as funções mais importantes do sistema CORBA. O padrão CORBA define os seguintes tipos de interceptores:

  1. Os interceptores IOR medeiam a criação das novas referências aos objetos remotos, apresentadas pelo servidor atual.
  2. Os interceptores do cliente geralmente medeiam as chamadas de método remoto no lado do cliente (chamador). Se o objeto Servant existir no mesmo servidor onde o método é invocado, ele também mediará as chamadas locais.
  3. Os interceptores de servidor medeiam a manipulação das chamadas de método remoto no lado do servidor (manipulador).

Os interceptores podem anexar as informações específicas às mensagens enviadas e IORs que estão sendo criados. Essas informações podem ser lidas posteriormente pelo interceptor correspondente no lado remoto. Os interceptores também podem lançar exceções de encaminhamento, redirecionando a solicitação para outro alvo.

Protocolo Geral InterORB (GIOP)

O GIOP é um protocolo abstrato pelo qual os Object request brokers (ORBs) se comunicam. Os padrões associados ao protocolo são mantidos pelo Object Management Group (OMG). A arquitetura GIOP fornece vários protocolos concretos, incluindo:

  1. Internet InterORB Protocol (IIOP) - O Internet Inter-Orb Protocol é uma implementação do GIOP para uso na Internet e fornece um mapeamento entre as mensagens GIOP e a camada TCP / IP .
  2. Protocolo SSL InterORB (SSLIOP) - SSLIOP é IIOP sobre SSL , fornecendo criptografia e autenticação .
  3. Protocolo HyperText InterORB (HTIOP) - HTIOP é IIOP sobre HTTP , fornecendo bypass de proxy transparente.
  4. IOP compactado (ZIOP) - Uma versão compactada do GIOP que reduz o uso de largura de banda.

VMCID (ID do conjunto de códigos secundário do fornecedor)

Cada exceção CORBA padrão inclui um código secundário para designar a subcategoria da exceção. Os códigos de exceção menores são do tipo longo sem sinal e consistem em um "ID do conjunto de códigos menor do fornecedor" (VMCID) de 20 bits, que ocupa os 20 bits de ordem superior, e o código menor propriamente dito, que ocupa os 12 bits de ordem inferior.

Os códigos menores para as exceções padrão são precedidos pelo VMCID atribuído ao OMG, definido como a constante longa sem sinal CORBA :: OMGVMCID, que tem o VMCID alocado para OMG ocupando os 20 bits de ordem superior. Os códigos de exceção secundária associados às exceções padrão que são encontrados na Tabela 3-13 na página 3-58 são or-ed com OMGVMCID para obter o valor do código secundário que é retornado na estrutura ex_body (consulte a Seção 3.17.1, "Padrão Definições de exceção ", na página 3-52 e Seção 3.17.2," Códigos de exceção secundária padrão ", na página 3-58).

Dentro de um espaço atribuído pelo fornecedor, a atribuição de valores aos códigos secundários é deixada para o fornecedor. Os fornecedores podem solicitar a alocação de VMCIDs enviando um e-mail para tagrequest@omg.org. Uma lista de VMCIDs atualmente atribuídos pode ser encontrada no site da OMG em: http://www.omg.org/cgi-bin/doc?vendor-tags

O VMCID 0 e 0xfffff são reservados para uso experimental. O VMCID OMGVMCID (Seção 3.17.1, "Definições de exceção padrão", na página 3-52) e 1 a 0xf são reservados para uso do OMG.

O Common Object Request Broker: Arquitetura e Especificação (CORBA 2.3)

Localização Corba (CorbaLoc)

Corba Location (CorbaLoc) refere-se a uma referência de objeto stringified para um objeto CORBA que se parece com um URL.

Todos os produtos CORBA devem suportar dois URLs definidos pelo OMG: " corbaloc: " e " corbaname: ". O objetivo deles é fornecer uma forma legível e editável para especificar um local onde um IOR pode ser obtido.

Um exemplo de corbaloc é mostrado abaixo:

corbaloc :: 160.45.110.41: 38693 / StandardNS / NameServer-POA / _root

Um produto CORBA pode, opcionalmente, oferecer suporte aos formatos " http: ", " ftp: " e " arquivo: ". A semântica disso é que eles fornecem detalhes de como fazer o download de um IOR stringificado (ou, recursivamente, fazer download de outro URL que acabará por fornecer um IOR stringificado). Alguns ORBs fornecem formatos adicionais que são proprietários para aquele ORB.

Benefícios

Os benefícios do CORBA incluem independência de idioma e sistema operacional, liberdade de implementações vinculadas à tecnologia, forte digitação de dados, alto nível de sintonia e liberdade dos detalhes de transferências de dados distribuídas.

Independência de linguagem
O CORBA foi projetado para liberar os engenheiros das limitações de acoplamento de seus projetos a uma linguagem de software específica. Atualmente, existem muitas linguagens suportadas por vários provedores CORBA, sendo os mais populares Java e C ++. Existem também implementações C ++ 11, C-only, Smalltalk, Perl, Ada, Ruby e Python, apenas para mencionar alguns.
Independência do sistema operacional
O design do CORBA deve ser independente do sistema operacional. CORBA está disponível em Java (independente do sistema operacional), bem como nativamente para Linux / Unix, Windows, Solaris, OS X, OpenVMS, HPUX, Android, LynxOS, VxWorks, ThreadX, INTEGRITY e outros.
Livre de tecnologias
Um dos principais benefícios implícitos é que o CORBA fornece um campo de jogo neutro para que os engenheiros possam normalizar as interfaces entre vários sistemas novos e legados. Ao integrar C, C ++, Object Pascal, Java, Fortran, Python e qualquer outra linguagem ou sistema operacional em um único modelo de design de sistema coeso, CORBA fornece os meios para nivelar o campo e permitir que equipes distintas desenvolvam sistemas e testes de unidade que podem posteriormente ser reunidos em um sistema completo. Isso não exclui a necessidade de decisões básicas de engenharia de sistema, como threading, temporização, vida útil do objeto etc. Esses problemas fazem parte de qualquer sistema, independentemente da tecnologia. CORBA permite que os elementos do sistema sejam normalizados em um único modelo de sistema coeso.
Por exemplo, o projeto de uma arquitetura multicamadas é simplificado usando Java Servlets no servidor da web e vários servidores CORBA contendo a lógica de negócios e agrupando os acessos ao banco de dados. Isso permite que as implementações da lógica de negócios mudem, enquanto as mudanças de interface precisariam ser tratadas como em qualquer outra tecnologia. Por exemplo, um banco de dados empacotado por um servidor pode ter seu esquema de banco de dados alterado para melhorar o uso ou desempenho do disco (ou até mesmo alterar o fornecedor do banco de dados em grande escala), sem afetar as interfaces externas. Ao mesmo tempo, o código legado C ++ pode se comunicar com o código legado C / Fortran e o código de banco de dados Java e pode fornecer dados para uma interface da web.
Digitação de dados
CORBA fornece tipagem de dados flexível, por exemplo, um tipo de dados "ANY". CORBA também impõe datatipos de dados fortemente acoplados, reduzindo erros humanos. Em uma situação em que os pares Nome-Valor são passados, é concebível que um servidor forneça um número onde uma string era esperada. A linguagem de definição de interface CORBA fornece o mecanismo para garantir que o código do usuário esteja em conformidade com nomes de métodos, retornos, tipos de parâmetros e exceções.
Alta sintonia
Muitas implementações (por exemplo, ORBexpress (implementação Ada, C ++ e Java) e OmniORB (implementação C ++ e Python de código aberto)) têm opções para ajustar os recursos de gerenciamento de threading e conexão. Nem todas as implementações de ORB fornecem os mesmos recursos.
Liberdade de detalhes de transferência de dados
Ao lidar com conexão de baixo nível e threading, CORBA fornece um alto nível de detalhes em condições de erro. Isso é definido no conjunto de exceções padrão definido por CORBA e no conjunto de exceções estendido específico da implementação. Por meio das exceções, o aplicativo pode determinar se uma chamada falhou por motivos como "Pequeno problema, tente novamente", "O servidor está inativo" ou "A referência não faz sentido". A regra geral é: Não receber uma exceção significa que a chamada do método foi concluída com êxito. Este é um recurso de design muito poderoso.
Compressão
CORBA organiza seus dados em um formato binário e oferece suporte à compactação. IONA, Remedy IT e Telefónica trabalharam em uma extensão do padrão CORBA que fornece compressão. Essa extensão é chamada de ZIOP e agora é um padrão OMG formal.

Problemas e críticas

Embora o CORBA tenha entregue muito na forma como o código foi escrito e o software construído, tem sido alvo de críticas.

Muitas das críticas ao CORBA derivam de implementações inadequadas do padrão e não de deficiências do próprio padrão. Algumas das falhas do próprio padrão foram devido ao processo pelo qual a especificação CORBA foi criada e os compromissos inerentes à política e aos negócios de escrever um padrão comum originado por muitos implementadores concorrentes.

Incompatibilidades de implementação inicial
As especificações iniciais do CORBA definiram apenas o IDL, não o formato on-the-wire. Isso significava que a compatibilidade do código-fonte era a melhor disponível por vários anos. Com CORBA 2 e posterior, esse problema foi resolvido.
Transparência de localização
A noção de transparência de localização do CORBA foi criticada; ou seja, os objetos que residem no mesmo espaço de endereço e acessíveis com uma chamada de função simples são tratados da mesma forma que os objetos que residem em outro lugar (processos diferentes na mesma máquina ou máquinas diferentes). Esta é uma falha fundamental de design, pois torna todo o acesso a objetos tão complexo quanto o caso mais complexo (ou seja, chamada de rede remota com uma ampla classe de falhas que não são possíveis em chamadas locais). Ele também oculta as diferenças inevitáveis ​​entre as duas classes, tornando impossível para os aplicativos selecionar uma estratégia de uso apropriada (ou seja, uma chamada com latência de 1 µs e retorno garantido será usada de forma muito diferente de uma chamada com latência de 1 s com possível falha de transporte , em que o status de entrega é potencialmente desconhecido e pode levar 30s para atingir o tempo limite).
Deficiências de design e processo
A criação do padrão CORBA também é frequentemente citada por seu processo de design por comitê . Não houve processo de arbitragem entre propostas conflitantes ou de decisão sobre a hierarquia de problemas a serem enfrentados. Assim, o padrão foi criado levando-se em conta a união dos recursos em todas as propostas, sem levar em consideração sua coerência. Isso tornava a especificação complexa, cara de implementar inteiramente e frequentemente ambígua.
Um comitê de design composto por uma mistura de fornecedores e clientes de implementação criou um conjunto diversificado de interesses. Essa diversidade dificultou um padrão coeso. Padrões e interoperabilidade aumentaram a competição e facilitaram a movimentação dos clientes entre implementações alternativas. Isso levou a muitas lutas políticas dentro do comitê e lançamentos frequentes de revisões do padrão CORBA que alguns implementadores de ORB garantiram serem difíceis de usar sem extensões proprietárias. Fornecedores CORBA menos éticos encorajaram o aprisionamento do cliente e alcançaram fortes resultados de curto prazo. Com o tempo, os fornecedores de ORB que incentivam a portabilidade assumiram a participação no mercado.
Problemas com implementações
Ao longo de sua história, CORBA tem sido atormentado por deficiências em implementações de ORB ruins. Infelizmente, muitos dos artigos que criticam o CORBA como um padrão são simplesmente críticas a uma implementação particularmente ruim do CORBA ORB.
CORBA é um padrão abrangente com muitos recursos. Poucas implementações tentam implementar todas as especificações e as implementações iniciais foram incompletas ou inadequadas. Como não havia requisitos para fornecer uma implementação de referência, os membros eram livres para propor recursos que nunca foram testados quanto à utilidade ou implementabilidade. As implementações foram ainda prejudicadas pela tendência geral da norma de ser prolixa e a prática comum de comprometer adotando a soma de todas as propostas enviadas, o que muitas vezes criava APIs que eram incoerentes e difíceis de usar, mesmo que as propostas individuais fossem perfeitamente razoáveis .
Implementações robustas de CORBA eram muito difíceis de adquirir no passado, mas agora são muito mais fáceis de encontrar. O SUN Java SDK vem com CORBA integrado. Algumas implementações mal projetadas foram consideradas complexas, lentas, incompatíveis e incompletas. Versões comerciais robustas começaram a aparecer, mas com um custo significativo. À medida que implementações gratuitas de boa qualidade se tornaram disponíveis, as implementações comerciais ruins morreram rapidamente.
Firewalls
CORBA (mais precisamente, GIOP ) não está vinculado a nenhum transporte de comunicações específico. Uma especialização do GIOP é o Internet Inter-ORB Protocol ou IIOP. O IIOP usa conexões TCP / IP brutas para transmitir dados.
Se o cliente estiver atrás de um firewall muito restritivo ou ambiente de servidor proxy transparente que só permite conexões HTTP para o exterior através da porta 80, a comunicação pode ser impossível, a menos que o servidor proxy em questão permita o método HTTP CONNECT ou conexões SOCKS também. Ao mesmo tempo, era difícil até mesmo forçar as implementações a usar uma única porta padrão - elas tendiam a escolher várias portas aleatórias. A partir de hoje, os ORBs atuais têm essas deficiências. Devido a essas dificuldades, alguns usuários têm feito uso crescente de serviços da web em vez do CORBA. Eles se comunicam usando XML / SOAP através da porta 80, que normalmente fica aberta ou filtrada por um proxy HTTP dentro da organização, para navegação na web via HTTP. No entanto, as implementações CORBA recentes suportam SSL e podem ser facilmente configuradas para funcionar em uma única porta. Alguns ORBS, como TAO , omniORB e JacORB também oferecem suporte a GIOP bidirecional, o que dá ao CORBA a vantagem de poder usar a comunicação de retorno de chamada em vez da abordagem de pesquisa característica das implementações de serviço da web. Além disso, a maioria dos firewalls modernos suporta GIOP e IIOP e, portanto, são firewalls compatíveis com CORBA.

Veja também

Engenharia de software

Tecnologias de software baseadas em componentes

Ligações de linguagem

Referências

Leitura adicional

links externos