Há muito para aprender com os erros de CORBA.
MICHI HENNING, ZeroC
Dependendo exatamente de quando se começa a contar, o CORBA tem entre 23 e 28 anos. Durante a sua vida útil, o CORBA deixou de ser uma tecnologia de ponta para os primeiros usuários, passou a ser um middleware popular e passou a ser uma tecnologia de nicho que existe em relativa obscuridade. É instrutivo examinar porque o CORBA – apesar de já ter sido anunciado como a “tecnologia de próxima geração para o comércio eletrónico” – sofreu esse destino. A história de CORBA é uma história que a indústria da informática já viu muitas vezes e parece provável que os atuais esforços de middleware, especificamente serviços da Web, sigam uma história semelhante.
Uma breve história
No início dos anos 90, conseguir que os programas comuniquem entre diferentes computadores era um pesadelo, especialmente se diferentes hardwares, sistemas operacionais e linguagens de programação estavam envolvidos: os programadores usavam soquetes e escreviam eles mesmos uma pilha de protocolos ou seus programas não comunicavam. (Outros middlewares de início, como Sun ONC, Apollo NCS e DCE, estavam vinculados ao C e Unix e não eram adequados para ambientes heterogêneos.)
Após um início falhado do CORBA 1.0, que não era interoperável e fornecia apenas um mapeamento C, o OMG (Object Management Group) publicou o CORBA 2.0 em 1997. Ele forneceu um protocolo padronizado e um mapeamento da linguagem C ++, com um mapeamento da linguagem Java a seguir em 1998. Isso deu aos desenvolvedores uma ferramenta que lhes permitiu criar aplicativos distribuídos heterogéneos com relativa facilidade. O CORBA rapidamente ganhou popularidade e vários aplicativos de missão crítica foram criados com a tecnologia. O futuro do CORBA parecia realmente bom.
Durante a fase de crescimento do CORBA em meados e no final dos anos 90, as principais mudanças afetaram o cenário da informática, principalmente o advento do Java e da Web. O CORBA forneceu um mapeamento da linguagem Java, mas não fez nada para cooperar com a Web em rápida explosão. Em vez de esperar que o CORBA forneça uma solução, as empresas voltaram-se para outras tecnologias e começaram a construir suas infraestruturas de comércio eletrónico baseadas em navegadores da Web, HTTP, Java e EJB (Enterprise JavaBeans).
Além disso, os desenvolvedores que adquiriram experiência com o CORBA descobriram que escrever qualquer aplicativo CORBA não trivial era surpreendentemente difícil. Muitas das APIs eram complexas, inconsistentes e absolutamente misteriosas, forçando o desenvolvedor a cuidar de muitos detalhes. Por outro lado, a simplicidade dos modelos de componentes, como o EJB, tornou a programação muito mais simples (se menos flexível); portanto, as solicitações de um modelo de componente CORBA se tornaram cada vez mais altas. Um modelo de componente demorou muito tempo para chegar, no entanto. O trabalho foi iniciado em 1996 em um CBOF (Common Business Object Facility), mas esse esforço foi atrapalhado em disputas políticas e acabou sendo abandonado, para ser substituído pelo CCM (CORBA Component Model). Uma especificação para o CCM foi finalmente publicada no final de 1999, mas acabou sendo um evento não recorrente:
- A especificação era grande e complexa e grande parte dela nunca havia sido implementada, nem como prova de conceito. A leitura do documento deixou claro que o CCM era tecnicamente imaturo; seções dele eram essencialmente não implementáveis ou, se fossem implementáveis, não forneciam portabilidade.
- Nenhum fornecedor comercial de CORBA se comprometeu a implementar o CCM, tornando-o um filho natimorto.
- Mesmo que as implementações estivessem disponíveis no momento em que o CCM foi finalmente publicado, era tarde demais. O cavalo já havia fugido: os EJB haviam entrincheirado na indústria a ponto de outra tecnologia de componentes não ter hipótese de sucesso.
O fracasso do CCM fez pouco para aumentar a confiança dos clientes de CORBA, que ainda estavam presos à sua tecnologia complexa.
Enquanto isso, a necessidade de middleware da indústria estava mais forte do que nunca. Após alguma experiência com sistemas de comércio eletrónico que usavam HTTP, HTML e CGI, ficou claro que a criação de sistemas distribuídos dessa maneira tinha sérias limitações. Sem um sistema de tipos adequado, os aplicativos eram reduzidos à análise de HTML para extrair semântica, o que equivalia a pouco mais que captura de tela. Os sistemas resultantes acabaram sendo muito frágeis. Por outro lado, o EJB tinha um sistema de tipos adequado, mas estava limitado ao Java e, portanto, não era adequado para muitas situações. Também havia algumas moscas na pomada CORBA:
- As implementações comerciais do CORBA normalmente custam vários milhares de dólares por estação de desenvolvimento, além de, em muitos casos, royalties de runtime para cada cópia implantada de um aplicativo. Essa aceitação limitada e mais ampla da plataforma – para muitos clientes em potencial, o CORBA era simplesmente muito caro.
- A plataforma tinha uma curva de aprendizado acentuada e era complexa e difícil de usar corretamente, levando a longos tempos de desenvolvimento e altas taxas de defeitos. As implementações iniciais também costumavam estar repletas de bugs e sofriam de falta de documentação de qualidade. As empresas tiveram dificuldade em encontrar os programadores CORBA de que precisavam.
A Microsoft nunca adotou o CORBA e, em vez disso, optou por criar seu próprio DCOM (Distributed Component Object Model). Isso manteve grande parte do mercado fora ou usando o DCOM, mas o DCOM também não conseguiu vencer a batalha do middleware, porque funcionava apenas no Windows. (Uma porta do DCOM para o Unix da Software AG nunca se destacou.) A Microsoft finalmente abandonou o DCOM após várias tentativas fracassadas de fazê-lo escalar. Naquela época, o mercado de middleware estava em um estado muito fragmentado, com várias tecnologias competindo, mas nenhuma capaz de captar a interesse suficiente para unificar o desenvolvimento de sistemas distribuídos.
Outro fator importante no declínio do CORBA foi o XML. No final dos anos 90, o XML se tornou o novo “blockbuster” da indústria da informática: quase por definição, se era XML, era bom. Depois de desistir do DCOM, a Microsoft não deixaria o mercado mundial de comércio eletrónico para seus concorrentes e, em vez de travar uma batalha que não poderia vencer, usou o XML para criar um campo de batalha totalmente novo. No final de 1999, a indústria viu a publicação do SOAP. Originalmente desenvolvido pela Microsoft e pela DevelopMentor, e depois passado para o W3C para padronização, o SOAP usou XML como a codificação “on-the-wire” para chamadas de procedimento remoto.
O SOAP apresentava sérias deficiências técnicas, mas, como estratégia de mercado, foi um golpe de mestre. Isso causou uma fragmentação ainda maior, à medida que vários fornecedores lutaram por uma fatia do bolo e afastaram os seus esforços de CORBA em direção ao crescente mercado de serviços da Web. Para os clientes, isso aumentou ainda mais a incerteza sobre a viabilidade do CORBA e, em muitos casos, levou-os a suspender o investimento na tecnologia.
O CORBA sofreu outro golpe quando a bolha da Internet estoirou no início de 2002. O colapso financeiro do setor expulsou muitas empresas de software do mercado e forçou os sobreviventes a reorientar seus esforços. O resultado foi um desgaste significativo no número de produtos comerciais CORBA. Antes do colapso, vários fornecedores já haviam descartado ou enfatizado seus produtos CORBA e, após o colapso, mais seguiram. O que em meados do final dos anos 90 havia sido um mercado em expansão, com muitos produtos concorrentes, de repente se transformou em um mercado marginal, com muito menos fornecedores, clientes e investimentos. Até então, estavam disponíveis implementações de código aberto do CORBA que compensavam parcialmente a saída dos fornecedores comerciais, mas isso não foi suficiente para recuperar a perda de consciência e restaurar a confiança do mercado: o CORBA não era mais o ente querido da indústria.
Hoje, o CORBA é usado principalmente para conectar componentes que são executados nas redes das empresas, onde a comunicação é protegida do mundo exterior por um firewall. Também é usado para o desenvolvimento de sistemas embarcados e em tempo real, um setor no qual o CORBA está realmente crescendo. No geral, no entanto, o uso do CORBA está em declínio e não pode ser chamado de nada além de uma tecnologia de nicho agora.
Dado que apenas alguns anos atrás, o CORBA era considerado a vanguarda do middleware que prometia revolucionar o comércio eletrónico, é surpreendente ver a rapidez com que a tecnologia foi marginalizada e é instrutivo examinar algumas das razões mais profundas do declínio.
Problemas técnicos
Obviamente, vários fatores externos contribuíram para a queda do CORBA, como o estoiro da bolha da Internet e a concorrência com outras tecnologias, como DCOM, EJB e serviços da Web. Pode-se argumentar também que o CORBA foi vítima de tendências e moda do setor. No setor de informática, a excelência técnica de uma determinada tecnologia frequentemente tem pouco a ver com seu sucesso – compartilhamento social e marketing podem ser fatores mais importantes.
Esses argumentos não podem explicar totalmente a perda de popularidade do CORBA, no entanto. Afinal, se a tecnologia tivesse sido tão atraente quanto o inicialmente previsto, é improvável que os clientes a abandonassem em favor de alternativas.
A excelência técnica não é um pré-requisito suficiente para o sucesso, mas, a longo prazo, é um pré-requisito necessário . Não importa quanto exagere na indústria, se uma tecnologia tiver sérias deficiências técnicas, ela será abandonada. É aqui que podemos encontrar os principais motivos do fracasso do CORBA.
Complexidade
O problema técnico mais óbvio é a complexidade do CORBA – especificamente, a complexidade de suas APIs. Muitas APIs do CORBA são muito maiores que o necessário. Por exemplo, o adaptador de objetos do CORBA requer mais de 200 linhas de definições de interface, mesmo que a mesma funcionalidade possa ser fornecida em cerca de 30 linhas – as outras 170 linhas não contribuem para a funcionalidade, mas complicam severamente as interações do programa com o tempo de execução do CORBA.
Outra área problemática é o mapeamento da linguagem C ++. O mapeamento é difícil de usar e contém muitas armadilhas que levam a erros, principalmente no que diz respeito à segurança do encadeamento, segurança de exceção e gestão de memória. Vários outros exemplos de APIs excessivamente complexas e mal projetadas podem ser encontrados na especificação CORBA, como os serviços de nomeação, negociação e notificação, todos os quais fornecem APIs sensíveis a erros e difíceis de usar. Da mesma forma, a configuração do CCM é tão complexa que não pode ser usada produtivamente sem o emprego de suporte adicional à ferramenta.
Interfaces e mapeamentos de linguagens mal projetados são uma parte muito visível de qualquer tecnologia, porque são a face negra do desenvolvimento de software: são o ponto em que os desenvolvedores e a plataforma se encontram, e sua usabilidade e segurança têm um grande impacto no tempo de desenvolvimento e contagem de defeitos. Obviamente, qualquer tecnologia que sofra de complexidade endémica faz pouco para agradar aos desenvolvedores e menos ainda para agradar aos responsáveis.
A complexidade também surge das escolhas arquiteturais. Por exemplo, os IORs do CORBA (referências a objetos interoperáveis) são entidades opacas cujo conteúdo deve permanecer oculto aos desenvolvedores. Isso é lamentável por três razões:
- Referências opacas praticamente forçam o uso de um serviço de nomenclatura porque os clientes não podem criar referências a objetos sem a ajuda de um serviço externo. Isso não apenas complica o desenvolvimento e a implantação do sistema, como também introduz um estado redundante no sistema (com o risco concomitante de corromper esse estado) e cria um ponto de falha adicional.
- Referências opacas complicam consideravelmente algumas APIs. Por exemplo, as APIs interceptoras do CORBA seriam muito mais simples se as referências a objetos fossem tornadas transparentes.
- Referências opacas requerem chamadas remotas para comparar a identidade do objeto de forma confiável. Para alguns aplicativos, a sobrecarga dessas chamadas é proibitiva.
Outra fonte de complexidade é o sistema de tipos. Por exemplo, a linguagem de definição de interface do CORBA fornece um grande conjunto de tipos, entre eles números inteiros não assinados, números de ponto flutuante de ponto fixo e de precisão estendida, sequências delimitadas e ilimitadas, bem como matrizes e um tipo “Universal” que pode armazenar valores de tipo arbitrário.
O suporte a esses tipos complica muitas APIs (em particular, as interfaces para introspecção e invocação dinâmica) e leva a sutis problemas de portabilidade. Por exemplo, Java não suporta tipos não assinados, portanto, o uso de um número inteiro não assinado em uma interface pode causar problemas de sobrescrita de memória quando um cliente Java comunica com um servidor C ++. Da mesma forma, em plataformas sem suporte nativo para números de ponto flutuante de ponto fixo ou precisão dupla, as implementações devem emular esses tipos. As emulações são difíceis de implementar, de modo que se comportem de forma idêntica nas plataformas e exigem APIs adicionais. Isso aumenta a complexidade e é uma fonte de problemas de interoperabilidade difíceis de diagnosticar.
Por fim, algumas das especificações de serviços de objetos anteriores do OMG, como ciclo de vida, consulta, controlo de concorrência, relacionamento e serviços de coleta, não eram apenas complexas, mas também não executavam nenhuma função útil. Eles apenas adicionaram ruído a um conjunto de especificações já complexo, confundiram clientes e reforçaram a reputação do CORBA de ser difícil de usar.
Recursos insuficientes
O CORBA fornece funcionalidade bastante rica, mas falha ao fornecer dois recursos principais:
Segurança. O tráfego não criptografado do CORBA está sujeito a ataques de interceptação e man-in-the-middle, e exige que uma porta seja aberta no firewall corporativo para cada serviço. Isso entra em conflito com a realidade das políticas de segurança corporativa. (Aliás, essa falha do CORBA foi um fator importante na ascensão do SOAP. Não ter que abrir uma porta no firewall corporativo e enviar tudo pela porta 80 foi visto como uma grande vantagem, apesar da ingenuidade dessa idéia.) O OMG fez várias tentativas de especificar a segurança e a travessia do firewall para o CORBA, mas foram abandonadas como resultado de deficiências técnicas e falta de interesse dos fornecedores de firewall.
Versionamento. O software comercial implantado requer middleware que permite atualizações graduais do software de uma maneira compatível com versões anteriores. O CORBA não fornece nenhum mecanismo de controlo de versão (exceto o de derivação, que é totalmente inadequado). Em vez disso, a versão de um aplicativo CORBA geralmente quebra o contrato on-the-wire entre cliente e servidor. Isso força todas as partes de um aplicativo implantado a serem substituídas de uma só vez, o que normalmente é inviável. (Essa falha do CORBA foi outro fator importante na ascensão do SOAP. A natureza supostamente fracamente acoplada do XML foi vista como abordando o problema, apesar de essa ideia ser tão ingénua quanto canalizar todas as comunicações pela porta 80.)
Para uma infraestrutura comercial de comércio eletrónico, a falta de segurança e o controlo de versão são simplesmente obstáculos – muitos clientes em potencial de comércio eletrónico rejeitaram o CORBA apenas por esses motivos.
Outras questões técnicas
Vários outros problemas técnicos afetam o CORBA, entre eles:
- As falhas de projeto no protocolo de interoperabilidade do CORBA tornam praticamente impossível a criação de um serviço de distribuição de eventos de alto desempenho.
- A codificação “on-the-wire” do CORBA contém uma grande quantidade de redundância, mas o protocolo não suporta compactação. Isso leva a um desempenho ruim em redes de área ampla.
- A especificação ignora o encadeamento quase completamente, portanto os aplicativos encadeados são inerentemente não portáveis (ainda que o encadeamento seja essencial para aplicativos comerciais).
- O CORBA não suporta transmissão assíncrona do lado do servidor.
- Não existem mapeamentos de linguagem para C # e Visual Basic, e o CORBA ignorou completamente o .NET.
Esta lista de problemas é apenas uma amostra e pode ser ampliada consideravelmente. Tais problemas afetam apenas uma minoria de clientes, mas aumentam a má imprensa de CORBA e limitam seu mercado.
Questões processuais
Os problemas técnicos estão no centro do declínio de CORBA. Isso levanta a questão de como é possível que uma tecnologia produzida pelo maior consórcio de software do mundo sofra tais falhas. Como se vê, os problemas técnicos são mais um sintoma do que uma causa.
O OMG é uma organização que publica tecnologia com base em consenso. Em essência, os membros votam para emitir uma RFP para uma especificação, as empresas membros enviam rascunhos de especificações em resposta e os membros votam em qual rascunho para aceitar como padrão. Em teoria, esse processo democrático é justo e equitativo, mas, na prática, não funciona:
Não há qualificações de entrada para participar do processo de padronização. Alguns colaboradores são especialistas na área, mas, para ser franco, um grande número de membros mal entende a tecnologia em que estão votando. Isso levou repetidamente à adoção de especificações com sérias falhas técnicas.
As RFPs geralmente exigem uma tecnologia não comprovada. A associação ao OMG pode ser dividida em aproximadamente dois grupos: usuários da tecnologia e fornecedores da tecnologia. Normalmente, são os usuários que desejam expandir o CORBA para adicionar um recurso que resolve um problema específico. Esses usuários, na esperança de que os fornecedores respondam com uma solução para seu problema, impulsionam a emissão de uma RFP. Os usuários, no entanto, geralmente sabem pouco sobre os aspectos internos de uma implementação CORBA. Na melhor das hipóteses, isso leva a RFPs contendo requisitos difíceis de implementar ou com impacto negativo no desempenho. Na pior das hipóteses, leva a RFPs que são pouco mais do que pedidos de fornecedores para realizar mágica. Em vez de padronizar as melhores práticas existentes, essas RFPs tentam inovar sem experiência prática anterior.
Os fornecedores respondem às RFPs, mesmo quando conhecem falhas técnicas. Isso pode parecer surpreendente. Afinal, porque um fornecedor aconselharia um padrão para algo conhecido se sofrer de problemas técnicos? O motivo é que os fornecedores competem entre si pelos clientes e estão continuamente disputando posição. A promessa de responder a uma RFP, mesmo quando está claro que ela contém sérios problemas, às vezes é usada para ganhar favores (e, esperançosamente, contratos) com os usuários.
Os fornecedores têm um conflito de interesses quando se trata de padronização. Para os fornecedores, a padronização é uma espada de dois gumes. Por um lado, a padronização é atraente porque facilita a venda da tecnologia. Por outro lado, muita padronização é vista como prejudicial porque os fornecedores desejam manter o controlo sobre os recursos que distinguem o seu produto da concorrência.
Às vezes, os fornecedores tentam bloquear a padronização de qualquer coisa que exija uma alteração em seus produtos existentes. Isso faz com que os recursos que devem ser padronizados permaneçam proprietários ou sejam vagamente especificados para serem úteis. Alguns fornecedores também negligenciam a distinção entre recursos padrão e proprietários, para que os clientes entrem no território específico da implementação sem aviso prévio. Como resultado, portar um aplicativo CORBA para a implementação de um fornecedor diferente pode ser surpreendentemente caro; os clientes geralmente veem-se ligados a um produto específico, apesar de toda a padronização.
As RFPs são frequentemente correspondidas por vários rascunhos de especificações. Em vez de escolher uma das especificações concorrentes, uma resposta comum dos membros do OMG é solicitar aos remetentes que mesclem seus recursos em uma única especificação. Essa prática é uma das principais causas da complexidade do CORBA. Ao combinar os recursos, as especificações acabam sendo o poço de todos os recursos imaginados por qualquer pessoa. Isso não apenas torna as especificações maiores e mais complexas do que o necessário, mas também tende a introduzir inconsistências: Recursos diferentes que, isoladamente, são perfeitamente razoáveis, podem interagir subtilmente entre si e causar conflitos semânticos.
Ocasionalmente, os principais fornecedores interrompem os procedimentos, a menos que seus recursos consigam entrar no padrão previsto. Isso faz com que o processo tecnológico se degenere em disputas políticas, force compromissos fracos e crie atrasos. Por exemplo, a primeira tentativa de um modelo de componente foi vítima dessas brigas internas, assim como a primeira tentativa de um mapeamento de C ++. Ambos os esforços foram atolados até o ponto em que tiveram que ser abandonados e reiniciados mais tarde.
O OMG não requer uma implementação de referência para que uma especificação seja adotada. Essa prática abre as portas para as especificações idealistas. Em várias ocasiões, o OMG publicou padrões que se mostraram parcial ou totalmente não implementáveis devido a sérias falhas técnicas. Em outros casos, as especificações que poderiam ser implementadas eram pragmaticamente inutilizáveis porque impunham uma sobrecarga de tempo de execução inaceitável. Naturalmente, incidentes repetidos desse tipo são embaraçosos e pouco contribuem para aumentar a confiança do cliente. Um requisito para uma implementação de referência obrigaria os remetentes a implementar suas propostas e evitaria muitos desses incidentes.
No geral, o processo de adoção de tecnologia do OMG deve ser visto como a principal razão do declínio do CORBA. O processo incentiva o esboço por grupo e manobras políticas a ponto de ser fácil alcançar a mediocridade técnica, ao invés da excelência técnica. Além disso, a adição de características desconexas leva a uma erosão gradual da visão arquitetural. (Por exemplo, o conceito arquitetural de referências opacas foi ignorado por uma atualização de especificação em 2000. O efeito líquido é que as referências não são mais opacas, mas as APIs ainda estão sobrecarregadas com a bagagem de tratá-las como opacas.)
As inúmeras falhas técnicas do CORBA se acumularam a um ponto em que é difícil consertar ou adicionar qualquer coisa sem quebrar outra coisa. Por exemplo, todas as revisões do protocolo de interoperabilidade do CORBA precisavam fazer alterações incompatíveis, e muitas correções e esclarecimentos precisavam ser retrabalhados várias vezes devido a interações imprevistas com recursos adicionados ao longo do tempo.
Podemos aprender com o passado?
Um processo democrático como o OMG é excepcionalmente inadequado para a criação de um bom software. Apesar dos problemas processuais conhecidos, no entanto, o setor prefere contar com grandes consórcios para produzir tecnologia. Os serviços da Web, a atual moda do middleware, usam um processo muito parecido com os OMGs e, por muitas contas, também sofrem com brigas internas, fragmentação, falta de coerência arquitetural, esboço por grupo e aumento dos recursos. Parece inevitável que os serviços da Web tenham uma história bastante semelhante à do CORBA.
Que etapas devemos tomar para obter um processo de padrões melhores e um middleware melhor? Vendo que falhas de procedimento são a causa raiz de falhas técnicas, sugiro pelo menos o seguinte:
Os consórcios de padrões precisam de regras revestidas de ferro para garantir que estandardizem as melhores práticas existentes. Não há espaço para inovação em padrões. Adicionar “apenas esse pequeno recurso extra” inevitavelmente causa problemas técnicos imprevistos, apesar das melhores intenções.
Nenhum padrão deve ser aprovado sem uma implementação de referência. Isso fornece uma verificação de sanidade de primeira linha do que está sendo padronizado. (Ninguém é brilhante o suficiente para examinar uma especificação e ter certeza de que ela não contém falhas ocultas sem realmente implementá-la.)
Nenhuma norma deve ser aprovada sem ter sido usada para implementar alguns projetos de complexidade realista. Isso é necessário para eliminar APIs ruins: Muitas vezes, os implementadores de uma API nunca usam suas próprias interfaces, com consequências desastrosas para a usabilidade.
Curiosamente, a comunidade de código aberto fez um trabalho muito melhor em aderir a essas regras do que os consórcios do setor.
A inovação de código aberto geralmente está sujeita a um processo de seleção darwiniano. Diferentes desenvolvedores implementam suas idéias de como algo deve funcionar, e outros tentam usar o recurso e fazer críticas ou aprimorá-lo. Dessa forma, o software é exaustivamente examinado e testado, e apenas a versão “mais adequada” sobrevive. (Muitos projetos de código aberto formalizam esse processo com versões experimentais e de produção alternadas: as versões experimentais atuam como base de teste e filtro evolutivo.)
Para criar software de qualidade, a capacidade de dizer “não” é geralmente muito mais importante do que a capacidade de dizer “sim”. O código aberto incorpora isso em algo que pode ser chamado de “ditadura benevolente”: Mesmo que muitas pessoas contribuam para o esforço geral , um único especialista (ou um pequeno grupo de especialistas) finalmente rejeita ou aceita cada alteração proposta. Isso preserva a visão arquitetural original e impede que provérbios cozinheiros demais estraguem o caldo.
No centro dessas práticas de código aberto estão dois pré-requisitos essenciais: cooperação e confiança. Sem cooperação, o processo evolutivo não pode funcionar; e sem confiança, nenhuma quadrilha de especialistas pode agir como um árbitro final. Porém, é exatamente nesse ponto que os consórcios de software encontram seu destino. É ingênuo colocar fornecedores e clientes concorrentes em um consórcio e esperar que eles apresentem um produto de alta qualidade – as realidades comerciais garantem que cooperação e confiança sejam as últimas coisas na mente dos participantes.
Obviamente, os consórcios de software contribuem para um processo evolutivo tanto quanto os projetos de código aberto. Mas é o mercado comercial que atua como plataforma de teste e filtro evolutivo, e são os clientes que, com suas carteiras, agem como o ditador (geralmente não tão benevolente). Isso equivale a pouco mais do que uma indústria que lança modas e clientes que saltam atrás delas como lémures sobre um penhasco. Até mudarmos esse processo, o dia do middleware universal de comércio eletrónico está mais distante do que nunca.
Michi Henning ( michi@zeroc.com ) é cientista chefe do ZeroC. De 1995 a 2002, trabalhou no CORBA como membro do conselho de arquitetura do OMG e como implementador, consultor e instrutor de ORB. Com Steve Vinoski, ele escreveu Advanced CORBA Programming with C ++ (Addison-Wesley, 1999). Desde que ingressou na ZeroC, ele trabalhou no esboço e na implementação do Ice, o middleware de próxima geração do ZeroC, e em 2003 foi co-autor de Distributed Programming with Ice. Ele é formado em ciências da informática pela Universidade de Queensland, Austrália.
Originalmente publicado em Queue vol. 4, n. 5 –