Sistemas de Informação Distribuídos/Interoperação/Common Object Request Broker Architecture (CORBA)/A evolução da arquitetura e principais problemas

O CORBA foi uma arquitetura que teve uma ascensão muito rápida após o lançamento de suas primeiras versões, principalmente após a versão 2.0 que corrigiu algumas falhas e insuficiências das primeiras versões. O principal motivo dessa rápida ascensão foi a promessa de possibilitar a comunicação entre sistemas heterogêneos, o que era um grande desafio na época (período 1990-2000), e continua sendo até hoje.

Com o passar dos anos e a crescente utilização da arquitetura, os problemas começaram a aparecer. Nestes problemas estão incluídas questões de falhas nas implementações da arquitetura, acontecimentos históricos que influenciaram na utilização do CORBA e, principalmente, questões de projeto e padronização que levaram ao surgimento de diversos desses problemas.

Questões históricas

No fim dos anos 90, o enorme crescimento da Internet e da linguagem Java tornaram a busca por soluções Web cada vez maior. CORBA disponibilizou um mapeamento para a linguagem Java, mas, a demora no surgimento de soluções (implementações), fez com que as empresas buscassem outras tecnologias.

Duas dessas tecnologias foram o EJB, baseado em Java, e o DCOM, tecnologia proprietária da Microsoft. Esta forte concorrência de uma tecnologia baseada no promissor Java e outra tecnologia criada por uma grande e influente empresa da área, acabou reduzindo a adoção do CORBA em novos sistemas.

No mesmo período deu-se o surgimento do XML e, mais tarde, do SOAP, protocolos que, juntos, tornaram-se o padrão mais utilizados em transmissões de dados. Um sistema que utiliza esta combinação são os Web services, cujo surgimento colaborou ainda mais para o declínio do CORBA.

Questões técnicas

Entre os problemas técnicos, a complexidade da arquitetura é um dos aspectos mais relatados, principalmente a complexidade das APIs. Diversos itens relacionados à complexidade podem ser citados, como:

• Possui uma curva de aprendizado muito lenta;
• Dificuldade de utilização correta;
• Serviços como o de nomes e de notificações possuem APIs muito complexas e mal projetadas;
• O mapeamento para a linguagem C++ é muito difícil de ser utilizado;
• A IDL suporta uma enorme quantidade de tipos de dados, o que complica ainda mais as APIs e pode gerar problemas de compatibilidade entre diferentes linguagens (e.g. para que tipo de dados um dado do tipo x deve ser mapeado caso a linguagem de destino não suporte este tipo x?);
• Existência de especificações desnecessárias que apenas aumentam a complexidade do sistema.

Todos os itens listados estão associados e são causas/conseqüências da complexidade do sistema. Toda esta complexidade cria outras graves conseqüências, como o enorme aumento no tempo de desenvolvimento e alta taxa de erros existente nas implementações.

Apesar de disponibilizar diversas funcionalidades, CORBA falha em prover duas muito importantes: segurança e versionamento.

Segurança é uma funcionalidade indispensável em qualquer sistema de comunicação. O CORBA não prevê o uso de criptografia em suas mensagens e requer a habilitação de portas específicas nos firewalls que estão ao longo do caminho de transmissão. Não utilizar criptografia possibilita que os dados sejam interceptados e interpretados sem maiores dificuldades, enquanto a necessidade de habilitar novas portas no firewall pode ir contra políticas de segurança das empresas.

Obs: Problema que está solucionado com a especificação de um padrão de segurança que já foi adotado por algumas implementações.

Versionamento é outra funcionalidade não especificada pelo CORBA, eu requer que todas as partes de uma aplicação sejam substituídas ao mesmo tempo caso pelo menos uma delas seja modificada. Isso dificulta muito atualizações de grandes aplicações, mesmo que apenas uma pequena porção da mesma tenha sido modificada.

Esses dois últimos problemas citados auxiliaram no surgimento do SOAP. Por utilizar a porta 80 para comunicação, o SOAP não necessita de alterações nos firewalls, resolvendo (em partes) o problema de segurança, e, por ser baseado em XML, é fracamente acoplado, facilitando o versionamento.

CORBA também apresentou alguns problemas em suas implementações, como o alto custo de compra, que impossibilitava muitos consumidores de adotar essas soluções, e a grande quantidade de erros de versões iniciais, o que era normal devido à grande complexidade da arquitetura. Além destes, podem ser citados alguns como:

• A codificação usada para transmissão dos dados gera muita redundância nos dados, porém o protocolo não suporta compressão;

(IONA desenvolveu o ZIOP, um protocolo que estende o GIOP e possibilita compressão das mensagens, porém ainda não é padronizado.)

• A especificação ignora a existência de threads nas aplicações;
• Apesar da existência de mapeamentos para diversas linguagens, algumas como C# e Visual Basic não são suportadas.

(O "Espresso" da J-Integra possibilita que qualquer cliente criado em uma linguagem suportada pelo Framework .NET da Microsoft (nestas incluem-se C# e Visual Basic) acesse um servidor CORBA)

Forma de padronização

O processo de padronização utilizado no CORBA é indicado como um dos principais causadores dos problemas citados anteriormente, principalmente a complexidade. Alguns aspectos muito importantes na padronização são comentados abaixo:

• Não é necessária uma qualificação para participar do processo de padronização, o que possibilita que membros que não tenham conhecimento suficiente da tecnologia decidam o seu futuro;

• Muitas solicitações de especificações (RFPs) são feitas por usuários da tecnologia, que pouco conhecem-na internamente. Com isso são criadas requisições que podem gerar problemas graves na arquitetura, mas que mesmo assim são atendidas por algumas empresas que buscam conquistar esses clientes e vender seus produtos;

• Empresas normalmente são contra padronizações que resultem em modificações em seus produtos, o que dificulta o processo de padronização. Assim, muitas vezes é muito difícil obter portabilidade de aplicações entre diferentes implementações, mesmo com a padronização criada;

• Normalmente uma requisição é respondida com diversas propostas de especificações de diferentes empresas. Em vez de escolher a mais viável entre elas, a OMG solicita uma especificação que inclua todas as funcionalidades de todas as propostas, o que acaba sendo uma das principais causas da complexidade do sistema;

• A OMG não solicita uma implementação para que uma proposta se torne uma especificação definitiva, o que acaba gerando muitas especificações com problemas técnicos de implementação ou até mesmo não possíveis de serem implementadas.