Computação Distribuída permite usuários diferentes ou computadores compartilhar informação. Computação Distribuída pode permitir uma aplicação em uma máquina usar o poder de processamento, memória, ou armazenamento em outra máquina. É possível que computação distribuída possa aumentar o desempenho de uma aplicação isolada, mas esta não é freqüentemente a razão para distribuir uma aplicação. Algumas aplicações, como processador de textos, poderiam não se beneficiar em danda da distribuição . Em muitos casos, um problema particular poderia exigir distribuição. Se uma companhia deseja colecionar informação por localizações, distribuição é um ajuste natural. Distribuição pode permitir aumentar desempenho ou disponibilidade em outros casos. Se uma aplicação tem que correr em um PC e a aplicação precisa executar cálculos longos e distribuir estes cálculos para máquinas mais rápidas poderia permitir aumentar desempenho.
Um objeto distribuído é um objeto que pode ser acessado remotamente. Isto significa que um objeto distribuído pode ser usado como um objeto regular, mas de em qualquer lugar da rede. É considerado tipicamente que um objeto encapsula dados e comportamento. A localização do objeto distribuído não é crítica ao usuário do objeto. Um objeto distribuído poderia proporcionar para seu usuário um jogo de capacidades relacionadas. A aplicação que provê um jogo de capacidades está freqüentemente chamado um serviço. Um Objeto Empresarial poderia ser um objeto local ou um objeto distribuído. O termo que objeto empresarial se refere a um objeto que executa um jogo de tarefas associado com um processo empresarial particular.
No máximo nível básico, CORBA é um padrão para objetos distribuídos. CORBA permite a uma aplicação solicitar a execução de uma operação por um objeto distribuído e os resultados da operação serem retornados à aplicação que faz o pedido. A aplicação comunica com o objeto distribuído que está executando a operação de fato. Esta é funcionalidade de cliente/servidor básica onde um cliente emite para um pedido a um servidor e o servidor responde atrás ao cliente. Dados podem passar do cliente ao servidor e podem ser associado com uma operação particular em um objeto particular. Dados são retornados ao cliente na forma de uma resposta.
Um servidor é definido como uma Interface em CORBA IDL. Dados que passam entre o cliente e o servidor são definidos como estruturas IDL, sucessões, etc. O IDL é compilado com um compilador de IDL e o código gerado é incluído dentro dos processos do cliente e do servidor. O servidor implementa uma interface particular. O implementação é o objeto distribuído. Clientes se comunicam com o objeto por uma referência de objeto. Quando uma operação é executada na referência de objeto, comunicação de cadeia acontece, são enviados parâmetros de operação ao servidor e o objeto distribuído atual executa a operação. Após isso, devolve qualquer dados apropriado então ao cliente.
Depende do vendedor específico e produto oferecido, mas não há nada no padrão que você achará terrivelmente oneroso.
Algumas aplicações querem fazer pedidos distribuídos, mas não espera pela resposta. Idealmente, eles querem ser notificados quando a resposta está disponível. Podem ser usadas linhas para permitir para aplicações fazer mais de um pedido ou continuar executando outras tarefas enquanto esperando por uma resposta, mas a linha que faz um pedido é bloqueada até a resposta está disponível. Comunicação de CORBA é basicamente uma requisição/resposta síncrona. Isto é verdade para todas as chamadas estáticas. Chamadas dinâmicas apoiam uma resposta de pedido adiada. Isto significa que uma aplicação pode emitir um pedido e pode aguardar a resposta. Pode ser usada comunicação de CORBA para notificar aplicações quando respostas associaram com pedidos mais cedo está disponível. Isto pode conduzir a uma arquitetura de aplicação mais complexa.
Antes de você que você possa usar CORBA para comunicação de client/server que você tem que implementar seu próprio corretor de pedido que apóia porções da especificação de CORBA inclusive IIOP (não sugiro) ou você pode obter um corretor de pedido de objeto que implementa a especificação de CORBA. Muitas companhias vendem corretoras de pedido de objeto que implementam tudo ou alguma da especificação de CORBA, incluindo várias partes do CORBA 2. x e 3.x , serviços CORBA , e outras integrações de terceiros. São incluídos links para os sites abaixo:
Informações adicionais pode ser encontradas em: * OMG List of free stuff.
DCOM é uma solução específica da Microsoft para distribuição . Produtos CORBA estão disponíveis em mais de 20 vendedores diferentes. Produtos CORBA apoiam qualquer sistema operacional ( Microsoft ou não ). CORBA é um mecanismo excelente para atravessar o caminho entre as estações Microsoft e os servidores UNIX.
Não. Podem ser desenvolvidas aplicações distribuídas usando CORBA e DCOM. Por exemplo, uma aplicação de cliente poderia ser desenvolvida para ter acesso um conjunto de objetos de automatização OLE , e esse objetos poderiam receber em troca objetos CORBA rodando em uma plataforma de não Microsoft tal como um UNIX. O OMG definiu uma especificação COM < - >CORBA para interconexões que unifica este tipo de ligação.
CORBA existe desde 1990. Implementações comerciais estão disponíveis desde 1992. DCOM ficou disponível em forma de beta em 1996. CORBA teve mais tempo para amadurecer. Também há um número grande de companhias diferentes desenvolvendo ORBs CORBA . Este nível de competição aumenta a robustez da soluções de CORBA em geral.
DCOM é bem ajustado para desenvolver apliacações front-end. Se as aplicações rodam sobre a plataforma da Microsoft, DCOM poderia ser uma escolha boa. DCOM também pode ser usado com CORBA. A pergunta não é se eu deveria usar DCOM ou CORBA?
O OSF desenvolveu um Ambiente de Computação Distribuída (DCE) bem antes de CORBA ser desenvolvido. Já existe uma base instalada de baseada em sistemas distribuídos DCE . Porém, o número de vendedores de DCE, e o número de plataformas suportadas por DCE é pequeno comparado a CORBA.
Os ambientes CORBA e DCE podem interoperar com o tipo correto de gateway. DCE é reconhecido pelo OMG como um ambiente importante e padronizou o DCE-ESEIOP ( DCE Environment Specific Interoperability Protocol ).
Não. Podem ser desenvolvidas aplicações distribuídas usando CORBA e DCE. Por exemplo, uma aplicação cliente poderia ser desenvolvida para ter acesso um jogo de objetos de DCE, e objetos de DCE poderiam ter acesso a objetos CORBA em troca. O OMG definiu um especificação de interconexão entre DCE < - >CORBA que unifica este tipo de relacionamento.
Não. DCE foi desenvolvido antes de CORBA. Isto dá para DCE um registro de rasto mais longo de instalações de sistema prósperas e fracassadas.
Uma distinção principal entre DCE e CORBA, porém, é que CORBA foi desenvolvido com o benefício de conceitos da orientação a objetos.
Outra distinção entre DCE e CORBA é a abrangência do padrão. CORBA é uma especificação mais ampla, e aponta para unificar definições de interface e serviços em ambiente comum de uma maneira orientada a objetos.
Enterprise Java Beans (EJB) é uma nova tecnologia para processamento distribuído. Sendo novo, EJB oferece simultaneamente atração (é novo! ) e risco (é novo! ). EJB não tem a larga base instalada da CORBA, nem tem tudo dos serviços. Mas, indubitavelmente, com o passar do tempo, desenvolvimentos de EJB e serviços crescerão. As distinções principais entre EJB e CORBA estão na flexibilidade e enfoque:
Os ambientes CORBA e de EJB podem naturalmente interoperar a nível de rede. Computação distribuída com Core Java e EJB usa Java Remote Method Invocation (RMI) para o protocolo de rede. CORBA’s IIOP e Java’s RMI são compatíveis no sentido de que IIOP pode transportar chamadas baseadas em RMI.
Não. Podem ser desenvolvidas aplicações distribuídas usando CORBA e EJB. Por exemplo, uma aplicação de cliente poderia ser desenvolvida para ter acesso um grupo de EJB e objetos CORBA sem distinção. Há algumas diferenças nos padrões de desígnio de interface nos dois ambientes.
Sim. EJB foi desenvolvido recentemente, bem depois de CORBA ter passado pelos seus problemas de adoção. Isto dá para CORBA um vasto registro de instalações de sistema prósperas e fracassadas. Porém, isto dá para EJB o benefício de handsight. Nós dissemos que “EJB é CORBA combinada com algumas melhores práticas.” Isto significa indicar
CORBA foi usado em uma variedade de indústrias em sistemas no mundo real . Reconheça que o domínio de problema que CORBA se dirige, i. e. , computação distribuída, é um domínio complexo. Qualquer sistema no mundo real de computação distribuída é complexo, possivelmente assuntos de endereço de tolerância de falta, disponibilidade, transações, mensagens, persistência, desempenho, e escalabilidade, isso só para mencionar alguns. CORBA provê infra-estrutura, serviços, e ferramentas para desenvolver soluções neste domínio complexo. A maioria dos sucessos e fracassos de CORBA não deveria ser associado como um todo à tecnologia, mas bastante o uso da tecnologia como parte de uma arquitetura.
Abaixo há uma lista de algumas histórias de sucesso da CORBA disponível na rede. Esta não é uma lista completa, mas bastante como um ponto de partida:
Sim.
Existe um numero de forma com que objetos CORBA podem ser acessados via aplicações baseada na web: