Corba (Common Object Request Broker Architecture) é um padrão criado pela OMG (Object Management Group) para pomover a integração entre sistemas distribuídos heterogêneos. Visa diminuir consideravelmente os custos, reduzir a complexidade, e proporcionar caminhos para o surgimento de novas aplicações a partir dos conceitos propostos pela OMG. O CORBA, propõe a interoperabilidade local ou remota entre aplicações, independente das linguagens de programação em que foram desenvolvidas ou sobre quais plataformas serão executadas.
A primeira versão do CORBA, a 1.1, surgiu em 1991, onde se definiu a IDL (Interface Definition Language) e a API (Appliation Programing Interfaces). Porém a interoperabilidade só veio em 1994, com a segunda versão do CORBA, a 2.0, quando implementou-se o IOP (Inter-ORB Protocol).
A arquitetura CORBA é um conjunto complexo de partes que possuem suas particularidades e especificações, e que têm como objetivo comum, promover um ambiente que atenda às especificações definidas pela OMG para o CORBA.
O Cliente é toda entidade (programa) responsável por invocar uma determinada operação sobre uma implementação de objeto.
A Implementação de Objetos se refere às operações que podem ser implementadas em uma interface ORB IDL. Este componente tem informações de objetos, como dados internos, os códigos de seus métodos e seus respectivos procedimentos de ativação e desativação determinados na criação do objeto.
O ORB é o middleware responsável pela comunicação, de forma transparente, entre o cliente e a implementação do objeto desejado. O ORB é a principal arma na simplificação da programação em ambientes distribuídos, já que o mesmo libera os programadores de realizarem o árduo trabalho de programar a baixo nível os detalhes das invocações dos métodos.
A Interface ORB é definida como uma "interface abstrata" para o ORB, servindo como uma biblioteca de ajuda para os serviços locais do mesmo (ORB). Onde ainda, por esta interface se tratar de uma entidade lógica, pode ser implementada de diversas maneiras, portanto, a interface ORB vem justamente para desacoplar as aplicações dos detalhes de cada uma dessas implementações de ORB. Dentre as funcionalidades oferecidas por essa interface, temos a conversão de “referências a objetos” para strings e vice-versa, provê também a criação de listas de argumentos para as requisições que são realizadas através da DII.
A Interface de Invocação Dinâmica (DII) permite ao cliente, por meio do descobrimento dos métodos em tempo de execução, um acesso direto aos mecanismos de requisição residentes em um ORB e também que realizem uma sincronização deferida não-bloqueada (operações separadas de envio e recebimento) e chamadas unidirecionais (só de envio). Neste tipo de invocação, esse processo é feito de forma dinâmica sem necessitar passar pela interface específica da IDL para que seja ativado (Stub).
A Interface de Esqueleto Dinâmico (DSI) realiza uma função semelhante a realizada pela DII, a diferença básica, é que todas as atividades realizadas pela DSI são feitas no servidor. A principal característica da DSI é permitir que ORB transmita, apesar de não conhecer em tempo de execução o tipo de objeto utilizado, requisições para uma implementação de objeto.
O Stub está localizado no cliente, tem como característica promover interfaces estáticas para criar e enviar requisições correspondentes dos serviços desejados do cliente para o servidor. O Stub é criado utilizando-se um compilador IDL.
O Skeleton está vinculado diretamente com o Stub, e tem como função fornecer a interface através da qual o método recebe as requisições.
O Adaptador de Objeto, chamados também de AO, tem como principal função auxiliar o ORB no despacho de requisições para os objetos e na ativação de um determinado objeto. O AO é considerado o núcleo da comunicação do ORB, pois associa implementações de um objeto com o ORB. Podemos encontrar vários tipos de adaptadores de objetos, pois é possível especializá-los para uma determinada função, como exemplo de um AO especializado temos o OODB, que são adaptadores para objetos, adaptadores persistentes e de bibliotecas para objetos não-remotos, entretanto, independentemente de existir os AOs especializados, sempre será encontrado um "padrão" denominado BOA (Basic Object Adapter), que nada mais é do que um adaptador padrão presente em todos os ORB’s.
O Stub está localizado no cliente, tem como característica promover interfaces estáticas para criar e enviar requisições correspondentes dos serviços desejados do cliente para o servidor. O Stub é criado utilizando-se um compilador IDL.
O Skeleton está vinculado diretamente com o Stub, e tem como função fornecer a interface através da qual o método recebe as requisições.
O Adaptador de Objeto, chamados também de AO, tem como principal função auxiliar o ORB no despacho de requisições para os objetos e na ativação de um determinado objeto. O AO é considerado o núcleo da comunicação do ORB, pois associa implementações de um objeto com o ORB. Podemos encontrar vários tipos de adaptadores de objetos, pois é possível especializá-los para uma determinada função, como exemplo de um AO especializado temos o OODB, que são adaptadores para objetos, adaptadores persistentes e de bibliotecas para objetos não-remotos, entretanto, independentemente de existir os AOs especializados, sempre será encontrado um "padrão" denominado BOA (Basic Object Adapter), que nada mais é do que um adaptador padrão presente em todos os ORB’s.
Referências sobre Corba:
http://www.corba.org/
http://searchsoa.techtarget.com/definition/Object-Request-Broker
http://www.corba.org/
http://searchsoa.techtarget.com/definition/Object-Request-Broker
Postar um comentário